#garagekidztweetz

id:garage-kid@76whizkidz のライフログ・ブログ!

「【17-E-5】 Cassandraで見るNoSQL」を聴講してきたメモ

スポンサーリンク

黄色いゾウ使いへの道に引き続き、devsumi 2011 にて、「Cassandraで見るNoSQL」を聞いてきた際にとったメモを共有します。

Speaker 小林隆 氏の自己紹介

Cassandra: The Definitive Guide

  • ブレインパッド
  • データマイニング、最適化
  • 今は主にHadoopメイン
  • 最近はあまり Cassandra は使っていない
  • GUI をつくってる
  • Amazon Elastic MR記事
  • Cassandra を絶賛翻訳中
  • 原書と違うところ、β版をもとにつくっているので動かない部分がある
  • Avro の対応を削る

NoSQLとは?

  • SQLだけというわけではない
    • Carlo Stozzi 1998に最初
    • 2009 Eric Evans 、rackspace
  • ACID 特性と CAP 定理は最低限抑えておくべき
  • Bit Data を扱うアーキテクチャの原則
    • 説明→スライドでみてみよう
  • KVS
    • KVSも NoSQLの一種
    • 単純なKVS
    • カラム指向KVS(Cassandra)
      • →Excelを想像してみる
    • クラスタ、カラムファミリ、キー名、カラム名とバリューのペア
    • Cassandraの場合、
      • この他にスーパーカラムというのがある
      • 最大5次元で管理できる
    • Cassandra、BigTable、SimpleDB、Roma、
    • nosql-dababase.org

RDBMS とNoSQLの違い

  • RDBMSはパフォーマンスをあげるのにスケールアップ
    • NoSQLはスケールアウト
  • RDBMSはSQLで操作
    • NoSQLはほとんどの場合、API、SQLライクなもので操作する
  • NoSQLの背景
    • パフォーマンスをスケールアウトで解決
    • Web2.0の登場
      • Ajax、Flashゲーム、携帯等でも気軽にアクセス、データの増加
  • NoSQL
    • DDLが必要ない
    • 仕様変更に即座に対応できる

Cassandra=BigTable+Dynamo

  • Facebookが開発したカラム指向のDB
    • 0.72が最新
    • 0.611が最新
  • Facebook、メッセージサービスに利用
    • →去年、HBaseをつかうと宣言
  • twitter
    • →log解析に使用
  • バージョンについて
    • 0.6から0.7には移行ツール
    • 0.7と0.8は互換性がない
    • 互換性よりも機能を優先
    • まだまだ発展途上と言える
    • twitterがだしたスライドが興味深い
  • 書き込み高速
  • スケールできレイテンシ低い
  • 無停止でスケールアウトできる
  • SPOFが存在しない
  • Thriftを使うのでJava、C++言語サポートが広い
  • 一貫性の制御はAPPで
  • 0.7からIO共にHadoop MR対応 0.6まではIのみ

Cassandra のアーキテクチャ

  • ノードはリングで構成
  • データの保存とレプリケーション
    • →データの保存先はパーティショナーにより決定される
  • Consistency Levelでデータ保存の成否を判断する方法が変わる
    • ONE、ALL、QUORUM
  • マスタが存在しないのでどのノードに接続しても処理ができる
  • データの取得
    • キーをもとに一番ちかいノードへデータの取得要求
    • DCをまたぐことを想定した
    • データの取得も Consistency Levelで挙動が異なる
    • ONE、QUORUM以上の場合
  • Gossip Protocol
    • ノード間で相互にやりとりするプロトコル
    • ノード間のキーの再配置
    • ノード間の障害通知
    • 新規ノードの追加通知
  • Bloom Filter, Commit Log …
  • Hadoop MR対応
    • Hadoop MR+Cassandra
  • twitterが実装しているフレームワークは内部の仕様に依存するため公開されていない

NoSQLはRDBMSに置き換わるか?

  • できる、ただし大きな痛みをともなう
    • PARTAKEのイベント監視システムの事例
  • すぐにでる問題
    • トランザクションをどうするのか?
    • ほとんどの場合、自分で実装しなくてはならない
  • ほとんどのプロダクトはAPIで行っている
    • SQLのような標準言語がないため、
    • プロダクトを変えると実装もかえなければならない
  • select count(*) はできない
    • count 保存するテーブルつくって代用
  • Joinはできない
  • RDBMSは正規化が前提
    • NoSQLは非正規化に強いもの
    • 無理矢理、正規化するのではなくそのままNoSQLにつっこめということ
  • やっぱり向き不向きがあるということ
  • RDBMSがあればよい?NoSQLだけあればよい?はちがう
    • Combination is good choice.
      • マスターをRDBMSにもち、書き込みは高速な Cassandra に。など。
      • Facebookの場合、キー等の作成は MySQL、その結果を Cassandraに。
      • しかし、 Cassandraにを捨てて HBase に移ってしまった
      • →全部置き換わったわけではないが、 Cassandraはつかってない
  • NoSQLといってもそれぞれ特性があるので、どれがよいとは言えない。
    • プロダクトによって見極めをすることが大事である。
    • 1つのプロダクトで足りるのであれば、各社ごとにプロダクトをつくる必要などない。

まとめ

  • NoSQL等の登場でRDBMSに固執する必要はなくなった
  • それぞれに向き不向きがある。択一ではなく、組み合わせることも大事。
    • →やってできないことはもちろんないが。
  • あくまでも、やりたいことをやるための技術、手段なのだから、最適なものを選択すべきである。
    • なぜなら、お客様、にとって裏側の技術がなんであろうと正常に使えることが大事なのだから。

References.

Books.

Cassandra: The Definitive Guide

Cassandra: The Definitive Guide