Oracle AI DB 26aiの進化と、Spannerの設計から読み解くRDBMS進化論

RDBMSは、SQLとACIDトランザクションを基盤に、エンタープライズで広く使われています。一方で、クラウド時代ではデータ量やグローバルアクセスの増加に対応するため、水平スケーラビリティが求められ、NewSQLの特徴を取り入れる動きが加速しています。この記事では、分散データベースの技術を基に、Oracle AI Database 26aiの進化、Google Cloud Spannerの設計思想、両者の共通点、MySQL/PostgreSQLの分散対応を解説します。さらに、RDBMSがNewSQLに進化できるかを考察します。

はじめに

RDBMSは、SQLによるデータ管理とACID（Atomicity, Consistency, Isolation, Durability）による信頼性で知られています。従来は単一サーバーでの垂直スケーリングが主流でしたが、クラウド時代では水平スケーラビリティが求められます。NewSQLは、RDBMSのSQLとACIDを維持しつつ、NoSQLの分散処理を融合したデータベースです。たとえば、Google Cloud Spannerはグローバルな分散処理と強一貫性を実現¹し、CockroachDBはマルチクラウド対応を重視します²。

AIワークロードの増加により、大量データの処理を効率化する必要性が高まっています³。分散システムはデータを複数サーバーに分割し、並行処理で高速化とコスト削減を実現します⁴。以下では、これらの技術を初心者にも分かりやすく解説し、RDBMSの進化を探ります。

分散データベースの基礎

クラウド時代では、データ量やグローバルアクセスの増加に対応するため、分散データベースが注目されています。この章では、シャーディングや同期手法を解説し、Oracle 26aiやSpannerの仕組みを明らかにします。

シャーディング

シャーディングは、データを複数のサーバー（シャード）に分割して保存する仕組みです。たとえば、大量の顧客データを1台で処理すると遅延が発生します。そこで地域やIDで分割し、並行処理することでスケーラビリティと負荷分散が可能になります。OracleやSpannerは、キー値に基づく水平シャーディングを採用しています。

2相コミット

2相コミット（2PC）は、分散システムでトランザクションを同期する手法です。準備フェーズで各サーバーにコミット可能性を確認し、全サーバーが「OK」なら次へ進みます。コミットフェーズでは、全サーバーがOKならコミット、1つでもNGならロールバックします。信頼性は高いものの、通信遅延でレイテンシが増加し、1台の障害で全体が停止するリスクがあります。

分散同期の手法

分散システムでは、データ同期が重要です。代表的な手法は以下の2つです。

• Raft：リーダーを選出し、データをコピーするシンプルな手法。運用が容易です⁵
• Paxos：過半数のサーバーが同意することで、データの一貫性と耐障害性を確保。SpannerはTabletのレプリカをmulti-Paxosで同期します¹

これらの技術を基に、Oracle 26aiやSpannerは高度な分散処理を実現しています。

Oracle AI Database 26aiの進化

Oracle 23aiでは静的シャーディングと手動管理が必要でしたが、26ai（2025年10月リリース、23aiの機能を継承・拡張）では動的マッピングや自動スケーリングが導入され、運用効率が向上しました⁶。主な強化点を以下に示します。

主な強化点

26aiでは、以下の4つの機能が強化されました。

Raftレプリケーションでは、Paxosから移行することでゼロデータロスと3秒未満の自動フェイルオーバーが可能になりました⁵。高可用性が大幅に向上しています。

Directory-Based分布は、DBMS_SHARDING_DIRECTORYパッケージを使ってシャードキーを動的管理します⁷。キーの追加・削除、パーティション分割、自動割り当てルール（ラウンドロビン、ランダム等）を設定できます。

ラウンドロビン
データを各シャードに順番に割り当てる負荷分散方式です。たとえば、シャードA、B、Cがある場合、1件目はA、2件目はB、3件目はC、4件目は再びAというように順次割り当てます。各シャードに均等にデータを分散できるため、負荷が特定のシャードに集中するのを防ぎます。

自動リシャーディングは、システム管理型シャーディングによってチャンク（データの塊）を自動再配布します⁸。シャード追加・削除時にデータを自動的に再バランスし、チャンク移動中も数秒の読み取り専用期間のみで運用できます。

AI機能統合では、AI Vector Searchをシャーディングと統合しています⁹。金融分析やeコマースの推奨分析を効率化できます。

Raft採用の背景

Oracleは23aiのPaxosから26aiでRaftに移行しました。Paxosは強固ですが複雑で、実装やデバッグが困難です。Raftはリーダーとフォロワーの役割を明確化し、プロトコルの理解しやすさと運用の明確さに優れています¹⁰。Oracleの公式資料では、Raftにより運用負荷の軽減と開発効率の向上が図られたとされています⁵。

一貫性保証と性能のバランス

Raftレプリケーションでは、トランザクションのコミット記録がリーダーと過半数のフォロワーによって同期的にログに書き込まれることで、ゼロデータロスを保証します⁵。分散システムの一般的な実装では、コミットログの同期書き込みで耐久性を確保しつつ、データ適用をバックグラウンドで処理することでレイテンシを最小化します。この設計により、耐久性と実用的な性能が両立されます。

アーキテクチャ上の制約
Oracle Globally Distributed DatabaseにおけるRaftレプリケーションは、データシャードの高可用性確保に利用されますが、メタデータを管理するカタログDBの高可用性（HA）には対応していません。カタログDBのHAを確保するには、引き続きOracle Data Guardを別途構成する必要があります。

利用シーン

Oracle 26aiは、グローバルERPでの複数地域の金融データ効率処理に適しています。また、ベクター検索によるリアルタイム顧客分析（例：eコマース推奨）など、AI駆動分析でも活用できます。

図1 Oracle 26aiのシャーディングアーキテクチャ

Google Cloud Spannerの設計思想

Spannerの内部実装（TrueTime、Paxos、Tablet）は2012年に初回発表され、2013年に正式発行された論文に基づいています¹¹。現在のアーキテクチャと異なる可能性があるため、最新情報は公式ドキュメントを確認してください¹²

Spannerは、Google CloudのNewSQLデータベースで、グローバル分散、外部整合性（linearizability）、ACIDトランザクションが特徴です¹¹²。

外部整合性とは

外部整合性は、トランザクションが実際の時間順序に従って実行されることを保証します。たとえば、トランザクションT1がT2より時間的に前（$t_1 < t_2$）なら、T1が先に完了します。これにより、時計のずれや通信遅延による順序の乱れを防ぎます。SpannerはTrueTimeとPaxosを組み合わせ、低コストで外部整合性を実現します¹。

グローバル分散とACIDの両立

グローバル分散環境でACIDを保証する際、クロック同期の不確実性が課題です。時計のずれにより、トランザクションの順序が乱れ、データの一貫性が損なわれる可能性があります。たとえば、ニューヨークと東京で同時に入金処理を行うと、順序が不明確になる場合があります。2PCは信頼性が高い一方、通信遅延でレイテンシが増大します。図2に示すように、クロックずれがあると、トランザクションT1とT2が誤った順序でコミットされるリスクがあります。SpannerはTrueTime API（GPSと原子時計で時刻同期、不確実性$\varepsilon$は99パーセンタイルで1ms未満¹³）を使用し、コミット待機（$2\varepsilon$）で順序矛盾を回避。グローバル分散環境でも低レイテンシで外部整合性を確保します¹。
このコミット待機は通常数ミリ秒ですが、外部整合性という最高の保証に対するレイテンシペナルティとなります。このトレードオフに対応するため、SpannerはMySQL開発者にも馴染み深い「Repeatable Read」分離レベルをプレビュー機能として導入しています（2025年11月現在¹⁴）。これにより、一部のワークロードでは、レイテンシを最大5倍改善できる柔軟性を提供しています。

パフォーマンスデータは推定値を含むため、詳細は公式ドキュメントを確認してください

図2 TrueTimeによるクロックずれの解決

設計思想

Spannerの設計思想は、グローバル分散、TrueTime API、自動シャーディングの3つの柱で支えられています。

グローバル分散では、複数地域にデータを分散配置し、Google Cloudのグローバルインフラを活用して低レイテンシでのアクセスを可能にします。

TrueTime APIは、時刻$t$と不確実性$[t - \varepsilon, t + \varepsilon]$を提供します¹。コミット待機によって外部整合性を確保します。

自動シャーディングでは、データをTablet（キー範囲の分割単位）に分割し、各TabletをPaxosで3から5つのレプリカにレプリケーションします^1121315。

Tablet
Spannerのデータ分割単位です。キー範囲で分割し、Paxosで同期します。負荷に応じて自動再配置されます¹²。

利用シーン

Spannerは、Google Adsでのリアルタイム広告配信などのグローバルSaaSに適しています。また、複数地域の送金処理で一貫性を確保する必要がある金融システムでも活用されています。

図3 TrueTimeによるトランザクション順序保証

図4 Spannerの外部整合性アーキテクチャ

Oracle 26aiとSpannerの比較

クラウド需要により、RDBMSとNewSQLの境界が曖昧になっています。Oracle 26aiとSpannerの共通点と違いを比較します。

共通点

シャーディングの面では、OracleがDirectory-Basedで動的管理する¹⁶一方、SpannerはTabletで自動分割します¹²。両者ともスケールアウトに対応しています。

分散同期については、OracleがRaftを採用し、SpannerはPaxosとTrueTimeで同期します⁵¹。

AI機能では、OracleがAI Vector Searchを提供⁹し、SpannerはBigQuery/Vertex AIと統合することで、分散データ分析を強化しています¹⁷。

違い

設計思想が大きく異なります。Oracleはエンタープライズ向けで、PL/SQLやハイブリッド運用を重視しています⁶。一方、SpannerはクラウドネイティブでTrueTimeに依存した設計¹です。

一貫性モデルでは、Spannerが外部整合性を保証します¹。一方、Oracleは強力な整合性（Strong Consistency）を提供し⁵、Serializableトランザクション分離レベルで高い一貫性を実現します。

パフォーマンスの最適化方針も異なります。Spannerはグローバル分散環境で低レイテンシを追求¹し、Oracleはリージョン内での高速処理に最適化されています⁶。

利用シーンの比較

システム	用途	例
Oracle 26ai	グローバルERP、AI分析	金融の分散トランザクション、eコマース推奨
Spanner	グローバルSaaS、金融	Google Ads、リアルタイム送金

OSSのNewSQL化と課題

MySQLやPostgreSQLも分散機能を強化し、NewSQLに近づいています。CockroachDBやTiDBと比較し、動向と課題を解説します。

MySQLの分散対応

MySQLは、HeatWaveによる自動シャーディングとスケールアウト（AWS/Google Cloud/OCI）を提供しています¹⁸。Vector StoreでAIにも対応しました。Group ReplicationはPaxosベースの合意形成による同期レプリケーションで高可用性を実現し、リージョン内のスケーラビリティに特化しています¹⁹。

eコマースの注文データ分散などに利用できますが、Spannerに比べるとグローバル一貫性が弱く、グローバル分散環境でのレイテンシが高い傾向があります¹⁸。

PostgreSQLの分散対応

PostgreSQLは、Citusによる分散クエリとシャーディングを提供しています²⁰。pgvectorでベクター検索もサポートします²¹。クラウド版としては、AWS AuroraやAzure Cosmos DBが自動スケーリングに対応しています。

IoTデータのリアルタイム集計などに活用できます。ただし、Citusはすべての分散トランザクションではなく、共有メタデータを含む参照テーブルの変更時に主に2PCを適用することで強一貫性を確保し、スケーラビリティとのバランスを取っています²²。広範囲に2PCを適用した場合のオーバーヘッドは依然として課題です。

NewSQLとの比較

CockroachDBはPostgreSQL互換で、Raftベースの分散一貫性を備えています²。Geo-Partitioningによる地域最適化が特徴です。TiDBはMySQL互換で、Paxosベースです²³。Spannerに近い設計ですが、TrueTimeはありません。

MySQL/PostgreSQLもNewSQL化を進めています。MySQLは、HeatWave自動シャーディング、Group Replication、Vector Storeを既にリリース済みで、9.x系Innovation releasesで継続的に機能強化中です。PostgreSQLは、Citus分散クエリ、pgvectorを提供済みで、19（2026年9月予定）で分散機能の改善が計画されています²⁴²⁵²⁶。ただし、Spannerの外部整合性レベルには達していません。

コミュニティ駆動の開発速度の課題

MySQLとPostgreSQLはコミュニティ主導のため、商用DB（Oracle、Spanner）に比べて開発速度が遅くなっています。MySQLはLTS版として8.0（2018年）から8.4（2024年）まで約6年を要し、LTS版間のリリースサイクルが長期化しています。PostgreSQLは年1回のメジャーアップデート（18は2025年9月）を維持していますが、Oracle（四半期リリース²⁷）やSpanner（頻繁なアップデート）に比べると、機能統合に時間がかかります²⁴²⁵。

商用DBと異なり、機能追加にはコミュニティ全体の合意が必要なため、開発速度が制約されています。

今後の展望と考察

クラウドネイティブ（Kubernetes）やAI統合（生成AI、データレイク）の進化により、RDBMSはNewSQLの特徴を吸収しています。Oracle AI Databaseはこれまで述べてきた機能の他にも、Apache Icebergを活用してデータレイクとの統合を進め、MySQL HeatWaveはAutoMLでAI機能を強化しています。一方、SpannerはTrueTimeで外部整合性を確保し、グローバルな低レイテンシを実現します。しかし、Spannerの外部整合性はTrueTime依存で現状のRDBMSでは再現が困難です。MySQLやPostgreSQLもCitusやHeatWaveで分散処理やAIを強化していますが、Spannerのグローバル一貫性には追いついていません。RDBMSとNewSQLの特性やユースケースを踏まえ、用途に最適なデータベースを選択することが現実的です。本記事が、データベース選定の参考になれば幸いです。

Apache Icebergとは：Apache Icebergは、データレイクをSQLテーブルライクに管理するオープンソースのフォーマット。ACIDトランザクションをサポートし、Oracle Databaseで効率的なデータレイククエリを実現²⁸²⁹

AutoMLとは：MySQL HeatWaveのAutoMLは、モデル構築を自動化。異常検知や予測を効率化し、データベース内でAIを活用可能³⁰³¹

1. Spanner: Google's Globally Distributed Database ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹

2. Multi-Region, Multi-Cloud Deployments ↩ ↩²

3. Train Models Using a Distributed Training Workload ↩

4. 分散コンピューティングとは何ですか? ↩

5. Using Raft Replication in Oracle Globally Distributed Database ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

6. Oracle AI Database 26ai: Feature Highlights ↩ ↩² ↩³

7. DBMS_SHARDING_DIRECTORY Package Reference ↩

8. Chunk Management - Oracle Globally Distributed AI Database ↩

9. 分散データベースでのOracle AI Vector Search ↩ ↩²

10. Raft Consensus Algorithm ↩

11. Spanner: Google's Globally-Distributed Database | USENIX ↩

12. Google Cloud Spanner Documentation ↩ ↩² ↩³ ↩⁴ ↩⁵

13. Strict Serializability and External Consistency in Spanner | Google Cloud Blog ↩ ↩²

14. Repeatable Read 分離を使用する ↩

15. レプリケーション ↩

16. Deploying and Managing a Directory-Based Oracle Globally Distributed Database ↩

17. Spanner Vertex AI インテグレーションの概要 ↩

18. MySQL HeatWave User Guide ↩ ↩²

19. MySQL Group Replication Overview ↩

20. Citus Documentation ↩

21. pgvector Extension for PostgreSQL ↩

22. Creating and Modifying Distributed Objects (DDL) ↩

23. TiDB Documentation ↩

24. MySQL Releases: Innovation and LTS ↩ ↩²

25. PostgreSQL Release Policy ↩ ↩²

26. PostgreSQL Roadmap ↩

27. Critical Patch Updates, Security Alerts and Bulletins ↩

28. Apache Iceberg とは何ですか? ↩

29. Apache Iceberg Explained: A Complete Guide for Beginners | DataCamp ↩

30. MySQL HeatWave AutoML ↩

31. Automate Machine Learning with MySQL HeatWave AutoML | Oracle ↩