データベースのシャーディングとパーティショニングのリソース

Question

スケーラビリティの問題に直面しているデータベーススキーマを使用しています。スキーマ内のテーブルの1つが約1,000万行に成長しました。このスキーマをより大きなデータセット（たとえば、10億から1,000億行）に拡張できるようにするシャーディングおよびパーティションオプションを調査しています。アプリケーションは、Oracle、MS SQL Server、MySQLを含むがこれらに限定されないいくつかのデータベース製品にもデプロイ可能でなければなりません。

これは一般に大きな問題であり、どのオプションが利用可能かを調べたいと思います。データベースのシャーディングとパーティショニング戦略のためのリソース（書籍、ホワイトペーパー、Webサイト）はありますか？

Answer 1

シャーディングに頼る前にスキーマとインデックスを調べる必要があるという他の回答に同意します。 1,000万行は、主要なデータベースエンジンの機能の範囲内です。

ただし、シャーディングの主題について学習するためのリソースが必要な場合は、これらを試してください：

• スケーラビリティのベストプラクティス：eBayからの教訓
• eBayの建築原則に関するランディショープ-ビデオとプレゼンテーション
• 高スケーラビリティサイト
• ミスタームーアはシャーディングでパントする（それをしないとき）

Answer 2

現在のサイズは問題ではないというMike Woodhouseの見解に同意します。質問者は同意します。

ほとんどの商用DBMSは、1つの名前または他のいくつかの名前で、一部または複数の断片化されたテーブルのサポートを提供します。重要な質問の1つは、データをフラグメントに分割する賢明な方法があるかどうかです。一般的な方法の1つは、日付に基づいて行うことです。たとえば、2008年11月のすべての値は1つのフラグメントに、2008年10月の値は別のフラグメントに、というように続きます。これには、古いデータを削除するときにメリットがあります。他のフラグメントに影響を与えることなく、おそらく2001年10月（7年間のデータ保持）からのデータを含むフラグメントをドロップできます。この種の断片化は、「断片化の解消」にも役立ちます。クエリが明らかに特定のフラグメントからデータを読み取る必要がない場合、それは未読のままになるため、パフォーマンスが大幅に向上します。 （たとえば、クエリが2008年10月の日付に対するものであることをオプティマイザーが知っている場合、2008年10月のデータを含むフラグメントを除くすべてのフラグメントを無視します。）

他の断片化手法もあります-ラウンドロビンは負荷を複数のディスクに分散しますが、断片の除去によるメリットは得られません。

Answer 3

1,000万行はDBMSの観点からはそれほど大きくないため、シャードまたはパーティションを使用してデータの物理的な分散を計画する前に、インデックス作成とクエリの計画を最初に検討します。数桁成長しました。

もちろん、すべての私見。

Answer 4

私の経験では、大きなテーブルは常にI / O側でヒットします。最も安価なソリューションは、すべてのクエリがメインデータページをロードせずにインデックスから直接データを取得できるように、十分なマルチカラムインデックスを追加することです。これにより、挿入と更新のI / Oが集中しますが、これで問題ない場合があります。 次の簡単なオプションは、サーバーのRAMを最大にします。データベースが大きい場合、32GB未満の理由はありません。 しかし、最終的にはまだI / Oに縛られていることに気付くでしょう。ハードドライブを大量に購入し、ハードウェアと労力の間で大金がかかる複雑なパーティションスキームを維持しようとしています。最近、より良い代替手段があることを願っています-回転するハードドライブからSLCソリッドステートドライブにデータベースを移動するボトルネック。 SSDは1ギガバイトあたり10ドルで始まるため、数ドルを費やすことになりますが、それでもSANなどよりはるかに安価です。