企業が新しいデータソースを活用して、既存のビジネスプロセスを改善したい、あるいは、ビジネスモデルを根本から変革させたいと考える中で、アプリケーションでは、旧来のリレーショナルに加え、ドキュメント、キーバリュー、オブジェクトなどの多様なデータモデルに対応するなど新しい要件がでてきています。この課題は、ITの複雑さを高めることなく、いかにデータモデルを追加できるかにあります。
SQLデータベースは普及する一方で、企業は、多様な型のデータの永続化を採用するようになりました。これは、こうした企業が、ドキュメントデータベースからドキュメントデータを、キーバリューデータベースからキーバリューデータをといった、それぞれのデータモデルタイプで異なるデータストアを使用している事を意味します。アプリケーション全体としてデータモデルを増やすと、データ変換やデータ系統といった事を管理しようとする時の複雑性があることが理解できると思います。これは、シンプルさを保つという原則に反します。
市場の要求に答えるため、NoSQLベンダーは、多様なデータモデルを１つの統合したバックエンドデータベースに保存する機能を提供しはじめており、これにより「マルチモデルデータベース」という言葉が生まれてきました。この利点は、アークテクチャの複雑さが減り、さらにデータの一貫性が改善されることにあります。
近年のアプリケーションは、その基盤としてマルチモデルデータベースが必要であるという前提から考えると、新たな疑問は、マルチワークロードがサポートできるかということになります。マルチワークロードデータベースは、トランザクションと分析を同時に処理できる能力があります。マルチモデルデータベースの歴史に見るように、組織は、ワークロードに特化したデータベースを構築してきました。OLTPなどの分析に特化したものやOLAPに特化したものなどです。
この複雑さをお使いの多種多様な永続データストアに加えると、何が得られるのでしょう？
答えは、煩雑さです。ガートナーは、マルチロードデータベースをハブリッドトランザクション/分析処理（HTAP）データベースと呼んでいます。この概念により、OLAPデータベースの必要性を廃除し、トランザクション処理を行う同じデータベース上で分析を走らせることが、広まってきました。その価値は、マルチモデルと同じで、シンプルなアーキテクチャ、全体としての維持管理コストの低減などです。
もう1歩踏み出してみましょう。では、リレーショナルとドキュメントデータソースの両方のトランザクションを処理して、構造化/非構造化データ分析をしながら、アプリケーションが、最適にトランザクション処理を行う必要があるとします。その場合、異なるデータソースの処理、あるいは構造化と非構造化データを含む複数の分析データベース処理をするために複数のデータベースを持つか、あるいは、マルチモデル、マルチワークロードデータベースを持つことが考えられます。
この場合、複雑性を加えることより、KISSの原則（keep it simple principle）に則ってエレガントなシンプルさを求めるべきです。それによる利点は、劇的なコスト削減も含まれます。なぜなら、アプリケーションをサポートするリソース要求が劇的に下がるからです。動的なパーツが減ることは、管理が容易になるだけでなく、自ずと高性能、高可用性、高拡張性に繋がります。
市場に投入される新しいデータモデルの数は継続的に増え、顧客はそれらを自身のアプリケーションに追加したいと考えます。当社は、シンプルさを保つということで、多種多様な永続データベースを持つことを回避させたいと考えます。
