Esta página descreve várias formas de implementar a multi-posse no Spanner. Também aborda padrões de gestão de dados e gestão do ciclo de vida do inquilino. Destina-se a arquitetos de bases de dados, arquitetos de dados e engenheiros que implementam aplicações multi-inquilino no Spanner como base de dados relacional. Com base nesse contexto, descreve várias abordagens para armazenar dados multi-inquilinos. Os termos "inquilino", "cliente" e "organização" são usados de forma intercambiável ao longo do artigo para indicar a entidade que está a aceder à aplicação multi-inquilino. Os exemplos fornecidos nesta página baseiam-se na implementação da aplicação multiinquilino de um fornecedor de SaaS de recursos humanos (RH) no Google Cloud. Um dos requisitos é que vários clientes do fornecedor de SaaS de RH tenham de aceder à aplicação multi-inquilino. Estes clientes são denominados inquilinos.
Multitenancy
A multilocação ocorre quando uma única instância ou algumas instâncias de uma aplicação de software servem vários locatários ou clientes. Este padrão de software pode ser dimensionado de um único inquilino ou cliente para centenas ou milhares. Esta abordagem é fundamental para as plataformas de cloud computing, onde a infraestrutura subjacente é partilhada entre várias organizações.
Pense na multi-tenancy como uma forma de partição baseada em recursos de computação partilhados, como bases de dados. Uma analogia é a dos inquilinos num prédio de apartamentos: os inquilinos partilham a infraestrutura, como os canos de água e as linhas elétricas, mas cada inquilino tem um espaço dedicado num apartamento. A multi-tenancy faz parte da maioria, se não de todas, as aplicações de software como serviço (SaaS).
O Spanner é uma base de dados totalmente gerida, de nível empresarial, distribuída e consistente que combina as vantagens do modelo de base de dados relacional com a escalabilidade horizontal não relacional. Google Cloud O Spanner tem semântica relacional com esquemas, tipos de dados aplicados, consistência forte, transações ACID de várias declarações e uma linguagem de consulta SQL que implementa o SQL ANSI 2011. Oferece tempo de inatividade zero para manutenção planeada ou falhas de regiões, com um SLA de disponibilidade de 99,999%. O Spanner também suporta aplicações modernas com vários inquilinos, oferecendo elevada disponibilidade e escalabilidade.
Critérios para critérios de mapeamento de dados de inquilinos
Numa aplicação multi-inquilino, os dados de cada inquilino estão isolados numa das várias abordagens de arquitetura na base de dados do Spanner subjacente. A lista seguinte descreve as diferentes abordagens de arquitetura usadas para mapear os dados de um inquilino para o Spanner:
- Instância: um inquilino reside exclusivamente numa instância do Spanner, com exatamente uma base de dados para esse inquilino.
- Base de dados: um inquilino reside numa base de dados numa única instância do Spanner que contém várias bases de dados.
- Tabela: um inquilino reside em tabelas exclusivas numa base de dados, e vários inquilinos podem estar localizados na mesma base de dados.
- Linha: os dados do inquilino são linhas em tabelas de base de dados. Essas tabelas são partilhadas com outros inquilinos.
Os critérios anteriores são denominados padrões de gestão de dados e são abordados em detalhe na secção Padrões de gestão de dados de multi-inquilinos. Essa discussão baseia-se nos seguintes critérios:
- Isolamento de dados: o grau de isolamento de dados em vários inquilinos é uma consideração importante para a multi-posse. Por exemplo, se os dados têm de ser separados física ou logicamente e se existem ACLs (listas de controlo de acesso) independentes que podem ser definidas para os dados de cada inquilino. O isolamento é determinado pelas escolhas feitas para os critérios noutras categorias. Por exemplo, determinados requisitos regulamentares e de conformidade podem exigir um maior grau de isolamento.
- Agilidade: a facilidade de integração e desativação de atividades para um inquilino no que diz respeito à criação de uma instância, uma base de dados, uma tabela ou uma linha.
- Operações: a disponibilidade ou a complexidade da implementação de operações de base de dados típicas, específicas do inquilino e atividades de administração. Por exemplo, operações de manutenção, registo, cópias de segurança ou recuperação de desastres regulares.
- Escala: a capacidade de escalar facilmente para permitir o crescimento futuro. A descrição de cada padrão contém o número de inquilinos que o padrão pode suportar.
- Desempenho:
- Isolamento de recursos: a capacidade de atribuir recursos exclusivos a cada inquilino, resolver o fenómeno do vizinho ruidoso e permitir um desempenho de leitura e escrita previsível para cada inquilino.
- Recursos mínimos por inquilino: a quantidade mínima média de recursos por inquilino. Isto não significa necessariamente que tem de pagar, pelo menos, este valor por cada inquilino individual, mas sim que tem de pagar, pelo menos, N * este valor por todos os N inquilinos em conjunto.
- Eficiência dos recursos: a capacidade de usar recursos inativos de outros inquilinos para poupar no custo geral.
- Seleção da localização para otimização da latência: a capacidade de escolher uma topologia de replicação específica para cada inquilino, de modo que os dados de cada inquilino possam ser colocados na localização que oferece a melhor latência para o inquilino.
- Regulamentos e conformidade: a capacidade de satisfazer os requisitos de setores e países altamente regulamentados que exigem o isolamento completo dos recursos e das operações de manutenção. Por exemplo, os requisitos de residência de dados para França exigem que as informações de identificação pessoal sejam armazenadas fisicamente apenas em França. Normalmente, os setores financeiros requerem chaves de encriptação geridas pelo cliente (CMEK) e cada inquilino pode querer usar a sua própria chave de encriptação.
Cada padrão de gestão de dados, no que diz respeito a estes critérios, é detalhado na secção seguinte. Use os mesmos critérios quando selecionar um padrão de gestão de dados para um conjunto específico de inquilinos.
Padrões de gestão de dados de multi-tenancy
As secções seguintes descrevem os quatro principais padrões de gestão de dados: instância, base de dados, tabela e linha.
Instância
Para oferecer um isolamento completo, o padrão de gestão de dados da instância armazena os dados de cada inquilino na respetiva instância e base de dados do Spanner. Uma instância do Spanner pode ter uma ou mais bases de dados. Neste padrão, é criada apenas uma base de dados. Para a aplicação de RH abordada anteriormente, é criada uma instância do Spanner separada com uma base de dados para cada organização do cliente.
Conforme apresentado no diagrama seguinte, o padrão de gestão de dados tem um inquilino por instância.
Ter instâncias separadas para cada inquilino permite a utilização deGoogle Cloud projetos separados para alcançar limites de confiança separados para diferentes inquilinos. Uma vantagem adicional é que cada configuração de instância pode ser escolhida com base na localização de cada inquilino (regional ou multirregionalmente), o que otimiza a flexibilidade e o desempenho da localização.
A arquitetura pode ser dimensionada para qualquer número de inquilinos. Os fornecedores de SaaS podem criar qualquer número de instâncias nas regiões pretendidas, sem limites rígidos.
A tabela seguinte descreve como o padrão de gestão de dados da instância afeta diferentes critérios.
| Critérios | Instância: um inquilino por padrão de gestão de dados de instância |
|---|---|
| Isolamento de dados |
|
| Agilidade |
|
| Operações |
|
| Evolua |
|
| Desempenho |
|
| Requisitos regulamentares e de conformidade |
|
Em resumo, os principais pontos a reter são:
- Vantagem: o nível de isolamento mais elevado
- Desvantagem: maior sobrecarga operacional e custo potencialmente mais elevado devido ao mínimo de 100 PUs por inquilino. A partilha de recursos entre inquilinos não é suportada.
O padrão de gestão de dados de instâncias é mais adequado para os seguintes cenários:
- Os diferentes inquilinos estão distribuídos por uma vasta gama de regiões e precisam de uma solução localizada.
- Os requisitos regulamentares e de conformidade para alguns inquilinos exigem níveis mais elevados de segurança e protocolos de auditoria.
- O tamanho dos inquilinos varia significativamente, de modo que a partilha de recursos entre inquilinos de elevado volume e tráfego pode causar contenção e degradação mútua.
Bases de dados
No padrão de gestão de dados da base de dados, cada inquilino reside numa base de dados numa única instância do Spanner. Podem existir várias bases de dados numa única instância. Se uma instância for insuficiente para o número de inquilinos, crie várias instâncias. Este padrão implica que uma única instância do Spanner é partilhada entre vários inquilinos.
O Spanner tem um limite rígido de 100 bases de dados por instância. Este limite significa que, se o fornecedor de SaaS precisar de expandir a sua atividade para mais de 100 clientes, tem de criar e usar várias instâncias do Spanner.
Para a aplicação de RH, o fornecedor de SaaS cria e gere cada inquilino com uma base de dados separada numa instância do Spanner.
Conforme se pode ver no diagrama seguinte, o padrão de gestão de dados tem um inquilino por base de dados.
O padrão de gestão de dados da base de dados alcança o isolamento lógico ao nível da base de dados para os dados de diferentes inquilinos. No entanto, uma vez que se trata de uma única instância do Spanner, todas as bases de dados de inquilinos partilham a mesma topologia de replicação e configuração de computação e armazenamento subjacente, a menos que seja usada a funcionalidade de partição geográfica. Pode usar a funcionalidade de geodivisão do Spanner para criar partições de instâncias em localizações diferentes e usar partições de instâncias diferentes para bases de dados diferentes na mesma instância.
A tabela seguinte descreve como o padrão de gestão de dados da base de dados afeta diferentes critérios.
| Critérios | Base de dados: um inquilino por padrão de gestão de dados da base de dados |
|---|---|
| Isolamento de dados |
|
| Agilidade |
|
| Operações |
|
| Evolua |
|
| Desempenho |
|
| Requisitos regulamentares e de conformidade |
|
Em resumo, os principais pontos a reter são:
- Vantagem: nível moderado de isolamento de dados e isolamento de recursos; nível moderado de eficiência dos recursos; cada inquilino pode ter a sua própria cópia de segurança e CMEK.
- Desvantagem: número limitado de inquilinos por instância; inflexibilidade da localização se não usar a funcionalidade de geoparticionamento.
O padrão de gestão de dados da base de dados é mais adequado para os seguintes cenários:
- Vários clientes estão na mesma residência de dados ou sob a mesma autoridade reguladora.
- Os inquilinos requerem a separação de dados baseada no sistema e a capacidade de fazer uma cópia de segurança e restaurar os respetivos dados, mas não se importam de partilhar recursos de infraestrutura.
- Os inquilinos precisam da sua própria CMEK.
- O custo é uma consideração importante. Os recursos mínimos necessários por inquilino são inferiores ao custo de uma instância. É desejável que os inquilinos usem os recursos inativos de outros inquilinos.
Tabela
No padrão de gestão de dados de tabelas, é usada uma única base de dados, que implementa um esquema único, para vários inquilinos, e é usado um conjunto separado de tabelas para os dados de cada inquilino. Pode distinguir estas tabelas incluindo o tenant ID nos nomes das tabelas como prefixo, sufixo ou esquemas com nome.
Este padrão de gestão de dados que usa um conjunto separado de tabelas para cada inquilino oferece um nível de isolamento muito inferior em comparação com as opções anteriores (os padrões de gestão de instâncias e bases de dados). A integração envolve a criação de novas tabelas e a integridade referencial e os índices associados.
Existe um limite de 5000 tabelas por base de dados. Para alguns clientes, esse limite pode restringir a respetiva utilização da aplicação.
Além disso, a utilização de tabelas separadas para cada cliente pode resultar num grande atraso nas operações de atualização do esquema. Este atraso demora muito tempo a resolver.
Para a aplicação de RH, o fornecedor de SaaS pode criar um conjunto de tabelas para cada cliente com tenant ID como prefixo nos nomes das tabelas. Por exemplo,
customer1_employee, customer1_payroll e customer1_department.
Em alternativa, podem usar o ID do inquilino como um esquema denominado e dar à tabela os nomes customer1.employee, customer1.payroll e customer1.department.
Conforme se pode ver no diagrama seguinte, o padrão de gestão de dados de tabelas tem um conjunto de tabelas para cada inquilino.
A tabela seguinte descreve como o padrão de gestão de dados de tabelas afeta diferentes critérios.
| Critérios | Tabela: um conjunto de tabelas para cada padrão de gestão de dados de inquilinos |
|---|---|
| Isolamento de dados |
|
| Agilidade |
|
| Operações |
|
| Evolua |
|
| Desempenho |
|
| Requisitos regulamentares e de conformidade |
|
Em resumo, os principais pontos a reter são:
- Vantagem: nível moderado de escalabilidade e eficiência dos recursos.
- Desvantagem:
- Nível moderado de isolamento de dados e isolamento de recursos.
- Inflexibilidade da localização se não usar a nova funcionalidade de partição geográfica.
- Incapacidade de monitorizar inquilinos em separado. As únicas informações de consumo de recursos disponíveis ao nível da tabela são as estatísticas de tamanho da tabela.
- Os inquilinos não podem ter as suas próprias CMEK e cópias de segurança.
O padrão de gestão de dados de tabelas é mais adequado para os seguintes cenários:
- Aplicações multiinquilino que não exigem legalmente a separação de dados, mas querem separação lógica e controlo de segurança.
- O custo é uma consideração importante. O custo mínimo por inquilino é inferior ao custo por base de dados.
Linha
O padrão de gestão de dados final serve vários inquilinos com um conjunto comum de tabelas, com cada linha pertencente a um inquilino específico. Este padrão de gestão de dados representa um nível extremo de multi-tenancy em que tudo, desde a infraestrutura ao esquema e ao modelo de dados, é partilhado entre vários inquilinos. Numa tabela, as linhas são particionadas com base nas chaves primárias, com tenant ID como o primeiro elemento da chave. Do ponto de vista da escalabilidade, o Spanner suporta melhor este padrão porque pode dimensionar tabelas sem limitações.
Para a aplicação de RH, a chave principal da tabela de folha de pagamentos pode ser uma combinação de customerID e payrollID.
Conforme se pode ver no diagrama seguinte, o padrão de gestão de dados de linhas tem uma tabela para vários inquilinos.
Ao contrário de todos os outros padrões, o acesso aos dados no padrão de linhas não pode ser controlado separadamente para diferentes inquilinos. A utilização de menos tabelas significa que as operações de atualização do esquema são concluídas mais rapidamente quando cada inquilino tem as suas próprias tabelas da base de dados. Em grande medida, esta abordagem simplifica a integração, a desativação e as operações.
A tabela seguinte descreve como o padrão de gestão de dados de linhas afeta diferentes critérios.
| Critérios | Linha: um conjunto de linhas para cada padrão de gestão de dados de inquilino |
|---|---|
| Isolamento de dados |
|
| Agilidade |
|
| Operações |
|
| Evolua |
|
| Desempenho |
|
| Requisitos regulamentares e de conformidade |
|
Em resumo, os principais pontos a reter são:
- Vantagem: altamente escalável; tem uma sobrecarga operacional baixa; gestão de esquemas simplificada.
- Desvantagem: elevada contenção de recursos; falta de controlos de segurança e monitorização para cada inquilino.
Este padrão é mais adequado para os seguintes cenários:
- Aplicações internas que atendem a diferentes departamentos onde o isolamento de segurança dos dados rigoroso não é uma preocupação proeminente em comparação com a facilidade de manutenção.
- Partilha máxima de recursos para inquilinos que usam a aplicação de nível gratuito quando minimizam o aprovisionamento de recursos ao mesmo tempo.
Padrões de gestão de dados e gestão do ciclo de vida do inquilino
A tabela seguinte compara os vários padrões de gestão de dados em todos os critérios a um nível elevado.
| Instância | Bases de dados | Tabela | Linha | |
|---|---|---|---|---|
| Isolamento de dados | Concluído | Alto | Moderada | Baixo |
| Agilidade | Baixo | Moderada | Moderada | Mais alto |
| Facilidade de operações | Alto | Alto | Baixo | Baixo |
| Escala | Alto | Limitado (a menos que use instâncias adicionais quando atingir o limite) | Limitado (a menos que use bases de dados adicionais quando atingir o limite) | Mais alto |
| Desempenho1 – Isolamento de recursos | Alto | Baixo | Baixo | Baixo |
| Desempenho1: recursos mínimos por inquilino | Alto | Moderada alta | Moderada | Sem mínimo por inquilino |
| Desempenho1: eficiência dos recursos | Baixo | Alto | Alto | Alto |
| Desempenho1: seleção da localização para otimização da latência | Alto | Moderada | Moderada | Moderada |
| Regulamentos e conformidade | Mais alto | Alto | Moderada | Baixo |
1 O desempenho depende muito do design do esquema e das práticas recomendadas de consultas. Os valores aqui apresentados são apenas uma expectativa média.
Os melhores padrões de gestão de dados para uma aplicação multiinquilino específica são aqueles que satisfazem a maioria dos respetivos requisitos com base nos critérios. Se um critério específico não for obrigatório, pode ignorar a linha em que se encontra.
Padrões de gestão de dados combinados
Muitas vezes, um único padrão de gestão de dados é suficiente para cumprir os requisitos de uma aplicação multi-inquilino. Quando é esse o caso, a conceção pode assumir um único padrão de gestão de dados.
Algumas aplicações multi-inquilino requerem vários padrões de gestão de dados ao mesmo tempo. Por exemplo, uma aplicação multi-inquilino que suporta um nível gratuito, um nível normal e um nível empresarial.
Nível gratuito:
- Tem de ser rentável
- Tem de ter um limite superior de volume de dados
- Normalmente, suporta funcionalidades limitadas
- O padrão de gestão de dados de linhas é um bom candidato ao nível gratuito
- A gestão de inquilinos é simples
- Não é necessário criar recursos de inquilino específicos ou exclusivos
Nível normal:
- Adequado para clientes pagantes que não tenham requisitos de escalabilidade ou isolamento particularmente fortes.
- O padrão de gestão de dados da tabela ou o padrão de gestão de dados da base de dados é um bom candidato ao nível normal:
- As tabelas e os índices são exclusivos para o inquilino.
- A cópia de segurança é simples no padrão de gestão de dados da base de dados
- A cópia de segurança não é suportada para o padrão de gestão de dados de tabelas.
- A cópia de segurança do inquilino tem de ser implementada como um utilitário fora do Spanner.
Nível Enterprise:
- Normalmente, um nível de gama alta com autonomia total em todos os aspetos.
- O inquilino tem recursos dedicados que incluem escalabilidade dedicada e isolamento total.
- O padrão de gestão de dados de instâncias é adequado para o nível empresarial.
Uma prática recomendada é manter diferentes padrões de gestão de dados em diferentes bases de dados. Embora seja possível combinar diferentes padrões de gestão de dados numa base de dados do Spanner, fazê-lo dificulta a implementação da lógica de acesso e das operações do ciclo de vida da aplicação.
A secção Conceção da aplicação descreve algumas considerações de conceção de aplicações multi-inquilino que se aplicam quando usa um único padrão de gestão de dados ou vários padrões de gestão de dados.
Faça a gestão do ciclo de vida do inquilino
Os inquilinos têm um ciclo de vida. Por conseguinte, tem de implementar as operações de gestão correspondentes na sua aplicação multi-inquilino. Além das operações básicas de criação, atualização e eliminação de inquilinos, considere as seguintes operações adicionais relacionadas com dados:
Exporte dados do inquilino:
- Quando elimina um inquilino, é uma prática recomendada exportar primeiro os respetivos dados e, possivelmente, disponibilizar-lhe o conjunto de dados.
- Quando usar o padrão de gestão de dados de linhas ou tabelas, o sistema de aplicação multi-inquilino tem de implementar a exportação ou mapeá-la para a funcionalidade de base de dados (exportação da base de dados) e implementar uma lógica personalizada para retirar a parte dos dados que corresponde ao inquilino.
Faça uma cópia de segurança dos dados do inquilino:
- Quando usar o padrão de gestão de dados da instância ou da base de dados e fizer uma cópia de segurança dos dados para inquilinos individuais, use as funções de exportação ou de cópia de segurança da base de dados.
- Quando usar o padrão de gestão de dados de tabela ou linha e fazer uma cópia de segurança dos dados para inquilinos individuais, a aplicação multi-inquilino tem de implementar esta operação. A base de dados do Spanner não consegue determinar a que inquilino pertencem os dados.
Mova os dados do inquilino:
A mudança de um inquilino de um padrão de gestão de dados para outro (ou a mudança de um inquilino no mesmo padrão de gestão de dados entre instâncias ou bases de dados) requer a extração dos dados de um padrão de gestão de dados e a inserção desses dados no novo padrão de gestão de dados.
- Quando for possível ter tempo de inatividade da aplicação, faça uma exportação/importação.
- Quando a inatividade não é possível, faça uma migração da base de dados sem inatividade.
A mitigação de uma situação de vizinho ruidoso é outro motivo para mover inquilinos.
Design de aplicações
Ao criar uma aplicação multi-inquilino, implemente uma lógica empresarial consciente do inquilino. Isto significa que, sempre que a aplicação executa lógica empresarial, tem de estar sempre no contexto de um inquilino conhecido.
Do ponto de vista da base de dados, a conceção da aplicação significa que cada consulta tem de ser executada em relação ao padrão de gestão de dados no qual o inquilino reside. As secções seguintes realçam alguns dos conceitos centrais da conceção de aplicações multi-inquilino.
Configuração de consultas e associação de inquilinos dinâmicos
O mapeamento dinâmico dos dados do inquilino para os pedidos da aplicação do inquilino usa uma configuração de mapeamento:
- Para padrões de gestão de dados de bases de dados ou padrões de gestão de dados de instâncias, uma string de ligação é suficiente para aceder aos dados de um inquilino.
- Para padrões de gestão de dados de tabelas, têm de ser determinados os nomes das tabelas corretos.
- Para padrões de gestão de dados de linhas, use os predicados adequados para obter os dados de um inquilino específico.
Um inquilino pode residir num dos quatro padrões de gestão de dados. A implementação de mapeamento seguinte aborda uma configuração de ligação para o caso geral de uma aplicação multi-inquilino que usa todos os padrões de gestão de dados ao mesmo tempo. Quando um determinado inquilino reside num padrão, algumas aplicações multi-inquilino usam um padrão de gestão de dados para todos os inquilinos. Este caso é coberto implicitamente pelo mapeamento seguinte.
Se um inquilino executar a lógica empresarial (por exemplo, um funcionário iniciar sessão com o respetivo ID do inquilino), a lógica da aplicação tem de determinar o padrão de gestão de dados do inquilino, a localização dos dados para um determinado ID do inquilino e, opcionalmente, a convenção de nomenclatura de tabelas (para o padrão de tabelas).
Esta lógica de aplicação requer o mapeamento do padrão de inquilino para gestão de dados. No exemplo de código seguinte, connection string refere-se à base de dados onde os dados do inquilino residem. O exemplo identifica a instância do Spanner e a base de dados. Para a instância do padrão de gestão de dados e a base de dados, o seguinte código é suficiente para a aplicação se ligar e executar consultas:
tenant id -> (data management pattern,
database connection string)
É necessário um design adicional para os padrões de gestão de dados de tabelas e linhas.
Padrão de gestão de dados de tabelas
Para o padrão de gestão de dados de tabelas, existem vários inquilinos na mesma base de dados. Cada inquilino tem o seu próprio conjunto de tabelas. As tabelas distinguem-se pelo respetivo nome. A tabela que pertence a cada inquilino é determinística.
Uma abordagem consiste em colocar a tabela de cada inquilino num espaço de nomes com o nome do inquilino e qualificar totalmente o nome da tabela com namespace.name. Por exemplo, coloca uma tabela EMPLOYEE no espaço de nomes T356 para o inquilino com o ID 356, e a sua aplicação pode usar T356.EMPLOYEE para encaminhar os pedidos para a tabela.
Outra abordagem é antepor os nomes das tabelas com o ID do inquilino. Por exemplo, a tabela EMPLOYEE chama-se T356_EMPLOYEE para o inquilino com o ID 356.
A aplicação tem de antepor o prefixo tenant
ID a cada tabela antes de enviar a consulta para a base de dados devolvida pelo mapeamento.
Se quiser usar outro texto em vez do ID do inquilino, pode manter um mapeamento do ID do inquilino para o espaço de nomes do esquema com nome ou para o prefixo da tabela.
Para simplificar a lógica da aplicação, pode introduzir um nível de indireção. Por exemplo, pode usar uma biblioteca comum com a sua aplicação para anexar automaticamente o prefixo do espaço de nomes ou da tabela para a chamada do inquilino.
Padrão de gestão de dados de linhas
É necessário um design semelhante para o padrão de gestão de dados de linhas. Neste padrão, existe um único esquema. Os dados do inquilino são armazenados como linhas. Para aceder corretamente aos dados, acrescente um predicado a cada consulta para selecionar o inquilino adequado.
Uma abordagem para encontrar o inquilino adequado é ter uma coluna denominada TENANT
em cada tabela. Para um melhor isolamento dos dados, o valor desta coluna deve fazer parte da chave principal. O valor da coluna é tenant ID. Cada consulta tem de anexar um predicado AND TENANT = tenant ID a uma cláusula WHERE existente ou adicionar uma cláusula WHERE com o predicado AND TENANT = tenant
ID.
Para estabelecer ligação à base de dados e criar as consultas adequadas, o identificador do inquilino tem de estar disponível na lógica da aplicação. Pode ser transmitido como parâmetro ou armazenado como contexto da discussão.
Algumas operações do ciclo de vida requerem que modifique a configuração de mapeamento do padrão de gestão de dados para o inquilino. Por exemplo, quando move um inquilino entre padrões de gestão de dados, tem de atualizar o padrão de gestão de dados e a string de ligação à base de dados. Também pode ter de atualizar o prefixo da tabela.
Geração e atribuição de consultas
Um princípio fundamental subjacente das aplicações multi-inquilino é que vários inquilinos podem partilhar um único recurso na nuvem. Os padrões de gestão de dados anteriores pertencem a esta categoria, exceto no caso em que um único inquilino é atribuído a uma única instância do Spanner.
A partilha de recursos vai além da partilha de dados. A monitorização e o registo também são partilhados. Por exemplo, no padrão de gestão de dados de tabelas e no padrão de gestão de dados de linhas, todas as consultas de todos os inquilinos são registadas no mesmo registo de auditoria.
Se uma consulta for registada, o texto da consulta tem de ser examinado para determinar para que inquilino a consulta foi executada. No padrão de gestão de dados de linhas, tem de analisar o predicado. No padrão de gestão de dados de tabelas, tem de analisar um dos nomes das tabelas.
No padrão de gestão de dados da base de dados ou no padrão de gestão de dados da instância, o texto da consulta não tem informações de inquilino. Para obter informações do inquilino para estes padrões, tem de consultar a tabela de mapeamento de inquilino para padrão de gestão de dados.
Seria mais fácil analisar registos e consultas determinando o inquilino para uma consulta específica sem analisar o texto da consulta. Uma forma de identificar uniformemente um inquilino para uma consulta em todos os padrões de gestão de dados é adicionar um comentário ao texto da consulta que tenha o tenant ID e (opcionalmente) um label.
A consulta seguinte seleciona todos os dados dos funcionários para o inquilino identificado por
TENANT 356. Para evitar a análise da sintaxe SQL e a extração do ID do inquilino do predicado, o ID do inquilino é adicionado como um comentário. Um comentário pode ser extraído sem ter de analisar a sintaxe SQL.
SELECT * FROM EMPLOYEE
-- TENANT 356
WHERE TENANT = 'T356';
ou
SELECT * FROM T356_EMPLOYEE;
-- TENANT 356
Com esta conceção, todas as consultas executadas para um inquilino são atribuídas a esse inquilino, independentemente do padrão de gestão de dados. Se um inquilino for movido de um padrão de gestão de dados para outro, o texto da consulta pode mudar, mas a atribuição permanece igual no texto da consulta.
O exemplo de código anterior é apenas um método. Outro método consiste em inserir um objeto JSON como um comentário em vez de uma etiqueta e um valor:
SELECT * FROM T356_EMPLOYEE;
-- {"TENANT": 356}
Também pode usar etiquetas para atribuir consultas a inquilinos e ver as estatísticas nas tabelas spanner_sys incorporadas.
Operações do ciclo de vida de acesso do inquilino
Consoante a sua filosofia de design, uma aplicação multi-inquilino pode implementar diretamente as operações do ciclo de vida dos dados descritas anteriormente ou pode criar uma ferramenta de administração de inquilinos separada.
Independentemente da estratégia de implementação, as operações do ciclo de vida podem ter de ser executadas sem a lógica da aplicação em execução em simultâneo. Por exemplo, ao mover um inquilino de um padrão de gestão de dados para outro, a lógica da aplicação não pode ser executada porque os dados não estão numa única base de dados. Quando os dados não estão numa única base de dados, são necessárias duas operações adicionais do ponto de vista da aplicação:
- Parar um inquilino: desativa todo o acesso à lógica da aplicação, ao mesmo tempo que permite operações do ciclo de vida dos dados.
- Iniciar um inquilino: a lógica da aplicação pode aceder aos dados de um inquilino enquanto as operações do ciclo de vida que interfeririam com a lógica da aplicação estão desativadas.
Embora não seja usada com frequência, o encerramento de emergência de um inquilino pode ser outra operação importante do ciclo de vida. Use este encerramento quando suspeitar de uma violação e precisar de proibir todo o acesso aos dados de um inquilino, não só à lógica da aplicação, mas também às operações do ciclo de vida. Uma violação pode ter origem no interior ou no exterior da base de dados.
Também tem de estar disponível uma operação do ciclo de vida correspondente que remova o estado de emergência. Esta operação pode exigir que dois ou mais administradores iniciem sessão em simultâneo para implementar o controlo mútuo.
Isolamento de aplicações
Os vários padrões de gestão de dados suportam diferentes graus de isolamento dos dados do inquilino. Do nível mais isolado (instância) ao nível menos isolado (linha), são possíveis diferentes graus de isolamento.
No contexto de uma aplicação multi-inquilino, tem de ser tomada uma decisão de implementação semelhante: todos os inquilinos acedem aos respetivos dados (em padrões de gestão de dados possivelmente diferentes) através da mesma implementação da aplicação? Por exemplo, um único cluster do Kubernetes pode suportar todos os inquilinos e, quando um inquilino acede aos respetivos dados, o mesmo cluster executa a lógica empresarial.
Em alternativa, como no caso dos padrões de gestão de dados, os diferentes inquilinos podem ser direcionados para implementações de aplicações diferentes. Os grandes inquilinos podem ter acesso a uma implementação de aplicação exclusiva, enquanto os inquilinos mais pequenos ou os inquilinos no nível gratuito partilham uma implementação de aplicação.
Em vez de fazer a correspondência direta dos padrões de gestão de dados abordados neste documento com padrões de gestão de dados de aplicações equivalentes, pode usar o padrão de gestão de dados da base de dados para que todos os inquilinos partilhem uma única implementação de aplicações. É possível ter o padrão de gestão de dados da base de dados e todos estes inquilinos partilham uma única implementação de aplicação.
A multi-tenancy é um padrão importante de gestão de dados de design de aplicações, especialmente quando a eficiência dos recursos desempenha um papel vital. O Spanner suporta vários padrões de gestão de dados. Use-o para implementar aplicações multi-inquilino. Oferece tempo de inatividade zero para manutenção planeada ou falhas de regiões, com um SLA de disponibilidade de 99,999%. Também suporta aplicações modernas com vários inquilinos, oferecendo elevada disponibilidade e escalabilidade.