1.

2. Equilbrio 3. Flexibilidade

• Fcil de manter;

• Fcil de portar/ migrar;

• Fcil de entender;

• Fcil de mudar;

4. Desempenho

• Transaes/ Atualizaes;

• Conexes simultneas;

• Consultas complexas;

• Carga e exportao de dados;

• Suporte a grande volume de dados;

5. Segurana

• Evitar acesso no autorizado a informaes confidenciais;

• Evitar alteraes indesejadas;

• Evitar perda de dados;

• Evitar indisponibilidade;

• Recuperao rpida de desastres;

6. Leiam a Documentao Oficial

• DBAs: Leiam tudo!

• Sysadmins: ao menos III - Server Administration

• Desenvolvedores: Leiam ao menos as partes

• • II - The SQL Language

• • IV Client Interfaces

• • V Server Programing

• http://www.postgresql.org/docs/manuals

7. Monitore sempre!

• Configurando os logs do PostgreSQL voc pode:

• • • Detectar gargalos de performance, erros nas aplicaes, falhas de segurana, etc;

• • • • Encontrar sugestes para melhorar a configurao do seu servidor;

• • Voc pode configurar onde, quando, como e o que logar;

• • Voc ainda pode importar os logs para uma tabela dentro do seu banco de dados (Novo no 8.3).

8. Inteligncia da Aplicao no Banco de Dados

Vantagens:

• Maior controle por parte do DBA;

• Maior velocidade em operaes que envolvem um grande volume de dados e um nmero limitado de clculos;

• Acesso padronizado para diversas aplicaes;

• Facilidade de manuteno;

• Baixa curva de aprendizado;

9.

Desvantagens:

• Menor controle por parte do desenvolvedor;

• PL = Procedural Language, ou seja no orientado a objeto;

• Dificuldade em migrar aplicao para outros SGDBs;

• No existe COMMIT ou ROLLBACK dentro de uma funo;

• Cdigo no pode ser ofuscado;

• Alguns servidores de aplicao escalam processamento melhor que o PostgreSQL;

• Concentrao de carga de processamento no SGDB;

Inteligncia da Aplicao no Banco de Dados 10. Inteligncia da Aplicao no Banco de Dados

Boas Prticas:

• Confie no PostgreSQL para reforar restries!

• Utilize funes para clculos em lote;

• Utilize gatilhos para auditar tabelas chave;

• Utilize funes e vises para aumentar a segurana no acesso a informaes sensveis;

• Utilize gatilhos, funes e vises para integrar dados de diferentes aplicaes;

11. Modelagem

• Estrutura de dados inteligentes e cdigo burro trabalham muito melhor que ao contrrio. (Eric Raimond)

• A origem de todo mal est da otimizao de performance precoce. (Leandro Dutra)

• Problemas de performance quando causados por falhas na modelagem podem demorar anos para aparecer.Quando surgem so quase insolveis.

12. Modelagem x Flexibilidade

• Use domnios para melhorar a semntica dos dados;

• Use seqncias para gerar nmeros nicos;

• Use vises para tornar o modelo lgico mais simples que o modelo fsico;

• Documentar DDL, DER e Dicionrio de Dados;

13. Modelagem X Segurana

• Use as restries de integridade: PK, FK, NOT NULL, CHECK;

• Use vises e funes para proteger o acesso a informaes sensveis.

• Nunca crie campos e tabelas do tipo FLEX;

• Documentar DDL, DER e Dicionrio de Dados;

14. Modelagem X Desempenho

• Evite desnormalizar o modelo de dados;

• Separe o modelo fsico do modelo lgico

• Nunca crie campos e tabelas do tipo FLEX;

• Cuidado com FRAMEWORKs e GERADORES DE CDIGO;

15. SQL X Desempenho

• Use funes para processar tarefas em lote;

• Agregue vrias consultas pequenas em uma nica consulta maior;

• Use o PREPARE ... EXECUTE quando no for possvel agregar vrias transaes pequenas e repetitivas;

• Use poucas transaes grandes no lugar de muitas transaes pequenas;

16. SQL X Desempenho

• Use ndices em campos muito utilizados em clusulas WHERE;

• Evite utilizar muitos ndices em ambiente transacional pesado;

• Evite operaes pesadas de DELETE e UPDATE;

• Evite o uso indiscriminado de gatilhos;

• Evite usar funes quando SQL puro resolve;

17. SQL X Segurana

• Use o nome do esquema em operaes DML e nomes explcitos para ndices, restries e seqncias em DDL ;

• Evite realizar operaes pesadas em ambiente grfico;

• Evite criar objetos em interfaces grficas;

• Antes de dizer que um SQL no funciona, teste sempre no psql;

18. SQL X Flexibilidade

• S utilize editores de texto puro;

• Use o psql com a opo i

• Escreva palavras reservadas em letra maiscula e nome de objetos em letra minscula;

• Use o nome do esquema em operaes DML e nomes explcitos para ndices, restries e seqncias em DDL ;

19. O PostgreSQL case sensitive!

Ruim :

CREATE TABLE FUNCIONARIO (

IDFUNCIONARIO SERIAL PRIMARY KEY,

NOME VARCHAR(50) NOT NULL,

DEPTO INTEGER REFERENCES DEPTO(IDDEPTO));

Pssimo :

Create Table Funcionario (

IdFuncionario Serial Primary Key,

Nome Varchar(50) Not Null,

Depto Integer References Depto(IdDepto));

20. USE MINSCULAS para nome de objetos

Bom :

CREATE TABLE funcionario (

id_funcionario SERIAL PRIMARY KEY,

nome VARCHAR(50) NOT NULL,

id_depto INTEGER REFERENCES depto(id_depto)

);

21. Explcito > Implcito

timo :

CREATE SEQUENCEhr. funcionario_seq;

CREATE TABLEhr. funcionario (

id_funcionario INTEGER

DEFAULT NEXTVAL('hr.funcionario_seq'),

nome VARCHAR(50) NOT NULL,

depto INTEGER

CONSTRAINTS

funcionario_pkPRIMARY KEY (id_funcionario)

USING INDEX TABLESPACE tbs_rh_index,

funcionario_depto_fkFOREIGN KEY (id_depto)

REFERENCESrh .depto(id_depto)

) TABLESPACE tbs_rh_table;

22. Explcito > Implcito

Excelente :

SET DEFAULT_TABLESPACE = tbs_rh_table;

CREATE SEQUENCErh. funcionario_seq;

CREATE TABLErh. funcionario (

id_funcionario INTEGER

DEFAULT NEXTVAL(' rh .funcionario_seq'),

nome VARCHAR(50) NOT NULL,

depto INTEGER

);

SET DEFAULT_TABLESPACE = tbs_rh_index;

ALTER TABLE rh.funcionario ADD CONSTRAINTfunc_pk

PRIMARY KEY (id_funcionario) USING INDEX func_pk_ix;

ALTER TABLE rh.funcionario ADD CONSTRAINTfunc_depto_fk

FOREIGN KEY (id_depto) REFERENCESrh .depto(id_depto);

23. Padres

• Aplicaes independentes de SGDB no existem...

• Use funes especficas do PostgreSQL quando:

• • • houver grande ganho de performance ou

• • • esta funo for chave para a sua aplicao;

24. Padres

• ... mas a necessidade de fornecer solues para mais de um SGDB existe!

• Use ao mximo o padro ANSI/SQL;

• Evite o uso de funes que no sejam em PL/pgSQL;

• Evite o uso de funes exticas que no tenham implementao similar em outro SGDB de mercado;

25. Estruturas Lgicas e Fsicas

• Esquema : estrutura lgica onde os objetos so criados. Todo objeto criado em um esquema;

• Tablespace : local fsico p/ armazenamento de tabelas e ndices;

• Banco de Dados : conjunto de esquemas e seus objetos.

• Cluster(initdb): conjunto de arquivos que compe uma nica instncia do PostgreSQL. Esta utiliza um nico conjunto de processos, memria, porta de rede, mas pode conter vrios bancos de dados;

26. Um Esquema Por Aplicao

PostgreSQL no acessa nativamente outros bancos de dados;

Crie um esquema para cada aplicao com seu prprio dono;

Utilize um esquema separado para auditoria de vrios sistemas;

Utiliza um esquema separado para monitoramento do DBA;

Utilize o esquemapublicapenas para compartilhar dados entre diversas aplicaes;

No coloque objetos noinformation_schema ,pg_catalogoupg_toast .

27. Dois tablespaces por aplicao

Utilizar nomnimoum tablespace para ndices e um para tabelas;

Mais fcil identificar o espao fsico ocupado pela aplicao;

Mais fcil identificar arquivos de backup fsico;

Mais fcil identificar uso e volume de ndices ou tabelas;

Mais fcil fazer ajuste de I/O e desempenho;

Uma camada a mais de segurana na criao de objetos;

28. Na Prtica

No bash do Linux:

#mkdir /postgresql

#chown postgres /postgresql

#su postgres

$cd /postgresql

$mkdir /postgresql/tbs_hr_index

$mkdir /postgresql/tbs_hr_table

$psql pgcon

29. Na Prtica

No psql do PostgreSQL:

pgcon=#REVOKE ALL ON TABLESPACE pg_default,pg_global FROM public;

pgcon=#REVOKE ALL ON SCHEMA public FROM public;

pgcon=#CREATE ROLE hr NOLOGIN;

pgcon=#CREATE TABLESPACE hr_index OWNER hr LOCATION '/postgresql/tbs_hr_index';

pgcon=#CREATE TABLESPACE hr_table OWNER hr LOCATION '/postgresql/tbs_hr_table';

CREATE SCHEMA AUTHORIZATION hr;

30. Novos TABLESPACES?

• S faz sentido utilizar muitos tablespaces se voc tem ou pretende ter vrios discos!

• Tablespace temporrio em ambiente com muitas consultas pesadas (novo no 8.3!);

• Separar dados histricos e parties de tabelas pouco utilizadas em discos mais baratos;

• Tabelas e ndices onde o desempenho crtico (Usar RAID);

• Tabelas onde a disponibilidade crtica (Usar RAID);

31. Ambientes

• Produo: utilizado por todos usurios da aplicao;

• Homologao: aceite de novas verses pelo usurio, testes de performance;

• Teste: desenvolvimento de aplicaes;

• Laboratrio: teste de novas verses, patches e funcionalidades do SGDB.

32. Segurana

• Use transaes com BEGIN, COMMIT e ROLLBACK;

• Use proteo efetiva contra SQL Injection na aplicao;

• Use desconexo automtica por ociosidade;

• Use de tratamento de erros especial para erros de violao de restries de integridade;

• Nunca exiba mensagens de erro do banco na tela do usurio;

• Nunca confie em converses implcitas de tipo de dados;

33. Segurana

• Faa backup peridico do seu ambiente de produo e teste;

• Teste todas rotinas de backup e restaurao;

• Nunca utilize TRUST ou PASSWORD como mtodo de autenticao no pg_hba.conf;

• Acompanhe os logs de erro;

• No utilize codificao de caracteres SQL_ASCII;

• Durma!!!

34. Backup e Alta Disponibilidade

• Backups:

• • • Lgico (pg_dump)

• • • Fsico off line

• • • Fsico on line (via PITR)

• • • Snapshot (via storage)

• Alta disponibilidade:

• • • Stand By (via PITR);

• • • Replicao (via pg_pool, Slony, pg_cluster, etc)

• • • Cluster (PL Proxy + pg_bouncer)

35. Autenticando Aplicaes no PostgreSQL

• Autenticao Interna : um usurio do PostgreSQL por usurio da Aplicao;

• Autenticao Externa : um usurio do PostgreSQL por usurio da Aplicao com autenticao externa (LDAP, AD, etc);

• Autenticao via Aplicao : um usurio do PostgreSQL para todos usurios da aplicao;

36. Autenticao Interna

• Auditoria consistente;

• Uso de ROLEs para agrupar privilgios em objetos;

• DBA precisa criar usurios no banco de dados manualmente;

• Aplicao deve trocar senha do usurio na primeira vez em que ele se conectar;

• Um usurio e senha para vrias aplicaes;

• Se a aplicao for Cliente/Servidor,PostgreSQL no consegue impedir o usurio de se conectar por fora da aplicao;

37. Autenticao Externa

• Tem as mesmas caractersticas da Autenticao Interna com as seguintes diferenas:

• • • Administrao de senhas fica a cargo do Administrador de Sistemas;

• • • Se integra com os demais usurios da rede;

• • • mais complexo para ser configurado;

38. Autenticao pela Aplicao

• Auditoria deve ser implementada pela aplicao;

• Cadastro de usurios, senhas e permisses de inteira responsabilidade da aplicao;

• Senha de acesso ao PostgreSQL deve ficar dentro da aplicao;

• O ROLE da aplicaonuncapode ser mesmo que o ROLE do desenvolvedor ou o dono dos objetos da aplicao;

39. Autenticao Boas Prticas

• Aplicaes web no corporativas com muitos usurios devem utilizar autenticao pela aplicao;

• Aplicaes que precisam de pool de conexes devem utilizar autenticao pela aplicao;

• Aplicaes corporativas com 3 ou mais camadas devem preferir devem preferir autenticao externa;

• Mude opg_hba.confconforme o ambiente (produo, homologao, teste e laboratrio)

40. pg_hba.conf

• Sempre identifique o nome do banco de dados;

• Utilize SSL para encriptar o trfego de informaes pela rede.

• Utilize 'ident' apenas para conexes locais;

• Utilize MD5 para conexes remotas;

• Limite a faixa de IPs ao mximo:

• • • No caso aplicaes em 3 ou mais camadas,limite aos IPs dos servidores de aplicao;

• • • No caso de aplicaes Cliente/Servidor, limite a rede local que eles utilizam;

41. pg_hba.conf

• Separe as regras por grupos (ROLES) de usurios:

• • • DBAs;

• • • Desenvolvedores;

• • • Aplicaes (autenticao pela aplicao);

• • • Aplicaes (autenticao interna);

• • • Aplicaes (autenticao externa);

• • • Usurios especiais;

42. Vrios ambientes no mesmo servidor?

• Voc tem que garantir a disponibilidade de recursos (Processador, Memria e Discos) para o servidor de produo;

• Uma nica consulta mal feita pode comprometer a performance de todos usurios;

• No possvel virtualizar os canais de I/O ;

43. Quando utilizar mais de um banco de dados no mesmo cluster?

• Voc quer aproveitar os processos do cluster existente mas precisa comparar uma nova verso dos mesmos objetos;

• Voc tem aplicaes que precisam utilizar diferentes codificaes de caracteres;

• NUNCA coloque um ambiente de teste e produo no mesmo cluster!

44. Quando utilizar mais de um cluster no mesmo Sistema Operacional?

• Voc precisa utilizar um LC_COLLATE diferente;

• Voc precisa utilizar diferentes verses do PostgreSQL no mesmo servidor;

• NUNCA coloque um ambiente de teste e produo no mesmo SO!

45. Melhores Prticas

Melhores prticas so diretrizes e no dogmas:

Uma pessoasembom senso no se preocupa com melhores prticas;

Uma pessoa com bom senso e pouca experincia procura aprender e utilizar as melhores prticas;

Uma pessoa com bom senso e muita experincia sabequandono utilizar as melhores prticas;

46. OBRIGADO

• Dvidas, sugestes, correes, indignaes e cervejas so bem vindas!

• Fbio Telles Rodriguez,

• SAVEPOINT:http://www.midstorm.org/~telles

• e-mail:[email_address]