3

私は、データのセカンダリ インデックスがキー内のすべての情報を使用して構築され、値側には何も必要としない設計に取り組んでいます。これは問題を引き起こす可能性がありますか?

空白の値を持つことが技術的に可能かどうかは尋ねていません。たとえば、ソートされたキーを追加すると、一部のツリー構造のバランスが崩れる可能性がありますか? (leveldb がツリーを使用していると言っているのではなく、類推を考えようとしているだけです ;-) )

つまり、「プライマリレコード」が次のように見えるとします（セパレータとしてのヌル）

  • キー = uniqueTableID \0 uniqueRowID
  • 値 = フィールドのコレクション

典型的な単一値フィールドのセカンダリ インデックスは次のようになります。

  • キー = uniqueFieldID \0 keyValue \0 uniqueRowID

これにより、部分キー [uniqueFieldID \0 keyValue] による反復が可能になり、メイン レコードが削除された場合やキー値が変更された場合に、これらのキーを簡単に見つけて削除し、メイン レコードの uniqueRowID から作業を戻すことができます。したがって、同じ uniqueRowID で終わる複数のキー値が存在する可能性がありますが、uniqueFieldID で始まり、uniqueRowID で終わる特定の組み合わせのキーは 1 つだけです。

唯一のことは、ペアの値側に値を入れる必要がないということです。

私はこの概念設計に満足しており、誰かが穴を見つけることができるかどうかを確認しています. たとえば、leveldb 内部が歪んでパフォーマンスの問題が発生する場合。

1 つの特定のアプリには、そのようなキーが何万もあると予想されます。

保存したい値の例として、テキスト フィールドへのセカンダリ ワード インデックスは次のようになります。

  • キー = uniqueFieldID \0 keyValue \0 GUID
  • 値 = 単語の出現数、または大きなブロブのスキャンが高価な場合はオフセットのリスト
4

2 に答える 2

2

LevelDB のキーと値は不透明な配列であり、スライスのコンストラクターのドキュメントを簡単に調べると、空のスライスを作成する方法が示されます。

// Create an empty slice.
Slice() : data_(""), size_(0)

これは、値データがないタイプの状況にまさに役立ちます。

于 2012-05-29T17:56:18.100 に答える
1

leveldb でさえ削除を値のないキーとして格納するので問題ないはずです。内部的に leveldb は、各 SST のキーにプレフィックス長エンコーディングを使用し、特定のケースのキー サイズをさらに削減するのに役立ちます。あなたの場合の唯一のゆがみは、インデックスのサイズです。通常、インデックスのサイズはデータ ブロックのごく一部になります (小さなキーと比較的大きな値を想定) が、インデックスはデータ ブロックごとにキーを格納するため、インデックスは比較的大きくなる可能性があります。

于 2013-09-04T23:04:00.237 に答える