Nossa, muito bom texto Prado, está de parabéns! Outra coisa, você teria algum link que mostrasse a diferença entre esses storage engines do mysql? Acho que seria interessante na hora de escolher a base de dados.
Abraço! Obs.: Vou guardar esse texto em um txt eehhehehe. 2008/1/22 Pablo Sánchez <[EMAIL PROTECTED]>: > Excelente análise, bastante imparcial. Parabéns. > > Em 22/01/08, junior Prado <[EMAIL PROTECTED]> escreveu: > > > > 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 > > > > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Sds, Thiago Diogo --- "Em um mundo sem paredes, quem precisa de janelas ?" - www.bizupedia.com ---
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
