Distributed SQL: ควรใช้ Spanner, CockroachDB หรือ Yugabyte เมื่อใด?

ความหมายของ “Distributed SQL” (โดยไม่ต้องโม้)

“Distributed SQL” คือฐานข้อมูลที่ให้ความรู้สึกเหมือนฐานข้อมูลเชิงสัมพันธ์ดั้งเดิม—ตาราง แถว join ทรานแซกชัน และ SQL—แต่ถูกออกแบบให้รันเป็นคลัสเตอร์ข้ามเครื่องหลายเครื่อง (และบ่อยครั้งข้ามภูมิภาค) ขณะที่ยังทำงานเหมือน ฐานข้อมูลเชิงตรรกะเดียว

การผสมผสานนี้สำคัญเพราะพยายามให้บริการสามอย่างพร้อมกัน:

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

ระหว่าง RDBMS แบบคลาสสิกและ NoSQL

RDBMS แบบคลาสสิก (เช่น PostgreSQL หรือ MySQL) มักจะจัดการได้ง่ายที่สุดเมื่อทุกอย่างอยู่บนโหนดหลักเดียว คุณสามารถสเกลการอ่านด้วยรีพลิก้าได้ แต่การสเกลการเขียนและการทนต่อการล้มของภูมิภาคมักต้องสถาปัตยกรรมเพิ่ม (การชาร์ด การสลับด้วยมือ และตรรกะแอปพลิเคชันที่ระมัดระวัง)

ระบบ NoSQL หลายตัวเลือกแนวทางตรงข้าม: ให้ความสำคัญกับการสเกลและความพร้อมใช้งานก่อน บางครั้งด้วยการผ่อนปรนความสอดคล้องหรือเสนอโมเดลง่ายกว่าของคิวรี

Distributed SQL มุ่งทางสายกลาง: คงแบบจำลองเชิงสัมพันธ์และทรานแซกชัน ACID แต่กระจายข้อมูลโดยอัตโนมัติเพื่อรองรับการเติบโตและความล้มเหลว

ปัญหาที่พยายามแก้

ฐานข้อมูล Distributed SQL ถูกสร้างมาเพื่อปัญหาเช่น:

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

นี่จึงเป็นเหตุผลที่ผลิตภัณฑ์อย่าง Google Spanner, CockroachDB, และ YugabyteDB มักถูกพิจารณาสำหรับการปรับใช้หลายภูมิภาคและบริการที่ต้องออนไลน์ตลอดเวลา

ตั้งความคาดหวัง (มันไม่ใช่ค่าเริ่มต้น)

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

หากเวิร์กโหลดของคุณพอดีกับฐานข้อมูลเดียวที่จัดการอย่างดีพร้อมการจำลองอย่างเรียบง่าย RDBMS แบบดั้งเดิมอาจง่ายและถูกกว่า Distributed SQL จะคุ้มค่าก็ต่อเมื่อทางเลือกคือการชาร์ดเอง สลับซับซ้อน หรือความต้องการทางธุรกิจบังคับความสอดคล้องและเวลาพร้อมใช้งานข้ามภูมิภาค

หลักการทำงานเบื้องหลังของ Distributed SQL

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

การจำลอง + คอนเซนซัส: โหนดตกลงกันอย่างไร

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

เพื่อป้องกันไม่ให้รีพลิก้าคลาดเคลื่อน ระบบ Distributed SQL ใช้โปรโตคอล คอนเซนซัส—โดยทั่วไปคือ Raft (CockroachDB, YugabyteDB) หรือ Paxos (Spanner) กล่าวโดยสรุป คอนเซนซัสหมายถึง:

• รีพลิก้าตัวหนึ่งทำหน้าที่เป็น “ผู้นำ” สำหรับกลุ่มรีพลิก้า
• การเขียนจะไปยังผู้นำ
• ผู้นำยืนยันการเขียนก็ต่อเมื่อเสียงข้างมากของรีพลิก้ายอมรับแล้ว

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

การชาร์ด/พาร์ติชัน: ข้อมูลอยู่ที่ไหน

ไม่มีเครื่องใดเครื่องเดียวเก็บทุกอย่างได้ ดังนั้นตารางจะถูกแยกเป็นชิ้นเล็ก ๆ ที่เรียกว่า ชาร์ด/พาร์ติชัน (Spanner เรียก splits; CockroachDB เรียก ranges; YugabyteDB เรียก tablets)

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

ทรานแซกชันข้ามโหนด (และเหตุใดจึงเพิ่มแล็ตเทนซี)

ในฐานข้อมูลโหนดเดียว ทรานแซกชันมักคอมมิตโดยการเขียนดิสก์ภายในเครื่อง แต่ใน Distributed SQL ทรานแซกชันอาจแตะหลายพาร์ติชัน—อาจอยู่บนโหนดต่างกัน

การคอมมิตอย่างปลอดภัยมักต้องการการประสานเพิ่ม:

• การล็อกหรือการตรวจสอบข้อมูลบนพาร์ติชันที่เกี่ยวข้อง
• การจำลองการเขียนผ่านคอนเซนซัส (การยืนยันของเสียงข้างมาก)
• สรุปการตัดสินใจคอมมิตเพื่อให้ผู้เข้าร่วมทั้งหมดเห็นตรงกัน

ขั้นตอนเหล่านี้เพิ่ม รอบเดินทางของเครือข่าย ซึ่งเป็นสาเหตุที่ทรานแซกชันกระจายมักเพิ่มแล็ตเทนซี—โดยเฉพาะเมื่อข้อมูลข้ามภูมิภาค

พฤติกรรมข้ามภูมิภาค: การอ่าน/เขียนตามเขตพื้นที่

เมื่อปรับใช้ข้ามภูมิภาค ระบบพยายามให้ปฏิบัติการ "ใกล้" ผู้ใช้:

• การอ่านตามเขตพื้นที่ อาจให้บริการจากรีพลิก้าที่ใกล้เมื่อปลอดภัย
• การเขียนตามเขตพื้นที่ อาจกำหนดเส้นทางไปยังผู้นำในภูมิภาคที่เลือกหรือวางผู้นำใกล้ผู้เขียนหลัก

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

เมื่อใดที่คุณจำเป็นจริง ๆ (และเมื่อไม่จำเป็น)

ก่อนใช้ Distributed SQL ให้ตรวจสอบความต้องการพื้นฐานของคุณ หากคุณมีภูมิภาคหลักเดียว โหลดคาดการณ์ได้ และทีมปฏิบัติการเล็ก ฐานข้อมูลเชิงสัมพันธ์แบบปกติ (หรือ Postgres/MySQL แบบจัดการ) มักเป็นวิธีที่ง่ายที่สุดในการส่งฟีเจอร์เร็ว คุณมักยืดการตั้งค่าในภูมิภาคเดียวได้ไกลด้วยรีพลิก้าแคชชิ่ง และการออกแบบสคีมา/ดัชนีที่รอบคอบ

ทริกเกอร์ชัดเจน: เมื่อ Distributed SQL คุ้มค่า

Distributed SQL ควรถูกพิจารณาเมื่อหนึ่ง (หรือมากกว่า) ข้อด้านล่างเป็นจริง:

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

สิ่งที่มักไม่ควรทำ

ระบบกระจายเพิ่มความซับซ้อนและค่าใช้จ่าย ระมัดระวังถ้า:

• ทีมคุณเล็ก และไม่มีเวลาศึกษาโหมดความล้มเหลวและรูปแบบการปฏิบัติการใหม่
• ทราฟิกต่ำหรือไม่สม่ำเสมอ และคุณไม่น่าจะโตจนเกินฐานข้อมูลภูมิภาคเดียวเร็วๆ นี้
• งบประมาณความหน่วงต่ำมาก สำหรับการเขียนแบบคีย์เดียวและทนไม่ได้กับค่าใช้จ่ายการประสานงานที่มาจากความสอดคล้องแบบเข้มงวด
• เวิร์กโหลดเน้นวิเคราะห์หนัก (สแกนขนาดใหญ่ รายงานซับซ้อน) คุณอาจแยกงาน OLTP ออกจากงานวิเคราะห์ดีกว่า

เช็คลิสต์การตัดสินใจด่วน

ถ้าคุณตอบ "ใช่" สองข้อหรือมากกว่า Distributed SQL น่าจะควรค่าแก่การประเมิน:

• คุณต้องการ หลายภูมิภาค กับข้อมูลที่สอดคล้องหรือไม่?
• คุณต้องการ การสลับอัตโนมัติ ข้ามโซน/ภูมิภาคหรือไม่?
• การสเกลกลายเป็นปัญหาซ้ำซ้อนหรือไม่?
• การชาร์ดจะเพิ่มภาระวิศวกรรมมากกว่าฐานข้อมูลเองหรือไม่?
• คุณต้องบังคับ การวางข้อมูลตามภูมิศาสตร์ ด้วยโมเดลการปฏิบัติการเดียวหรือไม่?

ความสอดคล้อง ความพร้อมใช้งาน และแล็ตเทนซี: การแลกเปลี่ยนหลัก

Distributed SQL ฟังดูเหมือนได้ทุกอย่างพร้อมกัน แต่ระบบจริงบังคับให้ต้องเลือก—โดยเฉพาะเมื่อภูมิภาคไม่สามารถคุยกันได้อย่างเชื่อถือได้

CAP อธิบายสำหรับการตัดสินใจผลิตภัณฑ์

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

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

ระบบ Distributed SQL มักถูกสร้างให้เน้น ความสอดคล้อง สำหรับทรานแซกชัน นั่นมักเป็นสิ่งที่ทีมต้องการ—จนกว่าจะเกิด partition แล้วบางการดำเนินการต้องรอหรือล้มเหลว

ความสอดคล้องแบบเข้มงวด (และทำไมเงินและสต็อกถึงสำคัญ)

ความสอดคล้องแบบเข้มงวด หมายความว่าเมื่อทรานแซกชันคอมมิต การอ่านต่อไปจะคืนค่านั้นเสมอ—ไม่มี "มันทำงานในภูมิภาคหนึ่งแต่ไม่ทำในอีกภูมิภาค" นี่สำคัญสำหรับ:

• การชำระเงินและยอดเงิน (ป้องกันการใช้จ่ายซ้ำหรือยอดผิดพลาด)
• สต็อก/การจอง (ป้องกันการขายเกิน)

ถ้าสัญญาผลิตภัณฑ์คือ "เมื่อเรายืนยัน มันคือของจริง" ความสอดคล้องแบบเข้มงวดเป็นฟีเจอร์ ไม่ใช่ของฟุ่มเฟือย

อ่านแล้วเห็นการเขียนของตัวเองและการแยกการทำงานในแอปจริง

สองพฤติกรรมที่ใช้งานได้จริงสำคัญ:

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

ค่าแล็ตเทนซีจากคอนเซนซัสข้ามภูมิภาค

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

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

Spanner vs CockroachDB vs YugabyteDB: ภาพรวมเชิงปฏิบัติ

Google Spanner เป็นฐานข้อมูล Distributed SQL ที่มักให้บริการแบบจัดการบน Google Cloud ถูกออกแบบสำหรับการปรับใช้หลายภูมิภาคเมื่อคุณต้องการฐานข้อมูลเชิงตรรกะเดียวที่สำเนาข้อมูลข้ามโหนดและภูมิภาค Spanner รองรับสองไดอะล็อก SQL—GoogleSQL (ไดอะล็อกเนทีฟ) และไดอะล็อกที่เข้ากันได้กับ PostgreSQL—ดังนั้นความสามารถถ่ายโอนจะแตกต่างตามที่คุณเลือกและฟีเจอร์ที่แอปพึ่งพา

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

YugabyteDB เป็นฐานข้อมูลกระจายที่มี API SQL ที่เข้ากันได้กับ PostgreSQL (YSQL) และ API ที่เข้ากันกับ Cassandra (YCQL) เช่นเดียวกับ CockroachDB มันมักถูกประเมินโดยทีมที่ต้องการ ergonomics การพัฒนาเหมือน Postgres ขณะสเกลข้ามโหนด มีทั้งการปรับใช้ self-hosted และบริการจัดการ (YugabyteDB Managed) โดยการปรับใช้ทั่วไปครอบคลุมตั้งแต่ HA ภายในภูมิภาคเดียวจนถึงการตั้งค่าข้ามภูมิภาค

บริการจัดการ vs โฮสต์เอง: อะไรเปลี่ยนไปบ้าง

บริการจัดการมักลดงานปฏิบัติการ (อัปเกรด แบ็คอัพ การเชื่อมต่อมอนิเตอร์) ขณะที่การโฮสต์เองให้การควบคุมเครือข่าย ชนิดอินสแตนซ์ และตำแหน่งข้อมูลมากกว่า Spanner มักบริโภคเป็นบริการจัดการบน GCP; CockroachDB และ YugabyteDB มักเห็นทั้งแบบจัดการและโฮสต์เอง รวมถึง multi-cloud และ on-prem ตัวเลือก