テーブルのパーティション分割はどのように役立ちますか？

テーブルパーティションの長所と短所の概念をつかむのが困難です。8つのテーブルを持つプロジェクトの作業を開始しようとしていますが、そのうちの1つは1億8千万から2億6千万件のレコードを保持するメインデータテーブルになります。適切にインデックスが付けられたテーブルになるので、9〜13個のテーブルを作成する必要があるこの方法で、テーブルレコードを2,000万に制限することを考えています。

しかし、同じマシン（32GB RAM）に座っているため、パフォーマンスがどのように改善されるかについてはよくわかりません。

私はMySQLを使用しており、テーブルはMyISAMであり、大きなテーブルにはidフィールドにインデックスがあり、フルテキスト検索などの複雑さはありません。

また、テーブルのパーティション分割とデータベースのパーティション分割についても明らかにしてください。

以下は、非常識な暴言と絶賛です...

すべてのデータを1つのテーブルに残す（パーティション化しない）場合、キーを使用してO（log n）検索時間が発生します。世界で最悪のインデックスである二分木を見てみましょう。各ツリーノードにはキーが1つだけあります。268,435,455（2 ^ 28-1）のツリーノードを持つ完全にバランスの取れたバイナリツリーの高さは28です。このバイナリツリーを16の別々のツリーに分割すると、16,777,215（2 ^ 24-1）の16のバイナリツリーが得られます。高さ24のツリーノード。検索パスは4ノード削減され、高さは14.2857％減少します。検索時間がマイクロ秒単位である場合、検索時間の14.2857％の短縮はゼロから無視できます。

現実の世界では、BTREEインデックスには複数のキーを持つツリーノードがあります。各BTREE検索は、ページ内でバイナリ検索を実行し、別のページにまともな場合があります。たとえば、各BTREEページに1024個のキーが含まれている場合、ツリーの高さ3または4が標準で、実際にはツリーの高さが短くなります。

テーブルのパーティショニングは、すでに小さいBTREEの高さを減少させないことに注意してください。260ミリオン行のパーティションを考えると、同じ高さの複数のBTREEがある可能性すらあります。キーを検索すると、毎回すべてのルートBTREEページを通過する場合があります。必要な検索範囲のパスを満た​​すのは1つだけです。

次にこれを展開します。すべてのパーティションは同じマシンに存在します。パーティションごとに個別のディスクがない場合、パーティション検索パフォーマンス以外の自動ボトルネックとしてディスクI / Oとスピンドル回転が発生します。

この場合、idのみが有効化される検索キーである場合でも、データベースによる分割では何も購入されません。

データのパーティション分割は、同じクラスに論理的かつまとまりのあるデータをグループ化するのに役立ちます。データが正しくグループ化されている限り、各パーティションを検索するパフォーマンスを主に考慮する必要はありません。論理パーティションを作成したら、検索時間に集中してください。IDのみでデータを分離している場合、読み取りまたは書き込みのために多くのデータ行にアクセスできない可能性があります。今、それは主要な考慮事項であるはずです：最も頻繁にアクセスされるすべてのIDを見つけ、それによってパーティション分割します。アクセス頻度の低いすべてのIDは、「ブルームーンに1回」クエリのインデックスルックアップによってアクセス可能な1つの大きなアーカイブテーブルに存在する必要があります。

全体的な影響は、少なくとも2つのパーティションを持つことです。1つは頻繁にアクセスされるID用で、もう1つは残りのID用です。頻繁にアクセスされるIDがかなり大きい場合、オプションでそれを分割できます。

確かに、2億行は、テーブルパーティション化の恩恵を受けることができる範囲にあります。アプリケーションに応じて、以下にリストされている利点のいくつかを賭けることができます。

• 古いデータの消去のしやすさ（たとえば）6か月以上前のレコードを消去する必要がある場合は、その日にテーブルをパーティション分割してから、古いパーティションをスワップアウトできます。これは、テーブルからデータを削除するよりもはるかに高速で、多くの場合、稼働中のシステムで実行できます。OPの場合、これはシステムのメンテナンスに役立つ場合があります。

• 複数のディスクボリュームパーティショニングにより、データを分割して、ディスクトラフィックを複数のディスクボリュームに分散して速度を向上させることができます。最新のRAIDコントローラーでは、これはOPの問題にはなりそうにありません。

• テーブルと範囲のスキャンの高速化実際、運用システムはこのようなことを行うべきではありませんが、データウェアハウスまたは同様のシステムはこの種のクエリを大量に行います。テーブルスキャンは主にシーケンシャルディスクトラフィックを使用するため、通常はテーブル内の行の数パーセント以上を返すクエリを処理する最も効率的な方法です。
  
  共通のフィルター（通常は時間または期間ベース）によるパーティション化により、パーティション化キーに対して述部を解決できる場合、そのようなクエリからテーブルの大きな部分を削除できます。また、テーブルを複数のボリュームに分割できるため、大きなデータセットのパフォーマンスが大幅に向上します。通常、これは運用システムの問題ではありません。

OPの目的上、パーティショニングは運用クエリのパフォーマンスを大幅に向上させる可能性は低いですが、システム管理には役立つ場合があります。大量のデータにわたって集計をレポートする必要がある場合は、適切なパーティションスキームが役立ちます。

すべての索引がパーティション化されている場合、パーティション化により、パーティションごとの同時再編成が可能になります。そうでない場合、パーティションはまだはるかに小さく、再編成に使用するワークスペースが少なくなります。また、内部的には、「良い」DBMSはパーティションテーブルと並行して処理を実行できます。おそらく、MySQLやMyISAMは含まれていません。