NoSQL Ecosystem とは？ _3

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

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.