Ikhtisar tipe instans - Hologres

Hologres menyediakan berbagai tipe instans dengan sumber daya core dan memori yang berbeda. Berkat arsitektur pemisahan komputasi dan penyimpanan (compute-storage separation), sumber daya penyimpanan bersifat independen dari tipe instans. Topik ini menjelaskan spesifikasi sumber daya untuk setiap tipe instans. Anda dapat menyesuaikan spesifikasi instans secara dinamis sesuai kebutuhan melalui peningkatan (upgrade), penurunan (downgrade), atau penskalaan terpisah sumber daya komputasi dan penyimpanan.

Istilah

Sumber daya runtime Hologres mencakup sumber daya proses untuk manajemen data, sumber daya komputasi untuk layanan kueri, sumber daya untuk mengoptimalkan jalur penulisan data, serta layanan cache. Semua layanan tersebut berbasis teknologi kontainer cloud-native dan menggunakan beberapa node komputasi kontainer paralel untuk mencapai komputasi paralel berkinerja tinggi.

Hologres menetapkan jumlah koneksi maksimum dan jumlah shard default untuk suatu instans berdasarkan spesifikasi sumber dayanya. Konfigurasi default ini telah disetel dan dioptimalkan untuk sebagian besar skenario. The maximum number of connections cannot be modified. You can adjust the shard count by creating a new Table Group. When an instance is scaled out or in, the maximum number of connections is also adjusted. However, the default shard count for existing databases does not change during a scaling operation and must be modified manually. New databases use the default shard count for the new specifications.

Setelah scale-out, sumber daya core tambahan dapat memberikan konkurensi kueri yang lebih baik. Dalam sebagian besar skenario, Anda tidak perlu menyesuaikan jumlah shard. Jika Anda memerlukan throughput penulisan yang lebih tinggi, Anda dapat menambah jumlah shard untuk meningkatkan throughput penulisan konkuren. Namun, untuk kueri Pemrosesan Analitik Online (Online Analytical Processing/OLAP), peningkatan jumlah shard tidak secara signifikan meningkatkan performa kueri dan bahkan dapat mengurangi throughput konkuren sistem. Penting untuk memahami prinsip dasarnya sebelum melakukan penyesuaian. Selain itu, untuk Tabel berorientasi baris (row-oriented tables), jumlah shard yang lebih tinggi menghasilkan performa baca yang lebih baik karena karakteristik distribusinya yang alami.

Tipe instans yang direkomendasikan

Setiap shard menangani permintaan layanan baca dan tulis untuk sebagian data. Dalam kelompok tabel (table group) yang sama, sebagian data dari setiap tabel didistribusikan ke shard yang sama. Jika tabel-tabel tersebut dapat di-join dalam satu shard, hal ini disebut local join, yang merupakan metode join yang lebih efisien. Jika datanya tidak berada dalam shard yang sama, diperlukan operator redistribusi untuk mengacak ulang (shuffle) data. Hal ini mengakibatkan overhead transmisi jaringan dan penjadwalan yang lebih besar. Oleh karena itu, saat merancang shard, Anda harus mempertimbangkan secara cermat apakah proses komputasi dapat diparalelkan di seluruh shard atau memerlukan pertukaran data antar-shard. Untuk skenario penulisan dan pembaruan data, operasi tulis dan pembaruan dapat diparalelkan di seluruh shard. Dengan demikian, semakin banyak shard menghasilkan throughput yang lebih tinggi. Untuk skenario kueri titik (point query), jika setiap kueri dapat secara akurat mengenai shard tertentu (proses yang dikenal sebagai shard pruning), semakin banyak shard menghasilkan konkurensi yang lebih tinggi. Untuk kueri OLAP, beberapa shard harus berpartisipasi dalam komputasi, yang pasti melibatkan pertukaran data. Terlalu banyak shard memperkenalkan overhead penjadwalan yang lebih besar antar-node dan pada akhirnya mengurangi konkurensi kueri.

Saat menggunakan instans Hologres, Anda harus menentukan tipe instans dan jumlah shard yang paling sesuai dengan volume data yang diharapkan. Tipe instans dan jumlah shard optimal tidak hanya bergantung pada volume penyimpanan data, tetapi juga pada faktor-faktor seperti frekuensi akses, volume akses data aktual, jenis muatan komputasi (misalnya kueri titik atau analitik), throughput penulisan, dan jumlah tabel dalam kelompok tabel. Oleh karena itu, tidak ada jawaban tunggal yang benar. Tabel berikut memberikan rekomendasi jumlah shard dan tipe instans berdasarkan perkiraan volume data. Anda dapat memilih pengaturan parameter yang sesuai dengan kebutuhan Anda.

Catatan

Jumlah shard dan tipe instans yang direkomendasikan dalam tabel berikut hanya bersifat referensi. Misalnya, tabel dengan volume data kecil dapat ditempatkan dalam instans dengan jumlah shard tinggi, sedangkan tabel dengan volume data besar dapat ditempatkan dalam instans dengan satu shard saja. Anda harus memilih jumlah shard yang sesuai berdasarkan skenario bisnis Anda. Tujuannya adalah mencapai konkurensi tinggi untuk efisiensi komputasi yang lebih baik sekaligus menjaga konsentrasi data guna menghindari overhead shuffle yang tidak perlu.

Total ukuran data	Spesifikasi yang direkomendasikan	Jumlah shard yang direkomendasikan	Catatan penggunaan
Kurang dari 40 juta baris	32 core atau lebih	10 hingga 20	Tidak cocok untuk uji stres. Direkomendasikan untuk lingkungan pengembangan.
40 juta hingga 400 juta baris	64 core atau lebih	20 hingga 40	Cocok untuk skenario bisnis sederhana tanpa muatan campuran.
400 juta hingga 4 miliar baris	128 core atau lebih	40 hingga 80	Kemampuan tulis dan kueri seimbang. Direkomendasikan sebagai konfigurasi awal default untuk sistem produksi.
4 miliar hingga 40 miliar baris	256 core atau lebih	80 hingga 240	Pertimbangkan penggunaan beberapa kelompok tabel. Bagi kelompok tabel berdasarkan koherensi atribut bisnis yang berbeda atau berdasarkan volume data. Rancang shard berbeda untuk kelompok tabel yang berbeda, dan tentukan secara eksplisit kelompok tabel saat membuat tabel.
40 miliar hingga 400 miliar baris	512 core atau lebih	160 hingga 400	Pertimbangkan penggunaan beberapa kelompok tabel. Bagi kelompok tabel berdasarkan koherensi atribut bisnis yang berbeda atau berdasarkan volume data. Rancang shard berbeda untuk kelompok tabel yang berbeda, dan tentukan secara eksplisit kelompok tabel saat membuat tabel. Tetapkan jumlah shard yang lebih besar hanya untuk tabel yang sangat besar. Jumlah shard tinggi tidak direkomendasikan untuk tabel standar.

Sumber daya instans default

Hologres menyediakan jumlah koneksi maksimum default dan jumlah shard yang telah dialokasikan sebelumnya berdasarkan spesifikasi sumber daya instans. Konfigurasi default ditampilkan dalam tabel berikut.

Sejak 25 April 2022, instans general-purpose mendukung spesifikasi sumber daya komputasi mulai dari 512 CUs hingga 1.024 CUs. Untuk spesifikasi yang lebih tinggi, Anda dapat mengajukan tiket. Sebelum melakukan upgrade ke spesifikasi sumber daya yang lebih besar, Anda harus memutakhirkan instans Anda ke V1.1.58 atau versi yang lebih baru.

Untuk instans compute group, Anda dapat secara fleksibel membeli spesifikasi apa pun dari 32 CUs hingga 8.192 CUs tanpa perlu mengajukan tiket.

Catatan

Setiap tipe instans mencakup node komputasi dan node akses frontend. Setiap 16 CUs setara dengan satu node komputasi. Untuk spesifikasi 512 CUs atau kurang, jumlah node komputasi default sama dengan jumlah node frontend. Untuk spesifikasi 1.600 CUs atau lebih, jumlah node frontend tetap sebanyak 100.
Jika Anda melakukan scale-out instans kurang dari lima kali ukuran aslinya, jangan sesuaikan jumlah shard. Spesifikasi default ini cocok untuk sebagian besar skenario dan memberikan konfigurasi seimbang untuk operasi tulis dan kueri.
Total koneksi maksimum = Koneksi maksimum per node frontend × Jumlah node frontend. Nilai dalam tanda kurung menunjukkan spesifikasi untuk setiap node. Angka sebelum tanda perkalian adalah jumlah koneksi maksimum per node akses, sedangkan angka setelahnya adalah total jumlah node akses frontend.

Tipe instans	Jumlah node komputasi	Jumlah shard default	Total koneksi maksimum (untuk V2.1 dan versi sebelumnya)	Total koneksi maksimum (untuk V2.2 dan versi lebih baru)	Total koneksi ter-reserve untuk Superuser (untuk V1.1 dan versi lebih baru)
32 CUs	2	20	256 (128 × 2)	512 (256 × 2)	10 (5 × 2)
48 hingga 80 CUs	3 hingga 5	40	128 × Jumlah Node Komputasi	256 × Jumlah Node Komputasi	5 × Jumlah node komputasi
96 hingga 112 CUs	6 hingga 7	60	128 × Jumlah Node Komputasi	256 × Jumlah Node Komputasi	5 × Jumlah node komputasi
128 hingga 192 CUs	8 hingga 12	80	128 × Jumlah Node Komputasi	256 × Jumlah Node Komputasi	5 × Jumlah node komputasi
208 hingga 352 CUs	13 hingga 22	120	128 × Jumlah Node Komputasi	256 × Jumlah Node Komputasi	5 × Jumlah node komputasi
368 hingga 992 CUs	23 hingga 62	160	128 × Jumlah Node Komputasi	256 × Jumlah Node Komputasi	5 × Jumlah node komputasi
1.008 hingga 1.584 CUs	63 hingga 99	200	128 × Jumlah Node Komputasi	256 × Jumlah Node Komputasi	5 × Jumlah node komputasi
1.600 hingga 2.272 CUs	100 hingga 142	200	12.800 (128 × 100)	25.600 (256 × 100)	500 (5 × 100)
2.288 hingga 4.000 CUs	143 hingga 250	240	12.800 (128 × 100)	25.600 (256 × 100)	500 (5 × 100)
4.016 hingga 8.000 CUs	251 hingga 500	320	12.800 (128 × 100)	25.600 (256 × 100)	500 (5 × 100)
8.016 hingga 8.192 CUs	501 hingga 512	400	12.800 (128 × 100)	25.600 (256 × 100)	500 (5 × 100)

Lihat dan kelola koneksi instans default

Hologres memungkinkan Anda melihat dan mengelola jumlah koneksi default untuk suatu instans.

Lihat jumlah koneksi.
Setelah membuat instans dan menghubungkannya ke tool developer, Anda dapat menjalankan pernyataan berikut untuk melihat jumlah koneksi maksimum untuk satu node akses frontend. Nilai kembali adalah jumlah koneksi maksimum untuk satu node akses frontend.

Catatan
Total koneksi maksimum untuk instans Hologres = Koneksi maksimum per node frontend × Jumlah node frontend.
```
-- Lihat jumlah koneksi maksimum untuk satu node akses. Koneksi diseimbangkan di beberapa node akses.
show max_connections;
```
Kelola koneksi.

Instans menyediakan koneksi ter-reserve untuk Superuser. Saat jumlah koneksi mencapai batas default, Superuser dapat terhubung ke Hologres dan menggunakan perintah SQL untuk melihat serta melepaskan koneksi idle, atau melakukan upgrade instans sesuai kebutuhan. Untuk informasi lebih lanjut tentang cara melihat dan melepaskan koneksi idle, lihat Koneksi.

Lihat dan ubah jumlah shard instans

Setelah melakukan scale-out instans, biasanya Anda tidak perlu menyesuaikan jumlah shard karena sumber daya core tambahan dapat memberikan konkurensi kueri yang lebih baik. Jika Anda memerlukan throughput penulisan yang lebih tinggi, Anda dapat menambah jumlah shard untuk meningkatkan throughput penulisan konkuren.

Selain itu, untuk Tabel berorientasi baris, jumlah shard yang lebih banyak menghasilkan performa baca yang lebih tinggi karena karakteristik distribusinya yang alami. Untuk melihat dan mengubah jumlah shard instans, lihat Panduan Pengguna Table Group dan Jumlah Shard.