Prestasi Cache Postgres vs Redis: Penanda Aras Menunjukkan 2/3 Kelajuan tetapi Mencetuskan Perdebatan Mengenai Kesahihan Ujian

Pasukan Komuniti BigGo
Prestasi Cache Postgres vs Redis: Penanda Aras Menunjukkan 2/3 Kelajuan tetapi Mencetuskan Perdebatan Mengenai Kesahihan Ujian

Penanda aras terkini yang membandingkan PostgreSQL dan Redis untuk caching telah mencetuskan perbincangan hangat dalam komuniti pembangun, dengan keputusan menunjukkan PostgreSQL mencapai kira-kira dua pertiga prestasi Redis sambil menimbulkan persoalan mengenai metodologi ujian itu sendiri.

Kajian asal menguji kedua-dua pangkalan data menggunakan kluster Kubernetes dengan had sumber tertentu, mendapati Redis secara konsisten mengatasi PostgreSQL merentasi beban kerja yang berbeza. Walau bagaimanapun, penanda aras tersebut telah mendapat kritikan tajam daripada komuniti teknikal mengenai pendekatan dan kesimpulannya.

Keputusan Perbandingan Prestasi

Jenis Penanda Aras Redis (req/saat) PostgreSQL (req/saat) Kelebihan Redis
Operasi GET 2,327 1,686 38% lebih pantas
Operasi SET 2,586 1,453 78% lebih pantas
Beban kerja campuran 2,377 1,497 59% lebih pantas

Konfigurasi Ujian:

  • Perkakasan: Had 20 teras CPU, peruntukan memori tinggi
  • Versi pangkalan data: PostgreSQL 15, Redis 7
  • Set data: 10 juta entri
  • Tempoh ujian: 1 minit setiap penanda aras
  • Kadar terkena cache: 80% untuk operasi GET, kadar kemaskini 10% untuk operasi SET

Metodologi Ujian yang Cacat Melemahkan Keputusan

Kesahihan penanda aras telah mendapat penelitian sengit daripada pembangun yang menunjukkan isu asas dengan persediaan ujian. Pengkritik menyerlahkan bahawa PostgreSQL terikat CPU pada 100% penggunaan pada teras yang diperuntukkan, manakala Redis disekat oleh pelayan HTTP dan bukannya pangkalan data itu sendiri. Ini bermakna perbandingan tidak mengukur potensi prestasi sebenar mana-mana sistem dalam keadaan yang adil.

Pendekatan ujian juga gagal menggunakan teknik pengoptimuman prestasi yang tersedia untuk kedua-dua sistem. Untuk Redis , ciri seperti pipelining dan klien auto-pipelining berpotensi memberikan peningkatan prestasi 10x. PostgreSQL juga menyokong query pipelining melalui perpustakaan klien popular, yang tidak diterokai dalam penanda aras.

Penggunaan Sumber Semasa Ujian

Prestasi Redis:

  • Penggunaan CPU: ~1,200-1,280 mCPU (jauh di bawah had 2,000 mCPU)
  • Penggunaan memori: 3,800-4,300 MB
  • Kesesakan: Pelayan HTTP, bukan Redis itu sendiri

Prestasi PostgreSQL:

  • Penggunaan CPU: 100% daripada 2 teras yang diperuntukkan (had 2,000 mCPU)
  • Penggunaan memori: 5,000-6,000 MB
  • Kesesakan: Penggunaan CPU pangkalan data

Penemuan Utama: PostgreSQL terikat dengan CPU manakala Redis dihadkan oleh pelayan HTTP, menjadikan perbandingan prestasi berpotensi mengelirukan.

Persoalan Prestasi Dunia Sebenar

Selain kebimbangan metodologi, perdebatan komuniti mendedahkan persoalan yang lebih mendalam mengenai keperluan prestasi praktikal. Penanda aras menunjukkan PostgreSQL mengendalikan sekitar 1,500 permintaan sesaat, yang diterjemahkan kepada lebih setengah bilion permintaan sehari. Bagi kebanyakan aplikasi, tahap prestasi ini jauh melebihi keperluan sebenar.

Ramai pembangun berpendapat bahawa pilihan antara Redis dan PostgreSQL untuk caching tidak seharusnya berdasarkan semata-mata pada nombor prestasi mentah. Keputusan sering bergantung pada kerumitan operasi, infrastruktur sedia ada, dan sama ada perbezaan prestasi benar-benar penting untuk kes penggunaan tertentu.

Pertukaran Operasi dan Kebergantungan

Perbincangan telah menyerlahkan pertimbangan operasi penting yang terlepas daripada penanda aras prestasi tulen. Redis menawarkan ciri terbina dalam seperti tamat tempoh kunci automatik (TTL) yang penting untuk caching berkesan. Melaksanakan fungsi serupa dalam PostgreSQL memerlukan komponen tambahan seperti cron jobs dan logik tamat tempoh tersuai.

Mempunyai keupayaan untuk menetapkan TTL pada kunci cache adalah ciri kritikal cache, bukan sesuatu yang boleh ditambah kemudian.

Walau bagaimanapun, penyokong pendekatan PostgreSQL berpendapat bahawa mengelakkan kebergantungan tambahan boleh bernilai, terutamanya untuk projek yang lebih kecil. Mereka menunjukkan bahawa kebanyakan aplikasi sudah memerlukan pangkalan data, jadi menggunakan PostgreSQL untuk caching menghapuskan keperluan untuk menguruskan perkhidmatan lain. Pertimbangan kos juga memihak kepada pendekatan ini, kerana instance PostgreSQL sering kurang digunakan dan boleh mengendalikan beban kerja caching tambahan tanpa perbelanjaan tambahan.

Penyelesaian Alternatif dan Hala Tuju Masa Depan

Perdebatan juga telah membawa perhatian kepada penyelesaian hibrid seperti Redka , yang menyediakan keserasian API Redis yang disokong oleh SQLite atau PostgreSQL . Pendekatan ini cuba menggabungkan antara muka Redis yang biasa dengan kesederhanaan operasi pangkalan data SQL .

Sesetengah pembangun telah mencadangkan bahawa PostgreSQL boleh mendapat manfaat daripada ciri caching asli, seperti keupayaan untuk menandakan lajur timestamp sebagai lajur tamat tempoh yang akan dikendalikan secara automatik oleh proses vacuum pangkalan data. Ciri sedemikian akan menjadikan PostgreSQL lebih kompetitif untuk kes penggunaan caching tanpa memerlukan alat luaran.

Kontroversi penanda aras akhirnya mencerminkan ketegangan yang lebih luas dalam seni bina perisian antara pengoptimuman prestasi dan kesederhanaan operasi. Walaupun Redis jelas menawarkan prestasi mentah yang unggul untuk beban kerja caching, keputusan dunia sebenar melibatkan menimbang kelebihan tersebut terhadap faktor seperti kerumitan infrastruktur, kos, dan keperluan prestasi sebenar. Bagi banyak aplikasi, prestasi PostgreSQL yang cukup baik mungkin lebih bernilai daripada prestasi puncak Redis , terutamanya apabila mempertimbangkan jumlah kos pemilikan dan overhed operasi.

Rujukan: Redis is fast - I'll cache in Postgres