AnalyticDB for PostgreSQL Edisi Berkinerja-tinggi menggunakan arsitektur single-replica untuk mengurangi biaya penyimpanan dan memberikan kinerja write I/O yang lebih tinggi dibandingkan Edisi Ketersediaan Tinggi. Edisi ini cocok untuk beban kerja analitik di mana efisiensi biaya dan throughput write lebih penting daripada uptime maksimum.
Edisi Berkinerja-tinggi sesuai untuk sebagian besar skenario analisis bisnis. Untuk kebutuhan bisnis inti yang menuntut ketersediaan tertinggi, gunakan Edisi Ketersediaan Tinggi.
Kapan menggunakan Edisi Berkinerja-tinggi
| Kriteria | Edisi Berkinerja-tinggi | Edisi Ketersediaan Tinggi |
|---|---|---|
| Arsitektur | Single replica | Dual replica (primary + standby) |
| Biaya penyimpanan | Lebih rendah (pengurangan 50% dibandingkan spesifikasi yang sama) | Lebih tinggi |
| Write I/O Performance | Lebih tinggi (tanpa overhead replikasi) | Lebih rendah |
| Pemulihan dari crash SQL | ~10 detik | 5–10 menit |
| Pemulihan dari kegagalan compute node | Diperlukan restart; tidak ada failover otomatis | Failover otomatis; tidak ada gangguan layanan |
| Pemulihan dari kegagalan host | Diperlukan restart setelah migrasi host; ~15 menit | Failover otomatis; migrasi berjalan di latar belakang |
| Paling cocok untuk | Analitik, pemrosesan batch, workload yang sensitif terhadap biaya | OLAP produksi yang mission-critical |
Pilih Edisi Berkinerja-tinggi jika beban kerja Anda dapat mentolerir jendela pemulihan dalam hitungan menit hingga jam saat terjadi kegagalan perangkat keras. Untuk beban kerja yang memerlukan ketersediaan berkelanjutan selama kegagalan perangkat keras, gunakan Edisi Ketersediaan Tinggi.
Arsitektur
Edisi Berkinerja-tinggi menerapkan coordinator node dan compute node dalam arsitektur single-replica, seperti yang ditunjukkan di bawah ini.
Gambar 1. Arsitektur Edisi Berkinerja-tinggi
Edisi Ketersediaan Tinggi mencakup coordinator node standby dan compute node secondary.
Gambar 2. Arsitektur Edisi Ketersediaan Tinggi
Menghapus coordinator node standby dan compute node secondary memiliki tiga efek langsung:
Tidak ada penyimpanan yang dialokasikan untuk coordinator node standby.
Penyimpanan compute node berkurang 50%.
Sinkronisasi data antara compute node primary dan secondary dihilangkan, sehingga meningkatkan kinerja write I/O.
Pengurangan biaya
Instans Edisi Berkinerja-tinggi dengan spesifikasi yang sama lebih murah dibandingkan instans Edisi Ketersediaan Tinggi karena hanya mempertahankan satu replica.
Tabel berikut menunjukkan harga bulanan dalam USD untuk kedua edisi pada dua level spesifikasi umum.
| Spesifikasi | Penyimpanan HPE (USD/bln) | Penyimpanan HAE (USD/bln) | Pengurangan penyimpanan | Compute HPE (USD/bln) | Compute HAE (USD/bln) | Pengurangan Komputasi | Total HPE (USD/bln) | Total HAE (USD/bln) | Pengurangan total |
|---|---|---|---|---|---|---|---|---|---|
| Entry-level | 22,4 | 100 | 77,6% | 175,55 | 352,05 | 50,13% | 197,95 | 452,05 | 56,21% |
| Common | 89,6 | 200 | 55,2% | 668,65 | 700,28 | 4,52% | 758,25 | 900,28 | 15,78% |
Spesifikasi entry-level: Edisi Berkinerja-tinggi (HPE) menggunakan 2 core CPU, penyimpanan 50 GB, dan 2 compute node. Edisi Ketersediaan Tinggi (HAE) menggunakan 2 core CPU, penyimpanan 50 GB, dan 4 compute node. Pada spesifikasi ini, HPE 56% lebih murah.
Spesifikasi umum: Kedua edisi menggunakan 4 core CPU, penyimpanan 100 GB, dan 4 compute node. Pada spesifikasi ini, HPE 15% lebih murah.
Untuk harga terkini, lihat harga AnalyticDB for PostgreSQL.
Kinerja
Edisi Berkinerja-tinggi memberikan kinerja I/O yang lebih tinggi karena menghilangkan sinkronisasi data dan replikasi streaming antara compute node primary dan secondary. Pada instans dengan 2 core CPU, kinerja I/O dapat mencapai hingga 250% dari instans Edisi Ketersediaan Tinggi yang sebanding. Beban kerja intensif-write mengalami peningkatan sekitar 100%.
Benchmark berikut membandingkan kedua edisi yang dikonfigurasi dengan 2 core CPU, penyimpanan 400 GB, dan 4 compute node.
Replikasi lokal
Mereplikasi tabel berorientasi baris yang berisi sekitar 90 GB data:
CREATE TABLE lineitem2 AS (SELECT * FROM lineitem);| Edisi | Waktu eksekusi |
|---|---|
| Edisi Berkinerja-tinggi | 249 detik |
| Edisi Ketersediaan Tinggi | 1.307 detik |
Edisi Berkinerja-tinggi menyelesaikan operasi sekitar 5x lebih cepat. Peningkatan serupa berlaku untuk operasi INSERT INTO SELECT.
Benchmark TPC-H
Uji ini berdasarkan metodologi benchmark TPC-H tetapi tidak memenuhi semua persyaratan TPC-H. Hasilnya tidak dapat dibandingkan dengan hasil TPC-H yang dipublikasikan.
22 kueri SQL dijalankan pada dataset TPC-H 100 GB. Gambar berikut menunjukkan hasilnya.
Edisi Berkinerja-tinggi menyelesaikan seluruh rangkaian kueri 40% lebih cepat dibandingkan Edisi Ketersediaan Tinggi, mencerminkan keunggulan I/O dari penghapusan overhead replikasi.
Ketersediaan
Keandalan data
AnalyticDB for PostgreSQL menyimpan data pada enhanced solid-state drives (ESSDs), yang menggunakan multiple internal replica di lapisan penyimpanan. Hal ini menjamin keandalan dan integritas data yang tinggi bahkan dalam mode single-replica — data tidak hilang saat compute node gagal.
Skenario kegagalan dan pemulihan
Edisi Berkinerja-tinggi menyediakan ketersediaan lebih rendah dibandingkan Edisi Ketersediaan Tinggi karena tidak ada node standby untuk failover. Tabel berikut merangkum perilaku pemulihan untuk skenario kegagalan umum.
| Skenario kegagalan | Edisi Berkinerja-tinggi | Edisi Ketersediaan Tinggi |
|---|---|---|
| Crash SQL (core dump, kehabisan memori (OOM)) | ~10 detik (checkpoint dioptimalkan) | 5–10 menit |
| Kegagalan node komputasi | Diperlukan restart; layanan tidak tersedia hingga restart selesai | Failover otomatis; node secondary mengambil alih tanpa gangguan layanan |
| Kegagalan host | Diperlukan restart setelah migrasi host; ~15 menit | Failover otomatis; migrasi host berjalan di latar belakang |
Untuk kegagalan mesin fisik, pemulihan dapat memakan waktu hingga 8 jam dalam skenario ekstrem.
Cara kerja mode pemulihan
Sebagian besar kegagalan di AnalyticDB for PostgreSQL — termasuk crash SQL akibat core dump atau error OOM — memicu mode pemulihan alih-alih kegagalan node penuh. Selama mode pemulihan, instans:
Membersihkan lock dan memori yang tersisa.
Memutar ulang file Write-Ahead Log (WAL) untuk memulihkan transaksi yang telah dikomit tetapi belum ditulis ke disk.
Melanjutkan layanan.
Edisi Berkinerja-tinggi menggunakan mekanisme checkpoint yang dioptimalkan sehingga mengurangi jumlah data WAL yang perlu diputar ulang. Pemulihan dari skenario kegagalan umum ini memakan waktu sekitar 10 detik, dibandingkan 5–10 menit untuk Edisi Ketersediaan Tinggi.
WAL dan checkpoint
Write-Ahead Log (WAL): Mencatat semua perubahan data untuk setiap transaksi sebelum transaksi tersebut dikomit. WAL memungkinkan database memutar ulang perubahan yang telah dikomit tetapi belum disimpan ke disk.
Checkpoint: Titik hingga mana semua perubahan data telah dikonfirmasi di disk. Database melakukan pemulihan dari checkpoint terbaru. AnalyticDB for PostgreSQL menjalankan checkpoint secara terjadwal dan juga memicunya ketika ukuran file WAL mencapai ambang batas.
Kegagalan compute node
Saat compute node gagal di Edisi Ketersediaan Tinggi, compute node secondary mengambil alih secara otomatis. Node yang rusak melakukan restart di latar belakang tanpa gangguan layanan.
Saat compute node gagal di Edisi Berkinerja-tinggi, tidak ada node secondary yang mengambil alih. Instans menjadi tidak tersedia dan harus direstart untuk pemulihan.
Kegagalan host
Kegagalan host memicu migrasi host otomatis di kedua edisi. Di Edisi Ketersediaan Tinggi, node standby menjaga kontinuitas layanan sementara migrasi berjalan di latar belakang. Di Edisi Berkinerja-tinggi, instans harus direstart setelah migrasi host selesai — proses yang memakan waktu sekitar 15 menit.
FAQ
Apakah saya dapat melakukan upgrade dari Edisi Berkinerja-tinggi ke Edisi Ketersediaan Tinggi?
Upgrade langsung in-place tidak didukung. Kedua edisi menggunakan jumlah replica dan konfigurasi penyimpanan yang berbeda, sehingga tidak ada jalur migrasi otomatis. Untuk beralih edisi, backup data dari instans Edisi Berkinerja-tinggi, beli instans Edisi Ketersediaan Tinggi, lalu restore data ke sana. Untuk instruksi migrasi, lihat Migrasi data antar instans AnalyticDB for PostgreSQL.