Fazendo Um Elefante Passar Debaixo da Porta - FISL

Fcil de manter;

Fcil de portar/ migrar;

Fcil de entender;

Fcil de mudar;

Transaes/ Atualizaes;

Conexes simultneas;

Consultas complexas;

Carga e exportao de dados;

Suporte a grande volume de dados;

Evitar acesso no autorizado a informaes confidenciais;

Evitar alteraes indesejadas;

Evitar perda de dados;

Evitar indisponibilidade;

Recuperao rpida de desastres;

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

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).

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;

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;

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;

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.

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;

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;

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;

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;

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;

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;

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 ;

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));

CREATE TABLE funcionario (

id_funcionario SERIAL PRIMARY KEY,

nome VARCHAR(50) NOT NULL,

id_depto INTEGER REFERENCES depto(id_depto)

timo :

CREATE SEQUENCEhr. funcionario_seq;

CREATE TABLEhr. funcionario (

id_funcionario INTEGER

DEFAULT NEXTVAL('hr.funcionario_seq'),

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;

Excelente :

SET DEFAULT_TABLESPACE = tbs_rh_table;

CREATE SEQUENCErh. funcionario_seq;

CREATE TABLErh. funcionario (

id_funcionario INTEGER

DEFAULT NEXTVAL(' rh .funcionario_seq'),

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);

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;

... 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;

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;

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 .

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;

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

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;

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);

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.

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;

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!!!

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)

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;

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;

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;

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;

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)

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;

Separe as regras por grupos (ROLES) de usurios:

Desenvolvedores;

Aplicaes (autenticao pela aplicao);

Aplicaes (autenticao interna);

Aplicaes (autenticao externa);

Usurios especiais;

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 ;

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!

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!

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;

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

Fbio Telles Rodriguez,

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

e-mail:[email_address]

Fazendo Um Elefante Passar Debaixo da Porta - FISL

Technology

Transcript of Fazendo Um Elefante Passar Debaixo da Porta - FISL