Topik ini memperkenalkan indeks utama di Hologres, seperti Distribution Key, Event Time Column (Segment Key), dan Clustering Key, untuk membantu Anda meningkatkan performa kueri selama pengembangan dengan Hologres.
Prinsip dasar gudang data terdistribusi Hologres
Hologres adalah gudang data terdistribusi yang menggunakan komputasi paralel dan komputasi vektor untuk memberikan respons kueri dalam hitungan detik. Oleh karena itu, distribusi data sangat penting bagi performa. Fitur-fitur tersebut mencakup distribusi data yang seimbang di berbagai node terdistribusi (distribution_key) dan distribusi data yang terurut dalam file pada satu node (event_time_column/segment_key). Secara default, Hologres menggunakan format column-store untuk skenario online analytical processing (OLAP), sehingga distribusi data yang terurut dalam file (clustering_key) juga sangat penting. Memahami ketiga konsep ini secara signifikan dapat meningkatkan performa. Fitur distribusi data ditentukan saat data ditulis dan mahal untuk disesuaikan, sehingga Anda harus merancang ketiga properti terkait tata letak data ini saat membuat tabel. Properti yang tidak secara langsung terkait tata letak data, seperti bitmap index (bitmap_columns) dan dictionary encoding (dictionary_columns), dapat disesuaikan sesuai kebutuhan setelah tabel dibuat.
Hologres juga menggunakan struktur metadata tiga tingkat: Database > Schema > Table. Sebaiknya simpan tabel-tabel yang secara logis saling terkait dalam satu schema yang sama untuk menghindari kueri lintas database. Database merupakan unit dasar untuk isolasi metadata, bukan untuk isolasi resource.
Prinsip dasar optimasi SQL: Kurangi I/O dan optimalkan konkurensi
Merancang distribusi data yang tepat saat membuat tabel memungkinkan SQL menemukan data dengan cepat selama eksekusi, sehingga mengurangi konsumsi I/O dan mencapai performa kueri yang lebih tinggi dengan sumber daya komputasi yang lebih sedikit. Distribusi data yang seimbang juga memungkinkan pemanfaatan penuh sumber daya konkuren serta menghindari bottleneck titik tunggal. Gambar berikut menunjukkan alur eksekusi kueri SQL dari inisiasi hingga pengambilan data. Anda dapat menggunakan gambar ini untuk memahami cara mengurangi I/O.
Pemangkasan Partisi (Partition Pruning): Saat kueri SQL dieksekusi pada tabel partisi, pemangkasan partisi digunakan untuk menemukan partisi yang diperlukan. Jika kueri tidak mengandung kondisi filter pada kunci partisi, semua partisi harus dilalui (traversed), yang menyebabkan pemindaian I/O berlebihan. Granularitas partisi harian biasanya sudah sesuai. Langkah ini dilewati untuk tabel non-partisi.
Pemangkasan Shard (Shard Pruning): Kunci distribusi (`distribution_key`) digunakan untuk dengan cepat menemukan shard data yang berisi data tersebut. Hal ini mengurangi konsumsi resource untuk satu kueri SQL dan memberikan throughput yang lebih tinggi untuk kueri SQL konkuren. Jika shard tertentu tidak dapat ditemukan, framework terdistribusi akan menjadwalkan semua shard untuk berpartisipasi dalam komputasi, yang meningkatkan tingkat paralelisme untuk satu kueri SQL dan menggunakan lebih banyak resource, sehingga mengurangi konkurensi secara keseluruhan. Beberapa operator yang memerlukan eksekusi terpusat menyebabkan overhead pengacakan (shuffle) tambahan. Biasanya, pilih bidang dengan distribusi seimbang, seperti ID pesanan (order IDs), ID pengguna (user IDs), atau ID event (event IDs), sebagai kunci distribusi. Jika beberapa tabel yang perlu digabungkan (join) menggunakan kunci distribusi yang sama, data terkait akan didistribusikan ke shard yang sama, memungkinkan Local JOIN untuk efisiensi join yang lebih tinggi.
Pemangkasan Kunci Segmen (Segment Key Pruning): Kunci segmen (`event_time_column/segment_key`) digunakan untuk dengan cepat menemukan file yang berisi data dari beberapa file pada satu node, sehingga menghindari pembukaan file yang tidak perlu. Jika penyaringan tidak memungkinkan, semua file pada node tersebut harus dilalui (traversed).
Pemangkasan Kunci Pengelompokan (Clustering Key Pruning): Kunci pengelompokan (`clustering_key`) digunakan untuk dengan cepat menemukan segmen data dalam satu file, sehingga meningkatkan efisiensi kueri rentang (range queries) dan pengurutan bidang (field sorting).
Praktik optimasi SQL
Bagian ini menggunakan kueri TPC-H sebagai contoh untuk menunjukkan cara mengatur indeks Hologres guna meningkatkan performa kueri. Untuk informasi lebih lanjut tentang TPC-H, lihat Ikhtisar rencana pengujian.
Praktik referensi SQL TPC-H
Kueri TPC-H Q1
TPC-H Q1 melakukan agregasi dan penyaringan data pada kolom-kolom tertentu dari tabel `lineitem`.
l_shipdate <=: Menyaring kueri. Indeks harus diatur untuk mendukung penyaringan rentang dan mempercepat penyaringan data.
--TPC-H Q1
SELECT
l_returnflag,
l_linestatus,
SUM(l_quantity) AS sum_qty,
SUM(l_extendedprice) AS sum_base_price,
SUM(l_extendedprice * (1 - l_discount)) AS sum_disc_price,
SUM(l_extendedprice * (1 - l_discount) * (1 + l_tax)) AS sum_charge,
AVG(l_quantity) AS avg_qty,
AVG(l_extendedprice) AS avg_price,
AVG(l_discount) AS avg_disc,
COUNT(*) AS count_order
FROM
lineitem
WHERE
l_shipdate <= DATE '1998-12-01' - INTERVAL '120' DAY
GROUP BY
l_returnflag,
l_linestatus
ORDER BY
l_returnflag,
l_linestatus;Kueri TPC-H Q4
TPC-H Q4 terutama melakukan kueri penggabungan (join) antara tabel `lineitem` dan `orders`.
o_orderdate >= DATE '1996-07-01': Ini adalah filter. Anda dapat mengatur indeks untuk mendukung penyaringan rentang dan dengan cepat menemukan data yang diperlukan.l_orderkey = o_orderkey: Ini adalah penggabungan antara dua tabel. Anda dapat mengatur indeks yang sama untuk kedua tabel. Disarankan untuk melakukan Local JOIN guna mengurangi operasi pengacakan (shuffle) data selama interaksi antara kedua tabel.--TPC-H Q4 Query SELECT o_orderpriority, COUNT(*) AS order_count FROM orders WHERE o_orderdate >= DATE '1996-07-01' AND o_orderdate < DATE '1996-07-01' + INTERVAL '3' MONTH AND EXISTS ( SELECT * FROM lineitem WHERE l_orderkey = o_orderkey AND l_commitdate < l_receiptdate ) GROUP BY o_orderpriority ORDER BY o_orderpriority;
Rekomendasi pembuatan tabel
Kueri Q1 dan Q4 melibatkan tabel `lineitem` dan `orders`.
hologres_dataset_tpch_100g.lineitem
Kedua kueri Q1 dan Q4 melibatkan tabel `lineitem`, tetapi menggunakan bidang dan kondisi kueri yang berbeda.
Untuk kueri Q1: Kueri terutama menggunakan `l_shipdate` untuk penyaringan rentang. `clustering_key` memanfaatkan data terurut dalam satu file untuk mempercepat penyaringan rentang. Oleh karena itu, Anda dapat mengatur `l_shipdate` sebagai Clustering Key. `segment_key` (`event_time_column`) digunakan untuk mempertahankan urutan antar file. Untuk bidang tanggal yang bersifat monoton naik atau turun, kami merekomendasikan agar Anda juga mengaturnya sebagai Segment Key. Hal ini memungkinkan penyaringan tingkat file yang efektif. Oleh karena itu, Anda juga dapat mengatur `l_shipdate` sebagai Segment Key.
Untuk kueri Q4: Kueri terutama menggunakan bidang `l_orderkey` dari tabel `lineitem` untuk digabungkan dengan bidang `o_orderkey` dari tabel `orders`. `distribution_key` menentukan kebijakan distribusi data. Sistem menyimpan data dengan nilai `distribution_key` yang sama pada shard yang sama. Jika dua tabel berada dalam kelompok tabel yang sama dan bidang join-nya adalah Distribution Key, catatan dengan nilai kunci yang sama dari kedua tabel secara otomatis didistribusikan ke shard yang sama saat data ditulis. Saat tabel-tabel ini digabungkan, Local JOIN dilakukan pada node saat ini, yang menghindari pengacakan (shuffling) dan redistribusi data berdasarkan kunci join pada waktu proses (runtime), sehingga secara signifikan meningkatkan efisiensi eksekusi. Oleh karena itu, atur `l_orderkey` sebagai Distribution Key.
Skema tabel akhir untuk tabel `lineitem` adalah sebagai berikut:
BEGIN; CREATE TABLE hologres_dataset_tpch_100g.lineitem ( l_ORDERKEY BIGINT NOT NULL, L_PARTKEY INT NOT NULL, L_SUPPKEY INT NOT NULL, L_LINENUMBER INT NOT NULL, L_QUANTITY DECIMAL(15,2) NOT NULL, L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL, L_DISCOUNT DECIMAL(15,2) NOT NULL, L_TAX DECIMAL(15,2) NOT NULL, L_RETURNFLAG TEXT NOT NULL, L_LINESTATUS TEXT NOT NULL, L_SHIPDATE TIMESTAMPTZ NOT NULL, L_COMMITDATE TIMESTAMPTZ NOT NULL, L_RECEIPTDATE TIMESTAMPTZ NOT NULL, L_SHIPINSTRUCT TEXT NOT NULL, L_SHIPMODE TEXT NOT NULL, L_COMMENT TEXT NOT NULL, PRIMARY KEY (L_ORDERKEY,L_LINENUMBER) ) WITH ( distribution_key = 'L_ORDERKEY',--Mengaktifkan Local JOIN untuk penggabungan tabel. clustering_key = 'L_SHIPDATE',--Mempercepat penyaringan rentang. event_time_column = 'L_SHIPDATE'--Mempercepat pemangkasan file. ); COMMIT;
hologres_dataset_tpch_100g.orders
Dalam contoh ini, tabel `orders` digunakan dalam kueri Q4.
Atur bidang `o_orderkey` dari tabel `orders` sebagai Distribution Key untuk memanfaatkan kemampuan Local JOIN dan meningkatkan efisiensi kueri join.
Bidang `o_orderdate` terutama digunakan untuk menyaring kueri berdasarkan bidang tanggal. Anda dapat mengaturnya sebagai Segment Key untuk mempercepat pemangkasan file.
Skema tabel akhir untuk tabel `orders` adalah sebagai berikut:
BEGIN; CREATE TABLE hologres_dataset_tpch_100g.orders ( O_ORDERKEY BIGINT NOT NULL PRIMARY KEY, O_CUSTKEY INT NOT NULL, O_ORDERSTATUS TEXT NOT NULL, O_TOTALPRICE DECIMAL(15,2) NOT NULL, O_ORDERDATE timestamptz NOT NULL, O_ORDERPRIORITY TEXT NOT NULL, O_CLERK TEXT NOT NULL, O_SHIPPRIORITY INT NOT NULL, O_COMMENT TEXT NOT NULL ) WITH ( distribution_key = 'O_ORDERKEY',--Mengaktifkan Local JOIN untuk penggabungan tabel. event_time_column = 'O_ORDERDATE'--Mempercepat pemangkasan file. ); COMMIT;
Impor data sampel
Anda dapat menggunakan fitur impor dataset publik sekali klik di HoloWeb untuk dengan cepat mengimpor dataset TPC-H 100 GB ke instans Hologres Anda. Untuk informasi lebih lanjut, lihat Impor dataset publik.
Perbandingan hasil uji performa
Setelah Anda mengatur properti (indeks) yang sesuai untuk tabel, Anda dapat menguji performa sebelum dan sesudah optimasi.
Lingkungan pengujian
Tipe instans: 32-core.
Tipe jaringan: VPC.
Jalankan kueri dua kali menggunakan klien PSQL dan catat waktu eksekusi kedua.
Kesimpulan pengujian
Untuk kueri penyaringan pada satu tabel, mengatur bidang filter sebagai Clustering Key dapat secara signifikan mempercepat kueri.
Untuk kueri yang menggabungkan beberapa tabel, mengatur bidang join sebagai Distribution Key dapat secara signifikan meningkatkan efisiensi join.
Kueri
Latensi dengan indeks Hologres
Latensi tanpa indeks Hologres apa pun
Q1
48,293 ms
59,483 ms
Q4
822,389 ms
3027,957 ms
Lampiran
Pelajari lebih lanjut
Prinsip teknis
Untuk mempelajari prinsip inti Hologres, seperti arsitektur, mesin penyimpanan, dan mesin komputasi, lihat Teknologi inti gudang data real-time cloud-native Alibaba Cloud.
Aktivasi layanan
Untuk mempelajari cara memilih tipe instans, lihat Manajemen instans.
Untuk informasi tentang otorisasi Pengguna RAM, lihat Pengenalan cepat otorisasi Pengguna RAM.
Impor data
Untuk penulisan real-time dan kueri tabel dimensi dengan Flink, lihat Flink yang sepenuhnya dikelola.
Untuk sinkronisasi real-time seluruh database, seperti MySQL, Oracle, dan PolarDB, lihat Konfigurasi sumber data (MySQL).
Untuk mengimpor data OSS, lihat Percepat akses ke data lake di OSS berdasarkan DLF.
Untuk secara signifikan meningkatkan efisiensi penulisan dan pembaruan data, gunakan Fixed Plan. Untuk informasi lebih lanjut, lihat Gunakan Fixed Plan untuk mempercepat eksekusi SQL.
Kueri data
Untuk rekomendasi pembuatan tabel berbasis skenario, lihat Panduan pembuatan dan penyetelan tabel berbasis skenario.
Saat membuat tabel, Anda harus memahami parameter kunci seperti `distribution_key`, `clustering_key`, `event_time_column`, dan `bitmap_index`, serta mengatur skema tabel yang wajar untuk secara signifikan meningkatkan performa. Untuk informasi lebih lanjut, lihat CREATE TABLE.
Untuk menyetel performa tabel internal, lihat Optimalkan performa kueri.
Untuk mempercepat kueri pada data MaxCompute, lihat Percepat kueri pada data MaxCompute berdasarkan tabel eksternal.
Pemantauan layanan
Untuk memecahkan masalah kueri aktif dan memeriksa lock, lihat Manajemen kueri.
Untuk memecahkan masalah kueri gagal atau berjalan lama, lihat Lihat dan analisis log kueri lambat.
Untuk pemisahan baca/tulis dan isolasi beban, lihat Deploy instans primary dan secondary untuk pemisahan baca/tulis (penyimpanan bersama).
Praktik terbaik dan studi kasus
Untuk kumpulan praktik terbaik dan studi kasus, lihat Praktik terbaik untuk skenario industri khas dan studi kasus pelanggan klasik.