1

100Gb以上のテキスト ドキュメントを操作するアプリケーションを作成しています。各ドキュメントのサイズは 2Kb ～ 100Kb です。

最初は、MySQL や Firebird などのDBMS を使用して、生のドキュメントを保存し、インデックスを lucene のインデックスに保存することを想定していました。このアプローチにはいくつかの欠点があります。たとえば、データベース トランザクションは lucene インデックスについて何も認識せず、その逆も同様です。したがって、それらを同期する必要があります。

次に、Lucene がドキュメント全体を index に格納できるものを想定しました。したがって、インデックスのバックアップを定期的に作成する必要があります。しかし、とても簡単です。カタログ全体をインデックス付きでコピーできます。ある種の No SQL ストレージ (Lucene など) を使用しています。また、DBMS を使用しない場合もあります。

元のドキュメントをインデックスに保存するかどうかのベストプラクティスは何ですか? 私は本当にそのような目的で DBMS を使用したくありません。出来ますか？

4

1 に答える 1

3

生のドキュメントを Lucene インデックス、特にあなたが話しているサイズに保存したくないでしょう。私はこれをいくつかの方法で行いましたが、どちらもインデックス付きフィールドのみを Lucene インデックスに格納し、未加工のドキュメントへの ID/ポインターを持っています。私は 1 億レコードをはるかに超えるインデックスを扱ってきましたが、それらは単一のサーバーで正常に動作します。

これが重要な理由は、追加の 100 ギガのデータを保存する必要がない場合、インデックスのビルド時間とインデックスの管理性が大幅に低下するためです。

基本的に、検索クエリを検索/満足させるために必要なすべてのフィールドにインデックスを付ける必要があります。ユーザーがグリッド内のアイテムをクリックした場合、生のテキストを表示する必要があると思います (UI パターンでは、ほとんどの場合、多くの Lucene フィールドにアクセスしますが、完全なバイナリ テキストをプルダウンする必要はほとんどありません)ファイル）。

Lucene と組み合わせて使用​​した raw アクセスは次のとおりです。

  • 大規模なバイナリ ファイル ストレージ用に最適化された SQL Server FILESTREAM。それも本当に速いです。MySQLにこれがあるかどうかはわかりません（これで動作したことはありません）
  • キー値の NoSQL クラウド データベースである Azure Table Storage。これは、バイナリ BLOB を格納するために使用されました。

キーに基づいて高速にアクセス/ストリーミングできる、より大きなバイナリ ファイル用に最適化されている限り、永続ストレージが何であるかは問題ではありません。Lucene がバイナリ テキスト ファイルにアクセスするための ID ポインターを持っている限り、Redis のようなメモリ内キャッシュを使用することもできます。

于 2013-11-09T22:35:30.917 に答える