Twitter の「つぶやき」に似ていますが、最大 1 MiB のサイズで、ユーザーからの任意の長さのテキスト入力を受け入れるアプリケーションを考えてみましょう。アプリケーションの分散性により、同じテキスト入力が特定のノードに複数回配信される場合があります。同じテキストが (Apache Solr に基づいて) インデックスに 2 回表示されるのを防ぐために、テキストの MD5 ハッシュを一意のキーとして使用しています。
残念ながら、Solr は SQL のような "INSERT IGNORE" をサポートしていません。そのようなものは、すべての複製ドキュメントが元のドキュメントの内容を置き換えるからです。アプリケーションのユーザーはフィールドを追加できるため、この置き換えには問題があります。それを防ぐために、私には2つの選択肢があります。
各挿入の前に、MD5 ハッシュ化された一意のキーを使用してドキュメントのインデックスをクエリします。結果が得られた場合、ドキュメントがインデックスに既に存在することがわかります。おそらく、1 分あたり数百のドキュメントのインデックスを作成しているため、このアプローチは遅すぎることがわかりました。
MD5 ハッシュを、フラット ファイル、MySQL などの追加のストアに保存します。このアプローチは、この質問の基礎です。
1 分間に数百回の挿入を処理し、値が存在するかどうかをすぐに知らせることができるデータ ストレージの形式は何ですか? MySQL (Solr インデックスとは異なるスピンドル) とフラット ファイルの両方を使用してテストしていgrep -w someHash hashes.txtますcat someHash >> hashes.txt。どちらのアプローチも、インデックスが大きくなるにつれて速度が低下するように見えますが、いずれかのアプローチが実行可能かどうかを確認するには、数日または数週間かかるでしょう.
ハッシュの存在を保存およびチェックする他の方法は何ですか? MySQL とフラット ファイルのアプローチでは、どのような基本的な問題が発生する可能性がありますか? クヌートはどうする？