Amazon シンプルDB

Amazon SimpleDBは、Amazon.comがErlang ^[1]で作成した分散データベースです。Amazon Elastic Compute Cloud (EC2)およびAmazon S3と連携したWebサービスとして使用され、 Amazon Web Servicesの一部です。2007年12月13日に発表されました。^[2]

EC2やS3と同様に、AmazonはSimpleDBのストレージ、転送、インターネット経由のスループットに対して料金を請求します。2008年12月1日、Amazonは1GBのデータと25マシン時間の無料利用枠^[3]という新しい料金体系を導入しました。他のAmazon Web Servicesへの転送は無料です。^[2]

SimpleDB は、他のデータベース管理システムと比較して、一貫性の弱い形式である結果的一貫性を提供します。これは、推論が難しく、SimpleDB を使用する正しいプログラムの作成が困難になるため、制限と見なされることがよくあります。この制限は、基本的な設計のトレードオフの結果です。一貫性を優先することで、システムは他の 2 つの非常に望ましい特性を実現できます。

1. 可用性 - システムのコンポーネントに障害が発生する可能性がありますが、サービスは正常に動作し続けます。
2. パーティション耐性 - システム内のコンポーネントは、コンピュータ ネットワークによって相互に接続されています。コンポーネントがネットワークを使用して相互に接続できない場合 (ネットワーク パーティションと呼ばれる状態) でも、システムの動作は継続されます。

コンポーネントの障害は避けられないものと考えられているため、信頼性の高いWeb サービスを提供するには、これらの両方の特性が必要であると考えられていました。CAP定理では、システムがこれらの特性と一貫性を同時に示すことは不可能であると述べられているため、設計者はより弱い一貫性で妥協する必要がありました。

公開された制限事項: ^[4]

条件付き put と条件付き delete は、2010 年 2 月に追加された新しい操作です。これらは、SimpleDB に同時にアクセスするときに発生する問題に対処します。SimpleDB を使用してカウンター (つまり、増分できる数値) を保存する簡単なプログラムを考えてみましょう。プログラムは次の 3 つのことを行う必要があります。

1. SimpleDB からカウンターの現在の値を取得します。
2. 値に 1 を加算します。
3. 新しい値を SimpleDB 内の古い値と同じ場所に保存します。

他のプログラムが SimpleDB にアクセスしていないときにこのプログラムを実行すると、プログラムは正常に動作します。ただし、ソフトウェア アプリケーション(特にWeb アプリケーション) が同じデータに同時にアクセスすることが必要な場合もあります。同じデータに同時にアクセスすると、競合状態が発生し、検出できないデータ損失が発生します。

前の例の続きで、同じプログラムを実行する 2 つのプロセス A と B について考えてみましょう。SimpleDB が、ステップ 1 で説明したように、A と B の両方からのデータ要求を処理するとします。A と B は同じ値を参照します。カウンターの現在の値が 0 であるとします。ステップ 2 と 3 により、A は 1 を格納しようとします。B も同じことをしようとします。したがって、予想される最終カウンター値は 2 ですが、最終カウンター値は 1 になります。これは、システムが A による増分操作と B による増分操作の 2 回を試行したためです。

この問題は、条件付き put を使用することで解決できます。ステップ 3 を次のように変更するとします。無条件に新しい値を保存する代わりに、プログラムは、現在保持している値がステップ 1 で取得された値と同じ場合にのみ、新しい値を保存するように SimpleDB に要求します。こうすると、カウンターの値が実際に増加していることを確認できます。これにより、複雑さが増します。現在の値が予想どおりでなかったために SimpleDB が新しい値を保存できなかった場合、条件付き put 操作によって保存された値が実際に変更されるまで、プログラムはステップ 1 ～ 3 を繰り返す必要があります。

一貫性のある読み取りは、条件付き put および条件付き delete と同時にリリースされた新機能です。名前が示すように、一貫性のある読み取りは、SimpleDB の最終的な一貫性モデルによって発生する問題に対処します (制限事項のセクションを参照)。次の操作シーケンスを検討してください。

1. プログラム A は SimpleDB にデータを保存します。
2. 直後に、A は保存したばかりのデータを要求します。

SimpleDB の最終的な一貫性の保証では、ステップ 2 で取得されたデータがステップ 1 で行われた更新を反映しているとは言えません。最終的な一貫性は、ステップ 2 がステップ 1 の更新の完全なセットを反映しているか、またはそれらの更新のいずれも反映していないかのみを保証します。一貫性のある読み取りを使用すると、ステップ 2 で取得されたデータがステップ 1 の変更を反映していることを確認できます。

一貫性のある読み取り操作を使用しない場合に不整合な結果が発生する可能性があるのは、SimpleDB がデータを複数の場所 (可用性のため) に保存し、SimpleDB がステップ 2 でデータ要求を受信したときに、ステップ 1 の新しいデータがすべての場所に書き込まれていない可能性があるためです。その場合、ステップ 2 のデータ要求は、新しいデータが書き込まれていない場所の 1 つで処理される可能性があります。

Amazon では、正確性のために必要でない限り、一貫性のある読み取りの使用は推奨していません。この推奨の理由は、一貫性のある読み取り操作が処理される速度が通常の読み取りよりも低いためです。

SimpleDB がDynamoDBに置き換えられるという話もあります(もはや「反復」は行われていませんが、^[6] Amazon はそれを削除する予定はありません)。DynamoDB がその後継になると思われます。^{[7] [8]}

• ノーSQL

• Amazon SimpleDB 公式ホームページ