¿Existe algún límite para la cantidad de bases de datos que puede poner en un servidor SQL?

Estoy configurando un sistema SaaS, donde planeamos dar a cada cliente su propia base de datos. El sistema ya está configurado para que podamos escalar fácilmente a servidores adicionales si la carga se vuelve demasiado grande; esperamos tener miles, o incluso decenas de miles de clientes.

Preguntas

• ¿Existe alguna limitación práctica en la cantidad de micro bases de datos que puede / debe tener en un SQL Server?
• ¿Puede afectar el rendimiento del servidor?
• ¿Es mejor tener 10,000 bases de datos de 100 MB cada una, o una base de datos de 1 TB?

Información Adicional

Cuando digo "micro bases de datos", en realidad no quiero decir "micro"; Solo quiero decir que apuntamos a miles de clientes, por lo que cada base de datos individual solo representaría una milésima parte o menos del almacenamiento total de datos. En realidad, cada base de datos estaría alrededor de los 100 MB, dependiendo de la cantidad de uso que obtenga.

La razón principal para usar 10,000 bases de datos es la escalabilidad. El hecho es que V1 del sistema tiene una base de datos, y hemos tenido algunos momentos incómodos cuando el DB se estaba esforzando bajo la carga.

Estaba agotando la CPU, la memoria, las E / S, todo lo anterior. A pesar de que solucionamos esos problemas, nos hicieron darnos cuenta de que en algún momento, incluso con la mejor indexación del mundo, si tenemos el éxito que esperamos, simplemente no podemos poner todos nuestros datos en una gran honkin 'base de datos. Entonces, para V2 estamos fragmentando, por lo que podemos dividir la carga entre múltiples servidores de bases de datos.

Pasé el último año desarrollando esta solución fragmentada. Es una licencia por servidor, pero de todos modos eso se soluciona ya que estamos usando máquinas virtuales en Azure. La razón por la que surge la pregunta ahora es porque anteriormente solo ofrecíamos a grandes instituciones y creábamos cada una de nosotros. Nuestro siguiente orden del día es un modelo de autoservicio en el que cualquier persona con un navegador puede registrarse y crear su propia base de datos. Sus bases de datos serán mucho más pequeñas y mucho más numerosas que las grandes instituciones.

Probamos los conjuntos elásticos de Azure SQL Database . El rendimiento fue muy decepcionante, por lo que cambiamos a máquinas virtuales normales.

He trabajado en servidores SQL con 8 a 10 mil bases de datos en una sola instancia. No es lindo.

Reiniciar el servidor puede tomar hasta una hora o más. Piense en el proceso de recuperación para 10,000 bases de datos.

No puede usar SQL Server Management Studio para localizar de manera confiable una base de datos en el Explorador de objetos.

Las copias de seguridad son una pesadilla, ya que para que las copias de seguridad valgan la pena, debe tener una solución de recuperación ante desastres viable. Esperemos que su equipo sea excelente para escribir todo .

Empiezas a hacer cosas como nombrar bases de datos con números, como M01022y T9945. Tratar de asegurarse de que está trabajando en la base de datos correcta, por ejemplo, en M001022lugar de M01022, puede ser una locura.

Asignar memoria para tantas bases de datos puede ser insoportable; SQL Server termina haciendo muchas E / S, lo que puede ser un verdadero obstáculo para el rendimiento. Considere un sistema que registra los detalles del uso de carbono en 4 tablas para 10,000 compañías. Si lo hace en una base de datos, solo necesita 4 tablas; si lo hace en 10,000 bases de datos, de repente necesita 40,000 tablas en la memoria. La sobrecarga de lidiar con ese número de tablas en la memoria es sustancial. Cualquier consulta que diseñe que se ejecutará en esas tablas requerirá al menos 10,000 planes en la caché del plan si hay 10,000 bases de datos en uso.

La lista anterior es solo una pequeña muestra de problemas que necesitará planificar cuando opere a ese tipo de escala.

Probablemente se encontrará con cosas como que el Servicio de SQL Server tarda mucho en iniciarse, lo que puede causar errores en el Controlador de servicio. Puede aumentar el tiempo de inicio del servicio usted mismo, cree la siguiente entrada de registro:

Subclave: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control
Nombre: ServicesPipeTimeout
Tipo: REG_DWORD
Datos: el número de milisegundos antes de que se agote el tiempo de espera durante el inicio del servicio

Por ejemplo, para esperar 600 segundos (10 minutos) antes de que se agote el tiempo de servicio, escriba 600000.

Desde que escribí mi respuesta, me di cuenta de que la pregunta es sobre Azure. Quizás hacer esto en la base de datos SQL no sea tan problemático; Quizás es más problemático. Personalmente, probablemente diseñaría un sistema usando una sola base de datos, quizás fragmentada verticalmente en varios servidores, pero ciertamente no una base de datos por cliente.

Así que hay ventajas y desventajas para ambos métodos. Sin saber más sobre su aplicación o los servicios que está buscando proporcionar, no podré dar una respuesta definitiva, pero descartaré algunos de mis pensamientos al respecto.

Mi caso es por qué debería usar 1 Base de datos para todos los clientes.

Pros

• Facil mantenimiento. Tener una base de datos significa que solo tiene que hacer su tarea de mantenimiento en una ubicación en lugar de en muchas. Imagine la pesadilla de manejar 1000 bases de datos diferentes para realizar copias de seguridad. ¿Qué tal actualizar estadísticas en 1000 DB's o reconstruir índices o DBCC CHECKDB?

• Código de implementación. Supongamos que tiene un problema con un procedimiento almacenado en su código de aplicación o informe. Necesita hacer un cambio rápido ... Ahora debe implementar ese cambio en más de 1000 DB. No, gracias, prefiero no hacerlo.

• Fácil visibilidad Solo imagínese SSMS tratando de abrir más de 1000 DB's (estremecimiento) . Prácticamente inutilizaría el problema y tomaría una cantidad sorprendente de tiempo abrir y procesar SSMS. Tenga en cuenta que eso es si puede llegar a una convención de nomenclatura decente.

Contras

• Seguridad. Sería más fácil evitar que la gente vea los datos de otros clientes si los tuviera como bases de datos separadas. Sin embargo, hay algunas cosas muy simples que puede hacer para evitar que esto suceda.

• Actuación. Se podría argumentar que limitarlo a una base de datos por cliente significa que el servidor SQL tendrá que escanear menos datos para obtener la información que está consultando. Sin embargo, con una estructura de datos adecuada y una buena indexación (y una posible partición), es probable que pueda eliminar esto como un problema si se hace con cuidado. Recomendaría dar a cada tabla que contenga datos específicos del cliente algún tipo de ventaja CompanyIDpara reducir esa sobrecarga.

En última instancia, creo que su mejor opción es tener una base de datos para su aplicación y simplemente dividir los datos del cliente dentro de la propia base de datos. Los problemas que le dará no serán nada en comparación con la pesadilla de administrar más de 1000 bases de datos.

Las especificaciones de capacidad máxima para SQL Server indican que hay un límite de 32,767.

En cuanto a si afectará el rendimiento, la respuesta es sí, pero las formas en que afectará el rendimiento, y si sería sustancial, dependerían de una miríada de factores.

Iría con una base de datos a menos que haya una buena razón para dividirla en 10,000 bases de datos. ¿Una copia de respaldo o 10,000 copias de respaldo? ¿Una verificación de integridad o 10.000? Puede haber una buena razón para usar 10,000 bases de datos pequeñas, pero no ha dado suficientes detalles para determinar eso. La pregunta que ha hecho es bastante amplia, y simplemente no hay suficiente información para que nadie sepa cuál es la mejor respuesta.

De lo que está hablando aquí es de la arquitectura multiinquilino frente a la multiinstancia . Solo menciono estos términos, ya que no los usa en su pregunta, pero así es como se llama y si simplemente conecta la "arquitectura multiinquilino" en Google, encontrará una gran cantidad de recursos y debates. al respecto, se han escrito libros completos sobre él.

Algunos buenos recursos sobre SQL Server específicamente aquí:

https://msdn.microsoft.com/en-us/library/ff966499.aspx

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

Estaría con otras respuestas, ya que me inclinaría fuertemente hacia múltiples inquilinos por defecto, a menos que tenga razones convincentes para favorecer las instancias múltiples.

No necesita dividirse en miles de bases de datos de clientes individuales para escalar, hay muchas otras formas de hacerlo que probablemente sean preferibles. Como agrupación, replicación, fragmentación, particionamiento, etc. No reinvente la rueda. No hay nada inherente que diga que necesita dividir esto manualmente en un nivel de cliente individual y, de hecho, es probable que aumente significativamente los costos de agregar a cada nuevo cliente.

Estás hablando de "millones" de clientes, piensa en cualquier software basado en la nube a gran escala como un servicio, Gmail, lo que sea, apenas crees que crean una base de datos completamente nueva para cada nuevo registro, ¿verdad?

Puede haber razones en las que desee facilitar esto, por ejemplo, si está vendiendo su producto a un cliente que DEBE tenerlo alojado internamente en su propia infraestructura. Pero como regla general de SAAS, inclínese por defecto a una arquitectura multiinquilino.

Una de las desventajas que puedo ver en la sugerencia de una sola base de datos es hacer que se reviertan los datos: si tiene una base de datos configurada por inquilino, puede restaurar los datos de cada cliente de forma independiente (y en un momento determinado). Si están todos en una base de datos, esto se vuelve mucho más difícil (y mucho más propenso a errores, ya que probablemente tendría que hacerse a través de las instrucciones INSERT / UPDATE / DELETE).

Gracias a todos los que respondieron, realmente aprecio los puntos que me han dado para pensar. La sensación general que tuve fue que es preferible una sola base de datos, pero me gustaría agregar algunos puntos compensatorios a favor de la arquitectura fragmentada y abordar algunas de las preocupaciones que otras personas han mencionado.

Motivación para fragmentar

Como se menciona en la pregunta (actualizada), apuntamos a ventas masivas en todo el mundo, con literalmente millones de usuarios. Con el mejor hardware e indexación del mundo, un solo servidor de base de datos no soportará la carga, por lo que tenemos que poder distribuirlo en varios servidores. Y una vez que tiene que buscar en qué servidor se encuentran los datos de cualquier cliente, no es mucho más trabajo darles una base de datos dedicada, lo que simplifica las cosas en términos de mantener los datos de las personas cuidadosamente segregados.

Respuesta a inquietudes

• Reiniciar el servidor lleva mucho tiempo: está bien, pero en funcionamiento normal no tenemos la intención de reiniciar ningún servidor. El sistema finalmente debe estar en línea las 24 horas del día, los 7 días de la semana, por lo que si vamos a tener tiempo de inactividad, de todos modos habrá que programarlo.
• Copias de seguridad / recuperación ante desastres: estamos utilizando CloudBerry, que automatiza todo. No es un problema.
• Nombrar bases de datos / localizarlas en SSMS: la convención de nomenclatura es fácil, solo se basa en el nombre del cliente. Agregue dígitos en serie si se comparten nombres.
• Mantenimiento: si cada base de datos es tan pequeña como imagino, no debería haber necesidad de reconstruir índices manualmente.
• Código de implementación: utilizamos Entity Framework, por lo que cada cambio de esquema se implementará automáticamente en cada base de datos con nuevas versiones. Sin embargo, es cierto que si descubrimos un problema de rendimiento en la producción que se puede solucionar con un simple ajuste de índice, no es tan fácil simplemente sacarlo. Por otro lado, dado que cada base de datos es tan pequeña, es poco probable que haya problemas de rendimiento superiores en los fragmentos de producción. Y la base de datos común sigue siendo una única base de datos, a la que no se aplican estas preocupaciones.

Estaré encantado de tener noticias tuyas en los comentarios si crees que me falta algo.