Tair (Redis® OSS-Compatible):Perbandingan antara Tair (Redis OSS-compatible) dan Redis yang dikelola sendiri

Dimensi

Tair (Redis OSS-compatible)

Redis yang dikelola sendiri

Keamanan

Isolasi jaringan: Menggunakan virtual private cloud (VPC) untuk mengisolasi lalu lintas pada level jaringan.

Kontrol akses: Kontrol akses berbasis daftar putih (lihat Konfigurasikan daftar putih) dan akun database kustom dengan izin granular (lihat Buat dan kelola akun database).

Enkripsi saat transit: Enkripsi TLS native.

Log audit: Mendukung log audit (lihat Kueri log audit).

Isolasi jaringan: Memerlukan sistem keamanan jaringan kustom, yang mahal untuk dibangun dan dipelihara. Konfigurasi akses Redis default memiliki kerentanan keamanan yang dapat mengekspos data.

Kontrol akses: Tidak memiliki sistem autentikasi akun bawaan.

Enkripsi saat transit: Memerlukan alat pihak ketiga untuk menerapkan enkripsi SSL.

Log audit: Tidak memiliki fitur audit.

Backup dan pemulihan

Instans berbasis DRAM dari Tair (Edisi Perusahaan) mendukung flashback data — memulihkan data ke titik waktu tertentu. Lihat Gunakan flashback data untuk memulihkan data berdasarkan titik waktu.

Hanya pemulihan data penuh — tidak ada pemulihan pada titik waktu.

O&M

• Lebih dari sepuluh kelompok metrik pemantauan dengan interval pemantauan minimum 5 detik. Lihat Metrik.

• Aturan peringatan yang dapat dikonfigurasi. Lihat Pengaturan peringatan.

• Mendukung beberapa arsitektur instans; ubah spesifikasi atau arsitektur sesuai kebutuhan.

• Analisis key besar berbasis snapshot — akurasi tinggi tanpa dampak pada performa. Lihat Gunakan fitur analisis key offline.

• Memerlukan alat pihak ketiga untuk pemantauan.

• Mengubah spesifikasi atau arsitektur instans memerlukan gangguan layanan dan melibatkan langkah manual yang kompleks.

• Analisis key besar berbasis pengambilan sampel — hasilnya bisa tidak akurat.

Penerapan dan penskalaan

Skalabilitas elastis dan pembuatan instans instan — tidak perlu menyediakan atau mengelola perangkat keras.

Memerlukan pengadaan perangkat keras, penyiapan pusat data, dan penerapan node. Menambahkan node memerlukan pengelolaan hubungan antar-node secara manual.

Ketersediaan tinggi (HA)

• Tersedia solusi HA satu zona dan pemulihan bencana antar-zona.

• Menggunakan modul pusat independen untuk pengambilan keputusan failover — stabil, efisien, dan tahan terhadap masalah split-brain.

• HA dalam mode Sentinel di dalam satu pusat data, atau pemulihan bencana antar-zona dalam mode Sentinel.

• Mode Sentinel memiliki biaya operasional tinggi, pengambilan keputusan lebih lambat saat beban puncak, dan rentan terhadap masalah split-brain.

Optimasi kernel

• Instans berbasis DRAM dari Tair (Edisi Perusahaan) menggunakan model multi-threaded, memberikan performa 3× lipat dibandingkan instans standar dengan spesifikasi yang sama.

• Instans berbasis ESSD/SSD dan instans yang dioptimalkan untuk memori persisten mendukung penyimpanan berkapasitas besar dan persistensi tingkat perintah.

• Redis 6.0 dan versi setelahnya mendukung beberapa thread I/O, yang dapat meningkatkan throughput hingga 2× tetapi juga meningkatkan utilisasi CPU secara signifikan.

• Penyimpanan persisten mengandalkan solusi pihak ketiga seperti SSDB atau Pika, yang tidak sepenuhnya kompatibel dengan protokol Redis dan hanya mendukung tiering data panas/dingin pada level key. Transfer key besar antara memori dan disk sangat mahal.

Pemanfaatan memori

100% kapasitas yang dialokasikan tersedia untuk aplikasi Anda. Overhead memori untuk pemulihan bencana, O&M, penskalaan, dan persistensi data (termasuk replikasi write-time berbasis fork) ditanggung oleh Alibaba Cloud.

Contoh: Instans 64 GB menyediakan 64 GB memori yang dapat digunakan.

25%–40% dari total memori dicadangkan untuk pemulihan bencana, O&M, dan operasi penskalaan.

Contoh: Dua instans Elastic Compute Service (ECS) berukuran 64 GB yang dikonfigurasi sebagai pasangan master/replica biasanya menyediakan kurang dari 45 GB memori yang dapat digunakan secara total.