Mike Stonebraker

[jdrowell]

http://cacm.acm.org/blogs/blog-cacm/98136-my-top-10-assertions-about-data-warehouses/fulltext

via @justinsheehy

Interessantes os pontos sobre Data Warehousing (DW), meio que um
gancho dele pro VoltDB, porque o mesmo faz OLTP muito rápido e possui
export tables específicas pra fazer offload pra DW.

Só que achei que ele escorregou no Assertion 10 do texto. Será que
nunca ouviu falar de Map/Reduce? Afinal é exatamente essa a motivação
do M/R, processar os queries utilizando I/O local, e apenas
transmitindo pela rede os dados já mapeados (e de preferência
reduzidos), ou seja, um stream ou batch, não I/O de acesso randômico
remoto.

De qq forma os argumentos dos outros Assertions são válidos, e
inclusive revelam outras oportunidades de ganhos de performance com a
utilização de soluções NoSQL, como por exemplo utilizar colunas
nativas (Cassandra?) ou "fake" (ex: dados particionados com chaves de
mesmo prefixo, chave:col:bi1, chave:col:bi2, etc. logo acesso O(1))
para otimizar I/O em queries complexas. Nada que não possa ser feito
no modelo relacional também (múltiplas tabelas com foreign keys).

[Mauricio De Diana]

Olá.

> Só que achei que ele escorregou no Assertion 10 do texto. Será que
> nunca ouviu falar de Map/Reduce?

Em "A Comparison of Approaches to Large-Scale Data Analysis", o
Stonebraker compara a performance de Hadoop, Vertica (a solução OLAP
de uma empresa dele) e um banco relacional paralelo não identificado
(DBMS-X). Ele faz 5 tipos de testes em 100 nós e conclui que o DBMS-X
é em média 3.2 vezes mais rápido que MapReduce e que o Vertica é 2.3
vezes mais rápido que o DBMS-X.

Em "MapReduce and Parallel DBMSs: Friends or Foes", ele declara que
MapReduce é bom para algumas tarefas:

- ETL (Extract-Load-Transform)
- Análises complexas que fazem várias passagens sobre os dados -
difícil de expressar em SQL
- Dados semi-estruturados.

A mesma edição da ACM Communications que publicou esse artigo publicou
"MapReduce: A Flexible Data Processing Tool", dos autores do paper
original sobre MapReduce. Eles afirmam que o teste do Stonebraker não
mostra que os bancos paralelos são mais rápidos que MapReduce
(modelo), mas sim que são mais rápidos que o Hadoop (a implementação).
Eles afirmam que alguns problemas no Hadoop levantados pelo
Stonebraker já foram atacados há tempos na implementação do Google.

No fim, todo mundo ainda tentando entender (e empurrar) os limites.

Vertica: http://www.vertica.com/
Os dois artigos do Stonebraker e o benchmark:
http://database.cs.brown.edu/projects/mapreduce-vs-dbms/
Slides com o resumo dos artigos: www.cs.brown.edu/~pavlo/presentations/mapreduce-nedb2010.pdf

[]s


On Aug 28, 12:14 pm, jdrowell <jdrow...@gmail.com> wrote:
> http://cacm.acm.org/blogs/blog-cacm/98136-my-top-10-assertions-about-...

[jdrowell]

Boa Mauricio, realmente prova que ele não gosta muito de Map/Reduce :)

On Aug 31, 12:53 am, Mauricio De Diana <mdedi...@gmail.com> wrote:
> Em "MapReduce and Parallel DBMSs: Friends or Foes", ele declara que
> MapReduce é bom para algumas tarefas:
>
> - ETL (Extract-Load-Transform)
> - Análises complexas que fazem várias passagens sobre os dados -
> difícil de expressar em SQL
> - Dados semi-estruturados.

O lance é, praticamente qualquer problema moderno, e o próprio exemplo
do Stonebraker (BI com quantidades crescentes de parâmetros) cai nessa
dos dados semi-estruturados. As otimizações começam a cair por terra
qdo vc percebe que a melhor modelagem dos seus dados é exatamente
documentos schema-free. Nesses casos não-tabulares, e em volumes de
dados que não permitem a criação de índices que caibam num único node
(a la MongoDB), não é nem muito uma questão de escola, você _tem_ que
fazer Map/Reduce, pois a alternativa é montar um filesystem
distribuido (e.g. GFS) e morrer com o I/O em rede (Infiniband?).

Assim,não tem como discutir que o Stonebraker é fera, mas os use cases
que ele tende a discutir são do "produto da vez" de alguma empresa
dele (no caso, VoltDB) e certamente existe um número bem maior de use
cases que esses produtos não atendem. Eu gostaria de ver algo que ele
desenvolveu focando em dados distribuídos e/ou volumes enormes de
dados para ver quais as soluções que ele recomenda nesses casos.

[Gleicon Moraes]

É só lembrar que Map/Reduce não é query com indice. E que funciona melhor para alimentar sua base, do que para fazer buscas ad-hoc. Ai dá para entender porque ele não fala disso quando fala dos produtos dele, para não entrar na distribuição e na pergunta 'como busco minhas coisas ai dentro?'

2010/8/31 jdrowell <jdro...@gmail.com>

--
More cowbell, please !

[Mauricio De Diana]

Dois artigos interessantes, um sobre Stonebraker e outro sobre MapReduce.

"SciDB: Relational daddy answers Google, Hadoop, NoSQL" começa falando
do novo DB do Stonebraker com foco em number crunching, o SciDB. Mas o
artigo acaba comentando bastante sobre o background do Stonebraker,
ajuda um pouco a ler as ideias do cara.

"Google search index splits with MapReduce" fala sobre a troca de
MapReduce pelo Caffeine na ferramenta de busca do Google, basicamente
por causa da indexação. De quebra, fizeram um GFS2 também, mas o
sistema ainda usa Bigtable. O Caffeine será apresentado na OSDI no mês
que vem.

SciDB: http://www.scidb.org/
SciDB: Relational daddy answers Google, Hadoop, NoSQL:
http://www.theregister.co.uk/2010/09/13/michael_stonebraker_interview/print.html
Google search index splits with MapReduce:
http://www.theregister.co.uk/2010/09/09/google_caffeine_explained/

[]s

2010/8/31 Gleicon Moraes <gle...@gmail.com>: