Matriz de decisão

Para decidir qual modelo de particionamento SaaS multilocatário você deve usar com o PostgreSQL, consulte a seguinte matriz de decisão. A matriz analisa essas quatro opções de particionamento:

• Silo: uma instância ou cluster de PostgreSQL separado para cada locatário.

• Bridge com bancos de dados separados — Um banco de dados separado para cada locatário em uma única instância ou cluster do PostgreSQL.

• Bridge com esquemas separados — Um esquema separado para cada locatário em um único banco de dados PostgreSQL, em uma única instância ou cluster do PostgreSQL.

• Pool — Tabelas compartilhadas para inquilinos em uma única instância e esquema.

	Silo	Bridge com bancos de dados separados	Ponte com esquemas separados	Piscina
Caso de uso	O isolamento de dados com controle total do uso de recursos é um requisito fundamental, caso contrário, você tem inquilinos muito grandes e muito sensíveis ao desempenho.	O isolamento de dados é um requisito fundamental, e é necessária uma referência cruzada limitada ou nenhuma referência cruzada dos dados dos inquilinos.	Número moderado de inquilinos com uma quantidade moderada de dados. Esse é o modelo preferido se você precisar cruzar os dados dos inquilinos.	Grande número de inquilinos com menos dados por inquilino.
Nova agilidade de integração de inquilinos	Muito lento. (É necessária uma nova instância ou cluster para cada inquilino.)	Moderadamente lento. (Requer a criação de um novo banco de dados para cada inquilino armazenar objetos do esquema.)	Moderadamente lento. (Requer a criação de um novo esquema para cada inquilino armazenar objetos.)	Opção mais rápida. (É necessária uma configuração mínima.)
Esforço e eficiência na configuração do pool de conexões do banco de dados	É necessário um esforço significativo. (Um pool de conexões por inquilino.) Menos eficiente. (Não há compartilhamento de conexão de banco de dados entre inquilinos.)	É necessário um esforço significativo. (Uma configuração de pool de conexões por locatário, a menos que você use o Amazon RDS Proxy.) Menos eficiente. (Sem compartilhamento de conexão de banco de dados entre locatários e número total de conexões. O uso em todos os locatários é limitado com base na classe da instância de instância de banco de dados.)	É necessário menos esforço. (Uma configuração de pool de conexões para todos os inquilinos.) Moderadamente eficiente. (Reutilização da conexão por meio doSET SCHEMA comandoSET ROLE or somente no modo de pool de sessões. SETos comandos também causam a fixação da sessão ao usar o Amazon RDS Proxy, mas os pools de conexões do cliente podem ser eliminados e conexões diretas podem ser feitas para cada solicitação de eficiência.)	É necessário o mínimo esforço. Mais eficiente. (Um pool de conexões para todos os inquilinos e reutilização eficiente da conexão em todos os inquilinos. Os limites de conexão do banco de dados.)
Manutenção do banco de dados (gerenciamento de vácuo) e uso de recursos	Gerenciamento mais simples.	Complexidade média. (Pode levar a um alto consumo de recursos, porque um aspirador precisa ser iniciado posteriormente para cada banco de dadosvacuum_naptime, o que leva ao alto uso da CPU do iniciador automático. Também pode haver uma sobrecarga adicional associada à limpeza das tabelas do catálogo do sistema PostgreSQL para cada banco de dados.)	Tabelas de catálogos do sistema PostgreSQL. (pg_catalogTamanho total em dezenas de GBs, dependendo do número de inquilinos e relações. Provavelmente exigirá modificações nos parâmetros relacionados à aspiração para controlar o inchaço da mesa.)	As tabelas podem ser grandes, dependendo do número de inquilinos e dos dados por inquilino. (Provavelmente exigirá modificações nos parâmetros relacionados à aspiração para controlar o inchaço da mesa.)
Esforço de gerenciamento de extensões	Esforço significativo (para cada banco de dados em instâncias separadas).	Esforço significativo (em cada nível de banco de dados).	Esforço mínimo (uma vez no banco de dados comum).	Esforço mínimo (uma vez no banco de dados comum).
Mude o esforço de implantação	Esforço significativo. (Connect a cada instância separada e implemente as alterações.)	Esforço significativo. (Connect a cada banco de dados e esquema e implemente as alterações.)	Esforço moderado. (Connect ao banco de dados comum e implemente alterações para cada esquema.)	Esforço mínimo. (Connect ao banco de dados comum e implemente as alterações.)
Implantação de mudanças — escopo do impacto	Mínimo. (Único inquilino afetado.)	Mínimo. (Único inquilino afetado.)	Mínimo. (Único inquilino afetado.)	Muito grande. (Todos os inquilinos afetados.)
Gerenciamento de desempenho e esforço de consultas	Desempenho de consultas gerenciável.	Desempenho de consultas gerenciável.	Desempenho de consultas gerenciável.	É provável que seja necessário um esforço significativo para manter o desempenho da consulta. (Com o tempo, as consultas podem ser executadas mais lentamente devido ao aumento do tamanho das tabelas. Você pode usar o particionamento de tabelas e a fragmentação do banco de dados para manter o desempenho.)
Impacto dos recursos entre inquilinos	Sem impacto. (Sem compartilhamento de recursos entre inquilinos.)	Impacto moderado. (Os inquilinos compartilham recursos comuns, como CPU e memória da instância.)	Impacto moderado. (Os inquilinos compartilham recursos comuns, como CPU e memória da instância.)	Impacto pesado. (Os inquilinos afetam uns aos outros em termos de recursos, conflitos de bloqueio e assim por diante.)
Ajuste em nível de inquilino (por exemplo, criação de índices adicionais por inquilino ou ajuste de parâmetros de banco de dados para um determinado inquilino)	Possível.	Um pouco possível. (Alterações no nível do esquema podem ser feitas para cada inquilino, mas os parâmetros do banco de dados são globais em todos os inquilinos.)	Um pouco possível. (Alterações no nível do esquema podem ser feitas para cada inquilino, mas os parâmetros do banco de dados são globais em todos os inquilinos.)	Não é possível. (As mesas são compartilhadas por todos os inquilinos.)
Reequilibre os esforços para inquilinos sensíveis ao desempenho	Mínimo. (Não é necessário reequilibrar. Dimensione os recursos do servidor e de I/O para lidar com esse cenário.)	Moderado. (Use a replicação lógica oupg_dump para exportar o banco de dados, mas o tempo de inatividade pode ser longo, dependendo do tamanho dos dados. Você pode usar o recurso de banco de dados transportável no Amazon RDS for PostgreSQL para copiar bancos de dados entre instâncias mais rapidamente.)	Moderado, mas provavelmente envolve um longo tempo de inatividade. (Use a replicação lógica oupg_dump para exportar o esquema, mas o tempo de inatividade pode ser longo, dependendo do tamanho dos dados.)	Significativo, porque todos os inquilinos compartilham as mesmas mesas. (A fragmentação do banco de dados exige a cópia de tudo para outra instância e uma etapa adicional para limpar os dados do locatário.) O mais provável é que exija uma alteração na lógica do aplicativo.
Tempo de inatividade do banco de dados	Tempo de inatividade padrão. (Depende do tamanho do catálogo do sistema PostgreSQL.)	É provável que haja um maior tempo de inatividade. (Dependendo do tamanho do catálogo do sistema, o tempo pode variar. (As tabelas do catálogo do sistema PostgreSQL também são duplicadas nos bancos de dados)	É provável que haja um maior tempo de inatividade. (Dependendo do tamanho do catálogo do sistema PostgreSQL, o tempo pode variar.)	Tempo de inatividade padrão. (Depende do tamanho do catálogo do sistema PostgreSQL.)
Sobrecarga de administração (por exemplo, para análise de registros de banco de dados ou monitoramento de tarefas de backup)	Esforço significativo	Esforço mínimo.	Esforço mínimo.	Esforço mínimo.
Disponibilidade em nível de inquilino	Mais alto. (Cada inquilino falha e se recupera de forma independente.)	Maior escopo de impacto. (Todos os inquilinos falham e se recuperam juntos em caso de problemas de hardware ou recursos.)	Maior escopo de impacto. (Todos os inquilinos falham e se recuperam juntos em caso de problemas de hardware ou recursos.)	Maior escopo de impacto. (Todos os inquilinos falham e se recuperam juntos em caso de problemas de hardware ou recursos.)
Esforço de backup e recuperação em nível de locatário	Menor esforço. (O backup de cada locatário pode ser feito e restaurado de forma independente.)	Esforço moderado. (Use exportação e importação lógicas para cada inquilino. Alguma codificação e automação são necessárias.)	Esforço moderado. (Use exportação e importação lógicas para cada inquilino. Alguma codificação e automação são necessárias.)	Esforço significativo. (Todos os inquilinos compartilham as mesmas mesas.)
Esforço de point-in-time recuperação em nível de inquilino	Esforço mínimo. (Use a recuperação pontual usando snapshots ou use o retrocesso no Amazon Aurora.)	Esforço moderado. (Use restauração de instantâneos, seguida de exportação/importação. No entanto, essa será uma operação lenta.)	Esforço moderado. (Use restauração de instantâneos, seguida de exportação/importação. No entanto, essa será uma operação lenta.)	Esforço e complexidade significativos.
Nome do esquema uniforme	Mesmo nome do esquema para cada locatário.	Mesmo nome do esquema para cada locatário.	Esquema diferente para cada locatário.	Esquema comum.
Personalização por inquilino (por exemplo, colunas de tabela adicionais para um inquilino específico)	Possível.	Possível.	Possível.	Complicado (porque todos os inquilinos compartilham as mesmas mesas).
Eficiência do gerenciamento de catálogos na camada de mapeamento relacional de objetos (ORM) (por exemplo, Ruby)	Eficiente (porque a conexão com o cliente é específica para um inquilino).	Eficiente (porque a conexão do cliente é específica para um banco de dados).	Moderadamente eficiente. (Dependendo do ORM usado, do modelo de segurança do usuário/função e dasearch_path configuração, o cliente às vezes armazena em cache os metadados de todos os locatários, levando a um alto uso da memória da conexão de banco de dados.)	Eficiente (porque todos os inquilinos compartilham as mesmas mesas).
Esforço consolidado de relatórios de inquilinos	Esforço significativo. (Você precisa usar wrappers de dados externos [FDWs] para consolidar dados em todos os locatários ou extrair, transformar e carregar [ETL] em outro banco de dados de relatórios.)	Esforço significativo. (Você precisa usar FDWs para consolidar dados em todos os inquilinos ou ETL em outro banco de dados de relatórios.)	Esforço moderado. (Você pode agregar dados em todos os esquemas usando uniões.)	Esforço mínimo. (Todos os dados do inquilino estão nas mesmas tabelas, portanto, os relatórios são simples.)
Instância somente leitura específica do inquilino para geração de relatórios (por exemplo, com base na assinatura)	Menor esforço. (Crie uma réplica de leitura.)	Esforço moderado. (Você pode usar a replicação lógica ou oAWS Database Migration Service [AWS DMS] para configurar.)	Esforço moderado. (Você pode usar a replicação lógica ouAWS DMS configurar.)	Complicado (porque todos os inquilinos compartilham as mesmas mesas).
Isolamento de dados	Melhor.	Melhor. (Você pode gerenciar permissões em nível de banco de dados usando funções do PostgreSQL.)	Melhor. (Você pode gerenciar permissões em nível de esquema usando funções do PostgreSQL.)	Pior. (Como todos os inquilinos compartilham as mesmas tabelas, você precisa implementar recursos como segurança em nível de linha [RLS] para isolamento de inquilinos.)
Chave de criptografia de armazenamento específica do locatário	Possível. (Cada cluster do PostgreSQL pode ter sua própria chaveAWS Key Management Service [AWS KMS] para criptografia de armazenamento.)	Não é possível. (Todos os inquilinos compartilham a mesma chave KMS para criptografia de armazenamento.)	Não é possível. (Todos os inquilinos compartilham a mesma chave KMS para criptografia de armazenamento.)	Não é possível. (Todos os inquilinos compartilham a mesma chave KMS para criptografia de armazenamento.)
UsandoAWS Identity and Access Management (IAM) para autenticação de banco de dados para cada inquilino	Possível.	Possível.	Possível (com usuários separados do PostgreSQL para cada esquema).	Não é possível (porque as mesas são compartilhadas por todos os inquilinos).
Custo da infraestrutura	Mais alto (porque nada é compartilhado).	Moderado.	Moderado.	Mais baixo.
Duplicação de dados e uso do armazenamento	Maior agregado entre todos os inquilinos. (As tabelas do catálogo do sistema PostgreSQL e os dados estáticos e comuns do aplicativo são duplicados em todos os locatários.)	Maior agregado entre todos os inquilinos. (As tabelas do catálogo do sistema PostgreSQL e os dados estáticos e comuns do aplicativo são duplicados em todos os locatários.)	Moderado. (Os dados estáticos e comuns do aplicativo podem estar em um esquema comum e acessados por outros locatários.)	Mínimo. (Sem duplicação de dados. Os dados estáticos e comuns do aplicativo podem estar no mesmo esquema.)
Monitoramento centrado no inquilino (descubra rapidamente qual inquilino está causando problemas)	Menor esforço. (Como cada inquilino é monitorado separadamente, é fácil verificar a atividade de um inquilino específico.)	Esforço moderado. (Como todos os inquilinos compartilham o mesmo recurso físico, você precisa aplicar uma filtragem adicional para verificar a atividade de um inquilino específico.)	Esforço moderado. (Como todos os inquilinos compartilham o mesmo recurso físico, você precisa aplicar uma filtragem adicional para verificar a atividade de um inquilino específico.)	Esforço significativo. (Como todos os inquilinos compartilham todos os recursos, incluindo tabelas, você precisa usar a captura de variáveis de vinculação para verificar a qual inquilino uma consulta SQL específica pertence.)
Gerenciamento centralizado e monitoramento de saúde/atividades	Esforço significativo (para configurar o monitoramento central e um centro de comando central).	Esforço moderado (porque todos os inquilinos compartilham a mesma instância).	Esforço moderado (porque todos os inquilinos compartilham a mesma instância).	Esforço mínimo (porque todos os inquilinos compartilham os mesmos recursos, incluindo o esquema).
Chances de envolver o identificador de objeto (OID) e o ID da transação (XID)	Mínimo.	Alto. (Como o OID, o XID é um único contador de cluster do PostgreSQL e pode haver problemas de limpeza eficaz em bancos de dados físicos).	Moderado. (Como o OID, o XID é um único contador em todo o cluster do PostgreSQL).	Alto. (Por exemplo, uma única tabela pode atingir o limite do TOAST OID de 4 bilhões, dependendo do número de out-of-line colunas.)