การเลือกเทคโนโลยีคิวด้วย Postgres

 (adriano.fyi)
6 คะแนน โดย GN⁺ 2023-09-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คิวของ Postgres นั้นดี แต่เหตุผลที่ยังไม่เป็นกระแสหลักคือมีความเชื่อกันโดยทั่วไปว่าเทคโนโลยีคิวแบบอื่นให้ความสามารถในการขยายระบบได้มากกว่า
  • บริษัทอย่าง webapp.io เลือกใช้คิวของ Postgres เพราะให้ความสำคัญกับความเรียบง่ายในการปฏิบัติการ การบำรุงรักษา และความคุ้นเคย มากกว่าความสามารถในการขยายระบบ
  • องค์ประกอบของเทคโนโลยีคิวของ Postgres
    • การแจ้งและรับฟังงานใหม่ (pub/sub) และการกันการเข้าถึงพร้อมกัน (row locks)
    • ทั้งสองอย่างนี้มีให้ใช้งานตั้งแต่ Postgres 9.5 ที่ออกในปี 2016
  • ผู้เขียนโต้แย้งความเชื่อทั่วไปในอุตสาหกรรมที่ว่าการใช้ Postgres ในลักษณะนี้เป็นการ "แฮ็ก" และยืนยันว่า Postgres ไม่ใช่เทคโนโลยีคิวที่ด้อยคุณค่า
  • ในฐานะเครื่องมือคิวสำหรับจัดการงานที่ใช้เวลานาน มีการเลือกใช้ Redis, Apache Kafka, RabbitMQ และ Amazon SQS กันมาโดยตลอด
  • วิจารณ์ความหมกมุ่นของอุตสาหกรรมเทคโนโลยีกับเรื่อง "สเกล" และการยอมแลกความเรียบง่าย ความสะดวกในการบำรุงรักษา และการลดภาระทางความคิดของนักพัฒนา
  • ผู้เขียนเสนอว่าเมื่อต้องตัดสินใจด้านเทคโนโลยี ควรพิจารณาเทคโนโลยีที่ใช้อยู่ในปัจจุบันและเข้าใจมันเป็นอย่างดี
  • แนะนำให้เลือก "เทคโนโลยีที่แสนน่าเบื่อ" ซึ่งใช้อยู่แล้วและเข้าใจดี
  • แนะนำแนวคิด "สร้างทางหนีไว้ล่วงหน้า" ซึ่งหมายความว่าโค้ดแอปพลิเคชันสำหรับประมวลผลงานควรไม่ผูกติดกับคิว
  • ผู้เขียนสรุปด้วยการสนับสนุนให้ผู้อื่นพิจารณาเทคโนโลยีคิวของ Postgres และใช้ "เทคโนโลยีที่แสนน่าเบื่อ" เป็นตัวเลือกตั้งต้น

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

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

 
GN⁺ 2023-09-25
ความคิดเห็นจาก Hacker News
  • แม้ Kafka จะได้รับการยอมรับในด้านความเรียบง่าย ความคงทน และความทนทานต่อความล้มเหลว แต่ธรรมชาติแบบกระจายของมันอาจเพิ่มความซับซ้อนสำหรับกรณีการใช้งานส่วนใหญ่
  • คิว Postgres สามารถใช้แทนคิว Redis ได้ แต่ไม่สามารถใช้แทนคิว SQS ได้
  • Postgres ถูกใช้เพื่อประมวลผลอีเวนต์มากกว่า 400 ล้านรายการหลังจากระบบเริ่มใช้งาน และประมวลผลได้ราว 1 ล้านอีเวนต์ต่อวัน
  • การใช้ตารางปกติร่วมกับ SELECT FOR UPDATE SKIP LOCKED เป็นแนวทางที่เรียบง่ายซึ่งใช้งานได้กับทุกเฟรมเวิร์ก ORM/Query DSL
  • ข้อเสียหลักของการใช้ LISTEN/NOTIFY เพื่อใช้ PostgreSQL เป็นบัส pub/sub คือ LISTEN เป็นความสามารถระดับเซสชัน จึงไม่เข้ากันกับการทำ connection pooling ระดับ statement
  • การใช้ Postgres เป็นคิวของแอปพลิเคชันมีข้อดีด้านความเป็นทรานแซกชัน ซึ่งงานอะซิงก์ที่ตั้งเวลาไว้จะได้รับประโยชน์จากสิ่งนี้
  • Postgres สามารถขยายเพื่อรองรับคิวได้ แต่การตั้งค่า SQS หรือสแตกคิวอื่นบน AWS, GCP, Azure นั้นง่ายกว่าและถูกสร้างมาให้เหมาะกับจุดประสงค์โดยตรง
  • Postgres รันเบนช์มาร์กได้ที่ 1200 jobs/s บนอินสแตนซ์ github CI และขยายไปถึง 5000 jobs/s ได้ด้วยการเพิ่ม worker
  • Postgres ที่ใช้ Oban ของ Elixir ถูกนำไปใช้ประมวลผลงานเบื้องหลังตั้งแต่หลายแสนถึงหลายล้านงานต่อวัน โดยมีข้อพิสูจน์เชิงปฏิบัติว่าความหมายเชิงทรานแซกชันรอบงานเบื้องหลังนั้นสะดวกมาก
  • การติดตั้งใช้งานที่ประมวลผลงาน 47M งาน เน้นย้ำข้อดีของที่เก็บข้อมูลแบบคงทนซึ่งมี SKIP LOCKED สำหรับ VACUUM, งานแบบหน่วงเวลา, การลองใหม่, การอัปเดตสถานะ และดัชนีสำหรับการทำแพตเทิร์นที่มีต้นทุนสูงอย่างเช่น "อย่างน้อยหนึ่งครั้ง"