Skip to content

ความเข้าใจผิดเกี่ยวกับ NoSQL Databases

ช่วง 1-2 ปีที่ผ่านมาบ้านเรามีการพูดถึง Cloud และ BigData กันเยอะมาก (จริงๆ ฝรั่งเขาเริ่มมานานละ) ถ้าใครสนใจเชิงเทคนิคคงจะได้ตามเข้าไปดูถึง Software Stack ว่าใช้อะไรใน stack บ้าง ที่พบเห็นได้ทั่วไปก็ซอฟต์แวร์สำหรับ aggregate ข้อมูล และที่ขาดไม่ได้ก็ database สำหรับเก็บข้อมูล และคงได้ยินคำว่า NoSQL กันมาบ้าง

ความจริงแล้ว concept ของ NoSQL ไม่ใช่เรื่องใหม่นะครับมีเสนอมาตั้งแต่ยุค 90 แล้วแต่เพิ่งมาฮิตกันอีกเมื่อไม่นานมานี้นี่เองเพราะข้อมูลมีปริมาณมากขึ้น มีความหลากหลายมากขึ้น การเก็บข้อมูลด้วย RDBMS อาจจะเริ่มไม่เหมาะสมแล้ว เว็บใหญ่ๆ ที่มีปริมาณข้อมูลเข้ามามากๆ จึงเปลี่ยนไปใช้ NoSQL แทน และเมื่อพูดถึง NoSQL คนจึงคิดว่า “NoSQL ต้องใช้กับข้อมูลขนาดใหญ่เสมอ” ซึ่งผมจะบอกว่า “มันไม่ใช่เสมอไป”
เนื่องจาก NoSQL นั้นไม่มี data structure  ที่ตายตัวแต่ละตัวถูกสร้างมาเฉพาะทาง ยกตัวอย่าง MongoDB เป็น document-based เก็บข้อมูลแบบ JSON, Redis เป็น key-value-based และเป็น data structure สามารถเก็บข้อมูลเป็น Hash, Set, List และทำ operation ของชุดข้อมูลนั้นๆ ได้ เช่น ข้อมูลที่เก็บเป็น Set สามารถนำมา union, intersect ได้ ซึ่งสามารถนำไปประยุกต์ใช้ในแอปพลิเคชันตามความเหมาะสม

มาถึงตรงนี้อาจจะเกิดคำถามว่าแล้ว RDBMS มันทำไม่ได้เหรอ? RDBMS แบบเดิมก็ทำได้ครับแต่ NoSQL ที่เหมาะสมมันตอบโจทย์กว่าเพราะไม่ต้อง join ตารางเพื่อเอาข้อมูลออกมา ซึ่งการ join ข้อมูลตรงนี้แหละครับที่ทำให้ช้า ยิ่ง join มากยิ่งช้า NoSQL จึงถูกสร้างมาเพื่อมาแก้ปัญหาตรงนี้ ยกตัวอย่าง NoSQL แบบ document-based อย่าง MongoDB เราสามารถ query ด้วย id ก็สามารถได้ข้อมูลทั้งก้อนเอาไปใช้ต่อได้

จากที่ผมเล่ามาข้างต้นจะเห็นว่า NoSQL นั้นไม่ได้เกี่ยวกับขนาดของข้อมูลเพียงอย่างเดียวแต่ขึ้นอยู่กับความเหมาะสมว่าเราเอามาใช้ทำอะไร ดังนั้นหากพิจารณานำ NoSQL มาใช้กับงานเล็กๆ ก็สามารถทำได้เช่นกันครับถ้ามันตอบโจทย์ เช่น ถ้าข้อมูลของเราเป็นลักษณะเป็น log หรือ transaction log ที่ไม่ได้มีความสัมพันธ์กับ entity ใดๆ เลยก็เลือกใช้ document based อย่าง MongoDB ก็ได้ไม่ต้องยุ่งยากออกแบบฐานข้อมูลด้วย แต่ … ในทางกลับกันถ้าแอปของเราเป็นแอปที่ต้องการความถูกต้องในการบันทึกข้อมูลมาก ๆ เช่น แอปการการเงิน, stock สินค้า ซึ่งจำเป็นต้องใช้ฟีเจอร์อย่าง transaction  (transaction นึงอาจจะมีการทำงานหลายอย่างถ้ามีข้อผิดพลาดเกิดขึ้นจะถือว่า fail ทั้งหมดและไม่มีการบันทึกลงใน database หรือ table ใดๆ) ก็ควรเลือกใช้ RDBMS เช่น MySQL, Postgres ซึ่ง transaction นี้มีใน RDBMS เกือบทุกเจ้าอยู่แล้ว

สรุปจะเลือกใช้อะไรก็แล้วแต่หลักการอย่างนึงคือ 1) มันฟีเจอร์ที่มีตอบโจทย์เราหรือไม่ 2) ทีมของเรามีความรู้ในการ scale, maintenance หรือเปล่า ถ้าตอบว่าใช้ทั้ง 2 ข้อใช้อะไรก็ใช้ไปเลยครับ 🙂

Be First to Comment

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.