การเลือกเครื่องมือ (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 ทั่วไป ข้อดี ข้อเสีย เมื่อไหร่ที่ควรใช้ Key-value Database 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 ของมันได้ ข้อดี ข้อเสีย เมื่อไหร่ที่ควรใช้ Wide-column Database ถึง 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 ข้อดี ข้อเสีย เมื่อไหร่ที่ควรใช้ 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 ตาราง ได้แก่ สมมติว่า query ทั้งหมดสำเร็จไปเพียงแค่สองในสามหมายความว่าทำให้อาจเกิดเหตุการณ์ที่ นอกจากนี้เมื่อ transaction ถูก submit หรือ commit ไปแล้วจะถูกเก็บรักษาไว้อย่างดี เพื่อป้องกันเวลาระบบล่ม หรือไฟดับ จะมั่นใจได้ว่าข้อมูลทุกอย่างยังอยู่ตามเดิม (Durability) โดย feature ที่กล่าวมาทั้งหมดข้างต้นได้แก่ atomicity, consistency, isolation, durability หรือที่เรียกว่า ACID operations นั่นเองซึ่งถือเป็นหนึ่งในข้อดีหลักของการเลือกใช้ RDBMS ข้อดีของความเป็น Relational ข้อเสียของความเป็น Relational เมื่อไหร่ที่ควรใช้ Relational DB 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 ข้อดี ข้อเสีย เมื่อไหร่ที่ควรใช้ Graph Database 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 สำคัญต่าง ๆ ว่าอยู่หน้าใดของหนังสือบ้าง ข้อดี ข้อเสีย เมื่อไหร่ที่ควรใช้ ดังนั้นหลักการนี้จึงทำให้เหมาะกับการทำ Search Engine หรือพวก Type Ahead (Auto-suggestion ตอนพิมพ์คำ) มาก ๆ เนื่องจากเป็นการใช้ search text ที่มักจะเป็น Term ต่าง ๆ ที่ store อยู่ใน inverted...
