As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Modelos de particionamento SaaS multilocatário para PostgreSQL
<a name="partitioning-models"></a>

O melhor método para realizar a multilocação depende dos requisitos do seu aplicativo SaaS. As seções a seguir demonstram modelos de particionamento para implementar com sucesso a multilocação no PostgreSQL. 

**nota**  
Os modelos discutidos nesta seção são aplicáveis tanto ao Amazon RDS for PostgreSQL quanto ao Aurora PostgreSQL compatível. As referências ao *PostgreSQL* nesta seção se aplicam a ambos os serviços.

Há três modelos de alto nível que você pode usar no PostgreSQL para particionamento SaaS: silo, bridge e pool. A imagem a seguir resume as vantagens e desvantagens entre os modelos de silo e piscina. O modelo de ponte é um híbrido dos modelos de silo e piscina.


****  

| **Modelo de particionamento** | **Vantagens** | **Desvantagens** | 
| --- | --- | --- | 
| Silo | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | 
| Grupo | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | 
| Ponte | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | 

As seções a seguir discutem cada modelo com mais detalhes.

**Topics**
+ [

# Modelo de silo do PostgreSQL
](silo.md)
+ [

# Modelo de pool do PostgreSQL
](pool.md)
+ [

# Modelo de ponte do PostgreSQL
](bridge.md)
+ [

# Matriz de decisão
](matrix.md)

# Modelo de silo do PostgreSQL
<a name="silo"></a>

O modelo de silo é implementado provisionando uma instância do PostgreSQL para cada locatário em um aplicativo. O modelo de silo se destaca no desempenho do inquilino e no isolamento de segurança, além de eliminar completamente o fenômeno de vizinhos *ruidosos*. O fenômeno do vizinho ruidoso ocorre quando o uso de um sistema por um inquilino afeta o desempenho de outro inquilino. O modelo de silo permite que você personalize o desempenho especificamente para cada inquilino e potencialmente limite as interrupções no silo de um locatário específico. No entanto, o que geralmente impulsiona a adoção de um modelo de silo são as restrições rígidas de segurança e regulamentação. Essas restrições podem ser motivadas pelos clientes de SaaS. Por exemplo, os clientes de SaaS podem exigir que seus dados sejam isolados devido a restrições internas, e os provedores de SaaS podem oferecer esse serviço por uma taxa adicional. 

 ![\[SaaS PostgreSQL silo model\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-silo.png) 

Embora o modelo de silo possa ser necessário em certos casos, ele tem muitas desvantagens. Muitas vezes, é difícil usar o modelo de silo de forma econômica, porque gerenciar o consumo de recursos em várias instâncias do PostgreSQL pode ser complicado. Além disso, a natureza distribuída das cargas de trabalho do banco de dados nesse modelo dificulta a manutenção de uma visão centralizada da atividade do inquilino. O gerenciamento de tantas cargas de trabalho operadas de forma independente aumenta a sobrecarga operacional e administrativa. O modelo de silo também torna a integração de inquilinos mais complicada e demorada, porque você precisa provisionar recursos específicos para inquilinos. Além disso, todo o sistema SaaS pode ser mais difícil de escalar, porque o número cada vez maior de instâncias PostgreSQL específicas para inquilinos exigirá mais tempo operacional para administrar. Uma última consideração é que um aplicativo ou uma camada de acesso a dados precisará manter um mapeamento dos locatários para suas instâncias PostgreSQL associadas, o que aumenta a complexidade da implementação desse modelo.

# Modelo de pool do PostgreSQL
<a name="pool"></a>

O modelo de pool é implementado provisionando uma única instância do PostgreSQL (Amazon RDS ou Aurora) e [usando a segurança em nível de linha (RLS) para manter o isolamento dos dados do inquilino](https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/). As políticas de RLS restringem quais linhas em uma tabela são retornadas por `SELECT` consultas ou quais linhas são afetadas pelos `INSERT` comandos`UPDATE`, e. `DELETE` O modelo de pool centraliza todos os dados do inquilino em um único esquema PostgreSQL, portanto, é significativamente mais econômico e requer menos sobrecarga operacional para manutenção. O monitoramento dessa solução também é significativamente mais simples devido à sua centralização. No entanto, monitorar os impactos específicos do inquilino no modelo do pool geralmente requer alguma instrumentação adicional na aplicação. Isso ocorre porque o PostgreSQL, por padrão, não sabe qual inquilino está consumindo recursos. A integração de inquilinos é simplificada porque nenhuma nova infraestrutura é necessária. Essa agilidade facilita a realização de fluxos de trabalho de integração de inquilinos rápidos e automatizados.

 ![\[SaaS PostgreSQL pool model\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-pool.png) 

Embora o modelo de pool seja geralmente mais econômico e mais simples de administrar, ele tem algumas desvantagens. O fenômeno do vizinho barulhento não pode ser completamente eliminado em um modelo de piscina. No entanto, isso pode ser mitigado garantindo que os recursos apropriados estejam disponíveis na instância do PostgreSQL e usando estratégias para reduzir a carga no PostgreSQL, como transferir consultas para ler réplicas ou para a Amazon. ElastiCache O monitoramento eficaz também desempenha um papel na resposta às preocupações de isolamento de desempenho do inquilino, porque a instrumentação do aplicativo pode registrar e monitorar atividades específicas do inquilino. Por fim, alguns clientes de SaaS podem não achar a separação lógica fornecida pelo RLS suficiente e podem solicitar medidas adicionais de isolamento.

# Modelo de ponte do PostgreSQL
<a name="bridge"></a>

O modelo de ponte do PostgreSQL é uma combinação das abordagens agrupadas e isoladas. Assim como no modelo agrupado, você provisiona uma única instância do PostgreSQL para cada locatário. Para manter o isolamento dos dados do inquilino, você usa construções lógicas do PostgreSQL. No diagrama a seguir, os bancos de dados PostgreSQL são usados para separar dados logicamente.

**nota**  
Um banco de dados PostgreSQL não se refere a uma instância de banco de dados separada compatível com Amazon RDS for PostgreSQL ou Aurora PostgreSQL. Em vez disso, ele se refere a uma construção lógica do sistema de gerenciamento de banco de dados PostgreSQL para separar dados.

 ![\[SaaS PostgreSQL bridge model with separate databases\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-dbs.png) 

Você também pode implementar o modelo de ponte usando um único banco de dados PostgreSQL, com esquemas específicos do locatário em cada banco de dados, conforme ilustrado no diagrama a seguir.

 ![\[SaaS PostgreSQL bridge model with separate schemas\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-schemas.png) 

O modelo de ponte sofre das mesmas preocupações ruidosas de isolamento de desempenho de vizinhos e inquilinos que o modelo de piscina. Também gera alguma sobrecarga operacional e de provisionamento adicional ao exigir que bancos de dados ou esquemas separados sejam provisionados por inquilino. Ela exige um monitoramento eficaz para responder rapidamente às preocupações de desempenho dos inquilinos. Também requer instrumentação do aplicativo para monitorar o uso específico do inquilino. No geral, o modelo de ponte pode ser visto como uma alternativa ao RLS, que aumenta um pouco o esforço de integração de inquilinos ao exigir novos bancos de dados ou esquemas PostgreSQL. Assim como no modelo de silo, um aplicativo ou uma camada de acesso a dados precisará manter um mapeamento dos inquilinos para seus bancos de dados ou esquemas PostgreSQL associados.

# Matriz de decisão
<a name="matrix"></a>

Para decidir qual modelo de particionamento SaaS multilocatário você deve usar com o PostgreSQL, consulte a matriz de decisão a seguir. A matriz analisa essas quatro opções de particionamento:
+ Silo — Uma instância ou cluster do PostgreSQL separado para cada locatário.
+ Ponte com bancos de dados separados — Um banco de dados separado para cada locatário em uma única instância ou cluster do PostgreSQL.
+ Ponte 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** | **Ponte com bancos de dados separados** | **Ponte com esquemas separados** | **Grupo** | 
| --- | --- | --- | --- | --- | 
| Caso de uso | O isolamento de dados com controle total do uso de recursos é um requisito fundamental, ou 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. | 
| Agilidade de integração de novos inquilinos | Muito lento. (Uma nova instância ou cluster é necessária 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 de configuração do pool de conexões de banco de dados | É necessário um esforço significativo. (Um pool de conexões por inquilino.) Menos eficiente. (Sem 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 inquilino, a menos que você use o [Amazon RDS Proxy.](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html))  Menos eficiente. (Sem compartilhamento de conexão de banco de dados entre inquilinos e número total de conexões. O uso em todos os locatários é limitado com base na classe da instância de banco de dados.) | É necessário menos esforço. (Uma configuração de pool de conexões para todos os locatários.)  Moderadamente eficiente. (Reutilização da conexão por meio do `SET SCHEMA` comando `SET ROLE` or somente no modo pool de sessões. `SET`os 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 locatários. Os limites de conexão do banco de dados são baseados na classe da instância de banco de dados.) | 
| Manutenção do banco de dados ([gerenciamento de vácuo](https://www.postgresql.org/docs/current/routine-vacuuming.html)) e uso de recursos | Gerenciamento mais simples. | Complexidade média. (Pode levar a um alto consumo de recursos, porque um operador de vácuo precisa ser iniciado para cada banco de dados posteriormentevacuum\$1naptime, o que leva a um alto uso da CPU do lançador de vácuo automático. Também pode haver sobrecarga adicional associada à limpeza das tabelas de catálogo do sistema PostgreSQL para cada banco de dados.) | Grandes tabelas de catálogo do sistema PostgreSQL. (pg\$1catalogTamanho 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. (Conecte-se a cada instância separada e implemente as alterações.) | Esforço significativo. (Conecte-se a cada banco de dados e esquema e implemente as alterações.) | Esforço moderado. (Conecte-se a um banco de dados comum e implemente as alterações para cada esquema.) | Esforço mínimo. (Conecte-se a um banco de dados comum e implemente as alterações.) | 
| Implantação de mudanças — escopo do impacto | Mínimo. (Um único inquilino afetado.) | Mínimo. (Um único inquilino afetado.) | Mínimo. (Um único inquilino afetado.) | Muito grande. (Todos os inquilinos afetados.) | 
| Gerenciamento e esforço de desempenho de consultas | Desempenho de consulta gerenciável. | Desempenho de consulta gerenciável. | Desempenho de consulta gerenciável. | Provavelmente é 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 particionamento de tabelas e fragmentação de banco de dados para manter o desempenho.) | 
| Impacto dos recursos entre inquilinos | Sem impacto. (Sem compartilhamento de recursos entre os 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 o esforço de inquilinos sensíveis ao desempenho | Mínimo. (Não é necessário reequilibrar. Dimensione o servidor e I/O os recursos para lidar com esse cenário.) | Moderado. (Use a replicação lógica ou exporte pg\$1dump 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 ou exporte pg\$1dump o esquema, mas o tempo de inatividade pode ser longo, dependendo do tamanho dos dados.) | Significativo, porque todos os inquilinos compartilham as mesmas mesas. (Fragmentar o banco de dados exige copiar tudo para outra instância e uma etapa adicional para limpar os dados do inquilino.)  Provavelmente requer uma mudança na lógica do aplicativo. | 
| Tempo de inatividade do banco de dados para atualizações de versões principais | Tempo de inatividade padrão. (Depende do tamanho do catálogo do sistema PostgreSQL.) | É provável que haja maior tempo de inatividade. (Dependendo do tamanho do catálogo do sistema, o tempo pode variar. As tabelas de catálogo do sistema PostgreSQL também são duplicadas em bancos de dados) | É provável que haja 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 administrativa (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 inquilino | Menor esforço. (Cada inquilino pode ser copiado e restaurado de forma independente.) | Esforço moderado. (Use exportação e importação lógicas para cada inquilino. Algumas codificações e automações são necessárias.) | Esforço moderado. (Use exportação e importação lógicas para cada inquilino. Algumas codificações e automações são necessárias.) | Esforço significativo. (Todos os inquilinos compartilham as mesmas mesas.) | 
| Esforço de recuperação em nível de inquilino point-in-time | Esforço mínimo. (Use a recuperação pontual usando snapshots ou use o retrocesso no Amazon Aurora.) | Esforço moderado. (Use a restauração de instantâneos, seguida de exportação/importação. No entanto, essa será uma operação lenta.) | Esforço moderado. (Use a 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 uniforme do esquema | Mesmo nome de esquema para cada inquilino. | Mesmo nome de esquema para cada inquilino. | Esquema diferente para cada inquilino. | 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 objeto-relacional (ORM) (por exemplo, Ruby) | Eficiente (porque a conexão do cliente é específica para um inquilino). | Eficiente (porque a conexão do cliente é específica de um banco de dados). | Moderadamente eficiente. (Dependendo do ORM usado, do modelo de user/role segurança e da search\$1path 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 tabelas). | 
| 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 para FDWs 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, então os relatórios são simples.) | 
| Instância somente de leitura específica do inquilino para 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 o AWS Database Migration Service [AWS DMS] para configurar.) | Esforço moderado. (Você pode usar a replicação lógica ou AWS 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 AWS Key Management Service própria chave AWS KMS[] para criptografia de armazenamento.) | Não é possível. (Todos os locatários compartilham a mesma chave KMS para criptografia de armazenamento.) | Não é possível. (Todos os locatários compartilham a mesma chave KMS para criptografia de armazenamento.) | Não é possível. (Todos os locatários compartilham a mesma chave KMS para criptografia de armazenamento.) | 
| Usando AWS 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 tabelas 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 de armazenamento | Maior agregado entre todos os inquilinos. (As tabelas de 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 de 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 ser 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 filtros adicionais 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 filtros adicionais 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 associação para verificar a qual inquilino uma consulta SQL específica pertence.) | 
| Gerenciamento e health/activity monitoramento centralizados | 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 contornar o identificador do objeto (OID) e o ID da transação (XID) | Mínimo.  | Alta. (Como o OID, o XID é um único contador de cluster do PostgreSQL e pode haver problemas ao limpar com eficiência os bancos de dados físicos). | Moderado. (Como o OID, o XID é um único contador de cluster do PostgreSQL). | Alta. (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.) |