Empfohlen
Weitere ähnliche Inhalte
Mehr von Kazutaka Tomita
Cassandra12to20
- 1. Cassandra 1.2 から 2.0 へ 株式会社 INTHEFOREST
- 2. 自己紹介 冨田 和孝 (@railute) 肩書き： 株式会社ＩＮＴＨＥＦＯＲＥＳＴ 代表取締役社長 Cassandra商用サポート、Cassandraコンサルティング他 Cassandra勉強会主宰 ２か月に一度程度開催。現在、第25回まで開催。 職種：本職はＤＢ・インフラ系エンジニア 以前、某レストランサーチのＤＢＡ 高負荷・大容量・大規模のOracleRACとPostgreSQLと MySQLに苦しめられ続けた経験あり。
- 3. Agenda Cassandra基礎知識 Cassandraの歴史 Cassandraの新機能 CQL3 Virtual Node Request Trace Atomic Batch JBOD Disk Failure Policy CQL3 Native Protocol Cassandra2.0に向けて トリガー 集約関数 Streaming及びrepairの改良 Counterの改良
- 4. Cassandraの基礎知識 Cassandraのノードはレプリカとコンシステントハッシン グによるデータ配置でデータ保全性を担保する。 ノード1 • 各ノードはP2Pで稼働 α” • データ配置はコンシステントハッシング ノード6 ノード2 • データの複製で保全性を担保 α’ ノード5 ノード3 α ノード4 α
- 5. Cassandraの歴史 • CQL • Row Leveｌ isolation • Counter 0.7 0.8 1.0 1.1 1.2 2.0 • 動的スキーマ変更 • Compression • セカンダリ・インデックス • Leveled-compaction
- 6. CQL3 変わるデータ構造（CQL2） thriftAPIのラッパー構造 cqlsh & cql CassandraBenchmark create keyspace CassandraBenchmark CBench with strategy_class = ‘SampleStrategy' and strategy_options:replication_factor=3; cbid：000001 Key textdata：xxxxxxxxxxxx use CassandraBenchmark; cbid：000002 CREATE COLUMNFAMILY CBench ( Key KEY text PRIMARY KEY, textdata：xxxxxxxxxxxx cbid int ); Key cbid：000003 CREATE INDEX cbid_idx ON CBench (cbid); textdata：xxxxxxxxxxxx SELECT * FROM Cbench WHERE KEY = ‘10000’; INSERT INTO (KEY,cbid,textdata) VALUES (‘10000’,‘000001’,’xxxxxxx’);
- 7. CQL3 変わるデータ構造（CQL3） APIを一から作り直し ※複合KEYもサポートされた cqlsh & cql CREATE KEYSPACE CassandraBenchmark WITH replication = { CassandraBenchmark 'class': 'SimpleStrategy', CBench 'replication_factor': '3' cbid textdata }; use CassandraBenchmark; 0001 xxxxxx CREATE TABLE CBench ( 0002 xxxxxx cbid int PRIMARY KEY, 0003 xxxxxx textdata text ); SELECT * FROM Cbench WHERE cbid = ‘10000’; INSERT INTO (cbid,textdata) VALUES (‘000001’,’xxxxxxx’);
- 8. Virtual Node Cassandraのノードは一つのリングに対して データを請け負う範囲を一つ設定する リング一周 0 ～ 2^127 ノード1 リング一周の 0 ～ 2^127 の数値の 各ノードに一つ割り当て ノード6 ノード2 割り当てた数値から次のノードの数値まで そのノードのデータ範囲を割り振れる ノード5 ノード3 ※1.2になってからデフォルトのリングの ノード4 一周の範囲が 0 ～ 2^127 から 変更されているので注意
- 9. Virtual Node Virtual Nodeの場合ランダムで請け負うデータ範囲が 複数持つ事になるので、データ範囲の設定が不要に ノード３つでそれぞれ ６つのデータ範囲を持たせた場合 ノード1 ノード3 ノード2 ノード3 ノード2 ノード１ ノード3 ノード3 ノード２ ノード1 ノード1 ノード３ ノード1 ノード2 ノード1 ノード3 一つのノードのトークンの数を増やせば増やすほど 比較的、平均に負荷分散が行える ノード2 ノード3 ノード2 ノード1 ノード2
- 10. Virtual Node また、Virtual Nodeの場合ノード追加の際は Cassandraの特性上、追加ノードへ割り当てられたデータが 別のノードから転送されます ノード1 ノード3 ノード2 ノード3 ノード2 ノード3 ノード2 ノード3 ノード2 ノード3 ノード3 ノード3 ノード3 ノード1 ノード1 ノード2 ノード2 ノード1 ノード1 ノード3 ノード3 ノード3 ノード2 ノード3 ノード2 ノード2 ノード2 ノード1 ノード2 ノード2 複数データを請け負う範囲を持つ事で、本来１ノードから転送される所を 複数のノードに分散でき、負荷も分散されます（ノード取り外しも負荷分散される）
- 11. Request Trace CQL3ではRequest Traceの機能が追加 tracing on と実行するとこの機能が使用できる Request Trace を行った結果はキースペースsystem_traceのテーブル sessions, events に溜まる
- 12. 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;
- 13. Atomic Batch バッチ内容をsystem.batchlogに書き込み 実行ノードがダウンしてもバッチは その後バッチが実行される 継続して実行される。 × cassandra Begin batch cassandra cassandra Insert into … Insert into … バッチ実行最中にDown Apply batch × cassandra × cassandra System.batchlogにバッチ内容が書き込まれているので cassandra cassandra 関係あるノードが全てDownしても復帰後に 更新作業が行われる cassandra
- 14. JBOD 同一カラムファミリを複数のディスクに分散してストアするこ とが可能になった。 data1 CF:ABC × data2 HDD × + HDD data3 + HDD
- 15. Disk Failure Policy Cassandra1.1 まではディスク障害時の挙動は決められていた Cassandra 1.2からは・・・ ３種類のいずれかを設定する事が出来る stop ： ディスク障害時、プロセスはダウンしないがgossipとThriftは行われない best_effort ： ディスク障害時、gossip、thriftは止めず動作し続けるが、問題あるディレクトリの 書込みは止まる、読込みも出来ない場合は読込みも止まるが 出来る場合は読込みは通常に行われる ignore ： 単にリクエストがエラーになる
- 16. CQL3 Native Protocol 現在Cassandra内ではサーバー・クライアント間の通信に Apache Thrift が使用されている CQLのクエリは cqlsh Thriftを使用していた Cassandra Thrift Thrift CQL3 CQL3 1.2は新しくCQL3用の Protocolが追加された ・ノード間のスキーマ反映が高速に ・複数のリクエストを同時に処理する事ができるように ・送信データは圧縮する事が可能に
- 17. Cassandra 2.0 トリガー サーバーサイドの各テーブルにトリガーを設置可能とする 構造はまだ議論中であるがRDBMSでいうところのアフタートリガーに近 い動きになる模様 集約関数 サーバーサイド側にSUMのような集約関数を実装可能にする。
- 18. Cassandra 2.0 Streaming及びrepairの改良 既存のCassandra無いで非常に負荷が高く運用上の問題になりがちな Repair処理に関して根本的な解決方法を提供する。 • より的確なレプリカの再生 • マークル木の精度の動的調整 • 最小限の同期 Counterの改良 ノード障害発生時に実数破損が起きやすい実装の修正
- 19. ご清聴ありがとうございました。