cassandra 入門 2回目 #TechLunch

Transcript

1. @bar_̲row  2012年年02⽉月15⽇日 Cassandra 2回⽬目 Livesense  Inc. 1

2. ⽬目次 Livesense  Inc. 2 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

   Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

3. ⽬目次 Livesense  Inc. 3 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

   Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

4. 1-‐‑‒1.  Eric  Brewerʼ’s  CAP  Theorem Livesense  Inc. 4 分散データシステムにおける以下3つの要求のうち 満たせるのは2つまで

   可⽤用性 分断耐性 ⼀一貫性

5. 1-‐‑‒2.  Eric  Brewerʼ’s  CAP  Theorem Livesense  Inc. 5 すべてのデータベースクライアントは どのような並列列な更更新時においても

   読み込みのクエリが同⼀一であれば 同じ結果しか返さない。 ⼀一貫性（Consistency） SELECT SUM(price) FROM order WHERE goods_id = 777; \127,000 \127,000

6. 1-‐‑‒3.  Eric  Brewerʼ’s  CAP  Theorem Livesense  Inc. 6 すべてのデータベースクライアントは 常にデータの書き込みと読み込みが

   可能である。 可⽤用性（Availability） SELECT ʙ UPDATE ʙ LOCK SPoF

7. 1-‐‑‒4.  Eric  Brewerʼ’s  CAP  Theorem Livesense  Inc. 7 ネットワークセグメント障害に直⾯面しても 機能し続けることが可能である。

   分断耐性（Partition  Tolerance） Down SELECT ʙ UPDATE ʙ

8. 1-‐‑‒5.  Eric  Brewerʼ’s  CAP  Theorem Livesense  Inc. 8 C A

   P MySQL SQL  Server Postgres Neo4J    Bigtable    MongoDB    HBase Hypertable    Redis Dynamo Cassandra Voldemort CouchDB Riak

9. ⽬目次 Livesense  Inc. 9 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

   Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

10. 2.  Network  Topology Livesense  Inc. 10 Ring P2P P2P P2P

    P2P P2P P2P ・⾮非中央集中型 ・Master/Slaveなし ・P2P分散モデル

11. ⽬目次 Livesense  Inc. 11 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

    Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

12. 3.  Gossip  Protocol Livesense  Inc. 12 ・各ノードが別ノードの状態情報を保持する仕組み ・品質の悪いネットワークでの運⽤用に最適化 ・⼈人間の噂がコンセプト、他のノードの噂を流流す ・org.apache.cassandra.gms.Gossiper

    ・定期的にトポロジ内のランダムなノードと通信 1.  GossipDigestSynMessage 2.  GossipDigestAckMessage 3.  GossipDigestAck2Message G 受

13. ⽬目次 Livesense  Inc. 13 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

    Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

14. 4.  Φ  Accrual  Failure  Detector Livesense  Inc. 14 ・ハートビートの応答による2択判定では曖昧 ・ノードの故障率率率「容疑レベル」をレポート

    ・死んでたら「有罪判定」を宣告 ・org.apache.cassandra.gms.FailureDetector #isAlive(InetAddress) #interpret(InetAddress) #report(InetAddress) ...ノードの⽣生存レポートを出⼒力力 ...Φ計算で出た故障レベルに基づいた⽣生死判定 ...ハートビートを受け取った際に実⾏行行

15. ⽬目次 Livesense  Inc. 15 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

    Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

16. 5.  Hinted  Hand  off Livesense  Inc. 16 ・落落ちたノードに書き込み予定だった情報を  　他のノードがヒントとしてメモ ・落落ちたノードが復復活したらメモを受け渡す

    ・可⽤用性を損なわないようにするための仕組み 【⽋欠点】 ・停⽌止時間が⻑⾧長いと周りのノードがメモだらけ ・復復活と同時に⼤大量量のメモ受け渡しが発⽣生してしまう ※無効にしたり、処理理優先度度を下げたりできる

17. ⽬目次 Livesense  Inc. 17 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

    Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

18. 6.  Read  Repair Livesense  Inc. 18 ・⼀一貫していない古いデータをバックグラウンドで  　最新の値に更更新する処理理 ・データの読み込み時にチェックして把握 ・タイムスタンプとチェックサムによって検出

    ・結果整合性（やがては⼀一貫する）

19. ⽬目次 Livesense  Inc. 19 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

    Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

20. 7-‐‑‒1.  設定可能な⼀一貫性 Livesense  Inc. 20 ・Cassandraクラスタ内で各データのコピーを  　何個配置するかを指定 ・ノード総数より多い値は設定できない ・Keyspace毎に設定可能 ・より重要なデータを保持するKeyspaceは

     　設定値を⼤大きくする ・読み込み／書き込み時の⼀一貫性指定の基準値になる Replication  Factor

21. 7-‐‑‒2.  設定可能な⼀一貫性（読み込み） Livesense  Inc. 21 ZERO ANY ONE QUORUM ALL

    設定不不可 設定不不可 最初のノードのデータを返す 最新であるとは限らない ⼤大半のノードが返答すると 最新のデータを返す 全ノードが返答すると最新のデータを返す 読み込み時のクエリに⼀一貫性を指定できる。

22. 7-‐‑‒3.  設定可能な⼀一貫性（書き込み） Livesense  Inc. 22 ZERO ANY ONE QUORUM ALL

    即座に応答、⾮非同期、成功保証なし 最低1ノードへの書き込みを保証 ヒントもカウント 最低1ノードへの書き込みを保証 ⼤大半のノードへの書き込みを保証 全ノードへの書き込みを保証 書き込み時のクエリにも⼀一貫性を指定できる。

23. ⽬目次 Livesense  Inc. 23 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

    Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

24. 8-‐‑‒1.  Memtable、SSTable、Commit  Log Livesense  Inc. 24 SSTable 書き込み操作の流流れ commit log

    memtable Disk Memory Disk 同期 同期 ⾮非同期

25. 8-‐‑‒2.  Memtable、SSTable、Commit  Log Livesense  Inc. 25 Commit  Log ・Cassandraのすべての書き込み記録 ・更更新時に必ず最初に記録

    ・追記モードで記録 ・org.apache.cassandra.db.commitlog.CommitLog ・RowMutationオブジェクトをserializeして追記 ・commitlog_̲rotation_̲threshold_̲in_̲mbで  　ファイルサイズ指定、デフォルトは128MB

26. 8-‐‑‒3.  Memtable、SSTable、Commit  Log Livesense  Inc. 26 Memtable ・ColumnFamilyごとに1つのmemtableを持つ ・memtable_̲throughput_̲in_̲mbでメモリ上に  　展開できる最⼤大サイズを指定

    ・memtable_̲operations_̲in_̲millionsでdiskへflash  　される前に保持できるColumn数の閾値を指定 ・org.apache.cassandra.db.Memtable

27. 8-‐‑‒4.  Memtable、SSTable、Commit  Log Livesense  Inc. 27 SSTable ・Memtableからflashされたデータファイル ・data／index／filterの3つのファイルで構成 ・Sorted

     String  Table  の略略で  Bigtable  から継承 ・⼀一度度flashされたら不不変となる ・追記モードでflashされる ・JSON形式でimport／exportが可能 ・Compactionでマージされ圧縮される

28. ⽬目次 Livesense  Inc. 28 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

    Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

29. 9.  Compaction Livesense  Inc. 29 ・データファイルの圧縮処理理 ・SSTableのデータがマージされる ・Key  のマージ ・Column

     の結合 ・データの削除 ・indexの再作成 ・org.apache.cassandra.db.compaction.CompactionManager

30. ⽬目次 Livesense  Inc. 30 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

    Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

31. 10.  Tombstone Livesense  Inc. 31 ・トゥームストーン（墓⽯石） ・Cassandraではデータはすぐに削除されない ・削除操作を⾏行行うと内部的に⽬目印が付けられる ・Compaction実⾏行行時に⽬目印が付いたデータが消える ・GCGraceSecondsでGCの待ち時間を設定

    ・落落ちたノードの復復旧時間を確保するための遅延

32. ⽬目次 Livesense  Inc. 32 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

    Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

33. 11.  Bloom  Filter Livesense  Inc. 33 ・要素があるメンバーの集合にあるかどうかを検査する  　⾼高速な⾮非決定性アルゴリズム ・クエリ実⾏行行時に最初にチェックされる ・メモリ上で動作

    ・キー探索索時のディスクアクセスを減らすことが⽬目的

34. ⽬目次 Livesense  Inc. 34 1.  Eric  Brewerʼ’s  CAP  Theorem 2. 

    Network  Topology 3.  Gossip  Protocol 4.  Φ  Accrual  Failure  Detector 5.  Hinted  Hand  off 6.  Read  Repair 7.  設定可能な⼀一貫性 8.  Memtable、SSTable、Commit  Log 9.  Compaction 10. Tombstone 11. Bloom  Filter 12. Staged  Event  Driven  Architecture

35. 12.  Staged  Event  Driven  Architecture Livesense  Inc. 35 ・Cassandraの並⾏行行モデルはSEDAをベースにしている ・処理理をステージごとに細かく分割して並⾏行行実⾏行行

    ・ステージごとに動作するThreadが異異なる ・ステージに関連付けられたThread  Poolが実⾏行行を制御 ・java.util.concurrent.ExecutorService ・org.apache.cassandra.concurrent.StageManager