จากประมาณปี 1980 นั้นในวงการพัฒนามีการจัดการข้อมูลเชิงความสัมพันธ์ (Relational data)
ซึ่งรู้จักกันดีในนาม RDBMS(Relational Database Management System)
และ ใช้งานผ่านภาษา SQL(Structured Query Language)
แต่เมื่อไม่กี่ปีมานี้ในวงการพัฒนา software เริ่มมีการใช้งาน NoSQL (Not Only SQL)
เพิ่มขึ้นอย่างต่อเนื่อง ซึ่งทั้งสองอย่างมันมีการจัดการข้อมูลที่แตกต่างกัน
และเมื่อไปดูข้อมูลต่างๆ ในโลก internet พบว่ามีการถกเถียง
เรื่องระหว่าง SQL vs NoSQL กันอย่างมาก
แต่ว่า มันจะมีประโยชน์อะไร สำหรับเราล่ะ ?
ถ้าคุณเลือกสิ่งใด คุณก็ควรจะรู้ว่าเลือกเพราะอะไร ทำไม ดีอย่างไร ?
ดังนั้น มาดูกันว่าแต่ละอย่างมีข้อดีและข้อเสียอย่างไร ในมุมมองของ developer
Table vs Collection
สิ่งที่แตกต่างระหว่าง Relational database และ Non-relational database
คือแนวทางในการจัดเก็บข้อมูล
โดยที่ Relational database ทำการจัดเก็บข้อมูลในรูปแบบของตาราง (Table)
ซึ่งใน table ประกอบไปด้วย row และ column
แต่ละ table สามารถเชื่อมความสัมพันธ์ได้
ทำให้มันง่ายต่อการดึงข้อมูลขึ้นมา
ส่วน Non-relational database นั้นไม่ได้จัดเก็บข้อมูลในรูปแบบของ table เพียงอย่างเดียวเท่านั้น
แต่ยังสามารถทำการรวมข้อมูลให้อยู่ในรูปแบบ Collection เช่น
- Document
- Key-value
- Graph
ดังนั้น ก่อนที่คุณจะเลือกจัดเก็บข้อมูลในรูปแบบไหน
ควรทำความเข้าใจกับรูปแบบข้อมูลของคุณเสียก่อน
ทั้งการจัดเก็บ และ การดึงข้อมูลมาใช้งาน
รูปแบบของ Schema เป็นแบบ Pre-defined หรือ Dynamic
โครงสร้างข้อมูลใน Relational database นั้นต้องเป็นข้อมูลที่มีโครงสร้าง
ตามที่ได้กำหนดไว้ก่อนหน้าก่อนการจัดเก็บแล้วเท่านั้น (pre-defined schema)
ดังนั้น ในการออกแบบ data model จึงเป็นเรื่องที่สำคัญมากๆ
มักจะได้ยินคำว่า Get it right first time ซึ่งเป็นแนวคิดและทัศนคติของการออกแบบเลยทีเดียว
ทำให้ต้องใช้เวลาในการออกแบบพอสมควร
แต่ข้อดีมันก็เยอะมาก ทั้ง ความน่าเชื่อถือของข้อมูล ความเสถียรของข้อมูล
ส่วนการแก้ไขโครงสร้างหลังจากที่จัดเก็บข้อมูลไปแล้วก็จะยากพอประมาณ !!
ส่วนโครงสร้างใน Non-relational database นั้นสามารถทำได้ทั้ง pre-defined และ dynamic
คือ สามารถจัดเก็บข้อมูลในรูปแบบ unstructured data ได้
โดยโครงสร้างการจัดเก็บข้อมูลจะเปลี่ยนแปลงไปตามรูปแบบของข้อมูล
แต่ข้อเสียก็คือ ข้อมูลมันจะไร้ซึ่งรูปแบบ และ จัดการยากพอสมควร
ดังนั้น ลองพิจารณากันดูนะ ว่าข้อมูลคุณเป็นแบบไหน
Normalization vs Cost of Storage
ข้อมูลที่จัดเก็บใน Relational database นั้นมักจะต้องทำการ normalization
ให้อยู่ในรูปแบบของตารางที่เล็กที่สุด เพื่อป้องกันการซ้ำซ้อนของข้อมูล
ซึ่งทำให้ข้อมูลดี และ สะอาด รวมทั้งใช้พื้นที่ในการจัดเก็บน้อยลงด้วย
แต่ก็เพิ่มความซับซ้อนของการจัดการข้อมูลขึ้นมาเช่นเดียวกัน
เช่น การอ่านและเขียนข้อมูล ต้องจัดการหลายๆ ตาราง
ในปัจจุบันเรื่องของราคาของ storage สำหรับเก็บข้อมูลมันไม่ใช่เรื่องที่ต้องพูดถึงมาก
เพราะว่าราคามันต่ำลงไปจากอดีตมากมาย
ส่วนข้อมูลของ Non-relational database นั้นมันอยู่ในรูปแบบของ collection
ซึ่งแน่นอนว่าก่อให้เกิดข้อมูลที่ซ้ำซ้อนกันมากมาย
แต่มันง่ายต่ออ่านและเขียนข้อมูล ที่อยู่เพียงที่เดียว
การขยายแบบแนวนอน vs แนวตั้ง ( Horizontal vs Vertical )
สิ่งที่แตกต่างกันอย่างมากของ SQL และ NoSQL คือการขยายระบบ
เพื่อรองรับปริมาณการใช้งานที่สูงมากขึ้น
สำหรับ Relational database นั้นมักจะทำการขยายในแนวตั้ง (Vertical)
นั่นคือ การเพิ่มความสามารถของ server เช่นเพิ่ม CPU และ memory เป็นต้น
แต่ถ้าถามว่าขยายแบบแนวนอนได้ไหม ตอบว่า ได้แต่ยาก หรือ แพง พอสมควร
ส่วน Non-relational database นั้น สามารถขยายในแบบแนวนอน (Horizontal) ได้เป็นธรรมชาติ
นั่นคือ สามารถเพิ่มจำนวนเครื่อง หรือ node เข้าไปได้อย่างง่ายดาย
ซึ่งข้อมูลที่จัดเก็บในรูปแบบนี้จะกระจายกันไป
รูปแบบการดึงข้อมูล
ในการจัดการข้อมูลของ Relational database นั้นแน่นอนว่าทำงานผ่าน SQL
ซึ่งเป็นภาษาที่ทรงประสิทธิภาพสำหรับ CRUD operation (Create, Read, Update, Delete )
และเป็นมาตรฐานกลางที่ถูกใช้งานกันทั้งโลก
ส่วนการจัดการข้อมูลของ Non-relational database นั้นทำงานผ่าน
สิ่งที่เรียกว่า UnQL (Unstructured Query Language)
เป็นรูปแบบที่ไม่มีมาตรฐานกลาง แต่เป็นมาตรฐานของแต่ละตัวไปเลย
แน่นอนว่า นั่นคือปัญหาหลักเลย
แต่พบว่าในปัจจุบันเริ่มมีการสนับสนุน SQL แล้วทำการแปลงไปดึงข้อมูลมาให้อัตโนมัติ
เรื่องของการจัดการ Transaction
ถ้าระบบต้องการจัดการข้อมูลด้วย transaction เยอะๆ
รวมทั้งข้อมูลมีความซับซ้อนในการดึงข้อมูลออกมาแล้ว
แนะนำว่าใช้ Relational database ไปเลย จะเป็นตัวเลือกที่ดีสุดๆ
ทั้งในเรื่องความน่าเชื่อถือ เสถียร และ ประสิทธิภาพ ซึ่งต้องไปด้วยกัน
ส่วน Non-relational database ก็เริ่มจะทำงานแบบ transaction ได้เช่นกัน
แต่ไม่ใช่ความสามารถหลักของมัน
ACID vs CAP
ในโลกของ Relational database นั้น แน่นอนว่ามีความสามารถในเรื่อง
ACID (Atomic Consistence Isolated Durable)
ซึ่งมันเป็นข้อดีของมันเลยทีเดียว
ทำให้ระบบมีความน่าเชื่อถือเสมอมา
ส่วน Non-relational database มันเกิดมาเพื่อระบบแบบกระจาย (Distributed Node System)
ดังนั้นมักจะต้องเลือกคุณสมบัติจาก 2 ใน 3
ของ CAP theorem ( Consistency Availability Partition Tolerance )
เนื่องจากมันยากมากๆ ที่จะสนับสนุนทั้ง 3 คุณสมบัติ
แต่ถามว่ามีไหนที่มีคุณสมบัติครบ ?
ตอบเลยว่า มี
แต่มันคุ้มไหมล่ะ ที่จะเลือกใช้ ?
คุณเท่านั้นที่สามารถตอบได้
Data vs Big Data
แน่นอนว่า Relational database นั้นมันสามารถจัดการกับข้อมูลได้ดีเป็นปกติ
แต่เมื่อคำว่า Big data เกิดขึ้นมา มันจะมาพร้อมกับ NoSQL หรือ Non relational database มาเสมอ
เนื่องจาก Big data นั้นมักจะเป็นข้อมูลแบบ Unstructure/Semi-structure
ซึ่งเกิดขึ้นอย่างรวดเร็ว มันเกินความสามารถของ Relational database ทั่วไปที่จะรองรับ
ทั้งในเรื่องการจัดการข้อมูล การขยายระบบที่ต้องง่าย และ รวดเร็ว
ตลอดจนค่าใช้จ่ายในเรื่องต่างๆ ต้องน้อยด้วย
รวมทั้งยังต้องสามารถสรุป วิเคราะห์ ค้นหา แสเงในรูปภาพแผนภาพ ได้อีกด้วย
แต่ในปัจจุบันพวก Relational database เริ่มเอาความสามารถเหล่านี้ใส่เข้ามา
เพื่อให้สามารถรองรับได้เช่นกัน
เราใช้อะไรกันบ้าง
ในโลกของ Relational database นั้นเรามักนิยมใช้ทั้ง
commercial และ opensource software เช่น Oracle, MS SQL Server, MySQL, PostgreSQL เป็นต้น
ส่วนในโลกของ No relational database เรามักได้ยิน
หรือ software ที่มักได้รับความนิยมจะเป็น Opensource ทั้งนั้น
ไม่ว่าจะเป็น Hadoop, MongoDB, Redis, Riak, Couchbase, Bigtable เป็นต้น
โดยสรุปแล้ว
ถ้าคุณจะเลือกใช้ทางไหนนั้น สิ่งที่คุณต้องเข้าใจก่อนคือ
- ระบบของคุณมีลักษณะการใช้งานแบบใด
- ข้อมูลของคุณมีรูปแบบอย่างไร
ต้องทำความเข้าใจของสิ่งที่นำมาใช้งานว่ามีข้อดี และ ข้อเสีย อย่างไร
แล้วนำมาเปรียบเทียบกันในเชิงตัวเลข
รวมทั้งสิ่งที่คุณเลือกมันจะต้องอยู่บนพื้นฐานของความต้องการของระบบ
ไม่ใช่เลือกแบบมั่วๆ หรือ แบบความเคยชิน หรือ ความง่าย
หรือไม่ใช่เลือกตามกระแสความนิยม ได้ยินว่าดี แล้วก็ใช้ตาม
แบบนี้ไม่ดีอย่างแน่นอนครับ
ส่วนตัวผมมักจะใช้งานทั้งสองโลกในระบบเดียวกัน
เพราะว่า แต่ละตัวมันมีความสามารถเฉพาะอย่างกัน
ดังนั้นเลือกเครื่องมือ ให้ ตรงกับงาน เป็นสิ่งที่เหมาะสมที่สุด
