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
rubygem開発で鍛える設計力
joker1007
3
850
実践Kafka Streams 〜イベント駆動型アーキテクチャを添えて〜
joker1007
3
990
本番のトラフィック量でHudiを検証して見えてきた課題
joker1007
2
1k
5分で分かった気になるDebezium
joker1007
1
110
Rustで作るtree-sitterパーサーのRubyバインディング
joker1007
5
1.3k
tree-sitter-rbsで作って学ぶRBSとパーサージェネレーター
joker1007
3
280
Kafka Streamsで作る10万rpsを支えるイベント駆動マイクロサービス
joker1007
7
4.7k
neovimで作る最新Ruby開発環境2023
joker1007
3
4.4k
ReproのImport/Exportを支えるサーバーレスアーキテクチャ
joker1007
1
1.3k
Other Decks in Technology
See All in Technology
ゼロから始めるSREの事業貢献 - 生成AI時代のSRE成長戦略と実践 / Starting SRE from Day One
shinyorke
PRO
0
230
Railsの限界を超えろ!「家族アルバム みてね」の画像・動画の大規模アップロードを支えるアーキテクチャの変遷
ojima_h
3
390
Semantic Machine Intelligence for Vision, Language, and Actions
keio_smilab
PRO
2
390
公開初日に個人環境で試した Gemini CLI 体験記など / Gemini CLI実験レポート
you
PRO
3
310
BEYOND THE RAG🚀 ~とりあえずRAG?を超えていけ! 本当に使えるAIエージェント&生成AIプロダクトを目指して~ / BEYOND-THE-RAG-Toward Practical-GenerativeAI-Products-AOAI-DevDay-2025
jnymyk
4
230
claude codeでPrompt Engineering
iori0311
0
430
PdM業務における使い分け
shinshiro
0
580
エンジニアリングマネージャー“お悩み相談”パネルセッション
ar_tama
1
650
AI時代にも変わらぬ価値を発揮したい: インフラ・クラウドを切り口にユーザー価値と非機能要件に向き合ってエンジニアとしての地力を培う
netmarkjp
0
220
スプリントゴール未達症候群に送る処方箋
kakehashi
PRO
1
190
機械学習を「社会実装」するということ 2025年夏版 / Social Implementation of Machine Learning July 2025 Version
moepy_stats
1
550
Wasmで社内ツールを作って配布しよう
askua
0
110
Featured
See All Featured
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
How GitHub (no longer) Works
holman
314
140k
How to train your dragon (web standard)
notwaldorf
96
6.1k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Faster Mobile Websites
deanohume
308
31k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
850
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
370
How to Think Like a Performance Engineer
csswizardry
25
1.8k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Writing Fast Ruby
sferik
628
62k
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 、ネットワークそれぞれかなり影響があるのでメトリックをち ゃんと取得しておくこと ホットデータはオンメモリで読み書きするのでメモリは多く セカンダリインデックスは基本使えない