SumrioIntroduo ..................................................................................................................................... 2 Parte 1 ........................................................................................................................................... 3 1. Problema ........................................................................................................................... 3 1.1. 1.2. 1.3. 1.4. Delimitao do Problema .......................................................................................... 3 Objetivos da Pesquisa ............................................................................................... 4 Justificativa ................................................................................................................ 4 Hipteses e variveis ................................................................................................. 5

Parte 2 ........................................................................................................................................... 9 2. Procedimentos Metodolgicos ......................................................................................... 9 2.1. 2.2. 3. 4. Delimitao do Universo ........................................................................................... 9 Pressupostos da Pesquisa ......................................................................................... 9

Referncias ...................................................................................................................... 22 Anexos ............................................................................................................................. 23 Exemplo de Implementao de um Sistema Simples Usando Um Banco de Dados Orientado a Grafos Neo4J ................................................................................................ 23

1

IntroduoCom o advento da web 2.0, vrias tendncias surgiram na web, e as redes scias explodiram. Com um nmero espantoso de usurios e contedo armazenar, o modelo relacional de banco de dados se torna um modelo invivel para as aplicaes. Com esse cenrio, e a busca por alternativas ao problema de gerenciar a grande quantidade de contedo, os bancos de dados no-relacionais, ou Bancos de dados NoSQL, se mostram uma tima alternativa, e tambm uma tima rea de pesquisa. A ideia mostrar como vivel e apropriado o uso desse tipo de banco de dados, para aplicaes que tem como objetivo a interao e integrao de contedo gerado por usurios, assim como integrao com redes sociais.

2

Parte 11. Problema 1.1. Delimitao do ProblemaModelo RelacionalIntroduo ao Modelo Relacional

O modelo relacional foi criado no incio dos anos 1970, e desde ento se tornaram o padro da indstria de softwares, e tm sido utilizados em larga escala por Sistemas Gerenciadores de Bancos de Dados. Ele se tornou padro, substituindo os modelos hierrquicos e de rede. Os exemplos mais comuns de bancos de dados relacionais so o SQL Server, o PostgreSQL, MySQL, entre outros. Os bancos de dados relacionais so estruturados atravs de tabelas, as quais por sua vez so compostas por linhas (ou tuplas) e colunas (ou atributos). O modelo relacional visa estruturar os dados seguindo esse modelo. Outra caracterstica desse modelo a utilizao de restries de integridade. As restries mais comuns so as chaves primrias, e chaves estrangeiras. As chaves primrias tm o objetivo de identificar unicamente uma tupla na tabela, enquanto uma chave estrangeira faz referncia uma dependncia de atributos, geralmente, em uma outra tabela. O modelo Relacional tem um processo de Normalizao, com o objetivo de garantir o projeto adequado de tabelas, separando os dados de elementos distintos em tabelas distintas, relacionando-as atravs de chaves. O modelo Relacional adotou como linguagem de definio, manipulao e consulta, a SQL (Structured Query Language).SQL Structured Query Language

Desenvolvida originalmente pela IBM, o SQL uma linguagem declarativa para bancos de dados relacionais, baseada na lgebra relacional. Sua simplicidade e alto poder de expresso a tornaram um padro, e tambm a linguagem de consulta de dados mais utilizada no mundo, ajudando a consolidar o domnio do Modelo Relacional. A simplicidade do SQL pode ser demonstrada utilizando-se um exemplo para selecionar todos os registros e seus respectivos atributos, dada uma tabela chamada ALUNO.SELECT * FROM ALUNO

Podemos ver a simplicidade do SQL ao utilizar condies para obter somente registros que atendem determinada condio, como por exemplo alunos que contm o texto ander no nome.SELECT * FROM ALUNO WHERE nome LIKE %ander%

3

Limitaes do Modelo Relacional

Devido ao intenso e acelerado crescimento do nmero de aplicaes, recursos e tudo o que tange sistemas computacionais, o volume de dados tambm cresceu de forma extraordinria, como por exemplo, o volume de dados do Google, que provavelmente j excede os Petabytes (1015 bytes). Em cenrios como esse, onde o gerenciamento do grande volume de dados necessrio, o Modelo Relacional se torna problemtico e ineficiente. De um modo geral, os principais problemas esto relacionados com a dificuldade de conciliar o modelo a demanda por escalabilidade.

1.2. Objetivos da PesquisaTemos por objetivo principal demonstrar como possvel e vivel o uso de bancos de dados no-relacionais, para solucionar os problemas do modelo relacional, e as novas necessidades que a web 2.0 trouxe.

1.3. JustificativaO movimento NoSQL prope solues que parecem ser a melhor opo para resolver os problemas apresentados, como listado nos tpicos abaixo. Modelo No RelacionalBuscando uma soluo para a problemtica do Modelo Relacional

A estrutura utilizada pelos modelos relacionais, considerado uma soluo at ento, passou ento a ser um problema a ser contornado, e logo as solues propostas tinham como objetivo flexibilizar essa estrutura. Vrias solues apresentadas pareciam regredir ao simples gerenciamento de arquivos. Por uma lado as solues perdiam grande parte das regras de consistncia presentes no Modelo Relacional, porm tinham a vantagem de ganhar em performance, tornando flexveis os sistemas de bancos de dados, para atender as necessidades de cada companhia.NoSQL Not Only Structured Query Language

O termo NoSQL foi utilizado pela primeira vez em 1998 por Carlo Strozzi, fazendo referncia ao seu projeto de um banco de dados de cdigo aberto, que ainda utilizava um modelo relacional, porm no possua interface SQL. Ainda de acordo com Carlo Strozzi, o movimento NoSQL " completamente distinto do modelo relacional e, portanto, deveria ser mais apropriadamente chamado 'NoREL' ou algo que produzisse o mesmo efeito". Posteriormente em 2009, foi utilizado por Eric Evans, em um evento organizado pela Last.fm para discutir bancos de dados open source distribudos. Desde ento passou a ser utilizado para representar solues onde o Modelo Relacional no 4

apresenta performance adequada. O propsito do NoSQL portanto, no substituir o modelo relacional como um todo, mas sim quando necessria uma maior flexibilidade do banco, para grande volumes de dados, necessidade de escalabilidade, necessidade de respostas mais rpidas dos aplicativos, entre outros.O Surgimento de implantaes NoSQL

Uma das primeiras implementaes de um sistema no-relacional, que teve um papel muito importante na exploso do movimento NoSQL, surgiu em 2004 quando o Google lanou o Google BigTable, um banco de dados proprietrio, de alta performance, com o objetivo de fornecer maior escalabilidade e disponibilidade. Vrios projetos da Google utilizam esse sistema, como por exemplo, o Google Web Indexing (Sistema de indexao do Google), Google Earth, entre outros, demonstrando o poder do sistema. Outra importante implementao foi realizada em 2007 pela Amazon. Denominado Dynamo, a implementao da Amazon tinha como caracterstica bsica ser um banco de dados no-relacional de alta disponibilidade, utilizado pelos web services da Amazon. Outros grandes nomes que tem importante participao no movimento NoSQL so: Yahoo: Hadoop com HBase e Sherpa Hadoop um framework para processamento de dados em larga escala, que se utiliza do paradigma de programao Map Reduce para realizar computao distribuda em clusters contendo centenas e at milhares de mquinas. HBase o banco de dados que est por trs desse poderoso framework. Facebook e Digg: Cassandra Projetado para ser um banco de dados de alta disponibilidade para lidar com grandes volumes de dados. No incio de 2010 desbancou o MySQL como banco de dados do Twitter. LinkedIn: Voldemort Projetado pelo LinkedIn para resolver problemas de altaescalabilidade. Engine Yard: MongoDB Banco de dados orientado documentos, que prov alta-escalabilidade, alta performance, entre outros atributos. Twitter: FlockDB Banco de dados orientado grafos distribudo, de alta performance, e tolerante falhas. Apache: CouchDB Banco de dados orientado documentos, que busca replicao e estabilidade horizontal.

1.4. Hipteses e variveisTemos por hiptese ento que os sistemas de bancos de dados no-relacionais, podem ser a soluo para os problemas encontrado, porm ainda existem vrios tipos de 5

bancos de dados serem considerados, e ainda algumas limitaes e mitos que surgem em toda tecnologia emergente, como mostrado nos tpicos abaixo.Classificao dos Bancos de Dados NoSQL

No que tange classificao dos bancos de dados NoSQL, utilizaremos 3 caractersticas principais: Arquitetura: Distribuidos / No Distribudos; Armazenamento: Memria / Disco / Configurvel; Modelo de Dados: Chave-Valor(Key-value) / Documento / Colunas / Grafo

Arquitetura Distribudos

Os distribudos tomam a responsabilidade pela partio dos dados e pela sua replicao. Exemplos: Amazon; Voldemort; BigTable; Cassandra;

No-Distribudos

Os bancos no-distribudos deixam a responsabilidade pela partio dos dados e sua replicao com o usurio. Exemplos: MemCacheDB; Neo4j; Amazon SimpleDB.

Armazenamento

Os bancos podem ser divididos tambm, entre aqueles que guardam os dados diretamente no disco, e os que armazenam na memria.Memria

Exemplos: Disco

Scalaris; Reddis. Exemplos:

CouchDB; MongoDB; 6

Neo4j. Exemplos:

Configurvel

BigTable; Cassandra; HBase.

Modelo de dados

Nessa classificao, os bancos de dados so separados pelo seu ncleo, ou seja, como ele trabalha com os seus dados.Chave-valor

Esse o tipo de banco de dados NoSQL mais simples, os seus conceitos so uma chave e um valor para essa chave. Esses tipos de bancos de dados so o que fornecem maior escalabilidade. Exemplos: Dynamo; Voldemort.

Documento

Baseado em documentos XML ou JSON, podem ser localizados pelo seu id nico ou por qualquer registro que tenha no documento. Exemplos: CouchDB; MongoDB.

Documento

Fortemente inspirados pelo BigTable, do Google, eles suportam vrias linhas e colunas, alm de permitir subcolunas. Exemplos: Grafo

BigTable; HBase; Cassandra.

Com uma complexibilidade maior, esses bancos de dados guardam objetos, e no registros como os outros tipos de NoSQL. A busca desses itens feita pela navegao desses objetos. Exemplos:

7

HyperGraphDB; FlockDB; Neo4j.

Mitos Sobre o NoSQL

Toda tecnologia emergente, passa por um grande processo de hype, e muitas vezes ficam conhecidas como buzzwords. Esse fato se deve ao uso indiscriminado de tais tecnologias, e tambm ao fato de acharem que acharam a to falada silver bullet, ou bala de prata. Mas como em desenvolvimento, no existe bala de prata, vamos listar alguns mitos gerados em torno dos bancos NoSQLNoSQL escalvel

Uma das grandes promessas dos bancos NOSQL consiste em dizer que eles so mais escalveis que os bancos de dados relacionais. O problema com esta mensagem que vendida por algumas empresas que ela no inteiramente verdade. Dizer que seu sistema escala sozinho vender um sonho. Ele pode at ser mais fcil de escalar se comparado a outras solues, mas ainda sim exigir algum esforo para escalar, e escalar de forma eficiente.No precisamos de DBAs

No mundo dos bancos relacionais a figura do DBA (DataBase Administrator) sempre est presente. Com sistemas que tem particularidades para cada fornecedor, os DBAs ficam a cargo de instalar, configurar e manter cada banco de dados em suas particularidades. Muita gente diz que quando se trabalha com NoSQL no precisamos de DBAs. Talvez no no sentido tradicional, mas ainda vamos precisar de algum responsvel por lidar com o banco e com o acesso aos dados. Esta funo pode vir a se tornar parte do trabalho de um desenvolvedor ou se tornar a funo full time de algum no seu time que pode ser at um DBA com conhecimentos em NoSQL. Em aplicaes reais em produo muito provavelmente ser necessrio misturar bancos relacionais e no relacionais, possuir algum que navegue facilmente nos dois mundos em seu time uma grande vantagem.NoSQL mais econmico

Meia verdade. Muitos fornecedores de NoSQL afirmam que suas solues vo baratear o custo dos seus clientes. Em parte sim, em algumas situaes o custo em usar um banco de dados relacional pode ser proibitivo devido escala, ou a licenas envolvidas. Existem muitos casos, entretanto, em que uma soluo relacional atende perfeitamente todas as necessidades do cliente e ainda sim pode ser considerada barata. Bancos de dados Open Source como MySQL e PosgreSQL so usados sem problemas por um grande nmero de aplicaes, e com sucesso.

8

Parte 22. Procedimentos Metodolgicos 2.1. Delimitao do UniversoNossa pesquisa foi baseada em casos reais, e em aplicaes de grande uso social e que apresentavam grandes problemas antes das solues NoSQL.

2.2. Pressupostos da PesquisaProcuramos demonstrar atravs de casos reais, como o uso da tecnologia de bancos de dados no-relacionais solucionou problemas que surgiram com o crescimento da internet, e demanda de dados. Apresentamos tambm como uma tecnologia baseada em grafos, solucionou o problema de uma das maiores redes sociais do mundo, o Twitter.

Estudos de Caso Abaixo citaremos alguns casos de usos, postados na ntegra, encontrados na Internet. Um deles o caso do Twitter com FlockDB, e o outro com uma soluo para um produto brasileiro, o BooBox.Twitter

O Twitter armazenda vrios grafos de relaes entre pessoas: Quem voc esta seguindo, quem est seguindo voc, entre outros. Algumas das caractersticas desses grafos, tem se mostrado verdadeiros desafios em se encontrar uma forma escalvel medida que crescem. Para completar um tweet, necessrio buscar por todos os seguidores, e paginlos rapidamente. Alm disso, necessrio gerenciar um grande trfego de escritas, como adicionar e remover seguidores. Algumas dessas operaes necessitam de certa aritmtica. Essas necessidades so difceis de implementar usando um banco de dados relacional tradicionalUm corajoso esforo

Depois de vrias tentativas com o uso abusivo de tabelas relacionais, e armazenamento de listas chave-valor. Essas tentativas eram boas em gerenciar operaes de escritas, ou boas para paginar resultados gigantes, mas nunca para os dois. Na tentativa de resolver esses problemas, surgiu a necessidade de tentar algo novo, e esses eram os objetivos: Escrever as coisas mais simples para que possam funcionar; 9

Usar o sistema off-the-shelf MySQL como sistema de armazenamento, devido ao domnio da tecnologia, e benefcios que a mesma oferece; Permitir escalonamento horizontal, para poder adicionar mais recursos, medida que a necessidade aumentar; Permitir operaes de escritas sem uma ordem pr-determinada, ou processar vrias vezes. FlockDB foi a soluo desenvolvida para solucionar essa problemtica.

O Resultado do Esforo

FlockDB um banco de dados que armazena grafos, mas que no otimizado para operaes de caminhar no grfico. Em contra-partida, ele otimizado para grandes listas de adjacncia, rpidas operaes de leitura/escrita, e conjuntos de consultas aritmticas paginveis. Ele armazena os grafos como conjuntos de arestas entre ns indentificados por inteiros de 64bits. Para um grafo de rede social, os IDs dos ns seriam usados como os IDs dos usurios, para um grafo de tweets favoritos, os IDs dos ns podem ser os IDs dos tweets.

Quando uma aresta deletada, a linha no realmente deletada do MySQL, ao invs disso, ela marcada com um estado de Deletado e armazenado com uma chave composta do ID, estado e posio, permitindo que seja restaurado posteriormente. Este tipo de otimizao, permite que o MySQL trabalhe de forma extremamente eficiente, provendo uma tima performance.Experimente

O flockDB atualmente um banco de dados de cdigo aberto, que pode ser obtido no repositrio github: http:github.com/twitter/flockdb.

Boo-Box

Esse um caso real, que aconteceu com o produto boo-box, um sistema de publicidades para mdias sociais, onde um banco de dados NoSQL, foi a soluo. Abaixo segue o artigo da autoria de Felipe Vieira, Consultor de Tecnologia e Scrum Master na boo-box, que foi publicado na iMasters. O link se encontra na seo de referncias. 10

Trabalho na boo-box e temos uma experincia bem interessante com bancos de dados NoSQL. Os cases abaixo foram apresentados no The Developer's Conference 2010 e so exemplos reais de como utilizamos o Redis em nosso sistema de tecnologia para exibio de anncios em mltiplos websites. Compartilhar estas solues uma das maneiras de agradecer comunidade de desenvolvedores por usarmos software livre, difundir o conhecimento criado na empresa e melhorar nossa prpria ferramenta. Bancos NoSQL, entende-se "Not only SQL", surgiram da necessidade de escalar bancos de dados relacionais com propriedades ACID em projetos web de alta disponibilidade que operam em larga escala. Suas principais caractersticas so alta performance, escalabilidade, fcil replicao e suporte a dados estruturados. Este rompimento com os padres SQL causa sempre grande repercusso e muitas discusses carregadas de sentimentos e emoes, mas a verdade que os bancos de dados relacionais ainda servem para resolver muitos problemas que nem sempre (veja bem, nem sempre) podero ser resolvidos com bancos NoSQL, como por exemplo: 1. Necessidade de forte consistncia de dados, tipagem bem definida, etc; 2. Pesquisas complexas que exigem um modelo relacional dos dados para realizaes de instrues e operaes de juno, por exemplo; 3. Dados que excedam a disponibilidade de memria do servidor, por mais que possamos utilizar swap, ningum quer prejudicar a performance neste caso. Ao escolher seu banco de dados, o importante considerar as funes e caractersticas especficas do sistema. Os bancos de dados NoSQL podem ser utilizados especialmente para funes descritas neste artigo. Vamos, aqui, abordar particulamente a nossa experincia com o Redis.Sobre o banco de dados NoSQL Redis

O NoSQL Redis, que atualmente est na verso 2.0.1, definido como advanced key-value store. Seu cdigo escrito em C sob a licena BSD e funciona em praticamente todos sistemas POSIX, como Linux ou Mac OS X. Ele foi idealizado e executado por @antirez para escalar o sistema da empresa LLOOGG. Hoje o repsitrio mantido por uma imensa comunidade e patrocinado pela VMWARE. A simplicidade de operar um banco apenas setando o valor e uma chave continua, entretanto, diferente de solues famosas como o memcached, podemos fazer diversas operaes na camada das chaves, alm de contar com um punhado de estruturas de dados. Alm de salvar strings na memria, tambm possvel trabalhar com conjuntos, listas, ranks e nmeros. De maneira atmica, pode-se fazer operaes de unio, interseco e diferenas entre conjuntos, alm de trabalhar com filas, adicionando e removendo elementos de maneira organizada. 11

Assim como outros bancos NoSQL este projeto completamente comprometido com velocidade, pouco uso de recursos, segurana e opes de configuraes triviais para ganhos de escalabilidade. Para manter a velocidade dos dados com garantia de persistncia, de tempos em tempos (ou a cada n mudanas) as alteraes so replicadas, de maneira assncrona, da memria RAM para o disco. Agora, vamos aos cases. Dentro de tantas possibilidades, mostraremos algumas solues do sistema boo-box utilizando o Redis.Armazenamento de sesses de usurios

Este um modelo muito simples de como utilizar o Redis para salvar as informaes da sesso de um usurio. Para cada sesso, gera-se uma chave que gravada no cookie do navegador. Com essa chave, o sistema tem acesso a um hash com informaes desta sesso: status do login, produtos e publicidades clicadas, preferncias de idioma e outras configuraes temporais, que perdem a validade aps algumas horas. O benefcio de no guardar tais informaes de sesso diretamente no cookie evidente: ganhamos a segurana de integridade dos dados, no correndo o risco de algum usurio malicioso modific-los. Com o Redis, utilizamos operaes simples de get/set para acessar estes dados diretamente da memria do servidor (ou servidores, caso exista mais de um), sem desperdcio de recursos, graas ao eficiente sistema de expirao promovida por este NoSQL. O algoritmo de expirao no monitora 100% das chaves que podem expirar. Assim como a maioria dos sistemas de cache as chaves so expiradas quando algum cliente tenta acess-la. Se a chave estiver expirada o valor no retornado e o registro removido do banco. Em bancos que gravam muitos dados que perdem a validade com o tempo, como neste exemplo, algumas chaves nunca seriam acessadas novamente consequentemente elas nunca seriam removidas. Essas chaves precisam ser removidas de alguma maneira, ento a cada segundo o Redis testa um conjunto randmico de chaves que possam estar expiradas. O algoritmo simples, a cada execuo:Testa 100 chaves com expirao setada. Deleta todas as chaves expiradas. Se mais de 25 chaves forem invlidas o algoritmo recomea do 1.

Essa lgica probabilstica continua a expirar at que o nosso conjunto de keys vlidas seja prximo de 75% dos registros.Cache de produtos de terceiros

Todo dia a boo-box exibe para a audincia milhes de produtos - de diferentes ecommerces - vinculados ao contedo de publishers. Os e-commerces fornecem APIs, e atravs delas possvel buscar produtos para serem mostrados em nossas vitrines.

12

Num modelo ideal, cada requisio de uma vitrine boo-box faria contato com as APIs dos e-commerces parceiros, em busca de produtos compatveis com o contedo em questo. Mas no mundo real da publicidade online, velocidade e escalabilidade so premissas essenciais para a qualidade de produto e, portanto, requisies sncronas a tais APIs tornariam o processamento lento demais. Portanto, essas operaes so cacheadas num banco Redis. Separamos os ecommerces em bancos distintos e obtemos os produtos segundo a keyword que foi utilizada nas buscas de todas as vitrines da rede boo-box.

Figura 1 - Execuo do cache de produtos quando h resultados para a tag solicitada.

Porm, sempre existe aquele usurio com poucos acessos e com tags que no so to populares. Neste caso, tentamos fazer a consulta diretamente da API (com um tempo limite pequeno para no complicar o sistema). Caso no encontremos nenhum produto para esta tag, podemos, como j foi dito acima, buscar chaves similares para mostrar nas vitrines deste Publisher, enquanto um evento paralelo acionado para adicionar esta tag no cache sem restries de tempo. Assim, em uma prxima visualizao, os produtos j estaro quentinhos no cache! Veja como esse luxo pode ser ilustrado:

13

Figura 2 - Quando no havia resultados para a tag solicitada, buscvamos os produtos na API, entregvamos ao usurio e gravvamos os resultados no cache.

A separao de e-commerce em bancos distintos facilita as operaes de busca por keywords. O Redis, por padro habilita 16 bancos que podem ser utilizados separadamente e, por consequncia, escalados separadamente. Com as keys de um ecommerce isoladas, podemos busc-las atravs de padres parecidos com regexp e, com sabedoria, isso pode ser um excelente recurso, mas tambm pode ser um problema tendo em vista que a complexidade desta funo O(n) onde n o numero de chaves no banco utilizado. Diagrama de sequncia dessa funcionalidade:

14

Figura 3 - Diagrama de sequncia dessa funcionalidade

Quando no h resultados para a tag solicitada no cache de produtos, exibimos produtos similares, depois buscamos pelos produtos exatos no e-commerce e os entregamos diretamente do cache na prxima solicitao. Veja os logs dessa funcionalidade em ao:merb : worker (port XXXX) ~ DEBUG get similar keys from redis the_velvet_underground instead underground 0.012 merb : worker (port XXXX) ~ DEBUG get similar keys from redis pushing_daisies instead push 0.012 merb : worker (port XXXX) ~ DEBUG get similar keys from redis deborah_secco instead deborah 0.017 merb : worker (port XXXX) ~ DEBUG get similar keys from redis oracoes_catolicas instead catolica 0.017 merb : worker (port XXXX) ~ DEBUG get similar keys from redis uma_linda_mulher instead linda 0.012 merb : worker (port XXXX) ~ DEBUG get similar keys from redis lutaram instead lutar 0.016 merb : worker (port XXXX) ~ DEBUG get similar keys from redis videogame_wii instead videogame 0.017 merb : worker (port XXXX) ~ DEBUG get similar keys from redis mini_craque_prostars instead craque 0.017 merb : worker (port XXXX) ~ DEBUG get similar keys from redis apple_ipod_shuffle_1_gb_silver instead apple 0.005 merb : worker (port XXXX) ~ DEBUG get similar keys from redis motocultivador_tratorito_branco_diesel instead motocultivador using using using using using using using using using using 0.017

15

merb : worker (port XXXX) ~ DEBUG get similar keys from redis using suporte_para_bicicleta_automovel instead automovel 0.005

Esse cache muito custoso e no remontado com facilidade. Portanto, assim como a primeira soluo, alm da velocidade a persistncia dos dados em disco imprescindvel. A expirao, neste caso, tambm muito importante, pois mudanas nos catlogos ou nos preos do produto acontecem com frequncia. Mesmo com uma expirao curta, no interessante esperar que produtos populares como videogames, celulares e afins saiam do cache. Para evitar isto, consultamos, a cada requisio, o tempo de vida restante deste produto no cache. Caso ele esteja prximo de expirar, um evento assncrono acionado para atualizar este produto na API do e-commerce em questo. Na apresentao Usando Redis para otimizar o sistema boo-box, feita na Campus Party Brasil 2010, mostramos detalhes deste fluxo. Os resultados desta soluo foram supreendentes como mostram as imagens abaixo. Uma queda no tempo de resposta de parte do sistema, uma economia insana de recursos que levou ao desligamentos de servidores e reduo de perfil de mquinas, assim como a melhoria da manutenibilidade do processo todo.

Tempo de resposta do sistema:

Mais velocidade no sistema aps a implementao do Cache de Produtos:

16

Todo dia a boo-box exibe milhes (milhes!) de produtos de diversos ecommerces. Com o Redis cacheamos tudo com apenas 300 MB de RAM.Busca em catlogos de produtos de terceiros

Algumas vezes temos acesso a um catlogos de produtos de um e-commerce por meio de um arquivo XML. Diariamente, este arquivo atualizado pelo parceiro, parseado e salvo no Redis do sistema boo-box. Alm de armazenados, esses produtos so tambm organizados para a realizao de consultas. Modelar NoSQL um pouco diferente do que modelar bancos relacionais. No existem joins ou queries complexas, a estrutura organizada para a pesquisa que deve ser feita. Vamos a um exemplo prtico: Supondo que o e-commerce disponibilize o seu catlogo de produtos em um arquivo XML que tem a estrutura abaixo: G28T49200F2 Quintette Du Hot Club De France DJANGO REINHARDT 51,90 CD Quintette Du Hot Club De Frace 1938-1939 - Importado Appel Indirect;Billets Doux;Japanese Sandman;Three Little Words;Stompin at Decca;Souvenirs;Sweet Georgia Brown;Tornerai (Jattendrai);If I Had You;It Had to Be You;Nocturne;Black and White;Night and Day;Honeysuckle Rose;Swing;I Wonder Where My Baby is Tonight;Why Shouldnt I?;Them There Eyes http:www.ecomm.com.br/imgs/cds/cover/img2/284922.jpg http:www.ecomm.com.br/produto/2/284922/ Musica

17

Dado que o campo "cod" uma referncia nica para este produto neste catlogo, poderamos transform-lo em chave e salvar um hash com todas as propriedades do produto, como mostra o cdigo abaixo:catalogo_xml.each do |product_xml| # Uma vez que transformamos o xml do produto em um hash... product = parser_to_hash(product_xml) # Para cada identificador cod salvamos todas as # informaes deste produto redis[:product].set(product[:cod], Marshal::dump(product)) end

Bonito e intil! Ter um hash referenciado por um id a princpio no ajudaria a fazer buscas, entretanto esse ser o nosso banco principal que guardar todas as informaes dos produtos. Se pensarmos em como indexar estes produtos por uma busca mais trivial (por exemplo, nome) devemos criar um novo banco e teramos que alterar o nossa funo de parser para organizar estes produtos ou melhorar suas chaves por nome:catalogo_xml.each do |product_xml| # Uma vez que transformamos o xml do produto em um hash... product = parser_to_hash(product_xml) # Para cada identificador cod salvamos todas as # informaes deste produto redis[:product].set(product[:cod], Marshal::dump(product)) # Para cada nome (que pode ser repetido no catalogo) # adicionamos o cod deste produto em uma estrutura de lista redis[:name].addmember(slugfy(product[:nome]), product[:cod]) end

A funo slugfy foi utilizada para evitar que a mesma palavra seja tratada diferentemente por conta de caracteres de acento ou em caixa alta. Esse um ponto crucial que pode aumentar muito a contextualizao da busca. Muitos algoritmos lingusticos podem ser teis neste caso, mas voltando ao ponto deste case, um mtodo simples de busca para essa indexao seria:def search(keyword) keyword = slugfy(keyword.to_s) return [] if keyword.empty? names = redis.keys("*" + name + "*") cods = redis[:name].union(names.join(" ")) products = [] cods.each do |cod| products Item item = (ItemDAO.instancia.busque(it)) ?: it ItemDAO.instancia.insira(item) Node noItem = baseDeDados.buscaNoPorId(item.id) node.createRelationshipTo(noItem, contemItem) } } protected Object monteObjetoComNo(Node node) { Venda venda = new Venda() venda.id = node.nodeId node.getRelationships(vendidoPara).each { venda.cliente = ClienteDAO.instancia.monteObjetoComNo(baseDeDados.buscaNoPorId(it.endN ode.id)) } node.getRelationships(vendidoPor).each { venda.vendedor = FuncionarioDAO.instancia.monteObjetoComNo(baseDeDados.buscaNoPorId(it. endNode.id)) } venda.itens = [] node.getRelationships(contemItem).each { venda.itens += ItemDAO.instancia.monteObjetoComNo(baseDeDados.buscaNoPorId(it.endNode .id)) } return venda } protected List obtenhaParamsDeBusca(Object objetoPersistente) { String textoDeBusca = '' String separador = ' && ' textoDeBusca += (objetoPersistente.id) ? 'id:' + objetoPersistente.id : '' textoDeBusca += objetoPersistente.data ? separador + DataUtils.convertaDate(objetoPersistente.data) : '' List argumentosDeBusca = textoDeBusca.split(separador) if (objetoPersistente.cliente) argumentosDeBusca.addAll ClienteDAO.instancia.obtenhaParamsDeBusca(objetoPersistente.cliente) if (objetoPersistente.vendedor) argumentosDeBusca.addAll FuncionarioDAO.instancia.obtenhaParamsDeBusca(objetoPersistente.vended or) objetoPersistente.itens?.each { argumentosDeBusca.addAll ItemDAO.instancia.obtenhaParamsDeBusca(it) }

44

argumentosDeBusca.remove('') return argumentosDeBusca } }

45