2

ここに問題があります。

通常の顧客、製品、注文スキーマを含むSQL DBがありますが、巨大です。[各テーブルには数千万行あります]。order_email [約 1 億行] を含む大きなテーブルもあります。このテーブルには、注文に関連付けられたすべての電子メール通信が保持されます。私は正常に動作する order_email の上に使用する全文検索を実装しました。

ここで、電子メール検索機能を拡張して、他のドメイン オブジェクトに基づいてこれをフィルタリングしたいと考えています。つまり、次のようなクエリに答えます

  • 「あなたをあきらめない」というフレーズを含むメールを送信した顧客を表示する
  • 「more ponies」という語句が関連付けられた電子メールを持つ注文を表示します。

実装は、lucene の結果と sql の結果の交差/結合を行うことですが、関連するテーブルとインデックスのサイズが原因で問題が発生せずにこれを行う方法は考えられません

私の失敗したアプローチ

  • 強引な。ほとんどの DB 列を lucene フィールドとして追加します。これは、DB 全体を非正規化し、すべての列をフィールドとして Lucene インデックス (テラバイト単位のサイズ) を作成することと同じです。パフォーマンスが悪く、法外なコストがかかります。

  • Lucene の結果セットを取得し、そこから OrderID を取得し、SELECT * from Order where OrderID IN( ORDERIDs from Lucene ) のように DB にクエリを実行します。メール検索で数百万の orderID が生成される可能性があり、SQL クエリのパフォーマンスが低下する可能性があるため、これは機能しません。

  • アプリケーション コードで結合を行いますが、SQL の結果と lucene の結果を反復処理します。これは、結果のサイズに基づいて、1 つのクエリが 2 数百万行のデータセットをロードしてそれらを反復処理し、CPU とメモリを浪費する可能性があることを意味します。

この 2 つの大きなデータセットの結合/交差をどのように構造化できるかについて考えてみませんか?

ps: Hadoop が腐った卵であることを示唆する最初の人。できればいいのですが、ハードウェアを追加する予算がありません。

4

1 に答える 1

0

OzrenTkalcecKrznaric が質問へのコメントで言ったように、ページングは​​あなたの友達です。(これまでに開発された唯一の最も強力なアルゴリズムは「分割統治法」であることを思い出してください。)

于 2013-08-16T19:32:51.233 に答える