¿En qué punto una base de datos por cliente se vuelve inviable?

Para uno de nuestros sistemas, tenemos datos confidenciales del cliente y almacenamos los datos de cada cliente en una base de datos separada. Tenemos alrededor de 10-15 clientes para ese sistema.

Sin embargo, estamos desarrollando un nuevo sistema que tendrá entre 50 y 100 clientes, tal vez más. Estoy pensando que podría ser inviable tener una base de datos por cliente en este caso (para almacenar registros confidenciales e historial de auditoría). Sin embargo, no sé si esto es perfectamente normal o no, o si hay otra forma de mantener la seguridad.

Tiene alguna idea sobre esto?

Administrar 100 o 500 bases de datos realmente no es tan diferente de administrar 5 o 10: solo tiene que adoptar la automatización y tener un plan de escalabilidad implementado (y no planea usar características de alto costo por base de datos como la duplicación en todos clientela).

En mi trabajo anterior usamos esta arquitectura y nunca hubiera pensado en fusionar dos clientes en una sola base de datos, aunque algunos de los desafíos pueden ser "difíciles".

Los grandes beneficios son modelos de recuperación independientes ( apueden ser simples, bcompletos, etc.), la capacidad de restaurar a un punto en el tiempo (o eliminar por completo) a un cliente sin interrumpir a otros, la capacidad de mover sin problemas a un cliente con muchos recursos a su propio almacenamiento oa un servidor completamente diferente con muy poca transparencia (actualiza un archivo o tabla de configuración que le dice a la aplicación dónde encontrar ese cliente).

Abordo varias de las objeciones, y / o cómo abordar los problemas, en estas publicaciones:

• Manejo de un número creciente de inquilinos en la arquitectura de bases de datos de múltiples inquilinos

• ¿Base de datos multiinquilino usando SQL Server 2008?

• Automatización de copias de seguridad de gran cantidad de bases de datos

Dicho todo esto, yo no creo que ninguno de nosotros puede decir que el punto en el cual la administración es un procedimiento práctico para usted - sólo sé que cualquiera que sea específica desafía que se encuentren, se puede preguntar acerca de esos problemas de forma individual.

Le recomiendo que lea la Arquitectura de datos de múltiples inquilinos , un documento técnico que analiza las opciones que tiene, y los pros y los contras. Para resumir, ofrece tres opciones:

• DB separadas
• esquemas separados
• esquema compartido

Ahora se encuentra en una etapa de DB separada, que ofrece la mejor separación (aislamiento entre inquilinos), pero es la más difícil de administrar. A medida que crezca y se convierta en cientos de inquilinos, se dará cuenta de que la logística de administrar cientos de bases de datos está lejos de ser trivial. Piense en la copia de seguridad-restauración (ubicación de los archivos respaldados, trabajos, programaciones, etc.). Piense cómo supervisará y administrará la asignación de archivos, el espacio en disco utilizado y el crecimiento de la base de datos en cientos de bases de datos. ¿Piensa cuál será su escenario de alta disponibilidad / recuperación ante desastres en un futuro cercano con 1000 inquilinos? ¿1000 DBs reflejados, 1000 sesiones de envío de registros? Piensa qué pasaría si en 6 meses tu equipo de desarrollo se te acerca y te dice "Sé cómo darle esta increíble característica a nuestro producto, ¡usaremos la Replicación transaccional!", ¿Qué dirás? "claro, déjenme configurar 500 editores,"! No es imposible administrar cientos de bases de datos, pero si planea hacerlo, es mejor que perfeccione sus habilidades de PowerShell y deje de usar las herramientas de administración de la interfaz de usuario en este momento .

Además, debe tener en cuenta que múltiples (cientos) bases de datos tienen un impacto medible en el rendimiento y el costo:

• el espacio en disco físico se usa de manera menos eficiente (cada base de datos debe tener un espacio libre, tendrá ese espacio multiplicado por el número de DB)
• No hay forma de que pueda crear un disco de registro dedicado para tareas intensivas de escritura, tendrá que mover todos esos LDF a un (o más) almacenamiento SSD
• las escrituras de registros serán menos eficientes en las confirmaciones frecuentes, ya que se extienden a través de muchos registros de bloques de registro individuales versus agregados en uno (obtendrá bloques de registro infrautilizados). Vea Qué es un LSN: Número de secuencia de registro para comprender de qué estoy hablando.

Los DB separados tienen algunas ventajas, aunque debido al aislamiento, la principal ventaja es la copia de seguridad / restauración independiente.

Sin embargo, escenarios como el suyo son un candidato perfecto para las bases de datos SQL Azure . Sin administración de espacio en disco, sin necesidad de proporcionar HA / DR, crecer a cientos / miles de bases de datos, etc.

En mi trabajo anterior, alojábamos no solo una base de datos por cliente, ¡en la mayoría de los casos, era más que eso! Cuando me fui, había más de 4.500 bases de datos ejecutándose en un clúster MariaDB, casi 7.000 en otro clúster (irónicamente más pequeño) y 4 "fragmentos" (servidores web y bases de datos completamente independientes e independientes, incluso en un centro de datos completamente separado) cada alojamiento 200-500 bases de datos en un solo servidor MySQL. Y esa compañía todavía está creciendo a buen ritmo.

Lo largo y lo corto es que el éxito de esa compañía prueba que tal arquitectura es realmente factible. (Advertencia: ¡Contrariamente a las aparentes ganancias en el aislamiento mediante el uso de bases de datos separadas, se accedió a todos los datos a través de un trío de aplicaciones estrechamente acopladas que utilizaron el mismo usuario / paso de la base de datos! Sospecho que el rendimiento puede haber sufrido muy ligeramente si cada cliente tenía un usuario / pase separado, pero solo ligeramente).

Según mis experiencias trabajando en estrecha colaboración con los administradores del sistema (técnicamente, yo era un programador de la empresa, pero en realidad era el mejor DBA que tenían, ¡y la única persona que tenían que sabía cómo configurar un firewall!), Relacionado con el rendimiento las preocupaciones se redujeron a accesos concurrentes, complejidad / tiempo de consulta, rendimiento del índice, etc. - todos los sospechosos habituales, en otras palabras, y el número de bases de datos en el servidor no jugaron un papel discernible, una conclusión afirmada por el especialista altamente remunerado consultores que consultamos regularmente.

La conclusión es que debe centrar sus preocupaciones en su aplicación, en su infraestructura y no en la cantidad de bases de datos que tiene. Todos esos otros factores serán más que suficientes para mantenerlo ocupado resolviendo problemas de rendimiento y cuellos de botella.