超高速データベースで10億行をスキャン

バックグラウンド

ローカルデータベースには、約13億の一意の行が含まれています。各行は、特定の緯度と経度（場所）に間接的に関連付けられています。各行には日付スタンプがあります。

使用事例

問題は次のとおりです。

1. ユーザーは、開始/終了日と値の範囲（たとえば、100から105）を設定します。
2. システムは、特定の日付に一致するすべての行を、場所ごとにグループ化して収集します。
3. システムは、これらの日付の間に、指定された値の範囲に該当する可能性がある場所を決定します。
4. システムは、一致するすべての場所をユーザーに表示します。

これは速度と規模の問題です。

質問

そのようなシステムが5秒未満でユーザーの結果を取得できると想像できる最も安価なソリューションアーキテクチャは何ですか。

現在のシステム

現在の環境は次のとおりです。

• PostgreSQL 8.4（アップグレードは可能です。データベースの切り替えはオプションではありません）
• RおよびPL / R
• XFS
• WD VelociRaptor
• 8 GB RAM（Corsair G.Skill; 1.3 GHz）
• クアッドコア本物のインテル7（2.8 GHz）
• Ubuntu 10.10

ハードウェアのアップグレードは許容されます。

更新-データベース構造

数十億行が次のようなテーブルにあります。

id | taken | location_id | category | value1 | value2 | value3

• id-主キー
• 取られた-行に割り当てられた日付
• location_id-緯度/経度への参照
• カテゴリ-データの説明
• value1 .. 3-ユーザーがクエリできるその他の値

takenカラムは、典型的にはあたり連続日付でlocation_id時々各位置1800から2010年までのデータを有し、（各位置は、同じ日付範囲のデータを有するよう77,000約日付が、それらの多くが重複）。

7つのカテゴリがあり、テーブルはすでにカテゴリ別に分割されています（子テーブルを使用）。各カテゴリには、1億9000万行が含まれます。近い将来、カテゴリごとの行数は10億を超えるでしょう。

約20,000の場所と70,000の都市があります。場所は、緯度と経度によって都市に関連付けられています。各場所を特定の都市に割り当てることは、都市の境界を見つけることを意味しますが、これは簡単な作業ではありません。

アイデア

私が持っているいくつかのアイデア：

• データベースをホストするクラウドサービスを見つけます。
• SSD RAIDストライプを作成します（素晴らしいビデオ）。
• 都市ごとにすべての場所を統合するテーブルを作成します（事前計算）。

ありがとうございました！

最も重要なことは、データベースを切り替えることができないため、ボトルネックが特定の数の代表的なリクエストに今どこにあるのかを確実に特定することです。

全表スキャンを行う場合は、適切なインデックスが必要です。

I / Oで待機する場合は、キャッシュ用により多くのメモリが必要です（Jeff Atwoodは最近、24 Gbシステムはデスクトップシステムで到達可能であると述べました）。

CPUで待機する場合は、計算を最適化できるかどうかを確認する必要があります。

これには、先​​のとがったDBAハットとオペレーティングシステムハットが必要ですが、適切なツリーを確実に起動するためには価値があります。

日付スタンプに基づいて、テーブルを異なるホストにある複数の部分に分割してみませんか？これは水平方向にスケーラブルであり、十分な数のボックスがある限り、これらのセットアップの上に小さな集約エンジンを書くことができます。

日付スタンプの変化が大きすぎる場合は、場所に基づいてパーティション分割できます。これも水平方向にスケーラブルです。（うまくいけば、彼らは緯度/経度の多くを追加しないでください！）

最悪のシナリオは、日付範囲がデータベース内のすべての日付をカバーすることです。

13億件のレコードを読み取り、5秒未満で、1台の物理マシン上で、各レコードと入力された値に対して何らかの分析を行っているとします。結果は、すべての場所である場合も、まったくない場合もあります。事前に何もわかっていません。

これらのパラメータを考えると、おそらく不可能だと思います。

ハードドライブを見てください。最大持続レートは150MB / s未満です。13億件のレコードを読み取るには5秒以上かかります。CPUに関しては、5秒間で13億件のレコードを統計的に分析することはできません。

あなたの唯一の望み（tm :-)）は、ユーザーが入力した値に基づいて、検索を（数桁）絞り込む絞り込み関数を見つけることです。このルックアップ関数はオフラインで計算できます。正確な一致基準について詳しく知らなければ、誰もそれを行う方法を教えられるとは思いませんが、例としては、値の範囲をいくつかの個別の間隔に分割し、その間隔のすべてのレコードを提供するルックアップを作成することです。間隔が十分に短い限り、実際の作業を行うことができます。たとえば、ユーザーが入力した値と一致しないエントリを削除します。基本的に時間とスペースを交換します。

メモリ内のすべてのレコード（または少なくとも重要な部分）を保持することが可能な場合があります。おそらく8GBではありません。これにより、少なくともディスクI / O部分がなくなりますが、メモリ帯域幅でさえ、5秒ですべてをスキャンするには不十分な場合があります。とにかく、これはこの種のアプリケーションを高速化するためのもう1つの手法です（以前の提案と組み合わせる）。

クラウドサービスの使用について言及します。はい、十分なCPUとIOの筋肉にお金を払い、多くのサーバー間でデータベースを分割すると、総当たり/分割して征服することができます。

質問に対するrwongのコメントの2番目：PostgreSQLは、適切なインデックスタイプとツール（GISTインデックス、GINインデックス、Postgis、Geometricalタイプ）を提供しており、ジオデータと日時関連データは、それほど問題なくこれらの基準に沿って検索できるはずです。

これらの基準でのクエリに数秒かかる場合は、そのようなインデックスが使用されていないことを意味します。これらを適切に調査したことを確認できますか？

PostgreSQLと緯度/経度データを使用する場合は、必ずPostGISも使用する必要があります。これにより、GiST空間インデックスをデータベースに追加して、高速化を図ることができます。

私はそのようなテーブル（350k行）を持っていますが、あなたの設定（2コアとかろうじて2Gb RAM）よりもはるかに小さい構成ですが、検索にかかる時間は1秒未満です。

EssbaseがOLAPアーキテクチャで行ったようなリレーショナルモデルを破ることができるかもしれません： Essbaseウィキペディア

つまり、都市ごとに1つのテーブルを作成し、最終的に1000以上のテーブルを作成します。あなたが提案したような1つのテーブルではなく、多く。日付と場所で各テーブルにインデックスを付けます。多くのテーブル、多くのインデックス->より高速。

データベースをホストするクラウドサービスを見つけるというアイデアに関して、SimpleGeoに出会ったことはありますか？10億を超える行の保存とクエリにかかるコストにより、このアプローチは実行不可能になる可能性がありますが、明らかに「場所データの保存とクエリを実際に非常に高速に行うように特に調整されている」ストレージサービスのリボンを切りました。

あなたは自転車が高速道路を走ることを期待しています。現在、この問題に取り組むためのソリューションを探していますが、20億件のレコードがある場合、問題を予測できません。スケーラビリティに対処する必要があります。答えはオブジェクトデータベースの簡単な使用です。例：システム間キャッシュ

そして、私がシステム間出身ではないことを信じてください;-)