JSON形式のデータを効率的に分析する - PolarDB - Alibaba Cloud ドキュメントセンター

このトピックでは、大量の構造化データと半構造化データを分析するために、PolarDBのインメモリ列インデックス (IMCI) 機能に基づいて開発された拡張ストリームコンピューティングソリューションについて説明します。このソリューションは、JSON形式のデータの列指向ストレージ、仮想列、インスタントDDL、テーブル内の列の拡張最大数など、IMCIのさまざまな機能を統合します。このトピックでは、顧客のユースケースについても説明します。

背景情報

多様で迅速な反復シナリオに適応するために、ほとんどのビジネスシステムは半構造化データを保存および分析するように構築されています。 PolarDBのIMCI機能は、JSON形式のデータの仮想列や列指向ストレージなどの包括的な機能を提供します。 IMCIは、ビッグデータと、構造化データや半構造化データを含む複数のタイプのデータを迅速に処理できます。 IMCIは、効率的なデータ分析、データクエリ、およびストリームコンピューティング機能も提供します。データ分析、データウェアハウジング、拡張ストリームコンピューティングなどのシナリオに適しています。

このトピックでは、PolarDBのIMCI機能に基づいて開発されたリアルタイムデータ分析および拡張ストリームコンピューティングソリューションを使用して、JSON形式のデータなど、大量の半構造化データを計算および分析する方法について説明します。その前に、このトピックでは、従来のデータベースとデータウェアハウスでの半構造化データ分析のソリューションについて説明します。また、JSON形式のデータの列指向ストレージ、仮想列、インスタントDDL、テーブル内の列の拡張最大数など、PolarDBが提供するIMCIの詳細な機能について説明します。

ソリューション

JSON形式のデータは、半構造化データの柔軟性と効率的な分析の必要性により、ほとんどのビジネスシステムで分析されます。したがって、柔軟性と効率性は、半構造化データ分析に対するソリューションのパフォーマンスを測定するための重要な指標です。

従来のデータベースのソリューション

MySQL、PostgreSQL、ClickHouseデータベースなどの従来のリレーショナルデータベースでは、生のJSON形式のデータがバイナリデータにエンコードされ、テーブルのJSON列に格納されます。クエリ中、JSON関数を使用して、JSON列のすべてのデータをリアルタイムで解析および計算します。

JSON形式のデータは、半構造化データの一種です。ビジネス要件に基づいて、JSON形式のデータの属性を追加、削除、および変更できます。ビジネス要件が変更された場合、テーブルのスキーマを変更する必要なく、ビジネスシステムのJSON列の新しいデータに関連する属性を動的に追加、削除、および変更するだけで済みます。これにより、テーブルスキーマの維持と管理のコストが効果的に削減されます。ただし、JSON列のすべてのデータは、クエリ中にリアルタイムで解析されます。これにより、大量のI/Oリソースが消費され、構文解析とコンピューティングが繰り返される可能性があります。さらに、JSON列の指定されたフィールドにセカンダリインデックスを作成または使用することはできません。

select product.item->"$.name"
from product, purchase
where product.id = purchase.item->"$.id"
group by product.item->"$.name";

たとえば、前述のSQLステートメントは、従来のデータベースで実行され、ネストされたループ結合に基づいてデータを照会します。データの行が製品テーブルから読み取られるたびに、すべてのデータが購入テーブルのアイテム列から読み取られます。 JSON列であるitem列内のすべてのデータは、指定されたフィールドからデータを抽出するために繰り返し解析されます。これは、クエリ効率を低下させます。

従来のデータウェアハウスのソリューション

データウェアハウスでのデータ処理プロセスは、次の手順で構成されます。

データ抽出: データベース、ファイル、webサービスなどのさまざまなデータソースから必要なデータを抽出し、抽出したデータをクリーンアップ、変換、およびフィルタリングします。
データ変換: 抽出されたデータを変換して、データがデータウェアハウスのデータモデルと仕様に準拠していることを確認します。関連する操作には、データクレンジング、データ統合、データ変換、データエンハンスメント、およびデータ集約が含まれます。
データの読み込み: ディメンションテーブルやファクトテーブルなど、変換されたデータをデータウェアハウスに読み込みます。
データ管理: データバックアップ、データ復元、データセキュリティなど、データウェアハウス内のデータを管理します。
データ分析: データウェアハウス内のデータに対して、データクエリ、レポート生成、データマイニングなどの多次元分析を実行します。

ほとんどの場合、ビジネスシステムの本番データは、データがデータウェアハウスにインポートされる前に、ビジネス要件に基づいて抽出、変換、ロード (ETL) ジョブによって処理されます。

データウェアハウスでのデータ処理中に、JSON形式のデータがETLジョブで事前解析され、必要に応じて対応する値が計算され、その値がテーブルの別の列に挿入されます。このようにして、JSON形式のデータの属性をビジネス要件に基づいて処理し、大きな幅のテーブルの列に挿入できます。これにより、クエリのパフォーマンスが向上します。クエリ中、JSON列のすべてのデータを読み取ったり解析したりすることなく、通常の列からデータを読み取ることができます。これにより、大量のI/Oリソースが節約されます。さらに、通常の列のインデックスを作成して使用して、クエリのパフォーマンスを効果的に向上させることができます。

ただし、ビジネスシステムのビジネス要件に基づいてJSON形式のデータの属性を追加、削除、または変更する場合、データウェアハウスのETLジョブとテーブルスキーマを、アップストリームの本番データに適合するように変更する必要があります。 ETLジョブの再発行やDDLステートメントの実行などの操作は、ETLジョブとビジネステーブルスキーマのロジックを維持するために実行されます。 ETLジョブの頻繁な公開は、アップストリームのデータ消費とダウンストリームのデータウェアハウジングに影響します。さらに、大きなテーブルのスキーマを変更するには、インスタントDDL機能がなければコストがかかり、通常のデータクエリにも影響します。

従来のデータウェアハウスにおける半構造化データ分析のソリューションは、効率的なデータクエリを提供できますが、柔軟性に欠け、高いメンテナンスコストを必要とします。

IMCIソリューション

従来のデータベースとデータウェアハウスでの半構造化データ分析のソリューションでは、クエリのパフォーマンスと柔軟なアーキテクチャの要件を同時に満たすことができません。 Alibaba Cloudは、業界における新しいソリューションの緊急のニーズに対応するために、PolarDBのIMCI機能を提供しています。

このセクションでは、JSON形式のデータ用の列指向ストレージ、仮想列、インスタントDDL、テーブル内の列の拡張最大数など、PolarDBのIMCI機能によって提供されるさまざまな機能について説明します。

JSON形式のデータの列指向ストレージ

構造化データと非構造化データの間のデータの形式として、半構造化データは部分的に構造化され、特定の関係または表形式のデータモデルが欠けています。半構造化データは、タグ、マーカー、およびメタデータなどの構造要素を使用することによって記述および編成することができるが、その構造および編成は、データの内容が変化するにつれて動的に調整することもできる。 webページのHTMLコード、XMLドキュメント、JSON形式のデータ、およびNoSQLデータベースのデータは、半構造化データの例です。半構造化データの柔軟性とスケーラビリティは、ビッグデータ時代の不可欠な部分です。

PolarDB for MySQLは、構造化データを格納するリレーショナルデータベース管理システムです。 PolarDB for MySQLは、XMLやJSON形式のデータなどの半構造化データの保存とクエリもサポートしています。 PolarDBのIMCI機能は、JSON形式のデータと列指向のJSON関数を完全にサポートしています。バイナリJSON形式を使用して半構造化データを格納し、列指向のJSON関数を使用してJSON形式のデータを解析、クエリ、変更、および削除します。 IMCIはMySQL構文と完全に互換性があります。

PolarDBのIMCI機能は、単純なバイナリ形式を使用してJSON形式のデータを列ごとに格納し、RapidJSONを使用してJSON形式のデータを解析します。データ処理中、データはオンデマンドで読み取られ、列指向ストレージの圧縮技術が使用されます。これは、消費されるI/Oリソースの量を効果的に減らす。また、SIMD (single instruction multiple data) 、ベクトル化、並列処理などの技術を使用して、コンピューティングを高速化します。

この例では、テストデータを使用して、JSON形式のデータに列指向ストレージを使用する方法を示し、行指向ストレージと列指向ストレージのクエリパフォーマンスを比較します。

テーブルを作成するときに、JSON列を追加し、JSON列にIMCIを作成します。

create table produce (
 id bigint(20) NOT NULL,
 attributes json DEFAULT NULL
) comment='columnar=1';

列指向のJSON関数を使用してデータをクエリします。

select count(*)
from produce
where attributes->"$.delivery.width" > 10 and attributes->"$.delivery.height" > 10 and attributes->"$.delivery.weight" > 10;

次のサンプルコードは、クエリの実行プランを示しています。

Project | Exprs: temp_table1.COUNT(0)
 HashGroupby | OutputTable(1): temp_table1 | Grouping: None | Output Grouping: None | Aggrs: COUNT(0)
 CTableScan | InputTable(0): produce | Pred: ((JSON_EXTRACT(produce.attributes, "$.delivery.width") > "10(json)") AND (JSON_EXTRACT(produce.attributes, "$.delivery.height") > "10(json)") AND (JSON_EXTRACT(produce.attributes, "$.delivery.weight") > "10(json)"))

次の表は、行指向ストレージと列指向ストレージの間のPolarDB内の数千万のデータエントリを含む農産物テーブルでSQL文を実行する期間を比較しています。

ストレージモデル	SQL実行期間
行指向ストレージ	9.29秒
IMCIが有効な列指向ストレージ (32コア)	0.14秒

上記のテスト結果は、列指向ストレージのクエリパフォーマンスが行指向ストレージのクエリパフォーマンスよりも2桁近く高いことを示しています。 PolarDBのIMCI機能は、JSON形式のデータをより効率的に分析できます。オンラインビジネスのクエリパフォーマンスは、データセットとクエリモードによって異なる場合があります。テストデータは参照だけのためです。

仮想列

特殊なタイプの列として、仮想列には値が挿入または更新されませんが、同じテーブル内の他の列の値に基づいて動的に計算、マージ、またはフィルタリングされます。仮想列はデータクエリとインデックス作成に使用できますが、直接変更または削除することはできません。仮想列を使用すると、クエリごとにデータを計算する必要なく、データにすばやくアクセスして処理できます。これにより、データクエリが最適化され、操作が簡素化されます。

仮想列を実装するために、PolarDBのIMCI機能は、仮想生成列と格納生成列の2種類の生成列をサポートします。デフォルトでは、仮想生成列が使用されます。仮想生成列の計算値は、列指向テーブルに永続的に格納されますが、行指向テーブルには格納されません。行指向テーブルが読み取られるたびに、仮想生成列の値がリアルタイムで計算されます。格納された生成列の計算値は、列指向テーブルと行指向テーブルに永続的に格納されますが、より多くのディスクスペースを占有します。 PolarDBのIMCI機能を使用する場合は、仮想生成列を使用することを推奨します。仮想生成された列は、ディスクスペースを節約するだけでなく、列指向ストレージのパフォーマンスも向上します。

次のサンプルコードは、仮想列を定義するために使用される構文を示しています。

col_name data_type [GENERATED ALWAYS] AS (expr)
 [VIRTUAL | STORED] [NOT NULL | NULL]
 [UNIQUE [KEY]] [[PRIMARY] KEY]
 [COMMENT 'string']

この例では、テストデータを使用して、仮想列を使用する方法と、行指向ストレージと列指向ストレージのクエリパフォーマンスを比較する方法を示します。

テーブルを作成するときに、仮想列を追加し、その仮想列にIMCIを作成します。

create table produce (
 id bigint(20) NOT NULL,
 attributes json DEFAULT NULL,
 `delivery_volume` double GENERATED ALWAYS AS (((json_extract(`attributes`,'$.delivery.width') * json_extract(`attributes`,'$.delivery.height')) * json_extract(`attributes`,'$.delivery.weight'))) VIRTUAL
) comment='columnar=1';

通常の列と仮想列のデータを照会します。
- 通常の列のデータを照会します。
```
select count(*)
from produce
where (attributes->"$.delivery.width" * attributes->"$.delivery.height" * attributes->"$.delivery.weight") > 1000;
```
  次のサンプルコードは、クエリの実行プランを示しています。
```
Project | Exprs: temp_table1.COUNT(0)
 HashGroupby | OutputTable(1): temp_table1 | Grouping: None | Output Grouping: None | Aggrs: COUNT(0)
 CTableScan | InputTable(0): produce | Pred: ((CAST JSON_EXTRACT(produce.attributes, "$.delivery.width")/JSON as DOUBLE(38, 31)) * (CAST JSON_EXTRACT(produce.attributes, "$.delivery.height")/JSON as DOUBLE(38, 31)) * (CAST JSON_EXTRACT(produce.attributes, "$.delivery.weight")/JSON as DOUBLE(38, 31)) > 1000.000000)
```
  次の表は、PolarDBの行指向ストレージと列指向ストレージの間の数千万のデータエントリを含む農産物テーブルの通常の列でSQL文を実行する期間を比較しています。
  ストレージモデル
  SQL実行期間
  行指向ストレージ
  13.43秒
  IMCIが有効な列指向ストレージ (1コア)
  5.72秒
  IMCIが有効な列指向ストレージ (32コア)
  0.24秒
- 仮想列のデータを照会します。
```
select count(*)
from produce
where delivery_volume > 1000;
```
  次のサンプルコードは、クエリの実行プランを示しています。
```
Project | Exprs: temp_table1.COUNT(0)
 HashGroupby | OutputTable(1): temp_table1 | Grouping: None | Output Grouping: None | Aggrs: COUNT(0)
 CTableScan | InputTable(0): produce | Pred: (produce.delivery_volume > 1000.000000)
```
  次の表は、PolarDBの行指向ストレージと列指向ストレージの間の数千万のデータエントリを含む農産物テーブルの仮想列でSQL文を実行する期間を比較しています。
  ストレージモデル
  SQL実行期間
  行指向ストレージ
  14.30秒
  IMCIが有効な列指向ストレージ (1コア)
  0.03秒
  IMCIが有効な列指向ストレージ (32コア)
  0.01秒

上記のテスト結果は、PolarDBのIMCI機能が仮想列を使用することでクエリのパフォーマンスを効果的に改善できることを示しています。オンラインビジネスのクエリパフォーマンスは、データセットとクエリモードによって異なる場合があります。テストデータは参照だけのためです。

PolarDB for MySQLの仮想列機能は、柔軟で強力です。 JSON形式のデータなどの半構造化データを処理する場合、仮想列を使用して不規則なデータを構造化データとして保存できます。これにより、データ処理のためにETLジョブを実行する必要がなくなり、データクエリと分析に従来のSQL構文を使用できます。仮想列は、複雑なコンピューティングとクエリを簡素化し、データベースアーキテクチャの柔軟性を向上させ、行指向ストレージによるデータの冗長性を回避します。仮想列にIMCIを作成した後、列指向ストレージのプルーナーメカニズムを使用してデータをフィルタリングできます。これにより、クエリのパフォーマンスが効果的に向上します。

インスタントDDL

ビジネス要件に基づいて半構造化データのJSON列を追加または削除する必要がある場合は、DDLステートメントを実行して、テーブルに列を追加またはテーブルから列を削除できます。この場合、効率的に列を追加または削除するための機能が必要です。半構造化データの構造が変更されるたびに、テーブルのスキーマを変更する必要はありません。テーブルでデータが頻繁にクエリされない場合は、列指向のJSON関数を使用して、クエリごとにリアルタイムでデータを計算できます。ほとんどの場合、PolarDBのIMCI機能をJSON形式のデータに使用すると、リアルタイムコンピューティングでクエリのパフォーマンス要件を満たすことができます。

PolarDBのIMCI機能は、仮想列を即座に追加または削除するのに役立つインスタントDDL機能を提供します。この機能では、読み取りおよび書き込み操作を実行でき、通常のデータクエリは影響を受けません。

次のサンプルコードは、インスタントDDL機能を使用して仮想列を追加するために使用される構文を示しています。

alter table produce add column delivery_volume DOUBLE AS (attributes->"$.delivery.width" * attributes->"$.delivery.height" * attributes->"$.delivery.weight");

次のサンプルコードは、インスタントDDL機能を使用して仮想列を削除するために使用される構文を示しています。

alter table produce drop column delivery_volume;

テーブル内の最大列数の拡張

半構造化データの属性が処理され、仮想列として大きなワイドテーブルに挿入された後、半構造化データの属性が増加するにつれて、大きなワイドテーブル内の列の数が増加する。ネイティブMySQLデータベースのテーブルの最大列数は、テーブルで使用されるストレージエンジンの制限によって異なります。たとえば、InnoDBストレージエンジンは、テーブル内の最大1,017列をサポートします。行指向のテーブルの場合、テーブル内の最大列数の制限は、ほとんどのビジネス要件を満たしています。リレーショナルデータベースのテーブルスキーマ設計中に、大きなワイドテーブルはめったに使用されません。多数の列を含むテーブルは、クエリ中により多くのI/Oおよびメモリリソースを消費しますが、クエリの効率が低下します。たとえば、特定の列からデータを読み取る必要がある場合は、すべての行を読み取る必要があります。ほとんどの場合、大きなテーブルを分割するか、小さなテーブルを結合してテーブルスキーマを最適化します。列指向ストレージを使用する場合、大規模なテーブルは、クエリの効率を向上させ、テーブルの結合を防ぐことができるため、推奨されます。列指向テーブルでは、データは列ごとに格納され、より良い圧縮効果を実現します。特定の列からデータを読み取る必要がある場合は、これらの列のみを読み取る必要があります。これは、消費されるI/Oリソースの量を効果的に減らす。

半構造化データの処理中に、PolarDBのIMCI機能は、必要に応じて半構造化データのいくつかの属性を変換し、変換されたデータをテーブルの個別の仮想列に挿入します。半構造化データに多数の属性が含まれている場合、テーブル内の列の数が制限を超えることがあります。したがって、PolarDBのIMCI機能は、InnoDBストレージエンジンを使用して4,089する列指向テーブルの最大列数を拡張します。

リアルタイムデータ分析

半構造化データを分析するために、PolarDBのIMCI機能は、JSON形式のデータや仮想列の列指向ストレージなどの機能を実装します。このセクションでは、PolarDBのIMCI機能に基づいて開発されたリアルタイムデータ分析ソリューションを、2023年7月のGitHubのリアルタイムイベントデータを使用してテストします。

GitHubのリアルタイムイベントデータは、GH ArchiveからJSON形式でダウンロードできます。たとえば、wgetコマンドを実行して、7月2023日の1時間ごとにデータをダウンロードできます。データがダウンロードされたら、データを解析し、github_eventsという名前のテーブルにデータを挿入します。

GitHubイベントタイプに基づいてgithub_eventsテーブルを定義します。

create table github_events (id bigint, type varchar(16), public bit, payload json, repo json, actor json, org json, created_at datetime);

GitHubについて常に知りたいことすべてからSQL文を選択し、SQL文を書き直して2つのクエリを実行します。

1週間で最も人気のあるプログラミング言語を照会します。

SELECT
    repo_language AS language,
    count(*) AS total
FROM
    github_events
WHERE
    created_at >= "2023-07-25 00:00:00"
    AND created_at <= "2023-07-31 23:59:59"
    AND repo_language IS NOT NULL
GROUP BY
    repo_language
ORDER BY
    total DESC
LIMIT 10;

すべてのLinuxリポジトリを星の数に基づいてランク付けします。

SELECT repo_name, count(*) AS stars
FROM github_events
WHERE (type = 'WatchEvent') AND (actor_login IN
(
    SELECT actor_login
    FROM github_events
    WHERE (type = 'WatchEvent') AND (repo_name IN ('torvalds/linux')) AND created_at >= "2023-07-31 00:00:00" AND created_at <= "2023-07-31 23:59:59"
)) AND (repo_name NOT IN ('torvalds/linux')) AND created_at >= "2023-07-31 00:00:00" AND created_at <= "2023-07-31 23:59:59"
GROUP BY repo_name
ORDER BY stars DESC
LIMIT 10;

上記のSQL文に基づいて、actor_login、repo_name、repo_languageなどの仮想列をgithub_eventsテーブルに追加し、IMCIを作成します。

alter table github_events add column actor_login varchar(256) generated always as (json_unquote(json_extract(`actor`,'$.login'))) virtual, add column repo_name varchar(256) generated always as (json_unquote(json_extract(`repo`,'$.name'))) virtual, add column repo_language varchar(32) generated always as (json_unquote(json_extract(`payload`,'$.pull_request.base.repo.language'))) virtual, comment 'columnar=1';

キャッシュサイズを行指向ストレージの場合は500 GB、列指向ストレージの場合は128 GBに設定します。次の表は、行指向ストレージと列指向ストレージの間のホットデータに対するSQL文の実行期間を比較しています。

ストレージモデル	クエリ1のSQL実行期間	クエリ2のSQL実行期間
行指向ストレージ	45.01秒	8.57秒
IMCIが有効な列指向ストレージ (1コア)	0.79秒	0.54秒
IMCIが有効な列指向ストレージ (32コア)	0.04秒	0.07秒

上記のテスト結果は、PolarDBのIMCI機能に基づいて開発されたリアルタイムデータ分析ソリューションが、行指向ストレージよりもはるかに優れたパフォーマンスを発揮することを示しています。このソリューションを使用して、大量の半構造化データを効率的に分析できます。

拡張ストリームコンピューティング

拡張ストリームコンピューティングソリューションは、大量の半構造化データの分析に役立つ自動化ソリューションとして、PolarDBのIMCI機能に基づいて開発されています。このソリューションでは、JSON形式のデータの列指向ストレージ、仮想列、インスタントDDL、テーブル内の列の拡張最大数など、このトピックで説明するIMCIのさまざまな機能を統合します。

ストリームコンピューティングは、連続データストリームに基づいてリアルタイムでデータを計算および分析するリアルタイムデータ処理技術です。軽量ストリームコンピューティングの一種として、拡張ストリームコンピューティングはデータストリームの処理とリアルタイムでのコンピューティング結果の提供に重点を置いています。一方、拡張ストリームコンピューティングは、コンピューティングリソースの使用を最小限に抑え、システムの複雑さを減らすことを目的としています。従来のストリームコンピューティングと比較して、拡張ストリームコンピューティングは、軽量、迅速な応答、および自動化により多くの注意を払っています。

PolarDBのIMCI機能に基づいて開発された拡張ストリームコンピューティングソリューションでは、SQL文を使用して、データストリームの処理ロジックを列指向テーブルのスキーマの式または関数として定義し、処理ロジックを仮想列として記録します。次に、拡張ストリームコンピューティングフレームワークは、ビジネスデータストリームに基づいてリアルタイムでデータを自動的に計算し、計算されたデータを列指向テーブルに永続的に格納します。クエリ中、IMCIを使用して計算データを読み取ります。拡張ストリームコンピューティングプロセスは、PolarDBのIMCI機能と統合されています。異なるデータストリームの処理ロジックを仮想列として定義するには、DDL文を実行するだけです。ビジネス要件が変更された場合、DDL文を実行して仮想列を追加または変更するだけで済みます。

大量の半構造化データを分析するには、JSON関数とJSON形式のデータの属性を使用して、ビジネス要件に基づいてデータストリームの処理ロジックを仮想列として定義し、仮想列にIMCIを作成します。次に、PolarDBのIMCI機能を使用して、連続データストリームに基づいてリアルタイムでデータを自動的に計算および保存し、大規模なテーブルを継続的に更新できます。クエリ中に、IMCIを使用して、指定した仮想列のデータをクエリできます。これにより、JSON列のすべてのデータが繰り返し読み取られたり解析されたりするのを防ぎ、クエリの効率を効果的に向上させます。 JSON関数を使用してデータをクエリする場合、PolarDBオプティマイザはまず、JSON関数とJSON列に基づいて仮想列が一致するかどうかをクエリします。クエリのパフォーマンスを向上させるために、一致する仮想列が優先的に選択およびクエリされます。ビジネスシステムのビジネス要件に基づいてJSON形式のデータの属性を追加、削除、または変更した後、インスタントDDL機能を使用して列を追加または削除するだけで済みます。これにより、従来のデータウェアハウスのようにETLジョブを実行する必要がなくなり、テーブルスキーマを即座に変更できます。これにより、追加のメンテナンスコストなしでビジネス要件の変更に柔軟に対応でき、ビジネスに影響を与えません。更新されたデータが頻繁に照会されない場合は、テーブルスキーマを変更する必要はありません。列指向のJSON関数を使用して、各クエリのデータをリアルタイムで解析できます。これは、ほとんどのビジネス要件も満たしています。

要約すると、PolarDBのIMCI機能に基づいて開発された拡張ストリームコンピューティングソリューションは、従来のデータベースの柔軟性と従来のデータウェアハウスの効率性の両方を備えています。このソリューションは、大量の半構造化データを分析する必要がある場合に適しています。

お客様のユースケース

ストリーミングプラットフォーム

ストリーミングプラットフォームは、中国で最も人気のあるオンラインビデオプラットフォームの1つです。このプラットフォームは、映画、テレビドラマ、バラエティ番組、ライブストリーミングなどのビデオと機能を提供します。ユーザーは、より良い視聴体験を得るために、有料加入者としてプラットフォームに加入できます。

多数の加入者に基づいて、トランザクションデータの量は毎日急速に拡大します。加入者の取引データは、リアルタイムテーブルに別々に記憶される。このデータは、ビジネス報酬および検証、注文ステータスのリアルタイム監視、自動注文管理、および加入者特典の自動処理などの機能を実装するために使用されます。

元のデータベースシステムは、MySQLのシャーディングを使用して、加入者のトランザクションデータを処理します。データベースは、アーキテクチャが1つのプライマリノードと複数の読み取り専用ノードで構成されるMySQLクラスターにデプロイされます。トランザクションデータの量が増加すると、MySQLクラスターをスケールアウトするためにパーティションと読み取り専用ノードの数が増加します。データは、バイナリログを使用してノード間で同期されます。高速な反復に対処するために、JSON形式のデータなどの大量の半構造化データが生成され、データベースシステムで処理されます。ビジネスの急速な発展に伴い、大規模なテーブル内のJSON形式のデータに対して同時並行性の高いクエリが実行されます。このようなクエリを処理するために、既存のデータベースアーキテクチャでは、データベースおよびパーティションの数が継続的に増加する。これにより、O&M操作が複雑になり、O&Mコストが高くなり、クエリのパフォーマンスが低下する可能性があります。

この場合、ストリーミングプラットフォームには、コストを削減し効率を高めるために、O&M操作を簡素化した新しいデータベースアーキテクチャが必要です。新しいデータベースアーキテクチャは、Alibaba Cloudの支援を受けて、PolarDBのオールインワンハイブリッドトランザクション /分析処理 (HTAP) ソリューションを採用しています。このソリューションは、拡張ストリームコンピューティングと列指向ストレージを最大限に活用して、JSON形式の大量データの分析パフォーマンスを向上させ、O&M操作を効果的に簡素化します。

金融eコマースプラットフォーム

金融eコマースプラットフォームは、シンガポールに本社を置き、2016年に設立された金融テクノロジー企業によって運営されています。このプラットフォームは、東南アジアの消費者金融サービスを提供します。提供されるサービスには、分割払い、クレジットローン、仮想クレジットカード、および電子商取引サービスが含まれます。このプラットフォームには、インドネシア、フィリピン、マレーシア、タイ、ベトナムなどの東南アジア諸国に数百万人のユーザーがおり、東南アジアの主要な消費者金融サービスプロバイダーの1つになっています。

プラットフォームの注文ビジネスシステムは、トランザクション処理システムとデータ分析システムに分けることができます。トランザクション処理システムは、JSON形式のデータを使用してさまざまなビジネス属性を格納しますが、データ分析システムは、多数のビジネス属性を計算および分析する必要があります。

元のデータベースシステムでは、ビジネストランザクションを処理するためにMySQLクラスターがデプロイされ、ビジネスデータを分析するためにClickHouseクラスターがデプロイされます。 Apache Flinkは、MySQLデータストリームをサブスクライブし、JSON形式のデータを構造化データに変換して大きなワイドテーブルを構築し、そのテーブルをClickHouseクラスターにリアルタイムで挿入するために使用されます。既存のデータベースアーキテクチャの複雑さにより、データ処理中のデータ損失、データ分析の遅延、および不十分なクエリ性能などの問題が発生する可能性があります。ビジネス要件に基づいてJSON形式のデータの属性を追加、削除、または変更する場合は、Flinkの処理ロジックとClickHouseテーブルのスキーマを変更する必要があります。ただし、ClickHouseはインスタントDDL機能をサポートしていません。これにより、大きなテーブルの変更に必要な時間が延長され、クエリのパフォーマンスに影響します。ビジネスが発展するにつれて、プラットフォームのアーキテクトは、システムの安定性、簡素化されたO&M操作、パフォーマンス分析、およびコスト削減を特徴とする新しいデータベースアーキテクチャを緊急に必要としています。

リアルタイムトランザクション処理とリアルタイムデータ分析を統合したPolarDBのクラウドネイティブHTAPソリューションが最適です。 MySQL、Data Transmission Service (DTS) 、Apache Flink、ClickHouseなどの複数のシステムを統合する元のデータベースシステムと比較して、新しいデータベースシステムはPolarDBのみに基づくシンプルなアーキテクチャを備えています。新しいデータベースアーキテクチャでは、Apache Flinkの代わりにPolarDBのIMCI機能に基づいて開発された拡張ストリームコンピューティングソリューションを使用して、半構造化データを構造化データに自動的に変換します。さらに、インスタントDDL機能を使用してO&M操作を簡素化し、テーブル内の最大列数を拡張することで迅速なビジネス開発をサポートし、列指向ストレージにより分析パフォーマンスが向上します。