GaussDB 技術解説シリーズ: 高度な圧縮 OLTP テーブル圧縮

この記事は、Huawei Cloud Community「DTCC 2023 Expert Interpretation | GaussDB Technical Interpretation Series: Advanced Compression OLTP Table Compression」、著者: GaussDB データベースから共有されたものです。

8月16日、第14回中国データベース技術会議（DTCC2023）が北京国際会議センターで成功裡に開催された。GaussDB の「5 つの高さと 2 つの容易さ」のコア技術、世界にとってより良い選択では、Huawei Cloud Database GaussDB のチーフアーキテクトである Feng Ke 氏が、Huawei Cloud GaussDB データベースの高度な圧縮技術について詳細に解釈しました。

以下はスピーチの書き起こしです。

貴重なゲストの皆様、こんにちは！今年、GaussDB の一連の新機能の技術的解釈を紹介し始めたことをとてもうれしく思います。私が解釈したのは、最初の機能である Advanced Compression です。

GaussDB高度な圧縮パノラマ

高度な圧縮は、あらゆるビジネスシナリオに対応するデータベース圧縮ソリューションであり、適用可能なシナリオは主に 2 つのカテゴリに分類されます。1 つ目のタイプはストレージタイプで、主にビジネスの容量制御を提供し、ビジネス拡大の可能性とコストを削減します。2 つ目のタイプは送信タイプで、主にネットワーク帯域幅を実際の状況に合わせる方法です。クロスリージョンおよびクロスアリゾナのビジネスシナリオでのビジネスに対応し、より安定した SLA 保証をビジネスに提供します。TP や AP など、さらに細分化されたシナリオが多数あります。

ここには多くの課題があり、1 つは圧縮アルゴリズムを設計する方法、もう 1 つはホット判定とコールド判定を行う方法です。ストレージクラス全体の圧縮には選択的圧縮を使用しており、システムによるホットデータとコールドデータの自動検出に基づいて、ビジネス内の比較的コールドなデータのみを圧縮し、比較的ホットなデータには触れません。ビジネスへのゼロ侵入の実現やストレージエンジンとの組み合わせなど、技術的な課題は数多くあります。

典型的なシナリオとターゲット設計

シナリオが異なれば、圧縮率、ビジネスへの影響、ビジネス侵入耐性などの圧縮アルゴリズムも異なります。ここで紹介したいのは、最初に公開された OLTP テーブル圧縮の技術的な詳細です。これについて説明する前に、OLTP テーブル圧縮がどのような種類の顧客シナリオを解決するかについて説明しましょう。これによって、当社の技術目標全体が決まります。

実際のビジネスで遭遇する典型的なシナリオは 2 つあります。最初のシナリオでは、顧客のビジネスは IBM ミニコンピューターから来ており、単一データベース全体の容量は数十 TB に達し、比較的大規模になります。ビジネスをオープンプラットフォームに移行する場合、最大の問題は、単一ユニットの容量が大きすぎて、全体の運用とメンテナンスに時間がかかることです。さまざまなオプションがあります。いわゆるデータベースの解体、つまりテーブルとサブデータベースの分割を選択することもできます。ただし、データベースの解体は、分散変換全体が必要になることを意味します。一部のビジネスにとって、それは重要なビジネスです。このような変革は、全体のリスクが非常に高くなります。2 番目のオプションは、圧縮を使用することです。圧縮により容量は削減できますが、お客様はビジネス設計の開始時にホットとコールドを分離していませんでした。たとえば、ユーザーのデータは時間ディメンションに基づいてセグメント化されていませんでした。圧縮を使用する場合は、お客様の主な要求は、ビジネスに対する圧縮の影響が十分に低いかどうか、次に圧縮率を確認できることです。これが最初の典型的なシナリオです。

2 番目の典型的なシナリオでは、顧客のビジネスは分散クラスターに基づいて展開され、容量は非常に急速に増加し、1 PB を超え、現在も増加しています。これは顧客にとって非常に大きな問題であり、定期的な拡張が必要です。圧縮を使用すると、拡張の頻度と変更のリスクを軽減することもできます。しかし、問題は同じです。顧客データもホットとコールドから分離されておらず、ユーザー ID 番号に基づくシャーディングなどの拡張性を考慮して設計されているため、さまざまなユーザーの負荷がさまざまなデータノードに均等に分散されます。冷気と熱気の分離がないため、圧縮を使用する場合、圧縮によるビジネスへの影響が十分に低いかどうか、次に圧縮率が続きます。これは、これまでに見てきた非常に典型的な OLTP 圧縮シナリオでもあります。

これら 2 つのシナリオを分析し、3 つの基本的な設計目標を導き出しました。まず第一に、圧縮スキーム全体がゼロ侵入である必要があります。ビジネスの既存のデータ分散を想定することはできず、パーティションが構築されているとは言えません。データはホットとコールドを区別できなければなりません。ビジネスにはそのような条件はありません。ビジネスのデータ分散とロジックモデルについてはいかなる仮定も行うことができず、ソリューションは侵襲性がゼロでなければなりません。2 番目に、ビジネス圧縮が有効になっている場合、ビジネスへの影響は非常に低いはずであり、少なくとも 10%、場合によっては 5% と定義していますが、これは非常に重要です。3 番目は、2:1 または 3:1 の適切な圧縮率です。圧縮率がなければ、これらのことを行う価値はありません。これら 3 つの基本目標は、当社の技術ソリューション全体の設計とエンジニアリングの実装も決定します。

主な課題 1: ビジネスのホットデータとコールドデータをどのように判断するか?

目標を決定したら、解決する必要がある 3 つの重要な問題があります。1 つ目は、ビジネスのホットデータとコールドデータを決定する方法、2 つ目は、決定後に既存の圧縮エンジンと組み合わせて圧縮データを効果的に保存する方法、3 つ目は、競争力のある圧縮アルゴリズムを実装する方法です。

ホット判断とコールド判断を行うとき、私たちはまず判断の粒度を決定します。テーブル、パーティション、ブロック、ロウ単位で判断できます。ビジネスのデータ分布全体について何の仮定も持たずに、判断の粒度が細かくなればなるほど、ビジネスへの侵入は低くなりますが、当然のことながら、実装の課題は大きくなります。定義した技術目標に基づいて、OLTP テーブル圧縮を実行するときの最初の目標は、ビジネスへの侵入を最小限に抑えるために、ホットとコールドを行レベルで行う必要があることを決定することです。

GaussDB の既存のストレージエンジンの既存のメカニズムを活用します。GaussDB の現在のストレージエンジンは他のエンジンと同じです。ユーザーデータの保存に加えて、データ全体のメタデータも保存します。メタデータにはトランザクション情報が含まれます。このトランザクション情報は通常、トランザクションの可視性を実現するために使用されます。前回の変更時刻が記録されます。トランザクションID番号。トランザクション ID 番号が現在のすべてのトランザクションに表示できるほど古い場合、トランザクション ID 番号を物理タイムスタンプに置き換えます。この物理タイムスタンプは、データ行が最後に変更された時間を表すために使用できます。コールド条件を実際に満たすのに十分な早さと古さがあれば、それを圧縮することができ、ユーザーは非常に単純なロジックを使用してホットとコールドの判断を実現できます。

2 番目の例は、ユーザーがホット条件とコールド条件をカスタマイズできるというものです。この行が長期間変更されていない場合、システムはそれを圧縮できますが、それ以外の場合は触れないでください。これは非常に単純な戦略です。顧客ビジネスの一部のフィールドに、トランザクション時間やトランザクション完了ステータスなど、非常に明確なホット属性とコールド属性がある場合、このフィールドを指定してホットとコールドの判断を行うことができます。または、顧客のトランザクションデータのほとんどは、3 か月前のトランザクションがコールドデータであるという要件を満たしていますが、保護されたトランザクションなどの一部の特殊な種類のトランザクションでは、この制約を満たすことができない場合があります。暑さと寒さの条件。たとえば、トランザクションのステータスが完了している必要がある、トランザクションの種類が特定の種類にならないなど、カスタム条件と最新の変更時刻の組み合わせにより、どのデータを圧縮するかを柔軟に定義できます。これが最初のポイント、暑さ寒さの判断方法です。

重要な課題 2: 圧縮データを効果的に保存するにはどうすればよいでしょうか?

2点目は、圧縮した対象データをどのように保存するかです。全体的な設計目標に従って、ビジネスへの侵入を可能な限り低くすることが望まれます。ブロック内圧縮を直接行うことを選択しました。つまり、ホットとコールドの判定を満たすブロック内のすべての行を一度に圧縮し、圧縮されたデータパケットを現在のデータブロックに格納します。これは圧縮率の観点からは最適な選択ではありませんが、ビジネスへの影響の観点からはより良い選択です。業務上ホット・コールドの判定条件を定めたとしても、一定の確率でコールドデータにアクセスしてしまうため、ブロック内圧縮の実装により、コールドデータにアクセスするコストに確定的な上限を持たせたいと考えています。これがブロック内圧縮の基本原理です。

重要な課題 3: 競争力のある圧縮アルゴリズムを実装するにはどうすればよいでしょうか?

なぜ選択的圧縮を行うのでしょうか? 「非常にシンプルです。データ圧縮後にビジネスに影響を与えない圧縮アルゴリズムは存在しません。現在、そのようなブラックテクノロジーは存在しません。これが基本的な技術的判断であり、圧縮率とビジネスへの影響のバランスを取る必要があります。」最初に行うのは選択的圧縮です。ビジネスデータの分散は、典型的な 80-20 分散ポリシーを満たしています。データの 80% がストレージ容量の 80% を占有しますが、消費するコンピューティングパワーは 20% のみです。例えば、銀行取引では、時間が経つと注文全体のアクセス頻度が急激に減少するという、まさにホットとコールドの特性を満たす典型的なビジネスです。

選択的圧縮を行う場合、ストレージ容量の 80% を占めるコールドデータのみが圧縮されますが、コンピューティングパワーの 20% しか消費しません。これは、ストレージコストを節約するという目標の 80% を達成したことを意味します。コールドデータはストレージ容量の 20% しか占有しませんが、ホットデータはコンピューティングパワーの 80% を消費します。これは、ユーザーへのビジネスへの影響を軽減するという目標の 80% を達成したことを意味します。これは非常に単純な技術です。選択。

また、いくつかの圧縮アルゴリズムも検討しました。たとえば、LZ4 が最もパフォーマンスの高いアルゴリズムであり、最初はこのアルゴリズムを使用しましたが、大きな問題は、圧縮率が比較的低いことです。アルゴリズム原理を注意深く分析すると、LZ4 は LZ77 アルゴリズムに基づいた実装であり、圧縮データを連続バイトストリームとして扱い、現時点から一致する文字列を検索し、エンコードする文字列の長さとオフセットを見つけ、一致した文字列を置き換えます。圧縮効果を実現する文字列。LZ77アルゴリズムは原理的に長文には非常に適していますが、データベースの特徴である数値型や短文が多い構造化データには比較的不向きです。

数値型の差分エンコードなど、多くの最適化を行ったので、圧縮フレームワークには実際には 2 つの層があり、最初の層はデータをエンコードし、2 番目の層は LZ77 アルゴリズムを使用します。ネイティブ LZ77 アルゴリズムには、3 バイトエンコーディングを含む長いテキストに対して多くの最適化が行われています。組み込みの行境界を含む 2 バイトの短いエンコーディングなど、短いテキストを容易にするためにエンジニアリングの最適化が数多く行われています。ここでは多くの詳細を説明することはできませんが、最適化の背景には主に 2 つあります。1 つは、一般的な圧縮アルゴリズムがリレーショナルデータベースの構造化データのシナリオにはあまり適していないということで、もう 1 つは、私たちが行ったエンジニアリングの最適化です。必ずしも最適であるとは限りませんが、特にリレーショナルデータに適しています。

競争力評価

最後に、簡単な評価があります。これは、TPCC および TPCH テストによる現在の商用データベース O* の圧縮率の評価です。O* も GaussDB と同様に完全なホットおよびコールド判定機能を提供しますが、開発上の理由により、実際には最初にデータ圧縮を実行してからホットおよびコールド判定を行うため、圧縮アルゴリズム全体の圧縮率は比較的低くなります。標準の TPCH データを使用しており、テストでは圧縮率が O* より平均 50% 高いことが示されており、これらのデータは直接検証できます。

オープンソースデータベースなどの他のメーカーや国内メーカーも圧縮ソリューションを提供していますが、共通の問題は、ホット/コールドの判断ができないことです。ユーザーは、テーブルまたはパーティションとその中のデータを指定できます。圧縮するか、圧縮しないかのどちらかになります。圧縮するとストレージのコストが削減されますが、パフォーマンスが低下するため、圧縮しないという選択肢もあります。この一見単純な選択は、顧客にとって最も難しいものであり、これが、今日多くの圧縮ソリューションがあるにもかかわらず、圧縮を有効にした後に何が起こるか誰も分からないため、ユーザーがそれらを使用していない理由です。これは比較的大きな問題です。。

ここでは、選択的圧縮用の GaussDB スタンドアロンバージョンに基づいて、標準的な TPCC テスト評価も行いました。TPCCのセマンティクスによれば、配信されたすべてのオーダーは変更されませんが、一定の確率でアクセスされるという、実際のビジネスシナリオに非常に近いアクセスモデルです。したがって、当社の圧縮アルゴリズムは、注文データなどのフロータイプのデータを圧縮することを選択しますが、在庫やアカウントなどの一部のステータスタイプのデータは圧縮されません。フローデータでは、配送された注文のみが圧縮され、圧縮されません。圧縮発送されていない注文。最終的な結果から判断すると、全体圧縮後のビジネスへの影響は約 1.5% です。当社は、基本的にパフォーマンスを低下させることなく、150 万 tpmC のピークパフォーマンスで圧縮をオンにすることができる業界初の製品であると考えています。

次のステップ: セマンティック圧縮

データのエンコードと圧縮アルゴリズムの境界を打ち破りましたが、圧縮アルゴリズムの使用は本質的に変わっていません。つまり、データ全体が 1 次元のバイトストリームと見なされます。ただし、リレーショナルデータは 2 次元の構造化データであるため、データの行と列の間には非常に豊富な関連性があります。この関連付けは、主に 2 つのシナリオから生じます。1 つは、モデリング時にビジネス自体によって導入される関連付けです。たとえば、接続を排除するために、データモデルはフラットまたは低正規化されるように設計されており、これにより、非常に一般的な関連付けが導入されます。2 つ目は、ビジネスサービス変換によるサービスの階層化です。これは、異なるサービス層間でのデータの継続的な転送によって引き起こされる関連付けです。私たちは、いくつかのアルゴリズムを使用して、このような構造化データ間の関連性を自動的に検出します。その結果、これらの関連性が製品の推奨やサービスのガバナンスに使用されていないことがわかり、これらの関連性を排除することで圧縮の目的を達成したいと考えています。多くのシナリオでは、このセマンティックベースの関連付け除去テクノロジは、汎用アルゴリズムよりも優れた圧縮パフォーマンスを提供します。これについては、後ほど競争力の構築に焦点を当てます。

まとめ

なぜ高度な圧縮機能が必要なのでしょうか? それは、私たちが 3 つの分野で業界のリーダーシップを達成したいと考えているからです。

まず、パフォーマンス重視のシナリオでは、適切な圧縮率を提供するという前提の下で、ビジネスへの影響 (小さいほど良い) が業界をリードします。

次に、コスト重視のシナリオでは、合理的な圧縮および解凍パフォーマンスを提供することを前提として、圧縮率 (高いほど良い) が業界をリードする結果を達成します。

3 番目に、ホットとコールドの判定自体がデータ圧縮だけでなく、マルチストレージメディアや負荷の認識など、他の多くのタスクも実行できることに気づいたかもしれません。サポートされているビジネス分野の広さという点で、業界をリードできることが、当社の高度な圧縮機能の基本的な目的です。

号外！

ファーウェイは、第8回HUAWEI CONNECT 2023を2023年9月20～22日に上海万博展示ホールおよび上海万博センターで開催する。「業界インテリジェンスの加速」をテーマとするこのカンファレンスでは、思想的リーダー、ビジネスエリート、技術専門家、パートナー、開発者、その他の業界関係者を招き、ビジネス、産業、生態学から業界インテリジェンスを加速する方法について議論します。

ぜひ会場にお越しいただき、インテリジェント化の機会と課題を共有し、インテリジェント化の主要な方策について議論し、インテリジェント技術の革新と応用を体験してください。あなたはできる：

100 を超える基調講演、サミット、フォーラムで、業界インテリジェンスの加速という観点から意見をぶつける
17,000 平方メートルの展示エリアを訪れ、業界におけるインテリジェントテクノロジーの革新と応用を間近で体験してください。
技術専門家と直接会って、最新のソリューション、開発ツール、実践的な方法について学びます。
顧客やパートナーとのビジネスチャンスを模索する

いつも皆様のご支援と信頼に感謝し、上海でお会いできるのを楽しみにしています。

カンファレンスの公式ウェブサイト: https://www.huawei.com/cn/events/huaweiconnect

「Huawei Cloud Developer Alliance」公式アカウントをフォローして、カンファレンスの議題、エキサイティングなアクティビティ、最先端の乾物を入手してください。

クリックしてフォローして、Huawei Cloudの最新テクノロジーについて初めて学びましょう~