web-dev-qa-db-ja.com

なぜ多くの人がCassandra=を列指向データベースとして参照しているのですか？

インターネット上のいくつかの論文や文書を読んで、Cassandra=データモデルに関する多くの矛盾した情報を見つけました。列指向のデータベース、行指向のデータベース、両方のハイブリッドな方法として。

Cassandra=ファイルを保存する方法について知っていることによれば、それは* -Index.dbファイルを使用して、ブルームフィルターが保存されている* -Data.dbファイルの正しい位置にアクセスします、列インデックス、次に必要な行の列。

私の意見では、これは厳密に行指向です。何か足りないものはありますか？

cassandranosqldata-modelingcolumn-oriented
47
cesare

はい、「列指向」の用語は少しわかりにくいです。

Cassandraのモデルでは、行に列が含まれます。データの最小単位（列）にアクセスするには、最初に行名（キー）、次に列名を指定する必要があります。

したがって、Fruitというcolumnfamilyには、次の例のような構造（2行）があります。フルーツタイプは行キーで、列にはそれぞれ名前と値があります。

Apple -> colour  weight  price variety
         "red"   100     40    "Cox"

orange -> colour    weight  price  Origin
          "orange"  120     50     "Spain"

テーブルベースのリレーショナルデータベースとの違いの1つは、いつでも列を省略したり（オレンジに多様性がない）、任意の列を追加したりできる（オレンジにOriginがある）ことです。上記のデータは、多くの値が空である可能性のあるまばらなものではありますが、依然としてテーブルとして想像できます。

ただし、「列指向」モデルは、すべての列名が一意であるリストおよび時系列にも使用できます（そして、ここでは1行しかありませんが、数千または数百万の列を持つことができます）。

temperature ->  2012-09-01  2012-09-02  2012-09-03 ...
                40          41          39         ...

これは、時系列のエントリをrowsではなくcolumnsとしてモデル化する必要があるリレーショナルモデルとはまったく異なります。このタイプの使用法は、多くの場合「ワイド行」と呼ばれます。

52
DNA

Cassandraはパーティション化された行ストアです。行は、必要な主キーを持つテーブルに編成されます。

パーティション化とは、Cassandraがアプリケーション透過的な問題でデータを複数のマシンに分散できることを意味します。 Cassandraは、クラスターにマシンが追加および削除されると自動的に再パーティション化されます。

行ストアとは、リレーショナルデータベースと同様に、Cassandraが行と列でデータを整理することを意味します。

  • 列指向または列状のデータベースは、列単位でディスクに保存されます。

    e.g：Table Bonuses table

     ID         Last    First   Bonus
 1          Doe     John    8000
 2          Smith   Jane    4000
 3          Beck    Sam     1000

  • row-orientedデータベース管理システムでは、データは次のように保存されます：1,Doe,John,8000;2,Smith,Jane,4000;3,Beck,Sam,1000;

  • column-orientedデータベース管理システムでは、データは次のように保存されます。
    1,2,3;Doe,Smith,Beck;John,Jane,Sam;8000,4000,1000;

  • Cassandraは基本的にcolumn-familyストアです

  • Cassandraは、上記のデータを"Bounses" : { row1 : { "ID":1, "Last":"Doe", "First":"John", "Bonus":8000}, row2 : { "ID":2, "Last":"Smith", "First":"Jane", "Bonus":4000} ... }として保存します
  • 詳細については、 this を参照してください。

お役に立てれば。

42
tharindu_DG

あなたは両方とも良い点を指摘し、それは混乱を招く可能性があります。例では

Apple -> colour  weight  price variety
         "red"   100     40    "Cox"

Appleはキー値であり、列は4つのデータ項目すべてを含むデータです。説明したところから、4つのデータ項目すべてが単一のオブジェクトとして一緒に保存され、アプリケーションによって解析されて必要な値だけが取り出されるように思えます。したがって、IOの観点から、オブジェクト全体を読み取る必要があります。これは本質的に行ベース（またはオブジェクトベース）であり、列ベースではありません。

列ベースのストレージは、完全なテーブルスキャン（DW）では極端な圧縮と削減IOを提供しますが、IO for = OLTPすべての列をプルする必要がある場合（*を選択）。ほとんどのクエリはすべての列を必要とせず、圧縮によりIOほんの数列のテーブルスキャン。例を挙げましょう

Apple -> colour  weight  price variety
         "red"   100     40    "Cox"

grape -> colour  weight  price variety
         "red"   100     40    "Cox"

2つの異なる果物がありますが、両方とも色=赤です。重量、価格、多様性とは別のディスクページ（ブロック）に色を保存し、保存されるのは色だけである場合、ページを圧縮すると、重複排除が非常に多いため、極端な圧縮を実現できます。 1ページに100行（仮に）を保存する代わりに、10,000色を保存できます。今、すべてを赤で読むと、1 IOの数千のIOの代わりになります。これは、倉庫保管と分析には本当に良いですが、OLTP if行には数百の列があり、単一の更新（または挿入）には数百のIOが必要になる可能性があるため、行全体を更新する必要があります。

私がこのコラムナーベースとは呼ばない何かを逃さない限り、オブジェクトベースと呼びます。オブジェクトがディスク上でどのように配置されているのかはまだ明らかではありません。複数のオブジェクトが同じディスクページに配置されていますか？同じメタデータを持つオブジェクトを確実に連携させる方法はありますか？あるメタデータまたはxml、またはオブジェクト自体に保存するものは何でも、ある果物が別の果物と異なるデータを含む可能性があるという点で、特定の一致する果物タイプを一緒に保存して効率を高める方法はありますか？

ラリー

11
user2615236

列ファミリは、列指向であることを意味しません。 Cassandraは列ファミリーですが、列指向ではありません。すべての列ファミリーとともに行を格納します。

Hbaseは列ファミリであり、列ファミリ形式で列ファミリを格納します。異なる列ファミリはノードに個別に保存されますが、異なるノードに存在することもできます。

5
SASANKA GHOSH

私が遭遇した最も明確な用語は、wide-column storeです。

これは、2次元のキーと値のストアの一種で、行キーと列キーを使用してデータにアクセスします。

このモデルとリレーショナルモデル（行指向と列指向の両方）との主な違いは、列情報がデータの一部であるということです。

これは、データがsparseであることを意味します。つまり、異なる行が同じ列名や列数を共有する必要はありません。これにより、半構造化データまたはスキーマのないテーブルが可能になります。

ワイド列ストアは、無制限の数の列を保持できるテーブルであり、したがって幅が広いと考えることができます。

これをバックアップするためのリンクがいくつかあります。

5
Jens