スケーラビリティの問題が発生しているデータベース スキーマを使用しています。スキーマ内のテーブルの 1 つが約 1,000 万行に増えました。私は、このスキーマをより大きなデータセット (たとえば、10 億行から 1,000 億行) にスケーリングできるように、シャーディングとパーティション分割のオプションを検討しています。私たちのアプリケーションは、Oracle、MS SQL Server、MySQL を含むがこれらに限定されないいくつかのデータベース製品にも展開できる必要があります。
これは一般的に大きな問題であり、利用可能なオプションについて調べたいと思います。データベースのシャーディングとパーティショニングの戦略について、どのようなリソース (書籍、ホワイトペーパー、Web サイト) がありますか?
シャーディングに頼る前に、スキーマとインデックスを確認する必要があるという他の回答に同意します。1,000 万行は、主要なデータベース エンジンの機能の範囲内です。
ただし、シャーディングの主題について学習するためのリソースが必要な場合は、次を試してください。
私は、現在のサイズは問題にならないという Mike Woodhouse の意見に同意します。質問者も同意します。
商用 DBMS のほとんどは、1 つまたは複数の名前で、断片化されたテーブルのサポートを提供しています。重要な問題の 1 つは、データをフラグメントに分割する賢明な方法があるかどうかです。一般的な方法の 1 つは、日付に基づいてこれを行うことです。たとえば、2008 年 11 月の値はすべて 1 つのフラグメントに入れられ、2008 年 10 月の値は別のフラグメントに入れられます。これには、古いデータを削除するときに利点があります。おそらく、2001 年 10 月 (7 年間のデータ保持) からのデータを含むフラグメントを、他のフラグメントに影響を与えることなく削除できます。この種の断片化は、「断片の除去」にも役立ちます。クエリが特定のフラグメントからデータを読み取る必要がないことが明らかな場合、それは読み取られないままになり、パフォーマンスが大幅に向上します。（例えば、
他にもフラグメンテーション手法があります。ラウンド ロビンでは負荷が複数のディスクに分散されますが、フラグメントの除去によるメリットは得られません。
私の経験では、大きなテーブルは常に I/O 側に影響を与えます。最も安価な解決策は、メイン データ ページをロードすることなく、すべてのクエリがインデックスから直接データを取得できるように、十分な数の複数列インデックスを追加することです。これにより、挿入と更新の I/O 負荷が高くなりますが、これで問題ない場合があります。次の簡単なオプションは、サーバーの RAM を最大化することです。データベースが大きい場合、32GB 未満にする理由はありません。しかし、最終的にはまだ I/O バウンドであり、大量のハード ドライブを購入し、複雑なパーティショニング スキームを維持する必要があり、ハードウェアと人件費に多額の費用がかかります。最近、より良い代替手段があることを願っています - データベースを回転するハード ドライブから SLC ソリッド ステート ドライブに移行します - これにより、ランダムな読み取りと書き込みが最上位の SAS ドライブよりも 100 倍速くなるはずです。I/O のボトルネックを取り除きます。SSD は 1 ギガバイトあたり 10 ドルからなので、数千ドルを費やす必要がありますが、それでも SAN などよりもはるかに安価です。
1,000 万行は DBMS 用語では実際には大きくありません。シャードまたはパーティションを使用したデータの物理的な分散の計画を開始する前に、最初にインデックス作成とクエリ プランを検討します。数桁。
もちろん、すべて私見です。