OLTP と OLAP のハイパーコンバージェンス: 次世代クラウドネイティブ データベースの設計

MatrixOne は、将来志向のハイパーコンバージド異機種クラウドネイティブ データベース管理システムです。新しく設計・開発された統合分散データベース エンジンにより、OLTP、OLAP、ストリーミングなどのさまざまなワークロードのデータ管理とアプリケーションを柔軟にサポートできます。ユーザーは、パブリック クラウド、自社構築のデータ センター、エッジ ノード上でシームレスに展開して実行できます。その利点としては、使いやすさ、低コスト、優れたパフォーマンス、柔軟な拡張などが挙げられます。この記事では、MatrixOne ストレージ形式の設計について詳しく説明します。

1. MatrixOneストレージフォーマット設計の本来の意図

1. MatrixOneアーキテクチャの解釈

MatrixOne の全体的なアーキテクチャは、次の 3 つのレイヤーに分かれています。

コンピューティング層はマルチノード構造として設計されており、主にデータの抽出とコンピューティング機能の完了を担当します。

中間層は、トランザクション処理とメタデータ レベル、共有ログであり、その主な機能は、完全なログ サービスとメタデータ情報を提供することです。

ドッキング レイヤーは、S3、ユーザー ローカル ファイル、NAS などのファイル サービスを通じて、さまざまな基盤となるストレージに接続します。

データ実行プロセス:

データを挿入する場合、システムがリクエストを受信した後、データはトランザクション処理層に送信されます。次に、システムはデータを共有ログに書き込み、操作が成功したことを示すプロンプトをユーザーに返します。

注意すべき点は3つあります。

1 点目: トランザクション層 (TN) が最初にデータを書き込むとき、データは比較的小さくなります。システムはまずメモリ内の構造を整理します。数千行、数万行など十分な量のデータが蓄積されると、そのデータはディスクに書き込まれます。ディスクに書き込まれた後のデータはブロックとして定義されます。

2 番目のポイント: 最初は、ユーザーが書き込むデータは比較的小さいです。データ量が増加すると、システムはデータを MER マージし、継続的にマージして、ユーザーがデータを直接クエリして分析を実行できるようにします。

3 番目のポイント: データ書き込みプロセス中に操作が多く、データ量が多い場合、システムはデータをデータベースまたは S3 に直接書き込みます。書き込みが完了すると、サービスを公開することでシステムのバックグラウンドに送信されます。

上図の右側の構造の通り、上から順に第1層が​​DB、第2層がテーブルとなっています。 DB とテーブルはメタデータ内に存在します。特定のデータは複数のオブジェクトに分割され、オブジェクトは複数のブロックに分割できます。

2. MatrixOneストレージフォーマット設計の本来の意図

MatrixOne 0.5 以降、1.1 にリリースされ、常に列ストレージ構造を採用しています。列ストレージは AP を最適化しやすく、負荷に柔軟に対応できるためです。列データは、ほとんどのデータベースの Hive ファイル配置構造に似ています。各列には独立したブロックがあり、ユーザーはこれらの列を通じてデータを照会できます。

MatrixOneでは、データベースのテーブルデータ、テーブル、DB、カタログメタデータ管理、メタデータストレージ、リプレイなど、あらゆる業務タイプに対応する必要があります。

業務データの運用中には、多くのトレースログや生ログが存在します。ユーザーがログを簡単に表示できるようにするには、これらのデータに対して十分なサポートを提供する必要があります。

AP に似たシナリオに遭遇すると、大量のデータを含むクエリがあり、クエリの結果が後で呼び出される場合があります。システムは共通クエリ結果をローカル ファイルまたは S3 に保存し、後で共通結果データを直接呼び出すことを可能にします。

すべてのビジネス データのニーズを満たすために、データ クエリの適時性に影響を与えることなく、さまざまなデータ タイプに簡単にアクセスできます。ファイル サーバーで S3 共有ストレージを使用すると、この問題を解決できます。 S3 オブジェクト ストレージの場合、各オブジェクトは指定された行、指定されたサイズ、または指定されたブロックを保存する必要があります。ブロックがたくさんあります。オブジェクトを格納するブロックには複数の種類があり、スキーマが異なる場合があります。これらのさまざまなスキーマに必要なブロックを特定するには、ブロックの言語データ分析を使用し、ブロックのソース データを更新して実際のデータ ストレージ アドレスを取得する必要があります。これは、メタデータ要求への便利で効率的なアクセスを保証する原則です。

ユーザー データが一定期間正常に実行された後、データの正確性を確認するためにスクラブ タスクが必要になります。 MatrixOne は、これらのニーズを満たし、ユーザーがデータを維持するのに役立つツールをいくつか提供します。

3. データ構造分析

構造図の上部にあるヘッダーには、オブジェクトのバージョン情報、データ形式、メタデータの場所、チェックサムの場所が記録されます。構造図の下部にあるフッターは、ヘッダーの鏡像です。

以下はデータ領域です。書き込まれた業務データはメモリ内にパッケージ化され、このデータ領域に書き込まれます。データ領域に書き込まれたデータはブロックと呼ばれます。構造図の次の層は、オブジェクト全体のメタデータ領域です。

1 つ目は、既存の機能と Romec が保存されるインデックス領域です。

構造図の最後の層は、オブジェクト全体のメタタグであり、オブジェクト全体を解析して読み取る方法が含まれます。

ユーザーがデータを正常に書き込むと、システムにはメタデータ領域全体を指すオフセットが設定されます。

メタデータの構造は上の図に示されています。

墓石はユーザーデータです。書き込み後、ユーザーは行を削除したい場合があります。書記体系を直接変更することはできないため、システムは削除する必要がある行を記録します。これをソフト削除と呼びます。

SubMeta には、カタログ、ブロック、オブジェクトなどが格納されます。ユーザーがデータを読み取るときには、チェックポイントと呼ばれるこれらのメタデータが必要になります。 SubMetaにはチェックポイントが存在し、その種類は20種類以上あります。パフォーマンスを確保するために、ユーザーがデータセットを抽出する場合、システムには対応するメタを取得してこれらのメタの場所を記録するためのポインター オフセットのみが必要であり、これには SubMetaIndex が必要です。

DataMeta、TombstoneMeta、SubMeta、各 Meta には Meta 全体の情報を記録するためのヘッドがあります。

ブロック層構造は上図のようになります。

各ブロックには異なる値があります。データ全体のメタ チェックポイント、列数、行、または Bloom Fitter インデックスはすべて補足に記録されます。ブロック オフセットを記録するために使用されるブロック インデックスもいくつかあります。ブロック数は固定されていないため、システムはインデックスを記録する必要があります。そうでない場合、最初にブロックの数を読み取り、次にこれらのブロックを使用して必要なブロックがどこにあるかを計算すると、全体的なパフォーマンスに高い要求が課せられます。したがって、システムはブロック インデックスを記憶し、固定の開始位置と終了位置を記録してブロックの位置をマークし、読みやすくします。

DBID、TableID、AccountIDなどの具体的な説明は上図の通りです。

ColumnMeta は、現在の列の列番号とタイプを記録します。 NDV は列内の異なる値の数です。 NullCnt は、この列の null 値の数を記録します。 DataExtent はデータの場所を記録し、圧縮前後のデータ サイズも記録します。 Chksum はデータのチェックサムです。 ZoneMap はこの列の MinMax インデックスを参照し、インデックスによって現在検索されているオフセット行アドレスを通じてデータを読み取ることができます。

ユーザーがデータの書き込みを完了すると、オブジェクトのメタ位置を記録したエクステントが返され、カタログ (メタデータ) に保存されます。ユーザーがシステムを使用してデータを照会し、データを読み取る必要がある場合、この範囲を使用してオブジェクト全体のメタを照会し、メタを通じて特定の列データをレイヤーごとに表示できます。

システム内のオブジェクトの最小単位は IO エントリであり、異なる IO に応じて異なる IO エントリに分割できるため、エクステントを通じて IO を読み取ることができます。たとえば、列データ、列は IO に等しく、列ごとに読み取ることができます。また、メタも IO であり、ブルームフィルターも IO であり、さまざまなフィードすべてを IO を通じて読み取って簡単にフィルタリングできます。

IO エントリを通じて、このオブジェクトのメタをクエリし、実際のデータをクエリします。 Meta を通じてデータを読み取るには、まずデータ ヘッドを見つけ、次にブロック インデックスを取得してブロック Meta を簡単に取得する必要があります。各列はブロック メタ内にあり、一部の列を簡単にクエリする方法も含まれています。データの範囲を記録する列 Meta が表示されます。その後、これらの IO に基づいてデータを読み取り、必要なデータを簡単に取得できます。

あまり使用されないが分析が必要なデータに遭遇した場合、ユーザーはどのデータを読み取るかを決定し、対応するオブジェクトのメタを継続的にチェックする必要があります。システムは、データの読み取りの適時性の問題を解決するために、オブジェクトのメタを常駐キャッシュに配置します。

2. 履行保証

アクセスする必要があるデータは、メタデータ、テーブル データ、インデックス、チェックポイント、さまざまなログなど多岐にわたります。低コストのアクセスを確保するためには、メタデータ キャッシュ、インデックス キャッシュなどが必要です。データを取得した後、効率的に解析する必要があります。

メタデータの効率的な解析を実現するために、私たちは多くの試みを行ってきました。例えば、byteメソッドを使うとメモリに格納する際にシリアル化する必要がなく、そのまま使うことができます。どのフィールドを読み取りたいかを指定する場合は、ポインター オフセットを使用して完了できます。

データの書き込みも非常に便利です。ブロック ID を設定することは、最初にブロック ID 構造をバイトにすることと同じであり、直接コピーすることができ、ポインター操作も非常に便利です。

ベンチマークを通じてデシリアライゼーション分析を行う場合、対応するメタデータ ID が取得されていれば、解析プロセス全体がナノ秒レベルで比較的高速になります。

3. データの互換性と使用シナリオ

1. データの互換性

互換性も非常に重要な問題です。たとえば、顧客が製品を 1 年または 2 年使用しており、最適化のためにデータ形式の変更が必要な場合、新しいコードは以前のデータと互換性がある必要があります。

私たちの解決策は比較的シンプルです。各 IO エントリはヘッダーにデータ タイプでマークされ、そのタイプによってエンコードおよびデコード方法が決まります。バージョンはタイプのバージョンです。バージョンを切り替える場合は、対応するエンコードおよびデコード関数を登録し、対応する IO エントリ ヘッダーを読み取り、対応する関数を選択してデータを解析することで、互換性を実現できます。

上記は構造図です。タイプとバージョンは IOEntryHeader に記録されます。タイプには、オブジェクトのメタ、列データ、インデックスなどが含まれます。ユーザーがデータを書き込むと、システムはエンコード機能を登録します。オブジェクトの Meta が書き込まれる場合、オブジェクト Meta がバージョン 2 であれば、タイプは type1 としてマークされ、バージョンは version2 となり、書き込まれる Meta のバイトが続きます。

読み取り時には、システムが IO エントリのすべての内容を読み取り、最初の 2 つのフィールドを取得してヘッダーを通じて解析するため、最初にヘッダーが読み取られます。

最初から現在まで、MatrixOne のバージョンは 3 回しか変更されていません。各バージョンには簡潔な対応機能があり、メンテナンスが非常に便利です。

2. 適用シナリオ

システムには個別のログ サービスがあり、他のすべてのデータ構造 (ディスクからの読み取り、テーブル データの通常のビジネス読み取りと書き込み、クエリ、挿入など) はこの構造を使用します。

チェックポイントとカタログをサポートします。システムは定期的にチェックポイントを作成し、どの DB が追加されたか、DB にいくつのテーブルが追加されたか、データがディスクに書き込まれたかどうか、どのオブジェクトが追加されたか、オブジェクト データ内の特定のブロックを記録します。起動時に、システムはチェックポイントに基づいてカタログを再生します。ユーザーはカタログに基づいて DB データを照会できます。

メタデータ スキャンの主な機能は、スキャン ユーザーが保存したデータの量、保存されているテーブル DB の数、これらの DB にあるオブジェクト ファイルの数、オブジェクトのサイズ、圧縮前後のサイズなどを確認することです。メタデータ スキャンでは、常にキャッシュに保存されているオブジェクトのメタデータが使用され、非常に効率的です。

クエリ結果キャッシュの使用。比較的大規模なクエリ分析が発生した場合、たとえば、クエリ分析に数秒かかり、より多くのコンピューティング リソースを消費する場合、システムはこれらの結果をすべてキャッシュに保存します。この方法により、ユーザーは次回大量のデータを再ロードしてクエリを再計算する必要がなくなります。

4. 質疑応答

Q1: 動的カタログを実装する際に、コミュニティはタスクの変更を考慮しますか?

A1: カタログ作成はチェックポイントを通じて行われるようになりました。この問題は解決されました。すべてのチェックポイントは増分です。追加、削除、変更、クエリ、DDL を含むすべての増分レコードが記録されます。これらはすべてチェックポイントに記録され、再生できます。カタログもメモリ内に常駐し、アトミックに制御できます。

Q2: たとえば、企業がすでに大量の既存データを含む非常に完全なクラスターを持っている場合、この場合、MatrixOne をどのように使用すればよいでしょうか?

A2: MatrixOne は、これらのデータをロードできるクラスター接続用の小さなツール、MoDump を提供しています。最初に行うことは、このデータをパッケージ化してロードし、次にこのデータを製品にロードすることです。今後は、さまざまなデータベースに接続してリアルタイムにコピーできるツールも開発していく予定です。