Prós e contras de usar muitos esquemas no PostgreSQL em vez de apenas um?

Para um aplicativo SAAS grande (suportado pelo PostgreSql 9.4), com mais de 300.000 contas (e em crescimento), quais são os prós e os contras de usar um esquema por conta para particionar os dados versus colocar todos os dados em um esquema e usar chaves estrangeiras para particioná-lo nas consultas?

Eu sei que no passado o pg_dump era dolorosamente lento ao trabalhar com muitos esquemas, mas não tenho certeza se esse é o caso hoje. Também estou ciente de que qualquer alteração na estrutura do banco de dados precisará ser feita em todos os esquemas. E sei que, do lado positivo, é fácil mover um esquema de um servidor físico para outro, além de restaurar um esquema do backup, sem mencionar que faz sentido particionar dados dessa maneira.

Então, quais são os prós e os contras que estou perdendo?

— Harel
fonte

Nem parece ser bom. Uma única tabela enorme ("crescimento vertical") é difícil de gerenciar e um grande número de esquemas ("crescimento horizontal") também é difícil de gerenciar.

— Daniel Vérité

Estou reconstruindo um sistema antigo que possui esse número de contas (e um número ainda maior de usuários). Ele está usando uma abordagem compartilhada (usando mySql) e funciona bem no que diz respeito ao desempenho. Minha preocupação é manter esse nível de desempenho, mas acrescentar manutenção.

— Harel

@ Harel Estou curioso, você tentou com esquemas de 400k ou mudou para outra arquitetura / tecnologia?

— sthzg

Desisti da ideia depois de analisar mais profundamente. A quantidade de esquemas que eu criaria derrotaria qualquer uso prático disso. Fui com o bom e antigo campo de identificação da conta em todos os registros. O que eu fiz também foi deixar cair os IDs numéricos de incremento automático em favor dos UUIDs, o que significa que posso levar uma conta inteira de um banco de dados para outro com bastante facilidade, sem ter que me preocupar em quebrar a integridade.

— Harel

Obviamente, você está lidando com as mesmas tabelas em cada esquema de usuário. Você já considerou herança para isso? Pode oferecer o melhor dos dois mundos para alguns casos de uso. Existem também algumas limitações . Você pode ter um esquema separado para cada usuário e ainda pesquisar todas as tabelas de usuários de uma só vez, de maneira muito conveniente.

Palavras-chave:

Fora isso, é necessário mencionar pelo menos a concessão / revogação de privilégios, o que é muito mais simples com esquemas separados.

— Erwin Brandstetter
fonte

Vou examinar a herança. No entanto, minha preocupação é com a escala aqui. Em todo lugar que leio, as pessoas estão falando sobre a estratégia de esquemas com vários inquilinos, mas se referindo a dezenas, centenas ou milhares de esquemas. Um lugar mencionou esquemas de 20K. A questão é - os esquemas de 400K são demais? Isso causará uma loucura no descritor de arquivos e matará o servidor? Estou empurrando?

— Harel

Além disso, pretendia manter os dados do inquilino (contas e usuários) no esquema público, mantendo os próprios esquemas como dados reais do usuário. Esses dados não são e nunca serão compartilhados entre esquemas.

— Harel

A herança não vai me ajudar aqui, eu não acho. A abordagem compartilhada usa um esquema único com chaves estrangeiras obrigatórias para o usuário ou inquilino, portanto, nada ganho com a herança, receio.

— Harel

Neste artigo, influitive.io/… acho que o modo multi-esquema não é uma boa maneira para grandes inquilinos. A coluna tenant_id (da maneira antiga) vem melhor.

— Xiaohui Zhang