Subscribed unsubscribe Subscribe Subscribe

RDS(RDBMS)とDynamoDB(NoSQL)の使い分けについて

日本ではRDBMSが多用されている件についてですが、よくあるアンチパターンが以下です。

DynamoDB(NoSQL)が最適の場合にRDS(RDBMS)を使っている

何も考えずにRDS(RDBMS)を使用
※モバイル, ウェブ, ゲーム, アドテク, IoTでもRDSを使用
↓
サービスがスケール
↓
アーキテクチャ上の課題が発生する。
※パフォーマンスのボトルネック
※スケーラビリティ
※メンテナンス困難な壮大なSQL
※チューニング工数の増大
※障害が多発
※DBを単一障害点になる
※DBインスタンスが死亡
※スケールアップによる費用増大

DBインスタンスを分けていない

複数アプリケーションのテーブルが同じDBインスタンスに同居しているため、
コネクションプール枯渇の問題、タイムアウトリスクの向上、パフォーマンスの問題が発生する

lambdaからRDSの使用を試みている

リクエストが増える
↓
コネクションが増える
↓
レイテンシの増大

RDBMSの厳密なスキーマ定義の利点を使えていない

テーブルのデータにビジネスルールを適用できておらず、現実の世界でおかしいデータがDBに存在することになる

きちんとAWSの資料に目を通している人が少ないのが上記事象が発生する原因かと思います。

AWSの資料を見て、どういう場合に何を使うのかを見てみます。

まず、それぞれの特徴を見ます。

特徴

項目 RDBMS NoSQL
データモデル テーブル、列、index、テーブル間の関係などはスキーマによって厳密に定義 値、列セット、半構造化 JSON等柔軟。データ取得にはパーティションキー
ACIDプロパティ ACIDをサポートする。アーキテクチャ上の課題が生じやすい。 完全には保証しないが、代わりにRDBMSアーキテクチャ上の課題が生じた場合に、パフォーマンスのボトルネック、スケーラビリティ、複雑な運用、管理コストとサポートコストの上昇といった問題を解消
パフォーマンス クエリ、インデックス、テーブル構造の最適化が必要 チューニング不要
拡張性 スケールアップ(AWS使用料が爆増する) スケールアウト(AWS使用料は変わらない)
API SQL(ORM使用する際はオブジェクトベース) オブジェクトベースの API

ACID

トランザクションが完全に実行されるか一切実行されないか
トランザクションが実行されたら、データが必ずデータベーススキーマに従う
同時発生したトランザクションが相互に独立して実行される
異常発生前の最後の状態まで復旧できる

※ACID(不可分性、一貫性、独立性、永続性)

NoSQLの種類

列指向

データ行ではなく、データ列の読み書きに最適化
必要な総ディスク I/O と、ディスクからロードする必要のあるデータ量が大幅に減少
分析クエリに向いている

Redshift, EMR

ドキュメント指向

JSON等で保存
データを柔軟に整理、保存でき、他の機能を使用する際に必要なストレージを減らせる

パフォーマンス、スケーラビリティを求めるものに向いている
モバイル、ウェブ、ゲーム、アドテク、IOTやその他多くのアプリケーションに向いている

グラフ指向

頂点と辺と呼ばれる有向リンクが格納
SQLでも、NoSQLでも
Amazon DynamoDB and Titan

https://aws.amazon.com/jp/blogs/big-data/building-a-graph-database-on-aws-using-amazon-dynamodb-and-titan/

メモリ内キー値ストア

読み取りの負荷が大きいアプリケーションワークロード
(SNS、ゲーム、メディアの共有、Q&A ポータル
や計算量の多いワークロード(レコメンデーションエンジン))に向いている

キャッシュ, セッション, pub/sub, leaderboards(redis)

Amazon ElastiCache

RDSのユースケース

NoSQLのユースケース以外のもの
パフォーマンスを無視しても、データの整合性を求めるもの
銀行の口座等
※RDBMSのスキーマ定義をビジネス・ルールと完全に一致させることができる場合

データの整合性について

RDBMSではアプリケーションでもバリデーションとDB側でのバリデーションが2重に発生します。
スキーマの定義が完璧でないとRDBMSを使用している利点はなくなります。

余分なオブジェクトについて

RDBMSでORMを使用する場合はオブジェクトを別途作成するため、オーバーヘッドが大きいです
また、最終的にはハッシュとなり、viewに渡されるので、NoSQLが代替になる可能性が高いです

allocated memory by gem
-----------------------------------
    685900  activemodel-5.0.1
    580514  activerecord-5.0.1
     71540  activesupport-5.0.1
     12288  mysql2-0.4.5
      8832  2.3.3/lib
      8192  ruby-memory/app
      3633  arel-7.1.4
      2432  concurrent-ruby-1.0.4

参考

http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/SQLtoNoSQL.html

https://aws.amazon.com/jp/nosql/?nc1=h_ls

http://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Introduction.html

https://aws.amazon.com/jp/relational-database/

https://aws.amazon.com/jp/nosql/columnar/

https://aws.amazon.com/jp/nosql/document/

https://aws.amazon.com/jp/nosql/graph/

https://aws.amazon.com/jp/nosql/key-value/