emit(key, doc)を実行すると、インデックスの構築にかかる時間が長くなるという言及に出くわしました（またはその効果の何か）。
emit(key, null)それに何かメリットはありますか? また、常にand thenを実行しない理由はありますinclude_docs = trueか?
質問する
6096 次
2 に答える
23
はい。その場合、CouchDBはドキュメント全体を効果的にコピーするため、インデックスのサイズが大きくなります。可能な場合は、を使用してくださいinclude_docs=true。
ただし、これを使用する場合は、wikiに記載されている競合状態に注意する必要があります。ビューデータの読み取りからドキュメントのフェッチまでの間に、そのドキュメントが変更された（または削除された場合は削除さ_deletedれるtrue）可能性があります。これは、ここの「クエリオプション」に記載されています。
于 2009-09-26T03:18:58.267 に答える
4
これは、古典的な時間と空間のトレードオフです。
ドキュメント データをインデックスに出力すると、ディスク上のインデックス ファイルのサイズが大きくなります。これは、CouchDB が出力されたデータを直接インデックス ファイルに含めるためです。ただし、これは、データをクエリするときに、CouchDB がディスク上のインデックス ファイルからコンテンツを直接ストリーミングできることを意味します。これは明らかに非常に高速です。
代わりに依存するinclude_docs=trueと、ディスク上のインデックスのサイズが減少します。これは本当です。ただし、クエリを実行すると、CouchDB は返された行ごとにドキュメントの読み取りを実行する必要があります。これには、基本的にメイン データ ファイルからのランダムなドキュメント ルックアップが含まれます。つまり、データを返すコストと時間が大幅に増加します。
少数のドキュメントのクエリ時間の差は遅くなりますが、アプリケーションによって行われる呼び出しごとに加算されます。したがって、私にとっては、ドキュメントからインデックスに必要なフィールドを発行することは、通常、適切な呼び出しです。ディスクは安価であり、ユーザーの注意はあまり広がりません。これは、リレーショナル データベースでカバリング インデックスを使用する場合とほぼ同じで、広く反響を呼んでいるもう 1 つのアドバイスです。
私はこれについて全く非科学的なテストを行い、違いが何であるかを感じました. include_docs=trueビューから 100,000 個のドキュメントを読み取るために使用すると、ドキュメントがインデックス自体に直接出力されるビューと比較して、応答時間が約 8 倍増加し、CPU が 50% 増加することがわかりました。
于 2017-02-04T19:27:55.643 に答える