[SP-pm] [OT] NoSQL

[Thiago Rondon]

Pessoal,

Cometi um erro gravíssimo aí embaixo... Não é gráficos, e sim grafos.

E aproveitando, segue mais um ... http://github.com/twitter/flockdb

-Thiago Rondon

Em 01/06/10 20:06, Thiago Rondon escreveu:
> Segue minha opnião sobre ....
>
> O movimento Not Only SQL é muito interessante no meu ponto de vista 
> técnico, pois hoje possuímos mais alternativas na hora de estudar uma 
> determinada implementação em relação aos dados. Não vou entrar no 
> mérito sobre questões polemicas relacionadas as escolhas de cada 
> desenvolvedor.
>
> Porém aqui na Aware, estamos com experiências ótimas relacionadas a 
> esta gama de banco de dados alternativos que vem surgindo e cada vez 
> mais me interessam, principalmente em casos de análises comparativas, 
> escalabilidade, performance e replicação.
>
> Eu considero que este movimento, existam alguns bancos de dados 
> interessantes que podem ser classificados nas seguintes "categorias" 
> de modo "geral":
>
> * Chave/Valor:
> São utilizados principalmente para escalabilidade de dados, no geral é 
> os que você vai utilizar para evitar problemas relacionado a demoras 
> de análises constantes no teu cenário, e etc, etc.
>
> Me parece que os mais utilizados são: Oracle Berkeley DB (no mundo 
> corporativo), memcache, redis, ...
>
> Porém para quem tiver curiosidade, eu recomendo muito a leitura do 
> projeto "Voldemort": http://project-voldemort.com/.
>
> * Documentos:
> Lembram do Lotus Notes ? Modelo K-V. Estas são muito interessantes de 
> serem utilizados quando você mantem bancos de dados em XML ou JSON por 
> exemplo, onde na grande maioria existe uma 'metodologia' no qual você 
> tem um ID (K) no qual contém todas as entidades/atributos (V) que você 
> desejar.
>
> Este é um caso muito interessante onde você realmente irá armazenar 
> documentos, e necessita de uma flexibilidade constante, no qual uma 
> modelagem SQL (como um EAV) irá gerar muitos obstáculos de 
> desenvolvimento e manutenção.
>
> Obs.: Talvez este tipo seja o mais polemico, pois muitos DBAs 
> acreditam que alguns desenvolvedores não vão saber encaixar nos casos 
> que podem ser usados, irão usar para tudo.  @$%@#%@!!
>
> Talvez os mais usados sejam : CouchDB e o MongoDB.
>
> Para os curiosos, a documentação do Riak (outra alternativa) é ótima: 
> http://riak.basho.com/
>
> * "Colunas":
> Este é o tipo de banco de dados que vem me chamando mais atenção em 
> relação a organização de informação, e não em performance, 
> principalmente para elaboração de análises comparativas...
>
> O mais usado me parece que é o Vertica (http://www.vertica.com/). O 
> LucidDB que é bem "comunitário", o InfoBright que é uma empresa que 
> trabalha com análises, bancos OLAT e etc... e o MonetDB.
>
> * "Gráficos":
> Para estes: objetos são diferentes de registros, baseado em estruturas 
> de nós, K-V em ambos, e etc, etc.
>
> O fator mais interessante neste tipo de banco de dados, é o 
> relacionamento entre os nós..  Montar uma matrix de informação aqui é 
> muito trivial, por exemplo em relacionamento de redes sociais...
>
> Como eu comentei sobre os bancos baseados em documento, aqui também 
> não há necessidade de um schema fixo, no qual isto facilita a 
> manutenção e a evolução da sua aplicação no qual é baseado em 
> informações "matrix" por exemplo....
>
> VertexDB, e talvez o mais conhecido no momento "Neo4j".
>
> * "BIGs clones"
> Inspirados no BigTable paper, alguns sugiram com o HBase, Hypertable, ...
>
> * Minha conclusão.
>
> Agora, a explicação destas tendencias é um pouco obvia, mas vou falar:
>
> 1. Aumento dos bancos de informações em praticamente todos os cenários.
> 2. O modelo de apps agora é baseado em grande número de conexões 
> simultâneas.
> 3. A generalização de modelo de dados está ficando complicada de se 
> manter em muitos cenários.
>
> Como eu tentei colocar, estes bancos que estão surgindo não são 
> concorrência e em muitos casos nem alternativas para o modelo RDBMS, o 
> interessante que estes bancos oferecem para você uma flexibilidade 
> para poder tratar mais usuários, de forma mais rápida e simples.
>
> Na minha humilde opinião, *em muitos casos* é essencial você ter um 
> banco de dados relacional por trás das informações da sua organização, 
> porém com estas alternativas você pode criar uma linguagem uniforme no 
> seu aplicativo para poder suportar mais alternativas para armazenar 
> dados, seja ela para elaborar análises, melhorar a performance, ou 
> guardar informações que não necessitam sempre serem ajustadas.
>
> Meus centavos,
> -Thiago Rondon
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>
>