¿Debo usar una configuración de base de datos única o múltiple para una aplicación multicliente?

Question

Estoy trabajando en una aplicación PHP que pretende facilitar el flujo de trabajo de la empresa y la gestión de proyectos, digamos algo como Basecamp y GoPlan.

No estoy seguro de cuál es el mejor enfoque, basado en la base de datos. ¿Debería usar una única base de datos y agregar columnas específicas del cliente a cada una de las tablas, o debería crear una base de datos para cada cliente nuevo? Un factor importante es la automatización: quiero que sea absolutamente simple crear un nuevo cliente (y tal vez abrir la posibilidad de registrarse por usted mismo).

contras posibles que puedo pensar en el uso de una base de datos:

• La falta de extensibilidad
• Los problemas de seguridad (aunque errores no deben estar allí en el primer lugar)

Lo ¿estás pensando en esto? ¿Tiene alguna idea de qué solución es más probable que las compañías anteriores hayan elegido?

Answer 1

Normalmente agrego ClientID a todas las tablas y voy con una base de datos. Pero dado que la base de datos suele ser difícil de escalar, también permitiré ejecutar en instancias de bases de datos diferentes para algunos o todos los clientes.

De esta manera puede tener un grupo de pequeños clientes en una base de datos y los grandes en servidores separados.

Sin embargo, un factor clave para el mantenimiento es que mantiene el esquema idéntico en todas las bases de datos. Habrá dolor de cabeza suficiente para administrar el control de versiones sin presentar esquemas específicos del cliente.

Answer 2

Para multiusuario, el rendimiento se suelen aumentar los recursos que administra más de compartir a través de los inquilinos, ver

http://en.wikipedia.org/wiki/Multitenancy

lo tanto, si se puede, ir con la base de datos única. Estoy de acuerdo en que los problemas de seguridad solo se producirán debido a errores, ya que puede implementar todo el control de acceso en la aplicación. En algunas bases de datos, aún puede usar el control de acceso a la base de datos mediante el uso cuidadoso de las vistas (para que cada usuario autenticado obtenga una vista diferente).

Hay formas de proporcionar extensibilidad también. Por ejemplo, puede crear una sola tabla con atributos de extensión (codificados por inquilino, registro base e ID de atributo de extensión). O puede crear tablas de extensión por inquilino, de modo que cada inquilino tenga su propio esquema de extensión.

Answer 3

En mi opinión, dependerá de su posible base de clientes. Si pudiera entrar en una situación en la que sus archirrivales usaran su sistema, entonces sería mejor que tuviera bases de datos separadas. También depende de cómo el DBMS implementa las múltiples bases de datos. Si cada base de datos tiene una copia separada de la infraestructura, eso sugiere una única base de datos (o un cambio de DBMS). Si varias bases de datos pueden ser servidas por una sola copia de la infraestructura, entonces buscaría bases de datos separadas.

Piense en la copia de seguridad de la base de datos. El cliente A dice "Por favor envíeme una copia de mis datos". Mucho, mucho más fácil en una configuración de base de datos separada que si se comparte una única base de datos. Piensa en eliminar un cliente; de nuevo, mucho más fácil con bases de datos separadas.

(La parte 'infraestructura' es comedido porque hay grandes diferencias entre los diferentes DBMS sobre lo que constituye una 'base de datos' frente a una 'instancia de servidor', por ejemplo Añadir:. La pregunta es etiquetada 'mysql' , así que tal vez esos pensamientos no son del todo relevante)

Añadir:. una de las cuestiones más - con varios clientes en una sola base de datos, todas las consultas SQL se va a necesitar para asegurarse de que los datos para el cliente correcto es elegido. Eso significa que el SQL va a ser más difícil de escribir y leer, y el DBMS tendrá que trabajar más duro en el procesamiento de los datos, y los índices serán más grandes, y ... Realmente iría con una base de datos separada por cliente para muchos propósitos.

Claramente, StackOverflow (por ejemplo) no tiene una base de datos separada por usuario; todos usamos la misma base de datos. Pero si estuviera ejecutando sistemas de contabilidad para diferentes compañías, no creo que sea aceptable (para las compañías, y posiblemente no para las personas jurídicas) compartir bases de datos.

Answer 4

Escucha el podcast de Stackoverflow donde Joel y Jeff hablan sobre la misma pregunta. Joel está hablando de su experiencia ofreciendo una versión alojada de su software. Señala que agregar identificadores de clientes en todo su DB complica el diseño y el código (¿está seguro de que no se olvidó accidentalmente de agregarlo a alguna cláusula WHERE?) Y complica la función de alojamiento, como las copias de respaldo específicas del cliente.

Fue en el episodio # 20 o # 21 (consulte las transcripciones para obtener más información).

Answer 5

Otro punto a considerar es que puede tener la obligación legal de mantener los datos de una empresa separados de los de otra persona '.

Answer 6

Tener una base de datos por cliente generalmente no se adapta bien. MySQL (y probablemente otras bases de datos) mantiene los recursos abiertos por tabla, esto no se presta bien a 10k + tablas en una instancia, lo que ocurriría en una situación de múltiples usuarios a gran escala.

Por supuesto, si tiene algún otro problema que causa otros problemas antes de llegar a este nivel, esto puede no ser relevante.

Además, es probable que "sharding" una aplicación multi-tenant sea lo correcto a medida que su aplicación se hace cada vez más grande.

Sharding no significa, sin embargo una base de datos (o instancia) por inquilino, pero uno por fragmento o conjunto de fragmentos, que puede tener varios inquilinos cada uno. Usted tendrá que descubrir los parámetros de ajuste adecuados para usted mismo, probablemente en la producción (por lo tanto es probable que tenga que ser bastante sintonizable desde el principio)

€ no puedo garantizarlo.

Answer 7

Puede comenzar con una única base de datos y particionarla a medida que crece la aplicación. Si hace esto, hay algunas cosas que recomendaría:

1) Diseño de la base de datos de manera que se puede dividir fácilmente. Por ejemplo, si los clientes van a compartir datos, asegúrese de que los datos se repliquen fácilmente en cada base de datos.

2) Cuando solo tiene una base de datos, asegúrese de que esté respaldada en otro servidor físico. En el caso de una conmutación por error, puede revertir el tráfico a este otro servidor y aún así tener sus datos intactos.

Answer 8

• DESARROLLO para el desarrollo rápido, utilizar una base de datos por cliente. Piense en lo fácil que será hacer una copia de seguridad, restaurar o eliminar los datos de un cliente. O para medir/monitorear/facturar el uso. No necesitará escribir código para hacerlo usted mismo, solo use sus primitivos de base de datos.

• PERFORMANCE Para obtener rendimiento, utilice una base de datos para todos. Piense en la agrupación de conexiones, memoria compartida, el almacenamiento en caché, etc.

• NEGOCIO Si su plan de negocio es tener un montón de clientes pequeños (piense hotmail) probablemente debería trabajar en una sola base de datos. Y tenga todas las tareas administrativas tales como registro, borrado, migración de datos, etc. completamente automatizadas y expuestas en una interfaz amigable. Si planea tener docenas o hasta unos pocos cientos de grandes clientes, entonces puede trabajar en una base de datos por cliente y tener scripts de administración del sistema implementados que puedan ser operados por el personal de soporte al cliente.

Answer 9

El siguiente screencast explica cómo se hace en salesforce.com. Usan una base de datos con una columna especial OrgId que identifica los datos de cada inquilino. Hay mucho más para eso, así que deberías ver esto. Yo iría con su enfoque.

Hay otro gran article sobre eso en MSDN. Explica en profundidad cuándo debe usar un enfoque compartido o aislado. Recuerde que tener una base de datos compartida para todos sus inquilinos tiene algunas implicaciones de seguridad importantes y si todos ellos comparten los mismos objetos DB que usted podría querer usar [seguridad a nivel de fila] - dependiendo del DBMS que use (estoy seguro de que es posible MS SQL Server y Oracle, probablemente en IBM DB2 también). Puede utilizar trucos como row level security in mySQL para obtener resultados similares (vistas + activadores).

Answer 10

Cuando se está diseñando una base de datos de múltiples usuarios, por lo general, tiene tres opciones:

1. Tener una base de datos por el inquilino
2. Ha un esquema por el inquilino
3. Han recibido todos los inquilinos compartir la misma mesa (s)

La opción que elija tiene implicaciones en la escalabilidad, extensibilidad y aislamiento. Estas implicaciones se han discutido ampliamente en diferentes StackOverflow questions y artículos de base de datos.

En la práctica, cada una de las tres opciones de diseño, con suficiente esfuerzo, puede abordar las preguntas en torno a la escala, los datos que varían entre los inquilinos y el aislamiento. La decisión depende de la dimensión principal para la que está construyendo. El resumen:

• Si usted está construyendo para la escala: Haga que todos los inquilinos comparten la misma tabla (s)
• Si usted está construyendo para el aislamiento: Crear una base de datos por el inquilino

Para ejemplo, Google y Salesforce siguen el primer patrón y hacen que sus inquilinos compartan las mismas tablas. Stackoverflow por otro lado sigue el segundo patrón y mantiene una base de datos por inquilino.El segundo enfoque también es más común en las industrias reguladas, como la salud.

La decisión se reduce a la dimensión principal para la que está optimizando el diseño de su base de datos. This article on designing your SaaS database for scale habla sobre las concesiones y proporciona un resumen en el contexto de PostgreSQL.