เหตุใดฐานข้อมูลและความซับซ้อนของมันจึงไม่จำเป็นอีกต่อไป

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

ปัญหาของฐานข้อมูลและเหตุใดความซับซ้อนของมันจึงไม่จำเป็น

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

โมเดลที่สอดคล้องกันสำหรับการสร้างแอปพลิเคชันแบ็กเอนด์

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

Rama

  • Rama เป็นแพลตฟอร์มพัฒนาแบ็กเอนด์ที่นำ Mastodon มาสร้างใหม่เพื่อให้บริการในระดับสเกลของ Twitter
  • Rama ทำองค์ประกอบทั้งหมดของแบ็กเอนด์ เช่น ข้อมูล ดัชนี ETL และคิวรี ด้วยแนวทางแบบทั่วไปเดียวกัน
  • Rama ทำให้การดีพลอยที่ซับซ้อนง่ายขึ้น และรวมระบบมอนิเตอร์เข้าด้วยกันเพื่อลดต้นทุนการพัฒนาและบำรุงรักษาได้อย่างมาก

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

  • ปัญหาสถานะแปรผันส่วนกลางของฐานข้อมูลเพิ่มทั้งความซับซ้อนของโค้ดและโอกาสเกิดข้อผิดพลาด ซึ่งเป็นปัญหาที่นักพัฒนามักพบเจอ
  • Rama นำเสนอแนวทางใหม่ที่ช่วยก้าวข้ามข้อจำกัดของฐานข้อมูลแบบเดิม และลดความซับซ้อนของการพัฒนาแบ็กเอนด์
  • บทความนี้มอบข้อมูลที่น่าสนใจและเป็นประโยชน์สำหรับนักพัฒนาที่ต้องการลดความซับซ้อนของฐานข้อมูลและระบบแบ็กเอนด์

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

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

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

  • ควรใช้ซับซิสเต็มหนึ่งที่แทนแหล่งความจริงของข้อมูล และอีกซับซิสเต็มหนึ่งที่ทำดัชนีสโตร์หลายตัวซึ่งอนุมานมาจากแหล่งนั้น นี่คือการผสานกันของ event sourcing และ materialized views

    • event sourcing และ materialized views: แนวทางแก้คือแยกระบบที่เป็นแหล่งความจริงของข้อมูลออกจาก index store ที่สร้างขึ้นบนพื้นฐานของมันเพื่อจัดการแยกกัน

  • เราแยก read model และ write model: write model ("แหล่งความจริงของข้อมูล") ประกอบด้วย relational domain model แบบดั้งเดิม และแทบทุกคำสั่งจะสร้าง event ที่ถูก publish ไปยัง shared domain event queue ส่วน read model ประกอบด้วย worker ที่ consume event และสร้าง views

    • การแยก read/write model: write model ประกอบด้วย relational domain model และคำสั่งต่าง ๆ จะสร้าง event แล้ว publish ไปยัง domain event queue ขณะที่ read model จะ consume event เพื่อสร้าง views

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

    • ข้อจำกัดของการ materialize ข้อมูล: มีประโยชน์เมื่อปรับให้เหมาะกับงานเดี่ยว แต่เมื่อเพิ่มฟีเจอร์ที่ต้องใช้ transaction ซับซ้อนหรือโครงสร้างข้อมูลใหม่ อาจเกิดปัญหาได้

  • การอ้างว่าสิ่งนี้ได้รับการพิสูจน์แล้วด้วย "Mastodon client ระดับสเกล Twitter" นั้นเป็นไปไม่ได้ เว้นแต่คุณจะเปิดเว็บที่มีผู้ใช้ 40 ล้านคนต่อวันจริง ๆ

    • ความสำคัญของสเกล: เป็นไปไม่ได้ที่จะจำลองสภาพแวดล้อมผู้ใช้ขนาดใหญ่จริง และจึงยากที่จะอ้างเช่นนั้นได้

  • แนวทางที่ดีกว่าคือการผสาน event sourcing กับ materialized views

    • การผสาน event sourcing กับ materialized views: ถูกเสนอเป็นแนวทางที่ดีกว่า แม้จะมาพร้อมความซับซ้อนที่เพิ่มขึ้น

  • ไม่มี data model แบบเดียวที่รองรับได้ทุก use case

    • ความหลากหลายของ data model: เป็นไปไม่ได้ที่จะใช้ data model เดียวรองรับทุก use case

  • ฉันไม่ได้มีปัญหาอะไรกับฐานข้อมูล

    • ความยังใช้ได้ของฐานข้อมูล: ไม่ได้มีข้อร้องเรียนต่อฐานข้อมูล และยังคงเป็นเครื่องมือที่ใช้ได้อยู่

  • แนวคิดอย่าง concurrency, isolation, constraints หายไปหรือไม่? "query topology" เหนือกว่าสำหรับสภาพแวดล้อมนักพัฒนาจริงหรือ?

    • ข้อสงสัยต่อ query topology: มีการตั้งคำถามว่าแนวคิดสำคัญอย่าง concurrency, isolation, constraints ถูกละเลยไปหรือไม่ และ query topology เหนือกว่าสำหรับสภาพแวดล้อมนักพัฒนาจริงหรือไม่

  • ต้องการคำอธิบาย Rama แบบ ELI5 เอกสารทำให้สับสน และอย่าใช้คำฮิตอย่าง "paradigm shift" หรือ "platform"

    • คำขอคำอธิบาย Rama แบบง่าย ๆ: ขอคำอธิบาย Rama ที่เข้าใจง่ายและชัดเจนโดยเลี่ยงการใช้คำฮิต

  • event sourcing (+ materialized views และ indexes) ไม่ได้หมายความว่าต้องทิ้ง RDBMS ทั้งสองอย่างสามารถใช้ร่วมกันได้

    • การอยู่ร่วมกันของ event sourcing กับ RDBMS: สามารถใช้ event sourcing และ materialized views ร่วมกับ RDBMS ได้ ทั้งสองไม่ใช่สิ่งที่排斥กัน

ความรู้พื้นฐาน:

  • Event Sourcing: แพตเทิร์นการออกแบบที่บันทึกการเปลี่ยนแปลงสถานะของระบบเป็น event และสามารถสร้างสถานะของระบบขึ้นใหม่ได้ด้วยการ replay event เหล่านั้น
  • Materialized Views: เทคนิคที่เก็บผลลัพธ์ของ query ในฐานข้อมูลไว้จริงเพื่อเพิ่มประสิทธิภาพการอ่านข้อมูล
  • RDBMS (Relational Database Management System): ระบบสำหรับจัดการฐานข้อมูลเชิงสัมพันธ์