En este documento se describen varias formas de implementar la propiedad múltiple en Cloud Spanner. También se tratan los patrones de gestión de datos y la gestión del ciclo de vida de los propietarios.
La propiedad múltiple se produce cuando una sola instancia o varias instancias de una aplicación de software atiende a varios propietarios o clientes. Este patrón de software puede escalar de un solo propietario o de un cliente a cientos o miles. Este enfoque es fundamental para las plataformas de cloud computing en las que se comparte la infraestructura subyacente entre varias organizaciones.
La propiedad múltiple como una forma de partición basada en recursos informáticos compartidos, como bases de datos, Una analogía es la propietario de un edificio de apartamentos: una infraestructura compartida, pero un espacio de propiedad dedicado. La propiedad múltiple forma parte de la mayoría de aplicaciones de software como servicio (SaaS) en su totalidad.
Este documento va dirigido a arquitectos de bases de datos, arquitectos de datos e ingenieros que implementan aplicaciones multicliente en Spanner como su base de datos relacional. En este contexto, describimos diferentes enfoques para almacenar datos de varios propietarios. Los términos "propietario", "cliente" y "organización" se utilizan indistintamente a lo largo del artículo para indicar a la entidad que está accediendo a la aplicación multicliente.
En este artículo se utiliza un proveedor de SaaS de recursos humanos que, por ejemplo, implementa su aplicación de varios propietarios en Google Cloud. En el ejemplo, varios clientes del proveedor de SaaS de RR. HH. deben acceder a la aplicación multicliente. Estos clientes se llaman propietarios.
Spanner es la base de datos empresarial, distribuida, distribuida y uniforme de Google Cloud que combina las ventajas del modelo de base de datos relacional con escalabilidad horizontal no relacional. Spanner tiene semánticas relacionales: con esquemas, tipos de datos aplicados, coherencia fija, transacciones ACID con declaraciones múltiples y un lenguaje de consultas SQL que implementa ANSI 2011 SQL.
Spanner proporciona tiempo de inactividad para las tareas de mantenimiento planificadas o los fallos de región, con un acuerdo de nivel de servicio de disponibilidad del 99,999%. Además, es compatible con aplicaciones modernas y multipropietario con alta disponibilidad y escalabilidad. En este artículo se explican las diferentes técnicas de arquitectura para implementar la propiedad múltiple con Spanner.
Criterios para los criterios de asignación de datos de propietario
En una aplicación de varios propietarios, los datos de cada propietario están aislados en uno de los enfoques de arquitectura de la base de datos de Spanner subyacente. En la siguiente lista se describen las diferentes formas de arquitectura empleadas para asignar los datos de un propietario a Spanner:
- Instancia: un propietario se encuentra exclusivamente en una instancia de Spanner, con una sola base de datos para dicho propietario.
- Base de datos: los propietarios se encuentran en una base de datos de una única instancia de Spanner que contiene varias bases de datos.
- Esquema: un propietario se encuentra en tablas exclusivas dentro de una base de datos y varios propietarios se encuentran en la misma base de datos.
- Tabla: los datos de propietarios son filas de tablas de bases de datos. Esas tablas se comparten con otros propietarios.
Los criterios anteriores se denominan patrones de gestión de datos y se explican en profundidad en la sección Patrones de gestión de datos de propiedad múltiple. Ese debate se basa en los siguientes criterios:
- Aislamiento: el grado de aislamiento de datos entre varios propietarios se considera un factor importante para la propiedad múltiple. El aislamiento se rige por las decisiones que se toman en los criterios de otras categorías, como por ejemplo, ciertos requisitos normativos y de cumplimiento normativo pueden suponer una mayor gravedad.
- Agilidad: facilidad de incorporación y de desactivación de actividades para un propietario con respecto a la creación de instancias, bases de datos o tablas.
- Operaciones: disponibilidad o complejidad de la implementación de actividades habituales de gestión de bases de datos y actividades de los propietarios habituales, como el mantenimiento periódico, el almacenamiento de registros, las copias de seguridad o las operaciones de recuperación tras fallos.
- Escala: la posibilidad de escalar sin problemas para crecer de forma óptima La descripción de cada patrón contiene el número de propietarios que admite.
- Rendimiento: la capacidad de asignar recursos exclusivos a cada propietario, tratar el fenómeno de no vecino y permitir un rendimiento predecible de lectura y escritura para cada uno. propietario.
- Reglamento y cumplimiento: la capacidad de satisfacer los requisitos de sectores y países altamente regulados que requieren la plena clasificación de recursos y operaciones de mantenimiento (por ejemplo, los requisitos de residencia de datos para Francia exige que la información personal identificable se almacene físicamente en Francia.
En la siguiente sección se detalla cada patrón de gestión de datos relacionado con estos criterios. Utiliza los mismos criterios al seleccionar un patrón de gestión de datos para un conjunto específico de propietarios.
Patrones de gestión de datos de propiedad múltiple
En las siguientes secciones se describen los cuatro patrones de gestión de datos principales: instancia, base de datos, esquema y tabla.
Instancia
Para proporcionar un aislamiento completo, el patrón de gestión de datos de instancia almacena los datos de cada propietario en su propia base de datos y instancia de Spanner. Una instancia de Spanner puede tener una o varias bases de datos. En este patrón, solo se crea una base de datos. En la aplicación de RR. HH. mencionada anteriormente, se crea una instancia de Spanner independiente con una base de datos por cada organización de cliente.
Como se ve en el siguiente diagrama, el patrón de gestión de datos tiene un único propietario por instancia.
Al tener instancias independientes para cada propietario, se pueden usar proyectos de Google Cloud independientes para alcanzar límites de confianza independientes para cada propietario. Una ventaja adicional es que cada configuración de instancia se puede elegir en función de la ubicación de cada propietario (ya sea regional o multirregional), además de optimizar la flexibilidad y el rendimiento de la ubicación.
La arquitectura puede adaptarse fácilmente a cualquier número de propietarios. Los proveedores de SaaS pueden crear cualquier cantidad de instancias en las regiones que quieras, sin límite estricto.
En la siguiente tabla se describe cómo influye el patrón de gestión de datos de instancia en diferentes criterios.
| Criterios | Instancia: un propietario por patrón de gestión de datos de instancia |
|---|---|
| Aislamiento |
|
| Agilidad |
|
| Operaciones |
|
| Escalar |
|
| Rendimiento |
|
| Requisitos normativos y de cumplimiento normativo |
|
Estas son las conclusiones más importantes:
- Ventaja: el nivel de aislamiento más alto
- Inconvenientes: mayor sobrecarga operativa
El patrón de gestión de datos de instancias es el más adecuado para las siguientes situaciones:
- Varios propietarios se encuentran en una amplia variedad de regiones y necesitan una solución localizada.
- Los requisitos normativos y de cumplimiento de algunos propietarios exigen grandes niveles de seguridad y auditorías.
- El tamaño de los propietarios varía considerablemente, de modo que el hecho de compartir recursos entre los propietarios con gran volumen de tráfico y con un gran volumen de tráfico puede causar congestión y degradación mutua.
Database
En el patrón de gestión de datos de la base de datos, cada propietario figura en una base de datos de una única instancia de Spanner. Pueden encontrarse varias bases de datos en una sola instancia. Si una instancia no es suficiente para el número de propietarios, crea varias instancias. Este patrón implica que una misma instancia de Spanner se comparte entre varios propietarios.
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 a más de 100 clientes, debe crear y usar varias instancias de Spanner.
En la aplicación de recursos humanos, el proveedor de SaaS crea y gestiona cada propietario con una base de datos independiente en una instancia de Spanner.
Como se ve en el diagrama siguiente, el patrón de gestión de datos tiene un único propietario por base de datos.
El patrón de gestión de datos de la base de datos consigue un aislamiento lógico a nivel de base de datos para los datos de los inquilinos. Sin embargo, como se trata de una sola instancia de Spanner, todas las bases de datos del propietario comparten la misma configuración regional y la configuración de computación y de almacenamiento subyacente.
En la siguiente tabla se describe cómo afecta el patrón de gestión de datos de la base de datos a distintos criterios.
| Criterios | Base de datos: un propietario por patrón de gestión de datos de base de datos. |
|---|---|
| Aislamiento |
|
| Agilidad |
|
| Operaciones |
|
| Escalar |
|
| Rendimiento |
|
| Requisitos normativos y de cumplimiento normativo |
|
Estas son las conclusiones más importantes:
- Ventajas: un mayor nivel de aislamiento.
- Inconvenientes: número limitado de propietarios por instancia inflexible de ubicación
El patrón de gestión de datos de bases de datos es el más adecuado para los casos siguientes:
- Hay varios clientes en la misma residencia de datos, como Francia o el Reino Unido, o que pertenecen a la misma autoridad normativa.
- Los propietarios necesitan separar los datos y crear copias de seguridad y restaurar los datos basados en el sistema, pero están más adecuados para el uso compartido de recursos de la infraestructura.
Esquema
En el patrón de gestión de datos del esquema, se utiliza una única base de datos (que implementa un único esquema) para varios propietarios y un conjunto independiente de tablas para los datos de cada propietario. Estas tablas se pueden diferenciar si se incluye la variable tenant ID en los nombres de tablas mediante un prefijo o un sufijo.
Este patrón de gestión de datos que usa un conjunto de tablas independiente para cada propietario proporciona un nivel de aislamiento mucho más bajo en comparación con las opciones anteriores (los patrones de gestión de instancias y bases de datos). El patrón también hace que la incorporación sea sencilla: implica la creación de tablas y la indexación y los índices de referencia asociados.
Una advertencia importante es que los permisos de acceso de Spanner mediante la gestión de identidades y accesos (IAM) solo se proporcionan a nivel de instancia o de base de datos. No se pueden proporcionar permisos de acceso a nivel de tabla. También hay un límite de 5000 tablas por base de datos. Para muchos clientes, limita ese uso de la aplicación.
Además, el uso de tablas independientes para cada cliente puede dar lugar a un gran número de operaciones de actualización de esquemas. La resolución de este trabajo es demasiado tiempo.
En la aplicación de HR, el proveedor de SaaS puede crear un conjunto de tablas para cada cliente cuyo valor de tenant ID es el prefijo en los nombres de las tablas. Por ejemplo, customer1_employee, customer1_payroll, customer1_department.
Como se ve en el siguiente diagrama, el patrón de gestión de datos del esquema tiene un conjunto de tablas para cada propietario.
En la siguiente tabla se describe cómo afecta el patrón de gestión de datos de esquema a diferentes criterios.
| Criterios | Esquema: un conjunto de tablas para cada patrón de gestión de datos de propietarios. |
|---|---|
| Aislamiento |
|
| Agilidad |
|
| Operaciones |
|
| Escalar |
|
| Rendimiento |
|
| Requisitos normativos y de cumplimiento normativo |
|
Estas son las conclusiones más importantes:
- Ventajas: el proceso de incorporación es trivial.
- Inconvenientes: mayor sobrecarga operativa. sin controles de seguridad a nivel de tabla
El patrón de gestión de datos del esquema es más adecuado en las situaciones siguientes:
- Las aplicaciones internas que se aplican a diferentes departamentos cuando el estricto aislamiento de seguridad de los datos no tienen ningún problema para compararlo con la facilidad de mantenimiento.
- Aplicaciones multicliente en las que los datos no requieran desviación estricta según los requisitos legales o reglamentarios.
Aunque es posible crear varios conjuntos de tablas (cada uno que representa a un propietario) en una base de datos, este es el patrón menos idóneo desde la perspectiva de una base de datos. El principal motivo es que las tablas deben seguir las convenciones de nomenclatura. La aplicación y todas las herramientas de base de datos (por ejemplo, las herramientas de migración de esquemas y IDE) deben comprender la convención de nomenclatura. Además, si el número de tablas es suficientemente grande por propietario, el patrón de gestión de datos de esquema no proporciona un escalado significativo.
Un mejor enfoque es migrar a una base de datos por propietario y aumentar el número de instancias, o bien continuar por el patrón de gestión de datos de la tabla.
Tabla
El patrón de gestión de datos final sirve a varios propietarios con un conjunto común de tablas. Cada tabla contiene datos de varios propietarios. Este patrón de gestión de datos representa un nivel extrema de propiedad múltiple entre las que se comparten todos los propietarios, desde la infraestructura hasta el esquema de datos, pasando por el modelo de datos. Dentro de una tabla, las filas se dividen en claves principales y tenant ID es el primer elemento de la clave. Desde una perspectiva de escalado, Spanner admite este patrón mejor, ya que puede escalar tablas sin límites.
En la aplicación HR, la clave principal de la tabla de nóminas puede ser una combinación de customerID y payrollID.
Como se ve en el diagrama siguiente, el patrón de gestión de datos de tabla tiene una tabla para varios inquilinos.
Como ocurre con el patrón de esquema, los accesos de datos del patrón de tabla no se pueden controlar por separado para cada propietario. Al utilizar menos tablas, las operaciones de actualización de esquema se completan más rápido cuando cada propietario tiene sus propias tablas de base de datos. Esta estrategia simplifica la incorporación de operaciones, operaciones de incorporación y operaciones.
En la siguiente tabla se describe cómo el patrón de gestión de datos de la tabla afecta a diferentes criterios.
| Criterios | Tabla: una tabla para varios patrones de gestión de datos de propietarios |
|---|---|
| Aislamiento |
|
| Agilidad |
|
| Operaciones |
|
| Escalar |
|
| Rendimiento |
|
| Requisitos normativos y de cumplimiento normativo |
|
Estas son las conclusiones más importantes:
- Ventajas: muy escalable. tiene una sobrecarga operativa
- Inconvenientes: contenido muy interesante. la falta de controles de seguridad para cada propietario
Este patrón es el más adecuado para las situaciones siguientes:
- Las aplicaciones internas que se aplican a diferentes departamentos cuando el estricto aislamiento de seguridad de los datos no tienen ningún problema para comparar con el mantenimiento.
- Uso compartido de recursos máximo con propietarios que utilizan funciones de aplicaciones de nivel gratuito al minimizar el aprovisionamiento de recursos a la vez.
Patrones de gestión de datos y gestión del ciclo de vida de los propietarios
En la siguiente tabla se comparan los distintos patrones de gestión de datos en todos los criterios de un nivel superior.
| Instancia | Database | Esquema | Tabla | |
|---|---|---|---|---|
| Aislamiento | Caducada | Caducada | Baja | Valor más bajo |
| Agilidad | Baja | Moderada | Moderada | Valor más alto |
| Facilidad de operaciones | Alta | Alta | Baja | Baja |
| Escala | Alta | Limitado | Posiblemente limitado | Alta |
| Rendimiento* | Alta | Moderada | Moderada | Potencial |
| Reglamento y cumplimiento | Valor más alto | Alta | Baja | Baja |
* El rendimiento depende en gran medida del diseño de los esquemas y de las prácticas recomendadas de las consultas. Aquí solo se indican los valores promedios.
Los mejores patrones de gestión de datos para una aplicación con varios propietarios son los que cumplen la mayoría de sus requisitos en función de los criterios. Si no se requiere un criterio concreto, puedes ignorar la fila en la que se encuentre.
Patrones de gestión de datos combinados
A menudo, un patrón de gestión de datos es suficiente para satisfacer los requisitos de una aplicación multicliente. Cuando este es el caso, el diseño puede suponer un único patrón de gestión de datos.
Algunas aplicaciones multicliente requieren varios patrones de gestión de datos al mismo tiempo; sin embargo, una aplicación con varios propietarios, compatible con un nivel gratuito, un nivel estándar y un nivel de empresa.
Nivel gratuito:
- Deben ser rentables.
- Debe tener un límite de volumen de datos superior.
- Normalmente admite funciones limitadas
- El patrón de gestión de datos de tabla es un buen candidato de nivel gratuito.
- La gestión de los propietarios es sencilla
- No es necesario crear recursos de propietario específicos o exclusivos
Nivel habitual:
- Ideal para clientes de pago que no tengan unos requisitos específicos de escalado o aislamiento
- El patrón de gestión de datos del esquema o el patrón de gestión de datos de base de datos es un buen candidato normal.
- Las tablas e índices son exclusivos del propietario.
- El patrón de gestión de datos de la base de datos es sencillo
- No se admite la copia de seguridad con el patrón de gestión de datos de esquema
- La copia de seguridad propietario se debe implementar como una utilidad fuera de Spanner
Nivel empresarial:
- Suele ser un nivel de alto nivel con autonomía completa en todos los aspectos.
- Tenant cuenta con recursos dedicados que incluyen escalado dedicado y aislamiento completo.
- El patrón de gestión de datos de instancias es adecuado para la empresa.
Una práctica recomendada es mantener diferentes patrones de gestión de datos en diferentes bases de datos. Si bien es posible combinar diferentes patrones de gestión de datos en una base de datos de Spanner, hacerlo dificulta la implementación de las operaciones de ciclo de vida y de acceso de la aplicación.
En la sección Diseño de aplicaciones se describen varias consideraciones sobre el diseño de aplicaciones de varios propietarios que se aplican cuando se utilizan un solo patrón de gestión de datos o varios patrones de gestión de datos.
Gestionar el ciclo de vida de los propietarios
Los clientes tienen un ciclo de vida. Por lo tanto, debes implementar las operaciones de gestión correspondientes en tu aplicación multicliente. Además de las operaciones básicas de crear, actualizar y eliminar propietarios, ten en cuenta las siguientes operaciones relacionadas con los datos:
Exportar datos de inquilino:
- Al eliminar un propietario, te recomendamos que exportes sus datos primero y que los conjuntos de datos estén a disposición de ellos.
- Al usar el patrón de gestión de datos de tablas o esquemas, el sistema de aplicaciones multicliente debe implementar la exportación o asignarla a la funcionalidad de la base de datos (exportación de la base de datos).
Crear copias de seguridad de los datos del propietario:
- Cuando utilices el patrón de administración de datos de instancia o base de datos y copias de seguridad de los datos de propietarios individuales, usa las funciones de exportación o copia de seguridad de la base de datos.
- Al usar el patrón de gestión de datos de esquema o tabla y crear una copia de seguridad de los datos de propietarios individuales, la aplicación de varios propietarios debe implementar esta operación. La base de datos de Spanner no puede determinar qué datos pertenece a cada propietario.
Transferir datos de propietarios:
Para mover un propietario de un patrón de gestión de datos a otro, o mover un propietario dentro del mismo patrón de gestión de datos entre instancias o bases de datos, se deben extraer los datos del patrón de gestión de datos de la tabla e insertar dichos datos en el patrón de gestión de datos de la base de datos.
- Cuando se produzca un periodo inactivo de la aplicación, lleva a cabo una exportación o importación.
- Cuando no se pueden aplicar periodos de inactividad, realiza una migración de bases de datos de periodos inactivos.
Identificar la situación de un vecino ruidoso es otra razón para trasladar a los inquilinos.
Diseño de aplicaciones
Cuando diseñes una aplicación para varios propietarios, implementa una lógica empresarial empresarial. Esto significa que cada vez que la aplicación ejecuta la lógica empresarial, siempre debe estar en el contexto de un propietario conocido.
Desde la perspectiva de la base de datos, el diseño de una aplicación implica que cada consulta se debe ejecutar contra el patrón de gestión de datos en el que se encuentra el propietario. En las siguientes secciones, se destacan algunos de los conceptos centrales del diseño de aplicaciones de varios propietarios.
Conexión dinámica de propietario y configuración de consultas
La asignación dinámica de datos de propietario a las solicitudes de aplicaciones de propietarios utiliza una configuración de asignación:
- Para los patrones de gestión de datos de base de datos o los de gestión de datos de instancia, una cadena de conexión es suficiente para acceder a los datos de inquilino.
- En los patrones de gestión de datos del esquema, se deben determinar los nombres de tabla correctos.
- En el caso de los patrones de gestión de datos de tabla, las consultas se tienen que ejecutar con la base de datos. Usa los predicados adecuados para obtener los datos de un propietario concreto.
El propietario puede residir en cualquiera de los cuatro patrones de gestión de datos. La siguiente implementación de asignación trata una configuración de conexión para el caso general de una aplicación multicliente que utiliza todos los patrones de gestión de datos al mismo tiempo. Cuando un propietario concreto reside en un patrón, algunas aplicaciones multicliente usan un patrón de gestión de datos para todos los propietarios. Este caso está cubierto implícitamente por la siguiente asignación.
Si un propietario ejecuta la lógica empresarial (por ejemplo, un empleado que inicia sesión con su ID de propietario), la lógica de la aplicación debe determinar el patrón de gestión de datos del propietario, la ubicación de los datos de un ID de propietario determinado y, De manera opcional, la convención de nomenclatura de tablas (para el patrón de esquema).
Esta lógica de aplicación requiere una asignación de patrón de propietario a datos-gestión. En el siguiente ejemplo de código, connection string hace referencia a la base de datos en la que se encuentran los datos de los propietarios. El ejemplo identifica la instancia de Spanner y la base de datos. Para la instancia del patrón de gestión de datos y la base de datos, el siguiente código es suficiente para que la aplicación se conecte y ejecute consultas:
tenant id -> (data management pattern,
database connection string,
[table_prefix])
Se requieren diseños adicionales para los patrones de gestión de datos de tablas y tablas.
Patrón de gestión de datos de esquemas
En el caso del patrón de gestión de datos del esquema, existen varios inquilinos en la misma base de datos. Cada propietario tiene su propio conjunto de tablas. Las tablas se distinguen por su nombre. La tabla que pertenece a cada propietario es determinante.
Una estrategia es añadir al nombre de la tabla los nombres de los propietarios. Por ejemplo, la tabla EMPLOYEE se llama T356_EMPLOYEE para el propietario con el ID 356. La aplicación debe anteponer cada tabla con el prefijo Ttenant ID antes de enviar la consulta a la base de datos que ha devuelto la asignación.
Otro método es añadir un objeto table_prefix a la asignación utilizada por la consulta para encontrar las tablas correctas de un propietario.
También se puede aplicar una estrategia mixta: si el patrón de gestión de datos es el patrón de esquema y el prefijo de la tabla está vacío, se realiza la asignación predeterminada (nombres de tabla finales con IDs de propietario).
Patrón de gestión de datos de tabla
Se requiere un diseño similar para el patrón de gestión de datos de tablas. En este patrón, hay un solo esquema. Los datos de los propietarios se almacenan como filas. Para acceder correctamente a los datos, añade un predicado a cada consulta para seleccionar al propietario adecuado.
Un método para encontrar al propietario adecuado es tener una columna llamada TENANT en cada tabla. El valor de la columna es tenant ID. Cada consulta debe añadir un predicado AND TENANT = tenant ID a una cláusula WHERE o añadir 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 propietario debe estar disponible en la lógica de la aplicación. Se puede transferir como parámetro o almacenar como contexto de conversación.
Algunas operaciones del ciclo de vida requieren que modifiques la configuración de asignación de propietario a datos-gestión-patrón. Por ejemplo, cuando mueves un propietario entre patrones de gestión de datos, debes actualizar el patrón de gestión de datos. La cadena de conexión de la base de datos. Es posible que también tengas que actualizar el prefijo de la tabla.
Generación de consultas y atribución
Un principio fundamental de aplicaciones multicliente es que varios propietarios pueden compartir un solo recurso de la nube. Los patrones de gestión de datos anteriores se incluyen en esta categoría, excepto en el caso de que un único propietario se asigne a una sola instancia de Spanner.
Para compartir recursos, no basta con compartir los datos. También se comparten la supervisión y el almacenamiento de registros (por ejemplo, en el patrón de gestión de datos de tablas y el patrón de gestión de datos de esquema), todas las consultas de todos los propietarios se registran en el mismo registro de auditoría.
Si se registra una consulta, el texto de la consulta debe examinarse para determinar a qué propietario se ha ejecutado la consulta. En el patrón de gestión de datos de tabla, debes analizar el predicado. En el patrón de gestión de datos del esquema, debes analizar uno de los nombres de las tablas.
En el patrón de gestión de datos de la base de datos o en el patrón de gestión de datos de instancia, el texto de la consulta no contiene información del propietario. Para obtener información sobre los propietarios de estos patrones, debes consultar la tabla de asignación de propietario a datos-gestión-patrón.
Sería más sencillo analizar los registros y las consultas determinando el propietario de una consulta determinada sin analizar el texto de la consulta. Una forma de identificar de un modo uniforme a un propietario de una consulta en todos los patrones de gestión de datos es añadir un comentario al texto de la consulta que tenga el elemento tenant ID y, opcionalmente, un label.
La siguiente consulta selecciona todos los datos de los empleados del propietario identificado por TENANT 356. Para no analizar la sintaxis SQL y extraer el ID del propietario del predicado, el ID del propietario se añade como comentario. Se puede extraer un comentario sin tener que analizar la sintaxis SQL.
select * from EMPLOYEE
-- TENANT 356
where TENANT = 'T356';
o
select * from T356_EMPLOYEE;
-- TENANT 356
Con este diseño, cada consulta de ejecución de un propietario se atribuye a dicho propietario independiente del patrón de gestión de datos. Si un propietario se traslada de un patrón de gestión de datos a otro, el texto de la consulta puede cambiar, pero la atribución sigue siendo la misma en el texto de la consulta.
El código de ejemplo anterior es solo un método. Otro método es insertar un objeto JSON como comentario en lugar de una etiqueta y valor:
select * from T356_EMPLOYEE;
-- {"TENANT": 356}
Operaciones de ciclo de vida de acceso de los propietarios
Dependiendo de tu filosofía de diseño, una aplicación para varios propietarios puede implementar directamente las operaciones del ciclo de vida de los datos descritas anteriormente o crear una herramienta de administración de propietarios independiente.
Independientemente de la estrategia de implementación, es posible que las operaciones del ciclo de vida se ejecuten sin que la lógica de la aplicación se ejecute al mismo tiempo. Por ejemplo, al transferir un propietario de un patrón de gestión de datos a otro, la lógica de la aplicación. no puede ejecutarse porque los datos no están en una sola base de datos. Si los datos no están en una sola base de datos, se necesitan dos operaciones adicionales desde la perspectiva de la aplicación:
- Detener el propietario: inhabilita el acceso lógico a la aplicación y permite llevar a cabo operaciones de ciclo de vida de los datos.
- Inicio de un propietario: la lógica de la aplicación puede acceder a los datos de un propietario mientras que las operaciones de ciclo de vida que interfieren en la lógica de la aplicación están inhabilitadas.
Aunque no se suele utilizar, es posible que una persona que cierre de emergencia pueda ser un importante movimiento de ciclo de vida importante. Utiliza este cierre cuando sospechas que se ha producido una quiebra de seguridad y tienes que prohibir el acceso a todos los datos de los propietarios, no solo a la lógica de las aplicaciones, sino también al funcionamiento de los ciclos de vida. Una quiebra de seguridad puede ser desde dentro o fuera de la base de datos.
También debe estar disponible una operación de ciclo de vida coincidente que elimine el estado de emergencia. Dicha operación puede requerir que dos o más administradores inicien sesión al mismo tiempo para implementar el control mutuo.
Aislamiento de aplicaciones
Los distintos patrones de gestión de datos admiten diferentes grados de segmentación de datos de inquilino. Puede haber distintos niveles de aislamiento, desde el nivel más aislado (instancia) al nivel menos aislado (tabla).
En el caso de las aplicaciones multicliente, se debe tomar una decisión similar sobre el despliegue: ¿todos los propietarios pueden acceder a sus datos (con patrones de gestión de datos diferentes) con el mismo despliegue de aplicaciones? Por ejemplo, un solo clúster de Kubernetes puede admitir todos los propietarios y, cuando un propietario acceda a sus datos, el mismo clúster ejecuta la lógica empresarial.
Como alternativa, en el caso de los patrones de gestión de datos, se podría dirigir a diferentes propietarios a distintos despliegues de aplicaciones. Es posible que los propietarios grandes tengan acceso a una implementación de aplicaciones exclusiva, mientras que los propietarios o propietarios más pequeños del nivel gratuito comparten la implementación de una aplicación.
En lugar de que coincidan directamente con los patrones de gestión de datos tratados en este artículo con patrones de gestión de datos de aplicaciones equivalentes, puedes usar el patrón de gestión de datos de la base de datos para que todos los propietarios compartan un mismo despliegue. Es posible que el patrón de gestión de datos de la base de datos y todos estos propietarios compartan un mismo despliegue de aplicación.
La propiedad múltiple es un importante patrón de gestión de datos de diseño de aplicaciones, especialmente cuando la eficiencia de los recursos es fundamental. Spanner admite varios patrones de gestión de datos. itsalo para implementar aplicaciones multicliente. Gracias a la escalabilidad extrema y a los rigurosos acuerdos de nivel de servicio de Spanner, es una base de datos idónea para los despliegues de grandes aplicaciones de varios propietarios.
Siguientes pasos
- Explora arquitecturas de referencia, diagramas, tutoriales y prácticas recomendadas sobre Google Cloud. Echa un vistazo a Cloud Architecture.