Recommended
More Related Content
What's hot
Similar to 1.2新機能と1.2から始めるcql3
Recently uploaded
Recently uploaded (9)
1.2新機能と1.2から始めるcql3
- 1. Cassandra1.2新機能と 1.2から始めるCQL3 2013年3月8日
- 2. 自己紹介 関 あつお (twitter : @atsuoon) 株式会社INTHEFOREST エンジニア 職歴 OSS関係の会社に入社後その会社が潰れ その後 某レストラン検索サイトで４，５年派遣として 働く
- 3. Agenda ・Cassandra1.2の新機能について さくっとご紹介 ・Cassandra1.2から始めるCQL3 自分が苦しんだ内容全般
- 5. Cassandra1.2の新機能について バーチャルノード ノードに複数のトークンをランダムで自動設定 ノード1 利点 ノード2 ノード3 ・ノードの立ち上げ、取り外しが早くなる ノード3 ノード2 ・トークン設定しなくてもいい ノード3 ノード3 ・バイト順のパーテショナーでも分散 難点 ノード1 ノード1 ・トークンの決め打ちができない ・リングの状態見辛い ノード2 ・色々ある不具合 ノード1 ノード1 ノード3 ノード2 ノード3 ノード2 ノード1 ノード2
- 6. Cassandra1.2の新機能について リクエストトレース CQL3でクエリの処理内容や かかった時間など把握する事ができる 利点 ・ボトルネックが把握しやすくなる 難点 ・重い
- 7. Cassandra1.2の新機能について アトミックバッチ 従来のバッチではバッチ処理中に 処理中のノードとそのノードにバッチクエリを渡したノードが落ちた際 データロストに繋がっていたが バッチ処理を行う前にsystem.batchlogにバッチ内容を書き込む事によって 途中で落ちても立ち上げたときよしなにしてくれるようになった 利点 ・バッチの信頼性が高くなった 難点 node ・バッチ自体重いのにさらに重い バッチ実行中に複数のサーバーが 落ちても何とかしてくれます
- 8. Cassandra1.2の新機能について ＪＢＯＤ 1.1でもディレクトリを複数設定できるが １つのカラムファミリが複数のディレクトリに分散はされない 1.2では分散されるようになった 利点 ・Raidを組まなくてよくなる ・I/Oのリソースが確保しやすい data1 ・保守しやすい 難点 Column Family data2 ・得に無い、強いて言えば memtable_flush_writerが増える data3
- 9. Cassandra1.2の新機能について ディスク障害ポリシー ディスク障害時の時の挙動を３つのうちから選べるようになった 利点 ・運用の明確化 ・best_effortでホットスワップが可能 stop ： ディスク障害時、プロセスはダウンしないがgossipとThriftは行われない best_effort ： ディスク障害時、gossip、thriftは止めず動作し続けるが、問題あるディレクトリの 書込みは止まる、読込みも出来ない場合は読込みも止まるが 出来る場合は読込みは通常に行われる ignore ： 単にリクエストがエラーになる 難点 ・best_effortでCL:ONEの読込みをした際 古い情報が取れる可能性を考えなければならない
- 10. Cassandra1.2の新機能について CLQ3 Native Protocol CQL3ではネイティブプロトコルとしてThriftを使用せずに Cassandra独自のプロトコルを使用する事ができるようになった 利点 ・ノード間のスキーマ反映などが高速に ・複数のリクエストを同時に処理 難点 ・Thrift対応が消える今後の可能性・・ CQLのクエリは ・まだベータ的な扱い Cassandra Thriftを使用していた Cassandra ・扱ってるクライアントが少ない Thrift Thrift CQL3 CQL3 1.2は新しくCQL3用の Protocolが追加された
- 11. Cassandra1.2の新機能について CQL3 Sets, Maps, Lists のコレクション対応 CQL3ではSets Maps Lists の型がカラムとして入れられるようになった 利点 ・シリアライズ化して突っ込まなくてもよくなった 難点 ・プライマリーキーとして宣言は出来ない CREATE TABLE points ( id text PRIMARY KEY, point list<int> ); id | point insert into points (id, point) values ('test',[2,4,7,9]); ＝ ------+-------- test | [2, 7] update points set point = point - [4, 9] where id = 'test‘; select * from points;
- 12. Cassandra1.2の新機能について 新パーテショナー Murmur3 RandomPartitionerの早い安い旨い版 利点 ・早い ・数値が少ない ・シノニムが生じるのが少ない 難点 ・範囲変わって計算の仕方も変わった ・しれっとデフォルトに・・ ・RandomPartitionerのレンジ範囲 0 ～ 2^127 ( 0 ～ 170141183460469231731687303715884105728 ) ・Murmur3Partitionerのレンジ範囲 -2^63 ～ 2^63 - 1 ( -9223372036854775808 ～ 9223372036854775807 ) python -c 'print [((2**64 / リングのノード数) * i) - 2**63 for i in range(リングのノード数)]
- 13. Cassandra1.2の新機能について 他、いくつかの追加や変更 ・hinted-handoff のスレッド数とパフォーマンスの設定 ・認証がクライアントとサーバーで別々に設定可能 ・Leveled Compactionでwrite heavy時の対策 ・タイムアウト関係の設定が追加 ・ノード間の通信を圧縮するかしないかの設定 ・compression時のメタデータをJVMのヒープから外出し ・CQL3でノードの情報を取得可能 ・カラムインデックスの改良 ・ＤＣ間通信時のパケットの設定 お、多い、、、
- 15. しかし・・
- 18. CQL3って・・？ CQL3さんの主張 CassandraでSQLが使えるよ！ CQL3からカラムファミリがテーブルになったよ！ しかも複合キーも使用可能になったよ！ これでRDBMSからの移行もしやすいよね（震え声） 兎にも角にも ＣＱＬ３を使用する為に bin/cqlsh を使ってみよう
- 19. CQL3を使用してみる Keyspaceとtableを作成 CREATE KEYSPACE space WITH strategy_class = 'SimpleStrategy' AND strategy_options:replication_factor=1 しかしうまくいかな い・・・ 実は1.1のCQL3と1.2のCQL3は別物 （1.2のCQLとして1.1のCQLが資料として乗っている場合がある）
- 20. CQL3を使用してみる 気を取り直してKeyspaceとtableを作成 CREATE KEYSPACE space WITH replication = { 'class': 'SimpleStrategy', 'replication_factor': '1' }; 定義が違う use space; CREATE TABLE books ( 複合キーを使用する場合は title text, 連ねて宣言する chapter int, page int, line int, value text, PRIMARY KEY (title,chapter,page,line) ); Insert into books(title,chapter,page,line,value) values (‘test’,1,1,1,‘testString’);
- 21. CQL3を使用してみる select文でwhere句を試そう select * from books where title = 'test' ○取得できた select * from books where chapter = 1 ×allow filter？ select * from books where chapter = 1 allow filtering ○取得できた select * from books where title = 'test' and chapter = 1 ○取得できた select * from books where page = 1 ×取得できない select * from books where title = 'test' and page = 1 ×取得できない select * from books where title = 'test' and chapter = 1 and page = 1 ○取得できた select * from books where title = 'test' and chapter = 1 and line = 1 ×取得できない select * from books where value = 'testString' ×取得できない なぜ？！ ここでＲＤＢＭＳから1.2に直接入ってきた人間はじわじわ死ぬ
- 22. CQL3を使用してみる 実は・・・ 複合キーの宣言の仕方が違う PRIMARY KEY ((title,chapter,page,line)) もう一つ括弧でくくればよい
- 23. CQL3を使用してみる Table を変更してもう一度試してみよう select * from books where title = 'test' ×取得できない select * from books where chapter = 1 ×取得できない select * from books where chapter = 1 allow filtering ×取得できない select * from books where title = 'test' and chapter = 1 ×取得できない select * from books where page = 1 ×取得できない select * from books where title = 'test' and page = 1 ×取得できない select * from books where title = 'test' and chapter = 1 and page = 1 ×取得できない select * from books where title = 'test' and chapter = 1 and line = 1 ×取得できない select * from books where value = 'testString' ×取得できない 悪化したんですけどお！！！！１１！
- 24. 複パ 複複 合ー キテ 合合 ーー だシ キキ けョ どン ーー なキ ！ー では ラカ の も サ ン ド ここでＲＤＢＭＳから1.2に直接入ってきた人間は死ぬ
- 25. データ構造 パーテーションキーを知る場合 今までのデータ構造を知ると良い リング一周 -2^63 ～ 2^63 – 1 （パーテショナーがMurmur3の場合） テーブルではなくカラムファミリ ColumnFamily[RowKey][Column] = value ノード1 ノード6 ノード2 RowKey パーテショ ナー ノード5 ノード3 RowKeyの値を変換 ノード4 RowKey = パーテーションキー 値によってリングのどこ に位置するデータか決ま る
- 26. データ構造 PRIMARY KEYの指定はColumnFamilyで 当てはめた考え方のほうが理解しやすい ColumnFamily[RowKey][Column] = value で言うPRIMARY KEYは PRIMARY KEY ((RowKey),Column) PRIMARY KEY ((title,chapter),page,line) の場合ColumnFamilyで言う ColumnFamily[title,chapter][page,line]
- 27. データ構造 以下のようなデータを入れた場合 CREATE TABLE books ( title text, chapter int, page int, line int, value text, PRIMARY KEY ((title,chapter),page,line) ); Insert into books(title,chapter,page,line,value) values (‘test’,1,1,1,‘testString’); ColumnFamilyで言うと books*title:test,chapter:1+*page:1,line:1,value+ = ‘testString’ ※実際にカンマやコロンで区切られている訳ではない
- 28. データ構造 Cassandraは原則 RowKey Column それぞれ１塊しか指定する事ができませ ん RowKeyはリング基準での一塊 ColumnはRowKeyに入っている一塊 ノード1 [00001] [00002] [00003] ノード6 ノード2 [00004] [00005] [00006] [00007] ノード5 ノード3 [00008] [00009] ノード4 [00010] ノード１～２ と ノード４～５ とか 00001 ～ 00003 と 00009～00008 同時に指定することは出来ない など同時に指定する事はできない
- 29. 実際のwhere文について PRIMARY KEY ((title,chapter),page,line) この場合のRowKey部分のwhere句 ・RowKeyを含める場合は確実にRowKey全てを含める事 ○ select * from books where title = 'book1' and chapter = 1 × select * from books where chapter = 1 × select * from books where title = 'book1' ・RowKeyで範囲検索をする際はtokenを使用する事 （パーテショナーを理解してから使用する事） ○ select * from books where token(title,chapter) >= token('book1', 1) and token(title,chapter) <= token('book1', 99) × select * from books where token(title) >= token('book1') and token(title) <= token('book1')
- 30. 実際のwhere文について PRIMARY KEY ((title,chapter),page,line) この場合のColumn部分のwhere句 ・Columnで検索する際は宣言した順番に指定する必要がある またallow filtering は複数のRowKeyから指定したColumnを取得する場合に付与しなければならない ○ select * from books where page = 1 allow filtering × select * from books where line = 1 allow filtering ○ select * from books where page = 1 and line = 1 allow filtering ・取得するRowKeyが一つの場合は allow filtering は付与しなくてもよ い○ select * from books where title = 'book1' and chapter = 1 and page = 1 ○ select * from books where title = 'book1' and chapter = 1 and page = 1 allow filtering ・Columnで範囲検索をする場合は一つのColumnのみ指定できる ○ select * from books where title = 'book1' and chapter = 1 and page >= 1 and page <= 99 × select * from books where title = 'book1' and chapter = 1 and page >= 1 and line >= 1
- 31. 実際のwhere文について Primary key 以外のカラムをwhere文で使用したい場合 そのカラムにインデックスを張る CREATE INDEX [<indexname>] ON <cfname> ( <colname> ) カラムファミリ booksのvalueというカラムにインデックスを張る場合 CREATE INDEX ON books (value); value を使用して問い合わせる select * from books where value = ‘test’ パーテーションキーが複合キーの場合 where句でパーテーションキーとの併用が・・・・ あと COMPACT STRAGE には使用できない・・・・
- 32. COMPACT STORAGEについて COMPACT STORAGE はPrimary Key 以外のカラムを一種類だけにして メタデータを省略する事によって、データ容量を削ったテーブル CREATE TABLE books ( title text, Primary Key以外は一つだけしか chapter int, 宣言できない page int, line int, value text, PRIMARY KEY ((title,chapter),page,line) ) WITH COMPACT STORAGE; このテーブルのvalueにはインデックスを指定する事ができない しかし cassandra-cli で使用可能になる （cqlsh -2 ではだめだった・・ 複合キーの区切りは“：”・・
- 33. ByteOrderedPartitioner にする事で可能なクエリ ・パーテーションキーの範囲検索がColumnと同じように可能 例えば CREATE TABLE books ( title text, chapter int, page int, line int, value text, PRIMARY KEY ((title,chapter),page,line) ); の場合 Select * from books where title = ‘text’ and chapter > 3 and page = 1 and line >= 3 and line < 8 allow filtering
- 34. ByteOrderedPartitioner にする事で可能なクエリ ・複合パーテーションキーでのインデックス２個目の範囲検索 例えば CREATE TABLE books ( title text, chapter int, で、こんなクエリが可能 page int, line int, Select * from books where title = ‘text’ and chapter > 3 value1 text, and page = 1 value2 text, and line >= 3 and line < 8 value3 text, and value1 = ‘test’ PRIMARY KEY ((title,chapter),page,line) and value2 > ‘a’ and value2 < ‘z’ ); allow filtering CREATE INDEX idx_001 ON books (value1); CREATE INDEX idx_002 ON books (value2); 逆を言えば複合パーテーションキーでインデックス２個目の範囲検索は ByteOrdered以外の場合は出来ない
- 35. ＣＱＬ３って・・・ • 元々のデータ構造を知らないと苦労する • ＳＱＬだからって夢見んな • ここに来てByteOrdered + vnodeに光が差し込む OrderPreservingPartitionerはバグってCQL3だと使えないけどこれ は・・・・
- 36. ご清聴ありがとうございま した