あしたのオープンソース研究所 2010年4月27日開催 Cassandra (0.6) 座談会 発表者 永江さん 提供 インフォサイエンス

1. Cassandra 2010/04/27 インフォサイエンス 永江

2. ・オープンソースの分散データベース ・もともとは Facebook において大規模データの格納のために開発された ・構造化された Key-Value 型データストア Cassandra について

4. ・キーと値の組を書き込み、キーを指定することで値を読み出せるデータベース管理ソフトウェア 書き込み (put) 要求 読み出し (get) 要求 削除 (remove) 要求 返答 ( 成否など ) 値 キー 値 サーバ クライアント HDD や SSD, メモリ上 ( 単純な )API key-value ストアとは

5. 各種 key-value ストアプロダクト Websphere eXtreme Scale Voldemort (LinkedIn 社発の OSS) Velocity Memcached (OSS) Kai (OSS) Dynamo Oracle Coherence Tokyo Cabinet/Tokyo Tyrant ROMA Kumofs (2010 年 1 月に OSS として公開 ) Flare プロダクト名

6. ・ 高い性能 1 秒あたりにさばける読み書き要求の数 (qps) は RDB とくらべて文字通りケタ違いの 性能。低遅延。ただしスループット ( 時間あたりのデータ量）は出ない。 ・ 高いスケーラビリティ ・ 高い可用性 ( 耐故障性も含む ) ・シンプルな問い合わせ方法 問い合わせ方法をキー 1 つの指定に限定することで、高速な検索のための表 （例： ハッシュ表や B+ 木 ) は 1 つで済み、データ書き込み時に書き換えなければならない 箇所を少なく抑えています。問い合わせの解釈、実行も素早く済み性能を稼げます。 ・細かい単位に限られた atomic な読み書き キーと値の組、また、読み出しや書き込みといった細かい単位でだけ、 atomic な処理 が可能です。 ⇔ RDB のトランザクションではデータ 1 つと言わず、表の複数箇所や 複数の表にまとまった atomic な処理が可能ですが、コストが高いです。 ・複製間の緩い整合性 複製間の整合性については緩い保証にとどめることで、性能と可用性を得ています。 key-value ストアの特徴

7. ・ RDB とはケタ違いの高性能 (qps, 低遅延 ) 、または ・数十台以上で達成できる大容量 が活きて、 ・キーを指定するシンプルな問い合わせ方法 ・キー 1 つを単位とする atomic な読み書き ・複製間の緩めの整合性 を許容できるようなアプリケーションです。 キー 値 サーバ クライアント HDD や SSD, メモリ上 key-value ストアの使いどころ

8. ・ Dynamo ・ 1 日あたり数千万の要求と 300 万以上のチェックアウト (2007 年時点 ) ・複数キーにまたがった厳しい整合性は必要ありません。 key-value ストアの使いどころ – 例 . amazon のショッピングカート

9. ・数万 qps 。 KVS としては” Flare( フレア )” を使っています。 ・ユーザ ID をキーとした問い合わせさえできれば OK 。複数キーにまたがった厳しい整合性も必要ありません。 key-value ストアの使いどころ – 例 . GREE のアクセス履歴

10. ・ データ量が少ない場合 ・ トラフィックの上限が見えているような場合 ・ 高価な HW を調達することでスケーラビリティや冗長性についての懸念をもつ必要がない場合 ・上記のようなところでは RDBMS を利用すれば足りますし、管理その他の側面で楽です。 ・複雑なクエリが必要なところでは、 KVS では難しいです。 key-value ストアでなくてもいい、向いていないところ

12. ・もともとは facebook において大規模データの格納のために開発されました。 ・ Amazon Dynamo の分散システムデザインと Bigtable のカラムファミリーに基づいたデータモデルをもちます。 ・ Facebook により 2008 年にオープンソース化され、現在は Apache のトップレベルプロジェクトとなっています。 Hadoop のロゴよりは数段かっこいいです。 Cassandra について

13. 「 facebook は、 友達や同僚、同級生、仲間たちと交流を深めることができるソーシャルユーティリティサイトです。」 (facebook のトップページから抜粋 ) facebook ( サンプルページ )

14. ・ 2004 年にハーバード大学の学生だったマーク・ザッカーバーグが創業。当初はハーバード大学の学生が交流を図るために作られた。その数日後、スタンフォード大学やコロンビア大学、イェール大学などの学生からの「同じようなサイトが欲しい」との要望に応え、いわゆるアイビー・リーグの学生にも開放した。その後、徐々に全米の学生に開放され学生生活に欠かせないツールとなった。大学のメールアドレス（ .edu ドメイン）を所有する大学生のみに参加が限られていたが、 2006 年初頭には全米の高校生に開放し、 2006 年 9 月までには一般に開放され、誰でも利用できるようになった。 ・ 2007 年 10 月 31 日、 Google が OpenSocialAPI を公開。 Orkut 、 Salesforce 、 LinkedIn 、 Ning 、 Hi5 、 Plaxo 、 Friendster 、 Viadeo 、 Oracle らが参加。 ・ 2008 年 1 月 25 日、 FacebookAPI"JavaScript Client Library" を公開したことにより、 SNS 業界にとどまらず、 IT 業界全体に SNS のオープン化に拍車をかける。 ・アプリケーションの総数は約 1 万 7000 。毎日、約 140 のアプリケーションが追加されている。 (wikipedia の facebook についての説明から抜粋 ) facebook の歴史

15. ・ピーク時には 1 憶以上のユーザが世界中のデータセンタにある数万のサーバにアクセスする。 ・パフォーマンス、信頼性、効率の面から厳格な運用要件がある。 ・継続的な成長に追従できる高スケーラビリティなプラットフォームが必要だった。 facebook で Cassandra が開発された理由

17. ・”カラム”は名前 (name) 、値 (value) 、タイムスタンプ (timestamp) から構成されます。 カラム (Column) timestamp: 123456789 value: “test@example.com” name: “E メールアドレス”

18. ・”スーパーカラム”は名前と、値としてのカラムから構成されます。 それぞれ カラムのキー となります。 スーパーカラム (SuperColumn) (1) Timestamp: “123456789” Value: “108-0023” Name: “zip” zip: Timestamp: “123456789” Value: “ 東京都港区” Name: “city” Timestamp: “123456789” Value: “ 芝浦 2-4-1” Name: “street” city: Street: value: name: “homeaddress1”

19. ・さきほどのスーパーカラムのタイムスタンプなどを省略して書いて以下のように表現することにします。 スーパーカラム (SuperColumn) (2) zip: 108-0023 city: 東京都港区 street: 芝浦 2-4-1 HomeAddress1:

20. ・”カラムファミリー”はカラム、スーパーカラムから構成されます。 RDB の「行」に相当します。 HomeAddressBook カラムファミリー ・カラムは常にソートされています。⇒ 読み込み性能の向上 ・設定ファイルで前もってソートするカラム、ソートに使う型（ Byte, UTF8, ascii, long) を指定しておきます。 ・ Cassandra はこのように単純なキー / バリュー型のストレージよりも多少は構造化してデータを保持できます。 カラムファミリー (ColumnFamily) Address1: Ken: zip: “93301 city: “BF” street: “A ave” zip: “94404” city: “FC” street: “Howard street” zip: “90210 city: “BH” street: “8 th street” Address2: Address1: Dean:

21. ・キーの値をハッシュ化した値をもとに接続するノードを決定します。 ( ハッシュ値の範囲は 0 ～ 2 127 -1 です。 ) この場合、キーをハッシュ化した値はノード B の担当する範囲に含まれますので、 B にアクセスします。 A B C ハッシュ ( キー ) 0 2 127 -1 データへのアクセス (1)

22. ・ノード間のアクセス負荷に偏りがでてきたら、ノードを追加しバランスをとることができます。以下の例ではノード C の負荷がノード A, B よりも高くなってきたために、ノード C の担当範囲にノード D を追加してノード C の負荷を減らしています。 A B C B ～ D の区間はノード D の担当範囲となります。 D 0 2 127 -1 データへのアクセス (2)

23. ・ CAP 定理： 共有データに関する以下の三つの特性のうち、 どんな時も , このうちの二つだけしか同時には達成することができない。 - データの整合性 (consistency) - システムの可用性 (availability) - ネットワークの分断 (network partition) ・結果整合性： 誰かがデータを更新し、そのデータが複製されるのに十分な時間が過ぎ、 その後更新が加えられていなかったら、必ず新しいデータにアクセスできる。 ⇒ Cassandra では整合性を妥協することでシステムは分断のある状況でも高可用性を実現できる。 参考：“ Eventually Consistent” http://www.allthingsdistributed.com/2007/12/eventually_consistent.html 日本語訳 http://www.hyuki.com/yukiwiki/wiki.cgi?EventuallyConsistent ) 結果整合性 (Eventual consistancy)

25. digg: 英語圏 におけるソーシャルブックマークサイトの一つ。アカウン トのないユーザーでもニュース記事をクリップでき ることに加え、アカウントを取得することによって、その記事へのコメントや投票ができるようになる。 http:// digg.com / Case study: digg

26. ・テラバイト級のデータ ; 高いトランザクション（読み込みがメイン） ・重度に sharding された複数の DB クラスタ (sharding: MySQL サーバーを複数用意し、アプリケーション側でデータを格納するべきサーバーを選択させること ) ・運用の難しさ ( 作業量大、かつ障害に弱い ) ・不十分な可用性 ( 地理的な孤立 ) digg での問題

27. Digg では HBase, Hypertable, Cassandra, Tokyo Cabinet/Tyrant, Voldemort, Dynomite 等を検討しました。 “ それぞれのシステムが長所と短所を持っていますが、 Cassandra はこれらすべての良い点を取り込んでいます。列指向データストレージを提供している ので、単純なキー / バリュー型のストレージよりも多少は構造化してデータを保持できます。 また、可用性の高いピアツーピアで連携する分散環境でも動作します。未実装の重要な機能もありますが、私たちを目的地に近づけてくれるのは、他のソリューションではなく Cassandra なのです。 “ “ Looking to the future with Cassandra” http://about.digg.com/blog/looking-future-cassandra Digg が cassandra に移行した理由

28. Twitter:Twitter （ツイッター）は、 2006 年 7 月に Obvious 社（現 Twitter 社）が開始したサービス。 個々のユーザーが「ツイート ( 「つぶやき」 ) と呼称される短文を投稿し、ゆるいつながりが発生するコミュニケーション・サービスであり、広い意味での SNS の 1 つ。「ミニブログ」「マイクロブログ」といったカテゴリーに括られることもある。 Case study: twitter

29. MySQL を使用 ・テラバイト級のデータ ・高トランザクション 100 万 ops/sec ・重度の sharding ・スキーマの変更がとても難しい ・人手による sharding はとても大変 ・自動化された sharding とレプリケーションは難しい twitter での問題

30. “ Kings 氏によると、 Twitter はシェアド MySQL と Memchache を組み合わせたシステムを利用してきたが、データの増加ペースが急増して おり、対応が急務となっていた。 人件費をはじめとした運用費用がかさんでおり、共有 MySQL 設定を自動化するか、他のデータベースへの乗り換えを考慮し たという。 Cassandra 以外のデータベースも検討したが、マシンの追加、 SPOF （単一障害点）、書き込みの拡張性、管理作業、コミュニティの健全さ（オープンソースの場合）などを考慮した結果、すべての条件を満たしたのが Cassandra だったという。 “ “ Twitter 、「拡張性と可用性」を求めて MySQL から Cassandra へ乗り換える ” sourceforge.jp http://sourceforge.jp/magazine/10/03/02/0350225 twitter が cassandra に移行した理由

31. ・テラバイト級のデータ ・高いトランザクション ・複数のデータセンター ・重度の sharding ・ DB のスキーマは簡単 (DB の機能はフルに使っていない。複雑なクエリはない ) ・運用に必要なコストに悩んでいた ・サービスが止まるのは困る ・ピーク時に応答が遅くなるのも困る facebook, digg, twitter に共通していること

32. twissandra ・ cassandra 上に twitter に近い機能を実装 http:// twissandra.com / デモ

33. Cassandra は高いスケーラビリティを持つ、結果整合性を用いた分散 KVS(Key Value Store) です。 Cassandra は Amazon Dynamo の特性と Google BigTable のデータモデルをあわせもった分散システムです。 Cassandra は、 Dynamo のように結果整合性で、 BigTable のように既存の KVS よりもリッチな ColumnFamily ベースのデータモデルを提供します。 Cassandra は 2008 年に Facebook がオープンソース化しました。そのデザインは Avinash Lakshman (Amazon‘s Dynamo の作者の一人 ) と Prashant Malik ( Facebook エンジニア ) によって行われました。 Cassandra は Dynamo と BigTable の融合によって生まれたものであり、 Dynamo 2.0 と位置づけることもできます。 Cassandra は Facebook によって実サービスによって使われており、依然進化の途中です。 Cassandra wiki http://wiki.apache.org/cassandra/FrontPage_JP より まとめ

34. ・大量のアクセスがあったときに従来の DBMS ではすぐに応答が遅くなってしまうというのは日常の運用でも日々実感しています。（しかもそう感じる頻度が多くなってきています。） ・テーブルの分割というのも一つの手ではありますが、障害時の対応、バックアップ、リストアなどの運用が大変になってしまいます。 ・上記のような問題を乗り越える手段として、 Cassandra はよく考えられていると感じました。 ・過去は高嶺の花であった RDB が現在は一般的に使われているように、将来的には cassandra のような技術も一般的になって、普通のシステムで分散 DB が使われるようになるかもしれません。 ・複数のお客様が並列に使える共用の分散 DB というのも面白いかもしれません。 ( 認証、暗号化のシステムはよく検討される必要がありますが。 ) 感想

35. ● Query get(): カラムもしくはスーパーカラムを取得する。 get_slice(): カラムのグループを取得する。 multiget_slice(): get_count(): カラムの数 等々 http://wiki.apache.org/cassandra/API Cassandra の API (1)

36. ● Updating insert(): カラムを追加 / 更新する。 batch_insert(): 複数のカラムを追加 / 更新する。 remove(): カラムを削除する。 batch_mutate(): http://wiki.apache.org/cassandra/API Cassandra の API (2)