0

数百GBのCouchDBデータベースがいくつかあり、複数のデータベースに依存する方法でドキュメントを取得する必要があります。たとえば、（擬似コード、プレフィックスはドキュメントの元のデータベースを示します）。

for each Db1_Document in Db1
    if Db1_Document has field "Db2_match"
        Db2_Document = Db1_Document.Db2_match
        for each Db2_Reference in Db2_Document.references
            if Db2_Reference has empty field "Db1_match"
                add Db2_Reference to List bigList
        emit [Db2_Document, bigList]

複雑な（そしてハッキーな）ビューのセットでこれを行うことができます。または、必要なドキュメントを一括HTTPフェッチして、Javaで処理することもできます。

ビューを作成する場合と比較して、バルクHTTPフェッチはどのくらいの費用がかかりますか？CouchDBがビューチェーンの理由をネイティブにサポートしていないという事実は、ビューソリューションを回避するのに十分ですか？

これは、効率が非常に優先されるアプリケーションです。

4

2 に答える 2

1

ビューの作成は、特にインスタンス内のすべてのドキュメントに影響するため、Couch で I/O と CPU を集中的に使用します。

ロジックがすべてのドキュメントに影響する場合は、ビューを作成することが最も効率的なメカニズムになる可能性があります。この処理に必要なサブセット (またはサブセットのスーパーセットですが、DB 全体よりも少ない) を提供するかなり粗いビューが既にある場合は、必要なサブセットをまとめて取得し、ローカルで処理する方がよいでしょう。 .

于 2012-07-16T18:32:58.710 に答える
1

フィルタリングされたレプリケーションを使用して、他の DB から別の DB にすべての情報をプルする新しい DB を作成する方が簡単/優れている場合があります。次に、その他の DB に対してクエリを実行します。データは少し古くなりますが、関連するすべてのデータを 1 つの DB に格納する利点により、関連するすべてのドキュメントを表示するビューを作成できます。したがって、そのビューは、複製ステップから新しいドキュメントが到着すると、インデックスが作成され、段階的に更新されます。

これにより、すべての世界で最高のものが提供されます。

  • 理にかなった見解を書くことができるようになります。
  • 必要なデータのみを Java コードに取り込みます。
  • ビューにはインデックスが作成され、レプリケーションから新しいデータが到着すると増分的に更新されるため、実行時のパフォーマンスの利点は引き続き得られます。
于 2012-07-16T21:11:25.270 に答える