บางคนบอกว่า MongoDB, PostgreSQL, Elasticsearch, Redis มันดีมากๆ เลยนะ
แต่คำพูดเหล่านั้น มันสามารถตีความหมายได้ 2 ทาง คือ
- เครื่องมือเหล่านั้นมัน perfect สุดยอดไปเลย
- เครื่องมือเหล่านั้นมันเหมาะสมกับงานนั้น (problem domain)
แล้วคุณล่ะ คิดอย่างไร ?
ตัวอย่างการเลือกใช้ database เพื่อจัดเก็บข้อมูล
คุณจะทำการเลือกอย่างไร ?
บางคนอาจจะบอกว่า
ก็ทำการศึกษาเครื่องมือเหล่านั้นอย่างละเอียด
ทั้งในเรื่อง performace และ knowledge ต่างๆ
เพื่อให้รู้ว่ามันตอบรับกับความต้องการได้หรือไม่
แต่แนะนำลองคิดให้ละเอียดหน่อยสิว่า
Database ที่เขาบอกว่ามันแจ่มๆ นั้น
มันเหมาะสมกับปัญหา ที่เราต้องการแก้ไขหรือไม่ ?
ถ้าตอบไม่ได้ แสดงว่าคุณน่าจะมาผิดทางหรือเปล่านะ !!
โดยสิ่งที่คุณต้องให้ความสำคัญ คือ
- Data model
- APIs ที่เราจะใช้งาน
อีกอย่างที่ต้องยึดไว้คือ “Do one thing and do it well”
นั่นหมายความว่า
ดูก่อนสิว่า database ที่เราให้ความสนใจ
มันมี data model อย่างไร ?
และ APIs มันเหมาะสมกับปัญหาของเราหรือไม่ ?
และมันเป็นวิธีการที่ดีกว่าเดิมหรือไม่ ?
แต่ในความเป็นจริง เรามักจะพบว่า
มันไม่ใช่เป็นแบบนั้นนะสิ !!
เพราะว่า มักจะทำการประเมินว่าสิ่งที่ใช้มันต้อง
มีความสามารถเยอะๆ รองรับ data model ได้มากมาย
มี APIs ให้เยอะๆ หรือเทียบเท่าของเดิม (คำว่าของเดิม หรือ เหมือนเดิม มันน่ากลัวมากมาย)
ซึ่งเป็นแนวคิดที่อันตรายอย่างมาก …
และเมื่อคุณมองว่า database ที่ใช้มันต้อง
รองรับ data model ที่หลากหลาย หรือพวก dynamic schema หรือ schemess
รองรับข้อมูลขนาดใหญ่ หรือที่ชอบเรียกกันว่า Big Data
ทุกคนจะนึกถึงพวก NoSQL ขึ้นมาโดยอัตโนมัติ !!
กลับมาที่ RDBMS (Relational Database Management System)
ซึ่งเรามักไม่ค่อยได้สนใจเรื่อง data model และ APIs กันมากนัก
คุณไม่ได้สนใจหรอกว่า RDBMS มันแก้ไขปัญหาเราหรือไม่ ?
เราสนใจแค่ว่าเมื่อใช้คำสั่ง SQL มันสามารถทำงานได้ตามที่เราต้องการหรือไม่เท่านั้น !!
แต่ในโลกของ NoSQL มันตรงข้ามกันเลย
เนื่องจาก NoSQL แต่ละตัวมี data model และ APIs ที่แตกต่างกัน
และมีความสามารถเฉพาะตัวมาก
นั่นหมายถึงแต่ละตัวเหมาะสมกับปัญหาที่แตกต่างกันไป
ดังนั้นต้องเลือกให้เหมาะสมกับปัญหาของเรานะ
ตัวอย่างเช่น NoSQL พวก Graph database
นั่นหมายถึงข้อมูลของเราต้องอยู่ในรูปแบบของกราฟ
ประกอบไปด้วย node และ edge
ซึ่งทำงานได้ดีกว่าเก็บข้อมูลไว้ใน RDBMS อย่างแน่นอน
โดย APIs ก็จะมีสำหรับจัดการข้อมูลเกี่ยวกับกราฟเท่านั้น
คำถาม
ถ้าเรามีข้อมูลอยู่ในรูปแบบคล้ายๆ กราฟล่ะ
เราต้องเลือกใช้งานพวก Graph database หรือไม่ ?
คำตอบ
ถ้าตอบตามแนวของที่ปรึกษาคือ “it depends”
ในการพิจารณานั้น ดูหน่อยว่า Graph database มันเข้ามาเพื่อแก้ไขปัญหาของเราจริงๆ หรือไม่ ?
เช่น
เราต้องทำการเดินทางไปยังแต่ละ node แบบลึกๆ จริงหรือไม่ ?
ปัญหาของเราจำเป็นต้องใช้ทฤษฎีของกราฟมาแก้ไขจริงๆ หรือไม่ ?
หรือว่าปัญหาของคุณต้องการเข้าถึง node เพียง 2-3 edge หรือไม่ ?
ถ้าใช่ คุณใช้ RDBMS ก็เพียงพอก็ได้นะ …
จากนั้นสิ่งที่คุณห้ามลืม คือ
ในการทำงานกับข้อมูลแบบ graph นั้นการเข้าข้อมูล node และ edge ต่างๆ
จำเป็นจะต้องมีการจัดทำ indexing
ซึ่งพวก NoSQL ต่างๆ มักจะขาดความสามารถนี้ไป หรือ ทำงานไม่ค่อยดีนัก
ถ้าไม่ระมัดระวัง มันจะส่งผลกระทบต่อประสิทธิภาพของการทำงานอย่างมาก
จากตัวอย่างมันทำให้เราเห็นว่า
ในการเลือกใช้ database ใดๆ นั้น ควรเลือกให้เหมาะสมกับปัญหาที่เราต้องการแก้ไข
ซึ่งให้เริ่มพิจารณาจาก data model
จากนั้นดูรูปแบบการเข้าถึงข้อมูล
และเรื่องของ indexing ซึ่งมันกระทบต่อประสิทธิภาพ
และอย่าคิดว่า database ชนิดเดียวที่เขาว่ามัน perfect จะแก้ไขปัญหาได้ทั้งหมดล่ะ !!
แล้วคุณล่ะมีวิธีการเลือกอย่างไรบ้าง ?
- ใช้ตามๆ ที่เขาใช้กันมา
- เห็นเขาบอกว่าดี ก็เลยใช้
- เอาที่พี่สบายใจเลยครับ
- ….
