Database 101 : Spreadsheet ไม่ใช่ Database โว้ยยยย

บทความนี้ เราเขียนสำหรับมือใหม่ หรือคนที่ไม่ได้เรียนด้านนี้แต่อยากรู้ละกัน สำหรับวันนี้เรามาพูดถึงคำที่ถ้าเราทำงานกับพวก Developer เขาคุยกันบ่อย ๆ ใช้งานกันเยอะ ๆ อย่าง Database กันว่า มันคืออะไร ทำไมเราต้องใช้ และ เราจะมีตัวเลือกอะไรในการใช้งานบ้าง

Database คืออะไร ?

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

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

โดยทั่ว ๆ ไป Database มันจะทำงานคนเดียวไม่ได้ ไม่งั้น มันก็จะเป็นก้อนข้อมูลที่อยู่เฉย ๆ ไม่รู้จะทำงานกับมันยังไง ทำให้มันต้องมี Database Management System (DBMS) เข้ามาช่วยเหลือ ในการเข้าถึง และ จัดการข้อมูล รวม ๆ เราจะเรียกว่า Database System แต่แหม่ มันยาวไปหน่อย เราเลยพูดย่อ ๆ ไปแค่ว่า Database ก็คือ เราจะรวบตึงทั้งข้อมูล และ ส่วนที่เป็น DBMS เข้าด้วยกันไปเลย

ตัว Database เอง จริง ๆ ก็ไม่ได้เป็นเรื่องใหม่อีกเหมือนกัน มันเกิดขึ้นช่วงประมาณ 1960 ตอนนั้น เรามี Database พวกที่เป็นกลุ่ม Hierarchical Database หรือเป็นพวกที่เก็บข้อมูลเหมือน Tree หรือพูดง่าย ๆ ถ้าคนที่เรียน Database มาหน่อย ก็คือ มันอนุญาติให้มีแค่ One-to-Many Relationshop จน 20 ปีผ่านไปช่วง 1980 เราเริ่มมีสิ่งที่เรียกว่า Relational Database ที่เน้นไปที่ความสัมพันธ์ของข้อมูลเป็นหลัก

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

ผ่านไปอีกนิดหน่อยช่วง 1990 พวก Object-Oriented Database ก็เกิดขึ้น เราขี้เกียจอธิบายแล้วอะไปหาอ่านเอาละกัน จนถึงช่วงนี้แหละ ที่การเข้าถึงอินเตอร์เน็ตมันเยอะขึ้นเรื่อย ๆ ข้อมูลทะลักเข้ามาแบบมหาศาลมาก ๆ ทำให้มันเกิดรูปแบบของข้อมูลใหม่ ๆ เยอะมาก ๆ ทำให้เกิดพวก NoSQL Database ขึ้นมา เพื่อรองรับรูปแบบข้อมูลใหม่ ๆ ที่เกิดขึ้น นั่นเองงง นี่แหละ คือ วิวัฒนาการของ Database แบบย่อ ๆ แล้ว ถ้าเราเรียนเข้าไปมันจะลึกกว่านี้มาก ๆ

การจะเป็น Database ได้ มันจะต้องมีคุณสมบัติอะไรบ้าง ?

ถ้าเราบอกว่า Database มันเอาไว้เก็บข้อมูล งั้น ถ้าเราเก็บไฟล์ไว้ใน Folder มันก็คือ Database แล้วใช่ปะ หรือ ถ้าเราเก็บข้อมูลของเราไว้ใน Spreadsheet มันก็เป็น Database แล้วเหรอ

คำตอบคือ ไม่ เพราะการที่มันจะเป็น Database ได้ มันจะมีทั้งหมด 4 คุณสมบัติด้วยกัน หรือที่เราชอบเรียกกันว่า ACID Properties คือ Atomicity, Consistency, Isolation และ Durability

Atomicity เราจะพูดถึงเวลา เรามีการเปลี่ยนแปลง หรือทำอะไรบางอย่างกับข้อมูล มันจะต้องทำเหมือนเป็น 1 อย่าง อาจจะ งง นะ ตอนเราเรียน เราจะจำว่า All or nothing ตัวอย่างเช่น เราจะทำเรื่องโอนเงิน เราจะต้องทำ 2 อย่างคือ หักเงินบัญชีต้นทาง และ เพิ่มเงินในบัญชีปลายทาง คุณสมบัติ Atomicity จะการันตีว่า ทั้ง 2 Operation นี้ ถ้าทำ มันจะต้องทำสำเร็จทั้ง 2 อย่าง หรือถ้าไม่ ก็คือ ไม่ทั้งหมด (สำหรับคนที่เรียน มันจะอยู่ในเรื่อง Transactional)

Consistency ทำตามชื่อของมันเลยคือ การการันตีว่า ข้อมูลที่เราเปลี่ยนแปลง มันจะต้องถูกเปลี่ยนแปลงอย่างถูกต้องตามที่ผู้ควบคุมเขียนเอาไว้ ส่วนคุมถูกมั้ย เป็นความรับผิดชอบของผู้ควบคุมที่ต้องออกแบบมาให้ถูก Logic ถ้าเราเทียบกับการโอนเงิน สมบัตินี้ มันจะการันตีว่า จำนวนเงินของบัญชีต้นทางรวมกับบัญชีปลายทาง ทั้งก่อนเริ่ม และ สิ้นสุดการเปลี่ยนแปลงข้อมูล จำนวนเงินนั้นต้องเท่ากันเสมอ

Isolation จะพูดถึงเวลาที่มันมีการทำงานพร้อม ๆ กันหลาย ๆ อย่าง มันจะต้องการันตีว่า ผลของอีก Transaction นึง จะต้องไม่ส่งผลกับอีก Transaction นึงเสมอ ยกตัวอย่างโอนเงินเหมือนเดิม เช่น ตอนเราสั่งโอนเงิน มันทำการหักเงินในบัญชีต้นทางไปละ ยังไม่ได้เพิ่มเงินปลายทางนะ ถ้าระหว่างนั้นมี คนที่ต้นทางเช็คเงิน เงินเขาควรจะยังไม่หายไป (สำหรับคนที่เรียนลึก ๆ หน่อยมันจะมีพวก Locking Mechanisms)

Durability เป็นคุณสมบัติที่การันตีว่าเมื่อ การเปลี่ยนแปลงเสร็จสมบูรณ์มันควรจะคงอยู่ตลอด แม้กระทั่งระบบมีปัญหาเกิดความผิดพลาดขึ้นก็ตาม ถ้าเป็นตัวอย่างการโอนเงินก็คือ เมื่อ Transaction ทั้ง 2 เกิดขึ้นเรียบร้อยแล้ว มันจะการันตีว่า ยอดเงินทั้งสองฝั่งจะถูกเพิ่ม และ หัก เรียบร้อยจริง ๆ แม้ว่าระบบจะเกิดปัญหาอะไรบางอย่างก็ตาม

โดย Database ที่เราใช้งานกัน มันก็จะเป็นไปตามคุณสมบัติทั้ง 4 ข้อที่เล่าไปเลย มันก็จะออกแบบพวกกลไกมาควบคุมพวกนี้แหละ ถ้าเราเรียนลึกเข้าไป เราก็จะได้เรียนพวกกลไกนี่แหละว่า มันทำงานยังไง เช่นพวก Locking Mechanism ที่ใช้กับสมบัติ Isolation มันจะมีลึกเข้าไปอีกว่า เราจะ Lock แค่ไหน ระดับไหน แล้วการจะล๊อคจริง ๆ มันทำยังไง มันมีเรื่องเข้าไปอีกเยอะมาก ๆ แต่ถ้าเราไม่ได้ไปเป็น DBA จริง ๆ ก็ไม่ต้องไปรู้หรอก

ทำไม Spreadsheet ไม่ใช่ Database ?

ก่อนหน้านี้ เวลามีคนมาบอกว่า เออ เรามี Database เก็บข้อมูลนะ เราก็อ่ออ เข้าใจว่าเขามีมา เราแค่เอาไปเชื่อมแล้วทำงานได้เลย ปรากฏว่า เชี้ยยยย เปิดมาเป็น Spreadsheet เช่น Excel หรือดีหน่อย เป็น Google Sheet แล้วหวะ

เราเคยเจอพีค ๆ คือ พนังงานต้องกรอก Excel ประมาณ 20-30 จุด ที่กระจายอยู่ในไฟล์ประมาณ 4-5 ไฟล์ สำหรับการเก็บข้อมูล 1 Record เรียกว่า พีค ๆ เลยละ ทำมาจนไฟล์มันใหญ่ขนาดที่ ถ้าจะ Apply Function ทีรอเป็นนาทีอะ

อ่านมาถึงตอนนี้ พอจะเดาได้มั้ยว่า ทำไมพวก Spreadsheet มันไม่ใช่ Database มันขาด ACID Properties ตัวไหนบ้าง เราลองมาดูกัน

Atomicity ถ้าเกิดว่า การปรับปรุงข้อมูลครั้งนึง เราจะต้องกรอกมากกว่า 1 รอบ ใน Spreadsheet เราการันตีไม่ได้เลยนะว่า พนักงานที่กรอกจะกรอกครบจริง ๆ ยิ่งถ้ากรอกในหลาย Sheet และ หลายไฟล์ด้วย หนักเลยนะ

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

Durability พีค ๆ อีก ถ้าเป็น Excel ที่เป็นไฟล์ ๆ หนักเลย เมื่อคนแก้ทำเสร็จ แล้วเซฟ ระหว่างนั้นมีคนเปิดไฟล์แก้อยู่เหมือนกัน พอเสร็จก็เซฟทับลงไป คนว่าการแก้ไขของคนแรกจะยังอยู่มั้ย ก็น่าจะลอยหายไปแล้วแหละ เรียกว่าข้อมูลตรงนั้นก็หายไปตลอดกาล จอบอไป

จาก 4 สมบัติ ก็คือ แตกไป 3 สมบัติแล้วนะ ดังนั้น กราบละ อย่าบอกว่า Spreadsheet เป็น Database เข้าใจนะว่า มันเก็บข้อมูลได้เหมือนกัน แต่การใช้งานมันคนละเรื่องเลย มันเหมาะกับการทำงานที่แตกต่างกัน ถ้ามันจำเป็นต้องใช้จริง ๆ อย่างกเนอะ จ้าง Programmer มา Implement เถอะ แก้ตอนนี้ยังไม่สายนะ ถ้าไปตอนข้อมูลเยอะ ๆ แล้วเสียเงินอ้วกค่าย้ายนี่ไม่รู้ด้วยนะ

SQL vs NoSQL Database

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

NoSQL Database ไม่ได้บอกว่า มันไม่ได้ใช้งาน SQL นะ แต่มันคือ Not Only SQL หรือก็คือ อะไรก็ตามที่ไม่ได้เป็น Relational Database โดยในทุก ๆ วันนี้ เรามี NoSQL ออกมาตอบโจทย์การทำงานแบบต่าง ๆ เยอะขึ้นเรื่อย ๆ แบบไม่น่าเชื่อนะ จำได้ว่า ช่วงแรก ๆ ที่เราได้รู้จัก มันพึ่งมีกลุ่มที่เป็น Document-Based Database อย่าง mongoDB กับพวก Graph Database อย่าง Neo4j ออกมาเอง ตอนนี้ก็อะไรบ้างอะ Dynamo, Redis, Cassandra, HBase, CouchDB, OrientDB ลอง ๆ ไปอ่านดูได้ มันจะมีจุดเด่นของแต่ละตัวอยู่ เลือกใช้ได้ตามที่เราต้องการเลย

อ่านมาแล้วอาจจะแอบคิดว่า เอ๊ะ พวก Relational Database มันล้าสมัยเหรอ ทำไมเรายกตัวอย่างน้อยจัง แต่จริง ๆ แล้วเป็น Database ประเภทที่เราใช้งานกันเป็นหลักในโลกอยู่นะ เพราะต้องยอมรับว่า มันเกิดมานานกว่า และ มันสามารถที่จะเข้าถึงข้อมูลอะไรได้ง่ายกว่า อยู่ในรูปแบบที่คนเราคุ้นเคยมากกว่าด้วย ตัวอย่างก็เช่น MySQL, MariaDB, PostgreSQL, Microsoft SQL Server และอันที่เราว่าน่าสนใจในสมัยใหม่ ๆ หน่อยก็ CockroachDB ที่เกิดมาเพื่อ Distributed Database โดยเฉพาะเลยแบบโหดมาก ๆ ถ้าเราต้อง Scale บน Cloud หลาย ๆ Region หรือพวก Enterprise บางเจ้าก็ไปเล่นของเจ้าตลาดอย่าง Oracle ที่หลัง ๆ มาทำ Oracle Database Appliance แล้วคือ โหดสัสมาก ๆ เป็นพวกกลุ่ม Multi-Model ด้วย ยืดหยุ่นสุด ๆ

Shit! It's BIG DATA ERA man!

ช่วงหลาย ๆ ปีที่ผ่านมานี้ เราจะได้ยินพวกสาย Business พูดกันเยอะมาก ๆ ว่านี่นะ นี่มันยุคของ Big Data แล้วองค์กรเราต้องปรับตัว เริ่มจากฐานข้อมูลของเราก่อนเลยนะ อันนี้พวก Relational Database มันไม่ได้แล้วมันไม่รองรับ Big Data เอ้า อี IT ไปดูมาสิ๊ ได้คำตอบมา อ่อใช้ Hadoop ครับ เปลี่ยน ๆ ย้าย ๆ แต่นายครับ บริษัทเราไม่เก็บข้อมูลอะไรเลยนะครับ... ไม่ได้สิ เราต้องเป็น Big Data

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

ทีนี้คำว่า Big Data จริง ๆ เป็น Concept กับพวกลักษณะของข้อมูลมากกว่า ที่มันเกิดจากความหลากหลายของข้อมูล และ ปริมาณที่เยอะขึ้นเรื่อย ๆ แล้วต้องการระบบที่มันเข้ากับข้อมูลของเขามากกว่า มันไม่ได้บอกนะว่า เราจะต้องใช้อะไรนั่นนี่ แต่มันต้องเป็น Solution ที่เข้ากับข้อมูล เช่น เราอาจจะใช้ Relational Database ก็ยังได้ แต่เราอาจจะต้อง Optimise อะไรบางอย่างเพื่อให้มันเข้ากับการทำงานของเรามากขึ้น เช่นการทำ Index มั้ย การทำ View แยกออกมามั้ย มันไม่เกี่ยวกับว่า โหยย เราจะต้อง Implement โดยการใช้ Hadoop นะ แค่ว่า Hadoop มี Feature พวกที่มันเอื้อกับการทำข้อมูลขนาดใหญ่ เราขอไม่พูดถึงละกัน ไปอ่านเพิ่มกันเอาเอง

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

สรุป

นี่น่าจะเป็นพื้นฐานง่าย ๆ ของ Database เอาให้พอเห็นภาพกว้าง ๆ ว่า มันคืออะไร และเราเอามาทำอะไรบ้าง ถ้าใครอยากศึกษาเพิ่มเติมก็อาจจะไปดู Database ที่เรายกตัวอย่างขึ้นมาก่อนก็ได้ว่ามันมีข้อดี ข้อเสียอะไรบ้าง เผื่อเราอาจจะต้องใช้ เราจะได้หยิบมาใช้งานได้เหมาะสมกับงานของเรา และสุดท้าย Spreadsheet ไม่ใช่ Database ขอบคุณครับบบบบ