คลังเก็บหมวดหมู่: Database

โม้เกี่ยวกับ Database System

ใช้ NoSQL จัดการกับ Big Data

ข้อมูลในองค์กรที่ ๆ ผมทำงานอยู่ กำลังมีมากขึ้นเรื่อย ๆ จะเอาออกก็ไม่ได้ เพราะผู้ใช้งานก็ยังใช้สืบค้นอยู่ จะว่าเปลืองพื้นที่ก็ไม่ใช่ เพราะเดี๋ยวนี้อัดฮาร์ดดิสก์กันทีเป็นหลักเทราไบต์ แถมเครื่องนึงใส่ฮาร์ดดิสก์หลายลูก ทำเป็นคลัสเตอริ่งโน่นนี่นั่นอีกต่างหาก

ปัญหามันอยู่ที่การสืบค้นข้อมูล มันใช้เวลานานขึ้นเรื่อย ๆ ยิ่งตอนที่กำลังอ่านพร้อมกับกำลังเขียน ยิ่งใช้เวลานานเข้าไปใหญ่ นี่ยังไม่นับว่ามีคนแย่งกันใช้แหล่งข้อมูลเดียวกันเป็นร้อย ๆ เครื่องด้วยนะเอ้อ

ทางเลือกมีไม่มาก ผมเลยเริ่มหันมามอง NoSQL อย่างจริงจัง ซึ่งถึงมันเพิ่งจะเริ่มตั้งไข่ได้ไม่กี่ปี แต่ผมก็คิดว่าในอนาคตผมต้องได้ใช้มันแน่ ๆ

ปัญหาที่ตอนนี้ผมเจอเกี่ยวกับ NoSQL ก็คือแนวความคิดที่่ว่า มันจะไม่มีการ JOIN ระหว่างตารางข้อมูล มันขัดกับหลักพื้นฐานที่ร่ำเรียนมามาก ๆ และการประยุกต์ใช้ในทางปฏิบัติมันก็หลีกเลี่ยงการ JOIN ไม่ได้ด้วยอ่ะดิ เพราะข้อมูลในทางธุรกิจมันพัวพันยึดโยงกันอยู่ มันควรจะแยกอิสระออกจากกันแล้ว JOIN กันตามแบบเดิม ๆ ที่เคยเป็น

ถ้า DBMS แบบ NoSQL ไม่ยอมทำเรื่อง JOIN ข้อมูล งั้นก็คงมีทางเลือกสองทาง คือออกแบบเป็นแบบ Denormalized หรือไม่ก็ต้องเขียนโปรแกรมเพื่อ JOIN เอง!!!

ผมคิดว่าคนอื่นก็คิดคล้าย ๆ กัน และผมก็ได้ข่าวว่าตอนนี้มีการซุ่มพัฒนาภาษาคอมพิวเตอร์ ที่เหมือนกับภาษา SQL เพื่อใช้สำหรับฐานข้อมูลแบบ NoSQL โดยเฉพาะ ผมก็เลยคิดว่าภายในปี สองปี สามปี ที่จะถึงนี้ เราอาจจะพบว่า DBMS แบบ NoSQL กับภาษาคอมพิวเตอร์เพื่อสืบค้นฐานข้อมูลแบบใหม่ อาจจะใส่กลไกการ JOIN แบบใหม่เข้าไปก็ได้ เมื่อถึงตอนนั้น เราคงจะได้ใช้ฐานข้อมูลแบบใหม่ บนพื้นฐานความรู้แบบเก่า โดยไม่กระทบกระเทือนกับของเดิมที่พัฒนาเอาไว้แล้ว

ของใหม่มันก็ดีอยู่หรอกนะ แต่ยังไงเราก็ต้องใส่ใจกับของเก่าด้วย เพราะต้นทุนในการยกระดับให้ทันสมัย มันแพงเอาเรื่องอยู่เหมือนกันนะเออ

ตีความฐานข้อมูลแบบย้อนกลับ

ปรกติแล้วถ้าเราต้องออกแบบฐานข้อมูล เราก็จะมีโจทย์เป็นฉาก ๆ ที่ต้องเอามาคิด จากนั้นก็ร่างความคิดออกมาเป็นความสัมพันธ์ของตาราง ตามหลักการของ Database Normalization (อันแสนจะเข้าใจยาก)

ทีนี้ถ้าเปลี่ยนใหม่ล่ะ เปลี่ยนเป็นว่าความสัมพันธ์ของตารางถูกวาดออกมาแล้ว แล้วเราต้องมาอธิบายความสัมพันธ์ดังกล่าวให้อยู่ในรูปของการพรรณนาแทน แบบนี้จะทำไงดี … งั้น มาลองดูกันดีกว่า

โจทย์ – จงอธิบายภาพความสัมพันธ์ของตารางในภาพข้างล่างพอสังเขป

Marry
กดเพื่อดูภาพขยาย

อ่านเพิ่มเติม ตีความฐานข้อมูลแบบย้อนกลับ

เครื่องมือออกแบบ Data Dictionary

ผมกำลังทำงานอดิเรกสนุก ๆ ชิ้นหนึ่งอยู่ โดยวางแผนไว้ว่าจะต้องใช้เวลาในการออกแบบและจัดสร้างประมาณ 1 ปี เพราะต้องเขียนแผนธุรกิจ, เขียนพิมพ์เขียว, ออกแบบ Data Dictionary, ออกแบบ GUI, สร้างซอฟต์แวร์ ฯลฯ อือม ช่างเป็นงานอดิเรกที่กินเวลายาวนานจริง ๆ

ทีนี้ที่จะเล่าให้อ่านกันก็คือการทำ Data Dictionary ซึ่งเป็นสิ่งที่ผมไม่ค่อยจะถนัดเท่าไหร่ เนื่องจากทุกวันนี้ผมยังท่องกฎของ Database Normalization ไม่ได้เลย ดังนั้น วิธีแก้ไขก็คือการใช้เครื่องมือเข้าช่วย ซึ่งเป็นโชคดีของผมที่มีผู้สาวจัดหาเครื่องมือมาให้ใช้ โดยเครื่องมือดังกล่าวมีชื่อว่า fabFORCE DBDesigner

…มันเป็นเครื่องมือทุ่นแรงที่ดี เพราะถ้าไม่มีมัน การออกแบบ Data Dictionary คงสาหัสขึ้นอีกอักโข แถมข้อดีอีกอย่างหนึ่งของมันก็คือ มันสนับสนุน MySQL ซะด้วยสิ ยิ่งดีเข้าไปใหญ่!!!

แต่เหนือสิ่งอื่นใด การออกแบบ Data Dictionary ก็ยังคงขึ้นกับจินตนาการของผู้ออกแบบอยู่ดี ดังนั้น ต่อให้มีเครื่องมือดีแค่ไหนก็ตาม .. แต่ทว่า .. หากจินตนาการของเราตีบตัน เครื่องมือก็ย่อมจะไม่สามารถช่วยเหลืออะไรเราได้อยู่ดี!

คำค้น: , , , , ,

ยังไงซะ!!! ฐานข้อมูลก็ยังคงสำคัญอยู่ดี

หลังจากอ่านเอกสารเกี่ยวกับ Amazon S3, Amazon EC2 และ Amazon SimpleDB มาจนสมองน่วม ก็ทำให้รู้ว่าแสงสว่างรำไรยังมีอยู่!!!

ถ้าอยากจะใช้ฐานข้อมูล MySQL ก็สามารถจะติดตั้งลงใน Amazon EC2 ได้ .. แต่ .. ต้องลงตัว MySQL Enterprise นะเอ้อ! แล้วก็ต้องจ่ายตังค์ให้กับความ Enterprise ของมันด้วย T-T ซึ่งคิดว่าคงไม่น้อย (ยังไม่ได้ตรวจราคา)

แต่ถ้าไม่อยากจ่าย อยากจะใช้ Amazon SimpleDB ก็ได้ แต่งานนี้รับรองหลังแอ่นแน่ ๆ เพราะ Amazon SimpleDB มันไม่ได้เป็น RDBMS มันก็เลยไม่มีอะไร ๆ ที่ RDBMS ทั่ว ๆ ไปเขามี ซึ่งสิ่งที่ขาดหายไปและถือว่าร้ายแรงที่สุดก็คือ มันไม่มี INDEX อ่ะดิ! แล้วจะให้ทำ RDBMS เองเหรอ อือม ไม่เอาอ่ะ ทำไม่เป็น T-T

ตอนนี้ Amazon SimpleDB ยังเป็น BETA อยู่ หวังลึก ๆ ว่าเขาคงจะทำ INDEX ในรุ่นจริงออกมานะ เพราะถึงแม้จะ join table ไม่ได้ แต่อย่างน้อย ขอค้นแบบเร็ว ๆ ได้ก็ยังดี

คำค้น: , , , ,

กฎการ select ข้อมูลจาก table ใหญ่ ๆ ในฐานข้อมูล mysql

ผลลัพธ์อันเลวร้ายที่เกิดกับการ select ข้อมูลจาก table ใหญ่ ๆ ในฐานข้อมูลมีอยู่สถานเดียวนั่นก็คือ .. ช้าโคตร ๆ ๆ ๆ ๆ ยิ่งถ้ามีคนร่วมด้วยช่วยกัน select แล้วล่ะก็ ต้องบอกว่า .. ช้าโคตร ๆ ๆ ๆ ๆ ยกกำลังด้วยจำนวนคนที่ค้น!!!

ดังนั้นหากเราไม่อยากจะเจอกับเรื่องเลวร้ายเช่นนี้ งั้นเรามาทราบกฎกันดีกว่า ว่าเราควรจะทำยังไงกันดี?

กฎข้อแรก อย่าออกแบบตามหลักการ Normalization

  • เพราะการแยกข้อมูลกระจายไว้ตาม table ต่าง ๆ ตามหลักการ Normalization นั้น มันดูดี๊ดูดีในทางทฤษฎี แต่มันใช้ไม่ได้เลยในทางปฏิบัติ โดยเฉพาะหากต้อง join table เยอะ ๆ ซึ่งมีข้อมูลมาก ๆ หรือใช้ subquery แล้วล่ะก็ … ไอ้ Normalization เนี่ยแหล่ะ มันจะรัดคอตัวมันเอง

กฎข้อสอง อย่าเลือกข้อมูลเกินความจำเป็น

  • ยกตัวอย่างเช่น select * from person โดย table ชื่อ person มีฟิลด์เป็นร้อย แต่ดันใช้แค่ฟิลด์ id กับ name … งั้นก็เปลี่ยนเป็น select id, name from person ดีกว่ามั๊ง!!

กฎข้อสาม ระบุ index ให้ชัดเจนไปเลย

  • ตามหลักแล้ว table ทุกอันควรมี primary key และ index เพื่อความรวดเร็วในการค้นหา ซึ่งบาง table อาจจะมี index มากกว่าหนึ่งตัว งั้นแทนที่เราจะเขียนว่า select id, name from person where name = “ยิปซี” เราก็ระบุเป้ง ๆ ไปเลยว่าเราจะใช้ index ตัวไหน เช่น select id, name from person where name = “ยิปซี” use index (ix_name) เป็นต้น

กฎข้อสี่ อย่ายึด table ไว้คนเดียว

  • ไอ้เจ้า table ก็เปรียบได้กับสมบัติ มันต้องผลัดกันชม ดังนั้นการยึดเอาไว้ select แค่คนเดียวมันก็เกินไป เพราะมีคนอื่นเข้าแถวรอ select อยู่ จะเป็นการทำให้ชาวบ้านเขาเสียเวลาได้ งั้นที่ถูกต้องก็คือ พอ select ได้แล้วก็รีบ ๆ ลอกเอาไปไว้อีกที่นึง จากนั้นก็เชิญไปคุ้ยแคะข้อมูลที่เลือกไปได้ตามสบาย โดยการ select sql_buffer_result id, name from person where name = “ยิปซี” แบบนี้

กฎข้อห้า ต้องรู้จักการ Recycle

  • ข้อมูลบางชุดมีคนต้องการเยอะ ไอ้ครั้นจะให้ฐานข้อมูลค้นซ้ำ ๆ มันก็เปลืองแรงไป งั้นค้นทีเดียวเก็บเอาไว้ แล้วแจกจ่ายให้คนที่ต้องการภายหลังดีกว่า โดยการ select sql_cache id, name from person where name = “ยิปซี” เป็นต้น

กฎข้อหก เอากฎข้อหนึ่งถึงกฎข้อห้ามารวมกัน

  • ก็จะได้แบบนี้ select sql_buffer_result sql_cache id, name from person where name = “ยิปซี” use index(ix_name)

แต่กฎย่อมไม่มีความตายตัว ดังนั้นกฎใหม่ย่อมจะสามารถแทนที่กฎเก่าได้เสมอ ดังนั้นถ้าใครทำให้มันเร็วกว่านี้ได้ ก็ไม่ต้องเชื่อกฎนี้ก็แล้วกันนะจ๊ะ 😛

คำค้น: , , , , , ,