※ 本記事は、Hermann Baerによる”To SQL or not to SQL: that is not the question“を翻訳したものです。

2025年7月2日

SQLとNoSQLの継続的な議論は、リレーショナル・データベース・システムと同じくらい古いものです。エドガー F. Codd氏は1970年にリレーショナル・データベースの概念を導入し、データベース・システムの構造と柔軟性の間には継続的な緊張がありました。SQLデータベースは、数十年にわたる実績ある信頼性、強力なACID保証、複雑なリレーショナル・データ・モデルに最適な強力なクエリ機能によって優位性を主張しています。対照的に、NoSQLデータベースでは、堅牢なスキーマは最新の開発に対応できず、スキーマの柔軟性、シンプルなアプリケーション開発、または高速または非構造化データのパフォーマンスが向上すると主張しています。

それぞれの陣営が優位性を主張していますが(一貫性と完全性のSQL、スピードと俊敏性のNoSQL）、現実のトレンドは収束傾向にあり、両陣営とも他方の陣営から機能を借用する取り組みが増えています。

SQLおよびNoSQL: マルチモデル・データベースへの変換

MySQL、PostgreSQL、Oracleなどのマルチモデル・データベースは、従来のリレーショナル・システムに非リレーショナル機能を統合する最前線にあります。最近のイノベーションには、ベクトル処理、ドキュメント・ストア機能、JSONドキュメントのコレクションのサポートが含まれます。これらの新機能により、開発者は次のことができます:

  • 使い慣れたドキュメントAPIを使用したJSONドキュメントの操作
  • SQLを使用して、構造化データと半構造化データの両方を問い合せて処理
  • リレーショナル正規化とドキュメント中心の開発の組合せ

マルチモデル・データベースによるネイティブ・ドキュメント・ストアAPIのサポート

これらのマルチモデル・データベースはすべて、JSONデータをネイティブに格納し、最適化するためのバイナリ形式を導入しました。これには、OracleのOSON形式が含まれます。この形式は、増分更新のパフォーマンスと効率性の調査において、BSONよりも利点があります。

ドキュメントファーストのエクスペリエンスを求める開発者にとって、ベンダーは、MySQLのxDev API、PostgreSQLベースのFerretDB、OracleのDatabase API for MongoDBなど、ネイティブJSONストアを公開するAPIを提供します。これらのAPIは、リレーショナル・インフラストラクチャ上でNoSQL開発のシンプルさを提供します。開発者は、特別な目的のドキュメント・ストア・データベースを必要とせずに、スキーマ・フレキシブルな開発のシンプルさと俊敏性を享受できます。

ただし、SQLとは異なり、ドキュメント・ストアAPIは標準化されておらず、ベンダー固有のままです。共通の基準を定義する努力は進行中ですが、まだ初期段階にあります。

SQLを使用したJSONの問合せ

ネイティブのJSONサポートにより、開発者はドキュメント・コレクションをデータベースのトップクラスの市民として扱うことができます。ANSI SQL/JSON (SQL:2016で導入)を使用すると、値の抽出、配列のネスト解除、ドキュメントのフィルタおよびSQL関数のJSONコンテンツへの適用を行うことができます。これにより、リレーショナル・データと半構造化データが統合言語によって橋渡しされ、分析とレポートのためのSQLの機能を活用できるようになります。

次に、映画のJSONコレクションを問い合せ、属性を抽出し、年間総収益を集計し、各年の収益配分を計算する例を示します:

WITH revenue AS (

   SELECT   
      m.data.year
      , round(sum(JSON_VALUE(data,'$.gross' RETURNING NUMBER NULL ON ERROR NULL ON EMPTY ))/1000000) as millions
   FROM movies m
   WHERE m.data.gross IS NOT NULL
   GROUP BY m.data.year
)
SELECT year

      , millions
      , ROUND((RATIO_TO_REPORT(millions) OVER ())*100,2) pct_revenue

FROM revenue r
WHERE year > 2000
ORDER BY year DESC;

 

この例では、ANSI SQL/JSON演算子JSON_VALUEとOracleの簡易ドット表記法の両方を使用します。これは、JSONドキュメント(m.data.year)からJSONスカラー値を抽出する簡単なSQLスタイルの方法です。

開発者は、JSONドキュメントに格納されている属性を抽出および”リレーショナル化”し、この情報をリレーショナル表に結合し、ネストされた副問合せまたはその他の構造を使用します。これは、リレーショナル・オブジェクトで使用可能なSQL演算子または関数を使用する場合と同じです。

JSONドキュメントとしてのリレーショナル・データの公開

逆に、リレーショナル・データはJSONコレクション・ビューを使用してJSONドキュメントとして公開できるため、ドキュメント中心のアプリケーションからアクセスできます。次の例では、OracleのEMP表にJSONコレクション・ビューを作成します。これは、デモンストレーションの目的で最初に作成されたリレーショナル表の1つです:

CREATE OR REPLACE JSON COLLECTION VIEW emp_collection AS
   SELECT
      JSON{‘_id’ : empno,
           ’employeeName’ : ename,
           ‘jobRole’ : job}
     FROM emp;

ドキュメント・ストアAPIでこのコレクション・ビューを使用すると、次のようなデータが返されます

 

json> db.emp_collection.findOne()

 

{ _id: 7369, employeName: ‘SMITH’, jobRole: ‘CLERK’ }

 

この双方向の柔軟性により、SQLとNoSQLの間の境界が曖昧になり、データの格納方法からデータの処理方法が分離されます。

デュアル・アクセスを超えて: JSONリレーショナル二面性

ネイティブのバイナリJSONストレージ、ドキュメントAPI、SQL/JSON機能は大きな進歩を遂げていますが、JSONリレーショナル二面性はさらに一歩進んでいます。この新機能は、どちらかのモデルのトレードオフなしで、リレーショナル・ドキュメントとJSONドキュメントの両方を最大限に活用します。

つまり、二面性ビューは、リレーショナル構造とJSON構造を使用して、JSONドキュメントを非常に効率的な正規化された形式で内部的に格納します。同時に、開発者はJSONドキュメントと対話します。

JSON duality views

二面性ビュー – 行として格納、ドキュメントとして公開

アプリケーションでREST APIを使用するか、ドキュメント中心のAPIを使用するかに関係なく、開発者は、単一のアプリケーション層オブジェクト(JSONドキュメント)に必要なすべてのデータを簡単に取得して操作できます。JSON二面性ビューの作成は非常に簡単です。開発者は、JSONコレクション・ビューと同様に、ビジネス・オブジェクトのオブジェクト・ドキュメント・モデルをデータベースのメタデータとして定義します。

GraphQLを使用して会議スケジュールをモデル化する二面性ビューを定義する簡単な例を次に示します。スケジュール・オブジェクトは、次のもので構成されます:

スケジュール・オブジェクトは、次のもので構成されます:

  • 出席者情報
  • 個々の出席者のスケジュール
  • スケジュールは、参加者が参加する予定の1つ以上のセッションを表します
  • セッションに関する詳細情報(講演者情報を含む)

 

create or replace JSON Duality view ScheduleV
AS
attendee 
{ _id : aid name : aname
  schedule : schedule @insert @update @delete
       { scheduleId : schedule_id
         sessions @unnest
                   { sessionId : sid
                     name : name
                     location : room
                     speaker @unnest
                              { speakerId : sid
                                speaker : name
                                }
                        } 
            }
} ;

したがって、JSONリレーショナル二面性は、リレーショナル・モデルのストレージ、一貫性および効率性のメリットを提供し、アプリケーションは深くネストされたJSON構造を取得および操作します。

両方の世界のベスト

SQLとNoSQLのコンバージェンスにより、開発者はJSONドキュメント開発のシンプルさと、単一のデータベースを使用したリレーショナル・データベースのパワーを利用できます。マルチモデル・データベースでは、単一目的のNoSQLデータベース・システム市場を引き継いで、別のパラダイムよりも1つのパラダイムを選択する必要がなくなります。開発者は、SQLシステムとNoSQLシステムのどちらかを選択し、1つのプログラミング・パラダイムにロックする必要はありません。柔軟性と自由性を享受し、機能を犠牲にすることなく、個々のアプリケーションに最適なアプローチを選ぶことができます。

OracleのJSONリレーショナル二面性ビューは、リレーショナル・モデルとドキュメント・モデルの長所を統合アーキテクチャに融合することで、共存を超えるものです。マルチモデル・システムが進化し続ける中で、このアプローチは説得力のある先例を定めています。他もそれに続くでしょう。

このブログ記事は、もともと https://thenewstack.io/to-sql-or-not-to-sql-that-is-not-the-question/ に掲載されました。