Melhores Práticas <ul><li>Melhores práticas são diretrizes e não dogmas: </li></ul><ul><li>Uma pessoa  sem  bom senso não ...
Modelagem <ul><ul><li>Estrutura de dados inteligentes e código burro trabalham muito melhor que ao contrário. (Eric Raimon...
Modelagem <ul><ul><li>Abuse de PK, FK, NOT NULL, CHECK; </li></ul></ul><ul><ul><li>Use domínios para melhorar a semântica ...
Desempenho <ul><ul><li>Use funções para processar tarefas em lote; </li></ul></ul><ul><ul><li>Agregue várias consultas peq...
Padrões <ul><ul><li>Aplicações independentes de SGDB não existem... </li></ul></ul><ul><ul><li>Use funções específicas do ...
Desenvolvedores <ul><ul><li>Abuse da documentação oficial; </li></ul></ul><ul><ul><li>Abuse de transações com BEGIN, COMMI...
DBAs <ul><ul><li>Abuse da documentação oficial; </li></ul></ul><ul><ul><li>Use backup periódico do seu ambiente de produçã...
Escrevendo SQL <ul><ul><li>Abuse de editores de texto puro; </li></ul></ul><ul><ul><li>Use o psql com a opção i </li></ul>...
O PostgreSQL é case sensitive! <ul><li>Ruim : </li></ul><ul><li>CREATE TABLE FUNCIONARIO ( </li></ul><ul><li>IDFUNCIONARIO...
USE MINÚSCULAS para nome de objetos <ul><li>Bom : </li></ul><ul><li>CREATE TABLE funcionario ( </li></ul><ul><li>id_funcio...
Explícito > Implícito <ul><li>Ótimo : </li></ul><ul><li>CREATE SEQUENCE  hr. funcionario_seq; </li></ul><ul><li>CREATE TAB...
Explícito > Implícito <ul><li>Excelente : </li></ul><ul><li>SET DEFAULT_TABLESPACE = tbs_rh_table; </li></ul><ul><li>CREAT...
Inteligência da Aplicação no Banco de Dados <ul><li>Vantagens: </li></ul><ul><ul><li>Maior controle por parte do DBA; </li...
Inteligência da Aplicação no Banco de Dados <ul><li>Desvantagens: </li></ul><ul><ul><li>Menor controle por parte do desenv...
Inteligência da Aplicação no Banco de Dados <ul><li>Boas Práticas: </li></ul><ul><ul><li>Confie no PostgreSQL para reforça...
Ambientes <ul><ul><li>Produção: utilizado por todos usuários da aplicação; </li></ul></ul><ul><ul><li>Homologação: aceite ...
Autenticando Aplicações no PostgreSQL <ul><ul><li>Autenticação Interna : um usuário do PostgreSQL por usuário da Aplicação...
Autenticando Aplicações no PostgreSQL <ul><ul><li>Autenticação Interna: </li></ul></ul><ul><ul><li>PostgreSQL é capaz de d...
Autenticando Aplicações no PostgreSQL <ul><ul><li>Autenticação Externa: </li></ul></ul><ul><ul><li>Tem as mesmas caracterí...
Autenticando Aplicações no PostgreSQL <ul><ul><li>Autenticação pela Aplicação: </li></ul></ul><ul><ul><li>O PostgreSQL não...
Autenticando Aplicações no PostgreSQL <ul><ul><li>Boas Práticas : </li></ul></ul><ul><ul><li>Aplicações web não corporativ...
Autenticando Aplicações no PostgreSQL <ul><ul><li>pg_hba.conf : </li></ul></ul><ul><ul><li>Sempre identifique o nome do ba...
Autenticando Aplicações no PostgreSQL <ul><ul><li>pg_hba.conf : </li></ul></ul><ul><ul><li>Separe as regras por grupos de ...
Autenticando Aplicações no PostgreSQL <ul><ul><li>pg_hba.con f </li></ul></ul><ul><ul><li>Utilize 'md5' para e o nome dos ...
Esquema, Tablespace, Banco de Dados e Cluster <ul><ul><li>Esquema : estrutura lógica onde os objetos são criados. Todo obj...
Um Esquema Por Aplicação <ul><li>PostgreSQL não acessa nativamente outros bancos de dados; </li></ul><ul><li>Compartilhe d...
Dois tablespaces por aplicação <ul><li>Utilizar no  mínimo  um tablespace para índices e um para tabelas; </li></ul><ul><l...
Na Prática: <ul><li>No bash do Linux: </li></ul><ul><li>#mkdir /postgresql </li></ul><ul><li>#chown postgres /postgresql <...
Na Prática: <ul><li>No psql do PostgreSQL: </li></ul><ul><li>pgcon=#REVOKE ALL ON TABLESPACE pg_default,pg_global FROM pub...
Quando utilizar novos TABLESPACES? <ul><ul><li>Só faz sentido utilizar muitos tablespaces se você tem ou pretende ter vári...
Quando utilizar mais de um banco de dados no mesmo cluster? <ul><ul><li>Você quer aproveitar os processos do cluster exist...
Quando utilizar mais de um cluster no mesmo Sistema Operacional? <ul><ul><li>Você precisa utilizar um LC_COLLATE diferente...
Quando virtualizar o SO? <ul><ul><li>Sempre procure utilizar discos distintos para cada VM! </li></ul></ul><ul><ul><li>Voc...
Equilíbrio
OBRIGADO <ul><ul><li>Dúvidas, sugestões, correções, indignações e cervejas são bem vindas! </li></ul></ul><ul><ul><li>Fábi...
Upcoming SlideShare
Loading in …5
×

Fazendo Um Elefante Passar Debaixo da Porta - PGCon-BR

1,692 views

Published on

Palestra sobre melhores práticas em PostgreSQL realizada no PGCon Brasil 2007 em dezembro de 2007

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,692
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
74
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Fazendo Um Elefante Passar Debaixo da Porta - PGCon-BR

  1. 2. Melhores Práticas <ul><li>Melhores práticas são diretrizes e não dogmas: </li></ul><ul><li>Uma pessoa sem bom senso não se preocupa com melhores práticas; </li></ul><ul><li>Uma pessoa com bom senso e pouca experiência procura aprender e utilizar as melhores práticas; </li></ul><ul><li>Uma pessoa com bom senso e muita experiência sabe quando não utilizar as melhores práticas; </li></ul>
  2. 3. Modelagem <ul><ul><li>Estrutura de dados inteligentes e código burro trabalham muito melhor que ao contrário. (Eric Raimond) </li></ul></ul><ul><ul><li>Problemas de performance quando causados por falhas na modelagem podem demorar anos para aparecer. Quando surgem são quase insolúveis. </li></ul></ul><ul><ul><li>A parte mais importante no sucesso de uma aplicação com comunicação tipo Matriz/Filial está na modelagem e não na replicação </li></ul></ul>
  3. 4. Modelagem <ul><ul><li>Abuse de PK, FK, NOT NULL, CHECK; </li></ul></ul><ul><ul><li>Use domínios para melhorar a semântica dos dados; </li></ul></ul><ul><ul><li>Use seqüências para gerar números únicos; </li></ul></ul><ul><ul><li>Use visões para tornar o modelo lógico mais simples que o modelo físico; </li></ul></ul><ul><ul><li>Evite desnormalizar o modelo de dados; </li></ul></ul><ul><ul><li>Nunca d eixe de documentar DDL, DER e Dicionário de Dados; </li></ul></ul><ul><ul><li>Nunca crie campos e tabelas do tipo “FLEX”; </li></ul></ul><ul><ul><li>Cuidado com FRAMEWORKs e GERADORES DE CÓDIGO; </li></ul></ul>
  4. 5. Desempenho <ul><ul><li>Use funções para processar tarefas em lote; </li></ul></ul><ul><ul><li>Agregue várias consultas pequenas em uma única consulta maior; </li></ul></ul><ul><ul><li>Use o PREPARE ... EXECUTE quando não for possível agregar consultas menores; </li></ul></ul><ul><ul><li>Use poucas transações grandes no lugar de muitas transações pequenas; </li></ul></ul><ul><ul><li>Use índices em campos muito utilizados em cláusulas WHERE; </li></ul></ul><ul><ul><li>Evite utilizar muitos índices em ambiente transacional pesado; </li></ul></ul><ul><ul><li>Evite operações pesadas de DELETE e UPDATE; </li></ul></ul><ul><ul><li>Evite o uso indiscriminado de gatilhos; </li></ul></ul><ul><ul><li>Evite usar funções quando SQL puro resolve; </li></ul></ul>
  5. 6. Padrões <ul><ul><li>Aplicações independentes de SGDB não existem... </li></ul></ul><ul><ul><li>Use funções específicas do PostgreSQL quando: </li></ul></ul><ul><ul><ul><ul><li>houver grande ganho de performance ou </li></ul></ul></ul></ul><ul><ul><ul><ul><li>esta função for chave para a sua aplicação; </li></ul></ul></ul></ul><ul><ul><li>... mas a necessidade de fornecer soluções para mais de um SGDB existe! </li></ul></ul><ul><ul><li>Use ao máximo o padrão ANSI/SQL; </li></ul></ul><ul><ul><li>Evite o uso de funções que não sejam em PL/pgSQL; </li></ul></ul><ul><ul><li>Evite ao máximo o uso de funções exóticas que não tenha implementação similar em outro SGDB de mercado; </li></ul></ul>
  6. 7. Desenvolvedores <ul><ul><li>Abuse da documentação oficial; </li></ul></ul><ul><ul><li>Abuse de transações com BEGIN, COMMIT e ROLLBACK; </li></ul></ul><ul><ul><li>Use proteção efetiva contra SQL Injection; </li></ul></ul><ul><ul><li>Use desconexão automática por ociosidade; </li></ul></ul><ul><ul><li>Use de tratamento de erros com tratamento especial para erros de violação de constraints; </li></ul></ul><ul><ul><li>Use logs de erro armazenados em servidores de aplicação; </li></ul></ul><ul><ul><li>Nunca exiba mensagens de erro do banco na tela do usuário; </li></ul></ul><ul><ul><li>Nunca confie em conversões implícitas de tipo de dados; </li></ul></ul>
  7. 8. DBAs <ul><ul><li>Abuse da documentação oficial; </li></ul></ul><ul><ul><li>Use backup periódico do seu ambiente de produção e teste; </li></ul></ul><ul><ul><li>Nunca deixe de testar, rotinas de backup e restauração; </li></ul></ul><ul><ul><li>Nunca utilize TRUST ou PASSWORD como método de autenticação no pg_hba.conf; </li></ul></ul><ul><ul><li>Nunca deixe de acompanhar os logs de erro; </li></ul></ul><ul><ul><li>Nunca utilize codificação de caracteres SQL_ASCII; </li></ul></ul><ul><ul><li>Nunca deixe de dormir!!! </li></ul></ul>
  8. 9. Escrevendo SQL <ul><ul><li>Abuse de editores de texto puro; </li></ul></ul><ul><ul><li>Use o psql com a opção i </li></ul></ul><ul><ul><li>Use palavras reservadas em letra maiúscula e nome de objetos em letra minúscula; </li></ul></ul><ul><ul><li>Use o nome do esquema em operações DML e nomes explícitos para índices, restrições e seqüências em DDL ; </li></ul></ul><ul><ul><li>Evite realizar operações pesadas em ambiente gráfico; </li></ul></ul><ul><ul><li>Evite criar objetos em interfaces gráficas; </li></ul></ul><ul><ul><li>Antes de dizer que um SQL não funciona, teste sempre no psql; </li></ul></ul>
  9. 10. O PostgreSQL é case sensitive! <ul><li>Ruim : </li></ul><ul><li>CREATE TABLE FUNCIONARIO ( </li></ul><ul><li>IDFUNCIONARIO SERIAL PRIMARY KEY, </li></ul><ul><li>NOME VARCHAR(50) NOT NULL, </li></ul><ul><li>DEPTO INTEGER REFERENCES DEPTO(IDDEPTO)); </li></ul><ul><li>Péssimo : </li></ul><ul><li>Create Table Funcionario ( </li></ul><ul><li>IdFuncionario Serial Primary Key, </li></ul><ul><li>Nome Varchar(50) Not Null, </li></ul><ul><li>Depto Integer References Depto(IdDepto)); </li></ul>
  10. 11. USE MINÚSCULAS para nome de objetos <ul><li>Bom : </li></ul><ul><li>CREATE TABLE funcionario ( </li></ul><ul><li>id_funcionario SERIAL PRIMARY KEY, </li></ul><ul><li>nome VARCHAR(50) NOT NULL, </li></ul><ul><li>id_depto INTEGER REFERENCES depto(id_depto) </li></ul><ul><li>); </li></ul>
  11. 12. Explícito > Implícito <ul><li>Ótimo : </li></ul><ul><li>CREATE SEQUENCE hr. funcionario_seq; </li></ul><ul><li>CREATE TABLE hr. funcionario ( </li></ul><ul><li>id_funcionario INTEGER DEFAULT NEXTVAL('hr.funcionario_seq'), </li></ul><ul><li>nome VARCHAR(50) NOT NULL, </li></ul><ul><li>depto INTEGER </li></ul><ul><li>CONSTRAINTS </li></ul><ul><li>funcionario_pk PRIMARY KEY (id_funcionario) USING INDEX </li></ul><ul><li>TABLESPACE tbs_rh_index, </li></ul><ul><li>funcionario_depto_fk FOREIGN KEY (id_depto) REFERENCES </li></ul><ul><li>rh .depto(id_depto) </li></ul><ul><li>) TABLESPACE tbs_rh_table; </li></ul>
  12. 13. Explícito > Implícito <ul><li>Excelente : </li></ul><ul><li>SET DEFAULT_TABLESPACE = tbs_rh_table; </li></ul><ul><li>CREATE SEQUENCE rh. funcionario_seq; </li></ul><ul><li>CREATE TABLE rh. funcionario ( </li></ul><ul><li>id_funcionario INTEGER DEFAULT NEXTVAL(' rh .funcionario_seq'), </li></ul><ul><li>nome VARCHAR(50) NOT NULL, </li></ul><ul><li>depto INTEGER </li></ul><ul><li>); </li></ul><ul><li>SET DEFAULT_TABLESPACE = tbs_rh_index; </li></ul><ul><li>ALTER TABLE rh.funcionario ADD CONSTRAINT funcionario_pk PRIMARY KEY (id_funcionario) USING INDEX funcionario_pk_ix; </li></ul><ul><li>ALTER TABLE rh.funcionario ADD CONSTRAINT funcionario_depto_fk FOREIGN KEY (id_depto) REFERENCES rh .depto(id_depto); </li></ul>
  13. 14. Inteligência da Aplicação no Banco de Dados <ul><li>Vantagens: </li></ul><ul><ul><li>Maior controle por parte do DBA; </li></ul></ul><ul><ul><li>Maior velocidade em operações que envolvem um grande volume de dados e um número limitado de cálculos; </li></ul></ul><ul><ul><li>Acesso padronizado para diversas aplicações; </li></ul></ul><ul><ul><li>Facilidade de manutenção; </li></ul></ul><ul><ul><li>Baixa curva de aprendizado; </li></ul></ul>
  14. 15. Inteligência da Aplicação no Banco de Dados <ul><li>Desvantagens: </li></ul><ul><ul><li>Menor controle por parte do desenvolvedor; </li></ul></ul><ul><ul><li>PL = Procedural Language, ou seja não é orientado a objeto; </li></ul></ul><ul><ul><li>Dificuldade em migrar aplicação para outros SGDBs; </li></ul></ul><ul><ul><li>Não existe COMMIT ou ROLLBACK dentro de uma função; </li></ul></ul><ul><ul><li>Código não pode ser ofuscado; </li></ul></ul><ul><ul><li>Alguns servidores de aplicação escalam processamento melhor que o PostgreSQL; </li></ul></ul><ul><ul><li>Concentração de carga de processamento no SGDB; </li></ul></ul>
  15. 16. Inteligência da Aplicação no Banco de Dados <ul><li>Boas Práticas: </li></ul><ul><ul><li>Confie no PostgreSQL para reforçar restrições! </li></ul></ul><ul><ul><li>Utilize funções para cálculos em lote; </li></ul></ul><ul><ul><li>Utilize gatilhos para auditar tabelas chave; </li></ul></ul><ul><ul><li>Utilize funções e visões para aumentar a segurança no acesso a informações sensíveis; </li></ul></ul><ul><ul><li>Utilize gatilhos, funções e visões para integrar dados de diferentes aplicações; </li></ul></ul>
  16. 17. Ambientes <ul><ul><li>Produção: utilizado por todos usuários da aplicação; </li></ul></ul><ul><ul><li>Homologação: aceite de novas versões pelo usuário, testes de performance; </li></ul></ul><ul><ul><li>Teste: desenvolvimento de aplicações; </li></ul></ul><ul><ul><li>Laboratório: teste de novas versões, patches e funcionalidades do SGDB. </li></ul></ul>
  17. 18. Autenticando Aplicações no PostgreSQL <ul><ul><li>Autenticação Interna : um usuário do PostgreSQL por usuário da Aplicação; </li></ul></ul><ul><ul><li>Autenticação Externa : um usuário do PostgreSQL por usuário da Aplicação com autenticação externa; </li></ul></ul><ul><ul><li>Autenticação via Aplicação : um usuário do PostgreSQL para todos usuários da aplicação; </li></ul></ul>
  18. 19. Autenticando Aplicações no PostgreSQL <ul><ul><li>Autenticação Interna: </li></ul></ul><ul><ul><li>PostgreSQL é capaz de distinguir quais usuários estão conectados; </li></ul></ul><ul><ul><li>Auditoria consistente; </li></ul></ul><ul><ul><li>Uso de ROLEs para agrupar privilégios em objetos; </li></ul></ul><ul><ul><li>DBA precisa criar usuários no banco de dados manualmente; </li></ul></ul><ul><ul><li>Aplicação deve trocar senha do usuário na primeira vez em que ele se conectar; </li></ul></ul><ul><ul><li>Se a aplicação for Cliente/Servidor, PostgreSQL não consegue impedir o usuário de se conectar por fora da aplicação; </li></ul></ul><ul><ul><li>Não é possível fazer pool de conexões. </li></ul></ul>
  19. 20. Autenticando Aplicações no PostgreSQL <ul><ul><li>Autenticação Externa: </li></ul></ul><ul><ul><li>Tem as mesmas características da Autenticação Interna com as seguintes diferenças: </li></ul></ul><ul><ul><ul><ul><li>Administração de senhas fica a cargo do Administrador de Sistemas; </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Se integra com os demais usuários da rede; </li></ul></ul></ul></ul><ul><ul><ul><ul><li>É mais complexo para ser configurado; </li></ul></ul></ul></ul>por Fábio Telles 8 de Dezembro de 2007
  20. 21. Autenticando Aplicações no PostgreSQL <ul><ul><li>Autenticação pela Aplicação: </li></ul></ul><ul><ul><li>O PostgreSQL não é capaz de distinguir qual usuário está conectado; </li></ul></ul><ul><ul><li>Auditoria deve ser implementada pela aplicação; </li></ul></ul><ul><ul><li>Cadastro de usuários, senhas e permissões é de inteira responsabilidade da aplicação; </li></ul></ul><ul><ul><li>Senha de acesso ao PostgreSQL deve ficar em posse da aplicação; </li></ul></ul><ul><ul><li>A senha da aplicação deve ser trocada com freqüência; </li></ul></ul><ul><ul><li>O ROLE da aplicação deve ter os menores privilégios possíveis; </li></ul></ul><ul><ul><li>O ROLE da aplicação nunca pode ser mesmo que o ROLE do desenvolvedor ou o dono dos objetos da aplicação; </li></ul></ul>por Fábio Telles 8 de Dezembro de 2007
  21. 22. Autenticando Aplicações no PostgreSQL <ul><ul><li>Boas Práticas : </li></ul></ul><ul><ul><li>Aplicações web não corporativas com muitos usuários devem ser utilizar autenticação pela aplicação; </li></ul></ul><ul><ul><li>Aplicações que precisam de pool de conexões devem utilizar autenticação pela aplicação; </li></ul></ul><ul><ul><li>Aplicações corporativas com 3 ou mais camadas devem preferir devem preferir autenticação externa; </li></ul></ul><ul><ul><li>Mude o pg_hba.conf conforme o ambiente (produção, homologação, teste e laboratório) </li></ul></ul>
  22. 23. Autenticando Aplicações no PostgreSQL <ul><ul><li>pg_hba.conf : </li></ul></ul><ul><ul><li>Sempre identifique o nome do banco de dados; </li></ul></ul><ul><ul><li>Utilize SSL se você se preocupar com o tráfego de informações pela rede sem encriptação; </li></ul></ul><ul><ul><li>Limite a faixa de Ips ao máximo: </li></ul></ul><ul><ul><ul><ul><li>No caso aplicações em 3 ou mais camadas, limite aos IPs dos servidores de aplicação; </li></ul></ul></ul></ul><ul><ul><ul><ul><li>No caso de aplicações Cliente/Servidor, limite a rede local que eles utilizam; </li></ul></ul></ul></ul>
  23. 24. Autenticando Aplicações no PostgreSQL <ul><ul><li>pg_hba.conf : </li></ul></ul><ul><ul><li>Separe as regras por grupos de usuários: </li></ul></ul><ul><ul><ul><ul><li>DBAs; </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Desenvolvedores; </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Aplicações (autenticação pela aplicação) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Aplicações (autenticação interna) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Aplicações (autenticação externa) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Usuários especiais; </li></ul></ul></ul></ul><ul><ul><li>Utilize 'ident' apenas para os usuários DBAs, localmente e MD5 para conexões remotas, limitadas aos Ips/Redes locais dos DBAs; </li></ul></ul>
  24. 25. Autenticando Aplicações no PostgreSQL <ul><ul><li>pg_hba.con f </li></ul></ul><ul><ul><li>Utilize 'md5' para e o nome dos ROLEs da aplicação para autenticação pelo PostgreSQL ou pela aplicação; </li></ul></ul><ul><ul><li>Utilize 'ldap', 'gss' ou 'sspi' para autenticação externa; </li></ul></ul><ul><ul><li>Desenvolvedores devem utilizar 'reject' no ambiente de produção; </li></ul></ul><ul><ul><li>Usuários de aplicação autenticados pelo PostgreSQL ou externamente devem ter 'reject' no ambiente de teste e homologação; </li></ul></ul><ul><ul><li>Somente usuários especiais devem ter acesso ao ambiente de teste e homologação; </li></ul></ul>
  25. 26. Esquema, Tablespace, Banco de Dados e Cluster <ul><ul><li>Esquema : estrutura lógica onde os objetos são criados. Todo objeto é criado em um esquema; </li></ul></ul><ul><ul><li>Tablespace : local físico de armazenamento de tabelas e índices; </li></ul></ul><ul><ul><li>Banco de Dados : conjunto de esquemas e seus objetos. Pode compartilhar (padrão) ou não os ROLES de outros bancos de dados do cluster; </li></ul></ul><ul><ul><li>Cluster (initdb): conjunto de arquivos que compõe uma única instância do PostgreSQL. Esta utiliza um único conjunto de processos, shared buffers e porta de rede, mas pode conter vários bancos de dados; </li></ul></ul>
  26. 27. Um Esquema Por Aplicação <ul><li>PostgreSQL não acessa nativamente outros bancos de dados; </li></ul><ul><li>Compartilhe dados entre as aplicações; </li></ul><ul><li>Crie um esquema para cada aplicação; </li></ul><ul><li>Cada esquema de aplicação deve possuir seu próprio dono; </li></ul><ul><li>Utilize um esquema separado para auditoria de vários sistemas; </li></ul><ul><li>Utiliza um esquema separado para monitoramento do DBA; </li></ul><ul><li>Utilize o esquema public apenas para compartilhar dados entre diversas aplicações; </li></ul><ul><li>Não utilize os esquemas information_schema , pg_catalog , pg_toast para criar, alterar ou excluir nenhum objeto; </li></ul>
  27. 28. Dois tablespaces por aplicação <ul><li>Utilizar no mínimo um tablespace para índices e um para tabelas; </li></ul><ul><li>Mais fácil identificar o espaço físico ocupado pela aplicação; </li></ul><ul><li>Mais fácil identificar arquivos de backup físico; </li></ul><ul><li>Mais fácil identificar uso e volume de índices ou tabelas; </li></ul><ul><li>Mais fácil fazer ajuste de I/O e desempenho; </li></ul><ul><li>Uma camada a mais de segurança na criação de objetos; </li></ul>
  28. 29. Na Prática: <ul><li>No bash do Linux: </li></ul><ul><li>#mkdir /postgresql </li></ul><ul><li>#chown postgres /postgresql </li></ul><ul><li>#su postgres </li></ul><ul><li>$cd /postgresql </li></ul><ul><li>$mkdir /postgresql/tbs_hr_index </li></ul><ul><li>$mkdir /postgresql/tbs_hr_table </li></ul><ul><li>$psql pgcon </li></ul>
  29. 30. Na Prática: <ul><li>No psql do PostgreSQL: </li></ul><ul><li>pgcon=#REVOKE ALL ON TABLESPACE pg_default,pg_global FROM public; </li></ul><ul><li>pgcon=#REVOKE ALL ON SCHEMA public FROM public; </li></ul><ul><li>pgcon=#CREATE ROLE hr NOLOGIN; </li></ul><ul><li>pgcon=#CREATE TABLESPACE hr_index OWNER hr LOCATION '/postgresql/tbs_hr_index'; </li></ul><ul><li>pgcon=#CREATE TABLESPACE hr_table OWNER hr LOCATION '/postgresql/tbs_hr_table'; </li></ul><ul><li>CREATE SCHEMA AUTHORIZATION hr; </li></ul>
  30. 31. Quando utilizar novos TABLESPACES? <ul><ul><li>Só faz sentido utilizar muitos tablespaces se você tem ou pretende ter vários discos! </li></ul></ul><ul><ul><li>Tablespace temporário em ambiente com muitas consultas pesadas (novo no 8.3!); </li></ul></ul><ul><ul><li>Separar dados históricos e partições de tabelas pouco utilizadas em discos mais baratos; </li></ul></ul><ul><ul><li>Tabelas e índices onde o desempenho é crítico; </li></ul></ul><ul><ul><li>Tabelas onde a disponibilidade é crítica; </li></ul></ul>
  31. 32. Quando utilizar mais de um banco de dados no mesmo cluster? <ul><ul><li>Você quer aproveitar os processos do cluster existente mas precisa comparar uma nova versão dos mesmos objetos; </li></ul></ul><ul><ul><li>Você tem aplicações que precisam utilizar diferentes codificações de caracteres; </li></ul></ul><ul><ul><li>NUNCA coloque um ambiente de teste e produção no mesmo cluster! </li></ul></ul>
  32. 33. Quando utilizar mais de um cluster no mesmo Sistema Operacional? <ul><ul><li>Você precisa utilizar um LC_COLLATE diferente; </li></ul></ul><ul><ul><li>Você precisa utilizar diferentes versões do PostgreSQL ao mesmo tempo; </li></ul></ul><ul><ul><li>NUNCA coloque um ambiente de teste e produção no mesmo SO! </li></ul></ul>
  33. 34. Quando virtualizar o SO? <ul><ul><li>Sempre procure utilizar discos distintos para cada VM! </li></ul></ul><ul><ul><li>Você precisa testar uma nova versão ou funcionalidade do PostgreSQL e não tem um ambiente de laboratório separado; </li></ul></ul><ul><ul><li>Você precisa manter o ambiente de produção junto com o ambiente de homologação ou teste no mesmo servidor físico. </li></ul></ul><ul><ul><li>Você deseja ter múltiplos ambientes de laboratório, homologação ou teste no mesmo servidor físico. </li></ul></ul>
  34. 35. Equilíbrio
  35. 36. OBRIGADO <ul><ul><li>Dúvidas, sugestões, correções, indignações e cervejas são bem vindas! </li></ul></ul><ul><ul><li>Fábio Telles Rodriguez, </li></ul></ul><ul><ul><li>Consultoria em PostgreSQL, Oracle e MySQL </li></ul></ul><ul><ul><li>SAVEPOINT: http://www.midstorm.org/~telles </li></ul></ul><ul><ul><li>e-mail: [email_address] </li></ul></ul>

×