En este documento, se describen varias formas de implementar múltiples usuarios en Spanner. También se analizan los patrones de administración de datos y la administración del ciclo de vida de los usuarios.
La configuración multiusuario se aplica cuando una sola instancia, o algunas instancias, de una aplicación de software se entrega a varios usuarios o clientes. Este patrón de software puede escalar de un solo usuario o cliente a cientos o miles. Este enfoque es fundamental para las plataformas de computación en la nube en las que la infraestructura subyacente se comparte entre varias organizaciones.
Piensa en el uso de la arquitectura multiusuario como una forma de partición basada en recursos de procesamiento compartidos, como las bases de datos. Una analogía son los usuarios en un edificio de apartamentos: infraestructura compartida, pero espacio dedicado para los usuarios. La arquitectura multiusuario es parte de la mayoría de las aplicaciones de software como servicio (SaaS), si no de todas.
Este documento se dirige a los arquitectos de bases de datos, los arquitectos de datos y los ingenieros que implementan aplicaciones multiusuario en Spanner como su base de datos relacional. Con ese contexto, se describen varios enfoques para almacenar datos multiusuario. Los términos “usuario”, “cliente” y “organización” se usan de manera intercambiable en todo el artículo para indicar la entidad que accede a la aplicación multiusuario.
En este artículo, se usa un proveedor de SaaS de recursos humanos (RR.HH.) que implementa su aplicación multiusuario en Google Cloud como ejemplo. En el ejemplo, varios clientes del proveedor de SaaS de RR.HH. deben acceder a la aplicación multiusuario. Estos clientes se denominan usuarios.
Spanner es la base de datos uniforme, distribuida y completamente administrada de Google Cloud que combina los beneficios del modelo de base de datos relacional con escalabilidad horizontal no relacional. Spanner tiene semántica relacional, con esquemas, tipos de datos aplicados, coherencia sólida, transacciones ACID de varias declaraciones y un lenguaje de consulta SQL que implementa SQL ANSI 2011.
Spanner proporciona un tiempo de inactividad cero para el mantenimiento planificado o los fallos regionales, con un ANS de disponibilidad del 99.999%. Admite aplicaciones modernas multiusuario, ya que proporcionan alta disponibilidad y escalabilidad. En este artículo, se analizan los diferentes enfoques de arquitectura para implementar una arquitectura multiusuario con Spanner.
Criterios para la asignación de datos de usuarios
En una aplicación multiusuario, los datos de cada instancia se aíslan en uno de varios enfoques de arquitectura en la base de datos subyacente de Spanner. En la siguiente lista, se describen los diferentes enfoques de arquitectura que se usan para asignar los datos de un usuario a Spanner:
- Instancia: Un usuario reside de forma exclusiva en una instancia de Spanner, con exactamente una base de datos para ese usuario.
- Base de datos: Un usuario reside en una base de datos en una sola instancia de Spanner que contiene varias bases de datos.
- Esquema: Un usuario reside en tablas exclusivas dentro de una base de datos y se pueden encontrar varios usuarios en la misma base de datos.
- Tabla: Los datos de usuarios son filas en tablas de bases de datos. Esas tablas se comparten con otros usuarios.
Los criterios anteriores se denominan patrones de administración de datos y se analizan en detalle en la sección Patrones de administración de datos multiusuario. Ese análisis se basa en los siguientes criterios:
- Aislamiento: El grado de aislamiento de datos entre varios usuarios es una consideración importante para los usuarios múltiples. El aislamiento se debe a las decisiones que se tomaron para los criterios de otras categorías, por ejemplo, ciertos requisitos normativos y de cumplimiento pueden dictar un mayor grado de aislamiento.
- Agilidad: La facilidad de incorporación y desvinculación de las actividades de un usuario respecto de la creación de una instancia, una base de datos o una tabla.
- Operaciones: La disponibilidad o complejidad de la implementación de actividades típicas, específicas de la base de datos y actividades de administración; por ejemplo, mantenimiento regular, registros, copias de seguridad u operaciones de recuperación ante desastres.
- Escalamiento: La capacidad de escalar sin problemas para permitir el crecimiento futuro. La descripción de cada patrón contiene la cantidad de usuarios que admite el patrón.
- Rendimiento: La capacidad de asignar recursos exclusivos a cada usuario, abordar el fenómeno de vecino real y habilitar el rendimiento de lectura y escritura predecible para cada usuario.
- Regulaciones y cumplimiento: La capacidad de abordar los requisitos de países y sectores altamente regulados que requieren el aislamiento completo de recursos y operaciones de mantenimiento; por ejemplo, los requisitos de residencia de datos de Francia requieren que la información de identificación personal se almacene físicamente en Francia.
Cada patrón de administración de datos relacionado con estos criterios se detalla en la siguiente sección. Usa los mismos criterios cuando selecciones un patrón de administración de datos para un conjunto específico de usuarios.
Patrones de administración de datos multiusuario
En las siguientes secciones, se describen los cuatro patrones principales de administración de datos: instancias, bases de datos, esquemas y tablas.
Instancia
Para proporcionar un aislamiento completo, el patrón de administración de datos de la instancia almacena los datos de cada usuario en su propia instancia y base de datos de Spanner. Una instancia de Spanner puede tener una o más bases de datos. En este patrón, solo se crea una base de datos. En la aplicación de RR.HH. que se explicó antes, se crea una instancia de Spanner independiente con una base de datos para cada organización del cliente.
Como se ve en el siguiente diagrama, el patrón de administración de datos tiene un usuario por instancia.
Tener instancias diferentes para cada usuario permite el uso de proyectos de Google Cloud diferentes a fin de alcanzar límites de confianza distintos para usuarios diferentes. Un beneficio adicional es que se puede elegir cada configuración de instancia según la ubicación de cada usuario (ya sea regional o multirregional), lo que optimiza la flexibilidad y el rendimiento de la ubicación.
La arquitectura puede escalar con facilidad a cualquier cantidad de usuarios. Los proveedores de SaaS pueden crear cualquier cantidad de instancias en las regiones deseadas, sin límites estrictos.
En la siguiente tabla, se describe cómo el patrón de administración de datos de instancia afecta a los diferentes criterios.
| Criterios | Instancia: un usuario por patrón de administración de datos de instancia |
|---|---|
| Aislamiento |
|
| Agilidad |
|
| Operaciones |
|
| Escala |
|
| Rendimiento |
|
| Requisitos reglamentarios y de cumplimiento |
|
En resumen, las conclusiones clave son:
- Ventaja: El nivel más alto de aislamiento
- Desventaja: Mayor sobrecarga operativa.
El patrón de administración de datos de instancia es más adecuado para las siguientes situaciones:
- Usuarios diferentes que se distribuyen en una amplia variedad de regiones y necesitan una solución localizada.
- Los requisitos regulatorios y de cumplimiento para algunos usuarios exigen niveles más altos de protocolos de seguridad y auditoría.
- El tamaño de los usuarios varía significativamente, de modo que compartir recursos entre usuarios de alto volumen y de tráfico alto puede causar contención y degradación mutua.
Base de datos
En el patrón de administración de datos de la base de datos, cada usuario reside en una base de datos dentro de una única instancia de Spanner. Puede haber varias bases de datos en una sola instancia. Si una instancia no es suficiente para la cantidad de usuarios, crea varias instancias. Este patrón implica que una sola instancia de Spanner se comparte entre varios usuarios.
Spanner tiene un límite estricto de 100 bases de datos por instancia. Este límite significa que, si el proveedor de SaaS necesita escalar más allá de 100 clientes, debe crear y usar varias instancias de Spanner.
En la aplicación de RR. HH., el proveedor de SaaS crea y administra cada usuario con una base de datos separada en una instancia de Spanner.
Como se ve en el siguiente diagrama, el patrón de administración de datos tiene un usuario por base de datos.
El patrón de administración de datos de base de datos logra un aislamiento lógico en el nivel de la base de datos para los datos de diferentes usuarios. Sin embargo, debido a que es una sola instancia de Spanner, todas las bases de datos de usuarios comparten la misma configuración regional, así como la configuración de procesamiento y almacenamiento subyacente.
En la siguiente tabla, se describe cómo el patrón de administración de datos de base de datos afecta a los diferentes criterios.
| Criterios | Base de datos: un usuario por patrón de administración de datos de base de datos |
|---|---|
| Aislamiento |
|
| Agilidad |
|
| Operaciones |
|
| Escala |
|
| Rendimiento |
|
| Requisitos reglamentarios y de cumplimiento |
|
En resumen, las conclusiones clave son:
- Ventajas: Nivel más alto de aislamiento
- Desventaja: La cantidad de usuarios por instancia es limitada; inflexibilidad de la ubicación
El patrón de administración de datos de base de datos es más adecuado para las siguientes situaciones:
- Varios clientes se encuentran en la misma residencia de datos, por ejemplo, Francia o el Reino Unido, o están bajo la misma autoridad reguladora.
- Los usuarios requieren separación de datos basada en el sistema y copia de seguridad/restablecimiento, pero funcionan bien con el uso compartido de recursos de infraestructura.
Esquema
En el patrón de administración de datos de esquema, se usa una sola base de datos (que implementa un solo esquema) para varios usuarios y un conjunto de tablas separado para los datos de cada usuario. Estas tablas se pueden diferenciar mediante la inclusión de tenant ID en los nombres de las tablas como un prefijo o un sufijo.
Este patrón de administración de datos con el uso de un conjunto separado de tablas para cada usuario proporciona un nivel de aislamiento mucho menor en comparación con las opciones anteriores (los patrones de administración de instancia y base de datos). El patrón también facilita la incorporación, lo que incluye la creación de tablas nuevas, y la integridad referencial y los índices asociados.
Una advertencia significativa es que los permisos de acceso para Spanner a través de Identity and Access Management (IAM) solo se proporcionan a nivel de instancia o base de datos. No se pueden proporcionar permisos de acceso a nivel de la tabla. También existe un límite de 5,000 tablas por base de datos. Para muchos clientes, ese límite restringe el uso de la aplicación.
Además, el uso de tablas separadas para cada cliente puede generar una gran acumulación de operaciones de actualización del esquema. Estas tareas pendientes tardan mucho tiempo en resolverse.
En la aplicación de RR. HH., el proveedor de SaaS puede crear un conjunto de tablas para cada cliente con tenant ID como el prefijo en los nombres de la tabla; por ejemplo, customer1_employee, customer1_payroll, customer1_department.
Como se muestra en el siguiente diagrama, el patrón de administración de datos de esquema tiene un conjunto de tablas para cada usuario.
En la siguiente tabla, se describe cómo el patrón de administración de datos de esquema afecta a los diferentes criterios.
| Criterios | Esquema: un conjunto de tablas para cada patrón de administración de datos de usuarios |
|---|---|
| Aislamiento |
|
| Agilidad |
|
| Operaciones |
|
| Escala |
|
| Rendimiento |
|
| Requisitos reglamentarios y de cumplimiento |
|
En resumen, las conclusiones clave son:
- Ventaja: La incorporación es trivial
- Desventaja: Mayor sobrecarga operativa; no hay controles de seguridad en el nivel de tabla
El patrón de administración de datos de esquema es más adecuado para las siguientes situaciones:
- Aplicaciones internas que se dirigen a diferentes departamentos en los que el aislamiento estricto de seguridad de datos no es una preocupación importante en comparación con la facilidad de mantenimiento.
- Aplicaciones multiusuario en las que los datos no requieren una separación estricta en función de requisitos legales o normativos.
Si bien es posible crear varios conjuntos de tablas (cada conjunto que representa una instancia) en una base de datos, es el patrón menos ideal desde la perspectiva de la base de datos. El motivo principal es que las tablas deben seguir las convenciones de asignación de nombres. La aplicación y cualquier herramienta de base de datos (por ejemplo, IDE y herramientas de migración de esquemas) deben comprender la convención de asignación de nombres. Además, si la cantidad de tablas es razonablemente grande por usuario, el patrón de administración de datos del esquema no proporciona un escalamiento significativo.
Un mejor enfoque es migrar a una base de datos por usuario y aumentar la cantidad de instancias o pasar al patrón de administración de datos de tabla.
Tabla
El patrón final de administración de datos entrega usuarios múltiples con un conjunto común de tablas. Cada tabla contiene datos de varios usuarios. Este patrón de administración de datos representa un nivel extremo de patrón multiusuario en el que todo, desde la infraestructura hasta el esquema y el modelo de datos, se comparte entre varios usuarios. Dentro de una tabla, las filas se particionan en función de las claves primarias, con tenant ID como el primer elemento de la clave. Desde la perspectiva del escalamiento, Spanner admite mejor este patrón porque puede escalar tablas sin límites.
En la aplicación de RR. HH., la clave primaria de la tabla de nóminas puede ser una combinación de customerID y payrollID.
Como se ve en el siguiente diagrama, el patrón de administración de datos de tabla tiene una tabla para varios usuarios.
Al igual que el patrón de esquema, el acceso a los datos en el patrón de tabla no se puede controlar por separado para usuarios diferentes. Usar menos tablas significa que las operaciones de actualización de esquema se completan más rápido cuando cada usuario tiene sus propias tablas de base de datos. En gran medida, este enfoque simplifica la integración, la desvinculación y las operaciones.
En la siguiente tabla, se describe cómo el patrón de administración de datos de tabla afecta a los diferentes criterios.
| Criterios | Tabla: Una tabla para varios patrones de administración de datos de usuarios |
|---|---|
| Aislamiento |
|
| Agilidad |
|
| Operaciones |
|
| Escala |
|
| Rendimiento |
|
| Requisitos reglamentarios y de cumplimiento |
|
En resumen, las conclusiones clave son:
- Ventajas: Altamente escalable; tiene una sobrecarga operativa baja
- Desventaja: Clasificación del recurso alta; la falta de controles de seguridad para cada usuario
Este patrón resulta más adecuado para las siguientes situaciones:
- Aplicaciones internas que se dirigen a diferentes departamentos en los que el aislamiento estricto de seguridad de datos no es una preocupación importante en comparación con la facilidad de mantenimiento.
- Uso compartido máximo de recursos para usuarios que usan la funcionalidad de aplicación de nivel gratuito cuando minimizan el aprovisionamiento de recursos al mismo tiempo.
Patrones de administración de datos y administración del ciclo de vida de los usuarios
En la siguiente tabla, se comparan los diversos patrones de administración de datos en todos los criterios a un alto nivel.
| Instancia | Base de datos | Esquema | Tabla | |
|---|---|---|---|---|
| Aislamiento | Completo | Completo | Bajo | Más bajo |
| Agilidad | Bajo | Moderado | Moderado | Más alto |
| Facilidad de operaciones | Alto | Alto | Bajo | Bajo |
| Escala | Alto | Limitado | Posiblemente muy limitado | Alto |
| Rendimiento* | Alto | Moderado | Moderado | Potencialmente alto |
| Reglamentos y cumplimiento | Más alto | Alto | Bajo | Bajo |
* El rendimiento depende en gran medida del diseño del esquema y de las prácticas recomendadas de consultas. Los valores que aparecen aquí son solo una expectativa promedio.
Los mejores patrones de administración de datos para una aplicación multiusuario específica son los que satisfacen la mayoría de sus requisitos según los criterios. Si no se requiere un criterio en particular, puedes ignorar la fila en la que se encuentra.
Patrones de administración de datos combinados
A menudo, un patrón de administración de datos único es suficiente para abordar los requisitos de una aplicación multiusuario. Cuando ese es el caso, el diseño puede adoptar un solo patrón de administración de datos.
Sin embargo, algunas aplicaciones multiusuario requieren varios patrones de administración de datos al mismo tiempo. Por ejemplo, una aplicación multiusuario que admite un nivel gratuito, un nivel regular y un nivel empresarial.
Nivel gratuito:
- Debe ser rentable
- Debe tener un límite superior de volumen de datos
- Por lo general, admite funciones limitadas
- El patrón de administración de datos de tabla es un buen candidato de nivel gratuito
- La administración de usuarios es simple
- No es necesario crear recursos de usuarios específicos o exclusivos
Nivel regular:
- Ideal para clientes que pagan, que no tienen altos requisitos de escalamiento o aislamiento
- El patrón de administración de datos de esquema o el patrón de administración de datos de base de datos son buenos candidatos para el nivel regular.
- Las tablas y los índices son exclusivos del usuario.
- Las copias de seguridad son fáciles en el patrón de administración de datos de base de datos
- La copia de seguridad no es compatible con el patrón de administración de datos del esquema
- La copia de seguridad de usuario debe implementarse como una utilidad fuera de Spanner
Nivel empresarial:
- Por lo general, un nivel alto de autonomía total en todos los aspectos
- El usuario tiene recursos dedicados que incluyen escalamiento dedicado y aislamiento completo.
- El patrón de administración de datos de la instancia es adecuado para el nivel empresarial
Una práctica recomendada es mantener diferentes patrones de administración de datos en diferentes bases de datos. Si bien es posible combinar diferentes patrones de administración de datos en una base de datos de Spanner, hacerlo dificulta la implementación de la lógica de acceso de la aplicación y las operaciones del ciclo de vida.
En la sección sobre el diseño de aplicaciones, se describen algunas consideraciones de diseño de aplicaciones multiusuario que se aplican cuando se usa un patrón de administración de datos único o varios patrones de administración de datos.
Administra el ciclo de vida del usuario
Los usuarios tienen un ciclo de vida. Por lo tanto, debes implementar las operaciones de administración correspondientes dentro de tu aplicación multiusuario. Más allá de las operaciones básicas de creación, actualización y eliminación de usuarios, considera las siguientes operaciones adicionales relacionadas con los datos:
Exporta datos de usuario:
- Cuando se borra un usuario, se recomienda exportar primero sus datos y, en lo posible, hacer que el conjunto de datos esté disponible para ellos.
- Cuando se usa el patrón de administración de datos de esquema o tabla, el sistema de aplicaciones multiusuario debe implementar la exportación o mapearla a la función de base de datos (exportación de bases de datos).
Crea una copia de seguridad de los datos del usuario:
- Cuando usas el patrón de administración de datos de instancia o de base de datos y las copias de seguridad de usuarios individuales, usa las funciones de exportación o copia de seguridad de la base de datos.
- Cuando usas el esquema de administración de datos de tabla o esquema y creas copias de seguridad de los datos de usuarios individuales, la aplicación multiusuario debe implementar esta operación. La base de datos de Spanner no puede determinar qué datos pertenecen a qué usuario.
Mueve datos de usuario:
Para mover un usuario de un patrón de administración de datos a otro (o mover un usuario dentro del mismo patrón de administración de datos entre instancias o bases de datos), se requiere la extracción de los datos del patrón de administración de datos de tabla y la inserción de esos datos en el patrón de administración de datos de base de datos.
- Cuando la aplicación puede tener tiempo de inactividad, realiza una importación o exportación.
- Cuando no puede haber tiempo de inactividad, realiza una migración de base de datos sin tiempo de inactividad.
Mitigar una situación de vecino ruidoso es otra razón para mover usuarios.
Diseño de aplicaciones
Cuando diseñas una aplicación multiusuario, implementas una lógica empresarial optimizada para usuarios. Esto significa que cada vez que la aplicación ejecuta la lógica empresarial, siempre debe estar en el contexto de un usuario conocido.
Desde la perspectiva de la base de datos, el diseño de la aplicación implica que cada consulta debe ejecutarse en el patrón de administración de datos en el que reside el usuario. En las siguientes secciones, se destacan algunos de los conceptos centrales del diseño de aplicaciones multiusuario.
Conexión de usuario dinámica y configuración de consulta
La asignación dinámica de datos de usuario a solicitudes de aplicación de usuarios usa una configuración de asignación:
- En el caso de los patrones de administración de datos de la base de datos o los patrones de administración de datos de una instancia, una string de conexión es suficiente para acceder a los datos de un usuario.
- Para los patrones de administración de datos de esquema, se deben determinar los nombres correctos de las tablas.
- Para los patrones de administración de datos de tablas, las consultas deben ejecutarse en la base de datos. Usa los predicados adecuados para recuperar los datos de un usuario específico.
Una instancia puede estar en cualquiera de los cuatro patrones de administración de datos. La siguiente implementación de asignación aborda una configuración de conexión para el caso general de una aplicación multiusuario que usa todos los patrones de administración de datos al mismo tiempo. Cuando un usuario determinado reside en un patrón, algunas aplicaciones multiusuario usan un patrón de administración de datos para todos los usuarios. Este caso se cubre de forma implícita mediante la siguiente asignación.
Si un usuario ejecuta la lógica empresarial (por ejemplo, un empleado que accede con su ID de usuario), la lógica de la aplicación debe determinar el patrón de administración de datos del usuario, la ubicación de los datos para un ID de usuario determinado y, opcionalmente, la convención de nomenclatura de tablas (para el patrón de esquema).
Esta lógica de aplicación requiere la asignación de patrones de administración de usuarios a datos. En la siguiente muestra de código, connection string hace referencia a la base de datos en la que residen los datos del usuario. En la muestra, se identifica la instancia de Spanner y la base de datos. Para la base de datos y la instancia de patrón de administración de datos, el siguiente código es suficiente a fin de que la aplicación conecte y ejecute consultas:
tenant id -> (data management pattern,
database connection string,
[table_prefix])
Se requiere un diseño adicional para los patrones de administración de datos de esquema y tabla.
Patrón de administración de datos de esquema
Para el patrón de administración de datos de esquema, hay varios usuarios dentro de la misma base de datos. Cada grupo de usuarios tiene su propio conjunto de tablas. Las tablas se distinguen por su nombre. Qué tabla pertenece a qué usuario es determinista.
Un enfoque es ingresar los nombres de la tabla con el ID de usuario: por ejemplo, la tabla EMPLOYEE se llama T356_EMPLOYEE para el usuario con el ID 356. La aplicación debe ingresar cada tabla con el prefijo Ttenant ID antes de enviar la consulta a la base de datos que mostró la asignación.
Otro enfoque es ingresar un table_prefix a la asignación utilizada por la consulta para que encuentre las tablas correctas para un usuario.
También es posible un enfoque mixto: si el patrón de administración de datos es el patrón de esquema y el prefijo de la tabla está vacío, se produce la asignación predeterminada (nombres de tablas de preparación con ID de usuario).
Patrón de administración de datos de tablas
Se requiere un diseño similar para el patrón de administración de datos de tablas. En este patrón, hay un solo esquema. Los datos de usuarios se almacenan como filas. Para acceder de forma correcta a los datos, agrega un predicado a cada consulta y selecciona el usuario adecuado.
Un enfoque para encontrar el usuario adecuado es tener una columna llamada TENANT en cada tabla. El valor de la columna es tenant ID. Cada consulta debe agregar un predicado AND TENANT = tenant ID a una cláusula WHERE existente o agregar una cláusula WHERE con el predicado AND TENANT = tenant ID.
Para conectarse a la base de datos y crear las consultas adecuadas, el identificador de usuario debe estar disponible en la lógica de la aplicación. Se puede pasar como parámetro o almacenar como contexto de subproceso.
Algunas operaciones del ciclo de vida requieren que modifiques la configuración de asignación del patrón de administración de usuario a dato Por ejemplo, cuando mueves un usuario entre patrones de administración de datos, debes actualizar el patrón de administración de datos y la string de conexión a la base de datos. Es posible que también debas actualizar el prefijo de la tabla.
Generación y atribución de consultas
Un principio subyacente fundamental de las aplicaciones multiusuario es que varios usuarios pueden compartir un solo recurso de nube. Los patrones de administración de datos anteriores se dividen en esta categoría, excepto en el caso de que se asigne un usuario único a una sola instancia de Spanner.
El uso compartido de recursos va más allá de compartir datos. La supervisión y el registro también se comparten; por ejemplo, en el patrón de administración de datos de tabla y el patrón de administración de datos de esquema, todas las consultas de todos los usuarios se registran en el mismo registro de auditoría.
Si se registra una consulta, este debe examinarse el texto de la consulta para determinar para qué usuario se ejecutó. En el patrón de administración de datos de tablas, debes analizar el predicado. En el patrón de administración de datos de esquema, debes analizar uno de los nombres de la tabla.
En el patrón de administración de datos de base de datos o en el de administración de datos de instancia, el texto de la consulta no tiene información de usuarios. A fin de obtener información del usuario para estos patrones, debes consultar la tabla de asignación de patrones de administración de datos a usuarios.
Sería más fácil analizar los registros y las consultas si se determina el usuario para una consulta determinada sin analizar el texto de la consulta. Una forma de identificar de manera uniforme un usuario para una consulta en todos los patrones de administración de datos es agregar un comentario al texto de la consulta que tiene tenant ID y, de forma opcional, una label.
En la siguiente consulta, se seleccionan todos los datos del empleado para el grupo de usuarios que identifica TENANT 356. Para evitar analizar la sintaxis de SQL y extraer el ID de usuario del predicado, el ID de usuario se agrega como un comentario. Se puede extraer un comentario sin tener que analizar la sintaxis de SQL.
select * from EMPLOYEE
-- TENANT 356
where TENANT = 'T356';
o
select * from T356_EMPLOYEE;
-- TENANT 356
Con este diseño, cada ejecución de una consulta para un usuario se atribuye a ese usuario con independencia del patrón de administración de datos. Si un usuario se mueve de un patrón de administración de datos a otro, el texto de la consulta puede cambiar, pero la atribución se mantiene igual en el texto de consulta.
La muestra de código anterior es solo un método. Otro método es insertar un objeto JSON como un comentario en lugar de una etiqueta y un valor:
select * from T356_EMPLOYEE;
-- {"TENANT": 356}
Operaciones del ciclo de vida de acceso de usuario
Según tu filosofía de diseño, una aplicación multiusuario puede implementar directamente las operaciones del ciclo de vida de los datos descritas antes, o puede crear una herramienta de administración de usuarios separada.
Independientemente de la estrategia de implementación, es posible que las operaciones del ciclo de vida deban ejecutarse sin la lógica de la aplicación en ejecución al mismo tiempo. Por ejemplo, mientras se mueve un usuario de un patrón de administración de datos a otro, la lógica de la aplicación no pueden ejecutar porque los datos no están en una sola base de datos. Cuando los datos no están en una sola base de datos, requieren dos operaciones adicionales desde la perspectiva de una aplicación:
- Detener una instancia: Inhabilita todo el acceso a la lógica de la aplicación mientras permite las operaciones del ciclo de vida de los datos.
- Iniciar un usuario: La lógica de la aplicación puede acceder a los datos de un usuario mientras las operaciones del ciclo de vida que interfieren en la lógica de la aplicación están inhabilitadas.
Si bien no se usa con frecuencia, el cierre de un usuario de emergencia puede ser otra operación importante del ciclo de vida. Usa este cierre cuando sospeches un incumplimiento y debas prohibir todo el acceso a los datos del usuario, no solo la lógica de la aplicación, sino también las operaciones del ciclo de vida. Un incumplimiento se puede originar dentro o fuera de la base de datos.
También debe estar disponible una operación del ciclo de vida coincidente que quite el estado de emergencia. Esta operación puede requerir que dos o más administradores accedan al mismo tiempo para implementar el control mutuo.
Aislamiento de aplicaciones
Los diversos patrones de administración de datos admiten diferentes grados de aislamiento de datos de usuarios. Desde el nivel más aislado (instancia) hasta el menos aislado (tabla), son posibles diferentes grados de aislamiento.
En el contexto de una aplicación multiusuario, se debe tomar una decisión de implementación similar: ¿todos los usuarios acceden a sus datos (en patrones de administración de datos posiblemente diferentes) con la misma implementación de la aplicación? Por ejemplo, un clúster de Kubernetes único podría ser compatible con todos los usuarios y cuando un usuario accede a sus datos, el mismo clúster ejecuta la lógica empresarial.
Como alternativa, como en el caso de los patrones de administración de datos, se pueden dirigir diferentes usuarios a distintas implementaciones de aplicaciones. Los usuarios grandes pueden tener acceso a una implementación de aplicación exclusiva para ellos, mientras que los usuarios más pequeños en el nivel gratuito comparten una implementación de aplicación.
En lugar de hacer coincidir de forma directa los patrones de administración de datos que se analizan en este artículo con patrones de administración de datos de aplicación equivalentes, puedes usar el patrón de administración de datos de base de datos para que todos los usuarios compartan una implementación de aplicación única. Es posible que el patrón de administración de datos de base de datos y todos estos usuarios compartan una sola implementación de la aplicación.
La arquitectura multiusuarios es un patrón de administración de datos de aplicación importante, en especial cuando la eficiencia de los recursos juega una función fundamental. Spanner admite varios patrones de administración de datos; úsalo para implementar aplicaciones multiusuario. Gracias a la escalabilidad extrema de Spanner y ANS rigurosos, es una base de datos ideal para implementaciones de aplicaciones multiusuario grandes.
¿Qué sigue?
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.