Início / dba / Perguntas / 1099
Accepted
David
Asked: 2011-02-07 05:46:35 +0800 CST

Por que tantas soluções MPP são baseadas em PostgreSQL em vez de MySQL?

  • 772

Astor Data, Greenplum e GridSQL permitem processamento paralelo massivo de consultas SQL. Eles também são todos construídos em torno da tecnologia PostgreSQL. Isso é apenas devido a problemas de licenciamento ou há outros motivos? Para mim, parece que o MyISAM, não sendo compatível com ACID e, portanto, não tendo os mesmos problemas com o MVCC (como visto aqui ), pois o PostgreSQL é muito mais adequado para a construção de data warehouses de alto desempenho. Afinal, a carga OLAP não requer transações, tanto quanto posso ver.

mysql postgresql

4 respostas

  1. Best Answer

    É principalmente uma questão de licença. Esses desenvolvimentos acabam corrigindo o código de maneira bastante pesada; portanto, se você fosse lidar com o MySQL, teria que abrir o código-fonte do seu código ou ficar à mercê do proprietário corporativo do MySQL por toda a vida do seu negócio. Algumas ofertas para o MySQL contornam isso implementando seu trabalho como um mecanismo de armazenamento, mas isso não oferece toda a flexibilidade de que precisam e, invariavelmente, acabam corrigindo o núcleo do MySQL também.

    • 14

  2. Vejo duas razões:

    1) historicamente, o PostgreSQL tinha melhor planejador de consultas e analisador de estatísticas. Isso pode não ser verdade agora, mas alguns anos atrás o PostgreSQL era muito melhor que o MySQL em consultas complexas, que são as OLAP.

    2) O PostgreSQL tem melhor suporte de programação de funções/triggers/etc.

    • 11

  3. Como Peter Eisentraut apontou corretamente, antes de mais nada é uma questão de licenciamento. O Postgres é licenciado sob um contrato semelhante ao BSD, o que o torna essencialmente "gratuito para todos", desde que você dê crédito aos desenvolvedores originais em seu trabalho derivado.

    O debate MVCC versus locking scheduler tem sido o assunto de mais do que algumas 'guerras santas' online. Os debates sobre os méritos de vários mecanismos de armazenamento têm sido igualmente controversos.

    Os méritos de diferentes mecanismos de armazenamento de linha principal (também conhecidos como armazenamento de linha) são IMHO amplamente irrelevantes quando se trata de MPP RDBMS construído para cargas de trabalho analíticas por dois motivos:

    1. Embora as peculiaridades do mecanismo de armazenamento sejam importantes para o processamento de transações ACID em cargas de trabalho do tipo OLTP, em um ambiente típico de armazenamento de dados, você precisa oferecer suporte a apenas um tipo de "transação" - um carregamento em lote. Idealmente, é o carregamento em lote que deve ser totalmente bem-sucedido ou falhar completamente.
    2. Bancos de dados analíticos, baseados em mecanismos de armazenamento de armazenamento de coluna, em muitos casos superarão qualquer implementação de armazenamento de linha. A Vertica foi uma loja de colunas desde o início, a Teradata e a Greenplum recentemente adicionaram a funcionalidade de armazenamento de colunas a seus produtos.
    • 6

  4. Construí um sistema MPP no MySQL e descartei o sistema por dois motivos:

    1) é Oráculo

    2) é a falta de junções de hash - loop aninhado e junções de índice não escalam para o nível exigido em um sistema MPP - novamente porque a Oracle inibiu a entrega prometida de junções de hash na linha de código 5.x depois de assumir a propriedade.

    Os sistemas de big data MPP devem ter junções que não sejam de complexidade geométrica. - Junções de complexidade linear ou logarítmica devem ser uma forte preferência para verdadeiros sistemas de big data.

    Em vez disso, implantei o Actian vetorialmente no novo sistema DeepCloud MPP, mantendo uma compatibilidade drizzle/MySQL no nível do usuário.

    Os usuários que desejam análises rápidas de big data podem baixar o DeepCloud em http://www.deepcloud.co

    • 4

relate perguntas