Nuestra aplicación actualmente genera una nueva base de datos para cada cliente. Estamos comenzando a preguntarnos si deberíamos considerar la refacturación de esto a un sistema de múltiples inquilinos.Cualquier idea sobre aplicaciones Multi-tenant versus Multi-database en Rails
¿Qué beneficios/compensaciones deberíamos considerar? ¿Cuáles son las mejores prácticas para implementar una aplicación de múltiples usuarios en Rails?
Los sistemas de múltiples inquilinos le presentarán toda una serie de problemas. Mis pensamientos rápidos están por debajo
Todos SQL debe ser examinado y rediseñado para incluir un valor ClientId.
todos los índices deben ser examinados para determinar si el ClientId tiene que ser incluido
un error en una instrucción SQL por un desarrollador /administrador de sistemas en la producción se afectar a todos sus clientes.
Una base de datos de la corrupción/problema afectar a todos sus clientes
Usted tiene algo de privacidad de datos cuestiones cual pobre código/aplicación podría permitir clienteA para ver los datos pertenecientes a clienteB
Un cliente que use su sistema de una manera pesada/agresiva puede afectar la percepción de los demás clientes sobre el rendimiento
Adaptar los datos estáticos a las preferencias individuales de los clientes se vuelve más complejo.
Estoy seguro de que hay una serie de otros problemas, pero estos fueron mis primeros pensamientos.
No tengo ninguna experiencia con esto personalmente, pero durante las charlas sobre rayos en el 2009 Ruby Hoedown, Andrew Coleman presentó un plugin que diseñó y usa para bases de datos de múltiples inquilinos en rieles con subdominios. Puede check out the lightning talk slides y aquí está el acts_as_restricted_subdomain repository.
¿Por qué lo harías? ¿Tiene una gran agregación entre usuarios o está generando demasiados DB? ¿Ha considerado usar archivos SQLite por inquilino en lugar de servidores de bases de datos compartidos (ya que las aplicaciones multiusuario a menudo son de bajo perfil y no necesitan mucha concurrencia)?
consideramos esto, sin embargo, en una configuración de servidor web con equilibrio de carga, nos habríamos encontrado con problemas al usar sqllite en diferentes servidores web, por lo que optamos por un enfoque de 2 niveles – Dom
Realmente depende de lo que esté haciendo.
Estamos haciendo un programa MIS para la industria de la impresión que rastrea inventario, empleados, clientes, equipos y hace algunos cálculos serios para estimar los costos de la realización de trabajos basados en muchas variables de entrada.
Estamos anticipando bases de datos muy grandes para cada cliente, y actualmente tenemos 170 tablas. Agregar otra columna a casi todas las tablas solo para almacenar el client_id me duele el cerebro.
Actualmente estamos en la fase beta de nuestro programa, y aquí están algunas cosas que hemos encontrado:
Si tiene preguntas específicas sobre cualquiera de estos, le puedo ayudar.
Nuestra aplicación funciona mucho como has descrito anteriormente. Constantemente hemos tenido problemas con la migración de bases de datos y hemos descubierto que nuestro desarrollo puede derivar en diferentes esquemas inconsistentes, lo que resulta en un gran esfuerzo para tratar de fusionar cuando queremos implementar. Las principales atracciones para refacturar nuestra aplicación como un sistema multi-tennant es que no tenemos que preocuparnos por una gran cantidad de lógica de migración de bases de datos, podemos escalar nuestra aplicación en base a una única base de datos, y podemos construir un conjunto más limpio de herramientas de administración ... – Dom
He estado investigando lo mismo y encontré esta presentación para ofrecer una solución interesante: usar esquemas de Postgre (un poco como espacios de nombres) para separar datos en el nivel DB manteniendo todos los inquilinos en el mismo DB y permaneciendo (en su mayoría) transparente a los rieles.
gracias Steve .. No parece demasiado enamorados .. Cualquier beneficio de hacer esto en su opinión? – Dom
Hmm. También hay muchas desventajas para el enfoque de múltiples bases de datos. Si estoy diseñando un sistema, tenderá a tener varios inquilinos con clientes grandes en particular, tal vez divididos en un sistema aparte. De hecho, hay algunos beneficios para un sistema con varios inquilinos. El gran número de bases de datos se convierte en un dolor de cabeza administrativo. También es doloroso programar actualizaciones en múltiples bases de datos, etc. –