• Like
Cassandra12to20
Upcoming SlideShare
Loading in...5
×

Cassandra12to20

  • 325 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
325
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
12
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Cassandra 1.2 から 2.0 へ 株式会社 INTHEFOREST
  • 2. 自己紹介冨田 和孝 (@railute)肩書き: 株式会社INTHEFOREST 代表取締役社長Cassandra商用サポート、Cassandraコンサルティング他Cassandra勉強会主宰2か月に一度程度開催。現在、第25回まで開催。職種:本職はDB・インフラ系エンジニア以前、某レストランサーチのDBA高負荷・大容量・大規模の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 Level isolation • Counter 0.7 0.8 1.0 1.1 1.2 2.0• 動的スキーマ変更 • Compression• セカンダリ・インデックス • Leveled-compaction
  • 6. CQL3 変わるデータ構造(CQL2) thriftAPIのラッパー構造 cqlsh & cql CassandraBenchmarkcreate keyspace CassandraBenchmark CBench with strategy_class = ‘SampleStrategy and strategy_options:replication_factor=3; cbid:000001 Key textdata:xxxxxxxxxxxxuse CassandraBenchmark; cbid:000002CREATE COLUMNFAMILY CBench ( Key KEY text PRIMARY KEY, textdata:xxxxxxxxxxxx cbid int); Key cbid:000003CREATE 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 & cqlCREATE KEYSPACE CassandraBenchmarkWITH replication = { CassandraBenchmark class: SimpleStrategy, CBench replication_factor: 3 cbid textdata};use CassandraBenchmark; 0001 xxxxxxCREATE 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 NodeCassandraのノードは一つのリングに対してデータを請け負う範囲を一つ設定する リング一周 0 ~ 2^127 ノード1 リング一周の 0 ~ 2^127 の数値の 各ノードに一つ割り当て ノード6 ノード2 割り当てた数値から次のノードの数値まで そのノードのデータ範囲を割り振れる ノード5 ノード3 ※1.2になってからデフォルトのリングの ノード4 一周の範囲が 0 ~ 2^127 から 変更されているので注意
  • 9. Virtual NodeVirtual Nodeの場合ランダムで請け負うデータ範囲が複数持つ事になるので、データ範囲の設定が不要に ノード3つでそれぞれ 6つのデータ範囲を持たせた場合 ノード1 ノード3 ノード2 ノード3 ノード2 ノード1 ノード3 ノード3 ノード2 ノード1 ノード1 ノード3 ノード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 複数データを請け負う範囲を持つ事で、本来1ノードから転送される所を 複数のノードに分散でき、負荷も分散されます(ノード取り外しも負荷分散される)
  • 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に書き込み実行ノードがダウンしてもバッチは その後バッチが実行される継続して実行される。 × cassandraBegin batch cassandra cassandraInsert into …Insert into … バッチ実行最中にDownApply 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からは・・・ 3種類のいずれかを設定する事が出来る 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. ご清聴ありがとうございました。