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


49

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?

2
Recuerde que "base de datos" significa cosas diferentes para diferentes personas. En el mundo de Oracle, una base de datos por usuario sería una exageración masiva. Pero en MySQL "base de datos" es sinónimo de "esquema".
Cayo

Lo digo en el sentido mysql. USE CompanyData;
Rik Heywood

1
Microsoft tiene un artículo detallado sobre la arquitectura de datos de múltiples inquilinos .
Nick Chammas

No diría que versionar el esquema es una desventaja ... más trabajo, pero mejor en general
Neil McGuigan

Respuestas:


41

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.


2
Ejecuto servicios web tanto con la base de datos compartida como con configuraciones de bases de datos separadas para múltiples inquilinos. Hay momentos en que ambos son la elección correcta. En la aplicación donde tengo una base de datos separada por cliente, me he encontrado con las mismas 5 razones por las que fue la elección correcta para esa aplicación.
Dan Grossman

La reciente base de datos en la nube sin servidor Aurora de Amazon supuestamente suministra automáticamente más recursos cuando es necesario para una mayor carga, y parecen alentar un diseño de base de datos única. Pero no lo entiendo completamente. Sin embargo, creo que iré con una única base de datos, con tablas separadas para cada usuario. Eso podría facilitar la división en bases de datos separadas si es necesario, y facilitará la realización de consultas agregadas contra todos los datos del usuario.
Buttle Butkus

Solo algo a tener en cuenta: tengo a todos mis clientes en una base de datos y uso una capa de código de base de datos que garantiza que cada consulta incluya criterios específicos del cliente. La parte peligrosa es cuando tienes que salir de la capa de la base de datos para hacer algo muy específico, como una horrible consulta grande y complicada donde los datos pueden filtrarse desde algún lugar inesperado.
Enigma Plus

14

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.


Implementamos una base de datos de listados múltiples que atiende a varios clientes. Terminamos en una situación en la que los clientes comenzaron a querer resultados personalizados. Para resolver este problema, clonamos los procesos almacenados y les dimos prefijos de nombre de cliente únicos y luego los llamamos desde la aplicación. Por otro lado, vendimos 150 tiendas web cada una con su propia base de datos separada (97% igual). Entonces, ambos pueden hacerse, depende de la situación.
Michael Riley - AKA Gunny

Agradable. No digo que no se pueda hacer, solo que no es tan fácil como parece, bien por ti, Gunny.
eiefai

1
Sería bueno si pudieras dar ejemplos de lo que salió mal exactamente. Claro que es más difícil mantener actualizadas todas las bases de datos, pero para decidir tenemos que poder medir pro vs contras.
Boris Callens

9

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.


¿Por qué no mantener una tabla de información de versión en su propia base de datos?
Boris Callens

@ Boris: porque es mucho más difícil conectarse a cada base de datos para pedirle su versión cuando tienes docenas o cientos de bases de datos. No es una mala idea para cada uno rastrearse a sí mismo, pero también vale la pena tener una lista maestra para el DBA
Joe

7

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.


2
Sé que esto es realmente antiguo, pero me pregunto cuál es el razonamiento detrás de su comentario sobre los SSD en entornos de alta escritura. ¿Puedes iluminarme?
elixenide

44
@EdCottrell Supongo que esta fue una advertencia sobre las escrituras limitadas de SSD. En algún momento, esto lleva el disco hasta el punto de que ya no se puede usar, creo que en los últimos años el TRIM y otras tecnologías se han integrado en los chips del controlador SSD para aliviar esos problemas en su mayor parte para que el SSD escriba no es un gran problema, aunque estoy seguro de que aún puede ser un problema.
shaunhusain

2

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.


1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.