4

データのインデックスを作成しています。これには、多くのトリプレットをフォームに格納する必要があります(document, term, weight)。このような行を最大数百万行保存します。現在、MySQL で単純なテーブルとしてこれを行っています。ドキュメントと用語の識別子を、他のテーブルへの外部キーよりも文字列値として保存しています。ソフトウェアを書き直し、データを保存するより良い方法を探しています。

HBase の仕組みを見ると、これはかなりスキーマに適合しているように見えます。多くのトリプレットを保存する代わりにdocument、{term => weight}.

私は単一ノードでこれを行っているので、分散ノードなどは気にしません。MySQL が機能するのでそのまま使用する必要がありますか、それとも HBase を試すのが賢明でしょうか? Lucene がこれをフルテキスト インデックス作成に使用していることがわかります (これは、私が行っていることと似ています)。私の質問は、単一の HBase ノードが単一の MySQL ノードとどのように比較されるかということです。私は Scala から来ているので、直接の Java API は、JDBC や MySQL の各クエリの解析などよりも優れているのでしょうか?

私の主な関心事は、以前はボトルネックだった挿入速度です。処理後、ライブ クエリのためにデータを MySQL に戻すことになるでしょう。

両方のプロトタイプを作成してみますが、コミュニティがこれに関する貴重な洞察を提供してくれると確信しています。

4

2 に答える 2

1

仕事に適したツールを使用してください。

ACID (アトミシティ、一貫性、分離、耐久性) とは対照的に、多くの反 RDBMS または BASE システム (基本的に利用可能、ソフト状態、最終的に一貫性がある) があり、こことここから選択できます。

従来の RDBMS を使用してきました。CLOB/BLOB を格納することはできますが、これらのオブジェクトを検索するために特別にカスタマイズされた組み込みのインデックスはありません。

ドキュメントを挿入するときに、ほとんどの作業 (検出された各タプルの加重頻度の計算) を行う必要があります。

また、各検索後に各 (documentId,searchWord) ペアの有用性をスコアリングする作業を行うこともできます。

そうすれば、毎回より良い検索を行うことができます。

また、各検索のスコアまたは重みと、他の検索との類似性のために重み付けされたスコアを保存する必要があります。

一部の検索が他の検索よりも一般的であり、ユーザーが一般的な検索を行うつもりであるにもかかわらず、検索クエリを正しく表現していない可能性があります。

ドキュメントを挿入すると、検索の重み付けインデックスも変更されます。

考えれば考えるほど、解決策は複雑になります。まず、優れた設計から始める必要があります。設計で予測される要因が多ければ多いほど、結果は良くなります。

于 2009-11-23T19:36:46.487 に答える
1

MapReduce は、タプルを生成する優れた方法のようです。scala ジョブを jar ファイルに入れることができる場合 (私は以前に scala を使用したことがなく、jvm n00b であるためわかりません)、それを送信し、それを実行するためのラッパーを少し書くだけです。マップ上でクラスターを減らします。

完了後のタプルの保存に関しては、タプルを保存するだけの場合は、 mongodbのようなドキュメント ベースのデータベースを検討することもできます。

一般的に、テキストを使ってもっと統計的なことをしているように思えます...自分で書くのではなく、単純に lucene や solr を使ってやっていることを考えたことはありますか?

于 2009-11-21T07:10:58.677 に答える