ถ้าให้ความน่าเชื่อถือ MongoDB น่าเชื่อถือว่า redis ครับ คือไฟตกไฟดับ ก็ยังเก็บข้อมูลได้ดีกว่า redis เพราะว่าตัวมันเกิดมาอยู่ตรงกลางๆ ระหว่าง ความเร็ว กับความน่าเชื่อถือของข้อมูล
ดังนั้น ถ้าจะเก็บถาวรใน mongo ก็ได้ และมี MySQL backup อีกชั้นก็สุดยอดครับ
การออกแบบหลาย layer แบบนี้ ปัจจุบัน น้อยคนนัก ที่จะทำได้ เพราะว่ามันยุ่งยาก เยอะ และดูแลลำบาก แต่สิ่งที่ได้รับกลับมาคือ ประสิทธิภาพที่สูงกว่ารันระบบเดียวมาก และข้อมูลก็ยังมีความน่าเชื่อถือด้วย และตัวคุณเองจะเป็นที่ต้องการของตลาด เพราะว่าคนที่ทำให้ระบบทำงานได้มีเยอะ แต่คนที่ทำให้ระบบทำงานได้ดี มีน้อยครับ
สำหรับเรื่องการแลกเปลี่ยนข้อมูลกันระหว่าง MongoDB <> MySQL อันนี้ ออกแบบ และเขียนได้หลายรูปแบบครับ แบบ on the fly ก็คือ คือเช็ค MongoDB ไม่มีก็อ่านใน MySQL ถ้าไม่มีอีกก็แปลว่าไม่พบเลย สร้างใหม่ ก็ว่ากันไป แต่หากไม่พบใน MongoDB แต่พบใน MySQL ก็อ่านจาก MySQL ขึ้นมาเก็บใน MongoDB แล้ว set expire เอาไว้ ก็ได้เหมือนกัน อันนี้ก็เป็นแนวทางหนึ่ง
อีกแนวทางหนึ่ง ก็เวลาเขียน ให้เขียนลงสองที่พร้อมกัน หรือเขียนลง MySQL แล้วอ่านจาก My ใส่ Mongo ก็ได้ เพราะว่าการ dump ข้อมูลระหว่างกัน มันจะใช้เวลาพอสมควรเมื่อขนาดข้อมูลโดยรวมของเรามีขนาดใหญ่ระดับหนึ่ง
แต่ว่าข้อมูลพื้นฐานบางอย่าง อาจจะต้องมีการ reload วันละครั้ง อันนั้นก็แยกกันไปอีกเรื่อง
เรื่องพวกนี้ มันมีปัจจัยเข้ามาเกี่ยวข้องเยอะแล้วครับ
เช่น
1.traffic เว็บเป็นอย่างไร
2.ต้องการความเร็วมากแค่ไหน
3.ต้องการความเชื่อถือมากแค่ไหน
4.concurrent เป็นอย่างไร
5.การประมวลผลปัจจุบันเป็นอย่างไร คอขวดที่ตรงไหน
6.ข้อมูลอะไรที่สำคัญ อะไรไม่สำคัญ
7.อัตราการ read/write เป็นอย่างไร
ถึงจะบอกได้ชัด ว่าการ link layer ของข้อมูลแต่ละชั้นควรเป็นแบบไหน
ส่วนเรื่องการเก็บเป็น json ใน MySQL ไม่รองรับก็จริงแต่เราแก้ปัญหาได้ด้วยการ แปลง json decode > array > serialize แล้วค่อยเอาไปเก็บใน MySQL ก็ได้ครับ เวลาใช้ ก็แปลงกลับ serialize > array > json encode ก็ได้เหมือนกันผมเคยใช้แบบนี้ แต่มีข้อเสียคือ MySQL เอามาเป็น condition ตอน search เพราะมันก็มองเป็น string ธรรมดา (แต่จริงๆ เก็บเป็น redis ก็ search ไม่ได้เหมือนกัน ต้อง retrieve ออกมาอ่านอย่างเดียว) แต่ถ้าเป็น mongo search ได้ครับ เพราะว่ามันทำงานเป็น BSON type ซึ่งคล้าย JSON นั่นล่ะครับ
เล่าสั้นๆเรื่อง mongo db มันจะมองโครงสร้างการเก็บเป็นแบบ document base ครับ ให้เราลองนึกถึงหน้าเว็บสักหน้า เราก็จะมี head title, header 2 , header3 , article , comment อีกหลายอันต่อไปยาวๆ จากคนหลายๆคน แบบนี้ mongo สามารถเก็บข้อมูลทั้งหมดได้ ใน record เดียว เท่านั้น (รวมทั้ง comment หลายๆอันยาวๆด้วยก็ตาม) ซึ่งจะต่างจาก MySQL ที่เราต้อง split comment แยก table ออก เวลาจะใช้ก็จับมาประกอบรวมกัน นี่คือ จุดแข็งของ MongoDB ครับ ทำงานได้ทั้ง memory + disk แต่ถ้าจำไม่ผิด ปกติจะทำงานบน disk นะครับ เป็น default
ทั้งนี้ ผมไม่แน่ใจว่า งานที่คุณกำลังทำ มี request หนักมากขนาดไหน เพราะว่าบางที back to basic ครับ คือ เขียนใส่แต่ MySQL อย่างเดียวเลยก็มากพอแล้วครับ (อาจจะเอา mysql memory table มาใช้ก็ช่วยได้เหมือนกัน) เพียงแต่เราต้องออกแบบ MySQL ให้เหมาะกับข้อมูลของเราสักหน่อย ผมยังไม่เจองานไหนที่เอามาใช้ออกแบบ MySQL ไม่ได้เลยนะครับ เพราะว่า RMDB มันเป็น database แบบพื้นฐานสุดๆที่ระบบส่วนใหญ่เค้าก็ทำงานกันได้โดยไม่มีปัญหาไม่ว่าโครงสร้างจะซับซ้อนขนาดไหนก็ตาม (แต่ความเร็วที่ได้นั่นก็เป็นอีกเรื่องหนึ่งครับ 5555)
งานที่ผมทำ ก็ผสมกันไป ส่วนใหญ่จะ mysql ล้วน เว้นแต่พวกที่ process หนักมากๆหรือเยอะมากๆ แบบนี้จะเอา redis+node เข้ามาช่วยเลยครับ คือ redis + MySQL และผมก็ตั้งสมมุติฐานว่า ถ้าไฟจะตกได้ตลอดเวลา จะทำอย่างไรกับข้อมูลให้ยังคงมีอยู่ และถูกต้องครับ หรือบางงาน ก็เป็นส่วนที่ต้อง process ทุกๆ 250ms และ process แต่ละครั้ง ก็ต้องจบใน 10ms ไม่เกินนี้ อะไรแบบนี้ครับ ถึงจะเอา redis เข้ามาใช้ (ยาวไปถึง lua ใน redis เลย ซึ่งน้อยคนที่จะใช้)
ลองค่อยๆออกแบบดูก่อนครับ มันมีหลายแนวทางให้เราทำ เลือกเอาที่เหมาะกับงานมากที่สุดครับ
อ้อ เรื่องการออกแบบ จะมาพร้อมกับประสบการณ์ครับ ดังนั้น ทำเยอะๆ เจอเยอะๆ แล้วจะได้ประสบการณ์เยอะก็จะออกแบบแก้ปัญหาได้ดีขึ้น