3
高速（<1s）の読み取りクエリパフォーマンスを備えた大規模（> 22兆項目）地理空間データセット
私は、迅速な読み取りクエリのパフォーマンスを必要とする大規模な地理空間データセット用の新しいシステムを設計しています。したがって、次の状況で必要なパフォーマンスを達成するために、適切なDBMS、データ構造、または代替方法について可能性があると思うか、経験/アドバイスを持っている人がいるかどうかを確認したいと思います。 データは、処理された衛星レーダーデータから継続的に生成され、グローバルカバレッジになります。衛星の解像度と地球の土地被覆率に基づいて、全データセットを推定して、地球上の750億の場所で値を生成します。単一の衛星の寿命にわたって、出力はこれらの場所のそれぞれで最大300の値を生成します（したがって、22兆を超える値の合計データセット）。これは1つの衛星のためのものであり、軌道上にはもう1つの衛星があり、新しい数年でもう2つの衛星が計画されています。したがって、多くのデータがあります！単一のデータアイテムは非常に単純で、（経度、緯度、値）のみで構成されますが、アイテムの数が原因で、1つの衛星で最大100 TBを生成すると推定しています。 書き込まれたデータは更新する必要はありません。新しい衛星の取得が処理されると成長するからです。書き込みパフォーマンスは重要ではありませんが、読み取りパフォーマンスは重要です。このプロジェクトの目標は、Googleマップ上のレイヤーなどのシンプルなインターフェイスを介してデータを視覚化できるようにすることです。各ポイントには、時間の平均、勾配、または何らかの関数に基づいた色付きの値があります。（投稿の最後にデモ）。 これらの要件から、データベースはスケーラブルである必要があり、クラウドソリューションを検討する可能性があります。システムは、「points near（lat、lon）」や「points within（box）」などの地理空間クエリを処理できる必要があります。また、単一のポイントと最大で50,000ポイント（ただし、最大200,000ポイントが望ましい）。 これまでのところ、1億1100万の場所に最大7億5,000万のデータ項目のテストデータセットがあります。私はpostgres / postGISインスタンスを試してみましたが、これは問題なく動作しましたが、シャーディングの可能性がなければ、これはデータの増加に応じて対処できるでしょう。シャーディングでは、データボリュームに合わせて拡張するだけで十分な場合があります。最近、私はelasticsearchについて少し学んだので、これについてのコメントは私にとって新しいので役立つでしょう。 完全なデータセットで達成したいものの簡単なアニメーションを次に示します。 このgif（私のpostgresトライアルから）は（6x3）事前に計算されたラスタータイルを提供し、それぞれが〜200,000ポイントを含み、それぞれを生成するのに〜17秒かかります。ポイントをクリックすると、1秒未満で最も近い場所にあるすべての履歴値を取得して、グラフが作成されます。 長い投稿に謝罪、すべてのコメント/アドバイスは大歓迎です。