การทดสอบเปรียบเทียบล่าสุดระหว่าง PostgreSQL และ Redis สำหรับการทำ cache ได้สร้างการถกเถียงอย่างมากในชุมชนนักพัฒนา โดยผลลัพธ์แสดงให้เห็นว่า PostgreSQL มีประสิทธิภาพประมาณสองในสามของ Redis ขณะเดียวกันก็ทำให้เกิดคำถามเกี่ยวกับวิธีการทดสอบ
การศึกษาเดิมได้ทดสอบฐานข้อมูลทั้งสองโดยใช้ Kubernetes clusters ที่มีการจำกัดทรัพยากรเฉพาะ พบว่า Redis มีประสิทธิภาพเหนือกว่า PostgreSQL อย่างสม่ำเสมอในงานต่างๆ อย่างไรก็ตาม การทดสอบนี้ได้รับการวิพากษ์วิจารณ์อย่างรุนแรงจากชุมชนเทคนิคเรื่องแนวทางและข้อสรุป
ผลการเปรียบเทียบประสิทธิภาพ
| ประเภทการทดสอบ | Redis (req/sec) | PostgreSQL (req/sec) | ข้อได้เปรียบของ Redis |
|---|---|---|---|
| การดำเนินการ GET | 2,327 | 1,686 | เร็วกว่า 38% |
| การดำเนินการ SET | 2,586 | 1,453 | เร็วกว่า 78% |
| งานแบบผสม | 2,377 | 1,497 | เร็วกว่า 59% |
การกำหนดค่าการทดสอบ:
- ฮาร์ดแวร์: จำกัด CPU 20 คอร์ การจัดสรรหน่วยความจำสูง
- เวอร์ชันฐานข้อมูล: PostgreSQL 15, Redis 7
- ชุดข้อมูล: 10 ล้านรายการ
- ระยะเวลาการทดสอบ: 1 นาทีต่อการทดสอบ
- อัตราการโดน cache: 80% สำหรับการดำเนินการ GET, อัตราการอัปเดต 10% สำหรับการดำเนินการ SET
วิธีการทดสอบที่มีข้อบกพร่องทำให้ผลลัพธ์ไม่น่าเชื่อถือ
ความถูกต้องของการทดสอบได้รับการตรวจสอบอย่างเข้มข้นจากนักพัฒนาที่ชี้ให้เห็นปัญหาพื้นฐานในการตั้งค่าการทดสอบ นักวิจารณ์เน้นว่า PostgreSQL ถูกจำกัดด้วย CPU ที่ใช้งาน 100% บนคอร์ที่จัดสรรให้ ในขณะที่ Redis ถูกจำกัดด้วย HTTP server มากกว่าฐานข้อมูลเอง นั่นหมายความว่าการเปรียบเทียบไม่ได้วัดศักยภาพประสิทธิภาพที่แท้จริงของระบบทั้งสองภายใต้เงื่อนไขที่ยุติธรรม
แนวทางการทดสอบยังไม่ได้ใช้เทคนิคการเพิ่มประสิทธิภาพที่มีให้กับทั้งสองระบบ สำหรับ Redis คุณสมบัติอย่าง pipelining และ auto-pipelining clients อาจส่งผลให้ประสิทธิภาพดีขึ้น 10 เท่า PostgreSQL ก็รองรับ query pipelining ผ่าน client libraries ยอดนิยมเช่นกัน ซึ่งไม่ได้ถูกสำรวจในการทดสอบ
การใช้ทรัพยากรระหว่างการทดสอบ
ประสิทธิภาพของ Redis :
- การใช้งาน CPU: ประมาณ 1,200-1,280 mCPU (ต่ำกว่าขีดจำกัด 2,000 mCPU อย่างมาก)
- การใช้งานหน่วยความจำ: 3,800-4,300 MB
- จุดคอขวด: HTTP server ไม่ใช่ตัว Redis เอง
ประสิทธิภาพของ PostgreSQL :
- การใช้งาน CPU: 100% ของ 2 cores ที่จัดสรรให้ (ขีดจำกัด 2,000 mCPU)
- การใช้งานหน่วยความจำ: 5,000-6,000 MB
- จุดคอขวด: การใช้งาน CPU ของฐานข้อมูล
ข้อค้นพบสำคัญ: PostgreSQL ถูกจำกัดด้วย CPU ในขณะที่ Redis ถูกจำกัดด้วย HTTP server ทำให้การเปรียบเทียบประสิทธิภาพอาจทำให้เข้าใจผิดได้
คำถามเรื่องประสิทธิภาพในโลกแห่งความเป็นจริง
นอกเหนือจากข้อกังวลเรื่องวิธีการแล้ว การถกเถียงในชุมชนยังเผยให้เห็นคำถามที่ลึกซึ้งกว่าเกี่ยวกับความต้องการประสิทธิภาพในทางปฏิบัติ การทดสอบแสดงให้เห็นว่า PostgreSQL จัดการได้ประมาณ 1,500 requests ต่อวินาที ซึ่งแปลเป็นมากกว่าครึ่งพันล้าน requests ต่อวัน สำหรับแอปพลิเคชันส่วนใหญ่ ระดับประสิทธิภาพนี้เกินความต้องการจริงไปมาก
นักพัฒนาหลายคนโต้แย้งว่าการเลือกระหว่าง Redis และ PostgreSQL สำหรับ caching ไม่ควรขึ้นอยู่กับตัวเลขประสิทธิภาพดิบเพียงอย่างเดียว การตัดสินใจมักจะขึ้นอยู่กับความซับซ้อนในการดำเนินงาน โครงสร้างพื้นฐานที่มีอยู่ และความแตกต่างของประสิทธิภาพมีความสำคัญจริงหรือไม่สำหรับการใช้งานเฉพาะ
การแลกเปลี่ยนในการดำเนินงานและการพึ่งพา
การถกเถียงได้เน้นให้เห็นข้อพิจารณาด้านการดำเนินงานที่สำคัญซึ่งการทดสอบประสิทธิภาพแบบดิบมองข้าม Redis มีคุณสมบัติในตัวอย่าง automatic key expiration (TTL) ที่จำเป็นสำหรับการทำ cache ที่มีประสิทธิภาพ การใช้ฟังก์ชันคล้ายกันใน PostgreSQL ต้องการส่วนประกอบเพิ่มเติมอย่าง cron jobs และตรรกะการหมดอายุแบบกำหนดเอง
ความสามารถในการตั้ง TTL บน cache key เป็นคุณสมบัติที่สำคัญของ cache ไม่ใช่สิ่งที่สามารถเพิ่มเข้ามาทีหลัง
อย่างไรก็ตาม ผู้สนับสนุนแนวทาง PostgreSQL โต้แย้งว่าการหลีกเลี่ยงการพึ่งพาเพิ่มเติมอาจมีคุณค่า โดยเฉพาะสำหรับโปรเจกต์ขนาดเล็ก พวกเขาชี้ให้เห็นว่าแอปพลิเคชันส่วนใหญ่ต้องการฐานข้อมูลอยู่แล้ว ดังนั้นการใช้ PostgreSQL สำหรับ caching จึงช่วยลดความจำเป็นในการจัดการบริการอื่น ข้อพิจารณาด้านต้นทุนก็สนับสนุนแนวทางนี้เช่นกัน เนื่องจาก PostgreSQL instances มักจะไม่ได้ใช้งานเต็มที่และสามารถจัดการงาน caching เพิ่มเติมได้โดยไม่ต้องเสียค่าใช้จ่ายเพิ่ม
โซลูชันทางเลือกและทิศทางในอนาคต
การถกเถียงยังได้นำความสนใจไปที่โซลูชันแบบผสมอย่าง Redka ซึ่งให้ความเข้ากันได้กับ Redis API ที่รองรับด้วย SQLite หรือ PostgreSQL แนวทางนี้พยายามรวมอินเทอร์เฟซ Redis ที่คุ้นเคยกับความเรียบง่ายในการดำเนินงานของฐานข้อมูล SQL
นักพัฒนาบางคนได้แนะนำว่า PostgreSQL อาจได้ประโยชน์จากคุณสมบัติ caching ในตัว เช่น ความสามารถในการทำเครื่องหมายคอลัมน์ timestamp เป็นคอลัมน์หมดอายุที่จะถูกจัดการโดยอัตโนมัติผ่านกระบวนการ vacuum ของฐานข้อมูล คุณสมบัติดังกล่าวจะทำให้ PostgreSQL แข่งขันได้มากขึ้นสำหรับการใช้งาน caching โดยไม่ต้องใช้เครื่องมือภายนอก
ความขัดแย้งเรื่องการทดสอบสะท้อนให้เห็นความตึงเครียดที่กว้างขึ้นในสถาปัตยกรรมซอฟต์แวร์ระหว่างการเพิ่มประสิทธิภาพและความเรียบง่ายในการดำเนินงาน แม้ว่า Redis จะมีประสิทธิภาพดิบที่เหนือกว่าอย่างชัดเจนสำหรับงาน caching แต่การตัดสินใจในโลกแห่งความเป็นจริงเกี่ยวข้องกับการชั่งน้ำหนักข้อได้เปรียบนั้นกับปัจจัยอย่างความซับซ้อนของโครงสร้างพื้นฐาน ต้นทุน และความต้องการประสิทธิภาพจริง สำหรับแอปพลิเคชันหลายตัว ประสิทธิภาพที่พอใช้ของ PostgreSQL อาจมีคุณค่ามากกว่าประสิทธิภาพสูงสุดของ Redis โดยเฉพาะเมื่อพิจารณาต้นทุนรวมของการเป็นเจ้าของและค่าใช้จ่ายในการดำเนินงาน