Lindorm:Uji kompresi data

Lingkungan pengujian

Lindorm adalah layanan database hyper-converged multi-model yang secara default menggunakan algoritma kompresi zstd dan mendukung kompresi berbasis kamus, yang meningkatkan rasio kompresi dengan mengoptimalkan pengambilan sampel kamus selama pengkodean data.

Tabel berikut menunjukkan versi database dan konfigurasi kompresi yang digunakan dalam pengujian ini.

Setiap skenario menguji dan membandingkan konfigurasi berikut:

• Lindorm dengan zstd (default)

• Lindorm dengan kompresi berbasis kamus diaktifkan

• Open source HBase dengan Snappy

• Open source MySQL dengan kompresi dinonaktifkan

• Open source MongoDB dengan Snappy

• Open source MongoDB dengan zstd

Kapan menggunakan kompresi berbasis kamus

zstd vs. kompresi berbasis kamus:

Data yang paling diuntungkan oleh kompresi berbasis kamus: set data dengan struktur repetitif antar baris, seperti entri log, bidang telemetri IoV, dan catatan event perilaku.

Untuk hasil konsolidasi di semua skenario, lihat Ringkasan.

Pesanan

# Unzip dan build generator data
unzip TPC-H_Tools_v3.0.0.zip
cd TPC-H_Tools_v3.0.0/dbgen
cp makefile.suite makefile

# Edit makefile: atur bidang berikut
# CC = gcc
# DATABASE = ORACLE
# MACHINE = LINUX
# WORKLOAD = TPCH
make

# Buat 10 GB data uji
./dbgen -s 10

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)
);

Hasil kompresi

Database	Ukuran tabel
Lindorm (zstd)	784 MB
Lindorm (kompresi berbasis kamus)	639 MB
HBase (Snappy)	1,23 GB
MySQL (tanpa kompresi)	2,10 GB
MongoDB (Snappy)	1,63 GB
MongoDB (zstd)	1,32 GB

IoV

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)
);

Hasil kompresi

Database	Ukuran tabel
Lindorm (zstd)	995 MB
Lindorm (kompresi berbasis kamus)	818 MB
HBase (Snappy)	1,72 GB
MySQL (tanpa kompresi)	2,51 GB
MongoDB (Snappy)	1,88 GB
MongoDB (zstd)	1,50 GB

Log

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)
);

Hasil kompresi

Database	Ukuran tabel
Lindorm (zstd)	646 MB
Lindorm (kompresi berbasis kamus)	387 MB
HBase (Snappy)	737 MB
MySQL (tanpa kompresi)	3,99 GB
MongoDB (Snappy)	1,17 GB
MongoDB (zstd)	893 MB

Perilaku pengguna

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)
);

Hasil kompresi

Database	Ukuran tabel
Lindorm (zstd)	805 MB
Lindorm (kompresi berbasis kamus)	721 MB
HBase (Snappy)	1,48 GB
MySQL (tanpa kompresi)	2,90 GB
MongoDB (Snappy)	3,33 GB
MongoDB (zstd)	2,74 GB

Ringkasan

Lindorm mencapai rasio kompresi lebih tinggi daripada database open source bahkan tanpa mengaktifkan kompresi berbasis kamus. Dengan kompresi berbasis kamus, Lindorm mencapai rasio kompresi tertinggi di keempat skenario. Dibandingkan dengan konfigurasi default masing-masing database open source, Lindorm dengan kompresi berbasis kamus mengurangi ukuran data tersimpan sebesar:

• 1–2x lebih cepat daripada HBase sumber terbuka (Snappy)

• 2–4x lebih tinggi daripada MongoDB sumber terbuka (Snappy atau zstd)

• 3–10x lebih baik daripada open source MySQL (tidak dikompresi)

Tabel berikut mengkonsolidasikan semua hasil pengujian.

Memilih antara zstd dan kompresi berbasis kamus: zstd diaktifkan secara default dan mengurangi biaya penyimpanan untuk semua tipe data tanpa konfigurasi tambahan. Kompresi berbasis kamus memberikan pengurangan lebih lanjut—paling signifikan untuk data log (387 MB vs. 646 MB) dan paling kecil untuk data IoV yang banyak mengandung angka—dengan biaya langkah pelatihan kamus selama ingesti data.