Cassandra 1.2 から 2.0 へ

株式会社 INTHEFOREST

自己紹介

冨田 和孝 (@railute)

肩書き： 株式会社ＩＮＴＨＥＦＯＲＥＳＴ 代表取締役社長 Cassandra商用サポート、Cassandraコンサルティング他 Cassandra勉強会主宰 ２か月に一度程度開催。現在、第25回まで開催。 職種：本職はＤＢ・インフラ系エンジニア 以前、某レストランサーチのＤＢＡ 高負荷・大容量・大規模のOracleRACとPostgreSQLと MySQLに苦しめられ続けた経験あり。

Agenda Cassandra基礎知識 Cassandraの歴史 Cassandraの新機能

CQL3 Virtual Node Request Trace Atomic Batch JBOD Disk Failure Policy CQL3 Native Protocol

Cassandra2.0に向けて トリガー 集約関数 Streaming及びrepairの改良 Counterの改良

Cassandraの基礎知識

Cassandraのノードはレプリカとコンシステントハッシングによるデータ配置でデータ保全性を担保する。

ノード1

ノード2

ノード3

ノード4

ノード5

ノード6

• 各ノードはP2Pで稼働 • データ配置はコンシステントハッシング • データの複製で保全性を担保

α

α

α’

α”

Cassandraの歴史

0.8 0.7 1.0 1.1 1.2

• 動的スキーマ変更 • セカンダリ・インデックス

• CQL • Counter

• Compression • Leveled-compaction

• Row Leveｌ isolation

2.0

CQL3 変わるデータ構造（CQL2）

cqlsh & cql

create keyspace CassandraBenchmark

with strategy_class = ‘SampleStrategy'

and strategy_options:replication_factor=3;

use CassandraBenchmark;

CREATE COLUMNFAMILY CBench (

KEY text PRIMARY KEY,

cbid int

);

CREATE INDEX cbid_idx ON CBench (cbid);

CassandraBenchmark

CBench

Key cbid：000001

textdata：xxxxxxxxxxxx

Key cbid：000002

textdata：xxxxxxxxxxxx

Key cbid：000003

textdata：xxxxxxxxxxxx

SELECT * FROM Cbench WHERE KEY = ‘10000’; INSERT INTO (KEY,cbid,textdata) VALUES (‘10000’,‘000001’,’xxxxxxx’);

thriftAPIのラッパー構造

CQL3 変わるデータ構造（CQL3）

cqlsh & cql

CREATE KEYSPACE CassandraBenchmark

WITH replication = {

'class': 'SimpleStrategy',

'replication_factor': '3'

};

use CassandraBenchmark;

CREATE TABLE CBench (

cbid int PRIMARY KEY,

textdata text

);

SELECT * FROM Cbench WHERE cbid = ‘10000’; INSERT INTO (cbid,textdata) VALUES (‘000001’,’xxxxxxx’);

APIを一から作り直し

CassandraBenchmark

cbid textdata

0001 xxxxxx

0002 xxxxxx

0003 xxxxxx

CBench

※複合KEYもサポートされた

Virtual Node

Cassandraのノードは一つのリングに対して データを請け負う範囲を一つ設定する

ノード1

ノード2

ノード3

ノード4

ノード5

ノード6

リング一周 0 ～ 2^127

リング一周の 0 ～ 2^127 の数値の 各ノードに一つ割り当て

割り当てた数値から次のノードの数値まで そのノードのデータ範囲を割り振れる

※1.2になってからデフォルトのリングの 一周の範囲が 0 ～ 2^127 から 変更されているので注意

Virtual Node

Virtual Nodeの場合ランダムで請け負うデータ範囲が 複数持つ事になるので、データ範囲の設定が不要に

ノード1 ノード3

ノード2

ノード3

ノード1

ノード2

ノード1

ノード3

ノード2

ノード2 ノード1

ノード2

ノード3

ノード1

ノード1

ノード3

ノード3

ノード2

ノード３つでそれぞれ ６つのデータ範囲を持たせた場合

ノード１

ノード２

ノード３

一つのノードのトークンの数を増やせば増やすほど 比較的、平均に負荷分散が行える

Virtual Node また、Virtual Nodeの場合ノード追加の際は Cassandraの特性上、追加ノードへ割り当てられたデータが 別のノードから転送されます

ノード3

ノード2

ノード3

ノード2

ノード3

ノード2

ノード2

ノード2

ノード3

ノード3

ノード3

ノード2

ノード1 ノード3

ノード2

ノード3

ノード1

ノード2

ノード1

ノード3

ノード2

ノード2 ノード1

ノード2

ノード3

ノード1

ノード1

ノード3

ノード3

ノード2

複数データを請け負う範囲を持つ事で、本来１ノードから転送される所を 複数のノードに分散でき、負荷も分散されます（ノード取り外しも負荷分散される）

Request Trace

Request Trace を行った結果はキースペースsystem_traceのテーブル sessions, events に溜まる

CQL3ではRequest Traceの機能が追加 tracing on と実行するとこの機能が使用できる

Atomic Batch

一塊のInsert, Update, Delete を一度に実行する事が出来る

Begin batch Insert into log (name, date, value) values (‘test1’, 2013220, ‘log1’) Insert into log (name, date, value) values (‘test2’, 2013220, ‘log2’) Insert into log (name, date, value) values (‘test3’, 2013220, ‘log3’) Insert into log (name, date, value) values (‘test4’, 2013220, ‘log4’) Apply batch;

Atomic Batch

cassandra

cassandra

cassandra cassandra

cassandra cassandra

cassandra cassandra

Begin batch Insert into … Insert into … Apply batch

バッチ内容をsystem.batchlogに書き込み その後バッチが実行される

×

× ×

System.batchlogにバッチ内容が書き込まれているので 関係あるノードが全てDownしても復帰後に 更新作業が行われる

バッチ実行最中にDown

実行ノードがダウンしてもバッチは継続して実行される。

JBOD

同一カラムファミリを複数のディスクに分散してストアすることが可能になった。

data1

data2

data3

CF:ABC × ×

HDD

HDD

HDD

+

+

Disk Failure Policy

Cassandra1.1 まではディスク障害時の挙動は決められていた

Cassandra 1.2からは・・・

３種類のいずれかを設定する事が出来る

stop ： ディスク障害時、プロセスはダウンしないがgossipとThriftは行われない best_effort ： ディスク障害時、gossip、thriftは止めず動作し続けるが、問題あるディレクトリの 書込みは止まる、読込みも出来ない場合は読込みも止まるが 出来る場合は読込みは通常に行われる ignore ： 単にリクエストがエラーになる

CQL3 Native Protocol

現在Cassandra内ではサーバー・クライアント間の通信に Apache Thrift が使用されている

cqlsh CQL3

Cassandra

Thrift Thrift

CQL3

CQLのクエリは Thriftを使用していた

1.2は新しくCQL3用の Protocolが追加された

・ノード間のスキーマ反映が高速に

・複数のリクエストを同時に処理する事ができるように

・送信データは圧縮する事が可能に

Cassandra 2.0

サーバーサイドの各テーブルにトリガーを設置可能とする 構造はまだ議論中であるがRDBMSでいうところのアフタートリガーに近い動きになる模様

トリガー

集約関数

サーバーサイド側にSUMのような集約関数を実装可能にする。

Cassandra 2.0

既存のCassandra無いで非常に負荷が高く運用上の問題になりがちなRepair処理に関して根本的な解決方法を提供する。

• より的確なレプリカの再生 • マークル木の精度 の動的調整 • 最小限の同期

Counterの改良

ノード障害発生時に実数破損が起きやすい実装の修正

Streaming及びrepairの改良

ご清聴ありがとうございました。