ก็ใช้ Postgres ไปเถอะ

 (mccue.dev)
43 คะแนน โดย GN⁺ 2024-08-19 | 18 ความคิดเห็น | แชร์ทาง WhatsApp
  • เว็บแอปพลิเคชันส่วนใหญ่ต้องการการเก็บข้อมูลแบบถาวร ดังนั้นเวลาเริ่มสร้างแอปใหม่ ตัวเลือกตั้งต้นที่ควรเลือกก็คือ Postgres

ทำไมไม่ใช้ sqlite?

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

ทำไมไม่ใช้ DynamoDB, Cassandra หรือ MongoDB?

  • ฐานข้อมูลเหล่านี้ให้ประสิทธิภาพยอดเยี่ยม แต่มีข้อสมมติตั้งต้นอยู่มาก:
    • ต้องรู้ให้ชัดว่าแอปพลิเคชันต้องทำอะไร และมีรูปแบบการเข้าถึงแบบไหน
    • ต้องมีความจำเป็นต้องขยายสเกลไปสู่ข้อมูลขนาดใหญ่มาก
    • ต้องยอมแลกกับความสอดคล้องของข้อมูลบางส่วนได้
  • ฐานข้อมูลเหล่านี้ทำงานคล้าย distributed hash map ดังนั้นต้องสะท้อนความรู้เรื่องรูปแบบคิวรีลงไปในวิธีเก็บข้อมูลด้วย
  • ถ้ารูปแบบการเข้าถึง (คิวรี) เปลี่ยน ก็อาจต้องประมวลผลข้อมูลทั้งหมดใหม่อีกครั้ง
  • ฐานข้อมูลเชิงสัมพันธ์สามารถเพิ่มดัชนีเพื่อรองรับคิวรีได้ง่าย แต่ NoSQL ทำแบบนั้นได้ยากกว่า
  • ไม่เหมาะกับคิวรีเชิงวิเคราะห์
  • ถ้านักศึกษามหาวิทยาลัยหรือนักพัฒนาใหม่เลือกใช้ MongoDB ก็น่าจะต้องมีคนช่วย

ทำไมไม่ใช้ Valkey?

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

ทำไมไม่ใช้ Datomic?

  • ถ้าคุณรู้จักสิ่งนี้อยู่แล้ว ก็ขอมอบ "ดาวสีทอง" ให้
  • Datomic เป็นฐานข้อมูล NoSQL เชิงสัมพันธ์ที่ไม่มีปัญหาแบบ "การออกแบบล่วงหน้า (Up-front Design)" และมีคุณสมบัติที่เรียบร้อยน่าสนใจอยู่หลายอย่าง
    • มันเก็บข้อมูลเป็นคู่ EAVT (entity-attribute-value-time) แทนตาราง และใช้ดัชนีแบบอเนกประสงค์
    • เวลาจะเขียนคิวรี ไม่จำเป็นต้องประสานกับคนที่เขียนข้อมูล แค่คิวรีฐานข้อมูล ณ "สถานะปัจจุบัน" ของช่วงเวลานั้นก็พอ ข้อมูลใหม่หรือแม้แต่การลบ (หรือที่เรียกว่า 'retractions') ก็ไม่ได้ลบข้อมูลเดิมจริง ๆ
  • แต่ก็มีข้อเสียอยู่บ้าง:
    • ใช้งานได้เฉพาะกับภาษาในตระกูล JVM
    • ถ้าไม่ใช่ Clojure API ก็ไม่ค่อยดี
    • ข้อความ error จากคิวรีที่โครงสร้างไม่ดีนั้นไม่เป็นมิตรอย่างมาก
    • ไม่มี ecosystem เครื่องมือแบบเดียวกับ SQL จึงขาดเครื่องมือสนับสนุน

ทำไมไม่ใช้ XTDB?

  • ผู้ใช้ Clojure สร้างฐานข้อมูลกันเยอะมาก
  • มันคล้าย Datomic แต่มีคุณสมบัติเหล่านี้:
    • มี HTTP API จึงไม่ผูกกับ JVM
    • คิวรีได้ตามสองแกนคือ "system time" และ "valid time"
    • รองรับ SQL API
  • แต่ปัญหาใหญ่ที่สุดคือ มันยังค่อนข้าง "ใหม่" อยู่ SQL API เพิ่งออกมาเมื่อปีที่แล้ว และเมื่อไม่นานมานี้ก็เพิ่งเปลี่ยน storage model ทั้งหมด
    • อีก 10 ปีข้างหน้ามันจะยังอยู่ไหม? เรื่องการรองรับระยะยาวยังไม่แน่นอน

ทำไมไม่ใช้ Kafka?

  • Kafka เป็น log แบบ "append-only" ที่ยอดเยี่ยมมาก และเหมาะกับการประมวลผลข้อมูลระดับ TB
  • ถ้าคุณต้องการทำงานแนว event sourcing กับข้อมูลที่ไหลเข้ามาจากหลายบริการซึ่งดูแลโดยหลายทีม มันทำงานได้ดีอย่างน่าทึ่ง
  • อย่างไรก็ตาม
    • ในระบบขนาดเล็ก ตารางใน Postgres ก็ใช้แทนได้สบาย
    • การสร้าง Kafka consumer มีโอกาสพลาดได้ง่ายกว่าที่คิด เพราะสุดท้ายแล้วต้องตามตำแหน่งของตัวเองใน log ให้ได้
    • ต้องดูแลโครงสร้างพื้นฐานเพิ่ม

ทำไมไม่ใช้ ElasticSearch?

  • ถ้าการค้นหาข้อมูลคือฟีเจอร์หลักของผลิตภัณฑ์ ElasticSearch ก็เป็นตัวเลือกที่เหมาะสม
    • คุณต้องทำ ETL ข้อมูลและดูแลทั้งกระบวนการ แต่ ElasticSearch ถูกสร้างมาเพื่อการค้นหา และมันทำสิ่งนั้นได้ดี
  • แต่ถ้าการค้นหาไม่ใช่ฟีเจอร์หลัก ความสามารถค้นหาข้อความในตัวของ Postgres ก็เพียงพอแล้ว
    • แล้วค่อยเพิ่ม search engine เฉพาะทางทีหลังได้

ทำไมไม่ใช้ MSSQL หรือ Oracle DB?

  • คำถามจริงที่ควรถามตัวเองคือ: "มันคุ้มค่ากับราคาหรือไม่?"
  • ต้องคิดทั้งค่าไลเซนส์และต้นทุนจากการถูกล็อกกับผู้ขาย
  • ถ้าเก็บข้อมูลไว้กับ Oracle คุณก็ต้องจ่ายให้ Oracle ไปตลอด และต้องฝึกนักพัฒนาต่อไปเรื่อย ๆ
    • คุณต้องเลือกอย่างใดอย่างหนึ่งไปตลอดกาลระหว่างฟีเจอร์ระดับองค์กรกับกระเป๋าเงินของคุณ
  • ถ้าไม่มีฟีเจอร์เฉพาะที่จำเป็นจริง ๆ ก็ควรหลีกเลี่ยง
    • ถ้าไม่มีฟีเจอร์ระดับ killer ที่ขาด MSSQL ไม่ได้ ก็อย่าใช้

ทำไมไม่ใช้ MySQL?

  • ส่วนนี้ผู้เขียนขอแรงผู้อ่านช่วยนิดหน่อย
  • MySQL เป็นของ Oracle และฟีเจอร์บางอย่างถูกล็อกไว้ในรุ่น enterprise
    • แน่นอนว่า MySQL ถูกใช้งานมายาวนาน และมีรุ่นฟรีที่ใช้กันอย่างแพร่หลาย
  • ผมเชื่อว่า Postgres เป็นตัวเลือกที่ดีกว่า แต่ก็ยังต้องการข้อมูลเพิ่มเติมเกี่ยวกับ MySQL

ทำไมไม่ใช้ AI vector DB?

  • AI vector DB ส่วนใหญ่เป็นเทคโนโลยีใหม่ จึงมีความเสี่ยงในการใช้งาน
    • ธุรกิจที่ตั้งอยู่บน AI bubble ควรเข้าหาด้วยความระมัดระวัง
  • ถึงธุรกิจของคุณจะเป็น AI grift อีกรายหนึ่ง ก็แค่ import openai ก็น่าจะพอแล้ว

ทำไมไม่ใช้ Google Sheets?

  • ไม่มีข้อเสียอะไรเป็นพิเศษ ถ้าจำเป็นก็ใช้ได้

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

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

 
hilft 2024-08-23

Firestore...
 
wedding 2024-08-20

บทความที่ฟันธงแบบนี้ ส่วนใหญ่เป็นความผิดพลาดที่พวกจูเนียร์มักทำกัน..
 
nemorize 2024-08-20

แทนแล้วเชิญรับ
C
ที่น่ารัก
SV
ไป
เลยครับ
 
roxie 2024-08-25

zzz
 
bus710 2024-08-20

เหมือนจะนึกถึงมุกที่ว่า ถ้าอยากได้ข้อมูลดี ๆ ก็ต้องโพสต์อะไรเรียกดราม่าก่อน… ขึ้นมาเลยนะครับ ฮ่าๆ
อย่างไรก็ตาม เพราะสำหรับนักพัฒนาแบ็กเอนด์ส่วนใหญ่ สิ่งแรกที่ได้ใช้ก็มักจะเป็น PostgreSQL นี่แหละ…
 
dicebattle 2024-08-19

ผมคิดว่า Postgres เป็นตัวเลือกที่ดีกว่า แต่ยังต้องการข้อมูลเพิ่มเติมเกี่ยวกับ MySQL

ฮ่าๆๆ;;;;
 
2024-08-19
[ความคิดเห็นนี้ถูกซ่อน]
 
koxel 2024-08-19

ปัญหาที่แท้จริงของ MySQL Enterprise ไม่ใช่เรื่องไลเซนส์ แต่คือถึงจะเป็นลูกค้าที่จ่ายเงินก็ยังได้รับการซัพพอร์ตแย่มากเวลาเกิดเหตุขัดข้อง
ก่อนหน้านี้เคยเจอกรณี mysql index เสียจนรันไม่ได้ ต่อให้ส่งคำขอซัพพอร์ตไปก็มีแค่ว่าถ้าเปิดซัพพอร์ตทิกเก็ตกับ Oracle แล้วค่อยขอ ก็จะให้ซัพพอร์ตทางโทรศัพท์ เท่านั้นเอง
สุดท้ายลูกค้าก็บอกว่าแบบนี้ไม่ไหว เลยกลายเป็นว่าเราต้องแก้กันเอง
แทนที่จะเชื่อ Oracle แล้วใช้ Enterprise ฟรีนี่แหละดีที่สุด..
 
kaydash 2024-08-19

ทำไมไม่ใช้ mariadb, impala, hive หรือ kudu
 
koxel 2024-08-19

ฟีเจอร์ระดับองค์กรของ Mysql เป็นฟีเจอร์ที่จริงๆ แล้วไม่จำเป็นมากนัก เช่น connection pool ของตัวเอง..
ถ้าเป็นระดับองค์กรจริง แทนที่จะใช้สิ่งนี้ ติดตั้ง sql proxy ไว้ด้านหน้าจะมีประสิทธิภาพกว่าในการกระจายโหลด
ผมชอบ Pgsql นะ.. แต่จะมาพูดแบบไม่คิดจะศึกษาฝั่ง mysql เลยว่าไม่รู้อะไรทั้งนั้น.. 555
 
iolothebard 2024-08-19

ก็ใช้ MySQL ไปเถอะ…

  • ทำไมไม่ใช่ Postresql? ตรงนี้อาจต้องการความช่วยเหลือเล็กน้อย
 
love7peace 2024-08-19

แล้ว MariaDB ล่ะ??
 
aer0700 2024-08-19

เป็นโพสต์ที่น่าจะกลายเป็นประเด็นถกเถียงใหญ่เลยนะ...
 
aer0700 2024-08-19

เหตุผลที่ใช้ Sqlite ก็เพราะมันเรียบง่าย และสำหรับงานขนาดประมาณหนึ่งมันก็ใช้งานได้ดีอยู่แล้ว
แค่ทำด้วย sqlite ไปก่อน แล้วถ้าภายหลังจำเป็นค่อยย้ายไป postgres ก็ไม่น่าจะมีอะไรยากมากนะครับ
 
xguru 2024-08-19

บทความสรรเสริญ Postgres ที่โผล่มาเป็นระยะจนแทบลืมกันไป คราวนี้ก็แค่สนุกกับมันเถอะ!

ใช้ Postgres กับทุกอย่างไปเลย
PostgreSQL ก็เพียงพอแล้ว
Postgres เริ่มเท่ตั้งแต่เมื่อไรกัน

 
GN⁺ 2024-08-19
ความเห็นบน Hacker News

  • แม้จะมีความเห็นเชิงลบเกี่ยวกับ MongoDB มาก แต่ส่วนใหญ่เป็นข้อมูลที่ไม่ถูกต้อง

    • MongoDB เหมาะกับการใช้งานในระยะแรก
    • มันทำงานได้โดยไม่มีปัญหาแม้เมื่อขนาดข้อมูลใหญ่ขึ้น
    • ปัญหาเรื่องความสอดคล้องของข้อมูลก็ได้รับการแก้ไขอย่างดี
    • MongoDB ไม่ใช่ distributed hash map แบบเดียวกับ Dynamo
    • มีหลายคนที่ไม่เข้าใจความสามารถด้าน aggregation ของ MongoDB ดีพอ
    • การบอกว่าไม่ควรใช้ MongoDB เพียงเพราะนักพัฒนามือใหม่ควรเรียน SQL นั้นไม่ยุติธรรม

  • ข้อดีของ SQLite

    • เป็นแบบ file-based จึงสำรองข้อมูลได้ง่าย
    • หากใช้ ORM ก็สามารถอัปเกรดจาก SQLite ไปเป็น Postgres ได้ง่าย

  • การชี้ข้อบกพร่องทางเทคนิคไม่ได้มีความหมายมากนัก

    • Rick Houlihan ของ MongoDB กำลังทำงานอยู่ที่ MongoDB ในปัจจุบัน

  • เหตุผลในการย้ายจาก MySQL ไป Postgres

    • MySQL ที่ Oracle เป็นเจ้าของมีความเสี่ยงทางธุรกิจ
    • Postgres มีเครื่องมือสำหรับรักษาความสอดคล้องของข้อมูลมากกว่า
    • ความสามารถในการขยายของ Postgres ช่วยประหยัดเวลาในการพัฒนา
    • ecosystem ด้านเครื่องมือของ Postgres มีความสุกงอมและครบถ้วนกว่ามาก

  • Postgres ยังรองรับ temporal table ไม่เพียงพอ

    • ต้องการการทำ versioning แบบ "bi-temporal" ตาม SQL:2011 system time และ application time
    • temporal table เหมาะอย่างยิ่งสำหรับอุตสาหกรรมที่ถูกกำกับดูแลซึ่งมีความต้องการด้านรายงานที่ซับซ้อน

  • ไม่เข้าใจเหตุผลในการใช้ SQLite

    • การติดตั้ง Postgres ไม่ได้ยาก
    • จำเป็นต้องมีคำอธิบายถึงความแตกต่างระหว่าง SQLite กับ Postgres

  • ขอโทษที่กล่าวชื่อ Rick Houlihan ผิด

    • การเปรียบเทียบ DynamoDB/Cassandra กับ MongoDB มาจากการบรรยายของเขา
    • MongoDB เป็นฐานข้อมูลที่เก็บข้อมูลแบบ de-normalized จึงไม่ยืดหยุ่นนักเมื่อรูปแบบการเข้าถึงเปลี่ยนไป

  • สิ่งสำคัญคือใช้สิ่งที่คุณรู้ และ deploy สิ่งที่มีประโยชน์

  • MySQL ก็เหมือน Javascript

    • มีการตัดสินใจที่ไม่ดีและจุดเสี่ยงอยู่มาก
    • แม้มันจะทำงานได้ดี แต่เมื่อมี Postgres อยู่แล้ว ก็ไม่มีเหตุผลนักที่จะเลือกใช้มัน
 
touguy 2024-08-19

Postgres มีเครื่องมือสำหรับรักษาความสอดคล้องของข้อมูลมากกว่า
=> พอจะมีตัวอย่างไหมครับ?
 
leftliber 2024-08-19

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