TL;DR

Overview MongoDB หลังจากมองๆอยู่ห่างๆอย่างห่วงๆ แฉลบไปมาๆ อยู่นาน //จริงๆแล้วจะเขียนเรื่อง Data Modeling with MongoDB

ช่วงนี้งงกับตัวเองมากๆ ทั้งๆที่ตัวเองต้องวุ่นวายกับเรื่องเรียนต่อ ไหนจะเรื่องงาน ความจริงแล้วมี task ให้ทำเยอะมากจนไม่รู้จะเริ่มยังไง วันๆก็เลยตัดสินใจนั่งเฉยๆ รู้ตัวอีกทีก็ผ่านมาแล้ว 1 อาทิตย์ เยี่ยมมม~

ตอนนี้ที่ บ.กำลังจะทำงานใหม่ชิ้นนึง ซึ่งคราวนี้ถึงเวลาที่จะใช้ MongoDB กัน อย่างจริงจัง ถึงจะไม่ใช่ครั้งแรกที่ /me ใช้ MongoDB แต่มันเป็นครั้งแรกที่จะเอามาใช้แบบจริงๆจังๆสักที หลังจากลองเล่นกับโปรเจคเล็กๆอยู่หลายๆงาน :)

Table of content

Why we use Database?

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

โดยปกติแล้ว เรามักคุ้นเคยกับการใช้ MySQL หนึ่งในผลิตผลจากแนวคิดในยุค 1980s ที่เรียกว่า Relational Database ยกระดับของการเขียนโปรแกรม ทำให้เราไม่จำเป็นต้องกังวลเรื่อง space efficiency, transactionality, Readers–writer lock, … อีกต่อไป (แต่ตอนทำงานจริงๆ ต้องกลับมาดูเรื่องพวกนี้อยู่บ่อยเหมือนกัน Orz)

แต่อย่างไรก็ตาม Relational Database ก็ไม่ใช่คำตอบสำหรับทุกเรื่อง

MongoDB is comming

MongoDB เปิดตัวเป็นอีกหนึ่งทางเลือกสำหรับ developer ภายใต้แนวคิดใหม่ที่เรียกว่า Document-oriented Database ข้อมูลแต่ละก้อนไม่จำเป็นต้องอยู่ใน table และไม่ได้มองข้อมูลเป็น row-column อีกต่อไป

โดยข้อมูลที่เก็บภายใน MongoDB จะถูกมองเป็นก้อนเอกสาร เหมือนกับการเป็น files.doc ใน folder เมื่อต้องการจะใช้ข้อมูล เราก็จะเรียกข้อมูลนั้นขึ้นมาโดยใช้ db.collection.find({…})

ดังนั้นแนวคิดในการดีไซน์ database จึงแตกต่างจากเดิมโดยสิ้นเชิง โดยพื้นฐานแล้วสำหรับ Relational DB เรามักคุ้นเคยกับการเก็บข้อมูลโดยการแยกมันเป็นองค์ประกอบกระจายไปตาม tables ต่างๆ และมี SQL เป็นภาษากลางเพื่อประกอบมันกลับมาเป็นเหมือนเดิม

แต่สำหรับ MongoDB ซึ่งไม่มี SQL มาช่วยประกอบชิ้นส่วนย่อยๆของข้อมูล ข้อมูลแต่ละก้อนจะถูกเก็บเป็นก้อนใหญ่ๆ อิสระต่อกัน แต่ทดแทนด้วยความสามารถในไม่จำกัดโครงสร้างข้อมูล เราสามารถสร้าง nested object เช่น {“a”:[{“b”:1}, {“b”:2}]} หรือ แม้กระทั้งเก็บ object ที่มีโครงสร้างไม่เหมือนกันใน collection เดียวกัน

What’s MongoDB good for?

และก็อีกเหมือนเคย MongoDB ก็ไม่ใช่คำตอบสำหรับทุกๆปัญหา ดังนั้นการเลือกใช้จึงจำเป็นต้องศึกษาข้อดีและข้อเสียของมัน สำหรับ MongoDB แล้ว

A Clear Path to Horizontal Scalability

สิ่งแรกที่พูดถึง MongoDB แล้วจะไม่พูดถึงไม่ได้ Scalability หรือความสามารถในการรองรับข้อมูลขนาดใหญ่ แน่นอนว่าสำหรับ MySQL ก็ทำได้ในระดับหนึ่ง แต่เมื่อไรก็ตามที่แต่ละ table มีขนาดใหญ่เกิน 10 GB ก็จะถึงเวลาที่ต้องมานั่งปวดหัวกับมันไปนานๆ

แต่ทางที่ชัดเจนนี้ก็ไม่ได้หมายความว่าจะสามารถทำมันแบบสุ่มสี่สุ่มห้าได้ การใช้ sharding, replication, load balancing เป็นอีกหนึ่งหัวข้อที่ซับซ้อนและอาศัยการใช้เวลาศึกษาอย่างถ้องแท้เป็นเวลานานในระดับหนึ่งเลย

Schema-free Data Structure

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

Write Code and Write Database with the Same Structure

ปัญหาหนึ่งในการใช้ SQL คือ โครงสร้างแบบตาราง ถึงแม้ว่ามันจะเป็นโครงสร้างที่ง่ายสำหรับการจัดการ aggregation, transaction, report แต่ในหลายๆงานกลับไม่ต้องการข้อมูลในลักษณะนี้ โดยเฉพาะอย่างยิ่งเมื่อเราหันมาออกแบบทุกอย่างเป็น OOP มากขึ้น เราจึงนิยมใช้ Object-relational mapping หรือ ORM เพื่อเข้าถึง Data แปลงข้อมูลแบบตารางมาเป็น Object แต่ก็กลับมาเป็นปัญหากับการ query เพื่อออกแบบรายงาน ย้อนแย้งกันไปมา Document-oriented Database อย่าง MongoDB สามารถแก้ปัญหานี้ได้ ใช้ความสามารถ Schema-free ทำให้เราสามารถบันทึกและใช้ข้อมูลในรูปแบบอะไรก็ตามที่เราต้องการ ข้อมูลที่ใช้ใน code และ database จึงสามารถมีโครงสร้างไม่ต่างกัน

High Write Load

ความสามารถข้อนี้ คิดว่าต้องยกความดีความชอบให้กับทีม MongoDB (ว่ากันว่า)สามารถรองรับ concurrency ได้มากสุดๆ //แต่ /me ก็ไม่รู้รายละเอียดเพราะไม่เคยไปลองแฮะ

Play with Location-base/Text-base Information

MongoDB นอกจากการเป็น DB แล้วยังมาพร้อมกับ built-in query สำหรับข้อมูลรูปแบบต่างๆ ไม่ว่าจะเป็น geolocation ใช้ค้นหาข้อมูลสถาณที่/ที่อยู่ตามพื้นที่ หรือ เป็น text search อันนี้จึงเป็นอีกหนึ่งความสามารถที่น่าตื่นเต้น

Example Works with MongoDB

  • Content Management System/ Survey System สำหรับงานที่ต้องรองรับรูปแบบเนื้อหาที่สามารถเปลี่ยนแปลงได้ตลอดเวลา

  • Messaging/ Log/ Monitoring System สำหรับงานที่ต้องบันทึกข้อมูลปริมาณบ่อยๆ และมีปริมาณมาก

  • Graphs visualization สำหรับงานที่ต้องแสดงผลข้อมูลที่ไม่ใช้ตาราง

  • บลาๆ

Never use Everything with MongoDB

ทุกอย่างมี 2 ด้านเสมอๆ และด้านที่ไม่ดีของ MongoDB ที่ต้องพูดถึง ก็คือ 3 NO อันได้แก่ No Joins, NO Transactions และ No Triggers

No Joins

เพราะว่า MongoDB ออกแบบมาให้เก็บข้อมูลเป็นก้อนๆ ไม่ต้องกระจายเป็นส่วนๆ ดังนั้นการพยายาม join tables จึงกลายเป็นฝันร้ายของ MongoDB ไปในทันที ปิดประตูสำหรับงาน Data Warehouse หรือการทำ Report ที่จำเป็นต้อง aggregate เยอะๆไปได้เลย เย้~

No Transactions

เพราะต้องการเพิ่มความสามารถในการเขียนข้อมูล จึงต้องแลกกับการไม่สามารถทำ Transactional Query ได้ แปลว่า หากมี query 2 อันใดๆ จะไม่การันตีว่า query 2 อันนี้จะต้องรันต่อกัน โดยไม่มี query อื่นมาขัดจังหวะ และรวมไปถึงไม่สามารถทำการ rollback ข้อมูลหากมี query ใดๆ ทำงานผิดพลาด และปิดประตูไปสำหรับงาน Financial ไปอีกหนึ่งงาน ฮูเร่~

No Triggers

หลายๆครั้ง เรามักเลี่ยงไม่ได้ที่จะต้องเผชิญกับความจำเป็นในการการเปลี่ยนแปลงข้อมูลหลายๆจุด ไล่เรียงกันไป การใช้ trigger เป็นหนึ่งความสามารถที่ช่วยให้เราแก้ไขปัญหานี้ได้ แต่ MongoDB ไม่มี :)

Lack of ACID Compliance

เพราะ No Joins ทำให้บางครั้ง เราจำเป็นต้องเลือกให้เก็บข้อมูลซ้ำๆกันในหลายๆที่ และ No Triggers + No Transactions ประกอบกันมาช่วยการันตีว่า เราไม่สามารถอัพเดตข้อมูลหลายๆที่พวกนั้นพร้อมกันได้ใน 1 query ด้วยเหตุผล 2 ประการนี้ ทำให้ข้อมูลที่เก็บใน DB อาจจะขัดแย้งกันได้ แล้วก็ปิดประตูไปอีกหนึ่งสำหรับงานจำพวก High consistency/integrity

Hard to Self-Reference

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

อ่านเพิ่มเติมที่ Why You Should Never Use MongoDB

ไม่ต้องเสียใจ แล้วค่อยๆปิดประตูไปสำหรับงาน Social Network ไปอีกหนึ่งงาน วู้วววว~

Thank you

ความจริงแล้วจะที่ลุกขึ้นมาเขียนบล๊อคนี้ มีความตั้งใจว่าจะเขียนเกี่ยวกับเรื่อง Data Modeling Concepts with MongoDB แต่ไปๆมาๆ กลายเป็น Overview MongoDB ไปซะได้

ครั้งหน้าจะไม่พลาดแบบนี้อีก