Seiring pesatnya pertumbuhan volume data bisnis, banyak perusahaan menghadapi tantangan utama dalam mengelola biaya penyimpanan data skala besar sekaligus mempertahankan efisiensi analitik. Untuk mengatasi hal ini, PolarDB for MySQL menyediakan fitur tabel kolom X-Engine. Fitur ini dibangun di atas penyimpanan kolom, kompresi efisien, dan komputasi paralel untuk mengurangi biaya penyimpanan hingga 90% dari ukuran data asli serta meningkatkan kinerja kueri analitik hingga satu orde lebih tinggi. Fitur ini memungkinkan pengarsipan data skala besar berbiaya rendah dan analitik real-time berkinerja tinggi, sekaligus mempertahankan kompatibilitas penuh dengan ekosistem MySQL.
Ikhtisar
Tabel kolom X-Engine menggunakan arsitektur berbasis pemisahan komputasi dan penyimpanan. Pendekatan ini memungkinkan sumber daya komputasi dan penyimpanan diskalakan secara independen dan elastis, memberikan kemampuan pemrosesan data hingga skala petabyte. Lapisan penyimpanan dibangun di atas sistem file terdistribusi dan OSS. Lapisan komputasi menyediakan analitik berkinerja tinggi melalui optimalisasi mendalam pada Query optimizer, Execution operator, dan mesin penyimpanan.
Arsitektur teknis
PolarDB arsitektur keseluruhan
PolarDB menggunakan arsitektur pemisahan komputasi dan penyimpanan yang dibangun di atas lapisan penyimpanan terdistribusi. Sistem ini memanfaatkan protokol ParallelRaft untuk menjamin konsistensi multi-replika dan secara transparan mendukung OSS. Node komputasi terdiri dari satu node read-write (RW) dan satu atau lebih node read-only (RO), yang mendukung mesin InnoDB maupun X-Engine. Proksi database bertindak sebagai jembatan antara aplikasi dan node komputasi, menyediakan pemisahan baca/tulis dan penyeimbangan beban.
Arsitektur tabel kolom
Komponen teknis intinya meliputi:
-
Query optimizer: Pengoptimal berbasis biaya (CBO) bawaan untuk penyimpanan campuran baris-kolom. Pengoptimal ini memperkirakan biaya kueri dan secara otomatis memilih rencana eksekusi optimal, baik menggunakan penyimpanan baris maupun kolom.
-
Execution operator: Menggunakan teknik vektorisasi berorientasi kolom dan eksekusi paralel. Pemrosesan batch secara signifikan mempercepat kueri analitik baik pada tabel tunggal maupun penggabungan multi-tabel.
-
Storage engine: Mendukung pembaruan transaksional real-time. Tabel utama menggunakan penyimpanan kolom dan memanfaatkan komponen Non-Clustered Index (NCI) untuk memberikan kemampuan pembaruan cepat. Mekanisme delete-mask menandai data untuk penghapusan, memungkinkan kueri paralel efisien tanpa mengganggu operasi tulis real-time. Selain itu, indeks sekunder berbasis row-store dapat dengan cepat menyaring data yang tidak relevan, sehingga semakin meningkatkan efisiensi kueri.
Perbandingan jenis tabel
Tabel berikut membandingkan perbedaan utama antara tabel berorientasi baris tradisional (seperti InnoDB) dan tabel kolom PolarDB untuk membantu Anda memilih jenis yang tepat:
|
Aspek |
Tabel Berorientasi Baris (X-Engine) |
Tabel Kolom |
|
Organisasi Data |
Data disimpan secara berurutan per baris. Semua kolom untuk satu baris disimpan bersamaan. |
Data disimpan secara berurutan per kolom. Semua nilai untuk satu kolom disimpan bersamaan. |
|
Rasio Kompresi Data |
Sedang. Dibandingkan dengan InnoDB, data dapat dikompresi hingga 3/10 dari ukuran aslinya. |
Tinggi. Dengan penyimpanan kolom dan encoding khusus (seperti dictionary encoding), data dapat dikompresi hingga 1/10 dari ukuran aslinya dibandingkan dengan InnoDB. |
|
Kinerja Kueri |
Sangat baik untuk point lookups. Sangat cocok untuk skenario Online Transaction Processing (OLTP) yang melibatkan pembacaan satu atau beberapa baris secara cepat berdasarkan primary key atau indeks. |
Kuat untuk analitik. Kueri hanya membaca kolom yang relevan, sehingga secara signifikan mengurangi I/O. Dikombinasikan dengan komputasi paralel vektorisasi, kinerja analitiknya satu orde lebih tinggi dibandingkan tabel berorientasi baris. |
|
Kinerja Pembaruan dan Penghapusan |
Tinggi. Langsung menemukan dan memodifikasi baris. |
Relatif lebih rendah, tetapi mendukung pembaruan real-time. Komponen NCI membantu menemukan catatan yang akan dimodifikasi secara cepat. |
|
Kasus Penggunaan |
Online Transaction Processing (OLTP), seperti operasi insert, delete, update, dan query dengan konkurensi tinggi. |
Online Analytical Processing (OLAP), seperti pengarsipan data, pembuatan laporan, kueri ad-hoc, dan analisis data agregat skala besar. |
Manfaat
-
Efisiensi Biaya: Mengurangi biaya penyimpanan dan pemrosesan untuk dataset masif hingga 90% melalui kombinasi penyimpanan kolom, encoding efisien, algoritma kompresi tinggi, dan media penyimpanan berbiaya rendah seperti OSS.
-
Analitik Real-Time Berkinerja Tinggi: Data tersedia untuk kueri analitik segera setelah ditulis. Dengan memanfaatkan paralelisme multi-core, vektorisasi, dan teknologi Massively Parallel Processing (MPP), kinerja kueri setara dengan database analitik khusus, memenuhi tuntutan analisis real-time yang ketat.
-
Kompatibilitas 100% dengan MySQL: Menyediakan sistem tipe data dan protokol yang konsisten dengan MySQL serta mendukung konversi tipe fleksibel. Anda dapat menghubungkan aplikasi dan alat yang sudah ada tanpa modifikasi.
-
Skalabilitas Elastis Independen: Pemisahan komputasi dan penyimpanan memungkinkan penskalaan independen sesuai permintaan untuk node komputasi dan ruang penyimpanan guna mengatasi lonjakan bisnis dan pertumbuhan data.
-
Dukungan Tabel Lebar yang Kuat: Satu tabel dapat mendukung hingga 10.000 kolom, memenuhi kebutuhan bisnis untuk penyimpanan tabel lebar dan operasi tulis dengan konkurensi tinggi.
-
Keandalan Penggunaan: Menyederhanakan tumpukan teknologi dan manajemen operasional dengan mendukung penyimpanan berkompressi tinggi dan analitik berkinerja tinggi dalam satu mesin database, serta dukungan penuh untuk operasi DDL dan DML.
Kasus penggunaan
Pengarsipan data berbiaya rendah
-
Permasalahan: Seiring pertumbuhan bisnis, data historis seperti pesanan lama, log, dan catatan transaksi dapat menumpuk dengan cepat di database inti, menghabiskan ruang penyimpanan mahal. Meskipun solusi migrasi data tradisional dapat mengurangi biaya, data tersebut sering kali di-offline-kan, sehingga akses online menjadi kompleks.
-
Solusi: Gunakan tabel kolom untuk pengarsipan data online. Anda dapat memigrasikan data dingin dari tabel berorientasi baris (InnoDB) atau seluruh tabel data historis ke tabel kolom dalam kluster PolarDB yang sama.
-
Nilai Inti:
-
Biaya jauh lebih rendah: Dengan rasio kompresi hingga 10:1 dan penggunaan media penyimpanan berbiaya rendah seperti OSS, biaya penyimpanan dapat dikurangi hingga 90%.
-
Ketersediaan data online: Data yang diarsipkan tetap online dan tersedia. Anda dapat mengkueri dan menganalisisnya kapan saja menggunakan SQL standar tanpa proses migrasi data yang rumit.
-
Integrasi aplikasi mulus: Dari perspektif aplikasi, tabel kolom berfungsi seperti tabel MySQL biasa, tanpa perlu perubahan kode.
-
Gudang data khusus
-
Permasalahan: Saat membangun gudang data khusus, perusahaan sering menghadapi biaya perangkat keras tinggi, pipeline sinkronisasi data (ETL) yang kompleks, dan kurva pembelajaran operasional yang curam, terutama saat memperkenalkan teknologi baru seperti ClickHouse.
-
Solusi: Anda dapat memanfaatkan kapasitas penyimpanan masif PolarStore untuk mengagregasi data dari berbagai sumber hulu dan menyimpannya secara seragam dalam tabel kolom X-Engine. Hal ini memungkinkan Anda memperoleh manfaat penyimpanan masif berbiaya rendah dan kinerja analisis agregat real-time.
-
Nilai Inti:
-
Biaya dan kompleksitas lebih rendah: Bangun gudang data dalam ekosistem MySQL yang sudah dikenal tanpa perlu membeli perangkat keras khusus yang mahal atau memperkenalkan sistem analitik heterogen. Pendekatan ini menyederhanakan stack teknologi dan mengurangi beban operasional.
-
Analisis data real-time: Mendukung konsolidasi data hulu secara real-time ke tabel kolom untuk analisis, menghindari latensi data T+1 yang umum pada solusi ETL tradisional.
-
Kapasitas pemrosesan data masif: Arsitektur penyimpanan X-Engine dan kompresi efisien memungkinkan penyimpanan dan pemrosesan data skala petabyte dengan biaya rendah.
-
Analisis kueri federasi
-
Permasalahan: Data bisnis sering kali tersebar di berbagai sistem. Sebagian data berada di database online seperti PolarDB, sedangkan data lain disimpan dalam format terbuka seperti Parquet atau ORC di OSS. Menganalisis dataset yang terpisah ini biasanya memerlukan proses ETL kompleks untuk mengimpor data OSS ke dalam database.
-
Solusi: Gunakan fitur tabel eksternal PolarDB untuk langsung mengkueri data di OSS.
-
Nilai Inti:
-
Analisis in-place: Kueri data di tempat asalnya. Buat tabel eksternal di PolarDB yang mengarah ke file Anda di OSS, lalu gunakan SQL standar untuk mengkuerinya langsung tanpa memindahkan atau mengimpor data tersebut.
-
Kueri federasi: Lakukan operasi
JOINdengan mudah antara tabel lokal di PolarDB (baik berorientasi baris maupun kolom) dan tabel eksternal OSS untuk menjalankan analisis terpadu antara data online dan offline.
-
Kinerja
Data kinerja berikut diperoleh dalam lingkungan pengujian tertentu dan berfungsi sebagai referensi untuk mengevaluasi manfaat tabel kolom.
Implementasi TPC-H dalam topik ini didasarkan pada pengujian benchmark TPC-H. Hasil uji ini tidak dapat dibandingkan dengan hasil benchmark TPC-H yang dipublikasikan karena pengujian ini tidak sepenuhnya memenuhi semua persyaratan TPC-H.
Kinerja pemuatan data
Data berikut didasarkan pada lingkungan pengujian dengan 32 core dan memori 256 GB. Data ini membandingkan kinerja pemuatan dan penyimpanan data tabel kolom dengan ClickHouse dan Doris menggunakan dataset TPC-H dan Airline.
Kecepatan Pemuatan
-
Dataset TPC-H: Kecepatan pemuatan untuk tabel kolom mencapai 5,71 juta baris/detik, dengan throughput tulis 50 GB/menit, sekitar 2,7 kali lipat dari ClickHouse.
-
Dataset Airline: Kecepatan pemuatan untuk tabel kolom mencapai 4,3 juta baris/detik, dengan throughput tulis 27 GB/menit, sekitar 2 kali lipat dari ClickHouse.
|
Dataset |
ClickHouse (juta baris/detik) |
Doris (juta baris/detik) |
Tabel kolom (juta baris/detik) |
|
TPC-H |
2,10 |
4,54 |
5,71 |
|
Airline |
1,40 |
2,15 |
4,30 |
Jejak Penyimpanan
-
Dataset TPC-H: Dengan data mentah 100 GB, tabel kolom mencapai rasio kompresi 4x.
-
Dataset Airline: Dengan data mentah 75 GB, tabel kolom mencapai rasio kompresi 18x.
Tabel berikut membandingkan jejak penyimpanan untuk dataset Airline 75 GB:
|
Jenis/Produk |
ClickHouse |
Doris |
Tabel kolom |
|
Jejak penyimpanan (GB) |
9,29 |
4,49 |
3,97 |
|
Rasio kompresi |
Sekitar 8x |
Sekitar 16x |
Sekitar 18x |
Kinerja kueri TPC-H
-
Dalam pengujian kinerja menggunakan dataset TPC-H 100 GB, waktu total eksekusi ke-22 kueri oleh tabel kolom adalah 17,994 detik, dibandingkan dengan 76,9 detik untuk ClickHouse. Secara keseluruhan, kinerja tabel kolom sekitar 4,3 kali lebih tinggi daripada ClickHouse.
Kueri
Columnar Table (seconds)
ClickHouse (detik)
Q1
1,175
2.2
Q2
0,178
0,9
Q3
0,577
1,6
Q4
0,433
1,3
Q5
0,522
3,3
Q6
0,366
0,32
Q7
0,633
1,7
Q8
0,528
1,8
Q9
2,817
12
Q10
0,935
2,3
Q11
0,218
0,66
Q12
0,535
1,4
Q13
1,255
4,4
Q14
0,442
0,3
Q15
0,889
0,42
Q16
0,553
0,6
Q17
0,738
4,2
Q18
2,381
4,3
Q19
0,759
2
Q20
0,453
0,6
Q21
1,308
29,6
Q22
0,299
1
Total
17,994
76,9
-
Analisis Paralel Multi-Node: Dalam pengujian kinerja dengan dataset TPC-H 1 TB, tabel kolom menggunakan akselerasi paralel multi-node, mengurangi waktu total kueri dari 1.420,551 detik pada satu node menjadi 167,948 detik pada enam node.
Kueri
1 node (detik)
2 node (detik)
4 node (detik)
6 node (detik)
Q1
76,849
36,831
23,031
20,022
Q2
5,841
2,805
1,527
1,09
Q3
133,69
26,131
15,833
4,75
Q4
51,466
19,02
3,353
2,362
Q5
52,965
26,844
13,715
4,269
Q6
34,577
21,831
35,17
11,274
Q7
75,996
29,659
17,279
5,717
Q8
54,989
28,922
15,651
3,375
Q9
155,33
78,216
40,38
25,983
Q10
72,222
31,659
17,177
4,594
Q11
4,149
2,049
1,351
1,069
Q12
50,997
27,79
16,207
2,977
Q13
73,009
31,742
17,605
16,255
Q14
36,887
22,093
4,475
3,778
Q15
66,217
38,628
7,583
6,451
Q16
11,493
4,49
2,528
1,758
Q17
59,225
37,101
11,434
8,767
Q18
132,604
53,578
17,164
10,797
Q19
72,794
38,416
23,759
16,651
Q20
42,621
22,432
5,62
4,768
Q21
149,245
54,803
12,758
8,793
Q22
7,385
5,684
2,972
2,448
Total
1.420,551
640,724
306,572
167,948