Topik ini menjelaskan prinsip dasar, skenario, dan kebijakan untuk menentukan grup tabel dan jumlah shard di Hologres guna mengoptimalkan kinerja query. Topik ini juga memberikan jawaban atas beberapa pertanyaan umum tentang grup tabel dan jumlah shard.
Spesifikasi instans yang direkomendasikan
Dalam praktiknya, Anda mungkin perlu menentukan rentang jumlah shard yang paling sesuai ketika jumlah data dapat diprediksi. Jumlah shard yang optimal tidak hanya bergantung pada volume data yang akan disimpan, tetapi juga pada frekuensi akses aktual, volume data yang diakses, jenis beban komputasi seperti query titik atau analisis data, throughput penulisan, serta jumlah tabel dalam grup tabel. Oleh karena itu, nilai pasti untuk jumlah shard yang optimal tidak dapat ditentukan secara langsung. Tabel berikut menjelaskan jumlah shard yang direkomendasikan beserta spesifikasi instans yang sesuai dengan rentang jumlah data tertentu. Anda dapat memilih pengaturan yang sesuai berdasarkan perkiraan volume data.
Jumlah baris data | Jumlah shard yang direkomendasikan | Spesifikasi instans yang direkomendasikan |
Kurang dari 40 juta | 10 hingga 20 | Lebih dari 32 core CPU |
40 juta hingga 400 juta | 20 hingga 40 | Lebih dari 64 core CPU |
400 juta hingga 4 miliar | 40 hingga 80 | Lebih dari 128 core CPU |
4 miliar hingga 40 miliar | 80 hingga 240 | Lebih dari 256 core CPU. Dalam kasus ini, Anda mungkin perlu membuat grup tabel. |
40 miliar hingga 400 miliar | 160 hingga 400 | Lebih dari 512 core CPU. Dalam kasus ini, Anda dapat membuat beberapa grup tabel. |
Jumlah shard dan spesifikasi instans yang direkomendasikan untuk jumlah baris data tertentu dalam tabel di atas bukan satu-satunya kriteria. Tabel dengan volume data kecil dapat ditambahkan ke grup tabel dengan jumlah shard besar, sedangkan tabel dengan volume data besar dapat ditambahkan ke grup tabel dengan satu shard. Pilih jumlah shard yang sesuai berdasarkan skenario bisnis Anda untuk memenuhi persyaratan konkurensi tinggi, efisiensi komputasi tinggi, dan konsentrasi data tinggi, serta untuk mencegah overhead shuffle yang tidak perlu.
Disarankan agar Anda mengonfigurasi tidak lebih dari 3.000 tabel (termasuk tabel anak partisi) dalam sebuah grup tabel. Jika terdapat sejumlah besar tabel dalam grup tabel, metadata akan menumpuk, dan eksekusi pernyataan bahasa definisi data (DDL) melambat.
Anda dapat menentukan apakah akan membuat grup tabel dan bagaimana memilih grup tabel untuk tabel Anda berdasarkan praktik terbaik dalam rencana berikut:
Rencana 1: Gunakan Grup Tabel Default
Jika instans Hologres Anda memenuhi kondisi berikut, disarankan agar Anda menggunakan grup tabel default. Setelah meningkatkan atau menurunkan spesifikasi instans Hologres, jumlah shard dari grup tabel default tidak berubah. Anda dapat mengeksekusi pernyataan berikut untuk menanyakan jumlah shard:
SELECT * FROM hologres.hg_table_group_properties; -- Contoh hasil tablegroup_name | property_key | property_value -----------------+---------------+---------------- test_tg_default | is_default_tg | 1 test_tg_default | shard_count | 40 test_tg_default | tg_version | 1 test_tg_default | table_num | 1 (4 rows)Volume Data
Jumlah shard dari grup tabel default memenuhi persyaratan volume data. Dalam hal ini, Anda dapat membuat tabel dalam grup tabel default.
Ukuran Keseluruhan
Volume data total semua tabel dapat dikendalikan dan diprediksi. Mode penggunaan tidak berubah secara signifikan.
Local Join
Anda perlu melakukan operasi local join yang efisien pada tabel dalam grup tabel default.
Rencana 2: Buat Grup Tabel Baru
Grup tabel default tidak dapat memenuhi persyaratan Anda, dan Anda mungkin memerlukan beberapa grup tabel. Dalam banyak kasus, beberapa grup tabel mungkin diperlukan dalam instans Anda di bawah kondisi berikut:
Volume Data
Jumlah shard dari grup tabel yang ada tidak sesuai dengan volume data yang diperkirakan dalam tabel saat ini. Jika jumlah shard besar dan volume data kecil, file kecil yang berlebihan dihasilkan dan overhead I/O tinggi. Jika jumlah shard kecil dan volume data besar, konkurensi query berkurang. Dalam hal ini, beberapa grup tabel diperlukan.
Beban Independen
Grup tabel yang ada berisi sejumlah besar tabel, dan data perlu ditulis secara bersamaan ke sebagian besar tabel. Akibatnya, beban instans tinggi. Selain itu, tabel yang akan dibuat memerlukan throughput query dan tulis yang tinggi. Dalam hal ini, beberapa grup tabel diperlukan untuk membuat penulisan data dan query independen sampai batas tertentu. Untuk informasi lebih lanjut, lihat topik tentang cara mengisolasi sumber daya komputasi. Jika Anda menentukan bahwa grup tabel yang ada tidak dapat memenuhi persyaratan tulis dan query, beberapa grup tabel juga diperlukan.
Korelasi Tabel
Jika sekelompok tabel dalam bisnis Anda memiliki pola tulis atau query data unik, memiliki atau akan memiliki persyaratan local join, dan memiliki sedikit atau tidak ada korelasi dengan tabel dalam grup tabel yang ada, Anda dapat membuat beberapa grup tabel independen untuk kelompok tabel tersebut. Operasi local join hanya dapat dilakukan pada tabel dengan kunci join sebagai kunci distribusi dan dalam grup tabel yang sama. Anda dapat membuat grup tabel untuk sekelompok tabel yang memiliki korelasi kuat satu sama lain tetapi memiliki sedikit korelasi dan probabilitas rendah local join dengan tabel dalam grup tabel yang ada.
Penskalaan Sumber Daya Instans
Jika instans Anda telah diskalakan masuk atau keluar lebih dari lima kali, jumlah shard asli mungkin tidak lagi memenuhi persyaratan. Dalam hal ini, Anda dapat mengubah grup tabel default. Jumlah shard harus lebih besar dari jumlah node komputasi dan kurang dari 60% dari jumlah total core CPU.
Rencana 3: Tambahkan Tabel ke Beberapa Grup Tabel
Jika Anda perlu merencanakan beberapa grup tabel, disarankan agar Anda merencanakan peran dan signifikansi grup tabel serta grup tabel tempat setiap tabel termasuk sebelum uji stres dan produksi. Anda dapat mempertimbangkan faktor-faktor berikut selama perencanaan:
Volume Data
Jumlah shard ditentukan oleh volume data yang akan disimpan dalam tabel. Grup tabel dengan jumlah shard besar sesuai untuk tabel besar, sedangkan grup tabel dengan jumlah shard kecil sesuai untuk tabel kecil dan menengah.
Kinerja Tulis yang Diperlukan
Jumlah shard memiliki korelasi positif dengan kinerja tulis data. Kemampuan tulis dari satu shard memiliki batas atas. Semakin banyak shard menunjukkan konkurensi tulis dan throughput yang lebih tinggi. Jika Anda perlu menulis data ke tabel pada laju permintaan per detik (RPS) yang tinggi, jumlah shard yang lebih besar mungkin diperlukan. Jika utilisasi CPU untuk satu core adalah 100%, satu shard di Hologres menulis data pada RPS 3.000 hingga 5.000 (1 KB per rekaman). Anda dapat memperkirakan jumlah shard yang diperlukan berdasarkan RPS yang Anda butuhkan. Setiap shard juga perlu melakukan operasi baca seperti query data. Oleh karena itu, utilisasi CPU untuk penulisan data tidak dapat mencapai 100%. Shard yang menggunakan 1/3 core CPU menulis data pada RPS 1.000 (1 KB per rekaman). Sebagai contoh, jika Anda ingin menulis data pada RPS 60.000 dan ukuran setiap rekaman adalah 1 KB, jumlah shard harus lebih besar dari 60. Jumlah shard dapat disesuaikan secara halus.
Beban Setiap Grup Tabel
Saat Anda membuat grup tabel, Anda harus mempertimbangkan jumlah tabel yang akan ditambahkan ke grup tabel ini. Jika sejumlah besar tabel akan ditambahkan ke grup tabel ini di masa mendatang, dan sebagian besar tabel sering diakses, jumlah shard kecil mungkin gagal mendukung query dengan konkurensi tinggi.
Tanya Jawab Umum
Saya memiliki instans dengan 512 core CPU dan menggunakannya untuk pemrosesan analitik online (OLAP) pada tabel event real-time. Tabel tersebut berisi sekitar 20 miliar hingga 40 miliar baris. Dalam kasus ini, bagaimana saya menentukan grup tabel dan jumlah shard?
Hanya satu beban komputasi yang terlibat sehingga Anda dapat menggunakan satu grup tabel. Jumlah shard default untuk instans dengan 512 core CPU adalah 160. Jika tabel event berisi sejumlah besar kolom, seperti ratusan kolom, Anda dapat meningkatkan jumlah shard secara tepat untuk meningkatkan konkurensi OLAP. Misalnya, ubah jumlah shard dari grup tabel default dalam database menjadi 200 atau lebih untuk menyimpan tabel event.
Saya memiliki instans dengan 256 core CPU dan sejumlah besar tabel berorientasi kolom, serta menggunakan instans tersebut untuk melakukan OLAP cepat dalam milidetik. Setiap tabel berisi puluhan juta baris. Saya ingin mengelompokkan data berdasarkan beberapa bidang dan menanyakan detail berdasarkan kondisi. Bagaimana saya menentukan grup tabel dan jumlah shard?
Hanya satu beban komputasi yang terlibat sehingga Anda dapat menggunakan satu grup tabel. Jumlah shard default untuk instans dengan 256 core CPU adalah 120. Untuk tabel yang berisi puluhan juta baris, disarankan agar Anda menentukan 10 hingga 20 shard. Terutama untuk operasi agregat seperti pengelompokan, lebih banyak shard menyebabkan lebih banyak overhead shuffle, dan analisis dalam milidetik tidak dapat diimplementasikan. Oleh karena itu, grup tabel default mungkin tidak dapat memenuhi persyaratan Anda. Untuk mencapai efek yang lebih baik, Anda dapat mengubah jumlah shard dari grup tabel default dalam database menjadi nilai antara 16 dan 40 berdasarkan situasi spesifik, dan melakukan uji stres.
Bagaimana saya memeriksa apakah query lambat disebabkan oleh jumlah shard yang tidak sesuai?
Untuk jumlah shard yang tidak sesuai, jumlah shard mungkin terlalu besar atau terlalu kecil.
Jika jumlah shard terlalu besar, overhead startup query atau shuffle besar. Overhead startup query dapat dipelajari dari baris start query cost dalam hasil eksekusi pernyataan EXPLAIN ANALYZE. Overhead shuffle dapat ditentukan berdasarkan ukuran Max_GetNext_Time dari Redistribution Motion dalam hasil eksekusi pernyataan EXPLAIN ANALYZE. Di Hologres V0.10 dan versi berikutnya, Anda dapat melihat overhead ini dari query lambat dalam log query lambat.
Jika jumlah shard terlalu kecil, utilisasi CPU tidak dapat mencapai 100% selama komputasi jangka panjang, overhead pemindaian data besar karena konkurensi yang tidak mencukupi, atau kinerja penulisan data buruk. Overhead pemindaian data dapat ditentukan berdasarkan ukuran Max_GetNext_Time dari Scan Node dalam hasil eksekusi pernyataan EXPLAIN ANALYZE. Jika utilisasi CPU untuk satu core adalah 100%, satu shard di Hologres menulis data pada RPS 3.000 hingga 5.000. Anda dapat membandingkan RPS aktual dengan rentang ini untuk memeriksa apakah jumlah shard terlalu kecil.
Queries per second (QPS) tidak cukup tinggi dalam skenario query titik. Apakah masalah ini disebabkan oleh shard yang tidak mencukupi?
Pertama-tama, tentukan apakah penyebab lain ada. Misalnya, query analitik daripada query titik dilakukan, tidak ada indeks yang digunakan, shard tidak dibagi, atau utilisasi CPU mencapai 100%. Jika penyebab lain yang mungkin tidak mengakibatkan masalah, satu pernyataan SQL mencapai kinerja tertinggi, dan QPS masih tidak memenuhi persyaratan Anda, Anda dapat meningkatkan jumlah shard untuk meningkatkan konkurensi backend dari query titik.
Bagaimana saya mendiagnosis skew data dari shard?
Hologres menyediakan bidang internal hg_shard_id. Bidang ini menentukan ID shard tempat data berada. Anda dapat mengeksekusi pernyataan SQL untuk memeriksa apakah skew data ada dalam shard.
SELECT hg_shard_id, COUNT(1) FROM <Table_Name> GROUP BY hg_shard_id ORDER BY COUNT(1) DESC;Jika jumlah data dalam shard secara signifikan lebih besar daripada yang ada di shard lain, skew data ada. Dalam hal ini, Anda mungkin perlu menyesuaikan kunci distribusi.