5

私は最近、ドキュメントベースのデータベースとキーバリューストアについて少し読んでいます (ドキュメントベースとキー/バリューベースのデータベースの違いについての概要はこちらです? ) 。 .

キー (または追加のインデックス) を使用してこれらのいずれかをクエリする場合、メカニズムに実際の違いはなく、値を取得します。インデックス化されていないドキュメント/フィールドをクエリするときに、ドキュメント ストアがキー値ストアとどのように異なるかについては明確ではありません。キーと値のストアの上にドキュメント ストアを実装する場合、クエリで適切な値を取得するために「テーブル スキャン」(すべてのキーと値のペアをチェック) を実行します。カバー？ドキュメント データ ストアをこのように考えるのは適切でしょうか。

これは、基礎となるテクノロジーを理解することを目的としたものというよりも、実用的な質問ではありません (何か有用なことを行う必要がある場合、BDB で Mongo を使用する可能性が最も高いでしょう)。特定のシステムのスケーリングの側面に興味があるのは、それらが基礎となる実装に適用できる場合のみです。

4

3 に答える 3

0

それらはすべて BTree とハッシュ インデックスを使用して、特定のクエリを高速化します。キー値ストアは基本的に、エンジンに応じて単一の値 (選択および範囲クエリを許可) または複合値と見なされるキーにアクセスするだけです。

ドキュメントベースのエンジンは、ドキュメント内の要素パスのサポートを追加します (または、概念的に呼ばれるものは何でも)。基本的に、キー値からドキュメント {key, value} を作成することで、キー値ストアをエミュレートできます。キー構造を使用してドキュメントのクエリのみを使用する場合、基本的に同じ結果が得られ、ルックアップに関して同様の最適化が行われます。

mongoDB の内部に関する情報を見つけるには、サイトを使用して内部を検索します ( https://www.mongodb.com/search?search=internals )。たくさんの情報が見つかります。

于 2015-07-05T11:26:08.893 に答える
-3

スケーラビリティに関心があるということは、設計上の使用シナリオを慎重に検討する必要があることを意味します。基盤となる実装がキーベースかドキュメント指向かにかかわらず、スケーラブルな NonSQL デプロイメントを考慮に入れる必要がある複数の変数があります。短いリストは次のとおりです。

考慮すべき側面:

-書き込み操作と読み取り操作の頻度

-データ分析の必要性

-高可用性のためのデータ冗長性

-データ複製/同期

- 多くの一時的なデータが必要

・データサイズ

-クラウド対応

一部の非 SQL 実装では、これらの側面を他の側面よりも個別に促進しています。

シナリオ:

- Web ヒット カウンターやロギング デバイスからのデータなど、頻繁に書き込まれ、めったに読み取られないデータ: Redis | モンゴDB

-頻繁に読み取り、めったに書き込み/更新しない:一時的なデータ キャッシング用のMemcached 、 Cassandra | 検索用のHBase 、データ分析用のHadoopとHive

-最小限のダウンタイムを必要とする高可用性アプリケーションは、クラスター化された冗長データ ストアでうまく機能します。カサンドラ

-複数の場所にまたがるデータ同期: CouchDB

- 一時的なデータ (Web セッションとキャッシュ) は、一時的なキーと値のデータ ストアでうまく機能します: Memcached

-ビジネスまたは Web 分析から生じるビッグ データで、明確なスキーマに従わない可能性がある: Hadoop

結論：

私見では、基本的な側面とそれらの違いではなく、使用シナリオから始めてスケーラブルなデータストアを選択するという問題に焦点を当てる必要があります。

また、キーベースとドキュメント指向という 2 つの世界を見事に組み合わせたCouchbaseを確認することをお勧めします。

于 2011-07-08T20:54:54.847 に答える