Tôi sẽ gặp vấn đề gì khi tạo cơ sở dữ liệu cho mỗi khách hàng?

Tôi nhớ từ các podcast stackoverflow rằng Fog Creek sử dụng cơ sở dữ liệu cho mỗi khách hàng cho Fogormsz . Tôi cho rằng điều đó có nghĩa là các máy chủ Fogbugz On Request có 10 nghìn cơ sở dữ liệu.

Chúng tôi mới bắt đầu phát triển một ứng dụng web và có một vấn đề tương tự để giải quyết (rất nhiều khách hàng có dữ liệu bị cô lập của riêng họ).

Những vấn đề tôi nên mong đợi khi sử dụng cơ sở dữ liệu cho mỗi khách hàng? Làm thế nào tôi có thể giải quyết chúng?

Những suy nghĩ ban đầu của tôi

Ưu điểm của cơ sở dữ liệu trên mỗi khách hàng

• Lược đồ cơ sở dữ liệu đơn giản
• Sao lưu đơn giản hơn - bạn có thể sao lưu lần lượt từng khách hàng mà không thực sự ảnh hưởng đến các khách hàng khác.
• Làm cho nó dễ dàng để xuất một dữ liệu khách hàng nhất định.
• Hiệu suất bộ đệm tốt hơn - ghi vào một trong các bảng hoạt động nhiều hơn chỉ tác động đến một khách hàng đã thực hiện ghi.
• Dễ dàng hơn để mở rộng quy mô trên phần cứng. Ví dụ: khi chúng tôi cần đi từ 1 đến 2 máy chủ, chúng tôi chỉ cần chuyển một nửa khách hàng của mình sang máy chủ mới.

Nhược điểm

• MySQL có thể đối phó với 5.000 cơ sở dữ liệu? Hiệu suất sẽ hút?
• Các thay đổi đối với lược đồ có thể khó lặp lại trên tất cả các cơ sở dữ liệu. Chúng tôi thực sự sẽ phải có một kế hoạch tự động cho việc này, chẳng hạn như phiên bản lược đồ và một kịch bản hiểu cách lấy cơ sở dữ liệu từ phiên bản này sang phiên bản khác.
• Làm bất cứ điều gì chung cho tất cả khách hàng của chúng tôi có thể khó xử hoặc không thể
• Tương tự như trên, nhưng bất kỳ phân tích nào chúng tôi muốn thực hiện trên tất cả các khách hàng của chúng tôi có thể là không thể. Làm thế nào chúng ta nên theo dõi việc sử dụng trên tất cả các khách hàng chẳng hạn?

Giải pháp này được gọi là thiết kế nhiều người thuê trong đó mỗi người thuê (khách hàng) có cơ sở dữ liệu riêng của họ. Do đó, có một số cân nhắc khác đối với phương pháp thay thế là một cơ sở dữ liệu duy nhất:

1. Với một cơ sở dữ liệu duy nhất, mọi người phải ở trên cùng một phiên bản cho dù thế nào đi chăng nữa. Không thể nâng cấp một số khách hàng và không phải những người khác. Điều này có thể có vấn đề nếu khách hàng muốn một hotfix của ứng dụng chưa sẵn sàng để phát hành rộng rãi.
2. Với một cơ sở dữ liệu duy nhất, khi bạn thực hiện nâng cấp, mọi máy khách đều bị hỏng. Nếu có sự cố xảy ra, mọi khách hàng đều bị lừa.
3. Với một cơ sở dữ liệu duy nhất, việc tiết kiệm tài nguyên sẽ khó khăn hơn nhiều. Tức là, nếu một khách hàng đang đập vào cơ sở dữ liệu, việc cung cấp cho họ nhiều tài nguyên tách biệt với mọi người khác sẽ khó hơn.
4. Việc cho phép người dùng lưu trữ các phiên bản ứng dụng của riêng họ sẽ khó khăn hơn nhiều. Nếu bạn đang xây dựng một giải pháp sẽ được sử dụng bởi các doanh nghiệp lớn, thì đây thường không phải là khởi đầu. Bộ phận CNTT của họ muốn kiểm soát hoàn toàn quyền truy cập vào hệ thống.
5. Có thể rẻ hơn để mở rộng quy mô cơ sở dữ liệu hơn là mở rộng chúng. Tức là, phải đầu tư vào phần cứng nhanh hơn để lưu trữ một cơ sở dữ liệu để thống trị tất cả chúng có lẽ tốn kém hơn nhiều so với việc có thể thu nhỏ khách hàng đến các máy chủ cơ sở dữ liệu nhỏ hơn, ít tốn kém hơn. Tôi không thể nói điều này dứt khoát vì nó phụ thuộc rất lớn vào phần mềm máy chủ. Nếu bạn gắn bó với MySQL, điều này có thể đúng vì chi phí cấp phép là không đáng kể. Tuy nhiên, nếu bạn chuyển lên SQL Server chẳng hạn, việc nhân rộng sẽ trở nên đắt hơn nhiều trừ khi bạn sử dụng môi trường VPS và lợi ích chi phí của việc nhân rộng so với thay đổi nhân rộng. Tuy nhiên, tôi có thể nói rằng một khi cơ sở dữ liệu của bạn trở nên rất lớn, việc quản lý đòi hỏi trình độ chuyên môn cao hơn bao giờ hết. Cơ sở dữ liệu rất lớn đòi hỏi phải chơi xung quanh với nhiều nhóm fileg và đẩy các chỉ mục nhất định đến các trục chính khác nhau để có hiệu suất tốt hơn. Nói tóm lại, họ có thể phức tạp rất nhanh.

Có cơ sở dữ liệu riêng biệt có nghĩa là bạn phải xây dựng một cơ chế cập nhật phù hợp với phiên bản cơ sở dữ liệu với phiên bản ứng dụng / trang web. Tuy nhiên, các cơ sở dữ liệu riêng biệt cung cấp sự cách ly dữ liệu vượt trội và IMO có chi phí lưu trữ thấp hơn. Nó không phải là một giải pháp cho tất cả các kịch bản. Nếu hệ thống của bạn sẽ không bao giờ được lưu trữ bên ngoài máy chủ của bạn và cần nhanh chóng tăng quy mô khách hàng và có tất cả người dùng trên cùng một phiên bản của ứng dụng và lược đồ cơ sở dữ liệu, thì chắc chắn có một cơ sở dữ liệu duy nhất là cách tiếp cận tốt hơn.

Theo kinh nghiệm của tôi, bạn không nên tạo một cơ sở dữ liệu cho mỗi khách hàng. Tôi sẽ cho bạn một ví dụ:

Năm ngoái tôi đã làm việc với 70 cơ sở dữ liệu (ít hơn 5000), mỗi cơ sở có cùng một lược đồ và tất cả. Về lý thuyết, mọi thứ sẽ diễn ra theo kế hoạch (như bạn đề cập trong phần lợi thế), nhưng thực tế không nhiều. Chúng tôi có nhiều vấn đề với việc cập nhật các lược đồ, hỗ trợ người dùng, cập nhật phần mềm, bạn đặt tên cho nó. Nó quá tệ.

Chúng tôi đã sử dụng Firebird và tôi đã được thuê sau khi sản phẩm được xuất xưởng, nhưng điều này cho tôi kiến ​​thức để không bao giờ làm việc với các cơ sở dữ liệu riêng biệt.

Tôi không nói rằng bạn không thể thực hiện nó, tôi đang nói mọi thứ có thể rất sai và thành thật mà nói, danh sách lợi thế của bạn không đủ hấp dẫn để chấp nhận rủi ro. Hầu hết trong số chúng có thể được thực hiện với một cơ sở dữ liệu duy nhất.

Bạn có thể muốn giữ một cơ sở dữ liệu khác để theo dõi từng phiên bản của mỗi khách hàng, vì vậy bạn có thể theo dõi những phiên bản nào đã hoặc chưa trải qua vòng sửa đổi cuối cùng.

Viết kịch bản nâng cấp sẽ không khó lắm ... bạn có thể viết một cái gì đó nhìn vào danh mục cơ sở dữ liệu và áp dụng các thay đổi cần thiết để đưa từng cơ sở dữ liệu lên phiên bản mới nhất, có thể bỏ qua những thứ không nên nâng cấp vì một số lý do.

Vì 'cơ sở dữ liệu' của mysql chỉ là các lược đồ, như Gaius đã chỉ ra, nếu tất cả đều chạy từ cùng một máy chủ, bạn chỉ có thể đủ điều kiện tên của các bảng bạn đang cố gắng sửa đổi hoặc lấy thông tin ra khỏi:

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

...

Nếu bạn bắt đầu phá vỡ mọi thứ trên nhiều máy chủ, bạn vẫn có thể tạo kịch bản thứ gì đó tạo kết nối đến nhiều máy chủ để bạn có thể áp dụng tất cả các thay đổi; đối với các phân tích, một lần nữa, bạn có thể đặt một loạt các liên kết cơ sở dữ liệu bằng cách sử dụng các bảng được liên kết trong cơ sở dữ liệu chính của bạn để truy cập dữ liệu từ một nơi, vì bạn chỉ cần đọc từ các bảng.

...

Ngoài ra, hãy lưu ý rằng họ không sử dụng myQuery để trao đổi ngăn xếp, họ đang sử dụng SQL Server.

Và tôi không biết loại hiệu năng nào sẽ có trong mysql ở quy mô đó, tôi không nghĩ rằng tôi đã vượt qua 30 'cơ sở dữ liệu' trong mysql.

Tôi có một máy khách Web / DB Hosting có hơn 750 cơ sở dữ liệu khách hàng với cùng số lượng bảng (162) và cùng cấu trúc bảng. Kết hợp lại, tất cả dữ liệu khách hàng của khách hàng của tôi có tổng cộng 524GB (95% InnoDB)

Hãy tưởng tượng tất cả các cơ sở dữ liệu này cạnh tranh cho 13G nhóm bộ đệm innodb trên chín máy chủ DB thông qua sao chép vòng tròn. Mở rộng ra với cấu hình phần cứng đó là không đủ. Ngay lập tức, chúng tôi đề nghị khách hàng mở rộng quy mô.

Gần đây chúng tôi đã di chuyển máy khách này sang 3 máy chủ DB với mã lực lớn hơn nhiều (Bằng mọi giá, hãy tránh xa SSD trong môi trường có tốc độ ghi cao, LUÔN LUÔN !!!). Chúng tôi đã nâng cấp chúng từ MySQL 5.0.90 lên MySQL 5.5.9. Sự khác biệt kịch tính đã được nhìn thấy gần như ngay lập tức.

Việc mở rộng quy mô cũng phải được xem xét bởi vì nếu bạn có hàng trăm máy khách truy cập cùng một tài nguyên bộ nhớ và đĩa, việc nhân rộng sẽ giảm mức sử dụng tuyến tính (O (n)) trong đó n dựa trên số lượng máy chủ DB trong môi trường đa tốc độ.

Trong trường hợp khách hàng của tôi, công ty của tôi đang giảm anh ta từ 9 máy chủ DB (Quad Code, 32GB RAM, 824G RAID10) xuống các máy chủ DB nhanh hơn (Dual HexaCore [đúng 12 CPU], RAM 192 GB, RAID 1.7TB) của MySQL 5.5 .9 (để bảng tận dụng lợi thế của nhiều CPU). Ngoài ra, hãy tưởng tượng nhóm bộ đệm innodb 150GB trong 50 phân vùng mỗi ổ 3 GB (Nhóm bộ đệm nhiều InnoDB là một tính năng mới trong MySQL 5.5). Một quy mô nhỏ hơn, nhưng quy mô lớn, đã làm việc cho cơ sở hạ tầng độc đáo của khách hàng của tôi.

MORAL CỦA CÂU CHUYỆN : Mở rộng hoặc mở rộng không phải lúc nào cũng là giải pháp nếu bạn có các bảng được thiết kế tồi. Ý tôi là thế này: Nếu các trang chỉ mục có dân số khóa bị lệch đối với các chỉ mục nhiều lớp, các khóa truy vấn từ các phần bị thiếu của các chỉ mục sẽ dẫn đến quét bảng sau khi quét bảng hoặc ít nhất là các chỉ mục không bao giờ được sử dụng do Truy vấn MySQL loại trừ Tối ưu hóa. Đơn giản là không có sự thay thế cho thiết kế phù hợp.

MySQL tạo cơ sở dữ liệu trong các thư mục riêng biệt, vì vậy rất nhiều phụ thuộc vào hệ điều hành cơ bản và số lượng thư mục / tệp xử lý mà nó có thể xử lý. Không nên là một vấn đề với các hệ điều hành hiện đại nhưng đó là nơi sẽ có rất nhiều nút thắt.

Không có gì nói rằng bạn phải lưu trữ các phiên bản khác nhau của cơ sở dữ liệu hoặc ứng dụng. Có gì sai khi chỉ cách ly dữ liệu bằng cách thực hiện một db cho mỗi khách hàng và có một phiên bản của cơ sở dữ liệu và ứng dụng? Tất nhiên, mỗi db khách hàng sẽ phải được sao chép từ một mẫu của phiên bản làm việc hiện tại. Từ quan điểm bảo mật và bảo mật dữ liệu, tôi nghĩ rằng điều này là lý tưởng.

Nhược điểm duy nhất tôi có thể thấy là bạn sẽ phải cập nhật thủ công từng cơ sở dữ liệu khi tạo phiên bản mới. Điều này có thể dễ dàng tự động mặc dù.