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
52
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.
EM候補者向け転職会議説明資料
livesense
PRO
0
6
コロナで失われたノベルティ作成ノウハウを復活させた話
livesense
PRO
0
73
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
0
360
転職会議でGPT-3を活用した企業口コミ要約機能をリリースした話
livesense
PRO
0
1k
株式会社リブセンス マッハバイト_プレイブック
livesense
PRO
0
410
Tech Award 2021 選出方法
livesense
PRO
0
1k
株式会社リブセンス エンジニアリング組織を支える風土と制度
livesense
PRO
0
530
株式会社リブセンス・マッハバイト 採用候補者様向け資料
livesense
PRO
0
210
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
2k
Other Decks in Technology
See All in Technology
プロトタイピングによる不確実性の低減 / Reducing Uncertainty through Prototyping
ohbarye
5
380
Janus
bkuhlmann
1
490
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
6
3.8k
地理空間データ可視化・解析・活用ソリューション Pacific Spatial Solutions (PSS)
pacificspatialsolutions
0
270
Java EE/Jakarta EEの現状と将来―クラウドネイティブ時代にJava EEは対応できるのか?―
takakiyo
1
160
生産性向上チームの紹介
cybozuinsideout
PRO
1
870
Compose Compiler Metricsを使った実践的なコードレビュー
tomorrowkey
1
220
AOAI をきっかけに 社内の Azure 管理を見直した話
recruitengineers
PRO
1
280
開発パフォーマンスを最大化するための開発体制
ham0215
2
410
元インフラエンジニアに成る / Human Resources to Human Relations
bobtani
4
920
ワールドカフェI /チューターを改良する / World Café I and Improving the Tutors
ks91
PRO
0
120
推しは推せるときに推せ! プロダクトにフィードバックしていこう
nakasho
0
310
Featured
See All Featured
Designing for humans not robots
tammielis
248
25k
Building Adaptive Systems
keathley
31
1.9k
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
The MySQL Ecosystem @ GitHub 2015
samlambert
243
12k
KATA
mclloyd
15
12k
Bootstrapping a Software Product
garrettdimon
PRO
302
110k
We Have a Design System, Now What?
morganepeng
43
6.7k
Mobile First: as difficult as doing things right
swwweet
216
8.6k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
17
1.4k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
244
20k
Building Effective Engineering Teams - LeadDev
addyosmani
28
1.8k
Build The Right Thing And Hit Your Dates
maggiecrowley
24
2k
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