※ 本記事は、Ranjan Priyadarshiによる”JSON Relational Duality: The Revolutionary Unification of Document, Object, and Relational Models“を翻訳したものです。

2024年5月7日

JSONリレーショナル二面性は、Oracle Database 23ai(旧Oracle Database 23c)のランドマーク機能であり、Oracle Database開発者に画期的な柔軟性とシンプルさを提供します。この画期的なイノベーションは、リレーショナル・モデルの使用時またはドキュメント・モデルの使用時に、開発者がアプリケーションの構築時に直面した過去の課題を克服します。Oracle Database 23aiの一般提供と主な機能の詳細は、Oracle Database 23aiの発表ブログを参照してください。

JSONリレーショナル二面性は、どちらのモデルのトレードオフも行わずに、リレーショナル表とJSONドキュメントの両方のメリットを提供するソリューションを提供します。

アプリケーション開発のリレーショナル・モデルとドキュメント・モデルを使用する制限

リレーショナル・アプローチは非常に強力ですが、必ずしもアプリケーション開発にとって最も簡単なわけではありません

リレーショナル・モデルは、データの重複を回避しながらデータの整合性を確保するためにデータ正規化を使用するため、非常に強力で効率的です。リレーショナル操作により、データのモデリングとアクセスが非常に柔軟になりますが、開発者にとって常に最も簡単なわけではありません:

  • 開発者は通常、アプリケーション層の言語オブジェクトに関してアプリケーションを構築し、リレーショナル・データベースではデータを表、行および列として格納します。個々のアプリケーション層オブジェクトを構築するには、多くの場合、複数の表にアクセスする必要があります。
  • これらの問題を回避するために、開発者はオブジェクト・リレーショナル・マッピング(ORM)フレームワークを使用することがよくあります。ORMはapp-devを簡素化できますが、オーバーヘッドも大きくなります。通常、単一のapp-tierオブジェクトを操作するために複数のデータベース・ラウンドトリップが必要になりますが、これは非効率です。データベース・エンジンの機能を十分に活用せず、同時実行性制御を適切に管理せず、アプリケーションは異なる言語に対して異なるORMフレームワークを使用する必要があります。また、多くのアプリケーション層オブジェクトを挿入または変更する必要があるバッチ操作やバルク操作でも非常に不十分です。
  • アプリケーション層のORMフレームワークでは、モジュールとマイクロサービス間で異なるセマンティクスの可能性も導入されます。ただし、それらのすべてがまったく同じマッピング情報を共有している場合を除きます。

したがって、リレーショナル・モデルは非常に効率的なデータ・ストレージ形式ですが、データ・アクセス形式として使用され、ORMが非効率性やその他のトレードオフを導入する場合、開発者にとって課題となることがあります。

JSONドキュメント・データベースに独自の欠点

ドキュメント・データベースは、アプリケーション層の言語オブジェクトに対応する階層的に編成されたデータを簡単に取得して格納できるため、開発者に人気があります。JSONドキュメント・モデルを使用すると、アプリケーションはオブジェクトを階層JSON形式に直接マップできるため、分解や再構成、および関連する複雑さを回避できます。ただし、次の理由から、JSONドキュメント・モデルはストレージ形式としては理想的ではありません:

  • ドキュメントには、重複するデータを格納することがよくあります。たとえば、異なるOrder文書に、同じCustomer情報が重複して格納される場合があります。共有情報(顧客の電話番号など)の更新では多数のOrderドキュメントを原子的に更新する必要がある場合があるため、データの複製によって非効率性および潜在的な不整合が発生します。
  • この問題を回避するために、一部のドキュメント・データベースでは、参照を使用してドキュメントを正規化することをお薦めします。つまり、OrderドキュメントにCustomerドキュメントを含めるかわりに、OrderドキュメントにはそのCustomerドキュメントのIDのみが含まれる場合があります。ただし、ドキュメントを正規化すると、ドキュメント・モデルのシンプルさが完全に損なわれ、実際には両方の世界で最悪のモデルになります。
  • また、ドキュメント・モデルを使用して多対多関係をモデル化することも非常に困難です。関係をモデル化しようとすると、データの重複がさらに大きくなり、不整合が生じる可能性があります。

したがって、ドキュメント/JSONは開発者にとってわかりやすいデータ・アクセス形式であり、開発者は簡単に開始できますが、特にアプリケーションの複雑さが増すにつれて、データ・ストレージ形式には大きな制限があります。

Oracle Database 23ai JSONリレーショナル二面性がアプリ開発に革命をもたらす方法

Oracle Database 23ai JSONリレーショナル二面性は、先ほど説明したトレードオフなしで、単一のデータベース内でリレーショナル世界とドキュメント世界の利点を統合します。Oracle Database 23aiでは、この機能を有効にする新機能がJSONリレーショナル二面性ビューと呼ばれます。

Figure 1: JSON Relational Duality: Best of both worlds
図1: JSONリレーショナル二面性: 両世界のベスト

 

二面性ビューを使用すると、データは非常に効率的な正規化された形式でリレーショナル表に格納されますが、JSONドキュメントの形式でアプリケーションによってアクセスされます(図2)。そのため、開発者は、シンプルさや効率性を損なうことなく、データ・ストレージに非常に効率的なリレーショナル・モデルを使用しながら、データ・アクセスのためのJSONドキュメントについて考えることができます。これに加えて、二面性ビューでは、データベース・レベルの同時実行性制御のすべての複雑さがユーザーに対して非表示になり、ドキュメント・レベルのシリアライズ可能性が提供されます。

Figure 2: Stored as rows - Accessed as JSON documents
図2: 行として格納- JSONドキュメントとしてアクセス

 

二面性ビューは、直感的なGraphQL構文を使用して、任意の数の表に対して宣言できます。たとえば、次の二面性ビューでは、order表、orderitem表およびcustomer表で使用可能なリレーショナル・データが、アプリケーション層のオーダー・オブジェクトに対応するJSONドキュメントとしてレンダリングされます:

Figure 3: Declaring a Duality View
図3: 二面性ビューの宣言

 

開発者は、同じリレーショナル表または重複するリレーショナル表のセットに対して異なる二面性ビューを簡単に定義できるため、同じデータ(orderitemやcustomerなどの一般的な表を共有するOrderObjやShipmentObj二面性ビューなど)で複数のユースケースを簡単にサポートできます。
二面性ビューを使用すると、開発者の柔軟性が大幅に向上します: 

  • SQL JSON拡張を使用した、JSON列のデータを含むすべてのデータへのSQLアクセス
  • 二面性ビューを使用した、リレーショナル表に格納されているデータへのアクセスを含む、すべてのデータへのJSONドキュメント・アクセス

開発者は、通常のドライバ、フレームワーク、ツールおよび開発方法を使用して、二面性ビューによって生成されたJSONドキュメントを、使用された方法で操作できます。

開発者にとって非常にシンプルで柔軟

開発者は、単一のアプリケーション層オブジェクトに必要なすべてのデータを1つのデータベース操作で取得して格納できるというシンプルさから大きなメリットを得られます。二面性ビューを使用するアプリケーションは、単にビューからドキュメントを読み取り、必要な変更を行い、基礎となるリレーショナル構造を心配せずにドキュメントを書き戻すことができるようになりました。通常のドライバ、フレームワーク、ツールおよび開発方法を使用して、二面性ビューで実現されたドキュメントを、使用中の方法で操作できます:

  • 二面性ビューは、ORMフレームワークの必要性を排除します。
  • ドキュメント中心のアプリケーションでは、Oracle Database API for MongoDBやOracle REST Data Services (ORDS)などのドキュメントAPIを使用することも、SQL/JSONドキュメント関数を使用することもできます。
  • 二面性ビューの読取りおよび書込みでは、GET、PUT、POSTなどの使い慣れたHTTP操作を使用できます。
  • HTTPよりもAPIを好むアプリケーションは、Oracle Database API for MongoDBを使用できます。
  • 二面性ビューを使用するアプリケーション操作は、ORMによって生成される非効率的なデータベース・アクセス・コードとは対照的に、アプリケーション層オブジェクトのユースケースに必要なすべての行を1つのデータベース・アクセスにフェッチして格納できるため、データベース内で最適に実行されます。

したがって、JSONリレーショナル二面性は、リレーショナル・モデルのストレージ、一貫性および効率性のメリットを提供し、JSONドキュメント・モデルのシンプルさと柔軟性も提供します。

Oracle Database 23aiによるロックフリー同時実行性制御

二面性ビューは、Oracle Database 23aiの新しいロックフリーまたはオプティミスティックな同時実行性制御アーキテクチャの恩恵も受けています。これにより、開発者は、ステートレスな操作間でデータを一貫して管理できます。

  • ロックはステートフルであり、ステートレス・コール間で保持できないため、従来のロックはREST GETやPUTなどのステートレス操作では機能しません。
  • Oracle Database 23aiの新しいロックフリー同時実行性制御アルゴリズムにより、ステートレス操作全体で一貫した更新が可能になります。
  • ロックフリー・スキームは、HTTPプロトコルからコア・データベースにエンティティ・タグ(ETAG)の概念を拡張し、取得したWebページの内容のハッシュまたは署名としてETAGを拡張します。
  • 二面性ビューに対してGETが実行されると、戻されたJSONドキュメントには、ドキュメントの構築に使用される行のセットのETAGも含まれます。
  • そのドキュメントが変更され、後でデータベースにPUTが戻されると、指定されたETAGが行の現在のETAGと比較されます。ETAGが異なる場合、オブジェクトはGETとPUTの間で変更されている必要があり、PUTは拒否されます。
  • その後、アプリケーションは新しいETAGを使用してドキュメントを再取得し、PUTを再試行できます。
  • PUTが成功した場合、オブジェクトに対して介入する変更が発生せず、ドキュメント・レベルの原子性と一貫性を確保することが保証されます。
  • ロックフリー同時実行性制御を使用したドキュメント・レベルのシリアライズ可能性により、開発者はアプリケーション層内でデバッグの同時実行性制御およびデータ一貫性の問題を実装するのではなく、アプリケーションに集中できます。

要約: JSONリレーショナル二面性でアプリ開発を簡素化

  • 開発者は、JSONドキュメント・モデルの柔軟性とデータ・アクセスのメリットに加え、リレーショナル・モデルのストレージ効率とパワーを得ることができます。
  • 二面性ビューは、リレーショナル・データに対する完全に更新可能なJSONビューです。アプリケーションは、アプリケーション層オブジェクトに対応するドキュメントを読み取り、必要な変更を行い、基礎となるリレーショナル構造、型マッピングまたはデータの一貫性を気にすることなく、ドキュメントを書き戻すことができます。
  • 複数の二面性ビューを複数の表のグループにわたって実装できるため、同じデータに対して複数のアプリケーション・ユース・ケースを柔軟に処理できます。
  • 二面性ビューを使用するアプリケーション操作は、データベース内で最適に実行されます。
  • 新しいオプティミスティックな同時実行性制御アルゴリズムにより、高い同時実行性更新と対話型ユース・ケースが可能になり、ドキュメント・レベルの強力なシリアライズが可能になります。

次のステップ: Oracle Database 23ai for freeでJSON Relational Dualityを試す

開発者は、Oracle Database 23aiのいくつかの無料オプションのいずれかを使用して、JSONリレーショナル二面性などのOracle Database 23ai機能を使用してアプリケーションの構築を開始できます。私たちは、アプリ構築における二面性ビューのパワーと柔軟性を簡単に体験できるようにしています。私たちは、GitHubで、文書化され、学習しやすいチュートリアルを提供しています。チュートリアルをダウンロードして、任意の無料のOracle Database 23aiで使用することができます。チュートリアルでは、開発者がSQL、RESTおよびOracle Database API for MongoDBを使用して、二面性ビューに関連する機能および例を試すことができます。

その他のリソース: