Usar um banco de dados apenas para armazenamento de dados é o mesmo que chamar o Unix de interface para trabalhar com arquivos. Portanto, quero lembrá-lo das funções conhecidas e não muito conhecidas do banco de dados que gostaria de ver com mais frequência em aplicativos de combate baseados na Web.
tl; dr
A seguir, serão apresentados sobre autenticação, usuários, direitos de acesso, integridade de dados, FDW, registro e estatísticas. Nada de novo.
Anotações
- Quero dizer Ruby on Rails e Postgres, mas a maioria das referências é bem tolerada em outros idiomas e DBMS.
- Não direi nada de novo, tudo isso já foi descrito na documentação e nos artigos. Só quero lembrar mais uma vez sobre as ferramentas e onde elas podem ser aplicadas para tornar a vida um pouco melhor.
Autenticação de mesmo nível / identificação
Coisa absolutamente saudável, que quase ninguém usa. Ele mapeia um usuário Unix para um usuário de banco de dados. No primeiro caso, o usuário local é mapeado e, no segundo, o usuário remoto. O lucro é que você pode jogar fora o host, nome de usuário e senha da configuração (e o nome do banco de dados também pode ser jogado fora), mas tudo funcionará como antes. Além disso, será mais conveniente acessar o console para depuração direta (apenas psql do terminal em vez de todos esses -h -U -W -d e assim por diante).
Documentação do PG sobre par e ident .
Nuances: adequado se você não possui apenas root e superusuário no servidor; e, no caso de ident, você controla a rede, o hardware e tem certeza de que não há invasores e sabotadores.
Exemplos de uso
Segurança Você não pode remover a senha do banco de dados e conectar-se a ela no ambiente local ou em outro local. Não há senha e não há nada para arrastar.
Controle de acesso. Se houver várias funções de acesso à produção ou outro servidor e elas já estiverem divididas no nível unix, é conveniente vincular os usuários do banco de dados a elas. Nesse caso, a mesma base de código será conectada em diferentes usuários do banco de dados. Por exemplo, o suporte técnico e os desenvolvedores entram no mesmo console de trilhos, mas, para alguns, é somente leitura e, no segundo, é de pleno direito.
Direitos de acesso
No Unix, todos pensam neles e parecem muito distorcidos ao trabalhar a partir da raiz ou no 'chmod 777' . Mas no banco de dados tudo é de alguma forma diferente. Superusuário e pronto. Embora tudo não seja menos (e talvez até mais) legal.
Existe uma hierarquia de herança de funções (um pouco como um grupo no Unix), há acessos de diferentes níveis: a objetos específicos (como permissões de arquivo), a operadores específicos (como regras em sudoers ), até a linhas específicas . Em suma, está tudo lá. Use-o.
Áreas de aplicação
Na versão mínima, juntamente com o par / ident acima, você pode separar o usuário para migrações / implantação e o usuário para a operação diária do aplicativo. Isso, pelo menos, protegerá contra chamadas DDL em tempo de execução. Obviamente, existem muitos casos de modificação da estrutura do banco de dados "on hot". São implantações com tempo de inatividade zero e vários hotfixes e reconstruções de índices com concordância (e às vezes sem). Mas, em geral, um aplicativo DDL não deve.
Outra opção: se você possui "microsserviços", mas, por algum motivo, eles usam o mesmo banco de dados, é muito bom compartilhar o acesso aos objetos do banco de dados. De fato, as interfaces de interação devem ser o mais localizadas possível, e o acesso anárquico a todos os dados contribui para a erosão da lógica e da responsabilidade.
Restrição de integridade
No Rails 5, pelo menos de alguma forma, o trabalho começou com referência e integridade de dados. Porém, no caso geral, muitos desenvolvedores acreditam que a validação no modelo ou em seus arredores é suficiente para preservar o estado consistente dos dados. Infelizmente, isso não é de todo verdade.
As validações podem ser ignoradas, você pode ir diretamente ao banco de dados e executar o sql, pode limpar durante a migração. Em geral, muito pode ser feito. Portanto, tudo o que depende da lógica de negócios deve ser pregado pelo banco de dados. Essa é a única maneira de preservar a integridade dos dados e não obter "surpresas" na próxima implantação.
Wrapper de dados externos
Trata-se de conectar um banco de dados a outro banco de dados para acessar tabelas remotas como suas. O principal lucro é que o aplicativo Web não participa aqui, mas há muitas otimizações quando dois bancos de dados idênticos funcionam (em geral, o pushdown é para adaptadores diferentes, mas tudo é complicado lá, por isso é mais fácil supor que o pacote PG-PG funcione bem, e tudo mais - como vai).
Usando o FDW
Em vez de configurações com as coordenadas de vários bancos de dados em um aplicativo Web, é incomparavelmente mais fácil deixar uma conexão com o banco de dados e gerenciar tudo no nível do banco de dados. Lá, por si só, será resolvida a questão dos direitos de acesso e a escolha dos objetos aos quais o acesso é necessário.
Além disso, no futuro, você pode substituir a tabela externa por uma visualização materializada ou apenas uma tabela, mas não altera nada em um aplicativo Web.
E, no entanto, você pode se conectar ao tipo exótico de MS Access e os problemas com restrições ao uso de relações nos modelos desaparecem. Afinal, se você tiver mais de 2 conexões, não fará a junção de duas bases no nível de aplicativo da web, embora o ORM (em particular, o ActiveRecord) tente honestamente fazer isso ... e caia. E no nível do banco de dados, isso pode ser feito, em alguns casos, quase sem sobrecarga.
Registo
Quase todo mundo sabe sobre ele e usa tudo. Mas, por precaução, deixe-me lembrá-lo: não hesite em registrar solicitações longas. Fora da caixa, no PG, está desativado. Precisa log_min_duration_statement . Quanto ao seu significado, há muitos holívoros e, talvez, eles me gaguejam, mas, para começar, coloque alguns segundos. Como se você tem um aplicativo grande, é improvável que o leia e sabe o que fazer, mas se for pequeno, não terá tempo para lidar com freios pequenos e apenas coisas fatais o incomodam.
Lembre-se também de N + 1. O banco de dados não diz nada sobre isso. Use ferramentas de terceiros. Por exemplo, bala e bom senso.
Estatísticas
Deve-se lembrar que é e pode cheirar mal. No começo, está tudo bem. Porém, com o tempo, geralmente, os seguintes resultados: a taxa de alteração dos dados é aproximadamente a mesma e o tamanho da tabela é maior. Consequentemente, as tabelas de vácuo / análise começam a ocorrer com menos frequência e, em algum momento, o planejador começa a falhar. Na melhor das hipóteses, a solicitação cai no log acima, na pior das hipóteses - você simplesmente sofre e não entende o porquê. Em geral, consulte pg_stat_user_tables e correlacione as datas de vácuo / análise com a carga nas tabelas.
E às vezes você pode usar estatísticas para uma count aproximada. Isso é útil raramente, mas muito apropriadamente, porque PG não é Oracle e a count para toda a tabela não é feita em O (1), embora eu realmente queira.
O fim
Obrigado pela leitura. Se não for difícil, responda à pergunta abaixo. À luz de um artigo recente sobre o GQL, em vez do SQL, isso começou a me incomodar bastante.