¿Cuáles son las ventajas de utilizar una única base de datos para CADA cliente?

Question

En una aplicación centrada en una base de datos diseñada para múltiples clientes, siempre pensé que era "mejor" usar una única base de datos para TODOS los clientes, asociando registros con índices y claves adecuados.Al escuchar el podcast Stack Overflow, escuché a Joel mencionar que FogBugz usa una base de datos por cliente (por lo que si hubiera 1000 clientes, habría 1000 bases de datos).¿Cuáles son las ventajas de utilizar esta arquitectura?

Entiendo que para algunos proyectos, los clientes necesitan acceso directo a todos sus datos; en una aplicación de este tipo, es obvio que cada cliente necesita su propia base de datos.Sin embargo, para proyectos en los que un cliente no necesita acceder a la base de datos directamente, ¿existe alguna ventaja al utilizar una base de datos por cliente?Parece que en términos de flexibilidad, es mucho más sencillo utilizar una única base de datos con una única copia de las tablas.Es más fácil agregar nuevas funciones, es más fácil crear informes y es más fácil de administrar.

Tenía bastante confianza en el método de "una base de datos para todos los clientes" hasta que escuché a Joel (un desarrollador experimentado) mencionar que su software utiliza un enfoque diferente, y estoy un poco confundido con su decisión...

He escuchado a personas decir que las bases de datos se ralentizan con una gran cantidad de registros, pero cualquier base de datos relacional con algún mérito no tendrá ese problema, especialmente si se utilizan índices y claves adecuados.

¡Cualquier aporte es muy apreciado!

Answer 1

Supongamos que no hay penalización de escala por almacenar todos los clientes en una base de datos;para la mayoría de las personas, y bases de datos/consultas bien configuradas, esto será bastante cierto en estos días.Si no eres una de esas personas, entonces el beneficio de una única base de datos es obvio.

En esta situación, los beneficios provienen de la encapsulación de cada cliente.Desde la perspectiva del código, cada cliente existe de forma aislada: no existe ninguna situación posible en la que una actualización de la base de datos pueda sobrescribir, corromper, recuperar o alterar datos pertenecientes a otro cliente.Esto también simplifica el modelo, ya que no es necesario considerar nunca el hecho de que los registros puedan pertenecer a otro cliente.

También obtiene los beneficios de la separabilidad: es trivial extraer los datos asociados con un cliente determinado y moverlos a un servidor diferente.O restaurar una copia de seguridad de ese cliente cuando llame para decir "¡Hemos eliminado algunos datos clave!", utilizando los mecanismos de base de datos integrados.

Obtiene movilidad de servidor fácil y gratuita: si supera la escala de un servidor de base de datos, puede alojar nuevos clientes en otro servidor.Si estuvieran todos en una base de datos, necesitaría obtener un hardware más potente o ejecutar la base de datos en varias máquinas.

Obtiene un control de versiones sencillo: si un cliente quiere permanecer en la versión de software 1.0 y otro quiere la versión 2.0, donde 1.0 y 2.0 usan diferentes esquemas de base de datos, no hay problema: puede migrar uno sin tener que sacarlo de una base de datos.

Supongo que se me ocurren unas cuantas docenas más.Pero en definitiva, el concepto clave es el de "simplicidad".El producto gestiona un cliente y, por tanto, una base de datos.Nunca hay ninguna complejidad por el problema "Pero la base de datos también contiene otros clientes".Se ajusta al modelo mental del usuario, donde existe solo.Las ventajas, como poder generar informes fácilmente sobre todos los clientes a la vez, son mínimas: ¿con qué frecuencia desea un informe sobre todo el mundo, en lugar de solo un cliente?

Answer 2

Aquí hay un enfoque que he visto antes:

• Cada cliente tiene una cadena de conexión única almacenada en una base de datos maestra de clientes.
• La base de datos está diseñada para que todo esté segmentado por CustomerID, incluso si hay un solo cliente en una base de datos.
• Se crean scripts para migrar todos los datos del cliente a una nueva base de datos si es necesario, y luego solo es necesario actualizar la cadena de conexión de ese cliente para que apunte a la nueva ubicación.

Esto permite usar una sola base de datos al principio y luego segmentarla fácilmente una vez que tenga una gran cantidad de clientes, o más comúnmente cuando tenga un par de clientes que usan en exceso el sistema.

Descubrí que restaurar datos específicos de clientes es realmente difícil cuando todos los datos están en la misma base de datos, pero administrar las actualizaciones es mucho más simple.

Cuando se utiliza una única base de datos por cliente, se encuentra con el gran problema de mantener a todos los clientes ejecutando la misma versión de esquema, y ​​eso ni siquiera considera los trabajos de respaldo en un montón de bases de datos específicas del cliente.Naturalmente, restaurar datos es más fácil, pero si se asegura de no eliminar registros permanentemente (simplemente márquelos con una marca de eliminación o muévalos a una tabla de archivo), entonces, en primer lugar, tendrá menos necesidad de restaurar la base de datos.

Answer 3

Para hacerlo simple.Puede estar seguro de que su cliente solo ve sus datos.El cliente con menos registros no tiene que pagar la pena de tener que competir con cientos de miles de registros que pueden estar en la base de datos pero no en los suyos.No me importa qué tan bien esté indexado y optimizado todo, habrá consultas que determinarán que deben escanear cada registro.

Answer 4

Bueno, ¿qué pasa si uno de sus clientes le pide que restaure sus datos a una versión anterior debido a algún trabajo de importación fallido o similar?Imagínese cómo se sentirían sus clientes si les dijera "no puede hacer eso, ya que sus datos se comparten entre todos nuestros clientes" o "Lo siento, pero sus cambios se perdieron porque el cliente X exigió una restauración de la base de datos".

Answer 5

En cuanto a la molestia de actualizar 1000 servidores de bases de datos a la vez, una automatización bastante simple debería solucionarlo.Siempre que cada base de datos mantenga un esquema idéntico, realmente no será un problema.También utilizamos el enfoque de base de datos por cliente y nos funciona bien.

Aquí hay un artículo sobre este tema exacto (sí, es MSDN, pero es un artículo independiente de la tecnología): http://msdn.microsoft.com/en-us/library/aa479086.aspx.

Otra discusión sobre el arrendamiento múltiple en relación con su modelo de datos aquí: http://www.ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx

Answer 6

Escalabilidad.Seguridad.Nuestra empresa también utiliza un enfoque de 1 DB por cliente.También hace que el código sea un poco más fácil de mantener.

Answer 7

Solo estoy agregando esta respuesta para incluir la palabra multiinquilino aquí.Estaba buscando esto, usando "multiinquilino" como consulta, y este no apareció.

Answer 8

Gracias por sus aportes, todos puntos excelentes y muy válidos.Supongo que estoy buscando más flexibilidad en las actualizaciones.Si necesita modificar el esquema para agregar una nueva característica (digamos para una aplicación web) o para mejorar las características existentes, es sencillo hacerlo en una sola base de datos.Si tuviera que replicar este cambio en 1000 bases de datos distintas, la posibilidad de error aumenta.¿Qué pasa si una operación falla?¿Cuánto tiempo lleva actualizar cada cliente?

Si se mantienen copias de seguridad adecuadas (o si su base de datos estaba estructurada de manera que los datos nunca se sobrescribieron), restaurar datos para un cliente en particular es trivial.

La simplicidad del código, si bien es importante, en realidad no resulta extremadamente complicada.Dependiendo del lenguaje utilizado y las metodologías, es sencillo crear objetos que representen solo a ese cliente específico (que almacena una ID de cliente particular) y el resto del proyecto solo debe codificarse para un solo objeto (algo así como un solo cliente). ).

La escalabilidad es algo a considerar: tiene razón en que es fácil tomar una única base de datos aislada y moverla a un servidor físico diferente;sin embargo, cada vez es más fácil agrupar servidores en clústeres, e incluso sin agruparlos, parece que sería un pequeño cambio apuntar a cada cliente a un SERVIDOR de base de datos que aloja la base de datos universal (por lo que podría tener dos o tres servidores de bases de datos que alojen por ejemplo, una sola base de datos cada uno).Este enfoque mantiene el proceso de actualización limitado a sólo tres bases de datos.

Answer 9

En sectores regulados, como el de la atención sanitaria, puede ser necesario disponer de una base de datos por cliente, posiblemente incluso de un servidor de base de datos independiente.

La respuesta simple para actualizar múltiples bases de datos cuando actualiza es realizar la actualización como una transacción y tomar una instantánea antes de actualizar si es necesario.Si está ejecutando bien sus operaciones, debería poder aplicar la actualización a cualquier cantidad de bases de datos.

La agrupación en clústeres no es realmente una solución al problema de los índices y los escaneos completos de tablas.Si te mudas a un grupo, muy pocos cambios.Si tiene muchas bases de datos más pequeñas para distribuir en varias máquinas, puede hacerlo de forma más económica sin un clúster.La confiabilidad y la disponibilidad son consideraciones que se pueden abordar de otras maneras (algunas personas seguirán necesitando un clúster, pero la mayoría probablemente no).

Me interesaría escuchar un poco más de contexto sobre esto porque la agrupación en clústeres no es un tema simple y su implementación en el mundo RDBMS es costosa.Se habla mucho sobre la agrupación en clústeres en el mundo no relacional de Google Bigtable, etc.pero están resolviendo un conjunto diferente de problemas y pierden algunas de las características útiles de un RDBMS.

Answer 10

Hay un par de significados de "base de datos"

• la caja de hardware
• el software en ejecución (p. ej."El oráculo")
• el conjunto particular de archivos de datos
• el inicio de sesión o esquema particular

Es probable que Joel se refiera a una de las capas inferiores.En este caso, es sólo una cuestión de gestión de la configuración del software...no es necesario parchear 1000 servidores de software para corregir un error de seguridad, por ejemplo.

Creo que es una buena idea para que un error de software no filtre información entre los clientes.Imagine el caso con una cláusula donde errónea que me mostrara sus datos de cliente además de los míos.