Cassandraの紹介といくつかの一般的な操作

Cassandraは信頼性の高い大規模な分散型ストレージシステムです.高度に伸縮性があり、一貫性があり、分散型の構造化key-valueストレージスキームであり、Google BigTableのデータモデルとAmazon Dynamoの完全な分散型のアーキテクチャを一体化しています.CassandraはGoogle BigTableのデータモデルを使用しており、ロー向けの従来のリレーショナル型データベースとは異なり、カラム向けのデータベースであり、カラムはカラムファミリー(Column Family)に組織されており、データベースにカラムを追加するのに非常に便利です.CassandraのシステムアーキテクチャはDynamoと脈々と受け継がれており、O(1)DHT(分散ハッシュテーブル)に基づく完全P 2 Pアーキテクチャであり、従来のShardingベースのデータベースクラスタに比べて、Cassandraはノードをシームレスに追加または削除することができ、ノード規模の変化が速いアプリケーションシーンに非常に適している.
Cassandraのデータは複数のノードに書き込まれ、データの信頼性を保証します.一貫性、可用性、ネットワークパーティション耐性(CAP)のトレードオフの問題では、Cassandraは比較的柔軟で、ユーザーは読み取り時にすべてのコピーの一貫性(高い一貫性)を指定することができます.1つのコピーを読めばよい(高可用性)か、選挙で多数のコピーが一致していることを確認すればよい(トレードオフ).これにより、Cassandraは、ノード、ネットワークの失効、およびマルチデータセンターのあるシーンに適用できます.Cassandraはオープンソース分散型NoSQLデータベースシステムであり、googleのBigTableのデータモデルとAmazonのDynamoの完全分散アーキテクチャを採用した設計思想を採用しているため、拡張性が高く、単一の障害が存在しない.
Hadoop HBAse Hadoop HBAseはApache Hadoopプロジェクトのサブプロジェクトであり、Google BigTableのクローンであり、Cassandraと同様にBigTableのファミリー式のデータモデルを使用している.両者の主な違いは、(1)Cassandraには1つのノードしかないが、HBAseには多くの異なる役割があり、Hadoopの下位プラットフォームの上にアーキテクチャがあり、導入はCassandraの方が簡単です.(2)Cassandraのデータ整合性ポリシーは構成可能である.(3)HBAseはCassandraにない行ロックメカニズムを提供し、Cassandraがロックを使用するにはHadoop Zookeeperなどの他のシステムに協力する必要がある.(4)HBAseはより良いMapReduce並列計算サポートを提供し、Cassandraは0.6バージョンでもこの機能を提供した.(5)Cassandraの読み書き性能と拡張性は優れているが,区間スキャンは苦手である.
NoSQLデータベースは、拡張性の高いシステムのために設計され、key/valueモデルが採用されていますが、その欠点は、NoSQLという名前が示すように、SQL操作はサポートされていません.これは深刻な欠陥のように聞こえます.SQLでよく見られる操作がcassandraで自然かつ効果的に実現される方法について説明します.
0.例column family
表1:

CREATE TABLE example (
    id int,
    name ascii,
    age bigint,
    gender bigint,
    high varint,
    PRIMARY KEY (id, name, age)
) WITH CLUSTERING ORDER BY (name ASC, age ASC)
    AND bloom_filter_fp_chance = 0.1
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 86400
    AND gc_grace_seconds = 86400
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99.0PERCENTILE';

表1の内容:

 id | name | age | gender | high
----+------+-----+--------+------
  5 |   ee |  25 |      1 |  168
  1 |   aa |  10 |      1 |  165
  2 |   bb |  20 |      0 |  170
  4 |   dd |  40 |      0 |  190
  6 |   ff |  30 |      0 |  168
  3 |   cc |  30 |      1 |  180

表2:

CREATE TABLE test (
    id int,
    name ascii,
    age bigint,
    gender bigint,
    high varint,
    PRIMARY KEY ((id, name), age)
) WITH CLUSTERING ORDER BY (age ASC)
    AND bloom_filter_fp_chance = 0.1
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 86400
    AND gc_grace_seconds = 86400
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99.0PERCENTILE';

表2の内容:

 id | name | age | gender | high
----+------+-----+--------+------
  1 |   aa |  10 |      1 |  165
  6 |   ff |  30 |      0 |  168
  4 |   dd |  40 |      0 |  190
  3 |   cc |  30 |      1 |  180
  5 |   ee |  25 |      1 |  168
  2 |   bb |  20 |      0 |  170

1.クエリー
EXampleテーブルでは、idはパーティション・プライマリ・キー、(name,age)はソート・プライマリ・キーがtestテーブル、(id,name)はパーティション・プライマリ・キー、ageはソート・プライマリ・キーがexampleテーブルであり、クエリーは次のようになります.

select * from example where id = 1;
select * from example where id = 1 and name = ''aa";
select * from example name = ''aa" allow filtering;
select * from example name > ''aa" allow filtering;
select * from example age = 30 allow filtering; ----X
select * from test where id = 3;  ---X
select * from test where age > 20 allow filtering;  

パーティション・プライマリ・キー・クエリーを使用する場合は、すべてのパーティション・プライマリ・キーを指定する必要があります.パーティション・プライマリ・キー・クエリーの一部は使用できません.ソート・プライマリ・キーの場合は、>,=,<=を使用してクエリーできます.前にパーティション・プライマリ・キーがある場合は、直接使用できます.ソート・プライマリ・キーのみを使用してクエリーする場合は、ソート・プライマリ・キーの最初のクエリーのみを使用し、allow filteringを使用します.または、ソート・プライマリ・キーの1番目、2番目を使用してクエリーを行います.つまり、ソート・プライマリ・キーは2番目、2番目を使用して3番目を使用します.しかし、これにより全表スキャンが行われ、パフォーマンスに深刻な影響を及ぼします.
2.二次索引の作成
もし私たちがexampleテーブルのageとtestテーブルのnameを直接調べたいなら?インデックスを作成する方法はあります.

CREATE INDEX ON example(age);
CREATE INDEX ON test(name);

desc exampleとdesc testで次の文を見ることができます.

desc example:
CREATE INDEX example_age_idx ON ad.example (age);
desc test:
CREATE INDEX test_name_idx ON ad.test (name);

ただし、構築された2次インデックスは=クエリーのみをサポートし、範囲クエリーはサポートしません.
3.ページングクエリ
1,2.xのapiにはページングクエリーがサポートされています.2、手動ページングクエリはtokenを使用できます.次の例ではデフォルトのソートを使用します.

cqlsh:> select * from example limit 2;

 id | name | age | gender | high
----+------+-----+--------+------
  5 |   ee |  25 |      1 |  168
  1 |   aa |  10 |      1 |  165

(2 rows)
cqlsh:> select * from example where token(id) > token(1) limit 2;

 id | name | age | gender | high
----+------+-----+--------+------
  2 |   bb |  20 |      0 |  170
  4 |   dd |  40 |      0 |  190

(2 rows)
cqlsh:> select * from example where token(id) > token(4) limit 2;

 id | name | age | gender | high
----+------+-----+--------+------
  6 |   ff |  30 |      0 |  168
  3 |   cc |  30 |      1 |  180

4.複雑なSelect
これから1つの基本的な例を考えます:1対の多関係のdepartmentとemployeeが存在します.2つのColumn Family(略称「CF」)が必要です.EmpsとDepsです.Empsでは、employee IDをkey、employeeのname、birthday、cityをcolumnとする.Depsではdepartment IDをkey,department nameをcolumnとする.クエリー:select * from Emps where Birthdate = ’25/04/1975′クエリーをサポートするために、dateがkeyであり、nameがその日に生まれたemployeeのIDであり、valueは空のbyte配列であってもよい(「-」で置き換える).Employee情報をEmpsから挿入/削除するたびに、Birthdate_を同時に更新する必要があります.Emps.このクエリを実行するには、Birthdate_からEmpsではkey’25/04/1975’に対応するすべてのcolumnが検索された.Birthdate_Empsは実際にはクエリーを迅速に実行するのに役立つインデックスであり、このインデックスは各cassandraノードに分布しているため、拡張性が高い.BirthdateでEmpsにemployee冗長情報を追加する方法はクエリー速度をさらに加速させ,このときemployeeのIDはsuper columnの名前となり,employeeのすべてのcolumnはこのsuper columnのcolumnとなる.
5.Join
クエリ:Birthdate_Emps Joinは、実際には異なるエンティティ間の連絡を確立します.このつながりは反復によって容易に表現できる.このクエリを実装するには、Dep_という名前を追加します.EmpsのCFでは、department IDがkeyであり、それに対応するemployeeのIDがnameである.
6.Group By
たとえばクエリー:select * from Emps e, Deps d where e.dep_id = d.dep_id実装の観点から見ると、GroupByは上記のselect/indexingに似ています.Cityという名前を追加するだけです.EmpsのCFは、cityをkey、employeeのIDをcolumn nameとする.クエリーを実行するときは、取得するcityに対応するemployeeの数を計算するか、columnレコードを追加するだけです.
7.Order By
ソート操作をサポートするには、OrderPreservingPartitionrを使用してkeyに従ってデータをソートできます.詳細は、「Cassandra:RandomPartitionr vs OrderPreservingPartitionr」を参照してください.
4-7のこれらの操作をサポートするために、クエリに対して冗長データを格納します.これは、(1)システムに必要なquery(インスタントクエリをサポートしない)を事前に知らなければならないことを意味します.幸いなことに、典型的なウェブアプリケーションと企業OLT Pアプリケーションのクエリーはすべて事前に知っていて、しかも数が多くなくて、よく変更しないで、具体的にこの論文を読むことができます:The End of an Architectural Era(2)私たちは圧力をクエリーから更新に移して、これは物化ビューをサポートするためです(クエリー結果を事前に計算します).これは、Cassandraの更新操作が最適化されているため(最終的な一貫性とgoogleのBigTableから参考にした「log-structured」ストレージコンセプトのおかげで)、pull-on-demandモデルよりもcassandraの使用シーンがpush-on-changeモデルに適しているため、Cassandraにとって非常に有意義である.pull-on-demandとpush-on-changeモデルについては、記事Why are Facebook、Digg、and Twitter so hard to scale?
参考記事

董のブログ:CassandraでSQL操作を実現