Cassandraの活用事例とパフォーマンス特性

Repro Tech LT発表資料

Transcript

1. Cassandra
   の活⽤事例とパフォーマンス特性
   joker1007 (Repro inc. CTO)
   

   View Slide

2. self.inspect
   @joker1007
   Ruby/Rails/fluentd/presto/infra
   ⼤体アーキテクト業
   今はkafka
   とkudu
   に興味がある
   

   View Slide

3. 話すこと
   Repro
   でのCassandra
   の活⽤⽬的
   Cassandra
   の選定理由
   Cassandra
   のパフォーマンス特性と設計時の注意
   話さないこと
   運⽤時の細かな注意点
   

   View Slide

4. 何のために
   端末情報記録
   ユーザープロフィール情報
   イベント実⾏回数 / user
   リアルタイムで更新される情報の保持がメイン
   

   View Slide

5. 何故Cassandra
   を選択したか
   書き込み回数が⾮常に多い
   かつ読み込み時に100
   万件単位で取得しJOIN
   する必要がある
   組み合わせる対象として、数⼗⽇分の⾏動ログを含む。
   書き込みがスケールし、当時からセグメンテーションに利⽤していたpresto
   と連携が
   可能で、読み込みもある程度分散できるデータストアが必要。
   → Cassandra
   を採⽤。
   

   View Slide

6. Cassandra
   のパフォーマンス特性
   

   View Slide

7. 書き込みの概要
   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
   

   View Slide

8. 書き込みの概要
   https://docs.datastax.com/ja/cassandra-
   jajp/3.0/cassandra/dml/dmlHowDataWritten.html
   

   View Slide

9. 書き込みパフォーマンス特性
   パーティション対象の決定とmemtable
   、transaction log
   が書ければOK
   。
   最終的なテーブルファイルは不変なので、書き出しがシンプル。
   パーティションさえ均等なら割と簡単にスケールする
   ⼀件単位の書き込みは、ほぼ100
   マイクロ秒以下
   現時点で20000/sec
   ぐらいの書き込みがある
   整合性を保ってカウントアップする処理は重い
   複数ノードを跨いでCAS
   やロックが必要になる
   

   View Slide

10. 読み込みの概要
    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
    

    View Slide

11. 読み込みの概要
    https://docs.datastax.com/ja/cassandra-jajp/3.0/cassandra/dml/dmlAboutReads.html
    

    View Slide

12. 読み込みパフォーマンス特性
    ⼀件単位の読み込みに向いている
    多くのデータをまとめて取得するには不向き
    取得対象のパーティションとノード特定にCPU
    を使う
    クラスタのノード間でデータの通信が多く発⽣する
    パーティション毎のdigest
    要求
    read repair
    

    View Slide

13. presto
    での利⽤は本来は不向き
    パーティション数とノード数でバランスを取ることで
    何とか⽬的のパフォーマンスを維持
    

    View Slide

14. テーブル設計の重要性
    読み込みワークロードに合わせてテーブルを設計する、でないとまともにパフォ
    ーマンスが出ない。
    ユースケース毎にテーブルがあり、データの重複は覚悟する。
    とにかくパーティションキー以外を条件にクエリしないこと。
    

    View Slide

15. まとめ
    読み込みパターンに合わせたテーブル設計をすること
    ⽤途が適切ならかなりのパフォーマンスが出せる
    パーティション数とデータの分散度合いのコントロールが重要
    

    View Slide

16. その他のTips
    CPU
    、ディスクI/O
    、ネットワークそれぞれかなり影響があるのでメトリックをち
    ゃんと取得しておくこと
    ホットデータはオンメモリで読み書きするのでメモリは多く
    セカンダリインデックスは基本使えない
    

    View Slide