「分散型データベースはアーキテクチャとして優れているが、とにかくコストが高い」このような言葉を、一度は耳にしたことがあるのではないでしょうか。
特にストレージ面では、分散型データベースには避けられない制約があるように思われがちです。強い一貫性を担保するためには、最低でも3つのレプリカが必要であり、1TBの業務データがあれば、スタート時点で3TBのストレージ容量が必要になります。多くのチームがMySQLから分散型データベースへ移行した後、ストレージコストが下がるどころか大きく増えてしまうケースも決して珍しくありません。
しかし、ここで一つ疑問が浮かびます。
分散型データベースは、本当に「必ず高い」のでしょうか。
この記事では、技術的な原理とコスト計算のロジックに絞ってこの問題を整理します。最後まで読んでいただければ、「分散型データベースが高いのではなく、データ特性に合わせた圧縮アーキテクチャを持たない場合に高くなりやすい」ということが見えてくるはずです。
OceanBaseでは、データ特性やワークロードによって差はありますが、「2段階圧縮アーキテクチャ」により、同じ業務データに対するストレージ使用量をMySQLの1/4程度まで削減できます。仮に3レプリカを保持したとしても、総ストレージコストは従来のシングルレプリカ構成を下回る可能性があります。
一、分散型データベースが抱える「ストレージコスト」のジレンマ
まずは、コストの考え方から整理してみましょう。
1.1 継続的なデータ増加への対応
オーダー、ログ、トランザクション履歴、ユーザー行動データ――企業のデータ量は増え続ける一方です。中規模のプラットフォームであっても、データベースの年間増加量が数十TBに達することは珍しくありません。さらに厄介なのは、従来型データベースそのものが「ストレージを大量に消費しやすい」構造を持っていることです。
● データの膨張：MySQLのB+Treeストレージエンジンでは、1TBの論理データをディスクに書き込むと、インデックス、フラグメンテーション（断片化）、ページフィルファクター、UNDO/REDOログなどの影響により、実際の消費量が3〜4TBに膨らむことがあります。
● スケールアウトの悩み：ディスク容量が逼迫した場合、ストレージを追加する（コスト増）、シャーディングを行う（複雑性増）、あるいはコールドデータをアーカイブする（クエリ性能低下）といった、いずれも簡単ではない選択を迫られます。
● コールドデータのジレンマ：過去データはアクセス頻度が低いにもかかわらず、高価なストレージを占有し続けます。削除するわけにもいかず、そのまま保持し続けるにはコスト負担が大きくなります。
1.2 分散型データベースにおける「×3」のストレージ負荷
強い一貫性と高可用性を確保するために、分散型データベースはコンセンサスプロトコルを用いてデータの信頼性を保証しており、データは最低でも3つのレプリカとして保存されます。TiDBやCockroachDBはRaftプロトコルを採用し、OceanBaseやGoogle SpannerはPaxosプロトコルを採用しています。どちらを採用する場合でも、3レプリカという前提自体はアーキテクチャ上ほぼ避けられません。
| 比較項目 | シングルノードMySQL | 分散型データベース （3レプリカ） |
|---|---|---|
| レプリカ数 | 1（+ オプションでPrimary/Standby構成） | 3（強い一貫性の要件） |
| ストレージオーバーヘッド | 1x | 最低 3x |
| 圧縮能力 | B+Treeは圧縮可能だが性能劣化に注意が必要 | ？ |
つまり、1TBの業務データがMySQL上で3TBに膨張している場合、それを分散型データベースに移行すると、3TB × 3レプリカ = 9TB となり、ストレージコストは大きく増加する可能性があります。
1.3 別の観点から考えてみると：もし「3レプリカの容量」が「MySQLの1レプリカ」より小さかったら？
ここで鍵になるのが、圧縮（Compression）です。
もし分散型データベースが1TBの業務データを0.25TBまで圧縮できるとしたら、3レプリカの総ストレージ容量は 0.25TB × 3 = 0.75TB になります。これは、MySQLのシングルレプリカが3TBを消費するケースと比べて、75%小さい計算です。
これは単なる理論上の話ではありません。OceanBaseでは、2段階圧縮技術によって、理想的な条件下で70%〜90%のストレージコスト削減が可能です（実際の効果はデータ型や業務シナリオに依存します）。
分散型データベースは、レプリカ数だけを見るとストレージ面で「割高」に見えます。しかし、その増加分を相殺できるほど強力な圧縮能力を備えていれば、シングルノードデータベースの1レプリカよりも低コストに抑えることも可能です。
二、OceanBaseの2段階圧縮アプローチ：ストレージ容量を1/4に削減する仕組み
2.1 結論
● 同一の業務データに対して、OceanBaseのストレージ使用量はMySQL/Oracleの1/4〜1/3に収まります。
● 3レプリカを構成しても、実際のストレージコストは従来型データベースより低く抑えられる可能性があります。
● アプリケーションからは透過的に利用でき、書き込み・クエリ性能の犠牲を最小限に抑えられます。
2.2 従来型データベースが抱えるB+Tree圧縮のジレンマ
MySQLやOracleが採用するB+Treeストレージエンジンには、圧縮アーキテクチャにおいて構造的な課題が存在します。
● 固定長データページ：B+Treeは、通常16KBなどの固定サイズのページ単位でデータを管理します。圧縮によってデータサイズが小さくなっても、ページ自体の物理サイズは変わらないため、ページ内に空洞が生じやすく、結果としてスペース効率が悪化しがちです。
● インプレース更新（In-Place Update）による書き込み増幅：1行のデータを更新する場合、データページをその場で書き換える必要があります。ページが圧縮されていると、「解凍 → 更新 → 再圧縮」という処理サイクルが要求され、深刻なライトアンプリフィケーション（書き込み増幅）を引き起こします。
● パフォーマンスとのトレードオフ：MySQLの公式ドキュメントでも、InnoDBのページ圧縮は慎重に利用すべきとされています。例えば初期の実装では、Buffer Pool内に圧縮ページと非圧縮ページの両方が同時にキャッシュされ、逆にメモリ効率を落としてしまうといった課題も存在しました。
● フラグメンテーションの蓄積：圧縮ページに対して更新が繰り返されると断片化（フラグメンテーション）が進行しやすくなり、手動での再編成など追加のメンテナンスタスクが必要になります。
そのため、多くのMySQLユーザーにとって実運用における現実的な選択肢は、「パフォーマンス低下や運用コストの増大を避けるため、圧縮を諦めてデータ量の膨張を受け入れる」ことになりがちです。
2.3 従来型DBとは異なるアプローチ
2.3.1 独自の「2段階圧縮」
OceanBaseの圧縮は、単にブロックレベルで「Zipのようにまとめる」わけではなく、データ特性をシステムレベルで理解して最適化する仕組みです。
第1段階：行・列ハイブリッドエンコーディング（Encoding）
マイクロブロック（通常約16KB）の内部では、PAX（行・列ハイブリッドストレージ）フォーマットを採用しています。論理的には行単位で構成しつつ、物理的には列単位でエンコードして保存します。これにより、同じ列に含まれるデータ型や値の分布といった特徴を利用し、最適なエンコーディングアルゴリズムを選択できます。
| アルゴリズム | 圧縮の原理 | 主な適用シナリオ |
|---|---|---|
| 辞書エンコーディング/RLE | 重複を排除し、参照やランレングスで保存 | 性別、都市、製品カテゴリなど |
| Bit-packing/HEX | ビット幅を削減し、より少ないビット数で表現 | ステータスフラグ、Enum値など |
| 差分エンコーディング | 最小値と各行との差分のみを保存 | タイムスタンプ、Auto Increment ID、日付 |
| 定長文字列差分エンコーディング | パターン文字列と各行との差分を保存 | 注文番号、身分証番号、URL |
| 列間等価エンコーディング/列間部分文字列エンコーディング | 複数列にまたがる冗長性を排除 | 都道府県・市区町村コード、プレフィックス付きの複合ID |
ポイントは、エンコーディング処理がコンパクション時に実行されるため、フロントの書き込み処理と完全に分離されていることです。最適な戦略はシステムが自動的に選択します。
第2段階：汎用圧縮（Compression）――データ形式に依存しない二次圧縮
行・列エンコーディングの後、マイクロブロック全体に対して汎用圧縮を行います。
● zlib / snappy / lz4 / zstd の4種類のアルゴリズムをサポートしており、DDLによってテーブル単位で設定可能
● エンコーディング後のデータに対してさらに汎用圧縮を適用するため、両者を組み合わせることで、より高い圧縮率を実現
● デフォルト推奨は zstd。zlib と同等の圧縮率を維持しながら、より高速な処理性能を提供
● 解凍処理は非同期I/Oスレッドで実行され、Read-Ahead や Block Cache と連携することで、クエリ性能への影響を最小限に抑制
この2段階圧縮を組み合わせることで、第1段階のエンコーディングで通常は元データサイズの 12〜28% まで縮小し、第2段階の汎用圧縮でさらに 10〜30% の削減が可能です。最終的な保存容量は、元データの 約1/4〜1/3 にまで抑えることができます。
2.3.2 LSM-Treeアーキテクチャ上の特徴
OceanBaseが高い圧縮率を実現できるのは、エンコーディングアルゴリズムの優秀さだけでなく、ベースとなるLSM-Treeアーキテクチャが根底から圧縮を可能にしているためです。
● 書き込みと圧縮の分離：データはまずメモリ上のMemTableに書き込まれるため、書き込みパス上での圧縮オーバーヘッドはゼロです。圧縮処理はバックグラウンドのコンパクション（Compaction）時に行われるため、オンラインのトランザクション処理性能に影響を与えません。
● SSTableのRead-Only特性：一度生成されたベースラインデータは変更（更新）されないため、更新時のオーバーヘッドを気にすることなく、よりアグレッシブな圧縮アルゴリズムを採用できます。また、書き込みによってキャッシュが失効（無効化）されることもありません。
● 可変長データブロック：マイクロブロックは可変長データブロック（通常16KB）として管理され、隙間なく密に配置されるためフラグメンテーションが発生しません。従来型データベースの定長データページで起こりやすい「圧縮による空洞・無駄なスペース」を構造的に回避できます。
● 適応的エンコーディングとバッチ最適化：ディスクへのバッチ書き込み時に連続して圧縮を行う際、直前のデータブロックの圧縮実績から得られる「先験的知識（事前情報）」を利用して、次のブロックの圧縮を最適化します。さらに、最適なエンコーディングを適応的に自動判定し、複数のエンコーディングの重ねがけをサポートすることで、単純な圧縮率の加算以上の効果を実現します。
● レプリカごとの段階的なマージ処理：アクセス集中と重い圧縮処理のピーク時間帯をずらす（オフピーク化する）ことで、業務の閑散時間帯に複雑な圧縮を実行します。マルチレプリカ構成を活かし、マージ処理中のZoneはデータデコード・エンコード処理にリソースを全力で集中させることができ、オンライン業務に対して影響を与えません。
【B+Treeとのトレードオフ比較】
B+Treeアーキテクチャを採用する従来型データベースでは、圧縮データを更新する際に「ページ全体の再書き込み」が必要になり、ランダム書き込みのライトアンプリフィケーションが顕著になります。MySQLの初期バージョンにおいてBuffer Pool内に圧縮ページと非圧縮ページの両方が同時に存在してしまった課題のように、B+Treeでは「圧縮と性能がトレードオフ」になりがちです。LSM-Treeでは、書き込みパスと圧縮処理を分離できるため、B+Tree系アーキテクチャと比較すると、高圧縮率と性能の両立を図りやすい構造と言えます。
2.4 クエリ性能への影響を抑え、さらに向上させる仕組み
圧縮技術の導入にあたり、「データが圧縮されるとクエリ性能が落ちるのではないか」と懸念するエンジニアは少なくありません。OceanBaseの設計において、この懸念は当てはまりません。
● 行レベルのランダムアクセス：エンコード済みデータは行単位のランダムアクセスをサポートしています。ターゲットとなる行だけをデコードすればよく、データブロック全体を解凍する必要がありません。これはOceanBaseのエンコーディング形式における重要な設計であり、ブロック全体の解凍が必須となる一般的な汎用圧縮とは一線を画す特長です。
● キャッシュされたデコーダー：各エンコード済みブロックに対応するデコーダー（デコード処理用モジュール）は、データブロックとともにBlock Cacheにキャッシュされます。これらは非同期I/Oスレッドによってバックグラウンドで事前構築されるため、繰り返しアクセス時のデコードオーバーヘッドは完全にゼロになります。これにより、「圧縮されたデータの方が、非圧縮データよりも高速にクエリを実行できる」という逆転現象を可能にしています。
● 演算のプッシュダウン：フィルタリングや集計処理は、エンコード済みデータに対して直接実行可能です。デコード処理を行うことなく、辞書メタデータ、Null Bitmap、定数などのメタデータを活用してクエリを加速します。たとえば COUNT クエリは、実データをスキャンせずに辞書メタデータのみを読み取って瞬時に結果を返すことができます。
● ベクタライズド実行：エンコードデータの行・列ハイブリッドフォーマットは列指向の性質を備えているため、SIMD命令を活用したベクタライズド（ベクトル化）バッチデコードおよび実行に非常に適しており、分析系クエリの性能を大きく向上させます。
OceanBaseにおいて、圧縮技術は「ストレージコスト削減のために性能を犠牲にする」ものではありません。コストを削減しながら、同時にクエリパフォーマンスをも高める、ストレージ効率と性能の両立を意図した設計となっています。
三、単なる圧縮に留まらない：包括的なコスト最適化機能
3.1 データとログの分離：さらに20%〜40%のコスト削減
従来アーキテクチャのストレージ課題：
従来の分散型データベースでは、各データノードがデータのコピーを完全に保持する（ユーザーデータ、CLOG、SLOGのそれぞれを3つずつ持つ）必要があり、これがストレージコストが単体データの3倍に増加する直接的な原因になっていました。
OceanBaseは、アーキテクチャの工夫により、ログ（CLOG）とユーザーデータを完全に分離することでこの課題を解決しています。
- 独立したログサービス：CLOGは、独立した分散ログサービス（LogService）によって提供されます。このサービス自体は3レプリカで独立してデプロイされ、複数のコンピュートノードクラスタ間で共有されます。これにより、コンピュートノードの規模がどれだけ拡大しても、ログのコピー数は「Nノード × 3」に膨らむことなく、常に3つに保たれます
- 柔軟なレプリカ戦略：この新アーキテクチャでは、コンピュートノード側でより経済的なシングルレプリカ戦略を採用できます。具体的には、SYSテナントのみがDR（ディザスタリカバリ）管理のために3レプリカを保持し、一般の業務テナントはシングルレプリカを利用するといった柔軟な運用が可能です
このデータとログの分離により、高い可用性を確保しつつ、ユーザーデータのストレージコストをさらに20%〜40%削減することができます
3.2 フラグメンテーションの解消：コンパクションによる自動整理
従来のB+Treeデータベースでは、頻繁な更新や削除によって大量のフラグメンテーションが発生し、手動で OPTIMIZE TABLE を実行してテーブルを再構築する必要がありました。これは運用コストが高く、オンライン業務への影響も無視できません。一方、LSM-Treeアーキテクチャを持つOceanBaseでは、この問題を構造的に回避できます。
● 自動デフラグ：定期的なコンパクション（Compaction）メカニズムにより、データは順序付けられたコンパクトな形式へ再編成されます。更新や削除による断片化が自動的に解消されるため、手動でのメンテナンスは不要です。
● 削除領域の自動回収：更新・削除操作によって生じた離散的な論理削除マークは、Major Compactionの過程で自動的にクリーンアップされ、物理ストレージ領域が回収されます。
● キューイングテーブル（Queuing Table）のインテリジェント最適化：頻繁なInsert/Deleteが発生するテーブルでは、物理行数が急増し、ユーザーが認識する論理行数との乖離によってReadオーバーヘッドが拡大することがあります。OceanBaseの適応型コンパクションは、このようなキューイングテーブルを自動的に検知して特別なクリーンアップをトリガーし、物理行数を論理行数に近い適正な水準に保ちます。
3.3 カラムナーストレージの導入：APシナリオにおける圧縮率と性能の向上
OceanBase 4.3からはカラムナー（列指向）ストレージエンジンが導入され、分析（AP）シナリオにおける圧縮率とクエリ性能がさらに強化されました。
● フルカラムナーテーブル：データは列ごとに独立して保存・エンコード・圧縮されます。デフォルトで列レベルのSkip Index（事前集計インデックス）が作成されるため、分析クエリにおける圧縮率とパフォーマンスの双方が向上します。
● 行・列冗長テーブル：ベースラインデータを行指向と列指向の両方のフォーマットで保持します。TPクエリは行指向パス、APクエリは列指向パスを利用することで、1つのデータベースでHTAP（TP/AP混在）ワークロードに対応できます。
● カラムナーレプリカ：行指向テーブルに対して、独立した列指向のレプリカを作成できます。APクエリはルーティングポリシーによって列指向レプリカへ振り分けられるため、TPとAPのリソースを物理的に分離することが可能です。
注：カラムナーストレージエンジンはV4.3.0からサポートされています。
3.4 共有ストレージアーキテクチャ：ローカルSSD＋オブジェクトストレージ
OceanBaseは共有ストレージ（Shared Storage）アーキテクチャもサポートしており、ストレージコストを限界まで引き下げる選択肢を提供しています。
● コンピュートとストレージの分離：コンピュートノードとデータストレージを分離し、ベースラインデータをオブジェクトストレージ（OSS/S3など）に永続化しつつ、ホットデータをローカルSSDにキャッシュすることで、真の意味でのコンピュートとストレージの分離を実現します。
● レイテンシとコストのトレードオフ：ホットデータはローカルSSDにキャッシュされるため、アクセスレイテンシは従来アーキテクチャと同等レベルに保たれます。一方、コールドデータはオブジェクトストレージ（レイテンシ80ms〜）に保存されます。キャッシュヒット率が100%であれば遅延のブレはなく、データのCold/Hot切り替え時にのみ一時的な遅延が発生します。コールド/ホットの境界が比較的安定しており、時折のレイテンシ増加を許容できるシナリオに最適です。
● 大幅なコストメリット：TPシナリオでは最大50%のストレージコスト削減が可能です（オブジェクトストレージ側はシングルレプリカでも高い信頼性を確保できます）。APシナリオにおいては、最大90%のコスト削減が期待できます。
注：共有ストレージアーキテクチャはV4.3.4から実験的機能（Experimental）として提供されています。
四、他の分散型データベースとの比較：アーキテクチャによる違い
ここからは、他製品のアーキテクチャとOceanBaseのアプローチの違いを客観的に比較します。
4.1 従来型シングルノードDB（MySQL）との比較
| 比較項目 | MySQL | OceanBase |
|---|---|---|
| ストレージエンジン | B+Tree（固定長データページ） | LSM-Tree（可変長データブロック） |
| 圧縮方式 | 汎用圧縮（InnoDB Page Compression/TPC）。性能への影響が大きい | 2段階圧縮（行・列エンコーディング ＋ 汎用圧縮）。書き込みパスへのオーバーヘッドはゼロ |
| 圧縮率 | 限定的。公式ドキュメントも「慎重な利用」を推奨 | 同一データに対するストレージ使用量はMySQLの1/4〜1/3に縮小 |
| レプリカ構成 | Primary/Standby構成（非同期／半同期）。強一貫性は担保されない | Paxosによる3レプリカ構成で強一貫性を確保 |
| 総ストレージコスト | 非圧縮（単一レプリカでも膨張しやすい） ＝ 高コスト | 「3レプリカ × 高圧縮率」により、従来の単一レプリカ構成のコストを下回る可能性あり |
【コスト試算：1TBの業務データの場合】
● MySQL：ディスク書き込み時約3TBに膨張。Primary-Standby（2レプリカ）構成で計 6TB
● OceanBase：2段階圧縮後に約0.33TB。3レプリカ構成で計 1TB
● 結論：OceanBaseの3レプリカ構成のストレージコストは、依然としてMySQLの1レプリカ（非圧縮・単一ノード）単体のコストを下回ります。
4.2 一般的な分散型データベース（NewSQL）との比較：圧縮アプローチの設計思想の違い
| 比較項目 | 分散型SQLデータベースA社 | OceanBase |
|---|---|---|
| 基盤ストレージエンジン | 汎用的なKVエンジン（ベースとなるOSSや独自開発エンジン等を採用） | 自社開発LSM-Treeエンジン |
| 圧縮方式 | ブロックレベルの汎用圧縮（zstd / lz4など）。データセマンティクスを認識しない | 2段階圧縮（自社開発の行・列エンコーディング ＋ 汎用圧縮） |
| 行・列エンコーディング | なし | 多彩な自社開発エンコーディングアルゴリズムを適応的に自動選択 |
| 圧縮率 | 50%〜70%（汎用ブロック圧縮のみ） | 70%〜90%（行・列エンコーディング ＋ 汎用圧縮の重ねがけ） |
| HTAPストレージ | 行指向ストレージ ＋ 分析用の列指向ストレージ。AP分析処理には追加のレプリカが必要 | 行・列ハイブリッド（PAX）単一レプリカ ＋ オプションの列指向インデックス。AP分析用の追加データ冗長化は原則不要 |
| AP分析に伴う追加ストレージ | 分析用レプリカが追加のストレージ領域を占有 | 行・列ハイブリッドフォーマットが標準でAPクエリをサポートするため、追加レプリカのオーバーヘッドなし |
【コアとなるアーキテクチャの差異】
多くの一般的な分散型データベースの基盤ストレージは、ブロックレベルの汎用圧縮（zstdやlz4など）を適用しています。これはデータのセマンティクス（意味論。例えば、この列は性別［2つの値のみ］、あの列は都市［数十値のみ］といったデータ特性）を認識しないため、列の特性に合わせた最適な圧縮が困難です。近年、オブジェクトストレージ主体の共有ストレージアーキテクチャに進化しているケースもありますが、行レベルのデータ圧縮は依然として汎用ブロック圧縮に依存しており、データベースレイヤーでの高度な列エンコーディング能力を備えていないことが少なくありません。
一方、OceanBaseの行・列ハイブリッドエンコーディングはデータベースレイヤーでデータのセマンティクスを解釈します。性別列には辞書エンコーディング（わずか1ビット）、タイムスタンプ列には差分エンコーディング、都道府県・市区町村コード列には列間等価エンコーディングを適用して複数列にまたがる冗長性を排除します。これは単純な圧縮アルゴリズムの優劣ではなく、ストレージ設計思想の根本的な違いによるものです。
また、従来型のNewSQLで本格的なAP分析を行うには専用の列指向レプリカを追加構成する必要があるケースは多く、これは通常の3レプリカ構成とは別に追加のデータコピーを保持することを意味し、ストレージコストをさらに増大させます。対してOceanBaseのPAXフォーマットは、1つのデータセットでTPとAPを同時に処理できるため、追加の列指向レプリカは原則不要です。ただし、PAXフォーマットは行指向クエリのパフォーマンスに強みを持つ一方、純粋な分析シナリオにおけるクエリ性能はネイティブな列指向に及びません。OceanBaseはこの点を補うため、PAXフォーマットだけに依存するのではなく、オプションとして「列指向レプリカ」や「列指向インデックス」を柔軟に追加できる設計を採用しています。
【コスト試算：1TBの業務データの場合】
● 一般的な分散型SQLデータベース：データ用3レプリカ（圧縮後約1.5〜2TB） ＋ 分析用1レプリカ（列指向約0.5〜1TB） ≒ 計 2〜3TB
● OceanBase：3レプリカ（圧縮後約0.75〜1TB） ≒ 計 0.75〜1TB
● 差分：OceanBaseの実際のストレージ使用量は、一般的な分散型データベースの約3分の1から2分の1に収まります。
4.3 vs クラウドネイティブDB：従量課金モデルにおけるコスト構造
| 比較項目 | 代表的なクラウドネイティブDB | OceanBase |
|---|---|---|
| ストレージモデル | コンピュート／ストレージ分離。共有分散ストレージプール | ローカルストレージ。圧縮後にディスクへ永続化 |
| ストレージ課金 | 実際のデータ量に基づく月額従量課金 | ハードウェア初期費用。圧縮後の実際のディスク占有量に基づく |
| I/O課金 | プランにより個別課金あり（リクエスト回数に応じた課金など） | I/Oに対する個別課金なし |
| 圧縮能力 | 汎用ブロック圧縮（LZ4/ZSTD）。データ特性の認識なし | 2段階圧縮（行・列エンコーディング ＋ 汎用圧縮） |
| データ冗長性 | 3つのAZにまたがる6レプリカ（ユーザーの課金対象は1コピー分、物理ストレージは6x） | Paxosに基づく3レプリカ構成で強一貫性を確保（OceanBaseとSpannerは、少数派であるPaxosを採用する代表的なDB） |
| AP分析能力 | 外部データウェアハウス（DWH）との連携が必要になり、追加コストが発生 | ネイティブHTAP。追加コンポーネントや追加費用は不要 |
ストレージ分離型のクラウドDBでよく見られる「課金対象は1コピー分のみ」というモデルは一見メリットが大きく見えますが、コストの実態を評価する際には以下の点に留意する必要があります。
● 高いストレージ単価：多くのクラウドネイティブDBのストレージ単価は、高度に圧縮された後のデータ量ではなく、論理的な元データ量に基づいて課金されるケースが一般的です。
● I/Oに対する個別課金：利用プランによっては、読み書きのたびにI/O費用が発生します。書き込み頻度の高い（ライトヘビーな）ワークロードでは、I/O費用がストレージ費用を上回ることがあります。
● 膨大な基礎物理ストレージ量：高可用性を担保するためにマルチAZで6レプリカなどを構成するアーキテクチャは極めて高い信頼性を誇りますが、物理的には膨大なデータが書き込まれており、これを相殺できる強力な圧縮技術が不足している傾向があります。
● AP処理における追加コンポーネントの必要性：本格的な分析クエリを実行するには外部DWHサービスとの連携（フェデレーションクエリやETL）が必要になり、データパイプラインの複雑化に加え、追加のストレージや計算（コンピュート）費用が発生します。
これに対し、OceanBaseは2段階圧縮によってデータ量自体をより小さく抑えられるため、3レプリカ構成であっても、実際のディスク占有量はクラウドネイティブDBの「課金対象のデータ量」より遥かに小さくなります。さらに、I/O課金がなく、ネイティブHTAPにより追加コンポーネントも不要なため、トータルの総合ストレージコスト（TCO）を低く抑えることができます。
4.4 比較のまとめ：同じ1TBの業務データで、最終ストレージコストが最も低いのは？
| ソリューション | オリジナルデータ | 圧縮後の単一レプリカ | レプリカ数 | 実際のストレージ占有量 | AP分析における追加コスト | 総合的なストレージコスト |
|---|---|---|---|---|---|---|
| MySQL（単一ノード） | 1TB | 約1TB（非圧縮） | 1＋1（Primary-Standby） | 約2TB | 外部DWHなどが別途必要 | 高 |
| 代表的なクラウドネイティブDB | 1TB | 約1TB（透過的圧縮は限定的） | 6（課金は1コピー分） | GBベースの従量課金 | 外部DWHなどが別途必要 | 中〜高 |
| 一般的な分散型SQLデータベース | 1TB | 約0.5〜0.7TB | 3 | 約1.5〜2.1TB | 専用の分析レプリカが必要 | 中 |
| OceanBase | 1TB | 約0.25〜0.33TB | 3 | 約0.75〜1TB | 追加レプリカ不要 | 最低水準 |
※比較データは公開されているテスト結果や理論分析に基づくものであり、実際のストレージ削減効果はデプロイ環境、スキーマ設計、および実ワークロードによって異なる場合があります。
五、導入事例から見る具体的なコスト削減効果
技術的な仕組みに続き、実際にOceanBaseを導入した企業のデータと運用の変化を解説します。
5.1 A社（Mobility系） —— 全サービス統合によるコスト削減と効率化
抱えていた課題
A社の基幹業務は従来、大規模なシャード分割に依存しており、システム構成が極めて複雑でした。また、多次元クエリの要件を満たすためにElasticsearchやRedisを外付けしてグローバルインデックスを構築する必要があり、アーキテクチャの複雑化に拍車がかかっていました。さらに、独立した多数のRDSインスタンスがサイロ化していたためリソースの効率的な共有ができず、データベースのインフラコストと運用負荷が高止まりしていました。スロークエリの頻発や、ディスクフラグメンテーションの解消作業に追われるDBAの運用管理工数も大きな課題でした。
解決策
シャーディング構成を廃止し、OceanBaseのネイティブ分散機能を適用しました。大規模クラスタにおけるマルチテナント機能を活用して、従来個別に稼働していたMySQLインスタンスを集約。さらに、高いストレージ圧縮率によって保存容量を削減し、高性能なオプティマイザと実行エンジンにより複雑なスロークエリの改善を図りました。
成果（公開事例に基づくデータ）
● ストレージ容量を約80%削減し、データベース全体のコストを30%以上削減。
● 計算（コンピュート）リソースを約50%に抑えつつ、SQLのスループットを20%以上向上。
● テナントの弾性拡張がシームレスに行えるようになり、ノード障害時の自動フェイルオーバー（RPO=0、RTO<30s）を確保。
● 管理コンソールを介した直感的な運用管理、モニタリング、自動分析を実現。
5.2 B社（ソーシャル・動画系サービス）—— 単一クラスタで150TB超の大規模データを安定運用
抱えていた課題
B社の注文データ量は150TBを突破し、従来のMySQL構成ではストレージ容量限界とクエリ性能の劣化が大きな障壁となっていました。容量と性能を確保するためにシャーディング分割を繰り返した結果、オンラインのMySQLシャード（インスタンス数）は300セットを超え、インフラコストおよびアプリケーションのコード改修コストが限界に近づいていました。
解決策
MySQLとの高度な互換性を活かし、既存のビジネスロジックやアプリケーションをほぼ書き換えることなくスムーズな移行を実現。同市内の3つのデータセンターにまたがるアクティブ・アクティブ構成をデプロイし、300以上のMySQL環境を単一のOceanBaseクラスタに統合しました。全体の管理・監視には管理ツール OCP（OceanBase Cloud Platform）を採用しました。
成果（公開事例に基づくデータ）
● ストレージコストを75%削減し、サーバー50台分のリソースを削減。
● データベース間のデータ同期レイテンシを約1/4に短縮。
● 150TBを超える大規模データ環境において、性能と安定した運用品質を担保。
● 拡張・縮退（スケーリング）操作、モニタリング、アラート管理がOCP経由で一元化され、運用負荷を大幅に軽減。
5.3 Trip.com—— 分散型への移行によるスケーラビリティと可用性の強化
抱えていた課題
Trip.comのIMサービスのグループメッセージデータは、わずか2ヶ月で800GBに達し、従来の単一テーブル運用の限界に直面していました。MySQLのアーキテクチャではマシンのスケールアウトによるストレージやスループットの拡張が困難であり、また大規模テーブルに対するオンラインDDL（カラムの追加など）の柔軟性が低いことも課題でした。可用性についても、非同期や半同期レプリケーションベースの構成では被災時にデータの強一貫性を担保できず、RTO（目標復旧時間）短縮にも限界がありました。
解決策
移行ツール OMS（OceanBase Migration Service）を活用し、全量および増量データのオンライン移行を実行。Paxosプロトコル（3レプリカのうち最低2レプリカの合意形成）による強一貫性を保証したうえで、マルチテナント機能を活かして複数のMySQL業務をOceanBaseの同一テナント内に集約・混在させました。
成果（公開事例に基づくデータ）
● データストレージ空間を約85%節約（ストレージリソース全体の2/3を削減）。
● Read性能が平均2倍、Write性能が平均3倍向上。
● ノードやデータセンター障害発生時の、RPO=0、RTO<30sでの自動フェイルオーバーを確立。
● マルチテナントによる秒単位のリソーススケールアウトを可能にし、スパイクアクセス時も安定した処理能力を維持。
導入効果の比較まとめ
| 企業 | 業界・シーン | 主な導入理由 | ストレージ削減率 | 総合的な成果 |
|---|---|---|---|---|
| A社 | モビリティ | シャーディング運用による管理コスト増とRDSのサイロ化 | 80%削減 | データベースコストを30%以上削減、SQLスループットが20%以上向上 |
| B社 | ソーシャル・動画 | 150TB超のデータ容量および300以上のMySQL運用の限界 | 75%削減 | サーバー50台分を節約、データ同期遅延を1/4に短縮 |
| Trip.com | 旅行（OTA） | 大規模IMシステムにおける単一テーブルの限界 | 85%削減 | ストレージリソースの2/3を削減、読み書き性能が2〜3倍に向上 |
六、導入ガイド：OceanBaseの圧縮機能を効果的に活用する方法
6.1 圧縮設定のクイックリファレンス
OceanBaseの圧縮設定は非常にシンプルで、テーブル作成（DDL）の際にパラメータを指定するだけで機能します。
1 CREATE TABLE xxx COMPRESSION = 'zstd_1.3.8';
圧縮アルゴリズムの選定ガイド：
| アルゴリズム | 圧縮率 | 速度 | 推奨されるユースケース |
|---|---|---|---|
| lz4_1.0 | 低 | 非常に高速 | CPU使用率に制約があり、書き込み集約型のオンラインサービス（TP業務） |
| snappy_1.0 | 中 | 高速 | 処理速度とストレージ容量削減率のバランスを最優先に調整したい場合 |
| zstd_1.3.8（デフォルト） | 高 | 優秀 | ほとんどのワークロードに対応。特別な設定を要しない「標準構成」 |
| zstd_1.5.7 | より高い | 優秀 | アクセス頻度の低い歴史（履歴）データ、長期アーカイブデータ |
| zlib_lite_1.0 | 高 | やや低速 | Intel QPL（QuickAssist Technology）等のハードウェアアクセラレーションを利用可能な環境 |
※デフォルト設定（追加設定なし）は ROW_FORMAT=DYNAMIC + COMPRESSION=zstd_1.3.8 です。多くのユースケースでは、この標準設定で十分に高い圧縮効果を得ることができます。
6.2 ユースケース別推奨構成
| 対象ワークロード | 推奨構成（DDL設定例） | 概要と主なメリット |
|---|---|---|
| TP業務（オンライントランザクション） | ROW_FORMAT=DYNAMIC ＋ COMPRESSION=zstd_1.3.8 | トランザクション性能と圧縮率を両立。CPUリソースが制約となる場合は lz4_1.0 を選択可能 |
| アーカイブ / コールドデータ | ROW_FORMAT=COMPRESSED ＋ COMPRESSION=zstd_1.5.7 ＋ 共有ストレージ構成 | 圧縮率を最大化し、オブジェクトストレージへ永続化することでコストを最適化 |
| AP分析ワークロード | 列指向テーブル ＋ 列指向エンコーディング | 圧縮率とクエリ性能を両立。TP/AP混在環境では行・列冗長テーブルも選択可能 |
| コスト重視シナリオ | 共有ストレージアーキテクチャ | ベースデータをオブジェクトストレージに保存し、ホットデータのみローカルSSDへキャッシュ。TPでは約50%、APでは約90%のコスト削減が可能 |
七、まとめ
LSM-Treeアーキテクチャと独自の「2段階圧縮」に基づくOceanBaseは、同じ業務データに対するストレージ使用量をMySQL/Oracleの1/4〜1/3に削減できる能力を持っています。
最後に、この記事のポイントを3つにまとめます。
1. 性能の妥協なしにコスト最適化を図るアーキテクチャ
2段階圧縮は単なる容量削減の仕組みではなく、LSM-Treeと高度なアルゴリズムを組み合わせた設計です。書き込みパスのオーバーヘッドを抑えつつ、キャッシュやベクタライズド実行によりクエリ性能の向上も期待できます。
2. 分散型＝高コストという前提は覆りつつある
「3レプリカ × 1/4の容量 ＜ シングルノードの1倍の容量」という関係が成り立つのであれば、強い一貫性と高可用性を確保しながら、従来構成よりも低コストで運用することが可能になります。
3. フルスタックでのコスト管理のしやすさ
追加の分析用レプリカを必要としないHTAPアーキテクチャや、I/O課金に依存しないモデルにより、TCO（総所有コスト）を総合的に抑えやすい設計になっています。
分散アーキテクチャにおけるストレージコストの課題は、データ特性に合わせた圧縮技術によって十分に解決可能です。ストレージコストは、単純なレプリカ数だけで決まるものではなく、圧縮方式やストレージアーキテクチャの影響も大きく受けます。実際の効果はデータ特性によって変わるため、PoC環境などで検証してみると、自社ワークロードに対する適用性を確認しやすいでしょう。OceanBase CloudでもPoC環境を短時間で構築できるため、実データで比較検証する方法もあります。