私たちのチームは、Couchbase DB に裏打ちされたアプリケーションの開発を開始しました。私たちの誰もが、SQL を使用しないデータベースを使用するのは初めての経験です。
エンティティの定義を開始し、Couchbase マニュアルで提案されている「タイプ」プレフィックスを使用する慣行を採用しました。
Entity "A":
key: a#123
Entity "B":
key: b#123
しかし、複合ドキュメント キーを作成するための戦略の選択に混乱していることに気付きました。私たちはカウンターをよく使用しますが、カウンターには独自の書類が必要です。私たちの鍵は複雑になりました:
Daily counter "x" for entity "A":
key: cntrx#a#123-20140117
私たちはさまざまなアプローチを検討してきましたが、この件についてはまだグリーンホーンであり、アドバイスを求めたいと考えています.
階層キーはまったく良いですか? 重要なキーを定義するためのベスト プラクティスを共有できる人はいますか?
私たちのプロジェクトでは、以下に説明する方法で階層キーを使用しました: キーの最初の部分は、RDBMS のテーブル名のようなものです:
users- 「テーブル」を表します
次に、各ユーザーには、例の独自の ID があります。
users:1- 「1 人のユーザーを表す」
「:」を使用したのは、他の区切り文字より見栄えが良いからです。任意の区切り記号を使用できます。
前の例のようにシーケンシャル インデックスを使用する場合idは、いくつかのキーからそれらを取得する必要があるため、次のようになります。
users:counter- 「最後のユーザー ID」を保持するキー (自動インクリメントのように機能します)
ユーザーアカウントの「サブセクション」を保存する必要がある場合は、次のように保存できます。
users:<user's id>:subsection.
より複雑な例
users:1:avatars:1:url- このキーによってユーザー 1 のアバター URL を取得することを意味しますが、ユーザーが多くのアバターを保存したい場合はusers:1:avatars:X:url、X がusers:1:avatars:counterキーの値になります。
この戦略は、1 つの値、JSON、またはバイナリ データのみを格納するすべてのドキュメントに使用されました。
まさにあなたの例のために、私は選択します：
a:123-20140117:counter- これは、(RDBMS 言語で言えば) "a" という名前のテーブルがあることを意味します。テーブル "a" には、フィールド "cntrx" を持つ ID (または他の何か) "123-20140117" を持つレコードがあります。
UPD: キーサイズについて。実際、それは問題ではありません。はい、キーのサイズは制限されていますが、サイズを小さくする方法はたくさんあります。それらの1つ-ハッシュを使用しますが、キーが長くなり、より多くのメモリを消費するため、それは悪い方法だと思います。私たちのプロジェクトでは、memcached バケットに「短い」キーを使用しました。人間が理解できるキー名と短縮値を表す列挙型 (couchbase にも格納できます) がありました。
例: レコードのセットがあります: 30 枚以上の写真を持っているユーザーのリスト。したがって、キーと値のペアがあります。
usersByPhotosCount - k:ubpc:{0}
30枚の写真のキーは になりますk:ubpc:30。
ただし、このような最適化は本番環境でのみ行うことをお勧めします。開発では、アプリとデータベースにわかりやすいキーを用意することをお勧めします (つまり、開発用の通常の kv ペア、本番用の短縮および難読化の 2 セットの kv ペアを作成し、環境に応じてそれらをロードできます)。
あなたの質問に関して、いくつか提案したいことがあります。
Nosql はその名の通り、優れた SQL データベースを設計するために以前使用されていた考え方とは大きく異なる考え方が必要です。たとえば、nosql データベースは基本的に大きなハッシュ マップです。そのため、キーを小さくするなどの考慮を払うことは良いことかもしれませんが、キーはドキュメントにアクセスする手段に過ぎないことを忘れないでください。それらを特定の方法で表示することから得られる特定の利点がない限り、それらは何も意味する必要はありません。通常、最初に必要なプライマリルックアップが常にあります。適切な例として、ユーザーがアプリに移動するときに直接「b#123」を要求する必要があることをどのくらいの頻度で認識しますか? これが有利であると私が考えることができる唯一の場所は、ユーザー名またはユーザーが知っているその他のデータです。
CB のマニュアルでは、複合キーを使用することをお勧めしますが (単純なデータベース構造には適している可能性が非常に高い)、一般に、キー サイズはできるだけ小さくする必要があります。キーは最大 256 バイトに制限されています。すべてのキーは RAM に保存する必要があります。そのため、キー内のデータが多いほど、残りのデータに使用できるデータが少なくなります。代わりに、ドキュメントにタイプ フィールドを作成し、ビューを使用して特定のタイプのオブジェクトを抽出する (またはオブジェクトをタイプ別にインデックス化する) ことをお勧めします。これにより、最終的には今後の柔軟性が向上します。
カウンターの説明はかなり曖昧なので、自動インクリメントキーとして使用していると仮定しています。カウンターから逃れるために、ここでアプローチを変更する必要があることをお勧めします。データベース内のすべてのキーに一意の識別子を使用しています。複合キーを使用するのは、キー自体が重要だからです (たとえば、リビジョン管理されたドキュメントでは、ドキュメント ID + ドキュメントが保存された日付の複合キーを使用して、一意であることを確認します)。数百万 (または数十億) のオブジェクトがある場合でも、12 バイトの GUID を使用して、ドキュメント ID の一意性を実質的に保証できます。これにより、新しいレコードを保存する必要がある場合に、アプリケーションで深刻なボトルネックが発生するのを防ぐことができます。