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
62
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.
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
0
770
26新卒_総合職採用_会社説明資料
livesense
PRO
0
1.4k
株式会社リブセンス会社紹介資料 / Invent the next common.
livesense
PRO
1
8.8k
26新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
1
5k
中途セールス職_会社説明資料
livesense
PRO
0
140
EM候補者向け転職会議説明資料
livesense
PRO
0
58
コロナで失われたノベルティ作成ノウハウを復活させた話
livesense
PRO
0
180
転職会議でGPT-3を活用した企業口コミ要約機能をリリースした話
livesense
PRO
0
1.2k
株式会社リブセンス マッハバイト_プレイブック
livesense
PRO
0
720
Other Decks in Technology
See All in Technology
強いチームと開発生産性
onk
PRO
36
12k
LINEヤフーにおけるPrerender技術の導入とその効果
narirou
1
160
TypeScriptの次なる大進化なるか!? 条件型を返り値とする関数の型推論
uhyo
2
1.7k
個人でもIAM Identity Centerを使おう!(アクセス管理編)
ryder472
4
240
アジャイルチームがらしさを発揮するための目標づくり / Making the goal and enabling the team
kakehashi
3
160
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
2
230
エンジニア人生の拡張性を高める 「探索型キャリア設計」の提案
tenshoku_draft
1
130
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
1.4k
10XにおけるData Contractの導入について: Data Contract事例共有会
10xinc
7
690
アジャイルでの品質の進化 Agile in Motion vol.1/20241118 Hiroyuki Sato
shift_evolve
0
180
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
150
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
364
19k
The Cost Of JavaScript in 2023
addyosmani
45
6.8k
Gamification - CAS2011
davidbonilla
80
5k
Teambox: Starting and Learning
jrom
133
8.8k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
The Cult of Friendly URLs
andyhume
78
6k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Side Projects
sachag
452
42k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
Being A Developer After 40
akosma
87
590k
Building an army of robots
kneath
302
43k
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