Seiring lonjakan volume data bisnis, banyak perusahaan menghadapi tantangan inti dalam mengelola biaya penyimpanan data skala besar dan 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 data hingga 90% dari ukuran data asli serta meningkatkan kinerja kueri analitik hingga satu orde besaran. Fitur ini memungkinkan pengarsipan data skala besar dengan biaya 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. Hal ini memungkinkan sumber daya komputasi dan penyimpanan diskalakan secara independen dan elastis, memberikan kemampuan pemrosesan data tingkat petabyte. Lapisan penyimpanan dibangun di atas sistem file terdistribusi dan OSS. Lapisan komputasi memberikan analitik berkinerja tinggi melalui optimalisasi mendalam pada query optimizer, execution operator, dan storage engine.
Arsitektur teknis
PolarDB arsitektur keseluruhan
PolarDB menggunakan arsitektur dengan pemisahan komputasi dan penyimpanan, yang dibangun di atas lapisan penyimpanan terdistribusi. Sistem ini menggunakan 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 read/write splitting dan load balancing.
Arsitektur tabel kolom
Komponen teknis intinya meliputi:
Query optimizer: Pengoptimal berbasis biaya (CBO) bawaan untuk penyimpanan campuran baris-kolom. Komponen 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 menyediakan kemampuan pembaruan cepat. Mekanisme delete-mask menandai data untuk dihapus, memungkinkan kueri paralel efisien tanpa mengganggu penulisan real-time. Selain itu, indeks sekunder berbasis row-store-nya dapat dengan cepat menyaring data yang tidak relevan, lebih lanjut 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 sesuai:
Aspek | Tabel berorientasi baris (X-Engine) | Tabel kolom |
Organisasi data | Data disimpan secara berurutan per baris. Semua kolom untuk satu baris disimpan bersama. | Data disimpan secara berurutan per kolom. Semua nilai untuk satu kolom disimpan bersama. |
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 pencarian titik (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 besaran 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
Hemat biaya: Mengurangi biaya penyimpanan dan pemrosesan untuk set data 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.
Kompatibel 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 dan sesuai permintaan terhadap node komputasi dan storage space untuk 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 penulisan dengan konkurensi tinggi.
Kepraktisan luar biasa: Menyederhanakan tumpukan teknologi dan manajemen operasional dengan mendukung penyimpanan kompresi tinggi dan analitik berkinerja tinggi dalam satu mesin database, lengkap dengan dukungan penuh untuk operasi DDL dan DML.
Kasus penggunaan
Pengarsipan data berbiaya rendah
Masalah: Seiring pertumbuhan bisnis, data historis seperti pesanan lalu, 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 di-offline-kan, sehingga akses online menjadi rumit.
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 perubahan kode.
Gudang data khusus
Masalah: Saat membangun gudang data khusus, perusahaan sering menghadapi biaya perangkat keras tinggi, pipeline sinkronisasi data kompleks (ETL), 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 dari 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 membeli perangkat keras khusus 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
Masalah: Data bisnis sering 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 tersebar 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.
Kueri federasi: Lakukan operasi
JOINdengan mudah antara tabel lokal di PolarDB (baik berorientasi baris maupun kolom) dan tabel eksternal OSS untuk menjalankan analisis terpadu lintas 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 benchmark TPC-H, tetapi hasilnya tidak dapat dibandingkan dengan hasil benchmark TPC-H yang dipublikasikan karena pengujian ini tidak sepenuhnya mematuhi spesifikasi 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 yang dibutuhkan tabel kolom untuk mengeksekusi ke-22 kueri 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
Tabel kolom (detik)
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 kueri total 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
1420,551
640,724
306,572
167,948