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
66
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新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
76
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
14
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
0
1.4k
データ基盤の負債解消のためのリプレイス
livesense
PRO
0
390
26新卒_総合職採用_会社説明資料
livesense
PRO
0
8.8k
株式会社リブセンス会社紹介資料 / Invent the next common.
livesense
PRO
1
27k
26新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
1
12k
中途セールス職_会社説明資料
livesense
PRO
0
250
EM候補者向け転職会議説明資料
livesense
PRO
0
120
Other Decks in Technology
See All in Technology
標準技術と独自システムで作る「つらくない」SaaS アカウント管理 / Effortless SaaS Account Management with Standard Technologies & Custom Systems
yuyatakeyama
3
1.3k
Oracle Cloud Infrastructure:2025年6月度サービス・アップデート
oracle4engineer
PRO
2
310
Yamla: Rustでつくるリアルタイム性を追求した機械学習基盤 / Yamla: A Rust-Based Machine Learning Platform Pursuing Real-Time Capabilities
lycorptech_jp
PRO
4
160
PHPでWebブラウザのレンダリングエンジンを実装する
dip_tech
PRO
0
210
より良いプロダクトの開発を目指して - 情報を中心としたプロダクト開発 #phpcon #phpcon2025
bengo4com
1
3.2k
OpenHands🤲にContributeしてみた
kotauchisunsun
1
490
Prox Industries株式会社 会社紹介資料
proxindustries
0
340
「良さそう」と「とても良い」の間には 「良さそうだがホンマか」がたくさんある / 2025.07.01 LLM品質Night
smiyawaki0820
1
420
2025-06-26_Lightning_Talk_for_Lightning_Talks
_hashimo2
2
110
5min GuardDuty Extended Threat Detection EKS
takakuni
0
180
Wasm元年
askua
0
160
生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction
nwiizo
4
3.1k
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
Making Projects Easy
brettharned
116
6.3k
Fireside Chat
paigeccino
37
3.5k
Typedesign – Prime Four
hannesfritz
42
2.7k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Thoughts on Productivity
jonyablonski
69
4.7k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
How to train your dragon (web standard)
notwaldorf
94
6.1k
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