web-dev-qa-db-ja.com

年間1億行の1つのテーブルのどのDBですか？

私は70問の質問票を持っており、回答を保存する必要があります。

問題：それは年間1億レコードです。

私はさまざまなタイプのストレージでの経験がありますが、これらの膨大な数に対処する必要はありませんでした。今、私はすべての間違った決定が大きなマイナスの影響につながる可能性があることを恐れています。

情報データについて：

  • 1テーブル70列について考えていました
  • 列は既に定義されており、しばらくするとわずかに調整される可能性があります（+/- 10列）
  • 各列のデータ型は主に整数と文字列で主に2文字、最大です。 10文字。
  • ネストされた（ツリー）構造は不要
  • 柔軟なデータ型は不要
  • 結合は不要

データ定義（疑似コード）

COLUMN           |   TYPE   | MAX. LENGTH
-----------------------------------------
id               | Integer  | 10  
questionnaire_id | Integer  | 10
answered_at      | Datetime | -
answered_by      | Integer  | 10
answer1          | Integer  | 2
answer2          | Integer  | 2
answer3          | Integer  | 2
answer4          | Integer  | 2
...
answer35         | String   | 2
answer36         | String   | 2
...
answer70         | String   | 2

優先度：

  • ビッグデータを保存する
  • 標準の集計関数（平均、最小、最大、カウントなど）を実行し、許容可能な時間でフィルタリングおよびソート

ベストプラクティスまたはチェックリストがあり、それによって私のオプションが減り、それにより間違った決定が下りますか？

前もって感謝します！

編集：デイブから着想を得て正規化

# questionnaire
- id (PK, AI)

# questions
- id (PK, AI)
- questionnaire_id (FK)
- label

# submits
- id (PK, AI)
- questionnaire_id (FK)
- answered_by
- answered_at

# answers
- id (PK, AI)
- submit_id (FK)
- question_id (FK)
- value      // Integers only (strings are mapped: A => 1, B => 2)
database-designdata-warehouse
2
Mr. B.

このテーブルでは、追加のキー/インデックスはなく、1行あたり160バイトなので、年間100,000,000行は約16GByteになります。適切なハードウェア/仮想リソースがあれば、適切なDBMS（SQL Server、postgres、[YourFavouriteDBHere]、...）がそれに対処でき、（適切なインデックス付けを前提として）効率的にクエリを実行できるはずです。キーや他のインデックスが占める余分なスペースは、スペース要件をあまり膨らませるべきではありません。もしそうなら、構造がより一般的に最適ではない可能性があります。

したがって、単にデータを保存するだけで心配はありません。

一部のデータベースは、圧縮、スパーステーブル、およびその他の手法をサポートしています。これらの手法は、スペースが主な関心事である場合にこの構造に非常に役立ちますが、最初に検討する前に、これが実際に必要な構造であることを確認してください。

他の人がコメントで議論しているように、現在の構造は実行する必要がある分析に最適ではない可能性があるため、ヘルプが必要な場合は、質問を編集してそのような詳細を含める必要があります。 すべてのデータベース設計で重要なことは、希望の出力と入力を考慮することです。

残念ながら、現時点で必要なすべての選択クエリがわかりません。

データに対して実行する予定のレポートの種類についてsomeのアイデアが必要です。これは、実行するすべてのクエリである必要はなく、またはそれに近いものである必要はありませんが、some予想されるレポートを最適化することは、最終的に出てくる何か/何か。

可能な限り、入力だけに基づいて設計しないでください。

出力についての考えがなければ、おそらくはい：日付にインデックスを付けたテーブルにデータを投げるだけです。これは、少なくとも、データをフィルター/パーティション/集計する主要な方法の1つである可能性が高いためです。レポートで、実行する必要のある分析がわかっている場合は、ETLを介してデータを別のデータに変換します。ただし、最初に出力についての考えがある場合は、2つの構造（1つはアクティブな記録用、もう1つはレポート用）を作成して維持する必要がないようにすることができますandからデータを変換するプロセスもう一方へ。もちろん、この2つの構造システムmightは最適ですが、詳細を説明しない限り、どちらか一方の方法を説明することはできません。

5
David Spillett

データ型を縮小します。必要に応じて、INTからTINYINTに変更すると、300MB以上節約できます。必要に応じて、代理の代わりに「自然な」PKを使用します。例：PRIMARY KEY(submit_id, question_id) for answers参照： http://mysql.rjweb.org/doc.php/schema_best_practices_mysql

あなたは70の質問が時間とともに少し変わるかもしれないと言います。これは深刻な問題であるか、軽微な迷惑である可能性があります。これらを尋ねて答えてください：

  • 72に変更した後、70の質問があった場合、回答はどうなりますか？
  • 質問を削除しますか？
  • 最終的に80の質問に回答しても問題ないでしょうか。そのうちのいくつかはもう使用されていません。つまり、質問番号15は常に「...」を参照するか、なくなってしまいます。つまり、他の質問に置き換えられることはありません。 （このアプローチは賢明かもしれません。）
  • 70列vs 70行-ALTER TABLE新しい列を追加するにはいくらかコストがかかりますが、ほとんど起こりません。
  • 70列vs 70行-70列は、ディスク容量の半分しか使用できません。これは問題ですか？

約40GB /年になります。

たとえば、週ごとにデータを要約することは理にかなっていますか？その後、生データをクエリするよりもはるかに迅速に、1年間のレポートを迅速に作成できます。

2
Rick James