次のどれがスケーリングとパフォーマンスに優れているかを理解するのを手伝ってください。
Table: test
columns: id <int, primary key>, doc <int>, keyword <string>
保存したいデータは、特定のキーワードを含むドキュメントへのポインタです
デザイン 1:
have unique constraint on the keyword column and store the list of documents as an array
e.g id: 1, doc: [4,5,6], keyword: google
デザイン 2:
insert a row for each document
1 4 google
2 5 google
3 6 google
特定のキーワードが見つかるドキュメントの平均数が 100000 に近いとしましょう。キーワードが表示されるドキュメントの最大数は存在しない可能性があります。
設計 1 は、MySQL の行サイズ制限によって制限される可能性があります。
私にはデザイン 2 が最も理にかなっています。これらの値の 1 つを削除する必要がある場合はどうすればよいでしょうか。配列を検索して更新するのではなく、行を削除するだけです。また、必要に応じて結果のサイズを制限できるので (ページネーションなど)、便利です。
ここにキーワードをフィールドとして格納する代わりに、このテーブルとキーワードテーブルの間に多対多の関係を作成することも検討してください。
mysql には配列データ型がないため、オプション 1 は忘れて構いません。
正直なところ、このタイプのデータに対してスケーラブルなソリューションが必要な場合は、別のタイプのデータベースを検討する必要があると思います。NoSQL と「キーと値のペア ストア データベース」について詳しく調べてください。
mysql では、私が考えることができる最善の方法は、数値 ID と一意のキーワードのリストを持つ別のテーブルを作成する必要があることを除いて、2 番目のオプションです。そうすれば、検索を行うときに、最初に ID を検索し、次に大きなテーブルを文字列ではなく ID でフィルター処理します。数値比較は、文字列比較よりも高速です。
多くの要因がスケーリングとパフォーマンスに影響するため、開発の早い段階で未知のものを最適化しようとするのは通常は良い考えではありません。
データベースの設計については、より正確な正規化されたアプローチ (設計 2) を使用し、問題が発生した場合はスケーリングとパフォーマンスについて心配するのが通常最善であることがわかりました。次に、直面している問題に応じて、特定の領域を非正規化するか、他のアプローチを取ることができます。
設計オプション 1 では、doc 列を別のテーブルと結合できず、更新や検索も複雑になるため、他の問題がすぐに発生する可能性があります。