【第15回】NoSQL(2)-基礎-AP型データベースAmazon DynamoDBとApache Cassandraの特徴¶
クラウドの普及に伴い、ビッグデータやキーバリュー型データの格納など、ますます活用の機会が広がりつつあるNoSQLデータベース。 第3回は代表的なNoSQLプロダクトであるAmazon DynamoDBやApache Cassandra、Amazon ElastiCacheへアクセスするSpringアプリケーションを開発する方法について、わかりやすく解説します。
本連載では、以下の様なステップで進めています。
- NoSQLデータベースの特徴とデータ特性
- CAP定理を元にしたデータベースの分類とデータ特性
- AP型データベースAmazon DynamoDBとApache Cassandraの特徴
- Amazon DynamoDBへアクセスするSpringアプリケーション
- Amazon DynamoDBの概要及び構築と認証情報の作成
- Spring Data DynamoDBを用いたアプリケーション(1)
- Spring Data DynamoDBを用いたアプリケーション(2)
- Apache CassandraへアクセスするSpringアプリケーション
- Apache Cassandraの概要及びローカル環境構築
- Spring Data Cassandraを用いたアプリケーション(1)
- Spring Data Cassandraを用いたアプリケーション(2)
- Amazon ElastiCacheへアクセスするSpringアプリケーション
- AmazonElasiCacheの概要及びローカル環境でのRedisServer構築
- Spring SessionとSpring Data Redisを用いたアプリケーション(1)
- Spring SessionとSpring Data Redisを用いたアプリケーション(2)
- Amazon ElastiCacheの設定
- セッション共有するECSアプリケーションの構築(1)
- セッション共有するECSアプリケーションの構築(2)
前回 CAP定理を基づくデータベースの分類 では、リレーショナルデータベース(以降RDB)やNoSQLデータベースをCAP定理を元に分類し、その特性に応じて適したユースケースやデータ特性を整理しました。 今回はその分類のうち、可用性(Availability)とネットワーク分断耐性(Partition Tolerance)を重視した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のデータベース分散モデルを参考にデザインされています。当然そのデータ分散配置に関する特徴を継承していますが、 まず、両者で共通して押さえておかなれければならないものの１つとして、各ノードに配置されるデータとキーの考え方についてです。 Amazon DynamoDB、Apache CassandraはConsistent Hashingと呼ばれるアルゴリズムにより、各ノードと配置されるデータを決定していますが、大まかなイメージを掴むために、上記の図の「都市テーブル」に市区情報を加えて構成される形に変更してみましょう。 都道府県と市・区は1：Nの関係になりますが、都道府県を区別するキーを親キー、市や区を区別するキーを子キーとします。DynamoDBとCassandraには、これらのキーに対して、以下の様な名称で対応づけられるキーがあります。
| データベース | 親キー | 子キー |
| Amazon DynamoDB | パーティションキー(Partition Key) | ソートキー(Sort Key) |
| Apache Cassandra | パーティションカラム(Partition Column) | クラスタカラム(Cluster Column) |
注釈
Amazon DynamoDBではパーティションキーは以前の名称としてはハッシュキー(Hash Key)、ソートキーはレンジキー(Range Key)という名称で使われていました。また、現在はパーティションキーとソートキーを合わせてプライマリキー(Primary Key)と呼んでいます。
どちらのデータベースにおいても、以下の様なルールを押さえておく必要があります。
- 親キーで配置されるノードが決定する。
- ノード内のデータ順序を決定する子キーを任意に設定できる。
- 親子関係を有しないデータは親キーでデータを一意に特定できるようにしておく必要がある。
- 子キーにはインデックスを設定できる
また、Amazon DynamoDBとApache Cassandraでは分散データ方式として、以下の様な違いがあります。
| 特性 | Amazon DynamoDB | Apache Cassandra |
| 配置するノード数上限 | AWSマネージド構築 | 上限なしで任意に設定 |
| レプリケーションファクタ (ノードに配置するデータのレプリケーション数) |
同一リージョンで３つのレプリケーション (DynamoDBはリージョンごとのサービス) |
テーブルごとに任意設定が可能。 |
| 結果整合性のオプション | 【読込】結果整合性か強い読込整合性かを選択 [結果整合性] 2/3以上の読込で結果一致した場合正常応答 [強い読込整合性] 全てのReadRepairが完了し、結果を応答 【書込】2/3以上の書込が成功した場合正常応答 |
ユーザ側で設定可能な読込・書込一貫性 ※読み込むレプリカ数と書き込むレプリカ数を指定できる。指定に達しない場合エラー |
こうした分散DBアーキテクチャを踏まえると、当然RDBでできていた以下の様な当たり前のことができなくなります。
| 制約 | 理由 |
| テーブル間結合ができない | データがテーブルごとに分散して配置されているので、テーブル同士を結合して、データを射影するといった操作はできない |
| 外部キーがない | プロダクトの性質上、キーはプライマリーキー(親キー)とセカンダリキー(子キー)に限定される |
| 条件指定でプライマリキー以外使用できない | データが分散して配置されているので、プライマリキー以外で検索をかけることができない ※対処として、インデックスを作成する、もしくは性能上問題出る可能性はあるが、セカンダリキーは指定できる。 |
| 副問合せができない | データが分載して配置されているので、検索結果のデータを条件とすることはできない |
| GROUP BY等集約関数が存在しない | データが分散して配置されているので、集約に必要なデータが検索時に足りない |
| OR、NOTの演算子はなくANDのみ | プロダクトの性質上、サポートしていない |
上記の制約はプロダクトによって差がありますが、RDBで実現できる機能を使いたい場合は、RDBを導入すべきであり、 NoSQLデータベースは、その特性を生かしたユースケースに対し導入を検討すべきです。ただし、AP型NoSQLデータベースを導入する場合でも、上記の様な色々な機能要件を求められるケースもあるため、 アプリケーションの設計時に上記のような制約をしっかり意識しておき、データベースの機能に委ねるべきか、不足する機能に代替する処理をアプリケーションで実装すべきかを判断できる様にしておきましょう。
次回以降は、Amazon DynamoDBのより詳細な特徴を整理し、実際にDynamoDBを構築していきます。
