หนึ่งใน plusses ขนาดใหญ่สำหรับ nosql DBMS คือพวกเขาสามารถจัดกลุ่มได้ง่ายขึ้น สมมุติว่าด้วย NoSQL คุณสามารถสร้างเครื่องจักรราคาถูกนับร้อยที่เก็บข้อมูลต่าง ๆ และทำการค้นหาทั้งหมดในครั้งเดียว

คำถามของฉันคือสิ่งนี้ทำไม DBMS เชิงสัมพันธ์ไม่สามารถทำเช่นเซิร์ฟเวอร์ mysql หรือ sql ได้ ผู้ค้าไม่ได้หาวิธีทางเทคนิคในการทำสิ่งนี้กับผลิตภัณฑ์ที่มีอยู่ของพวกเขาหรือมีปัญหากับตัวแบบเชิงสัมพันธ์ที่ป้องกันไม่ให้เกิดความเป็นไปได้หรือไม่? มีอะไรที่ยอดเยี่ยมเกี่ยวกับวิธี NoSQL ในการจัดเก็บและเข้าถึงข้อมูล (คีย์ / ค่าเอกสาร ฯลฯ ) ที่ทำให้การจัดกลุ่มง่ายขึ้นหากเป็นจริงทั้งหมด

ระบบฐานข้อมูลแบบกระจาย 101

หรือฐานข้อมูลแบบกระจาย - FK หมายถึง ' ขนาดของเว็บ ' จริงๆหรือไม่

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

ก่อนอื่นคำศัพท์บางคำ

คุณสมบัติกรด (Atomicity, Consistency, Isolation and Durability): สิ่งเหล่านี้เป็นค่าคงที่ที่สำคัญที่จะต้องมีการบังคับใช้สำหรับธุรกรรมที่จะต้องดำเนินการอย่างน่าเชื่อถือโดยไม่ก่อให้เกิดผลข้างเคียงที่ไม่พึงประสงค์

Atomicityต้องการให้ธุรกรรมเสร็จสมบูรณ์หรือย้อนกลับอย่างสมบูรณ์ ธุรกรรมที่เสร็จสิ้นแล้วบางส่วนไม่ควรมองเห็นได้และระบบจะต้องสร้างขึ้นในลักษณะที่ป้องกันไม่ให้สิ่งนี้เกิดขึ้น

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

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

ความคงทนนั้นต้องใช้เมื่อทำรายการธุรกรรมนั้นยังคงอยู่ในที่จัดเก็บข้อมูลถาวรในลักษณะที่ทนทานต่อความล้มเหลวของฮาร์ดแวร์หรือซอฟต์แวร์

ฉันจะอธิบายถึงอุปสรรค์ทางเทคนิคบางประการข้อกำหนดเหล่านี้มีอยู่ในระบบแบบกระจายด้านล่าง

Shared Disk Architecture:สถาปัตยกรรมที่โหนดการประมวลผลทั้งหมดในคลัสเตอร์สามารถเข้าถึงที่เก็บข้อมูลทั้งหมด สิ่งนี้สามารถแสดงคอขวดกลางสำหรับการเข้าถึงข้อมูล ตัวอย่างของระบบที่ใช้ร่วมกันดิสก์ Oracle RACหรือExadata

Shared Nothing Architecture:สถาปัตยกรรมที่การประมวลผลโหนดในคลัสเตอร์มีที่จัดเก็บในตัวเครื่องซึ่งไม่สามารถมองเห็นได้ด้วยโหนดคลัสเตอร์อื่น ตัวอย่างของระบบที่ใช้ร่วมกันไม่มีอะไรเป็น TeradataและNetezza

Shared Memory Architecture:สถาปัตยกรรมที่ CPU หลายตัว (หรือโหนด) สามารถเข้าถึงพูลหน่วยความจำที่ใช้ร่วมกัน เซิร์ฟเวอร์ที่ทันสมัยส่วนใหญ่เป็นประเภทหน่วยความจำที่ใช้ร่วมกัน หน่วยความจำที่ใช้ร่วมกันช่วยให้การดำเนินการบางอย่างเช่นแคชหรือการซิงโครไนซ์แบบพื้นฐานของอะตอมที่ยากต่อการทำบนระบบแบบกระจาย

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

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

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

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

Two Phase Commit (2PC):ตระกูลของโปรโตคอลที่ช่วยให้มั่นใจว่าการอัพเดทฐานข้อมูลที่เกี่ยวข้องกับระบบฟิสิคัลหลาย ๆ การกระทำหรือย้อนกลับอย่างสม่ำเสมอ ไม่ว่าจะใช้ 2PC ภายในระบบหรือข้ามหลายระบบผ่านตัวจัดการธุรกรรมที่มีค่าใช้จ่ายสูง

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

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

Election Algorithm:ระบบกระจายที่เกี่ยวข้องกับหลาย ๆ โหนดนั้นมีความน่าเชื่อถือน้อยกว่าระบบเดียวเนื่องจากมีโหมดความล้มเหลวมากกว่า ในหลายกรณีกลไกบางอย่างจำเป็นสำหรับระบบคลัสเตอร์เพื่อจัดการกับความล้มเหลวของโหนด อัลกอริทึมการเลือกตั้งเป็นคลาสของอัลกอริทึมที่ใช้ในการเลือกผู้นำเพื่อประสานการคำนวณแบบกระจายในสถานการณ์ที่โหนด 'ผู้นำ' ไม่ได้กำหนดหรือเชื่อถือได้ 100%

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

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

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

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

Non-Blocking Switch:สวิตช์เครือข่ายที่ใช้ความขนานของฮาร์ดแวร์ภายในเพื่อให้ได้ปริมาณงานที่เป็นสัดส่วนกับจำนวนพอร์ตโดยไม่มีคอขวดภายใน การใช้งานแบบไร้เดียงสาสามารถใช้กลไก crossbar แต่สิ่งนี้มีความซับซ้อน O (N ^ 2) สำหรับพอร์ต N ซึ่ง จำกัด ให้สวิตช์ขนาดเล็ก สวิตช์ที่ใหญ่กว่าสามารถใช้โทโพโลยีภายในที่ซับซ้อนมากขึ้นที่เรียกว่าสวิตช์การขยายแบบไม่ปิดกั้นขนาดเล็กเพื่อให้ได้อัตราการรับส่งข้อมูลแบบตรงโดยไม่ต้องใช้ฮาร์ดแวร์ O (N ^ 2)

การสร้าง DBMS แบบกระจาย - มันยากขนาดไหน?

ความท้าทายทางเทคนิคหลายประการทำให้การปฏิบัติในทางปฏิบัติค่อนข้างยาก นอกเหนือจากความซับซ้อนที่เพิ่มขึ้นของการสร้างระบบกระจายแล้วสถาปนิกของ DBMS แบบกระจายยังต้องเอาชนะปัญหาทางวิศวกรรมที่ยุ่งยาก

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

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

การบังคับใช้ข้อ จำกัด ล่าช้า (เช่นรอจนกระทั่งส่งมอบเพื่อตรวจสอบ DRI) ต้องมีการล็อคเพื่อเก็บไว้ในช่วงเวลาของการทำธุรกรรม การล็อคแบบกระจายนี้มาพร้อมกับค่าใช้จ่ายที่สำคัญ

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

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

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

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

การปรับให้เหมาะสมทั่วไปอย่างหนึ่งที่ทำในระบบ NoSQL คือการใช้การจำลองแบบองค์ประชุมและความสอดคล้องในที่สุดเพื่อให้ข้อมูลสามารถทำซ้ำอย่างเกียจคร้านในขณะที่รับประกันระดับความยืดหยุ่นของข้อมูลโดยการเขียนลงในองค์ประชุมก่อนรายงานธุรกรรม จากนั้นข้อมูลจะถูกจำลองแบบอย่างเกียจคร้านไปยังโหนดอื่น ๆ ที่สำเนาของข้อมูลอยู่

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

ระบบแชร์ดิสก์

ระบบดิสก์ที่ใช้ร่วมกันเป็นระบบที่ทุกโหนดสามารถเข้าถึงที่เก็บข้อมูลทั้งหมดได้ ดังนั้นการคำนวณจึงขึ้นอยู่กับตำแหน่ง แพลตฟอร์ม DBMS จำนวนมากสามารถทำงานในโหมดนี้ได้ - Oracle RAC เป็นตัวอย่างของสถาปัตยกรรมดังกล่าว

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

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

ระบบที่ใช้ร่วมกันไม่มีอะไร

Shared-nothing systems คือระบบที่มีข้อมูลอย่างน้อยบางส่วนถูกจัดเก็บไว้ในโหนดและไม่สามารถมองเห็นโหนดอื่น ๆ ได้โดยตรง สิ่งนี้จะลบคอขวดของสวิตช์ส่วนกลางทำให้ฐานข้อมูลสามารถปรับขนาด (อย่างน้อยก็ในทางทฤษฎี) ด้วยจำนวนโหนด การแบ่งพาร์ติชันในแนวนอนช่วยให้สามารถแยกข้อมูลข้ามโหนดได้ สิ่งนี้อาจโปร่งใสสำหรับลูกค้าหรือไม่ (ดูที่ Sharding ด้านบน)

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

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

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

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

การคัดลอกควอรัมและความสอดคล้องท้ายที่สุด

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

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

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

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

เทคนิคเหล่านี้อนุญาตให้ฐานข้อมูลขยายในอัตราใกล้เชิงเส้นโดยการเพิ่มโหนดเข้ากับคลัสเตอร์ ในทางทฤษฎีการจำลองแบบองค์ประชุมเป็นสิ่งจำเป็นเฉพาะถ้าสื่อจัดเก็บข้อมูลพื้นฐานจะได้รับการพิจารณาไม่น่าเชื่อถือ สิ่งนี้มีประโยชน์หากต้องใช้เซิร์ฟเวอร์สินค้าโภคภัณฑ์ แต่มีค่าน้อยกว่าหากกลไกหน่วยเก็บข้อมูลพื้นฐานมีรูปแบบความพร้อมใช้งานสูงของตนเอง (เช่น SAN ที่มีตัวควบคุมแบบมิเรอร์และการเชื่อมต่อหลายเส้นทางไปยังโฮสต์)

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

กลับไปที่แพลตฟอร์ม RDBMS

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

Shared-disk และ shared-nothing systems สามารถเพิ่มปริมาณงานได้มาก ตัวอย่างเช่น Oracle RAC สามารถรองรับ 63 โหนดการประมวลผล (ซึ่งอาจเป็นเครื่อง SMP ขนาดใหญ่ที่อยู่ด้านขวาของตัวเอง) และตัวควบคุมพื้นที่เก็บข้อมูลจำนวนหนึ่งบน SAN IBM Sysplex (คลัสเตอร์ของเมนเฟรม zSeries) สามารถรองรับเมนเฟรมจำนวนมาก (แต่ละอันมีกำลังการประมวลผลที่สำคัญและแบนด์วิดธ์ I / O ของตนเอง) และตัวควบคุม SAN หลายตัว สถาปัตยกรรมเหล่านี้สามารถรองรับปริมาณการทำธุรกรรมที่มีขนาดใหญ่มากด้วยความหมายของ ACID แม้ว่าพวกเขาจะถือว่าการจัดเก็บที่เชื่อถือได้ Teradata, Netezza และผู้ขายรายอื่นสร้างแพลตฟอร์มการวิเคราะห์ที่มีประสิทธิภาพสูงโดยอิงจากการออกแบบที่ไม่มีอะไรที่ใช้ร่วมกันซึ่งปรับขนาดเป็นปริมาณข้อมูลขนาดใหญ่มาก

จนถึงขณะนี้ตลาดสำหรับแพลตฟอร์ม ACID RDBMS ที่มีปริมาณมาก แต่ราคาถูกมากเป็นพิเศษถูกครอบงำโดย MySQL ซึ่งรองรับการคัดลอกและการจำลองแบบหลายต้นแบบ MySQL ไม่ได้ใช้การจำลองแบบองค์ประชุมเพื่อเพิ่มประสิทธิภาพ throughput การเขียนดังนั้นการทำธุรกรรมมีราคาแพงกว่าในระบบ NoSQL Sharding อนุญาตให้ปริมาณการอ่านสูงมาก (ตัวอย่างเช่น Facebook ใช้ MySQL อย่างกว้างขวาง) ดังนั้นสถาปัตยกรรมประเภทนี้จึงปรับขนาดได้ตามปริมาณงานที่อ่านมาก

การอภิปรายที่น่าสนใจ

BigTableเป็นสถาปัตยกรรมที่ใช้ร่วมกันไม่มีอะไร (หลักกระจายค่าคีย์คู่) เป็นแหลมออกโดยไมเคิล Hausenblas ด้านล่าง การประเมินดั้งเดิมของฉันนั้นรวมถึงโปรแกรม MapReduce ซึ่งไม่ได้เป็นส่วนหนึ่งของ BigTable แต่โดยปกติจะใช้ร่วมกับมันในการใช้งานทั่วไป (เช่น Hadoop / HBase และกรอบการทำงาน MapReduce ของ Google)

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

ปริมาณการประมวลผลของระบบสไตล์ MapReduce เช่น Hadoop ถูก จำกัด ด้วยแบนด์วิดท์ของสวิตช์เครือข่ายที่ไม่บล็อก ¹ สวิทช์ที่ไม่บล็อกสามารถจัดการกับการรวมแบนด์วิดท์ขนาดใหญ่เนื่องจากความขนานในการออกแบบดังนั้นจึงไม่ค่อยมีข้อ จำกัด ในทางปฏิบัติที่สำคัญเกี่ยวกับประสิทธิภาพ ซึ่งหมายความว่าสถาปัตยกรรมดิสก์ที่ใช้ร่วมกัน (อาจเรียกว่าระบบจัดเก็บข้อมูลที่ใช้ร่วมกันได้ดีกว่า) สามารถปรับขนาดเป็นปริมาณงานขนาดใหญ่ได้แม้ว่าสวิตช์เครือข่ายจะเป็นคอขวดกลางในทางทฤษฎี

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

¹แน่นอนว่าการประมวลผลและปริมาณงานของ I / O ที่มีอยู่นั้นยังมีข้อ จำกัด ด้านประสิทธิภาพ แต่สวิตช์เครือข่ายเป็นจุดศูนย์กลางในการรับส่งข้อมูลทั้งหมด

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

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

สิ่งที่ บริษัท ที่ฉันทำงานให้คือClustrixข้อเสนอคือชุดของการคำนวณและโหนดการจัดเก็บข้อมูลที่เชื่อมต่อกันด้วยเครือข่ายความเร็วสูง ข้อมูลเชิงสัมพันธ์มีการแฮชกระจายข้ามโหนดบนพื้นฐานต่อดัชนีในกลุ่มข้อมูลที่เราเรียกว่า 'สไลซ์' ชิ้นงานแต่ละชิ้นจะมีแบบจำลองสองชุดขึ้นไปกระจายทั่วทั้งคลัสเตอร์เพื่อความทนทานในกรณีที่โหนดหรือดิสก์ล้มเหลว ลูกค้าสามารถเชื่อมต่อกับโหนดใด ๆ ในคลัสเตอร์เพื่อออกแบบสอบถามโดยใช้โปรโตคอล wire ของ MySQL

มันค่อนข้างไม่เป็นธรรมชาติเลยที่จะคิดว่าส่วนประกอบของฐานข้อมูล ACID เป็นอิสระเพราะมันประกบกันมาก แต่นี่จะไป:

Atomicity - Clustrix ใช้สองขั้นตอนเพื่อให้มั่นใจว่าเป็นอะตอมมิก การดำเนินการ UPDATE และ DELETE จะล็อคแถวผ่านตัวจัดการการล็อกแบบกระจายของเราเพราะเราจะเปลี่ยนการดำเนินการเหล่านั้นให้เป็น SELECT ตามด้วยการดำเนินการ UPDATE / DELETE ที่แน่นอน

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

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

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

แยก - Clustrix ให้แยก MVCC ที่ระดับภาชนะ การรับประกันแบบปรมาณูของเราว่าแบบจำลองที่ใช้บังคับทั้งหมดได้รับการเขียนเฉพาะก่อนที่เราจะรายงานการทำธุรกรรมที่มุ่งมั่นส่วนใหญ่จะลดปัญหาการแยกกับสิ่งที่คุณมีในกรณีที่ไม่ใช่แบบคลัสเตอร์

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

คำตอบพื้นฐานคือโมเดลความสอดคล้องแตกต่างกัน ฉันกำลังเขียนสิ่งนี้เพื่อขยายคำตอบของ ConcernedOfTunbridge ซึ่งน่าจะเป็นจุดอ้างอิงสำหรับสิ่งนี้

จุดพื้นฐานของรูปแบบความสอดคล้องของกรดคือมันทำให้การรับประกันพื้นฐานมากมายเกี่ยวกับสถานะของข้อมูลทั่วโลกภายในระบบ การค้ำประกันเหล่านี้อยู่ภายใต้ข้อ จำกัด ทางทฤษฎีของ CAP ซึ่งหมายความว่าโดยทั่วไปเพื่อให้การทำงานนั้นเป็นไปได้คุณต้องมีแหล่งข้อมูลที่เชื่อถือได้ทั้งหมดในหน้าเดียวกันก่อนที่คุณจะบอกแอปพลิเคชันที่คุณทำธุรกรรม การจำลองแบบหลายต้นแบบจึงเป็นเรื่องยากมากที่จะไม่ทำตามข้อ จำกัด เหล่านี้ แน่นอนเมื่อคุณเริ่มทำการจำลองแบบอะซิงโครนัสในสภาพแวดล้อมแบบ multi-master การรับประกันเหล่านี้จะออกไปนอกหน้าต่าง แบบจำลองความสอดคล้อง ACID เป็นแบบจำลองความสอดคล้องที่แข็งแกร่งสำหรับข้อมูลที่สำคัญหรือสำคัญ

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

RDBMS สามารถทำและปรับขนาดรวมถึงโซลูชั่น NoSQL ได้!

อย่างไรก็ตามมีบางกรณีที่ RDBMS สามารถทำและขยายขนาดจนถึง NoSQL อาจไม่สามารถจับคู่ได้ มันแตกต่างกันมาก ฉันจะดู Postgres-XC เป็นตัวอย่างของวิธีการขยายขนาดที่เป็นไปได้โดยไม่สูญเสียการรับประกันความมั่นคงที่แข็งแกร่ง

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

ฉันเข้าใจรุ่น Postgres-XC ซึ่งได้แรงบันดาลใจจาก Teradata ประกอบด้วยโหนดในสองบทบาทที่แตกต่างกันเช่นโหนดหน่วยเก็บข้อมูลหรือผู้ประสานงาน ผู้ประสานงานเป็น multi-master (ไม่มีการจำลองแบบจริงที่เกี่ยวข้อง) และพวกเขาเชื่อมต่อกับโหนจัดเก็บข้อมูลเพื่อจัดการกับการประมวลผลข้อมูลจริง โหนดหน่วยเก็บข้อมูลจำลองแบบในการตั้งค่า master-slave โหนดจัดเก็บข้อมูลแต่ละโหนดมีสิ่งที่อยู่ในใจความสำคัญของฐานข้อมูล แต่ผู้ประสานงานเก็บรักษาภาพที่สอดคล้องกันของข้อมูล

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

ในเรื่องนี้ Postgres-XC นำเสนอบางอย่างเช่นตัวเลือกการปรับขนาด NoSQL แต่มีความซับซ้อนเพิ่มขึ้นเนื่องจากการรับประกันความสอดคล้องเพิ่มเติม ฉันเข้าใจว่ามี RDBMS เชิงพาณิชย์ที่ให้ความยืดหยุ่นเช่นนี้ Teradata ทำสิ่งนี้ นอกจากนี้ระบบดิสก์ที่ใช้ร่วมกันสามารถขยายขนาดในลักษณะที่คล้ายกันและทั้ง DB2 และ Oracle เสนอโซลูชันดังกล่าว ดังนั้นจึงไม่ยุติธรรมเลยที่จะบอกว่า RDBMS ไม่สามารถทำได้ พวกเขาสามารถ. ในอดีตที่ผ่านมาความต้องการมีขนาดเล็กมากจนการประหยัดต่อขนาดไม่เพียงพอที่จะทำให้โซลูชั่นที่เป็นกรรมสิทธิ์มีราคาไม่แพงมากสำหรับผู้เล่นส่วนใหญ่

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

แก้ไข: สิ่งสำคัญคือต้องคำนึงถึงนัยของการเข้าร่วม ในระบบคลัสเตอร์การรวมกลายเป็นปัญหาประสิทธิภาพที่แตกต่างกันมาก หากทุกอย่างอยู่ในโหนดเดียวกันพวกเขาสามารถปรับปรุงประสิทธิภาพได้ แต่ถ้าคุณต้องเดินทางไปกลับที่โหนดอื่นจะทำให้มีค่าใช้จ่ายสูงมาก ดังนั้นแบบจำลองข้อมูลจะสร้างความแตกต่างและวิธีการจัดกลุ่มมีผลกระทบต่อประสิทธิภาพ วิธีการเช่น Postgres-XC และ Postgres-XL คิดว่าคุณสามารถใช้เวลาคิดอย่างยุติธรรมเพื่อให้คุณสามารถแชร์ข้อมูลของคุณและรวบรวมข้อมูลเข้าด้วยกันได้อย่างเหมาะสม แต่นั่นเป็นค่าใช้จ่ายในการออกแบบ ในทางกลับกันเครื่องชั่งนี้ดีกว่าโซลูชั่น NoSQL จำนวนมากและสามารถปรับได้อย่างเหมาะสม ตัวอย่างเช่นเรา (at Adjust) ใช้กลยุทธ์การจัดกลุ่มที่คล้าย NoSQL สำหรับข้อมูล 3.5PB ของเราใน PostgreSQL ซึ่งเป็นการวิเคราะห์บันทึกโดยทั่วไป และการออกแบบของเราจำนวนมากได้รับแรงบันดาลใจจากกลยุทธ์การจัดกลุ่ม NoSQL ดังนั้นบางครั้งตัวแบบข้อมูลก็ จำกัด รูปแบบการจัดกลุ่มเช่นกัน

คำตอบของฉันจะไม่ถูกเขียนอย่างดีเหมือนคำตอบก่อนหน้านี้ แต่นี่จะไป

ชื่อเสียงของ Michael Stonebraker of Ingres ได้สร้าง MPP shared-nothing column-store (Vertica) และ MPP shared-nothing ฐานข้อมูล SQL ใหม่ (VoltDB) ซึ่งกระจายข้อมูลระหว่างโหนดต่าง ๆ ในคลัสเตอร์และดูแล ACID HP ได้ซื้อ Vertica แล้ว

ฉันเชื่อว่าฐานข้อมูล SQL ใหม่อื่นยังคงรักษากรดอยู่เช่นกัน แต่ฉันไม่แน่ใจว่ามีกี่คนที่แจกจ่ายแถวของพวกเขาบนคลัสเตอร์ ฯลฯ

นี่คือการพูดคุยของ Stonebraker ที่มอบให้กับ SQL ใหม่ที่เกี่ยวข้องกับ NoSQL และ "Old SQL" http://www.youtube.com/watch?v=uhDM4fcI2aI

การจัดกลุ่ม MySQL สามารถใช้การจำลองแบบการเรียนรู้แบบหลายส่วนและแบ่งส่วนที่ครอบคลุมทั่วทั้งคลัสเตอร์