สารบัญ
Series: Database 101 — เข้าใจห้องสมุดของเมืองดิจิทัล (ภาษาคน)
Part 0 — WHY: ทำไมต้องมีห้องสมุด
Part 1 — ประวัติ: 4 ยุคของ Database
- EP.02 — ยุค 1960s-70s: Hierarchical → Relational Revolution
- EP.03 — ยุค 1980s-90s: ACID + Enterprise Backbone
- EP.04 — ยุค 2000s-2010s: NoSQL Movement + Big Data ← คุณอยู่ตรงนี้
- EP.05 — ยุค 2020s: Cloud-Native + Serverless Database (เร็วๆ นี้)
Part 2 — How: ภายใน Database ทำงานยังไง
- EP.06 — Schema, Normalization, Keys (เร็วๆ นี้)
- EP.07 — Index + Query Optimization (เร็วๆ นี้)
- EP.08 — Transaction + Concurrency Control (เร็วๆ นี้)
Part 3 — เลือก Storage ตามขนาด
- EP.09 — มุมเว็บส่วนตัว: Database-less Architecture (เร็วๆ นี้)
- EP.10 — มุม Personal Data: SQLite + Local-first (เร็วๆ นี้)
- EP.11 — มุม Startup: Serverless DB Stack (เร็วๆ นี้)
- EP.12 — มุม Enterprise: Polyglot Persistence (เร็วๆ นี้)
Part 4 — Operations
- EP.13 — DBA Role + Privileged Access (เร็วๆ นี้)
- EP.14 — Database Security + Encryption (เร็วๆ นี้)
Part 5 — Future
- EP.15 — Vector Database + AI Era (เร็วๆ นี้)
- EP.16 — Wrap: Decision Tree + 5 Trends (เร็วๆ นี้)
ครับ EP.03 เราจบที่ภาพสวยงาม ACID ทำให้ transaction ไม่หายระหว่างทาง Oracle / SQL Server / DB2 กลายเป็นกระดูกสันหลังของธนาคาร สายการบิน โรงพยาบาล ระบบบัญชีของบริษัทใหญ่ทั่วโลก relational database ไม่ได้แค่ชนะการประกวด แต่ชนะวงการไปทั้งวงการ ปี 2000 ใครเปิดตำรา database เจอแต่ SQL ใครจบมหาลัยสาย IT ต้องเรียน Oracle ดูเหมือนเรื่องจบแล้ว
แต่ปี 2006 มี paper หนึ่งหลุดออกมาจาก Google ปี 2007 มีอีกหนึ่งหลุดมาจาก Amazon ปี 2008 Twitter ล่มทุกสัปดาห์จนภาพการ์ตูนปลาวาฬสีฟ้ากลายเป็น meme ของวงการ พอถึงปี 2010 โลกก็ค้นพบว่า relational database ที่ทุกคนคิดว่า “ครบเครื่องแล้ว” มันมีจุดหนึ่งที่มันรับไม่ไหว จุดนั้นชื่อว่า Web Scale
EP.04 คือเรื่องของทศวรรษที่ “database ตัวเดียวพอ” กลายเป็นความเชื่อที่ตกยุค เป็นทศวรรษที่ NoSQL เกิด Hadoop ขึ้นมาเป็นพระเอกแล้ว fade และแนวคิด CAP theorem บังคับให้ทุกคนต้องเลือกข้างชัดเจน จะเอา consistency หรือ availability? เลือกได้แค่อย่างเดียวตอนระบบมีปัญหา
มาเริ่มที่ฉากที่คนทั้งโลกได้เห็นกันก่อน ภาพปลาวาฬลอยอยู่ในสายสวิงนกตัวเล็ก
ฉากเปิด: Twitter Fail Whale ปี 2008
ใครใช้ Twitter ช่วงปี 2007-2009 น่าจะคุ้นกับภาพนี้ครับ ปลาวาฬสีฟ้าตัวอ้วน ลอยอยู่บนท้องฟ้าโดยมีนกตัวเล็กๆ 8 ตัวพยายามใช้ตาข่ายช่วยกันยกขึ้น เป็นภาพการ์ตูนน่ารัก แต่มันโผล่ขึ้นมาเมื่อไหร่หมายความว่า Twitter ล่มอีกแล้ว ปีนั้นมันโผล่บ่อยจนคนเริ่มเรียกมันว่า “Fail Whale” มีเว็บไซต์ตั้งขึ้นมาเฉพาะเพื่อ track ว่าวันไหนปลาวาฬลอยอยู่บ้าง 555+
Twitter ตอนนั้นมี user ราวๆ 5 ล้าน ดูเป็นเลขเยอะ แต่ในมุมวิศวกรไม่ได้มากขนาดที่ระบบควรจะเอาไม่อยู่ขนาดนี้ คำถามคือ ทำไมเว็บไซต์ที่ทำแค่เรื่องเดียว (ส่งข้อความสั้น 140 ตัวอักษร) ถึงล่มได้บ่อยขนาดนี้?
คำตอบอยู่ที่ database ของ Twitter ในตอนนั้น MySQL ตัวเดียว relational database ที่ออกแบบมาตามคัมภีร์ของ EP.03 ทุกประการ ACID ครบ normalize ถูก foreign key สวย ปัญหาคือพอ user ใช้พร้อมกันถึงระดับล้าน โครงสร้างที่สวยงามนี้ทำงานช้าลงเรื่อยๆ จนหยุดทำงาน
วิศวกรของ Twitter ไม่ได้โง่ครับ พวกเขาทำทุกอย่างตามตำรา เพิ่ม RAM อัพเกรด server เพิ่ม CPU เพิ่ม cache แต่ทุกครั้งที่แก้ปัญหาได้ user ก็เพิ่มขึ้นเร็วกว่า มันคือการแข่งขันที่วิศวกรแพ้แน่นอน เพราะปัญหาไม่ได้อยู่ที่ server ไม่แรงพอ ปัญหาอยู่ที่ โครงสร้างของ relational database เอง ไม่ได้ออกแบบมาให้รองรับ user หลายร้อยล้านคน
Fail Whale คือสัญญาณเตือนของวงการว่ายุคของ “database ตัวเดียวรองรับทุกอย่าง” ใกล้จบแล้ว แต่ก่อนจะไปเรื่อง NoSQL ผมอยากให้คุณเข้าใจก่อนว่า ทำไม relational ถึงรับไม่ไหว? ทำไมเพิ่ม server แล้วยังพัง?
ทำไม relational ไม่ scale แนวนอน
ก่อนอื่นต้องอธิบายคำว่า scale แนวตั้ง vs scale แนวนอน ก่อนครับ เพราะคำนี้คือหัวใจของเรื่องทั้งหมด
ลองนึกถึงร้านอาหารร้านหนึ่ง Scale แนวตั้ง (Vertical Scaling) คือ ลูกค้าเยอะขึ้น เราจ้างเชฟเก่งขึ้น ซื้อเตาดีขึ้น ขยายครัวให้ใหญ่ขึ้น มันคือ “ทำตึกเดิมให้แข็งแรงขึ้น” ส่วน Scale แนวนอน (Horizontal Scaling) คือ ลูกค้าเยอะขึ้น เราเปิดสาขา 2, สาขา 3, สาขา 10 กระจายทั่วเมือง
relational database ในยุค 1990-2000 ถนัด scale แนวตั้งมาก Oracle ขายตู้ server ราคาหลายสิบล้านบาทที่แรงเป็นพิเศษให้ธนาคารใช้ แต่พอเจอเว็บที่มี user เป็นร้อยล้าน scale แนวตั้งไปไม่ไหว ต่อให้ซื้อตู้แพงสุดในโลกก็ไม่พอ ต้อง scale แนวนอน และตรงนี้แหละที่ relational เริ่มมีปัญหา 3 ข้อใหญ่
ปัญหาที่ 1: JOIN เริ่มแพง
ลองนึกถึงห้องสมุดที่มีตู้บัตรรายการหนังสือ ถ้าจะหา “หนังสือที่เขียนโดยนักเขียนชาวฝรั่งเศสที่เกิดก่อนปี 1900 และอยู่ในหมวดวรรณกรรม” บรรณารักษ์ต้องเดินไปดู 3 ตู้แล้วเอามาจับคู่กัน ในโลก relational เราเรียกการจับคู่นี้ว่า JOIN
ตอนตารางเล็ก JOIN เร็วครับ แต่พอตารางมีข้อมูลเป็น ร้อยล้านแถว การ JOIN 3 ตารางพร้อมกันใช้เวลา เป็นวินาที ต่อ query หนึ่งตัว เว็บที่มีคนเข้าวินาทีละแสนคน รับไม่ไหวแน่ๆ
ปัญหาที่ 2: Single Master Bottleneck
relational database แบบดั้งเดิมมี server หลัก (master) ตัวเดียว ที่รับหน้าที่เขียนข้อมูล server อื่นๆ ที่กระจายอยู่ทั่วโลกได้แค่ “อ่าน” เขียนไม่ได้ ทำไม? เพราะ ACID บังคับว่าทุก transaction ต้องผ่านศูนย์กลางตัวเดียว ไม่งั้น consistency จะพัง
ลองนึกถึงห้องสมุดเครือข่ายที่มีสาขา 100 ที่ทั่วโลก ถ้าใครจะยืม-คืนหนังสือ ต้องโทรไปขอบรรณารักษ์ที่สำนักงานใหญ่ที่กรุงเทพคนเดียว คน 100 ล้านคนทั่วโลกต่อสายเข้ามาพร้อมกัน บรรณารักษ์คนนั้นโทรศัพท์ระเบิดแน่นอน นี่แหละเหตุผลที่ Twitter ล่ม server หลักรับ tweet ใหม่ไม่ทัน
ปัญหาที่ 3: Sharding ยาก
วิธีแก้ในตำราคือ Sharding แบ่งตารางออกเป็นชิ้นๆ แล้วเก็บไว้คนละ server เช่น user ID 1-1,000,000 อยู่ server A, user ID 1,000,001-2,000,000 อยู่ server B แนวคิดดี ปฏิบัติยาก
ปัญหาคือ พอแบ่งตารางข้าม server แล้ว JOIN ข้าม server กลายเป็นฝันร้าย transaction ที่ต้องแตะหลาย shard พร้อมกันก็ทำให้ ACID พัง ถ้า user ย้ายข้อมูลข้าม shard ต้องเขียน script ย้ายเองมือ ผิดนิดเดียวข้อมูลหาย หลายบริษัทลอง sharding แล้วเลิก เพราะค่าดูแลแพงกว่าซื้อ server ใหม่
สรุปคือ relational ออกแบบมาเพื่อเก็บข้อมูลให้ถูกต้อง ไม่ได้ออกแบบมาเพื่อกระจายตัวข้าม server หลายร้อยตัว ปี 2000 ก่อน Google/Amazon/Facebook ใหญ่ขนาดนี้ ไม่มีใครรู้ว่ามันจะเป็นปัญหา พอถึงปี 2008 รู้แล้ว แต่ไม่มีใครมีคำตอบ คำตอบกำลังก่อตัวขึ้นจากอีกฝั่ง และมันมาพร้อมกับทฤษฎีที่บังคับให้ทุกคนต้องเลือกข้าง
CAP Theorem — เลือกได้แค่ 2 จาก 3
ปี 2000 Eric Brewer อาจารย์ที่ Berkeley ขึ้นเวทีงานสัมมนาแล้วโยนคำพูดหนึ่งทิ้งไว้ ที่ภายหลังกลายเป็นกฎเหล็กของ distributed database ทั้งวงการ เขาบอกว่าในระบบที่ database กระจายตัวอยู่หลาย server พร้อมกัน คุณจะได้คุณสมบัติพร้อมกัน 3 อย่างนี้ไม่ได้ เลือกได้แค่ 2
3 อย่างนั้นคือ Consistency, Availability, Partition Tolerance รวมกันย่อเป็น CAP
ก่อนจะอธิบายแต่ละตัว ผมอยากให้คุณนึกถึง scenario นี้ครับ สมมติคุณมีร้านสะดวกซื้อ 3 สาขา (กรุงเทพ, เชียงใหม่, ภูเก็ต) ทั้ง 3 สาขาต้องเห็นยอดสต๊อกของกันและกันแบบ real-time เพราะลูกค้าจองสินค้าจาก app กลางได้ เพื่อให้เห็น stock ตรงกัน ทั้ง 3 สาขาต้อง sync ผ่าน internet ตลอดเวลา
วันหนึ่ง internet ระหว่างสาขาเชียงใหม่กับสาขาอื่นขาด นี่แหละสิ่งที่วงการเรียกว่า Network Partition เครือข่ายแตก ไม่มีทางสื่อสารกันได้ คำถามคือ สาขาเชียงใหม่ควรทำอย่างไร?
มี 2 ทางเลือกเท่านั้นครับ
ทางเลือกที่ 1: ปิดสาขาเชียงใหม่เลย บอกลูกค้าว่า “ขออภัย ระบบมีปัญหา ไม่สามารถขายได้” ทำแบบนี้คุณรักษา Consistency ไว้ได้ เพราะตอนสาขาเชียงใหม่กลับมา online ยอด stock ทุกสาขายังตรงกัน แต่คุณเสีย Availability เพราะลูกค้าที่เชียงใหม่ซื้อของไม่ได้
ทางเลือกที่ 2: เปิดสาขาเชียงใหม่ต่อไป ขายเลย สาขาเชียงใหม่เก็บ record ไว้ก่อน เดี๋ยวค่อย sync ทีหลัง คุณรักษา Availability ไว้ ลูกค้ายังซื้อของได้ แต่คุณเสีย Consistency เพราะอาจจะมีคนที่กรุงเทพและเชียงใหม่จองของชิ้นเดียวกันพร้อมกัน เกิดเรื่องว่ามีคนที่จะไม่ได้ของจริง
นี่แหละสิ่งที่ CAP บอกครับ เมื่อเครือข่ายแตก (Partition เกิดขึ้น ซึ่งในระบบจริงมันจะเกิดขึ้นไม่วันใดก็วันหนึ่ง) คุณต้องเลือกระหว่าง C กับ A เลือกได้แค่อย่างเดียว
มาดู 3 ตัวอักษรกันชัดๆ
- C — Consistency ทุก server เห็นข้อมูลเดียวกันในเวลาเดียวกัน
- A — Availability ระบบตอบกลับได้เสมอ ไม่ปฏิเสธ request
- P — Partition Tolerance ระบบยังทำงานได้แม้เครือข่ายระหว่าง server แตก
ในโลกจริง P เป็น must ครับ คุณไม่มีสิทธิ์เลือกว่า “เครือข่ายห้ามแตก” มันแตกแน่ๆ ไม่วันใดก็วันหนึ่ง ดังนั้นในทางปฏิบัติ distributed database ทุกตัวคือการเลือกระหว่าง CP (Consistency + Partition Tolerance) หรือ AP (Availability + Partition Tolerance)
- CP database เน้น consistency ตอน partition เกิด ปฏิเสธ request ดีกว่ายอมให้ข้อมูลผิด ตัวอย่าง: ระบบธนาคาร ระบบสต๊อกสินค้า
- AP database เน้น availability ตอน partition เกิด รับ request ก่อน เดี๋ยวค่อย sync ทีหลัง ตัวอย่าง: feed ของ Facebook ตะกร้าสินค้าของ Amazon
สังเกตว่า Amazon เลือก AP สำหรับตะกร้าสินค้า ทำไม? เพราะถ้าตะกร้า sync ช้าไป 2 วินาที ลูกค้าไม่ได้เดือดร้อนอะไร แต่ถ้าตะกร้า “ใช้ไม่ได้” Amazon เสียเงินวินาทีละเป็นแสนเหรียญ มุมผู้บริหาร: CAP ไม่ใช่ปัญหาเทคนิค มันคือการตัดสินใจทางธุรกิจว่า เมื่อระบบมีปัญหา คุณยอมเสียอะไรก่อน ระหว่างความถูกต้อง กับความพร้อมให้บริการ
ทีนี้พอเรารู้กฎเหล็กข้อนี้แล้ว มันคือ trigger ที่ทำให้วงการสร้าง database พันธุ์ใหม่ขึ้นมา และคนที่จุดชนวนคือ Google กับ Amazon
2 papers ที่จุดชนวน NoSQL ทั้งหมด
ถ้าจะพูดว่า movement หนึ่งเริ่มจากที่ไหน NoSQL เริ่มจาก paper 2 ฉบับ ฉบับแรกจาก Google ปี 2006 ฉบับสองจาก Amazon ปี 2007 ทั้งสองฉบับเป็น public ใครก็โหลดมาอ่านได้ และทั้งสองฉบับเขียนวิธีสร้าง database ที่ relational แก้ปัญหาไม่ได้
Google BigTable Paper (2006)
Google ปี 2006 มีปัญหาที่ไม่มีใครในโลกเคยมีมาก่อน ต้องเก็บ index ของเว็บทั้งโลก หน้าเว็บเป็นพันล้านหน้า แต่ละหน้ามีคำเป็นล้านคำ ถ้าจะใช้ relational database เก็บ ตารางจะใหญ่เป็น petabyte (ล้านล้านไบต์) และ JOIN จะใช้เวลาเป็นชั่วโมงต่อ query หนึ่งตัว ใช้ไม่ได้
Google เลยสร้าง database ของตัวเองชื่อ BigTable แนวคิดต่างจาก relational เด็ดขาด แทนที่จะเก็บข้อมูลในตารางแบบแถว/คอลัมน์ที่ตายตัว BigTable เก็บข้อมูลเป็น column family ที่ยืดหยุ่นกว่า กระจายอยู่บนเครื่องนับพันได้ และยอม “เสีย consistency เล็กน้อย” เพื่อแลกความเร็วและขนาด
แล้ว Google ก็ทำสิ่งที่เปลี่ยนวงการ เผยแพร่ paper อธิบายว่า BigTable ทำงานยังไง ไม่ปล่อย code แต่อธิบายแนวคิดละเอียดพอให้คนอื่นไปสร้างเองได้ ปี 2006 paper นี้ทำให้คนทั่วโลกรู้ตัวว่ามีวิธีทำ database แบบที่ relational ทำไม่ได้
Amazon Dynamo Paper (2007)
อีกฝั่ง Amazon ปี 2007 มีปัญหาคนละแบบ เขาไม่ได้ต้องการเก็บ index ของเว็บ เขาต้องการให้ ตะกร้าสินค้าของลูกค้าทำงานได้เสมอ ไม่ว่าระบบจะเจอปัญหาอะไร ลองนึกถึง Black Friday ปี 2006 ลูกค้า Amazon ทั่วโลกใส่ของลงตะกร้าพร้อมกันเป็นล้าน ถ้าตะกร้าล่ม 1 นาที Amazon เสียรายได้หลายสิบล้านเหรียญ
Amazon เลยสร้าง database ของตัวเองชื่อ Dynamo แนวคิดคือ เก็บข้อมูลเป็น key-value pair ง่ายๆ (key คือ user ID, value คือเนื้อหาตะกร้า) กระจายข้อมูลซ้ำกันบนหลาย server และยอมให้ข้อมูลในแต่ละ server “ไม่ตรงกันชั่วคราว” ได้ ขอแค่ ระบบไม่มีวันล่ม นี่แหละ AP ตามภาษา CAP
แล้ว Amazon ก็เผยแพร่ paper ของ Dynamo เหมือนที่ Google ทำกับ BigTable ปี 2007 paper นี้ออกมาเหมือนคู่มือสร้าง key-value database ที่ scale ได้ระดับ Amazon
ทำไม 2 papers นี้สำคัญ
paper สองฉบับนี้ทำให้วิศวกรทั่วโลกรู้ว่า ไม่จำเป็นต้องใช้ relational ทุกงาน มีวิธีทำ database แบบอื่นที่เก่งคนละมุม แล้วในช่วง 5 ปีถัดมา (2007-2012) ทั่วโลกระเบิดของ database พันธุ์ใหม่ออกมา
- Cassandra (2008, จาก Facebook) — เอาแนวคิด BigTable + Dynamo มารวมกัน
- MongoDB (2009) — document database ที่ทำให้นักพัฒนาเก็บข้อมูลได้ยืดหยุ่นกว่าตาราง
- Redis (2009) — key-value store ที่เร็วที่สุดในโลก
- Neo4j (2010) — graph database สำหรับเก็บความสัมพันธ์
- HBase (2008) — clone ของ BigTable แบบ open source
วงการเรียก movement นี้ว่า NoSQL ย่อมาจาก “Not Only SQL” (ไม่ใช่ “ไม่มี SQL”) หมายความว่ามี database พันธุ์อื่นนอกจาก SQL/relational ใช้คนละงานกัน ไม่ได้แทนกัน
ทีนี้มาดูกันว่า NoSQL ที่ระเบิดออกมามี 4 ตระกูลหลักอะไรบ้าง
4 ตระกูลของ NoSQL
NoSQL ไม่ใช่ database ตัวเดียวครับ มันคือชื่อรวมของ database 4 ตระกูลที่เก็บข้อมูลคนละแบบ แต่ละตระกูลออกแบบมาเพื่อแก้ปัญหาคนละมุม ผมจะเล่าทีละตระกูลพร้อม use case จริง
ตระกูลที่ 1: Key-Value Store
Analogy: สมุดโทรศัพท์ ป้อนชื่อคน (key) ได้เบอร์โทร (value) จบ ไม่มีโครงสร้างซับซ้อน ไม่มี JOIN ไม่มีตาราง แค่ “ป้อน key ได้ value”
ตัวอย่างในตลาด: Redis, Amazon DynamoDB, Memcached
Use case จริง:
- Cache เก็บผลลัพธ์ของ query ที่ใช้บ่อย เพื่อไม่ต้องไปรบกวน database หลัก เช่น “10 ข่าวยอดนิยม” query ครั้งเดียวเก็บใน Redis 5 นาที อีก 5 นาทีค่อย refresh
- Session เก็บข้อมูล login ของ user (เช่น “user คนนี้ login อยู่จริง valid ถึงเวลา 17:00 น.”)
- Leaderboard ของเกม Redis ทำได้ใน 1 ms ไม่ว่าจะมี user 10 คนหรือ 10 ล้านคน
- Rate limiting กันคนยิง API เกินวันละ 1,000 request
จุดแข็ง: เร็วที่สุดในโลก Redis ตอบกลับใน 1 milli-second โดยเฉลี่ย เพราะเก็บข้อมูลใน RAM ทั้งหมด
จุดอ่อน: ทำได้แค่ “ป้อน key ได้ value” ถ้าต้องการ query ซับซ้อน (เช่น “หา user ทุกคนที่อายุเกิน 30”) Key-Value ทำไม่ได้ ต้อง scan ทั้งหมดเอง
ตระกูลที่ 2: Document Database
Analogy: ตู้เอกสารที่แต่ละแฟ้มมีรูปแบบของตัวเอง ลองนึกถึงตู้เอกสารโรงพยาบาล แฟ้มผู้ป่วยแต่ละคนมีข้อมูลไม่เหมือนกัน คนหนึ่งมีประวัติการแพ้ยา 5 รายการ อีกคนไม่มีเลย คนหนึ่งเคยผ่าตัด 3 ครั้ง อีกคนไม่เคย ถ้าเอามาทำเป็นตาราง จะมี column ว่างเต็มไปหมด
ตัวอย่างในตลาด: MongoDB, Couchbase, Firebase Firestore
Use case จริง:
- Catalog สินค้า สินค้าแต่ละชิ้นมีคุณสมบัติไม่เหมือนกัน กล้องถ่ายรูปมี “ความละเอียด” + “ชนิด lens” หนังสือมี “ผู้เขียน” + “จำนวนหน้า” เสื้อผ้ามี “size” + “สี” ใช้ document เก็บง่ายกว่าทำตาราง 50 column
- CMS (Content Management System) บทความแต่ละบทไม่เหมือนกัน
- User profile บางคน fill ทุก field บางคนไม่ fill เลย
จุดแข็ง: เก็บข้อมูลที่โครงสร้างไม่ตายตัวได้สบาย นักพัฒนาเปลี่ยน schema ได้โดยไม่ต้องไปแก้ตารางทั้ง database
จุดอ่อน: ตรงนี้สำคัญครับ MongoDB เคย hype มากในยุค 2010-2015 สตาร์ทอัพทุกที่เปลี่ยนจาก Postgres มาใช้ MongoDB เพราะ “มันเป็นยุคใหม่” ผ่านมา 10 ปี หลายเคสกลับลำกลับมาใช้ Postgres ที่มี JSON column (Postgres รองรับ document ได้ตั้งแต่ปี 2014) เพราะอะไร? เพราะข้อมูลของ business ส่วนใหญ่มี relational กันจริงๆ (order มี customer, customer มี address) ถ้าเก็บเป็น document แล้วมาทำ JOIN เอง ปวดหัวกว่าใช้ relational ตั้งแต่แรก
ตระกูลที่ 3: Column-Family Store
Analogy: spreadsheet ที่หมุน 90 องศา + กระจายอยู่หลาย server ใน relational เราคิดเป็น “แถว” (row) ผู้ใช้คนหนึ่งคือหนึ่งแถว ส่วนใน column-family เราคิดเป็น “คอลัมน์” เก็บ “อายุของผู้ใช้ทุกคน” ไว้ที่หนึ่ง “เพศของผู้ใช้ทุกคน” ไว้อีกที่หนึ่ง แล้วกระจายไปหลาย server
ตัวอย่างในตลาด: Apache Cassandra, Apache HBase, ScyllaDB
Use case จริง:
- Time-series data ข้อมูลที่มีเวลาเป็นแกนหลัก เช่น log ของ server ราคาหุ้นทุกวินาที อุณหภูมิจาก IoT sensor
- IoT เซ็นเซอร์ในโรงงานส่งข้อมูลเข้ามาวินาทีละหลายล้าน reading relational ตายแน่นอน
- Message storage Discord ใช้ Cassandra เก็บ message หลายพันล้าน message ต่อวัน
- Audit log ขนาดใหญ่ บริษัทที่ต้องเก็บ log ทุกการเข้าระบบของพนักงาน 5 ปี
จุดแข็ง: เขียนเร็วมหาศาล รองรับการเขียน เป็นล้าน operation ต่อวินาที ข้าม cluster หลายร้อย server
จุดอ่อน: ออกแบบโครงสร้างยาก ถ้าออกแบบ partition key ผิด ระบบช้ามาก แก้ทีหลังลำบาก ต้องมี engineer ที่เข้าใจ Cassandra ลึกๆ
ตระกูลที่ 4: Graph Database
Analogy: แผนผังความสัมพันธ์ระหว่างคน ลองนึกถึง Facebook friend graph คุณเป็นจุดหนึ่ง เพื่อนคุณเป็นจุดอื่นๆ เส้นเชื่อมระหว่างจุดคือความเป็นเพื่อน ถ้าจะหา “เพื่อนของเพื่อนของเพื่อน” แค่เดินตามเส้นไป 3 hop
ใน relational เรื่องนี้แพงมาก ต้อง JOIN ตาราง friend 3 ครั้งซ้อน แต่กับ graph database เป็นเรื่องธรรมชาติของมันเลย
ตัวอย่างในตลาด: Neo4j, Amazon Neptune, Memgraph
Use case จริง:
- Fraud detection ตรวจว่ามีคนเปิดบัญชีหลอกๆ เชื่อมโยงกับเครือข่ายโจรไหม ธนาคารใหญ่ใช้ graph เพื่อหา “เครือข่ายที่ต้องสงสัย” ภายใน 100 ms
- Recommendation engine “คนที่ซื้อหนังสือเล่มนี้ มักจะซื้ออะไรอีก” graph ตอบเร็วกว่า relational เป็นร้อยเท่า
- Knowledge graph Google ใช้ knowledge graph เพื่อตอบคำถามแบบ “Tom Hanks อายุเท่าไหร่” โดยตรงในหน้า search
- Social network LinkedIn, Facebook, Twitter ทุกตัวใช้ graph สำหรับเรื่องความสัมพันธ์ระหว่าง user
จุดแข็ง: query ความสัมพันธ์เร็วมาก “เพื่อนของเพื่อนของเพื่อน” ใน Neo4j ใช้เวลาไม่ถึง 100 ms ต่อให้มี user 100 ล้านคน
จุดอ่อน: ไม่เก่งเรื่อง query ทั่วไป (ที่ relational เก่ง) ส่วนใหญ่บริษัทใช้ graph เป็น database “เสริม” ข้างๆ relational ไม่ใช่ใช้แทน
ทีนี้พอ NoSQL มาครบ 4 ตระกูล ก็มี movement พี่น้องอีกอันที่เกิดพร้อมๆ กัน และมันใหญ่กว่า NoSQL ในแง่ hype ของช่วงนั้นเสียอีก
Hadoop + MapReduce — ยุค Big Data ก่อน Cloud ครอง
ปี 2003-2004 Google เผยแพร่ paper อีก 2 ฉบับ (ก่อน BigTable) ฉบับแรกชื่อ Google File System (GFS) วิธีเก็บไฟล์ขนาดมหาศาลกระจายข้ามเครื่องนับพัน ฉบับที่สองชื่อ MapReduce วิธีคำนวณข้อมูลก้อนใหญ่โดยแบ่งงานออกเป็นชิ้นเล็กๆ กระจายให้เครื่องหลายตัวช่วยกันคำนวณ
วิศวกรชื่อ Doug Cutting อ่าน paper 2 ฉบับนั้นแล้วบอกว่า งั้นผมสร้าง open source version ขึ้นมาเอง ผลลัพธ์คือ Hadoop ที่เปิดตัวปี 2006 พร้อม 2 ส่วนหลัก
- HDFS (Hadoop Distributed File System) copy แนวคิด GFS เก็บไฟล์ใหญ่กระจายข้าม cluster
- MapReduce copy แนวคิดของ Google แบ่งงานคำนวณกระจาย
ลองนึกภาพแบบนี้ครับ สมมติคุณมีหนังสือ 1 ล้านเล่ม ต้องนับว่าคำว่า “ความสุข” ปรากฏในหนังสือทั้งหมดกี่ครั้ง ถ้าให้คนคนเดียวอ่าน 100 ปีก็ไม่จบ แต่ถ้าจ้างคน 1,000 คน แต่ละคนอ่าน 1,000 เล่ม นับเสร็จแล้วเอามารวมกัน เสร็จในวันเดียว นี่แหละ MapReduce Map = แจกงาน, Reduce = รวมผล
ระหว่างปี 2010-2015 Hadoop กลายเป็นคำที่ทุก CIO ทุกบริษัทใหญ่ต้องพูดในห้องประชุม “Big Data” กลายเป็น buzzword ของยุค สถาบันการเงิน telco ค้าปลีก ทุกที่สั่งซื้อ Hadoop cluster ขนาดมหึมา มหาวิทยาลัยเปิดสาขาเรียน “Big Data Engineer” มีคนพูดว่า “Hadoop จะกลายเป็น OS ของยุคใหม่”
แต่ปี 2015-2020 Hadoop fade อย่างรวดเร็ว ทำไม?
3 เหตุผล
- Cloud อย่าง AWS, Google Cloud, Azure ออกบริการที่ดีกว่า แทนที่จะตั้ง Hadoop cluster เองใช้เวลา 6 เดือน + จ้าง engineer 5 คนดูแล ใช้ AWS EMR หรือ Google BigQuery แค่กดปุ่ม ราคาถูกกว่า 10 เท่า
- Snowflake / BigQuery / Redshift บริการ data warehouse บน cloud ที่ใช้ SQL ได้ตามเดิม + scale ได้ระดับ petabyte นักวิเคราะห์ที่เคยใช้ SQL ไม่ต้องเรียน Java/MapReduce ใหม่
- Spark มาแทนที่ MapReduce Apache Spark ทำงานเร็วกว่า MapReduce หลายสิบเท่าเพราะใช้ RAM เก็บข้อมูลกลางทาง
บทเรียนจาก Hadoop: เทคโนโลยีที่ “ปฏิวัติวงการ” วันนี้ อาจจะ fade ในอีก 5-10 ปี ถ้ามีของดีกว่ามาแทน มุมผู้บริหาร อย่าซื้อเทคโนโลยีตาม hype ดูว่าอีก 5 ปีข้างหน้า cloud provider จะมีบริการที่ดีกว่าให้กดปุ่มใช้ไหม
ทีนี้ผมต้องเตือนเรื่องความเข้าใจผิดที่ผู้บริหารมักจะติดกัน เพราะการเข้าใจผิดเรื่อง NoSQL ทำให้บริษัทเลือกผิดเยอะมาก
3 ความเข้าใจผิดยอดฮิตเรื่อง NoSQL
หลังจาก hype ของ NoSQL ในยุค 2010 มีความเข้าใจผิดที่ลามไปทุกห้องประชุมของบริษัท ถ้าคุณเป็นผู้บริหาร ผมอยากให้รู้ทันก่อนทีม IT มาเสนอ
ความเข้าใจผิดที่ 1: “NoSQL = ไม่มี schema”
ความจริง: NoSQL ส่วนใหญ่มี schema แค่ schema นั้น “ยืดหยุ่นกว่า” MongoDB ก็มี schema (เรียกว่า “implicit schema”) แค่ไม่ได้บังคับตอนเขียนข้อมูล
ถ้าคิดว่า “NoSQL ไม่มี schema เลย ก็โยนข้อมูลอะไรก็ได้เข้าไป” 1 ปีต่อมา ข้อมูลของคุณจะเป็นซากที่ไม่มีใครเข้าใจ นักพัฒนาคนใหม่จะร้องไห้ การ query จะเป็นฝันร้าย
คำที่ถูกกว่า: NoSQL คือ schema-on-read บังคับ schema ตอนอ่าน Relational คือ schema-on-write บังคับ schema ตอนเขียน
ความเข้าใจผิดที่ 2: “NoSQL ดีกว่า SQL”
ความจริง: NoSQL ไม่ได้ดีกว่า SQL มันเป็น tool คนละงาน
- ถ้าข้อมูลมี relational กันจริงๆ (order, customer, product เชื่อมกัน) + ต้องการ ACID + มีคน hundred-thousand ไม่ใช่ million → ใช้ relational (Postgres/MySQL)
- ถ้าต้องการ scale ระดับ Facebook/Twitter + ยอม trade consistency เล็กน้อย → ใช้ NoSQL ตามตระกูลที่เหมาะ
ปัญหาคือ สตาร์ทอัพไทยเยอะมากในช่วงปี 2014-2018 เลือก MongoDB ตั้งแต่วันแรก เพราะ “มันใหม่กว่า มันเทรนด์กว่า” 5 ปีต่อมา เจอปัญหาเรื่อง JOIN ปวดหัว transaction ไม่ atomic query ซับซ้อนทำไม่ได้ หลายเคสยอม migrate กลับมา Postgres ใช้เงินหลายล้านบาท
ความเข้าใจผิดที่ 3: “NoSQL = scale แล้วไม่มีปัญหา”
ความจริง: NoSQL scale ได้ แต่แลกกับ trade-off ตามกฎ CAP คุณยอม consistency เพื่อแลก availability แปลว่าระบบของคุณจะมีพฤติกรรมแบบ eventual consistency ข้อมูลที่เขียนเข้าไป อาจจะใช้เวลา 100 ms ถึง 5 นาทีกว่าจะปรากฏให้คนอ่านที่ server อีกฝั่ง
ถ้าระบบของคุณรับ eventual consistency ได้ (เช่น feed ของ social media ช้าไป 5 วินาทีไม่เป็นไร) → OK ถ้ารับไม่ได้ (เช่น ระบบโอนเงินธนาคาร ยอดเงินต้องตรงกัน 100% ทุกวินาที) → NoSQL ที่เลือก AP จะเป็นฝันร้าย
ผู้บริหารหลายคนเข้าใจผิดว่า “เปลี่ยนเป็น NoSQL แล้วระบบรับได้ทุกอย่าง” จริงๆ คุณกำลังแลกของแบบหนึ่งเพื่อได้ของอีกแบบ ไม่มีของฟรีในวงการ database ครับ
มุมผู้บริหาร: signal ที่บอกว่าทีมเลือก MongoDB ผิด
ตรงนี้ผมเขียนเฉพาะสำหรับเจ้าของกิจการ / ผู้บริหารที่กำลังจะตัดสินใจครับ ไม่ใช่เรื่องเทคนิค เป็นเรื่อง pattern ที่เห็นซ้ำในวงการสตาร์ทอัพไทย
ถ้าทีม IT ของคุณเสนอใช้ MongoDB (หรือ document DB ตัวอื่น) ลอง check signal พวกนี้
ใช้ MongoDB ถูก ถ้า:
- ข้อมูลของคุณคือ catalog ที่แต่ละชิ้น field ไม่เหมือนกัน (สินค้าที่หลากหลาย content ที่มีหลายแบบ)
- ระบบของคุณคือ event log / IoT data ที่เขียนเยอะ อ่านน้อย
- คุณไม่ต้องการ JOIN ข้ามตารางบ่อยๆ
- ทีมของคุณเข้าใจ trade-off ของ NoSQL
ใช้ MongoDB ผิด (ที่จริงควรใช้ Postgres) ถ้า:
- ข้อมูลของคุณมี order, customer, product ที่เชื่อมกันแน่น
- ต้องการ transaction (เช่น ระบบ checkout ระบบบัญชี)
- ต้อง query แบบ “หา order ทั้งหมดของ customer คนนี้ที่ซื้อสินค้าหมวด A ในเดือนที่แล้ว” ซึ่ง relational ทำใน 50 ms, MongoDB ทำใน 5 วินาที
- ทีมของคุณยังไม่เข้าใจ CAP theorem
สัญญาณเตือนภัยที่ควรถามทีม
- “ทำไมเราเลือก MongoDB?” ถ้าตอบว่า “เพราะมันเทรนด์” หรือ “เพราะ schema-less” สัญญาณไม่ดี ถ้าตอบว่า “เพราะ data ของเรามีโครงสร้างหลากหลาย ไม่ต้องการ JOIN รับ eventual consistency ได้” OK
- “เราจะทำ transaction ยังไง?” ถ้าตอบว่า “เขียน application logic เอง” ผิดเลย เขียน transaction logic เองคือทางลัดสู่ข้อมูลผิด
- “ถ้า scale เกิน 10 ล้าน user, schema เราจะเป็นยังไง?” ถ้าตอบไม่ได้ แปลว่าทีมยังไม่ได้คิดเรื่อง partition key
ที่เห็นใน pattern ของวงการ สตาร์ทอัพไทยที่เลือก MongoDB ตั้งแต่วันแรกแล้วโตเร็ว 70% migrate กลับมา Postgres ภายใน 3 ปี ค่า migrate รวมแล้วมักจะเป็นหลักล้านบาท + เสียเวลาทีม 6-12 เดือน ถ้าเริ่มที่ Postgres ตั้งแต่แรก ปลอดภัยกว่า แล้วค่อยขยายไป NoSQL ทีหลังได้เมื่อจำเป็น
ปิดบท + ข้ามไป EP.05
EP.04 จบที่นี่ครับ 2000s-2010s คือทศวรรษที่วงการ database ค้นพบว่า “database ตัวเดียวพอ” คือความเชื่อที่ตกยุค Twitter Fail Whale ปี 2008 เป็นสัญญาณ Google BigTable paper + Amazon Dynamo paper เป็น trigger CAP theorem เป็นกฎเหล็ก NoSQL 4 ตระกูลเป็นคำตอบ Hadoop เป็นพระเอกที่ผ่านมาแล้ว fade
แนวคิดที่เกิดในยุคนี้ที่จะอยู่กับเราต่อไปคือ Polyglot Persistence ใช้ database หลายตัวในระบบเดียวกัน ตัวละหน้าที่ Postgres สำหรับ order + transaction, Redis สำหรับ cache + session, Elasticsearch สำหรับ search, Cassandra สำหรับ time-series log, Neo4j สำหรับ recommendation ไม่มี database ตัวเดียวที่เก่งทุกอย่าง เลือกตัวที่เหมาะกับงาน (เรื่องนี้จะเจาะใน EP.12 — มุม Enterprise: Polyglot Persistence)
แต่ระหว่างที่ NoSQL กำลังระเบิดออกมา มี movement อีกอันที่ค่อยๆ เปลี่ยนสมมติฐานของวงการเงียบๆ ตลอด EP.04 เราคุยกันบนสมมติฐานว่า database อยู่บน server ของบริษัทเอง บริษัทซื้อตู้ server ตั้งใน data center จ้าง DBA ดูแล แต่พอเข้าปี 2020s สมมติฐานนี้พังทลาย
ปี 2020s คือทศวรรษที่ database ขึ้น cloud อย่างเต็มตัว ไม่ใช่แค่ “เอา database ของเราขึ้น server ของ AWS” แต่เป็น database ที่เกิดมาเพื่อ cloud โดยเฉพาะ Serverless database ที่คุณไม่ต้องคิดเรื่อง server เลย DBaaS (Database as a Service) ที่ scale อัตโนมัติ edge database ที่ใกล้กับ user มากที่สุดในโลก และวิธีคิดเรื่อง database ของวงการก็เปลี่ยนไปอีกครั้ง
EP.05 เราจะเข้าทศวรรษ 2020s กัน มาดูกันว่า cloud-native database คืออะไร ทำไม Snowflake ถึงมีมูลค่าสูงกว่า Oracle ในตลาดหุ้น และทำไม Neon / PlanetScale / Supabase กลายเป็น default ของสตาร์ทอัพยุคใหม่
→ EP.05 — ยุค 2020s: Cloud-Native + Serverless Database (เร็วๆ นี้)
