LevelDBをストレージエンジンとして使用し、キャッシュ層としてmemcachedする分散ストレージプロジェクトでは、ストレージエンジンにキーが存在しない95％のクエリがあります。ストレージエンジン：そのキーが存在しないことを素早く見つける方法
memcachedレイヤーで、キーが見つからない場合は、LevelDBをクエリします。
LevelDBでは、デフォルトのブルームフィルタを使用して、キーが存在するかどうかを判断しますが、依然として1％の偽陽性率があります。 1％のパーセンテージのために、私たちはIOによって値を要求しなければなりません。これはクライアントが許容することができません。 （95％のキーは存在しません）
キーが存在しないかどうかを知る良い解決策はありますか？
更新日： 1.鍵は毎日生成されます（ユーザID +日付）。一度キーを取得できないと、クライアントはその値を記憶層に入れます。 2.クライアント私はあなたのソリューションを改善するために使用することができる2つの方法があると思い
（クライアントが敏感レイテンシーである）（TP99）<のxミリ秒の待ち時間を読みたい：
1.要求することができるすべてのキーと仮定します限られたセットに含まれています。たぶんあなたは、すべてのキーをセットに入れることができます。これは、 "FALSE"のような値を持たないものです。
2. leveldbのパフォーマンスを向上させます。テーブルキャッシュとブロックサイズのサイズを調整するか、ストレージメディアとしてssdを使用してください。
私たちはあなたのシナリオに似たブラックリストのような生産的な環境とサポートアプリケーションで、持続的なkv-storageとしてleveldbを使用します。
お勧めに感謝します。最初の解決策では、私たちの鍵が毎日生成される（key = userid + date）ため、すべての鍵をfalseにフラグを立てることは不可能です。 2番目の解決法では、テーブルキャッシュはまだIOを要求する必要がないので見つけることができません。ブルームフィルタの偽陽性が存在するため、ブロックサイズが少しだけ助けになります。ブロックサイズを増やすと、キーの数が増えます。つまり、ブロックを見つけることが少なくなりますが、IOアクセスを大幅に回避できる方法があります。 –
私はこのアーキテクチャの下でより良いアイデアを理解することはできません。実際、このようなシナリオに直面すると、私は単なる障害に耐え、十分なストレージを提供できるRAMキャッシュシステムを使用します。 –
多分あなたは1日あたりのユーザーアクセスを記録したいでしょう。そうすれば、この「キーは存在しません」という問題を「存在していますが、値には指定された項目が含まれていません。 –