私が理解している限り、CouchDB インデックスは、ビューがクエリされると更新されます。書き込みよりも読み取りの方が多いと仮定すると、これはスケーリングにとって悪いことではありませんか? 書き込み時にインデックスを更新するように CouchDB を構成するにはどうすればよいでしょうか。
3 に答える
CouchDB は更新時にビューを再生成しますが、ビューへの最後の読み取りアクセス以降に変更されたものに対してのみです。読み取り量が書き込み量を大幅に上回っていると仮定すると、これは問題になりません。
一度に多数のドキュメントを変更する場合、最初の読み取り要求にかなりの時間がかかる可能性があります。これを軽減するために、いくつかの異なる可能性が提案されています。ほとんどは、CouchDB の更新通知への登録と読み取りの自動トリガーに依存しています。
これを正確に実行するためのサンプル スクリプトは、[1] の CouchDB wiki で入手できます。
[1] http://wiki.apache.org/couchdb/RegeneratingViewsOnUpdate
a)「スケーリング」は、そのようなオーバーロードされた用語です。どの「種類」のスケーリングについて言及していますか? (いずれにせよ、それがあなたにどのように悪影響を与えるかわかりません)。
b) 書き込みの更新: 書き込み後にビューをクエリするだけです。一連のデータをインデックスに追加すると、リソースが使いやすくなることに注意してください (CouchDB に固有のものではありません)。したがって、N回の書き込みごとにビューをトリガーしたい場合があります。
c) スケジュール: M 分ごとにビューをクエリする cronjob を設定します。
d) CouchDB が進化して、構成パラメーターを使用してこれをセットアップできるインフラストラクチャーを提供するまで待ちます。
e) (最良の選択肢)。手を汚して、私たちが CouchDB を磨くのを手伝ってください! どんな貢献も高く評価されます。
d) RTFM (点滅:)
できませんし、なぜそれが必要なのですか?
次のように考えてください。
- データを MySQL にインポートするときは、1 回の実行で 100 回の書き込み (またはインポートする行数) のインデックスを更新するよりも、挿入するすべての行のインデックスを更新する方がコストがかかるため、インデックスを無効にすることができます。
- これが、CouchDB が読み取り時にインデックスを更新する理由です。これらの 100 個の変更を同時に統合し、書き込み時にそれぞれの変更を統合する方がコストがかからないからです。
これは、CouchDB の利点の 1 つです。:) これが CouchDB のみの機能であると言っているわけではありませんが、読み取り時にこれを行うのが賢明です。
できることの 1 つは、update=false を指定して読み取ることです。これはダーティ リードであり、期待どおりに返されない可能性があります。常にこれを行う場合は、cronjob を介して「通常の」読み取りをスケジュールし、それでインデックスを更新できます。意味がないと思います。