テーブルのパーティション分割はどのように役立ちますか？
テーブルパーティション分割の長所と短所を理解するのが困難です。 8つのテーブルがあるプロジェクトで作業を開始します。そのうちの1つは、1億8億-2億6000万のレコードを保持するメインデータテーブルになります。適切にインデックスが付けられたテーブルになるので、テーブルレコードをこのように2,000万に制限することを考えています。9〜13個のテーブルを作成する必要があります。
しかし、同じマシン（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の目的では、パーティショニングによって運用クエリのパフォーマンスが大幅に向上する可能性は低いですが、システム管理には役立ちます。大量のデータにわたって集計を報告するという重要な要件がある場合は、適切なパーティションスキームが役立ちます。
すべてのインデックスがパーティション化されている場合、パーティション化により、パーティションごとの同時reorgが可能になります。そうでない場合でも、パーティションはずっと小さく、再編成に使用するワークスペースが少なくなります。また、内部的には、「良い」DBMSはパーティションテーブルと並行して処理を実行できます。 MySQLやMyISAMは含まれていません。