ฐานข้อมูลเชิงสัมพันธ์ vs NoSQL: วิธีเลือกพื้นฐานที่เหมาะสมสำหรับระบบของคุณ

ทุกฐานข้อมูลเก็บข้อมูล นั่นคือจุดที่ความคล้ายคลึงกันสิ้นสุดลง ฐานข้อมูลเชิงสัมพันธ์และฐานข้อมูล NoSQL แสดงถึงปรัชญาที่แตกต่างกันโดยพื้นฐานเกี่ยวกับวิธีการจัดโครงสร้าง จัดเก็บ และสืบค้นข้อมูล — และความแตกต่างเหล่านี้ส่งผลกระทบต่อเนื่องไปยังทุกชั้นของระบบที่สร้างขึ้นบนฐานข้อมูลเหล่านั้น

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

อะไรคือฐานข้อมูลเชิงสัมพันธ์อย่างแท้จริง

ฐานข้อมูลเชิงสัมพันธ์จัดระเบียบข้อมูลเป็นตาราง — แถวและคอลัมน์ที่มีความสัมพันธ์ที่กำหนดไว้อย่างชัดเจนระหว่างกัน คำว่า "เชิงสัมพันธ์" ในชื่อไม่ได้หมายถึงการที่ตารางมีความสัมพันธ์กัน (แม้ว่ามันจะมีความสัมพันธ์กัน) แต่หมายถึงแนวคิดทางคณิตศาสตร์ของความสัมพันธ์: กลุ่มของคู่ข้อมูลที่มีคุณลักษณะเหมือนกัน รากฐานทางทฤษฎีนี้ ซึ่งได้รับการพัฒนาโดยเอ็ดการ์ โคดด์ ที่ไอบีเอ็มในปี 1970 ได้พิสูจน์แล้วว่ามีความคงทนอย่างน่าทึ่ง

ลักษณะสำคัญของฐานข้อมูลเชิงสัมพันธ์ ได้แก่:

สคีมาแบบคงที่ ก่อนที่คุณจะแทรกข้อมูล คุณต้องกำหนดโครงสร้างก่อน: มีตารางใดบ้าง แต่ละตารางมีคอลัมน์อะไรบ้าง แต่ละคอลัมน์ยอมรับข้อมูลประเภทใด และมีข้อจำกัดใดบ้าง (NOT NULL, UNIQUE, CHECK และอื่นๆ) สคีมาคือข้อตกลงระหว่างแอปพลิเคชันของคุณกับฐานข้อมูลของคุณ

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

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

SQL. Structured Query Language คืออินเตอร์เฟซสากลสำหรับฐานข้อมูลเชิงสัมพันธ์ มันเป็นการประกาศ — คุณอธิบายสิ่งที่คุณต้องการ ไม่ใช่ว่าจะได้มาอย่างไร — และมันมีความสามารถในการแสดงออกได้อย่างยอดเยี่ยม การเชื่อมต่อ, การรวมข้อมูล, ฟังก์ชันหน้าต่าง, คำถามย่อย, CTEs: ความหลากหลายทั้งหมดของ SQL มอบเครื่องมือให้คุณในการถามคำถามที่ซับซ้อนเกี่ยวกับข้อมูลของคุณโดยไม่ต้องเขียนโค้ดแอปพลิเคชันเพื่อทำงานนั้น

ฐานข้อมูลเชิงสัมพันธ์หลัก ๆ — PostgreSQL, MySQL, SQL Server, Oracle — มีคุณสมบัติร่วมกันเหล่านี้ในขณะที่แตกต่างกันในชุดคุณสมบัติเฉพาะ, ลักษณะการทำงาน, และรูปแบบการอนุญาตใช้งาน PostgreSQL โดยเฉพาะอย่างยิ่งได้กลายเป็นตัวเลือกเริ่มต้นสำหรับโครงการใหม่ ๆ โดยผสมผสานการปฏิบัติตามมาตรฐานอย่างเคร่งครัดกับชุดคุณสมบัติที่ยอดเยี่ยม

NoSQL ฐานข้อมูลคืออะไรกันแน่

"NoSQL" เป็นคำที่ครอบคลุมหลายประเภทของฐานข้อมูลที่แตกต่างกัน โดยมีจุดร่วมหลักคือสิ่งที่พวกเขาไม่ใช่: พวกเขาไม่ใช่ฐานข้อมูลเชิงสัมพันธ์ และพวกเขาไม่ได้ใช้ SQL เป็นอินเทอร์เฟซหลัก (แม้ว่าบางประเภทจะรองรับภาษาการค้นหาที่คล้าย SQL ก็ตาม) คำนี้เข้าใจได้ดีกว่าว่า "ไม่เพียงแต่ SQL" — เป็นการยอมรับว่ารูปแบบเชิงสัมพันธ์ไม่ใช่แนวทางที่ถูกต้องเพียงอย่างเดียว

หมวดหมู่หลักของ NoSQL ได้แก่:

ฐานข้อมูลเอกสาร จัดเก็บข้อมูลในรูปแบบเอกสาร — โดยทั่วไปเป็น JSON หรือ BSON — ซึ่งแต่ละเอกสารสามารถมีโครงสร้างที่แตกต่างกันได้ MongoDB เป็นฐานข้อมูลประเภทนี้ที่ใช้กันอย่างแพร่หลายที่สุด; อื่นๆ ได้แก่ CouchDB และ Firestore ไม่มีตารางและไม่มีสคีมาที่ตายตัว; "คอลเลกชัน" ของเอกสารสามารถมีเรคอร์ดที่มีฟิลด์ที่แตกต่างกันโดยสิ้นเชิงได้

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

การจัดเก็บข้อมูลแบบคอลัมน์แฟมิลี จัดระเบียบข้อมูลตามคอลัมน์แทนที่จะเป็นแถว ซึ่งช่วยให้การอ่านข้อมูลเฉพาะคอลัมน์จากหลายล้านแถวมีประสิทธิภาพสูงมาก Apache Cassandra และ HBase เป็นตัวอย่างหลักของระบบนี้ โมเดลนี้ออกแบบมาสำหรับงานที่มีปริมาณการเขียนสูงและปริมาณข้อมูลมาก ซึ่งรูปแบบการค้นหาข้อมูลเป็นที่ทราบล่วงหน้า

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

ฐานข้อมูลแบบลำดับเวลา ได้รับการปรับให้เหมาะสมสำหรับข้อมูลที่จัดเรียงตามเวลา: InfluxDB, TimescaleDB, Prometheus. การอ่านค่าจากเซ็นเซอร์, การเคลื่อนไหวทางการเงิน, ตัวชี้วัดของแอปพลิเคชัน — ข้อมูลที่เวลาเป็นคีย์หลักเสมอและมีการค้นหาช่วงเวลามากกว่าการค้นหาแบบเฉพาะเจาะจง

ความแตกต่างทางโครงสร้างที่ขับเคลื่อนทุกสิ่งทุกอย่าง

ความแตกต่างที่ลึกซึ้งที่สุดระหว่างฐานข้อมูลเชิงสัมพันธ์และ NoSQL ไม่ใช่เรื่องไวยากรณ์หรือขนาด — แต่เป็นความสัมพันธ์ระหว่างโครงสร้างข้อมูลกับความยืดหยุ่นในการค้นหาข้อมูล

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

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

นี่คือความขัดแย้งหลัก: ความยืดหยุ่นของโครงสร้างข้อมูล vs ความยืดหยุ่นของการค้นหาข้อมูล คุณสามารถมีทั้งสองอย่างได้ แต่เพียงในระดับที่เหมาะสมเท่านั้น โมเดลฐานข้อมูลที่คุณเลือกสะท้อนถึงการแลกเปลี่ยนที่ยอมรับได้มากกว่าสำหรับกรณีการใช้งานของคุณ

ทฤษฎี CAP และความสำคัญ

ระบบกระจายไม่สามารถรับประกันความสอดคล้อง (Consistency), ความพร้อมใช้งาน (Availability), และความทนทานต่อการแบ่งแยก (Partition Tolerance) ได้พร้อมกัน — พวกเขาสามารถทำได้เพียงสองในสามเท่านั้น นี่คือทฤษฎี CAP และเป็นพื้นฐานทางทฤษฎีสำหรับการเข้าใจว่าทำไมฐานข้อมูลเชิงสัมพันธ์ (Relational) และ NoSQL จึงทำงานแตกต่างกันภายใต้เงื่อนไขการล้มเหลว

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

ฐานข้อมูล NoSQL หลายแห่ง — โดยเฉพาะอย่างยิ่งฐานข้อมูลที่ออกแบบมาเพื่อการกระจายแบบแนวนอน เช่น Cassandra และ DynamoDB — ให้ความสำคัญกับความพร้อมใช้งานและความทนทานต่อการแบ่งพาร์ติชัน พวกมันจะให้บริการข้อมูลแม้ในระหว่างที่เกิดการแบ่งพาร์ติชันของเครือข่าย โดยยอมรับว่าการอ่านข้อมูลบางส่วนอาจคืนค่าที่ล้าสมัย นี่คือ "ความสอดคล้องในที่สุด": ทุกโหนดจะบรรจบกันที่ค่าเดียวกันในที่สุด แต่จะมีช่วงเวลาหนึ่งที่พวกมันอาจไม่เห็นพ้องกัน

ผลกระทบในทางปฏิบัติ: หากแอปพลิเคชันของคุณไม่สามารถทนต่อการอ่านข้อมูลที่ล้าสมัยได้ — ยอดเงินในธนาคาร, จำนวนสินค้าคงคลัง, บันทึกทางการแพทย์ — คุณจำเป็นต้องมีความสอดคล้องที่แข็งแกร่ง หากแอปพลิเคชันของคุณสามารถทนต่อความไม่สอดคล้องชั่วคราวได้เพื่อแลกกับการพร้อมใช้งานตลอดเวลา — เช่น ฟีดโซเชียลมีเดีย แคตตาล็อกสินค้า โปรไฟล์ผู้ใช้ — ความสอดคล้องแบบในที่สุด (eventual consistency) ถือเป็นที่ยอมรับได้และมอบอิสระทางสถาปัตยกรรมให้กับคุณ

ตัวอย่างจากโลกจริง: เมื่อการเลือกที่ถูกต้องสร้างความแตกต่าง

GitHub: PostgreSQL หัวใจของแพลตฟอร์มระดับโลก

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

เป็นเวลาหลายปีที่ GitHub ดำเนินการ PostgreSQL อินสแตนซ์หลักเพียงหนึ่งเดียวพร้อมด้วยรีพลีกาสำหรับการอ่าน เมื่อขนาดระบบเติบโตขึ้น พวกเขาได้แนะนำ Vitess (เลเยอร์การแบ่งข้อมูลแบบ sharding สำหรับ MySQL สำหรับบางเวิร์กโหลด) และ ProxySQL สำหรับการจัดการการเชื่อมต่อ — แต่แกนหลักแบบสัมพันธ์ยังคงอยู่ บทเรียนไม่ใช่ว่า PostgreSQL สามารถขยายได้อย่างไม่มีที่สิ้นสุดโดยไม่ต้องใช้ความพยายาม แต่เป็นเพราะโมเดลเชิงสัมพันธ์เหมาะสมอย่างยิ่งกับโดเมนที่กำหนดโดยความสัมพันธ์ และความพยายามที่ลงทุนไปในการขยายระบบนั้นคุ้มค่า เพราะการย้ายไปยังโมเดลข้อมูลอื่นจะมีค่าใช้จ่ายสูงกว่ามาก

Twitter: การย้ายข้อมูลที่เจ็บปวดจาก MySQL สู่สถาปัตยกรรมแบบผสมผสาน

Twitter เริ่มต้นบน MySQL และเผชิญกับวิกฤตการขยายตัวที่มีการบันทึกไว้อย่างดี เมื่อการเติบโตของผู้ใช้แซงหน้าขีดความสามารถของฐานข้อมูลเชิงสัมพันธ์เพียงระบบเดียว ปัญหาหลักคือกราฟสังคม — ความสัมพันธ์ระหว่างผู้ติดตามและผู้ติดตามของผู้ใช้หลายร้อยล้านคน — และปัญหาการกระจายตามไทม์ไลน์: เมื่อผู้ใช้ที่มีผู้ติดตาม 10 ล้านคนทวีต ข้อความนั้นจะต้องปรากฏในไทม์ไลน์ของผู้ติดตาม 10 ล้านคนเกือบจะทันที

แบบจำลองเชิงสัมพันธ์ตามที่ Twitter ได้นำไปใช้ ไม่สามารถรองรับการกระจายข้อมูลแบบเขียน (write fanout) ได้ด้วยความเร็วที่ต้องการ Twitter จึงย้ายกราฟสังคมไปยังระบบจัดเก็บข้อมูลในหน่วยความจำที่พัฒนาขึ้นเอง และในที่สุดก็ใช้ Manhattan (ระบบจัดเก็บข้อมูลแบบกระจายภายในองค์กรที่ใช้คีย์-ค่า) สำหรับไทม์ไลน์ และ Cassandra สำหรับงานที่มีปริมาณการเขียนสูงอื่นๆ

บทเรียนที่นี่มีความละเอียดอ่อน ข้อมูลหลักของ Twitter — ทวีต, ผู้ใช้, ความสัมพันธ์ — มีลักษณะเชิงสัมพันธ์โดยพื้นฐาน ปัญหาไม่ได้อยู่ที่โมเดลข้อมูล แต่เป็นปริมาณการเขียนและการกระจายข้อมูลในระดับที่ต้องการการกระจาย การย้ายข้อมูลมีค่าใช้จ่ายสูง ซับซ้อนทางเทคนิค และต้องใช้การลงทุนด้านวิศวกรรมเป็นเวลาหลายปี ในระดับของ Twitter การตัดสินใจนั้นถูกต้องแล้ว แต่ในระดับของแอปพลิเคชันอื่น ๆ เกือบทั้งหมด การตัดสินใจเช่นนี้ถือว่าเร็วเกินไป

MongoDB: เรื่องราวเตือนใจเกี่ยวกับความยืดหยุ่นของสคีมา

ในช่วงต้นทศวรรษ 2010 เมื่อ MongoDB ได้รับความนิยมเพิ่มขึ้นอย่างรวดเร็ว หลายทีมได้นำมาใช้เป็นหลักเนื่องจากความยืดหยุ่นของสคีมา — ความสามารถในการเริ่มเก็บข้อมูลโดยไม่ต้องกำหนดสคีมาไว้ก่อน สำหรับการสร้างต้นแบบและการพัฒนาในระยะเริ่มต้น สิ่งนี้ช่วยเร่งกระบวนการทำงานได้อย่างแท้จริง

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

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

Amazon DynamoDB: เรื่องราวความสำเร็จเมื่อใช้ในกรณีที่เหมาะสม

ตะกร้าสินค้าของ Amazon เป็นหนึ่งในตัวอย่างที่เป็นแบบอย่างของการใช้ NoSQL อย่างถูกต้อง ข้อกำหนดมีความชัดเจน: รถเข็นช้อปปิ้งต้องพร้อมใช้งานเสมอ (ลูกค้าควรสามารถเพิ่มรายการสินค้าได้ตลอดเวลา แม้ในกรณีที่ระบบในภูมิภาคเกิดขัดข้อง) ต้องรองรับปริมาณการเขียนข้อมูลจำนวนมาก (ผู้ใช้หลายร้อยล้านคนเพิ่มและลบรายการสินค้า) และรูปแบบการเข้าถึงต้องเรียบง่ายและทราบล่วงหน้า (เข้าถึงโดยใช้รหัสลูกค้าเท่านั้น)

ทีมวิศวกรรมของ Amazon ในเอกสารปี 2007 ที่เป็นแรงบันดาลใจให้กับ DynamoDB ได้อธิบายถึงการตั้งใจเลือกใช้ความสอดคล้องแบบสุดท้าย (eventual consistency) สำหรับรถเข็นสินค้า: หากอุปกรณ์สองเครื่องเพิ่มรายการสินค้าพร้อมกันในระหว่างที่เกิดการแบ่งแยกเครือข่าย การเพิ่มทั้งสองรายการจะถูกเก็บไว้เมื่อการแบ่งแยกสิ้นสุดลง แม้ว่าอาจต้องแสดงสถานะที่ไม่สอดคล้องกันชั่วคราวก็ตาม รถเข็นช้อปปิ้งที่สามารถแก้ไขได้ตลอดเวลา — แม้ว่าจะมีความไม่สอดคล้องกันชั่วคราว — มีคุณค่ามากกว่ารถเข็นที่บางครั้งไม่สามารถใช้งานได้

การออกแบบของ DynamoDB ที่เน้นการใช้งานกรณีนี้ — การเข้าถึงคีย์-ค่าอย่างง่าย, รูปแบบการค้นหาที่ทราบล่วงหน้า, ความพร้อมใช้งานมากกว่าความสอดคล้อง — คือสิ่งที่ทำให้มันยอดเยี่ยม แอปพลิเคชันที่พยายามใช้ DynamoDB เป็นฐานข้อมูลเชิงสัมพันธ์ทั่วไป, การรันคำสั่งค้นหาที่ซับซ้อนข้ามหลายเอนทิตี, มักจะประสบปัญหาเป็นประจำ

Airbnb: Elasticsearch สำหรับการค้นหา, PostgreSQL สำหรับความจริง

การค้นหาของ Airbnb — การกรองรายการตามสถานที่, วันที่, ราคา, สิ่งอำนวยความสะดวก, และความพร้อมใช้งาน — เป็นคำค้นหาที่ฐานข้อมูลเชิงสัมพันธ์ไม่สามารถให้บริการได้อย่างมีประสิทธิภาพในระดับใหญ่ การผสมผสานระหว่างการค้นหาทางภูมิศาสตร์ การจับคู่ข้อความเต็มรูปแบบ และการกรองหลายคุณลักษณะที่ซับซ้อนในรายการนับล้านรายการ เป็นกรณีการใช้งานที่ Elasticsearch ถูกออกแบบมาเพื่อรองรับโดยเฉพาะ

Airbnb ใช้ Elasticsearch เป็นชั้นการค้นหาในขณะที่ยังคงใช้ PostgreSQL เป็นระบบบันทึกข้อมูลหลัก เมื่อมีการอัปเดตข้อมูลรายการ การเปลี่ยนแปลงจะถูกบันทึกลงใน PostgreSQL (แหล่งข้อมูลหลักที่มีความถูกต้องสมบูรณ์ พร้อมการรับประกันแบบ ACID) จากนั้นจะถูกกระจายไปยัง Elasticsearch (ดัชนีสำหรับการค้นหา ซึ่งได้รับการปรับแต่งให้เหมาะสมกับรูปแบบการค้นหาเฉพาะของประสบการณ์ผู้ใช้) อย่างไม่พร้อมกัน

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

เมื่อใดควรเลือกใช้ฐานข้อมูลเชิงสัมพันธ์

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

ข้อมูลของคุณมีความสัมพันธ์ที่มีความหมาย หากเอนทิตีในระบบของคุณมีความเกี่ยวข้องกันในลักษณะที่มีความสำคัญ — ผู้ใช้และโพสต์ของพวกเขา, คำสั่งซื้อและรายการในคำสั่งซื้อ, โครงการและงานในโครงการ — แบบจำลองเชิงสัมพันธ์จะแสดงความสัมพันธ์เหล่านั้นโดยตรงและช่วยให้คุณสืบค้นข้ามความสัมพันธ์เหล่านั้นได้อย่างมีประสิทธิภาพ

คุณต้องการความสม่ำเสมอที่แข็งแกร่ง การทำธุรกรรมทางการเงิน, การจัดการสินค้าคงคลัง, ระบบการจอง, บันทึกทางการแพทย์ — ทุกโดเมนที่การอ่านข้อมูลผิดพลาดมีผลกระทบร้ายแรงต้องการการรับประกันแบบ ACID ฐานข้อมูลเชิงสัมพันธ์ให้การรับประกันนี้ในระดับเครื่องยนต์

รูปแบบการค้นหาของคุณยังไม่เป็นที่ทราบอย่างสมบูรณ์ หากแอปพลิเคชันของคุณจำเป็นต้องตอบคำถามเกี่ยวกับข้อมูลของคุณซึ่งคุณไม่สามารถคาดการณ์ได้ทั้งหมดในระหว่างขั้นตอนการออกแบบ ความยืดหยุ่นของ SQL จะมีคุณค่าอย่างยิ่ง ความสามารถในการเขียนคำสั่งค้นหาแบบเฉพาะกิจ (ad-hoc) ต่อโครงสร้างข้อมูลที่ได้รับการจัดรูปแบบอย่างดี (well-normalised schema) เป็นสินทรัพย์ทางการดำเนินงานที่สำคัญอย่างยิ่ง

ทีมของคุณรู้จัก SQL นี่อาจฟังดูเป็นเรื่องเล็กน้อย แต่ไม่ใช่เลย SQL เป็นหนึ่งในทักษะทางเทคนิคที่เข้าใจกันอย่างแพร่หลายที่สุดในวิศวกรรมซอฟต์แวร์ นักพัฒนาทุกคนที่คุณจ้างจะมีความรู้เกี่ยวกับมันในระดับหนึ่ง ความรู้เชิงปฏิบัติการ — วิธีการเพิ่มดัชนี วิธีการอ่านแผนการค้นหา วิธีการจัดการสำรองข้อมูล — มีอยู่ทั่วไป ระบบนิเวศของเครื่องมือก็มีความสมบูรณ์แล้ว

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

เมื่อใดควรเลือกใช้ NoSQL

NoSQL เป็นตัวเลือกที่เหมาะสมเมื่อความต้องการเฉพาะไม่สามารถตอบสนองได้ด้วยโมเดลเชิงสัมพันธ์โดยไม่ก่อให้เกิดความพยายามที่ไม่สมเหตุสมผล:

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

ข้อมูลของคุณไม่มีโครงสร้างที่ชัดเจนหรือมีความหลากหลายสูงมาก แคตตาล็อกสินค้าที่มีประเภทสินค้าต่างกันโดยมีคุณลักษณะที่แตกต่างกันโดยสิ้นเชิง ระบบจัดการเนื้อหา (CMS) ที่ประเภทของเนื้อหาเปลี่ยนแปลงอย่างรวดเร็ว ระบบบันทึกข้อมูล (logging system) ที่โครงสร้างของเหตุการณ์ถูกกำหนดโดยระบบภายนอก — กรณีเหล่านี้จะได้ประโยชน์จากการจัดเก็บข้อมูลแบบเอกสารที่ไม่มีการบังคับใช้โครงสร้างโดยฐานข้อมูล

รูปแบบการเข้าถึงหลักของคุณคือการค้นหาคีย์-ค่าในระดับที่มหาศาล การจัดเก็บเซสชัน, แคช, อันดับแบบเรียลไทม์, ฟีเจอร์แฟล็ก — ภาระงานที่คุณเข้าถึงข้อมูลโดยใช้คีย์เดียวเสมอและไม่จำเป็นต้องรวมหรือสรุปข้อมูล จะได้รับประโยชน์จากความเรียบง่ายและประสิทธิภาพของระบบจัดเก็บข้อมูลแบบคีย์-ค่า

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

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

ความเป็นจริงของระบบฐานข้อมูลหลายระบบ

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

PostgreSQL สำหรับระบบบันทึกข้อมูลหลัก Redis สำหรับการแคชเซสชันและการจำกัดอัตรา Elasticsearch สำหรับการค้นหาข้อความเต็มรูปแบบ InfluxDB สำหรับเมตริกของแอปพลิเคชัน ฐานข้อมูลแต่ละตัวในสแต็กนี้ทำหน้าที่ที่ถนัดที่สุด และชั้นแอปพลิเคชันจะจัดการความสอดคล้องระหว่างฐานข้อมูลเหล่านี้

ค่าใช้จ่ายในการดำเนินงานของความซับซ้อนนี้เป็นจริง แต่ละฐานข้อมูลเพิ่มเติมคือระบบอีกหนึ่งระบบที่ต้องตรวจสอบ สำรองข้อมูล ขยายขนาด และทำความเข้าใจ วินัยทางวิศวกรรมที่จำเป็นในการรักษาความสอดคล้องของหลายแหล่งข้อมูล — การจัดการสถานการณ์ความล้มเหลวที่การเขียนข้อมูลไปยัง PostgreSQL สำเร็จแต่การอัปเดต Elasticsearch ถัดไปล้มเหลว — ไม่ใช่เรื่องง่าย

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

การตัดสินใจ

คำถามที่สำคัญจริงๆ เมื่อเลือกฐานข้อมูล:

คุณต้องการความสม่ำเสมอในระดับใด? หากคำตอบสำหรับคำถามที่ว่า "จะเกิดอะไรขึ้นหากผู้ใช้อ่านข้อมูลที่ล้าสมัย" คือ "นั่นเป็นปัญหาที่ร้ายแรง" คุณจำเป็นต้องใช้ ACID หากคำตอบคือ "นั่นเป็นเรื่องน่ารำคาญเล็กน้อยแต่ยอมรับได้" คุณมีตัวเลือกหลายอย่าง

รูปแบบการค้นหาของคุณคืออะไร? หากคุณทราบแน่ชัดว่าข้อมูลของคุณจะถูกเข้าถึงอย่างไร และรูปแบบการเข้าถึงนั้นเรียบง่ายและมีปริมาณมาก คุณสามารถปรับให้เหมาะสมกับรูปแบบนั้นได้ หากรูปแบบการเข้าถึงของคุณซับซ้อนหรือไม่ทราบอย่างเต็มที่ ความยืดหยุ่นของ SQL จะมีคุณค่า

ปริมาณการเขียนของคุณคือเท่าไร? สำหรับการใช้งานส่วนใหญ่ อินสแตนซ์ PostgreSQL ที่ได้รับการปรับแต่งอย่างดีบนฮาร์ดแวร์ที่เหมาะสมสามารถรองรับการเขียนได้หลายพันครั้งต่อวินาทีโดยไม่มีปัญหา กรณีที่ไม่เพียงพออย่างแท้จริงนั้นพบได้น้อยกว่ากระแสความนิยมของ NoSQL ในช่วงปี 2010 มาก

ข้อมูลของคุณมีลักษณะอย่างไร? ข้อมูลที่มีความสม่ำเสมอสูงและมีความสัมพันธ์กันอย่างชัดเจนเหมาะสำหรับโมเดลเชิงสัมพันธ์ ข้อมูลที่มีความแปรปรวนสูงและมีความสัมพันธ์กันไม่แน่นแฟ้นอาจเหมาะกับโมเดลเอกสารมากกว่า

ทีมของคุณรู้อะไรบ้าง? ความคุ้นเคยในการปฏิบัติงานมีความสำคัญ ทีมที่รู้จัก PostgreSQL อย่างลึกซึ้งจะสามารถสร้างระบบที่เชื่อถือได้บน PostgreSQL ได้ดีกว่าการสร้างบนฐานข้อมูล NoSQL ที่พวกเขากำลังเรียนรู้ แม้ว่าฐานข้อมูล NoSQL นั้นจะเหมาะสมทางทฤษฎีมากกว่าก็ตาม

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