NoSQL Ecosystem とは？ _2

Posted in HDFS, NoSQL, Parallel by Agile Cat on December 9, 2009

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.