Agile Cat — in the cloud

Facebook の HBase は、毎月 1350億 メッセージを処理する!

Posted in Big Data, Facebook, HDFS, NoSQL by Agile Cat on November 18, 2010

Facebook’s New Real-Time Messaging System: HBase To Store 135+ Billion Messages A Month


You may have read somewhere that Facebook has introduced a new Social Inbox integrating email, IM, SMS,  text messages, on-site Facebook messages. All-in-all they need to store over 135 billion messages a month. Where do they store all that stuff? Facebook’s Kannan Muthukkaruppan gives the surprise answer in The Underlying Technology of Messages: HBase. HBase beat out MySQL, Cassandra, and a few others.

Facebook が導入する新しい Social Inbox が、電子メールおよび、IM、SMS、テキスト・メッセージ、Facebook オン・サイト・メッセージを統合するという記事を、どこかのメディアで読んでいると思う。 全般的に見て、Facebook は 1カ月に、1350億以上のメッセージをストアする必要がある。それら全てを、何処にストアするのであろうか? Facebook の Kannan Muthukkaruppan は、The Underlying Technology of MessagesHBase だと答えて、多くの人々を驚かせた。 つまり、HBase は、MySQL や、Cassandra などを打ち負かしたことになる。


Why a surprise? Facebook created Cassandra and it was purpose built for an inbox type application, but they found Cassandra’s eventual consistency model wasn’t a good match for their new real-time Messages product. Facebook also has an extensive MySQL infrastructure, but they found performance suffered as data set and indexes grew larger. And they could have built their own, but they chose HBase.

なぜ、それが驚きなのだろうか? Facebook は、InBox タイプのアプリケーションを目的として Cassandra を作り出した。しかし、Cassandra のイベンチュアル・コンシステンシー・モデルが、今回の新しいリアル・タイム Messages に適合しないことに気付いた。 また、Facebook は大規模な MySQL インフラストラクチャを有しているが、これまで以上の大規模なデータセットとインデックスにおいて、パフォーマンスの問題が生じることを見いだした。 さらに Facebook は、独自のものを構築できたはずだが、HBase を選択した。

HBase is a scaleout table store supporting very high rates of row-level updates over massive amounts of data. Exactly what is needed for a Messaging system. HBase is also a column based key-value store built on the BigTable model. It’s good at fetching rows by key or scanning ranges of rows and filtering. Also what is needed for a Messaging system. Complex queries are not supported however. Queries are generally given over to an analytics tool like Hive, which Facebook created to make sense of their multi-petabyte data warehouse, and Hive is based on Hadoop’s file system, HDFS, which is also used by HBase.

HBase は スケールアウト型のテーブル・ストアであり、きわめて頻度の高い Row レベル・アップデートを、大量のデータに対してサポートする 。 まさに、Messaging システムにとって必要とされるものである。 さらに HBase は、BigTable モデル上に構築される、Column ベースの  key-value ストアでもある。 それは、Key によるフェッチや、Row レンジのスキャン、そしてフィルタリングに優れている。これも、Messaging システムにとって必要とされるものである。 しかし、複雑なクエリーがサポートされていない。クエリーは、一般的には Hive のような Analytics ツールへと託される。 Hive とは、数ペタバイト・オーダーのデータ・ウエアハウスを活用するために、Facebook が作成したものである。そして Hive は、Hadoop のファイル・システムである HDFS をベースにするが、それは HBase でも使用されるものである。

Facebook chose HBase because they monitored their usage and figured out what the really needed. What they needed was a system that could handle two types of data patterns:

Facebook が HBase を選択した理由は、自らの用法をモニターし、実際に必要とされるものを理解したところにある。彼らが必要としたものは、2種類のデータ・パターンを取り扱うことができるシステムだ:

  1. A short set of temporal data that tends to be volatile
  2. An ever-growing set of data that rarely gets accessed
  1. 揮発性の高い、一時的なデータのショート・セット
  2. 頻繁にはアクセスされない、永遠に成長していくデータ・セット

Makes sense. You read what’s current in your inbox once and then rarely if ever take a look at it again. These are so different one might expect two different systems to be used, but apparently HBase works well enough for both. How they handle generic search functionality isn’t clear as that’s not a strength of HBase, though it does integrate with various search systems.

尤もである。 あなたは、InBox のカレント・データを一度読む。 そして、もう一度読むにしても、それは稀なことである。 それらは、きわめて異なる要件であり、2種類のシステムを使うべきかもしれないが、HBase は双方において充分に機能するらしい。一般的なサーチ機能については、そこに HBase の強みがないため、方式は明らかにされない。したがって、各種のサーチ・システムを統合することになるだろう。

Some key aspects of their system:


  • HBase:
    • Has a simpler consistency model than Cassandra.
    • Very good scalability and performance for their data patterns.
    • Most feature rich for their requirements: auto load balancing and failover, compression support, multiple shards per server, etc.
    • HDFS, the filesystem used by HBase, supports replication, end-to-end checksums, and automatic rebalancing.
    • Facebook’s operational teams have a lot of experience using HDFS because Facebook is a big user of Hadoop and Hadoop uses HDFS as its distributed file system.
    • Cassandra と比較して、よりシンプルなコンシステンシー・モデルを持つ
    • Facebook のデータ・パターンに対して、最適なスケーラビリティと性能
    • この要件に対するリッチな機能:オート・ロード・バランシングとフェイルオーバーおよび、圧縮のサポート、サーバーごとの multiple shard。
    • HBase で用いられる HDFS(ファイル・システム)による、リプリケーションおよび、End-to-End チェックサム、自動的な rebalancing のサポート
    • Facebook の運用チームが有する、HDFS 利用のエクスペリエンス。 Facebook が Hadoop のビッグ・ユーザーであり、Hadoop の分散型ファイル・システムとしてHDFS を利用
  • Haystack is used to store attachments.
  • A custom application server was written from scratch in order to service the massive inflows of messages from many different sources.
  • A user discovery service was written on top of ZooKeeper.
  • Infrastructure services are accessed for: email account verification, friend relationships, privacy decisions, and delivery decisions (should a message be sent over chat or SMS?).
  • Keeping with their small teams doing amazing things approach, 20 new infrastructures services are being released by 15 engineers in one year.
  • Facebook is not going to standardize on a single database platform, they will use separate platforms for separate tasks. 
  • ストア・アタッチメントのために Haystack を使用
  • カスタム・アプリケーション・サーバを、スクラッチで記述。多様なソースから流入する、大量のメッセージに対応するため
  • ユーザー・ディスカバリー・サービスを、ZooKeeper 上に記述
  • インフラストラクチャ・サービスへのアクセス:電子メール・アカウント検証および、フレンド・リレーション、プライバシー設定、配達設定(例:メッセージをチャットや SMS に送信するか?)
  • 驚くほど、小規模なチームによるアプローチ。20 種類の新しいインフラストラクチャ・サービスを、15人のエンジニアにより 1年間でリリース
  • Facebook は、単一のデータベース・プラットフォームを標準にはしない。それぞれのタスクに適合した、それぞれのプラットフォームを使用


I wouldn’t sleep on the idea that Facebook already having a lot of experience with HDFS/Hadoop/Hive as being a big adoption driver for HBase.  It’s the dream of any product to partner with another very popular product in the hope of being pulled in as part of the ecosystem. That’s what HBase has achieved. Given how HBase covers a nice spot in the persistence spectrum–real-time, distributed, linearly scalable, robust, BigData, open-source, key-value, column-oriented–we should see it become even more popular, especially with its anointment by Facebook.

これは、一夜漬けのアイデアではないだろう。 すでに Facebook は、HBase の大規模実装をドライブするための エクスペリエンス を、HDFS / Hadoop / Hive により有している。  それは、エコシステムの一部として取り込みたいポピュラーなプロダクトを、あらゆるプロダクトと組み合わせるという、夢のような話である。 そして、それは HBase により達成されたことである。パーシスタンス領域の、ちょうど良い部分をカバーする方法が、HBase に提供されたことになる。そこでは、リアルタイムや、分配、リニア・スケーラブル、堅牢性、BigData、オープンソース、Key-Value Column が実現される。そして、Facebook の大きな一歩により、さらに HBase がポピュラーになっていく状況が、確認できるはずだ。

Related Articles


きわめて大量のデータを、きわめて洗練されたアプローチで処理! さすがですね、Facebook は。  以下の Big Link 集も、ぜひ、ご利用ください 🙂 ーーー A.C.


Hadoop DFS _ Introduction
HDFS のスケーラビリティを考察する _1
HDFS のスケーラビリティを考察する _2
HDFS のスケーラビリティを考察する _3
Apache ZooKeeper による分散並列キューの構築 _1
Apache ZooKeeper による分散並列キューの構築 _2
Apache ZooKeeper による分散並列キューの構築 _3
Apache ZooKeeper による分散並列キューの構築 _4
Observers と ZooKeeper _1
Observers と ZooKeeper _2
Gridmix3 : Apache Hadoop の実運用負荷をエミュレート _1
Gridmix3 : Apache Hadoop の実運用負荷をエミュレート _2
Gridmix3 : Apache Hadoop の実運用負荷をエミュレート _3
Facebook のメッセージング・インフラを、再構築する立役者は HBase だ!
Facebook の Social Inbox は、単なる Email ではない!
Google vs. Facebook のメール対決で盛り上がる全米
これが Facabook の Mail Server、Project Titan なのか?
Facebook は Google キラーを発表するのか?

Comments Off on Facebook の HBase は、毎月 1350億 メッセージを処理する!

Facebook の HDFS クラスターは 21 PB !!!

Posted in Big Data, Facebook, HDFS by Agile Cat on June 25, 2010

Facebook has the world’s largest Hadoop cluster!


なにげなく Facebook を見ていたら、こんなポストが ・・・ これまでは秘密だったみたいですね。 スゴイ! ーーー A.C.


It is not a secret anymore!

The Datawarehouse Hadoop cluster at Facebook has become the largest known Hadoop storage cluster in the world. Here are some of the details about this single HDFS cluster:

  • 21 PB of storage in a single HDFS cluster
  • 2000 machines
  • 12 TB per machine (a few machines have 24 TB each)
  • 1200 machines with 8 cores each + 800 machines with 16 cores each
  • 32 GB of RAM per machine
  • 15 map-reduce tasks per machine

That’s a total of more than 21 PB of configured storage capacity! This is larger than the previously known Yahoo!’s cluster of 14 PB. Here are the cluster statistics from the HDFS cluster at Facebook:





HDFS のスケーラビリティを考察する _1
Hadoop DFS _ Introduction

Tagged with: , ,

Comments Off on Facebook の HDFS クラスターは 21 PB !!!

HDFS のスケーラビリティを考察する _3

Posted in HDFS by Agile Cat on June 24, 2010

Scalability of the Hadoop Distributed File System _3
Yahoo! Developer Network Blog
May 5, 2010



Reasonable Load Expectations

We have learned by now that the name-node can use 70% of its time to process external client requests. Even with a handful of clients one can saturate the name-node performance by letting the clients send requests to the name-node with very high frequency. The name-node most probably would become unresponsive, potentially sending the whole cluster into a tailspin because internal load requests do not have priority over regular client requests.

これまでに、外部クライアントのリクエストを処理する時間の 70% を、Name-Node が使えるを学んできた。 ただし、ひと握りのクライアントを用いるときでさえ、クライアントから Name-Node へ向けて極端な頻度でリクエストを送信すると、Name-Node は飽和してしまうだろう。 内部に負荷をもたらすリクエストが、クライアントからの一般的なリクエストに対して優先されないと、大半のケースにおいて Name-Node は反応を失い、クラスタ全体を急速に劣化させる可能性を生じる。

In practice, the extreme load bursts are uncommon. Regular Hadoop clusters run MapReduce jobs, and jobs perform conventional file reads or writes. To get or put data from or to HDFS, a client first accesses the name-node and receives block locations, and then directly talks to data-nodes to transfer file data. Thus the frequency of name-node requests is bound by the rate of data transfer from data-nodes.

現実的に見て、極端な負荷によるバーストは一般的ではない。 通常の Hadoop クラスタは MapReduce のジョブを実行し、それらのジョブが標準的なファイルの Read/Write を行う。 HDFS を相手にデータの送受信を行うために、クライアントは最初に Name-Node にアクセスし、ブロックのロケーションを受け取り、続いて、ファイル・データを転送するために、Data-Node とダイレクトに交信する。したがって、Name-Node におけるリクエストの頻度は、Data-Node からのデータ転送のレートにより拘束される。

Typically a map task of a MapReduce jobs reads one block of data. We estimate how much time it takes for a client to retrieve a block replica and, based on that, evaluate the expected read load on the name-node — namely, how many “get block location” requests the name-node should expect per second from 100,000 clients. We apply the same technique to evaluate the write load on the cluster.

典型的な MapReduce ジョブのマップ・タスクは、1つのデータ・ブロックを読み込む。
私たちは、クライアントがブロック・レプリカを取得するために、費やす時間を見積もることができる。そして、それに基づいて、Name-Node 上での読み取りの負荷を評価する。 つまり、Name-Node が想定すべき、1秒あたりの "get block location" リクエスト数を、10,000 クライアントを前提として予測することになる。クラスタにおける書き込みの負荷に対しても、同じテクニックで評価できる。

Performance Limitations

The read and write throughputs have been measured by the DFSIO benchmark and are summarized in Table 3.

この read/write に関するスループットは、Table 3 に示されるように、DFSIO ベンチマークにより測定されている。


Another series of throughput results produced by NNThroughputBenchmark (Table 4) measures the number of open (the same as get block location) and create operations processed by the name-node per second:

NNThroughputBenchmark (Table 4)により生成される、もう 1つのスループットは、Name-Node により 1 秒ごとに処理される、ブロックのオープン(get block location と同じ)と作成に関する頻度を測定している。


The read throughput in Table 3 indicates that 100,000 readers are expected to produce 68,750 get-block-location requests to the name-node per second. And Table 4 confirms that the name-node is able to process that many requests even if only 70% of its processing capacity is dedicated to this task.

NNThroughputBenchmark (Table 4)により生成される、もう 1つのスループットは、1 秒ごとに Name-Node により処理される、ブロックのオープン(get block location と同じ)と作成に関する頻度を測定している。Table 3 における read スループットによると、100,000 reader が Name-Node に対して、1秒あたり 68,750 回の get-block-location リクエストを発行すると予測される。 そして Table 4 では、このタスクが占有する処理容量の 70% であっても、Name-Node が数多くのリクエストを処理できることが確認される。

A 10,000 node HDFS cluster with the internal load at 30% will be able to handle an expected read-only load produced by 100,000 HDFS clients.

30% の内部負荷を伴なう 10,000ノードの HDFS クラスタは、100,000の HDFS クライアントが生じる read-only の負荷を処理できるだろう。

The write performance is not as optimistic. According to Table 3, 100,000 writers are expected to provide an average load of 41,667 create block requests per second on the name-node. This is way above 3,920 creates per second — 70% of possible processing capacity of the name-node (see Table 4).

書き込みのパフォーマンスに関しては、楽観できない。 Table 3 によると、100,000 writer が Name-Node に対して、1 秒あたり 41,667 回の create-block リクエストを、平均として発行すると予測される。 つまり、Name-Node の処理容量の 70% に相当する、毎秒3,920 回の生成を上回ることになる(参照 Table 4)。

A reasonably expected write-only load produced by 100,000 HDFS clients on a 10,000 node HDFS cluster will exceed the throughput capacity of a single name-node.

10,000のノードの HDFS クラスタにおける、100,000 の HDFS クライアントが生成する write-only の負荷については、単一の Nme-Node のスループット容量を超えると予測すべきだろう。

We have seen that a 10,000-node HDFS cluster with single name-node is expected to handle a workload of 100,000 readers well. However, even 10,000 writers can produce enough workload to saturate the name-node, making it a bottleneck for linear scaling.

私たちが確認してきたことは、単一の Name-Node を持つ 10,000ノードの HDFS クラスタが、100,000 reader のワークロードを適切に処理するだろうというものだ。 しかし、10,000 writer のケースでさえ、単一の Name-Node を充分に飽和させるワークロードを生成するため、リニアなスケールにボトルネックを生じる。

Such a large difference in performance is attributed to get-block-locations (read workload) being a memory-only operation, while creates (write workload) requires journaling, which is bounded by the local hard drive performance.

このような、パフォーマンスにおける大きい相違は、get-block-locations(read workload)が memory-only 操作であるのに対して、create(write workload)がローカルな HDD の性能に拘束される journaling を要求することに起因する。

There are ways to improve the single name-node performance. But any solution intended for single namespace server optimization lacks scalability.

単一の Name-Node におけるパフォーマンスを、改善する方法は存在する。 しかし、単一の名前空間サーバーの最適化を意図する、あらゆるソリューションはスケーラビリティを失う。

Looking into the future — especially taking into account that the ratio of small files tend to grow — the most promising solutions seem to be based on distributing the namespace server itself both for workload balancing and for reducing the single server memory footprint.

前向にいこう。 とりわけ、小さなファイルの比率が、増大していく傾向にあることを考慮に入れよう。 最も有望なソリューションは、ワークロードのバランスを取り、シングル・サーバーのメモリ・フットプリントを低減する、名前空間サーバー自体を分散していくという、方式に基づいて達成されると思われる。

I hope you will benefit from the information provided above. Please refer to the USENIX ;login: article for more details.

ここで提供した情報から、メリットが得られることを希望する。 詳細に関しては、 USENIX ;login: の記事を参照してほしい。



Konstantin V. Shvachko
Hadoop Distributed File System (HDFS) Team, Yahoo!


HDFS のスケーラビリティを考察する _1
HDFS のスケーラビリティを考察する _2
HDFS のスケーラビリティを考察する _3
Hadoop DFS _ Introduction
NoSQL Ecosystem とは? _1

Tagged with: , , , ,

Comments Off on HDFS のスケーラビリティを考察する _3

HDFS のスケーラビリティを考察する _2

Posted in HDFS by Agile Cat on June 22, 2010

Scalability of the Hadoop Distributed File System _2
Yahoo! Developer Network Blog
May 5, 2010



Storage Capacity vs. Namespace Size

With 100 million files, each having an average of 1.5 blocks, we will have 200 million blocks in the file system. If the maximal block size is 128 MB and every block is replicated 3 times, then the total disk space required to store these blocks is about 60 PB.

1億のファイルがそれぞれ、平均で1.5ブロックを持つ場合には、そのファイル・システム内で2億ブロックを持つことになる。 最大のブロック・サイズが 128MBであり、また、すべてのブロックが 3回複製されるなら、それらのブロックをストアするために必要な、全体的なディスク・スペースは約 60 PB になる。

100 million file namespace needs 60 PB of total storage capacity on the cluster

1 億ファイルの名前空間は、クラスタ上に合計で 60 PB のストレージ容量を必要とする。

As a rule of thumb, the correlation between the representation of the metadata in RAM and physical storage space required to store data referenced by this namespace is:

1 億ファイルの名前空間は、クラスタ上に合計で 60 PB のストレージ容量を必要とする。
大まかな指針として、RAM 上でのメタデータの表現と、名前空間により参照されるデータのストアに必要な、物理的なストレージ空間との相互関係は以下のとおりである:

1 GB metadata ≈ 1 PB physical storage

The rule should not be treated the same as, say, the Pythagorean Theorem, because the correlation depends on cluster parameters (the block to file ratio and the block size). But it can be used as a practical estimate for configuring cluster resources.

対象となる相互関係がクラスタ・パラメータ(ファイル・レシオのブロックとブロック・サイズ)に依存するため、たとえば Pythagorean 定理として、このルールを取り扱うべきではない。 ただし、クラスタ・リソースをコンフィグレーションするための、現実的な見積もりとして使用することができる。

Cluster Size and Node Configuration

Next we can estimate the number of data-nodes the cluster should have to accommodate the namespace of a certain size. On Yahoo’s clusters, data-nodes are usually equipped with four disk drives of size 0.75 – 1 TB, and configured to use 2.5 – 3.5 TB of that space per node. The remaining space is allocated for MapReduce transient data, system logs, and the OS.

続いて、Data-Node 数が推定できる。それは、クラスタが受け入れるべき名前空間のサイズとなる。 Yahoo のクラスタでは、一般的に 4台のディスク・ドライブ(0.75TB~1TB x 4)により Data-Node が配備され、また、ノードごとに 2.5TB~3.5TB を用いるようにコンフィグレーションされる。 残りのスペースは、MapReduce の一時データや、システム・ログ、そして OS に割り当てられる。

If we assume that an average data-node capacity is 3 TB, then we will need on the order of 20,000 nodes to store 60 PB of data. To keep it consistent with the target requirement of 10,000 nodes, each data-node should be configured with eight 1TB hard drives.

もし、平均的な Data-Node 容量が 3TB だと想定されるなら、60 PB のデータをストアするために、20,000 ノードが必要になる。 なお、10,000ノードをターゲットとする要件と矛盾しないようにするために、8台の 1TB ハードドライブを用いて、それぞれの Data-Node をコンフィグレーションすべきだ。

To accommodate data referenced by a 100 million file namespace, a HDFS cluster needs 10,000 nodes equipped with 8TB of total hard drive capacity per node

1億ファイルの名前空間により参照されるデータを受け入れるために、HDFS クラスタは、トータルで 8TB のハードドライブをノードごとに配備した、10,000 ノードを必要とする。

Note that these estimates are true under the assumption that the block per file ratio of 1.5 and the block size remain the same. If the ratio or the block size increases, a gigabyte of RAM will support more petabytes of physical storage and vice versa. Sadly, based on practical observations, the block to file ratio tends to decrease during the lifetime of a file system, meaning that the object count (and therefore the memory footprint) of a single namespace server grows faster than the physical data storage. That makes the object-count problem — which becomes file-count problem when the average file to block ratio is close to 1 — the real bottleneck for cluster scalability.

ファイルとブロックの比率が 1.5 であり、また、ブロック・サイズが変化しないという仮定において、これらの見積もりが正確になることに注意すべきだ。もし、この比率やブロック・サイズが増大するなら、1GB のRAM により、さらに多くの物理ストレージを、ペタバイト単位でサポートすることになる。 また、減少するのであれば、その逆も同様となる。 現実的な観察に基づくと、残念なことにファイルとブロックの比率は、ファイル・システムのライフサイクルにおいて減少する傾向にある。つまり、単一の名前空間サーバーにおけるオブジェクト・カウント(それによるメモリ・フットプリント)は、物理的なデータ・ストレージよりも速く成長することになる。 それにより、オブジェクト・カウントの問題が生じる。 そして、ファイルとブロックの平均的な比率が 1に近づくとき、それはファイル・カウントの問題に発展し、クラスタのスケーラビリティにおけるボトルネックとなる。

The Internal Load

Apart from the hierarchical namespace the name-node’s metadata includes a list of registered data-nodes, and a block to data-node mapping, which determines physical block locations.

階層的な名前空間は別として、Name-Node のメタデータには、登録された Data-Node のリストと、Data-Node マッピングのためのブロックが含まれ、それにより物理的なブロック配置が決定される。

A data-node identifies block replicas in its possession to the name-node by sending block reports. The first block report is sent at the startup. It reveals the block locations, which otherwise are not known to the name-node at startup time. Subsequently, block reports are sent periodically every 1 hour by default and serve as a sanity check providing that the name-node has an up-to-date view of block replica distribution on the cluster.

Data-Node はブロック・レポートを送信することで、Name-Node に対する所有権を用いて、ブロック・レプリカを識別する。 最初のブロック・レポートは、開始時に送信される。 それによりブロック配置が明らかにされるが、そうしなければ、開始時に Name-Node を識別することができない。 その後、デフォルトにおいて、ブロック・レポートは 1時間ごとに周期的に送信される。 そして、クラスタ上に配信されるブロック・レプリカについて、Name-Node が更新されたビューを持っている場合には、サニティ・チェックの役割を果たす。

During normal operation, data-nodes periodically send heartbeats to the name-node to indicate that the data-node is alive. The default heartbeat interval is 3 seconds. If the name-node does not receive a heartbeat from a data-node in 10 minutes, it pronounces the data-node dead and schedules its blocks for replication on other nodes.

正常なオペレーションが行われている間は、Data-Node から Name-Node へ周期的にハートビートが送信され、Data-Node が生きていることが確認される。 デフォルトのハートビート間隔は、3秒となっている。 Data-Node からのハートビートを、10分間にわたりName-Node が受信しない場合には、Data-Node が死んでいると判断され、他のノードへ向けたブロックをリプリケーションがスケジュールされる。

The block reports and heartbeats form the internal load of the cluster. If the internal load is too high, the cluster becomes dysfunctional, able to process only a few, if any, external client operations such as ls, read, or write. The internal load depends on the number of data-nodes. Assuming that the cluster is built of 10,000 data-nodes having 8 hard drives with 6 TB of effective storage capacity each, we estimate that the name-node will need to handle

ブロック・レポートとハートビートは、クラスタ内の負荷も構成する。 内部の負荷が大きすぎる場合には、クラスタは機能不全となり、外部クライアントによる Is/read/write などのオペレーションがあるにしても、その処理能力は劣化してしまう。 内部の付加は、Data-Node 数に依存する。 対象となるクラスタが、6TB の有効なストレージ容量を備えたる、8 台のハードドライブを有する 10,000 Data-Node で構成されると想定している。 それにより、Name-Node は、以下の処理を行う必要が出てくる:

● 3 block reports per second, each reporting 60,000 replicas
● 10,000 heartbeats per second

Using the standard HDFS benchmark called NNThroughputBenchmark, we measure the actual name-node performance with respect to the two internal operations. Table 2 summarizes the results. Note that the block report throughput is measured in the number of blocks processed by the name-node per second.

NNThroughputBenchmark と呼ばれる標準的な HDFS ベンチマークを用いて、2つの内部オペレーションについて、Name-Node の現実的なパフォーマンスを測定した。 その結果を、Table 2 に要約する。 ブロック・レポートのスループットが、Name-Node により毎秒処理されるブロック数で、測定されることに注意してほしい。

The implication of these results is:


The internal load for block reports and heartbeat processing on a 10,000 node HDFS cluster with the total storage capacity of 60 PB will consume 30% of the total name-node processing capacity.

60BP のトータル・ストレージ容量を用いて、10,000 ノードの HDFS クラスタを取り扱うブロック・レポートとハートビートの内部負荷は、全体的な Name-Node 処理能力の 30% を消費する。

The internal load is proportional to the number of nodes in the cluster and the average number of blocks on a node. Thus, if a node had only 30,000 blocks — half of the estimated amount — then the name-node will dedicate only 15% of its processing resources to the internal load. Vice versa, if the average number of blocks per node grows, then the internal load will grow proportionally. The latter means that the decrease in block to file ratio (more small files with the same file system size) increases the internal load and therefore negatively affects the performance of the system.

この内部負荷は、クラスタのノード数と、ノードにおける平均的なブロック数に比例する。 したがって、見積もられる総量の半分に相当する 30,000 ブロックをノードが保有するなら、内部負荷に関するリソース処理において、Name-Node は 15% だけを占有するだろう。また、その逆も真であり、ノードごとの平均的なブロック数が増大するなら、内部負荷も相対的に増大する。 後者が示すのは、ブロックとファイルの比率の低下が(同じファイルシステム・サイズを用いて、より多くの小さなファイルに対応)、内部負荷を増大する状況である。 したがって、システムのパフォーマンスに悪影響を与えることになる。

HDFS のスケーラビリティを考察する _1
HDFS のスケーラビリティを考察する _2
HDFS のスケーラビリティを考察する _3
Hadoop DFS _ Introduction
NoSQL Ecosystem とは? _1


Tagged with: , , , ,

Comments Off on HDFS のスケーラビリティを考察する _2

HDFS のスケーラビリティを考察する _1

Posted in Big Data, HDFS by Agile Cat on June 20, 2010

Scalability of the Hadoop Distributed File System _1 

Yahoo! Developer Network Blog
May 5, 2010



In his fictional story "The Library of Babel", Jorge Luis Borges describes a vast storage universe composed of all possible manuscripts uniformly formatted as 410-page books. Most are random meaningless sequences of symbols. But the rest excitingly forms a complete and an indestructible knowledge system, which stores any text written in the past or to be written in the future, thus providing solutions to all problems in the world. Just find the right book.

ホルヘ・ルイス・ボルヘス (Jorge Luis Borges) の作である「バベルの図書館」では、410ページの本として共通のフォーマットを持つ書籍で構成された、巨大なストレージの世界を表現している。そして、その 大部分が、無意味なシンボルの羅列となる。 しかし、残りの部分は完全で破壊されることのない知識システムを形成し、過去に記述され将来に記述されるあらゆるテキストをストアする。 したがって、世界におけるすべての問題に対するソリューションを提供する。 まさに、必要な本を探し出せる。

The same characteristic fascinates us in modern storage growth: The aggregation of information directly leads to proportional growth of new knowledge discovered out of it. A skeptic may doubt that further reward in knowledge mining will not justify the effort in information aggregation. What if by building sophisticated storage systems we are chasing the 19th century’s horse manure problem, when at the dawn of the automobile era the scientific world was preoccupied with the growth of the horse population that threatened to bury the streets of London nine feet deep in manure?

近代的なストレージが成長してきたいま、それと同じ特質が私たちを魅惑する。 つまり、情報のアグリゲーションから発見される、均衡のとれた新しい知識のダイレクトな成長が導かれることになる。 懐疑的な人々は、ナレッジ・マイニングにおける更なる報いは、正当な情報アグリゲーションを破壊すると言うだろう。しかし、洗練されたストレージ・システムを構築することで、19世紀における馬糞の問題を取り除けるなら、どうなるかと考えるべきだろう。 つまり、自動車の時代が始まろうとしているのに、London の街が 9フィートの深さまで馬糞で埋まると脅す馬喰たちに、科学の世界は屈してはならないのだ。

The historical judgment will turn one way or another. In the meantime, we want to know how far we can go with existing systems even if only out of pure curiosity. In my USENIX ;login: article “HDFS Scalability: the Limits to Growth,” I studied scalability and performance limitations imposed on a distributed file system by the single-node namespace server architecture. The study is based on experience with largest deployments of the Hadoop Distributed File System (HDFS) currently in production at Yahoo!.

歴史における審判は、一様なものではなく、揺れ動く。 そうこうしている間に、たとえ純粋な好奇心を失うにしても、既存システムを用いて、どこまで行けるかを知りたがる。 私は USENIX ; login: article “HDFS Scalability: the Limits to Growth” において、シングル・ノードの名前空間サーバー・アーキテクチャにより、何らかの分散ファイル・システムを割り当てられた際の、スケーラビリティとパフォーマンス限界を調査した。 この調査は、Yahoo! で運用中の Hadoop Distributed File System(HDFS)における、最も大規模なディプロイメント・エクスペリエンスに基づいている。

The first part of the study focuses on how the single name-server architecture limits the number of namespace objects (files and blocks) and how this translates to the limitation of the physical storage capacity growth.


The second part explores the limits for linear performance growth of HDFS clusters bound by natural performance restrictions of a single namespace server. As the cluster grows, the linear increase in the demand for processing resources puts a higher workload on the single namespace server. When the workload exceeds a certain threshold, it saturates the server, turning it into a single-node bottleneck for linear scaling of the entire cluster.

2番目のパートでは、単一の名前空間サーバーにおける自然なパフォーマンス制約により、HDFS クラスタのリニアなパフォーマンス向上が妨げられる限界を探究する。 クラスタが成長するにつれて、リソース処理の要求に関するリニアな増加が、単一の名前空間サーバー上のワークロードを押し上げる。 ワークロードが一定の閾値を超えるとき、そのサーバーは飽和することになり、クラスタ全体のリニアなスケーリングに対する、シングル・ノード・ボトルネックへと変様する。

In 2006, the Hadoop group at Yahoo! formulated long-term target requirements for HDFS and outlined a list of projects intended to bring the requirements to life. Table 1 summarizes the targets and compares them with the current achievements:

Yahoo! の Hadoop グループは 2006年に、 HDFS に対する長期的な目標の要件を規定し、それらの要件を活性化する意図を持つ、いくつかのプロジェクトのリストをまとめた。 それらのターゲットを Table 1 に要約し、現時点の到達点と比較する:


The bottom line is that we achieved the target in Petabytes and got close to the target in the number of files. But this is done with a smaller number of nodes and the need to support a workload close to 100,000 clients has not yet materialized. The question now is whether the goals are feasible with the current system architecture.

結論として、私たちは Petabytes オーダーの目標を達成し、ファイル数においても目標に近づいたといえる。 しかし、これらの結果は少数のノードを用いて達成されており、100,000 クライアントに近いワークロードを、サポートしていくという必要性は、まだ実現していない。 そして、私たちのゴールが、現在のシステム・アーキテクチャを用いて実現できるのかという疑問が残っている。

Namespace Limitations

HDFS is based on an architecture where the namespace is decoupled from the data. The namespace forms the file system metadata, which is maintained by a dedicated server called the name-node. The data itself resides on other servers called data-nodes.

HDFS は、名前空間がデータから分離されるアーキテクチャに基づいている。 この名前空間は、Name-Node という専用サーバーにより維持される、ファイル・システムのメタデータを形成する。 そして、データ自身は、Data-Node という他のサーバー上に配置される。

The namespace consists of files and directories. Files are divided into large (128 MB) blocks. To provide data reliability, HDFS uses block replication. Each block by default is replicated to three data-nodes. Once the block is created its replication is maintained by the system automatically. The block copies are called replicas.

この名前空間は、ファイルとディレクトリで構成される。 そして、それらのファイルは、大きなブロック(128MB)に分けられる。 データの信頼性を確保するために、 HDFS はブロック・リプリケーションを使用する。 それぞれのディフォルト・ブロックは、3 つのデータノードにリプリケートされる。 それらのブロックが作成された後に、システムにより自動的に、リプリケーションの管理が行われる。 このブロックされたコピーのことを、レプリカと呼ぶ。

The name-node keeps the entire namespace in RAM. This architecture has a natural limiting factor: the memory size; that is, the number of namespace objects (files and blocks) the single namespace server can handle.

そして、Name-Node により、すべての名前空間が RAM 上に保持される。 当然のこととして、このアーキテクチャは制約の要因を伴う。 つまり、メモリのサイズであり、単一の名前空間サーバーが取り扱う、名前空間オブジェクト(ファイルとブロック)の数が制限されることになる。

Estimates show that the name-node uses less than 200 bytes to store a single metadata object (a file inode or a block). According to statistics on Y! clusters, a file on average consists of 1.5 blocks. Which means that it takes 600 bytes (1 file object + 2 block objects) to store an average file in name-node’s RAM

シングル・メタデータ・オブジェクト(a file inode or a block)をストアするために、200 Bytes 以下を使用する Name-Node を見積もってみよう。 Yahoo! クラスタにおける統計値では、ファイルの平均サイズは 1.5 ブロックに相当する。 つまり、Name-Node の RAM 内に、平均的なサイズのファイルをストアするために、600 Bytes(1 file object + 2 block objects)が必要となる。

To store 100 million files (referencing 200 million blocks), a name-node should have at least 60 GB of RAM.

1億のファイルをストアするためには、Name-Node は最低でも 60GB の RAM を必要とする。


おそらく、3回くらいに分けてのポストになると思います。 ーーー A.C.

HDFS のスケーラビリティを考察する _1
HDFS のスケーラビリティを考察する _2
HDFS のスケーラビリティを考察する _3
Hadoop DFS _ Introduction
NoSQL Ecosystem とは? _1


Tagged with: , , , ,

Comments Off on HDFS のスケーラビリティを考察する _1

NoSQL Ecosystem とは? _1

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

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 wanted to organize an event to discuss open source distributed databases. The name and concept both caught on.

この「NoSQL」という用語は、オープンソース分散データベースについてディスカッションするために、 の 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
Rackspace のクラウド料金体系
ISP とクラウド経済


Comments Off on NoSQL Ecosystem とは? _1

NoSQL Ecosystem とは? _2

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

NoSQL Ecosystem


// November 9th, 2009 // Development


By Jonathan Ellis, Systems Architect


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.)

このコンテキストにおいて、スケーリングについて論じるとき、リプリケーションを用いることで読み取りの調整は簡単に行える。 つまり、マルチ・マシンをまたいでデータを自動的にパーテショニングする、書き込みのスケーリングが論点となる。そのようなシステムを、ここでは「分散データベース」と呼ぶ。たとえば、CassandraHBaseRiakScalarisVoldemort などが、そこには含まれる。 そこには、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) 対象となるアプリケーションのための活きたクラスタに対して、新しいマシンを透過的に加える能力である。

NoSQL Chart_1

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 MongoDBNeo4jRedisTokyo 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 がある。

NoSQL Chart_2

(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
Rackspace のクラウド料金体系
ISP とクラウド経済


Comments Off on NoSQL Ecosystem とは? _2

NoSQL Ecosystem とは? _3

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

NoSQL Ecosystem


// November 9th, 2009 // Development


By Jonathan Ellis, Systems Architect

Persistence Design

By persistence design I mean, “how is data stored internally?”

私の考える、パーシスタンスに関するデザインとは、"どのような方式で、データを内部的にストアするか?" ということである。

NoSQL Chart_3

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 によるオーバーヘッドを回避する。


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 ディスカッション・グループで参照できる。


昨日ですが、 上で、” なぜ エコシステムなんだ? ” というディスカッションが、 さん、そして さんとの間になりました。 著者の意図が掴めないのですが、みなさんは どう思います? ーーー A.C.

NoSQL Ecosystem とは? _1
NoSQL Ecosystem とは? _2
NoSQL Ecosystem とは? _3
Rackspace のクラウド料金体系
ISP とクラウド経済


Comments Off on NoSQL Ecosystem とは? _3

%d bloggers like this: