banco de dados
Mauro Zirbes
Como realmente, nada sei sobre o assunto, qualquer ajuda seria bem vinda, obrigado.
Mauro Zirbes
Leonardo Menezes Vaz
> assunto?
Sim. Para entender os conceitos começaria aqui:
http://en.wikipedia.org/wiki/NoSQL
http://nosql-database.org/
Tem uma apresentação que um amigo de SP fez no trabalho dele:
http://www.slideshare.net/gleicon/nosql-introduction
Vale a pena dar uma olhada nos docs do MongoDB:
http://www.mongodb.org/display/DOCS/Home
http://slidesha.re/9isqkk
Se quiseres ver na prática como funciona a implementação, dá uma
olhada nos links:
http://www.linuxjournal.com/article/3294
http://planeta.gnulinuxbrasil.org/?cat=1875
> Como realmente, nada sei sobre o assunto, qualquer ajuda seria bem vinda,
Vou falar com o Gleicon e ver se ele topa vir à PoA no final do ano
falar sobre o assunto. ;)
Leo
Vinicius Mello
> Algu�m a� j� conhece bancos noSQL (key-value)? Talvez algum link sobre o
> Como realmente, nada sei sobre o assunto, qualquer ajuda seria bem
> vinda, obrigado.
Mauro,
No site da Redis, uma base key-value em software livre, tem
um tutorial de "15 minutos" sobre key-value com uma
abordagem sobre as principais quest�es de key-value.
http://code.google.com/p/redis/wiki/IntroductionToRedisDataTypes
E tamb�m um tutorial sobre como criar um Twitter em
key-value, com uma implementa��o em PHP com c�digo fonte e
demonstra��o.
http://code.google.com/p/redis/wiki/TwitterAlikeExample
O site da Redis tem wiki e FAQ excelentes.
Existem v�rias formas de resolver os problemas atrav�s de
NoSQL, mas � bom prestar aten��o no contexto das discuss�es
e o tipo de ferramenta que se est� usando. Porque existem
conceitos e implementa��es key-value, key-document,
key-object, key-graph, etc.
NoSQL � muito mais um conceito do que software. Por exemplo,
esse texto mostra como o FriendFeed.com usa o MySQL pra
armazenar dados em formato de NoSQL:
http://bret.appspot.com/entry/how-friendfeed-uses-mysql
Sds,
vmm.
Mauro Zirbes
Muito obrigado a ti e aos demais que contribuiram:)
Confesso que tive dificuldades em achar algo de inicio, por que pensava mais em um produto pronto e menos como um conceito.
Mauro Zirbes
LPI Certified III Level
Mauro Zirbes wrote:
Alguém aí já conhece bancos noSQL (key-value)? Talvez algum link sobre o assunto?
Como realmente, nada sei sobre o assunto, qualquer ajuda seria bem vinda, obrigado.
Mauro,
No site da Redis, uma base key-value em software livre, tem um tutorial de "15 minutos" sobre key-value com uma abordagem sobre as principais questões de key-value.
http://code.google.com/p/redis/wiki/IntroductionToRedisDataTypes
E também um tutorial sobre como criar um Twitter em key-value, com uma implementação em PHP com código fonte e demonstração.
http://code.google.com/p/redis/wiki/TwitterAlikeExample
O site da Redis tem wiki e FAQ excelentes.
Existem várias formas de resolver os problemas através de NoSQL, mas é bom prestar atenção no contexto das discussões e o tipo de ferramenta que se está usando. Porque existem conceitos e implementações key-value, key-document, key-object, key-graph, etc.
NoSQL é muito mais um conceito do que software. Por exemplo, esse texto mostra como o FriendFeed.com usa o MySQL pra armazenar dados em formato de NoSQL:
http://bret.appspot.com/entry/how-friendfeed-uses-mysql
Sds,
vmm.
--Você está recebendo esta mensagem porque se inscreveu no grupo "TcheLinux" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para tche...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para tchelinux+...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/tchelinux?hl=pt-BR.
Mauricio Mauad Menegaz Filho
Eu não sou grande fã dos RDBMS, e em 2008 eu e um colega do trabalho
resolvemos "dropar" a base de dados do projeto, e usar o filesystem +
JSON pra fazer o armazenamento dos dados de um sistema que escrevemos.
Foi legal, pena que não fizemos isso antes, e que não tivemos tempo de
limpar a colcha de retalhos para liberar pro mundo o negócio (tinha
java, shell script, C, magia negra e tudo que os programas que
funcionam devem ter, hehehehehe)
A performance do sistema melhorou muito, a concorrência fica
totalmente a cargo do sistema operacional, e o backup/restore é uma
beleza indescritível! comprime o diretório, mete na fita, deu pau,
descomprime da fita e toca o barco. Parece mentira... Ah, da pra usar
até o git pra fazer o backup, hehehehehe :)
Derepente descobri o Erlang, e junto com isso vi que uns gringos
estavam fazendo o CouchDB, e que a idéia deles era uma espécie de
harley davidson (teórica) comparada á nossa bicicleta (up and
running). Vale a pena ver o couch se tu consideras a idéia de largar
de mão a base de dados (e o dba :p).
Abraço
mauad
Gustavo Ciello
Também fiquei "hipnotizado" pela idéia (simples) por trás desse
movimento NoSQL, especialmente depois que o Twitter decidiu mudar a
coisa toda de MySQL para Cassandra.
Segue link de referência:
http://computerworld.uol.com.br/tecnologia/2010/02/23/crescimento-faz-twitter-trocar-o-mysql-pelo-cassandra/
Bom estudo!
On 1 mar, 13:11, Mauricio Mauad Menegaz Filho <mma...@gmail.com>
wrote:
Mauro Zirbes
Agora, em especial ao Mauad ou a qualquer outro que ja tenha utilizado o noSQL, uma pergunta:
Em príncípio, deslocando as regras de integridade e validação para a aplicação isso não sobrecarregaria a aplicação, quero dizer não aumentaria a responsabilidade do programador? Não que eu seja contra isso! Pelo contrário! Apenas quero comprovar se estou compreendendo o assunto.
[ ]s
Mauro Zirbes
Mauricio Mauad Menegaz Filho
Em 1 de março de 2010 19:08, Mauro Zirbes <mzi...@gmail.com> escreveu:
> Essa do twitter um amigo me deu a dica hoje pela manhã. Novamente, muito
> obrigado os que se manifestaram e contribuiram positivamente.
> Agora, em especial ao Mauad ou a qualquer outro que ja tenha utilizado o
> noSQL, uma pergunta:
> Em príncípio, deslocando as regras de integridade e validação para a
> aplicação isso não sobrecarregaria a aplicação, quero dizer não aumentaria a
> responsabilidade do programador? Não que eu seja contra isso! Pelo
> contrário! Apenas quero comprovar se estou compreendendo o assunto.
Certo que sim! Não só do programador, mas também de quem desenha a
solução -- quando não são o mesmo. Todo caso, há um efeito colateral
nisso tudo que é vantajoso: o desenho, depois de refeito sem uma base
relacional fica mais limpo! Principalmente pra quem não é DBA...
Especificamente falando da validação/integridade, o aumento de
trabalho não é tão grande, já que em geral tanto o desenhista da base
quanto da aplicação incluem checagens relacionadas à validação. Quanto
à integridade "no bit", tu dispensas a forma dos metadados utilizados
pela base em detrimento da forma que tu vais escolher -- que
geralmente vai ser mais "lazy".
Pense que agora tuas stored procedures podem ser substituídas por
scripts/programas; as estruturas hierárquicas que outrora tu montava
na base, vão direto pro filesystem e/ou no modelo de metadados do teu
noSQL (JSON, XML ou outros formatos). ah, mas atente aos limites do
teu filesystem! Muito provavelmente a crescente no uso de noSQL vai
demandar escolhas mais judiciosas de filesystem, e pode ter certeza de
que teremos um ganho em qualidade tremendo nesta área.
O modelo de segurança utilizado agora pode ser exatamento o modelo de
segurança do próprio sistema de arquivos. É como uma explosão! Tudo
que a base encapsulava, reforçava, fica exposto, na mão do sistema de
novo. No nosso caso qeubramos tudo em milhares de arquivos, e as
"queries" eram simplesmente correr sobre as chaves (que eram o nome
dos diretórios) a fim de se encontrar o último ramo da raíz, se qé que
ele estava lá. claro que sofremos, pois chegamos aos limites de
inodes, e tivemos dificuldades em depurar algumas coisas por estarmos
mentalmente presos à base.
Por exemplo, tinhamos um (de um software de monitoração), que sob um
aspecto era mais ou menos assim:
(id do cleinte, dados de performance, id do dispositivo, timestamp
unix, id do objeto de performance)
file = "/02344/perf/3442/1264488610/34423/data.json";
if ((fp = fopen(file, "r") == NULL) {
return;
}
E essa era a query. Se o fopen() deste arquivo desse == NULL, é por
que não havia coleta naquele tempo. claro, esta árvore aí tinha
centenas de links simbólicos pra gente acessar a coisa em contextos
diferentes, e a princípio, pode parecer mais complicado do que uma
query do tipo
select * from perf where customer_id = 02344 and device_id = 3442 and
timestamp = 1264488610;
porém, a velocidade é impressionantemente melhor nesse caso.
Ah claro, to falando aqui especificamente de um sistema baseado em
arquivos soltos no filesystem, e não de uma tecnologia noSQL
comoditizada...
Mas nem tudo são flores... Em determinados problemas esse approach
pode ser menos vantajoso em alguns aspectos... Por exemplo, em acessos
de leitura massivos, uma base com uma baita área de cache em memória
pode render muito, porém, pode-se obter isso fazendo tunnign do
sistema operacional. Outra coisa: se o desenho da solução depende
fortemente no relacionamento entre as entidades, vai ser um inferno
montá-la! A menos que se mude tudo desde o início.
Imagino muitos fatores vantajosos:
-- O administrador dos dados é o administrador do filesystem
-- O backup dos dados, é o backup do filesystem
-- o restore do backup é um tar zxvf de um arquivo :p
-- A escrita vai da aplicação para o filesystem
-- aumentar um "tablespace" é fazer um lvextend!
-- monitorar a base é monitorar o filesystem
-- Replicação? copia o arquivo, ora!
E claro, algumas desvantagens:
-- Nenhum DBA vai migrar facilmente (por motivos (crenças) técnicos,
econômicos, políticos, pessoais e por aí vai...)
-- Poucas companhias (especialmente os executivos) serão facilmente
convencidos de que abandonar o
RDBMS pode ser vantajoso em algumas ocasiões, portanto, mostrar
resultados é fundamental!
-- Não tem mais query!
-- Esqueça os joins, views e muitas coisas fantásticas que a
matemática relacional pode oferecer!
Com tudo isso, o noSQL parece ser uma bela escolha para armazenamento
de documentos, e em casos onde o relacionamento entre as entidades não
é muito complicado. Ah, isso sem falar que o noSQL certamente é a
escolha natural para o armazenamento na nuvem (que contra vários, vai
colar sim senhor).
abraço
mauad
Mauro Zirbes
Realmente, teus argumentos são sólidos! Valeu por mais esta aula :)
[ ]s
Mauro Zirbes
abraço
mauad
Rafael Almeida
negócio continua sendo viável?
On 1 mar, 21:15, Mauro Zirbes <mzir...@gmail.com> wrote:
> Bela explicação Mauad!
> Realmente, teus argumentos são sólidos! Valeu por mais esta aula :)
> [ ]s
> Mauro Zirbes
>
> 2010/3/1 Mauricio Mauad Menegaz Filho <mma...@gmail.com>
>
> > Buenas!
>
> > tchelinux+...@googlegroups.com<tchelinux%2Bunsu...@googlegroups.com>
Mauricio Mauad Menegaz Filho
Em 3 de março de 2010 10:10, Rafael Almeida <rafael...@gmail.com> escreveu:
> E quando entramos em aspectos mais críticos e soluções como BI, o
> negócio continua sendo viável?
Não sei o que tu chama de aspectos mais críticos, mas quanto ao BI, sem dúvida!
Não sou especialista em bancos e estruturas de dados, mas já sofri com
alguns problemas do tipo: pergunte a um banco de dados quem é a
métrica de monitoração (e de onde ela vem) que mais ofende o nível de
serviço nos dias da semana no datacenter xyz, cuja taxa de ofensa
cresce dentro do intervalo de valores (l, m). Looks like hell! Se o
modelamento dos dados fosse feito com este tipo de pergunta em mente,
não seria um inferno tão quente saber disso. Mas o modelamento foi
feito com as métricas, servidores, datacenters e tudo o que não era
essa pergunta em mente. Todo caso, o relatório tem que responder à
pergunta!
Veja-se o OLAP, onde em geral as bases de dados relacionais não mandam
muit bem, já que os dados são normalizados (i.e. os dados diferentes
são armazenados em tabelas distintas, porém relacionadas, em suma,
dependendo de um join para o relacionamento na query -- é aquela
historia do Boyce-Codd Normal Form, onde cada determinante é candidato
a chave... vixi...), e a montagem do cubo acaba invariavelmente
estressando o I/O, já que estes artifícios da matemática relacional
demandam que muitas tabelas e linhas sofram lock, ou full scans e o
raio que o parta. E a forma da query então?
Então, estas bases denormalizadas (cheias de redundâncias a fim de
eliminar o relacionamento), apesar de não serem tão gerais quanto uma
base normalizada, podem ser mais bem adaptadas ao desing das queries
(isso mesmo, estas bases é que dão o drive das queries, já que a
generalidade do SQL cai por terra com este modelo). Nesse caso, é o
próprio desenho da base que vai formatar as queries, e é aí que vem a
vantagem do uso delas com OLAP, por exemplo. Como as queries são
feitas sem o peso da relacionamento (já que há redundância graças ao
desenho denormalizado), há um casamento conveniente com os appraches
mais eficientes para a montagem do cubo. É como se o caderno de
respostas tivesse que ser construído com as questões que serão
consultas em mente, ao contrário de dispor os dados da resposta com
índices, relacionamentos e artifícios capazes de relacionar dados nem
tão obviamente correlatos.
Pra concluir, se as perguntas do BI são conhecidas durante o desenho
(e geralmente são), tudo pode evoluir para que no fim, elas sejam
diretas em relação à base resultante. Isso demanda uma "reengenharia"
na metodologia de desenho e arquitetura de solução! E dá trabalho! Ah,
e tem mais: bases denormalizadas tendem a diminuir a esparsidão dos
dados, o que é vantajoso demais na hora de processar o cubo.
O grande problema (ainda) disso tudo, é que as bases nosql não tem
ferramentas que te ajudam na dernomalização. É na unha! Mas logo
alguém que precise muito disso, e meta a mão no código pinta com uma
ferramenta. Esse é o software livre :D
abraço
mauad
Mauricio Mauad Menegaz Filho
<mma...@gmail.com> escreveu:
> e tem mais: bases denormalizadas tendem a diminuir a esparsidão dos
> dados, o que é vantajoso demais na hora de processar o cubo.
Ooops... inventei uma palavra pra uma que já existia: não existe
esparsidão, e sim esparsidade :) Desculpem.
abraço
mauad
Fabio Olive Leite
On 2010-03-03 Mauricio Mauad Menegaz Filho wrote:
>
> Não sou especialista em bancos e estruturas de dados, ...
> [ HAHAHA ]
> ... Esse é o software livre :D
BINGO! Caramba Mauad, fechou uma cartela inteira aqui só num email
teu. :)
Brincadeiras à parte, essa thread toda tem sido muito instrutiva.
Obrigado pelas longas explicações. :)
Abraços!
Fábio Olivé
--
ex sed lex awk yacc, e pluribus unix, amem
na matemática das idéias, permuta é igual a adição
e um debate inteligente implementa a multiplicação
Mauricio Mauad Menegaz Filho
> Olá!
>
> On 2010-03-03 Mauricio Mauad Menegaz Filho wrote:
>>
>> Não sou especialista em bancos e estruturas de dados, ...
>> [ HAHAHA ]
>> ... Esse é o software livre :D
>
> BINGO! Caramba Mauad, fechou uma cartela inteira aqui só num email
> teu. :)
:p
>
> Brincadeiras à parte, essa thread toda tem sido muito instrutiva.
> Obrigado pelas longas explicações. :)
Bah, às vezes me passo mesmo, hehehehehe. O que me impede de escrever
mais é o dedo grosso nesse tecladinho mini do asus aspire :) Agora,
dando uma espiada nesse mundo de armazenamento de dados e tal (já que
é a base quem mais cria problemas pra mim -- um cara de infra), a
gente acaba descobrindo por que os DBAs são -- em média -- tão bem
remunerados! O negócio é cascudo! E se o sujeito for levar ao pé da
letra o sync entre teoria e prática, a cousa vai longe...
abração!
mauad
Leonardo Menezes Vaz
http://www.yafla.com/dforbes/Getting_Real_about_NoSQL_and_the_SQL_Isnt_Scalable_Lie/
Leo
Gustavo Ciello
Esse assunto me apetece, principalmente por ser uma das áreas que
menos recebe idéias malucas que "vão revolucionar o mundo" todos os
dias, como é o caso do desenvolvimento WEB de um tempo pra cá.
Queria escrever um artigo pra matar umas horas de Atividades Extras na
faculdade e sinto que achei um tema bom.
[]'s!
On 3 mar, 14:22, Leonardo Menezes Vaz <leonardo....@gmail.com> wrote:
> Mais um link interessante sobre o assunto:
>
> http://www.yafla.com/dforbes/Getting_Real_about_NoSQL_and_the_SQL_Isn...
>
> Leo
Mauricio Mauad Menegaz Filho
Em 4 de março de 2010 16:47, Gustavo Ciello <cie...@gmail.com> escreveu:
> Interessante o link Leo!
É legal mesmo! O cara fala realisticamente sobre a escalabilidade do
banco de dados, e reitera o que falamos aqui: noSQL não serve para
tudo.
Mas, seguindo pelo artigo dele, se dinheiro é problema (i.e Oracle RAC
nem pensar), e o hardware que tu tem pra trabalhar é meia dúzia de HP
Proliant ML 110 (P4 com 2Gb de RAM decente), tem que espremer mesmo
pra conseguir atender um número crescente de clientes com essa
infra...
>
> Esse assunto me apetece, principalmente por ser uma das áreas que
> menos recebe idéias malucas que "vão revolucionar o mundo" todos os
> dias, como é o caso do desenvolvimento WEB de um tempo pra cá.
É muito vero: não se vê muitas idéias revolucionárias em relação ao banco.
Mas, alto lá! O noSQL não é uma idéia maluca, e provavelmente não vai
revolucionar o mundo. Talvez o nome soe agressivo demais -- e muitos
usuários realmente detestem SQL. Aliás, conheço alguns (bons) DBA's
que detestam SQL! Particularmente até gosto do SQL, o que me indiguina
são os bancos mesmo! É um trabalinho inglório fazer ele caber legal
dentro da infra. O danado é I/O bound e CPU bound!
A idéia por trás do noSQL (grosso modo baseado em hashtables) é velha
-- o conceito apareceu em 1953! [1] -- , mais até que a base
relacional, que faz 40 anos em junho [2] (a referência traz o paper
original para download de graça!).
Ah, e quando escrever o artigo, se puder manda pra gente ler :)
Referências
[1] http://en.wikipedia.org/wiki/Hash_function#Origins_of_the_term
[2] http://portal.acm.org/citation.cfm?id=362685
abração
mauad
Leonardo Menezes Vaz
O Gleicon acabou de criar um grupo para falar sobre NoSQL:
http://groups.google.com/group/nosql-discussion-br
Quem tiver interesse de participar e trocar idéias sobre o assunto,
fica o convite.
Leo