เรียนรู้ว่า Distributed SQL คืออะไร ความแตกต่างระหว่าง Spanner, CockroachDB และ YugabyteDB รวมถึงกรณีใช้งานจริงที่ควรใช้ฐานข้อมูล SQL กระจายหลายภูมิภาคพร้อมความสอดคล้องแบบเข้มงวด

“Distributed SQL” คือฐานข้อมูลที่ให้ความรู้สึกเหมือนฐานข้อมูลเชิงสัมพันธ์ดั้งเดิม—ตาราง แถว join ทรานแซกชัน และ SQL—แต่ถูกออกแบบให้รันเป็นคลัสเตอร์ข้ามเครื่องหลายเครื่อง (และบ่อยครั้งข้ามภูมิภาค) ขณะที่ยังทำงานเหมือน ฐานข้อมูลเชิงตรรกะเดียว
การผสมผสานนี้สำคัญเพราะพยายามให้บริการสามอย่างพร้อมกัน:
RDBMS แบบคลาสสิก (เช่น PostgreSQL หรือ MySQL) มักจะจัดการได้ง่ายที่สุดเมื่อทุกอย่างอยู่บนโหนดหลักเดียว คุณสามารถสเกลการอ่านด้วยรีพลิก้าได้ แต่การสเกลการเขียนและการทนต่อการล้มของภูมิภาคมักต้องสถาปัตยกรรมเพิ่ม (การชาร์ด การสลับด้วยมือ และตรรกะแอปพลิเคชันที่ระมัดระวัง)
ระบบ NoSQL หลายตัวเลือกแนวทางตรงข้าม: ให้ความสำคัญกับการสเกลและความพร้อมใช้งานก่อน บางครั้งด้วยการผ่อนปรนความสอดคล้องหรือเสนอโมเดลง่ายกว่าของคิวรี
Distributed SQL มุ่งทางสายกลาง: คงแบบจำลองเชิงสัมพันธ์และทรานแซกชัน ACID แต่กระจายข้อมูลโดยอัตโนมัติเพื่อรองรับการเติบโตและความล้มเหลว
ฐานข้อมูล Distributed SQL ถูกสร้างมาเพื่อปัญหาเช่น:
นี่จึงเป็นเหตุผลที่ผลิตภัณฑ์อย่าง Google Spanner, CockroachDB, และ YugabyteDB มักถูกพิจารณาสำหรับการปรับใช้หลายภูมิภาคและบริการที่ต้องออนไลน์ตลอดเวลา
Distributed SQL ไม่ใช่คำตอบที่ "ดีกว่า" โดยอัตโนมัติ คุณยอมรับชิ้นส่วนที่เคลื่อนไหวมากขึ้นและความเป็นจริงด้านประสิทธิภาพที่ต่างออกไป (การส่งผ่านเครือข่าย การคอนเซนซัส ความหน่วงข้ามภูมิภาค) เพื่อแลกกับความทนทานและการสเกล
หากเวิร์กโหลดของคุณพอดีกับฐานข้อมูลเดียวที่จัดการอย่างดีพร้อมการจำลองอย่างเรียบง่าย RDBMS แบบดั้งเดิมอาจง่ายและถูกกว่า 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 น่าจะควรค่าแก่การประเมิน:
Distributed SQL ฟังดูเหมือนได้ทุกอย่างพร้อมกัน แต่ระบบจริงบังคับให้ต้องเลือก—โดยเฉพาะเมื่อภูมิภาคไม่สามารถคุยกันได้อย่างเชื่อถือได้
คิดว่าการแบ่งแยกเครือข่ายเป็น "ลิงก์ระหว่างภูมิภาคมีปัญหาหรือหลุด" ในช่วงเวลานั้น ฐานข้อมูลสามารถเน้นได้:
ระบบ Distributed SQL มักถูกสร้างให้เน้น ความสอดคล้อง สำหรับทรานแซกชัน นั่นมักเป็นสิ่งที่ทีมต้องการ—จนกว่าจะเกิด partition แล้วบางการดำเนินการต้องรอหรือล้มเหลว
ความสอดคล้องแบบเข้มงวด หมายความว่าเมื่อทรานแซกชันคอมมิต การอ่านต่อไปจะคืนค่านั้นเสมอ—ไม่มี "มันทำงานในภูมิภาคหนึ่งแต่ไม่ทำในอีกภูมิภาค" นี่สำคัญสำหรับ:
ถ้าสัญญาผลิตภัณฑ์คือ "เมื่อเรายืนยัน มันคือของจริง" ความสอดคล้องแบบเข้มงวดเป็นฟีเจอร์ ไม่ใช่ของฟุ่มเฟือย
สองพฤติกรรมที่ใช้งานได้จริงสำคัญ:
ความสอดคล้องแบบเข้มงวดข้ามภูมิภาคมักต้องการ คอนเซนซัส (รีพลิก้าหลายตัวต้องยอมรับก่อนคอมมิต) หากรีพลิก้ากระจายข้ามทวีป ความเร็วของแสงกลายเป็นข้อจำกัด: การเขียนข้ามภูมิภาคมักเพิ่มสิบถึงร้อยมิลลิวินาที
การแลกเปลี่ยนชัดเจน: ความปลอดภัยทางภูมิศาสตร์และความถูกต้องมากขึ้นมักหมายถึงแล็ตเทนซีการเขียนสูงขึ้น เว้นแต่คุณจะออกแบบตำแหน่งข้อมูลและจุดคอมมิตอย่างระมัดระวัง
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 ภายในภูมิภาคเดียวจนถึงการตั้งค่าข้ามภูมิภาค
บริการจัดการมักลดงานปฏิบัติการ (อัปเกรด แบ็คอัพ การเชื่อมต่อมอนิเตอร์) ขณะที่การโฮสต์เองให้การควบคุมเครือข่าย ชนิดอินสแตนซ์ และตำแหน่งข้อมูลมากกว่า Spanner มักบริโภคเป็นบริการจัดการบน GCP; CockroachDB และ YugabyteDB มักเห็นทั้งแบบจัดการและโฮสต์เอง รวมถึง multi-cloud และ on-prem ตัวเลือก
ฐานข้อมูล Distributed SQL ให้อินเทอร์เฟซเชิงสัมพันธ์และ SQL (ตาราง, join, คอนสเตรนท์, ทรานแซกชัน) แต่รันเป็นคลัสเตอร์ข้ามเครื่องหลายเครื่อง—บ่อยครั้งข้ามภูมิภาค—ในขณะที่ยังคงทำงานเป็น ฐานข้อมูลเชิงตรรกะเดียว
ในทางปฏิบัติ มันพยายามรวม:
RDBMS แบบโหนดเดียวหรือแบบ primary/replica มักจะง่ายกว่า ถูกกว่า และเร็วกว่าในงาน OLTP ที่อยู่ในภูมิภาคเดียว
Distributed SQL น่าสนใจเมื่อทางเลือกอื่นคือ:
แนวคิดหลักสองอย่างคือ:
นี่คือสิ่งที่ทำให้ได้ความสอดคล้องแบบเข้มงวดแม้โหนดล้ม—แต่เพิ่มค่าใช้จ่ายการประสานงานทางเครือข่าย
ตารางถูกแบ่งเป็นชิ้นเล็ก ๆ (มักเรียกว่าพาร์ติชัน/ชาร์ด หรือชื่อเฉพาะของผู้ขายเช่น ranges/tablets/splits) แต่ละพาร์ติชัน:
โดยปกติคุณจะกำหนดนโยบายการวางเพื่อให้ข้อมูล "ฮอต" และผู้เขียนหลักอยู่ใกล้ ลดการข้ามเครือข่าย
ทรานแซกชันแบบกระจายมักจะสัมผัสพาร์ติชันหลายตัว ซึ่งอาจอยู่บนโหนด/ภูมิภาคต่างกัน การคอมมิตอย่างปลอดภัยอาจต้อง:
รอบเดินทางของเครือข่ายเหล่านี้เป็นสาเหตุหลักที่ทำให้แล็ตเทนซีของการเขียนเพิ่มขึ้น—โดยเฉพาะเมื่อข้ามภูมิภาค
สัญญาณชัดเจนที่คุณต้องพิจารณา Distributed SQL: ตอบ "ใช่" อย่างน้อยสองข้อ:
หากโหลดของคุณยังอยู่ในภูมิภาคเดียวพร้อม replica/caching ฐานข้อมูลเชิงสัมพันธ์แบบปกติมักเป็นค่าเริ่มต้นที่ดีกว่า
ความสอดคล้องแบบเข้มงวดหมายความว่าเมื่อทรานแซกชันคอมมิต การอ่านถัดไปจะไม่เห็นข้อมูลเก่า
ในเชิงผลิตภัณฑ์ มันช่วยป้องกัน:
ต้นทุนคือเมื่อเกิด partition บางการดำเนินการอาจถูกบล็อกหรือล้มเหลว แทนที่จะยอมรับความจริงที่แตกต่างกันชั่วคราว
ใช้ข้อจำกัดของฐานข้อมูลร่วมกับทรานแซกชันเพื่อจัดการการลองใหม่อย่างปลอดภัย:
idempotency_key ต่อคำขอ/ความพยายาม(account_id, idempotency_key)วิธีนี้การลองใหม่จะกลายเป็น no-op แทนที่จะเป็นการกระทำซ้ำ—จำเป็นสำหรับการชำระเงิน, การ provision, และการประมวลผลงานเบื้องหลัง
การแยกเชิงปฏิบัติ:
ก่อนตัดสินใจ ให้ทดสอบ ORM/migration และส่วนขยาย Postgres ที่คุณพึ่งพา—อย่าสันนิษฐานว่าจะเปลี่ยนแทนกันได้แบบตรงๆ
เริ่มด้วย PoC ที่มุ่งไปยังงานสำคัญหนึ่งอย่าง (เช่น เช็คเอาต์, การจอง, การบันทึกบัญชี) และตรวจสอบ:
ถ้าต้องการความช่วยเหลือในการคำนวณต้นทุน/ชั้นบริการ ให้ดูที่ /pricing. สำหรับบันทึกการใช้งานเชิงปฏิบัติ ให้เรียกดู /blog.