Amazon DynamoDB: NoSQL in the Cloud
http://wp.me/pwo1E-3R0
Wednesday, January 18, 2012
http://perspectives.mvdirona.com/2012/01/18/AmazonDynamoDBNoSQLInTheCloud.aspx
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 Amazon.com. 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／Amazon.com といった、きわめてハイ･スケールな 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 のフル機能に似たようなものは、何も必要とされない。 シンプル／安価／高速で、運用上の負担を低減するソリューションが、このマーケット･セグメントにおいて、最も重要な要件である。
More 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つのコンシステンシー･モデルがサポートされる。
It 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: http://phx.corporate-ir.net/phoenix.zhtml?c=176060&p=irol-newsArticle&ID=1649209&highlight=
· DynamoDB detail Page: http://aws.amazon.com/dynamodb/
· DynamoDB Developer Guide: http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/
· Blog entries:
· Werner: http://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html
· Jeff Barr: http://aws.typepad.com/aws/2012/01/amazon-dynamodb-internet-scale-data-storage-the-nosql-way.html
· DynamoDB Frequently Asked Questions: http://aws.amazon.com/dynamodb/faqs/
· DynamoDB Pricing: http://aws.amazon.com/dynamodb/pricing/
· GigaOM: http://gigaom.com/cloud/amazons-dynamodb-shows-hardware-as-mean-to-an-end/
· eWeek: http://www.eweek.com/c/a/Database/Amazon-Web-Services-Launches-DynamoDB-
a-New-NoSQL-Database-Service-874019/
· Seattle Times: http://seattletimes.nwsource.com/html/technologybrierdudleysblog/
2017268136_amazon_unveils_dynamodb_databa.html
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: http://aws.amazon.com/rds/.
Feature-First の構造化されたストレージを必要とするアプリケーションにとって、リレーショナル･システムは優れたソリューションであり続ける。 そして、AWS Relational Database Service は、MySQL と Oracle 、そして、リレーショナル･データベース･マネージメント･システムをサポートする：http://aws.amazon.com/rds/.
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 なことである。
–jrh
ーーーーー
なんというか、息をのむ迫力です。 優れたテクノロジーと AWS のスケールが組み合わされると、このようなものが出来てしまうのですね。 最後の締め括りで、James Hamilton さんが言っているように、DynamoDB であるうがスパコンであろうが、API を叩けば誰でも使えるという、コモディティ感覚が素晴らしいです。 ある意味、「京」などは、その足元にも及びません。 文句なしに スゴイ！ 以下の＜関連＞も、ぜひ ご覧ください。 ーーー 
ーーーーー
＜関連＞
イベンチュアル･コンシステンシーはお好き？ — 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
