Cassandraチュートリアル(四):CQL要点整理

本文は詳しいCQLチュートリアルではなく、CQLのいくつかの要点だけを記録します.
Keyspace
keyspaceはリレーショナル・データベースのdatabaseの概念に似ており、Cassandraのkeyspaceはネーミング・スペースであり、データ・バックアップの方法を定義しています.例えば、keyspace cyclingのすべてのtableは、データセンターdatacenter 1に3つのreplicasが存在する.

CREATE KEYSPACE IF NOT EXISTS cycling WITH REPLICATION = { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3 };

Table
tableを作成する文は、SQLと似ています.

CREATE TABLE cycling.cyclist_alt_stats ( id UUID PRIMARY KEY, lastname text, birthday timestamp, nationality text, weight text, height text );

いくつかのコアコンセプト:
Primary Key
primary keyは、table内の1行のデータを一意にタグするために使用され、table内のデータの位置と順序を定義し、primary keyが定義されると、その後は変更できません.primary keyは、(part 1,part 2)として表すことができる2つの部分を含み、part 1はpartition keyであり、データを決定するpartitionであり、partition 2はオプション部分であり、clustering keyであり、partition内部でのデータの順序を決定するために使用され、clustering keyは選択可能であり、partition keyは必須部分である.
Simple Primary Key
primary keyには1つのcolumnしか含まれていません.このcolumnはpartition keyであり、clustering keyはありません.この場合、データの読み書きが早いのでおすすめです.
Composite Partition Key
partition keyが複数のcolumnsを含む場合、Composite Partition Keyと呼ばれます.このようなパーティションキーは、データを複数に分割することができ、Cassandraにおけるホットな問題や、単一ノードに大量のデータが書き込まれる問題を解決することができる.ただし、この場合、データを読み込む場合は、partition keyのcolumnsをすべて指定する必要があります.
Compound Primary Key
partition keyとcluster keyが同時に含まれています.cluster keyはノード内のデータのソートに使用され、cluster keyを指定すると、データをすばやく読み取ることができます.
Counter Table
counterは特殊なcolumnで、増加または減少する整数しか格納されていません.counter tableにはprimary keyとcounter columnの2つの部分しか含まれていないことに注意してください.例を次に示します.

CREATE TABLE popular_count (  id UUID PRIMARY KEY,  popularity counter  );

また、counter tableのcounter column値の書き込みは通常のcolumnとは異なり、counter columnはinsertメソッドではなくupdateメソッドを使用する必要があります.たとえば、次の文の最初の後、popularityの値は1に等しくなります.

UPDATE popular_count
 SET popularity = popularity + 1
 WHERE id = 6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47;

マテリアライズドビュー
Cassandraもmaterialized viewを提供しています.Cassandraのmaterialized viewは、実は別のテーブルのデータに基づいて作成された新しいテーブルで、新しいテーブルは元のテーブルとは異なるprimay keyと属性を持っています.Cassandraでは、データモデルはqueryによって駆動され(相対的に、リレーショナル・データベースはエンティティ・リレーショナルによって駆動される)、標準的な方法はqueryのためにテーブルを作成し、異なるqueryがあれば異なるテーブルを作成する必要があるが、この場合はデータのメンテナンスに困難を増大させ、複数のテーブルの更新を維持するために適用する必要がある.materialized viewはこの問題を解決し、ソーステーブルが更新されるとmaterialized viewのデータが自動的に更新されます.
マテリアライズド・ビューにはいくつかの要件があります.

ソーステーブルのprimary keyは、物体化ビューのprimary keyの一部である必要があります.

マテリアライズドビューのprimary keyは、新しい列を1つしか追加できません.static columnではありません.

また、マテリアライズド・ビューには次のような影響もあります.

は、通常のテーブルに及ばないパフォーマンスを書き込みます.

ソーステーブルの書き込み操作性能が悪くなります.

物化ビューのデータには遅延がある.なぜなら、ユーザーはソーステーブルにデータを書き込み、次に非同期で物体化ビューに書き込むしかないからです.

二次索引
primary keyは1級インデックスであるため、インデックスは2級インデックスとも呼ばれ、1級インデックスの検索を支援します.2次インデックスは、partition keyを使用することなく、通常のcolumnsを使用してデータにアクセスし、迅速かつ効率的なクエリーデータを提供します.2次インデックスは、インデックス列を個別の非表示のテーブルに格納し、インデックス列をprimary keyとし、ソーステーブルのprimary keyを新しいテーブルの値とします.ただし、2次インデックスには適用シーンがあり、使用に適していないシーンもあります.
適用シーン:テーブル内の多くのローが同じindexed valueを持つ場合に適しており、インデックス列の値が多ければ多いほど、メンテナンスとクエリーのコストが高くなります.
シーンは適用されません:

high-cardinality列.この列には多くの異なる値があります.この場合、多くの値がクエリーされますが、その一部しか結果として取得されません.この場合、マテリアライズドビューを使用できます.もう1つの極端、例えばブール値は、区別度が小さすぎて、適切ではありません.

counter column.

頻繁に更新/削除されるカラム.

複数のpartitionからデータを取得する場合、この場合、複数のpartitionに関し、クラスタが大きくなるにつれて、ますます遅くなる可能性があります.

Insert/Update
INSERTおよびUPDATEオペレーションは、IF従属文を使用する場合、lightweight transactions(Compare and Set(CAS))をサポートします.Lightweight transactionsは、より大きな遅延をもたらすため、慎重に使用する必要があります.
Time-To-Live(TTL)
columns/tableはTTLをサポートします.データが期限切れになるとtombstoneとマークされます.
Batch Insert/Update
バッチinsert/updateは原子操作です.単一partitionのロット操作は自動的に原子性を保証し,マルチpartitionのロット操作に関しbatchlogを用いて原子性を保証する必要がある.同時に、一括操作はネットワーク伝送を低減し、性能を向上させることができる.
バッチ操作を使用する重要な考慮事項は、一連の操作が原子性を保証する必要があることである.単一パーティションの一括操作は、サーバ側で一度に完了します.マルチパーティションに関連する一括操作は、パフォーマンスの問題をもたらすことが多く、慎重に使用する必要があります.一括操作の場合、coordinatorノードはすべての書き込み操作を管理し、coordinatorノードはボトルネックになりやすい.
性能のために一括操作を盲目的に使用することはできないことに注意してください.
Query
Where条件でpartition keyとcluster keyが生成した結果は、連続した結果セットでなければなりません.たとえば、テーブルのprimaryが(cola,colB,colC)である場合、where条件cola=XXX and colC=XXXはエラーを報告します.
ORDER BY句を使用して結果セットの順序を指定できます.partition keyはwhere句で指定する必要があります.order by句はcluster keyを指定してソートする必要があります.
まとめ
CassandraがHbaseなどに比べて使いやすい重要な原因の一つはSQLのようなCQLを提供していることですが、CQLを使うときには、CQLはSQLではなく、Cassandraの原理と関係型データベースが異なり、CQLもSQLとは異なり、SQLの経験だけを持ってくると、思わぬ問題がたくさんあることがわかります.本文はただいくつかのCQLの要点の記録で、完全なCQLチュートリアルではありませんて、公式サイトのシステムを参考にして学ぶことができます.
次はSparkでCassandraを使う方法についてお話しします.