¿Qué problemas tendré al crear una base de datos por cliente?

Recuerdo de los podcasts de stackoverflow que Fog Creek usa una base de datos por cliente para Fogbugz . Supongo que eso significa que los servidores Fogbugz On Demand tienen 10 de miles de bases de datos.

Recién estamos comenzando a desarrollar una aplicación web y tenemos un problema similar que resolver (muchos clientes con sus propios datos aislados).

¿Qué problemas debo esperar con el uso de una base de datos por cliente? ¿Cómo puedo resolverlos?

Mis pensamientos iniciales

Ventajas de una base de datos por cliente

• Esquema de base de datos más simple
• Copias de seguridad más simples: puede hacer copias de seguridad de cada cliente a su vez sin que realmente afecte a otros clientes.
• Facilita la exportación de datos de un cliente determinado.
• Mejor rendimiento de la memoria caché: una escritura en una de las tablas más activas solo afecta a ese único cliente que realizó la escritura.
• Más fácil de escalar a través del hardware. Por ejemplo, cuando necesitamos pasar de 1 a 2 servidores, simplemente trasladamos la mitad de nuestros clientes al nuevo servidor.

Desventajas

• ¿Puede MySQL hacer frente a 5.000 bases de datos? ¿El rendimiento apestaría?
• Los cambios en el esquema pueden ser difíciles de replicar en todas las bases de datos. Realmente tendríamos que tener un plan automatizado para esto, como versionar el esquema y un script que comprenda cómo llevar una base de datos de una versión a otra.
• Hacer cualquier cosa que sea común a todos nuestros clientes puede ser incómodo o imposible
• Similar a lo anterior, pero cualquier análisis que deseamos realizar en todos nuestros clientes puede ser imposible. ¿Cómo deberíamos rastrear el uso en todos los clientes, por ejemplo?

Esta solución se llama diseño multiinquilino donde cada inquilino (cliente) tiene su propia base de datos. Dado eso, hay algunas otras consideraciones para el enfoque alternativo que es una base de datos única:

1. Con una sola base de datos, todos deben estar en la misma versión sin importar qué. No es posible actualizar algunos clientes y no otros. Esto puede ser problemático si un cliente quiere una revisión de una aplicación que no está lista para su lanzamiento general.
2. Con una única base de datos, cuando realiza una actualización, todos los clientes están inactivos. Si algo sale mal, cada cliente está jodido.
3. Con una sola base de datos, es mucho más difícil limitar los recursos. Es decir, si un cliente está manipulando la base de datos, es más difícil darles más recursos separados de los demás.
4. Es mucho más difícil permitir que los usuarios alojen sus propias versiones de su aplicación. Si está creando una solución que será utilizada por las grandes empresas, esto a menudo no es un comienzo. Su departamento de TI quiere un control completo sobre el acceso al sistema.
5. Probablemente sea más barato escalar bases de datos en lugar de escalarlas. Es decir, tener que invertir en hardware más rápido para alojar una base de datos para descartarlas probablemente sea más costoso que poder escalar clientes a servidores de bases de datos más pequeños y menos costosos. No puedo decir esto definitivamente porque depende en gran medida del software del servidor. Si te quedas con MySQL, esto probablemente sea cierto porque los costos de licencia son insignificantes. Sin embargo, si pasa a SQL Server, por ejemplo, el escalado se vuelve mucho más costoso a menos que use un entorno VPS y el costo-beneficio de escalar en lugar de escalar los cambios. Sin embargo, puedo decir que una vez que su base de datos se vuelve muy grande, la administración requiere niveles cada vez mayores de experiencia. Las bases de datos muy grandes requieren jugar con múltiples grupos de archivos y empujar ciertos índices a diferentes ejes para obtener un mejor rendimiento. En resumen, se pueden complicar muy rápidamente.

Tener bases de datos separadas significa que debe crear un mecanismo de actualización que coincida con la versión de la base de datos con la versión de la aplicación / sitio. Sin embargo, las bases de datos separadas proporcionan un aislamiento superior de los datos y la OMI tiene un costo de alojamiento más bajo. No es una solución para todos los escenarios. Si su sistema nunca iba a estar alojado fuera de su alojamiento y necesitaba aumentar la escala de los clientes rápidamente y era deseable tener a todos los usuarios en la misma versión de la aplicación y el esquema de la base de datos, entonces tener una sola base de datos es un mejor enfoque.

En mi experiencia, no debería crear una base de datos por cliente. Dejame darte un ejemplo:

El año pasado trabajé con 70 bases de datos (mucho menos de 5000), cada una con el mismo esquema y todas. En teoría, las cosas irían según lo planeado (como mencionas en la sección de ventajas), pero en realidad no tanto. Tuvimos muchos problemas con la actualización de esquemas, soporte al usuario, actualización de software, lo que sea. Fue horrible.

Usamos Firebird y me contrataron mucho después de que se envió el producto, pero esto me dio el conocimiento para nunca trabajar con bases de datos separadas.

No digo que no puedas lograrlo, digo que las cosas pueden salir muy mal y, para ser sincero, tu lista de ventajas no sonaba lo suficientemente atractiva como para correr el riesgo. La mayoría de ellos se pueden lograr con una sola base de datos.

Es probable que desee mantener otra base de datos para rastrear en qué versión se encuentra cada cliente, para poder realizar un seguimiento de cuáles han sufrido o no la última ronda de modificaciones.

Escribir las actualizaciones no sería tan difícil ... podría escribir algo que mire el catálogo de bases de datos y aplique los cambios necesarios para obtener cada base de datos a la última versión, posiblemente omitiendo las que no deberían actualizarse por alguna razón.

Como las 'bases de datos' de mysql son solo esquemas, como señaló Gaius, si todo se ejecuta desde la misma instancia del servidor, puede calificar el nombre de las tablas que está tratando de modificar u obtener información de:

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

...

Si comienza a dividir las cosas en varios servidores, aún puede escribir algo que haga conexiones a múltiples servidores para que pueda aplicar todos los cambios; para la analítica, nuevamente, podría establecer un montón de enlaces de bases de datos usando tablas federadas en su base de datos maestra para acceder a los datos desde un lugar, como estaría leyendo en las tablas.

...

Además, tenga en cuenta que no están usando mySQL para el intercambio de pila, están usando SQL Server.

Y no tengo idea de qué tipo de sobrecarga de rendimiento habría en mysql a esa escala, no creo que haya pasado más de 30 'bases de datos' en mysql.

Tengo un cliente de alojamiento web / base de datos que tiene más de 750 bases de datos de clientes con el mismo número de tablas (162) y la misma estructura de tablas. Combinados, todos los datos de clientes de mi cliente totalizan 524 GB (95% InnoDB)

Imagine que todas estas bases de datos compiten por 13G del grupo de búferes innodb en nueve servidores de base de datos mediante replicación circular. Escalar con esa configuración de hardware no fue suficiente. Inmediatamente, le recomendamos al cliente que escale.

Recientemente migramos este cliente a 3 servidores de base de datos con mucha más potencia (a toda costa, manténgase alejado de SSD en entornos de alta escritura, ¡SIEMPRE!). Los actualizamos de MySQL 5.0.90 a MySQL 5.5.9. Se vieron diferencias dramáticas casi al instante.

El escalado horizontal también debe considerarse porque si tiene cientos de clientes que acceden a la misma memoria y recursos de disco, el escalado horizontal reduce su uso linealmente (O (n)) donde n se basa en la cantidad de servidores DB en un entorno multimaestro.

En el caso de mi cliente, mi empresa lo está reduciendo de 9 servidores de base de datos (código cuádruple, 32 GB de RAM, 824G RAID10) a servidores de base de datos más rápidos (doble HexaCore [eso es 12 CPUs], 192 GB de RAM, 1.7TB RAID10) de MySQL 5.5 .9 (para aprovechar las múltiples CPU de la tabla). Además, imagine un grupo de búferes innodb de 150 GB en 50 particiones de 3 GB cada uno (los múltiples grupos de búferes InnoDB son una nueva característica en MySQL 5.5). Una escala menor, pero una escala masiva, había funcionado para la infraestructura única de mi cliente.

Moraleja de la historia : Ampliación o fuera no siempre es la solución si tiene tablas mal diseñados. Lo que quiero decir es esto: si las páginas de índice tienen una población de claves asimétrica para índices de varias columnas, la consulta de claves de las partes asimétricas de los índices conduce al escaneo de tablas después del escaneo de tablas, o al menos índices que nunca se utilizan debido a que MySQL Query lo descarta Optimizador. Simplemente no hay sustituto para el diseño adecuado.

MySQL crea bases de datos en directorios separados, por lo que mucho depende del sistema operativo subyacente y cuántas carpetas / archivos maneja que pueda manejar. No debería ser un problema con los sistemas operativos modernos, pero de ahí vendrá gran parte del cuello de botella.

No hay nada que diga que tiene que alojar diferentes versiones de la base de datos o la aplicación. ¿Qué tiene de malo simplemente aislar los datos haciendo una base de datos por cliente y teniendo una versión de la base de datos y la aplicación? Por supuesto, cada cliente db tendría que ser clonado a partir de una plantilla de la versión de trabajo actual. Desde el punto de vista de seguridad y aislamiento de datos, creo que esto es ideal.

El único inconveniente que puedo ver es que tendría que actualizar manualmente cada base de datos al crear una nueva versión. Sin embargo, esto podría automatizarse fácilmente.