En esta página se describen varias formas de implementar la multitenencia en Spanner. También se analizan los patrones de gestión de datos y la gestión del ciclo de vida de los inquilinos. Está dirigido a arquitectos de bases de datos, arquitectos de datos e ingenieros que implementan aplicaciones multiinquilino en Spanner como base de datos relacional. En ese contexto, se describen varios enfoques para almacenar datos de varios clientes. Los términos "inquilino", "cliente" y "organización" se usan indistintamente a lo largo del artículo para hacer referencia a la entidad que accede a la aplicación multiinquilino. Los ejemplos que se proporcionan en esta página se basan en la implementación de una aplicación multicliente de un proveedor de SaaS de recursos humanos (RR. HH.) en Google Cloud. Uno de los requisitos es que varios clientes del proveedor de SaaS de RR. HH. deben acceder a la aplicación multiempresa. Estos clientes se denominan inquilinos.
Arquitectura multicliente
La arquitectura multiinquilino es aquella en la que una o varias instancias de una aplicación de software sirven a varios inquilinos o clientes. Este patrón de software se puede escalar de un solo arrendatario o cliente a cientos o miles. Este enfoque es fundamental para las plataformas de computación en la nube, donde la infraestructura subyacente se comparte entre varias organizaciones.
La propiedad múltiple es una forma de partición basada en recursos informáticos compartidos, como las bases de datos. Una analogía sería la de los inquilinos de un edificio de apartamentos: los inquilinos comparten la infraestructura, como las tuberías de agua y las líneas eléctricas, pero cada inquilino tiene un espacio dedicado en un apartamento. La arquitectura multiinquilino forma parte de la mayoría de las aplicaciones de software como servicio (SaaS), si no de todas.
Spanner es una base de datos totalmente gestionada, de nivel empresarial, distribuida y coherente que combina las ventajas del modelo de base de datos relacional con la escalabilidad horizontal no relacional. Google Cloud Spanner tiene semánticas relacionales con esquemas, tipos de datos obligatorios, coherencia sólida, transacciones ACID de varias instrucciones y un lenguaje de consulta SQL que implementa SQL ANSI 2011. Ofrece un tiempo de inactividad cero para las tareas de mantenimiento programadas o los fallos de la región, con un acuerdo de nivel de servicio de disponibilidad del 99,999%. Spanner también admite aplicaciones modernas multiinquilino, ya que proporciona alta disponibilidad y escalabilidad.
Criterios de asignación de datos de inquilinos
En una aplicación multiempresa, los datos de cada empresa se aíslan en uno de los varios enfoques de arquitectura de la base de datos de Spanner subyacente. En la siguiente lista se describen los diferentes enfoques de arquitectura que se usan para asignar los datos de un arrendatario a Spanner:
- Instancia: un arrendatario reside exclusivamente en una instancia de Spanner, con exactamente una base de datos para ese arrendatario.
- Base de datos: un inquilino reside en una base de datos de una sola instancia de Spanner que contiene varias bases de datos.
- Tabla: un arrendatario reside en tablas exclusivas de una base de datos, y varios arrendatarios pueden estar en la misma base de datos.
- Fila: los datos de los clientes son filas de tablas de bases de datos. Esas tablas se comparten con otros inquilinos.
Los criterios anteriores se denominan patrones de gestión de datos y se describen en detalle en la sección Patrones de gestión de datos de multitenencia. Esta conversación se basa en los siguientes criterios:
- Aislamiento de datos: el grado de aislamiento de los datos entre varios clientes es un factor importante en la arquitectura multi-tenant. Por ejemplo, si los datos deben separarse física o lógicamente, y si hay listas de control de acceso independientes que se pueden definir para los datos de cada arrendatario. El aislamiento se basa en las opciones elegidas para los criterios de otras categorías. Por ejemplo, determinados requisitos normativos y de cumplimiento pueden exigir un mayor grado de aislamiento.
- Agilidad: la facilidad de las actividades de incorporación y baja de un arrendatario con respecto a la creación de una instancia, una base de datos, una tabla o una fila.
- Operaciones: disponibilidad o complejidad de la implementación de operaciones de bases de datos y actividades de administración típicas y específicas de cada inquilino. Por ejemplo, operaciones de mantenimiento periódico, registro, copias de seguridad o recuperación tras fallos.
- Escalabilidad: la capacidad de escalar sin problemas para permitir el crecimiento futuro. La descripción de cada patrón contiene el número de arrendatarios que puede admitir.
- Rendimiento:
- Aislamiento de recursos: 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 propietario.
- Recursos mínimos por inquilino: la cantidad mínima media de recursos por inquilino. Esto no significa necesariamente que tengas que pagar al menos esta cantidad por cada inquilino, sino que debes pagar al menos N veces esta cantidad por todos los inquilinos juntos.
- Eficiencia de los recursos: capacidad de usar los recursos inactivos de otros inquilinos para ahorrar costes en general.
- Selección de la ubicación para optimizar la latencia: posibilidad de elegir una topología de replicación específica para cada inquilino, de forma que los datos de cada inquilino se puedan colocar en la ubicación que le proporcione la mejor latencia.
- Reglamentos y cumplimiento: la capacidad de cumplir los requisitos de los sectores y países altamente regulados que requieren el aislamiento completo de los recursos y las operaciones de mantenimiento. Por ejemplo, los requisitos de residencia de datos de Francia exigen que la información personal identificable se almacene físicamente solo en Francia. Las entidades financieras suelen requerir claves de cifrado gestionadas por el cliente (CMEK), y cada arrendatario puede querer usar su propia clave de cifrado.
En la siguiente sección se describe cada patrón de gestión de datos en relación con estos criterios. Usa los mismos criterios al seleccionar un patrón de gestión de datos para un conjunto específico de arrendatarios.
Patrones de gestión de datos multiempresa
En las siguientes secciones se describen los cuatro patrones principales de gestión de datos: instancia, base de datos, tabla y fila.
Instancia
Para ofrecer un aislamiento completo, el patrón de gestión de datos de instancias almacena los datos de cada arrendatario en su propia instancia y base de datos 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 el caso de la aplicación de recursos humanos que hemos mencionado antes, se crea una instancia de Spanner independiente con una base de datos para cada organización de cliente.
Como se muestra en el siguiente diagrama, el patrón de gestión de datos tiene un inquilino por instancia.
Tener instancias independientes para cada arrendatario permite usar proyectosGoogle Cloud independientes para conseguir límites de confianza independientes para diferentes arrendatarios. Una ventaja adicional es que cada configuración de instancia se puede elegir en función de la ubicación de cada arrendatario (regional o multirregional), lo que optimiza la flexibilidad y el rendimiento de la ubicación.
La arquitectura se puede adaptar a cualquier número de clientes. Los proveedores de SaaS pueden crear cualquier número de instancias en las regiones que quieran, sin límites estrictos.
En la siguiente tabla se describe cómo afecta el patrón de gestión de datos de instancias a los diferentes criterios.
| Criterios | Instancia: un patrón de gestión de datos por instancia |
|---|---|
| Aislamiento de datos |
|
| Agilidad |
|
| Operaciones |
|
| Escalar |
|
| Rendimiento |
|
| Requisitos normativos y de cumplimiento |
|
En resumen, los puntos clave son los siguientes:
- Ventaja: el nivel de aislamiento más alto
- Desventaja: mayor sobrecarga operativa y costes potencialmente más elevados debido al mínimo de 100 PUs por inquilino. No se admite compartir recursos entre inquilinos.
El patrón de gestión de datos de instancias es el más adecuado para los siguientes casos:
- Los diferentes clientes se distribuyen en una amplia gama de regiones y necesitan una solución localizada.
- Los requisitos normativos y de cumplimiento de algunos clientes exigen mayores niveles de seguridad y protocolos de auditoría.
- 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.
Base de datos
En el patrón de gestión de datos de la base de datos, cada inquilino reside en una base de datos dentro de una sola instancia de Spanner. Varias bases de datos pueden residir en una sola instancia. Si una instancia no es suficiente para el número de clientes, crea varias instancias. Este patrón implica que una sola instancia de Spanner se comparte entre varios clientes.
Spanner tiene un límite estricto de 100 bases de datos por instancia. Este límite significa que, si el proveedor de SaaS necesita superar los 100 clientes, debe crear y usar varias instancias de Spanner.
En el caso de la aplicación de RR. HH., el proveedor de SaaS crea y gestiona cada arrendatario con una base de datos independiente en una instancia de Spanner.
Como se muestra en el siguiente diagrama, el patrón de gestión de datos tiene un inquilino 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 diferentes clientes. Sin embargo, como se trata de una sola instancia de Spanner, todas las bases de datos de los inquilinos comparten la misma topología de replicación y la misma configuración de computación y almacenamiento subyacentes, a menos que se utilice la función de partición geográfica. Puede usar la función de partición geográfica de Spanner para crear particiones de instancias en diferentes ubicaciones y usar particiones de instancias distintas para diferentes bases de datos en la misma instancia.
En la siguiente tabla se describe cómo afecta el patrón de gestión de datos de la base de datos a los diferentes criterios.
| Criterios | Bases de datos: un inquilino por patrón de gestión de datos de base de datos |
|---|---|
| Aislamiento de datos |
|
| Agilidad |
|
| Operaciones |
|
| Escalar |
|
| Rendimiento |
|
| Requisitos normativos y de cumplimiento |
|
En resumen, los puntos clave son los siguientes:
- Ventaja: nivel moderado de aislamiento de datos y de recursos; nivel moderado de eficiencia de los recursos; cada propietario puede tener su propia copia de seguridad y CMEK.
- Inconveniente: número limitado de inquilinos por instancia; inflexibilidad de la ubicación si no se usa la función de partición geográfica.
El patrón de gestión de datos de bases de datos es el más adecuado para los siguientes casos:
- Varios clientes se encuentran en la misma residencia de datos o están sujetos a la misma autoridad reguladora.
- Los clientes requieren una separación de datos basada en el sistema y la posibilidad de crear copias de seguridad y restaurar sus datos, pero no les importa compartir recursos de infraestructura.
- Los arrendatarios necesitan su propia CMEK.
- El coste es un factor importante. Los recursos mínimos necesarios por inquilino son inferiores al coste de una instancia. Es recomendable que los inquilinos utilicen los recursos inactivos de otros inquilinos.
Tabla
En el patrón de gestión de datos de tabla, se usa una sola base de datos que implementa un solo esquema para varios clientes y se usa un conjunto de tablas independiente para los datos de cada cliente. Estas tablas se pueden diferenciar incluyendo el
tenant ID en los nombres de las tablas como prefijo, sufijo o como
esquemas con nombre.
Este patrón de gestión de datos, que consiste en usar un conjunto de tablas independiente para cada cliente, proporciona un nivel de aislamiento mucho más bajo que las opciones anteriores (los patrones de gestión de instancias y bases de datos). La incorporación implica la creación de nuevas tablas y la integridad referencial y los índices asociados.
Hay un límite de 5000 tablas por base de datos. En el caso de algunos clientes, ese límite puede restringir el uso de la aplicación.
Además, si se usan tablas independientes para cada cliente, se puede generar un gran número de operaciones de actualización de esquemas. Este tipo de acumulación de trabajo tarda mucho tiempo en resolverse.
En el caso de la aplicación de RR. HH., el proveedor de SaaS puede crear un conjunto de tablas para cada cliente con tenant ID como prefijo en los nombres de las tablas. Por ejemplo, customer1_employee, customer1_payroll y customer1_department.
También pueden usar el ID de arrendatario como esquema con nombre y asignar a la tabla los nombres customer1.employee, customer1.payroll y customer1.department.
Como se muestra en el siguiente diagrama, el patrón de gestión de datos de la tabla tiene un conjunto de tablas para cada arrendatario.
En la siguiente tabla se describe cómo afecta el patrón de gestión de datos de tabla a los diferentes criterios.
| Criterios | Tabla: un conjunto de tablas para cada patrón de gestión de datos de clientes |
|---|---|
| Aislamiento de datos |
|
| Agilidad |
|
| Operaciones |
|
| Escalar |
|
| Rendimiento |
|
| Requisitos normativos y de cumplimiento |
|
En resumen, los puntos clave son los siguientes:
- Ventaja: nivel moderado de escalabilidad y eficiencia de recursos.
- Desventaja:
- Nivel moderado de aislamiento de datos y de recursos.
- La ubicación no es flexible si no se usa la nueva función de geopardición.
- No se pueden monitorizar los inquilinos por separado. La única información disponible sobre el consumo de recursos a nivel de tabla son las estadísticas de tamaño de la tabla.
- Los inquilinos no pueden tener sus propias CMEK ni copias de seguridad.
El patrón de gestión de datos de tabla es el más adecuado para los siguientes casos:
- Aplicaciones multiempresa que no requieren legalmente la separación de datos, pero que quieres que tengan una separación lógica y un control de seguridad.
- El coste es un factor importante. El coste mínimo por inquilino es inferior al coste por base de datos.
Acceso
El patrón de gestión de datos final sirve a varios arrendatarios con un conjunto común de tablas, donde cada fila pertenece a un arrendatario específico. Este patrón de gestión de datos representa un nivel extremo de multitenencia en el que todo (desde la infraestructura hasta el esquema y el modelo de datos) se comparte entre varios arrendatarios. En una tabla, las filas se particionan en función de las claves principales, con tenant ID como primer elemento de la clave. Desde el punto de vista del escalado, Spanner es la opción más adecuada para este patrón, ya que puede escalar tablas sin limitaciones.
En el caso de la aplicación de RR. HH., la clave principal de la tabla de nóminas puede ser una combinación de customerID y payrollID.
Como se muestra en el siguiente diagrama, el patrón de gestión de datos de las filas tiene una tabla para varios inquilinos.
A diferencia de todos los demás patrones, el acceso a los datos en el patrón de fila no se puede controlar por separado para diferentes inquilinos. Si se usan menos tablas, las operaciones de actualización de esquemas se completan más rápido cuando cada arrendatario tiene sus propias tablas de base de datos. En gran medida, este enfoque simplifica la incorporación, la baja y las operaciones.
En la siguiente tabla se describe cómo afecta el patrón de gestión de datos de las filas a los diferentes criterios.
| Criterios | Fila: un conjunto de filas para cada patrón de gestión de datos de inquilino |
|---|---|
| Aislamiento de datos |
|
| Agilidad |
|
| Operaciones |
|
| Escalar |
|
| Rendimiento |
|
| Requisitos normativos y de cumplimiento |
|
En resumen, los puntos clave son los siguientes:
- Ventaja: es muy escalable, tiene una sobrecarga operativa baja y una gestión de esquemas simplificada.
- Inconveniente: alta contención de recursos y falta de controles de seguridad y monitorización para cada inquilino.
Este patrón es el más adecuado para las siguientes situaciones:
- Aplicaciones internas dirigidas a diferentes departamentos en las que el aislamiento estricto de los datos no es una preocupación importante en comparación con la facilidad de mantenimiento.
- Compartir recursos al máximo para los clientes que usen aplicaciones de nivel gratuito y, al mismo tiempo, minimizar el aprovisionamiento de recursos.
Patrones de gestión de datos y gestión del ciclo de vida de los inquilinos
En la siguiente tabla se comparan los distintos patrones de gestión de datos en todos los criterios de forma general.
| Instancia | Base de datos | Tabla | Acceso | |
|---|---|---|---|---|
| Aislamiento de datos | Completado | Alta | Moderada | Bajo |
| Agilidad | Bajo | Moderada | Moderada | Más alto |
| Facilidad de las operaciones | Alta | Alta | Bajo | Bajo |
| Escala | Alta | Limitado (a menos que se usen instancias adicionales al alcanzar el límite) | Limitado (a menos que se usen bases de datos adicionales al alcanzar el límite) | Más alto |
| Rendimiento1: aislamiento de recursos | Alta | Bajo | Bajo | Bajo |
| Rendimiento1: recursos mínimos por inquilino | Alta | Moderada alta | Moderada | Sin mínimo por cliente |
| Rendimiento1: eficiencia de recursos | Bajo | Alta | Alto | Alta |
| Rendimiento1: selección de la ubicación para optimizar la latencia | Alta | Moderada | Moderada | Moderada |
| Normativas y cumplimiento | Más alto | Alta | Moderada | Bajo |
1 El rendimiento depende en gran medida del diseño del esquema y de las prácticas recomendadas para las consultas. Los valores que se muestran aquí son solo una expectativa media.
Los mejores patrones de gestión de datos para una aplicación multiempresa específica son aquellos que satisfacen la mayoría de sus requisitos en función de los criterios. Si no se requiere un criterio concreto, puede ignorar la fila en la que se encuentra.
Patrones de gestión de datos combinados
A menudo, un solo patrón de gestión de datos es suficiente para cumplir los requisitos de una aplicación multiinquilino. En ese caso, el diseño puede adoptar un único patrón de gestión de datos.
Algunas aplicaciones multiempresa requieren varios patrones de gestión de datos al mismo tiempo. Por ejemplo, una aplicación multiinquilino que admite un nivel gratuito, un nivel normal y un nivel Enterprise.
Nivel gratuito:
- Debe ser rentable
- Debe tener un límite de volumen de datos superior
- Suele admitir funciones limitadas
- El patrón de gestión de datos de filas es un buen candidato para el nivel gratuito
- La gestión de inquilinos es sencilla
- No es necesario crear recursos de inquilino específicos o exclusivos
Nivel Normal:
- Es una buena opción para los clientes de pago que no tienen requisitos de escalado o aislamiento especialmente exigentes.
- El patrón de gestión de datos de tablas o el patrón de gestión de datos de bases de datos son buenos candidatos para el nivel regular:
- Las tablas y los índices son exclusivos del arrendatario.
- La copia de seguridad es sencilla en el patrón de gestión de datos de la base de datos
- No se admite la copia de seguridad del patrón de gestión de datos de tabla.
- La copia de seguridad de propietario se debe implementar como una utilidad fuera de Spanner.
Nivel Enterprise:
- Normalmente, se trata de un nivel alto con autonomía total en todos los aspectos.
- El arrendatario tiene recursos dedicados, como escalado dedicado y aislamiento completo.
- El patrón de gestión de datos de instancias es adecuado para el nivel Enterprise.
Una práctica recomendada es mantener diferentes patrones de gestión de datos en diferentes bases de datos. Aunque es posible combinar diferentes patrones de gestión de datos en una base de datos de Spanner, esto dificulta la implementación de la lógica de acceso y las operaciones del ciclo de vida de la aplicación.
En la sección Diseño de la aplicación se describen algunas consideraciones sobre el diseño de aplicaciones multiempresa que se aplican al usar uno o varios patrones de gestión de datos.
Gestionar el ciclo de vida del cliente
Los inquilinos tienen un ciclo de vida. Por lo tanto, debes implementar las operaciones de gestión correspondientes en tu aplicación multiempresa. Además de las operaciones básicas de creación, actualización y eliminación de inquilinos, ten en cuenta las siguientes operaciones relacionadas con los datos:
Exportar datos de inquilinos:
- Cuando elimines un arrendatario, te recomendamos que primero exportes sus datos y, si es posible, que le proporciones el conjunto de datos.
- Cuando se usa el patrón de gestión de datos de filas o tablas, el sistema de aplicaciones multiempresa debe implementar la exportación o asignarla a la función de base de datos (exportación de base de datos) e implementar una lógica personalizada para extraer la parte de los datos que corresponde al arrendatario.
Crea una copia de seguridad de los datos del arrendatario:
- Cuando utilices el patrón de gestión de datos de instancias o bases de datos y hagas copias de seguridad de los datos de inquilinos concretos, usa las funciones de exportación o copia de seguridad de la base de datos.
- Cuando se usa el patrón de gestión de datos de tabla o de fila y se hace una copia de seguridad de los datos de inquilinos individuales, la aplicación multiinquilino debe implementar esta operación. La base de datos de Spanner no puede determinar a qué inquilino pertenecen los datos.
Mover datos de un arrendatario:
Para mover un arrendatario de un patrón de gestión de datos a otro (o mover un arrendatario dentro del mismo patrón de gestión de datos entre instancias o bases de datos), es necesario extraer los datos de un patrón de gestión de datos e insertarlos en el nuevo patrón de gestión de datos.
- Si es posible que la aplicación deje de funcionar, realiza una exportación o importación.
- Si no es posible que haya un periodo de inactividad, realiza una migración de base de datos sin tiempo de inactividad.
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 multicliente, implementa una lógica empresarial que tenga en cuenta a los clientes. Esto significa que, cada vez que la aplicación ejecute lógica empresarial, siempre debe estar en el contexto de un arrendatario conocido.
Desde el punto de vista de la base de datos, el diseño de la aplicación implica que cada consulta debe ejecutarse en el patrón de gestión de datos en el que reside el arrendatario. En las secciones siguientes se destacan algunos de los conceptos centrales del diseño de aplicaciones multiempresa.
Configuración dinámica de la conexión y las consultas de inquilinos
Para asignar dinámicamente los datos de los arrendatarios a las solicitudes de aplicaciones de los arrendatarios, se usa una configuración de asignación:
- En el caso de los patrones de gestión de datos de bases de datos o de instancias, una cadena de conexión es suficiente para acceder a los datos de un inquilino.
- Para los patrones de gestión de datos de tabla, se deben determinar los nombres de tabla correctos.
- Para los patrones de gestión de datos de filas, usa los predicados adecuados para obtener los datos de un arrendatario específico.
Un arrendatario puede residir en cualquiera de los cuatro patrones de gestión de datos. La siguiente implementación de la asignación aborda una configuración de conexión para el caso general de una aplicación multiempresa que usa todos los patrones de gestión de datos al mismo tiempo. Cuando un determinado arrendatario reside en un patrón, algunas aplicaciones multiarrendatario usan un patrón de gestión de datos para todos los arrendatarios. Este caso se cubre implícitamente con la siguiente asignación.
Si un arrendatario ejecuta lógica empresarial (por ejemplo, un empleado inicia sesión con su ID de arrendatario), la lógica de la aplicación debe determinar el patrón de gestión de datos del arrendatario, la ubicación de los datos de un ID de arrendatario concreto y, opcionalmente, la convención de nomenclatura de tablas (para el patrón de tabla).
Esta lógica de aplicación requiere una asignación de patrón de inquilino a gestión de datos. En el siguiente ejemplo de código, connection string hace referencia a la base de datos en la que se encuentran los datos del arrendatario. En el ejemplo se identifican la instancia y la base de datos de Spanner. En el caso de la instancia y la base de datos del patrón de gestión 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)
Se necesita un diseño adicional para los patrones de gestión de datos de tablas y filas.
Patrón de gestión de datos de tablas
En el patrón de gestión de datos de tabla, hay varios inquilinos en la misma base de datos. Cada arrendatario tiene su propio conjunto de tablas. Las tablas se distinguen por su nombre. Qué tabla pertenece a qué inquilino es determinista.
Una opción es colocar la tabla de cada arrendatario en un espacio de nombres con el nombre del arrendatario y calificar completamente el nombre de la tabla con namespace.name. Por ejemplo, puedes colocar una tabla EMPLOYEE en el espacio de nombres T356 del arrendatario con el ID 356, y tu aplicación puede usar T356.EMPLOYEE para dirigir las solicitudes a la tabla.
Otra opción es añadir el ID de arrendatario al principio de los nombres de las tablas. Por ejemplo, la tabla EMPLOYEE se llama T356_EMPLOYEE para el arrendatario con el ID 356.
La aplicación debe añadir el prefijo tenant
ID a cada tabla antes de enviar la consulta a la base de datos que ha devuelto la asignación.
Si quiere usar otro texto en lugar del ID de cliente, puede mantener una asignación del ID de cliente al espacio de nombres del esquema con nombre o al prefijo de la tabla.
Para simplificar la lógica de la aplicación, puedes introducir un nivel de indirección. Por ejemplo, puedes usar una biblioteca común con tu aplicación para adjuntar automáticamente el prefijo del espacio de nombres o de la tabla a la llamada del arrendatario.
Patrón de gestión de datos de filas
Se requiere un diseño similar para el patrón de gestión de datos de las filas. En este patrón, hay un solo esquema. Los datos de los arrendatarios se almacenan como filas. Para acceder correctamente a los datos, añade un predicado a cada consulta para seleccionar el arrendatario adecuado.
Una forma de encontrar el arrendatario adecuado es incluir una columna llamada TENANT
en cada tabla. Para mejorar el aislamiento de los datos, el valor de esta columna debe formar parte de la clave principal. 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 inquilino debe estar disponible en la lógica de la aplicación. Se puede transferir como parámetro o almacenar como contexto de conversación.
Para realizar algunas operaciones del ciclo de vida, debe modificar la configuración de la asignación de patrón de gestión de datos a inquilino. Por ejemplo, si mueve un inquilino entre patrones de gestión de datos, debe actualizar el patrón de gestión de datos y la cadena de conexión de la base de datos. También es posible que tengas que actualizar el prefijo de la tabla.
Generación de consultas y atribución
Un principio fundamental de las aplicaciones multiinquilino es que varios inquilinos pueden compartir un único recurso en la nube. Los patrones de gestión de datos anteriores se incluyen en esta categoría, excepto en el caso en el que se asigna un solo inquilino a una sola instancia de Spanner.
El uso compartido de recursos va más allá del uso compartido de datos. La monitorización y el registro también se comparten. Por ejemplo, en el patrón de gestión de datos de tabla y en el patrón de gestión de datos de fila, todas las consultas de todos los inquilinos se registran en el mismo registro de auditoría.
Si se registra una consulta, se debe examinar el texto de la consulta para determinar en qué inquilino se ejecutó. En el patrón de gestión de datos de filas, debes analizar el predicado. En el patrón de gestión de datos de tabla, debes analizar uno de los nombres de tabla.
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 la instancia, el texto de la consulta no contiene información sobre el arrendatario. Para obtener información de los arrendatarios de estos patrones, debes consultar la tabla de asignación de arrendatario a patrón de gestión de datos.
Sería más fácil analizar los registros y las consultas determinando el arrendatario de una consulta determinada sin analizar el texto de la consulta. Una forma de identificar de forma uniforme un arrendatario para una consulta en todos los patrones de gestión de datos es añadir un comentario al texto de la consulta que tenga el valor tenant ID y, opcionalmente, el valor label.
La siguiente consulta selecciona todos los datos de los empleados del arrendatario identificado por TENANT 356. Para evitar analizar la sintaxis SQL y extraer el ID de arrendatario del predicado, el ID de arrendatario 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 que se ejecuta para un arrendatario se atribuye a ese arrendatario, independientemente del patrón de gestión de datos. Si se cambia un inquilino 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 fragmento de código anterior es solo un método. Otra forma es insertar un objeto JSON como comentario en lugar de una etiqueta y un valor:
SELECT * FROM T356_EMPLOYEE;
-- {"TENANT": 356}
También puedes usar etiquetas para atribuir consultas a inquilinos y ver las estadísticas en las tablas spanner_sys integradas.
Operaciones del ciclo de vida del acceso de los propietarios
En función de tu filosofía de diseño, una aplicación multiinquilino puede implementar directamente las operaciones del ciclo de vida de los datos descritas anteriormente o crear una herramienta de administración de inquilinos independiente.
Independientemente de la estrategia de implementación, es posible que las operaciones del ciclo de vida tengan que ejecutarse sin que la lógica de la aplicación se ejecute al mismo tiempo. Por ejemplo, al mover un arrendatario de un patrón de gestión de datos a otro, la lógica de la aplicación no se puede 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, se requieren dos operaciones adicionales desde el punto de vista de la aplicación:
- Detener un arrendatario: inhabilita todo el acceso a la lógica de la aplicación y permite las operaciones del ciclo de vida de los datos.
- Iniciar un arrendatario: la lógica de la aplicación puede acceder a los datos de un arrendatario mientras las operaciones del ciclo de vida que interferirían con la lógica de la aplicación están inhabilitadas.
Aunque no se usa con frecuencia, el cierre de emergencia de un inquilino puede ser otra operación importante del ciclo de vida. Usa este cierre cuando sospeches que se ha producido una brecha y necesites prohibir todo acceso a los datos de un arrendatario, no solo a la lógica de la aplicación, sino también a las operaciones del ciclo de vida. Una brecha puede originarse dentro o fuera de la base de datos.
También debe haber una operación de ciclo de vida correspondiente que quite el estado de emergencia. Para llevar a cabo esta operación, es posible que dos o más administradores tengan que iniciar 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 aislamiento de datos de los clientes. Se pueden aplicar diferentes grados de aislamiento, desde el nivel más aislado (instancia) hasta el menos aislado (fila).
En el contexto de una aplicación multiinquilino, se debe tomar una decisión de implementación similar: ¿todos los inquilinos acceden a sus datos (posiblemente con patrones de gestión de datos diferentes) mediante la misma implementación de la aplicación? Por ejemplo, un clúster de Kubernetes puede admitir a todos los inquilinos y, cuando un inquilino accede a sus datos, el mismo clúster ejecuta la lógica empresarial.
También puede ocurrir que, como en el caso de los patrones de gestión de datos, se dirija a diferentes clientes a diferentes implementaciones de aplicaciones. Los grandes arrendatarios pueden tener acceso a una implementación de aplicaciones exclusiva, mientras que los arrendatarios más pequeños o los que tienen el nivel gratuito comparten una implementación de aplicaciones.
En lugar de asociar directamente los patrones de gestión de datos que se describen en este documento con patrones de gestión de datos de aplicaciones equivalentes, puedes usar el patrón de gestión de datos de bases de datos para que todos los inquilinos compartan una única implementación de la aplicación. Es posible tener el patrón de gestión de datos de la base de datos y que todos estos inquilinos compartan una única implementación de la aplicación.
La arquitectura multiinquilino es un patrón importante de gestión de datos y diseño de aplicaciones, sobre todo cuando la eficiencia de los recursos desempeña un papel fundamental. Spanner admite varios patrones de gestión de datos. Úsalo para implementar aplicaciones multiinquilino. Ofrece un tiempo de inactividad cero para las tareas de mantenimiento programadas o los fallos de la región, con un acuerdo de nivel de servicio de disponibilidad del 99,999%. También admite aplicaciones modernas multiinquilino, ya que ofrece alta disponibilidad y escalabilidad.