KVS系NoSQLのまとめ（Hibari、Dynamo、Voldemort、Riak編）：知らないなんて言えないNoSQLまとめ（1）（3/4 ページ）

P2P型のキー・バリューストア

P2P型の代表Amazon Dynamo

　Dynamoは他の多くのP2P型NoSQLデータベースのアーキテクチャに影響を与えているので、その特徴をあらためて簡単にまとめておきます。

結果整合性を採用　DynamoはAmazonのビジネス面からの要求を考慮して設計されました。最も重要な要求は信頼性の高さでした。「ほんのわずかな停止さえも、売上の減少につながるという財務面と、顧客の信頼感に影響を与えるからだ」と説明されています。

　その一方で、同社のサービスの多くは、プライマリ・キー経由で呼び出されます。例えば、ベストセラーリスト、ショッピングカートリスト、顧客の嗜好、セッション管理、売上ランクや製品カタログなどといったサービスがそうです。そのため、通常のRDBの機能は不要であり、RDBの機能を使うとかえって非効率性につながり、拡張性や可用性に制約があったとしています。

　このようなニーズを満たすため、Dynamoは「常に書き込みができること」、つまり書き込み動作の高い可用性が求められました。そのトレードオフとして、読み込みの際にシステム内に複数のバージョンが存在する「弱い整合性」でよいとされました。このように、一時的な内部におけるデータの整合性の欠落を許容しながら、正しい結果を返す仕組みを「結果整合性」と呼びます。

バージョン管理にベクタークロック*5を採用　複数バージョンの発生を許容する以上、バージョン管理の仕組みが必要になります。その点でDynamoは、仮にバージョン間に差異が生じた際には、「最新のものが勝つ」というルールか、またはベクタークロックとタイムスタンプにより解決するロジックをクライアント側に実装することで、「バージョンの差異を仲裁する」という考え方で設計されました。

コンシステント・ハッシング*6とゴシッププロトコル*7　Dynamoは拡張性を得るために、コンシステント・ハッシングのアルゴリズムを使っています。これにより、データのサイズやリクエストの件数が増えたときは、ノードを追加するだけで自動的にシステム全体の容量を増加できます。また、ゴシッププロトコルを実装することで、サーバ同士が相互の状態を把握しています。

永続化のためにストレージエンジンをプラグイン　Dynamoは、ディスクにデータを保存するためのストレージエンジン*8を自らは持っていません。このため、BerkeleyDBというNoSQLデータベースや、MySQLなどのDBMS（データベース管理システム）を併用する必要があります。

改良版がAWSにて利用可能に　Dynamoはプロプライエタリなソフトウェアですので、Amazon社外で入手することはできません。しかし2012年1月、Amazon Web Services（AWS）において、Dynamoによく似た特徴を持つ「Amazon DynamoDB」*9のホスティングサービスが開始されました。

　DynamoDBには、Dynamoを使いやすくするための改良が施されています。まず、読み出し時に整合性を調整できるようになりました。また、アトミックなカウンターも使用できます。データモデルはキー・バリューではなく、テーブルとプライマリ・キーによる行形式を採用しています。

　ホスティングサービスですので、利用者はノード数やキーの分散について意識する必要はありません。テーブル作成時に、読み書きの性能をリクエスト件数／秒で指定すると、格納したデータ量に合わせて自動的にノード数が調整されます。また、データを他のデータセンターへ複製することはできませんが、同一データセンター内の複数のゾーンにまたがって複製することは可能です。AWSの他のサービスと同様にアーキテクチャの詳細は非公開ですので、例えばアトミックなカウンターをどのようにして実現しているかは明らかにされていません。