web-dev-qa-db-ja.com

列指向のNoSQLはドキュメント指向とどのように違いますか？

私が読んだ3種類のNoSQLデータベースは、キーバリュー、カラム指向、ドキュメント指向です。

Key-Valueは非常に単純です-単純な値を持つキーです。

キー指向のように記述されたドキュメント指向のデータベースを見てきましたが、その値はJSONオブジェクトのような構造になる可能性があります。各「ドキュメント」には、他のキーと同じキーをすべて、いくつか、またはまったく持たないことができます。

列指向は、構造を指定しないという点でドキュメント指向に非常に似ているようです。

それでは、これら2つの違いは何ですか？また、なぜ一方を他方よりも使用するのでしょうか？

私は特にMongoDBとCassandraに注目しました。基本的に、変更できるが他の値には影響しない動的構造が必要です。同時に、特定のキーを検索/フィルタリングし、レポートを実行できるようにする必要があります。 CAPでは、APが私にとって最も重要です。データは、競合またはデータの損失がない限り、「最終的に」ノード間で同期できます。各ユーザーは、独自の「テーブル」を取得します。

mongodbcassandranosql
74
Luke

Cassandraでは、各行（キーでアドレス指定）に1つ以上の「列」が含まれています。列自体はキーと値のペアです。列名を事前に定義する必要はありません。つまり、構造は固定されていません。行の列は、キー（名前）に従ってソートされた順序で格納されます。

場合によっては、行に非常に多くの列がある場合があります（たとえば、特定の種類のクエリを有効にするためのインデックスとして機能するため）。 Cassandraはこのような大きな構造を効率的に処理でき、特定の範囲の列を取得できます。

列にネストされた（サブ）列が含まれるスーパー列と呼ばれる、さらに一般的なレベルの構造（それほど一般的には使用されません）があります。

全体の構造は、2レベルまたは3レベルのキーを持つネストされたハッシュテーブル/辞書と考えることができます。

通常の列ファミリ：

row
    col  col  col ...
    val  val  val ...

スーパーカラムファミリー：

row
      supercol                      supercol                     ...
          (sub)col  (sub)col  ...       (sub)col  (sub)col  ...
           val       val      ...        val       val      ...

また、データを分割またはグループ化するために使用できる、より高いレベルの構造（列ファミリとキースペース）もあります。

この質問も参照してください： Cassandra：サブカラムとは

または http://wiki.Apache.org/cassandra/ArticlesAndPresentations からのデータモデリングリンク

再：ドキュメント指向データベースとの比較-後者は通常、ドキュメント全体（通常JSON）を挿入しますが、Cassandraでは、個々の列またはスーパー列をアドレス指定し、これらを個別に更新できます。異なるレベルの粒度：各列には、独自のタイムスタンプ/バージョンがあります（分散クラスター全体で更新を調整するために使用されます）。

Cassandra列の値は単なるバイトですが、ASCII、UTF8テキスト、数字、日付などとして入力できます。

もちろん、JSONを含む列を挿入することで、Cassandraをプリミティブドキュメントストアとして使用できますが、実際のドキュメント指向ストアのすべての機能を取得することはできません。

33
DNA

主な違いは、ドキュメントストア（MongoDBやCouchDBなど）では、任意の複雑なドキュメント（サブドキュメント内のサブドキュメント、ドキュメント付きリストなど）を許可するのに対して、列ストア（Cassandra and HBase）では、固定形式、たとえば、厳密な1レベルまたは2レベルの辞書。

44
Theo

「挿入」では、rdbms単語を使用するために、ドキュメントベースの方が一貫性があり、まっすぐです。次のことに注意してくださいcassandraクォーラムの概念との整合性を実現できますが、すべての列ベースのシステムに適用されるわけではなく、可用性が低下します。 、MongoDBに行きます。また、オブジェクトの構造全体を常に読み取る場合は、ドキュメントベースのシステムがドキュメントを取得したときにドキュメント全体を返すように設計されており、行全体の一部を返すのにあまり強くありません。

Cassandraなどの列ベースのシステムは、「更新」で文書ベースよりもはるかに優れています。列を含む行を読み取らなくても列の値を変更できます。書き込みはしません。実際には同じサーバーで行う必要があり、複数のサーバーの複数のファイルに行が含まれる場合があります。巨大な高速データシステムでは、Cassandraを使用します。また、キーごとに非常に大きなデータチャンクがある場合は、各クエリですべてを読み込む必要はありません。「select」では、Cassandra必要な列のみを読み込むことができます。

また、Mongo DBはC++で記述されており、2番目のメジャーリリースであるが、CassandraはJVMで実行する必要があり、最初のメジャーリリースは昨日からのみリリース候補に含まれている0.Xリリースはすでに大手企業のプロダクションに組み込まれています）。

一方、Cassandraの設計は、部分的にAmazon Dynamoに基づいており、高可用性ソリューションとなるように中核に構築されていますが、列ベースの形式とは関係ありません。 MongoDBもスケールアウトしますが、Cassandraほど優雅ではありません。

23
user327961