[db tech showcase Tokyo 2016] D27: Next Generation Apache Cassandra by ヤフー株式会社星井祥吾

Next Generation
Apache Cassandra
データ＆サイエンスソリューション統括本部
データプラットフォーム本部開発３部KVS
星井祥吾

今日のアジェンダ
• 自己紹介
• Cassandra利用状況
• Cassandra利用事例
• NGCCとは？
• NGCC発表内容
• NGCC重要トピック
• 最後に
2

• 自己紹介
• NGCCとは？
• 最後に
3

• Cassandraオペレータ
– 広告部署から全社KVSチームに異動 -> サービス側にKVSプラット
フォームを提供、運用
• Cassandra自動デプロイシステムの刷新を担当
– Chef
– Jenkins
• Cassandraコントリビュータ
– https://github.com/shoshii
• Video gamer
– PSN ID: kobuchizawa0102
自己紹介
4

• 自己紹介
• NGCCとは？
• 最後に
5

提供サービス
Media
US
Search Video Answer Mail
JP
US
JP
Membership C2C Payment C2C EC B2C EC Local
Search Knowledge search MailNews
YAHUOKU!Premium Wallet Loco

利用データベース
7
300
Systems
Yahoo! JAPAN
Cassandra利用シ
ステムは約100

Cassandraクラスタ状況
8
50
clusters
30TB
usages
1000
nodes
300,000
read/sec
100,000
write/sec
2016
10
nodes
160
nodes
…
1
Common
clusters
50
Special
clusters
50
systems
50
systems
3
DCs

• 自己紹介
• NGCCとは？
• 最後に
9

利用事例 #1 : パーソナルデータ
• 月間3000万のアクティブユーザーID属性
• 弊社プライバシーポリシー[1]に基づき、各サービスに応じて
様々な属性を格納
10
個人属性
[1] Yahoo! JAPAN利用規約第2章プライバシーポリシー
エンドユーザの趣味嗜好
アプリ通知メッセージ

利用事例 #2 : 行動履歴
• 弊社プライバシーポリシー[1]に基づき、各サービスの履歴
データを格納
11
[1] Yahoo! JAPAN利用規約第2章プライバシーポリシー
行動履歴
広告クリック履歴・CV履歴
リアルタイム検索ツイート閲覧ログ

利用事例 #3 : コンテンツキャッシュ
• RDBのコンテンツ情報や、集計情報などを格納し、各サービ
スのスケールアウトに活用
12
メタデータ
集計情報
電子書籍：商品ID、レコメ情報
ニュース：テーマID、記事ID、記事内容

• 自己紹介
• NGCCとは？
• 最後に
13

Next Generation Cassandra Conference
• Cassandraトップコントリビュータが集まる国際会議
• ほぼDataStax社の主要メンバで構成されるが、最近は
外部メンバの取り込みに積極的
• 各自が議題を持ち寄って議論する
– 専任のファシリテータがいないので、待ちの姿勢だと議論に参
加できないことも
• 今年で３年目、３回目の開催
• youtube公開動画：資料末尾の付録参照
14

弊社注目ポイント
• （弊社発表分）コネクション過多時の問題の解決
• 巨大パーティション対応
15

• 自己紹介
• NGCCとは？
• 最後に
16

How to manage 30,000+
connections
17

Cassandra process goes down when too many clients
connect it
19
Client machine
Apache child process
Client machine
Client machine

• 200 client machines
connect it
20

• 200 client machines * 128 apache child
processes
connect it
21

processes * 2 (request + heart beat) =
connect it
22

processes * 2 (request + heart beat) =
51,200 connections / node
connect it
23

connect it
24
Client machine
51,200 > 32,768 ( max open file num )
Client machine
Client machine
写真：アフロ

connect it
25
Process down
写真：アフロ

connect it
26
Process down
写真：アフロ

Cassandra Proxy
28
写真：アフロ

Our solution ~ Cassandra Proxy
29
Client machine
Cassandra Proxy
Client machine
Client machine
写真：アフロ

• 200 client machines
30

processes
31

processes 1 proxy
32写真：アフロ

processes 1 proxy * 2 (request + heart beat)
=
33
写真：アフロ

processes 1 proxy * 2 (request + heart beat)
= 400 connections / node
34
写真：アフロ

• 51,200 -> 400 connections / node
35
写真：アフロ

• Stress test
– 1 msec / request (95%)
– 1 Cassandra Proxy can send 300 requests/sec
to C*
Consequences
37
写真：アフロ

• Production
– 370 client machines – 33 Cassandra nodes
– 3,000 read requests / sec (cluster)
• To be 100,000 read requests / sec
– Advertisement platform
– Available on datastax cpp driver
Consequences
38

• In the future?
– Cassandra Proxy could become one of the
functions of datastax cpp driver?
Consequences
39

• 自己紹介
• NGCCとは？
• 最後に
40

Large partition in Cassandra
41

remark
• This is a summary of following tickets:
– https://issues.apache.org/jira/browse/CASSANDRA-11206

Agenda
• Recap the read path
• What’s the problem?
• Solutions

High level: read path
Row Cache
Key Cache
SSTables Mem Table
1. Check row cache before going to key cache
2. Check the key cache to get the
offsets to data
3. Find the offsets to data and retrieve data
4. Merge data from sstables and memtable
5. Populate row cache with new row returned
http://docs.datastax.com/en/cassandra/3.x/cassandra/dml/dmlAboutReads.html

Pattern 1. The row is in row cache
Partition
Summary
Disk
Mem Table
Compression
Offsets
Bloom Filter
Row Cache
Heap Off Heap
Key Cache
Partition
Index
Data
1. read request
2. return row when that is in row cache

Pattern 2. The key is in key cache
Partition
Summary
Disk
Mem Table
Compression
Offsets
Bloom Filter
Row Cache
Heap Off Heap
Key Cache
Partition
Index
Data
1. read request
2. Check bloom filters 3. Check the partition key is in key cache
4. Find the offset to the result set
5. Access the result set

Pattern 3. The key is not cached
Partition
Summary
Disk
Mem Table
Compression
Offsets
Bloom Filter
Row Cache
Heap Off Heap
Key Cache
Partition
Index
Data
1. read request
2. Miss -> Check bloom filters
3. Check the partition key is in key cache
4. Miss -> Bsearch the close location of index
5. Disk scan to find the offsets 6. Find the offset into the result set
8. Update key cache

What’s the problem?
• GC pressure by key cache when a large partition is read

Partition Index Recap
• http://distributeddatastore.blogspot.jp/2013/08/cassandra-sstable-storage-format.html

RowIndexEntry
• Partition size < 64 kb
– RowIndexEntry
• Position
• Seriarized size of data
• Partition size > 64 kb
– IndexedEntry
• Position
• Seriarized size of data
• IndexInfo[]
– Seriarize method
– Offset
– width
– Etc.
Approximation on 16 byte value
1mb : 3kb / > 200 objects
4mb : 11kb / > 800 objects
64mb : 180kb / > 13k objects
512mb : 1.4mb / > 106k objects

3. The key is not cached
Partition
Summary
Disk
Mem Table
Compression
Offsets
Bloom Filter
Row Cache
Heap Off Heap
Key Cache
Partition
Index
Data
1. read request
2. Miss -> Check bloom filters
3. Check the partition key is in key cache
4. Miss -> Bsearch the close location of index
5. Disk scan to find the offsets 6. Find the offsets into the result set
8. Update key cache
9. GC, GC, GC…

Current solution
• If partition size <
column_index_cache_size_in_kb(configurable)
– IndexedEntry is kept on heap
• Otherwise
– Always read from disk when needed
• https://issues.apache.org/jira/browse/CASSANDRA-11206
• https://www.youtube.com/watch?v=qa84vABqftM

Other possible solutions
• IndexInfo never be kept on heap
– Read from disk when needed
– degrades performance when small partition is read

Other possible solutions
• Migrate key cache to be fully off heap
– Serialization & deserialization cost so much when large partition is
read
• Will Birch help us to solve this problem?

What we go for
• 来年もNGCCに呼んでもらえるように頑張ろう！
そのためには？: Cassandraコミュニティに貢献する
1. 日本で一番Apache Cassandraを使っている会社になる。
2. Cassandraのコード改善や問題提起の活動を継続する。
3. Cassandraコミュニティの人と仲良くなる。
55

DAY3 ?
• 3日目（おまけ）
56

• 自己紹介
• NGCCとは？
• 最後に
57

最後に
58
D I S T R I B U T E D
大規模分散処理
H A R D W A R E
ハードウエア分野
N E T W O R K
ネットワーク分野
mailto:kvs-pj-recruit@mail.yahoo.co.jp

ご清聴ありがとうございました
59

付録：NGCC動画集
• Next-Gen Schema
– https://www.youtube.com/watch?v=eAWRj0kqpvU
• Change Data Capture
– https://www.youtube.com/watch?v=Y0fOxa3tC98
• Explicit support for time series data
– https://www.youtube.com/watch?v=CmsQNNdDuSA
• Automated Repair
– https://www.youtube.com/watch?v=8sGUn6Q2bUU
• Storage format and key cache changes to support large partitions
– https://www.youtube.com/watch?v=qa84vABqftM
• SASI update
– https://www.youtube.com/watch?v=yUFoSAg6rA4
• Instagram’s use cases
– https://www.youtube.com/watch?v=VwhovoqavT4
• Lightning Talks
– https://www.youtube.com/watch?v=6y5UV4OTawg
60

[db tech showcase Tokyo 2016] D27: Next Generation Apache Cassandra by ヤフー株式会社星井祥吾

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to [db tech showcase Tokyo 2016] D27: Next Generation Apache Cassandra by ヤフー株式会社星井祥吾 (20)

More from Insight Technology, Inc. (20)