วิธีสร้างฐานข้อมูลแบบหลายผู้เช่าที่มีโครงสร้างตารางแบบแบ่งใช้

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

จนถึงตอนนี้ฉันได้เห็นสามตัวเลือก:

• หลายฐานข้อมูล (ผู้เช่าแต่ละคนได้รับเป็นของตัวเอง - เกือบเท่ากับ 1 เซิร์ฟเวอร์ต่อลูกค้าหนึ่งราย)
• Multi-Schema (ไม่มีให้ใน MySQL ผู้เช่าแต่ละคนจะได้รับ schema ของตัวเองในฐานข้อมูลที่แชร์)
• Shared Schema (แนวทางปัจจุบันของเราอาจมีการระบุบันทึกเพิ่มเติมในแต่ละคอลัมน์)

Multi-Schema เป็นรายการโปรดของฉัน (พิจารณาค่าใช้จ่าย) อย่างไรก็ตามการสร้างบัญชีใหม่และการย้ายข้อมูลดูเหมือนจะค่อนข้างเจ็บปวดเพราะฉันจะต้องทำซ้ำกับ schema ทั้งหมดและเปลี่ยนตาราง / คอลัมน์ / คำจำกัดความของพวกเขา

ถาม: Multi-Schema ดูเหมือนว่าได้รับการออกแบบให้มีตารางที่แตกต่างกันเล็กน้อยสำหรับผู้เช่าแต่ละคน - ฉันไม่ต้องการสิ่งนี้ มี RDBMS ใดบ้างที่อนุญาตให้ฉันใช้ multi-schema multi-tenant solution ซึ่งมีการแชร์โครงสร้างตารางระหว่างผู้เช่าทั้งหมดหรือไม่

ป.ล. โดยหลาย ๆ คนฉันหมายถึงบางสิ่งบางอย่างเช่นอัลตร้ามัลติ (10.000+ ผู้เช่า)

อย่างไรก็ตามมี บริษัท บางแห่งที่กลัวว่าข้อมูลของพวกเขาอาจถูกบุกรุกดังนั้นเราจึงประเมินโซลูชั่นอื่น ๆ

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

มีบทความ MSDN ที่น่าสนใจชื่อMulti-Tenant Data Architectureซึ่งคุณอาจต้องการตรวจสอบ นี่คือวิธีที่ผู้เขียนกล่าวถึงความเข้าใจผิดเกี่ยวกับวิธีการแบ่งปัน:

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

สำหรับการพิจารณาทางเทคนิคและธุรกิจบทความจะทำการวิเคราะห์สั้น ๆ ว่าวิธีการใดที่เหมาะสมกว่าอีกวิธี:

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

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

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

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

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

ปรับปรุง:เพิ่มเติมเพื่อปรับปรุงเกี่ยวกับจำนวนผู้เช่าที่คาดหวัง

จำนวนผู้เช่าที่คาดหวัง (10k) นั้นควรยกเว้นวิธีการหลายฐานข้อมูลส่วนใหญ่หากไม่ใช่ทุกสถานการณ์ ฉันไม่คิดว่าคุณจะนึกฝันว่าจะรักษาอินสแตนซ์ฐานข้อมูลไว้ถึง 10,000 อินสแตนซ์และต้องสร้างสิ่งใหม่หลายร้อยรายการทุกวัน

จากพารามิเตอร์นั้นเพียงอย่างเดียวดูเหมือนว่า shared-database วิธี single-schema เหมาะสมที่สุด ความจริงที่ว่าคุณจะเก็บประมาณ 50Mb ต่อผู้เช่าและไม่มี add-on ของผู้เช่าทำให้วิธีนี้เหมาะสมยิ่งขึ้น

บทความ MSDN ที่อ้างถึงข้างต้นกล่าวถึงรูปแบบความปลอดภัยสามรูปแบบที่จัดการกับข้อควรพิจารณาด้านความปลอดภัยสำหรับวิธีแชร์ฐานข้อมูล:

• การเชื่อมต่อฐานข้อมูลที่เชื่อถือได้
• ตัวกรองมุมมองผู้เช่า
• การเข้ารหัสข้อมูลผู้เช่า

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

ปรับปรุง 2:เห็นได้ชัดว่าพวก Microsoft ย้าย / สร้างบทความใหม่เกี่ยวกับเรื่องนี้ลิงค์เดิมหายไปและนี่เป็นเรื่องใหม่: รูปแบบการครอบครองฐานข้อมูลผู้เช่าหลาย SaaS (รุ่งโรจน์เพื่อ Shai Kerer)

ประสบการณ์ของฉัน (แม้ว่า SQL Server) คือหลายฐานข้อมูลเป็นวิธีที่จะไปที่ลูกค้าแต่ละรายมีฐานข้อมูลของตัวเอง ดังนั้นแม้ว่าฉันจะไม่มีประสบการณ์ mySQL หรือ Ruby On Rails แต่ฉันหวังว่าอินพุตของฉันอาจเพิ่มคุณค่าบางอย่าง

เหตุผลที่รวมถึง:

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

ฉันหวังว่านี่จะให้ข้อมูลที่มีประโยชน์บางอย่าง! มีเหตุผลมากกว่านี้ แต่ใจของฉันว่างเปล่า หากมันกลับมาอีกครั้งฉันจะอัปเดต :)

แก้ไข:
ตั้งแต่ฉันโพสต์คำตอบนี้เป็นที่ชัดเจนว่าเรากำลังพูดคุยกับผู้เช่า 10,000+ ประสบการณ์ของฉันอยู่ในฐานข้อมูลขนาดใหญ่หลายร้อย - ฉันไม่คิดว่า 10,000 ฐานข้อมูลแยกกันจะจัดการได้มากเกินไปสำหรับสถานการณ์ของคุณดังนั้นตอนนี้ฉันไม่ชอบวิธี multi-db สำหรับสถานการณ์ของคุณ โดยเฉพาะอย่างยิ่งตอนนี้มันชัดเจนว่าคุณกำลังพูดถึงปริมาณข้อมูลขนาดเล็กสำหรับผู้เช่าแต่ละคน!

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

ด้านล่างนี้เป็นลิงค์ไปยังเอกสารทางเทคนิคบน Salesforce.com เกี่ยวกับวิธีการใช้หลายการเช่า:

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

พวกเขามี 1 คอลัมน์ขนาดใหญ่ที่มีคอลัมน์สตริง 500 คอลัมน์ (ค่า 0, ค่า 1, ... ค่า 500) วันที่และตัวเลขถูกเก็บเป็นสตริงในรูปแบบที่สามารถแปลงเป็นชนิดเนทิฟของพวกเขาได้ในระดับฐานข้อมูล มีตารางข้อมูลเมตาที่กำหนดรูปร่างของรูปแบบข้อมูลที่สามารถไม่ซ้ำกันต่อผู้เช่า มีตารางเพิ่มเติมสำหรับการจัดทำดัชนีความสัมพันธ์ค่าที่ไม่ซ้ำ ฯลฯ

ทำไมต้องวุ่นวาย?

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

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

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

วิธีที่ปรับขนาดได้มากขึ้นคือการมีผู้เช่ากระจายอย่างสุ่มเก็บไว้ในฐานข้อมูลเดียวกัน แต่ข้ามโลจิคัลเศษที่แตกต่างกัน (หรือตาราง ) ขึ้นอยู่กับภาษาของคุณมีห้องสมุดหลายแห่งที่สามารถช่วยเหลือคุณได้ หากคุณกำลังใช้ Rails มีห้องสมุดที่จะacts_as_tenantช่วยให้คุณมั่นใจว่าการสืบค้นของคุณจะดึงข้อมูลนั้นกลับมา นอกจากนี้ยังมีอัญมณีด้วยapartment- แม้ว่ามันจะใช้โมเดลของสคีมามันช่วยในเรื่องการย้ายข้อมูลข้ามสคีมาทั้งหมด หากคุณกำลังใช้ Django มีจำนวน แต่หนึ่งในคนนิยมมากขึ้นน่าจะเป็นทั่วschemas สิ่งเหล่านี้ช่วยได้มากขึ้นในระดับแอปพลิเคชัน หากคุณกำลังมองหาบางสิ่งเพิ่มเติมในระดับฐานข้อมูลโดยตรงCitusมุ่งเน้นไปที่การทำเศษวัสดุประเภทนี้multi-tenancyทำงานได้มากขึ้นจากกล่องด้วย Postgres