Cassandra プロジェクトと Rackspace
The Cassandra Project
http://www.rackspacecloud.com/blog/2009/09/23/the-cassandra-project/
// September 23rd, 2009 // Development
By Jonathan Ellis, System Architect
You may have heard about the Cassandra distributed database in recent articles or conferences. I’d like to explain what advantages Cassandra offers over traditional relational databases like MySQL or Oracle and why Rackspace has committed resources to the Cassandra project.
最近の記事やカンファレンスで、Cassandra 分散データベースについて聞いたかもしれない。MySQL や Oracle といった、これまでのリレーショナル･データベースに対して、どのようなアドバンテージを Cassandra が提供するか、そして、Rackspace がCassandra プロジェクトに対する投資をコミットするる理由を説明する。
The Cassandra project was started by Facebook in 2007 to scale their internal applications, particularly Inbox Search. Earlier this year, they released it to the Apache incubator where other people from the community could become involved and start contributing. This allowed the project to move forward in a direction that is more general to the public than just to Facebook’s needs.
Cassandra プロジェクトは 2007年に Facebook において、特に Inbox Search などの、内部アプリケーションをスケールアウトするために初めて使用された。 今年の初めに Facebook は、コミュニティの人々が関与し貢献できる Apache インキュベータに、Cassandra をリリースした。それにより、Facebook のニーズだけではなく、より一般的でパブリックな方向に前進していくプロジェクトが実現された。
In March, I became the first outside committer to this Apache Incubator project. Eric Evans from Rackspace and Jun Rao from IBM Research soon followed, and we recently added Chris Goffinet from Digg. The community has grown from 5 people in the IRC channel in December to over 60.
そして 3月に私は、この Apache インキュベータ・プロジェクトの、最初の外部コミッターとなった。 Rackspace の Eric Evans と、IBM Research のJun Rao が、その直ぐ後に続き、最近になって Digg の Chris Goffinet が加わった。このコミュニティは、12 月時点の IRC チャネルにおける 5人から、60 人を超えるまでに成長した。
Distributed vs. Relational Databases
Traditional relational databases are 30 years old, are well understood and have a huge ecosystem of tools around them. For that reason, it’s a compelling option when building your application. Postgres, MySQL, and Oracle are all relational databases modeling a schema on entities and relations between those entities. That’s a good, powerful programming model with interesting theoretical properties. But companies with large amounts of data have already gone past what you can reasonably fit on a single machine, even on high-end hardware, and it’s provably impossible to keep the traditional relational model, in particular the ACID properties, while scaling across multiple machines. Even if you’re willing to give up availability, scaling reads (via caching and replication) is difficult with relational databases, and scaling writes by partitioning is either very expensive, very painful from an application programming and operations standpoint, or both.
伝統的なリレーショナル･データベースは、その誕生から 30年を経過し、適切に理解され、そして、その周辺のツールと共に巨大なエコシステムを保持している。それらの理由により、一般的なアプリケーションを構築するときの説得力のある選択肢となっている。 Postgres や、MySQL、Oracle などは、その全てが、エンティティ上のスキーマと、エンティティ間に関係をモデリングする、リレーショナル･データベースである。 それは、理論的なプロパティへの関与を用いた、パワフルなプログラミング･モデルである。しかし、すでに膨大なデータを持つ企業は、それがハイエンド･ハードウェアであっても、シングル･マシンにフィットするデータ量を超えてしまい、とりわけ、ACID プロパティにおいては、従来からのリレーショナル･データベース･モデルを保持することは不可能となっているはずだ。たとえ可用性を犠牲にするとしても、（キャッシングとリプリケーションにより）読み取りのスケールをリレーショナル･データベースで調整することは困難であり、また、パーティショニングにより書き込みのスケールを調整することは、極めて高価なものとなる。したがって、アプリケーションのプログラミングとオペレーションの視点から、あるいは双方の視点から見ても、大きな痛みをもたらすことになる。
Cassandra is taking the approach that, given that you’re going to have to give up some parts of the relational model to scale, let’s start over and rethink things. Let’s add things like transparent replication and failover, built-in partitioning and load balancing, multiple data center support, and the ability to add capacity without ever disturbing applications running against the database.
Cassandra が採用するアプローチは、リレーショナル･モデルをスケーするという、いくつかの部分を断念することを前提とし、リンクを最初からやり直すことである。 そのために追加するものとしては、トランスペアレントなリプリケーションとフェイルオーバーおよび、ビルトインのパーティショニングとロード･バランシング、マルチ･データセンター･サポート、そして、データベースに反してアプリケーションの実行を止めることなくキャパシティを増やす能力などがある。
Rackspace’s Involvement
The original Facebook team has been busy elsewhere, so the community has had to step up and take the initiative in moving Cassandra forward. Cassandra is open source and I don’t want to downplay others’ contributions, including those from IBM Research, Digg, and Twitter as well as other companies and individuals, but I’m proud that Rackspace’s support has been instrumental in adding many important new features, fixing bugs, and getting out new releases.
オリジナルの Facebook チームは多忙であるため、コミュニティは Cassandra forward を前進させるために、イニシアティブを見出し、ステップアップして良く必要があります。Cassandra はオープンソースであり、IBM Research／Digg／Twitter などの企業や、個人からのコントリビューションを軽視するものではないが、これまでに、Rackspace が重要な機能を加えて、バグを修正し、新しいリリースの配布において、重要な役割を担ってきたことにを誇りに思う。
Here are 3 reasons why Rackspace has committed resources:
こうして、Rackspace がコントリビュートしてきた理由は、以下のとおりである：
1- As stated in previous posts by Erik Carlin, we are committed to an Open Cloud. With Amazon’s Simple DB or Google App Engine’s datastore, you’re locked in. Cassandra presents an open alternative: you can write against Cassandra and deploy anywhere. That’s important.
1- Erik Carlin の以前のポストで述べられているように、私たちは Open Cloud をコミットする。 Amazon の Simple DB であっても、Google App Engine の Datastore であっても、ユーザーはロックインされる。Cassandra が提示するのはオープンな選択肢であり、Cassandra を前提とした記述の、他へのディプロイを実現する。それは、重要なことである。
2- We have a suite of Cloud products that are productized beyond just the raw Cloud Servers. Cassandra is interesting to us because we can use it under the hood to improve Cloud Sites and Cloud Files. And people are already starting to ask, “When can I just go to Rackspace and deploy a preconfigured Cassandra cluster?” It’s still early, but that’s definitely something we’re looking at.
2- 私たちの Cloud プロダクト･スイートは、単なる素材としての Cloud Servers を超えて効率化されている。 私たちが Cassandra に引きつけられるのは、Cloud Sites と Cloud Files を改善するための体系の中で、それを利用できるからである。 そして人々は、”Rackspace へ移行して、事前にコンフィグレーションされている Cassandra クラスタをディプロしできますか？」という、質問をし始めている。 それはまだ、早期に過ぎるが、私たちが注目しているものがある。
3- Rackspace itself has a ton of data that we generate from our switches and routers and the rest of our infrastructure. Right now we are getting by with traditional monitoring and logging technologies, searching those logs and so forth. Cassandra will help us a lot with that as our volumes continue to increase. Our Mail & Apps products are also very interested in using Cassandra to store mail messages and other data.
3- Rackspace 自身が膨大なデータを保有しているが、それらは、私たちのスイッチとルーターから生成され、また、その他のインフラストラクチャから生成される。 そしていま、従来からのモニタリングや、ログ、サーチのテクノロジーで問題を処理し、前へと進んでいる。私たちの保有するデータ量が増加し続けるにつれて、 それらの活用を Cassandra が支援するだろう。私たちの Mail & Apps プロダクトにおいても、メールメッセージと他のデータをストアするために、Cassandra を活用しようと前向きに検討している。
Finally, I want to emphasize Cassandra is not a magic bullet. You can’t just take your SQL app and put it on Cassandra and expect it to work. It’s a different programming model and instead of modeling as entities and relationships and just adding indexes to get performance, you need to think at a more basic level: “What information do I need to retrieve from each query?” and model your Cassandra schema accordingly. It’s a different way of thinking and does require new code to be written. It’s very much for people that have a lot data that doesn’t fit on a single machine and are feeling the pain from traditional approaches to scaling that.
最後に、Cassandra が特効薬ではないところを強調しておきたい。何らかの SQL アプリケーションを取り出して、Cassandra に押し込んでも、それが機能すると期待しないで欲しい。それは、別種のプログラミング･モデルであり、エンティティとリレーションのモデリングに替えて、また、パフォーマンスを得るためにインデックスを加えるだけのモデリングに替えて、より以上に基本的なレベルで考える必要がある：”それぞれのクエリーから、どのような情報を引き出す必要があのか？” という点を考え、それに従ったCassandra スキーマをモデリングしていく。 それは、異なる考え方であり、また、新しいコードの記述を必要とする。それは、シングル･マシンにフィットしないデータをもち、そのスケーリングに痛みを感じている人々に、きわめて適合するものとなる。
We plan to write some other posts in the future detailing what a switch might look like for some sample applications.
こうした考え方の切り替えを、詳細に示すサンプル･アプリケーションについて、今後のポストで説明していくことを計画している。
＜関連＞
NoSQL Ecosystem とは？ _1
NoSQL Ecosystem とは？ _2
NoSQL Ecosystem とは？ _3
nosql-ja
サーバー保有台数ランキング
Rackspace のクラウド料金体系
ISP とクラウド経済
NoSQL Ecosystem とは？ _1
NoSQL Ecosystem
http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/#
// November 9th, 2009 // Development
By Jonathan Ellis, Systems Architect
Unprecedented data volumes are driving businesses to look at alternatives to the traditional relational database technology that has served us well for over thirty years. Collectively, these alternatives have become known as “NoSQL databases.”
前例のないデータ量が、30 年以上にもわたって適切なサービスを提供してきた、伝統的なリレーショナル･データベース･テクノロジーに替る選択肢を探し出せと、ビジネスに対して働きかけている。それらの代替物を集約すると、「NoSQL データベース」として認識されるものとなる。
The fundamental problem is that relational databases cannot handle many modern workloads. There are three specific problem areas: scaling out to data sets like Digg’s (3 TB for green badges) or Facebook’s (50 TB for inbox search) or eBay’s (2 PB overall), per-server performance, and rigid schema design.
根本的な問題は、近年になって生じてきた、数多くの新しいワークロードを、リレーショナル･データベースが取り扱えない点にある。つまり、Digg（3 TB for green badges）／Facebook（50 TB for inbox search）／eBay（2 PB overall） のようなデータセットのスケールアウトおよび、サーバーごとのパフォーマンス、そして固定的なスキーマ設計という、3つの問題点がある。
Businesses, including The Rackspace Cloud, need to find new ways to store and scale large amounts of data. I recently wrote a post on Cassandra, a non-relational database we have committed resources to. There are other non-relational databases being worked on and collectively, we call this the “NoSQL movement.”
The Rackspace Cloud を含めたビジネスにおいて、大量のデータをストアし、また、調整していくための、新しい方式が必要とされている。Cassandra に関する先日のポストでは、そのためのリソースとして、Non リレーショナル･データベースをコミットしていると書いた。 その他にも、運用されている Non リレーショナル･データベースがあり、それらを集約して「NoSQL ムーブメント」と称している。
The “NoSQL” term was actually coined by a fellow Racker, Eric Evans when Johan Oskarsson of Last.fm wanted to organize an event to discuss open source distributed databases. The name and concept both caught on.
この「NoSQL」という用語は、オープンソース分散データベースについてディスカッションするために、Last.fm の Johan Oskarsson がイベントを開催したいと望んだときに、Rackspace と親しい Eric Evans が言い出したものである。そして、その名前とコンセプトが、広く用いられるようになった。
Some people object to the NoSQL term because it sounds like we’re defining ourselves based on what we aren’t doing rather than what we are. That’s true, to a degree, but the term is still valuable because when a relational database is the only tool you know, every problem looks like a thumb. NoSQL is making people aware that there are other options out there. But we’re not anti-relational-database for when that really is the best tool for the job; it’s “Not Only SQL,” rather than “No SQL at all.”
何人かの人々は、私たちが行う以外のことを、指し示す定義のように聞こえるという理由から、NoSQL という用語に反対した。それは、ひとつの局面から見れば事実であるが、リレーショナル･データベースが唯一のツールであり、何も問題がないと認識されている場合には、この用語は意味を成す。 つまり、他の選択肢があることを、NoSQL は人々に知らせることになる。 ただし、私たちはアンチ･リレーショナル･データベースではなく、また、現実的な面で作業に適したツールが欲しいだけであり、“No SQL at all” ではなく “Not Only SQL” なのである。
One real concern with the NoSQL name is that it’s such a big tent that there is room for very different designs. If this is not made clear when discussing the various products, it results in confusion. So I’d like to suggest three axes along which to think about the many database options: scalability, data and query model, and persistence design.
NoSQL という名前から連想すべきことは、それが極めて大きなテントであり、その中に、各種のデザインを収めるためのスペースがあるということだ。その点を明確にせずに、また、個々のプロダクトについて議論するとき、混乱が生じるだろう。そのため、数多くのデータベース・オプションについて考えるための、 scalability／data and query model／persistence design という3つの機軸を提案する。
I have chosen 10 NoSQL databases as examples. This is not an exhaustive list, but the concepts discussed are crucial for evaluating others as well.
サンプルとして、10 種類の NoSQL データベースを選んだ。それは、包括的なリストではないが、それらの概念は、他の製品を評価する上で、決定的な指標となる。
ーーーーー
先日、CloudNewsCenter の鈴木逸平さんとお会いしたとき、Cloud を取り扱う日本のメディアは、なぜ Google ばかりを追いかけ、Rackspace には見向きもしないのか、という話題になりました。 この、クラウド界の実力者が、NoSQL にも深く関わっていることに、とても興味があります。 ーーー A.C.
＜関連＞
NoSQL Ecosystem とは？ _1
NoSQL Ecosystem とは？ _2
NoSQL Ecosystem とは？ _3
nosql-ja
サーバー保有台数ランキング
Rackspace のクラウド料金体系
ISP とクラウド経済
＜続く・・・＞
NoSQL Ecosystem とは？ _2
NoSQL Ecosystem
http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/#
// November 9th, 2009 // Development
By Jonathan Ellis, Systems Architect
Scalability
Scaling reads is easy with replication, so when we’re talking about scaling in this context, we mean scaling writes by automatically partitioning data across multiple machines. We call systems that do this “distributed databases.” These include Cassandra, HBase, Riak, Scalaris, Voldemort, and more. If your write volume or data size is more than one machine can handle then these are your only options if you don’t want to manage partitioning manually. (You don’t.)
このコンテキストにおいて、スケーリングについて論じるとき、リプリケーションを用いることで読み取りの調整は簡単に行える。 つまり、マルチ･マシンをまたいでデータを自動的にパーテショニングする、書き込みのスケーリングが論点となる。そのようなシステムを、ここでは「分散データベース」と呼ぶ。たとえば、Cassandra／HBase／Riak／Scalaris／Voldemort などが、そこには含まれる。 そこには、1台のマシンでは処理し切れない量の、データを書き込む場合の選択肢がある。もし、手作業によりパーティショニングを行いたくないなら、唯一の選択肢となる。
There are two things to look for in a distributed database: 1) support for multiple datacenters and 2) the ability to add new machines to a live cluster transparently to your applications.
分散データベースには 2つのポイントがある。 それらは、1)マルチ･データセンターのサポートと、2) 対象となるアプリケーションのための活きたクラスタに対して、新しいマシンを透過的に加える能力である。
Non-distributed NoSQL databases include CouchDB, MongoDB, Neo4j, Redis, and Tokyo Cabinet. These can serve as persistence layers for distributed systems; MongoDB provides limited support for sharding, as does a separate Lounge project for CouchDB, and Tokyo Cabinet can be used as a Voldemort storage engine.
非分散型の NoSQL データベースには、 CouchDB ／MongoDB／Neo4j／Redis／Tokyo Cabinet が含まれる。 それらは分散システムのための、永続的なレイヤーの役割を担える。 つまり、MongoDB は sharding のための限定されたサポートを提供し、CouchDB のための分離された Lounge プロジェクトとして機能し、Tokyo Cabinet は Voldemort のストレージ･エンジンとして利用される。
Data and Query Model
There is a lot of variety in the data models and query APIs in NoSQL databases.
NoSQLデータベースには、多種多彩なデータモデルとクエリー API がある。
(Respective Links: Thrift, map/reduce views, Thrift, Cursor, Graph, Collection, Nested hashes, get/put, get/put, get/put)
Some highlights:
The columnfamily model shared by Cassandra and HBase is inspired by the one described by Google’s Bigtable paper, section 2. (Cassandra drops historical versions, and adds supercolumns.) In both systems, you have rows and columns like you are used to seeing, but the rows are sparse: each row can have as many or as few columns as desired, and columns do not need to be defined ahead of time.
Cassandra と HBase で共有されるcolumnfamily モデルは、Google の Bigtable ペーパーのセクション 2に記述されたことに触発されている（Cassandra はヒストリカル･バージョンを廃して、supercolumns を加える）。 双方のシステムにおいて、見慣れた Row/Column を持つことが可能だが、その Row の数は少ない。 つまり、それぞれの Row は、必要に応じたCloumn 数を持つことが可能であり、さらに、Column を事前に定義する必要はない。
The Key/value model is the simplest and easiest to implement but inefficient when you are only interested in querying or updating part of a value. It’s also difficult to implement more sophisticated structures on top of distributed key/value.
この Key/Value モデルの実装は、最も簡潔で簡単だが、それらの値の一部だけをクエリーおよびアップデートするだけなら、効果的なものにはならない。さらに言えば、分散された Key/Value の上に、洗練された構造を実装することが困難になる。
Document databases are essentially the next level of Key/value, allowing nested values associated with each key. Document databases support querying those more efficiently than simply returning the entire blob each time.
ネストされた値と個々の Key を結びつけるドキュメント･データベースは、Key/Value モデルにおける次の重要なテーマとなる。データベースがサポートするクエリーは、その都度 Blob 全体をリターンする方式よりも、効果的なものとなる。
Neo4J has a really unique data model, storing objects and relationships as nodes and edges in a graph. For queries that fit this model (e.g., hierarchical data) they can be 1000s of times faster than alternatives.
Neo4J は、クラフにおけるノードとエッジとして、特徴的なデータ・モデルおよび、強化されたオブジェクトとリレーションを持つ。このモデル（たとえば階層的なデータ）に適合するクエリーのために、その他のテクノロジーと比較して 1000倍ほど高速になるだろう。
Scalaris is unique in offering distributed transactions across multiple keys. (Discussing the trade-offs between consistency and availability is beyond the scope of this post, but that is another aspect to keep in mind when evaluating distributed systems.)
Scalaris は、マルチ･キーをまたいだ分散トランザクションを提供するという点でユニークである。（コンシステンシーとアベイラビリティのトレードオフという論点は、このポストのスコープ外となるが、分散システムを評価する際に、気に留めておくべき別の局面となる）
ーーーーー
抄訳といっても、ちょっとアヤフヤ過ぎるところがあるかと思います。 ご指摘などをいただけると嬉しいです。 ーーー A.C.
＜関連＞
NoSQL Ecosystem とは？ _1
NoSQL Ecosystem とは？ _2
NoSQL Ecosystem とは？ _3
nosql-ja
サーバー保有台数ランキング
Rackspace のクラウド料金体系
ISP とクラウド経済
＜続く・・・＞
NoSQL Ecosystem とは？ _3
NoSQL Ecosystem
http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/#
// November 9th, 2009 // Development
By Jonathan Ellis, Systems Architect
Persistence Design
By persistence design I mean, “how is data stored internally?”
私の考える、パーシスタンスに関するデザインとは、"どのような方式で、データを内部的にストアするか？" ということである。
The persistence model tells us a lot about what kind of workloads these databases will be good at.
上記のデータベースが、どのような種類のワークロードを得意とするのか、パーシスタンス･モデルというものが教えてくれる。
In-memory databases are very, very fast (Redis achieves over 100,000 operations per second on a single machine), but cannot work with data sets that exceed available RAM. Durability (retaining data even if a server crashes or loses power) can also be a problem; the amount of data you can expect to lose between flushes (copying the data to disk) is potentially large. Scalaris, the other in-memory database on our list, tackles the durability problem with replication, but since it does not support multiple data centers your data will be still be vulnerable to things like power failures.
イン･メモリのデータベースは、桁外れに高速であるが（Redis はシングル･マシン上で毎秒100,000回のオペレーションを実行する）、利用可能な RAM を超えるデータセットは取り扱えない。さらに、耐障害性（サーバー･クラッシュや停電でもデータを維持る）も問題となり得る。つまり、フラッシュ（ディスクへのデータ・コピー）を行わない間に失うことになるデータは、きわめて大量のものとなり得る。上記のリストにおける、別種のインメモリー･データベースである Scalaris は、リプリケーションを用いて耐久性の問題に取り組む。ただし、複数のデータセンターをまたぐサポートが無いため、依然として停電などの被害を免れない。
Memtables and SSTables buffer writes in memory (a “memtable”) after writing to an append-only commit log for durability. When enough writes have been accepted, the memtable is sorted and written to disk all at once as a “sstable.” This provides close to in-memory performance since no seeks are involved, while avoiding the durability problems of purely in-memory approaches. (This is described in more detail in sections 5.3 and 5.4 of the previously-referenced Bigtable paper, as well as in The log-structured merge-tree.)
Memtables と SSTables のバッファは耐障害性を確保するために、append-only commit log を書いた後に、イン･メモリ（memtable）での書き込みを行う。必要とされる書き込みが受け付けられたとき、 この memtable はソートされ、ひとまとめにされた ”sstable” としてディスクに書き込まれる。それにより、seek が消費する時間が無関係となるため、インメモリーに近いパフォーマンスが提供されるが、純粋なインメモリーのアプローチにおける、永続性の問題は回避されてしまう。（その点については、以前に参照した Bigtable ペーパーのセクション 5.3 と 5.4 に詳述されている。また、 The log-structured merge-tree のセクションにも、同様に記述されている）
B-Trees have been used in databases since practically the beginning of time. They provide robust indexing support, but performance is poor on rotational disks (which are still by far the most cost-effective) because of the multiple seeks involved in reading or writing anything.
B-Trees は、とりわけ、その初期において、データベースを使ってきた。そこでは、堅牢なインデックスがサポートされるが、読み書きにおいて、たくさんの seek が生じるため、（依然として費用効果が最も高い）磁気ディスク上でのパフォーマンスは低い。
An interesting variant is CouchDB’s append-only B-Trees, which avoids the overhead of seeks at the cost of limiting CouchDB to one write at a time.
面白い使い方は、CouchDB の append-only B-Trees であり、CouchDB からの書き込みを1回に制限するという犠牲を払って、seek によるオーバーヘッドを回避する。
Conclusion
The NoSQL movement has exploded in 2009 as an increasing number of businesses wrestle with large data volumes. The Rackspace Cloud is pleased to have played an early role in the NoSQL movement, and continues to commit resources to Cassandra and support events like NoSQL East.
NoSQL conference announcements and related discussion can be found on the Google discussion group.
NoSQL ムーブメントは、大量のデータと格闘する企業が増えるにつれて高まり、2009年に爆発した。NoSQL の早期において、Rackspace Cloud は積極的に活動してきた。そして、Cassandra と NoSQL East などのイベントに対して、リソースを提供し続けていく。NoSQL カンファレンスと、それに関連するディスカッションは、Google ディスカッション・グループで参照できる。
ーーーーー
昨日ですが、http://twitter.com/Agile_Cat 上で、” なぜ エコシステムなんだ? ” というディスカッションが、http://twitter.com/okachimachiorz さん、そして http://twitter.com/tatsuya6502 さんとの間になりました。 著者の意図が掴めないのですが、みなさんは どう思います？ ーーー A.C.
＜関連＞
NoSQL Ecosystem とは？ _1
NoSQL Ecosystem とは？ _2
NoSQL Ecosystem とは？ _3
nosql-ja
サーバー保有台数ランキング
Rackspace のクラウド料金体系
ISP とクラウド経済
＜おわり＞
leave a comment