Agile Cat — in the cloud

Real World NoSQL シリーズ – Openwave における Cassandra

Posted in Big Data, NoSQL by Agile Cat on February 15, 2011

RealWorld NoSQL: Cassandra at Openwave
By Guy Harrison Jan. 29, 2011, 9:00am PST

_ Gigaom

Edit Note: This is the third of a multi-part series of posts exploring the use cases for NoSQL deployments in the real world. So far, the series has covered case studies on MongoDB andHbase.


With all the excitement surrounding the relatively recent wave of non-relational – otherwise known as “NoSQL” – databases, it can be hard to separate the hype from the reality. There’s a lot of talk, but how much NoSQL action is there in the real world? In this series, we’ll take a look at some real-world NoSQL deployments.

ノン・リレーショナル、さもなければ「NoSQL」 データベースとして認識されている大きなウネリが、このところ様々な憶測をもたらしているが、そこから真実と虚構を切り分けるのは、難しい作業となる。 数多くの話題が提供されているが、現実の世界において、NoSQL への取り組みは、どれぐらいの件数になっているのか? このシリーズでは、現実の世界における、いくつかの NoSQL ディプロイメントについて注目していく。


Openwave delivers mediation and messaging products for ISPs and telecom service providers. It has adopted Cassandra as the basis for its next generation messaging platform, which will go live in the second half of 2011. Like HBase, Cassandra is heavily influenced by the Google BigTable model, but also uses concepts from Amazon’s Dynamo distributed key-value store. Cassandra was first developed by Facebook, and has since seen action at Cloudkick (recently acquired by Rackspace), Digg and Twitter.

Openwave は、ISP およびテレコム・サービス・プロバイダに対して、仲介とメッセージングのプロダクトを提供している。 そして同社は、次世代メッセージング・プラットフォームの基盤として Cassandra を適用しており、2011年の後半には実運用を開始する。 HBase と同様に Cassandra も、Google BigTable モデルから強く影響されているが、Amazon の Dynamo 分散 Key-Value ストアの概念も用いる。 当初、Cassandra は Facebook により開発され、その後は、Cloudkick(Rackspace が買収)/Digg/Twitter などで調査されている。

Openwave’s next generation platform must support geographic redundancy, massive scalability and high availability. It needed to be able to distribute databases redundantly across multiple data centers and handle large customer datasets – varying from hundreds of terabytes to petabytes, and supporting thousands of transactions per second from each customer.

Openwave の次世代プラットフォームは、地理的な冗長性および、手厚いスケーラビリティ、そして高度な可用性をサポートする必要がある。 具体的には、マルチ・データセンターをまたいだ分散データベースの冗長性と、顧客の大規模なデータセットを取り扱う能力が要求される。つまり、何100テラ・バイトからペタ・バイト・レベルまでのスケールと、それぞれの顧客から発信される数1000/秒のトランザクションをサポートすることになる。

Openwave settled on Cassandra after evaluating other non-relational databases including CouchDB and Voldemort. Cassandra was selected because of its multi-data center scalability and reliability.

Openwave は、CouchDB および Voldemort を含めたノン・リレーショナル・データベースを評価した後に、Cassandra に落ち着いた。 そして、Cassandra が選択された理由としては、マルチ・データセンターおよび、スケーラビリティ、信頼性があげられている。


Moving from the relational world to Cassandra required unlearning a lot of traditional techniques, particularly with respect to data modelling. In Cassandra, the data modeling is determined by the nature of the application queries rather than the nature of the data. Cassandra “Super Columns” essentially determine which child records will be accessible from a master record. Selecting the correct Super Column structure will therefore determine which queries can be supported. Furthermore, while relational data modeling starts with the elimination of redundant data, in Cassandra one would normally create multiple “Column Families” – roughly equivalent to an RDBMS table – to support the various questions that the application might ask. For instance, one Column Family might store sales grouped by customer, while another might store sales grouped by product.

リレーショナル世界から Cassandra へ向けた移行は、とりわけデータ・モデリングに関して、従来からのテクニックを捨てよと要求する。Cassandra におけるデータ・モデリングは、データの本質的な特性というより、アプリケーションが発行するクエリーの特性により決定される。 Cassandra の ”Super Colmuns" は本質的に、マスター・レコードからアクセス可能なチャイルド・レコードを決定する。したがって、正しい Super Colmun 構造の選択により、サポートが可能なクエリーが決定される。 さらに、リレーショナル・データ・モデリングが、冗長なデータ排除から始まるに対して、Cassandra では、アプリケーションが実行するかもしれない質問をサポートするための、マルチ “Column Families” (大まかには RDBMS テーブルと等しい)の作成から始まるだろう。 たとえば、ある Column Family は、顧客によりグループ化された Sales をストアし、別の  Column Family は、商品によりグループ化された Sales をストアするかもしれない。

“It was tempting to apply relational techniques that we know and love to Cassandra,” said Utpal Thakrar, product manager at Openwave. “It simply does not work. Performance gets impacted dramatically if the data model is ill-designed.”

『 私たちが慣れ親しんでいるリレーショナル・テクニックを、 Cassandra に適用することは魅力的だった。しかし、シンプルに言って、それは機能しない。 データ・モデルのデザインが悪いと、パフォーマンスに対して極端な悪影響が生じる 』と、であった」、と Openwave のプロダクト・マネージャーである Utpal Thakrar は発言する。

Like most of the non-relational database alternatives, Cassandra does not support the strong multi-object transactions found in the relational world. Cassandra supports “tuneable consistency” though, which allows the application to trade off between speed and consistency. For instance, an operation might choose the strictest consistency level, ensuring that all users of the database see the changes immediately. Another operation may choose a lower level of consistency, achieving higher throughput but permitting temporary inconsistencies as the changes are propagated through the system. “Applications that require transactional support have to be redesigned to play within the limitations of tunable consistency that Cassandra offers”, said Thakrar, “When in Rome, do as Cassandra does’ was the motto we had to preach throughout the organization.”

ノン・リレーショナル・データベースにおける、その他の選択肢の大半と同様に、リレーショナルの世界に見られる、ストロング・マルチ・オブジェクト・トランザクションを、Cassandra もサポートしない。 正、Cassandra は ” 調整可能なコンシステンシー” をサポートするため、スピードとコンシステンシーのトレードオフが、アプリケーションに提供される。 たとえば、ある運用モデルでは、最も厳しいコンシステンシー・レベルを選択し、すべてのユーザーがデータベースにおける変更を、同時に確認できることを保証する。 別の運用モデルでは、緩いコンシステンシー・レベルを選択し、より高いスループットを達成するが、変更がシステムを介してプロパゲートされるの待つような、一時的な矛盾を認めることになる。 『 トランザクショナル・サポートを要求するアプリケーションは、Cassandra が提供する構成可能なコンシステンシーの範囲内で、その実行を可能にするための再設計が必要となる。 郷に入れば郷に従えが、私たちの組織で徹底しなければならない標語になった 』と、Thakrar は発言する。

Moving from RDBMS to Cassandra has not been a trivial, and commercial support from Cassandra vendor Riptano (now DataStax) has been critical,” said Thakrar. “We have certainly run into issues, but are resolving them quickly with Riptano’s help.”

RDBMS から Cassandra へ向けた移行は簡単ではないため、Cassandra ベンダーである Riptano(現 DataStax)による商用サポートは重要である。 たしかに、私たちは問題に出くわしたが、Riptano の手助けにより、それらを迅速に解決している 』と、Thakrar は続ける。

To learn more about the factors driving big data and optimal strategies for solving it, including from Hadoop, NoSQL and MPP database leaders, come to our Big Data conference held on March 23 in NYC.

Hadoop から、NoSQL、そして MPP といった、最先端のデータベースを含めて、ビッグ・データを取り扱う際の要因について、また、それを解決するための最適化された戦略を学ぶために、 3月23日に NYC で開催される、私たちの Big Data conference に参加して欲しい。

Guy Harrison is a director of research and development at Quest Software, and has over 20 years of experience in database design, development, administration, and optimization. He can be found on the internet at, on e-mail at and is @guyharrison on twitter.

Related content from GigaOM Pro (sub req’d):


Cassandra におけるデータ・モデリングは、データの本質的な特性というより、アプリケーションが発行するクエリーの特性により決定される ・・・ ですか。 これは、あらゆる NoSQL に言えることなのでしょうね。 それにしても、いろいろと事例が出てきて、これからが楽しみです。 ーーー __AC Stamp 2


Real World NoSQL シリーズ – 4PB を処理する Trend Micro の HBase
Cassandra:6つの迷信と 6つの真実
Cassandra Summit 2010 でのスライドとビデオが公開
Cassandra はアメリカ政府に食い込み、Amazon EC2 でも利用できる
Cassandra – 永続性とは? そして何故に?
Windows Azure チームは、どのような興味を Cassandra に持っているのか?

One Response

Subscribe to comments with RSS.

  1. […] This post was mentioned on Twitter by Agile Cat, Agile Cat. Agile Cat said: そるそろ、事例の時期なのでしょうね RT @Metal_Oyaji: これも歴史は繰り返す的な動きですね☆ RT @Agile_Cat: Real World NoSQL シリーズ – Openwave における Cassandra […]

Comments are closed.

%d bloggers like this: