トップ  > メモ一覧  > カテゴリ「NoSQL」の絞り込み結果 : 1件

1件中 1 〜 1 表示  1 

No.2172 TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由

TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由

スケーラブルなデータベースを実現する手段として「Sharding MySQL plus memcached」がよく知られる方法だとは、1つ前の記事「MySQL+Memcachedの時代は過ぎ、これからはNoSQLなのか、についての議論」で紹介しました。

ちなみに「Sharding」(シャーディング)とは複数のデータベースにデータを分散して運用することで、ざっくりいえばShared Nothing的な分散データベース構成のことです(この記事で紹介する英文中には「Shared MySQL」(共有MySQL)との記述がありますが、これは恐らく「Sharded MySQL」(ShardされたMySQL)のミススペルではないと推測します)。

日本で(たぶん)もっともMySQLについて詳しく解説してあるブログ「漢(オトコ)のコンピュータ道」のエントリ「さらにMySQLを高速化する7つの方法」 では、Shardingとは何かについて簡単に触れているとともに「Shardingが必要になるほど大規模なデータベースはどちらかといえば少数派なの で、あまり一般的なケースには当てはまらないかも知れないが」と書いてあります。Shardingを採用する規模というのはそれだけ大きいのだといえるで しょう。

TwitterとDiggがNoSQLを検討している

The Apache Cassandra Project

そのShardingされたMySQLやMemcachedなど用いて運用している超大規模なWebサイトのTwitterやDiggは、それぞれ新しいデータベースとしてCassandraを採用し、MySQLからリプレースしようとしています。

Cassandraとは、The Apache Projectが開発中のNoSQLデータベース。キーバリュー型データストアの一種で、Eventual Consistency(結果整合性)、レプリケーションと自動フェイルオーバーによるフォールトトレラント機能などを実装しています。

2つの会社はなぜMySQLからCassandraへと移行しようとしているのでしょうか? なぜCassandraなのでしょうか? 理由と選考過程について紹介してみましょう。

Twitter:Cassandraは単一障害点がなくスケーラブル

TwitterがMySQLからなぜ他のデータベースへと移行しようとしているのか。「myNoSQL」の2月23日のエントリ「Cassandra @ Twitter: An Interview with Ryan King」で、TwitterでCassandraの利用を推進中のRyan King氏に対するインタビューを掲載しています。ポイントを見てみましょう。

Twitterは、ShardingされたMySQLとMemcachedで運用していたけれども、運用コストが大きくなってきたことが、ほかのデータベースを検討し始めた理由だとKing氏は答えています。

We have a system in place based on shared mysql + memcache but its quickly becoming prohibitively costly (in terms of manpower) to operate. We need a system that can grow in a more automated fashion and be highly available.

私たちはShardingさ れたMySQL + memcachedをベースとしたシステムを運用しています。しかしそれは急速に受け入れがたいほど運用コストが(おもに人的コストが)かかるようになっ てしまいました。もっと高可用で自動化された方法で成長可能なシステムが必要です。

そこでTwitterでは2つの手段を検討したとのこと。それは、さらに自動化されたMySQLをセットアップするか、あるいはほかのもっと高速なデータベースへと移行するか、です。

  • A more automated sharded mysql setup
  • Various databases: HBase, Voldemort, MongoDB, MemcacheDB, Redis, Cassandra, HyperTable and probably some others I’m forgetting.

それらを以下の観点で比較したとのこと。

  • How will we add new machines?
  • Are their any single points of failure?
  • Do the writes scale as well?
  • How much administration will the system require?
  • If its open source, is there a healthy community?
  • How much time and effort would we have to expend to deploy and integrate it?
  • Does it use technology which we know we can work with? … and so on.

つまり、(性能を向上させるための)マシンの追加方法、単一障害点の有無、データ追加が多くてもスケールするか、管理コスト、プロジェクトの将来性などが主な比較項目のようです。

特にTwitterはデータベースへの書き込み負荷が非常に多いと考えられるので、データ追加のスケーラビリティは大きなポイントのはずです。

Asking these questions narrowed down our choices dramatically. Everything but Cassandra was ruled out by those questions. Given that it seemed to be our best choice, we went about testing its functionality (“can we reasonably model our data in this system?”) and load testing.

こうした質問によって選択肢は劇的に狭められていった。Cassandraだけが答えられたのだ。私たちにとって最適な選択だといえ、これから機能と負荷テストをしようとしているところだ。

Cassandraを採用する重要なポイントを、King氏は次のようにまとめています。

  • No single points of failure
  • Highly scalable writes (we have highly variable write traffic)
  • A healthy and productive open source community

Digg:Cassandraはバランスがよい

一方のDiggはどのようにしてCassandraを選んだのでしょうか? Diggのオフィシャルブログに、昨年の9月にポストされたエントリ「Looking to the future with Cassandra」から紹介しましょう。

Digg has been researching ways to scale our database infrastructure for some time now. We’ve adopted a traditional vertically partitioned master-slave configuration with MySQL, and also investigated sharding MySQL with IDDB.

これまでDiggはスケールするデータベースを調査してきた。これまでに伝統的な手法であるパーティションに分けたMaster-Slave構成のMySQLを取り入れ、Sharding MySQLとInnoDBについても調査してきた。

DiggでもSharding MySQLは選択肢にあったようです。しかし、彼らの調査でもやはりMySQLでは運用コストが大きくなりすぎるとの結論となり、「we felt comfortable looking at more exotic, non-relational data stores.」つまりNoSQLへと選択肢を広げたのでした。

After considering HBase, Hypertable, Cassandra, Tokyo Cabinet/Tyrant, Voldemort, and Dynomite, we settled on Cassandra.

そしてさまざまなNoSQLを検討した結果、Cassandraを選択したと。

Each system has its own strengths and weaknesses, but Cassandra has a good blend of everything. It offers column-oriented data storage, so you have a bit more structure than plain key/value stores. It operates in a distributed, highly available, peer-to-peer cluster.

それぞれのシステムには強みと弱みがあるが、Cassandraはそれらを適切なバランスで備えてい た。カラム指向型データストレージであり、キーバリュー型データストアよりもややデータ構造を備えている。分散構成による高い可用性を持つピア・ツー・ピ ア型のクラスタで運用できる。

Cassandraの評価を一気に固めることになるか

TiwtterもDiggも、これから実運用にCassandraを投入するフェーズを迎えることになります。両社とも動いているシステムのデータベースを入れ替えるのですから、それは慎重かつ大きなプロジェクトになることでしょう。

そして、入れ替え後に果たして想定した通りの能力をCassandraが発揮してくれるのか。もし順調にいったとしたら、それを契機にNoSQL が、Cassandraが、スケーラブルな環境において実用的なレベルで非常に優れたシステムだという評価を一気に固めることになるかもしれません。

関連記事

Twitterはすでに徹底的にMemcachedのオプティマイズなどを行い、性能向上に努力してきました。その様子は次の記事で紹介しています。

NoSQLについては以下の記事をぜひ参照してみてください。

引用元

更新:2010/03/09 10:26 カテゴリ: DBその他  > NoSQL ▲トップ
1件中 1 〜 1 表示  1 

FuelPHP

Mac

フロントエンド開発

web開発

プロマネ

マネタイズ

プレゼン

webサービス運用

webサービス

Linux

サーバ管理

MySQL

ソース・開発

svn・git

PHP

HTML・CSS

JavaScript

ツール, ライブラリ

ビジネス

テンプレート

負荷・チューニング

Windows

メール

メール・手紙文例

CodeIgniter

オブジェクト指向

UI・フロントエンド

cloud

マークアップ・テキスト

Flash

デザイン

DBその他

Ruby

PostgreSQL

ユーティリティ・ソフト

Firefox

ハードウェア

Google

symfony

OpenPNE全般

OpenPNE2

Hack(賢コツ)

OpenPNE3

リンク

個人開発

その他

未確認

KVS

ubuntu

Android

負荷試験

オープンソース

社会

便利ツール

マネー

Twig

食品宅配

WEB設計

オーディオ

一般常識

アプリ開発

Python

サイトマップ

うずら技術ブログ

たませんSNS

rss2.0