MongoDB คืออะไร

MongoDB เป็น document database วลีเดียวนี้บรรจุแนวคิดทั้งหมดไว้แล้ว: สิ่งที่เก็บคือ document ที่เป็น object คล้าย JSON ที่ครบในตัวเอง และกลุ่มของ document ก็คือ collection ฝั่ง relational database ขอให้คุณกระจายหนึ่งระเบียนเชิงตรรกะออกไปยังหลายตารางแล้วเย็บกลับมาด้วย join ส่วน MongoDB ปล่อยให้หนึ่งระเบียนเป็น document เดียวที่บรรจุทุกอย่างที่ควรอยู่ด้วยกันไว้แล้ว — รวมทั้ง object ซ้อนในและ array

ผลในทางปฏิบัติคือข้อมูลใน database มักจะมีหน้าตาเหมือน object ในโปรแกรมของคุณ สมาชิกที่มีชื่อ ยอดค่าปรับ และรายการหนังสือที่ยืม คือ document เดียว ไม่ใช่ row ในตาราง members บวกกับ row ในตาราง loans ที่คุณต้อง join ทุกครั้งที่ต้องการเห็นภาพเต็ม

document แทน row

ในโลก relational สมาชิกและหนังสือที่พวกเขายืมอยู่ในสองตารางที่เชื่อมกันด้วย key ใน MongoDB ข้อมูลเดียวกันนี้เป็น document เดียวที่มี array ฝังอยู่

flowchart LR
  subgraph RDBMS["Relational: two tables joined by a key"]
    direction TB
    T1["members table
 id | name | fines"]
    T2["loans table
 id | member_id | title"]
    T1 -->|"member_id = id"| T2
  end
  subgraph MONGO["MongoDB: one document"]
    direction TB
    D["members collection
 one document:
 name, fines, borrowed[ ... ]"]
  end
  RDBMS -.->|"same data, different shape"| MONGO

ระเบียนเดียวกันในรูปของ relational row ที่ join กัน เทียบกับ MongoDB document เดียว

นี่คือหน้าตาจริงของ document เดียวนั้น — ชื่อ ยอดคงเหลือ และหนังสือที่ยืมทั้งหมดอยู่ในที่เดียว:

{
  "_id": "65f0b3d4e4b0a1c2e4b0a1d1",
  "name": "Grace",
  "fines": 0,
  "borrowed": ["Compilers", "Algorithms"]
}

schema ที่ยืดหยุ่น

collection ไม่ได้บังคับให้ทุก document มี field ชุดเดียวกัน document ของสมาชิกคนหนึ่งอาจมี email, อีกคนอาจไม่มี, และคนที่สามอาจเพิ่ม phone ที่ไม่มีใครอื่นมี MongoDB ไม่ปฏิเสธตัวที่แตกต่างนี้ สิ่งนี้เรียกว่า schema แบบ flexible (หรือ dynamic) และเป็นฟีเจอร์ที่คนสังเกตเห็นเป็นอันดับแรก

ความยืดหยุ่นเป็นความสะดวก ไม่ใช่ข้ออ้างสำหรับความวุ่นวาย ในทางปฏิบัติคุณจงใจทำให้ document ใน collection ค่อนข้างสม่ำเสมอ และ MongoDB ยอมให้คุณเพิ่มกฎ schema validation เมื่อคุณต้องการให้ database บังคับรูปร่าง ประเด็นคือ schema อยู่ในมือคุณและสามารถวิวัฒน์ทีละ field โดยไม่ต้อง migration ที่เขียนทับทุกระเบียนที่มีอยู่ตั้งแต่ต้น

{ "_id": "1", "name": "Ada",  "fines": 0 }

{ "_id": "2", "name": "Alan", "fines": 2, "email": "[email protected]" }

ทั้งสองนี้เป็นสมาชิกที่ถูกต้องสมบูรณ์ใน collection เดียวกัน แม้ว่าจะมีเพียงหนึ่งที่มี email

เมื่อไร MongoDB เหมาะสม

MongoDB มักจะเป็นทางเลือกที่สบายใจเมื่อ:

ข้อมูลของคุณเป็นลำดับชั้นหรือหลากหลายโดยธรรมชาติ document, โปรไฟล์, แคตตาล็อกสินค้า, event, และเนื้อหาที่ระเบียนไม่ได้มี field ชุดเดียวกันทั้งหมด map ลงบน document ได้อย่างสะอาด
คุณอ่านและเขียน object ทั้งก้อนพร้อมกัน ถ้าแอปของคุณเกือบจะต้องการทั้งสมาชิก และ หนังสือที่ยืมพร้อมกันเสมอ การ embed ไว้ใน document เดียวหมายถึงการอ่านครั้งเดียวที่เร็วแทนที่จะเป็น join
schema ของคุณยังเปลี่ยนแปลงอยู่ ผลิตภัณฑ์ในระยะเริ่มต้นเปลี่ยนรูปร่างตลอดเวลา schema ที่ยืดหยุ่นยอมให้คุณเพิ่ม field วันนี้โดยไม่ต้อง migration
คุณต้องสเกลการเขียนแบบแนวนอน MongoDB shard ข้ามหลายเครื่อง ซึ่งโมดูล Operations & Scaling ในภายหลังจะครอบคลุม

เมื่อไร relational database เป็นเครื่องมือที่ดีกว่า

document database ไม่ใช่คำตอบที่ถูกต้องเสมอไป เลือกใช้ relational database (PostgreSQL, MySQL และพวกพ้อง) เมื่อ:

ข้อมูลของคุณเป็น relational สูงและสม่ำเสมอ ความสัมพันธ์ many-to-many จำนวนมากระหว่าง entity ที่สำคัญเท่า ๆ กัน คือสิ่งที่ SQL join ถูกสร้างมาเพื่อพอดี
คุณต้องการ transaction หลาย row เป็นเรื่องประจำวัน MongoDB รองรับ transaction หลาย document แต่บัญชีแยกประเภทแบบธนาคารที่เกือบทุก operation ครอบคลุมหลายระเบียน มักจะเข้ากับโมเดล relational ได้อย่างเป็นธรรมชาติมากกว่า
คุณพึ่งพา ad-hoc SQL ที่ทรงพลังและระบบนิเวศรายงานที่เติบโตเต็มที่ เครื่องมือ SQL, การผสานรวม BI, และความคุ้นเคยของนักวิเคราะห์ที่สั่งสมมาหลายทศวรรษ เป็นข้อได้เปรียบจริง
schema ที่เข้มงวดและบังคับตั้งแต่ต้นเป็นฟีเจอร์ที่คุณต้องการ ไม่ใช่ข้อจำกัดที่คุณพยายามหนีออกมา

สรุปอย่างตรงไปตรงมา: เลือก database ที่รูปร่างตามธรรมชาติตรงกับข้อมูลและ access pattern ของคุณ MongoDB เปล่งประกายเมื่อระเบียนเป็น object ที่ครบในตัวเองที่คุณอ่านและเขียนเป็นหน่วยเดียว

เคล็ดลับและข้อควรระวัง

“flexible schema” ไม่ได้หมายความว่า “ไม่มี schema” แต่หมายความว่า schema เป็นความรับผิดชอบของคุณและสามารถเปลี่ยนแปลงทีละน้อยได้ collection ที่แข็งแรงส่วนใหญ่ค่อนข้างสม่ำเสมอในทางปฏิบัติ
MongoDB ไม่ใช่ key-value store และ ไม่ใช่ JSON ที่ไม่มี schema ทิ้งไว้บนดิสก์ MongoDB ทำ index ให้ field รัน query ที่ทรงพลังได้ และตรวจรูปร่างข้อมูลให้เมื่อคุณสั่ง
ทางเลือกนี้แทบไม่เคยเป็นแบบทั้งหมดหรือไม่เลย หลายระบบใช้ MongoDB สำหรับ workload บางอย่างและ relational database สำหรับอย่างอื่น

ข้อแลกเปลี่ยน

ตัวเลือก	Benefit	Cost
Document database (MongoDB)	รูปร่างข้อมูลยืดหยุ่น เหมาะกับข้อมูลที่เป็นลำดับชั้นหรือหลากหลายโดยธรรมชาติ อ่านและเขียน object ทั้งก้อนได้เร็วโดยไม่ต้อง join	schema ไม่ถูกบังคับโดยอัตโนมัติ ความสม่ำเสมอของ document เป็นเรื่องที่ทีมต้องดูแลเอง และ ad-hoc join ข้าม collection ทำได้จำกัดกว่า SQL
Relational database (PostgreSQL, MySQL)	schema เข้มงวดตั้งแต่ต้น รองรับ join แบบ many-to-many ที่ซับซ้อนได้ดี และมี tooling/ระบบนิเวศรายงานที่เติบโตเต็มที่	การเปลี่ยน schema ต้อง migration ที่กระทบทุก row ที่มีอยู่ และข้อมูลที่เกี่ยวข้องกันมักต้องกระจายไปหลายตารางแล้ว join กลับ

ข้อผิดพลาดที่พบบ่อย

เลือก MongoDB เพราะกระแส ไม่ใช่เพราะรูปแบบการเข้าถึงข้อมูลเข้ากัน — ถ้า workload ของคุณเป็น join แบบ many-to-many หนัก ๆ และสม่ำเสมอ relational database มักเหมาะกว่า ไม่ใช่ว่า document database ดีกว่าเสมอ
คิดว่า “schema ยืดหยุ่น” แปลว่า “ไม่มี schema” — ในทางปฏิบัติ document ส่วนใหญ่ใน collection เดียวกันควรมีรูปร่างใกล้เคียงกัน schema แค่ไม่ได้ถูกบังคับโดย database เอง (เว้นแต่คุณเพิ่ม validation)
มองว่าต้องเลือกอย่างใดอย่างหนึ่งสำหรับทั้งระบบ — หลายระบบใช้ MongoDB สำหรับส่วนที่ต้องการความยืดหยุ่น และ relational database สำหรับส่วนที่ต้องการ transaction หลาย row หรือ join ที่ซับซ้อน ใช้ทั้งสองพร้อมกันได้

💡 ตัวอย่างจากของจริง

Forbes — ย้าย CMS จาก relational schema ที่ตายตัวมาเป็น MongoDB เพราะบทความแต่ละประเภทมี field ไม่เหมือนกัน การบังคับทุกประเภทให้อยู่ใน table เดียวกันทำให้ schema ซับซ้อนขึ้นเรื่อย ๆ เมื่อเนื้อหาใหม่ ๆ เพิ่มเข้ามา

MetLife — สร้างระบบ “single customer view” ด้วย MongoDB โดยรวมข้อมูลลูกค้าจากระบบ relational เดิมหลายสิบระบบให้เป็น document เดียวต่อลูกค้าหนึ่งคน แทนที่จะพยายาม join ข้ามระบบเดิมที่แยกกันอยู่