DynamoDB VS ElasticSearch！🤔データアクセス思考なDBMS使い分けの思考方法を解説します！😎

こんにちは！

最近のAWSサーバーレス開発プロジェクトでは、DynamoDB・ElasticSearch の組み合わせがデファクトスタンダートになってきています。うまく設計できれば、RDBMS よりも遥かにハイパフォーマンスで可用性の高い DBMS を構築が可能です。

しかし現場から時折「 DynamoDB設計は理解できたけど、ElasticSearch との使い分けに悩む 」といった声が挙がってきます。実際、ElasticSearch の導入は実装・費用面でコスト高になりやすい傾向にあるので、DyanamoDB の設計後に行うプロジェクトが多いですよね。

本記事では、DynamoDB の設計・実装経験のある方向けに、ElasticSearch との使い分け思考方法を解説します。

想定する読者

• DynamoDB の設計・実装経験のあるヒト
• スタートアップ・新規事業で DynamoDB を利用しているヒト
• 既存のプロジェクトで DynamoDB のリードキャパシティユニットが気になるヒト
• ElasticSearch の導入を検討しているヒト

はじめに

本記事を読む前に

以下の単語を見てピンとこない方は、先に私たちの DynamoDB に関する記事を読むことをオススメします。

• パーティションキー
• ソートキー
• GSI
• オーバーローディング
• コンポージットキー

RDB設計者のための DynamoDB の解説！開発経験者が語る DynamoDB 設計入門🤔

DynamoDBで、RDBMSのリレーション設計に対応！GSIで効率良いクエリー設計を解説します😎

ElasticSearchに関して詳細に解説しません

本記事では ElasticSearch を詳細に解説しません。（インデックス設計手法など）DynamoDB との使い分け・ユースケースをメインに解説いたします。

DynamoDB VS ElasticSearch

DBMSとしての役割

それぞれ、DBMS としての役割がそもそも異なります。

• DynamoDB は Key-Value 型データベース
• ElasticSearch は検索用途に主に使用されるサービス

DynamoDBとの付き合い方

DynamoDB は、KVS です。どのようなデータアクセスがされるかを設計段階で検討する必要があり、設計後の柔軟な検索要件変更には弱いです。（ ComposieKey、GSI-Overloading、Sparse-Index などのテクニックを使用することで多少は回避できます ）

例を挙げると、管理画面やBIツールなどの検索要件が水平展開するようなプロダクトで DynamoDB のみで検索要件を満たすのは非推奨と言えます。この点、MySQL のようなデータを正規化することで後から自由にクエリーできる思想とは異なりますね。

一方で DynamoDB を使用するメリットは下記が挙げられます。

• サーバーレスの側面からくる高い可用性
• 従量課金によるコスト効率の良さ
• 属性値を気軽に追加できる
• インデックス設計次第では非常に高速

特にインデックス設計は、データアクセスがどのようにされるのかを事前に検討してから行うことが必要です。
データアクセス設計の重要性はこちらで解説しています。

ElasticSearchとの付き合い方

ElasticSearch は、柔軟な検索要件を扱いたい時に利用します。ElasticSearch はインデックス設計次第では設計後に柔軟な複合検索の実行、自由なソート要件へ対応することが可能となり、大半のウェブ・スマフォアプリの検索要件は網羅できます。

ただし ElasticSearch は下記のような要件がある場合は採用を慎重に選択しなければいけません。

• リアルタイム性を求めたい
• 月額のインフラコストがシビア

加えて、ElasticSearch を導入する際はインデックス設計も必要です。DynamoDB レベルに厳しいデータアクセス設計が必要ないにしても、NoSQL ならではのインデックス ( データベース ) 設計の知見は求められます。

DynamoDB・ElasticSearchそれぞれの推奨ケースまとめ

DynamoDBを推奨したいケース

• KVS による高速なデータ取得
• 可用性を求められるデータアクセス
• アプリケーションのメインデータベース ( ユースケースで他 DBMS 併用 )

ElasticSearchを推奨したいケース

• DynamoDB のリード API ( GetItem, BatchGetItem, Query, Scan ) で対応が難しい検索要件の対応
• AWS 月額利用費用に余裕があるプロジェクト
• 管理画面 ( BI ツール等 ) の検索要件への対応

DynamoDBのみで検索要件をカバーするテクニック

ElasticSearch が非推奨という意味ではございませんが、ElasticSearch を採用することでコスト高に悩まれている場合は有効な手段かと思います。

形態素解析の利用

KVS の特性を生かして、文字列を形態素解析し DynamoDB へ格納します。
今回はブログの記事登録機能を想定します。

1. ブログの投稿画面で記事文章を登録
2. Amazon Comprehend で形態素解析APIへテキストを送信
3. レスポンスの単語を DynamoDB の PK として格納
4. BatchGetItem で PK で Item を取得

GSI設計テクニックを活用

ComposieKey、GSI-Overloading、Sparse-Index などの設計テクニックを活用し、DymamoDB で検索要件に対応します。注意することは、あくまで DynamoDB は KVS なので、パラメーター同士の複合検索やソート要件への柔軟対応は苦手という点です。

詳しくはこちらをご覧ください。

まとめ

正直なところ私たちが最も利用するパターンは下記です。

• DynamoDB をメインDB として扱う
• 検索要件は ElasticSearch ( DynamoStream よりインデックス連携 )
• 縦軸処理は RedShift ( DWH )
• BI への連携は AWS Glue を活用し QuickSight へ流し込む

データベースをユースケース別で使い分けることで、1つの DBMS の担う仕事を減らすことが可能になり、運用コストや実装面のストレスを緩和することができます。

最後までご覧いただき、ありがとうございました。
AWS のアーキテクチャー、開発のご相談はお気軽にお問い合わせください。