จำเป็นต้องมี Redis ไหม? ในเมื่อ PostgreSQL มีทั้งคิวอิง ล็อกกิง และ pub/sub ให้ใช้ (2021)

 (spin.atomicobject.com)
2 คะแนน โดย GN⁺ 2024-11-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

  • กรณีใช้งาน 1: การจัดคิวงาน

    • Redis มักถูกใช้เพื่อประสานงานงานเบื้องหลังในเว็บเซอร์วิส
    • ตั้งแต่ PostgreSQL เวอร์ชัน 9.5 เป็นต้นมา สามารถใช้ตัวเลือก SKIP LOCKED เพื่อทำระบบคิวงานได้
    • ตัวเลือกนี้ช่วยให้เลือกงานได้โดยไม่ต้องรอการล็อก ทำให้มั่นใจได้ว่าผู้ปฏิบัติงานหลายรายจะไม่ประมวลผลงานเดียวกันพร้อมกัน

  • กรณีใช้งาน 2: การล็อกระดับแอปพลิเคชัน

    • Redis มักถูกใช้สำหรับ distributed locking
    • สามารถทำความสามารถแบบเดียวกันได้ด้วย advisory lock ของ PostgreSQL
    • advisory lock ช่วยให้นำเอนจินการล็อกภายในของ PostgreSQL มาใช้ตามวัตถุประสงค์ที่กำหนดโดยแอปพลิเคชันได้

  • กรณีใช้งาน 3: Pub/Sub

    • Redis ถูกใช้เพื่อ push อีเวนต์ไปยังไคลเอนต์ที่กำลังเชื่อมต่ออยู่
    • ตั้งแต่ PostgreSQL เวอร์ชัน 9 เป็นต้นมา มีความสามารถแบบ Pub/Sub ผ่านคำสั่ง LISTEN และ NOTIFY
    • ไคลเอนต์ PostgreSQL สามารถ subscribe ช่องข้อความที่ต้องการได้ และเมื่อไคลเอนต์อื่นส่งข้อความไปยังช่องนั้น ผู้ติดตามทั้งหมดจะได้รับการแจ้งเตือน

  • การใช้ PostgreSQL ให้คุ้มค่าครบถ้วน

    • Redis ถูกใช้ในงานที่ต่างจาก PostgreSQL และโดดเด่นด้านการแคชข้อมูลที่มี TTL รวมถึงการเก็บข้อมูลชั่วคราว
    • PostgreSQL ให้ความสามารถมากกว่าการเป็นฐานข้อมูล SQL และมีความเป็นไปได้ที่จะใช้ PostgreSQL แทนงานบางอย่างที่เดิมใช้ Redis
    • นี่อาจเป็นทางเลือกที่มีคุณค่าในการลดความซับซ้อนจากการใช้บริการข้อมูลหลายตัว และลดต้นทุนการดำเนินงาน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-11-04
ความคิดเห็นจาก Hacker News

  • Redis ให้เวลาในการตอบสนองที่รวดเร็วมากเมื่อรันอยู่บนเครื่องเดียวกับแอปพลิเคชัน ซึ่งทำให้ทำงานบางอย่างที่ต่างจาก Postgres ได้

    • คลังเก็บคีย์-แวลูแบบอินเมมโมรีเหมาะกับงานที่ต้องการคุณลักษณะด้านประสิทธิภาพของ RAM
    • เป็นเรื่องชัดเจนอยู่แล้วว่าไม่สามารถได้ประสิทธิภาพระดับ RAM ผ่านการเชื่อมต่อเครือข่าย

  • PostgreSQL มีความสามารถมากกว่าเป็นเพียงฐานข้อมูล SQL ธรรมดา

    • หากใช้ฐานข้อมูลแค่ผ่าน ORM ก็อาจพลาดความสามารถเหล่านี้ไป
    • การใช้ฐานข้อมูลที่ตั้งค่าไว้อยู่แล้วอาจดีกว่าการเพิ่มบริการอย่าง Redis เข้าไป

  • PGQueuer เป็นทางเลือกแบบมินิมอลที่ใช้ PostgreSQL เพื่อให้คิวงาน การล็อก และการแจ้งเตือนแบบเรียลไทม์

    • ช่วยลดความจำเป็นในการใช้ Redis

  • Postgres เป็นฐานข้อมูลที่ทรงพลัง

    • Redis ใช้งานได้ง่าย ให้ประสิทธิภาพสูง และช่วยลดภาระของฐานข้อมูลหลัก
    • การแคชการตอบกลับของ API ก็ทำได้ใน Postgres แต่ใช้ Redis จะง่ายกว่า
    • การใช้ระบบแยกต่างหากมีข้อเสีย แต่ในกรณีของ Redis ข้อเสียนั้นไม่มากนัก

  • โปรเจกต์ส่วนใหญ่ต้องการเพียงคิวงานแบบง่าย ๆ และการทำให้สแตกที่ซับซ้อนเรียบง่ายลงเป็นเรื่องสำคัญ

    • มีทางเลือกหลากหลายที่มีแรงจูงใจเชิงพาณิชย์อยู่เบื้องหลัง

  • Postgres มีข้อจำกัดอยู่บางประการ

    • ฟังก์ชันอย่าง KV store, คิว, pub/sub, การล็อก และอื่น ๆ สามารถทำได้ แต่ไม่ง่าย

  • ควรเริ่มต้นด้วย PostgreSQL แล้วค่อยเปลี่ยนไปใช้ Redis เมื่อจำเป็น

    • การลดจำนวนส่วนประกอบที่ต้องดูแลให้เหลือน้อยที่สุดเป็นสิ่งสำคัญ

  • ข้อเสียใหญ่ของ pub/sub ใน Postgres คือขนาดข้อความถูกจำกัดไว้ที่ 8000 ไบต์

    • มีวิธีเก็บข้อมูลไว้ในฐานข้อมูลแล้วส่ง ID แทน แต่ก็ต้องเพิ่มงานอีก

  • การแคชซึ่งเป็นหนึ่งในการใช้งานที่สำคัญที่สุดของ Redis ทำได้ซับซ้อนกว่าใน Postgres

    • การอัปเดตใน Postgres มีต้นทุนสูงกว่าการแทรก และการรับประกันความทนทานไม่ได้สำคัญสำหรับงานแคช

  • เมื่อใช้ความสามารถเหล่านี้ใน Postgres การอัปเดตและการทำซ้ำข้อมูลจะยากขึ้น

    • ทำได้ แต่หลายคนชอบโฟกัสกับความสามารถของ Postgres ที่มีการใช้งานแพร่หลายมากกว่า