COMPARAÇÕES ENTRE MYSQL E POSTGRESQL
Cobertura do sql Em termos de expressividade as linguagens suportadas pelos dois sistemas são bastante equivalentes. Armazenamento e estrutura de dados O MySQL no campo de armazenamento de dados prima principalmente pela variedade. Fornece aos seus utilizadores a oportunidade de escolher a forma de armazenamento que mais se adequa a utilização que irá dar à base de dados. Ambos os sistemas usam as funcionalidades do Sistema Operacional para organizar os dados em disco. O tipo de tabelas por omissão do MySQL guarda os dados sob a forma de registos seqüenciais de tamanho fixo ou variável ao passo que o PostgreSQL guarda todos os dados em Slotted Page(ponteiros apontados para registros). A primeira abordagem é mais genérica e pode ser usada em qualquer suporte físico, a segunda tenta tirar o maior partido do suporte físico mais comum para bases de dados: os discos magnéticos. A possibilidade de compressão de alguns dados oferecida pelo MySQL pode ser uma mais-valia para ambientes onde os recursos são escassos.(ex. sistemas embutidos) Indexação Embora ambos os sistemas permitam indexação, o MySQL é um pouco mais limitado neste aspecto. A flexibilidade oferecida pela variedade de storage engines torna-se aqui algo limitante quando alguns índices apenas estão disponíveis para alguns tipos de tabelas. A funcionalidade de índices sobre parte da chave do MySQL pode ser simulada em PostgreSQL com a funcionalidade de índices com uma função sobre os atributos como chave (substring), ao mesmo tempo que permite funções mais complexas. Embora o MySQL possua um indexador de fulltext bastante flexível, o PostgreSQL tem dois mecanismos de indexação sobre os quais podem ser construídos quaisquer índices (em teoria) e onde foram de fato construídos índices de fulltext, presente nos módulos contribuídos (tsearch2). O PostgreSQL não permite associar a organização de uma tabela com a ordem de um índice, embora permita uma operação única de ordenação(CLUSTER). O MySQL não suporta nada como a indexação parcial do PostgreSQL, poupa espaço ao impedir que os índices se tornem inúteis devido a estarem populados com valores comuns e/ou desinteressantes. Processamento e Otimização de queries O otimizador e executor de queries do PostgreSQL são obviamente mais avançados que os módulos correspondentes no MySQL. A simplicidade tanto do planejador como do executor de queries do MySQL pode ser explicado pelo fato de este sistema apontar principalmente para o uso em páginas web em que as queries nem são complicadas nem incidem numa quantidade considerável de dados. Mais uma vez notamos numa dualidade de critérios sobre as funcionalidades presentes dependendo do storage engine usado. O MySQL permite, no entanto, uma forma mais fácil de dar indicações sobre como realizar as operações, funcionalidade que no PostgreSQL é bastante mais difícil, para algumas dicas até mesmo impossível de conseguir. Transações e controle de concorrência Mais uma vez no MySQL as transações mostram serem uma funcionalidade presente apenas para algumas escolhas no que diz respeito à forma de guardar as tabelas. Será certamente uma pena não haver a possibilidade de se ter acesso concorrente com algumas garantias de isolamento em tabelas onde se pode querer usar índices fulltext, por exemplo. Esta abordagem mista também da luz a muitos casos especiais que o programador deve ter cuidado se quiser (ou tiver de) misturar vários storage engines. Por outro lado ao ter algoritmos menos complicados, ou simplesmente a não os ter, de controle e gestão de concorrência, o MySQL pode ganhar na área da eficiência. Um exemplo disto é a execuções da função de agregação count. Enquanto que devido ao fato de se ter de ler as tuplas da página de forma a determinar a sua visibilidade para a transações corrente, no PostgreSQL a melhor forma de responder a uma pergunta com essa funções é percorrendo toda a relações, o que em alguns casos pode ser muito demorado. O MySQL com as tabelas MyISAM é perfeitamente capaz de responder a uma pergunta deste gênero consultando apenas meta-dados sobre a tabela, ou índices. O sistema de controle de transações do PostgreSQL parece ser bastante mais robusto e consistente. O fato de sua semântica e gestão das tuplas requerer manutenção temporária pode ser visto como outra desvantagem das escolhas tomadas. Suporte para base de dados distribuídas Embora também seja possível obter replicações de bases de dados PostgreSQL usando os seus logs, não é uma funcionalidade de fácil acesso pelo que para todos os efeitos consideramos que o PostgreSQL poderia oferecer um pouco mais neste aspecto. O MySQL fornece uma forma bastante transparente (um storage engine) de acessar remotamente a outras bases de dados, funcionalidade que está em falta no PostgreSQL. Mesmo não sendo suporte consagrado para distribuição da base de dados uma vez que não mantém o esquema da tabela sincronizado, nem permite a criação transparente de tabelas em hosts remotos, uma funcionalidade com bastante utilidade. Conclusões O MySQL: É o mais ágil, pois é otimizado para proporcionar processamento rápido dos dados e tempo curto de resposta sem exigir muito do hardware. Quando Usar o MySQL a. Back-end para geração de conteúdo de web sites; b. Aplicação envolvendo basicamente consultas e inserção de dados. Sugiro não usar para aplicações com fortes demandas transacionais, (especialmente se houverem atualizações concorrentes)! c. Empresas como o Yahoo Finance combinam o MySQL (aplicações web) com um outro banco de dados (retaguarda financeira). Flickr também usa MySQL, e são mais de 800 queries simultâneas por segundo, entre outras estatísticas surpreendentes. O PostgreSQL: é para aplicações complexas, ou seja, quando envolvem um grande volume de dados(acima de 5 milhões por dia) ou que tratam informações críticas. Quando Usar o PostgreSQL Aplicações com fortes componentes transacionais. Aplicações que necessitem de tipos de dados especializados, como Sistemas de Informações Geográficas (SIG) e repositórios de meta-dados. Projetos baseados em metodologias Orientadas Objeto - perda de compatibilidade com o padrão ANSI SQL Aplicações OLAP "light", que não necessitem do nível de sofisticação de um DataWarehouse. -- Valter Cezar Prado Junior Analista TI Sem saber como fazer ele fez!
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
