Michael Stonebraker และฐานข้อมูลสมัยใหม่: สิ่งที่เขาเปลี่ยนไป

ทำไมงานของ Stonebraker ยังคงปรากฏในสแต็กข้อมูลของคุณ

Michael Stonebraker เป็นนักวิทยาการคอมพิวเตอร์ที่โครงการของเขาไม่ได้แค่มีอิทธิพลต่อการวิจัยฐานข้อมูล แต่ยังเป็นรูปแบบการออกแบบและผลิตภัณฑ์ที่ทีมงานจำนวนมากพึ่งพาทุกวัน หากคุณเคยใช้ฐานข้อมูลเชิงสัมพันธ์ เวิร์เฮาส์เชิงวิเคราะห์ หรือระบบสตรีม คุณได้ประโยชน์จากไอเดียที่เขาช่วยพิสูจน์ สร้าง หรือทำให้เป็นที่แพร่หลาย

สิ่งที่คุณจะได้จากบทความนี้

นี่ไม่ใช่ชีวประวัติหรือทัวร์ทฤษฎีฐานข้อมูลเชิงวิชาการ แต่เป็นการเชื่อมระบบสำคัญของ Stonebraker (เช่น Ingres, Postgres และ Vertica) เข้ากับทางเลือกที่คุณเห็นในสแต็กข้อมูลสมัยใหม่:

• ทำไม SQL ถึงกลายเป็นภาษากลางของงานข้อมูล
• ทำไมเอนจินเชิงวิเคราะห์จึงดูและทำงานต่างจากฐานข้อมูล OLTP
• ทำไม “ฐานข้อมูลเดียวเพื่อทุกอย่าง” มักล้มเหลวในทางปฏิบัติ
• การเลือกสถาปัตยกรรมส่งผลต่อค่าใช้จ่าย ประสิทธิภาพ และความน่าเชื่อถืออย่างไร

คำว่า “ฐานข้อมูลสมัยใหม่” หมายถึงอะไร (ภาษาง่ายๆ)

ฐานข้อมูลสมัยใหม่หมายถึงระบบที่สามารถ:

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

แต่ละระบบจะเน้นเป้าหมายเหล่านี้ต่างกัน โดยเฉพาะเมื่อเปรียบเทียบแอปเชิงธุรกรรม, แดชบอร์ด BI และ pipeline แบบเรียลไทม์

คำสัญญาของบทความนี้

เราจะเน้นผลกระทบเชิงปฏิบัติ: ไอเดียที่ปรากฏในโลก “warehouse + lake + stream + microservices” ของวันนี้ และส่งผลต่อสิ่งที่คุณซื้อ สร้าง และปฏิบัติการ คาดหวังคำอธิบายชัดเจน ข้อแลกเปลี่ยน และผลลัพธ์เชิงโลกจริง—ไม่ใช่การเจาะลึกพิสูจน์ทางทฤษฎีหรือรายละเอียดการใช้งาน

ไทม์ไลน์สั้น ๆ และมีประโยชน์ของเหตุการณ์สำคัญ

เส้นทางอาชีพของ Stonebraker เข้าใจง่ายที่สุดเมื่อมองเป็นลำดับระบบที่สร้างขึ้นเพื่องานเฉพาะ—แล้วไอเดียที่ดีที่สุดก็ย้ายเข้าสู่ผลิตภัณฑ์หลักทั่วไป

ทศวรรษ 1970: Ingres — ทำให้ฐานข้อมูลเชิงสัมพันธ์ใช้ได้จริง

Ingres เริ่มจากโครงการวิชาการที่พิสูจน์ว่าฐานข้อมูลเชิงสัมพันธ์สามารถเร็วและปฏิบัติได้จริง ไม่ใช่แค่ทฤษฎี มันช่วยทำให้การคิวรีแบบ SQL และแนวคิดการปรับแผนคิวรีตามต้นทุนเป็นที่แพร่หลาย ซึ่งต่อมากลายเป็นเรื่องปกติในเอนจินเชิงพาณิชย์

ทศวรรษ 1980–1990: Postgres — ความสามารถขยายและ “ให้ฐานข้อมูลพัฒนาได้”

Postgres (ระบบวิจัยที่นำไปสู่ PostgreSQL) ทดลองเดิมพันแบบต่างออกไป: ฐานข้อมูลไม่ควรเป็นฟังก์ชันตายตัว คุณควรสามารถเพิ่มชนิดข้อมูลใหม่ วิธีการดัชนีใหม่ และพฤติกรรมที่ซับซ้อนขึ้นโดยไม่ต้องเขียนเอนจินทั้งตัวใหม่

ฟีเจอร์ “สมัยใหม่” หลายอย่างย้อนกลับไปยังยุคนี้—ชนิดข้อมูลที่ขยายได้ ฟังก์ชันที่ผู้ใช้กำหนดเอง และฐานข้อมูลที่ปรับตัวตามภาระงานที่เปลี่ยนไป

ทศวรรษ 2000: ระบบคอลัมน์และการออกแบบสำหรับการวิเคราะห์

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

กลางทศวรรษ 2000: Vertica — MPP เชิงวิเคราะห์เป็นผลิตภัณฑ์

Vertica นำไอเดียจากงานวิจัยคอลัมน์ไปสู่เอนจิน SQL แบบ massively parallel processing (MPP) ที่พร้อมใช้งานสำหรับคิวรีวิเคราะห์ขนาดใหญ่ รูปแบบนี้เกิดซ้ำในอุตสาหกรรม: โปรโตไทป์วิจัยพิสูจน์แนวคิด แล้วผลิตภัณฑ์ทำให้มันแข็งแรงขึ้นด้านความน่าเชื่อถือ เครื่องมือ และข้อจำกัดของลูกค้าจริง

ทศวรรษ 2010 เป็นต้นไป: สตรีมมิงและ “เครื่องมือที่ใช่สำหรับงาน”

งานในช่วงหลังขยายสู่ การประมวลผลสตรีม และเอนจินเฉพาะงาน—โต้แย้งว่าฐานข้อมูลทั่วไปเดียวมักไม่ชนะในทุกบริบท

โปรโตไทป์วิจัย vs ผลิตภัณฑ์ (ทำไมต้องแยกแยะ)

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

Ingres: ทำให้ฐานข้อมูลเชิงสัมพันธ์ใช้งานได้จริง

Ingres (ย่อมาจาก INteractive Graphics REtrieval System) เป็นผลงานยืนยันว่าโมเดลเชิงสัมพันธ์สามารถเป็นมากกว่าไอเดียที่สวยงาม ในตอนนั้นหลายระบบถูกสร้างรอบวิธีเข้าถึงข้อมูลแบบกำหนดเองและเส้นทางข้อมูลเฉพาะแอปพลิเคชัน

Ingres ต้องการแก้ปัญรง่ายๆ ที่เป็นมิตรกับธุรกิจ:

จะให้คนถามคำถามยืดหยุ่นกับข้อมูลได้อย่างไร โดยไม่ต้องเขียนซอฟต์แวร์ใหม่ทุกครั้งเมื่อคำถามเปลี่ยน?

สิ่งที่ Ingres พยายามแก้

ฐานข้อมูลเชิงสัมพันธ์สัญญาว่าคุณสามารถบรรยาย สิ่งที่ต้องการ (เช่น “ลูกค้าที่อยู่ในแคลิฟอร์เนียที่ค้างชําระ”) แทนที่จะบอก วิธี ดึงข้อมูลทีละขั้นตอน แต่การทำให้คำสัญญานั้นเป็นจริงต้องระบบที่สามารถ:

• เก็บข้อมูลอย่างเชื่อถือในตาราง
• ยอมรับภาษาคิวรีระดับสูงที่ใกล้เคียงกับ SQL
• แปลงคิวรีนั้นเป็นแผนที่มีประสิทธิภาพโดยอัตโนมัติ

Ingres เป็นก้าวสำคัญสู่เวอร์ชัน “ปฏิบัติได้” ของการคอมพิวติ้งเชิงสัมพันธ์—ที่สามารถรันบนฮาร์ดแวร์ในสมัยนั้นและยังรู้สึกตอบสนองได้

การยอมรับ SQL และกำเนิดของพื้นฐานการปรับแผนคิวรี

Ingres ช่วยทำให้ฐานข้อมูลควรทำงานหนักในการวางแผนคิวรี แทนที่นักพัฒนาจะต้องปรับจูนทางเข้าข้อมูลทีละรายการ ระบบสามารถเลือกกลยุทธ์ เช่น ตารางใดอ่านก่อน จะใช้ดัชนีใด และจะ join ตารางอย่างไร

นั่นช่วยให้แนวคิดแบบ SQL แพร่หลาย: เมื่อคุณเขียนคิวรีแบบประกาศความต้องการ คุณทำการวนรอบได้เร็วขึ้น และคนจำนวนมากขึ้นสามารถถามคำถามได้โดยตรง—นักวิเคราะห์ ทีมผลิตภัณฑ์ แม้แต่ฝ่ายการเงิน—โดยไม่ต้องรอรายงานเฉพาะตัว

ทำไมการปรับแผนแบบต้นทุนถึงสำคัญ

อินไซต์เชิงปฏิบัติใหญ่คือ การปรับแผนคิวรีตามต้นทุน: เลือกแผนคิวรีที่คาดว่าจะมี “ต้นทุน” ต่ำสุด (โดยปกติผสมกันของ I/O, CPU และหน่วยความจำ) อิงจากสถิติของข้อมูล

สิ่งนี้สำคัญเพราะมักหมายถึง:

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

Ingres ไม่ได้คิดค้นทุกชิ้นส่วนของการปรับแผนสมัยใหม่ แต่ช่วยวางรูปแบบ: SQL + optimizer คือสิ่งที่ทำให้ระบบเชิงสัมพันธ์ขยายจาก “ไอเดียดี” เป็นเครื่องมือรายวัน

Postgres: ไอเดียใหญ่เรื่องฐานข้อมูลที่ขยายได้

ฐานข้อมูลเชิงสัมพันธ์ยุคแรกมักสมมติชุดชนิดข้อมูลคงที่ (ตัวเลข ข้อความ วันที่) และชุดการดำเนินการคงที่ (กรอง join รวม) นั่นทำงานได้ดี—จนทีมเริ่มเก็บข้อมูลชนิดใหม่ (ภูมิศาสตร์ log time series ตัวระบุโดเมนเฉพาะ) หรือต้องการฟีเจอร์ด้านประสิทธิภาพพิเศษ

เมื่อการออกแบบตายตัว ทุกความต้องการใหม่จะกลายเป็นตัวเลือกที่ไม่ดี: บีบข้อมูลเป็น blob ข้อความ ผูกระบบแยกต่างหาก หรือรอให้ผู้จำหน่ายเพิ่มการรองรับ

Extensibility อธิบายแบบไม่ใช้ศัพท์เทคนิค

Postgres ผลักดันแนวคิดต่างออกไป: ฐานข้อมูลควรเป็น ขยายได้—หมายถึงคุณสามารถเพิ่มความสามารถใหม่ในรูปแบบที่ควบคุมได้ โดยไม่ทำลายความปลอดภัยและความถูกต้องที่คาดหวังจาก SQL

พูดง่ายๆ การขยายความสามารถเหมือนการเพิ่มหัวต่อที่รับรองกับเครื่องมือไฟฟ้า แทนที่จะต่อสายมอเตอร์เอง คุณสามารถสอนฐานข้อมูลให้ทำ “ทริก” ใหม่ๆ ในขณะที่ยังรักษาธุรกรรม สิทธิ์ และการปรับแผนคิวรีให้ทำงานร่วมกันอย่างสอดคล้อง

สิ่งนี้ส่งผลต่อระบบนิเวศขยายของสมัยใหม่อย่างไร

แนวคิดนี้เห็นได้ชัดในระบบนิเวศของ PostgreSQL ในปัจจุบัน (และหลายระบบที่ได้รับแรงบันดาลใจจาก Postgres) แทนที่จะรอฟีเจอร์แกนกลาง ทีมงานสามารถรับส่วนขยายที่ผ่านการตรวจสอบแล้วซึ่งผสานรวมอย่างเรียบร้อยกับ SQL และเครื่องมือการปฏิบัติการ

ตัวอย่างในภาพรวม ได้แก่:

• ชนิดข้อมูลกำหนดเอง: เก็บค่าที่ซับซ้อนขึ้น (เช่น จุดเชิงภูมิศาสตร์ ช่วงเวลา หรือโครงสร้างแบบ JSON) เป็นพลเมืองชั้นหนึ่ง
• ฟังก์ชันกำหนดโดยผู้ใช้: เพิ่มตรรกะโดเมนที่ใช้ในคิวรีและรายงานได้โดยตรง
• ตัวเลือกดัชนี: เลือกชนิดดัชนีต่างกันตามรูปแบบการเข้าถึง เพื่อให้คิวรี SQL เดิมทำงานเร็วยิ่งขึ้น

กุญแจคือ Postgres ถือว่า “การเปลี่ยนสิ่งที่ฐานข้อมูลทำได้” เป็นเป้าหมายการออกแบบ ไม่ใช่เรื่องเสริม และไอเดียนี้ยังมีอิทธิพลต่อการวิวัฒนาการของแพลตฟอร์มข้อมูลสมัยใหม่

ธุรกรรมและความขนาน: ให้ผลลัพธ์ถูกต้องเมื่อขยายตัว

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

ธุรกรรมรับประกันอะไรจริงๆ

ธุรกรรม คือกลุ่มการเปลี่ยนแปลงที่ต้องสำเร็จหรือไม่สำเร็จเป็นหน่วยเดียว

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

ในเชิงปฏิบัติ ธุรกรรมให้คุณ:

• ความสอดคล้องที่อธิบายให้มนุษย์เข้าใจได้: ฐานข้อมูลจะไม่ "ประมาณ" การเปลี่ยนแปลง
• การกู้คืน: ถ้ามีการชนกันระหว่างอัปเดต ระบบสามารถยกเลิกกลับสู่สถานะปลอดภัยได้

ความขนาน: ความยุ่งเหยิงในโลกจริงที่ฐานข้อมูลต้องจัดการ

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

หากไม่มีกฎระมัดระวัง ความขนานจะสร้างปัญหาเช่น:

• การอัปเดตสูญหาย: สองคนแก้ไขระเบียนเดียวกัน คนหนึ่งถูกเขียนทับ
• การอ่านข้อมูลสกปรก: เห็นข้อมูลที่ต่อมาถูกยกเลิก
• รายงานไม่สอดคล้อง: คิวรีเห็นส่วนผสมของสถานะ "ก่อน" และ "หลัง"

MVCC อธิบายแบบง่ายๆ

แนวทางที่มีอิทธิพลคือ MVCC (Multi-Version Concurrency Control) แนวคิดคือเก็บหลายเวอร์ชันของแถวเป็นช่วงเวลาสั้นๆ เพื่อให้ผู้อ่านเห็น snapshot ที่เสถียรในขณะที่ผู้เขียนทำการอัปเดต

ข้อดีใหญ่คือ การอ่านไม่ค่อยบล็อกการเขียน และผู้เขียนไม่ต้องรอเบื้องหลังการคิวรีที่รันนาน คุณยังคงได้ความถูกต้องแต่มีการรอคอยน้อยลง

ทำไมเรื่องนี้ถึงสำคัญในงาน SQL สมัยใหม่

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

ระบบแบบคอลัมน์: จุดเปลี่ยนด้านประสิทธิภาพเชิงวิเคราะห์

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

แถว vs คอลัมน์ (อุปมาง่ายๆ)

คิดถึงสเปรดชีต ระบบ row store เหมือนการเก็บแต่ละแถวเป็นแฟ้มหนึ่ง: เมื่อคุณต้องการ "ทั้งหมดเกี่ยวกับคำสั่ง #123" ก็หยิบแฟ้มนั้นขึ้นมาได้เลย ส่วน column store เหมือนการแยกแฟ้มโดยคอลัมน์: ลิ้นชักหนึ่งเก็บ "order_total" อีกลิ้นชักเก็บ "order_date" อีกลิ้นชักเก็บ "customer_region"

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

ทำไมงานวิเคราะห์ถึงชอบคอลัมน์

คิวรีเชิงวิเคราะห์มัก:

• สแกนส่วนใหญ่ของตาราง
• ใช้เพียงไม่กี่คอลัมน์
• รวมผล (SUM/AVG/COUNT) และกรองหนัก

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

การบีบอัดไม่ได้มีไว้เพื่อประหยัดพื้นที่อย่างเดียว

คอลัมน์มักมีค่าซ้ำกัน (ภูมิภาค สถานะ หมวดหมู่) ทำให้บีบอัดได้ดี—และการบีบอัดช่วยเพิ่มความเร็วเพราะระบบอ่านไบต์น้อยลง และบางครั้งสามารถประมวลผลข้อมูลบีบอัดได้เลย

การเปลี่ยนแปลงครั้งใหญ่

ระบบแบบคอลัมน์ช่วยเน้นการย้ายจากฐานข้อมูลที่เน้น OLTP ไปสู่เอนจินที่ออกแบบมาสำหรับการวิเคราะห์เป็นหลัก โดยการสแกน การบีบอัด และการรวมผลอย่างรวดเร็วกลายเป็นเป้าหมายหลักแทนที่จะเป็นเรื่องรอง

Vertica และ MPP เชิงวิเคราะห์: ขยาย SQL สำหรับคิวรีขนาดใหญ่

Vertica เป็นตัวอย่างที่ชัดเจนว่าหลักคิดเกี่ยวกับฐานข้อมูลเชิงวิเคราะห์ของ Stonebraker กลายเป็นผลิตภัณฑ์ที่ทีมงานสามารถรันในการผลิตได้อย่างไร มันนำบทเรียนจากการเก็บแบบคอลัมน์มาคู่กับการออกแบบแบบกระจายที่มุ่งแก้ปัญหาเฉพาะ: ตอบคิวรี SQL เชิงวิเคราะห์ขนาดใหญ่ให้เร็ว แม้ว่าปริมาณข้อมูลจะเกินเซิร์ฟเวอร์เครื่องเดียว

MPP หมายถึงอะไร (ภาษาง่ายๆ)

MPP ย่อมาจาก massively parallel processing วิธีคิดง่ายๆ คือ: หลายเครื่องร่วมกันทำคิวรี SQL เดียวพร้อมกัน

แทนที่เซิร์ฟเวอร์ฐานข้อมูลเครื่องเดียวจะอ่านข้อมูลทั้งหมดและทำ grouping กับ sorting เอง ข้อมูลจะแบ่งข้ามโหนด แต่ละโหนดประมวลผลชิ้นของตัวเองแบบขนาน แล้วระบบรวมผลย่อยเป็นคำตอบสุดท้าย

นี่คือเหตุผลที่คิวรีที่ใช้เวลานาทีเดียวบนเครื่องเดียวอาจลดเหลือวินาทีเมื่อกระจายข้ามคลัสเตอร์—ถ้าข้อมูลกระจายดีและคิวรีสามารถขนานได้

สิ่งที่มันทำได้จริง

ระบบวิเคราะห์สไตล์ Vertica เหมาะเมื่อคุณมีแถวจำนวนมากและต้องการสแกน กรอง และรวมผลอย่างมีประสิทธิภาพ กรณีใช้งานทั่วไปได้แก่:

• แดชบอร์ดที่อ่านตาราง fact ขนาดใหญ่ (การวิเคราะห์ผลิตภัณฑ์ ประสิทธิภาพการตลาด เมตริกเชิงปฏิบัติการ)
• การรายงานตามตารางเวลาและการวิเคราะห์ ad-hoc ด้วย SQL
• การรวมผลขนาดใหญ่ (cohorts รายวัน funnels top-N rollups ตามมิติหลายค่า)

ข้อแลกเปลี่ยนเทียบกับฐานข้อมูลเชิงธุรกรรม

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

ข้อแลกเปลี่ยนที่พบบ่อยได้แก่:

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

แนวคิดสำคัญคือการมุ่งจุดประสงค์: Vertica และระบบคล้ายกันได้ความเร็วโดยจูนการจัดเก็บ การบีบอัด และการประมวลผลแบบขนานสำหรับงานวิเคราะห์—แลกด้วยข้อจำกัดที่ระบบธุรกรรมออกแบบมาเพื่อหลีกเลี่ยง

นวัตกรรมการประมวลผลคิวรีที่ทำให้การวิเคราะห์เร็วขึ้น

ฐานข้อมูลสามารถ “เก็บและคิวรี” ข้อมูลได้แต่ยังรู้สึกช้าเมื่อทำการวิเคราะห์ ความแตกต่างไม่ใช่แค่ SQL ที่คุณเขียน แต่เป็นวิธีที่เอนจิน ประมวลผล มัน: อ่านเพจ ย้ายข้อมูลผ่าน CPU ใช้หน่วยความจำ และลดงานที่เสียเปล่า

โครงการเชิงวิเคราะห์ของ Stonebraker ผลักดันแนวคิดว่า ประสิทธิภาพคิวรีเป็นปัญหาการประมวลผลเท่ากับปัญหาการจัดเก็บ ความคิดนี้ช่วยผลักดันทีมจากการปรับจูนค้นหาแถวเดียวไปสู่การปรับจูนสแกนขนาดใหญ่ join และ aggregation บนแถวล้านๆ

การประมวลผลแบบเวกเตอร์ (ทำงานเป็นแบตช์ ไม่ใช่ทีละแถว)

เอนจินเก่าบางตัวประมวลผลคิวรีแบบ "tuple-at-a-time" (ทีละแถว) ซึ่งสร้างการเรียกฟังก์ชันและ overhead มาก การประมวลผลแบบเวกเตอร์กลับโมเดลนั้น: เอนจินประมวลผล แบตช์ (เวกเตอร์) ของค่าในลูปที่แน่นหนา

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

การออกแบบเพื่อประสิทธิภาพหน่วยความจำสำหรับการวิเคราะห์

เอนจินวิเคราะห์ที่เร็วจะใส่ใจกับการใช้ CPU และ cache มากเป็นพิเศษ นวัตกรรมการประมวลผลมักมุ่งไปที่:

• หลีกเลี่ยงการสร้างผลกลางที่ไม่จำเป็น (อย่าสร้างตารางขนาดใหญ่ถ้าสามารถ stream ผลต่อไปได้)
• ทำงานบนข้อมูลที่บีบอัดเมื่อเป็นไปได้ (แบนด์วิดท์หน่วยความจำน้อยลง ไบต์ที่ย้านน้อยลง)
• เก็บข้อมูลร้อนไว้ใน cache (การจัดวางและแบตช์ที่สอดคล้องกับวิธีที่ CPU เข้าถึงหน่วยความจำ)

ไอเดียเหล่านี้สำคัญเพราะคิวรีเชิงวิเคราะห์มักถูกจำกัดด้วยแบนด์วิดท์หน่วยความจำและ cache miss ไม่ใช่ด้วยความเร็วดิสก์บริสุทธิ์

สิ่งที่คุณจะพบวันนี้

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

แม้เมื่อผู้ขายโฆษณาฟีเจอร์อย่าง "autoscaling" หรือ "การแยก storage กับ compute" ความเร็วที่คุณรู้สึกในวันต่อวันยังพึ่งพาการเลือกโมเดลการประมวลผลเหล่านี้อย่างมาก

ถ้าคุณกำลังประเมินแพลตฟอร์ม ถามไม่เพียงว่า เก็บอะไร แต่ถามว่า มันรัน join และ aggregation อย่างไรใต้ฝากม่าน—และว่าโมเดลการประมวลผลถูกออกแบบมาสำหรับงานวิเคราะห์หรือสำหรับงานธุรกรรม

ระบบสตรีมมิง: จากความคิดแบบแบตช์สู่ข้อมูลเรียลไทม์

ข้อมูลสตรีมคือข้อมูลที่มาถึงอย่างต่อเนื่องเป็นลำดับของเหตุการณ์—คิดถึง "เกิดเหตุการณ์ใหม่" ข้อความ การรูดบัตรเครดิต การอ่านเซนเซอร์ การคลิกบนหน้าผลิตภัณฑ์ การสแกนพัสดุ หรือบรรทัดล็อกแต่ละบรรทัด: แต่ละรายการมาถึงแบบเรียลไทม์และต่อเนื่อง

ทำไมฐานข้อมูลแบบแบตช์รู้สึกช้าเมื่อใช้กับงานสด

ฐานข้อมูลและ pipeline แบบแบตช์เหมาะเมื่อคุณรอได้: โหลดข้อมูลของเมื่อวาน รันรายงาน เผยแพร่แดชบอร์ด แต่ความต้องการแบบเรียลไทม์ไม่รอการรันงานรายชั่วโมง

ถ้าคุณประมวลผลข้อมูลเป็นแบตช์เท่านั้น มักเจอปัญหา:

• เมตริกล้าหลัง (ตัวเลขตามหลังสิ่งที่เกิดขึ้น)
• การแจ้งเตือนล่าช้า (ทราบปัญหาหลังเกิดความเสียหาย)
• การแก้ปัญหาที่เชื่องช้า (poll ตาราง รันคิวรีซ้ำ)

ระบบสตรีมมิงถูกออกแบบบนแนวคิดว่าการคำนวณทำงานต่อเนื่องเมื่อตัวเหตุการณ์มาถึง

แนวคิดหลัก: คิวรีต่อเนื่องและ windows

คิวรีต่อเนื่อง เหมือนคิวรี SQL ที่ไม่เคย "จบ" มันอัปเดตผลเมื่อเหตุการณ์ใหม่มาถึงเรื่อยๆ

เพราะสตรีมไม่มีที่สิ้นสุด ระบบสตรีมใช้ windows เพื่อจัดการการคำนวณ หน้าต่างคือช่วงเวลา或จำนวนเหตุการณ์ เช่น "5 นาทีล่าสุด" "ทุกนาที" หรือ "1,000 เหตุการณ์ล่าสุด" ซึ่งช่วยให้คำนวณการนับ ค่าเฉลี่ย หรือ top-N แบบโรลลิงโดยไม่ต้องประมวลผลซ้ำทั้งหมด

ตัวอย่างเชิงธุรกิจที่ได้ประโยชน์ทันที

การสตรีมแบบเรียลไทม์มีค่าสูงเมื่อเวลาเป็นสิ่งสำคัญ:

• การตรวจจับการทุจริต: แจ้งเตือนการใช้จ่ายผิดปกติภายในไม่กี่วินาที
• การแจ้งเตือนเชิงปฏิบัติการ: ตรวจพบการพุ่งของข้อผิดพลาดทันทีที่เริ่มเกิด
• เมตริกสดของผลิตภัณฑ์: เห็นการสมัคร แปลง หรือการเปลี่ยนแปลงสต็อกทันที
• การมองเห็นโลจิสติกส์: อัปเดตเวลาคาดการณ์การส่งของจากการสแกนต่อเนื่อง

สถาปัตยกรรมที่ขับเคลื่อนโดยภาระงาน: ใช้เอนจินที่เหมาะกับงาน

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

ทำไมทีมจึงใช้หลายระบบ

สแต็กสมัยใหม่ส่วนใหญ่ใช้มากกว่าหนึ่งระบบเพราะธุรกิจต้องการคำตอบหลายแบบ:

• ฐานข้อมูล OLTP (ฐานข้อมูลแอป): แทรก/อัปเดตเร็ว ความถูกต้องเข้มงวด ผู้ใช้พร้อมกันจำนวนมาก
• เวิร์เฮาส์ / ฐานข้อมูลวิเคราะห์: การอ่านเร็วบนข้อมูลจำนวนมาก การรวมผลหนัก การสแกนยาว
• แคช / key-value store: การอ่านเร็วมากสำหรับข้อมูล "ฮอต" (session counters feature flags)
• การประมวลผลสตรีม + log: จัดการเหตุการณ์ต่อเนื่อง latency ต่ำ pipeline เรียลไทม์

นั่นคือสาเหตุ "ไซส์เดียวไม่ได้เหมาะกับทุกคน" ในทางปฏิบัติ: คุณเลือกเอนจินที่ตรงกับรูปแบบงาน

แนวทางตัดสินใจอย่างง่าย

ใช้ตัวกรองเร็วๆ นี้เมื่อเลือก (หรืออธิบายเหตุผลในการเพิ่ม) ระบบใหม่:

• ถ้าคุณต้องการ การอ่าน/เขียนเล็กจำนวนมากพร้อมธุรกรรม (คำสั่ง สโปรไฟล์ผู้ใช้): เริ่มด้วย OLTP DB
• ถ้าคุณต้องการ คิวรีและการรวมผลขนาดใหญ่ (รายได้รายสัปดาห์ การวิเคราะห์ cohort): เพิ่มเวิร์เฮาส์เชิงวิเคราะห์
• ถ้าคุณต้องการ ตอบสนองภายในวินาทีกับการค้นหาซ้ำ: เพิ่มแคช
• ถ้าคุณต้องการ ตอบสนองแบบเรียลไทม์ต่อเหตุการณ์ (กฎตรวจจับการทุจริต แดชบอร์ดสด): เพิ่มสตรีมมิง

หลีกเลี่ยงการแพร่หลายของเครื่องมือ

การมีหลายเอนจินอาจเป็นเรื่องดี แต่เมื่อแต่ละเครื่องมือมีภาระงานชัดเจน เครื่องมือใหม่ควรได้รับที่อยู่โดยลดค่าใช้จ่าย เวลาแฝง หรือความเสี่ยง—ไม่ใช่เพราะความใหม่ชอบ แต่ละระบบควรมีความเป็นเจ้าของเชิงปฏิบัติการที่ชัดเจน และเก็บเครื่องมือที่ไม่มีวัตถุประสงค์ชัดเจนออกไป

ไอเดียเหล่านี้ปรากฏในสถาปัตยกรรมข้อมูลสมัยใหม่อย่างไร

เส้นใยงานวิจัยของ Stonebraker—พื้นฐานเชิงสัมพันธ์ ความสามารถขยาย การเก็บแบบคอลัมน์ การประมวลผลแบบ MPP และแนวคิด "เครื่องมือที่ใช่สำหรับงาน"—ปรากฏในรูปแบบมาตรฐานของแพลตฟอร์มข้อมูลสมัยใหม่

รูปแบบสถาปัตยกรรมที่คุ้นเคย (และทำไมมันเป็นแบบนี้)

เวิร์เฮาส์ สะท้อนงานหลายสิบปีเรื่องการปรับแผนคิวรี SQL การเก็บแบบคอลัมน์ และการประมวลผลแบบขนาน เมื่อคุณเห็นแดชบอร์ดเร็วบนตารางขนาดใหญ่ มักเป็นการผสมระหว่างรูปแบบไฟล์คอลัมน์และการประมวลผลแบบเวกเตอร์และการสเกลแบบ MPP

Lakehouse ยืมแนวคิดจากเวิร์เฮาส์ (สกีมา สถิติ แคช การปรับแผนคิวรีตามต้นทุน) แต่วางไว้บนรูปแบบไฟล์เปิดและ object storage การเปลี่ยนแปลงว่า "storage ถูก compute ยืดหยุ่น" เป็นเรื่องใหม่; แต่การคิดเรื่องคิวรีและธุรกรรมข้างใต้ไม่ใช่เรื่องใหม่

ระบบวิเคราะห์ MPP (shared-nothing clusters) เป็นทายาทตรงของงานวิจัยที่พิสูจน์ว่าคุณสามารถสเกล SQL โดยการแบ่งพาร์ติชันข้อมูล ย้ายการคำนวณไปยังข้อมูล และจัดการการย้ายข้อมูลอย่างระมัดระวังในระหว่างการ join และ aggregation

SQL อยู่ตรงไหนวันนี้

SQL กลายเป็นอินเตอร์เฟซที่ใช้ร่วมกันระหว่างเวิร์เฮาส์ ระบบ MPP และแม้แต่ชั้นคิวรีบน "lake" ทีมพึ่งพามันเป็น:

• สัญญาที่มั่นคงสำหรับเครื่องมือ BI และนักวิเคราะห์
• เลเยอร์พกพาเมื่อเปลี่ยนเอนจิน
• พื้นที่กำกับดูแล (views สิทธิ์ การเข้าถึงที่ถูกตรวจสอบ)

แม้ว่าการประมวลผลจะเกิดขึ้นในเอนจินต่างกัน (แบตช์ โต้ตอบ สตรีม) SQL มักยังคงเป็นภาษาหน้าตาผู้ใช้

การวางแบบข้อมูลและการกำกับดูแล: สกีมายังคงสำคัญ

การจัดเก็บยืดหยุ่นไม่ได้ยกเลิกความจำเป็นของโครงสร้าง การมีสกีมาที่ชัดเจน ความหมายที่มีเอกสาร และการวิวัฒนาการที่ควบคุมได้ ลดการเสียหายด้านล่างได้มาก

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

เช็คลิสต์ไม่ฮิปสำหรับการเลือกแนวทาง

เมื่อประเมินแพลตฟอร์ม ให้ถาม:

1. ความเหมาะสมกับภาระงาน: เป็น BI dashboards, สำรวจ ad-hoc, สร้าง feature ML, หรืองานปฏิบัติการ?
2. ความต้องการ latency: วินาที นาที หรือชั่วโมง? ต้องความสดแบบสตรีมไหม?
3. รูปร่างข้อมูล: ส่วนใหญ่เป็น event logs กว้างๆ (เหมาะกับคอลัมน์) หรือการค้นหาจุดหลายครั้ง (มักเหมาะที่อื่น)?
4. ความขนาน: มีผู้ใช้/คิวรีพร้อมกันมากแค่ไหน และคาดเดาได้แค่ไหน?
5. ความต้องการความสอดคล้อง: ต้องการธุรกรรมเข้มงวดไหม หรือ eventual consistency พอรับได้?
6. ความเป็นจริงเชิงปฏิบัติการ: ใครจะดูแล มีกี่ทักษะ และความล้มเหลวตอนตีสองจะเป็นอย่างไร?

ถ้าผู้ขายอธิบายผลิตภัณฑ์ของตนตามพื้นฐานเหล่านี้เป็นภาษาง่ายๆ ไม่ได้ นวัตกรรมอาจเป็นแค่การบรรจุใหม่

ข้อสรุปสำคัญสำหรับทีมที่สร้างหรือซื้อแพลตฟอร์มข้อมูล

เส้นทางของ Stonebraker ง่าย: ฐานข้อมูลทำงานได้ดีที่สุดเมื่อออกแบบมาสำหรับงานเฉพาะ—และเมื่อพวกมันสามารถวิวัฒน์ตามงานนั้นได้

1) จับคู่ระบบกับภาระงาน (อย่าคาดหวังว่าเอนจินเดียวจะชนะทุกอย่าง)

ก่อนเปรียบเทียบฟีเจอร์ เขียนสิ่งที่คุณต้องทำจริงๆ ลงไป:

• การวิเคราะห์: การสแกนยาว การรวมผลขนาดใหญ่ การอ่านจำนวนมาก
• ธุรกรรม: การอัปเดตเล็กจำนวนมาก ความถูกต้องเข้มงวด การตอบสนองเร็ว
• งานผสม: ทั้งสอง แต่มักต้อง tuning และลำดับความสำคัญชัดเจน
• ฟีดเรียลไทม์: การรับข้อมูลต่อเนื่องและการคำนวณเชิงเพิ่ม

กฎที่มีประโยชน์: ถ้าคุณบรรยายภาระงานไม่ได้ในไม่กี่ประโยค (รูปแบบคิวรี ขนาดข้อมูล ความต้องการ latency ความขนาน) คุณจะเลือกสินค้าตามคำพูดฮิปๆ

2) ออกแบบเพื่อการเปลี่ยนแปลง ไม่ใช่เฉพาะสกีมาในวันนี้

ทีมมักประเมินต่ำว่าความต้องการเปลี่ยนบ่อยแค่ไหน: ชนิดข้อมูลใหม่ เมตริกใหม่ กฎกำกับดูแลใหม่ ผู้บริโภคใหม่

เลือกแพลตฟอร์มและโมเดลข้อมูลที่ทำให้การเปลี่ยนแปลงเป็นเรื่องปกติ ไม่ใช่ความเสี่ยง:

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

3) ความถูกต้องเป็นฟีเจอร์ของผลิตภัณฑ์

คำตอบที่เร็วมีค่าก็ต่อเมื่อเป็นคำตอบที่ ถูกต้อง เมื่อประเมินตัวเลือก ถามว่าระบบจัดการอย่างไรกับ:

• การเขียนพร้อมกัน (จะเกิดอะไรเมื่อสองคน/กระบวนการอัปเดตระเบียนเดียวกัน?)
• การแยกส่วนและความสอดคล้อง (คุณได้การันตีแบบไหน และต้องเสียอะไรบ้างเพื่อให้ได้มัน?)
• โหมดล้มเหลวเชิงปฏิบัติการ (รีสตาร์ท ขาดบางส่วน การ backfill)

4) เช็คลิสต์การประเมินเชิงปฏิบัติสำหรับคนทั่วไป

รัน “พิสูจน์ของจริงด้วยข้อมูลของคุณ” ขนาดเล็ก ไม่ใช่แค่สาธิต:

• ทดลอง 3–5 คิวรีตัวแทน แล้ววัดเวลาและค่าใช้จ่าย
• ทดสอบความขนานสูงสุด (สไปก์เช่นเช้าวันจันทร์)
• ยืนยันความสดของข้อมูล ขั้นตอนการกู้คืน และใครจะปฏิบัติการในระดับวันต่อวัน

5) เปลี่ยนการตัดสินใจสถาปัตยกรรมเป็นซอฟต์แวร์ที่ส่งมอบได้

คำแนะนำฐานข้อมูลมากมักหยุดที่ "เลือกเอนจินที่ใช่" แต่ทีมยังต้องส่งมอบแอปและเครื่องมือภายในรอบเอนจินนั้น: แผง admin, แดชบอร์ดเมตริก, บริการ ingestion และ workflow หลังบ้าน

ถ้าคุณอยากทำโปรโตไทป์โดยไม่ต้องคิดระบบใหม่ทั้งชุด แพลตฟอร์มแบบ vibe-coding อย่าง Koder.ai สามารถช่วยสปินแอปเว็บ (React), บริการ backend (Go + PostgreSQL) และแม้แต่ไคลเอนต์มือถือ (Flutter) จาก workflow แบบแชทได้ นั่นมีประโยชน์เมื่อคุณวนรอบการออกแบบสกีมา สร้าง "data product" ภายในขนาดเล็ก หรือตรวจสอบพฤติกรรมภาระงานจริงก่อนตัดสินใจโครงสร้างพื้นฐานระยะยาว

อ่านต่อ (เพื่อสร้างสัญชาตญาณ)

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