AWSの2大データベースであるRDSとDynamoDB、シンプルに初心者向けに何が違うのか、違いが簡単にわかるような説明を考えてみます。
はじめに
初めてAWSのアーキテクチャーを考えるときに、最近ではサーバーレスな設計がごろごろ落ちているため、初めてシステム設計をする場合でも、NoSQLデータベースである、DynamoDBを使ったシステム構成が描けてしまいます。私が駆け出しのころは、Oracleまっさかりで、RDBを使ったシステム構成しか描けなかったものです。あらためて今回CAP定理という言葉をつかって初心者向けに比較してみたいと思います。
CAP定理 と ACID と BASE を知っておこう
分散コンピューティングの考え方として、CAP定理、ACID、BASEを整理してみます。データベースを比較するときにかならず取り上げられる特徴になります。なかなか理解できませんが絵のように頭に焼き付けておきましょう。
CAP定理
具体的な利用例でまとめられているのですが、3つの機能のうち1つを犠牲にしなければならないという定理です。2000年に生まれた概念です。
- 一貫性 (Consistency)
- 全てのノードで同時に同じデータが見える。
- 可用性 (Availability)
- 単一障害など一部のノードで障害が起きても処理の継続性が失われない。
- 分断耐性 (Partition-tolerance)
- 任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。
ACID
トランザクションシステムの持つべき性質としてまとめられた概念です。1970年後半に生まれた概念です。ACIDについては「銀行の送金」を例にした説明がわかりやすいです。
- 原子性 (Atomicity)
- トランザクションに含まれるタスクが全て実行されるか、あるいは全く実行されないことを保証する性質をいう。
- 一貫性 (Consistency)
- トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保証する性質を指す。
- 独立性 (Isolation)
- トランザクション中に行われる操作の過程が他の操作から隠蔽されることを指す。
- 永続性 (Durability)
- トランザクション操作の完了通知をユーザが受けた時点でその操作は永続的となり結果が失われないことを指す。
BASE
可用性や性能を重視した特性を持つ分散システムの特性です。いつ生まれた概念かは不明です。
- 基本的に利用可能 (Basically Available)
- 基本的にいつでも利用できる。
- 厳密ではない状態遷移 (Soft state)
- 常に整合性を保っている必要はない。
- 結果整合性 (Eventual consistency)
- 結果的には整合性が保証される。
RDB vs NoSQL (RDS vs DynamoDB)
CAP定理、ACID、BASE、ほか、いろいろな情報を盛り込んで、RDBとNoSQL、RDSとDynamoDBを整理してみます。
CAP定理における整理
共通のデータを扱うネットワークで繋がったシステムが3つの望ましい性質のうち、2つしか満たせない、1つの特性は犠牲にしなければならない、というCAP定理に、RDBとNoSQLを当てはめてみます。
- AP: 利用可能性(A)が高く、パーティション耐性(P)があるが、一貫性(C)を犠牲にする。NoSQLはここ。
- CP: 一貫性(C)があり、パーティション耐性(P)があるが、可能性(A)を犠牲にする。
- CA: 利用可能性(A)が高く、一貫性(C)があるが、分断耐性(P)を犠牲にする。RDBはここ。
ACID、BASEも含めた整理
最後に、全部含めてまとめると以下のような表になります。スッキリまとまりました。ACIDはCAに、BASEはAPに対応します。
RDB | NoSQL | |
---|---|---|
CAP定理 | CA | AP(+C) |
BASEとACID | ACID | BASE |
使い所 | 整合性の必要なデータ保存、トランザクション処理、難しいクエリ処理 | 簡単でたくさんある保存処理、キーバリューシステム(KVS)、ドキュメントDB |
例 | 決済、他システム連携 | ゲームの課金情報保存、カート保存 |
AWSの2大データベース | RDS | DynamoDB |
余談
余談ですが「12年後のCAP定理: "法則"はどのように変わったか」の中では、銀行のATMについて触れら得れていました。非常に興味深かったのですが、銀行のATMは、一貫性(C)が求められる用に見えて、なんと、実は可用性(A)が求められるそうです。理由は利用者が多いほど利益性が高められるからだそうです。
まとめ
ということで、データベースの大事なワードを盛り込みつつ、AWSの2大データベースを整理してみました。みなさんそれでは迷わずNoSQLやRDBを使ったシステム設計やアーキテクティングを楽しみましょう。
参考
おっさんがACIDとかBASEとかまとめておく。
https://qiita.com/suziq99999/items/2e7037042b31a77b19c8
「RDBMS」と「NoSQL」の比較
https://masawan-guitar.hatenablog.com/entry/2016/08/14/163447
CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった
https://www.publickey1.jp/blog/13/capcap32.html
12年後のCAP定理: "法則"はどのように変わったか
https://www.infoq.com/jp/articles/cap-twelve-years-later-how-the-rules-have-changed/
DynamoDB vs MongoDB: 6 Critical Differences
https://www.xplenty.com/jp/blog/dynamodb-vs-mongodb-differences-ja/#CAP
AmazonのDynamoの論文を読んでみた(1/3)
https://imai-factory.hatenablog.com/entry/2013/11/03/215247
AWS Black Belt Techシリーズ Amazon DynamoDB
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-amazon-dynamodb
以上