Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
cassandra 入門 2回目 #TechLunch
Search
Livesense Inc.
PRO
April 23, 2014
Technology
0
67
cassandra 入門 2回目 #TechLunch
2012/04/18(水) @ Livesense TechLunch
発表者:春日 太志
Livesense Inc.
PRO
April 23, 2014
Tweet
Share
More Decks by Livesense Inc.
See All by Livesense Inc.
27新卒_総合職採用_会社説明資料
livesense
PRO
0
390
27新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
3.9k
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
85
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
0
1.6k
データ基盤の負債解消のためのリプレイス
livesense
PRO
0
480
26新卒_総合職採用_会社説明資料
livesense
PRO
0
12k
株式会社リブセンス会社紹介資料 / Invent the next common.
livesense
PRO
1
43k
26新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
1
13k
中途セールス職_会社説明資料
livesense
PRO
0
270
Other Decks in Technology
See All in Technology
kotlin-lsp の開発開始に触発されて、Emacs で Kotlin 開発に挑戦した記録 / kotlin‑lsp as a Catalyst: My Journey to Kotlin Development in Emacs
nabeo
2
160
マルチエージェントのチームビルディング_2025-10-25
shinoyamada
0
240
次世代のメールプロトコルの斜め読み
hirachan
1
190
20251029_Cursor Meetup Tokyo #02_MK_「あなたのAI、私のシェル」 - プロンプトインジェクションによるエージェントのハイジャック
mk0721
PRO
6
2.2k
猫でもわかるAmazon Q Developer CLI 解体新書
kentapapa
1
220
東京大学「Agile-X」のFPGA AIデザインハッカソンを制したソニーのAI最適化
sony
0
180
InsightX 会社説明資料/ Company deck
insightx
0
150
組織全員で向き合うAI Readyなデータ利活用
gappy50
5
2k
ソースを読む時の思考プロセスの例-MkDocs
sat
PRO
1
350
設計に疎いエンジニアでも始めやすいアーキテクチャドキュメント
phaya72
22
14k
RemoteFunctionを使ったコロケーション
mkazutaka
1
170
【SORACOM UG Explorer 2025】さらなる10年へ ~ SORACOM MVC 発表
soracom
PRO
0
200
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
40
2.1k
How STYLIGHT went responsive
nonsquared
100
5.9k
Building a Scalable Design System with Sketch
lauravandoore
463
33k
Being A Developer After 40
akosma
91
590k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Practical Orchestrator
shlominoach
190
11k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Reflections from 52 weeks, 52 projects
jeffersonlam
355
21k
Done Done
chrislema
186
16k
Designing for humans not robots
tammielis
254
26k
Transcript
@bar_̲row 2012年年02⽉月15⽇日 Cassandra 2回⽬目 Livesense Inc. 1
⽬目次 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
⽬目次 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
1-‐‑‒1. Eric Brewerʼ’s CAP Theorem Livesense Inc. 4 分散データシステムにおける以下3つの要求のうち 満たせるのは2つまで
可⽤用性 分断耐性 ⼀一貫性
1-‐‑‒2. Eric Brewerʼ’s CAP Theorem Livesense Inc. 5 すべてのデータベースクライアントは どのような並列列な更更新時においても
読み込みのクエリが同⼀一であれば 同じ結果しか返さない。 ⼀一貫性(Consistency) SELECT SUM(price) FROM order WHERE goods_id = 777; \127,000 \127,000
1-‐‑‒3. Eric Brewerʼ’s CAP Theorem Livesense Inc. 6 すべてのデータベースクライアントは 常にデータの書き込みと読み込みが
可能である。 可⽤用性(Availability) SELECT ʙ UPDATE ʙ LOCK SPoF
1-‐‑‒4. Eric Brewerʼ’s CAP Theorem Livesense Inc. 7 ネットワークセグメント障害に直⾯面しても 機能し続けることが可能である。
分断耐性(Partition Tolerance) Down SELECT ʙ UPDATE ʙ
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
⽬目次 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
2. Network Topology Livesense Inc. 10 Ring P2P P2P P2P
P2P P2P P2P ・⾮非中央集中型 ・Master/Slaveなし ・P2P分散モデル
⽬目次 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
3. Gossip Protocol Livesense Inc. 12 ・各ノードが別ノードの状態情報を保持する仕組み ・品質の悪いネットワークでの運⽤用に最適化 ・⼈人間の噂がコンセプト、他のノードの噂を流流す ・org.apache.cassandra.gms.Gossiper
・定期的にトポロジ内のランダムなノードと通信 1. GossipDigestSynMessage 2. GossipDigestAckMessage 3. GossipDigestAck2Message G 受
⽬目次 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
4. Φ Accrual Failure Detector Livesense Inc. 14 ・ハートビートの応答による2択判定では曖昧 ・ノードの故障率率率「容疑レベル」をレポート
・死んでたら「有罪判定」を宣告 ・org.apache.cassandra.gms.FailureDetector #isAlive(InetAddress) #interpret(InetAddress) #report(InetAddress) ...ノードの⽣生存レポートを出⼒力力 ...Φ計算で出た故障レベルに基づいた⽣生死判定 ...ハートビートを受け取った際に実⾏行行
⽬目次 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
5. Hinted Hand off Livesense Inc. 16 ・落落ちたノードに書き込み予定だった情報を 他のノードがヒントとしてメモ ・落落ちたノードが復復活したらメモを受け渡す
・可⽤用性を損なわないようにするための仕組み 【⽋欠点】 ・停⽌止時間が⻑⾧長いと周りのノードがメモだらけ ・復復活と同時に⼤大量量のメモ受け渡しが発⽣生してしまう ※無効にしたり、処理理優先度度を下げたりできる
⽬目次 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
6. Read Repair Livesense Inc. 18 ・⼀一貫していない古いデータをバックグラウンドで 最新の値に更更新する処理理 ・データの読み込み時にチェックして把握 ・タイムスタンプとチェックサムによって検出
・結果整合性(やがては⼀一貫する)
⽬目次 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
7-‐‑‒1. 設定可能な⼀一貫性 Livesense Inc. 20 ・Cassandraクラスタ内で各データのコピーを 何個配置するかを指定 ・ノード総数より多い値は設定できない ・Keyspace毎に設定可能 ・より重要なデータを保持するKeyspaceは
設定値を⼤大きくする ・読み込み/書き込み時の⼀一貫性指定の基準値になる Replication Factor
7-‐‑‒2. 設定可能な⼀一貫性(読み込み) Livesense Inc. 21 ZERO ANY ONE QUORUM ALL
設定不不可 設定不不可 最初のノードのデータを返す 最新であるとは限らない ⼤大半のノードが返答すると 最新のデータを返す 全ノードが返答すると最新のデータを返す 読み込み時のクエリに⼀一貫性を指定できる。
7-‐‑‒3. 設定可能な⼀一貫性(書き込み) Livesense Inc. 22 ZERO ANY ONE QUORUM ALL
即座に応答、⾮非同期、成功保証なし 最低1ノードへの書き込みを保証 ヒントもカウント 最低1ノードへの書き込みを保証 ⼤大半のノードへの書き込みを保証 全ノードへの書き込みを保証 書き込み時のクエリにも⼀一貫性を指定できる。
⽬目次 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
8-‐‑‒1. Memtable、SSTable、Commit Log Livesense Inc. 24 SSTable 書き込み操作の流流れ commit log
memtable Disk Memory Disk 同期 同期 ⾮非同期
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
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
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でマージされ圧縮される
⽬目次 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
9. Compaction Livesense Inc. 29 ・データファイルの圧縮処理理 ・SSTableのデータがマージされる ・Key のマージ ・Column
の結合 ・データの削除 ・indexの再作成 ・org.apache.cassandra.db.compaction.CompactionManager
⽬目次 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
10. Tombstone Livesense Inc. 31 ・トゥームストーン(墓⽯石) ・Cassandraではデータはすぐに削除されない ・削除操作を⾏行行うと内部的に⽬目印が付けられる ・Compaction実⾏行行時に⽬目印が付いたデータが消える ・GCGraceSecondsでGCの待ち時間を設定
・落落ちたノードの復復旧時間を確保するための遅延
⽬目次 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
11. Bloom Filter Livesense Inc. 33 ・要素があるメンバーの集合にあるかどうかを検査する ⾼高速な⾮非決定性アルゴリズム ・クエリ実⾏行行時に最初にチェックされる ・メモリ上で動作
・キー探索索時のディスクアクセスを減らすことが⽬目的
⽬目次 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
12. Staged Event Driven Architecture Livesense Inc. 35 ・Cassandraの並⾏行行モデルはSEDAをベースにしている ・処理理をステージごとに細かく分割して並⾏行行実⾏行行
・ステージごとに動作するThreadが異異なる ・ステージに関連付けられたThread Poolが実⾏行行を制御 ・java.util.concurrent.ExecutorService ・org.apache.cassandra.concurrent.StageManager