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

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, en cuanto a bases de datos. ¿Debo usar una sola base de datos y agregar columnas específicas del cliente a cada una de las tablas, o debo crear una base de datos para cada nuevo cliente? Un factor importante es la automatización: quiero que sea muy simple crear un nuevo cliente (y tal vez abrir la posibilidad de registrarse por ti mismo).

Posibles desventajas que se me ocurren al usar una base de datos:

• Falta de extensibilidad
• Problemas de seguridad (aunque los errores no deberían estar allí en primer lugar )

¿Qué piensas de esto? ¿Tiene alguna idea de qué solución es más probable que las empresas mencionadas hayan elegido?

Answer 1

Normalmente agrego ClientID a todas las tablas y voy con una base de datos. Pero como la base de datos suele ser difícil de escalar, también haré posible la ejecución en diferentes instancias de base de datos para algunos o todos los clientes.

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

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

Answer 2

Escuche el podcast de Stackoverflow donde Joel y Jeff hablan sobre la misma pregunta. Joel está hablando de su experiencia al ofrecer una versión alojada de su software. Señala que agregar identificadores de clientes en toda su base de datos complica el diseño y el código (¿está seguro de que no olvidó agregarlo a alguna cláusula WHERE?) Y complica la función de hospedaje, como las copias de seguridad específicas del cliente.

Estaba en el episodio # 20 o # 21 (verifique las transcripciones para más detalles).

Answer 3

En mi opinión, dependerá de su probable base de clientes. Si pudiera entrar en una situación en la que los archirrivales están usando su sistema, entonces estaría mejor con bases de datos separadas. También depende de cómo las bases de datos múltiples sean implementadas por su DBMS. Si cada base de datos tiene una copia separada de la infraestructura, eso sugiere una base de datos única (o un cambio de DBMS). Si una sola copia de la infraestructura puede servir a varias bases de datos, entonces iré por 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 sola base de datos. Piense en la eliminación de un cliente; de nuevo, mucho más fácil con bases de datos separadas.

(La parte de 'infraestructura' está mal expresada porque hay diferencias importantes entre los diferentes DBMS sobre lo que constituye una 'base de datos' en comparación con una 'instancia de servidor', por ejemplo. Agregar : la pregunta es etiquetado 'mysql', así que tal vez esos pensamientos no sean completamente relevantes.)

Añadir : Un problema más: con varios clientes en una sola base de datos, cada consulta SQL necesitará asegurarse de que se seleccionen los datos para el cliente correcto. Eso significa que el SQL 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 (como 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 empresas, no creo que sea aceptable (para las empresas, y posiblemente no para las personas jurídicas) compartir bases de datos.

Answer 4

• DESARROLLO Para un desarrollo rápido, use una base de datos por cliente. Piense en lo fácil que será realizar 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 los primitivos de su base de datos.

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

• NEGOCIOS Si su plan de negocios es tener muchos clientes pequeños (piense en Hotmail), probablemente debería trabajar en una sola base de datos. Y haga que todas las tareas administrativas tales como registro, eliminación, migración de datos, etc. estén completamente automatizadas y expuestas en una interfaz amigable. Si planea tener docenas o hasta cientos de grandes clientes, puede trabajar en un DB por cliente y tener implementados scripts de administración del sistema que pueden ser operados por su personal de atención al cliente.

Answer 5

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 que eso, así que deberías investigar esto. Me gustaría ir con su enfoque.

Hay otro gran artículo sobre eso en MSDN. Explica en profundidad cuándo debe utilizar 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 de base de datos que desea utilizar [seguridad a nivel de fila], dependiendo del DBMS que utilice (estoy seguro de que es posible en MS SQL Server y Oracle, probablemente en IBM DB2 también). Puede usar trucos como seguridad de nivel de fila en mySQL para lograr resultados similares (vistas + activadores) ).

Answer 6

Para la multitenencia, el rendimiento generalmente aumentará los recursos que gestione para compartir entre los inquilinos, vea

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

Así que si puedes, ve con la base de datos única. Estoy de acuerdo en que los problemas de seguridad solo se producirían 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).

También hay formas de proporcionar extensibilidad. Por ejemplo, podría crear una sola tabla con atributos de extensión (con clave por inquilino, registro base e id de atributo de extensión). O puede crear tablas de extensión por arrendatario, de modo que cada arrendatario tenga su propio esquema de extensión.

Answer 7

Cuando estás diseñando una base de datos multiusuario, generalmente tienes tres opciones:

1. Tener una base de datos por inquilino
2. tener un esquema por inquilino
3. Haga que todos los inquilinos compartan la misma tabla (s)

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

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

• Si está construyendo para la escala: haga que todos los inquilinos compartan las mismas tablas
• Si está construyendo para aislamiento: cree una base de datos por inquilino

Por ejemplo, Google y Salesforce siguen el primer patrón y hacen que sus inquilinos compartan las mismas tablas. Por otro lado, Stackoverflow 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. Este artículo sobre el diseño de su La base de datos de SaaS para escala habla sobre las compensaciones y proporciona un resumen en el contexto de PostgreSQL.

Answer 8

Otro punto a considerar es que puede tener la obligación legal de mantener los datos de una compañía separados de los demás.

Answer 9

Por lo general, tener una base de datos por cliente no se escala bien. MySQL (y probablemente otras bases de datos) mantiene recursos abiertos por tabla, esto no se presta bien a 10k + tablas en una instancia, lo que ocurriría en una situación de multitenencia a gran escala.

Por supuesto, si tiene algún otro problema que cause otros problemas antes de llegar a este nivel, es posible que esto no sea relevante.

Además, " fragmentación " es probable que una aplicación para múltiples inquilinos sea lo correcto a la larga, a medida que su aplicación se haga más y más grande.

Sharding no significa, sin embargo, una base de datos (o instancia) por inquilino, sino una por shard o conjunto de fragmentos, que pueden tener varios inquilinos cada uno. Necesitará descubrir los parámetros de ajuste correctos para usted, probablemente en producción (por lo tanto, probablemente deba ser bastante ajustable desde el principio)

€ No puedo garantizarlo.

Answer 10

Puede comenzar con una sola base de datos y particionarla a medida que la aplicación crezca. Si haces esto, hay algunas cosas que recomendaría:

1) Diseñe la base de datos de manera que pueda particionarse 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 tienes una base de datos, asegúrate de hacer una copia de seguridad en otro servidor físico. En el caso de una conmutación por error, puede revertir el tráfico a este otro servidor y seguir teniendo sus datos intactos.