9

バケット内の大量のデータ (>100GB、>100M ドキュメント、>12 ドキュメント タイプ) を想定し、各ビューが 1 つのドキュメント タイプのみに適用されると仮定すると、バケットあたりのビューの数は多すぎますか? または別の言い方をすれば、すべてのドキュメント タイプのすべてのビューを処理するオーバーヘッドを節約するために、一部のドキュメント タイプを個別のバケットに分割する必要があるのはどの時点ですか?

データをソファベース バケットに分割する方法と、データに必要なビューのパフォーマンスへの影響を決定するのに苦労しています。私のデータは 12 を超えるリレーショナル DB で構成されており、少なくともその半分は多数のテーブルに数億行あります。

http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-writing-bestpractice.html doc セクションの「ドキュメント タイプの使用」は、同じバケットに複数のドキュメント タイプを持つことは理想的ではないことを暗示しているようです。特定のドキュメント タイプのビューは、ビューに決して一致しないものも含め、すべてのドキュメントに対して更新されます。実際、このオーバーヘッドを回避するために、データをバケットに分割することを提案しています。

ただし、パフォーマンス上の理由から、クラスターあたり 10 バケットの制限があります。したがって、私の唯一の結論は、各クラスターが最大 10 個の大規模なドキュメントのコレクションを効率的に処理できるということです。これは正確ですか？

4

2 に答える 2

14

Tug のアドバイスは的を射ていたので、私もいくつかの視点を付け加えることができました。

バケットは、RDMS の世界における "データベースのインスタンス化" に (正確ではありませんが) 最も密接に関連していると見なすことができます。その「データベース」内には複数のテーブル/スキーマがあり、それらはすべてバケット内で組み合わせることができます。

バケットは、いくつかの共通の構成パラメーター (RAM クォータ、レプリカ数など) をすべて共有するデータの論理グループと考えてください。特定のデータセットを個別に制御する必要がある場合にのみ、データを複数のバケットに分割する必要があります。その他の理由は、異なるデータセットへの非常に異なるワークロード、またはそれらのデータセットへのワークロードを個別に追跡できるようにしたいという要望に関連しています。

いくつかの例：

-あるデータ セットのキャッシュ動作を別のデータ セットとは異なる方法で制御したい。たとえば、多くの顧客は常に RAM に保存したい「セッション」バケットを持っていますが、RAM にキャッシュされたすべてのデータを必要としない、より大きな「ユーザー プロファイル」バケットを持っている場合もあります。技術的には、これらの 2 つのデータ セットを 1 つのバケットに格納し、Couchbase が RAM に保持するデータをインテリジェントに処理できるようにすることもできますが、セッション データがプッシュされないという保証や制御はあまりできません...独自のバケットでそれを強制できます。また、トラフィックを個別に監視できるという利点もあります。

-一部のデータを他のデータよりも多く複製したい。通常、ほとんどのクラスターでレプリカを 1 つだけにすることをお勧めしますが、ユーザーが特定のデータセットを選択して、さらに時間をかけてレプリケートする場合があります。これは、個別のバケットを介して制御できます。

-同じように、一部のデータのみを別のクラスター/データセンターに複製したいと考えています。これもバケットごとに制御されるため、データを別のバケットに分割できます。

-特定のデータセットへのワークロード (特に書き込み量) にかなり極端な違いがある場合、ビュー/インデックスの観点から、データを別のバケットに分離することは理にかなっています。これは本当なので言及しますが、それが一般的なケースではないことも明確にしたいと思います。このアプローチは、問題を特定した後に使用する必要があります。

この最後の点に関しては、はい、バケットへのすべての書き込みはインデックス作成エンジンによって取得されますが、JSON 内のドキュメント タイプを使用することで、特定のドキュメントの処理を非常に迅速に中止でき、実際に悪影響を与えることはありません。特定のビューには当てはまらない大量のデータが入ってきます。よろしければ、ドキュメントのどの部分がそうではないことを暗示しているのか、特に興味があります。

そのため、一般的に、ほとんどの展開ではバケット数が少なく (2 ～ 3)、5 以上の数しかありません。10 という制限は、統計の内部追跡 (負荷またはバケツにそれがなくても、ここでは問題になりません)。将来のリリースでこのオーバーヘッドを削減する予定は確かにありますが、バケットを少数にするという推奨事項は変更されません。複数の「スキーマ」を単一の論理グループに結合し、ビュー/インデックスを適用できるという利点は、依然として存在します。

私たちは現在、より具体的なガイドラインとサイジングの推奨事項を考えているところです (最初の 2 つのブログは、そうするまでの一時しのぎとして書きました)。

最初のアプローチとして、設計ドキュメントの数を 4 前後に維持することをお勧めします。これは、デフォルトで最大 4 つまで並列処理するためです。この数を増やすことはできますが、CPU とディスクの IO キャパシティを増やして一致させる必要があります。次に、各ドキュメント内のビューの数を比較的低く (おそらく 10 をはるかに下回る) 維持する必要があります。これは、各ドキュメントが順次処理されるためです。

私は最近、かなり大量のビュー (約 8 つの設計ドキュメントと 20 近くのビューを持ついくつかの DD) を持つ 1 人のユーザーと協力しました。明らかにアプリケーションに大きく依存しますが、1 つのインデックスから複数の異なる「クエリ」を生成するようにしてください。リダクション、キープレフィックス (ビュー内)、および照合を使用して、すべてを異なる範囲およびグループ化クエリと組み合わせて、最初は混雑しているように見えるかもしれませんが、実際には非常に柔軟な単一のインデックスを作成できます。

設計ドキュメントとビューが少ないほど、必要なディスク容量、IO、および CPU リソースが少なくなります。残念ながら、魔法の弾丸や厳格なガイドライン番号は決してありません. 最後に、YMMV と独自のデータセットでのテストは、私が書くことができる複数ページの応答よりも優れています ;-)

お役に立てば幸いです。公開したくない特定のユースケースについて具体的な質問がある場合は、遠慮なく直接お問い合わせください。

ペリー

于 2013-03-01T15:35:25.783 に答える
4

Couchbase のドキュメントからわかるように、正確なメンバーを提供する「普遍的な」ルールを提供することは実際には不可能です。

ただし、使用したベスト プラクティス ドキュメントといくつかのディスカッション (こちら) に基づいて、データベース/ビューを適切に設計できるはずです。

最後の質問から始めましょう。

はい、少数のバケットを持つというCouchbaseのアドバイスがパフォーマンスのためであり、さらに重要なのはリソース消費のためです。Couchbaseの「内部」で何が起こっているかを理解するのに役立つこれらのブログ投稿を読むように招待します。

したがって、ほとんどの「操作」がバケットによって行われることがわかります。

それでは、元の質問を見てみましょう。

  • はい、ほとんどの場合、設計ドキュメント/およびビューをドキュメントの種類ごとに整理します。
  • すべてのドキュメント「タイプ」を 1 つの (少数の) バケットに格納することは問題ではありません。実際、これが Couchbase での作業方法です。
  • ビューの JS コードがドキュメントを作成/変更するときにのみ実行されます。

だからあなたがすべきこと：

  • 1 個のバケツ
  • 設計図書は何枚？（何種類ありますか？）
  • 各ドキュメントにどのくらいのビューがありますか?

実際、最もコストのかかる部分は、インデックス作成またはクエリ中ではなく、ノード間でデータとインデックスのバランスを取り直す必要があるときです (追加、削除、ノードの失敗)。

最後に、すでにご存知のようですが、この章はビューの仕組み (インデックスの作成方法と使用方法) を理解するのに非常に役立ちます: http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase -views-operation.html

必要に応じて、さらに情報を追加することを躊躇しないでください。

于 2013-02-21T13:22:57.633 に答える