1

そのため、いくつかの調査を行ったところ、キーのサイズに応じてストレージ要件が大幅に増加する可能性があるようです。

実際には、「long int」をキーとして使用できるようにしたいのですが、couchdb ではキーが正しい文字列である必要があるため、これは不可能です。これを回避する方法はありますか?

私のIDは次のように見えるため：

{ "_id" : "10209939", ....data here ... }
{ "_id" : "10209940", ....data here ... }
{ "_id" : "10209941", ....data here ... }

範囲クエリを実行するために数値を保持したいと思います。しかし、キーの長さに応じてストレージが増加するため、私のストレージは爆発します。ある意味では、文字列として表されるこれらの ID は、long int として解釈されるよりも多くのバイトを必要とします。

「数値」整数を ids としてドキュメントを保存した経験のある人はいますか? couchdb が "_id" を文字列として認識している場合、どのようにしてストレージ効率を向上させましたか? いいえ、文字列ではなく「long int」です。

4

2 に答える 2

1

ドキュメントのサイズが非常に小さい場合を除き、ID は重要ではありません。いくつかのテストを行い、異なるアプローチ間で実際にどれだけのスペースが失われるかを確認することをお勧めします。テストを行う前に圧縮することを忘れないでください。また、CouchDB 1.2.0 のデータ圧縮の使用も有効になっているため、大きな ID の影響も軽減されることに注意してください。

厳密な要件は JSON UTF-8 です。詳細については、RFC http://www.ietf.org/rfc/rfc4627.txtを参照してください。可能であれば、連続して増加する ID を持つドキュメントを挿入していることを確認する必要があります。これにより、B ツリーの再調整の必要性が減少します。もちろん、圧縮を使用して後でこれに対処することもできます。

ほとんどの場合、id に使用する最も賢明なものは、一意性が必要な意味のある値です。CouchDB は ID の一意性のみを強制するため、ID を有効にすることもできます。

于 2012-07-02T08:32:53.523 に答える
1

ID は文字列でなければなりません。代替手段はありません。

範囲クエリを実行できますが、数値範囲ではなく字句範囲のみです。

于 2012-06-30T21:51:48.300 に答える