背景
データ量の爆発的な増加に伴い、企業や組織はデータベース管理においてますます厳しい課題に直面しています。データベースのパフォーマンス低下、ストレージコストの上昇、データ運用保守の複雑化といった問題が、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データアーカイブは、アクティブレート制限とパッシブレート制限の二重戦略を採用し、オンラインデータベースの性能安定性を最大限に保証します。
アクティブレート制限にはトラフィック制限と行数制限が含まれ、読み取り操作と書き込み操作に対して計算と制限を行います。トラフィック制限の目的は、過大なトラフィックによるNICの過負荷や、速度が速すぎてCPUおよびI/Oリソースが枯渇するのを防ぐことです。データ行数制限の目的は、DRCに影響を与える可能性のある過剰なRPSの発生を防ぐことです。
パッシブレート制限は、タスク実行中にODCがデータソースのCPUおよびメモリ使用状況を継続的に監視するものです。CPUとメモリが設定されたしきい値に達すると、タスク実行者をスリープ状態にし、監視指標がタスク実行基準を満たすまで実行を続けません。この戦略により、リソース使用を効果的に制御し、タスクが適切な条件下で実行されることを保証できます。
シャーディング並列処理による高性能アーカイブの実現
データ規模がますます大きくなる中、データアーカイブプロセスは可能な限り効率的である必要があります。データアーカイブ性能を向上させるため、ターゲットテーブルの処理において主キーに基づくシャーディング戦略を採用しています。これにより、アーカイブが必要なデータを複数の小さなサブタスクに分割し、複数のスレッドによって並行して処理させることができます。並列処理により、データアーカイブ操作をより効率的に完了できます。
前提検証・削除による履歴データの信頼性確保
データベースは一貫性の最終的な保証であり、履歴データベースであっても、履歴データの有効性と完全性を保証する必要があります。現在、ODCのデータアーカイブタスクは、オンラインデータベースのデータをクリーンアップする際に、一貫性検証の保証層を提供しています。データを削除する前に、ODCはオンラインデータベースと履歴データベースのデータを取得して比較し、一貫性ポリシーを満たすデータのみが削除を許可されます。これにより、データ損失のリスクを防ぎます。現在のデータ一貫性検証ポリシーは、フルフィールドの等価比較によるもので、オンラインデータベースと履歴データベースのデータが完全に一致した場合にのみ、ODCはオンラインデータベースのデータ削除を許可します。データ移行と同様に、データ削除時にもバースト防止制御が行われ、システムの安定性が保証されます。
断点復元による大規模データシナリオ要求の満たし
大規模データシナリオにおいて、タスクが予期せぬ停止を起こした場合や手動でタスクを中止する必要がある場合、タスクを再開するコストは通常許容できないものとなります。そのため、大規模データ量シナリオにおけるアーカイブの信頼性を満たす必要があります。
ODCデータアーカイブは断点復元機能を提供しており、最新の断点記録からタスクを迅速に復元できます。実現原理はアーカイブテーブルのシャーディング処理に基づいており、各サブタスクはスライディングウィンドウを保持します。各トランザクション行グループは生成後、スライディングウィンドウに配置されます。サブタスクのデータ読み取りスレッドは単一スレッドであるため、これらのトランザクション行グループのスライディングウィンドウ内の順序は生成順序と一致します。各トランザクション行グループの消費完了後、成功マークが付けられます。この時、スライディングウィンドウの最初のタスクが完了している場合、ウィンドウを「移動」し、スライディングウィンドウの最前面のタスクが未完了状態になるまで続けます。ウィンドウが移動するたびに、外側に移動したトランザクション行グループの最後の行が新たな断点となります。各実行中のサブタスクについて、その断点情報は定期的にデータベースに報告されます。このタスクが何らかの理由で終了した場合、他のノードがこのタスクを再実行できます。タスクを再実行する際には、データベースから各サブタスクの断点情報を取得し、断点の位置から実行を再開します。サブタスク生成スレッドについても、同様の断点からの転送再開メカニズムがあります。
実際のアプリケーションシナリオにおける履歴データベースの事例
現在、Alipay、Ctrip、Monster Charging、NetBankなど、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を配置し、パーティションを通じてデータを複数のunitに分散しています。OceanBaseはビジネス非感知のエラスティックスケーリング機能を備えており、ノードの拡張によって容量と性能を増やすことができます。これにより、履歴データベースはディスクサイズに制約されなくなり、少数のクラスタですべてのビジネス履歴データベースをカバーできるため、運用コストが削減されます。
データの強整合性と迅速な障害復旧：データ移行はデータアーカイブおよび論理バックアップに相当し、監査や履歴データのクエリが必要な金融業務において、データの一貫性は極めて重要です。OceanBaseの基盤となるPaxos一貫性アルゴリズムにより、単一のOBServerがダウンした場合でも、30秒以内に迅速に復旧し、データの強整合性を保証し、オンラインクエリやアーカイブタスクへの影響を最小限に抑えます。
さらに、NetBankはOceanBase履歴データベースソリューションにより、1000万円以上のハードウェアコストを節約しました。CtripはOceanBase履歴データベースソリューションを採用することで、以前MySQLを使用していたソリューションと比較して、ストレージコストを85%削減しました。Monster Chargingは履歴データベースをOceanBaseに移行した後、ストレージコストを71%削減しました。