ฐานข้อมูลเซิร์ฟเวอร์ sql sharding - จะทำอย่างไรกับข้อมูลทั่วไป / ข้อมูลที่ไม่ใช้เศษ

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

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

เราได้ตัดสินใจแล้วว่าข้อมูลใดควรถูกทิ้ง มันเป็นส่วนหนึ่งของฐานข้อมูลของเราซึ่งใช้อย่างมาก

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

ฉันเห็นสองตัวเลือกในการจัดการข้อมูลทั่วไป / สากลนี้:

1) การออกแบบ 1 - วางข้อมูลทั่วไป / สากลในฐานข้อมูลภายนอก การเขียนทั้งหมดจะเกิดขึ้นที่นี่ ข้อมูลนี้จะถูกทำซ้ำลงไปในแต่ละชิ้นส่วนทำให้แต่ละชิ้นส่วนสามารถอ่านข้อมูลนี้และเข้าร่วมภายในกับข้อมูลนี้ในโปรแกรม t-sql

2) การออกแบบ 2 - ให้แต่ละสำเนาของตัวเองของข้อมูลทั่วไป / สากลทั้งหมด ปล่อยให้แต่ละชิ้นส่วนจะเขียนลงในตารางเหล่านี้และใช้การจำลองแบบ sql merge เพื่ออัปเดต / ซิงค์ข้อมูลนี้กับส่วนอื่นทั้งหมด

ความกังวลเกี่ยวกับการออกแบบ # 1

1) ปัญหาการทำธุรกรรม: หากคุณมีสถานการณ์ที่คุณต้องเขียนหรืออัปเดตข้อมูลเป็นเศษแล้วเขียน / อัปเดตตารางทั่วไป / สากลใน 1 proc ที่จัดเก็บไว้เช่นคุณจะไม่สามารถทำสิ่งนี้ได้อย่างง่ายดายอีกต่อไป ขณะนี้ข้อมูลมีอยู่ในอินสแตนซ์และฐานข้อมูลแยกต่างหาก คุณอาจต้องเกี่ยวข้องกับ MS DTS เพื่อดูว่าคุณสามารถรวมการเขียนเหล่านี้ลงในทรานแซคชันได้เนื่องจากอยู่ในฐานข้อมูลแยกต่างหาก ประสิทธิภาพเป็นสิ่งที่น่ากังวลและการเขียนซ้ำที่เป็นไปได้อาจเกี่ยวข้องกับ procs ที่เขียนไปยังเศษข้อมูลและข้อมูลทั่วไป

2) การสูญเสียความสมบูรณ์ของการอ้างอิง ไม่สามารถทำการอ้างอิงข้ามฐานข้อมูลได้อย่างสมบูรณ์

3) การ Recoding พื้นที่ขนาดใหญ่ของระบบเพื่อที่จะรู้การเขียนข้อมูลทั่วไปไปยังฐานข้อมูลสากลใหม่ แต่อ่านข้อมูลทั่วไปจากเศษ

4) เพิ่มฐานข้อมูลทริป เช่นเดียวกับ # 1 ข้างต้นเมื่อคุณพบสถานการณ์ที่คุณต้องอัปเดตข้อมูลที่มีการแบ่งและข้อมูลทั่วไปคุณจะต้องทำการเดินทางหลายรอบเพื่อให้บรรลุเป้าหมายนี้เนื่องจากข้อมูลอยู่ในฐานข้อมูลแยกต่างหาก เวลาแฝงของเครือข่ายบางส่วนที่นี่ แต่ฉันไม่ได้กังวลเกี่ยวกับปัญหานี้เท่าที่กล่าวข้างต้น 3

ความกังวลเกี่ยวกับการออกแบบ # 2

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

ฉันอยากรู้ว่าใครมีตัวเลือกการออกแบบ # 2 ฉันยังอยากรู้ว่าถ้าฉันมองเห็นตัวเลือกการออกแบบที่ 3 หรือ 4 ที่ฉันไม่เห็น

ขอบคุณล่วงหน้า.

คำถามของคุณมุ่งเน้นไปที่สิ่งนี้:

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

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

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

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

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

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

ตอนนี้เกี่ยวกับข้อกังวลของคุณ:

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

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

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

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

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

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

ฉันจะถามว่า SQLServer เป็นทางออกที่ดีที่สุดของคุณหรือไม่ ปริมาณงานมากขึ้นเช่น OLTP หรือมากกว่าเช่น DW / BI หรือไม่

ไชโยเดฟซิสค์

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