PostgreSQL ก็เพียงพอแล้ว

 (gist.github.com/cpursley)
44 คะแนน โดย GN⁺ 2024-02-07 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • หน้ารวมลิงก์เกี่ยวกับวิธีใช้ PostgreSQL ในงานหลากหลายด้าน
    • งานเบื้องหลัง, message queue, GIS, audit log, การควบคุมการเข้าถึง, การจัดการสิทธิ์, การค้นหา, ข้อมูลอนุกรมเวลา, ข้อมูลกราฟ, ข้อมูลภายนอก, HTTP, API, อีเวนต์/การจำลองแบบ/CDC, unit test, migration, dashboard/UI, การทำภาพข้อมูล, HTML และแอปพลิเคชัน, LSP (language server)

PostgreSQL is Enough

งานเบื้องหลัง

  • สามารถจัดการงานที่ตั้งเวลาไว้ใน PostgreSQL ได้ผ่าน pg_cron

Message Queue

  • ให้ข้อมูลเกี่ยวกับแนวทางเลือก PostgreSQL มาใช้เป็นเทคโนโลยี message queue
  • pgmq คือระบบ message queue ที่สร้างบน PostgreSQL

GIS/แผนที่

  • PostGIS เพิ่มความสามารถด้านฐานข้อมูลเชิงพื้นที่ให้กับ PostgreSQL

Audit Log

  • pgMemento และ pgaudit ใช้ติดตามการเปลี่ยนแปลงและจัดการ audit log ใน PostgreSQL

การควบคุมการเข้าถึง

  • acl ใช้สำหรับจัดการ access control list ใน PostgreSQL

การยืนยันตัวตน

  • โมดูล pgcrypto และ pgjwt ของ PostgreSQL ใช้จัดการการยืนยันตัวตนภายในฐานข้อมูล

การค้นหา

  • มีลิงก์ที่เป็นประโยชน์เกี่ยวกับความสามารถด้าน full-text search ของ PostgreSQL
  • paradedb, pg_embedding, pgvector ช่วยเพิ่มความสามารถด้านการค้นหาใน PostgreSQL

ข้อมูลอนุกรมเวลา

  • timescaledb ขยาย PostgreSQL เพื่อจัดการข้อมูลอนุกรมเวลา

ข้อมูลกราฟ

  • Apache AGE ขยาย PostgreSQL เพื่อมอบความสามารถแบบฐานข้อมูลกราฟ

ข้อมูลภายนอก

  • wrappers ใช้รวมแหล่งข้อมูลภายนอกเข้ากับ PostgreSQL

HTTP

  • pgsql-http และ pg_net ใช้จัดการคำขอ HTTP ใน PostgreSQL

API

  • PostgREST, graphql-engine, postgraphile, pg_graphql ใช้สร้าง API server บนพื้นฐานของ PostgreSQL

อีเวนต์, การจำลองแบบ, CDC

  • คำสั่ง NOTIFY ของ PostgreSQL และ walex, peerdb, debezium, pglogical ใช้ติดตามการเปลี่ยนแปลงข้อมูลและให้ความสามารถด้านการจำลองแบบ

Unit Test

  • pgtap เป็นเครื่องมือสำหรับทำ unit test ให้ฐานข้อมูล PostgreSQL

Migration

  • postgresql-migrations และ bytebase ใช้จัดการ migration ของฐานข้อมูล PostgreSQL

Dashboard / UI

  • Baserow, NocoDB, AppSmith มอบส่วนติดต่อผู้ใช้และ dashboard

การทำภาพข้อมูล

  • Evidence และ Metabase เป็นเครื่องมือสำหรับการทำภาพข้อมูล

HTML และแอปพลิเคชัน

  • SQLpage, Omnigres, pg_render, plmustache ใช้ผสานข้อมูล PostgreSQL เข้ากับเว็บแอปพลิเคชัน

Language Server

  • postgres_lsp มอบการรองรับ Language Server Protocol สำหรับ PostgreSQL

มีอะไรตกหล่นบ้าง?

  • ช่วยแชร์สิ่งที่ขาดไปผ่านคอมเมนต์

ความเห็นของ GN⁺

  • PostgreSQL แสดงให้เห็นว่าเป็นแพลตฟอร์มอเนกประสงค์ที่ก้าวข้ามจากการเป็นเพียงระบบจัดการฐานข้อมูล ด้วยส่วนขยายและเครื่องมือที่หลากหลาย
  • บทความนี้นำเสนอวิธีใช้ PostgreSQL เพื่อตอบโจทย์ความต้องการของแอปพลิเคชันที่หลากหลาย จึงเป็นทรัพยากรที่มีประโยชน์สำหรับนักพัฒนา
  • โดยเฉพาะอย่างยิ่ง มันเน้นศักยภาพในการทำให้สถาปัตยกรรมระบบเรียบง่ายขึ้นและเพิ่มประสิทธิภาพ ด้วยความสามารถที่ประมวลผลได้โดยตรงภายในฐานข้อมูล

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

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

 
eususu 2024-02-07

ในบรรดานี้ผมใช้ postgREST อยู่เป็นการส่วนตัว และพอใจมากครับ
 
GN⁺ 2024-02-07
ความคิดเห็นจาก Hacker News

  • แชร์ประสบการณ์เกี่ยวกับความพยายามทำให้แอปพลิเคชันสแต็กเรียบง่ายขึ้น

    ผู้ใช้คนหนึ่งเล่าว่ามักพยายามลดความซับซ้อนของแอปพลิเคชันสแต็กอยู่บ่อย ๆ แต่เมื่อความซับซ้อนของแอปเพิ่มขึ้น ก็ได้ตระหนักถึงความจำเป็นของเทคโนโลยีสแต็กที่หลากหลาย หากพยายามรวมทุกอย่างไว้ในเทคโนโลยีเดียวอย่าง Postgres อาจรู้สึกอึดอัดได้ ถึงอย่างนั้น การขยายความสามารถของเทคโนโลยีที่มีอยู่เดิมก็อาจดีกว่าการเพิ่มเลเยอร์ใหม่ ๆ ตัวอย่างเช่น การใช้ Postgres เป็น message queue นั้นง่ายกว่าการดูแล message queue แยกต่างหากมาก Postgres ถือว่าขยายความสามารถได้ดีมากในบรรดาฐานข้อมูล และการสร้างเทคโนโลยีบนพื้นฐานนี้ก็สนุกมาก

  • ความเห็นของผู้สร้าง ParadeDB เกี่ยวกับความสามารถในการขยายของ Postgres

    ในฐานะหนึ่งในผู้สร้าง ParadeDB ซึ่งให้ความสามารถด้านการค้นหาและการวิเคราะห์ความเร็วสูงผ่านส่วนขยายของ Postgres มองว่าสำหรับเวิร์กโหลดขนาดเล็กอย่างในสตาร์ตอัป การทำงานอยู่ภายใน Postgres ให้นานที่สุดเท่าที่จะทำได้เป็นทางเลือกที่สมเหตุสมผล อย่างไรก็ตาม เมื่อขนาดใหญ่ขึ้น ก็ไม่สามารถแก้ทุกอย่างได้ด้วย Postgres เพียงอย่างเดียว หากต้องจัดการเวิร์กโหลดที่หลากหลายภายใน Postgres ก็จำเป็นต้องแยกระบบให้สอดคล้องกับความต้องการเฉพาะ และทำให้สามารถขยายตัวและฟื้นตัวได้อย่างอิสระ เมื่อถึงจุดนั้น ก็จำเป็นต้องมีสแต็กโซลูชันเฉพาะทางตามความต้องการแต่ละแบบ แม้จะมีความเคลื่อนไหวในการสร้างองค์ประกอบของสแต็กในเวอร์ชัน Postgres แต่แต่ละโซลูชันก็ล้วนก้าวออกไปไกลกว่า Postgres และไม่คิดว่าจะมีโซลูชันที่อิง Postgres สำหรับองค์ประกอบทุกชิ้นของสแต็ก

  • ความเห็นเรื่องการตัดสินใจเริ่มโปรเจกต์ใหม่ด้วย sqlite

    ผู้ใช้คนหนึ่งตัดสินใจว่า ทุกครั้งที่เริ่มโปรเจกต์ใหม่จะเริ่มด้วย sqlite และจะไม่ย้ายออกจนกว่าจะจำเป็นจริง ๆ หาก Postgres เหมาะกับ 90% ของกรณี sqlite ก็เหมาะกับ 80% ของกรณี อีกทั้งเริ่มต้นได้ง่ายและมีประสิทธิภาพดี เมื่อการขยายแบบแนวตั้งใช้ไม่ได้ผล อย่างน้อยก็น่าจะพอใจกับสิ่งที่สร้างไว้แล้ว

  • ข้อสงสัยของผู้เชี่ยวชาญ C++ เกี่ยวกับฐานข้อมูล

    ผู้เชี่ยวชาญ C++ ที่ไม่คุ้นเคยกับฐานข้อมูลตั้งคำถามถึงความจำเป็นของฐานข้อมูล โดยมาจากอุตสาหกรรมที่ใช้ฟอร์แมตไฟล์ไบนารีแบบกำหนดเองจำนวนมาก และรู้สึกว่าฐานข้อมูลดูเหมือนจะแก้ปัญหาได้หลายอย่างในผิวเผิน แต่ในความเป็นจริงไม่ได้เป็นเช่นนั้น ข้อจำกัดด้านชนิดข้อมูล ปัญหาเรื่องการอัปเดต และปัญหาความเข้ากันได้ระหว่าง SQL engine ต่าง ๆ ทำให้การใช้ฐานข้อมูลดูเป็นความคิดที่ไม่ดี แม้จะเข้าใจข้อดีด้านการทำงานร่วมกันในกรณีที่มีข้อมูลปริมาณมาก แต่ในกรณีอื่น ๆ ก็ยังตั้งคำถามอย่างจริงจังถึงความจำเป็นของฐานข้อมูล

  • ความเห็นเกี่ยวกับส่วนเสริมของ PostgreSQL

    มีการชี้ว่าส่วนเสริมส่วนใหญ่มีมาใน MariaDB อยู่แล้ว และยกบางส่วนจากแรงจูงใจของ PostgreSQL HTTP client มาอ้างอิง เกี่ยวกับแนวคิดที่ว่าคงจะดีถ้าสามารถเขียน trigger เพื่อเรียกใช้ web service ได้ ผู้ใช้แสดงความเห็นว่างานแบบนั้นอยากปล่อยให้คนอื่นทำมากกว่าจะทำเอง

  • ปัญหาการผูกเข้ากับประสบการณ์การจัดการโค้ดเมื่อใช้ฟีเจอร์ขั้นสูง

    แม้จะใช้งาน Postgres อย่างกว้างขวาง แต่ทุกครั้งที่ใช้ฟีเจอร์ขั้นสูง ก็จะเจอกับปัญหาในการผูกเข้ากับข้อดีต่าง ๆ ของการเขียนโค้ด เช่น version control, code review, type, test และ static analysis พร้อมตั้งคำถามเกี่ยวกับ migration

  • ข้อดีของการทำต้นแบบฟีเจอร์ใหม่ด้วยสแต็กเดิม

    มีการแชร์ประสบการณ์ว่าการทำต้นแบบฟีเจอร์ใหม่ก่อนนั้นดีกว่าการนำของใหม่เข้ามา ผ่านการคัดเลือกอย่างรอบคอบ เราสามารถเปลี่ยนต้นแบบเริ่มต้นให้กลายเป็นโค้ดโปรดักชันบนสแต็กเดียวกันได้ แต่เมื่อระบบชนข้อจำกัด ก็อาจรู้สึกว่าจำเป็นต้องใช้ Redis หรือเครื่องมือเฉพาะทางอื่น ๆ สิ่งสำคัญคือการเขียน API wrapper เปลี่ยนเฉพาะ implementation ภายในเมื่อถึงเวลาจำเป็น และทดสอบ migration ให้ดี พร้อมบอกว่าผู้คนมักประหลาดใจกับระยะเวลาที่สามารถเลื่อนการตัดสินใจด้านเทคโนโลยีออกไปได้

  • แชร์ประสบการณ์ของผู้ใช้ที่ใช้ Postgres, Redis และ S3

    มีการใช้ชุดผสมของ Postgres, Redis และ S3 และระบุว่าชุดนี้ยังไม่เคยพลาดเลย บางครั้งก็อยากลองทำ Pub/Sub ด้วย Postgres แต่สุดท้ายก็ต้องใช้ Redis อยู่ดีทั้งสำหรับ caching และ sidekiq และเพราะ Redis เองก็ยอดเยี่ยมมาก จึงไม่ได้รู้สึกว่าจำเป็นต้องลอง

  • ข้อจำกัดของ Postgres สำหรับการวิเคราะห์ข้อมูลขนาดใหญ่

    แม้จะชอบ Postgres มาก แต่ก็แชร์ประสบการณ์ว่ารู้สึกว่า Postgres ไม่เพียงพอเมื่อขนาดข้อมูลใหญ่มาก Postgres เหมาะอย่างยิ่งกับการจัดการเวิร์กโหลดประเภท OLTP แต่หากต้องการการรองรับ OLAP มากขึ้น ก็แนะนำให้ใช้ StarRocks ประสบการณ์การนำข้อมูลจาก Postgres ไปยัง StarRocks เพื่อการวิเคราะห์ข้อมูลนั้นยอดเยี่ยมมาก และ StarRocks ยังรองรับการ query ตรงจาก data lake ด้วย

  • ความต้องการฟีเจอร์บีบอัด jsonb ของ Postgres

    ใช้ทั้ง Mongo และ PG แต่รู้สึกว่า PG เรียบง่ายกว่ามาก จึงอยากเลิกใช้ Mongo เพื่อทำให้ระบบง่ายขึ้น สิ่งที่ต้องการมีเพียงคอลัมน์ jsonb แบบบีบอัด โดยไม่จำเป็นต้องอัปเดตหรือ query แค่ insert, select และ delete ได้ก็พอ และหวังว่าจะรักษาอัตราการบีบอัด 80-90% สำหรับ json key ที่ซ้ำ ๆ กันได้แบบเดียวกับใน Mongo โดยไม่ต้องมีภาระในการดูแลรักษา