database - para - tutorial django

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

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.
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 apuntar a la nueva ubicación.

Esto permite usar 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 tiene un par de clientes que usan en exceso el sistema.

Descubrí que restaurar 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 única base de datos por cliente, se encuentra con un gran problema de mantener a 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.

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 acceso directo a todos sus datos; en dicha aplicación, 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 ...

He oído a gente citar 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 va a tener ese problema, especialmente si se usan los índices y las claves adecuadas.

¡Cualquier aporte es muy apreciado!

Bueno, ¿qué ocurre si uno de tus clientes te dice que restaures a una versión anterior de sus datos debido a algún trabajo de importación fallido 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".

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 sobre multi-tenancy 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

En industrias reguladas como la atención médica, puede ser un requisito de una base de datos por cliente, posiblemente incluso un servidor de base de datos separado.

La respuesta simple a la actualización de múltiples 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 esto porque 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.

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.

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 copias de seguridad adecuadas (o si su base de datos se estructuró donde los datos nunca se sobrescribieron), la restauración de datos para un cliente en particular es trivial.

La simplicidad del código, aunque 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 sola 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.

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 archivos de datos
el inicio de sesión o esquema particular

Es probable que Joel signifique 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, para que un error de software no filtre 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.

Para mantenerlo 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.

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

Supongamos que no hay una penalización de escala 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.

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 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.

Obtiene movilidad de servidor fácil y gratuita: si supera un servidor de base de datos, puede alojar 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.

Obtendrás versiones sencillas: si un cliente desea permanecer en la versión de software 1.0 y otro quiere 2.0, donde 1.0 y 2.0 usan diferentes esquemas de base de datos, no hay problema, puedes migrar uno sin tener que sacarlos de una 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?