MySQLのスケーラブルなデータモデル

Question

：

• 二つの主要なオブジェクト：コレクションとリソース。
• 各ユーザーには複数のコレクションがあります。私はユーザー情報を保存しているわけではありません。すべてのコレクションには「ユーザーID」フィールドがあります。
• 各コレクションには複数のリソースが含まれています。
• 与えられたコレクションは1人のユーザーにのみ属します。
• 任意のリソースが複数のコレクションに関連付けられている可能性があります。

当面はMySQLを使用することを約束しますが、別のデータベースに移行する可能性があります。私の主な関心事は、以下の前提条件によるスケーラビリティです。

• ユーザー数は約200人になります。
• 平均して、各ユーザーには5つのコレクションがあります。
• 約30,000の新しい明確なリソースは、毎日の「消費」されています。リソースが消費されたときに、アプリケーションを関連付け、そのリソースに関連するすべてのコレクションにそのリソース。典型的には、リソースはコレクションの約半分に関連していると仮定すると、1日に30,000 x（1,000/2）= 15,000,000の挿入が行われます。
• コレクションオブジェクトとリソースオブジェクトは、どちらも約半ダースのフィールドで構成され、その一部は100文字の長さに達することがあります。
• すべてのユーザーは定期的にポーリングを設定してコレクションと関連リソースを定期的に取得します。これは1分に1回発生するものとします。

私はMySQLを使用していますのでご注意ください。期待されるデータ量を考えると、データモデルはどのように正規化されるべきですか？このデータをフラットなテーブルに格納することは理にかなっていますか？どのようなシャーディングアプローチが適切でしょうか？ MySQLのNDBクラスタリングソリューションは、このユースケースに適していますか？

Answer 1

期待されるデータ量を考えれば、データモデルはどのように正規化されるべきですか？

完璧に。

ボリュームは小さいです。毎日10,000〜355,000件の取引をしていますか？ピーク使用量が12時間のウィンドウであると仮定しましょう。それは8/secまでの.23/secです。 30 /秒（12時間の期間に100万行以上）のような料金になるまでは、ほとんど気にする必要はありません。

このデータをフラットなテーブルに格納することは意味がありますか？

号

適切なシャーディングのアプローチはどんなでしょうか？

問題ではありません。あなたを幸せにするものを選んでください。

これらは経験的にテストする必要があります。現実的な量の偽のデータを構築する。いくつかのベンチマーク取引を書く。負荷の下で実行してベンチマーキングの代替候補を探します。

MySQLのNDBクラスタリングソリューションはこのケースに適していますか？

それは疑わしいです。多くの場合、この負荷を処理するのに十分な大きさの単一サーバーを作成できます。

これは、問題の要件のいずれかのようには聞こえません。

MySQL Clusterはシングルポイント障害を起こさないように設計されています。 シェアードナッシングシステムでは、各コンポーネントに固有の メモリとディスクがあり、 ネットワーク共有、ネットワークファイルシステム、SANなどの共有ストレージメカニズムの使用は推奨されず、 がサポートされています。