luceneを使用してインデックスのメタデータまたはAmazon SimpleDBを格納しますか？

Question

アップロードされたファイルをS3に配置するWebソリューションを設計しています。ファイルをアップロードするときに、ユーザーはインデックス作成やアーカイブの目的でメタデータを追加できます。これまで何度も使用していたLuceneをこの目的に使用する予定でしたが、Amazon SimpleDBがS3用のオブジェクトメタデータサービスを提供していることにも気付きました。

私は、Webアプリケーションを処理するマシンのメンテナンスとオーバーヘッドがなく、Luceneの単一ロケーションインデックスファイルよりもSimpleDBの分散性質があるため、SimpleDBに惹かれています。

Luceneが提供できるWebインターフェイスを入力するときにユーザーがajax検索を行う必要がありますが、SimpleDBも可能です。この限定されたスコープアプリケーションでLuceneでSimpleDBインデックスを使用することで、

ご理解いただきありがとうございます。

Answer 1

私はこれのためにSimpleDBを使用しました。ゼロメンテナンスを除けば、SimpleDBは本質的に無制限に拡張されるという利点があります。非常に高いトラフィックの可能性を考慮して設計したい場合には、これは実際には利点に過ぎません。

私が見る、このためのSimpleDBの主な欠点は以下のとおりです。

• 高いレイテンシー。 SimpleDBは、巨大なスケーラビリティと高可用性のために設計されています妥協点は、要求には中程度の遅延があることです。Luceneのような「ローカル」非分散型サービスやRDBMSテキスト検索機能を使用すると、要求が高いことになります。

• 柔軟性の低いテキスト検索。シンプルなDBは、基本的に=、！=、>、<などをサポートするSQLのようなクエリ構文を持ちます。また、ワイルドカード "％"は、文字列の先頭、文字列の最後、またはその両方（例えば、 "％keyword％"）。正規表現やより複雑なパターンを検索する方法はありません（AND/ORで演算子を組み合わせることを除いて）。 注：LIKE条件は以前は文字列の最後に "％"しかサポートされていませんでした。

SimpleDBはまた、（更新が少し時間がかかることがあり - 時々秒の10S - 一貫して見えるように）デフォルトで「最終的な一貫性」モデルを使用します。これは避けられないスケーラビリティの結果です。しかし、私はそれがあなたのユースケースにとって問題になるとは思わない。