Image Image Image Image Image
Scroll to Top

Topo

NoSQL

28

mar
2012

Sem Comentários

Em Blog
NoSQL

Por Allison

Um olhar sobre alguns bancos de dados NoSQL

Em 28, mar 2012 | Sem Comentários | Em Blog, NoSQL | Por Allison

Fonte: Mikayel Vardanyan/IMasters

Texto original disponível em http://blog.monitis.com/index.php/2011/06/06/a-look-at-some-nosql-databases-mongodb-redis-and-basho-riak/

Em um artigo anterior, falei sobre o NoSQL e algumas ferramentas para serem usadas com ele. Neste artigo, daremos uma olhada no MongoDB, no Redis e no Riak.

O MongoDB combina o melhor dos armazenamentos chave-valor, documentos de bancos de dados, bancos de dados (ou database?) de objeto e sistemas de gerenciamento de bancos de dados relacionais (RDBMS). Isso significa que o MogoDB executa o sharding automaticamente (como com armazenamentos chave-valor), permite documentos de schema dinâmicos baseados em JSON, e oferece uma rica linguagem de query na forma de RDBMS. Além disso, o MongoDB oferece auto-sharding (o sharding de dados novos e pré-existentes é feito automaticamente) e um recurso de implementação MapReduce.

Dê uma olhada mais de perto no cluster MongoDB, e você verá que ele é feito de vários tipos de servidores:

  • Servidores shard que armazenam dados
  • Servidores de configuração que armazenam a configuração
  • Servidores router que recebem e roteiam as solicitações
  • Uma thread de servidor usando MapReduce

Alguns fatos adicionais sobre MongoDB: é uma ferramenta de armazenagem distribuída orientada a documentos e usa a linguagem de implementação C++. Com o progresso do schema, documentos do tipo JSON são armazenados, e schemas dinâmicos podem ser usados. Entre as companhias que usam o MongoDB encontramos: Shutterfly, Evite e The New York Times. Impressionante! Uma das coisas bacanas das quais gosto a respeito desse produto é a existência de uma interface web bastante boa, que permite testar o MongoDB em seu browser – mas usando uma shell JavaScript.

O Redis não é um simples armazenamento chave-valor, porque suporta uma variedade de valores em diferentes estruturas de dados, tais como listas e conjuntos de binary-safe strings, bem como conjuntos ordenados, que contêm uma pontuação de números float. No ano passado, o VMWare se tornou patrocinador do Redis.

Ele possui uma orientação chave-valor, e sua linguagem de implementação é ANSI C. Entretanto, o Redis não é distribuído. Sob seu schema, Redis oferece um armazenamento chave-valor, usando um nome-chave de servidor para armazenar e recuperar valores. Como MongoDB, o Redis tem uma lista impressionante de clientes – incluindo Python, Twisted Python e a nova linguagem do Google, Go. O Redis é open source, e há uma página muito bacana que oferece um tutorial Redis que permite experimentá-lo diretamente de seu browser usando JavaScript. Descubra-a em http://try.redis-db.com.

Riak é um banco de dados híbrido fabricado pela BashoTecnologies, mas é baseado no Amazon Dynamo. Funciona como um banco de dados (tradução de database?) orientado para documentos, e também com um armazenamento chave-valor distribuído. É tolerante a falhas e faz escalas linearmente. É direcionado para uso em aplicativos web. Como o Cassandra, não tem um controlador central, e assim não tem um ponto único de falhas.

O Riak é um armazenamento de chaves/valor plenamente distribuído, e implementa o MapReduce.

O design do Riak inclui três elementos básicos: buckets, chaves e valores. Os dados são organizados em buckets, que são pouco mais do que flat namespaces para agrupar logicamente pares chave/valor. Os buckets podem armazenar os dados diretamente ou através de links para outro bucket. Todos os nós no cluster têm o mesmo papel. O sharding de dados (existentes ou novos) é feito automaticamente entre os nós.

O Riak vem tanto em versão comercial quanto em versão open source. Roda em Unix, mas não em sistemas Windows. Ele é distribuído, um sistema tanto de documento quanto de armazenamento chave-valor, e sua linguagem de implementação é Erland, juntamente como alguma coisa de C e de JavaScript.

O Riak tem uma estrutura simples e não usa tipos de dados específicos. Os valores associados às chaves são objetos. O Riak interage com clientes via JSON sobre a interface HTTP; tem drivers para Erlang, Python, Java, PHP, JavaScript e Ruby; e, finalmente, uma interface de cliente que suporta o Protocol Buffers, do Google. A base de clientes do Riak inclui a Comcast.

Tags | , , , ,

01

fev
2012

Sem Comentários

Em Blog
Dados
NoSQL

Por Allison

DynamoDB da Amazon: NoSQL na nuvem por preços módicos

Em 01, fev 2012 | Sem Comentários | Em Blog, Dados, NoSQL | Por Allison

Fonte: Postado por JP Morgenthal/traduzido por Eder Ignatowicz/InfoQ

A Amazon lançou o DynamoDB, apresentado por Werner Vogels, CTO do AWS, em seu blog como uma base de dados NoSQL projetada para aplicações de internet. Esses serviços de banco de dados do AWS oferecem armazenamento com preço razoável e alta disponibilidade (graças à arquitetura de alto desempenho baseada em discos de estado sólido, ou SSD). O serviço introduz um novo concorrente ao universo em expansão de provedores NoSQL em nuvem, que inclui o Cloudant e o MongoHQ, por exemplo.

Com custo de um dólar por mês por gigabyte de discos SSD gerenciados, o AWS apresenta-se como um forte concorrente para outras soluções de gerenciamento NoSQL. Além disso, diferencia-se pela oferta de diversos outros serviços integrados ao DynamoDB, que pode ser uma vantagem se comparado com a utilização de múltiplos fornecedores de serviços diferentes.

Mas qual seria o potencial desse serviço? Pode-se ter uma ideia fazendo uma busca simples no Google por “Managed NoSQL Databases” (bancos NoSQL gerenciados), que resulta em muitas citações referentes ao DynamoDB, deixando, porém, os competidores bem abaixo nos resultados. Há também um post detalhado de Jonathan Ellis, no DataStax, comparando o Cassandra (outra importante solução NoSQL) com o DynamoDB.

Os resultados de Ellis são apoiados pela NetFlix, que utiliza amplamente o Cassandra no AWS e vem obtendo resultados muito positivos com performance e não sinaliza com planos de migração para o DynamoDB. Mas a visão da NetFlix sobre o novo serviço é bastante positiva. De acordo com Adrian Cockroft, CTO do empresa:

Agora que o DynamoDB foi lançado, uma questão óbvia é se o Netflix tem planos de utilizá-lo. A resposta curta é não, pois o DynamoDB só oferece um subconjunto das funcionalidades do Cassandra. Mas isso não tira o valor da grande evolução do DynamoDB em relação ao SimpleDB, em desempenho, escalabilidade e latência. Para novos clientes ou usuários que se depararam com limites de escalabilidade do MySQL ou MongoDB, o DynamoDB apresenta-se como excelente opção para começar a usar fontes de dados no AWS. As vantagens de uma administração transparente, além da maior performance e escalabilidade dos discos de estado sólido, são convidativas.

De acordo com Werner Vogel, o DynamoDB não se trata apenas de mais um serviço, pois a própria Amazon o está utilizando em seus produtos de nuvem. Se a Amazon encontrar um mercado de desenvolvedores disposto a criar aplicações que utilizem o DynamoDB, isto pode representar uma vantagem inicial em relação a outros provedores de serviços NoSQL. No entanto, como o DynamoDB não é open source, nem está disponível para download, esta solução NoSQL pode não ser adotada como primeira opção, pelos desenvolvedores web.

Tags | , , , ,

30

jan
2012

Sem Comentários

Em Blog
Dados
NoSQL

Por Allison

A revolução do Big Data está prestes a acontecer

Em 30, jan 2012 | Sem Comentários | Em Blog, Dados, NoSQL | Por Allison

Fonte: Cezar Taurion/IMasters

O termo Big Data começa a despertar muita atenção, mas ainda é um conceito mal definido e compreendido. Com uma rápida pesquisa ao Google, identifiquei, pelo menos, uma dúzia de definições. Neste artigo, vou falar um pouco sobre o assunto e debater alguns desafios que temos para conseguir colocar projetos de Big Data em ação.

Sem entrar em definições e nos atendo apenas à conceitos, podemos resumir com uma fórmula simples o que é Big Data: volume + variedade + velocidade de dados. Volume porque, além dos dados gerados pelos sistemas transacionais, temos a imensidão de dados gerados pelos objetos na Internet das Coisa, como sensores e câmeras, e os gerados nas mídias sociais, via PCs, smartphones e tablets. Variedade porque estamos tratando tanto de dados textuais estruturados, quanto dos não estruturados, como fotos, videos, emails e tuítes. E, por fim, velocidade porque, muitas vezes, precisamos responder aos eventos quase que em tempo real. Ou seja, estamos falando de criação e tratamento de dados em volumes massivos.

Outro desafio: criar e tratar apenas de dados históricos, como os veteranos Data Warehouse e as tecnologias de BI (Business Intelligence) começam a se mostrar lentos demais para a velocidade com que os negócios precisam tomar decisões. Aliás, o termo BI já tem mais de 50 anos. Ele foi cunhado por Hans Peter Luhn, pesquisador da IBM em um artigo escrito nos idos de 1958.

Quando falamos em volume, os números são gigantescos. Se olharmos globalmente, estamos falando em zetabytes, ou 10²¹ bytes. Grandes corporações armazenam múltiplos petabytes e mesmo as pequenas e médias empresas trabalham com dezenas de terabytes de dados. Este volume tende a crescer geométrica mente. Em mundo cada vez mais competitivo e rápido, as empresas precisam tomar decisões baseadas não apenas em palpites, mas em dados concretos. Assim, para um setor de marketing faz todo sentido ter uma visão 360° de um cliente, olhando não apenas o que ele comprou da empresa, como registrado no ERP, mas saber o que ele pensa e diz sobre a empresa e como os faz – pelo Facebook e Twitter, por exemplo.

Hoje, já é consenso que dados são os recursos naturais da nova Revolução Industrial. Na atual sociedade industrial, ter apenas recursos naturais, como minério, e exportá-los de forma bruta – importando em troca produtos manufaturados, não garante a competitividade de um país no longo prazo. O importante é a tecnologia e o conhecimento que cria produtos manufaturados. Afinal, um quilo de satélite vale imensamente mais forte que um quilo de minério de ferro.

Fazendo um paralelo, na sociedade da informação é crucial saber tratar os dados na velocidade adequada. Dados não tratados e analisados em tempo hábil são dados inúteis, pois não geram informação. Dados passam a ser ativos corporativos importantes e como tal, podem – e deverão – ser quantificados economicamente.

Big Data representa um desafio tecnológico, pois demanda atenção à infraestrutura e tecnologias analíticas. O processamento de volumes massivos de dados pode ser facilitado pelo modelo de computação em nuvem, desde, é claro, que este imenso volume não seja transmitido repetidamente via Internet. Só para lembrar, os modelos de cobrança pelo uso de nuvens públicas tendem a gerar processamentos muito baratos, mas tornam caro a transmissão de muitos dados.

A principal base tecnológica para Big Data Analytics é o Hadoop e os bancos de dados NoSQL, onde “No” significa Not Only SQL, ou seja, usa-se bases de dados SQL e não SQL. A importância do “Not Only” SQL explica-se pelo fato do modelo relacional ser baseado na época de sua criação, no início dos anos 70. Nessa época, acessar, categorizar e normalizar dados era bem mais fácil do que hoje. Praticamente não existiam dados não estruturados circulando pelos computadores da época. Também não foi desenhado para escala massiva, ou para um processamento muito rápido. Seu objetivo básico era possibilitar a criação de queries que acessassem bases de dados corporativas e, portanto, estruturadas. Para soluções Big Data, tornam-se necessárias varias tecnologias, desde bancos de dados SQL, a softwares que utilizem outros modelos, que lidem melhor com documentos, grafos, processamento paralelo, etc.

A complexidade do Big Data vem à tona quando lembramos que não estamos falando apenas de armazenamento e tratamento analítico de volumes massivos de dados, mas de revisão, ou criação, de processos que garantam a qualidade destes dados e de processos de negócios que usufruam dos resultados obtidos. Portanto, Big Data não é apenas um debate sobre tecnologias, mas, principalmente, sobre como os negócios poderão usufruir da montanha de dados que está agora à sua disposição. Aí emerge a questão da integração: como integrar bases de dados estruturadas e não estruturadas com diversos softwares envolvidos?

O Big Data abre oportunidades profissionais bem amplas. Na minha opinião, existe espaço para dois perfis profissionais: um mais voltado para os negócios e qualificados para tratar analiticamente as informações geradas por estas imensas bases de dados e outro com viés mais técnico, ou Data Architect.

Pelo viés dos negócios, um artigo interessante que foi publicado há poucos meses pelo Wall Street Journal, na edição brasileira, aponta como problema a escassez de talentos. Ele fala que muitas empresas americanas começaram a procurar profissionais que saibam interpretar os números usando a análise de dados, também conhecida como inteligência empresarial. Mas encontrar profissionais qualificados tem se mostrado difícil. O resultado foi que várias faculdades americanas, como a Faculdade de Pós-Graduação em Administração da Universidade Fordham e a Faculdade de Administração Kelley, da Universidade de Indiana, começaram a oferecer disciplinas eletivas, cursos de extensão e mestrados em análise de dados. Já o Data Architect deve lidar com tecnologias SQL e NoSQL, conhecer profundamente conceitos como stream processing e Event Driven Architecture (EDA) e, portanto, ter capacidade de desenhar estratégias para manusear e analisar grandes volumes de dados de formatos diferentes, quase que em tempo real.

A ideia de stream processing, ou stream computing, é fantástica; é um novo paradigma. No modelo de data mining tradicional, uma empresa filtra dados dos seus vários sistemas e, após criar um data warehouse, dispara “queries”. Na prática, faz-se uma garimpagem em cima de dados estáticos, que não refletem o momento, mas sim o contexto de horas, dias ou mesmo semanas atrás. Com o stream computing, esta garimpagem é efetuada em tempo real. Em vez de disparar queries em cima de uma base de dados estática, coloca-se uma corrente contínua de dados (streaming data) atravessando um conjunto de queries. Podemos pensar em inúmeras aplicações, sejam estas em finanças, saúde e mesmo manufatura.

Vamos ver este último exemplo: um projeto em desenvolvimento com uma empresa de fabricação de semicondutores monitora em tempo real o processo de detecção e classificação de falhas. Com o stream computing, as falhas nos chips que estão sendo fabricados são detetadas em minutos e não em horas ou semanas. Os wafers defeituosos podem ser reprocessados e, mais importante ainda, pode-se fazer ajustes em tempo real nos próprios processos de fabricação.

Quanto ao EDA, pode-se começar a estudar o assunto acessando seu verbete na Wikipedia.

O termo Big Data vai aparecer na tela do radar dos CIOs em breve. Aliás, já aparece no canto da tela de um ou outro CIO, e, provavelmente, em alguns anos já será um dos temas mais prioritários das tradicionais listas de “tecnologias do ano”. Portanto, é bom estar atento à sua evolução e começar a colocar em prática algumas provas de conceito.

Tags | , , , , ,

10

jan
2012

Sem Comentários

Em Blog
NoSQL

Por Allison

O Futuro do CouchDB

Em 10, jan 2012 | Sem Comentários | Em Blog, NoSQL | Por Allison

Neste último dia 04/01 (Quarta-Feira) Damien Katz, um dos criadores do projeto Apache CouchDB, divulgou em seu blog que ele e o time de desenvolvimento Couchbase não terão mais o CouchDB como projeto principal.

Conforme dito por Katz, o novo foco de desenvolvimento é o Couchbase Server:

Não quer dizer que o CouchDB não é incrível. Simplesmente estamos criando seu sucessor: Couchbase Server. Um produto e projeto com capacidades e objetivos similares, porém mais rápido, mais escalável, mais customizável e com foco nos desenvolvedores. E definitivamente não será parte da Apache.

Muitos devem se perguntar “Porquê não continuar evoluindo o CouchDB?”, Damien Katz explica que o desenvolvimento do Apache CouchDB foi governado pelo consenso da comunidade, o que o levou a seguir caminhos que (hoje) ele considera como não sendo os melhores. Pode parecer um descaso com a Apache, mas ele explica: “O Apache foi a grande responsável pelo sucesso do CouchDB, sem isso o CouchDB não teria alcançado o sucesso repentino que alcançou. Mas em minha opinião, o projeto alcançou um ponto onde a abordagem consensual limitou a competitividade do projeto. Não é pessoal, é negocial.”

O foco inicial do desenvolvedor é tornar o CouchBase Server 2.0 pronto para uso em ambiente produtivo e tornando-o o banco de dados NoSQL mais fácil, rápido e confiável, além de reescrever o núcleo do projeto utilizando C/C++.

O CouchDB é um dos bancos de dados NoSQL mais famosos e utilizados atualmente. Boa parte desta fama é resultado do esforço de divulgação e de algumas decisões estratégicas tomadas pela Fundação Apache, tornando o CouchDB um SGBD único e com grande apelo para os desenvolvedores Web. Por isso os usuários do Apache CouchDB podem continuar despreocupados, o projeto é forte e ativo, pois continuará sendo desenvolvido pelo restante da equipe/comunidade. Não há chances do projeto ser descontinuado, pois possui diversos patrocinadores como, Cloudera, Right Scale, Canonical, Red Hat, Heroku, AppFirst, Fusion-io, HP e VMWare. Claro que nenhum apoio/patrocínio do mundo pode suprir a perda de um dos principais “cabeças” do projeto, logo podemos esperar uma possível mudança no ritmo de desenvolvimento do CouchDB. Se você está curioso para saber um pouco mais sobre o COuchDB, sugiro dar uma olhada neste outro artigo publicado aqui no blog Mind Bending: Python e CouchDB na Prática

É interessante perceber que esta notícia mostra tanto o lado bom quanto o lado perigoso do mundo Open Source. Ao mesmo tempo que este modelo permitiu que Damien Katz utilizasse o código do CouchDB como base para o CouchBase Server, este mesmo modelo é parcialmente culpado pelo caminho que o CouchDB tomou. Existem diversos modelos para o desenvolvimento OpenSource, o modelo adotado pela Apache permite que diversas “pessoas” tenham poder para interferir no caminho que seus software tomam, por isso usei a palavra “parcialmente”.

Dando uma olhada na sessão de download do CouchBase Server, acabei me decepcionando, e muito. O CouchBase está sendo distribuído em duas modalidades: Enterprise Edition e Community Edition. A Community Edition é voltado para pequenas aplicações e não oferece atualizações e/ou hotfixes imediatamente. Já a Enterprise Edition é o produto completo, submetido a testes de performance e funcionalidade, e é o único produto ao qual os desenvolvedores oferecem suporte. A Enterprise Edition também é dividida em dois tipos, a versão paga e a versão gratuita. A versão gratuita só pode ser utilizada em até 2 servidores de produção.

Exposto isto, eu entendo que o único produto Livre que eles irão distribuir é o CouchBase Community Server (ao qual não é oferecido suporte), pois, ao restringir o uso da Enterprise Edition eles ferem as regras da liberdade de uso do software. Creio que isso impedirá que muitas pessoas pensem em migrar do CouchDB.

Fonte: MidBegin

Tags | , , ,

23

nov
2011

Sem Comentários

Em Arquitetura
Blog
NoSQL
REST

Por Allison

REST tem impacto sobre NoSQL?

Em 23, nov 2011 | Sem Comentários | Em Arquitetura, Blog, NoSQL, REST | Por Allison

A partir do momento que grandes empresas como o Twitter e a Amazon abraçaram a arquitetura REST e também se tornaram defensores do NoSQL tornou-se inevitável assistirmos a essas duas tecnologias sendo utilizadas em conjunto. Em um post recente, Ganesh Prasad questiona como o sucesso do NoSQL nos leva a reavaliar os aspectos centrais do REST. Ganesh acredita que existem dois aspectos na tecnologia que representam obstáculos para a sua adoção:

Um deles é o uso do modelo cliente/servidor, ao invés do modelo de ponto a ponto, que acredito ser mais geral e útil. O segundo é a insistência na ausência de estado do cliente no servidor, forçando que essas informações sejam armazenadas no próprio cliente ou que sejam modeladas como recursos.

É no aspecto da ausência de estado que Ganesh se concentra. A questão de manutenção de estado e o REST já foi muito debatida em várias fontes, por exemplo Bill Burke discutiu essa questão anos atrás:

Em REST, a ausência de estado significa que não existem dados da sessão do cliente armazenados no servidor. O servidor somente cuida do estado dos recursos que expõe. Se houver necessidade de informações específicas da sessão de algum cliente, essas informações devem ser armazenadas no próprio cliente e transferidas para o servidor a cada requisição, quando necessário.

A camada de serviços que não mantém informações dos clientes conectados é muito mais simples de escalar, por precisar de menos informações ao se replicar em um ambiente em cluster. É mais simples de colocar em cluster, porque tudo o que é preciso fazer é adicionar mais máquinas.

Stefan Tilkov adota a mesma linha:

É importante reforçar que, embora REST inclua a ideia da ausência de estado, isso não significa que a aplicação que expõe suas funcionalidades não pode ter estado – isso tornaria essa abordagem pouco útil para a maioria dos cenários.


O REST obriga que o estado seja transformado em um recurso ou mantido no cliente. Em outras palavras, o servidor não deve manter nenhum tipo de informação associada ao estado da comunicação com o cliente, independente do da duração de uma requisição. A principal razão para isso é a escalabilidade: a capacidade de atendimento dos servidores fica severamente prejudicada quando o servidor necessita manter o estado das comunicações. (Note que essa restrição exige modificações na aplicação: não se pode simplesmente atribuir uma URI a um estado da sessão e chamar a aplicação de RESTful.)


Existem outros aspectos mais importantes: a ausência de estado isola o cliente de alterações dos servidores, uma vez que não depende da comunicação com o mesmo servidor em duas requisições consecutivas. O cliente pode receber um “documento” contendo links de um servidor e, enquanto o cliente processa essas informações, o mesmo servidor pode ser desligado; o disco removido e trocado; e o software atualizado e reiniciado; tudo isso sem impacto negativo. Se o cliente seguir os links obtidos a partir do servidor, ele não irá perceber.

Ganesh, apesar de entender que a ausência de estado colabora com demandas de escalabilidade e recuperação a falhas, acredita que tais restrições sobrecarregam a camada da aplicação, que passa a ter de tratar aspectos de distribuição e infraestrutura:

A abordagem REST é aceitável para elementos do domínio da aplicação, mas a existência de estado de comunicação com o cliente é útil para tratar elementos independentes do domínio, associados à qualidade do serviço como, por exemplo chaves de sessão para o controle de segurança. A recusa do REST em suportar aspectos como esses compromete a habilidade de oferecer essas características de forma transparente.

É para esse tipo de estado referenciado por Bill e Stefan que Ganesh chama atenção. Ganesh destaca que o NoSQL oferece uma solução escalável e tolerante a falhas para o problema. Ele se refere à implementação do Redis, entretanto a maioria (se não todas) as implementações NoSQL também tratam deste problema.

Está se tornando uma recomendação armazenar o estado da sessão em um banco de dados NoSQL como o Redis, ao invés de em memória. Delegar o armazenamento dos dados de sessão para um cluster NoSQL independente, e configurar os servidores de aplicação para obtê-las a partir deste cluster, torna os servidores de aplicações independentes dos clientes novamente. Um destaque no Redis é a baixa complexidade das operações GET e SET, que são de Ordem(1), ou seja, constante. Isto significa que (pelo menos em teoria) o número de clientes utilizando um banco de dados Redis pode aumentar indefinidamente, sem impacto na performance.

O artigo de Ganesh descreve como podemos utilizar o banco de dados NoSQL Redis para gerenciar os dados de sessão. Desta forma, acredita ele, aplicações REST devem ser levadas seriamente em consideração (neste caso sendo necessário atualizar/aprimorar a filosofia do REST). Ele conclui dizendo:

Seria bom se um mecanismo padrão e sem dependência de domínio pudesse evoluir para fornecer segurança e confiabilidade às interações baseadas em REST, utilizando mecanismos de armazenamento escalável de sessões em NoSQL.

A maioria das metodologias de desenvolvimento, frameworks e padrões mantém a sua relevância evoluindo para novas abordagens, assim que novas experiências são obtidas. NoSQL era apenas um exercício acadêmico quando a arquitetura REST foi proposta, portanto surge a questão: a arquitetura REST precisa evoluir face ao NoSQL, ou a natureza sem estado do REST continua a ser uma exigência, independentemente da abordagem utilizada para armazená-lo?

Fonte: Mark Little , traduzido por Lucas Machado/InfoQ

Tags | , , ,