web-dev-qa-db-ja.com

長期的なデータベースのスケーラビリティに優れている：列の追加またはキー/値ストアの使用

現在のところ少数（5〜10）の設定がありますが、将来的にはさらに多く（最大100）になるアプリケーションの場合は、より良いアプローチになります。

  1. 新しい設定が導入されるたびに新しい列を設定テーブルに追加する
  2. キー/値のストレージとして設定テーブルを持つ

アプリケーションに数百万のインスタンス（すべてが同じdbで実行され、同じテーブルを設定に使用する）がある場合、DBはシャーディングされる可能性があることを考慮してください。 DBはリレーショナルです。つまり、MySQLまたはT-SQLです。

開発者としては2番目のバリアントを使用したいので、DBスキーマを変更したり、設定を自由に追加/削除したりせずにアプリケーションをスケーリングできました。インデックスがアプリケーションインスタンスにクラスター化されている場合、1つのテーブルに数百万のレコードが存在することは問題ではないと理解しています。私が気づいていない欠点はありますか？

そして、1番目のバリアントはどうですか？大きなメリットはありますか？そして、列の数はどうですか：テーブルが持つことができる列の理論的な制限はありますか？ 1000（10000、1000 000）列のテーブルがあるとどうなりますか？遅いですか？

mysqldatabase-designt-sqlscalabilityeav
4
valentinas

オプション2は「EAV」または エンティティ属性値 として知られています

  • 関係ではない
  • dBレベルの制約なし
  • 単純なリストでない限り、データを読み取るにはゆがみが必要

しかし、「設定」が何を意味するかによって異なります。オブジェクトではなく、制約を必要としない数千の行がある場合、はい、このパターンを使用します。これは、SQL Serverが sys.configurations で行うことです。

何かを格納できる「柔軟なスキーマ」を作成しようとしている場合は、 しないでください 。それは涙で終わります。 DBA.SEの EAVに関する質問も参照してください

「追加の列」（オプション1）ではデフォルトとデータ型の安全性を定義できますが、「行がない」（オプション2）ではコードにデフォルト値を格納する必要があり、すべてがデータベース内の文字列です。

"場合によります"

6
gbn

どちらでもない。

代わりに、以下を実行します。

プランA：

  1. 実際にインデックスが必要なフィールドを決定します。いいえ、すべてのフィールドにインデックスが必要なわけではありません。
  2. 残りの列と将来の列をプログラミング言語の「ハッシュ」または「連想」配列に配置します。これをJSONにマーシャリングします。
  3. JSONを圧縮して、テーブルのMEDIUMBLOB列に格納します。
  4. 新しい列を追加するための労力ゼロ（またはオプションの列があるか、列を廃止するなど）

特徴：

  • 効率的なストレージ（圧縮されたblobは個別の列よりもはるかに小さい）
  • ALTER TABLE ADD COLUMNは必要ありません。
  • 検索機能（これらの列は除外しておいてください。）

プランB：MariaDB 5.3以降とその動的列： http://kb.askmonty.org/en/dynamic-columns

1
Rick James