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の活用事例とパフォーマンス特性
Search
Tomohiro Hashidate
June 04, 2019
Technology
3
1.2k
Cassandraの活用事例とパフォーマンス特性
Repro Tech LT発表資料
Tomohiro Hashidate
June 04, 2019
Tweet
Share
More Decks by Tomohiro Hashidate
See All by Tomohiro Hashidate
本番のトラフィック量でHudiを検証して見えてきた課題
joker1007
2
820
5分で分かった気になるDebezium
joker1007
1
68
Rustで作るtree-sitterパーサーのRubyバインディング
joker1007
5
1k
tree-sitter-rbsで作って学ぶRBSとパーサージェネレーター
joker1007
3
240
Kafka Streamsで作る10万rpsを支えるイベント駆動マイクロサービス
joker1007
7
3.3k
neovimで作る最新Ruby開発環境2023
joker1007
2
4.2k
ReproのImport/Exportを支えるサーバーレスアーキテクチャ
joker1007
1
1.3k
Ruby on Rails on Lambda
joker1007
13
13k
Sidekiq to Kafka ストリームベースのmicro services
joker1007
4
8.9k
Other Decks in Technology
See All in Technology
Developers Summit 2025 浅野卓也(13-B-7 LegalOn Technologies)
legalontechnologies
PRO
1
1.3k
データマネジメントのトレードオフに立ち向かう
ikkimiyazaki
6
1.2k
Classmethod AI Talks(CATs) #17 司会進行スライド(2025.02.19) / classmethod-ai-talks-aka-cats_moderator-slides_vol17_2025-02-19
shinyaa31
0
160
PHPカンファレンス名古屋-テックリードの経験から学んだ設計の教訓
hayatokudou
2
510
Building Products in the LLM Era
ymatsuwitter
10
6.1k
Exadata Database Service on Cloud@Customer セキュリティ、ネットワーク、および管理について
oracle4engineer
PRO
1
1.5k
プロダクトエンジニア構想を立ち上げ、プロダクト志向な組織への成長を続けている話 / grow into a product-oriented organization
hiro_torii
1
290
コンピュータビジョンの社会実装について考えていたらゲームを作っていた話
takmin
1
480
株式会社EventHub・エンジニア採用資料
eventhub
0
4.3k
システム・ML活用を広げるdbtのデータモデリング / Expanding System & ML Use with dbt Modeling
i125
1
250
「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly
i35_267
1
520
EDRの検知の仕組みと検知回避について
chayakonanaika
2
530
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
133
33k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Building an army of robots
kneath
303
45k
Adopting Sorbet at Scale
ufuk
74
9.2k
Building Applications with DynamoDB
mza
93
6.2k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
Side Projects
sachag
452
42k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Transcript
Cassandra の活⽤事例とパフォーマンス特性 joker1007 (Repro inc. CTO)
self.inspect @joker1007 Ruby/Rails/fluentd/presto/infra ⼤体アーキテクト業 今はkafka とkudu に興味がある
話すこと Repro でのCassandra の活⽤⽬的 Cassandra の選定理由 Cassandra のパフォーマンス特性と設計時の注意 話さないこと 運⽤時の細かな注意点
何のために 端末情報記録 ユーザープロフィール情報 イベント実⾏回数 / user リアルタイムで更新される情報の保持がメイン
何故Cassandra を選択したか 書き込み回数が⾮常に多い かつ読み込み時に100 万件単位で取得しJOIN する必要がある 組み合わせる対象として、数⼗⽇分の⾏動ログを含む。 書き込みがスケールし、当時からセグメンテーションに利⽤していたpresto と連携が 可能で、読み込みもある程度分散できるデータストアが必要。
→ Cassandra を採⽤。
Cassandra のパフォーマンス特性
書き込みの概要 Client Client R2 R2 R3 R3 1 1 2
3 4 4 5 6 7 8 9 10 11 12 R1 R1 Write response Chosen node Coordinator node https://docs.datastax.com/ja/cassandra- jajp/3.0/cassandra/dml/dmlClientRequestsWrite.html
書き込みの概要 https://docs.datastax.com/ja/cassandra- jajp/3.0/cassandra/dml/dmlHowDataWritten.html
書き込みパフォーマンス特性 パーティション対象の決定とmemtable 、transaction log が書ければOK 。 最終的なテーブルファイルは不変なので、書き出しがシンプル。 パーティションさえ均等なら割と簡単にスケールする ⼀件単位の書き込みは、ほぼ100 マイクロ秒以下
現時点で20000/sec ぐらいの書き込みがある 整合性を保ってカウントアップする処理は重い 複数ノードを跨いでCAS やロックが必要になる
読み込みの概要 Client Client R2 R2 R3 R3 1 1 2
3 4 4 5 6 7 8 9 10 11 12 R1 R1 replica node failed coodinator node resends after timeout Chosen node Coordinator node https://docs.datastax.com/ja/cassandra- jajp/3.0/cassandra/dml/dmlClientRequestsRead.html
読み込みの概要 https://docs.datastax.com/ja/cassandra-jajp/3.0/cassandra/dml/dmlAboutReads.html
読み込みパフォーマンス特性 ⼀件単位の読み込みに向いている 多くのデータをまとめて取得するには不向き 取得対象のパーティションとノード特定にCPU を使う クラスタのノード間でデータの通信が多く発⽣する パーティション毎のdigest 要求 read repair
presto での利⽤は本来は不向き パーティション数とノード数でバランスを取ることで 何とか⽬的のパフォーマンスを維持
テーブル設計の重要性 読み込みワークロードに合わせてテーブルを設計する、でないとまともにパフォ ーマンスが出ない。 ユースケース毎にテーブルがあり、データの重複は覚悟する。 とにかくパーティションキー以外を条件にクエリしないこと。
まとめ 読み込みパターンに合わせたテーブル設計をすること ⽤途が適切ならかなりのパフォーマンスが出せる パーティション数とデータの分散度合いのコントロールが重要
その他のTips CPU 、ディスクI/O 、ネットワークそれぞれかなり影響があるのでメトリックをち ゃんと取得しておくこと ホットデータはオンメモリで読み書きするのでメモリは多く セカンダリインデックスは基本使えない