Not Only SQL (NoSQL)
พอดีตอนนี้ผมต้องเข้าไปพัวพันกับเรื่อง ฐานข้อมูล หรือ database ขนาดใหญ่ (สำหรับผมนะครับ แต่คงไม่ใหญ่สำหรับคนอื่น) และเคยหลวมตัวเข้าไปนั่งฟัง whitepaper ของพวกพี่ ป.โท เกี่ยวกับ database ที่มีการ insert วันละเป็นล้าน record มาด้วย
เลยสงสัยว่า ยักษ์ใหญ่อย่างพวก Google,Facebook,twitter และรายอื่นๆ มีวิธีเก็บฐานข้อมูลกันอย่างไร หาไปหามา เจอเรื่องตกใจ ,,, เค้าใช้ "NoSQL",,, อ้าวยังไงล่ะทีนี้ สงสัยไปหมด แล้ว Relational Database ล่ะ
ไหนจะ SELECT * FROM ... ไหนจะเรื่อง table และ field อ่าว แล้วเรื่อง SQL Injection ล่ะ ??? เอ้ะ ยังไงล่ะทีนี้ ,,,
หลังจากหาข้อมูลได้พอสมควร เท่าที่ดูแล้วมันไม่ใช่เทคโนโลยีใหม่เลยครับ มีมานานแล้ว คงแค่ว่า(ผม)ไม่ค่อยได้เข้าไปพัวพันกับมัน เลยไม่ใช่สิ่งที่จะได้เจอ หรือจะได้ใช้ในชีวิตจริงกันมากเท่าไหร่นัก
จะเข้าใจได้ มันก็คงต้องเริ่มจากเรื่อง basic concept ของมันกันก่อน ว่าแล้ว ก็หาดูกันเลย
อะไรคือ NoSQL
NoSQL ถ้าหาข้อมูลแล้วเจอชื่อเต็มๆ หลายๆ แบบก็ไม่ต้องตกใจนะครับ ก็คงแล้วแต่จะเรียกกันไป เช่น Not Only SQL บ้าง , Non Relational Database บ้าง หรืออะไรอื่นๆ อีก ก็แล้วแต่ครับ
ปัจจุบันเรื่องฐานข้อมูลต่างๆ ไม่ว่าจะเป็นตามเว็บไซต์ ก็คงจะมีข้อมูลที่ต้องเก็บต่อวันมากขึ้น ตามสังคมแบบ Social Network ทำให้ไม่ต้องสงสัยเลยว่า ในอนาคต trend การเก็บข้อมูลแบบ NoSQL นี้ จะต้องใช้กันอย่างแพร่หลายแน่ๆ
จริงๆ แล้ว เจ้า NoSQL นี้ไม่มีอะไรมากเท่าไหร่ แค่เป็นการวิวัฒนาการที่มาจาก Relational Database จำพวก MySQL, Microsoft SQL นั่นแหละครับ แต่สิ่งที่มันทำให้แตกต่างจากพวก SQL ก็คือ
1.Non Relational
2.Distributed, Large Scale Databases
3.Horizontally Scalable (More nodes/servers)
4.Open Source
5.Schema Free
6.Eventually Consistent (BASE - Basically Available, Soft state, Eventual consistency)
7.Easy Replication Support
8.Simple API support
ประมาณ นี้นะครับ
พอมองเข้าไปอีกว่า แล้วในเมื่อมันเก็บข้อมูลเป็นก้อนๆ ไม่มีการเก็บแบบ table หรือแยกเก็บเป็นแต่ละ database แล้วทำไมมันถึงสามารถ Distribute ข้อมูลออกไปในแต่ละ Server ได้ล่ะ
NoSQL มีการพัฒนามาจาก Relational Database ใช้ SQL ทั่วๆ ไป ดั้งนั้น การคิดพัฒนา จึงมีการปรับปรุงโดยใช้ SQL มาคิดวิเคราะห์ พอมองพฤติกรรมของ SQL แล้ว SQL จะมีการออกแบบระบบฐานข้อมูลในแต่ละ table ให้มีความสัมพันธ์กัน ออกแบบให้มีการเก็บข้อมูลที่ซ้ำซ้อนน้อยที่สุด หรือเรียกว่าการทำ Normalization
และเนี่ยแหละครับ พอมันมีความสัมพันธ์ของแต่ละ table แต่ละ Database เข้ามา ปัญหาก็จะเกิดกับข้อมูลที่มีขนาดใหญ่ๆ ไม่ว่าจะเรื่องการสำรองข้อมูลให้กระจายไปยังแต่ละ database server (Redundant Server) หรือแต่ละ node
หากมีการเก็บข้อมูลที่เป็น Relation Database บน Server แบบ parallel เมื่อเกิดปัญหาใดปัญหาหนึ่งต่อระบบ ก็อาจจะส่งผลกระทบ อาจจะไม่สามารถดึงข้อมูลในระบบออกมาใช้ได้ครับ (เช่น จะเอาข้อมูลจาก table A ซึ่งปกติ ต้อง query ผ่าน table B แต่ถ้า table B เสียหายไป เราก็ไม่สามารถดึงข้อมูลจาก table A ออกมาดูได้ เพราะมันมีความสัมพันธ์กันหมด)
เมื่อการเก็บข้อมูลแบบ Relational Database ไม่ค่อยมีประสิทธิภาพมากนักกับการกระจายเก็บข้อมูลในหลายๆ แหล่ง ยักษ์ใหญ่ทั้งหลายที่ต้องเก็บข้อมูลวันละเป็นล้านๆ record และต้องนำข้อมูลนั้น ออกมาใช้ตลอดเวลา จึงต้องการระบบที่มีเสถียรภาพสูงมากๆ และยังต้องสำรองให้เก็บไว้หลายๆ แหล่ง เผื่อกรณีฉุกเฉินบาง server ได้ตาย(server down)ลงไป การเก็บข้อมูลแบบ Redundant Server จึงมีความจำเป็นที่สุด
ต้องสามารถเรียกข้อมูลได้ตลอดเวลา ส่งข้อมูลติดต่อกันแต่ละ server ได้ตลอด หรือเรียกว่า Eventually Consistent
ถึงยังไงก็ตาม ก็ต้องเข้าใจนะครับว่า การเก็บข้อมูลแบบ NoSQL ที่ว่ากันมานี้ มันเหมาะสำหรับข้อมูลที่มันมีขนาดใหญ่มากๆ เช่นฐานข้อมูล ของ Search Engine Google ยักษ์ใหญ่ ที่ตอนนี้กระจายเก็บใน server ต่างๆ มากเป็นพัน server แต่ถ้าเราทำระบบที่เก็บข้อมูลไม่เยอะมากมายถึงขนาดนั้น
สังเกตดูจากภาพ ข้อมูลชุดหนึ่ง จะกระจายไปยังหลายๆ node ตาม concept Distribute Server เลยครับ
ถ้าตัวใดตัวนึงตายไป ก็ยังมีอีกหลาย node server ที่สามารถเข้าถึงข้อมูลทั้งชุดได้ สามารถรองรับปัญหาต่างๆ ที่าจจะเกิดกับ node server แต่ละตัวได้เป็นอย่างดี ก
การใช้งานในแบบ Relational Database ก็มีความสามารถเพียงพอกับการใช้งานของเราแล้วล่ะครับ (แบบนี้ SQL Injection ก็ยังคงมีอยู่ ตราบชั่วลูกชั่วหลาน เหอๆๆๆ )
เพิ่มเติมได้ที่ NoSQL For Dummies – Rise Of Non Relational Database Engines | Open Source Technology Blog
เอาให้ละเอียดมันต่างจาก MySQL Microsoft SQL Oracle ที่เราๆท่านๆคุ้นเคยตรงนี้ครับ
- อย่างแรกเลยมันไม่มีความสัมพันธ์ครับ เพราะมันไม่ใช่ Relational Database เพราะฉะนั้นลืมเรื่อง Join, WHERE ไปได้เลย
- เน้นใช้งานกับปริมาณข้อมูลที่มีจำนวนมากมายมหาศาล ใครนึกไม่ออกว่ามากขนาดไหน ลองนึกถึง www.facebook.com, www.twitter.com, www.google.com นั่นแหละครับ ให้มา่นั่ง SELECT FROM WHERE รับรองครับ สิบนาทีถึงจะได้ข้อมูล
- แต่ เนื่องจากพวก NOSQL มันไม่มีโครงสร้างตายตัว มันเลยขายได้มากกว่า ในแบบขนาน (horizontal scaling) คือเพิ่มเครื่องได้ง่ายกว่านั่นแหละ
- ประสิทธิภาพสูงกว่า แต่ก็มากับการออกแบบที่ไม่แน่นอนไม่ตายตัวและยากกว่า RDB เป็นไหนๆ เพราะไม่ต้องคอยจัดการเรื่องความสัมพันธ์
- ตอนเรียนวิชาฐานข้อมูลมาเราเน้นการ Normalize แต่ที่นี่เราเน้นการ Denormalize ครับ เน้นให้มันเร็วที่สุดไม่ต้องไป join อะไรทั้ง หาเรคคอร์ดเดียวแล้วเอามาใช้งานได้เลย เช่นข้อมูล Contact ของ member เราก็เก็บทุกอย่างทุกคอลัมน์ลงไปเลยครับ ไม่ต้องไปแยกจังหวัด หรืออำเภออะไร เพื่อให้เกิดการ Compare เปรียบเทียบน้อยที่สุดครับ
- เวลาจะเชื่อมต่อต้องง่ายเข้าไว้ไม่ต้องมี overhead เยอะ มีแค่ IP กับ Port จบเลย
- ต้อง สามารถทำ Replication ได้เพราะ ข้อมูลเป็นสิ่งสำคัญ และจะได้ไม่ทำให้เกิด Single Point of Failure หรือเกิดจุดตายในระบบ คือ พังไปซักเครื่อง ก็ยังทำงานได้ปกติ
- เน้นการทำงานแบบ Key/Value หรือ Key/Column แล้วแต่ยี่ห้อครับ
- Document
- Graph
- Key/Value
- Tabular
- Unknown
| SQL | NoSQL or /rdb | |||
|---|---|---|---|---|
| select col1 col2 from filename | column col1 col2 < filename | |||
| where column - expression | row ’column == expression’ | |||
| compute column = expression | compute ’column = expression’ | |||
| group by | subtotal | |||
| having | row | |||
| order by column | sorttable column | |||
| unique | uniq | |||
| count | wc -l | |||
| outer join | jointable -al | |||
| update | delete, replace | |||
| nesting | pipes |
ที่มา
0 ความคิดเห็น:
แสดงความคิดเห็น