ใช้ Postgres ทุกที่ไปเลย

 (amazingcto.com)
50 คะแนน โดย xguru 2022-12-13 | 13 ความคิดเห็น | แชร์ทาง WhatsApp
  • Postgres สามารถแทนที่เทคโนโลยีแบ็กเอนด์จำนวนมากได้ (จนถึงระดับผู้ใช้หลายล้านคน)
    → Kafka, RabbitMQ, Mongo, Redis,..
  • สำหรับแคช ใช้ TEXT ในรูปแบบ JSON บนตาราง UNLOGGED แทน Redis
    • กำหนดระยะหมดอายุของข้อมูลด้วย stored procedure
  • คิวข้อความ (Kafka): SKIP LOCKED
  • คลังข้อมูลใช้ Postgres+TimescaleDB
  • แทน Mongo ด้วยการเก็บ JSONB แล้วค้นหาและทำดัชนี
  • ใช้ pg_cron เป็น CRON daemon สำหรับงานอย่างการส่งอีเมล
  • ใช้กับคำสั่งค้นหาเชิงภูมิศาสตร์
  • ใช้แทน Elastic สำหรับการค้นหาแบบ Full-text
  • สร้าง JSON ภายใน DB แล้วส่งตรงไปยัง API ได้โดยไม่ต้องมีโค้ดฝั่งเซิร์ฟเวอร์
  • รองรับ GraphQL ด้วย GraphQL adapter

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

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

 
bbulbum 2022-12-15

อืม.. ถ้าไม่ได้ต้องการฟีเจอร์เพิ่มเติมที่แต่ละแอปรองรับ ดูเหมือนว่าแนวคิดพื้นฐานประมาณว่า postgres อย่างเดียวก็น่าจะเพียงพอแล้ว
เพราะแต่ละแอปสามารถใช้ฟีเจอร์ได้มากกว่าโฟลว์ที่กำลังถูกแทนที่อยู่ข้างบนนั่นเอง
 
colossus 2022-12-14

ผมคิดว่าถ้าวางโครงอินเทอร์เฟซให้ดี มันก็ไม่ใช่เรื่องเกินจริงเสียทีเดียวครับ แต่สำหรับแคช/เมสเสจคิว ผมว่าปล่อยให้ Redis จัดการก็โอเคนะ
 
gninggoon 2022-12-14

ผมเองก็มีความคิดคล้ายกับบทความข้างต้นอยู่เหมือนกันในช่วงหลังมานี้ แน่นอนว่าสำหรับบริการขนาดใหญ่ การกระจายระบบให้มากที่สุดเพื่อลดความเสี่ยงย่อมเป็นเรื่องที่ดีกว่า แต่เวลารับงานเอาต์ซอร์สขนาดเล็กหลายครั้ง การไม่ใช้ NoSQL แยกต่างหากแล้วใช้ประโยชน์จากชนิดข้อมูล jsonb ของ Postgres กลับใช้งานได้หลากหลายกว่ามาก ให้ประสบการณ์เหมือนใช้ทั้ง RDB + NoSQL ร่วมกัน และสำหรับโปรเจ็กต์ขนาดเล็กก็ให้ประสิทธิภาพที่เพียงพอมากครับ
 
a9t84j1k5j2j1 2022-12-13

พอเอาทุกอย่างไปทำไว้ในที่เดียว จุดเสี่ยงทั้งหมดก็ไปรวมอยู่ที่จุดเดียวด้วย..!
 
ehlegeth 2022-12-13

บางอย่างจริง ๆ แล้วเป็นงานที่เคยทำกันด้วย RDB ในช่วงที่ยังไม่มีผลิตภัณฑ์มาทดแทน แต่สิ่งอย่าง Redis, Kafka, หรือ Cron ดูเหมือนจะไม่สามารถทดแทนข้อดีหลักของมันได้ จึงน่าจะเป็นไอเดียประมาณว่าอ่านขำ ๆ แล้วผ่านไปมากกว่า
 
ifmkl 2022-12-13

น่าจะถูกใจคนที่ชอบใช้ตัวเดียวทำได้ทุกอย่างนะ
 
s0400615 2022-12-13

ผมเคยใช้ postgres เพราะเรื่อง Geospatial
เมื่อเทียบกับ DB อื่น ๆ แล้วมันเร็วกว่าอยู่ราว 10~100 เท่า.. ฝั่ง geo นี่เหนือกว่าชัดเจนเลยครับ

แต่ก็อย่างที่ทุกคนรู้กัน พอข้อมูลเยอะขึ้นแล้ว vacuum ทำงานพลาดเมื่อไร ก็จะได้สัมผัสนรกกันเลย..
 
kbumsik 2022-12-13

โอ้ มีหลายเทคนิคเลยนะ

แต่สำหรับการผสมกันระหว่าง UNLOGGED กับ stored procedure แบบแรก ผมว่าถ้าใช้ Redis ไปเลยน่าจะสะอาดกว่ามากครับ ฮ่าๆ
 
youknowone 2022-12-13

หลายปีก่อน ผมเคยทำงานแบบว่าใช้ JSONB ไปก่อน แล้วพอโหลดหนักขึ้นก็เลือกสิ่งที่เหมาะกับแพตเทิร์นแบบ kv แล้วแยกออกไปไว้ใน Redis ซึ่งเป็นประสบการณ์ที่ลื่นไหลมากครับ
 
sangheon 2022-12-13

เป็นความเห็นที่น่าสนใจนะ
 
xguru 2022-12-13

เป็นชื่อที่จงใจเรียกความสนใจ แต่ก็เป็นประเด็นที่น่าลองคิดดูอยู่เหมือนกัน เลยขอนำมาแปลตามต้นฉบับ
เพราะตอนทำ MVP ระยะแรก การนำคอมโพเนนต์เข้ามามากเกินไปก็เป็นปัญหาได้เหมือนกัน
 
jujumilk3 2022-12-13

ดูเหมือนจะเป็นแนวคิดที่ดี
 
devo209 2022-12-20

ขอบคุณครับ