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

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

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 ไปอีกหนึ่งงาน วู้วววว~

Thnak you

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

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

Tell your friend about thisShare on Facebook
Facebook
0Tweet about this on Twitter
Twitter
Share on Google+
Google+
0