Lindorm:データ圧縮テスト

背景情報

Lindorm は、複数のオープンソースサービスと互換性があり、クラウドネイティブのスケーラビリティを提供するマルチモデルハイパーコンバージドデータベースサービスです。さらに、Lindorm を使用すると、データベース内のデータを効率的に圧縮できます。 Lindorm は、データ圧縮用の zstd アルゴリズムをサポートし、辞書サンプリングを最適化してストレージコストを削減します。

このトピックで説明するデータ圧縮テストでは、特定のバージョンの以下のデータベースサービスが使用されます。

• Lindorm: 最新バージョンの Lindorm が使用されます。デフォルトでは、最適化された zstd 圧縮アルゴリズムが使用され、辞書ベースの圧縮がサポートされています。

• オープンソース HBase: HBase V2.3.4 が使用されます。 HBase は、Hadoop の新しいバージョンを使用する場合、zstd 圧縮アルゴリズムをサポートしています。ただし、データの圧縮は安定しておらず、コアダンプが発生しやすいです。ほとんどのオープンソース HBase ユーザーは SNAPPY 圧縮アルゴリズムを使用しています。

• オープンソース MySQL: MySQL 8.0 が使用されます。デフォルトでは、データ圧縮は無効になっています。 MySQL は ZLIB 圧縮アルゴリズムをサポートしています。ただし、データ圧縮を有効にすると、MySQL データベースのクエリパフォーマンスが大幅に低下します。そのため、MySQL ユーザーが MySQL データベースのデータ圧縮を有効にすることはほとんどありません。

• オープンソース MongoDB: MongoDB 5.0 が使用されます。デフォルトでは、SNAPPY 圧縮アルゴリズムが使用されます。ユーザーは、データ圧縮に SNAPPY アルゴリズムの代わりに zstd アルゴリズムを選択することもできます。

このトピックでは、Lindorm が一般的に使用される以下のシナリオ（注文、車載インターネット (IoV)、ログ、ユーザー行動）でデータ圧縮テストが実行されます。各テストシナリオでは、異なる圧縮アルゴリズムを使用する以下のデータベースサービスのデータ圧縮機能がテストおよび比較されます。デフォルトの zstd アルゴリズムを使用する Lindorm、辞書ベースの圧縮が有効になっている Lindorm、SNAPPY アルゴリズムを使用するオープンソース HBase、データ圧縮が無効になっているオープンソース MySQL、SNAPPY アルゴリズムを使用するオープンソース MongoDB、zstd アルゴリズムを使用するオープンソース MongoDB。

さまざまなシナリオでのテスト結果と結論の詳細については、「概要」をご参照ください。

注文

# unzip TPC-H_Tools_v3.0.0.zip
# cd TPC-H_Tools_v3.0.0/dbgen
# cp makefile.suite makefile
# vim makefile
################Oracle データベースのスクリプトとデータを生成します。以下のフィールドの値を変更します。
CC = gcc
DATABASE = ORACLE
MACHINE = LINUX
WORKLOAD = TPCH
################
# make -- dbgen プログラムを生成します。
# ./dbgen -s 10 -- 10 GB のテストデータを生成します。

create 'ORDERS', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}

CREATE TABLE ORDERS  ( O_ORDERKEY       INTEGER NOT NULL,
                       O_CUSTKEY        INTEGER NOT NULL,
                       O_ORDERSTATUS    CHAR(1) NOT NULL,
                       O_TOTALPRICE     DECIMAL(15,2) NOT NULL,
                       O_ORDERDATE      DATE NOT NULL,
                       O_ORDERPRIORITY  CHAR(15) NOT NULL,
                       O_CLERK          CHAR(15) NOT NULL,
                       O_SHIPPRIORITY   INTEGER NOT NULL,
                       O_COMMENT        VARCHAR(79) NOT NULL);

db.createCollection("ORDERS")

# lindorm-cli
CREATE TABLE ORDERS  ( O_ORDERKEY       INTEGER NOT NULL,
                      O_CUSTKEY        INTEGER NOT NULL,
                      O_ORDERSTATUS    CHAR(1) NOT NULL,
                      O_TOTALPRICE     DECIMAL(15,2) NOT NULL,
                      O_ORDERDATE      DATE NOT NULL,
                      O_ORDERPRIORITY  CHAR(15) NOT NULL,
                      O_CLERK          CHAR(15) NOT NULL,
                      O_SHIPPRIORITY   INTEGER NOT NULL,
                      O_COMMENT        VARCHAR(79) NOT NULL,
                      primary key(O_ORDERKEY));

IoV

このシナリオでは、次世代シミュレーション (NGSIM) データセットがデータ圧縮テストに使用されます。 NGSIM は、米国連邦道路局によって開始されたデータ収集プロジェクトです。このプロジェクトは、車両追跡や車線変更などの運転行動の研究、交通流分析、マイクロ交通モデル構築、車両軌跡予測、自動運転意思決定計画などに広く実装されています。すべての NGSIM データは、米国ルート 101 の実際の車両の軌跡から収集されます。

create 'NGSIM', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}

CREATE TABLE NGSIM ( ID								 INTEGER NOT NULL,
                     Vehicle_ID				 INTEGER NOT NULL,
                     Frame_ID					 INTEGER NOT NULL,
                     Total_Frames			 INTEGER NOT NULL,
                     Global_Time			 BIGINT NOT NULL,
                     Local_X					 DECIMAL(10,3) NOT NULL,
                     Local_Y					 DECIMAL(10,3) NOT NULL,
                     Global_X					 DECIMAL(15,3) NOT NULL,
                     Global_Y					 DECIMAL(15,3) NOT NULL,
                     v_length					 DECIMAL(10,3) NOT NULL,
                     v_Width					 DECIMAL(10,3) NOT NULL,
                     v_Class					 INTEGER NOT NULL,
                     v_Vel						 DECIMAL(10,3) NOT NULL,
                     v_Acc						 DECIMAL(10,3) NOT NULL,
                     Lane_ID					 INTEGER NOT NULL,
                     O_Zone						 CHAR(10),
                     D_Zone						 CHAR(10),
                     Int_ID						 CHAR(10),
                     Section_ID				 CHAR(10),
                     Direction				 CHAR(10),
                     Movement					 CHAR(10),
                     Preceding				 INTEGER NOT NULL,
                     Following				 INTEGER NOT NULL,
                     Space_Headway		 DECIMAL(10,3) NOT NULL,
                     Time_Headway			 DECIMAL(10,3) NOT NULL,
                     Location					 CHAR(10) NOT NULL,
                     PRIMARY KEY(ID));

db.createCollection("NGSIM")

# lindorm-cli
CREATE TABLE NGSIM ( ID								 INTEGER NOT NULL,
                     Vehicle_ID				 INTEGER NOT NULL,
                     Frame_ID					 INTEGER NOT NULL,
                     Total_Frames			 INTEGER NOT NULL,
                     Global_Time			 BIGINT NOT NULL,
                     Local_X					 DECIMAL(10,3) NOT NULL,
                     Local_Y					 DECIMAL(10,3) NOT NULL,
                     Global_X					 DECIMAL(15,3) NOT NULL,
                     Global_Y					 DECIMAL(15,3) NOT NULL,
                     v_length					 DECIMAL(10,3) NOT NULL,
                     v_Width					 DECIMAL(10,3) NOT NULL,
                     v_Class					 INTEGER NOT NULL,
                     v_Vel						 DECIMAL(10,3) NOT NULL,
                     v_Acc						 DECIMAL(10,3) NOT NULL,
                     Lane_ID					 INTEGER NOT NULL,
                     O_Zone						 CHAR(10),
                     D_Zone						 CHAR(10),
                     Int_ID						 CHAR(10),
                     Section_ID				 CHAR(10),
                     Direction				 CHAR(10),
                     Movement					 CHAR(10),
                     Preceding				 INTEGER NOT NULL,
                     Following				 INTEGER NOT NULL,
                     Space_Headway		 DECIMAL(10,3) NOT NULL,
                     Time_Headway			 DECIMAL(10,3) NOT NULL,
                     Location					 CHAR(10) NOT NULL,
                     PRIMARY KEY(ID)) ;

ログ

このシナリオでは、Web サーバーログの次のデータセットがデータ圧縮テストに使用されます: Zaker, Farzin, 2019, "Online Shopping Store - Web Server Logs", https://doi.org/10.7910/DVN/3QBYB5, Harvard Dataverse, V1。

54.36.149.41 - - [22/Jan/2019:03:56:14 +0330] "GET /filter/27|13%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,27|%DA%A9%D9%85%D8%AA%D8%B1%20%D8%A7%D8%B2%205%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,p53 HTTP/1.1" 200 30577 "-" "Mozilla/5.0 (compatible; AhrefsBot/6.1; +http://ahrefs.com/robot/)" "-"

create 'ACCESS_LOG', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}

CREATE TABLE ACCESS_LOG  ( ID        INTEGER NOT NULL,
                           CONTENT   VARCHAR(10000),
                           PRIMARY KEY(ID));

db.createCollection("ACCESS_LOG")

# lindorm-cli
CREATE TABLE ACCESS_LOG  ( ID        INTEGER NOT NULL,
                           CONTENT   VARCHAR(10000),
                           PRIMARY KEY(ID));

ユーザー行動

このシナリオでは、Alibaba Cloud Tianchi から取得した次のデータセットがデータ圧縮テストに使用されます: IJCAI-15 のショップ情報とユーザー行動データ。

create 'USER_LOG', {NAME => 'f', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'SNAPPY', BLOCKSIZE => '32768}

CREATE TABLE USER_LOG  ( ID            INTEGER NOT NULL,
                         USER_ID       INTEGER NOT NULL,
                         ITEM_ID       INTEGER NOT NULL,
                         CAT_ID        INTEGER NOT NULL,
                         SELLER_ID     INTEGER NOT NULL,
                         BRAND_ID      INTEGER,
                         TIME_STAMP    CHAR(4) NOT NULL,
                         ACTION_TYPE   CHAR(1) NOT NULL,
                         PRIMARY KEY(ID));

db.createCollection("USER_LOG")

# lindorm-cli
CREATE TABLE USER_LOG  ( ID            INTEGER NOT NULL,
                         USER_ID       INTEGER NOT NULL,
                         ITEM_ID       INTEGER NOT NULL,
                         CAT_ID        INTEGER NOT NULL,
                         SELLER_ID     INTEGER NOT NULL,
                         BRAND_ID      INTEGER,
                         TIME_STAMP    CHAR(4) NOT NULL,
                         ACTION_TYPE   CHAR(1) NOT NULL,
                         PRIMARY KEY(ID));

概要

上記のシナリオでのテスト結果に基づくと、Lindorm はさまざまな種類の大量のデータをより高い圧縮率で圧縮できます。他のオープンソースデータベースと比較して、Lindorm は、辞書ベースの圧縮が有効になっていない場合でも、大幅に高い圧縮率を提供できます。辞書ベースの圧縮を有効にすると、Lindorm は、オープンソースの HBase の 1 ～ 2 倍、オープンソースの MongoDB の 2 ～ 4 倍、オープンソースの MySQL の 3 ～ 10 倍の圧縮率でデータを圧縮できます。

次の表に、さまざまなシナリオでのテスト結果を示します。