ฉันจะสร้างปัญหาฐานข้อมูลต่อลูกค้าหนึ่งรายได้อย่างไร

ผมจำได้จากพอดคาสต์ StackOverflow ว่าหมอกครีกใช้ฐานข้อมูลต่อลูกค้าสำหรับFogbugz ฉันคิดว่านั่นหมายถึงเซิร์ฟเวอร์ Fogbugz On Demand มีฐานข้อมูลนับหมื่น ๆ

เราเพิ่งเริ่มพัฒนาเว็บแอปและมีปัญหาคล้ายกันในการแก้ปัญหา (ลูกค้าจำนวนมากที่มีข้อมูลแยกต่างหากของตัวเอง)

ฉันควรคาดหวังปัญหาอะไรบ้างเมื่อใช้ฐานข้อมูลต่อลูกค้าหนึ่งราย ฉันจะแก้ปัญหาได้อย่างไร

ความคิดเริ่มต้นของฉัน

ข้อดีของฐานข้อมูลต่อลูกค้า

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

ข้อเสีย

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

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

1. ด้วยฐานข้อมูลเดียวทุกคนต้องอยู่ในเวอร์ชันเดียวกันไม่ว่าจะเกิดอะไรขึ้น ไม่สามารถอัปเกรดลูกค้าบางรายและบางรายไม่ได้ ซึ่งอาจเป็นปัญหาได้หากลูกค้าต้องการให้มีโปรแกรมแก้ไขด่วนของแอปพลิเคชันที่ไม่พร้อมสำหรับการเปิดตัวในวงกว้าง
2. ด้วยฐานข้อมูลเดียวเมื่อคุณทำการอัปเกรดไคลเอ็นต์ทุกรายจะหยุดทำงาน หากมีข้อผิดพลาดลูกค้าทุกคนจะถูกทำให้เมา
3. ด้วยฐานข้อมูลเดียวมันเป็นเรื่องยากมากที่จะเค้นทรัพยากร นั่นคือถ้าลูกค้ารายหนึ่งกำลังตอกย้ำฐานข้อมูลมันก็ยากที่จะให้ทรัพยากรเพิ่มเติมแก่พวกเขาแยกจากคนอื่น
4. เป็นการยากมากที่จะอนุญาตให้ผู้ใช้โฮสต์แอปพลิเคชันเวอร์ชันของคุณเอง หากคุณกำลังสร้างโซลูชันที่จะใช้งานโดยองค์กรขนาดใหญ่นี้มักจะไม่ใช่ผู้เริ่มต้น แผนกไอทีของพวกเขาต้องการควบคุมการเข้าถึงระบบอย่างสมบูรณ์
5. มันอาจถูกกว่าการขยายฐานข้อมูลแทนที่จะขยายฐานข้อมูล นั่นคือการลงทุนในฮาร์ดแวร์ที่เร็วกว่าเพื่อโฮสต์ฐานข้อมูลเดียวเพื่อครองฐานข้อมูลทั้งหมดนั้นอาจมีราคาแพงกว่าความสามารถในการขยายลูกค้าไปยังเซิร์ฟเวอร์ฐานข้อมูลขนาดเล็กและราคาไม่แพง ฉันไม่สามารถพูดสิ่งนี้ได้อย่างแน่นอนเพราะมันขึ้นอยู่กับซอฟต์แวร์เซิร์ฟเวอร์เป็นอย่างมาก ถ้าคุณยึดติดกับ MySQL นี่อาจเป็นจริงเพราะค่าใช้จ่ายใบอนุญาตมีน้อยมาก อย่างไรก็ตามหากคุณเลื่อนไปที่ SQL Server ตัวอย่างการปรับขนาดจะกลายเป็นราคาที่แพงกว่ามากยกเว้นว่าคุณใช้สภาพแวดล้อม VPS และผลประโยชน์ด้านต้นทุนของการปรับขนาดเทียบกับการปรับขนาดการเปลี่ยนแปลง ฉันสามารถพูดได้ว่าเมื่อฐานข้อมูลของคุณมีขนาดใหญ่มากการจัดการต้องใช้ความเชี่ยวชาญในระดับที่มากขึ้น ฐานข้อมูลขนาดใหญ่มากจำเป็นต้องเล่นกับกลุ่มไฟล์หลายกลุ่มและผลักดัชนีบางอย่างไปยังแกนหมุนที่ต่างกันเพื่อให้ได้ประสิทธิภาพที่ดีขึ้น ในระยะสั้นพวกเขาจะซับซ้อนได้เร็วมาก

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

จากประสบการณ์ของฉันคุณไม่ควรสร้างฐานข้อมูลเดียวต่อลูกค้า ผมขอยกตัวอย่าง:

ปีที่แล้วฉันทำงานกับฐานข้อมูล 70 แห่ง (น้อยกว่า 5,000 รายการ) แต่ละรายการมีสคีมาเหมือนกันและทั้งหมด ในทางทฤษฎีสิ่งต่าง ๆ จะเป็นไปตามแผนที่วางไว้ (ตามที่คุณพูดถึงในส่วนข้อดี) แต่ในความเป็นจริงไม่มาก เรามีปัญหามากมายกับการอัพเดตสกีมาการสนับสนุนผู้ใช้การอัปเดตซอฟต์แวร์คุณตั้งชื่อมัน มันน่ากลัว.

เราใช้ Firebird และฉันได้รับการว่าจ้างหลังจากมีการจัดส่งผลิตภัณฑ์ แต่สิ่งนี้ทำให้ฉันมีความรู้ที่จะไม่ทำงานกับฐานข้อมูลแยกกัน

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

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

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

เนื่องจากฐานข้อมูลของ mysql เป็นเพียง schemas ดังที่ Gaius ชี้ให้เห็นหากทุกอย่างทำงานจากอินสแตนซ์ของเซิร์ฟเวอร์เดียวกันคุณสามารถกำหนดชื่อของตารางที่คุณพยายามปรับเปลี่ยนหรือรับข้อมูลจาก:

alter schema.table ...
select ... from schema.table

...

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

...

นอกจากนี้โปรดระวังว่าพวกเขาไม่ได้ใช้ mySQL สำหรับการแลกเปลี่ยนสแต็กพวกเขากำลังใช้ SQL Server

และฉันก็ไม่รู้ว่าค่าใช้จ่ายประเภทใดที่มีอยู่ใน mysql ในระดับนั้นฉันไม่คิดว่าฉันเคยผ่านฐานข้อมูล 30 ครั้งใน mysql มาก่อน

ฉันมีลูกค้า Web / DB Hosting ที่มีฐานข้อมูลลูกค้ากว่า 750 รายที่มีตารางจำนวนเท่ากัน (162) และโครงสร้างตารางเดียวกัน รวมข้อมูลลูกค้าของลูกค้าของฉันทั้งหมดรวม 524GB (95% InnoDB)

ลองนึกภาพทั้งหมดของฐานข้อมูลเหล่านี้แข่งขันกับ 13G ของพูลบัฟเฟอร์ innodb บนเซิร์ฟเวอร์เก้าฐานข้อมูลผ่านการจำลองแบบวงกลม การปรับขนาดด้วยการกำหนดค่าฮาร์ดแวร์นั้นไม่เพียงพอ ทันทีเราแนะนำให้ลูกค้าขยายขนาด

เราเพิ่งย้ายไคลเอนต์นี้ไปยังเซิร์ฟเวอร์ DB 3 ตัวที่มีแรงม้ามากขึ้น (ในทุกค่าใช้จ่ายให้อยู่ห่างจาก SSD ในสภาพแวดล้อมที่มีการเขียนสูงเสมอ !!! เราอัปเกรดจาก MySQL 5.0.90 เป็น MySQL 5.5.9 เห็นความแตกต่างอย่างมากเกือบจะในทันที

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

ในกรณีที่ลูกค้าของฉัน บริษัท ของฉันกำลังลดเขาจากเซิร์ฟเวอร์ 9 DB (Quad Code, 32GB RAM, 824G RAID10) ไปยังเซิร์ฟเวอร์ DB ที่เร็วขึ้น (Dual HexaCore [เหมาะสม 12 ซีพียู], 192GB RAM, 1.7TB RAID10) ของ MySQL 5.5 .9 (ไปยังตารางใช้ประโยชน์จาก CPU หลายตัว) นอกจากนี้ลองจินตนาการถึง 150GB innodb buffer pool ใน 50 พาร์ติชั่น 3GB แต่ละอัน (Multiple InnoDB buffer pool เป็นคุณสมบัติใหม่ใน MySQL 5.5) ขนาดเล็กกว่า แต่ขยายใหญ่ขึ้นได้ทำงานกับโครงสร้างพื้นฐานที่เป็นเอกลักษณ์ของลูกค้าของฉัน

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

MySQL สร้างฐานข้อมูลในไดเรกทอรีที่แยกต่างหากดังนั้นขึ้นอยู่กับระบบปฏิบัติการและจำนวนโฟลเดอร์ / ไฟล์ที่สามารถจัดการได้ ไม่ควรมีปัญหากับระบบปฏิบัติการที่ทันสมัย ​​แต่นั่นเป็นจุดที่คอขวดจำนวนมากจะมาจาก

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

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