0

膨大な量のデータ (1 日あたり約 200,000 txns) を保存する必要があるアプリケーションがあり、各レコードのサイズは約 100 kb から 200 kb です。データの形式は JSON/XML になります。

アプリケーションは高可用性である必要があるため、S3 または AWS DynamoDB にデータを保存する予定です。

いくつかの属性 (日付範囲、ステータスなど) に基づいてデータを検索する必要がある場合があります。ほとんどの検索はいくつかの一般的な属性に対して行われますが、特定の運用ユース ケースでは任意のクエリが含まれる場合があります。

非リレーショナル データを検索する方法を調査したところ、これまでのところ、ほとんどのテクノロジで使用されている 2 つの方法が見つかりました。1) インデックスを構築する (Solr/CloudSearch など) 2) Map Reduce ジョブを実行する (Hive/Hbase など)

私たちの要件は、検索結果が信頼できるものであることです (S3/DB のデータと一致している - オラクル クエリのようなものです。遅くても問題ありませんが、データを取得するときに、クエリに一致するすべてのものを返すか、少なくとも許可する必要があります)。一部の結果がスキップされたことはわかっています)

最初は、インデックス ベースのアプローチが MR よりも高速であるように見えます。しかし、それが信頼できるかどうかはわかりません-インデックスが古くなっている可能性がありますか? (検索を行ったときにインデックスが古かったことを確認して修正できるようにする方法はありますか? インデックスを DB/S3 の値と常に一致させる方法はありますか? Oracle DB のインデックスに似たもの）。MR ジョブは常に信頼できるようです (クエリごとに S3 からデータをフェッチするため)、その仮定は正しいですか? とにかくこのクエリを高速化する方法はありますか? S3 のパーティション データであり、各パーティションに基づいて複数の MR ジョブを実行できますか?

4

2 に答える 2

0

ドキュメントを追加した後、Solr インデックスを <commit /> および <optimize /> できるので、古いインデックスが問題になるかどうかはわかりません。1 日あたりおそらく 100,000 の追加ドキュメントを処理する Solr インスタンスをセットアップしました。私が仕事を辞めたとき、インデックスには 140 万のドキュメントがありました。これは内部レポートに使用され、パフォーマンスが高かった (最も複雑なクエリでも 1 分未満)。元同僚に聞いたところ、1年経った今でもうまくいっています。

ただし、マップ削減ソフトウェアと話すことはできません。

于 2012-04-17T23:22:25.953 に答える
0

たとえば、週/月ごとに 1 つの Solr コアを使用することを検討する必要があります。これにより、古いコアは読み取り専用になり、管理が容易になり、複数の Solr インスタンスに非常に簡単に分散できます。1 日あたり 200,000 件のドキュメントが追加される場合、それまたは Solr シャーディングが必要な場合、単一のコアでは永遠に十分ではありません。

于 2012-04-19T13:50:06.893 に答える