¿Cómo crear una base de datos multi-tenant con estructuras de tabla compartidas?
Nuestro software se ejecuta actualmente en MySQL. Los datos de todos los tenants se almacenan en el mismo esquema. Ya que estamos usando Ruby on Rails podemos determinar fácilmente qué datos pertenecen a qué tenant. Sin embargo, hay algunas empresas, por supuesto, que temen que sus datos puedan verse comprometidos, por lo que estamos evaluando otras soluciones.
Hasta ahora he visto tres opciones:
- Multi-Base de datos (cada inquilino obtiene su propio - casi lo mismo que 1 servidor por cliente)
- Multi-Esquema (no disponible en MySQL, cada inquilino obtiene su propio esquema en una base de datos compartida)
- Esquema compartido (nuestro enfoque actual, tal vez con registro de identificación adicional en cada columna)
Multi-Esquema es mi favorito (teniendo en cuenta los costos). 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.
P: Multi-Esquema parece estar diseñado para tener un poco mesas diferentes para cada inquilino-no quiero esto. ¿Hay algún RDBMS que me permita usar una solución multi-esquema multi-tenant, donde la estructura de tabla se comparte entre todos los tenants?
P.d. Por multi me refiero a algo como ultra-multi (más de 10.000 inquilinos).
4 answers
Sin Embargo, hay algunas empresas de curso que temen que sus datos podrían estar comprometido, por lo que estamos evaluando otras soluciones.
Esto es desafortunado, ya que los clientes a veces sufren de una idea errónea de que solo el aislamiento físico puede ofrecer suficiente seguridad.
Hay un interesante artículo de MSDN, titulado Multi-Tenant Data Architecture, que puede que desee comprobar. Así es como los autores abordaron el concepto erróneo hacia lo compartido enfoque:
Un error común sostiene que solo el aislamiento físico puede proporcionar una nivel adecuado de seguridad. En hecho, los datos almacenados mediante un el enfoque también puede proporcionar datos sólidos seguridad, pero requiere el uso de más patrones de diseño sofisticados.
En cuanto a las consideraciones técnicas y comerciales, 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 necesidades de la inquilinos que esperan servir a todos los afectados su decisión de arquitectura de datos en diferentes maneras. Algunos de los siguientes preguntas pueden sesgar hacia un más enfoque aislado, mientras que otros pueden sesgar hacia un más compartido enfoque.
¿Cuántos posibles inquilinos esperan apuntar? Puede que no estés en ninguna parte cerca de poder estimar uso prospectivo con autoridad, pero piense 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 espera que tu base de inquilinos sea, la es más probable que desee considerar un enfoque más compartido.
¿Cuánto espacio de almacenamiento espera que ocupen los datos del inquilino promedio? Si espera que algunos o todos los inquilinos almacenar grandes cantidades de datos, el separate-database approach is probably mejor. (De hecho, el almacenamiento de datos los requisitos pueden obligarle a adoptar una modelo de base de datos separada Por cierto. Si es así, será mucho más fácil diseñar el aplicación de esa manera desde el a partir de pasar a un separate-database approach later on.)
¿Cuántos usuarios finales simultáneos espera que admita el inquilino promedio? Cuanto mayor sea el número, más adoptar un enfoque más aislado será para satisfacer las necesidades de los usuarios finales.
¿Espera ofrecer servicios de valor agregado por inquilino, tales como copia de seguridad y restauración según el inquilino ¿capacidad? Tales servicios son más fáciles para ofrecer a través de un más aislado enfoque.
ACTUALIZACIÓN: Más información sobre el número esperado de inquilinos.
Ese número esperado de inquilinos (10k) debe excluir el enfoque de bases de datos múltiples, para la mayoría, si no todos los escenarios. No creo que te guste la idea de mantener 10,000 instancias de base de datos, y tener que crear cientos de nuevas cada día.
Solo a partir de ese parámetro, se parece que el enfoque de base de datos compartida y esquema único es el más adecuado. El hecho de que almacenará solo unos 50 Mb por inquilino, y que no habrá complementos por inquilino, hace que este enfoque sea aún más apropiado.
El artículo de MSDN citado anteriormente menciona tres patrones de seguridad que abordan las consideraciones de seguridad para el enfoque de base de datos compartida:
- Conexiones de base de datos de confianza
- Filtro de vista del inquilino
- Arrendatario Cifrado de datos
Cuando esté seguro de las medidas de seguridad de datos de su aplicación, podrá ofrecer a sus clientes un Acuerdo de nivel de servicio 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: Aparentemente los chicos de Microsoft se movieron / hicieron un nuevo artículo con respecto a este tema, el original el enlace se ha ido y este es el nuevo: Patrones de tenencia de la base de datos SaaS Multi-tenant (felicitaciones a Shai Kerer)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-12-06 04:50:04
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. Así que aunque no tengo experiencia en MySQL o Ruby On Rails, espero que mi entrada pueda agregar algún valor.
Las razones por las que incluyen:
- seguridad de datos/recuperación ante desastres. Los datos de cada empresa se almacenan completamente por separado de los demás, lo que reduce el riesgo de que los datos se vean comprometidos (pensando en cosas como si introduces un error de código que significa algo mira erróneamente otros datos del cliente cuando no debería), minimiza la pérdida potencial de un cliente si una base de datos en particular se corrompe, etc. Los beneficios de seguridad percibidos para el cliente son aún mayores (¡efecto secundario adicional!)
- escalabilidad. Esencialmente, estaría particionando sus datos para permitir una mayor escalabilidad, por ejemplo, las bases de datos se pueden colocar en diferentes discos, podría llevar varios servidores de bases de datos en línea y mover las bases de datos más fácilmente para propagar el carga.
- ajuste de rendimiento. Supongamos que usted tiene un cliente muy grande y uno muy pequeño. Patrones de uso, volúmenes de datos, etc. puede variar enormemente. Puede ajustar / 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 activa de nuevo, voy a actualizar :)
EDITAR:
Desde que publiqué esta respuesta, ahora está claro que estamos hablando de más 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 de múltiples bases de datos para su escenario. ¡Especialmente porque ahora está claro que estás hablando de pequeños volúmenes de datos para cada inquilino!
Mantener mi respuesta aquí como de todos modos, ya que puede tener algún uso para otras personas en un barco similar (con menos inquilinos)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-02-06 15:46:43
A continuación hay un enlace a un documento técnico sobre Salesforce.com acerca de cómo implementan multi-tenancy:
Http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf
Tienen 1 tabla enorme con 500 columnas de cadena (Value0, Value1,... Value500). Las fechas y los números se almacenan como cadenas en un formato tal que se pueden convertir a sus tipos nativos a nivel de base de datos. Hay tablas de metadatos que definen la forma de los datos modelo que puede ser único por inquilino. Hay tablas adicionales para indexación, relaciones, valores únicos, etc.
¿Por qué la molestia?
Cada tenant puede personalizar su propio esquema de datos en tiempo de ejecución sin tener que realizar cambios a nivel de base de datos (modificar tabla, etc.). Esta es definitivamente la manera difícil de hacer algo como esto, pero es muy flexible.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-04-18 21:05:46
Como usted menciona, la base de datos por inquilino es una opción y tiene algunas compensaciones más grandes con ella. Puede funcionar bien a una escala más pequeña, como un solo dígito o un mínimo de 10 inquilinos, pero más allá de eso se vuelve más difícil de administrar. Tanto solo las migraciones, sino también solo en el mantenimiento de las bases de datos en funcionamiento.
El modelo por esquema no solo es útil para esquemas únicos para cada uno, aunque las migraciones en ejecución a través de todos los inquilinos se vuelven difíciles y en 1000 de esquemas Postgres puede empezar a tener problemas.
Un enfoque más escalable es absolutamente tener inquilinos distribuidos aleatoriamente, almacenados en la misma base de datos, pero a través de diferentes fragmentos lógicos (o tablas). Dependiendo de su idioma hay una serie de bibliotecas que pueden ayudar con esto. Si estás usando Rails hay una biblioteca para el alquiler acts_as_tenant, ayuda a garantizar que sus consultas de inquilinos solo recuperen esos datos. También hay una joya apartment - aunque utiliza el esquema model it ayuda con las migraciones a través de todos los esquemas. Si estás usando Django hay un número, pero uno de los más populares parece estar en esquemas. Todo esto ayuda más a nivel de aplicación. Si está buscando algo más a nivel de base de datos directamente, Citus se enfoca en hacer que este tipo de sharding para multi-tenancy funcione más fuera de la caja con Postgres.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-09-07 21:07:23