Topik ini menjelaskan prinsip dasar, skenario, dan kebijakan dalam menentukan kelompok tabel serta jumlah shard di Hologres untuk mengoptimalkan performa kueri. Topik ini juga mencakup jawaban atas beberapa pertanyaan umum (FAQ) mengenai kelompok tabel dan jumlah shard.
Spesifikasi instans yang direkomendasikan
Dalam praktiknya, Anda mungkin perlu menentukan rentang jumlah shard yang paling sesuai ketika volume 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 kueri titik atau analisis data—throughput tulis, serta jumlah tabel dalam kelompok tabel tersebut. Oleh karena itu, nilai pasti untuk jumlah shard yang paling sesuai tidak dapat ditentukan secara akurat. Tabel berikut menyajikan jumlah shard dan spesifikasi instans yang direkomendasikan untuk rentang volume data tertentu. Anda dapat memilih pengaturan yang sesuai berdasarkan perkiraan volume data.
Total Ukuran 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 kelompok tabel. |
40 miliar hingga 400 miliar | 160 hingga 400 | Lebih dari 512 core CPU. Dalam kasus ini, Anda dapat membuat beberapa kelompok tabel. |
Jumlah shard dan spesifikasi instans yang direkomendasikan untuk berbagai jumlah baris data dalam tabel di atas bukan satu-satunya kriteria. Tabel dengan volume data kecil juga dapat ditambahkan ke kelompok tabel dengan jumlah shard besar. Sebaliknya, tabel dengan volume data besar juga dapat ditambahkan ke kelompok tabel dengan satu shard saja. Anda harus memilih jumlah shard yang sesuai berdasarkan skenario bisnis Anda untuk memenuhi kebutuhan konkurensi tinggi, efisiensi komputasi tinggi, dan konsentrasi data tinggi, serta mencegah overhead shuffle yang tidak perlu.
Satu kelompok tabel sebaiknya tidak berisi lebih dari 10.000 tabel, termasuk tabel anak partisi tetapi tidak termasuk tabel eksternal. Jika satu kelompok tabel berisi terlalu banyak tabel, akumulasi metadata dapat memperlambat eksekusi pernyataan Data Definition Language (DDL).
Anda dapat menentukan apakah perlu membuat kelompok tabel dan bagaimana memilih kelompok tabel untuk tabel-tabel Anda berdasarkan praktik terbaik dalam rencana berikut:
Rencana 1: Gunakan kelompok tabel default
Jika instans Hologres Anda memenuhi kondisi berikut, kami merekomendasikan penggunaan kelompok tabel default. Setelah Anda melakukan peningkatan atau penurunan spesifikasi instans Hologres, jumlah shard pada kelompok tabel default tidak berubah. Anda dapat menjalankan pernyataan berikut untuk memeriksa 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 pada kelompok tabel default memenuhi kebutuhan volume data. Dalam hal ini, Anda dapat membuat tabel di dalam kelompok tabel default.
Ukuran keseluruhan
Total volume data semua tabel terkendali dan dapat diprediksi. Pola penggunaannya tidak berubah secara signifikan.
Local join
Anda perlu melakukan operasi local join yang efisien pada tabel-tabel dalam kelompok tabel default.
Rencana 2: Buat kelompok tabel
Kelompok tabel default tidak dapat memenuhi kebutuhan Anda, dan Anda mungkin memerlukan beberapa kelompok tabel. Dalam kebanyakan kasus, beberapa kelompok tabel diperlukan dalam instans Anda dalam kondisi berikut:
Jumlah Data
Jumlah shard pada kelompok tabel yang ada tidak sesuai dengan perkiraan volume data pada tabel saat ini. Jika jumlah shard terlalu besar sementara volume data kecil, akan dihasilkan terlalu banyak file kecil dan overhead I/O menjadi tinggi. Jika jumlah shard terlalu kecil sementara volume data besar, konkurensi kueri akan berkurang. Dalam kasus ini, diperlukan beberapa kelompok tabel.
Pemisahan beban
Kelompok tabel yang ada berisi banyak tabel, dan data perlu ditulis secara simultan ke sebagian besar tabel tersebut. Akibatnya, beban instans menjadi tinggi. Selain itu, tabel yang akan dibuat memerlukan throughput kueri dan tulis yang tinggi. Dalam kasus ini, diperlukan beberapa kelompok tabel agar proses tulis dan kueri data menjadi independen hingga batas tertentu. Untuk informasi lebih lanjut, lihat topik tentang cara mengisolasi resource komputasi. Jika Anda menilai bahwa kelompok tabel yang ada tidak dapat memenuhi kebutuhan tulis dan kueri, maka beberapa kelompok tabel juga diperlukan.
Korelasi tabel
Jika sekelompok tabel dalam bisnis Anda memiliki pola unik dalam penulisan atau kueri data, memiliki atau akan memiliki kebutuhan local join, serta memiliki sedikit atau tidak ada korelasi dengan tabel dalam kelompok tabel yang ada, Anda dapat membuat beberapa kelompok tabel independen untuk kumpulan tabel tersebut. Operasi local join hanya dapat dilakukan pada tabel-tabel yang memiliki kunci gabungan sebagai kunci distribusi dan berada dalam kelompok tabel yang sama. Anda dapat membuat kelompok tabel untuk kumpulan tabel yang saling berkorelasi kuat tetapi memiliki sedikit korelasi dan probabilitas rendah untuk local join dengan tabel dalam kelompok tabel yang ada.
Penskalaan sumber daya instance
Jika instans Anda telah mengalami scaling in atau out lebih dari lima kali, jumlah shard awal mungkin tidak lagi memenuhi kebutuhan. Dalam kasus ini, Anda dapat mengubah kelompok tabel default. Jumlah shard harus lebih besar daripada jumlah node komputasi dan kurang dari 60% dari total jumlah core CPU.
Rencana 3: Penempatan beberapa kelompok tabel
Untuk merencanakan beberapa kelompok tabel, kami merekomendasikan Anda merancang peran dan signifikansi masing-masing kelompok tabel serta kelompok tabel tempat setiap tabel akan ditempatkan 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 suatu tabel. Kelompok tabel dengan jumlah shard besar cocok untuk tabel besar, sedangkan kelompok tabel dengan jumlah shard kecil cocok untuk tabel kecil dan menengah.
Performa tulis yang dibutuhkan
Jumlah shard memiliki korelasi positif dengan performa penulisan data. Kemampuan tulis satu shard memiliki batas atas. Semakin banyak shard, semakin tinggi konkurensi dan throughput tulis. Untuk menulis data ke suatu tabel dengan catatan per detik (RPS) tinggi, mungkin diperlukan jumlah shard yang lebih besar. Jika utilisasi CPU satu core mencapai 100%, satu shard di Hologres dapat menulis data dengan RPS 3.000 hingga 5.000 (1 KB per catatan). Anda dapat memperkirakan jumlah shard yang dibutuhkan berdasarkan RPS yang diinginkan. Setiap shard juga perlu melakukan operasi baca seperti kueri data. Oleh karena itu, utilisasi CPU untuk penulisan data tidak dapat mencapai 100%. Satu shard yang menggunakan 1/3 core CPU dapat menulis data dengan RPS 1.000 (1 KB per catatan). Misalnya, jika Anda ingin menulis data dengan RPS 60.000 dan ukuran setiap catatan adalah 1 KB, jumlah shard harus lebih dari 60. Jumlah shard ini dapat disesuaikan lebih lanjut.
Beban setiap kelompok tabel
Saat membuat kelompok tabel, Anda harus mempertimbangkan jumlah tabel yang akan ditambahkan ke kelompok tersebut. Jika banyak tabel akan ditambahkan ke kelompok ini di masa depan dan sebagian besar tabel tersebut sering diakses, jumlah shard yang kecil mungkin tidak mampu mendukung kueri dengan konkurensi tinggi.
FAQ
Saya memiliki instans dengan 512 core CPU dan menggunakannya untuk melakukan online analytical processing (OLAP) pada tabel event real-time. Tabel tersebut berisi sekitar 20 miliar hingga 40 miliar baris. Dalam kasus ini, bagaimana saya menentukan kelompok tabel dan jumlah shard?
Hanya ada satu beban komputasi sehingga Anda dapat menggunakan satu kelompok tabel. Jumlah shard default untuk instans dengan 512 core CPU adalah 160. Jika tabel event berisi banyak kolom, misalnya ratusan kolom, Anda dapat meningkatkan jumlah shard secara tepat guna meningkatkan konkurensi OLAP. Misalnya, ubah jumlah shard kelompok tabel default dalam database menjadi 200 atau lebih untuk menyimpan tabel event tersebut.
Saya memiliki instans dengan 256 core CPU dan banyak tabel berorientasi kolom, serta menggunakan instans tersebut untuk melakukan OLAP cepat dalam hitungan milidetik. Setiap tabel berisi puluhan juta baris. Saya ingin mengelompokkan data berdasarkan beberapa bidang dan mengkueri detail berdasarkan kondisi. Bagaimana saya menentukan kelompok tabel dan jumlah shard?
Hanya ada satu beban komputasi sehingga Anda dapat menggunakan satu kelompok tabel. Jumlah shard default untuk instans dengan 256 core CPU adalah 120. Untuk tabel yang berisi puluhan juta baris, kami merekomendasikan jumlah shard sebesar 10 hingga 20. Terutama untuk operasi agregat seperti pengelompokan, semakin banyak shard akan menyebabkan overhead shuffle yang lebih besar, sehingga analisis dalam hitungan milidetik tidak dapat dicapai. Oleh karena itu, kelompok tabel default mungkin tidak memenuhi kebutuhan Anda. Untuk hasil yang lebih baik, Anda dapat mengubah jumlah shard kelompok tabel default dalam database menjadi nilai antara 16 hingga 40 sesuai situasi spesifik, lalu melakukan uji stres.
Bagaimana saya memeriksa apakah kueri lambat disebabkan oleh jumlah shard yang tidak tepat?
Untuk jumlah shard yang tidak tepat, jumlah shard tersebut bisa terlalu besar atau terlalu kecil.
Jika jumlah shard terlalu besar, overhead startup kueri atau overhead shuffle menjadi besar. Overhead startup kueri dapat dilihat 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 setelahnya, Anda dapat melihat overhead ini untuk kueri historis dalam log kueri lambat.
Jika jumlah shard terlalu kecil, utilisasi CPU tidak dapat mencapai 100% selama komputasi jangka panjang, overhead pemindaian data menjadi besar karena konkurensi yang tidak mencukupi, atau performa 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 satu core mencapai 100%, satu shard di Hologres menulis data dengan RPS 3.000 hingga 5.000. Anda dapat membandingkan RPS aktual dengan rentang ini untuk memeriksa apakah jumlah shard terlalu kecil.
Permintaan per detik (QPS) tidak cukup tinggi dalam skenario kueri titik. Apakah masalah ini disebabkan oleh jumlah shard yang tidak mencukupi?
Pertama-tama, tentukan apakah ada penyebab lain. Misalnya, kueri analisis (bukan kueri titik) yang dijalankan, tidak menggunakan indeks, shard tidak dipisahkan, atau utilisasi CPU mencapai 100%. Jika penyebab lain tidak menyebabkan masalah ini, satu pernyataan SQL mencapai performa tertinggi, namun QPS tetap tidak memenuhi kebutuhan Anda, Anda dapat meningkatkan jumlah shard untuk meningkatkan konkurensi backend pada kueri titik.
Bagaimana saya melakukan troubleshooting kesenjangan data pada shard?
Hologres menyediakan field internal hg_shard_id. Field ini menentukan ID shard tempat data berada. Anda dapat menjalankan pernyataan SQL untuk memeriksa apakah terjadi kesenjangan data pada shard.
SELECT hg_shard_id, COUNT(1) FROM <Table_Name> GROUP BY hg_shard_id ORDER BY COUNT(1) DESC;Jika volume data dalam satu shard secara signifikan lebih besar daripada shard lainnya, berarti terjadi kesenjangan data. Dalam kasus ini, Anda mungkin perlu menyesuaikan kunci distribusi.