1.2新機能と1.2から始めるcql3

3,550 views
3,440 views

Published on

第24回Cassandra勉強会

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,550
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

1.2新機能と1.2から始めるcql3

  1. 1. Cassandra1.2新機能と 1.2から始めるCQL3 2013年3月8日
  2. 2. 自己紹介 関 あつお (twitter : @atsuoon) 株式会社INTHEFOREST エンジニア 職歴 OSS関係の会社に入社後その会社が潰れ その後 某レストラン検索サイトで4,5年派遣として働く
  3. 3. Agenda ・Cassandra1.2の新機能について さくっとご紹介 ・Cassandra1.2から始めるCQL3 自分が苦しんだ内容全般
  4. 4. Cassandra1.2の新機能について
  5. 5. Cassandra1.2の新機能についてバーチャルノード ノードに複数のトークンをランダムで自動設定 ノード1利点 ノード2 ノード3・ノードの立ち上げ、取り外しが早くなる ノード3 ノード2・トークン設定しなくてもいい ノード3 ノード3・バイト順のパーテショナーでも分散難点 ノード1 ノード1・トークンの決め打ちができない・リングの状態見辛い ノード2・色々ある不具合 ノード1 ノード1 ノード3 ノード2 ノード3 ノード2 ノード1 ノード2
  6. 6. Cassandra1.2の新機能についてリクエストトレース CQL3でクエリの処理内容や かかった時間など把握する事ができる利点・ボトルネックが把握しやすくなる難点・重い
  7. 7. Cassandra1.2の新機能についてアトミックバッチ 従来のバッチではバッチ処理中に 処理中のノードとそのノードにバッチクエリを渡したノードが落ちた際 データロストに繋がっていたが バッチ処理を行う前にsystem.batchlogにバッチ内容を書き込む事によって 途中で落ちても立ち上げたときよしなにしてくれるようになった 利点 ・バッチの信頼性が高くなった 難点 node ・バッチ自体重いのにさらに重い バッチ実行中に複数のサーバーが 落ちても何とかしてくれます
  8. 8. Cassandra1.2の新機能についてJBOD 1.1でもディレクトリを複数設定できるが 1つのカラムファミリが複数のディレクトリに分散はされない 1.2では分散されるようになった 利点 ・Raidを組まなくてよくなる ・I/Oのリソースが確保しやすい data1 ・保守しやすい 難点 Column Family data2 ・得に無い、強いて言えば memtable_flush_writerが増える data3
  9. 9. Cassandra1.2の新機能についてディスク障害ポリシー ディスク障害時の時の挙動を3つのうちから選べるようになった 利点 ・運用の明確化 ・best_effortでホットスワップが可能 stop : ディスク障害時、プロセスはダウンしないがgossipとThriftは行われない best_effort : ディスク障害時、gossip、thriftは止めず動作し続けるが、問題あるディレクトリの 書込みは止まる、読込みも出来ない場合は読込みも止まるが 出来る場合は読込みは通常に行われる ignore : 単にリクエストがエラーになる 難点 ・best_effortでCL:ONEの読込みをした際 古い情報が取れる可能性を考えなければならない
  10. 10. Cassandra1.2の新機能についてCLQ3 Native Protocol CQL3ではネイティブプロトコルとしてThriftを使用せずに Cassandra独自のプロトコルを使用する事ができるようになった 利点 ・ノード間のスキーマ反映などが高速に ・複数のリクエストを同時に処理 難点 ・Thrift対応が消える今後の可能性・・ CQLのクエリは ・まだベータ的な扱い Cassandra Thriftを使用していた Cassandra ・扱ってるクライアントが少ない Thrift Thrift CQL3 CQL3 1.2は新しくCQL3用の Protocolが追加された
  11. 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. 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. 13. Cassandra1.2の新機能について他、いくつかの追加や変更 ・hinted-handoff のスレッド数とパフォーマンスの設定 ・認証がクライアントとサーバーで別々に設定可能 ・Leveled Compactionでwrite heavy時の対策 ・タイムアウト関係の設定が追加 ・ノード間の通信を圧縮するかしないかの設定 ・compression時のメタデータをJVMのヒープから外出し ・CQL3でノードの情報を取得可能 ・カラムインデックスの改良 ・DC間通信時のパケットの設定 お、多い、、、
  14. 14. 全体的にCQL3に追加された機能が多いです
  15. 15. しかし・・
  16. 16. CQL3自体は もっと変貌していた・・
  17. 17. Cassandra1.2から始めるCQL3
  18. 18. CQL3って・・?CQL3さんの主張 CassandraでSQLが使えるよ! CQL3からカラムファミリがテーブルになったよ! しかも複合キーも使用可能になったよ! これでRDBMSからの移行もしやすいよね(震え声) 兎にも角にも CQL3を使用する為に bin/cqlsh を使ってみよう
  19. 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. 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. 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 ×取得できない なぜ?! ここでRDBMSから1.2に直接入ってきた人間はじわじわ死ぬ
  22. 22. CQL3を使用してみる実は・・・ 複合キーの宣言の仕方が違う PRIMARY KEY ((title,chapter,page,line)) もう一つ括弧でくくればよい
  23. 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 ×取得できない 悪化したんですけどお!!!!11!
  24. 24. 複パ 複複 合ー キテ 合合 ーー だシ キキ けョ どン ーー なキ !ー ではラカ の も サ ン ド ここでRDBMSから1.2に直接入ってきた人間は死ぬ
  25. 25. データ構造 パーテーションキーを知る場合 今までのデータ構造を知ると良い リング一周 -2^63 ~ 2^63 – 1 (パーテショナーがMurmur3の場合)テーブルではなくカラムファミリColumnFamily[RowKey][Column] = value ノード1 ノード6 ノード2 RowKey パーテショ ナー ノード5 ノード3 RowKeyの値を変換 ノード4RowKey = パーテーションキー 値によってリングのどこ に位置するデータか決ま る
  26. 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. 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. 28. データ構造Cassandraは原則 RowKey Column それぞれ1塊しか指定する事ができません RowKeyはリング基準での一塊 ColumnはRowKeyに入っている一塊 ノード1 [00001] [00002] [00003] ノード6 ノード2 [00004] [00005] [00006] [00007] ノード5 ノード3 [00008] [00009] ノード4 [00010]ノード1~2 と ノード4~5 とか 00001 ~ 00003 と 00009~00008同時に指定することは出来ない など同時に指定する事はできない
  29. 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. 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. 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. 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. 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. 34. ByteOrderedPartitioner にする事で可能なクエリ ・複合パーテーションキーでのインデックス2個目の範囲検索 例えば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 filteringCREATE INDEX idx_001 ON books (value1);CREATE INDEX idx_002 ON books (value2); 逆を言えば複合パーテーションキーでインデックス2個目の範囲検索は ByteOrdered以外の場合は出来ない
  35. 35. CQL3って・・・• 元々のデータ構造を知らないと苦労する• SQLだからって夢見んな• ここに来てByteOrdered + vnodeに光が差し込む OrderPreservingPartitionerはバグってCQL3だと使えないけどこれ は・・・・
  36. 36. ご清聴ありがとうございました

×