AP型データベースAmazon DynamoDBとApache Cassandraの特徴

なお、Cassandraは、DynamoDBの分散モデルを参考にFacebook社が開発したオープンソースのNoSQLデータベースです。Amazon DynamoDBはその実装が厳密に公開されていないため、同様のアーキテクチャを持つApache Cassandraを合わせて比較することで理解を深めていきたいと思います。

AP型データベースAmazon DynamoDBとApache Cassandraの特徴

前回の復習になりますが、AP型のNoSQLデータベースは一貫性(Consistency)が下がることのトレードオフとして、可用性(Availability)とネットワーク分断耐性(Partition Tolerance)を高めています。具体的には、以下のイメージのように複数のアベイラビリティゾーンにデータベースを配置し、各ノードにデータを分散して配置することで実現しています。

単一障害点がないのが大きな特徴で、どこのノードからでもデータ更新が可能であり、ノードも任意に追加／設定できるスケーラビリティにも優れた分散型構成です。ただし、ノードの故障や通信のエラーにより、複数のノード間で整合性のとれない(一貫性を損なう)ケースが発生します。

その回避策として、読み込み時に最新のデータで古いノードのデータを更新するReadRepair機能や、Quorumをベースに結果整合性をとる方法(雑に言えば、不整合が出た場合に、なるべく多くの一致したデータを判定する多数決に似た手法)が用意されている……というところまでが、前回説明したお話です。

Apache Cassandraは、Amazon DynamoDBのデータベース分散モデルを参考にデザインされているため当然、そのデータ分散配置に関する特徴を継承しています。

まず、両者で共通して押さえておかなれければならないものの1つが、各ノードに配置される「データ」と「キー」の概念です。

Amazon DynamoDB、Apache Cassandraは「Consistent Hashing」と呼ばれるアルゴリズムにより、各ノードと配置されるデータを決定しています。大まかなイメージを掴むために、先の図の「都市テーブル」に市区情報を加えて構成されるかたちに変更してみましょう。都道府県と市／区は1：Nの関係であり、都道府県を区別するキーを「親キー」、市や区を区別するキーを「子キー」とします。DynamoDBとCassandraには、これらのキーに対して、以下のような名称で対応付けられるキーがあります。

※　なお、Amazon DynamoDBでは以前、パーティションキーは「ハッシュキー(Hash Key)」、ソートキーは「レンジキー(Range Key)」という名称で呼ばれていました。また現在、パーティションキーとソートキーを合わせて「プライマリキー(Primary Key)」と呼んでいます。

どちらのデータベースにおいても、以下のルールを押さえておくことが必要です。

1. 親キーで配置されるノードが決定する。
2. ノード内のデータ順序を決定する子キーを任意に設定できる。
3. 子キーを作成しない場合は親キーでデータを一意に特定できるようにする必要がある。
4. 子キーにはインデックスを設定できる。

また、Amazon DynamoDBとApache Cassandraでは分散データ方式として、以下のような違いがあります。

こうした分散DBアーキテクチャを踏まえると、当然、RDBでできていた以下のような当たり前のことができなくなります。

上記の制約はプロダクトによって差がありますが、RDBで実現できる機能を使いたい場合は、RDBを導入すべきであり、NoSQLデータベースは、その特性を生かしたユースケースに対して導入を検討すべきです。

ただし、AP型NoSQLデータベースを導入する場合でも、上記のようなさまざまな機能要件を求められるケースもあるため、アプリケーションの設計時に制約をしっかりと意識し、データベースの機能に委ねるべきか、不足する機能に代替する処理をアプリケーションで実装すべきかを判断できるようにしておきましょう。

次回以降は、Amazon DynamoDBのより詳細な特徴を整理し、実際にDynamoDBを構築していきます。