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