DynamoDB

このレッスンを終えると、Amazon DynamoDB がどんな要件で選ばれるのかを、RDS と比べながら説明できるようになります。

まず、自分でサーバーを建てるなら

MySQL を自分で運用していて、アクセスが桁違いに増えた場面を思い出してください。読み取りはリードレプリカで逃がせますが、書き込みが増えると手が止まります。書き込みを分けるにはテーブルを複数の機械に切り分ける必要があり、切り分けたら JOIN が使えなくなり、切り直すには止める必要が出てきます。これがリレーショナルデータベースを大きくするときに必ずぶつかる壁です。

DynamoDB は、この壁を最初から回避する設計になっています。表と表をつないで検索する能力を最初から諦める代わりに、データ量とアクセスが増えても速度がほぼ変わらないという性質を手に入れています。

DynamoDB は何者か

DynamoDB は AWS のフルマネージドな NoSQL データベースです。キーと値の組でデータを持ちます。特徴は次のとおりです。

サーバーレス。インスタンスのサイズを選ぶ操作すらありません。テーブルを作ればすぐ使えます
データは自動的に複数のアベイラビリティゾーンに複製されます。可用性のために利用者が何かを組む必要はありません
キーによる読み書きが、データ量に関わらず一桁ミリ秒で返るように設計されています
容量は自動で伸縮します。あらかじめディスクサイズを決める必要がありません
スキーマが固定ではありません。項目ごとに持つ属性が違っていても格納できます

RDS と並べる

	RDS (リレーショナル)	DynamoDB (NoSQL)
データの形	行と列の表。スキーマを先に決める	キーと値。項目ごとに属性が違ってよい
検索	SQL で複雑な結合や集計ができる	キーを指定した取得が中心
拡張	インスタンスを大きくする方向が基本	自動で水平に広がる
得意	会計・在庫・受注のような整合性が要る業務データ	セッション情報、ゲームのスコア、IoT のイベント、ユーザー設定
苦手	極端な書き込み量	表をまたぐ複雑な集計

選び分けの基準は1つで、取り出し方が決まっているかです。「ユーザー ID を渡したらそのユーザーのカート情報が欲しい」のように、キーで一発で引ける取り出し方しかしないなら DynamoDB が向きます。逆に「先月の商品カテゴリ別の売上を店舗と結合して集計する」のように、その場で自由に問い合わせたいなら RDS です。

押さえておく機能

CLF の範囲で名前を知っておくとよいものが3つあります。

DynamoDB Accelerator (DAX) — DynamoDB 専用のインメモリキャッシュ。読み取りをマイクロ秒台まで速める
グローバルテーブル — 複数リージョンに同じテーブルを持ち、どこからでも読み書きできるようにする。世界中に利用者がいるアプリケーション向け
TTL — 項目に有効期限を持たせ、期限が来たら自動で消す。セッション情報の掃除に使う

試験ではこう出る

DynamoDB は、次のような言い換えで登場します。

「キーバリュー型」「NoSQL」「スキーマが柔軟」 → DynamoDB
「一桁ミリ秒の応答」「規模が大きくなっても性能が落ちない」 → DynamoDB
「サーバーの管理が不要なデータベース」「サーバーレス」 → DynamoDB。RDS はインスタンスを選ぶので、この言い方は当たりません
「ユーザーのセッション情報を保存したい」「ゲームのプレイヤー状態」「IoT デバイスからのイベント」 → DynamoDB
「複数リージョンで読み書きできるテーブルが要る」 → グローバルテーブル
「複雑な結合や集計を SQL で行う」「トランザクションを伴う会計処理」 → RDS や Aurora。ここで DynamoDB を選ぶと誤りです

引っ掛かりやすいのは「高性能だから DynamoDB」という短絡です。問題文がリレーショナルなデータモデルやSQL による自由な問い合わせを要求していたら、いくら性能の話が書いてあっても答えは RDS 側になります。逆に、既存の MySQL をそのまま移したいという文で DynamoDB を選ぶのも誤りです。互換性がないので、その場合は RDS か Aurora です。

まとめ

DynamoDB はフルマネージドでサーバーレスな NoSQL のキーバリューデータベース
複数 AZ への複製と自動の伸縮が最初から組み込まれている
取り出し方がキーで決まっているなら DynamoDB、自由な結合や集計が要るなら RDS
DAX で読み取りを速くでき、グローバルテーブルで複数リージョンに広げられる
「性能が高いから」ではなく「データの形と取り出し方」で選ぶ