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
72
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
2.6k
27新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
0
6.6k
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
190
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
0
1.6k
データ基盤の負債解消のためのリプレイス
livesense
PRO
0
550
26新卒_総合職採用_会社説明資料
livesense
PRO
0
13k
株式会社リブセンス会社紹介資料 / Invent the next common.
livesense
PRO
2
52k
26新卒_Webエンジニア職採用_会社説明資料
livesense
PRO
1
13k
中途セールス職_会社説明資料
livesense
PRO
0
290
Other Decks in Technology
See All in Technology
配列に見る bash と zsh の違い
kazzpapa3
3
170
モダンUIでフルサーバーレスなAIエージェントをAmplifyとCDKでサクッとデプロイしよう
minorun365
4
220
今こそ学びたいKubernetesネットワーク ~CNIが繋ぐNWとプラットフォームの「フラッと」な対話
logica0419
5
360
Embedded SREの終わりを設計する 「なんとなく」から計画的な自立支援へ
sansantech
PRO
3
2.6k
Amazon Bedrock Knowledge Basesチャンキング解説!
aoinoguchi
0
160
OpenShiftでllm-dを動かそう!
jpishikawa
0
140
AzureでのIaC - Bicep? Terraform? それ早く言ってよ会議
torumakabe
1
600
広告の効果検証を題材にした因果推論の精度検証について
zozotech
PRO
0
210
コスト削減から「セキュリティと利便性」を担うプラットフォームへ
sansantech
PRO
3
1.6k
SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント
rvirus0817
0
340
Oracle AI Database移行・アップグレード勉強会 - RAT活用編
oracle4engineer
PRO
0
110
Context Engineeringが企業で不可欠になる理由
hirosatogamo
PRO
3
660
Featured
See All Featured
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
310
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.4k
Utilizing Notion as your number one productivity tool
mfonobong
3
220
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
650
WCS-LA-2024
lcolladotor
0
450
Kristin Tynski - Automating Marketing Tasks With AI
techseoconnect
PRO
0
150
Leo the Paperboy
mayatellez
4
1.4k
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
55
Optimizing for Happiness
mojombo
379
71k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.6k
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
71
Abbi's Birthday
coloredviolet
1
4.8k
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