4

私は、ルックアップがいくつかのオブジェクト プロパティ (published = TRUE または user_id = X) によって行われ、どこにも結合がない(1:1 キャッシュ レイヤーのため) SQL の世界から来ました。私のデータには文書データベースが適しているようです。

1 つ (または複数) のオブジェクト プロパティをCouchDB の map/reduce 関数に渡して、ドキュメント タイプごとに多数のビューを作成することなく、データベース内の一致するドキュメントを検索する方法があるかどうかを調べようとしています。

実行時に一致する目的のドキュメント プロパティ キーを CouchDB に渡して、一致するオブジェクト (またはページネーションに一致するオブジェクトの数) を返すことは可能ですか?

たとえば、あるページでdoc.user_id、 Xの が であるすべての投稿が必要ですdoc.published。doc.tags[]別のページでは、「スポーツ」というタグが付いたすべてのドキュメントが必要になる場合があります。

4

3 に答える 3

6

ドキュメント内のキーを反復処理し、キーを発行するビューを作成でき[propertyName, propertyValue]ます。そのようにして、すべてのプロパティ/値を含む単一のインデックスを作成します。大規模になり、パフォーマンスがどのように構築されるかわかりません。また、ディスクの使用量も (おそらく悪いです)。

Map 関数は次のようになります。

// note - totally untested, my CouchDB fu is rusty
function(doc) {
  for(prop in doc) {
    emit([prop, doc[prop]], null);
  }
}

単純なプロパティの基本的なケースで機能し、配列についてスマートになるように拡張し、配列内の各項目の prop/value ペアを発行できます。これにより、タグを処理できます。

クエリを実行するには、[prop] をビューのクエリ キーとして設定します。

于 2011-06-28T03:21:24.447 に答える
2

基本的に、いいえ。

Couch のようなものと SQL DB の主な違いは、CouchDB でクエリを実行する唯一の方法は、基本的にビュー/インデックスを使用することです。SQL のインデックスはオプションです。それらは（主に）パフォーマンスを向上させるために存在します。たとえば、DB が小さい場合、アプリはインデックスが 0 の SQL でも問題なく動作します。(一意の制約に関する問題かもしれませんが、それは詳細です。)

全体的なポイントは、SQL データベースのクエリ プロセッサの一部には、単なるインデックス以外のデータ アクセスの他の方法、特にテーブル スキャン、マージ結合などが含まれているということです。

Couch にはクエリ プロセッサがありません。B-Tree インデックスを定義するために使用される (JS によって定義された) ビューがあります。

以上です。それがカウチのハンマーです。いいハンマーです。データ処理の世界では、基本的に 40 年間存続しています。

Couch でインデックスを作成するには (データ量に基づいて) 多少コストがかかるため、「一時的なビュー」は嫌われます。また、メンテナンスにもコストがかかるため、ビューはデータベース内の意識的な設計要素である必要があります。同時に、通常の SQL インデックスよりも少し強力です。

Couch の上に独自のクエリ処理を簡単に追加できますが、それは手間がかかります。最も一般的な基準または選択基準に基づいていくつかの選択ビューを作成し、独自のコード内の他の基準で結果のドキュメントをフィルター処理できます。はい、やらなければならないので、Couch が SQL ソリューションよりも (HTTP API、レプリケーション、安全で常に一貫性のあるデータストアなど) を提供すると感じる以上の価値があるかどうかを疑問視する必要があります。

于 2011-06-28T04:35:06.543 に答える