はじめに
本記事では、データベースに求められる要件の多様化についてまずは触れ、なぜ最適なデータベースを選択する必要があるのかについてお伝えします。
こちらはAWS Summit Tokyo 2019 Breakout Session 「【初級】 AWSにおけるデータベース選択指針」を基にした内容となっております。
目的
- なぜデータベースの選択が必要なのかを理解すること
- 各種データベースの特徴と考えられるユースケースを理解すること
対象
- データベースの選定を行う方
- リレーショナルデータベースを使ったアプリケーション開発経験をお持ちの方
- リレーショナルデータベース以外のデータベースの知識はお持ちでない方
アプリケーション要件の多様化
人事システムやCRM、ERPなど、主に社内ユーザ向けのエンタープライズシステムで使われるデータベースといえば、Relational Database(RDB)が主流でした。このような社内システムのユーザ数はおおよそ数十人だったり、多くても数万人、そして、データ量は数十GBから数TB程度の容量が主流でした。そして、システムの拡張はサーバのスケールアップで対応ケースが多かったと思います。
しかし、近年、データベースのニーズは、大きく変わってきていると思います。既存のワークロードと異なる新しいワークロードへの対応が必要になってきています。それは、メディアストリーミング、ソーシャルメディアなどのシステムです。そのシステムにおけるデータベースの要件は、数百万人のユーザ数に応えるためのものだったり、データ量も数TBから数PBになる場合もあります。ユーザーはモバイル端末からアクセスしたり、大多数のIoTデバイスからのアクセスのあるシステムもあります。
従来のアプリケーション要件のように、ユーザー数が比較的少なく、データ量の規模が小さければ、シンプルなデータベース要件で満たせていたかもしれません。しかし、データ量が拡大し続けていくなど要件が多様化した昨今、要件に応じて「データベースを選択していく」ことが重要になると考えています。
従来のエンタープライズ DBシステムにおいても、トランザクション処理はOLTP専用のRDBで、分析をするときはOLAP専用のRDBを利用するといった用途に応じた使い分けは一般的に行われていました。なぜなら、トランザクション処理に求められる要件と、分析に求められる要件が異なっていたため、異なる物理設計のRDBを用意することが最適解の一つだったからです。そして、アプリケーション要件の変化した近年においては、複数のRDBを使い分けるだけではなく、RDB以外のデータベースも選択肢に入れた、複数のデータベースの使い分けも検討すべきと考えます。また、1つのシステム内でも複数のデータストアを組み合わせて活用することで、開発効率向上・運用負荷軽減を行うことが出来ます。
データベースの選択
データベースには多様な選択肢があり、ワークロードに応じて最適な選択が可能です。最適なデータベースを選択すれば、そのデータベースで担保されている機能を活用でき、アプリケーションで同様の機能を実装する必要がなくなります。さらに、データベース内で最適に実装されている分、高速に動作することが期待出来ます。しかし、注意点もあります。例えば、テーブルの結合やトランザクションなどの実行の必要がある場合に、選択するデータベースによって、その機能が不足しているケースが考えられます。その場合は、アプリケーション側でそれを実装する必要があるため、アプリケーションの設計が変わってきます。さらに、データ量が増加してきたときにどのように分割するか、パフォーマンス向上のためのチューニング方法、堅牢性、管理の容易さなどについても各データベースで戦略が異なる点も考慮するポイントになります。
各種データベースの特徴と一般的なユースケース
RelationalとNon-Relationalデータベースに分けて、それぞれの一般的なユースケースについて考えてみます。
Relational
以下引用：
リレーショナルデータベースとは、事前定義された、関連があるデータ項目の集合体です。この項目は、列と行を持つテーブルのセットとして構成されます。テーブルは、データベースに表現されるオブジェクトに関する情報を保持するために使用されます。テーブルの各列には、特定の種類のデータおよび属性の実際の値を保存するフィールドが保持されます。テーブルの各行は、1 つのオブジェクトまたはエンティティに関連する値のコレクションです。テーブルの各行は、プライマリキーと呼ばれる固有の識別子を使ってマーキングできます。また、外部キーを使用すると、テーブル間で複数の行を関連付けることができます。このデータには、データベーステーブル自体を再編成することなく、さまざまな方法でアクセスできます。多くのリレーショナルデータベース製品にはアトミック性、一貫性、分離性、および耐久性(ACID)の特性があります。
引用元：リレーショナルデータベースとは
リレーショナルデータベースのユースケースとしては、基幹系システムやERP、CRM等のエンタープライズアプリケーション、SaaSアプリケーション、Eコマースアプリケーション、その他ウェブアプリケーションが挙げられます。
また、データウェアハウスやデータマートと呼ばれるOLAP用にも使用されます。OLAP処理に不要な機能を省く代わりに、ペタバイトレベルのデータの分析の高速化をより簡単に実現している製品もあります。
Non Relational
RDBではないデータベースの総称のことをNoSQL(Not only SQL)と呼ぶこともあります。従来は、データベースにはRDBが一般的に採用されていましたが、昨今のアプリケーション要件の高難易度化に伴い、そのアプリケーション要件に不要な機能を省き、その要件をより実現しやすくする目的のために開発されたものが多いです。
NoSQLのデータベースには、さまざまな種類があります。それぞれの特徴とユースケース、解決する課題について触れることで、RDBのみならず、用途にあわせて適材適所で異なるデータベースをご活用頂く必要性をお伝えしたいと思います。
Key Value Store
KVSではKeyとValueというデータ構造を持ちます。データの量やアクセス数の規模を問わず、低レイテンシーで高スループットのデータアクセスを実現可能です。インターネットスケールのシステムで、スケール規模を事前に予測するのが難しいシステムで用いることができます。
KVSのユースケースの例としてはオンラインゲームにおいて永続化が求められるアイテムのステータス管理に使用するケースや、Eコマースのショッピングカートで、ホリデーシーズン等のピーク時の更新処理に使用するケースがあります。
RDBは1:1の関係（たとえば、顧客ID:顧客名。1つの顧客IDには1つの顧客名しか許されな場合、1:1の関係となる）はもちろん、結合 (JOIN) を用いることで1:Nの関係（たとえば、顧客ID:注文書番号。1つの顧客IDから複数の注文をできる場合、1:Nの関係となる）を表現することも得意としています。上記のユースケースはRDBでも実現可能です。ただし、これらのユースケースは1:1の関係が多いため、1:1の関係により最適化されたKVSを利用することで、RDBよりも比較的簡単にスケールアウトさせられるなどのメリットを得られる場合があります。あるユースケースが1:Nまたは1:1のどちらか一方に限られるケースはあまり多くありませんが、1:Nの関係と1:1の関係のどちらが主であるかを考えることは、RDBを選ぶかKVSを選ぶかの良いスタートポイントになります。
###ドキュメントデータベース
以下引用
データを JSON のようなドキュメントとして保存し、クエリするために設計されています。ドキュメントデータベースを使用すると、開発者はアプリケーションコードで使用しているのと同じドキュメントモデル形式を使って、簡単にデータをデータベースに保存し、クエリできるようになります。ドキュメントおよびドキュメントデータベースは柔軟性があり、半構造化され、階層的な性質を持つため、アプリケーションのニーズに合わせて進化させることができます。ドキュメントモデルは、カタログ、ユーザープロファイル、コンテンツ管理システムなど、各ドキュメント固有のものであり、時間の経過とともに進化するユースケースでうまく機能します。ドキュメントデータベースを使用すると、柔軟なインデックス作成、強力なアドホッククエリ、およびドキュメントのコレクションに対する分析が可能になります。
引用元：ドキュメントデータベースとは
ユースケースとしては、多種多様なコンテンツ管理やカタログ情報管理などがその例になります。
JSON や XML は柔軟に属性を追加できる一方、一部のRDBでは属性の追加に該当する列の追加はコストが高く、本番環境では気軽には実行できないという意見を聞くことがあります。また、アプリケーションがメモリー上では JSON で処理しているものの、永続化の目的のためにデータベースに書き込みたい場合、RDB に保存する場合は JSON をリレーショナルモデルに変換する必要があるかもしれません。しかし、ドキュメントデータベースに保存する場合は JSON をそのまま保存できます。一部の RDB では JSON 型などのドキュメント型を持っているものもありますが、ドキュメントデータベースはドキュメントに特化することで、複雑なクエリーをより簡単に実行することが一般的には可能です。一方で、データモデルの柔軟さよりも堅牢さを重視する要件の場合、柔軟に属性を追加できるドキュメントデータベースの特徴が逆にデメリットになることも考えられます。RDBの場合、Add column 権限はアプリ開発者ができないような権限に設定することもできます。さらに、RDBでは外部キー制約やチェック制約で、データ管理者が想定しているデータしか入れらないような制約をかけることが可能です。
###インメモリデータベース
データベースの中には、主たる処理をメモリーだけで実行するように設計されたものもあります。メモリーに特化することで、短い応答時間を安定的に実現できることが期待できます。単体で使われることもありますが、RDBなどのほかのデータベースからクエリーした結果をキャッシュするなど、その他のデータベースと組み合わせて使われることも一般的です。
ユースケースとしては、Webサイトやゲームにおけるレイテンシ・クリティカルな処理に向いています。
インメモリーデータベースは書き込み応答時間を短くするために、書き込んだデータをディスクで永続化しない、またはメモリーに書き込んだタイミングとは非同期にディスクに書き込むことが一般的です。そのため、何らかの障害などでメモリー上のデータが揮発した場合、すべてのデータ、または直近のデータを失う可能性があります。すべてのデータをディスクに同期で書き込むことが可能な製品もありますが、その場合、データは失われませんが、書き込み性能についてはインメモリーデータベースの特徴が生かせません。データ消失が許容できるかどうか、または読み取り性能だけが高速化できれば良いのかなどの観点が、インメモリーデータベースを検討する際のスタートポイントになります。
グラフデータベース
以下引用
グラフデータベースは、リレーションシップの格納とナビゲートを目的として構築されたデータベースです。リレーションシップはグラフデータベースにおける最重要の構成要素で、グラフデータベースの価値の大半は、これらのリレーションシップから引き出されます。グラフデータベースはノードを使用してデータエンティティを格納し、エッジを使用してエンティティ間のリレーションシップを格納します。エッジには常に開始ノード、終了ノード、タイプ、方向があって、1 つのエッジで親子関係、アクション、所有権などを記述できます。1 つのノードが持つことができるリレーションシップの数や種類に制限はありません。
引用元：グラフデータベースとは
グラフデータベースではデータ間を相互に結び付けて、データ同士の関係をグラフという形で表します。データ同士がN:Nの関係（たとえば、SNSユーザーと店舗。1人のユーザーは複数の店舗にチェックインでき、1つの店舗には複数のチェックインした人がいる）を表すのに向いています。
ユースケースとしては、SNSのフレンドの関連性が一つの例であり、他にもSNSニュースフィードや商品やコンテンツのリコメンデーションのユースケースがあります。
RDBではN:Nの関係を直接表現できないため、1:N + 1:1 + N:1 という3つの表で表現する必要がありました。交差表と呼ばれる表を追加して、3つの表で表現する必要がありました。また、RDBは、あるデータから直接的な関係があるデータへのアクセスは得意ですが、階層構造をたどるような、間接的なデータにアクセスする際には特別な実装をしないと再帰アクセスが必要となり、性能が出ないこともあります。このように、RDBでもこれらのデータを管理することは不可能ではありませんが、グラフデータベースはグラフ構造に特化することで、より簡単に高速処理できるようになっています。
時系列データベース
時系列データでは時間が唯一の主軸となります。特定の間隔で記録され続けます。時間の経過に伴う変化を測定することで、迅速に時系列データを分析し、警告を出すことができます。
ユースケースとしては、IoTデバイスデータやアプリケーションのイベント、DevOpsにおけるリソース監視データ、産業用テレメトリなど継続的にデータを送り続けられるケースが考えられます。解決したい課題としては、複数のデバイスが数百万/秒レベルのログを生成します。多数のソースからの頻繁な送信に対して、大量の挿入と一定の時間間隔での分析処理を両立させる必要があります。
これらのデータは今まではRDBに保存することが一般的でしたが、数百万台のデバイスからの同時接続への対応や、数百万/秒のINSERTを安定的に実現するには、高度なチューニングが必要でした。時系列データベースは、時系列を持つデータに特化することで、より簡単にこれらのユースケースに対応できるようになっています。
台帳データベース
台帳データベースで扱うデータは、その変更履歴がイミュータブル（変更や削除が不可能なもの）です。意図しない変更が発生していないことを暗号学的ハッシュ関数で検証が可能です。管理者でも変更履歴を改ざんできないことを保証することができます。
ユースケースとしては、医療カルテや保険ログ、不動産登記、戸籍、住民票、渡航履歴、会計上の証跡、契約書管理などがあります。
エンタープライズDBシステムなどでは変更履歴をすべて保存しておく要件はしばしばあり、これらはRDBのトリガーなどを使って従来は実現されていました。しかし、トリガーでの実装は列の追加ごとに新たなトリガーの追加が必要になり、列追加時のコスト増の要因の一つになっていました。また、一般的なデータベースでは、データベース管理者 (DBA) は、すべてのデータの読み書きが可能であるため、DBAによるデータ改ざんを防ぐことは困難でした。台帳データベースは、すべての変更履歴が自動的に保存され、その履歴を消去する方法をデータベースとして提供しないことで、上記のような課題を簡単に解決しています。
最後に
Non-Relationalデータベースには上記以外にも様々なものが存在しますが、今回は上記のものをピックアップし、それぞれのデータベースを選択するためのガイドをご紹介しました。
具体的に１つのユースケースをサンプルとして、異なるデータベースを活用する例を紹介します。
独自のAWSデータベースを使って最新のアプリケーションを構築
こちらはオンライン書店のデモアプリケーションを使って、製品カタログや製品検索、ベストセラーリスト、ソーシャルリコメンデーションを実現する例が紹介されています。KVSやインメモリデータベース、グラフデータベースを活用した例となっていますので、宜しければご覧ください。