単一のデータベースサーバー上の複数のデータベースにわたるユーザーデータの共有

Question

私は独学のプログラマーであり、スケールするシステムの構築に関しては、研究より常識に基づいた特定の設計パラメーターに常に従ってきました。しかし、私のシステムの1つのコンポーネントが必要でないかもしれないことに気がつきました。

一般的に言えば、ユーザーデータをグループに分けて、特定のmysqlサーバーに割り当てます。ロード・バランサの背後にあるコンテンツ・サーバーがリクエストを受け取ると、リクエストのデータ（ユーザーIDなど）を使用して、DynamoDBに格納されたセントラル・テーブルを問い合せることによって、そのユーザー・データが格納されるデータベースを解決します。

ただし、サーバー内のデータベースにもユーザーデータを割り当てます。同様に、すべてのテーブル構造が同じで、各データベースに250人のユーザーを割り当てます。

ロジックはもともと、各ユーザーが2k個のエントリを持つテーブルは、50万個以上の500kエントリで高速に実行されるというロジックでした。しかし、このようにユーザーデータを分割することはまったく意味がないかもしれません。 インデックスはかなり効率的です。データベースには、実際には基本的に同じ速度でデータにアクセスするための内部ロジックがありますか？私はこれを10年間続けてきましたが、これはまったく必要ではないかもしれないことが分かりました。何かご意見は？ 1つのデータベースをすべてのテーブルにまとめることはできますか？それとも、サーバー上の100個のデータベースに分散して、いつものやり方でやり続ける必要がありますか？

Answer 1

これは少し理論的なので、Big-O complexityという名前の時間複雑度の概念を理解する価値があるかもしれません。

単一項目のクラスタ化Bツリー索引ルックアップはO（log（n））です（nは表内の行数）。 DynamoDBはハッシュベースの実装であり、O（1）に非常に近くなります。つまり、コンテンツのサイズによってパフォーマンスが大きく変化することはありません。

ここでlog（500k）= 5.7です。ここでlog（50mil）= 7.7単列検索は、ディスクへのヒットを避けてメモリにインデックスをロードしている限り、

したがって、1行の検索では25％の違いがあります。これは重要ですが、別のdbシステム（DynamoDBなど）への往復のオーバーヘッドよりも低い可能性があります。

もちろん、あなたの走行距離は、インデックスをメモリに保存するなどの懸念があるため、変更される可能性があります。したがって、実稼働環境に違いが生じる可能性があります。テストを設定し、パフォーマンスを確認することを強くお勧めします。