Image Image Image Image Image
Scroll to Top

Topo

couchdb

10

abr
2012

Sem Comentários

Em Blog
Dados

Por Allison

Apache CouchDB 1.2 aumenta velocidade e comprime mais

Em 10, abr 2012 | Sem Comentários | Em Blog, Dados | Por Allison

Fonte: IMasters

Com informações de The H

Os desenvolvedores do Apache CouchDB anunciaram melhorias em desempenho e em segurança na versão 1.2 do banco de dados NoSQL. A atualização também traz uma nova implementação de replicação e o padrão para habilitar compressão de arquivos para o banco de dados e para os arquivos do index view.

Além disso, a nova versão foi lançada junto com uma reforçada presença do banco de dados na Apache Software Foundation.

O CouchDB faz muito uso do format de dados JSON e, na 1.2, os desenvolvedores moveram partes críticas do parser do JSON para o Com (usando a biblioteca yail), que, segundo eles, melhorou a latência e a taxa de transferência do sistema. Bancos de dados e índices para views agora são passados através do sistema de compressão Snappy, do Google, reduzindo a quantidade de dados transferida para e a partir do disco; essa redução em I/O também melhorou o desempenho do banco de dados e permitiu vários aprimoramentos em algoritmos, o que resultou na melhoria de operações comuns, como a construção de views.

A segurança também foi modificada no Apache CouchDB 1.2, o que levou a algumas rupturas de compatibilidade com versões anteriores. Agora, o banco de dados dos usuários não está legível para todos e, ao acessar os dados no replicador do banco de dados, irá retornar documentos retirados de informações confidenciais, como senhas e tokens OAuth. O CouchDB agora gerencia, de forma consistente, o hashing de senhas antes de seu armazenamento, em vez de confiar nos aplicativos do cliente para isso. Além disso, segredos do OAuth dentro do banco de dados e cookies de autenticação persistente também são suportados pelo CouchDB.

Outras mudanças incluem um novo sistema replicador, que, segundo os desenvolvedores, é mais confiável e rápido que o anterior; maior abrangência de opções de configuração para permitir melhor tuning para ambientes particulares; e melhorias no sistema de building e de logging, além de várias correções de bugs.

Detalhes estão disponíveis aqui. O Apache CouchDB 1.2 pode ser baixado neste link, e uma versão para Mac OS X chegará em breve.

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 | , , ,

24

nov
2011

Sem Comentários

Em Blog

Por Allison

Canonical resolve descontinuar CouchDB do Ubuntu One

Em 24, nov 2011 | Sem Comentários | Em Blog | Por Allison

A Canonical decidiu descontinuar o uso do CouchDB como parte do seu serviço de sincronização de dados, Ubuntu One. O anúncio foi feito por John Lenton, gerente sênior de engenharia na Canonical.

De acordo com Lenton, a Canonical trabalhou com a companhia por trás do CouchDB para fazer o banco de dados escalar de uma maneira peculiar. “Nossa situação é única e ficamos incapazes de resolver alguns problemas que surgiram”.

Devido a esses problemas, a Canonical decidiu desligar a maioria dos seus serviços baseados no CouchDB. Bancos de dados de contatos, notas e playlists ainda existirão para usuários para suportar os serviços que eles consomem, mas o acesso externo aos sistemas de banco de dados será descontinuado, e quaisquer outros bancos de dados armazenados no serviço de nuvem do Ubuntu será deletado.

Além disso, a Canonical está descontinuando o desenvolvimento do desktopcouch e, no Ubuntu 12.04, pacotes do Ubuntu One não usarão o CouchDB. Segundo Lenton, a empresa está construindo algo novo, baseado em tudo o que foi aprendido, que recebeu o nome de U1DB. Entretanto, ele não ficará pronto a tempo de ser incluído no Ubuntu 12.04.

Não foram divulgadas datas de quando os bancos de dados serão removidos.

Com informações de The H

Fonte: IMasters

Tags | , , ,

10

set
2011

Sem Comentários

Em Blog

Por Allison

Escolhendo a ferramenta certa para o banco de dados NoSQL

Em 10, set 2011 | Sem Comentários | Em Blog | Por Allison

Meu Deus, existem tantas ferramentas para armazenamento do NoSQL por aí. É quase tão ruim quanto as marcas de bebidas esportivas, ou de água. Você notou que alguns supermercados imensos têm corredores inteiros dedicados ao que bebemos?

Como um administrador ou gerente de sistemas de TI, às vezes é muito difícil comparar várias ferramentas do NoSQL. Isso envolve a consideração das suas necessidades computacionais especiais, e o alinhamento das mesmas ao que é disponibilizado no mercado, combinando o que é certo para a sua empresa e então tomando a decisão certa!

É por isso que Monitis, um serviço tudo-em-um de monitoramento de performance de redes e sistemas para sysadmins, está publicando uma série de blogs que tinham o objetivo de oferecer um guia compreensivo para a tecnologia e para as marcas do NoSQL. O objetivo é te ajudar a fazer a escolha certa que atende à necessidade específica da sua empresa.

Por que deveríamos nos importar? – você pode se perguntar. Cada vez mais, nossos clientes, que dependem da nossa habilidade de monitorar servidores e redes e de várias outras métricas-chave dia e noite a partir da nuvem, também querem nosso conselho sobre qual tipo de tecnologia de banco de dados escalável e robusto usar. Portanto, estamos sendo prestativos!

Portanto, apresentaremos pesquisas em ferramentas populares existentes de armazenamento de dados NoSQL, que têm o intuito, geralmente, de armazenar quantidades imensas de dados sem precedentes, oferecer escalabilidade horizontal e flexível, e fornecer o processamento de consultas absurdamente rápido. Também chegaremos ao âmago da questão e iremos comparar vários bancos de dados NoSQL bastante conhecidos, como Cassandra, MongoDB, CouchDB, Redis, Riak, HBase e outros.

Neste primeiro artigo, vamos discutir sobre a razão pela qual a tecnologia NoSQL é importante.

Então, o que é NoSQL?

Geralmente, o NoSQL não é relacional e foi projetado para armazenamento distribuído de dados, para dados de grande escala (p.e. o Facebook ou o Twitter acumulam terabits de dados todos os dias para milhões de usuários), e não existem fixed schemas e joins. Enquanto isso, sistemas de gerenciamento de bancos de dados relacionais (RDBMS) geram escalonamento ao deixar seu hardware cada vez mais rápido e adicionando memória. O NoSQL, por outro lado, pode tirar vantagem de “escalar para baixo” – o que significa distribuir o carregamento entre muitos outros sistemas de conveniência.

O acrônimo NoSQL foi criado em 1998 e, enquanto muitos pensam que o NoSQL é um termo depreciativo criado para tirar sarro do SQL, na verdade ele significa “Não Somente SQL – Not Only SQL”. A ideia é que ambas tecnologias (NoSQL and RDBMSs) podem coexistir e cada uma delas tem o seu lugar. Empresas como Facebook, Twitter, Digg, Amazon, LinkedIn e Google usam o NoSQL de alguma maneira – então o termo tem estado nas notícias atuais nos últimos anos.

Qual o problema com RDBMSs?

Bom, nada, na verdade. Eles apenas têm suas limitações. Considere estes três problemas com RDBMSs:

RDBMSs usam uma abordagem de normalização com base em tabela de dados, e esse modelo é limitado. Certas estruturas de dados não podem ser representadas sem adulteração dos dados, programas, ou ambos…

Elas permitem versionamento ou atividades como: Criar, Ler, Atualizar e Deletar. Para banco de dados, atualizações nunca deveriam ser permitidas, porque elas destroem a informação. Em vez disso, quando os dados mudam, o banco de dados deveria apenas adicionar outro registro e anotar devidamente o valor para aquele registro.

A performance é perdida quando o RDBMSs normaliza os dados. O motivo: a normalização pede mais tabelas, joins de tabelas, chaves e índices e, dessa maneira, mais operações internas do banco de dados para implementar as consultas. Logo logo, o banco de dados começa a crescer para o tamanho de terabytes, e é aí que as coisas começam a ficar lentas.

As quatro categorias do NoSQL

1. Armazenamento Chave-Valor

A ideia principal aqui é usar uma tabela hash na qual há uma chave única e um indicador de um dado ou de um item em particular. O modelo chave-valor é o mais simples e fácil de implementar. Mas ele é ineficiente quando você somente está interessado em consultar ou em atualizar parte de um valor, entre outras desvantagens.

  • Exemplos: Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
  • Aplicações típicas: Cache de conteúdo (Foco em escalar para imensas quantidades de dados, criado para lidar com carregamento massivos) logging etc.
  • Modelo de dados:Coleção de pares de chave-valor.
  • Pontos fortes: Pesquisas rápidas.
  • Fraquezas: Dados armazenados não têm schema.

2. Armazenamento Column Family

Foram criadas para armazenar e para processar grandes quantidades de dados distribuídos em muitas máquinas. Ainda existem chaves, mas elas apontam para colunas múltiplas. As colunas são organizadas por família da coluna.

  • Exemplos: Cassandra, HBase, Riak.
  • Aplicações típicas: Sistemas de arquivos distribuídos.
  • Modelo de dados: Colunas → famílias de colunas
  • Pontos fortes: Pesquisas rápidas, boa distribuição de armazenamento de dados.
  • Fraquezas: API de baixo nível.

3. Banco de Dados orientado a Documentos

Foram inspirados por Lotus Notes e são similares ao armazenamento chave-valor. O modelo é basicamente documentos versionados que são coleções de outras coleções de chave-valor. Os documentos semi-estruturados são armazenados em formatos como JSON. Bancos de dados de documentos são essencialmente o próximo nível do chave-valor, permitindo valores aninhados associados a cada chave. Bancos de dados de documentos suportam as consultas mais eficientemente.

  • Exemplos: CouchDB, MongoDb.
  • Aplicações típicas: Aplicações Web (Similar ao armazenamento chave-valor, mas o BD sabe qual é o valor).
  • Modelo de dados: Coleções de coleções de chave-valor.
  • Pontos fortes: Tolerante a dados incompletos.
  • Fraquezas: Query performance, sem sintaxe de query padrão.

4. Banco de Dados orientado a Grafos

Em vez de tabelas com linhas e colunas e a rígida estrutura do SQL, um modelo gráfico flexível é usado e que pode, mais uma vez, ser escalado através de varias máquinas. Bancos de dados NoSQL não fornecem uma linguagem query declarativa de alto nível como o SQL para evitar tempo extra em processamento. Em vez disso, executar o querying nesse banco de dados é um modelo de dados específico. Muitas das plataformas NoSQL permitem interfaces RESTful nos dados, enquanto outras oferecem query APIs.

  • Exemplos: Neo4J, InfoGrid, Infinite Graph.
  • Aplicações típicas: Redes Sociais, Recomendações (Foco em modelar a estrutura dos dados – interconectividade)
  • Modelo de dados: Grafo de Propriedades – Nós.
  • Pontos fortes: Algoritmos gráficos, p.e. caminho mais curto, conectividade, relacionamentos n degrees etc.
  • Fraquezas: Tem que atravessar todo o gráfico para obter uma resposta definitiva. Não é fácil de agrupar.

Geralmente, os melhores lugares para usar a tecnologia NoSQL é onde o modelo de dados é simples; onde flexibilidade é mais importante que controle rígido sobre estruturas definidas de dados; onde alta performance deve existir; consistência de dados rígida não é necessária; e onde é fácil mapear valores complexos para chaves conhecidas.

Alguns exemplos de quando usar NoSQL

  • Logging/Arquivamento. Ferramentas de Log-mining vêm a calhar porque elas conseguem acessar logs através de servidores, relacioná-los e analisá-los..
  • Insight em computação social. Muitas empresas hoje forneceram a seus usuários a habilidade de atuar na computação social através de fóruns de mensagens blogs etc.
  • Integração de feed de dados externos. Muitas empresas precisam integrar os dados oriundos de seus parceiros. Mesmo se as duas partes conduzirem várias discussões e negociações, as empresas têm pouco controle sobre o formato dos dados que chegam a elas. Além disso, existem muitas situações em que esses formatos mudam muito frequentemente – baseado na mudança das necessidades de negócios dos parceiros.
  • Sistemas de processamento de pedidos Front-end. Hoje, o volume de pedidos, aplicações e serviços flutuando através de diferentes canais para comerciantes, banqueiros e seguradoras, fornecedores de entretenimento, logística etc é enorme. Esses pedidos precisam ser capturados sem nenhum interrupção sempre que um usuário final faz uma transação de qualquer parte do mundo. Depois disso, um sistema de reconciliação tipicamente os atualiza para sistemas de back-end, ao mesmo tempo que atualiza o usuário final com o seu status.
  • Serviço de gerenciamento de conteúdo empresarial. O gerenciamento de conteúdo agora é utilizado através de diferentes grupos funcionais da empresa, como RH ou vendas. O desafio é congregar grupos diferentes utilizando estruturas diferentes de metadados em um serviço comum de gerenciamento de conteúdo.
  • Estatísticas/análises em tempo real. Às vezes, é necessário usar o banco de dados como uma maneira de rastrear métricas de performance em tempo real para websites (visualizações de páginas, visitas únicas etc). Ferramentas como o Google Analytics são ótimas, mas não são em tempo real – às vezes, é util construir um sistema secundário que fornece estatísticas em tempo real. Outras alterativas, como monitoramento de tráfego 24/7, são uma boa opção também.

Que tipo de armazenamento devo usar?

Aqui está um breve resumo que deve te ajudar a decidir:

NoSQL

  • O armazenamento deve ser capaz de lidar com carregamentos pesados.
  • Você executa muitas operações de escrita no armazenamento.
  • Você quer um armazenamento que seja escalável horizontalmente.
  • Simplicidade é bom, como em uma linguagem query bem simples (sem joins).

RDBMS

  • Armazenamento é esperado para apresentar carregamento pesado também, mas consiste principalmente na leitura de operações.
  • Você prefere performance a uma estrutura de dados sofisticada.
  • Você precisa de uma linguagem SQL query poderosa.

Em outros artigos, voltarei a falar do assunto, te guiando através de sete bancos de dados populares do NoSQL e discutindo seus méritos e seus problemas. Fique ligado!

Texto original disponível em http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool/

Fonte: Mikayel Vardanyan/IMaster

Tags | , , , , , , , , ,

02

ago
2011

Sem Comentários

Em Blog

Por Allison

Couchbase anuncia preview da versão 2.0 de seu servidor

Em 02, ago 2011 | Sem Comentários | Em Blog | Por Allison

A Couchbase anunciou um preview da versão 2.0 do seu servidor, que tem como objetivo a unificação com o CouchDB Membase para oferecer um banco de dados orientado a documentos distribuídos com key-value store do MemBase e com o MemCached em uma plataforma única.

A novidade é esperada desde quando que a CouchOne e o Membase uniram-se, em fevereiro deste ano.

De acordo com a empresa, o novo servidor deve ser fácil de instalar e gerenciar, além de trazer nova indexação e apoio de consulta, com uma combinação de tecnologias que oferece a menor latência disponível em um banco de dados NoSQL.

Fonte: Under-Linux

Tags | , ,

01

ago
2011

Sem Comentários

Em Blog

Por Allison

Criadores de CouchDB e SQLite lançam UnQL

Em 01, ago 2011 | Sem Comentários | Em Blog | Por Allison

Os sistemas de banco de dados livres CouchDB e SQLite apresentaram juntos o UnQL (pronuncia-se “Uncle”), uma especificação de uma nova linguagem de consulta, que é parecida com o SQL em muitos aspectos, mas é projetada para trabalhar com bancos de dados documentais NoSQL.

Damien Katz, criador do CouchDB, e Richard Hipp, responsável pelo SQLite, vêm trabalhando no UnQL para criar uma linguagem de alto nível. Segundo Katz, a especificação surgiu da crença de que uma linguagem de consulta comum é necessária para impulsionar a adoção NoSQL, da mesma maneira que o SQL levou a adoção no mercado de banco de dados relacional.

A linguagem inclui comandos SELECT, INSERT, UPDATE e DELETE, mas, diferentemente do que ocorre do SQL, eles não funcionam em tabelas, e sim em “collections” desordenadas de conjuntos de documentos.

Fonte: Under-Linux

Tags | , , ,