Instans Hologres diukur dalam satuan Compute Unit (CU). Karena Hologres menggunakan arsitektur pemisahan komputasi dan penyimpanan, kapasitas penyimpanan dapat diskalakan secara independen—memilih spesifikasi instans pada dasarnya berarti memilih kapasitas komputasi yang sesuai dengan beban kerja Anda.
Halaman ini menjelaskan hubungan antara jumlah CU dengan koneksi, jumlah shard, dan performa kueri sehingga Anda dapat memilih spesifikasi awal dan mengetahui kapan perlu menyesuaikannya.
Konsep utama
CU (Compute Unit) — Unit sumber daya dasar untuk instans Hologres. Setiap 16 CU setara dengan satu node komputasi.
Shard — Unit partisi data dalam Hologres. Setiap shard menangani permintaan baca dan tulis untuk sebagian data. Shard dalam Table Group yang sama mendistribusikan data setiap tabel sehingga operasi join antar tabel yang berada dalam lokasi yang sama tidak memerlukan perpindahan data antar-shard (*local join*). Ketika data tersebar di beberapa shard, operator redistribusi akan mengacak data melalui jaringan—menimbulkan overhead penjadwalan.
Table Group — Pengelompokan logis yang menentukan cara shard diorganisasi. Semua tabel dalam Table Group yang sama memiliki tata letak shard yang identik, memungkinkan local join antar tabel tersebut.
Frontend node — Lapisan akses yang menangani koneksi masuk. Total koneksi untuk suatu instans dihitung sebagai: jumlah koneksi maksimum per frontend node × jumlah frontend node.
Cara jumlah shard memengaruhi performa
Perilaku shard berbeda tergantung jenis beban kerja:
|
Workload |
Effect of more shards |
|
Data writes and updates |
Higher throughput — writes parallelize across shards |
|
Point queries (with shard pruning) |
Higher concurrency — each query hits one shard |
|
OLAP (Online Analytical Processing) queries |
Diminishing returns — multiple shards must coordinate, adding scheduling overhead |
|
Row-oriented tables |
Better read performance — natural distribution across shards |
Setelah melakukan scale-out terhadap instans, penambahan sumber daya komputasi saja sudah meningkatkan konkurensi kueri. Dalam kebanyakan kasus, biarkan jumlah shard tetap tidak berubah kecuali Anda benar-benar membutuhkan throughput tulis yang lebih tinggi. Jika Anda melakukan scale-out kurang dari lima kali ukuran aslinya, jangan sesuaikan jumlah shard.
Jumlah koneksi maksimum tidak dapat diubah. Saat instans diskalakan naik atau turun, batas koneksi akan disesuaikan secara otomatis. Namun, jumlah shard default untuk database yang sudah ada tidak berubah selama proses scaling—perbarui secara manual jika diperlukan. Database baru akan menggunakan jumlah shard default sesuai spesifikasi barunya.
Kapan harus menyesuaikan spesifikasi Anda
Sebelum merujuk ke tabel rekomendasi, periksa apakah spesifikasi saat ini benar-benar menjadi bottleneck. Tanda-tanda berikut mengindikasikan bahwa perubahan spesifikasi kemungkinan diperlukan:
|
Signal |
Likely action |
|
Connection count is near or at the instance limit |
Scale out (adds frontend nodes and raises connection ceiling) |
|
Write throughput cannot keep up with ingest rate |
Scale out, then increase shard count for existing databases |
|
OLAP query latency is high but concurrency is low |
Scale out for more compute nodes; do not increase shard count |
|
Point query concurrency has plateaued |
Scale out, then increase shard count if shard pruning is active |
Jalankan pernyataan berikut untuk memeriksa penggunaan koneksi saat ini terhadap batasnya:
-- Mengembalikan jumlah koneksi maksimum untuk satu frontend node.
-- Kalikan dengan jumlah frontend node untuk mendapatkan total instans.
show max_connections;Jika tidak ada tanda-tanda tersebut yang muncul, spesifikasi saat ini kemungkinan sudah mencukupi.
Spesifikasi yang direkomendasikan berdasarkan volume data
Spesifikasi yang tepat bergantung pada lebih dari sekadar jumlah baris. Frekuensi akses, volume data yang diakses, beban kerja komputasi (kueri titik vs. analitik), throughput tulis, dan jumlah tabel dalam satu Table Group semuanya turut berperan. Gunakan tabel berikut sebagai titik awal.
Rekomendasi ini bersifat panduan, bukan batasan mutlak. Tabel dengan volume data kecil dapat berjalan pada instans dengan jumlah shard tinggi; tabel besar pun dapat berjalan pada instans single-shard. Sesuaikan jumlah shard dengan target konkurensi Anda, sekaligus pastikan data cukup terkonsentrasi untuk menghindari overhead shuffle yang tidak perlu.
|
Total data size |
Recommended spec |
Recommended shard count |
Workload fit |
|
Less than 40 million rows |
32 cores or more |
10–20 |
Development and testing. Not suitable for stress testing. |
|
40 million–400 million rows |
64 cores or more |
20–40 |
Simple workloads: moderate write throughput, no mixed OLAP + point query concurrency. |
|
400 million–4 billion rows |
128 cores or more |
40–80 |
Balanced writes and queries. Default starting point for production. |
|
4 billion–40 billion rows |
256 cores or more |
80–240 |
High-throughput write or large-scale OLAP. Use multiple Table Groups; divide by business cohesion or data volume; specify the Table Group explicitly when creating tables. |
|
40 billion–400 billion rows |
512 cores or more |
160–400 |
Very large-scale OLAP or multi-tenant workloads. Use multiple Table Groups (same guidance as above). Reserve high shard counts for very large tables only—standard tables do not benefit. |
Sumber daya default berdasarkan spesifikasi instans
Sejak 25 April 2022, instans general-purpose mendukung 512 CU hingga 1.024 CU. Untuk spesifikasi yang lebih tinggi, submit a ticket. Sebelum melakukan upgrade ke spesifikasi yang lebih besar, upgrade instans ke V1.1.58 atau versi yang lebih baru.
Instans compute group mendukung semua spesifikasi dari 32 CU hingga 8.192 CU tanpa perlu tiket.
-
Setiap 16 CU setara dengan satu node komputasi.
-
Untuk spesifikasi 512 CU atau kurang: jumlah node komputasi sama dengan jumlah frontend node.
-
Total koneksi maksimum = koneksi maksimum per frontend node × jumlah frontend node. Nilai dalam tanda kurung menunjukkan angka per node diikuti jumlah nodenya.
|
Instance spec |
Compute nodes |
Default shard count |
Max connections (V2.1 and earlier) |
Max connections (V2.2 and later) |
Reserved connections for Superuser (V1.1 and later) |
|
32 CUs |
2 |
20 |
256 (128 × 2) |
512 (256 × 2) |
10 (5 × 2) |
|
48–80 CUs |
3–5 |
40 |
128 × number of compute nodes |
256 × number of compute nodes |
5 × number of compute nodes |
|
96–112 CUs |
6–7 |
60 |
128 × number of compute nodes |
256 × number of compute nodes |
5 × number of compute nodes |
|
128–192 CUs |
8–12 |
80 |
128 × number of compute nodes |
256 × number of compute nodes |
5 × number of compute nodes |
|
208–352 CUs |
13–22 |
120 |
128 × number of compute nodes |
256 × number of compute nodes |
5 × number of compute nodes |
|
368–992 CUs |
23–62 |
160 |
128 × number of compute nodes |
256 × number of compute nodes |
5 × number of compute nodes |
Apa yang berubah secara otomatis saat Anda melakukan scaling
Saat Anda melakukan scale-out atau scale-in terhadap instans, perubahan berikut terjadi secara otomatis:
|
Configuration |
Behavior during scaling |
|
Maximum connections |
Adjusted automatically to match the new spec |
|
Default shard count (new databases) |
Uses the default for the new spec |
|
Default shard count (existing databases) |
Does not change—update manually if needed |
Artinya, setelah scale-out, database yang sudah ada tetap mempertahankan jumlah shard aslinya. Node komputasi tambahan tetap meningkatkan konkurensi kueri karena lebih banyak core yang memproses setiap kueri. Perbarui jumlah shard secara manual hanya jika Anda membutuhkan throughput tulis yang lebih tinggi atau berencana menambahkan data dalam jumlah signifikan.
Lihat dan kelola koneksi
Periksa batas koneksi saat ini
Setelah terhubung ke tool developer, jalankan pernyataan berikut untuk melihat jumlah koneksi maksimum untuk satu frontend node:
-- Lihat jumlah koneksi maksimum untuk satu frontend node.
-- Koneksi didistribusikan merata di seluruh frontend node.
show max_connections;Kalikan nilai yang dikembalikan dengan jumlah frontend node untuk mendapatkan total batas koneksi instans.
Kelola koneksi saat batas tercapai
Setiap instans menyediakan koneksi khusus untuk role Superuser. Saat batas koneksi tercapai, Superuser dapat terhubung dan menggunakan SQL untuk melihat serta melepaskan koneksi idle, atau melakukan scale-up terhadap instans. Untuk detailnya, lihat Connections.
Lihat dan ubah jumlah shard
Scale-out instans tidak mengubah jumlah shard untuk database yang sudah ada—sesuaikan secara manual jika beban kerja Anda memerlukannya. Tingkatkan jumlah shard saat Anda membutuhkan throughput tulis yang lebih tinggi. Untuk tabel berorientasi baris, lebih banyak shard juga meningkatkan performa baca karena distribusi data alami.
Untuk petunjuknya, lihat Table Group and Shard Count user guide.
Langkah selanjutnya
-
Table Group and Shard Count user guide — Buat Table Group dan sesuaikan jumlah shard
-
Connections — Pantau dan lepaskan koneksi idle