VoltDB: nova investida do pai do PostgreSQL
Separei um trecho do post do InfoQ, cujo link tem mais detalhes:
Dia 25 de Maio foi anunciado o Release do VoltDB. O VoltDB é um banco de dados relacional que vêm atingir um ramo onde os RDBMS estavam perdendo mercado para os NoSQL, que é o mercado de escalabilidade. Segunda a empresa VoltDB (fundada por Mike Stonebraker, o criador do PostgreSQL) responsável pelo projeto, o novo RDBMS garante escalabilidade e confiabilidade, obtendo, em alguns casos, performance superior aos banco de dados NoSQL baseados em chave-valor (key-value).
O VoltDB ficou disponível em versão pré -lançamento por alguns meses e, segundo a empresa, os resultados foram extremamentes satisfatórios e as expectativas foram superadas. Michael Rauchman CTO da empresa Getco testou a versão de pré-lançamento e disse: “Nós utilizamos a versão pré-lançamento do VoltDB por diversos meses e sua performance e escalabilidade excederam qualquer DBMS que nós já havíamos utilizado.”
O que o VoltDB vem oferecer merece grande atenção: ele é diferente da maioria dos RDBMS atuais, que se baseiam em designs antigos de cerca de 30 anos atrás que apresentam alguns problemas de design quando o assunto é de performance e escalabilidade. Isso acontece pois esses designs foram criados bem antes dos bancos de dados para web (web-scale), quando escalabilidade e performance eram tratadas de uma maneira diferente. (…) (via infoq.com)
“O que o VoltDB vem oferecer merece grande atenção: ele é diferente da maioria dos RDBMS atuais, que se baseiam em designs antigos de cerca de 30 anos atrás que apresentam alguns problemas de design quando o assunto é de performance e escalabilidade.”
Escalabilidade pode se discutir. Mas performance ?
Piada, estão muito bem. O que se quer é performance excelente com usuários Dummy que estão criando sua primeira aplicação em Basic, digo, PHP e mysql.
Achei estranha essa iniciativa. Muita promessa e tudo ligado a uma empresa só.
Prefiro esperar mais uns dois ou três meses a versão 9 do postgres que vem com muita novidade, principalmente na parte de escalabilidade, feita sem gambiarras.
Engraçado… Criador do Postgres lança um SGBD sob a GPL. Será que ele se revoltou com o modelo de licenciamento do pg?
“Engraçado… Criador do Postgres lança um SGBD sob a GPL. Será que ele se revoltou com o modelo de licenciamento do pg?”
Não sei. O que sei é que é um projeto completamente controlado por uma empresa.
Deve ter se revoltado é com a venda do Mysql. Pensado que se até aquele banco ruim foi bem vendido, porque algo muito melhor não pode.
Ainda bem que o postgres não é controlado por uma empresa. :)
http://www.voltdb.com/blog/key-value-benchmarking
@Weber Jr.
MySQL não é ruim. É MUITO ruim.
Tenho um projeto pessoal para fazer backup de arquivos em banco de dados. O suporte a BLOB do mySQL é a coisa mais porca e sem vergonha que que já ví.
Para começar tem 3 tipos de BLOB (Small blob, medium blob e large blob). Más são todos muito limitados. Usando ferramentas como essa, o desenvolvedor, mesmo que hobista como eu, acaba sendo obrigado a adotar as metodologias POG.
Tomara que a Oracle dê um jeito no MySQL. Do jeito que está, logo logo não vai ter mais niguem usando.
@Conan
Assim, não é uma boa prática usar o banco de dados para armazenar arquivos.
Ja vi excelentes sistemas funcionarem redondo sobre MySQL porém em muitas vezes alguma coisa foi sacrificada como a integridade referêncial (mas isso o ORM garante em varios casos, como no ActiveRecord do Rails). Porém usar banco, usar sql, para armazenar arquivos eu só faria em casos excepcionais e onde o tempo de leitura não fosse critico. Um bom cache e um filesystem eficiente (e bem configurado) é o ideal para 95% dos casos. Ai resta os outro 5% que o Conan pode estar enfrentando ;-)
@Conan
Acho muito dramático dizer que algo é “MUITO ruim” só por causa de uma funcionalidade secundária… Como outros disseram, banco de dados é para armazenar (preferencialmente) dados e não arquivos!
Quanto vai levar para a Oracle tentar comprar?
O PostgreSQL nasceu na Sum, e seu maior desenvolvimento também era realizado por eles, e acho que ainda é, só que agora são Oracle, como o MySQL, ou seja, estamos num terreno meio complicado ao falar desses dois SGBDs porque quem esta comandando é uma empresa que vive disso, o Oracle.
@Curioso
“O PostgreSQL nasceu na Sum”
Soma, é uma empresa ? Ou Sun ? Mas não interessa, não nasceu em nenhuma delas e sim na universidade de Berkeley(Não precisei consultar a Wikipedia pra saber isso :P).
“e seu maior desenvolvimento também era realizado por eles”
Não sei como mediu isso, mas duvido. A Sun ajudou muito, inclusive empregando alguns dos grandes desenvolvedores. Mas na última versão, por exemplo, muita coisa evoluiu no Pg e quase nada da Sun foi usado (faltou tempo nos testes, parece).
A versão 9 já está entrando em Beta com muita coisa nova (e por isso não vai mais ser 8.5 e sim 9) e a Sun já até é da Oracle.
“estamos num terreno meio complicado ao falar desses dois SGBDs”
Não, é muito diferente. Um banco é feito por uma empresa vendida e depois revendida num pacotão. Outro SGBD é feito por uma Organização independente que recebe sim, ainda bem, muita ajuda de empresas, diversas, não uma única.
Esses medos e achismos devem ser fruto ainda dos boatos maldosos e mentirosos (o velho FUD) que o Widenius andou espalhando para todo lado.
@Rodrigo Carvalho,
No meu trabalho eu estou acostumado com Oracle, vai ver que é por isso que eu acho que as fucionalidades existem para funcionar.
@SJCatar,
Porque não é uma boa prática armazenar arquivos em bancos de dadoss? Não é para isso que existe o tipo de dados BLOB? (Não é flame, eu não sei mesmo)
@Conan
Porque é muito mais eficiente armazenar arquivos no sistema de arquivos do SO, que foi feito especialmente para isso. Armazenar arquivos no banco de dados apenas incha o banco, tornando a execução das transações mais lentas desnecessariamente. Nesse caso a melhor opção seria armazenar o caminho do arquivo no banco de dados e os arquivos em si no sistema. Assim você consegue um sistema mais eficiente.
@SJCatar
“Armazenar arquivos no banco de dados apenas incha o banco, tornando a execução das transações mais lentas desnecessariamente.”
Na verdade isso depende muito do SGBD usado, SGBDS como o ORACLE permitem vc. usar este recurso sem impacto na performance.
@Víctor, vai ver que é por isso que bancos de dados tẽm este nome: armazenam dados. Já sistemas de arquivos, como o próprio nome diz, armazenam arquivos (poderiam ser chamados de bancos de arquivos?) hauahauha. Brincadeira, só pra descontrair :-)
Acho que o que o SJCatar quis dizer é que bancos de dados não foram originalmente feitos para o armazenamento de arquivos, mas de dados. Arquivo é um tipo especial de “contêiner” para armazenar dados, mas não é um banco de dados (embora bancos sejam normalmente armazenados em arquivos). São níveis de abstração diferentes.
Não sou muito expert em banco de dados (conheço no máximo um pouco de mysql e sqlite, só como usuário), mas o fato da Oracle ter um bom desempenho em armazenar arquivos não implica que um bom banco tenha que ter esta capacidade. Senão vira que nem o Corel Draw, um programa de criação vetorial que se destaca como preferido pelos usuários por recursos que não tem a menor relação com desenhos vetoriais. Logo qualquer programa que não faça tudo que o Draw faça não é considerado um programa tão bom.
Ah sim, eu descobri, por meio de um colega meu, que os blobs e binary blobs servem somente pra que os outros não consigam interpretar textos guardados nestes campos, e para quem futuramente for usar os dados tenham muitos problemas com codificação de caracteres… :-) hauhuhaau
E tem alguns que trapaceiam. O MSFT SQL 2008, por exemplo. Muito se fala do gigantesco (da ordem dos petabytes) banco do projeto Pan-STARRS baseado num cluster de MSFT SQL Server 2008 (que a MSFT praticamente paga para que o usem). Só esquecem de dizer que os blobs com os dados/fotos em si são gravados fora do tablespace, em arquivos referenciados no sistema de arquivos. Apenas pegaram algo que seria feito na aplicação e colocaram como “feature”.