MySQLは数十億行のクエリを合理的に実行できますか？
質量分析計からのスキャンをMySQLデータベースに保存することを計画しており、この量のデータの保存と分析がリモートで実行可能かどうかを知りたいです。パフォーマンスは環境によって大きく異なることを知っていますが、大まかな順序を探しています。クエリには5日または5ミリ秒かかりますか？
入力フォーマット
各入力ファイルには、分光器の単一の実行が含まれています。各実行は一連のスキャンで構成され、各スキャンにはデータポイントの順序付けられた配列があります。メタデータは少しありますが、ファイルの大部分は32ビットまたは64ビットのintまたはfloatの配列で構成されています。
ホストシステム
| ---------------- + --------------------------- - | OS | Windows 2008 64ビット| | MySQLバージョン| 5.5.24（x86_64）| | CPU | 2x Xeon E5420（合計8コア）| | RAM | 8GB | | SSDファイルシステム| 500 GiB | | HDD RAID | 12 TiB | | ---------------- + ------------------------------- |
わずかなプロセッサー時間を使用してサーバー上で実行されている他のいくつかのサービスがあります。
ファイル統計
| ------------------ + -------------- | |ファイル数| 〜16,000 | |合計サイズ| 1.3 TiB | |最小サイズ| 0バイト| |最大サイズ| 12 GiB | |平均| 800 MiB | |中央値| 500 MiB | |合計データポイント|〜2,000億| | ------------------ + -------------- |
データポイントの総数は、非常に大まかな見積もりです。
提案されたスキーマ
私は「正しい」ことを行うことを計画しています（つまり、クレイジーなようにデータを正規化します）。そのため、runsテーブル、spectraへの外部キーを含むrunsテーブルを作成します、そしてdatapointsへの外部キーを持つspectraテーブル。
2,000億データポイントの質問
複数のスペクトルと、場合によっては複数の実行を分析して、数百万の行に影響するクエリを作成します。すべてを適切にインデックス付けし（別の質問のトピックです）、ネットワーク全体で数百ものMiBをシャッフルしようとしていないとすると、MySQLがこれを処理することはリモートでもっともらしくなりますか？
追加情報
スキャンデータは、XMLベースの---（mzML 形式のファイルから取得されます。この形式の要点は、データが格納される<binaryDataArrayList>要素にあります。各スキャンは、2以上の<binaryDataArray>要素を生成します。これらの要素を組み合わせて、[[123.456, 234.567, ...], ...]という形式の2次元（またはそれ以上）の配列を形成します。
これらのデータは1回限りなので、更新のパフォーマンスとトランザクションの安全性は問題になりません。
データベーススキーマの単純な計画は次のとおりです。
runsテーブル
|列名|タイプ| | ------------- + ------------- | | id |プライマリキー| | start_time |タイムスタンプ| |名前| VARCHAR | | ------------- + ------------- |
spectraテーブル
|列名|タイプ| | ---------------- + ------------- | | id |プライマリキー| |名前| VARCHAR | |インデックス| INT | | spectrum_type | INT | |表現| INT | | run_id |外部キー| | ---------------- + ------------- |
datapointsテーブル
|列名|タイプ| | ------------- + ------------- | | id |プライマリキー| | spectrum_id |外部キー| | mz |ダブル| | num_counts |ダブル| |インデックス| INT | | ------------- + ------------- |
これは妥当ですか？
だから、あなたが推測できたかもしれないが、私はプログラマーであり、研究室の生物学者ではないので、実際の科学者だけでなく科学についてもほとんど知らない。
これは、私が扱うデータの種類の単一スペクトル（スキャン）のプロットです。
ソフトウェアの目標は、ピークがどこにどれほど重要であるかを理解することです。独自のソフトウェアパッケージを使用してこれを把握していますが、独自の分析プログラム（R）を作成して、シートの下で何が起こっているのかを把握します。ご覧のとおり、データの大部分は興味をそそるものではありませんが、アルゴリズムで失われた潜在的に有用なデータを破棄したくありません。満足できる可能性のあるピークのリストを取得すると、残りのパイプラインは、データポイントの生のリストではなく、そのピークリストを使用します。生のデータポイントを大きなblobとして保存するだけで十分だと思います。必要に応じて再分析できますが、ピークのみを個別のデータベースエントリとして保持します。その場合、スペクトルごとに数十のピークしかないので、クレイジーなスケーリングの問題はそれほど問題になりません。
私はあなたのニーズにあまり精通していませんが、おそらくデータベースに各データポイントを保存することは少々やり過ぎです。リレーショナルデータベースに各ピクセルを個別のレコードとして保存することで、画像ライブラリを保存するアプローチに似ています。
原則として、バイナリデータをデータベースに保存することは、ほとんどの場合間違っています。通常、問題を解決するより良い方法があります。リレーショナルデータベースにバイナリデータを格納することは本質的に間違っているわけではありませんが、多くの場合、デメリットが利益を上回ります。リレーショナルデータベースは、その名のとおり、リレーショナルデータの保存に最適です。バイナリデータはリレーショナルではありません。データベースにサイズを（多くの場合は大幅に）追加し、パフォーマンスを低下させる可能性があり、数十億レコードのMySQLインスタンスの維持に関する疑問につながる可能性があります。良いニュースは、バイナリデータの保存に特に適したデータベースがあることです。それらの1つは、常にすぐにわかるわけではありませんが、ファイルシステムです。バイナリファイルのディレクトリとファイルの命名構造を考え出し、クエリによって値を生成する可能性のある他のデータと一緒にMySQL DBに保存します。
別のアプローチは、データポイント（およびおそらくスペクトル）データにドキュメントベースのストレージシステムを使用し、実行にMySQLを使用する（または実行を他と同じDBに入れる）ことです。
私はかつて非常に大きな（Terabyte +）MySQLデータベースを扱っていました。私たちが持っていた最大のテーブルは文字通り10億行を超えていました。これはMySQL 5.0を使用していたため、状況が改善された可能性があります。
動いた。 MySQLはほとんどの場合、データを正しく処理しました。しかし、それは非常に扱いにくいものでした。 （テラバイトのデータで6シグマレベルの可用性が必要な場合は、MySQLを使用しないでください。私たちは、DBAがなく資金が限られたスタートアップでした。）
データをバックアップして保存するだけでも困難でした。必要に応じてテーブルを復元するには数日かかります。
1000万から1億行の範囲に多数のテーブルがありました。テーブルへの重要な結合は時間がかかりすぎ、永遠にかかります。そのため、テーブルを「ウォーク」し、「ID」の範囲に対して結合を処理するストアドプロシージャを作成しました。このようにして、一度に10〜100,000行のデータを処理します（IDが1〜100,000、次に100,001〜200,000などと結合します）。これは、テーブル全体に対して結合するよりも大幅に高速でした。
主キーに基づいていない非常に大きなテーブルでインデックスを使用することも、はるかに困難です。 Mysql 5.0は、インデックスを2つの部分に分けて格納します-インデックス（プライマリインデックス以外）をプライマリキー値へのインデックスとして格納します。したがって、インデックス付きルックアップは2つの部分で行われます。最初のMySQLはインデックスに移動し、そこから検索する必要のあるプライマリキー値をプルします。次に、プライマリキーインデックスで2番目のルックアップを実行して、それらの値の場所を見つけます。
これの正味は、非常に大きなテーブル（1〜2億行以上）の場合、テーブルに対するインデックス作成がより制限されることです。必要なインデックスは少なくて簡単です。また、直接インデックスにない単純なselectステートメントを実行しても、戻ってこない場合があります。 Where句mustはインデックスにヒットするか、それを忘れます。
しかし、言われていることはすべて、物事は実際に機能しました。これらの非常に大きなテーブルでMySQLを使用して計算を行い、正しい答えを得ることができました。
2,000億行のデータを分析しようとすると、非常にハイエンドのハードウェアと多くの手持ちと忍耐が必要になります。復元できる形式でデータをバックアップしておくだけでも、大変な作業になります。
私は srini.venigallaの答え に同意しますcrazyのようにデータを正規化することはここでは良い考えではないかもしれません。大量のデータを含む複数のテーブル間で結合を行うと、ファイルソートのリスクにさらされます。これは、一部のクエリが決して戻らないことを意味します。単純な整数キーで非正規化すると、成功する可能性が高くなります。
私たちが持っていたものはすべてInnoDBでした。 MyISAMとInnoDBについて：主なことは、2つを混合しないことです。 MySQLがキーやその他のデータをキャッシュする方法のため、実際には両方に対してサーバーを最適化することはできません。可能であれば、サーバーのすべてのテーブルに対してどちらか一方を選択してください。 MyISAMはいくつかの速度の問題には役立ちますが、実行する必要があるDBAの全体的な作業には役立ちません。
狂ったようにデータを正規化する
この場合、crazyのようなデータの正規化は適切な戦略ではない可能性があります。正規化された形式とアプリケーションに非常に適したマテリアライズドビューの形式の両方でデータを保存することにより、オプションを開いたままにします。このタイプのアプリケーションのキーは、アドホッククエリを作成することではありません。クエリモデリングは、データモデリングよりも重要です。ターゲットクエリから始めて、最適なデータモデルに向けて取り組みます。
Is this reasonable?
すべてのデータを含む追加のフラットテーブルも作成します。
run_id | spectrum_id | data_id | <data table columns..> |
このテーブルをすべてのクエリのプライマリソースとして使用します。その理由は、結合を行う必要がないようにするためです。インデックスなしの結合はシステムを非常に使用不可能にし、そのような巨大なファイルにインデックスを付けることは同様にひどいものになります。
戦略は、最初に上記のテーブルでクエリを実行し、結果を一時テーブルにダンプし、一時テーブルをRunおよびSpectrumのルックアップテーブルと結合して、必要なデータを取得します。
書き込みニーズと読み取りニーズを分析しましたか？ SQLを捨てて非標準のデータストレージメカニズムに移行するのは非常に魅力的です。私の見解では、それは最後の手段であるべきです。
書き込み速度を加速するには、ハンドラーソケットメソッドを試してください。 Perconaは、覚えていると思いますが、Handler Socketをインストールパッケージにパッケージ化しています。 （ペルコナとは関係ありません！）
http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html
行の数が正確なスキーマを増やすにつれて、選択したイエス、つまり、選択したデータ型と操作の重要性が高まります。
データをどれだけ正規化するかは、格納されたデータに対して実行する予定の操作によって異なります。あなたの「データポイント」テーブルは特に問題があるようです-特定のスペクトルのn番目のポイントを他のm番目のポイントと比較することを計画していますか？そうでない場合、それらを別々に保管することは間違いである可能性があります。データポイントが独立しておらず、関連するスペクトルのコンテキストでのみ意味がある場合は、PRIMARY KEYは必要ありません-スペクトルへの外部キーと「n番目」の列（「インデックス」列？）で十分です。 。
実行する必要があるスペクトル間およびスペクトル内の操作を定義し、それらを実行する最も安価な方法を見つけます。同等性が必要なすべてである場合、それらは非正規化される可能性があります-おそらく、あなたの操作を支援するいくつかの事前計算された統計メタデータで。個々のデータポイントへのSQL内アクセスが絶対に必要な場合は、各行のサイズを最小限のフィールド数と可能な限り最小のデータ型に減らすようにしてください。
私がこれまで個人的に管理した中で最大のMySQLは、約1億行でした。このサイズで、 行を維持し、フィールドを固定サイズにします。これにより、MySQLは、テーブル内の任意の行の位置を効率的に計算できます 各行（ポインター演算と考えてください）-正確な詳細は、使用する予定のストレージエンジンによって異なります。 MyISAMを使いこなせるかどうか、速度の点で信頼性に欠けているもの、そして状況によってはそれで十分な場合に使用してください。 VARCHARなどの可変サイズのフィールドをCHAR（n）に置き換え、読み取りクエリでRTRIM（）を使用します。
テーブルの行が固定幅になると、MySQLの integer datatypes （一部は非標準）を慎重に評価することにより、バイト数を減らすことができます。 4バイトのINTを3バイトのMEDIUMINTに変換することで、1バイト節約するごとに、100万行あたり最大1MB節約できます。つまり、ディスクI/Oが減り、キャッシュがより効果的になります。 を使用して回避できる最小のデータ型を使用します。浮動小数点型を慎重に評価し、8バイトのDOUBLEを4バイトのFLOATまたは<8バイト 固定小数点NUMERIC で置き換えることができるかどうかを確認します。テストを実行して、選択したものが後であなたを噛まないことを確認します。
データセットの予想されるプロパティと必要な操作に応じて、値のより珍しいエンコード（値のセットへのインデックスとしてエンコードできる予想されるパターン/繰り返し）にさらに節約がある可能性があります。メタデータや破棄など）-エキゾチックで直感的ではない破壊的な最適化は、他のすべてのオプションが試された場合にのみ価値があります。
最も重要なことは、最終的に何をしようとも、完璧なスキーマを選択したと想定せず、何千万ものレコードを盲目的にダンプし始めることです。優れたデザインは進化するのに時間がかかります。大規模であるが管理可能な（たとえば1〜5％）テストデータセットを作成し、スキーマの正確さとパフォーマンスを確認します。さまざまな操作がどのように実行されるかを確認し（http://dev.mysql.com/doc/refman/5.0/en/using-explain.html）、スキーマのバランスを取り、最も頻繁な操作を優先するようにしてください。
短く言った？おっと。とにかく頑張ってね！
データポイントデータを（実行の時間とタイプなどのメタデータとは対照的に）XMLからデータベースフォームに細断する唯一の理由は、アレイ全体のスペクトルを分析しているときです。特定の署名で実行されます。現在、問題のドメインを知っているのはあなただけですが、これは、96kHzでサンプリングされた音楽を1行1サンプルで保存するのと同じようなものです。データがどのように使用されるかよりもサイズが問題かどうかはわかりません。データ全体のクエリは、ビートルズのすべての曲の曲に2分間の相対振幅を尋ねることと同じです。実行される可能性のある分析の種類を知っている場合、信号に対してこれらを実行し、実行に関するメタデータにそれらを保存することは、より意味がある可能性があります。
また、ソースデータがスパースかどうかもわかりません。元のXMLにはゼロエントリが含まれているのに、データベースのスペクトルにはゼロ以外のエントリしか含まれていない可能性があるため、行の総数はソースデータよりもはるかに少ない可能性があります。
したがって、多くの質問と同様に、MySQLがモデルを処理することについて尋ねる前に、モデルに戻り、モデルとその使用方法を確認することは、おそらくまだパフォーマンスを心配するよりも適切です。
質問の更新を確認した後、バイナリデータがBLOBまたはファイルへのポインターとして保存されているモデルで十分だと思います。モデルを変更して、データが最初に識別されたときに特定された重要なピークに関するデータを保存します読んだ。
私は約50のデータベースサーバーでWeb分析サービスを実行し、各サーバーには1億行を超える多くのテーブルと、10億行を超える傾向があるいくつかのサーバー（時には各サーバー）が含まれています。
ここのパフォーマンスは素晴らしいです。非常に正規化されたデータです。ただし、これを読むことに関する私の主な懸念は、これらのテーブルの42億行をはるかに超えていることです（「実行」されない可能性がありますが、おそらく他の2つです）。つまり、INTではなくBIGINTを使用する必要があります。主キー/外部キー。
インデックス付きカラムのBIGINTフィールドを使用したMySQLのパフォーマンスは、INTと比較して途方もなく恐ろしいです。このサイズを超える可能性があると考えたテーブルを使用してこれを1回実行するのは間違いでした。数億行に達すると、パフォーマンスはひどいものになりました。生の数字はありませんが、私が悪いと言うとき、私はWindows MEが悪いことを意味します。
この列が主キーでした。我々はそれをただのINTとプレスト・マジコに変換し直し、パフォーマンスは再び良好でした。
当時のすべてのサーバーは、Debian 5とMySQL 5.0を搭載していました。それ以来、Debian 6とPercona MySQL 5.5にアップグレードしたため、状況は改善されている可能性があります。しかし、ここでの私の経験に基づいて、いいえ、それはあまりうまく機能するとは思いません。
機能してもしなくても、単一のモノリシックストレージメディアでは常に同じ問題が発生します。ディスクが遅いのです。 100 MB /秒（メディアの回転にはかなり良い）で、1 TBのテーブルをread読み取るだけで3時間かかります。これは、分析やシークなどの遅延が発生しないことを前提としています。
これが、ほとんどすべての「ビッグデータ」インストールが何らかの分散データストアを使用する理由です。 DBを実行するために1つの超すばらしいコンピューターを構築するのに8倍のお金を費やすことができますが、並行してスキャンできる大量のデータがある場合、ほとんどの場合、8台の安価なコンピューターに負荷を分散する方がベターです。
hadoop のようなプロジェクトは、特にこのような目的のためにビルドされました。大量の安価なコンピュータのクラスタを構築し、すべてのコンピュータにデータを分散し、それらを並行してクエリします。これはすべて同じアイデアを基に構築された6ダースのソリューションの1つにすぎませんが、非常に人気のあるソリューションです。
うーん...私があなたがこの種のデータ構造を選択する理由は2つあると思います：
- データポイントクエリとデータポイントクエリを実際に行う必要がある
- すべてのロジックをSQLで実行する予定である
さて、私はあなたの要件を長く精査して、上記の仮定の少なくとも1つが真であることを確認することをお勧めします。どちらも真でない場合は、物事を遅くしているだけです。この種のデータセットについては、最初にデータへのアクセス方法、必要な精度などを確認し、それらを中心にデータベースを設計することをお勧めします。
PS：データポイントごとに少なくとも36 + 5バイトが必要になるので、200Bデータポイントでは少なくとも8.2 TB必要なスペースを提供する必要があります。
PPS：idテーブルのdatapoints列は必要ありません。PRIMARY KEY (spectrum_id, index)で十分です（indexは予約語である可能性があることに注意してください） ）
編集：
単一のディスクに保存されたデータを使用してこれをMYSQLで実行しないでください。単一のメディアからその量のデータを読み取るだけでは数時間かかります。拡大ではなく拡大する必要があります。
また、効果的なデータ分析を行うには、データを非正規化する必要があります。ここではオンラインシステムを設計していません。数値を処理したい場合は、それに応じて設計してください。
行の下の元の答え。
答えはクエリによって異なりますが、MySQLはこのジョブに最適なツールではない可能性があります。 「拡大」ではなく「拡大」できるソリューションを確認することをお勧めします。何らかの努力を惜しまない場合は、HadoopなどのMap Reduceソリューションを検討する必要があります。
さらにアドホッククエリを実行する場合は、 GoogleのBigQuery ソリューションが適しています。 Google I/O 2012からの関連プレゼンテーション： BigQueryによるビッグデータの処理
したがって、解決策は、これが1回限りのものであり、アドホッククエリを合理的にサポートするかどうかによって異なります。
誰も言及していないので、私の提案です。 大規模に分割されたMySQLソリューションを見てください。たとえば、この高く評価されている tumblr presentation を参照してください。
コンセプトは：
- 1つの特別な大規模データベースではなく
- 元のデータの一部を保持する小さなものをたくさん使用する
したがって、垂直方向のパフォーマンスを向上させる代わりに、水平方向にスケーリングできます。 Googleの BigTable と [〜＃〜] gfs [〜＃〜] は、ペタバイト単位のデータの保存とクエリに、安価な水平方向にスケーラブルなノードを使用しています。
ただし、異なるシャードに対してクエリを実行する必要がある場合は問題が発生します。
誰かが興味を持っていれば、少し前にhello-world shardingアプリケーションを作成しました。 here についてはブログの投稿で説明しています。 RavenDBとC＃を使用しましたが、詳細は無関係であり、考え方は同じです。
データはどのようなマシンに保存されますか？共有ストレージデバイスですか？
クエリ時間を決定する最終的な要因は、ハードドライブです。データベースとそのクエリオプティマイザーは、ディスクI/Oの数をできるだけ減らすように設計されています。テーブルが3つしかない場合、これはかなり確実に行われます。
ハードドライブの読み取り/書き込み速度は、メモリ速度よりも200〜300倍遅くなります。 レイテンシが非常に速く、読み取りと書き込みの速度が速いハードドライブを探します。このすべてのデータが1つの2 TBドライブにある場合、クエリが完了するまで長い間待機することになります。ハードドライブのレイテンシは約10〜15ミリ秒で、メモリのレイテンシは10ナノ秒未満です。ハードドライブの待ち時間は、メモリの待ち時間よりも1000〜2000倍遅くなる可能性があります。ハードドライブ上のメカニカルアームの移動は、このシステム全体で最も遅いものです。
どのくらいRAMありますか？16 GB？32のレコードを保持できるとしましょう。16,000のファイルがあります。すべてのデータポイントを線形スキャンする場合、簡単にシーク時間だけで5〜10秒。次に、転送速度50mb/sを考慮に入れますか？約7時間さらに、一時的に保存されたデータは、新しいデータを読み取るためのスペースを確保するためにハードディスクに保存する必要があります。
他のユーザーによってアクティブに使用されている共有ストレージデバイスを使用している場合...最善の策は、すべてを夜に実行することです。
ネストされたクエリの数を減らすことも役立ちます。ネストされたクエリの結果、一時テーブルが作成され、ハードドライブがさらにクラッシュします。ハードドライブに十分な空き容量があることを願っています。
クエリの最適化では、一度に1つのクエリしか確認できません。そのため、ネストされたselectステートメントは最適化できません。ただし、特定のネストされたクエリによって小さなデータセットが返されることがわかっている場合は、それを保持してください。クエリの最適化では、ヒストグラムと大まかな仮定を使用します。データとクエリについて何か知っている場合は、次に進んでください。
データがディスクに保存される方法について理解を深めるほど、クエリをより速く書き込むことができます。すべてが主キーに順番に格納されている場合は、ネストされたクエリから返された主キーを並べ替えると便利な場合があります。また、事前に分析する必要があるデータセットのセットを減らすことができる場合は、それを行います。システムによっては、ファイルごとに約1秒のデータ転送が見られます。
名前の値（varchars）を変更する場合は、最大サイズのデータ型に変更します。これにより、断片化が防止され、トレードオフはメモリの数バイトだけになります。多分最大100のNVARCHARです。
テーブルの非正規化に関するコメントに関する限り。データポイントをより大きなグループ（おそらくスペクトルとして）に保存し、pythonまたはデータベースと対話する言語で）データ分析を行うのが最善だと思います。SQL-ウィザード。
私にとっては、「リレーショナル列ストア」 ここで説明 のようなものが必要な使用シナリオのように思えます。
設計を誤解しているかもしれませんが、主に配列の大きなコレクションを扱っている場合、それらを典型的な行指向のテーブルに格納することは、各要素がスライスに似ていることを意味します。一般的な方法でスライスを確認することに興味がある場合は、それは理にかなっていますが、一度に列全体を実際に確認する場合は、効率が低下する可能性があります。
配列を取得する場合、正規化の結果として別のテーブルと結合する必要がないだけでなく、シリーズをハッシュではなく配列として取得できます。
私は本当に問題を誤解しているかもしれません、そして私は特定の解決策を提案することすらありません。
これは別の話です たとえそれが実際には現在のソリューションでも展開可能なソリューションでもない場合でも、それは関連があるかもしれません。
テーブルを分割してみることをお勧めします。 1つのテーブル（株式市場データ）に80ミルを超える行があり、問題なくすばやくアクセスできます。
データの検索方法に応じて、パーティションを設計する必要があります。私たちの場合、特定の日付を照会するため、日付順はうまく機能します。
http://dev.mysql.com/doc/refman/5.1/en/partitioning-limitations.html
http://www.slideshare.net/datacharmer/mysql-partitions-tutorial
はい、しかし...
20億行あるテーブルで作業しました。ただし、PKを使用したクエリのみが高速であることが期待されていました。
最も重要なのは、ハードウェアにテーブル全体をメモリに収めるのに十分なRAM=でした。それが問題になったとき（そのときは最大で96GB）、垂直パーティション分割になり、それぞれに設定されたテーブルのサイズを維持しました。マシンはメモリに収まるほど十分に小さいマシンであり、また、マシンは10Gbファイバーで接続されているため、ネットワークスループットはそれほど問題ではありませんでした。
ところで。スキーマは、SQLのハッシュキーとしてrun_idを使用し、データポイントのハッシュキーとしてspectrum_idを使用して、NoSQLソリューションに適合するようなものに見えます。
私は私のブログでこのトピックについて書きました： http://www.tocker.ca/2013/10/24/improving-the-performance-of-large-tables-in-MySQL.html =
重要なポイントのいくつかを繰り返すには：
- Bツリーは大きくなり、メモリに収まらないと劣化します（MySQLだけではありません）。
- InnoDBには、一定のパフォーマンスを維持するのに役立ついくつかの機能があります（バッファリングの変更。以前は「挿入バッファー」と呼ばれていました）。
- パーティショニングも役立ちます。
私の投稿のコメントで、Tim Callaghanはこれにリンクしています： http://www.tokutek.com/resources/benchmark-results/benchmarks-vs-innodb-hdds/#iiBench
これは、iibenchベンチマークを使用して10億行を挿入する方法を示しています。