500M +アイテムのクエリを処理する方法

私のデータの構造は次のとおりです：

date: <timestamp>
filter_a: <integer> -> range [0, 1000]
filter_b: <integer> -> range [0, 1000]
filter_c: <integer> -> range [0, 86400]
filter_d: <integer> -> range [0, 6]
group: <string>
second_group: <integer>
variable_a: <float>
variable_b: <float>
variable_c: <float>
a couple more no very important

次のクエリを実行する必要があります。

最初：

• フィルターデータによってdate、filter_a、filter_b、filter_c、その他

次に、フィルタリングされたデータを使用します。

• すべてのレコードを数える
• 取得平均のvariable_a、variable_bおよびvariable_c
• 取得標準偏差のをvariable_a、variable_bそしてvariable_c
• 取得四分位 のをvariable_a、variable_bそしてvariable_c
• groupor second_groupおよびaggregate（Count、Avg、Std、..）によってデータをグループ化する

システムの利用者の数は約10または15であるが、項目数は今それが、巨大である70Mが、それはなります500M数週間で、それが可能になる1000Mについての年に。

クエリの数は少なく、同時ユーザー数は10人以下です。私の問題は、この大量のデータでこれらのクエリを処理する方法です。

これまでに何を試しましたか？

• 私mongodbはから始めましたが、最初は高速でしたが、10M +で四分位数を計算すると遅くなりました。インデックスを追加すると改善しましたが、すべてのデータをクエリする必要がある場合はあまり役に立ちませんでした。mongodbを使い始めたのは、データが非常に動的だったためですが、幸いにもデータ形式は「もう変更されない」ためです。

• ノードのように見えるのでfilter_a、filter_b試してみましたneo4j。私はそれをneo4jがとても好きでしたが、私のグラフはエッジがたくさんあるので、クエリはあまり速くありませんでした。

• 最後に、データ形式は変更されず、コレクション/テーブルは1つだけなので、SQLで結合する必要がないため、postgresqlを確認しました。私のテストはpostgresqlの方が高速でしたが、将来的に適切にスケーリングできなくなるのではないかと心配しています。

私が必要なものは何？

• この場合、postgresqlは適切な選択肢ですか？
• 使用できる別の種類のデータベースはありますか？この場合、どちらが最適ですか？
• それを改善するために他に何ができますか？

編集する

• 約1Mの要素が毎日挿入され、時間に沿って「変更してはいけません」。
• 書き込み速度は重要ではありません
• ハード要件は、読み取り/集約を高速化することです

ありがとう！

リレーショナルデータベースを使用して時系列データに対してこれらの統計計算を実行する代わりに、この数学および後処理作業をデータベースの外部のクライアントアプリケーションに移動することをお勧めします。

PythonやRubyなどのスクリプト言語を使用して、固定幅の期間にわたってデータの「チャンク」をクエリし、中間の統計サマリーを計算して、ループするときに複数のチャンクにわたって結果を結合することで、問題を段階的に解決できます。歴史全体にわたって。いくつかの統計的測定値はチャンク間で組み合わせるのは難しいですが、Avg（）のようなものはチャンクごとにsum（）とcount（）しか必要ないため、O（1）とO（chunksize）の両方があるため、チャンクのマージは適切にスケーリングできます。

データは変更されず、追加されるだけなので、データは好きなところに保存します。たとえば、Amazon S3ですが、高速読み込みのデータベースであれば問題ありません。インデックスはありません。選択するデータベース/ FSには、バケット内のデータを読み取るオプションが必要です。たとえば、1Mレコードのファイルを1日1つ持つことができます。

次に、Sparkを使用してフィルタリング/分析を行います。これはクラスターベースであり、ニーズに合わせてスケーリングできます。

応答は、この後のデータの使用方法によって異なります。処理にはCassandraを、分析にはHiveを使用してください。

この種の状況は、SQL Server（私が最もよく知っているもの）のようなプラットフォーム上でRalph Kimball等によって完成された手法を使用するデータウェアハウジングに理想的です。これらは、このタイプのシナリオを念頭に置いて特別に設計されました。比較的静的な膨大な量のデータレコードで、この種の集計を計算する必要があります。番号リレーショナルテクニックは、この種のアプリケーションで適切に実装されたデータウェアハウジングと一致しますが、組織がそれらを実装するソフトウェアパッケージ（SQL Server Analysis Servicesなど）のライセンスを単に提供できない場合は、他のものよりも確かに優れているものもあります。この種のデータアクセス用にカスタマイズされたMDXなどの言語を実装するための学習曲線もあります。データウェアハウジングが組織にとって実行可能なオプションである場合でも、リレーショナルソリューションを探すために時間を無駄にしないでください。これはリレーショナルデータベースの問題ではありません。必要に応じて、Kimballなどの基本的なリファレンスやSSASおよびMDXへのリンク（申し訳ありませんが、Oracleや、よく知らない他の競合他社には役立ちません）のドキュメントを投稿できます。お役に立てば幸いです。