1

約 10mm ハッシュのデータセットがあります。人々がハッシュのリストをそれらと比較して、それらが一致するかどうかを確認できるようにする必要があります。現在、SQL を使用しており、基本的に推測配列内の各項目をスキャンしています。これは約 10K で機能しましたが、ユーザーは 10mm ハッシュの辞書に対して 200K ハッシュのような、より大きなセットをチェックする必要があります。

sqlまたはnosqlまたはその他で、これに適したアプローチは何ですか

--

意図のコンテキストについては、オプトアウト リストを管理し、マーケティング マネージャーがそれに対してシートをアップロードできるようにし、クリーンでノーメール ファイルを返します。

4

2 に答える 2

1

テーブルで検索値を提供できる場合は、おそらく EXCEPT クエリが最善の策です。これにより、テーブル 2 (オプトアウト リスト) にないテーブル 1 (検索値) のすべてのエントリが取得されます。EXCEPT の例については、こちらの投稿を参照してください: http://sqlity.net/en/1401/a-join-a-day-except/

検索値がデータベースにないためにそれができない場合は、1,000 万個のハッシュ値すべてを含むメモリ常駐ハッシュ テーブルを作成し、それを使用して、特定の電子メールがリストに含まれているかどうかを判断します。バッチごとにそのテーブルを新たに作成する必要がある場合でも、データベースに 20 万回のリクエストを送信するよりも高速です。

于 2012-12-21T22:45:55.687 に答える
0

現在のソリューションはスケールアップできないようです。つまり、メモリや CPU などを追加して、ユーザーが望むレスポンシブ ソリューションを維持することは、システムの負荷が増加したために不可能になっています。

応答性を維持する 1 つの方法は、スケールアウトできるスケーラブルなソリューションを実装することです。つまり、ワークロードを複数のシステムに分散します。

たとえば、nosql で 1000 万のハッシュのローカル コピーを持つ 10 のシステムをそれぞれ持つことができる場合、200K のハッシュをチェックする要求が来ると、作業は 10 のシステムに分散され、それぞれが 20K のハッシュをチェックする要求を処理します。 .

これは古典的な分割統治法です。

擬似コードは次のようになります

while (1) {                   
    wait for a request to come in;

    for (j = 1; j < 10; j++) {
        spawn(system[j], 1/10 of the request for matching)
    }   

    wait for/collect responses from 10 systems

    return result;
}

追加や削除などの変更が行われた場合、システム上のローカル コピーの一貫性を維持する必要があります。

于 2012-12-23T06:11:35.990 に答える