MySQLデータベースに質量分析計からのスキャンを保存することを計画していますが、この量のデータの保存と分析がリモートで実行可能かどうかを知りたいです。パフォーマンスは環境によって大きく異なることがわかっていますが、大まかな順序を探しています：クエリには5日または5ミリ秒かかりますか？

入力形式

各入力ファイルには、分光器の単一の実行が含まれています。各実行は一連のスキャンで構成され、各スキャンには順序付けられたデータポイントの配列があります。少しのメタデータがありますが、ファイルの大部分は32ビットまたは64ビットのintまたはfloatの配列で構成されています。

ホストシステム

| ---------------- + ------------------------------- |
| OS | Windows 2008 64ビット|
| MySQLバージョン| 5.5.24（x86_64）|
| CPU | Xeon E5420 x 2（合計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外部キーto runsを持つdatapointsテーブル、および外部キーto を持つテーブルを持つことになりspectraます。

2,000億のデータポイントの質問

複数のスペクトル、場合によっては複数の実行にわたって分析し、数百万行に及ぶクエリを作成します。すべてを適切にインデックス付けし（別の質問のトピック）、ネットワーク全体で数百のMiBをシャッフルしようとしていないと仮定すると、MySQLがこれを処理することはリモートでもっともらしいですか？

追加情報

スキャンデータは、XMLベースのmzML形式のファイルから 取得されます。この形式の中核は <binaryDataArrayList>、データが保存される要素にあります。各スキャンは2つ以上の<binaryDataArray>要素を生成し、これらを合わせて、フォームの2次元（またはそれ以上）の配列を形成し[[123.456, 234.567, ...], ...]ます。

これらのデータは追記型なので、更新パフォーマンスとトランザクションの安全性は問題になりません。

データベーススキーマの私の素朴な計画は次のとおりです。

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として保存すれば十分だと思うので、必要に応じて再分析できますが、ピークのみを個別のデータベースエントリとして保持します。その場合、スペクトルごとに数ダースのピークしかないので、クレイジーなスケーリングはすべきではありません。

私はあなたのニーズにあまり精通していませんが、おそらく各データポイントをデータベースに保存するのは少しやり過ぎです。各ピクセルをリレーショナルデータベースに個別のレコードとして保存することで、画像ライブラリを保存するアプローチを取っているように思えます。

一般的なルールとして、ほとんどの場合、データベースにバイナリデータを保存するのは間違っています。通常、問題を解決するより良い方法があります。バイナリデータをリレーショナルデータベースに格納することは本質的に間違っているわけではありませんが、多くの場合、欠点は利点よりも重要です。リレーショナルデータベースは、その名前が示すように、リレーショナルデータの保存に最適です。バイナリデータはリレーショナルではありません。データベースに（多くの場合大幅に）サイズが追加され、パフォーマンスが低下する可能性があり、10億レコードのMySQLインスタンスの維持に関する質問につながる場合があります。良いニュースは、バイナリデータの保存に特に適したデータベースがあることです。そのうちの1つは、必ずしもすぐにはわかりませんが、ファイルシステムです！バイナリファイルのディレクトリとファイルの命名構造を考え出すだけで、

別のアプローチは、データポイント（およびおそらくスペクトル）データにドキュメントベースのストレージシステムを使用し、実行にMySQLを使用する（または実行を他と同じDBに配置する）ことです。

私はかつて非常に大きな（Terabyte +）MySQLデータベースを扱っていました。私たちが持っていた最大のテーブルは、文字通り10億行以上でした。これはMySQL 5.0を使用していたため、状況が改善された可能性があります。

動いた。MySQLはほとんどの場合、データを正しく処理しました。しかし、それは非常に扱いにくいものでした。（テラバイトのデータで6シグマレベルの可用性が必要な場合は、MySQLを使用しないでください。私たちはDBAがなく、資金が限られた新興企業でした。）

データをバックアップして保存するだけでは困難でした。必要に応じてテーブルを復元するには数日かかります。

10〜1億行の範囲で多数のテーブルがありました。テーブルへの重要な結合は時間がかかりすぎ、永遠にかかります。そこで、テーブルを「ウォーク」し、「id」の範囲に対して結合を処理するストアドプロシージャを作成しました。このようにして、データを一度に10〜100,000行処理します（idの1〜100,000、次に100,001〜200,000などに結合します）。これは、テーブル全体に対して結合するよりも大幅に高速でした。

主キーに基づいていない非常に大きなテーブルでインデックスを使用することも非常に困難です。Mysql 5.0はインデックスを2つの部分に分けて保存します-インデックス（プライマリインデックス以外）をプライマリキー値のインデックスとして保存します。そのため、インデックス付きルックアップは2つの部分で行われます。最初にMySQLがインデックスに移動し、検索する必要があるプライマリキー値を取得し、次にプライマリキーインデックスで2回目の検索を実行してそれらの値の場所を検索します。

これの正味は、非常に大きなテーブル（1億から2億行以上）に対して、テーブルに対するインデックス作成がより制限されることです。必要なインデックスは少なく、シンプルです。また、インデックス上に直接ない単純な選択ステートメントを実行しても、戻ることはありません。Where句はインデックスにヒットするか、インデックスを忘れる必要があります。

しかし、言われたことはすべて、物事は実際に機能しました。これらの非常に大きなテーブルでMySQLを使用し、計算を行い、正しい答えを得ることができました。

2000億行のデータを分析しようとすると、非常にハイエンドのハードウェアと多くの手持ちと忍耐が必要になります。復元可能な形式でデータをバックアップしておくだけでも、大きな仕事になります。

私は同意するsrini.venigallaの答え狂ったようにデータを正規化すると、ここには良いアイデアではないかもしれません。大量のデータを使用して複数のテーブル間で結合を行うと、ファイルの並べ替えのリスクにさらされることになり、一部のクエリが返されなくなる可能性があります。単純な整数キーで非正規化すると、成功の可能性が高くなります。

私たちが持っていたものはすべてInnoDBでした。MyISAMとInnoDBについて：主なことは、2つを混在させないことです。MySQLがキーとその他のデータをキャッシュする方法のため、両方に対してサーバーを実際に最適化することはできません。可能であれば、サーバー内のすべてのテーブルのいずれかを選択します。MyISAMは速度の問題には役立つかもしれませんが、実行する必要のあるDBA作業全体には役に立たない可能性があります。

狂ったようにデータを正規化する

この場合、クレイジーなデータの正規化は適切な戦略ではないかもしれません。正規化形式とアプリケーションに非常に適したマテリアライズドビューの両方の形式でデータを保存することにより、オプションを開いたままにします。このタイプのアプリケーションで重要なのは、アドホッククエリを記述しないことです。クエリモデリングは、データモデリングよりも重要です。ターゲットクエリから始めて、最適なデータモデルを目指します。

Is this reasonable?

また、すべてのデータを含む追加のフラットテーブルを作成します。

run_id | spectrum_id | data_id | <data table columns..> |

このテーブルをすべてのクエリの主要なソースとして使用します。その理由は、結合を行う必要がないようにするためです。インデックスを作成せずに結合すると、システムが非常に使用できなくなり、そのような巨大なファイルにインデックスを作成することも同様にひどくなります。

戦略は、最初に上記のテーブルでクエリを実行し、結果を一時テーブルにダンプし、一時テーブルをRunおよびSpectrumのルックアップテーブルと結合し、必要なデータを取得します。

書き込みニーズと読み取りニーズを分析しましたか？SQLを捨て、非標準のデータストレージメカニズムに移行するのは非常に魅力的です。私の見解では、それは最後の手段であるべきです。

書き込み速度を上げるには、Handler Socketメソッドを試してください。覚えているなら、PerconaはインストールパッケージにHandler Socketをパッケージ化しています。（Perconaとは関係ありません！）

http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html

簡単な答えは「はい」です。行の数が増えると、選択する正確なスキーマ、データ型、および操作の重要性が増します。

データをどの程度正規化するかは、保存されたデータに対して実行する操作によって異なります。あなたの「データポイント」テーブルは特に問題があるようです-特定のスペクトルのn番目のポイントを他のスペクトルのm番目と比較することを計画していますか？そうでなければ、それらを別々に保存するのは間違いかもしれません。データポイントがスタンドアロンではなく、関連するスペクトルのコンテキストでのみ意味をなす場合、プライマリキーは必要ありません-スペクトルの外部キーと 'nth'列（ 'index'列）で十分です。 。

実行する必要があるスペクトル間およびスペクトル内の操作を定義し、それらを実行する最も安価な方法を見つけます。平等が必要な場合は、非正規化される可能性があります-おそらく事前に計算された統計メタデータを使用して、操作を支援します。個々のデータポイントへのSQL内アクセスが絶対に必要な場合は、各行のサイズを最小限のフィールド数と可能な限り最小のデータ型に減らすようにしてください。

私が個人的に管理した中で最大のMySQLは1億行まででした。このサイズでは、行を保持するため、フィールドを固定サイズにします-これにより、MySQLは各行の固定サイズを乗算することでテーブル内の任意の行の位置を効率的に計算できます（ポインター演算を考慮）-正確な詳細は、使用する予定のストレージエンジンによって異なります。MyISAMを使用できます。信頼性が不足しているため速度を補うことができ、状況によっては十分です。VARCHARなどの可変サイズフィールドをCHAR（n）で置き換え、読み取りクエリでRTRIM（）を使用します。

テーブルの行が固定幅になったら、MySQLの整数データ型（一部は非標準）を慎重に評価することで、バイト数を減らすことができます。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（実行時間や実行タイプなどのメタデータとは対照的に）からデータベース形式に細断処理す​​る唯一の理由は、配列全体のスペクトルを分析するときです。特定の署名で実行されます。あなたの問題領域を今すぐ知っているのはあなただけですが、これは行ごとに1サンプルで96kHzでサンプリングされた音楽を保存することに似ているかもしれません。サイズがデータの使用方法以上の問題であるかどうかはわかりません。データ全体を照会することは、ビートルズがすべての曲を対象に、その曲に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 /秒（メディアの回転に適しています）では、読むだけで3時間かかります、1 TBのテーブルます。それは、分析やシークなどの遅延がないことを前提としています。

これが、ほぼすべての「ビッグデータ」インストールが何らかの分散データストアを使用する理由です。DBを実行するために1枚の非常に素晴らしいコンピューターを構築するのに8倍のお金を費やすことができますが、並行してスキャンできるデータが大量にある場合は、ほとんどの場合、8台の安価なコンピューターに負荷を分散する方が良いでしょう。

hadoopなどのプロジェクトは、このような目的のために特別に構築されました。多数の安価なコンピューターのクラスターを構築し、それらすべてにデータを分散し、それらを並列にクエリします。これは、この同じ考えに基づいて構築された半ダースのソリューションの1つにすぎませんが、非常に人気のあるものです。

うーん...私はあなたがこの種のデータ構造を選ぶだろう2つの理由を見ます：

• あなたは本当にデータポイント対データポイントクエリを行う必要があります
• SQLですべてのロジックを実行する予定

ここで、要件を詳細に検討し、上記の前提の少なくとも1つが当てはまることを確認することをお勧めします。どちらも当てはまらない場合は、物事を遅くしているだけです。この種のデータセットの場合、まずデータへのアクセス方法、必要な精度などを確認してから、それらに基づいてデータベースを設計することをお勧めします。

PS：データポイントごとに少なくとも36 + 5バイトが必要になることに注意してください。200Bのデータポイントでは、少なくとも8.2 TBのスペースが必要です。

PPS：テーブルのid列は必要ありません。おそらく十分です（予約語であることに注意してください）datapointsPRIMARY KEY (spectrum_id, index)index

編集：

単一ディスクにデータが保存されているMYSQLではこれを行わないでください。1つのメディアからその量のデータを読み取るだけでも数時間かかります。アップではなく、スケールアウトする必要があります。

また、効果的なデータ分析を行うには、データを非正規化する必要があります。ここではオンラインシステムを設計していません。数字を計算したいので、それに応じて設計します。

行の下の元の答え。

答えはクエリによって異なります。MySQLはこの仕事に最適なツールではないかもしれません。「アップ」ではなく「アウト」にスケールできるソリューションをご覧ください。何らかの努力をしたい場合は、HadoopなどのMap Reduceソリューションを検討してください。

さらにアドホッククエリを実行する場合は、GoogleのBigQueryソリューションが最適です。Google I / O 2012からの関連プレゼンテーション：BigQueryを使用したビッグデータの処理

したがって、ソリューションは、これが単発のものであるかどうか、およびアドホッククエリを合理的にサポートするかどうかに依存します。

誰も言及していないので、私の提案。大量に断片化されたMySQLソリューションをご覧ください。たとえば、この高く評価されているtumblrプレゼンテーションを参照してください。

コンセプトは：

• 1つの特大データベースの代わりに
• 元のデータの一部を保持している多くの小さなものを使用する

したがって、垂直方向のパフォーマンスを向上させる代わりに、水平方向にスケーリングできます。GoogleのBigTableとGFSは、安価で水平方向にスケーラブルなノードを使用して、ペタバイト単位のデータを保存およびクエリします。

ただし、異なるシャードに対してクエリを実行する必要がある場合は問題が発生します。

データはどのようなマシンに保存されますか？共有ストレージデバイスですか？

クエリ時間を決定する究極の要因は、ハードドライブになります。データベースとそのクエリオプティマイザーは、ディスクI / Oの数をできるだけ減らすように設計されています。テーブルが3つしかない場合、これはかなり確実に行われます。

ハードドライブの読み取り/書き込み速度は、メモリ速度の200〜300倍遅くなります。非常に速いレイテンシーと速い読み書き速度を備えたハードドライブを探してください。このすべてのデータが1つの2 TBドライブ上にある場合、クエリが完了するまで長い時間待機することになります。ハードドライブのレイテンシは10〜15ミリ秒で、メモリのレイテンシは10ナノ秒未満です。ハードドライブのレイテンシは、メモリのレイテンシよりも1000〜2000倍遅くなります。ハードドライブ上の機械式アームの動きは、このシステム全体で最も遅いものです。

RAMはどれくらいありますか？16ギガバイト？それで、32個のレコードを保持できるとしましょう。16000個のファイルがあります。すべてのデータポイントをリニアスキャンする場合、シーク時間だけで5〜10秒になります。次に、転送速度を50mb / sに考慮しますか？約7時間。さらに、一時的に保存されたデータは、新しいデータを読み込むためのスペースを確保するために、ハードディレクトリに保存する必要があります。

他のユーザーが積極的に使用している共有ストレージデバイスを使用している場合...最善の策は、すべてを夜間に実行することです。

ネストされたクエリの数を減らすことも役立ちます。ネストされたクエリにより、一時テーブルが作成され、ハードドライブがさらにスラッシングされます。ハードドライブに十分な空き容量があることを願っています。

クエリの最適化では、一度に1つのクエリしか見ることができません。したがって、ネストされた選択ステートメントは最適化できません。ただし、特定のネストされたクエリによって小さなデータセットが返されることがわかっている場合は、それを保持してください。クエリの最適化では、ヒストグラムと大まかな仮定を使用します。データとクエリについて何か知っている場合は、先に進んでください。

データがディスクに保存される方法を理解すればするほど、クエリをより速く書くことができます。すべてが主キーに連続して格納されている場合、ネストされたクエリから返された主キーを並べ替えることが有益な場合があります。また、事前に分析する必要があるデータセットのセットを削減できる場合は、それを実行します。システムによっては、ファイルごとに約1秒のデータ転送が見られます。

Name値（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ファイバーを介して接続されていたため、ネットワークスループットはそれほど大きな問題ではありませんでした。

ところで。スキーマはrun_id、スペクトルのspectrum_idハッシュキーおよびデータポイントのハッシュキーとして使用して、NoSQLソリューションに適合する何かのように見えます 。

このトピックについてブログに書いています：http : //www.tocker.ca/2013/10/24/improving-the-performance-of-large-tables-in-MySQL.html

キーポイントのいくつかを繰り返すには：

• Bツリーは大きくなり、メモリに収まらないために劣化します（MySQLはここだけではありません）。
• InnoDBには、パフォーマンスの維持に役立つ機能がいくつかあります（バッファリングの変更。以前は「バッファの挿入」と呼ばれていました）。
• パーティション分割も役立ちます。

これにリンクされた私の記事のティム・キャラハンのコメント： http //www.tokutek.com/resources/benchmark-results/benchmarks-vs-innodb-hdds/#iiBench

これは、iibenchベンチマークを使用して10億行を挿入することを示しています。