เมื่อเริ่มต้นใช้งาน MongoDB นั้น
การออกแบบ schema เป็นส่วนสำคัญมากที่ต้องทำความเข้าใจ
ต้องออกแบบให้สนับสนุนความต้องการต่างๆ
ทั้ง functional และ non-functional ของระบบงาน
เช่น ประสิทธิภาพการทำงานต้องดี ตอบรับความต้องการต่างๆ ได้ เป็นต้น
ซึ่งนั้นสิ่งที่เราต้องการก็คือ การออกแบบที่เหมาะสม
อธิบายในส่วนของการออกแบบ schema ของ MongoDB เพิ่มจาก post ใน facebook นิดหน่อย
[fb_embed_post href=”https://www.facebook.com/somkiatspns/posts/10152709554653588/” width=”550″/]
ตัวอย่างระบบงานนั้นผมนำมาจาก slide เรื่อง MongoDB Advance Schema Design ของทาง 10Gen ดังนี้
1. การเขียนข้อความ เมื่อเขียนมา 1 ข้อความแล้ว จะทำการบันทึกข้อมูลลงระบบ แยก sharding ตามผู้รับหรือคนที่ติดตาม
2. การอ่านข้อความ เมื่อผู้ใช้งานเข้ามาดูจะพบข้อความจากผู้ใช้งานที่ติดตาม ซึ่งจะไปอ่านข้อมูลมาจาก sharding node ต่างๆ
มาดูกันว่าในการออกแบบควรคำนึงถึงปัจจัยอะไรบ้าง
- รูปแบบการใช้งานของระบบว่ามีอัตราการเขียนและอ่านสูงมากเพียงใด ซึ่งควรสนับสนุนทั้งการอ่านและเขียนในปริมาณสูงๆ
- การอ่านและเขียนของแต่ละผู้ใช้งานแตกต่างกัน ดังนั้นการออกแบบระบบแบบกระจายควรคิดถึงเรื่องนี้ด้วย ไม่เช่นนั้นข้อมูลจะไม่กระจาย เนื่องจากผู้ใช้งานบางคนมีอัตตราการเขียนที่สูง บางคนมีอัตราการอ่านที่สูง เช่นผู้ใช้งานที่ติดตามผู้อื่นๆ มากๆ จะมีอัตราการอ่านที่สูงมาก
- รองรับการเข้าใช้งานพร้อมๆ กันได้
ในการออกแบบให้รองรับจำนวนการอ่านและเขียนสูงๆ ด้วย MongoDB นั้น
จำเป็นต้องใช้วิธีการที่เรียกว่า Sharding มีรูปแบบการออกแบบ 3 แบบ ดังนี้
- Fan out on Read
- Fan out on Write
- Fan out on Write with Buckets
โดยแต่ละแบบล้วนมีข้อดีและข้อเสียเสมอตามความต้องการของระบบ
ดังนั้นมาดูกันว่าแต่ละแบบคืออะไร และเป็นอย่างไร
ซึ่งจะไม่ลงในส่วนของ coding เลย เน้นแนวคิดล้วนๆ
1. Fan out on Read
- ทำการสร้างข้อความ 1 ข้อความต่อการส่ง ส่วนชื่อผู้รับจะอยู่ใน array ของ key
- ส่วนการอ่านข้อมูล ก็จะไปหาข้อมูลที่ชื่อผู้รับตรงกับผู้ใช้งานนั้นๆ เกิดจำนวน IO ต่างๆ จำนวนมาก จากการอ่านข้อมูลจากแต่ละ sharding โดยการทำงานแบบนี้จะเรียกว่า scatter-gather ซึ่งทำการส่ง query ไปดึงข้อมูลจากแต่ละ sharding
- รูปแบบนี้จึงไม่เหมาะสมกับความต้องการของระบบนี้
รูปแบบการสร้างหรือส่งข้อความเป็นดังนี้
รูปแบบการอ่านข้อความเป็นดังนี้
2. Fan out on Write
- ข้อมูลจะถูกสร้างขึ้นตามจำนวนผู้รับ เช่นมีผู้รับ 5 คนในการส่งข้อความครั้งนั้นๆ จะเกิด 5 ข้อความ ซึ่งการเขียนจะใช้ทรัพยากรเยอะ
- ส่วนการอ่านนั้นจะมีประสิทธิภาพที่สูงขึ้น เนื่องจากไม่ต้องไปดึงข้อมูลจาก shard อื่นๆ ซึ่งลดจำนวน I/O ลงไป
- โดยรวมสามารถรองรับการขยายตัวของระบบได้มากกว่า Fan out on Read
รูปแบบการสร้างหรือส่งข้อความเป็นดังนี้
รูปแบบการอ่านข้อความเป็นดังนี้
3. Fan out on Write with Buckets
- เปลี่ยนวิธีการเก็บข้อมูลใหม่โดยใน inbox ข้อผู้ใช้งานแต่ละคน จะเก็บข้อมูล array ของข้อความไว้ ซึ่งเรียกการเก็บแบบนี้ว่า bucket
- เมื่อมีข้อความใหม่ๆ เข้ามา ก็จะต่อท้ายเข้าไปใน bucket ของแต่ละคน
- ในการอ่านข้อมูลจะอ่านที่ sharding เดียวเท่านั้น แต่ขนาดข้อมูลในแต่ละ bucket จะใหญ่มาก ซึ่งในทางปฏิบัตินั้น ไม่ควรมีขนาดใหญ่เกินไป
รูปแบบการสร้างหรือส่งข้อความเป็นดังนี้
รูปแบบการอ่านข้อความเป็นดังนี้
โดยสรุปแล้ว
ก่อนที่จะเริ่มการออกแบบ schema ของ MongoDB
ควรทำความเข้าใจและต้องการของระบบก่อนเสมอ
เพื่อทำให้เราสามารถออกแบบได้ตรงตามความต้องการของระบบ
และการใช้งานที่เกิดขึ้นจริงๆ
ไม่เช่นนั้น มีโอกาสที่คุณจะต้องทำการรื้อ schema มาทำใหม่
ซึ่งจากที่ทำมา มันไม่สนุกเลย เนื่องจากต้องทำการย้ายข้อมูล และ ระบบต้องหยุดทำงานด้วยสิ …
