同様の質問があります 大規模なデータ - ストレージとクエリ しかし、私の質問はさらに難しいと思います。
問題を単純化するために、巨大なデータ セットがあります。各レコードに 3 つのフィールドがあるとします。
日付、場所、オブジェクト
オブジェクトがどの日にどの場所を訪れるかを意味します。
毎日、5000 万の新しいレコードが存在する可能性があります。100 日分のデータを保持する必要があります。
クエリは次のようなものです。
これをどのように設計すればよいですか？解決策を与えることは可能ですか？試してみるべきツールはありますか？mongodb または hadoop を使用できますか?
さらに、クエリはフロントエンドからクエリされるため、クエリにそれほど時間はかかりません。
ありがとう。
説明するクエリは、リレーショナルデータベースに最適です。大量のデータがありますが、クエリはかなり単純なインデックススキームに適しています。
一部の商用データベースには地理空間拡張機能があり、クエリを「日付範囲を指定して、場所xから20km以内にあるオブジェクトを教えてください」に拡張できます。
また、行数が多い場合でも、実際のデータサイズはかなり制限されているようです。ハイエンドマシンのメモリに収まると期待するのは不合理ではありません。
ほとんどのデータベースシステムは非常に大きなテーブルを処理できます。RDBMSが保持するレコード数に論理的な制限はありませんが、明らかに実際的な制限があります。Oracleは、大規模なデータセットでのパフォーマンスに定評がありますが、経験豊富なOracleDBAに支援を求めることは間違いなく価値があります。大量のデータを処理する場合の一般的な戦略は、「シャーディング」です。つまり、さまざまなレコードをさまざまなテーブルやサーバーに配置します。すべてのクエリが日付ベースの場合、たとえば、毎月のデータを異なる物理サーバーに配置できます。
RDBMSから始めて、サンプルクエリを実行および調整することにより、スケーラビリティのニーズを満たしているかどうかを判断するためのテストデータセットを作成します。ハードウェアを調整し、余裕があればさらに追加します。
Hadoopから多くのメリットが得られるとは思いません。多くの処理を行っておらず、大規模なデータセットを検索しているだけです。
MongoDBは、ドキュメントスタイルのデータを処理するように設計されています。データは、ドキュメントではなく、本質的にリレーショナルに見えます。これはMongoDBでビルドできますが、多くのメリットが得られるかどうかはわかりません。
その問題は思ったほど難しくありません。2 つのインデックスが必要です。
(Location, Date, Object)
(Object, Date, Location)
これらの 2 つのインデックスは、クエリを最適に満たします。心配する必要がある固有のスケーラビリティ制限はありません。
Date古いパーティションを効率的に削除できるように、パーティショニングを検討することもできます。