Agile Cat — in the cloud

Amazon DynamoDB の 超弩級 クラウド NoSQL 感覚 by James Hamilton

Posted in .Selected, Amazon, James Hamilton, NoSQL by Agile Cat on January 27, 2012

Amazon DynamoDB: NoSQL in the Cloud
Wednesday, January 18, 2012

_ perspectives

Finally! I’ve been dying to talk about DynamoDB since work began on this scalable, low-latency, high-performance NoSQL service at AWS. This morning, AWS announced availability of DynamoDB: Amazon Web Services Launches Amazon DynamoDB – A New NoSQL Database Service Designed for the Scale of the Internet.

ついに、この日がやってきた!AWS における、スケーラブル/ロー・レイテンシ/ハイ・パフォーマンスな NoSQL サービスに着手したときから、この DynamoDBについて話したいとを強く望んでいた。 今朝のことだが、DynamoDB の提供が開始されたと AWS が発表した: Amazon Web Services Launches Amazon DynamoDB – A New NoSQL Database Service Designed for the Scale of the Internet.

In a past blog entry, One Size Does Not Fit All, I offered a taxonomy of 4 different types of structured storage system, argued that Relational Database Management Systems are not sufficient, and walked through some of the reasons why NoSQL databases have emerged and continue to grow market share quickly. The four database categories I introduced were: 1) features-first, 2) scale-first, 3) simple structure storage, and 4) purpose-optimized stores. RDBMS own the first category.

私は以前のブログ・エントリーである One Size Does Not Fit All で、構造化されたストレージ・システムに関する、4種類のタクソノミーを提供している。そこでは、Relational Database Management Systems が十分ではないことを論じ、また、NoSQL データベースが出現した理由と、素早くマーケット・シェアを拡大し続ける理由について、簡単に説明している。 私が紹介した 4つのデータベース・カテゴリーは: 1) features-first 機能優先、2) scale-first スケール優先、3) simple structure storage シンプルなストレージ構成、4) purpose-optimized stores 目的に最適化されたストア、であった。そして、RDBMS が持つのは、最初のカテゴリのみである。

DynamoDB targets workloads fitting into the Scale-First and Simple Structured storage categories where NoSQL database systems have been so popular over the last few years. Looking at these two categories in more detail.

DynamoDB は、Scale-First と Simple Structured Storage のカテゴリにフィットした、ワークロードをターゲットにするものであるが、これらの領域は、これまでの数年にわたって、NoSQL データベース・システムで人気を集めているところである。これら 2つのカテゴリについて、さらに詳細を追いかけよう。

Scale-First is: Scale-first applications are those that absolutely must scale without bound and being able to do this without restriction is much more important than more features. These applications are exemplified by very high scale web sites such as Facebook, MySpace, Gmail, Yahoo, and Some of these sites actually do make use of relational databases but many do not. The common theme across all of these services is that scale is more important than features and none of them could possibly run on a single RDBMS. As soon as a single RDBMS instance won’t handle the workload, there are two broad possibilities: 1) shard the application data over a large number of RDBMS systems, or 2) use a highly scalable key-value store.

Scale-First:Scale-first アプリケーションは、境界に影響されることなく、また、あらゆる制約から開放された方式で、絶対的にスケーラブルであることが、その他の機能よりも優先する。 これらのアプリケーションは、Facebook/MySpace/Gmail/Yahoo/ といった、きわめてハイ・スケールな Web サイトにより実証される。 これらのサイトにおいて、いくつかのリレーショナル・データベース利用例があるが、大半は別の方式を採用するという現実がある。それら全てのサービスを横断する普遍的なテーマは、スケーラブルであることが機能よりも重要であり、また、それらをシングル RDBMS 上で実現することは、不可能だろうという点に集約される。 シングル RDBMS インスタンスが、対象となるワークロードを処理しきれない場合に、すぐに適応できる 2つの対応策がある: 1) 大量の RDBMS システム上に、アプリケーション・データを Sharding する。あるいは、2) きわめてスケーラブルな Key-Value ストアを使用する。

And, Simple Structured Storage: There are many applications that have a structured storage requirement but they really don’t need the features, cost, or complexity of an RDBMS. Nor are they focused on the scale required by the scale-first structured storage segment. They just need a simple key value store. A file system or BLOB-store is not sufficiently rich in that simple query and index access is needed but nothing even close to the full set of RDBMS features is needed. Simple, cheap, fast, and low operational burden are the most important requirements of this segment of the market.

Simple Structured Storage: 構造化されたストレージ要件を持つ、数多くのアプリケーションが存在するが、そこでは、RDBMS の機能と、コスト、複雑さが必要とされないのも現実である。 また、それらのアプリケーションは、Scale-first の構造化されたストレージ・セグメントが要求する、スケールに対してフォーカスすることもない。 つまり、そこでは、シンプルな Key-Value ストアだけが必要とされる。 必要とされるシンプル・クエリーとインデックス・アクセスにおいて、何らかのファイル・システムや BLOB ストアが、その要件を十分に充たすことはないが、RDBMS のフル機能に似たようなものは、何も必要とされない。 シンプル/安価/高速で、運用上の負担を低減するソリューションが、このマーケット・セグメントにおいて、最も重要な要件である。

_ AmazonMore detail at: One Size Does Not Fit All.

The DynamoDB service is a unified purpose-built hardware platform and software offering. The hardware is based upon a custom server design using Flash Storage spread over a scalable high speed network joining multiple data centers.

DynamoDB は、目的に合せて構築されたハードウェア・プラットフォームと、ソフトウェアが提供するサービスである。 そのハードウェアは、接続されるマルチ・データセンターに対して、高速でスケーラブルなネットワークを供給するために、Flash  Storage 用いたカスタム・サーバー・デザインをベースにしている。

DynamoDB supports a provisioned throughput model. A DynamoDB application programmer decides the number of database requests per second their application should be capable of supporting and DynamoDB automatically spreads the table over an appropriate number of servers. At the same time, it also reserves the required network, server, and flash memory capacity to ensure that request rate can be reliably delivered day and night, week after week, and year after year. There is no need to worry about a neighboring application getting busy or running wild and taking all the needed resources. They are reserved and there whenever needed.

DynamoDB がサポートするのは、プロビジョニングされたスループット・モデルである。 DynamoDB アプリケーションのプログラマーは、自身のアプリケーションがサポートすべき、毎秒ごとのデータベース・リクエスト数を決定する。 そして DynamoDB は、適切な数のサーバー上に、テーブルを自動的に供給していく。 それと同時に、たとえば日/週/年の単位で、リクエスト・レートが確実に供給されることを保証するために、要求されるネットワーク/サーバー/フラッシュ・メモリの容量を確保する。そして、隣接するアプリケーションがビジーになることや、制御不能な状況に陥ること、そして、必要とするリソースを奪っていってしまうようなことを、心配する必要は無い。それらの確保されたリソースは、必要とされるときに、必ず供給される。

The sharding techniques needed to achieve high requests rates are well understood industry-wide but implementing them does take some work. Reliably reserving capacity so it is always there when you need it, takes yet more work. Supporting the ability to allocate more resources, or even less, while online and without disturbing the current request rate takes still more work. DynamoDB makes all this easy. It supports online scaling between very low transaction rates to applications requiring millions of requests per second. No downtime and no disturbance to the currently configured application request rate while resharding. These changes are done online only by changing the DynamoDB provisioned request rate up and down through an API call.

高度なリクエスト・レートを達成する、Sharding のテクニックが必要とされていることは、この業界において広く認識されている。 しかし、それを実装するには、いくつかの作業が欠かせない。 つまり、キャパシティの確保が、必要とされるときに、常に約束されるようにするには、多くの作業が要求される。オンライン時にリクエスト・レートに影響をあたえることなく、 割り当てられているリソースの増減を達成するには、さらに多くの作業が要求される。 DynamoDB は、それら全ての容易に実現する。 具体的には、きわめて低いトランザクション・レートから、何百万回(秒)のレートを必要とするアプリケーションを、停止すること無くスケーリングしていく。 また、Re-Sharding を行う間も、そこ時点でコンフィグレーションされている、アプリケーション・リクエスト・レートを妨害することはなく、もちろん、ダウンタイムを要求することもない。 これらの変更は、プロビジョニングされている DynamoDB のリクエスト・レートを、API コールを介して変更するだけで、オンラインを維持しながら達成される。

In addition to supporting transparent, on-line scaling of provisioned request rates up and down over 6+ orders of magnitude with resource reservation, DynamoDB is also both consistent and multi-datacenter redundant. Eventual consistency is a fine programming model for some applications but it can yield confusing results under some circumstances. For example, if you set a value to 3 and then later set it to 4, then read it back, 3 can be returned. Worse, the value could be set to 4, verified to be 4 by reading it, and yet 3 could be returned later. It’s a tough programming model for some applications and it tends to be overused in an effort to achieve low-latency and high throughput. DynamoDB avoids forcing this by supporting low-latency and high throughout while offering full consistency. It also offers eventual consistency at lower request cost for those applications that run well with that model. Both consistency models are supported.

API による透過的のサポートに加えて、リソースの確保については、プロビジョニングされるリクエスト・レートの、オンラインにおけるスケールを 6段階で増減できる。 つまり DynamoDB は、コンシステンシーとマルチ・データセンターにおける、2つの冗長性に対応する。 インベンチュアル・コンシステンシーは、いくつかのアプリケーションにとっては素晴らしいプログラミング・モデルであるが、別の状況においては、紛らわしい結果をもたらす場合もある。 たとえば、何らかの値を 3に設定し、続いて 4に変更しても、それを読み返すときに 3が返される可能性があるのだ。 さらに悪いことに、4 に設定された値が、4であると確かめられた後に、依然として 3が返される場合もある。 それは、いくつかのアプリケーションにとっては、利用が困難なプログラミング・モデルであり、また、ロー・レイテンシとハイ・スループットを達成するために、過度に使用されるという傾向を持つ。  DynamoDB は、ロー・レイテンシとハイ・スループットをサポートしながら、フル・コンシステンシーを提供することで、こうした問題の発生を回避している。 さらに、このモデルを適切に実行するアプリケーションの、リクエスト・コストを抑制する場合には、インベンチュアル・コンシステンシーも提供される。つまり、2つのコンシステンシー・モデルがサポートされる。

Amazon-DynamoDBIt is not unusual for a NoSQL store to be able to support high transaction rates. What is somewhat unusual is to be able to scale the provisioned rate up and down while on-line. Achieving that while, at the same time, maintaining synchronous, multi-datacenter redundancy is where I start to get excited.

NoSQL が、高度なトランザクション・レートをサポートできたとしても、べつに異常なことではない。 通常と異なる点があるとすれば、オンラインを維持しながら、プロビジョニングされたレートを、上下にスケールできることである。それを達成すると同時に、マルチ・データセンターの同期をとることで、その冗長性を維持できるところが、私がエキサイトするところである。

Clearly nobody wants to run the risk of losing data but NoSQL systems are scale-first by definition. If the only way to high throughput and scale, is to run risk and not commit the data to persistent storage at commit time, that is exactly what is often done. This is where DynamoDB really shines. When data is sent to DynamoDB, it is committed to persistent and reliable storage before the request is acknowledged. Again this is easy to do but doing it with average low single digit millisecond latencies is both harder and requires better hardware. Hard disk drives can’t do it and in-memory systems are not persistent so flash memory is the most cost effective solution.

データを失うというリスクを、望む人がいないのは明らかであるが、NoSQL システムの定義は Scale-First である。 高度なスループットとスケールを達成するための、唯一の方式がリスクを冒すことであり、また、コミット時にデータをパーシスタント・ストレージに入れると約束できないなら、そのような事態が頻繁に生じるということである。 そして、この点が、DynamoDB が本当に輝くところである。 データが DynamoDB に送られるとき、そのリクエストが承認される前に、信頼できるパーシスタント・ストレージに対してコミットが行われる。 繰り返すが、それを実現することは容易である。 ただし、平均で一桁台のミリセカンド・レイテンシを達成することは困難であり、また、より良いハードウェアを必要とする。 ハードディスク・デバイスを用いて、それを達成することは不可能だ。 そして、イン・メモリのシステムはパーシスタントでないため、フラッシュ・メモリが最も費用効果の高いソリューションとなる。

But what if the server to which the data was committed fails, or the storage fails, or the datacenter is destroyed? On most NoSQL systems you would lose your most recent changes. On the better implementations, the data might be saved but could be offline and unavailable. With dynamoDB, if data is committed just as the entire datacenter burns to the ground, the data is safe, and the application can continue to run without negative impact at exactly the same provisioned throughput rate. The loss of an entire datacenter isn’t even inconvenient (unless you work at Amazon :-)) and has no impact on your running application performance.

しかし、そのデータをコミットするサーバーが失敗したら、あるいは、ストレージが失敗したら、データセンターに障害が発生したら、いったい、どうなるのだろう? 大半の NoSQL システムでは、直近の更新が失われてしまうだろう。  それよりも優れた実装が行われていれば、データは保存されるかもしれないが、オフラインとなり、利用できなくなるケースも生じるだろう。 dynamoDB を用いるなら、データをコミットしたときにデータセンターが火災にあっても、そのデータは安全である。 そして、あなたのアプリケーションは、プロビジョニングされたときと、まったく同じスループットレートで、悪影響を受けることなく走り続けるだろう。1つのデータセンターが、まるごと吹っ飛んでも、たいした問題ではない(あなたが Amazon の従業員でない限り :) )。 そして、実行中のアプリケーションに、パフォーマンスの問題が生じることもない。

Combining rock solid synchronous, multi-datacenter redundancy with average latency in the single digits, and throughput scaling to the millions of requests per second is both an excellent engineering challenge and one often not achieved.


More information on DynamoDB:

· Press Release:
· DynamoDB detail Page:
· DynamoDB Developer Guide:
· Blog entries:
· Werner:
· Jeff Barr:
· DynamoDB Frequently Asked Questions:
· DynamoDB Pricing:
· GigaOM:
· eWeek:

· Seattle Times:

Relational systems remain an excellent solution for applications requiring Feature-First structured storage. AWS Relational Database Service supports both the MySQL and Oracle and relational database management systems:

Feature-First の構造化されたストレージを必要とするアプリケーションにとって、リレーショナル・システムは優れたソリューションであり続ける。 そして、AWS Relational Database Service は、MySQL と Oracle 、そして、リレーショナル・データベース・マネージメント・システムをサポートする:

Just as I was blown away when I saw it possible to create the world’s 42nd most powerful super computer with a few API calls to AWS (42: the Answer to the Ultimate Question of Life, the Universe and Everything), it is truly cool to see a couple of API calls to DynamoDB be all that it takes to get a scalable, consistent, low-latency, multi-datacenter redundant, NoSQL service configured, operational and online.

いくつかの API コールを AWS へ送るだけで、世界で 42位のスーパー・コンピュータが構成できるという事実は、私を仰天させた(42: the Answer to the Ultimate Question of Life, the Universe and Everything)。それと同要に、いくつかの DynamoDB API をコールすることで、スケーラブル/コンシステンシー/ロー・レイテンシなマルチ・データセンターにおける冗長性と、コンフィグレーションされた NoSQL サービス、そして、オンラインによるオペレーションの全てが得られるとは、まさに COOL なことである。



_ perspectivesなんというか、息をのむ迫力です。 優れたテクノロジーと AWS のスケールが組み合わされると、このようなものが出来てしまうのですね。 最後の締め括りで、James Hamilton さんが言っているように、DynamoDB であるうがスパコンであろうが、API を叩けば誰でも使えるという、コモディティ感覚が素晴らしいです。 ある意味、「京」などは、その足元にも及びません。 文句なしに スゴイ! 以下の<関連>も、ぜひ ご覧ください。 ーーー __AC Stamp 2



イベンチュアル・コンシステンシーはお好き? — by James Hamilton
Stonebraker と CAP Theorem と Databases – by James Hamilton
Database System エラーと Eventual Consistency と CAP Theorem _1
Database System エラーと Eventual Consistency と CAP Theorem _2
Amazon の James Hamilton が語る、効率の良いデータセンター運用のコツとは?
Facebook メッセージを支えるストレージ・インフラを解説 – James Hamilton

Google が OSS NoSQL として発表した、LevelDB の狙いは Chrome にあるのか?

Posted in Google, HTML5, NoSQL by Agile Cat on August 1, 2011

Google Open-Sources NoSQL Database Called LevelDB
Klint Finley / July 30, 2011 10:30 AM

_ Read Write

_ googleIn May Google open-sourced a BigTable-inspired key-value database library called LevelDB under a BSD license. It was created by Jeff Dean and Sanjay Ghemawat of the BigTable project at Google. It’s available for Unix based systems, Mac OS X, Windows, and Android.

この 5月に Google は、LevelDB という名の、BigTable を彷彿とさせる key-value データベース・ライブラリを、BSD 許可証の下でオープン化した。 それは、Google の BigTable プロジェクトに属する、Jeff Dean と Sanjay Ghemawat により作られたものである。そして、Unix ベースのシステムおよび、Mac OS X、Windows、Android で利用できる。

Although it first appeared in Google Code months ago, a blog post from Google earlier this week made the project more widely known.

それは、数カ月前に Google Code に登場したが、今週(7/30)に Google がブログにポストしたことで、プロジェクトの存在が広く知れわたった。

imageLevelDB is not a database server like other other key-value stores like Redis or Membase. Instead, it would most likely be used as an embedded database for other applications, much the way SQLite or Berkley DB are used. The technical advantage to using LevelDB instead of other key-value stores is its support for ordered data. Also, its BSD license is more liberal than the GPL Sleepycat license of Berkley DB.

LevelDB は、Redis や Membase といった、key-value ストアのデータベース・サーバーではない。それは、他のアプリケーションにエンベッドされるデータベースとして、使用される見込みが高い。つまり、SQLite やBerkley DB の用法に近いものとなる。他の key-value ストアに換えて、LevelDB を利用する際のテクニカルなアドバンテージは、ソートされたデータのサポートとなる。それに加えて、BSD ライセンスは、Berkley DB に適用される Sleepycat ライセンスよりも自由度が高い。

According to the announcement:


For example, LevelDB may be used by a web browser to store a cache of recently accessed web pages, or by an operating system to store the list of installed packages and package dependencies, or by an application to store user preference settings. We designed LevelDB to also be useful as a building block for higher-level storage systems. Upcoming versions of the Chrome browser include an implementation of the IndexedDB HTML5 API that is built on top of LevelDB. Google’s Bigtable manages millions of tablets where the contents of a particular tablet are represented by a precursor to LevelDB.

たとえば LevelDB は、最近にアクセスされた Web ページをキャッシュする Web ブラウザにより、あるいは、インストール済みのパッケージや依存性をリストする OS により、そして、ユーザー・プリファレンスをストアするアプリケーションなどにより利用されるだろう。さらに、私たちは、ハイ・レベルなストレージ・システムのための、有益なビルディング・ブロックとして、LevelDB をデザインしてきた。 これから登場してくる、将来の Chrome ブラウザ・バージョンは、この LevelDB 上に構築され、IndexedDB HTML5 API の実装を取り込むことになる。 Google の Bigtable は、何百万というタブレットを管理するが、その場所において、特定タブレットのコンテンツが前処理されることで、LevelDB へ向けて表示されていく。

LevelDB isn’t limited to just being used as an embedded database, however. Basho is already exploring the possibility of using LevelDB with Riak as an alternative to Bitcask or InnoDB. The company conducted some benchmarks, which you can find in this blog post.

しかし、 LevelDB の用途は、エンベッドされたデータベースだけに限定されるものではない。 すでに Basho は、Bitcask や InnoDB に代わる選択肢として、LevelDB と Riak を組み合わせて利用する、可能性について研究している。 そして、いくつかのベンチマークが行われたが、その結果を、このブログ・ポストで確認することが可能だ。

Google also released its own set of benchmarks here.

さらに Google は、それらのベンチマークで用いたセットを、ココ で公表している。

According to the project site the key features are:

  • Keys and values are arbitrary byte arrays.
  • Data is stored sorted by key.
  • Callers can provide a custom comparison function to override the sort order.
  • The basic operations are Put(key,value), Get(key), Delete(key).
  • Multiple changes can be made in one atomic batch.
  • Users can create a transient snapshot to get a consistent view of data.
  • Forward and backward iteration is supported over the data.
  • Data is automatically compressed using the Snappy compression library.
  • External activity (file system operations etc.) is relayed through a virtual interface so users can customize the operating system interactions.
  • Detailed documentation about how to use the library is included with the source code.

And the limitations are:

  • This is not a SQL database. It does not have a relational data model, it does not support SQL queries, and it has no support for indexes.
  • Only a single process (possibly multi-threaded) can access a particular database at a time.
  • There is no client-server support builtin to the library. An application that needs such support will have to wrap their own server around the library.

See Also


NoSQL も、まずは利用シナリオありきで、考えられるようになってきなのですね。IndexedDB HTML5 API って、どれほどのパーフォーマンスを見せてくれるのでしょう。 :) とても楽しみですね。 ーーー __AC Stamp 2



NoSQL Database で 認識しておくべき 9つのポイント
NoSQL のユースケースを一般論と具体論で整理する
NoSQL の CouchDB が Android に搭載されるという話
Big Data を 美味しくいただくための、クッキング・ブックを作ろう

Big Data を 美味しくいただくための、クッキング・ブックを作ろう

Posted in Big Data, Hadoop, MapReduce, NoSQL by Agile Cat on March 9, 2011

The Big Data Cookbook
Posted in
Main on March 8th, 2011
by Pingdom 

_ pingdom

Big data has become one the new buzzwords on the Internet. It refers to the massive amounts of data that many modern web services deal with. This post will list some of the more useful software available to web developers for working with big data.

Big data は、インターネット上の新しいバズワードになっている。 この用語は、数多くのモダンな Web サービスが取り扱う、大規模なデータのことを指す。 そして、このポストでは、ビッグ・データの分野で働くWeb デベロッパーにとって有益な、いくつかのソフトウェアをリストアップしていく。


You don’t have to operate at the scale of Google or Facebook to enter into big data territory. Web analytics services, monitoring services (like our very own Pingdom), search engines, etc., all process and store massive amounts of data.

ただし、この領域に参加するからといって、Google や Facebook のスケールを考える必要はない。 そこまでいかなくても、Web 分析サービスおよび、モニタリング・サービス(Pingdom など)、サーチ・エンジンなどの全てが、大量データの処理と保存に対応している。

To quote Wikipedia (Wikipedia からの引用):

Big data are datasets that grow so large that they become awkward to work with using on-hand database management tools. […] Though a moving target, current limits are on the order of terabytes, exabytes and zettabytes of data.

Big data ビッグ・データは、成長が著しいデータセットであるため、手製のデータベース・マネージメント・ツールを用いた作業は厄介になってしまう。 [中略]その上限が定まっているわけではないが、現時点におけるデータの限度は、テラバイト/エクサバイト/ゼッタバイトの並びの上にある(つまり、ペタということ?)。

At this scale, many traditional approaches for handling and processing data are either impractical or break down completely.


That’s why the web development community has been turning to alternative ways to handle all this data, developing new software that scales to these extremes. You may have heard about NoSQL databases, but that’s just a small piece of the puzzle.

そこに、Web 開発のコミュニティが、それら全てのデータを取り扱うための、代替案を探し求めてきた理由がある。つまり、それらを大幅にスケールするソフトウェアの開発である。 NoSQL データベースの情報を持っていると思うが、それはパズルにおける小さい小片である。

So what are the various ingredients available for handling big data? We’ve divided them into four categories:

そして、このビッグデータを取り扱うために利用できる、各種の構成要素とは、何なのだろう?私たちは、それを を4つのカテゴリに分けてみた:

  • Storage and file systems
  • Databases
  • Querying and data analysis
  • Streaming and event processing

We figured this could be a good starting point, and we’re hoping that you’ll help us add to the list in this post by making your own suggestions in the comments. In other words, read the list, and help us add more useful ingredients!


ーーーーー とりあえず、訳はココまで ーーーーー

Here we go…

Storage and file systems

When you need to store massive amounts of data, you’ll want a storage solution designed to scale out on multiple servers.

  • HDFS (Hadoop Distributed File System) – Part of the open source Hadoop framework, HDFS is a distributed, scalable file system inspired by the Google File System. It runs on top of the file system of the underlying OSs and is designed to scale to petabytes of storage. The Hadoop project (you’ll see several of the other components further down) has several high-profile contributors, the main one being Yahoo. Hadoop is used by Yahoo, AOL, eBay, Facebook, IBM, Meebo, Twitter and a large number of other companies and services.
  • CloudStore (KFS) – An open source implementation of the Google File System from Kosmix. It can be used together with Hadoop and Hypertable. A well-known CloudStore user and contributor is Quantcast.
  • GlusterFS – A free, scalable, distributed file system developed by Gluster

While classics like MySQL are still widely used, there are other options out there that have been designed with “web scalability” in mind, many of them so-called NoSQL databases (speaking of buzzwords…).

  • HBase – A distributed, fault-tolerant database modeled after Google’s BigTable. It’s part of the Apache Hadoop project, and runs on top of HDFS.
  • Hypertable – An open source database inspired by Google’s BigTable. A notable Hypertable user is Baidu.
  • Cassandra – A distributed key-value database originally developed by Facebook, released as open source, and now run under the Apache umbrella. Cassandra is used by Facebook, Digg, Reddit, Twitter and Rackspace, to name a few.
  • MongoDB – An open source, scalable, high-performance, document-oriented database. It’s used by, among others, Foursquare,, Shutterfly, Etsy and Chartbeat.
  • Membase – An open source, distributed, key-value database optimized for interactive web applications, developed by several team members from the famous Memcached project. Users include Zynga and Heroku. A month ago, the Membase project merged with CouchDB, creating a new project called Couchbase.
Querying and data analysis

All that data is of no use without the ability to access, process and analyze it.

  • Hadoop MapReduce – Open source version of Google’s MapReduce framework for distributed processing of large datasets.
  • Hive – An open source data warehouse infrastructure with tools for querying and analyzing large datasets in Hadoop. Supports an SQL-like query language called Hive QL.
  • Pig – A high-level language used for processing data with Hadoop. Funny aside: the language is sometimes referred to as Pig Latin.
Streaming and event processing

When you have massive amounts of data flowing into your system, you will often want to process and react on this data in real time.

  • S4 – A general-purpose, distributed, scalable platform for processing continuous streams of data. Developed by Yahoo and released as open source in 2010. It’s apparently not quite ready for prime time yet, although Yahoo is using a version of it internally.
  • Esper – An event-processing platform from EsperTech for handling continuous streams of incoming data.
  • StreamInsight – Microsoft’s entry in the EST/CEP field, included with SQL Server.

A small aside when speaking of streaming and event processing, you’ll hear two industry terms repeated over and over again: EST, Event Stream Processing, and CEP, Complex Event Processing. Just in case you were wondering what that actually stood for.

The Google legacy

It’s interesting how influential Google has been in the big data field in spite of having released very little actual software to the public.

Much of the open source big data movement is centered around Apache’s Hadoop project, which essentially has tried to replicate Google’s internal software based on the various whitepapers Google has made available. (More specifically, Hadoop has replicated GFS, BigTable and Mapreduce.)

Here is a list of some of Google’s proprietary software relating to big data:

  • GFS (Google File System) – Google’s scalable, fault-tolerant, distributed file system. Designed from scratch for use with data-intensive applications.
  • BigTable – A distributed, high-performance database system built on top of GFS.
  • Mapreduce – A framework for distributed processing of very large data sets.
  • Pregel – A framework for analyzing large-scale graphs with billions of nodes.
  • Dremel – Meant as a faster complement to Mapreduce, Dremel is a scalable, interactive, ad-hoc query system for large data sets. According to Google, it’s capable of running aggregation queries over trillion-row tables in seconds and scales to thousands of CPUs.

If we may be so bold as to bring out our crystal ball, there will most likely be several open source implementations of Pregel and Dremel available soon. For example, there’s already an OpenDremel project in the works.

Help us add more ingredients!

What excellent big data software did we leave out? Let’s make this post a true resource, so please give us a hand in the comments.


なかなか面白い試みで、さすがは Pingdom です。 それと、Google legacy というカテゴリがユニークですが、さまざまな基盤を提供してくれて有難うと、言いたくなる実績ですね! では コメント欄から、ご意見など、ぜひ ど~ぞ! ーーー __AC Stamp 2


Mollom アーキテクチャは、毎秒 100回のリクエストを発行し、3億 7300万のスパムを退治する
プロジェクト Piccolo は、スピードで Hadoop を凌駕する
Real World NoSQL シリーズ – Netflix における Amazon SimpleDB
Real World NoSQL シリーズ – Openwave における Cassandra
Real World NoSQL シリーズ – 4PB を処理する Trend Micro の HBase
Google の発想 – リクエストとレスポンスを Tree で制御する
TOPSY の Twitter 分析 API は、5 億クエリー/月 を処理する!

Facebook が目指す、リアルタイム分析のインフラとは?

Posted in Facebook, NoSQL by Agile Cat on March 8, 2011

How Facebook Is Powering Real-Time Analytics
Derrick Harris Mar. 4, 2011, 9:21am PT

_ Gigaom

Facebook is working on a real-time analytics dashboard that will let users determine which content on their pages is getting the most attention from visitors. As described in an educational session on Wednesday night in Facebook’s Seattle office, the service, which tracks both impressions and actions  for plugins and newsfeeds, should be valuable to companies seeking to maximize the effectiveness of the marketing efforts on the popular social media site. However, the highlight of the session was the infrastructure underlying the forthcoming service.

Facebook が取り組んでる、リアルタイム分析ダッシュボードとは、ユーザーのページ上のコンテントの中で、何がビジターの注意を引き付けているのを、判断させるためのものである。 Facebook の Seattle オフィスで、水曜日(3/2)の夜に開催されたエデュケーション・セッションで説明されたように、 プラグインとニュースフィードに関する Impression と Action を追跡するサービスは、この人気ソーシャル・メディア・サイトにおける、マーケティング戦略の有効性を最大にしようとする企業にとって、貴重なものになるはずだ。 ただし、このセッションのハイライトは、この新しいサービスの基礎となる、インフラストラクチャに関するものであった。


クリックで動画ページへ ⇒

The session video gives plenty of details, but here are some highlights. The analytics service tracks about 100 different metrics; is built atop HBase, with support from two Facebook-developed tools called pTail and Puma; and it aims for less than 30 seconds of lag time, a goal it has met a majority of the time during testing. It’s interesting that Facebook is becoming such a big user of the Hadoop-based HBase database, but the company line thus far is that the Cassandra NoSQL database it developed a few years ago just can’t hang with HBase when it comes to reliability and performance. HBase also underpins Facebook’s recently launched “social inbox” feature.

このセッション・ビデオでは、たくさんの詳細情報が提供されるが、いくつかのハイライトも含まれている。この、分析サービスは、およそ 100種類の基準を追跡する。そして、Facebook が開発した pTail とPuma という、2つのツールによりサポートされ、また、HBase 上に構築される。さらに、タイム。ラグに関しては 30秒以内という目標をたて、タイム・テストの大半において、そのレベルが達成されているという。 Facebook が、Hadoop ベースの HBase データベースにおける、ビッグ・ユーザーになることは興味深い。しかし、これまでのところ、同社の方針は数年前に開発した Cassandra NoSQL データベースであり、信頼性と性能の話になると、 簡単に HBase へ移行できないとのことである。 HBase に関しては、最近に Facebook が立ち上げた、“social inbox” 機能を下から支えている。


この分析というのは、Facebook Page(以前の Fan Page)に関するもので、現時点では、だいたい 2日~3日遅れで更新されているという感じです。 詳しい内容については、大元さんのブログをご参照ください。 とても丁寧に説明してくださっています。 ーーー __AC Stamp 2


Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか
Facebook、Twitter、Digg などでの Cassandra の状況について
Facebook の Social Inbox は、単なる Email ではない!
Facebook のメッセージング・インフラを、再構築する立役者は HBase だ!
Facebook は 20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理する!

NoSQL Database で 認識しておくべき 9つのポイント

Posted in NoSQL by Agile Cat on March 4, 2011

9 Things to Acknowledge about NoSQL Databases
Wednesday, 2 March 2011


以下のリストは、強者の my NoSQL がエクセレントと紹介する、evident software からの情報とのことです。 なんというか、NoSQL に取り組む際の 【 心得 9ヶ条 】 みたいな感じの、頭を切り替えましょうというサゼッション集です。 先日は、Digg における Cassandra の失敗例について、Jonathan Ellis さんが説明していましたが、ここに書かれている何かが、抜けていたのだろうと思えてきます。 それにしても、この evident はマークですね。 Agile_Cat は、早速、RSS リストに追加です! ーーー __AC Stamp 2


Excellent list:

  1. Understand how ACID compares with BASE (Basically Available, Soft-state, Eventually Consistent)
  2. Understand persistence vs non-persistence, i.e., some NoSQL technologies are entirely in-memory data stores
  3. Recognize there are entirely different data models from traditional normalized tabular formats: Columnar (Cassandra) vs key/value (Memcached) vs document-oriented (CouchDB) vs graph oriented (Neo4j)
  4. Be ready to deal with no standard interface like JDBC/ODBC or standarized query language like SQL; every NoSQL tool has a different interface
  5. Architects: rewire your brain to the fact that web-scale/large-scale NoSQL systems are distributed across dozens to hundreds of servers and networks as opposed to a shared database system
  6. Get used to the possibly uncomfortable realization that you won’t know where data lives (most of the time)
  7. Get used to the fact that data may not always be consistent; ‘eventually consistent’ is one of the key elements of the BASE model
  8. Get used to the fact that data may not always be available
  9. Understand that some solutions are partition-tolerant and some are not

  1. ACID と BASE (Basically Available, Soft-state, Eventually Consistent) の比較方法を理解する。
  2. パーシスタンス vs ノン・パーシスタンスの対比を理解する。(インメモリの NoSQL もある)
  3. これまでの正規化されたタブル・フォーマットとは、完全に異なるデータ・モデルを認識すべきだ。 つまり、Columnar (Cassandra) と、key/value (Memcached) と、Document-Oriented (CouchDB) と、Graph Oriented (Neo4j) などが存在する。
  4. JDBC/ODBC などのノン・スタンダードなインターフェイスと、SQL のようなスタンダードなインターフェイスを取り扱えるように準備すべきだ。つまり、それぞれの NoSQL Tool は、それぞれのインターフェイスを有している。
  5. アーキテクトへ : Web-Scale / Large-Scale の NoSQL システムは、数10 ~ 数100 のサーバーおよびネットワークを横断し、これまでの共有型データベース・システムの対極にあるという事実に、脳内をスイッチすべきだ。
  6. データの存在する場所を特定できないという、居心地の悪い現実に(だいたいそうなる)、慣れてしまうべきだ。
  7. データが常にコンシステントな状態にならないことに、慣れてしまうべきだ。 イベンチュアル・コンシステントは、BASE モデルの主たる要素の 1つである。
  8. ストアされているデータが、常に利用できる状態にならないという事実に、慣れてしまうべきだ。
  9. いくつかのソリューションは、パーティション・トレラントになり、いくつかは、そうならないことを、理解すべきだ。



NoSQL のユースケースを一般論と具体論で整理する
Cassandra の 2010 年を、Digg への反論も含めて振り返る by Jonathan Ellis
Mollom アーキテクチャは、毎秒 100回のリクエストを発行し、3億 7300万のスパムを退治する
Real World NoSQL シリーズ – Netflix における Amazon SimpleDB
Real World NoSQL シリーズ – Openwave における Cassandra
Real World NoSQL シリーズ – 4PB を処理する Trend Micro の HBase

Cassandra の 2010 年を、Digg への反論も含めて振り返る by Jonathan Ellis

Posted in NoSQL by Agile Cat on March 1, 2011

Apache Cassandra: 2010 in review
Tuesday, January 04, 2011
Posted by Jonathan Ellis at
11:53 AM


Riptano の立ち上げで忙しかったのか、すっかりと更新の途絶えてしまった Spyced ですが、1月に久々のポストがあったことを知りました。 もちろん Jonathan Ellis さんからで、お元気そうで何よりという感じです。 Code、Community、Controversy という三部構成になってますが、3つ目の Controversy は、議論とか物議という意味で、Digg での問題について解説しています。 あの件は、とても大きなダメージなったはずですが、少なくとも Cassandra は、そこから回復しているように思えます。 ーーー __AC Stamp 2


My Photo

In 2010, Apache Cassandra increased its momentum as the leading scalable database. Here is a summary of the notable activity in three areas: code, community and controversy. As always, comments are welcome.

2010年において、Apache Cassandra はスケーラブルなデータベースをリードする存在として勢いを増してきた。 ここでは、注目すべきアクティビティについて、3つのエリアである Code/Community/Controversy に整理しながら概説していく。 いつもの通り、コメントは大歓迎だ。


2010 started with the release of Cassandra 0.5, followed by 0.6 and graduation from the ASF incubator a few months later. Seven more stable releases of 0.6 proceeded, adding many features to improve operations in response to feedback from production users.

2010 年は Cassandra 0.5 のリリースから始まったが、それに 0.6 が続き、また、その数カ月後に ASF インキュベータから卒業することになった。 0.6 のリリースでは、安定化のために 7つのポイントが進化し、運用環境のユーザーからのフィードバックに応えるかたちで、数多くの機能が追加され、オペレーションが改善された。

0.7 adds highly anticipated features like column value indexes, live schema updates, more efficient cluster expansion, and more control over replication, but didn’t quite make it into 2010, with rc4 released on new year’s 2011.

0.7 では、 column value indexeslive schema updates/efficient cluster expansion/more control over replication といった期待どおりの機能が加えられたが、2010年には完了せず、2011年に入ってから、rc4 というかたちでリリースされた

We also committed the distributed counters patchset, begun at Digg and enhanced by Twitter for their real-time analytics product. Notable as the most-involved feature discussion to date, distributed counters started with a vector clock approach, but switched to a new design by Kelvin Kakugawa after we realized vector clocks were a dead end for anything but the trivial case of monotonic-increments-by-one.

さらに、私たちは、Digg で始まり、Twitter のリアルタイム分析プロダクトで拡張された、distributed counters patchset にも責任を持つことになった。現時点において、もっとも時間を費やして議論されたものとして、vector clock approach を用いて開始される distributed counters に注目すべきだが、vector clock が自身で単調にインクリメントすることを除いて、すでに手詰まりとなっていることに気づいた後、Kelvin Kakugawa新たにデザインすることになった。

One of the biggest trends was increasing activity around Cassandra as well as in the core database itself. 2010 saw Hadoop map/reduce integration, as well as Pig support and apatch for Hive.

Cassandra に関連するアクティビティを増やすだけではなく、そのコア・データベース自身のアクティビティも増やしていくことが、最も大きな流れとなった。 2010 年に行われた Hadoop Map/Rerduce とのインテグレーションと同様に、Pig のサポートと、Hive へのパッチが推進された。

We also saw Lucandra, which implements a Cassandra back end for Lucene and is used in several high volume production sites, grow up into Solandra, embedding Solr and Cassandra in the same JVM for even more performance.

さらに、Lucene のバックエンドとして Cassandra を実装する、Lucandra にも注目した。それは、Solandra で成長する、いくつかのハイ・ボリューム実運用サイトで用いられ、さらなるパフォーマンスのために、 Solr と Cassandra を同一の JVM にエンベッドするものである。



Cassandra hit its stride in 2010, starting with graduation from the ASF incubator in April. 2010 saw 1025 tickets resolved, nearly twice as many compared to 2009 (565).

2010年 4月に、Cassandra は ASF インキュベーションから卒業し、その歩みを始めた。 また、2010 年には 1025 枚のチケットが解決されたが、それは、2009年(565)の 約 2倍近に匹敵するものだ。

Like many Apache projects, Cassandra has a relatively small set of committers, but a much larger group of contributors. In 2010 Cassandra passed over 100 people who have contributed at least one patch. Release manager Eric Evans put together a great way to visual this with a Code Swarm video of Cassandra development.

数多くの Apache プロジェクトと同様に、Cassandra のグループは、少数のコミッターと多数のコントリビューターにより構成されている。 2010年に Cassandra は、少なくとも 1つのパッチをコントリビュートした、100名以上の人々の手を通過した。 リリース・マネージャーである Eric Evans は、Cassandra 開発に関する Code Swarm ビデオを用いて、そのプロセスをビジュアライズするという、素晴らしい方式を作り上げた。

I started Riptano with Matt Pfeil in April to provide professional products and services around Cassandra. In October, we announced funding from Lightspeed and Sequoia. From May to December, we conducted eleven Cassandra training events in eight months, and twice that many private classes on-site with customers.

私に関しては、Cassandra に関連するプロフェッショナルなプロダクトとサービスを提供するために、Matt Pfeil と一緒になって、4月に Riptano を立ち上げた。 10月には、Lightspeed と Sequoia からのファンドについて発表した。 5月から 12月までの 8ヶ月間において、11回の Cassandra のトレーニング・イベントを開催し、また、顧客のオンサイトでは、その 2倍のプライベート・クラスを開催した。

Riptano is now up to 25 employees, with offices in the San Francisco bay area, Austin, and New York, and engineers working remotely in San Antonio, France, and Belarus.

いまでは、Riptano は、San Francisco Bay Area と、 Austin、New York にオフィスを構え、25人の従業員を有している。そして、エンジニアたちは、San Antonio と、France、Belarus においてリモートで作業している。

In August, Riptano and Rackspace organized a very successful inaugural Cassandra Summit, with about 200 attendees (videos available), followed by almost a full track at ApacheCon in November. Cassandra was also represented at many other conferences onmultiple subjects, for several languages, and continents.

8月には、Riptano と Rackspace は共同で Cassandra Summit(ビデオ)を開催し、200名の参加者を集めるという大成功をおさめた。それに続いて、11月の ApacheCon では、Summit のほぼフル・トラックを再演した。 さらに Cassandra は、いくつかの国々に置いて、数多くのテーマを提供するカンファレンスを開催した。


Cassandra got a lot of negative publicity when Kevin Rose blamed Cassandra for Digg v4′s teething problems. However, there was no deluge of bug reports coming out of Digg’s Cassandra team, and Digg engineers Arin Sarkissian and Chris Goffinet (now working on Cassandra for Twitter) got on Quora to refute the idea that Cassandra was at fault:

Digg v4 の初期問題について Kevin Rose が Cassandra の責を追求したときには、多くのネガティブ効果が生じてしまった。 しかし、Digg の Cassandra チームから、大量のバグ・レポートが送られることはなかった。そして、Digg のエンジニアである Arin Sarkissian と Chris Goffinet(Cassandra for Twitter チーム)が Quora 上にで、Cassandra が間違っていたという考え方に対して反論している

The whole "Cassandra to blame" thing is 100% a result of folks clinging on to the NoSQL vs SQL thing. It’s a red herring.

その「 Cassandra への批判 」は、「 NoSQL 対 SQL 」 に執着する人々の視点で、100% が埋め尽くされている。 つまり、目を逸らすためのオトリにされたわけだ。

The new version of Digg has a whole new architecture with a bunch of technologies involved. Problem is, over the last few months or so the only technological change we mentioned (blogged about etc) was Cassandra. That made it pretty easy for folks to cling on to it as the "problem".

この Digg の新しいバージョンは、いくつかのテクノロジーを組み合わせた、まったく新しいアーキテクチャを持っている。 問題なのは、この数カ月にわたって、私たちが(ブログなどで)言及した唯一の技術的な変更点が、Cassandra であったことだ。そのことが、「問題」として指摘しやすい状況を作ってしまった。

Meanwhile, Digg competitor Reddit has continued migrating to Cassandra, crediting it with enabling their 3x traffic growth in 2010.

その一方で、Digg 競争相手である Reddit は、Cassandra への移行を継続しており、2010年に 3倍のトラフィックに成長したサービスで、Cassandra が機能していることを認めている。

More importantly, 2010 saw dozens of new Cassandra deployments, including a new contender for the largest-cluster crown when Digital Reasoning announced a 400-node cluster for the US government.

それより重要なことは、2010年に、いくつかの新規 Cassandra ディプロイメントが実現したことだ。そこには、Digital Reasoning が米国政府用の 400ノード・クラスタを発表したとき、その最大クラスタの新しい候補として、選ばれたことも含まれる。

We look forward to another great year in 2011!


先日に、『 Cassandra の Riptano は、DataStax に買収されてしまったの? 』というタイトルでポストしましたが、今回 ご紹介する Spyced のポストの直後に、DataStax に社名変更されたということなのでしょうね。ーーー __AC Stamp 2


Cassandra はアメリカ政府に食い込み、Amazon EC2 でも利用できる
Cassandra Summit 2010 でのスライドとビデオが公開
Real World NoSQL シリーズ – Openwave における Cassandra
NoSQL のユースケースを一般論と具体論で整理する
Windows Azure チームは、どのような興味を Cassandra に持っているのか?

Mollom アーキテクチャは、毎秒 100回のリクエストを発行し、3億 7300万のスパムを退治する

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

Mollom Architecture – Killing Over 373 Million Spams At 100 Requests Per Second
transparentTUESDAY, FEBRUARY 8, 2011 AT 12:18PM 


Mollom is one of those cool SaaS companies every developer dreams of creating when they wrack their brains looking for a viable software-as-a-service startup. Mollom profitably runs a useful service—spam filtering—with a small group of geographically distributed developers. Mollom helps protect nearly 40,000 websites from spam, including one of mine, which is where I first learned about Mollom. In a desperate attempt to stop spam on a Drupal site, where every other form of CAPTCHA had failed miserably, I installed Mollom in about 10 minutes and it immediately started working. That’s the out of the box experience I was looking for.

成長していく SaaS スタートアップについて熟考するとき、すべてのデベロッパーが夢見るようなクールな企業が Mollomある。 Mollom は、有用なスパム・フィルタリング を、地理的に分配されたデベロッパーによる小規模なグループと共に、有益性のあるサービスとして実現している。 Mollom から最初に学んだことは、約 40,000 の Web サイトをスパムから守り、その中に私のサイトも含まれていることであった。私は Drupal サイトでスパムを退治しようと、他の CAPTCHA フォームを用いたが、その全てが惨敗した。 しかし、Mollom 10分でインストールすると、直ちに機能し始めた。 私が探していたのは、この、直ちに機能するエクスペリエンスだった。


From the time Mollom opened it’s digital inspection system they’ve rejected over 373 million spams and in the process they’ve learned that a stunning 90% of all messages are spam. This spam torrent is handled by only two geographically distributed machines that handle 100 requests/ second, each running a Java application server and Cassandra. So few resources are necessary because they’ve created a very efficient machine learning system. Isn’t that cool? So, how do they do it?

Mollom のデジタル走査システムをオープンしたときから、3 億 7300 万以上のスパムが除去されたが、そのプロセスにおいて、全メッセージの 90% がスパムであるという、衝撃的な事実が学習された。 このスパムの奔流は、地理的に分散され、秒間で 100 リクエストを処理する、たった 2台マシンにより処理される。 そして、それらのマシンでは、Java アプリケーション・サーバーと、Cassandra が運用されている。 彼らは、その程度のリソースしか要求しない、きわめて効率的な機械学習システムを開発している。 とてもクールでしょう? そして、その方式を探ってみたくないか?

To find out I interviewed Benjamin Schrauwen, cofounder of Mollom, and Johan Vos, Glassfish and Java enterprise expert. Proving software knows no national boundaries, Mollom HQ is located in Belgium  (other good things from Belgium: Hercule Poirot, chocolate, waffles).

そのために、Mollom の創業者である Benjamin Schrauwen と、 Glassfish および Java Enterprise のエキスパートである Johan Vos に、インタビューを試みた。 Mollom HQ は Belgiumエルキュール・ポアロチョコレートワッフルが有名)に所在し、ソフトウェアには国境が存在しないことを証明している。


  • Serving 40,000 active websites, many of which are very large customers like Sony Music, Warner Brothers, Fox News, and The Economist. A lot of big brands, with big websites, and a lot of comments.
  • Find 1/2 million spam messages each day.
  • Handle 100 API calls/second.
  • A spam check is low latency, taking between 30-50msecs. The slowest connection would be 500msec. The 95th percentile of latency is 250msecs. It’s really optimized for speed. 
  • Spam classification efficiency is at 99.95%. This means that only 5 in 10,000 spam messages were not caught by Mollom.
  • Netlog, which is a social networking site in Europe, has their own Mollom setup in their own datacenter. Netlog handles about 4 million messages a day on custom classifiers that are trained on their data.
  • 40,000 のアクティブな Webサイトに対して、サービスを提供する。そこには、Sony Music や、Warner Brothers、Fox News、The Economist といったビッグ・ブランドがいる。それぞれが、大規模な Web サイトであり、膨大なコメント抱える。
  • 毎日、500,000 のスパム・メッセージが発見される。
  • 秒間で、100 回の API コールを処理する。
  • スパム・チェックは、30-50 msec という、きわめて低いレイテンシーで処理される。 最も遅いコネクションで、500 msec となる。レイテンシーの 95 パーセンタイルは、250 msec となる。 つまり、スピードに対して最適化される。
  • スパムの分類効率は、99.95% である。 つまり、Mollom にり検知できないスパムは、5/10,000 となる。
  • ヨーロッパのソーシャル・ネットワークである Netlog は、自身のデータセンター内で、自身で設定した Mollom を用いる。そして、自身のデータに合わせたカスタムな  classifiers を用いて、1日あたり 400 万メッセージを処理する。


  • Two production servers run in two different datacenters for failover. 
    • One server is on the East coast and one is on the West coast. 
    • Each server is an Intel Xeon Quad core, 2.8GHz, 16GB RAM, 4 disks of 300 GB, RAID 10.
  • SoftLayer – the machines are hosted by SoftLayer.
  • Cassandra – a NoSQL database selected for it’s write performance and ability to operate across multiple datacenters. 
  • Glassfish – open source application server for the Java EE platform. They picked Glassfish for it’s enterprise ready features like replication and failover.
  • Hudson – provides for continuous testing and deployment of the backend across all their servers.
  • Java – From the start Mollom was written in Java.
  • Munin – used to measure and plot metrics concerning server health.
  • MySQL – JPA (The Java Persistence API) is used for regular data sets and Cassandra is used for large data sets.
  • Pingdom – used for uptime monitoring.
  • Zendesk – used for support.
  • Drupal – used for the main website with a custom E-commerce module.
  • Unfuddle  – Subversion hosting used for source code control by their distributed development team.
  • 2 台の運用サーバーが、フェイルオーバーのために、2つのデータセンターで稼働する。 
    • 1 台のサーバーが東海岸で、もう1台が西海岸に配置される。
    • それぞれのサーバーのスペックは、Intel Xeon Quad/2.8GHz/16GB RAM/4 disks of 300 GB/RAID 10 である。
  • SoftLayer – それらのサーバーをホストするデータセンター。
  • Cassandra – 書込みの性能と、マルチ・データセンターのために選択された NoSQL。
  • Glassfish – Java EE プラットフォーム用の OSS アプリケーション・サーバー。りプリケーションやフェイルオーバーといった、エンタープライズ用の機能が、その選択の理由。
  • Hudson – すべてのサーバーを横断するかたちで、継続的なテストとデプロイメントを実現。
  • Java – 当初から、Mollom は Java で記述されている。
  • Munin – サーバーに関する、measure and plot metrics に使用。
  • MySQL – 一般的なデータセットのために JPA (The Java Persistence API) を使用し、また、大規模データセットには Cassandra を使用。
  • Pingdom – アップ・タイムのモニタリングのために使用。
  • Zendesk – サポートのために利用。
  • Drupal – メインの Web サイトと、カスタムな E-commerce モジュールとして利用。
  • Unfuddle  – 地理的に分散された開発チームにより、ソースコードを管理するために用いられる、サブバージョン・ホスティング。

What Is Mollom?

Mollom is a web service for filtering out various types of spam from user generated content: comments, forum posts, blog posts, polls, contact forms, registration forms, and password request forms. Spam determination is not only based on the posted content, but also on the past activity and reputation of the poster. Mollom’s machine learning algorithms act as your 24×7 digital moderator, so you don’t have to.

Mollom は、ユーザーが生成する各種のコンテンツから、スパムを除外するための Web サービスである。 それらのコンテンツには、コメントおよび、フォーラム・ポスト、ブログ・ポスト、ポール、コンタクト・フォーム、レジストレーション・フォーム、パスワード・リクエスト・フォームなどがある。 スパムの認定は、ポストされたコンテントだけではなく、ポストした人物の過去のアクティビティや頻度などに基づく。 Mollom の機械学習アルゴリズムは、デジタル仲介者の役割を 24×7 で務め、その処理からユーザーを解放する。


なんというか、Mollom ってすごくカッコ良いですね。 また、ITの ビジネスが急速に様変わりするという予測が、すでに現実のものとなっている状況が分かります。 Cassandra も上手く使われているみたいで、ともても面白い話ですね。ーーー __AC Stamp 2


Google Megastore – 1日で 30億 Write/200億 Read のトランザクションを実現
Facebook は 20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理する!
Web デベロッパーが知っておくべき、15種類の オープンソース・プロジェクト

Real World NoSQL シリーズ – Netflix における Amazon SimpleDB

Posted in Amazon, Big Data, Entertainment, Netflix, NoSQL by Agile Cat on February 17, 2011

Real World NoSQL: Amazon SimpleDB at Netflix
By Guy Harrison Feb. 4, 2011, 11:45am PST

_ Gigaom

Edit Note: This is the fourth 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,Cassandra and Hbase.


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 ディプロイメントについて注目していく。


Netflix provides rent-by-mail and streaming movies in the United States. The shift from mail-order to streaming video had fairly significant implications for Netflix’s application infrastructure. Netflix realized that it would need multiple geographically dispersed data centers and far more processing capacity. Rather than build these new data centers, Netflix decided to migrate its applications to Amazon’s AWS cloud. This allowed the company to concentrate its intellectual efforts on building customer value rather than nationwide data centers.

Netflix は、US における映画マーケットにおいて、メールによる貸し出しとストリーミングを介して、それらのコンテンツを提供している。 そのメール・オーダーから、ストリーミング・ビデオへのシフトは、Netflix のアプリケーション。インフラストラクチャに対して、きわめて大きな影響をおよぼした。 そのためには、マルチ・ロケーションに分散されたデータセンターと、さらなるプロセシング・キャパシティが必要になると、Netflix は理解した。 そして Netflix は、そのための新しいデータセンターを構築するよりも、Amazon AWS クラウドへアプリケーションを移行する方針を定めた。それにより同社は、全国的規模でのマルチ・データセンターの構築ではなく、顧客にとっての価値を構築するという、より知的な作業に集中することを可能にした。

As a part of this bold move, Netflix migrated core parts of its database from Oracle to Amazon’s SimpleDB data store. This migration is one of the biggest migrations to the cloud yet undertaken, with the Netflix system serving the needs of more than 16 million subscribers and hosting over 100,000 DVD titles.

この思い切った手段の一部として、Netflix はデータベースのコア部分を、Oracle から Amazon SimpleDB データ・ストアへと移行させた。 それは、Netflix のシステムにおける、1600万人以上のサブスクライバーにサービスを提供し、100,000以上の DVD タイトルをホストするものである。 つまり、すでに着手された、クラウドにおける最大級の移行である。

SimpleDB is a key-value store that runs within the Amazon Web Services (AWS) cloud, and promises reliable and transparently scalable storage together with a flexible schema that supports either immediate or eventual consistency. SimpleDB is a virtually zero-administration service: there is no database administration involved in scaling the system – storage and computer power is assigned dynamically and automatically by Amazon as the database grows.

SimpleDB は、Amazon Web Services(AWS)クラウド上で稼働する Key-Value ストアであり、イミディエイトあるいはイベンチュアルのコンシステンシーをサポートする柔軟なスキーマを組み合わせた、信頼性と透過性を持つスケーラブルなストレージを保証する。 SimpleDB は、アドミニストレーションが実質的に不要なサービスである。 つまり、システムのスケーリングに関与する、データベース・アドミニストレーションが存在しない。そして、対象となるデータベースが成長するにつれて、ストレージつコンピューティングのパワーは動的かつ自動的に、 Amazon により割り当てられる。

Netflix needed to make significant compromises in exchange for the scalability provided by Amazon AWS and SimpleDB. Complex SQL operations such as joins between tables or aggregate “group by” operations which would normally be executed within the database were moved to the application layer. In some cases this required that the data model be de-normalized; data that would be stored in multiple tables in Oracle was flattened into a single SimpleDB structure so that joins could be avoided.

Amazon AWS と SimpleDB が提供するスケーラビリティと引き換えに、Netflix は大幅な妥協を強いられた。 通常はデータベース内で実行されるテーブル間の join や、“group by” によるアグリゲーションといった、複雑な SQL オペレーションがアプリケーション・レイヤに移動した。 いくつかのケースでは、これらのデータ・モデルを de-normalize する必要があった。つまり、Oracle ではマルチ・テーブルにストアされるデータを、シングル SimpleDB 構造内にフラットに展開し、join を回避する必要があった。

Relational database transactions were depreciated in favour of SimpleDB’s optimistic concurrency mechanism, which allows modifications to proceed only if an item is unchanged since it was last accessed. For instance, an attempt to increment a counter (number of rentals for a video for instance) would be rejected if the counter was simultaneously modified by another transaction. Even so application developers needed to be aware that certain operations (reading a value immediately after modifying it, for instance) might incorrect or at least unexpected results.

リレーショナル・データベース・トランザクションは、SimpleDB の楽観的コンカレント・メカニズムを導入するために軽視され、最後にアクセスされたときから、アイテムが変化していない場合に限り、処理を進めるように修正された。 たとえば、カウンターが別のトランザクションにより同時に修正された場合は、カウンターをインクリメント(レンタルされたビデオの本数など)させる試みは拒絶されるであろう。 それにしても、アプリケーション・デベロッパーは、特定のオペレーション(たとえば 修正直後の値の読み出し)が不正確なケースを知る必要がある。また、少なくとも、想定外の結果がもたらされるのであれば、それも知らなければならない。

Netflix doesn’t use SimpleDB for all storage; Oracle, MySQL and the Amazon S3 service all form significant parts of the Netflix architecture. Nevertheless, with more than 16 million customers, Netflix has made a significant commitment to a non-relational alternative and one which, it says, allows them to better meet customer and shareholder needs. Netflix has been generous in sharing their experiences in articles such as this one.

Netflix では、すべてのストレージに対して、SimpleDB を用いるわけではない。つまり、Oracle/MySQL/Amazon S3 の全てのサービスにより、Netflix アーキテクチャの重要なパートが構成される。それにもかかわらず、1600万人以上の顧客を前提として、 Netflix はノン・リレーショナルという選択肢をコミットした。 その点において、顧客と関係者の要件を充たすものと評価できる。このような記事において、そのエクスペリエンスを共有することに関して、Netflix は寛大である。

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





まぁ、日本でいえば TAUTAYA とか DeNA みたいな会社なんでしょうね、Netflix は。また、SimpleDB は S3 ほど有名ではないと思いますが、マルチ・データセンターによる冗長性を確保しているのですね。 Agile_Cat も、この Google に関する記事を見て初めて知りましたが、大したものです。その分、S3 に対してパフォーマンスで遅れをとりますが、トレードオフとして、致し方ないところなんでしょうね。 ーーー __AC Stamp 2


Real World NoSQL シリーズ – Openwave における Cassandra
Real World NoSQL シリーズ – 4PB を処理する Trend Micro の HBase

%d bloggers like this: