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 workload analitik di mana efisiensi biaya dan throughput penulisan lebih penting daripada uptime maksimum.
Edisi Berkinerja-tinggi cocok 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 bersifat mission-critical |
Pilih Edisi Berkinerja-tinggi jika workload Anda dapat mentoleransi jendela pemulihan dalam hitungan menit hingga jam saat terjadi kegagalan perangkat keras. Untuk workload 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 di bawah ini menunjukkan harga bulanan dalam USD untuk kedua edisi pada dua tingkat spesifikasi umum.
| Spesifikasi | Penyimpanan HPE (USD/bulan) | Penyimpanan HAE (USD/bulan) | Pengurangan penyimpanan | Compute HPE (USD/bulan) | Compute HAE (USD/bulan) | Reduksi Komputasi | Total HPE (USD/bulan) | Total HAE (USD/bulan) | Pengurangan total |
|---|---|---|---|---|---|---|---|---|---|
| Entry-level | 22,4 | 100 | 77,6% | 175,55 | 352,05 | 50,13% | 197,95 | 452,05 | 56,21% |
| Umum | 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. Workload intensif penulisan 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
Pengujian ini didasarkan pada 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 set 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 beberapa replica internal di lapisan penyimpanan. Hal ini menjamin keandalan dan integritas data yang tinggi bahkan dalam mode single-replica — data tidak hilang ketika compute node gagal.
Skenario kegagalan dan pemulihan
Edisi Berkinerja-tinggi memberikan ketersediaan lebih rendah dibandingkan Edisi Ketersediaan Tinggi karena tidak ada node standby untuk failover. Tabel di bawah ini merangkum perilaku pemulihan untuk skenario kegagalan umum.
| Skenario kegagalan | Edisi Berkinerja-tinggi | Edisi Ketersediaan Tinggi |
|---|---|---|
| SQL crash (core dump, kehabisan memori (OOM)) | ~10 detik (checkpoint dioptimalkan) | 5–10 menit |
| Kegagalan compute node | 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:
-
Menghapus lock dan memori yang tersisa.
-
Memutar ulang file Write-Ahead Log (WAL) untuk memulihkan transaksi yang telah dikomit namun 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 namun 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 berkala dan juga memicunya ketika ukuran file WAL mencapai ambang batas tertentu.
Kegagalan compute node
Ketika 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.
Ketika 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?
Peningkatan versi langsung tidak didukung karena kedua edisi menggunakan jumlah replika dan konfigurasi penyimpanan yang berbeda, sehingga tidak tersedia jalur migrasi otomatis. Untuk beralih edisi, cadangkan data dari instans Edisi Performa Tinggi, beli instans Edisi Ketersediaan Tinggi, lalu pulihkan data tersebut di instans baru. Untuk petunjuk migrasi, lihat Migrasikan data antar instans AnalyticDB for PostgreSQL.