#cct2012 Cassandra Conference in Tokyo 2012 でとったメモを公開しておこう

ツイート

404 Not Found に参加してきましたので、わたしのとってきたメモを公開します。
本カンファレンスは 2 トラックあり、業務トラックと技術トラックがありましたが、わたしは全部技術トラックに参加してきました。
（わたしの勤めている会社では Cassandra を使っていますが、わたし自身はまったく触れていないので、いつやってくれと言われてもいいよう少しでも情報をキャッチアップしておこうというモチベーションで参加しました）

※ また togetter でハッシュタグまとめ "Cassandra Conference in Tokyo 2012 ハッシュタグ #cct2012 まとめ - Togetterまとめ" をつくっておきました。誰でも編集可能なので、ぜひ有用な情報が他にあればどんどん追加していただけたらと思います。

基調講演：Cassandra 1.2

Cassandra started as a database for social media but today it has become a general-purpose tool for any application that requires massive scalability, high performance, and robust availability. This talk will cover how companies like Netflix, eBay, and Disney take advantage of Cassandra's features to build their applications. This talk will also introduce the new features in Cassandra 1.2 and give a taste of what developing against Cassandra is like with the Cassandra Query Language (CQL3).
DataStax Inc.
Jonathan Ellis

➤ Some Cassandara Users

• eBey and etc...

➤ Present

• 1.1
• self-tuning row + key caches
• support for mixed SSD + HDD nodes
• Row level isolation

➤ Self-tuning Row Cache

• Without cache case
• With cache case
• not need to read SSTables contains data, enable to cache in those data in memory
• Now 1.1 we can tell cassandra to use row case hogehoge MB.

➤ Mixed SSD/HDD Suppport

• can separate data to store in HDD or SDD for each suitable purpose.
• ex.
  • user_activity for HDD
  • user_session for SDD

➤ Row level isolation

• Lock free concurrency

➤ 1.2 (late 2012)

• concurreent schema changes
• virtural nodes
• "Fat node" support
  • JBOD improvement
• Atomic batches
• CQL3
  • collection
  • data dictionary
• Tracing

➤ Concurrent Schema Changes

• Adding table, Dropping table etc...
• not have to warry about who are modifying databases

➤ Virtual nodes

• Ring with VNodes
• with it realize more flexible Node Rebuild
• and also allow to upgrade with no downtime

➤ JBOD support

• no reason to use RAID for Cassandra
• it already have replicas for its data.
• if one of the disk died

➤ On-Heap/Off-Heap

• On: managed by GC
• Off: Not managed by GC
• can keep heap sizes down

➤ Moving O(n) structures off-heap

• Row partition bloom filter
  • 1-2 GB per billion rows
• Compression metadata

➤ Batches (Atomic Batches)

• ex.
• when tell cassandra to update multiple rows
• if before update complete coordinator node dies but batch can complete in 1.2
  (adding Batchlog node that can be enabled)

➤ CQL: You got SQL in my NoSQL!

• subset specialized SQL for Cassandra.

➤ Strictly "realtime" focused

• Aiming Cassandra for realtime analytics engine, so
  • No joins
  • No subqueries
  • No aggregration functions or group by ....

➤ CQL examples

• can put tags on columns.
• CQL transpositions, column family becomes the rows.
• storage engine rows we call it partition.
  (easy to understand seeing with slide)

#

• Clustering

#

• Data dictionary
  • information about the local node.
    • trancate
  • peers

➤ Request tracing

• when cqlsh, tracing on
  • collect entire request on each nodes
  • useful to find the bottle neck of the query

➤ Tracing an antiipattern

• (seeing with slide)

➤ Throughput vs latency

• benchmark with anothere DBs(HBase, Voldemort, ...)
• Throughput: Cassandra make great result
• Latency: Cassandra not makes good result
  • and this result can see why from the trace result.

➤ QA

• about JVM
• occasionally recommend ?????

CQL で表現した論理スキーマが、物理的にどのように Cassandra に格納されるのかの説明が興味深かった

CQL3 in depth

Cassandra 1.1で登場したCQL3が、1.2で機能強化され、デフォルトのCQLバージョンとなります。このセッションでは、CQL3の機能に加え、ストレージ部分での実装やデータモデリングについてご紹介いたします。
DataStax Inc.
森下 雄貴

➤ Why CQL3?

• Cassandra の内部的なデータの保持方法
• Bigtable 型のデータストレージ
• comparator
• values are validated by validation_class
• columns are sorted in comparator order

＊

• Thrift API
• Casssandra ができたときからある
• low level な get, get_slice, mutate

＊

• CQLがでてきたことによって、SQLに似たインターフェスでデータを操作できるようになった

＊

• CQL2 problems
• almost 1 to 1 mapping to thrift API, so not compose with the row oriented parts of SQL.
• no support for CompositeType.

＊

• CQL3
  • CQL2の問題解決
• Maps storage to a more natural rows-and-columns representatin using
• CompositeType
  • wide rows are transposed and unpacked into named columns
• Collection Support
  • set, list, map など。非正規化

➤ CQL3 walkthrough

➤ Defining Schema

• Defining Keyspace
• 一番外側の定義
• syntax is changed from CQL2.

＊

• Defining Static Column Family
  ダミーの行がはいる
• Strict schema difinition (and its good things)
  ダイナミックなカラムの追加はできない
  • you cannot add column arbitrary
  • you need to ALTER TABLE ... ADD COLUMN ...
• Columns are defined and sorted using CompositeType comparator

＊

• Defining Dynamic Column Family
• Use compound key ★
• Compound key ex. (slide)

＊

• Changes worth nothing
• Indentifiers (keyspace/table/columns/names) are always case insentive by default
  • use double quote to force case
    大文字、小文字の区別をしたければ " で囲む
• Compaction setting is now map type
• system.schema_*
  • data dictionaries
• CQL3 schema are not visible through cassandra-cli's 'describe' command

＊

• ブログ記事にThrift からCQLへの移行方法が詳細に

➤ Querying / Mutating Data

• insert, update, delete 互換
• しかし、 no more USING CONSISTENCY
• プロトコルレベルに移行した

＊

• Batch Mutate
• atomic が 1.2 からデフォルトに
• ただし、パフォーマンスのデメリットがでてくる
• atomic な処理が必要ない場合は、
• BEGIN UNLOGGED BATCH ... APPLY BATCH

＊

• Batch log node はランダムに2、3選ばられる
• ローカルのデータセンター内で。

＊

• Querying Data
• Order by のサポートもできるようになった
• compound key を設定した時の制限

＊

• TTL/WRITETIME
• SELECT WITETIME(author) FROM comment;

＊

• Collection Support
• Collections are typed, but cannot be nested(no list>)
• No secondary index on collections
• You cannot retrieve item in collection individually
  • ブログのタグのデータなど、データモデリングの難しい細かいデータを格納するのに向いている

• Set - Unordered...
• List - Ordered...
• Map - Keys ..

• ブログ記事に多くまとまっているようなのであとでみる

➤ Native Transport

• CQL3 still goes through Thrift's execute_cql3_query API
• Try Datastax Java native driver with C* 1.2 beta today.

➤ QA

• Range での削除はできるのか？
• using composite key possible

＊

• Collection の内部の数の上限
• Collection の内部をすべてもってくることになるのであまり多すぎるとメモリに載らなくなることはある

＊

• Native Transport
• Streaming に対応しているか？
• そこまではまだ考えてはいない
• フレーム内におさまらないといけないという制約

＊

• 日単位でデータを格納
• CQLで表現できるか？
• row と key の工夫

＊

• パフォーマンスは Thrift より 20％ ほど遅いようだ

＊

➤ Now Hiring

• if you want to join, contact to @yukim

CQL によって大分、RDBMS のようにCassandra がデータを扱えるようになっていることが確認できた
数多く紹介されていた Datastax さんのブログ記事はそれぞれ読んでおきたい

Cassandraの運用監視とバックアップ

実際にCassandraクラスターを運用するにあたって監視項目のポイント、zabbixなどの監視ツールへの組み込み方法、考え方など、またSI案件で要求されるバックアップに関してCassandraのデータストアの仕組み復旧方法、オペレーションミスに対応するためのスナップショットのとり方、データのサルベージ方法など、想定される要求に対する対応方法を例に、以前、大規模DBを運用していた観点も盛り込み、Cassandraのアーキテクチャを交えながら説明します。
株式会社INTHEFOREST
冨田 和孝

➤ 自己紹介

• @railute
• Cassandra 勉強会、だいたい2ヶ月に一回主催
• NLP、テキストマイニングを始めたとのこと
• Cassandara サポートサービスあり〼とのこと
• トレーニングもあり〼、1日、バージョンは1.1 or 1.0
• 最低、6ノード以上、できれば9ノード以上を推奨する理由などがわかる

➤ Cassandra の前提

• ★ 各ノードは独立している
• Cassandaraは他のノードのステータスの管理はしない
• Seeds は初期接続対象、ないしはGossipの優先選択先なだけ
• 初期接続時、スキーマ情報取得など
• Gossip、毎回必ずSeedをゴシップ対象に加える
• NW断がおきたときは分断された単位で生きていることになる、スプリットブレインは起こり得る

＊

• ★ SSTable はWrite Once
• 書き込みが起きるのはいつか？という話
• Compaction が制御する
• MemTableのしたに BloomFilter があり、そのしたに複数の SSTable がある構造
  （図の説明がわかりやすい）
  ※Flush のことが書いてないので、後ほど追記するとのこと

➤ 監視をするということ

• Cassandra は原則すべて JMX で監視をしている
• Java Management Extensions
• JVM の握っているHW リソースも監視できる

＊

• Cassandra における監視の定義
• ステータス管理、ようは生死確認
• リソース管理
  • CPU, IO, NW, memory
    • 通常の状態がどういう状態かを知っていることが必要、でないと何が異常なのか気づけない
    • Cassandra は相手が死んでしまうことを前提にしているため、何をもって障害とするかが難しい
• monit などの watchdog をいれることによって落ちたらあげるとしても大きな問題がおきるものではない
  （ただし、データロストは起こるのでもちろん業務要件に依存する）

＊

• 障害検知としてのステータス管理
• HW障害→むしろきさくにノード障害扱いにして落としてしまう（1ノードくらいならですが）
• Out of memory→ヒープ不足、コンパクション遅延、など→原因特定とチューニング必要（メモリは結構食う、4GBはヒープに割り当てた方が良い）
• NW 遅延→パケロス、帯域不足など、データ不整合が発生する可能性があるのでRepairを検討

＊

• 何を抑えておくべきか
• ノードが落ちるメモリ使用量
  → OOM killer に殺されるはよくある
• データが闇に消えかねないNW系の不具合
• Write Heavy は CPU バンド
  →デフォルトではすべての CPU を使い切るということはほとんどない 8 thread くらいしかたたないので。
• Read Heavy は memory/IO バンド

＊

• メモリ使用量
• Cassandra はメモリを喰う
• GCが適切に行われているか
• Compactionが適切に行われているか
• Flushが適切に行われているか
• これらが正常に行われないとメモリとディスクを圧迫する

＊

• NW不具合
• Cassandraはノード間メッセージが10秒返ってこないとそのセッションを叩き落す
• 書き込みはリードリペアに後を託す
• メッセージの欠損が発生している場合は Repair を検討（しかし処理重い compaction 走る）

＊

• Write heavy はCPUバンド
• Write の処理はBloomFilterの演算、Flush、Compactionなどが入るためCPUを使いまくる
  （図解わかりやすい）

＊

• Read Heavy はIOメモリヘビー
• BloomFilter のサイズがチューニングポイント

＊

• ツールの紹介
  • Jconsole
    • JMX の情報取得の基本
  • MX4J
    • Cassandra 起動時に読み込ませることで使用可能。ブラウザでJMXの情報取得、操作が可能に
  • OPSCenter
    • Datastax 社製、エンタープライズでは Hadoop の管理も
  • Zabbix
    • 2.0 系からJMXをネイティブサポート
  • Nagios + RRDtool もまだまだ捨てがたい

＊

• 監視のまとめ
• 障害のレイヤーがRDBMSとは異なる
• 気軽にノード障害にしちゃおう
• OOM が出た場合は原因に注意
• メッセージのドロップが出ていないかを常に監視

➤ バックアップをするということ

• 時間がないから急ぎ足に…
• バックアップの目的
• バックアップをするということ
• Cassandra は Key さえあればデータのあり先が分かる
• node tool からも確認可能

＊

• Cassandra のバックアップは SSTable のコピー
• Snapshot と呼ばれる

＊

• データリカバリ1
• クラスター内の特定のノードのHDD破損
• 他のノードから取得して復旧

＊

• リカバリ2
• 同条件、バックアップあり
• バックアップSSTableから復旧

＊

• リカバリ3
• キーがストアされているレプリカ分のクラスター内のHDD全滅
• バックアップSSTableがない場合は復旧不可能
• バックアップSSTableのFlushされてないデータはロスト
  （EC2のリージョン全滅とかなったら死ねる）

＊

• オペレーションリカバリ
• 指定のキーで特定のバージョンが格納されているバックアップSSTableを取得
• 他のクラスタにリカバリ
• 希望データを取得

＊

• サーバ移行
• 最新バックアップSSTableを取得
• 他のHWにリカバリ
• IPさしかえ
• Repair

＊

• 監査
• バックアップSSTableを取得
• S3などに流し込みましょう
• Tracking 機能が 1.2 から追加されたから

＊

• まとめ
• データのある場所を抑えること
• ノード間でバックアップタイミングをずらしデータの確保を行う
• 必要なところだけ取得することも可能

➤ QA

• 欠損したデータを特定する方法はない
• Cassandra の Delete は論理削除、10日間は保持される
• Read Repair より Repair のほうが確実

運用よりの話だったため、特に Cassandra に言及しなくても使える内容だった。

Logging platform for PaaS Cloud Platform of Rakuten

We introduce a use case of how we use Cassandra to build a logging platform, to provide log query services for PaaS Cloud developers, and analysis of their behaviors in real time.
楽天株式会社
Yongkun Wang（Big Data Department）

➤ About Rakuten

➤ Big Data Department of Rakuten

• active in Cassandra Communitiy

➤ Bigdata Analysis Platform

• Cassandra for rearly realtime
• In memory DB
• and Hadoop and Hive

➤ Rakuten PaaS

• Cloudfoundry
• Why PaaS
• about 1900 developers in R&D unit
• very challenging to support them to develop and deploy their application
• PaaS make it easier

➤ Developer's Logs on PaaS

• Logs cannot be accessed directly likie in their on their PC
• We choose Cassandra

➤ Why Casssandra

➤ System overview

• multiple DCs
• log agent collect data to Cassandra

➤ Log Types

• INFO, WARN, ERROR
• Access Logs by End Users

➤ Cassandra Setup

• VM: medium Instance (4cores, 8GB RAM HDD)
• Cassandra 1.1
• Consistency level: QUORUM
• replication factor: 2
• Random Partitioning
• TTL = 1week
• Snappy compression

➤ Schema design

• JSON format
• find the Hierarchy structure
• and give choice of schema to developers

➤ Characteristics of Casssandra Data

• Insert only, no update, less SSTable
• Wide rows

➤ Performance of Query on Log Columns

• Write latency: 0.03ms
• Read latency: 96ms
• in this case cache is not very helpful

➤ Counter design

• Time series counters
• Counters of user, app, day, hour, minutes, seconds

➤ Developer's dashboard by counters

• Most developers are very active between 13:00-18:00 w

➤ Access log analysis

• Time series of User Activities
• to analyze why user go away form our website

➤ Current Status

• 140 developers using this system
• 2,000,000 log recores per day
• Easy to add Casssandra nodes when cluster gets heavy - add more VMs

➤ Expect to be better

• Frequent schema change

➤ Conclusion

➤ QA

• why cache is not worth?
• access is sparse , so the time series cache hit ratio is not much good

スキーマデザインのスライドが興味深い
資料を公開してくれることを切望する

LT

• なかった…

Reference.

• CCT 2012 |Cassandra Conference in Tokyo 2012
• Cassandra Conference in Tokyo 2012 ハッシュタグ #cct2012 まとめ - Togetter

✔ こちらもあわせてどうぞ

• 途中までだけど参加した #cassandratk2011
• 「【17-E-5】 Cassandraで見るNoSQL」を聴講してきたメモ