データベースサイズがパフォーマンスに与える影響：理論と現実

データベースのサイズはパフォーマンスに大きな影響を与えてはならないということはたくさんあります。テーブルのインデックスがメモリに収まる限り、データベースのパフォーマンスは維持されます。

しかし、現実は何ですか？データベースアーキテクチャが最適でない場合、インデックスがメモリに収まらず、冗長データが大量に存在する可能性があります。冗長データを削除するだけで大​​幅なメリットが得られますか？データベース内のデータの60〜80％が削除される可能性があると推定しています。

データベースのサイズを減らし、RAMを増やしてインデックスがメモリに収まるようにすると、パフォーマンスが大幅に向上し、システムを再設計するための数か月の余裕ができると思います。

データベースのサイズに基づいてパフォーマンスに影響を与えるIO、断片化、作業データセットなどの他の要因もありませんか？

それはあなたがデータで何をしているかに完全に依存します。

数行のみに影響する基本的な挿入/更新/削除トランザクションの場合、データサイズの増加はおそらく大きな考慮事項ではありません。データベースはインメモリインデックスを使用して正しいページにアクセスします。テーブルがメモリに収まらなくなると、キャッシュミスが増えます。ただし、データベース、データベース構成、およびハードウェア構成によっては、オーバーヘッドがわずかになる場合があります。

フルテーブルスキャンを必要とするクエリを実行している場合、パフォーマンスはデータサイズとともに直線的または悪化します。インデックスは、ページアクセスをランダム化することで実際に状況を悪化させる可能性があり、キャッシュミスをほぼ保証します。

メモリを増やす代わりに、ディスク速度が向上します。ソリッドステートディスクを使用すると、大幅な改善が可能です。

テーブルがクエリで使用されていない限り、データが増えるだけでパフォーマンスに影響が出る可能性は低くなります。データはテーブル内またはテーブル間で冗長ですか？決して使用されない大きなテーブルがあると面倒ですが、パフォーマンスへの影響は最小限です。無数の不要なテーブルがある場合、クエリのコンパイルに時間がかかるようになると考えられます。

ナンバー1のチューニングルールAMM（Add More Memory）は単純なものです。また、非常にコストがかかり、最終的に選択性に問題がある場合には効果的ではありません。データベースがメモリに完全に収まる場合でも、アプリケーションのパフォーマンスが低下する可能性があります。非常にa選択的なSQL実行中にロックとラッチが発生するため、最悪のシナリオ。最初に修正する必要があります。1つの理由は、すべてのSQLがテーブル内のすべてのデータに毎回アクセスする場合、中断とヒット-保持-のような同時実行性です。

SQLが必要以上の行にアクセスしないようにしてください。これは、パフォーマンスを良好に保つための最も効果的な方法です。通常のデータベースはioの処理方法を知っており、最も使用されているデータを何らかの形でキャッシュします。

アプリケーションで可能なすべてのアクセスがすでに最小化されており、最速のディスクシステムをすでに使用している場合は、実際のフラッシュメモリアレイの使用を検討してください。彼らはパフォーマンスを他のレベルに上げることができます。

これらの投稿を参照してください：

• MySQLデータベースは、パフォーマンスが低下し始める前にどれくらいの大きさになることができますか
• 大きなテーブルでMySQLが遅くなるのはなぜですか？

データをできるだけ小さくするためのヒント：

ディスク上のスペースを最小限に抑えるようにテーブルを設計します。これにより、ディスクに読み書きされるデータの量が減り、大幅な改善が可能になります。小さいテーブルは通常、クエリの実行中にその内容がアクティブに処理されている間、必要なメインメモリが少なくなります。また、テーブルデータのスペースを削減すると、インデックスが小さくなり、より高速に処理できます。

MySQLは、さまざまなストレージエンジン（テーブルタイプ）と行フォーマットをサポートしています。各テーブルについて、使用するストレージとインデックスの作成方法を決定できます。アプリケーションに適したテーブル形式を選択すると、パフォーマンスが大幅に向上する場合があります。

ここにリストされている手法を使用すると、テーブルのパフォーマンスが向上し、ストレージ領域を最小限に抑えることができます。-可能な限り最も効率的な（最小の）データ型を使用します。MySQLには、ディスク領域とメモリを節約する多くの特殊なタイプがあります。たとえば、可能な場合は小さい整数型を使用して、小さいテーブルを取得します。MEDIUMINT列は25％少ないスペースを使用するため、多くの場合、MEDIUMINTはINTよりも適切な選択です。

• 可能であれば、列をNOT NULLとして宣言します。それはすべてをより速くし、列ごとに1ビット節約します。アプリケーションで本当にNULLが必要な場合は、必ずそれを使用する必要があります。デフォルトでは、すべての列で使用しないでください。

• MyISAMテーブルの場合、可変長列（VARCHAR、TEXT、またはBLOB列）がない場合は、固定サイズの行形式が使用されます。

• InnoDBテーブルはコンパクトストレージフォーマットを使用します。MySQL 5.0.3より前のバージョンでは、InnoDB行には、固定サイズの列であっても、列の数や各列の長さなどの冗長な情報が含まれています。デフォルトでは、テーブルはコンパクト形式（ROW_FORMAT = COMPACT）で作成されます。コンパクト行形式の存在により、一部の操作でのCPU使用率の増加を犠牲にして、行ストレージ領域が約20％減少します。ワークロードが、キャッシュヒット率とディスク速度によって制限される典型的なものである場合、より高速になる可能性があります。CPU速度によって制限されるまれなケースである場合は、遅くなる可能性があります。

コンパクトなInnoDB形式は、UTF-8データを含むCHAR列の格納方法も変更します。ROW_FORMAT = REDUNDANTを使用すると、UTF-8エンコードされた文字の最大長が3バイトである場合、UTF-8 CHAR（N）は3×Nバイトを占有します。多くの言語は主にシングルバイトのUTF-8文字を使用して記述できるため、固定長のストレージは多くの場合スペースを浪費します。ROW_FORMAT = COMPACT形式では、InnoDBは、必要に応じて末尾のスペースを削除することにより、これらの列にN〜3×Nバイトの範囲の可変量のストレージを割り当てます。通常の場合のインプレース更新を容易にするために、最小ストレージ長はNバイトとして保持されます。

• テーブルのプライマリインデックスはできるだけ短くする必要があります。これにより、各行の識別が簡単かつ効率的になります

• 本当に必要なインデックスのみを作成してください。インデックスは取得には適していますが、データをすばやく格納する必要がある場合には適していません。主に列の組み合わせを検索してテーブルにアクセスする場合は、それらの列にインデックスを作成します。インデックスの最初の部分は、最もよく使用される列である必要があります。テーブルから選択するときに常に多くの列を使用する場合、インデックスの最初の列は、インデックスの圧縮率を高めるために重複が最も多い列にする必要があります。

• 状況によっては、非常に頻繁にスキャンされるテーブルを2つに分割すると便利な場合があります。これは、動的形式のテーブルであり、テーブルをスキャンするときに関連する行を見つけるために使用できる小さい静的形式のテーブルを使用できる場合に特に当てはまります。