1

現在、最大 2 ミルのレコードで非常に高速な検索を実行する必要があるアプリケーションがあります。

検索では、さまざまな関数/計算と並べ替えに加えて、大きなフリーテキスト フィールドと、さまざまな範囲の整数/小数フィールドの両方を検索する必要があります。

現在、これは大規模な MSSQL データベースで処理されており、組み込みのフリーテキスト エンジンとレプリケーションを使用して、トランザクション テーブルから負荷を移動しています。

ただし、ご想像のとおり、このソリューションは最もスケーラブルではありません。

私は小さな Lucene ベースのドキュメント ストアを作成しましたが、一般的に結果に非常に感銘を受けており、テキスト検索の所要時間は 1/2 秒 (100,000 レコードの場合) よりも長くはありません。

難点はパラメトリック検索です。Lucene が基本的な範囲マッチングを行うことは知っていますが、もっと強力なものが必要だと感じています。

強力なクエリ機能を備えた db4o を使用して小さなテスト データベースを作成しましたが、これらのクエリは非常に遅く、わずか 10 万レコードで 15 秒以上かかります。SQL ではフリーテキストとパラメトリック検索に約 1.5 秒かかります。

また、私たちのデータベースは 10 分未満の更新解像度を持つ必要があり、レコードの約 15% が毎日変更されます。私たちの SQL サーバーは現在これを処理していますが、きしみ始めています。

適切な技術とアプローチに関するガイダンスをいただければ幸いです。

乾杯、デイブ

4

1 に答える 1

0

LinkedIn は、 boboと呼ばれる Lucene のアドオンを作成して、調べてみる価値のある事実に基づいた検索クエリを拡張しました。しかし、bobo が本当に必要になるのは、絶対に大規模なインデックスがある場合だけだと思います。10 万件のドキュメントの検索にそれほど時間がかかる場合は、本当に奇妙なことが起こっているに違いありません。

于 2010-07-22T16:15:02.237 に答える