インフラエンジニアのためのcassandra入門

108,174 views

Published on

Published in: Technology
1 Comment
82 Likes
Statistics
Notes
No Downloads
Views
Total views
108,174
On SlideShare
0
From Embeds
0
Number of Embeds
69,196
Actions
Shares
0
Downloads
0
Comments
1
Likes
82
Embeds 0
No embeds

No notes for slide
  • Spider Storage Engine はおいておくw
  • 実装によるとは思いますが。 Spider Storage Engine はおいておくw
  • 実装によるとは思いますが。 Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw 迷子データがでますよ。
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • Spider Storage Engine はおいておくw
  • インフラエンジニアのためのcassandra入門

    1. 1. <ul><li>インフラエンジニアのための </li></ul><ul><li>cassandra 入門 </li></ul>株式会社サイバーエージェント 桑野 章弘
    2. 2. 自己紹介
    3. 3. 自己紹介 <ul><li>桑野 章弘 </li></ul><ul><ul><li>id: akuwano </li></ul></ul><ul><ul><li>twitter: @kuwa_tw </li></ul></ul><ul><li>株式会社サイバーエージェント </li></ul><ul><li>インフラエンジニア </li></ul><ul><ul><li>最近は自分でも何やってんのかわからなくなってきた </li></ul></ul>
    4. 4. はじめに <ul><li>Cassandra を知らない人向けに </li></ul><ul><ul><li>どういうもので </li></ul></ul><ul><ul><li>どうやって使ったらいいの? </li></ul></ul><ul><li>細かい部分ははしょっています </li></ul>
    5. 5. アジェンダ <ul><li>MySQL の分散って大変? </li></ul><ul><li>そこで Cassandra ですよ </li></ul><ul><li>Cassandra を試すのは簡単 </li></ul><ul><li>設定とか、管理とかってどうなの </li></ul><ul><li>MySQL->Cassandra への置換例 </li></ul><ul><li>これからの話 </li></ul><ul><li>まとめ </li></ul>
    6. 6. MySQL の分散って大変?
    7. 7. 1 台ならいいけど <ul><li>サービスが大きくなるにつれてサーバへの負荷は増えていきます </li></ul><ul><li>そこをケアするためにサーバを増やすわけですが、、、 </li></ul><ul><ul><li>Web 、 Ap サーバは主にロードバランサ等で分散します </li></ul></ul><ul><ul><li>DB サーバはシャーディングで分散します </li></ul></ul><ul><ul><li>例えば、、、 </li></ul></ul>
    8. 8. テーブル分割手法(例 1 ) <ul><li>特定のカラムでの分割 </li></ul><ul><ul><li>UserID などで特定のレンジ毎にサーバを分割する </li></ul></ul>
    9. 9. テーブル分割手法(例 1 ) <ul><li>特定のカラムでの分割 </li></ul>DBMaster DBSlave1 DBSlave2 分散ルール 150000 175000 200000 50000 1 データ UserID B 200000 100001 A 100000 1 レンジ End レンジ Start テーブル UserID 50000 1 データ UserID 150000 175000 200000 データ UserID
    10. 10. テーブル分割手法(例 1 ) <ul><li>メリット </li></ul><ul><ul><li>データの管理は分かりやすい </li></ul></ul><ul><li>デメリット </li></ul><ul><ul><li>特定サーバへの偏り </li></ul></ul><ul><ul><li>一部障害の可能性 </li></ul></ul><ul><ul><li>サーバ追加のタイミングとレンジルールのメンテナンス性 </li></ul></ul>
    11. 11. テーブル分割手法(例 2 ) <ul><li>ハッシュテーブルでの分割 </li></ul><ul><ul><li>分散対象をハッシュ化してそのハッシュ値を元にサーバの分割を行う </li></ul></ul>
    12. 12. テーブル分割手法(例 2 ) <ul><li>ハッシュテーブルでの分割 </li></ul>DBMaster DBSlave1 DBSlave2 分散ルール ハッシュ化 1->01 50000->01 15000->00 17500->00 200000->02 150000 175000 200000 50000 1 データ UserID B 02 B 01 A 00 テーブル ハッシュ値 175000 150000 データ UserID 1 50000 200000 データ UserID
    13. 13. テーブル分割手法(例 2 ) <ul><li>メリット </li></ul><ul><ul><li>分散の粒度を細かくすればメンテナンスの手間は少ない </li></ul></ul><ul><li>デメリット </li></ul><ul><ul><li>特定サーバへの偏り </li></ul></ul><ul><ul><li>一部障害の可能性 </li></ul></ul><ul><ul><li>特定データの受け持ち DB をトレースしないといけない </li></ul></ul>
    14. 14. 結構大変じゃないですか? <ul><li>継続的に管理しないといけない </li></ul><ul><ul><li>もちろん自動化とかするのもありだけど、サーバ追加とか分散ルールの変更とか。 </li></ul></ul><ul><ul><li>負荷が増えてきた時にデータ移動とか。 </li></ul></ul><ul><ul><li>1 台落ちると部分障害になったり。 </li></ul></ul><ul><ul><li>それに対応してさらに複雑になったり。 </li></ul></ul><ul><ul><li>増えれば増えるほどサーバの管理は大変になる、、、。 </li></ul></ul><ul><ul><li>この辺り気にしない様になったら楽ですよね </li></ul></ul>
    15. 15. そこで Cassandra ですよ
    16. 16. Cassandra って? <ul><li>Cassandra は Facebook で作られた分散型 DB サーバ </li></ul><ul><li>Dynamo 的な大規模分散管理と、 HyperTable の様なカラム型データ構造を持った DB である </li></ul>
    17. 17. それ Cassandra で出来(ry <ul><li>パフォーマンス </li></ul><ul><li>分散実装 </li></ul><ul><li>冗長性 </li></ul><ul><li>データ構造 </li></ul><ul><ul><li>全部確保できます </li></ul></ul>
    18. 18. それ Cassandra で出来、、、 <ul><li>整合性の確保 </li></ul><ul><li>カラム構造の動的変更 </li></ul><ul><ul><li>これはダメ。(出来るけど) </li></ul></ul>
    19. 19. パフォーマンス <ul><li>MySQL と比べてリードライトの性能が格段に良い </li></ul><ul><ul><li>公式 Wiki より </li></ul></ul>write read 15ms 350ms 0.12ms 300ms Cassandra MySQL
    20. 20. 分散実装 <ul><li>クラスタリング </li></ul><ul><ul><li>各サーバには差異は無い。サーバ種別はノードサーバのみ。 </li></ul></ul><ul><li>Gossip プロトコルを使用した情報伝播 </li></ul><ul><ul><li>次ページ </li></ul></ul>
    21. 21. Gossip プロトコル <ul><li>直近ノード間でのみ情報をやり取りしつつ最終的にはノードの状態( JOIN 、 DEAD 、 AVAIL など)を取得できる </li></ul><ul><ul><li>トラフィック量が倍倍に増えていく事がない </li></ul></ul><ul><ul><li>即時性は無い </li></ul></ul>
    22. 22. 冗長性 <ul><li>各レンジ毎にレプリカをもつ </li></ul><ul><li>レプリカ数は設定可能、デフォルトは 1 (レプリカ無) </li></ul><ul><li>レプリカ先のサーバの決定方法はカスタマイズ可能 </li></ul><ul><ul><li>ランダム、 IP アドレスレンジ等でレプリカの場所を指定、など </li></ul></ul>
    23. 23. データ構造 <ul><li>基本はカラム型 </li></ul><ul><ul><li>Key 、 Name とその Value </li></ul></ul><ul><ul><li>でも SuperColumn 等で柔軟なデータ構造が作れる </li></ul></ul>
    24. 24. データ構造 <ul><li>Column </li></ul>・ ・ ・ Key Key Name Value Name Value Name Value Name Value Name Value Name Value Name Value
    25. 25. データ構造 <ul><li>SuperColumn </li></ul>・ ・ ・ Key Key Name Value Value Value Value Value Name Value Value Name Value Name Value Name Value Name Value Name Value Name Value Name Value Name に紐付く形で Column が入っている
    26. 26. 整合性の確保 <ul><li>クラスタ台数が増えれば増えるほど整合性の即時確保は難しい </li></ul><ul><li>整合性レベル( Consistency Level )を指定することでクラスタにいきわたるまで待つ事も出来る </li></ul>
    27. 27. カラム構造の動的変更 <ul><li>現カレントバージョンでは動的変更は出来ない </li></ul><ul><ul><li>やりたい場合は、 JSON エクスポート -> カラム変更 ->JSON 変更 ->JSON インポート の手順が必要 </li></ul></ul><ul><ul><li>全台 </li></ul></ul><ul><ul><li>無理 </li></ul></ul>
    28. 28. Cassandra を試すのは簡単
    29. 29. 手順 <ul><li>バイナリであればインストールは簡単 </li></ul><ul><ul><li>JDK の展開 </li></ul></ul><ul><ul><li>バイナリの展開 </li></ul></ul><ul><ul><li>ディレクトリ作成(データ、ログ) </li></ul></ul><ul><ul><li>設定ファイルはサンプルで動くのでそのまま起動 </li></ul></ul><ul><ul><li>これだけ! </li></ul></ul>
    30. 30. 手順 ##### JDK インストールは割愛 ##### Cassandra インストール # cd /usr/local/src/cassandra # wget http:// ftp.riken.jp/net/apache/incubator/cassandra/0.6.1/apache-cassandra-0.6.1-bin.tar.gz # tar zxvf apache-cassandra-0.6.1-bin.tar.gz # mv apache-cassandra-0.6.1 /usr/local/ # ln -s /usr/local/apache-cassandra-0.6.1 /usr/local/cassandra ##### DATA ディレクトリ、 LOG ディレクトリの作成 # mkdir -p /var/log/cassandra # mkdir -p /var/lib/cassandra # chown -R cassandra. cassandra /var/log/cassandra # chown -R cassandra.cassandra /var/log/cassandra # chown -R cassandra.cassandra /usr/local/cassandra ##### Cassandra 起動テスト # su - cassandra $ cd /usr/local/cassandra/bin $ ./cassandra -f Listening for transport dt_socket at address: 8888 INFO - Saved Token not found. Using 65403833352419508191139141305783892154 INFO - Starting up server gossip INFO - Cassandra starting up... Ctrl+C で停止
    31. 31. 設定とか、管理とかってどうなの?
    32. 32. 設定の勘所ってどこ? <ul><li>Seed </li></ul><ul><li>Port </li></ul><ul><li>KeySpace & ColumnFamily </li></ul><ul><li>ReplicaPlacementStrategy & ReplicationFactor </li></ul><ul><li>Partitioner </li></ul><ul><li>Memory, Disk, and Performance </li></ul><ul><li>Directories </li></ul><ul><ul><li>殆ど全部じゃねぇか!、、、ので抜粋して。 </li></ul></ul>
    33. 33. 設定の勘所ってどこ? <ul><li>Seed </li></ul><ul><ul><li>クラスタのやり取りを行うサーバを設定する </li></ul></ul><ul><ul><li>サーバの情報のやり取りは Gossip 経由で行われるので全サーバを書く必要はありません </li></ul></ul><Seeds> <Seed>cass-test01</Seed> <Seed>cass-test02</Seed> <Seed>cass-test03</Seed> </Seeds>
    34. 34. 設定の勘所ってどこ? <ul><li>Port </li></ul><ul><ul><li>他ノードとの通信用ポート </li></ul></ul><ul><ul><li>クライアントとの通信用ポート </li></ul></ul><!-- 他のノードとの通信のための IP,Port --> <ListenAddress> サーバの IP アドレス </ListenAddress> <StoragePort>7000</StoragePort> <ControlPort>7001</ControlPort> <!-- Thrift Interface の IP,Port --> <ThriftAddress>0.0.0.0</ThriftAddress> <ThriftPort>9160</ThriftPort>
    35. 35. 設定の勘所ってどこ? <ul><li>KeySpace & ColumnFamily </li></ul><ul><ul><li>カラムを定義する </li></ul></ul><ul><ul><li>データ種別の設定 </li></ul></ul><ul><ul><ul><li>SuperColumns </li></ul></ul></ul><ul><ul><ul><li>BytesType </li></ul></ul></ul><ul><ul><ul><li>AsciiType </li></ul></ul></ul><ul><ul><ul><li>UTF8Type </li></ul></ul></ul><ul><ul><ul><li>LongType </li></ul></ul></ul><ul><ul><ul><li>LexicalUUIDType </li></ul></ul></ul><ul><ul><ul><li>TimeUUIDType </li></ul></ul></ul><ul><ul><li>詳しくは後述 </li></ul></ul>
    36. 36. 設定の勘所ってどこ? <ul><li>ReplicaPlacementStrategy & ReplicationFactor </li></ul><ul><ul><li>ReplicaPlacementStrategy はレプリカ作成の戦略 </li></ul></ul><ul><ul><li>ReplicationFactor はレプリカの数を指定する </li></ul></ul># 物理配置を気にしない <ReplicaPlacementStrategy> org.apache.cassandra.locator.RackUnawareStrategy </ReplicaPlacementStrategy> # レプリカの数 =2 <ReplicationFactor>2</ReplicationFactor>
    37. 37. 設定の勘所ってどこ? <ul><li>Partitioner </li></ul><ul><ul><li>データの分割方式の指定 </li></ul></ul><ul><ul><li>基本的には RandomPartitioner を選択することで適切に分散してくれる </li></ul></ul><ul><ul><li>レンジでのデータ取得をしたい場合には OrderPreservingPartitioner を選択する必要があるが、その代わりノード毎に InitialToken を指定する必要がある </li></ul></ul># ランダム分割 <Partitioner>org.apache.cassandra.dht.RandomPartitioner</Partitioner> # 分散箇所を指定する <Partitioner>org.apache.cassandra.dht.OrderPreservingPartitioner</Partitioner>
    38. 38. 設定の勘所ってどこ? <ul><li>Memory, Disk, and Performance </li></ul><ul><ul><li>各種カラムのキャッシュ </li></ul></ul><ul><ul><li>リード、ライトのスレッド数 </li></ul></ul><ul><ul><li>Memtable のフラッシュタイミング、バッファ容量 </li></ul></ul><ul><ul><li>作成したカラムの構成によって変更する必要がある </li></ul></ul>
    39. 39. 設定の勘所ってどこ? <!-- Column を読む際のバッファ。よく実行される Column サイズにするべき。これを増やす時は ColumnIndexSizeInKB も増やす --> <SlicedBufferSizeInKB>64</SlicedBufferSizeInKB> <!-- memtable から SSTable に Flush するさいのバッファ。リソースが許すのであれば大きい方がよい --> <FlushDataBufferSizeInMB>32</FlushDataBufferSizeInMB> <FlushIndexBufferSizeInMB>8</FlushIndexBufferSizeInMB> <!-- Column の Value が非常に大きい場合や、数が多い場合はこの値を増やすこと --> <ColumnIndexSizeInKB>64</ColumnIndexSizeInKB> <!-- memtable に Store しておける最大容量 --> <MemtableSizeInMB>64</MemtableSizeInMB> <!-- memtable に Store しておける最大 Column 数 --> <MemtableObjectCountInMillions>0.1</MemtableObjectCountInMillions> <!-- memtable から flush するまでの分指定 --> <MemtableFlushAfterMinutes>60</MemtableFlushAfterMinutes>
    40. 40. 設定の勘所ってどこ? <!-- リードとライトの並列数 --> <ConcurrentReads>8</ConcurrentReads> <ConcurrentWrites>32</ConcurrentWrites> <!-- CommitLog を同期する周期、 periodic は一定期間ごとに、 batch は明示的に CommitLog を書き出す --> <CommitLogSync>periodic</CommitLogSync> <!-- periodic の場合の周期設定。 --> <CommitLogSyncPeriodInMS>10000</CommitLogSyncPeriodInMS> <!-- オブジェクトに GC の削除マーカーをつける時間 --> <GCGraceSeconds>864000</GCGraceSeconds> <!-- memtable の最大値( MB ) --> <BinaryMemtableSizeInMB>256</BinaryMemtableSizeInMB>
    41. 41. 設定の勘所ってどこ? <ul><li>Directories </li></ul><ul><ul><li>ディスクの使い道としては、 [SStable:/usr/lib/cassandra/data][Commitlog:/usr/lib/cassandra/commitlog] の 2 つ </li></ul></ul><ul><ul><li>その 2 つに関してパーテション等を分けて I/O 分散した方が良い </li></ul></ul>
    42. 42. 管理はどうやるの? <ul><li>データ操作 </li></ul><ul><li>バックアップ/リストア </li></ul><ul><li>サーバ追加 </li></ul><ul><li>データ再配置 </li></ul><ul><li>サーバ監視 </li></ul>
    43. 43. 管理はどうやるの? <ul><li>データ操作 </li></ul><ul><ul><li>cassandra-cli コマンドで行えます </li></ul></ul><ul><ul><li>プログラムから読みたい場合は Thrift インターフェースで雛形が出せるのでそれを使いましょう </li></ul></ul>
    44. 44. 管理はどうやるの? <ul><li>サーバ追加 </li></ul><ul><ul><li>クラスタに参加しているサーバを Seed で追加して立ち上げればクラスタに入る </li></ul></ul><ul><ul><li>全サーバを Seed に書く必要はありません。 </li></ul></ul>
    45. 45. 管理はどうやるの? <ul><li>サーバ追加 </li></ul>RingA RingB RingC ここがハブになる形でも可
    46. 46. 管理はどうやるの? #### 状態確認 $ ./nodeprobe -host cass-test01 ring Address Status Load Range Ring 124039723817946554142311632841015584374 cass-test03 Up 1.5 GB 54726667172133563740938363913892816149 |<--| cass-test02 Up 767 MB 85116141055809869248935675462381407463 | | cass-test01 Up 643.61 MB 124039723817946554142311632841015584374 |-->| #### 設定追加 $ vi ../conf/storage-conf.xml <Seeds> <Seed>cass-test01</Seed> </Seeds> #### サーバ起動 $ ./cassandra -p ./cassandra.pid INFO - Replaying /var/lib/cassandra/commitlog/CommitLog-1269269853066.log INFO - Log replay complete INFO - Saved Token not found. Using 97147856872319332778007596849029295064 INFO - Starting up server gossip #### 状態確認 $ ./nodeprobe -host cass-test01 ring Address Status Load Range Ring 124039723817946554142311632841015584374 cass-test03 Up 1.5 GB 54726667172133563740938363913892816149 |<--| cass-test02 Up 767 MB 85116141055809869248935675462381407463 | | cass-test04 Up 1.47 KB 97147856872319332778007596849029295064 | | cass-test01 Up 643.61 MB 124039723817946554142311632841015584374 |-->|
    47. 47. 管理はどうやるの? <ul><li>データ再配置 </li></ul><ul><ul><li>nodetool コマンドで出来るよ </li></ul></ul><ul><ul><li>loadbalance コマンド </li></ul></ul><ul><ul><ul><li>データ展開 </li></ul></ul></ul><ul><ul><ul><li>他ノードへのデータ移動 </li></ul></ul></ul><ul><ul><ul><li>を自分の受け持ちレンジ毎にじわじわ行う </li></ul></ul></ul>
    48. 48. 管理はどうやるの? <ul><li>データ再配置 </li></ul>#####  データ再配置 $ /usr/local/cassandra-0.6.1/bin/nodetool -h localhost loadbalance
    49. 49. 管理はどうやるの? <ul><li>サーバ監視 </li></ul><ul><ul><li>nodetool コマンドで出来ますよ </li></ul></ul><ul><ul><li>tpstats コマンド </li></ul></ul>#####  スレッドの遷移統計 $ /usr/local/cassandra/bin/nodetool -host localhost tpstats Pool Name Active Pending Completed FILEUTILS-DELETE-POOL 0 0 18 STREAM-STAGE 0 0 0 RESPONSE-STAGE 0 0 4947787 ROW-READ-STAGE 0 0 314 LB-OPERATIONS 0 0 0 MESSAGE-DESERIALIZER-POOL 0 0 14089762 GMFD 0 0 309642 LB-TARGET 0 0 0 CONSISTENCY-MANAGER 0 0 0 ROW-MUTATION-STAGE 0 0 11206334 MESSAGE-STREAMING-POOL 0 0 0 LOAD-BALANCER-STAGE 0 0 0 FLUSH-SORTER-POOL 0 0 0 MEMTABLE-POST-FLUSHER 0 0 76 FLUSH-WRITER-POOL 0 0 76 AE-SERVICE-STAGE 0 0 1 HINTED-HANDOFF-POOL 0 0 8
    50. 50. 管理はどうやるの? <ul><li>サーバ監視 </li></ul><ul><ul><li>nodetool コマンドで出来ますよ </li></ul></ul><ul><ul><li>cfstats コマンド </li></ul></ul>$ /usr/local/cassandra/bin/nodetool -host localhost cfstats ---------------- Keyspace: <KeySpace> Read Count: 314 ( snip ) Key cache capacity: 1157568 Key cache size: 310 Key cache hit rate: 0.0 Row cache capacity: 10000 Row cache size: 72 Row cache hit rate: 0.7707006369426752 Compacted row minimum size: 228 Compacted row maximum size: 1357548 Compacted row mean size: 313 ----------------
    51. 51. 管理はどうやるの? <ul><li>バックアップ/リストア </li></ul><ul><ul><li>だから n (ry </li></ul></ul><ul><ul><li>snapshot コマンドで実行 </li></ul></ul><ul><ul><li>clearsnapshot で削除 </li></ul></ul>##### Memtable の書き出し $ /usr/local/cassandra/bin/nodetool -h localhost flush <KeySpace> ##### Snapshot の作成 $ /usr/local/cassandra/bin/nodetool -h localhost snapshot snapshottest ##### Snapshot が出来ているのを確認 $ ls /var/lib/cassandra/data/<KeySpace>/snapshots/1273757807243-snapshottest/ ##### Snapshot の削除 $ /usr/local/cassandra/bin/nodetool -h localhost clearsnapshot
    52. 52. 管理はどうやるの? <ul><li>バックアップ/リストア </li></ul><ul><ul><li>json <-> SStable でエクスポート、インポート出来る tool もあります </li></ul></ul>##### エクスポート $ ./sstable2json -f CfByte1-36-Data.json /var/lib/cassandra/data/KsName1/CfByte1-36-Data.db INFO - Sampling index for /var/lib/cassandra/data/KsName1/CfByte1-36-Data.db $ cat CfByte1-36-Data.json { &quot;test843352&quot;: [[&quot;746573746461746131&quot;, &quot;383433333532&quot;, 1269433709, false]], (snip) &quot;test851643&quot;: [[&quot;746573746461746131&quot;, &quot;383531363433&quot;, 1269433743, false]] } ##### インポート $ ./json2sstable -K KsName1 -c CfByte1 CfByte1-36-Data.json /var/lib/cassandra/data/KsName1/CfByte1-36-Data.db $
    53. 53. MySQL->Cassandra の移行例
    54. 54. 実際のカラムってどうなります? <ul><li>設定方法はわかったけどじゃあ MySQL を移行したい場合はどうしよう。 </li></ul><ul><ul><li>じゃあ実際に変更してみましょう。 </li></ul></ul>
    55. 55. 実際のカラムってどうなります? <ul><li>想定システムは? </li></ul><ul><ul><li>SNS のコミュニティのシステムの一部。 </li></ul></ul><ul><ul><ul><li>コミュニティの新着更新情報 </li></ul></ul></ul><ul><ul><li>実際のテーブル構造はこんな感じで。 </li></ul></ul>
    56. 56. テーブル構造 <ul><li>2 テーブルで構成します。 </li></ul>ユーザマスタ コミュニティマスタ コミュニティが更新 されたら更新日時を UPDATE Mac ユーザ B Solaris ユーザ C FreeBSD ユーザ D Solaris ユーザ A Linux ユーザ B Windows ユーザ C Plan9 ユーザ C Windows ユーザ A Linux ユーザ A コミュニティ ID UserID 1970/01/01 00:00:01 Plan9 2010/05/13 17:59:00 Solaris 2010/05/12 17:59:00 FreeBSD 2010/05/14 17:59:00 Linux 2010/05/10 01:00:00 Mac 2009/01/01 00:00:01 Windows 更新日時 コミュニティ ID
    57. 57. 参照クエリの処理 <ul><ul><li>ユーザマスタとコミュニティマスタをコミュニティ ID でリレーション </li></ul></ul><ul><ul><li>コミュニティマスタの更新日時でソート </li></ul></ul>
    58. 58. テーブル構造 <ul><li>ユーザ A のカラムをとってきた場合 </li></ul>ユーザマスタ コミュニティマスタ 更新日時でソートして表示 Solaris Windows Linux コミュニティ ID 2010/05/13 17:59:00 ユーザ A 2009/01/01 00:00:01 ユーザ A 2010/05/14 17:59:00 ユーザ A 更新日時 UserID Linux Solaris Windows コミュニティ ID 2010/05/14 17:59:00 ユーザ A 2010/05/13 17:59:00 ユーザ A 2009/01/01 00:00:01 ユーザ A 更新日時 UserID
    59. 59. これを Cassandra で置き換える <ul><li>カラム構造 </li></ul><ul><ul><li>こちらも 2 つの CF で表現 </li></ul></ul>
    60. 60. カラム構造 <ul><li>2 つの SuperColumn で構成します。 </li></ul>コミュニティマスタ コミュニティと、その所属ユーザの関連付け Plan9 Solaris FreeBSD Linux Mac Windows コミュニティ ID ユーザ B ユーザ A 所属ユーザ
    61. 61. カラム構造 <ul><li>2 つの SuperColumn で構成します。 </li></ul>ユーザマスタ コミュニティの更新日時をキーにする事でソートを考慮する必要が無くなる ユーザ D ユーザ B ユーザ C ユーザ A UserID Linux 2010/05/14 17:59:00 Solaris 2010/05/13 17:59:00 Windows 2009/01/01 00:00:01 コミュニティ ID 更新日時
    62. 62. 設定ファイル <ul><li>ColumnFamily としてはこのように書きます。 </li></ul><ul><li>これだけw </li></ul><ColumnFamily Name=&quot; コミュニティマスタ &quot; ColumnType=&quot;Super&quot; CompareWith=&quot;BytesType&quot; CompareSubcolumnsWith=&quot;BytesType&quot; /> <ColumnFamily Name=&quot; ユーザマスタ &quot; ColumnType=&quot;Super&quot; CompareWith=&quot;BytesType&quot; CompareSubcolumnsWith=&quot;TimeUUIDType&quot; />
    63. 63. 何が違う? <ul><ul><li>RDBMS ではリレーションを使っているが、 Cassandra はリレーションは行えない </li></ul></ul><ul><ul><li>RDBMS ではユーザ * 参加コミュニティ 数分のレコード数が必要になるが、 Cassandra では必要ないのでシンプルな構成 </li></ul></ul><ul><ul><li>Cassandra ではキーのソートが保障されているのでソートを考慮する必要がない。 </li></ul></ul><ul><li>でも同じような事が Cassandra でもできました </li></ul>
    64. 64. これからの話
    65. 65. 今後のロードマップ <ul><li>0.7 </li></ul><ul><ul><li>NameSpace 毎に Partitioner の指定 </li></ul></ul><ul><ul><li>動的カラム変更 </li></ul></ul><ul><ul><li>Avro 対応 </li></ul></ul><ul><li>0.8 </li></ul><ul><ul><li>index 実装 </li></ul></ul><ul><ul><li>VectorClock 実装 </li></ul></ul>
    66. 66. 現在の問題 <ul><li>動作が一部安定していない </li></ul><ul><ul><li>高負荷時に落ちる場合がある </li></ul></ul><ul><ul><ul><li>ソフトウェアの安定度は MySQL に及ばない </li></ul></ul></ul><ul><ul><li>バグは踏む前提でw </li></ul></ul>
    67. 67. 現在の問題 <ul><li>クライアントの冗長/分散は要ります </li></ul><ul><ul><li>kumo-gateway みたいな実装ではないので、 Thrift で特定サーバに繋ぎに行けなかった時には別のサーバに繋げるようにする必要があります。 </li></ul></ul>
    68. 68. 現在の問題 <ul><li>仕様が大胆に変わる </li></ul><ul><ul><li>現在の Trunk は設定ファイルで初期 ColumnFamily を設定できない。読まない。前述のカラムの動的変更の余波。 </li></ul></ul><ul><ul><li>0.7 から設定ファイルが XML から YAML に変わっている </li></ul></ul><ul><ul><li>XML->YAML 変換ツールは付属。でもそもそもの設定項目名が変わってたりしてるのであんま意味内 </li></ul></ul>
    69. 69. まとめ
    70. 70. Cassandra 自体は現在も開発が活発に進んでいて機能追加も凄いスピードでされている状態です。
    71. 71. 、、、正直インフラエンジニアとしてはまだプロダクトへの利用は怖いかなーと思います ボソッ
    72. 72. 要するに <ul><li>まだプロダクトにはいれてないよー。 </li></ul><ul><li>検証中だよー。 </li></ul><ul><li>                 ですw </li></ul>
    73. 73. ですが、非常に魅力的な物には違いないですので、人柱 ^H^H 先駆者になっておいて損は無いと思います。
    74. 74. 特に実際にプロダクトで使用した問題点がでてくるのはこれからだと思います。
    75. 75. みなさん使ってみましょう! そして語り合いましょう! 語り合いたいですw
    76. 76. 以上、ご清聴ありがとうございました。
    77. 77. 最後に裏番組の告知です
    78. 78. Cassandra Web Console
    79. 79. Cassandra Web Console
    80. 80. Cassandra Web Console
    81. 81. Cassandra Web Console
    82. 82. こんな話もやっている、アメーバ技術勉強会!
    83. 83. 今やってます!
    84. 84. ハッシュタグ #techameba にアクセス!
    85. 85. ustream もやっているので是非見て頂ければと思います。 録画もある(はずだ)よ!

    ×