高速（<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秒未満で最も近い場所にあるすべての履歴値を取得して、グラフが作成されます。

長い投稿に謝罪、すべてのコメント/アドバイスは大歓迎です。

場所ごとに分割できます。グローブをグリッドに分割し、そのグリッド内の各正方形を1つのサーバーに配置します。クラウドについて述べたので、それはクラウドに適しています。もちろん、複数のサーバーからの結果を手動でマージする必要があります。

これにより、好きなデータベースソリューションを使用できます。単独でスケーラブルである必要はありません。

個々の正方形には異なる量のデータがあります。異なるサイズのマシンを使用できます（これはクラウドであるため）。または、同じマシンに複数の小さな破片を配置します。

このシャーディングスキームは、実行するクエリの種類に最適です。各クエリはごく少数のシャードに触れるだけで済むためです。クエリごとにすべてのタイムシャードに触れる必要があるため、時間によるシャーディングはさらに悪化します。ランダムシャーディングにも同じ問題があります。

全体として、クエリパターンはシャーディングスキームに非常によく適合するため、これは簡単なシャーディングケースです。

実際、このためにデータベースが必要なのかと思います。グローブを1000x1000以下のタイルに分割し、各タイルのBLOBストレージに1つのフラットファイルを作成できます。BLOBストレージは1MのBLOBをまったく気にしません。

このストレージスキームを使用すると、クエリの実行は概念的に非常に簡単です。データを複数のグリッド解像度で冗長に保存することもできます。

読み取りクエリはどの程度最新である必要がありますか？

マップに最新の測定値を表示するだけでよい場合は、時間でデータベースを分割できます。これにより、マップのクエリ負荷が軽減されます。

特定のポイントの履歴については、xとyによって履歴を示す2番目のストアを保持できます。これは、履歴データが変更されないため、夜間の更新/更新で実行できます。

次に、異なるズームレベルでマップと統合するために、より粗い解像度で平均を事前計算できます。これにより、大きなマップエリアで取得するポイントの数が減ります（ズームアウト）。より小さな領域をクエリするマップでより多くのズームを行うには、より細かい解像度を使用します。これを本当に高速化する必要がある場合は、タイルをブロブとして計算し、アプリケーションで解釈することができます。

これらは集計情報の再計算を伴うため、クエリ結果に多少の遅延が発生します。許容可能なレイテンシーに応じて、この種のアプローチを使用して読み取りを最適化できます。

OK、だからあなたのポイントは時間をかけて平均を計算する必要があります。この計算では、実際のクエリは22兆個のアイテムからかなり下がっていると思います。ラスタ値はクエリのために事前に計算できるからです。

クエリには2つのクラスがあるように思えます。1つは現在のビューウィンドウ内にある場所を理解するためのもので、もう1つはそれらのポイントに必要な統計を提供するためのものです。私の提案は、それぞれに個別の専用ツールを使用することです。

すべての測定値が同じ75Bnポイントのセットに関連すると仮定しています。したがって、これらの緯度/経度は、一度確立されると静的です。グループ化、集計、およびインデックス作成は1回限りのコストで行えます。したがって、地域とズームレベルで分割することをお勧めします。各シャードのサイズは、各GISインスタンスから達成できるパフォーマンスによって決まります。

GISは、時系列データベースに渡されるポイントのセットを返します。これは測定値を保持し、集計を実行します。KDBは私が知っているものです。これは、お客様のシナリオよりもキーは少ないがキーあたりのデータポイントが多い証券取引を対象としています。

キー値をGISサーバーからtimeseries DBに転送するにはコストがかかります。私の仮説は、このコストは、タスク固有の時系列DBでの高速処理によって返済されるというものです。質問の文言から、単一のインスタンスがすべてのデータを保持することはできないため、一部のクロスサーバートラフィックは避けられないように思われます。コンポーネントの相対的な速度を考えると、データがキャッシュされているリモートサーバーにキーセットを送信する方が、ローカルディスクからデータを読み取るよりも高速であるようです。

ポイント検索部分と値計算部分が互いにローカルである場合、もちろん、応答がより速くなると予想されます。私の（限られた）理解は、与えられた点に最も近いNを見つけることは簡単なことではないということです。これが、特定のソフトウェアを使用して実行することを提案した理由です。ポイント検出を次のように縮小できる場合

where latitude between x1 and x2
and logitude between y1 and y2

その部分は価値保存ソフトウェアで処理でき、GISはアーキテクチャから削除されました。

私はそのようなシステムを実装していません。私は本当にここで大声で考えています。ペタバイト規模では、既成のソリューションはありません。ただし、多くの衛星データプロバイダーが存在するため、問題は扱いやすくなります。がんばろう。