以下は少し長くなったので：これがtl;drです。バージョン：永続的なインデックスを持つハッシュベースのセットのような、高速なキーと値のルックアップのための既存のキー/値のベストプラクティスはありますか？
私はKey-Valueデータベースの世界に興味があり、これまでのところ、次のユースケースを効率的に実装する方法を理解できていません。
一部のデータをシリアル化し、永続的で一意の整数インデックスによって別の場所でそれらを参照するとします。したがって、例：Key = unsigned int、Value=MyData。
データベースは高速キールックアップを備え、MyDataが一意であることを確認する必要があります。
これで、データベースに新しい値を挿入するときに、データベースの現在のサイズなどの新しいインデックスキーを割り当てたり、アイテムを削除した後の衝突を防ぐために、外部にカウンターを保持することができます。
しかし、同じMyData値をデータベースに挿入しないようにするにはどうすればよいですか？これまでのところ、これはKey-Valueデータベースでは効率的に不可能であるように見えます-これは正しいですか？つまり、MyData値がデータベースに存在しないことを確認するためだけに、データベース全体を反復処理したくありません...
では、これを実装するための最良の方法は何ですか？
背景として：私はKDevelopに取り組んでおり、コード分析キャッシュに上記を使用しています。実際には、上記のユースケース1のカスタム実装があります。内部に興味がある場合はBucketとItemRepositoryを検索し、ItemRepositoryの使用例については2を参照してください。
しかし、おそらくあなたは、このコードを理解するのが非常に難しく、したがって維持するのが難しいことに同意するでしょう。そのパフォーマンスを代替ソリューションと比較したいのですが、コードが単純になる可能性がありますが、パフォーマンスが大幅に低下しない場合に限ります。OpenLDAP MDB、Kyoto Cabinet、LevelDBなどのKey-Valueストレージのパフォーマンスに関する誇大宣伝を考慮して、ここから始めたいと思いました。
KDevelopにあるのは、私が理解している限り、基本的にはディスク上/メモリ内のハイブリッドハッシュマップの一種であり、定期的にディスクに保存されます（もちろん、クラッシュなどの場合にデータが大幅に破損する可能性があります。 ）。アイテムはハッシュ値に基づいた場所に保存されます。もちろん、ハッシュ関数が高速である限り、比較的高速な値のルックアップも可能です。追加されたひねりは、アイテムを非常に効率的に検索するために使用できる、ある種の永続的なデータベースインデックスも取得することです。
つまり、簡単に言えば、LevelDB、Kyoto Cabinet、OpenLDAPMDBなどのKey/Valueデータベースでそれをどのように行うのでしょうか。