似ているようで違いがあるもの、世の中には沢山ありますね。
春になると、桜が咲きます。
日本で一般的に見られる桜、ソメイヨシノは江戸時代半ばぐらいに出てきた種で、日本古来からの桜といえば、八重桜という桜です。この２つの桜、桜という名前でこそあれ、花の形は違っていて、花の色も違います。
AWSでのDynamoDBとRDSも同様に、データベースのサービスだけれど異なるサービス名なだけに当然特徴は異なります。
ということで今回は、RDSとDynamoDBの違いを深掘りしてみます。目次はこちら。
1. 特徴を知りましょう
違いについて確認する前に、まずは特徴を掴んでおきましょう。
DynamoDBの特徴
- マネージド型のNoSQLデータベース
- 読み込み書き込みが早い
- 原則API経由で操作
- スループットに応じてスケーリングするサーバーレスなDB
- 利用中に読み込み/書き込み性能(キャパシティユニット)の変更が可能
- AWSのクレデンシャル情報を使いエンドポイントに対してアクセス
DynamoDBの特徴は、NoSQLであるという点です。
データ構造もリレーショナルデータベースのテーブルとは異なり、リレーショナルではなく型もありません。
読み込み書き込みの早い点が特徴ですが、一方でデータの操作がAPI経由となり、SQLとはデータの扱い方が異なっています。
利用中でも、読み込み/書き込みの性能を(キャパシティユニット)変更可能で、プロビジョニングモードと呼ばれるモードを使うことで、自動でキャパシティユニットを調整することも可能です。
※1 Amazon DynamoDB: 仕組み
※2 DynamoDBのスループットキャパシティ
RDSの特徴
- マネージド型のリレーショナルデーターベース
- SQLにより操作
- テーブル結合など複雑なクエリが利用可能
- hostnameでアクセスする
- 利用者のVPCに配置
RDSの特徴は、リレーショナルデータベースであるという点です。
使い慣れた方も多い、MySQLやPostgreSQL、OracleやSQL Serverなども利用できます。
テーブルを結合しての複雑なクエリが利用出来る点は最大の特徴で、どうテーブル設計できるかが、RDSを選択するか、DynamoDBを選択するかの分かれ目とも言えます。
またRDSはVPCに配置し、hostnameでアクセスします。MySQLならmysqlコマンドでホスト名とユーザー名・パスワードで接続する、いつもの接続の仕方ですね。
2. 気を付けたい設計ポイント
特徴が分かったところで、特徴に応じて選ぶだけでなく、実際にシステム設計するにあたって気を付けたいポイントもあります。
どちらを利用するのかを決める際のポイントにもなる部分ですね。
詳しく見ていきましょう。
DynamoDBの気を付けポイント
- 空文字が利用出来ない
- テーブル結合した検索はできない
- 複雑なデータ更新の多いシステムの利用には向かない
- キャパシティユニットを大幅に増加させるとパーティション分割が発生する
- キャパシティユニットを下げた際に、極端にパフォーマンスが落ちる可能性あり
DynamoDBではこの3つの気を付けたいポイントがあります。
リレーショナルデータベースに慣れていると、空文字の利用やテーブル結合が当たり前なので、使いづらいと感じるかも知れません。
この点は、次のようにすることで回避できます。
- DynamoDBを利用するアプリケーションで、特定の文字列があった場合に空文字へ変換処理を入れる
- テーブル設計を見直し、テーブル結合が必要ないテーブル設計にする
また、DynamoDBはデータの更新が難しいデータベースです。検索にも制約があるため、複雑な更新となるデータの利用には向いていません。
複雑なデータ更新が行われる設計のシステムは、システム設計・テーブル設計の見直しや、RDSの利用についても検討を推奨します。
キャパシティユニットという、DynamoDBの性能管理も気を付けたいポイント。
運用中に変更出来るのは大きなポイントである一方、オンデマンドモードとプロビジョニングモードによってキャパシティ管理も異なるため、どちらで運用するかは負荷テストなどを実施して、確認するようにしましょう。構築後でも、オンデマンドモードとプロビジョニングモードは切り替えることができます。
RDSの気を付けポイント
- Lambdaと組み合わせて使いたい場合のシステム構成に注意
- LambdaをVPCに配置するか、RDSをグローバルに配置するか、選択になる
- LambdaのzipファイルにMySQLなどのライブラリを含める必要がある
- 個人情報をインターネットから隠したい場合はRDSになるが、実行時間とのトレードオフ
- スケールアップにはシステム停止が必要 ※Aurora Serverlessを除く
RDSの気を付けたいポイントは、Lambdaと組み合わせる場合に多いです。
Lambdaはデフォルトでは自分の作ったVPCには配置されないため、RDSにアクセスしようとすると、RDSがグローバルになくてはなりません。
LambdaをVPCに置いた場合、Lambdaが利用するENIの生成に掛かる時間の考慮が必要になります。
そしてどちらを選択しても、LambdaにMySQLなど、DB接続のライブラリが必要になります。
Lambdaの初回のアクセスは応答が遅くなるので、時間を許容できるかどうかがポイントに。
またスケールアップにシステム停止も必要です。※Aurora Serverlessを除きます
Aurora Serverlessを使うという選択肢もありますが、MySQL・PostgreSQLにDBエンジンの選択肢が限られる他、負荷が一定の場合はプロビジョンドの利用が推奨なので、この点にも注意しましょう。
3. 使いどころ
使いどころとしては、以下のようなシステムがそれぞれ向いています。
テーブル設計なども勘案しながら、適切なデータベースを選択したいですね。
DynamoDBの使いどころ
- 読み込み/書き込みの多いシステム
- テーブル結合が不要なシステム
RDSの使いどころ
- 更新が頻繁なシステム
- テーブル結合が必要となるテーブル設計のシステム
4. まとめ
- RDSとDynamoDBは似ているようで特徴が異なる
- 気を付けたいポイントがあるので、設計などで回避できるか確認する
- 使いどころも違うので、使いどころにあった利用を
今回はRDSとDynamoDBの違うについて取り上げました。
AWSの中にはRDSとDynamoDBに限らず、似通ったサービスもいくつかありますが、特徴や使いどころが異なっています。
特徴に合った使い方をして、その効果を存分に得られるように、アーキテクチャを設計していきたいですね。