背景
データ量の爆発的な増加に伴い、企業や組織はデータベース管理においてますます厳しい課題に直面しています。データベースのパフォーマンス低下、ストレージコストの上昇、データ運用保守の複雑化といった問題が、DBAや開発者によるデータ管理を一層困難にしています。これらの課題に対応するためには、オンライン、ニアライン、アーカイブから廃棄までの4つの段階を含む、よりきめ細かいデータライフサイクル管理が必要です。その中でも、特にニアライン段階とアーカイブ段階における既存データベースの管理が重要です。
シナリオの概要
履歴データは、近線ストレージおよびアーカイブストレージの両段階で重要な役割を果たします。アーカイブ段階では、データベースまたはオフラインファイル形式が採用されます。一方、まだ少数のクエリが必要なアーカイブデータについては、通常、履歴データベースソリューションが選択されます。履歴データベースソリューションは、実際にはコールドデータとホットデータを分離する戦略であり、オンラインデータベースの負荷を軽減することでそのパフォーマンスを向上させます。履歴データベースのコールドデータは通常アクセス頻度が低いため、コスト削減を目的として、ディスク容量が大きくCPU構成が低いマシンタイプを選択できます。
ユーザーとの対話を通じて、多くのユーザーが大規模な履歴データを効果的に処理できるソリューションを切望しており、コスト削減を図りながらもパフォーマンスやデータ可用性に影響を与えたくないというニーズがあることがわかりました。本記事では、履歴データベースのモダンアーキテクチャへのアップグレード方法について詳しく探求し、特にOceanBaseが企業の履歴データベース管理最適化をどのように支援するかを重点的に紹介します。
技術アーキテクチャ
業務上の実際の使用状況に基づき、履歴データベースは以下の特性を備えている必要があります：
大容量のストレージ空間を備え、大量のデータの格納とオンラインデータベースからの効率的かつ継続的なデータインポートをサポートする。
良好な拡張性を備え、ストレージアーキテクチャを調整することなく増加し続けるデータ量を処理できる。
より低いストレージコストを提供し、より少ないディスク容量とより経済的なストレージ媒体でより多くのデータを保存する。
一定のクエリ能力を提供し、効率的な少量トランザクション型クエリをサポートすると同時に、効率的な分析型クエリもサポートできる。
アプリケーションとオンラインデータベースが同じアクセスインターフェースを維持し、アプリケーションの複雑さを低減する。
これらの要件に直面した場合、OceanBaseは自然な選択肢となります。優れた単一マシンおよび分散型の拡張能力とHTAP混合ワークロード処理能力を備えているため、業務システムのオンラインデータベースおよび履歴データベースのシナリオを効率的にサポートできます。さらに重要なのは、OceanBaseは業務要件を満たしつつ、ストレージコストを少なくとも半分に削減できる点です。一部の顧客からのフィードバックによると、業務履歴データベースを他のデータベースからOceanBaseに移行した後、ストレージコストは約80％削減できたとのことです。これも、多くのユーザーが履歴データベースシナリオでOceanBaseを選択する主な理由の一つです。
履歴データベース製品アーキテクチャの設計に伴い、OceanBaseは履歴データベースのストレージアーキテクチャについてさらに検討しています。
まず、履歴データベースのデータベースアーキテクチャがオンラインデータベースと一致する必要があるかどうかについてです。オンラインデータベースは、データ規模やパフォーマンスの要件から、データ分割やシャーディングなどのアーキテクチャを採用する場合がありますが、履歴データベースのパフォーマンス要件は通常低く、使用シナリオに応じて一致させる必要はありません。データ分割やシャーディングのアーキテクチャは、データベースのデプロイ・運用保守、バックアップ・リカバリに追加のコストをもたらします。特にOceanBaseを履歴データベースとして使用する場合、単一のテーブルで数十TBのデータ規模を容易に扱えるため、データ規模が大きくてもパーティションテーブルを採用できます。
次に、履歴データベースがデータ更新をサポートすべきかどうかについてです。技術的には可能であり、履歴データベースは更新をサポートすることも、読み取り専用に設定することもできます。しかし、履歴データベース全体のコストを考慮すると、可能な限り読み取り専用の履歴データベース構成を採用することを推奨します。読み取り専用の履歴データベースではランダムな読み書きが少なくなり、SSDではなくSATAディスクなどのより安価なストレージハードウェアを使用できます。さらに、読み取り専用の履歴データベースは、自身のバックアップコストも削減され、バックアップコピーを1つだけ維持すればよくなります。
最後に、データアーカイブにおいてオンラインデータベースへの影響を可能な限り抑えることが非常に重要です。オンラインデータベースは企業業務の持続的かつ安定した運用の鍵となります。データ規模が大きいシナリオでは、大量データの読み取り、計算、削除がオンラインデータベースに負荷をかけるため、データアーカイブプロセスはオンラインデータベースの安定性を確保できなければなりません。
OceanBaseデータアーカイブのコア機能
コールド/ホットデータの分離によるオンラインデータベースのパフォーマンス向上
通常、業務データの一部は一定期間経過するとほとんどアクセスされなくなったり、全くアクセスされなくなったりします。これらのデータは一般的に「コールド」データと呼ばれます。この問題を解決するためのアプローチは、アクセス頻度が低い「コールド」データを履歴データベースにアーカイブし、オンラインデータベースには直近の期間のデータのみを保持することです。
従来のデータアーカイブ方法では、多くの時間と人的リソースを消費することが一般的であり、操作ミスやデータ損失などのリスクも伴います。さらに、手動によるアーカイブ操作の煩雑さは、データ管理の効率と作業の柔軟性を制約しています。これらの課題に対処するため、ODCはV4.2.0バージョンからデータアーカイブ機能を導入し、データ管理における課題を解決し、作業効率とデータセキュリティを向上させることを目指しています。
ODCのデータアーカイブ機能を利用することで、このようなコールド/ホットデータの分離プロセスを実現できます：
Web版ODCにログインします。
チケット > 新規チケット > データアーカイブ をクリックします。
データアーカイブチケットの作成ページに移動し、チケットの詳細を入力します。 以下の図は例ですが、tb_order テーブルのオンラインデータベースから履歴データベースへのアーカイブタスクを設定し、アーカイブ完了後にソース側のアーカイブ済みデータをクリーンアップするオプションを選択しています。データアーカイブのすべての設定詳細については、データアーカイブを参照してください。
注意
ここでは変数 archive_date を使用しており、その値は現在時刻から1年前に設定されています。フィルタ条件で変数を参照することで、アーカイブタスクを実行するたびに1年前のデータをアーカイブできます。
ODCのデータアーカイブは、即時実行、指定時刻実行、周期実行をサポートしています。また、構造同期、データ挿入戦略、レート制限戦略の設定も可能です。構造同期では、必要に応じてパーティションとインデックスの同期を選択できます。履歴データベースはオンラインデータベースと異なるパーティション設計を採用している可能性があり、履歴データベースとオンラインデータベースのクエリ要件も異なる場合、より少ないインデックスでストレージコストをさらに削減できます。
新規タスク をクリックすると、アーカイブSQLのプレビューが表示され、アーカイブするデータ範囲を確認できます。ODCのデータアーカイブタスクを利用すれば、簡単な設定だけで、コールドデータをオンラインデータベースから履歴データベースにアーカイブし、オンラインデータベースのコールド/ホットデータを分離できます。
今後のユースケースにおいて、業務の変更や誤操作により、履歴データベースにアーカイブされたデータをオンラインデータベースに復元する必要が生じた場合、ODCはワンクリックでロールバックできる機能を提供しています。先ほどのタスクを例にすると、アーカイブ済みのデータをオンラインデータベースにロールバックする必要がある場合、実行記録ページで、データアーカイブタスクの記録後にあるロールバックボタンをクリックするだけで、アーカイブのロールバックタスクを開始できます。
期限切れデータのクリーンアップによるストレージコストの削減
ODCのデータアーカイブ機能は、オンラインデータベースのホットデータとコールドデータを分離し、コールドデータを履歴データベースに移行することで、コスト削減と効率向上を実現します。実際の運用では、業務上のコールドデータが履歴データベースに移行された後も、必ずしも永続的に保持する必要はありません。一定期間経過すると、ログデータなど、一部のコールドデータは「期限切れ」状態となり、全く使用されなくなる場合があります。これらの期限切れデータを適時にクリーンアップできれば、ストレージコストをさらに削減できます。この問題を解決するため、ODCはデータクリーンアップ機能を提供し、データベース内の期限切れデータを定期的にクリーンアップすることで、ストレージリソースの利用をさらに最適化します。
ODCコンソールにログインします。
チケット > 新規チケット > データクリーンアップ をクリックします。
データクリーンアップチケットの作成ページに進みます。データクリーンアップチケットの設定は、データアーカイブチケットと基本的に同じです。以下の例は、定期的なクリーンアップを設定したチケットの作成手順を示しています。データクリーンアップの全設定の詳細については、データクリーンアップを参照してください。
説明
ODCのデータクリーンアップは、履歴データベースと連携して、クリーンアップ前のデータ検証もサポートしています。
エンドツーエンドのデータアーカイブパイプライン
ODC v4.3.4バージョンまでに、ODCのデータアーカイブは以下のパイプラインをサポートしています：
OceanBase MySQL、MySQLオンラインデータベースからOceanBase MySQL履歴データベースへ。
OceanBase Oracle、OracleオンラインデータベースからOceanBase Oracle履歴データベースへ。
OceanBase MySQL、MySQLオンラインデータベースからMySQL履歴データベースへ。
OceanBase Oracle、OracleオンラインデータベースからOracle履歴データベースへ。
PostgreSQLオンラインデータベースからOceanBase MySQL履歴データベースへ。
OceanBase MySQL、OceanBase Oracle、MySQL、Oracle、PostgreSQLからオブジェクトストレージ（OSS、COS、OBS、S3）へ。
ODCのプロダクト形態は以下のとおりです：
プライベートクラウドWEB版：プライベートクラウド版は、OceanBase Community EditionやEnterprise Editionに接続できるほか、OB Cloudクラウドデータベースへの接続もサポートしています。
OB Cloudクラウドサービス：ODCのデータアーカイブ機能は、OB Cloudクラウドコンソールでも提供されており、OB Cloudクラウドデータベースを購入したユーザーは直接利用できます。
OceanBaseデータアーカイブのコア技術
データアーカイブプロセスを安定して、高速に、正確に実現し、大規模データシナリオに適応させるために、ODCデータアーカイブでは多次元レート制限、シャーディング並列処理、データ検証、断点復元などの技術を導入しています。以下はデータアーカイブの技術アーキテクチャで、主に3つのコンポーネントで構成されています：
Worker（タスク実行者。タスクの具体的なロジックを実行する責任を負う）
MetaDB（タスクのメタデータ情報を格納するために使用され、OceanBaseを採用して高可用性を保証する）
ODC Console（ユーザー操作の入口。タスクの公開と管理に使用される）。
多次元レート制限メカニズムにより、オンラインデータベースの安定した運用を保証
ODCデータアーカイブは、アクティブレート制限とパッシブレート制限の二重戦略を採用し、オンラインデータベースの性能安定性を最大限に保証します。
アクティブレート制限には、トラフィック制限と行数制限が含まれ、読み取り操作と書き込み操作に対して計算と制限を行います。トラフィック制限の目的は、過大なトラフィックがネットワークカードを過負荷にさせたり、速度が速すぎてCPUとI/Oリソースを使い果たしたりするのを防ぐことです。データ行数制限の目的は、DRCに影響を与える可能性のある過剰なRPSの発生を防ぐことです。
パッシブレート制限は、タスク実行中にODCがデータソースのCPUとメモリ使用状況を継続的に監視するものです。CPUとメモリが設定されたしきい値に達すると、タスク実行者はスリープ状態に入り、監視指標がタスク実行基準を満たすまで実行を続けません。この戦略により、リソース使用を効果的に制御し、タスクが適切な条件下で実行されることを保証できます。
シャーディング並列処理により、高性能なアーカイブを実現
データ規模がますます大きくなる中、データアーカイブプロセスは可能な限り効率的である必要があります。データアーカイブ性能を向上させるため、ターゲットテーブルの処理において主キーに基づくシャーディング戦略を採用しています。これにより、アーカイブが必要なデータを複数の小さなサブタスクに分割し、複数のスレッドによって並行して処理させることができます。並列処理により、データアーカイブ操作をより効率的に完了できます。
前提検証・削除により、履歴データの信頼性を確保
データベースは一貫性の最終的な保証であり、履歴データベースであっても、履歴データの有効性と完全性を保証する必要があります。現在のODCのデータアーカイブタスクは、オンラインデータベースのデータをクリーンアップする際に、一貫性検証の保証層を提供しています。データを削除する前に、ODCはオンラインデータベースと履歴データベースのデータを取得して比較し、一貫性ポリシーを満たすデータのみが削除を許可されます。これにより、データ損失のリスクを防ぎます。現在のデータ一貫性検証ポリシーは、フルフィールドの値が一致するかどうかを比較するもので、オンラインデータベースと履歴データベースのデータが完全に一致した場合にのみ、ODCはオンラインデータベースのデータの削除を許可します。データ移行と同様に、データ削除時にもシステムの安定性を保証するための防爆制御が施されます。
断点復元により、大規模データシナリオの要求を満たす
大規模データシナリオでは、タスクが予期せぬ停止を起こしたり、手動でタスクを中止する必要が生じたりした場合、タスクを再開するコストは通常許容できないものとなります。そのため、大規模データ量シナリオにおけるアーカイブの信頼性を満たす必要があります。
ODCデータアーカイブは断点復元機能を提供しており、直近の断点記録からタスクを迅速に復元できます。実装原理はアーカイブテーブルのシャーディング処理に基づいており、各サブタスクはスライディングウィンドウを保持します。各トランザクション行グループは生成後、スライディングウィンドウ内に配置されます。サブタスクのデータ読み取りスレッドは単一スレッドであるため、これらのトランザクション行グループのスライディングウィンドウ内での順序は生成順序と一致します。各トランザクション行グループの消費完了後、成功マークが付けられます。この時、スライディングウィンドウの最初のタスクが完了している場合、ウィンドウを「移動」させ、スライディングウィンドウの最前面のタスクが未完了状態になるまで繰り返します。ウィンドウが移動するたびに、外側に移動したトランザクション行グループの最後の行が新たな断点となります。各実行中のサブタスクについて、その断点情報は定期的にデータベースに報告されます。このタスクが何らかの理由で終了した場合、他のノードがそのタスクを再実行できます。タスクを再実行する際には、データベースから各サブタスクの断点情報を取得し、断点から先の部分から実行を再開します。サブタスクの生成スレッドについても、同様の断点からの転送再開メカニズムがあります。
実際のアプリケーションシナリオにおける歴史データベースの事例
現在、Alipay、Ctrip、Monster Charging、NetEase Money Market Bankなど、100社以上のユーザーがOceanBaseを利用して歴史データベースのアーキテクチャをアップグレードし、顕著な効果を得ています。
AlipayはOceanBaseを利用して歴史データベースのアーキテクチャをアップグレードし、PBレベルのデータアーカイブと水平方向への無限スケーラビリティを実現しました。全体のストレージコストは3分の1、データストレージコストは80%削減されました。現在までに、Alipayは取引、決済、チャージ、会員、会計など、ほぼすべてのコア業務をカバーする20以上の歴史データベースクラスタを構築しており、総データ量は95PBに達し、毎月3PB増加しています。その中で、最大の取引・決済クラスタのデータ量は15PBに達し、日次データ増分は最大50TBに達します。この歴史データベースのアップグレードにより、Alipayは顕著なメリットを得ています：
コストの大幅な削減：歴史データベースでは、より低コストなSATAディスクを使用してOceanBaseデータベースクラスタを構築し、単位面積あたりのディスクコストをオンラインマシンの30%に削減しました。同時に、より高い圧縮率を持つzstd圧縮アルゴリズムを使用することで、全体のコストを80%削減しました。オンラインデータベースがMySQLやOracleなどの従来型データベースの場合、コスト削減はさらに顕著です。これは、OceanBaseのデータエンコーディング、圧縮、およびLSM-Treeストレージアーキテクチャにより、ストレージコストが従来型データベースの3分の1になるためです。
エラスティックスケーリングによる運用コストの削減：歴史データベースでは、OceanBaseの3レプリカアーキテクチャを採用し、各ゾーンに複数のOBServerを配置し、パーティションを通じてデータを複数のユニットに分散しています。OceanBaseはビジネスを意識せずにエラスティックにスケールアウトできる機能を備えており、ノードの拡張によって容量とパフォーマンスを向上させることができます。これにより、歴史データベースはディスクサイズに制約されなくなり、少数のクラスタですべてのビジネスの歴史データをカバーできるため、運用コストが削減されます。
データの強整合性と迅速な障害復旧：データ移行は、データアーカイブおよび論理バックアップに相当します。監査や履歴データ検索が必要な金融業務において、データの一貫性は極めて重要です。OceanBaseは基盤としてPaxos一貫性アルゴリズムを使用しており、単一のOBServerがダウンした場合でも、30秒以内に迅速に復旧し、データの強整合性を保証することで、オンラインでのクエリやアーカイブタスクへの影響を最小限に抑えます。
さらに、NetEase Money Market BankはOceanBaseの歴史データベースソリューションにより、1,000万円以上のハードウェアコストを節約しました。CtripはOceanBaseの歴史データベースソリューションを導入したことで、以前のMySQLソリューションと比較してストレージコストを85%削減しました。Monster Chargingは歴史データベースをOceanBaseに移行した後、ストレージコストを71%削減しました。