質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.35%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

Q&A

解決済

6回答

933閲覧

データベースの設計について

peridot

総合スコア9

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

0グッド

0クリップ

投稿2020/10/05 06:08

編集2020/10/05 07:09

データベースの設計で1つのテーブルにデータを入れ込むか、
テーブルを複数持つかで悩んでいます。

条件は以下になります。
・500カ所以上にセンサーを設置し1日100件ほどデータを取得(年間1800万件ほど)
・1件あたりの測定個数は256個以上
・データベースのデータはWEBシステムでグラフや帳票にする(月ごとにパーティションで分割予定)
・稼働後もセンサーは少しずつ増える可能性あり
・使用するDBサーバーは2core8gbぐらいの低スペック

500カ所テーブルをもったほうが良いか、
1つのテーブルに入れ込んだほうが良いのかわかりません。

教えてください。
よろしくお願いします。

追記
パフォーマンス(速度)を求めています。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

m.ts10806

2020/10/05 06:18 編集

結局テーブル分割してもほぼ同じ容量を食うことになります。(テーブル分割したほうが使う領域多くなるとは思いますが) 低スペックだという認識でしたら、運用のためにスペック上げるしかなくなるのでは。
peridot

2020/10/05 06:31

すみません書いておりませんが容量ではなく速度を求めています。 運用にお金をかけれないのでスペックはとりあえずそこからスタートする予定です。
m.ts10806

2020/10/05 06:46

書いてないのでしたら質問本文に追記してください。 書いてあることが全てです。 それに、速度でしたら実際に簡易にテーブル作って同じデータ量突っ込んで参照すれば試せるのでは?
hentaiman

2020/10/05 08:48

要件いい加減過ぎてテーブル分割そのものを許容して良いのかどうかすら分かりませんね 質問者自身が「500テーブルに分けるほうがいいか」と言っている点をから、500に分けてもシステムの動作には全く影響ないと考えていいんですかね?
guest

回答6

0

パーティショニングするなら1つのテーブル十分対応できる量だと思います

投稿2020/10/05 07:15

yambejp

総合スコア116724

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

peridot

2020/10/26 06:43

回答ありがとうございます。 試しに1億件のデータ作成してみました。 おっしゃる通り対応できそうです。
guest

0

ベストアンサー

500個テーブルを作のは無いかと思います。
SQLアンチパターンに該当します。
測定か所は簡単に増減するとのことですし。

パーティションを設定するなら、十分対応できる量かなと思います。
WEB側で画面やグラフの表示に時間がかかるなら、集計後のデータを作成するバッチを作り
別テーブルに持っておくことをおススメします。

投稿2020/10/05 14:17

Kaiser

総合スコア295

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

peridot

2020/10/26 06:47

回答ありがとうございます。 SQLのアンチパターンに該当するんですね。 有名な書籍ですよね?読んでみます。
guest

0

計算すると。
単純に1レコード化する場合
500ケ×31日×100件×256個=396.8百件/月(約4億件)
1件に複数検査項目を入れて1レコード化する場合
500ケ×31日×100件=1.55百件/月(約2百万件)

月に4億件の方ですと言われてます様に多いと思います。
パーティションで分割と言われていますので、こちらが第一候補でしょうか。
月に2百万件であれば普通に見かける件数と思いますので、さほど悩まないかと思います。
ただ、その後のアプリケーションで利用する時に難しくなるケールがあります。

意見ですが、データ用テーブルは月4億件側の1本が良いかと思います。使い勝手が良いです。
構成にて極力項目数/項目長を少なくして対応します。
年月/日/時刻/箇所NO/センサーNO/件NO/測定内容NO/測定値
といった感じでしょうか。項目もINTなど短い項目型を採用。
その他名称等は、日常的に増加がないマスタテーブル側に持たせます。
こちらをメインデータとして運用。

データベースのデータはWEBシステムでグラフや帳票にする

こちらが目的の様ですので、
グラフ用テーブル
とか帳票用テーブルを別途作成。
箇所NO/箇所名称/センサーNO/センサ名称/年月日/回数/検査名1/検査値1/検査名2/検査値2・・・・
こんな感じでしょうか。
1日1回夜中にでもこのテーブルへバッチ更新を行い、WEBシステム側ではこのテーブルを見る事で速度向上を図ります。
速度上げるため古いデータは削除で良いと思います。
バッチは場合によって1時間に一回とか、年月日+箇所NOで部分的にデータを更新させるプログラムがあっても良いと思います。
検査測定データですので、それほどリアルタイムの必要性は低いと予想しますので、バッチで良いかと思われます。

パーティション機能は使った事が無いので速度的に効果あるんでしょうか?
インデックスを適切に張っても行く様な気がします。
パーティションの場合には、先頭に当月区分(例:値1)とか項目設けて、これを選択したパーティションを見れば当月データが見れるイメージでしょうか。

投稿2020/10/07 00:11

編集2020/10/07 00:19
ad.sys.soleil

総合スコア28

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

peridot

2020/10/26 06:51

回答ありがとうございます。 月に2百万件で考えていました。 4億件の方法は件数が跳ね上がるので考えていませんでしたが、 利用する観点からするとそちらが良いのですね。 ちなみにパーティショニングはかなり効果有りました。
guest

0

肥大化は結局パフォーマンスに直結します。
増える可能性がある情報をテーブルわけるというのはメンテナンス性にも直結しますし
複雑なデータ配分になりますので、結局パフォーマンスに影響するのではないでしょうか。
同じテーブル構成なのであればテーブルを分割するメリットはありません。

投稿2020/10/05 08:09

m.ts10806

総合スコア80875

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

peridot

2020/10/26 06:46

回答ありがとうございます。 1つのテーブルで作成してみます。
guest

0

高速処理化!MySQLのパーティショニング機能を使ってみよう
1テーブルの内容を分割保存することができ
使用する場合は1テーブルと見なすことができます。

19.6 パーティショニングの制約と制限

制約もありますがこの様な方法があるという事です。

追記
細かく書かないと判らない人がいるみたいなので

今現在MySQLでは最大8192パーティションまで対応しています。

質問者様が想定している月毎だと1パーティション
年間1800万件 / 12か月 = 150万件

それより
箇所毎だと1パーティション
年間1800万件 / 500カ所 = 3.6万件

が良いのでは?
ただし使用目的や用途によっては適さない分け方です。
そこは質問者様が判断して下さい。

あと一定期間過ぎたら集計結果しか使わないなどの場合
元となるデータをバックアップテーブルに一部移し替える手法もあります。
(ひと月に一回1年前より古いデータは移し替える)

パーティションとバックアップの併用は可能ですのでご検討下さい。

投稿2020/10/05 07:25

編集2020/10/05 18:21
kuma_kuma_

総合スコア2506

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

hentaiman

2020/10/05 18:22

>細かく書かないと判らない人がいるみたいなので というよりいたずら低評価に見えますが、そうでないなら理由は気になるところです
peridot

2020/10/26 06:45

回答ありがとうございます。 パーティショニングを使う予定でした。 実際に試作したところかなり良いパフォーマンスが得られました。
guest

0

パフォーマンスにもよりますが、あんまりJOINしないで
引っ張ってこれる設計にした方があとあと楽なのではと思いました。
せめて500をいくつかのグループにわけるとか。

投稿2020/10/05 06:54

firegrape

総合スコア902

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

peridot

2020/10/26 06:43

回答ありがとうございます。検討してみます。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.35%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問