¿Cómo crear una base de datos de múltiples usuarios con estructuras de tablas compartidas?

Question

Nuestro software se ejecuta actualmente en MySQL. Los datos de todos los inquilinos se almacenan en el mismo esquema. Como usamos Ruby on Rails, podemos determinar fácilmente qué datos pertenecen a cada inquilino. Sin embargo, hay algunas empresas que temen que sus datos se vean comprometidos, por lo que estamos evaluando otras soluciones.

Hasta ahora he visto tres opciones:

• Multi-Base de datos (cada inquilino tiene su propia - casi lo mismo que 1 servidor por cliente)
• Multi-Esquema (no disponible en MySQL, cada arrendatario obtiene su propio esquema de una base de datos compartida)
• compartido esquema (nuestro enfoque actual, tal vez con el registro de identificación adicional en cada columna)

Multi-esquema es mi favorito (teniendo en cuenta co pts). Sin embargo, crear una nueva cuenta y hacer migraciones parece ser bastante doloroso, porque tendría que iterar sobre todos los esquemas y cambiar sus tablas/columnas/definiciones.

Q: Multi-Schema parece estar diseñado para tener tablas ligeramente diferentes para cada inquilino. No lo quiero. ¿Hay algún RDBMS que me permita utilizar una solución de múltiples inquilinos de múltiples esquemas, donde la estructura de la tabla se comparte entre todos los inquilinos?

P.S. Por multi quiero decir algo así como ultra-multi (más de 10.000 inquilinos).

Answer 1

Sin embargo, hay algunas empresas de supuesto que temen que sus datos podrían verse comprometidas , por lo que estamos evaluando otras soluciones .

Esto es desafortunado, ya que a veces los clientes tienen la idea errónea de que solo el aislamiento físico puede ofrecer suficiente seguridad.

Hay un artículo interesante de MSDN, titulado Multi-Tenant Data Architecture, que es posible que desee comprobar. Así es como los autores abordan la idea errónea hacia el enfoque compartido:

Un error común sostiene que aislamiento solamente física puede proporcionar una nivel adecuado de seguridad. En el hecho , los datos almacenados utilizando un enfoque compartido también pueden proporcionar datos fuertes de seguridad, pero requiere el uso de más patrones de diseño sofisticado .

En cuanto a las consideraciones técnicas y de negocios, el artículo hace un breve análisis sobre dónde un cierto enfoque podría ser más apropiado que otro:

El número, la naturaleza y las necesidades de los inquilinos que se pueden esperar servir a todos afecta su decisión de arquitectura de datos en formas diferentes. Algunas de las siguientes preguntas pueden inclinarlo hacia un enfoque más aislado de , mientras que otras pueden inclinarlo hacia un enfoque más compartido.

• ¿Cuántos posibles inquilinos espera apuntar? Puede estar en ninguna parte cerca de poder estimar uso prospectivo con autoridad, pero pensar en términos de órdenes de magnitud: ¿Está construyendo una aplicación para cientos de inquilinos? ¿Miles? Tens de miles? ¿Más? Cuanto más grande sea espere que su base de clientes sea, es más probable que desee considerar un enfoque más compartido.

• ¿Cuánto espacio de almacenamiento espera que ocupen los datos medios del inquilino? Si espera que algunos o todos los inquilinos a almacenen grandes cantidades de datos, el enfoque de la base de datos separada probablemente sea mejor. (De hecho, almacenamiento de datos requisitos pueden obligan a adoptar un modelo de -base de datos separada de todos modos. Si es así, Será mucho más fácil diseñar la aplicación así desde el empezando a pasar a un enfoque -base de datos independiente más adelante).

• ¿Cuántos usuarios finales concurrentes espera que soporte el cliente promedio? Cuanto mayor sea el número, más apropiado será un enfoque más aislado para cumplir con los requisitos del usuario final.

• ¿Espera ofrecer algún servicio de valor agregado por cada inquilino, como como copia de seguridad por inquilino y restaurar capacidad? Dichos servicios son más fáciles de ofrecer a través de un enfoque más aislado .

---

ACTUALIZACIÓN: Además de actualizar sobre el número esperado de los inquilinos.

El número esperado de inquilinos (10k) debe excluir el enfoque de varias bases de datos, para la mayoría, si no todos los escenarios. No creo que te apetezca la idea de mantener 10.000 instancias de base de datos y tener que crear cientos de nuevas cada día.

Solo desde ese parámetro, parece que el enfoque de base de datos compartidos, de un solo esquema es el más adecuado. El hecho de que almacene unos 50Mb por inquilino y que no haya complementos por inquilino hace que este enfoque sea aún más apropiado.

El artículo de MSDN antes citado menciona tres patrones de seguridad que abordan las consideraciones de seguridad para el enfoque de base de datos compartida:

• Trusted Database Connections
• Tenant View Filter
• Tenant Data Encryption

Cuando se tiene la certeza de las medidas de seguridad de datos de su aplicación, usted podría ofrecer a sus clientes un Service Level Agrement que proporciona sólidas garantías de seguridad de datos.En su SLA, además de las garantías, también podría describir las medidas que tomaría para garantizar que los datos no se vean comprometidos.

ACTUALIZACIÓN 2: Al parecer, los chicos de Microsoft se trasladó/hizo un nuevo artículo sobre este tema, el enlace original se ha ido y esta es la nueva: Multi-tenant SaaS database tenancy patterns (felicitaciones a Shai kerer)

Answer 2

Mi experiencia (aunque SQL Server) es que la base de datos múltiple es el camino a seguir, donde cada cliente tiene su propia base de datos. Entonces, aunque no tengo experiencia mySQL o Ruby On Rails, espero que mi entrada agregue algún valor.

Las razones por las cuales incluyen:

1. de recuperación de datos de seguridad/desastre. Los datos de cada compañía se almacenan completamente separados de otros, lo que reduce el riesgo de que los datos se vean comprometidos (pensando cosas como si introdujese una falla en el código que significa que algo mira erróneamente otros datos del cliente cuando no debería), minimiza la pérdida potencial de un cliente la base de datos particular se corrompe, etc. Los beneficios de seguridad percibidos para el cliente son aún mayores (¡efecto secundario añadido adicional!)
2. escalabilidad. Básicamente, usted dividiría sus datos para permitir una mayor escalabilidad, por ej. las bases de datos se pueden poner en diferentes discos, puede poner varios servidores de bases de datos en línea y mover bases de datos para distribuir la carga.
3. puesta a punto del rendimiento. Supongamos que tiene un cliente muy grande y uno muy pequeño. Los patrones de uso, los volúmenes de datos, etc. pueden variar mucho. Puede sintonizar/optimizar más fácilmente para cada cliente si lo necesita.

¡Espero que esto ofrezca alguna entrada útil! Hay más razones, pero mi mente se quedó en blanco. Si se inicia de nuevo, voy a actualizar :)

EDIT:
Desde que he publicado esta respuesta, ahora está claro que estamos hablando de 10.000 inquilinos. Mi experiencia está en cientos de bases de datos a gran escala. No creo que 10.000 bases de datos separadas sean demasiado manejables para su escenario, por lo que ahora no estoy a favor del enfoque multi-db para su escenario. ¡Especialmente cuando ahora está claro que estás hablando de pequeños volúmenes de datos para cada inquilino!

Mantener mi respuesta aquí como de todas formas, ya que puede tener algún uso para otras personas en un barco similar (con un menor número de inquilinos)

Answer 3

A continuación se muestra un enlace a un libro blanco sobre Salesforce.com acerca de cómo se implementan múltiples -tenancy:

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

tienen 1 mesa enorme w/500 columnas de cadena (Value0, valor1, ... Value500). Las fechas y los números se almacenan como cadenas en un formato tal que se pueden convertir a sus tipos nativos en el nivel de la base de datos. Hay tablas de metadatos que definen la forma del modelo de datos que puede ser único por inquilino. Hay tablas adicionales para la indexación, las relaciones, los valores únicos, etc.

¿Por qué la molestia?

Cada inquilino puede personalizar su propio esquema de datos en tiempo de ejecución sin tener que realizar cambios en el nivel de la base de datos (modificar la tabla, etc.). Esta es definitivamente la manera más difícil de hacer algo como esto, pero es muy flexible.

Answer 4

Como mencionas, la base de datos por inquilino es una opción y tiene algunas compensaciones más grandes con ella.Puede funcionar bien a menor escala, como un solo dígito o bajo 10 de inquilinos, pero más allá de eso, se vuelve más difícil de gestionar. Ambas son solo migraciones, pero también solo para mantener las bases de datos en funcionamiento.

El modelo por esquema no solo es útil para esquemas únicos para cada uno, aunque sigue corriendo migraciones entre todos los inquilinos se vuelve difícil y en 1000 de los esquemas Postgres puede comenzar a tener problemas.

Un enfoque más escalable es tener absolutamente a los inquilinos distribuidos aleatoriamente, almacenados en la misma base de datos, pero a través de diferentes fragmentos lógicos (o tables). Dependiendo de su idioma, hay varias bibliotecas que pueden ayudar con esto. Si está utilizando Rails, hay una biblioteca para consultar el inquilinato acts_as_tenant, lo que ayuda a garantizar que las consultas de inquilinos solo recuperen esos datos. También hay una gema apartment - aunque utiliza el modelo de esquema, sí ayuda con las migraciones en todos los esquemas. Si está usando Django, hay un número, pero uno de los más populares parece estar en schemas. Todos estos ayudan más en el nivel de aplicación. Si busca algo más directamente en la base de datos, Citus se centra en hacer que este tipo de fragmentación para multi-tenancy funcione más rápido con Postgres.