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

Question

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

entiendo que para algunos proyectos, los clientes necesitan tener 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 directamente a la base de datos, ¿hay alguna ventaja con el uso de una base de datos por cliente? Parece que, en términos de flexibilidad, es mucho más simple usar una sola base de datos con una sola 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 mucha 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 ...

la gente que he oído citan que las bases de datos más lento con un gran número de registros, pero cualquier base de datos relacional con algún mérito no va a tener ese problema - en especial si se utilizan los índices y las claves adecuadas.

¡Cualquier entrada es muy apreciada!

Answer 1

Supongamos que no hay pena de escalamiento para almacenar todos los clientes en una base de datos; para la mayoría de las personas, y las bases de datos/consultas bien configuradas, esto será bastante cierto en estos días. Si no eres una de estas personas, bueno, 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 aislado: no hay una situación posible en la que una actualización de la base de datos pueda sobrescribir, dañar, recuperar o alterar datos pertenecientes a otro cliente. Esto también simplifica el modelo, ya que no necesita considerar el hecho de que los registros pueden pertenecer a otro cliente.

Usted también obtiene beneficios de la separabilidad - es trivial para sacar los datos asociados a un cliente determinado, y moverlos a un servidor diferente. O restaure una copia de seguridad de ese cliente cuando llame para decir "¡Hemos eliminado algunos datos clave!", Utilizando los mecanismos de base de datos incorporados.

Usted recibe la movilidad servidor fácil y gratis - si outscale un servidor de base de datos, sólo puede albergar nuevos clientes en otro servidor. Si estuvieran todos en una base de datos, necesitaría obtener hardware más robusto o ejecutar la base de datos en varias máquinas.

Obtiene versiones sencillas: si un cliente desea permanecer en la versión de software 1.0 y otra quiere 2.0, donde 1.0 y 2.0 usan esquemas de base de datos diferentes, no hay problema, puede migrar uno sin tener que sacarlos de uno base de datos.

Puedo pensar en unas pocas docenas más, supongo. Pero en general, el concepto clave es "simplicidad". El producto administra un cliente y, por lo tanto, una base de datos. Nunca hay ninguna complejidad del problema "Pero la base de datos también contiene otros clientes". Se ajusta al modelo mental del usuario, donde existen solos.Las ventajas, como poder hacer informes fáciles para todos los clientes a la vez, son mínimas: ¿con qué frecuencia desea un informe en todo el mundo, en lugar de solo un cliente?

Answer 2

Bueno, ¿y si uno de sus clientes le dice a restaurar a una versión anterior de sus datos debido a algún trabajo de importación fallida o similar? Imagine cómo se sentirían sus clientes si les dijera "no puede hacerlo, 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 3

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

Answer 4

Gracias por su aporte - todos puntos excelentes y muy válidos. Supongo que estoy buscando más flexibilidad de actualización. 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 simple hacerlo en una sola base de datos. Si tuviera que replicar este cambio en 1000 bases de datos separadas, la posibilidad de error aumenta. ¿Qué pasa si una operación falla? ¿Cuánto tiempo lleva actualizar a cada cliente?

Si se guardan las copias de seguridad adecuadas (o si su base de datos se estructuró donde los datos nunca se sobrescribieron realmente), restaurar datos para un cliente en particular es trivial.

La simplicidad del código, si bien es importante, en realidad no se vuelve extremadamente complicado. Dependiendo del lenguaje utilizado y las metodologías, es simple crear objetos que representen solo a ese cliente específico (que almacena una ID de Cliente particular) y el resto del proyecto solo tiene que ser codificado para un solo objeto (algo así como un solo cliente)

La escalabilidad es algo a tener en cuenta: 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úster, e incluso sin agrupar, parece ser un pequeño cambio apuntar a cada cliente a un servidor de bases de datos que aloja la base de datos universal (para que pueda tener dos o tres servidores de bases de datos solo una sola base de datos, por ejemplo). Este enfoque mantiene el proceso de actualización limitado a solo tres bases de datos.

Answer 5

Hay un par de significados de "base de datos"

• la caja de hardware
• el software en ejecución (por ejemplo, "el oráculo")
• el conjunto particular de los archivos de datos
• lo particular login o esquema

Es probable que Joel sea una de las capas inferiores. En este caso, es solo una cuestión de administración de la configuración del software ... no tiene que parchear 1000 servidores de software para arreglar un error de seguridad, por ejemplo.

Creo que es una buena idea, por lo que un error de software no filtra información entre los clientes. Imagínese el caso con una cláusula where errante que me mostró los datos de sus clientes, así como los míos.

Answer 6

Para hacerlo simple. Puede estar seguro de que su cliente solo está viendo sus datos. El cliente con menos registros no tiene que pagar la multa 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 todo está indexado y optimizado habrá consultas que determinen que tienen que escanear cada registro.

Answer 7

Aquí es un enfoque que he visto antes:

• Cada cliente tiene una cadena de conexión única almacenada en una base de datos maestros 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.
• Los scripts se crean para migrar todos los datos de los clientes a una nueva base de datos si es necesario, y solo la cadena de conexión del cliente debe actualizarse para que apunte a la nueva ubicación.

Esto permite utilizar una única base de datos al principio, y luego segmentar fácilmente más adelante una vez que tiene una gran cantidad de clientes, o más comúnmente cuando hay un par de clientes que usan el sistema en exceso.

Descubrí que restaurar los datos específicos de los 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.

Al usar una sola base de datos por cliente, se encuentra con un gran problema de mantener todos los clientes funcionando en la misma versión de esquema, y ​​eso ni siquiera considera trabajos de respaldo en una gran cantidad de bases de datos específicas del cliente. Restaurar los datos de forma natural es más fácil, pero si se asegura de no eliminar los registros permanentemente (simplemente marque con un indicador borrado o muévase a una tabla de archivos), entonces tendrá menos necesidad de restaurar la base de datos en primer lugar.

Answer 8

En cuanto al dolor de actualizar 1000 servidores de bases de datos a la vez, una automatización bastante simple debería ocuparse de eso. Siempre que cada base de datos mantenga un esquema idéntico, entonces realmente no será un problema. También usamos la base de datos por enfoque de cliente, y funciona bien para nosotros.

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 de multitenencia lo que se refiere a su modelo de datos aquí: http://www.ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx

Answer 9

En las industrias reguladas tales como cuidado de la salud que puede ser un requisito de una base de datos por cliente, posiblemente, incluso un servidor de base de datos independiente.

La respuesta simple a la actualización de varias bases de datos cuando se 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úster no es realmente una solución al problema de los índices y escaneos completos de tablas. Si te mueves a un clúster, 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, pero se pueden tratar de otras maneras (algunas personas todavía necesitarán un clúster, pero la mayoría probablemente no).

Me interesaría escuchar un poco más de contexto sobre usted, ya que la agrupación no es un tema simple y es costoso de implementar en el mundo de RDBMS. Se habla mucho/se jacta de la agrupación en el mundo no relacional Google Bigtable, etc., pero resuelven un conjunto diferente de problemas y pierden algunas de las características útiles de un RDBMS.

Answer 10

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