ฐานข้อมูลที่นิยมใช้มากที่สุด

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

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

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

Key-Value Database

การเก็บข้อมูลจะอยู่ในลักษณะ key กับ value โดยที่แต่ละ key นั้นจะไม่ซ้ำกัน และใช้ในการเป็น index สำหรับการเข้าถึง value เพราะฉะนั้นลักษณะของ Database ประเภทนี้จะเปรียบเสมือน Python dictionary หรือ JSON Object ขนาดใหญ่ที่สามารถเข้าถึง value ต่าง ๆ ได้ด้วยการ indexing ผ่าน key

นอกจากนี้พวก Key-value Database อย่างเช่น Redis (เป็น in-memory data structure store ที่ถูกนำมาใช้เป็น Key-value Database) นั้นจะเก็บ Data อยู่ในส่วนของ RAM หรือ Cache ของ machine ทำให้ความเร็วในการทำ operations อย่าง read, write นั้นสูงกว่า Database ประเภทอื่นมาก (ความเร็วอยู่ในระดับ millisecond) อีกทั้งตัว value ยังรองรับ Data Type หลายประเภทอีกด้วย (String, List, Set, Hash, Bitmap, etc)

ในเมื่อถ้ามันเร็วขนาดนี้ ทำไมไม่เอามาใช้แทนพวก MSSQL, MongoDB หรือ Database ประเภทอื่น ๆ เลยหล่ะ?

เนื่องจากมันมีแค่ key กับ value ทำให้ไม่มีสามารถทำการ query, JOIN operations หรือมี Data Model ที่นอกเหนือจาก key-value ได้ ทำให้ไม่เหมาะกับ Complex Data อีกทั้งเนื่องจาก Data ถูก store อยู่ใน RAM ทำให้ไม่สามารถเก็บข้อมูลได้เยอะ เมื่อเทียบกับ disk storage ทั่วไป

ข้อดี

• ใช้งานง่าย มีแค่ get value กับ set value
• มี response time ที่สูงเนื่องจากใช้ RAM ที่มีความเร็วในการ access ข้อมูลสูง
• มีความยืดหยุ่นสูง รองรับ Data Type ได้หลากหลายเช่น List, String, Hash, Set ได้เป็นต้น

ข้อเสีย

• เก็บข้อมูลได้น้อยเนื่องจาก volume ของ RAM นั้นค่อนข้างต่ำเมื่อเทียบกับ storage รูปแบบอื่น
• ไม่เหมาะกับการ query ซับซ้อน ทำได้แค่ get value ตาม key

เมื่อไหร่ที่ควรใช้ Key-value Database

• เหมาะกับการทำ Cache หรือ Session – โดยใช้ Key-value Database ในการลดเวลา response time ในการเข้าถึงข้อมูล นอกจากนั้นยังสามารถ store value ได้หลายประเภทเช่น โปรไฟล์ผู้ใช้ ข้อมูลประจำตัวผู้ใช้
• เน้นการเขียนข้อมูลแบบเรียลไทม์ – เช่นการแสดงผล leaderboard ของเกมแบบ หรือ การสนทนาส่งข้อความแบบเรียลไทม์

Wide-column Database

Database ประเภทนี้จะคล้ายกับการนำ Key-value Database มาปรับแต่งในส่วนของ value โดยที่ value นั้นจะ store ในส่วนที่อยู่ในลักษณะ set ของ column แทนที่จะเป็น value เดี่ยว ๆ เหมือนใน Key-value Database

นอกจากนั้น Wide-column Database ก็ยังไม่มี Schema ที่ตายตัว (Schema-less) ทำให้สามารถจัดการกับ unstructured ได้ อีกทั้งยังมีระบบ fault tolerant ในตัวจากการที่เก็บข้อมูลไว้หลาย Data Node เช่น Apache H-Base ที่ operate อยู่บน Hadoop file system จะมีการเก็บข้อมูลเดียวกันไว้ 3 Data Nodes เพื่อที่ว่าหากมี Data Node อันใดอันหนึ่งเสียไป จะสามารถ recover ข้อมูลกลับมาได้

มีภาษาที่ใช้ในการ query ข้อมูลที่คล้าย SQL แต่ไม่ทรงพลังเท่า (เพราะว่า perform JOIN operation ไม่ได้) อย่าง CQL (สำหรับ Cassandra) รวมถึงยังไม่สามารถ index value นอกเหนือจาก key ของมันได้

ข้อดี

• สามารถจัดการกับ Unstructured Data ได้
• สามารถทำ horizontal scaling ได้ง่าย
• รองรับการ write ในระดับข้อมูลขนาดใหญ่ได้ดี
• รองรับ fault tolerant ในการเก็บข้อมูล เช่นเวลามี Data Node พัง

ข้อเสีย

• ไม่สามารถทำ query ที่ซับซ้อนได้อย่าง JOIN ใน SQL

เมื่อไหร่ที่ควรใช้ Wide-column Database

• High write – มีการ write ข้อมูลบ่อย ๆ และจำนวนมาก ๆ เช่นข้อมูลที่เป็น time-series หรือเป็นสตรีมของข้อมูลจากหลาย IoT devices ทุกวินาที, ข้อมูลตลาดหุ้น
• Low read – ไม่จำเป็นต้องมีการอ่านข้อมูลแบบ real time หรือไม่จำเป็นต้องมี complex query พวก JOIN operation
• Large variety of Data – มี Data ข้อมูลไหลเข้ามาหลายประเภทเช่น unstructured, structured, semi-structured

ถึง Wide-column Database นั้นจะสามารถ scale horizontally หรือสามารถทำ write operation ที่มีปริมาณมาก ๆ ได้ แต่ก็ยังไม่เหมาะสำหรับการใช้เป็น General-purpose Database อยู่ดีแต่อาจเหมาะกับการเป็น Data Lake ที่ต้องการความสามารถในการ dump data ที่หลากหลายเข้ามาตลอดเวลา (High Write, Large variety)

Document Database

Document Database เป็นหนึ่งใน Database ที่นิยมใช้มากที่สุดในยุคปัจจุบัน โดยภายใน Database จะเก็บ Document ที่เป็นเซ็ตของ key-value pairs (หรือก็คือ JSON) และ Document เหล่านั้นจะถูกเก็บไว้ใน Collection (เปรียบเทียบคล้ายกับ Table ใน Relational Database Management System (RDBMS)) อีกที เพื่อทำให้ง่ายต่อการทำ Data Model

Document Database นั้นจะใช้คอนเซ็ปต์ของการทำ Denormalization ซึ่งตรงกันข้ามกับการทำ Normalization table ต่าง ๆ ใน RDBMS

การทำ Denormalization จะคล้ายกับการรวมหลายข้อมูลจาก table มาแล้วให้เป็นหนึ่งเดียว ทำให้มัน read ข้อมูลได้ไวมาก เมื่อเทียบกับ RDBMS ที่ต้องทำการ JOIN หลายสิบ table และมีจำนวนมากพร้อมกัน

นอกจากนั้นภายในแต่ละ Collection นั้นไม่จำเป็นต้องมี Schema ที่ตายตัว (Schema-less) ทำให้มีความยืดหยุ่น และสามารถรองรับ Data ทุกประเภท หรือ Data Structure ที่ซับซ้อนได้ เช่น Embedded Document, Nested JSON

อีกทั้งยังมีการ query ข้อมูลที่คล้ายกับ RDBMS เพียงแต่ JOIN ไม่ได้ แต่ความที่มันเป็น Schema-less นั้นมันก็ทำให้มี Trade-off ในเรื่องของ redundancy และ inconsistency ของข้อมูล ส่งผลให้การ write หรือ update ข้อมูลนั้นซับซ้อนยิ่งขึ้นเพราะไม่มีตัว validate schema เหมือนดั่ง RDBMS

ข้อดี

• มีความยืดหยุ่นรองรับ Unstructured Data ได้ดี
• สามารถทำ horizontal scaling ได้โดยง่าย
• ใช้งาน query ง่าย ๆ ได้ และ read ข้อมูลได้เร็ว

ข้อเสีย

• ไม่สามารถ query ซับซ้อนได้เช่นการ JOIN
• Trade-off ของการที่เป็น schema-less, และ Denormalization เช่น inconsistency, การทำ transaction, ความยุ่งยากในการ update ข้อมูล

เมื่อไหร่ที่ควรใช้

• มี Unstructured Data เข้ามาเกี่ยวข้อง, Schema ของ Data ยังไม่แน่นอน มี Nested Structured ที่ไม่ตายตัว
• มีเรื่องของ Scaling เข้ามาเกี่ยวข้องทั้ง Horizontal และ Vertical เช่นหากมีการเปลี่ยนแปลงของ requirement ตลอดเวลา หรือกำลังมีข้อมูลมีมหาศาลมากจนต้องเก็บอยู่ในหลาย Database Server
• ต้องการความเร็วในการ read ข้อมูล และไม่ควรมี query ที่ซับซ้อนมากนัก
• ยอมรับข้อเสียของการที่ไม่มี ACID operation ได้

Relational Database Management System (RDBMS)

เป็นหนึ่งใน Database ที่นิยมใช้กันมากที่สุดอีกหนึ่งตัว โดยจะบริหารจัดการข้อมูลอยู่ในลักษณะของความสัมพันธ์ระหว่างข้องมูล (Relational)  ซึ่งจะเก็บข้อมูลอยู่เป็นหมวดหมู่ในลักษณะของตาราง (Table) และแต่ละตารางสามารถบรรยายความสัมพันธ์กับตารางอื่นได้ ส่งผลให้สามารถ query ข้อมูลแบบซับซ้อนได้ (เช่นการทำ JOIN operation)

การเก็บข้อมูลในรูปแบบของตารางตาม Data Model ที่วางไว้ทำให้การเก็บข้อมูลมีความเป็นระเบียบเรียบร้อย นอกจากนั้น Database ยังทำหน้าที่ยืนยันว่าข้อมูลที่เข้ามานั้นจะตรงตาม Data Model ที่วางไว้เสมอ (consistency)

ความเป็น Relational

ลองจินตนาการภาพการผลิตสิ่งของบางอย่างจากโรงงานหนึ่งอย่างเช่น คอมพิวเตอร์

คอมพิวเตอร์นั้นเกิดจากการนำ components ต่าง ๆ เช่น RAM, DISK, CPU, POWER SUPPLY, GPU, MOTHERBOARD มาต่อกันเป็นคอมพิวเตอร์เครื่องหนึ่ง และแต่ละ component ก็จะมี Unique ID ของ Hardware ติดมาด้วย

ดังนั้นการจะผลิตคอมพิวเตอร์ขึ้นมาจำนวนมาก ๆ ในโรงงานได้ อย่างมีประสิทธิภาพ จึงจำเป็นต้องมี Blueprint ที่บอกถึงส่วนประกอบของ component ส่วนต่าง ๆ รวมถึง computer เองด้วยเช่น RAM ควรมีส่วน component ย่อยอะไรบ้าง จำนวณเท่าไหร่ เช่น clock, register, speed chip ซึ่งตัว Blueprint สามารถเรียกได้ว่าเป็น Schema ที่ถูกใช้ใน RDBMS

RDBMS ยังสามารถรองรับการทำ transaction เป็นข้อดีที่สุดอย่างหนึ่งของ Database ประเภทนี้ หมายความว่าถ้าหากมี query ย่อย ๆ หลาย ๆ อันที่มี relation ต่อกัน การทำ transaction จะทำให้มั่นใจได้ว่าชุดของ query ภายใน transaction นี้ต้อง success ทั้งหมด หรือถ้ามีอันใดอันหนึ่ง fail ก็จะ fail พร้อมกันทั้งหมด (Atomicity) และแต่ละ transaction จะเป็นเอกเทศต่อกันหมายความว่าถ้า transaction A มีข้อผิดพลาดบางอย่างเกิดขึ้นจะไม่ส่งผลต่อการทำ transaction B  (Isolation) เพื่อป้องกัน business logic ที่ผิดพลาด เช่น ลูกค้าซื้อสินค้า 1 ชิ้น ต้องมี query update 3 ตาราง ได้แก่

1. อัพเดทข้อมูลตารางลูกขค้าว่าลูกค้าคนไหนเป็นคนซื้อของ
2. อัพเดทข้อมูลตารางสินค้าว่าสินค้าไหนที่ถูกลูกค้าซื้อไป และ stock จะเหลือเท่าใดหลังจากซื้อ
3. อัพเดทข้อมูลตารางบัญชีว่ายอดบัญชีภายในร้านเพิ่มขึ้น หรือลดลงเท่าไหร่ด้วยเหตุผลใด 

สมมติว่า query ทั้งหมดสำเร็จไปเพียงแค่สองในสามหมายความว่าทำให้อาจเกิดเหตุการณ์ที่

1. สินค้าไหนลดลง เงินขึ้นในบัญชีของร้าน แต่ไม่รู้ว่าลูกค้าไหนเป็นคนซื้อ
2. จู่ๆ ร้านมีเงินเพิ่มขึ้นในบัญชี แต่ไม่รู้สินค้าชิ้นไหนถูกซื้อไป และ stock balance ผิดพลาด
3. ลูกค้าได้สินค้าตามปกติ แต่ยอดไม่ขึ้นในบัญชี ร้านค้าได้เงินแบบไม่ทราบที่มาที่ไป

นอกจากนี้เมื่อ transaction ถูก submit หรือ commit ไปแล้วจะถูกเก็บรักษาไว้อย่างดี เพื่อป้องกันเวลาระบบล่ม หรือไฟดับ จะมั่นใจได้ว่าข้อมูลทุกอย่างยังอยู่ตามเดิม (Durability)

โดย feature ที่กล่าวมาทั้งหมดข้างต้นได้แก่ atomicity, consistency, isolation, durability หรือที่เรียกว่า ACID operations นั่นเองซึ่งถือเป็นหนึ่งในข้อดีหลักของการเลือกใช้ RDBMS

ข้อดีของความเป็น Relational

• มีความเป็น ACID (Atomicity, Consistency, Isolation, and Durability)
• การที่มี Blueprint หรือ Schema ใน RDBMS นั้นทำให้สามารถมั่นใจได้ว่าข้อมูลที่เข้ามาจะคงอยู่ใน format ตาม Schema ที่วางไว้ตลอด โดยที่ RDBMS จะจัดการเรื่องยุ่งยางอย่างการ Validation ให้ทั้งหมด

ข้อเสียของความเป็น Relational

• ในโลกที่ requirement , regulation และ trends เปลี่ยนอยู่ตลอดเวลาเช่นจากหน้าจอ Monitor แบบกล่อง กลายเป็นจอ LCD, ช่องใส่ Floppy Disc ที่หายไปตามกาล, ขนาดของ component ที่เล็กลงเรื่อย ๆ ซึ่งทำให้ต้องรื้อ ปรับเปลี่ยน เพิ่มเติมอนอกเหนือจากส่วนที่เคยมีเช่น จากการใช้ CPU แบบเก่ามาเป็น M1 (รวม CPU กับ GPU ให้เป็น component เดียวกัน) ย่อมต้องมี cost ที่ตามมาซึ่งสถานการณ์นี้คล้ายคลึงกับการออกแบบแอปพลิเคชั่นขนาดใหญ่ ดังนั้นถ้าหากจะใช้ RDBMS การออกแบบฐานข้อมูลให้รัดกุม และ requirement ที่ค่อนข้างนิ่งจึงเป็นเรื่องที่สำคัญ
• การทำ scaling โรงงานจากวันหนึ่งผลิตคอมพิวเตอร์ได้ 30 เครื่อง/วัน กลายเป็น 1000 เครื่อง/วัน  นั้นทำได้ยากกว่า Database รูปแบบอื่น แต่ก็มีข้อยกเว้นอย่างเช่น CockroachDB หรือ PosgresSql ที่ถูกออกแบบมาสำหรับการ Scaling

เมื่อไหร่ที่ควรใช้ Relational DB

• มั่นใจว่า requirement ค่อนข้างแน่ชัด หรือมีการปรับเปลี่ยนที่ไม่เยอะ เช่นวันแรกผลิตคอมพิวเตอร์ อีกวันหนึ่งเปลี่ยนไปสร้างเครื่องบิน
• ไม่ค่อยเหมาะกับข้อมูลที่เป็น unstructured
• การ JOIN ข้อมูลหลายสิบตารางพร้อมกันอาจไม่เหมาะกับการใช้งานแบบ real time ได้

Graph Database

ภายใน Database นั้นจะเก็บอยู่ในลักษณะของ Node และ Edge โดยข้อมูลจะถูก store อยู่ใน Node และมีการ define relationship ของแต่ละ Node ผ่าน Edges

การจะหาว่ามีนักเรียนคนใดบ้างที่ลงคอร์สเรียน English ไปบ้างนั้น จำเป็นต้องมี Lookup/Middleman Table ทีเก็บข้อมูลว่านักเรียนคนไหนลงคอร์สใดไปบ้าง (การทำ Normalization ใน RDBMS) และจำเป็นต้องการใช้ JOIN ระหว่าง Table ดังภาพด้านบน

แต่ถ้าหากเป็น Graph Database นั้นมันจะ define relationship ลักษณะนี้ได้โดยไม่ต้องมี Table ที่ต้องมาเก็บ relationship ระหว่าง Data แต่หลักการของ Graph Database จะสามารถ define relationship ได้ที่ Edge โดยตรงดังภาพด้านบน

ให้การเก็บข้อมูลในลักษณะนี้ บรรยายความสัมพันธ์ระหว่าง Entity ได้โดยง่าย และตรงไปตรงมา นอกจากนั้นยังหลีกเลี่ยง complex query อย่างการ JOIN หลายตารางมาก ๆ ที่เป็นปัญหาหนึ่งใน RDBMS

ข้อดี

• Query speed สูงมากในกรณีที่ต้องการหา relationship ระหว่าง Node (ถ้าหากเป็น RDBMS นั้นจำเป็นต้อง JOIN หลายตาราง หรือมี Lookup Table)
• เป็นการเก็บข้อมูลที่อธิบาย relationship ของแต่ละ Node ได้ตรงไปตรงมา และ visualize ออกมาได้ง่าย
• มีความ flexible สูง ไม่จำเป็นต้องมี schema ที่ตายตัว

ข้อเสีย

• มีปัญหาเรื่องการทำ scaling
• ไม่เหมาะกับ High Write (มีการเขียนข้อมูล volume สูง ๆ)
• จำนวน vendors กับ userbase ยังต่ำอยู่ ทำให้  community ยังไม่โตเท่าที่ควร ส่งผลให้ยังไม่มี integrated tools, lib ต่าง ๆ หรือพวก data connector สำหรับใช้งานแต่ละ platform

เมื่อไหร่ที่ควรใช้ Graph Database

• ต้องการความเร็วในการ query data ที่มี relation ซับซ้อน (ต้องการ JOIN หลายตารางใน RDBMS) เช่นการทำ Realtime Recommendation System
• Data มี relationship ระหว่างกันมาก ๆ เช่นข้อมูลใน Wikipedia, Social Media Platform (อาจไม่เหมาะถ้าหากข้อมูลมีการ write เข้ามาใน volume ที่สูงมาก ๆ เช่น Facebook)
• ต้องการความง่ายในการ visualize relation ระหว่าง Data ที่มีอยู่

Search Database

จะมีลักษณะคล้าย Document Database แต่มีความต่างกันตรงที่ Document Database จะ assign index แล้วจึง insert document บน index นั้น ในขณะที่ Search Database จะทำตรงกันข้ามนั้นก็คือหลังจาก insert document เข้าไปแล้วตัว Search Database จะทำการ generate index ขึ้นมาให้จากคำสำคัญ หรือ term ต่าง ๆ (inverted index) เหมือนกับหน้า appendix ในหนังสือที่เราไว้ใช้ค้นหา Term หรือ Keyword สำคัญต่าง ๆ ว่าอยู่หน้าใดของหนังสือบ้าง

ข้อดี

• เร็วมาก ๆ ในการ query ที่เป็น Text Based (ตาม inverted index ของมัน แล้วแต่จะกำหนด)
• ไม่มี Schema เพราะเก็บเป็น Document Based (สำหรับ ElasticSearch จะรองรับข้อมูลที่เป็น JSON เท่านั้น)
• Scale ได้ง่าย

ข้อเสีย

• ไม่เหมาะกับการทำ Relational Query
• ต้องการ fine tuned พอสมควรถึงจะมี performance ที่ดี

เมื่อไหร่ที่ควรใช้

• การทำ Search Engine ภายใน Application, Enterprise ได้หมด
• Auto-suggestion, Auto-complete
• นำไปเสริม technology อื่นเช่นการทำ indexing ให้ Hadoop เพื่อทำให้ read ข้อมูลได้ไวขึ้น

ดังนั้นหลักการนี้จึงทำให้เหมาะกับการทำ Search Engine หรือพวก Type Ahead (Auto-suggestion ตอนพิมพ์คำ) มาก ๆ เนื่องจากเป็นการใช้ search text ที่มักจะเป็น Term ต่าง ๆ ที่ store อยู่ใน inverted index ทำให้มันเร็วมาก ๆ ในการค้นหา Document จาก search text นอกจากนั้นยังสามารถ custom algorithm ในการ search ได้ด้วย

ทิ้งท้าย

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

Reference

• 7 Databases paradigm
• How to choose right db for ur apps
• Key-Value Database
• Redis คืออะไร
• Amazon Redis
• pros and cons hbase
• getting started with mongodb
• https://medium.com/@rsk.saikrishna/when-to-use-mongodb-rather-than-mysql-d03ceff2e922
• https://saixiii.com/acid-database/
• https://www.trustradius.com/products/neo4j/reviews?qs=pros-and-cons

เนื้อเรื่อง ณนนท์ นพรัตน์
ตรวจทานและปรับปรุงโดย อนันต์วัฒน์ ทิพย์ภาวัต