行単位のコールドデータアーカイブ (行レベルのアーカイブ) は、オンラインテーブルのコールドデータをObject Storage Service (OSS) に自動的にアーカイブし、データ操作言語 (DML) DELETE操作を使用してオンラインテーブルからコールドデータを削除します。 これは、TTL 2.0ソリューションとも呼ばれます。
背景情報
多くの企業は、最新の頻繁にアクセスされるデータ (ホットデータ) のみを保持したいと考えています。 アクセス頻度が低く、継続的に蓄積される古いデータ (コールドデータ) の場合、企業では次の要件を満たすソリューションが必要です。
定期的にコールドデータを削除します。
コールドデータを低コストで保存します。
アーカイブされたコールドデータを分析および統計目的で使用できるようにします。
PolarDB-Xは、前述の課題に対処するためのコールドデータアーカイブ (TTL) 機能を提供します。
CCIベースのコールドデータのアーカイブ
メリット
PolarDB-Xは、クラスター化列インデックス (CCI) 機能に基づいた行レベルのコールドデータアーカイブソリューションを提供します。 このソリューションは、次の利点を提供します。
高圧縮率: CCIは、テーブル内の各列のデータ型に基づいて最適なデータ圧縮アルゴリズムを使用して、テーブル全体で高い全体的な圧縮率を実現します。 詳細については、「CCIの概要」をご参照ください。
高いリアルタイム機能と強力な一貫性: CCIは、プライマリインスタンスとのリアルタイム同期を維持するために、プライマリインスタンスの増分バイナリログをサブスクライブします。
低ストレージコスト: CCIデータをOSSにアーカイブできるため、ストレージコストを大幅に削減できます。 詳細については、「OSSとは」をご参照ください。
オールインワン透過HTAP機能: MySQLと完全に互換性のあるオールインワン透過ハイブリッドトランザクション /分析処理 (HTAP) 機能を提供します。 これにより、企業は、既存のアーキテクチャを複雑に変更することなく、同じシステムでトランザクション処理とデータ分析を同時に実行できます。 詳細については、「HTAP」をご参照ください。
ソリューションの概要
PolarDB-Xは、他のクラウドデータベース製品で使用されているものとは異なるコールドデータアーカイブソリューションを使用しています。 PolarDB-Xは、一般的な「アーカイブ中の削除」アプローチの代わりに、「事前アーカイブおよび定期的な削除」メソッドを使用します。
事前アーカイブ: オンラインテーブルにTTL設定が設定された後、columnstoreノードはテーブルの全データに基づいてCCIを生成し、CCIをOSSに転送します。 columnstoreノードは、オンラインテーブルのバイナリログもサブスクライブし、バイナリログに基づいて増分データをOSSにリアルタイムで保存します。 次の図にプロセスを示します。
定期的な削除: オンラインテーブルのすべてのデータがアーカイブされた後、オンラインテーブルのアーカイブされたデータはTTL設定に基づいて削除されます。 詳細については、「TTLテーブルからアーカイブデータを削除する」をご参照ください。 削除操作は、OSSにアーカイブされるデータには影響しません。
ソリューションの詳細
コールドデータのアーカイブ
TTL 2.0ソリューションでは、TTLテーブルのアーカイブテーブルを作成すると、CCIが作成されます。 このプロセス中、columnstoreノードは、スナップショットに基づいてTTLテーブルの既存のデータをアーカイブテーブルのOSSストレージに転送し、TTLテーブルのbinlogをリアルタイムでサブスクライブして、増分データの行から列への変換を実行し、増分更新をアーカイブテーブルのOSSストレージにアップロードします。 次の図にプロセスを示します。
説明上の図には、次の手順が含まれます。
オンラインテーブルにTTL設定が設定されているかどうかを確認します。
DDLステートメントを使用して、オンラインテーブルのTTL設定を構成できます。 TTL設定は、特定の列が特定の期間後に期限切れになることを定義します。 詳細については、「TTLテーブルの定義と作成」をご参照ください。
コールドデータを保存するTTLテーブルのアーカイブテーブルを作成します。 TTL設定は、現在のオンラインテーブルに対して構成されます。
TTLテーブル用の専用CCIを作成します。
TTLテーブルの既存のデータをOSSに転送します。
TTLテーブルのbinlogをサブスクライブし、増分データを行から列にリアルタイムで変換し、増分更新をアーカイブテーブルのOSSストレージに転送します。
コールドデータのクリーンアップアルゴリズム
TTLテーブルは、最も古いものから最新のものまでのバッチデータクリーンアップアルゴリズムを使用してデータを削除します。 クリーンアッププロセスは、最も早いデータから開始し、各サイクル中の固定時間間隔内にデータを除去します。 詳細については、「TTL テーブルの期限切れデータのクリーンアップ」をご参照ください。
たとえば、現在の時刻は2023-10-01で、オンラインテーブルには最新の月のデータのみを保持する必要があります。 クリーンアッププロセスは次の図のとおりです。
説明1日目:
この例では、TTL定義の時間列の最小時間値は2022-10-05(MinValue) で、データクリーンアップ時間間隔 (CleanupDataInterval) は3か月です。 データクリーンアップ時間間隔の詳細については、「データクリーンアップ時間間隔の変更」をご参照ください。 最小時間値とデータクリーンアップ時間間隔に基づいて、最初のクリーンアップ時間範囲は2022年10月5日 (両端を含む) から2023年1月1日 (排他的) までです。 その後のクリーンアップ期間は、2023年1月1日 (含む) から2023年4月1日 (排他的) 、2023年4月1日 (排他的) から2023年7月1日 (排他的) 、2023年7月1日 (排他的) から2023年9月1日 (排他的) です。
2日目:
2023年1月1日 (包括的) から2023年4月1日 (排他的) の時間範囲のデータをクリーンアップします。 2023年4月1日は、クリーンアップジョブの上限 (CleanupUpperBound) です。
3日目:
2023年4月1日 (包括的) から2023年7月1日 (限定) の時間範囲のデータをクリーンアップします。 7月1日、2023はクリーンアップジョブの上限 (CleanupUpperBound) です。
4日目:
2023年7月1日 (包括的) から2023年9月1日 (排他的) の時間範囲のデータをクリーンアップします。 期間は2か月です。 この例では、現在の日付は2023年10月1日で、TTLテーブルは最新の月 (ExpiredDataInterval) のデータを保持するように設定されています。 したがって、クリーンアップジョブは、クリーンアップジョブの上限 (CleanupUpperBound) である2023年9月1日より前のデータをクリーンアップします。
各クリーンアップジョブの上限 (CleanupUpperBound) は、以下の式を用いて計算することができる。CleanupUpperBound = Min (MinValue + CleanupDataInterval, ExpiredDataInterval) 。
(オプション) アーカイブテーブルのコールドデータのクリーンアップ
コールドデータがアーカイブテーブルに蓄積されると、ストレージの負荷を軽減するために、アーカイブテーブルのコールドデータを定期的にクリーンアップする必要があります。 アーカイブテーブルのOSSストレージにアーカイブされたコールドデータは、TTLテーブルのTTL列に基づいて自動的に
レンジパーティションされます。 次の図は、アーカイブテーブルのコールドデータをクリーンアップする方法を示しています。
説明アーカイブテーブルのコールドデータは、指定されたTTL列に基づいて範囲分割されます。 アーカイブされたデータはパーティションで直接削除できます。 詳細については、「パーティションの削除」をご参照ください。。