NoSQL データベースのアジャイルなデータモデリング

先日の Data Architecture Summit 2018 Conference にて、 Hackolade の CEO である Pascal Desmarets 氏が NoSQL データベースのためのアジャイルなモデリングについて語った。 NoSQL データベースでは正規化の制約がなくなるためデータモデリングが更に重要になる、と彼は述べた。非構造化かつポリモーフィックなビッグデータはガバナンスとレギュレーション（GDPR and PII）の観点から困難をもたらし、同時に、蓄積された情報にレバレッジを効かせることができるようになる。

Desmarets 氏は、データモデリングによって企業が RDBMS から NoSQL へのマイグレーションをいかに容易になるか、についても語った。関連データベースと NoSQL データベースでのデータモデリングを行うと、高いアプリケーションの品質、改善されたデータの品質、GDPRと個人情報、そしてビジネスインテリジェンスといった利点が得られる。

チームは彼らの要求に基づいて適切な NoSQL データベースを選択するべきだ。たとえば、シンプルなスキーマで高速な read/write を、頻繁な更新を必要とせず行いたい場合は key-value ストアを選択する。複雑なクエリで柔軟なスキーマを必要とする場合は ドキュメントデータストアを選択する。列志向データベースは、読み込み速度が比較的重要視されないが高速な書き込みが求められる場合に適している。各データのプロパティとデータ間の関連が同時に保存され、それらデータを横断して取得するアプリケーションにはグラフデータベースが適しているだろう。

彼は伝統的なデータモデリングプロセスについて、そして我々がデータモデリングからスキーマ設計アプローチへいかに移行しているかについて騙った。概念データモデルはドメイン駆動設計 (DDD) によって置き換えられており、論理データモデルはもはや必要ではなくなり、物理データモデルは物理スキーマ設計によって置き換えられている。

アジャイルな開発プロセスでは、データモデリングはプロダクションを含む各ステップで役割を担う。データモデリングのための努力は共同責任であり複数のプロジェクトのステークホルダー間の会話が必要となる。

彼はドメイン駆動設計 (DDD) と NoSQL の相性がよく、 DDD の言語と NoSQL データベースの概念には直接的な一致がみられる、ということも述べた。彼の主張は、一貫性が戦略、プロセス、アーキテクチャー、技術において重要であり、ドメイン駆動設計、アジャイルな開発、データ中心性、マイクロサービス、イベント駆動アーキテクチャ、NoSQL、DevOps、クラウドといった規律を、いずれか1つか2つ適用するのではなく、全てを同時に適用することが望ましい、ということだった。

InfoQ は Desmarets 氏と会話し、 NoSQL データベースのデータモデリングとビッグデータのマネジメントのベストプラクティスについて尋ねた。

InfoQ: データモデリングのアプローチは、たとえば Cassandra のような時系列データベースと Neo4j などのグラフデータベースのように、 NoSQL データベースの種類によって異なるのでしょうか？

Pascal Desmarets 氏: 原則はほぼ同じですが、実装が大きく異なることがあります。 NoSQL の利点を生かすためには、アプリケーション固有のデータモデルを設計することが重要であり、クエリのパフォーマンスを最適化する方式で情報を保存することになるでしょう。この考え方の転換は、アプリケーションに依存しない原則を数十年間も適用し続けてきた人にとっては困難かもしれません。我々の多くにとって、正規化のルールは後天的な才能であり、我々は自身をクエリ駆動のアプローチを NoSQL データベースのスキーマ設計に対して適用するよう強制する必要があります。

クエリ駆動の手法は NoSQL データベースの全ての種類に対してほぼ同様です。しかし各技術のスキーマ設計の特定の側面となると、最大の違いはグラフデータベースと他の3種類の NoSQL DB の差です。グラフデータベースの性質は、クエリ実行時のグラフトラバーサルのパフォーマンスなどが挙げられます。これはほかの技術では属性を要求しますが、グラフデータベースの場合ではエンティティまたはノードの状態となります。

NoSQL データベースの種類のなかでも違いはあります。たとえばグラフデータベースであれば、プロパティと RDF トリプルでは根本的に異なります。 JSON ドキュメントデータベースでは、 Couchbase と MongoDB を比べてみると構造的なストレージの差異がわかるでしょう。同様に HBase と Cassandra はデータ保存のアプローチが全く異なります。

InfoQ: NoSQL データベースのアジャイルなモデリングにおけるベストプラクティスについて教えていただけますか。

Desmarets 氏: 我々が数十年にわたって記憶しているデータモデリングはアジャイルな開発のコンテキストにおいて大きなプレッシャーを与えられています。データモデリングをアジャイルにしようとしても、スピードと2週間スプリントのケイデンスのボトルネックとなってしまうこともよく見られました。世界中のデータモデラーはプロセスから外されているように感じています。真実は、いくつかのスキーマ設計の形態は不可欠であり、つまりデータモデリングは関連性を維持して再発明される必要があるのです。

まず、データモデリングは初期段階のヘビーなタスクではなく、開発スプリントやアプリケーションのライフサイクルに応じたイテレーティブなプロセスが必要です。

データモデリングはまた、ビジネスの理解を抽象化することに長けたデータモデラーと、要求をコードに翻訳する方法をよく理解した開発者との、コラボレーティブなプロセスも必要です。

したがってデータモデラーはスクラムチームに欠かせない存在となります。

この方式は、特に前述のクエリ駆動でアプリケーション固有のアプローチを用いる場合、開発テクニックと技術スタックに適用される必要があります。アプリケーションのクエリを派生させてスキーマの設計を考慮するため、スクリーンワイヤーフレームやレポートなどを用いて、ドメイン駆動設計とユーザー体験およびビジネスルールのフローチャート化を組み合わせなければなりません。

最後に、この新しい景色に適用する軽快な次世代のツールが必要となるでしょう！

彼はまた、NoSQL データベースのベンダーたちが長い時間をかけて ‘スキーマレス’ あるいは ‘非リレーショナル’ といった言葉で差別化し噂を生み出してきた、ということも話した。しかし NoSQL データベースは柔軟で強力なものであり、厳格な技術を知らない未熟なユーザーは容易に困難に陥る。ベンダーたちはそのことに気づき、ソリューションを企業に販売するため、代わりに ‘動的スキーマ’ という言葉を使うのが賢いとしている。データモデリング（スキーマ設計ではなく）は実は、関連データベースを扱う場合よりも NoSQL を扱う場合のほうがより重要となる。我々はこれまでと異なる種類のデータモデリングが必要だ。そしてデータモデラーはアジャイルな開発を受け入れ、新しい技術スタックの実装を学び、開発プロセスにおける新たな価値を証明するのだ。