Image Image Image Image Image
Scroll to Top

Topo

nosql

17

abr
2012

Sem Comentários

Em Blog
Dados

Por Allison

MySQL 5.6.2 introduz a interface NoSQL

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

Fonte: IMasters

Com informações de The H

A Oracle lançou a versão 5.6.2 do MySQL, que ganhou melhorias no recurso de replicação e a capacidade de passar do framework SQL para um acesso mais rápido a dados e para performace parecida com NoSQL.

Reagindo às demandas dos clientes para a melhoria da velocidade de transação, o MySQL 5.6.2 introduz uma interface NoSQL usando a API memcached, que permite aos usuários acessar diretamente o mecanismo de armazenamento InnoDB, ignorando completamente o SQL, mantendo a compatibilidade com o modelo de banco de dados relacional. Os recursos do NoSQL foram originalmente vistas em um “laboratório instantâneo” em abril de 2011. A replicação também tem recebido vários novos recursos no MySQL 5.6.2, incluindo melhorias de desempenho e melhorias de integridade de dados, tais como novas replicações de checksums e a recuperação automática de escravos de banco de dados com falhas.

Mais informações sobre o lançamento você encontra aqui. O software experimental está licenciado sob a GPLv2 e pode ser baixado do site do MySQL Labs. Como acontece com todo o software experimental, os usuários são lembrados de que o objetivo é usá-los em teste e não deve ser usados em ambientes de produção.

Tags | , ,

13

fev
2012

Sem Comentários

Em Blog

Por Allison

Amazon lança serviço para facilitar crescimento de sites

Em 13, fev 2012 | Sem Comentários | Em Blog | Por Allison

Com informações de ComputerWorld

Fonte: IMasters

Amazon anunciou, na última terça-feira, o DynamoDB, um serviço que permite que sites cresçam sem perda de desempenho. O recurso faz parte da Amazon Web Services, plataforma de serviços na nuvem usada por empresas para processar determinadas tarefas sem precisar investir muito em hardware e software próprios.

De acordo com a empresa, a tecnologia usada é a do padrão de banco de dados NoSQL, que permite o crescimento no tamanho dos sites sem prejudicar o desempenho, repartindo o processamento entre servidores e storage de maneira mais barata e simples.

Agora, a Amazon vai oferecer o NoSQL como um serviço cloud – os clientes pagarão apenas por aquilo que usam. A empresa também aumentou sua oferta de armazenamento em estado sólido (SSD), mais ágil que os dicos rígidos tradicionais.

“Com o Amazon DynamoDB, os desenvolvedores de aplicativos baseados em nuvem pode começar pequeno, com apenas a capacidade de que precisam e, em seguida, aumentá-la conforme sua app cresce em popularidade”, disse Werner Vogels, CTO da Amazon.

Desenvolvedores podem testar o DynamoDB gratuitamente para aplicações que não passem de 40 milhões de pedidos por mês. Assinaturas pagas começam em 1 dólar por GB por mês.

A Amazon informa que o DynamoDB está atualmente disponível na região leste dos Estados Unidos. Mas, assim como acontece com todos os serviços da companhia, a Amazon trabalha para torná-los disponíveis rapidamente em todas as localidades. Por meio da assessoria de imprensa no Brasil, a organização diz que ainda não há uma data para disponibilizar o serviço no país.

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

23

nov
2011

Sem Comentários

Em Blog
SQL

Por Allison

10 técnicas para otimização de instruções SQL

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

Neste artigo vou apresentar dez técnicas de otimização de instruções SQL. Elas não são específicas de um banco de dados e podem ser aplicadas em qualquer SGBD que utilize SQL e até bancos de dados NoSQL.

Também destaco que estas são apenas sugestões de técnicas que podem ser aplicadas, pois o processo de tuning de instruções SQL, ou seja, otimizar uma instrução para que ela seja executada mais rapidamente, é complexo, demorado, depende de cada cenário e exige uma boa dose de experiência. Contudo, quanto mais nos esforçarmos e focarmos na otimização, melhores serão os resultados.

Outro ponto importante, que é preciso destacar, é que estas técnicas podem ser aplicadas às quatro principais instruções SQL: SELECT, INSERT, UPDATE e DELETE. Como dito anteriormente, algumas delas também são válidas para os bancos de dados NoSQL, um vez que, apesar da linguagem SQL não ser empregada, muitos dos conceitos são os mesmos (geração de plano de execução, uso de índices, métricas, etc).

1. Use bem os índices

Um dos principais fatores que impacta no desempenho de uma instrução SQL é o uso de índices, principalmente em instruções que empregam tabelas com muitos dados. Este é um fator tão importante, que a mera criação de um índice pode reduzir drasticamente a quantidade de passos internos na execução de instruções SQL.

Neste momento surge uma pergunta: como começar a analisar e criar os índices adequados? Infelizmente, não existe uma única resposta para esta pergunta. Mas para ajudar o leitor que não tem muita experiência no uso de índices, montei o seguinte fluxograma apresentado abaixo. Este diagrama é apenas uma sugestão genérica e deve ser utilizado somente como ponto de partida para aqueles que possuem pouca experiência. Obviamente, a cada criação de índice devem ser realizados diversos testes.

2. Explore o paralelismo

Atualmente, vivemos em uma era onde os microprocessadores são dominados por múltiplos núcleos. Até dispositivos móveis como smartphones, tablets e consoles portáteis estão recebendo microprocessadores com múltiplos núcleos. Mas isso não quer dizer que as aplicações estejam preparadas para obter o máximo de desempenho proporcionado por este hardware.

Sendo assim, é recomendável sempre procurar explorar o paralelismo em banco de dados. Apesar desta preocupação ser relativamente recente, e talvez um pouco mais comum para quem trabalha com programação, a exploração de paralelismo deve ser considerada quando for necessário otimizar instruções SQL.

Infelizmente, existem poucos recursos para a manipulação, ou aplicação direta de conceitos de programação paralela direto no banco de dados. Entretanto, é possível utilizar algumas técnicas para explorar o paralelismo na execução de instruções SQL,. dependendo, principalmente, do banco de dados a ser utilizado. Por exemplo: tanto o Oracle, quanto o SQL Server possuem diversos operadores utilizados internamente no plano de execução para mostrar se o plano escolhido utilizou, ou não paralelismo. Outro exemplo é a técnica apresentada no meu artigo de capa da revista SQL Magazine número 91, chamado Processamento paralelo de instruções SQL, disponível em neste aqui.

3. Saiba trabalhar com condições de pesquisa dinâmica

Imagine a seguinte situação: uma aplicação permite ao usuário escolher diversos campos para pesquisar na base de dados. Estes campos são apresentados através de elementos de um formulário como campos de texto, checkbox, combo e outros. Se o valor de algum campo for preenchido, este valor será montado em uma string, cujo conteúdo será utilizado para montar uma cláusula WHERE na instrução SELECT, que será encaminhada para o banco de dados. Este cenário é muito comum tanto em aplicações desktop, como em aplicações web.

Deixando as preocupações com SQL Injection de lado, como garantir que instruções SELECT dinâmicas possam ser executadas com um bom desempenho? Bem, como esta situação é muito comum, há uma técnica chamada condições de pesquisa dinâmica que pode auxiliar a criação da instrução SELECT visando tanto a flexibilidade proporcionada pela escolha dinâmica de filtros, quanto pelo desempenho.

Para quem trabalha com o SQL Server, existe alguns artigos escritos por Erland Sommarskog e que abordam esta técnica. Eles estão disponíveis neste link. Os conceitos apresentados podem ser adaptados para outros bancos de dados sem grandes problemas.

4. Conheça bem o modelo de dados

Quando se trabalha com uma instrução SQL, como SELECT, INSERT, UPDATE e DELETE é extremamente importante tem um bom conhecimento do modelo de dados. De fato, o modelo pode impactar muito no desempenho da instrução, devido aos joins que são realizados, os filtros na cláusula where e outros fatores.

Já escrevi diversos artigos aqui no iMasters abordando questões de desempenho que tratam do modelo de dados: como eliminar tabelas desnecessárias, tipagem de dados correta e até a análise de modelos de dados do WordPress. Destaco também um artigo em inglês para o site SQLServerCentral.com, onde apresento algumas dicas para quem trabalha com modelos de dados grandes (com muitas tabelas e relacionamentos).

5. Quebre uma instrução SQL complexa em várias

Durante a minha carreira tenho encontrado muitos desenvolvedores com uma mania um tanto quanto esquisita: tentar montar relatórios utilizando uma instrução SELECT, por mais complexa que ela seja.

Ora, a instrução SELECT possui diversas cláusulas e opções que permitem realizar muitas operações de uma vez só, como filtros, ordenação, agregação, cálculos e outros. Porém, quanto mais operações uma única instrução SELECT realiza, mais complexa ela se torna. Aliás, recomendo o ótimo formatador online de instruções SQL, chamado SQL Online Formater, para auxiliar na melhora do visual de instruções SQL complexas e ajudar a compreendê-las. Este formatador está disponível em aqui.

Voltando ao assunto, a mania de fazer tudo em uma única instrução SELECT é considerada preciosa, e muitas vezes mais ajuda do que atrapalha. Faz muito sentido dividir as operações necessárias para se obter o relatório desejado em mais de uma instrução SELECT, pois assim fica mais fácil de dar manutenção no código, pode-se aplicar outras otimizações, gerenciar melhor o acesso a recursos (locks) e também fazer uso de opções de cache, criptografia e permissões do banco de dados. Uma dúvida pode surgir neste caso: como vou fazer minha aplicação/gerador de relatório utilizar mais de uma instrução SELECT para obter os dados que preciso?

Bem, neste caso existem algumas opções. A utilização de stored procedures é uma delas, mas pode ser utilizadas funções e views. Além das vantagens citadas também existem opções específicas de stored procedures e objetos programáveis do banco de dados que podem ser úteis, como criptografia, uso de parâmetros, opções de cache, entre outras.

6. Empregue os conceitos de teoria de conjuntos

Uma das técnicas de otimização mais disseminadas e, ouso a dizer, repetidas à exaustão, envolve trocar o processamento linha a linha (cursor) por operações baseadas em conjunto (set-based). Com certeza esta técnica é válida, mas não devemos parar por aí.

Atualmente, diversos dialetos do padrão SQL (Pl/SQL, T-SQL, etc) possuem operadores que são muito parecidos com as operações de conjuntos união, intersecção e diferença, como os operações UNION, INTERSECT e MINUS, respectivamente. Em muitas situações vale a pena pensar em termos de conjunto para montar uma instrução SQL otimizada. Por exemplo: para atualizar determinado conjunto de linhas, podemos pensar em obter todas as linhas desta tabela e retirar as linhas desta outra tabela. Neste caso deve-se considerar utilizar o operador MINUS.

O mais importante desta técnica não é, necessariamente, empregar este, ou aquele operador, ou joins; e sim mostrar que é possível pensar de maneira diferente em relação ao processo normal e muitas vezes já viciado na cabeça do desenvolvedor. A teoria de conjuntos, matematicamente falando, é muito poderosa e com alto grau de expressão. Saber aplicá-la quando se trabalha com instruções SQL pode fazer muita diferença, principalmente quando se busca obter desempenho.

7. Tenha casos de uso confiáveis para a instrução a ser otimizada

Quando se está modificando uma instrução SQL que já funciona corretamente, e se deseja melhorar seu desempenho, é praticamente obrigatório elaborar testes antes da modificação, pois assim é fácil determinar se a(s) modificação(es) implementada(s) quebraram, ou não a funcionalidade existente.

Por exemplo: suponha que uma instrução SELECT receba três parâmetros de filtro e, com certos valores A, B e C retorne, X linhas e T segundos. Guarde em algum lugar esta informação indicando que para os valores A, B e C dos respectivos parâmetros, estas X linhas são retornadas em T segundos. Este é um caso de testes simples e é conveniente armazenar outros valores para os três parâmetros, as linhas que eles retornam e o tempo de execução.

Depois que estas informações são armazenadas você já pode começar a otimizar a instrução SELECT. A cada nova técnica empregada verifica-se se houve um ganho de tempo de acordo com os valores dos parâmetros armazenados nos casos de teste e nas linhas retornadas.

Este procedimento pode parecer básico, mas isso é de extrema importância quando se está trabalhando com otimizações de instrução SQL e, infelizmente, poucas pessoas fazem isso de maneira pragmática e metódica no dia a dia.

8. Modifique ou exclua poucos dados por vez

Praticamente todos bancos de dados relacionais suportam o conceito de transações, sejam elas implícitas na instrução que modifica os dados (INSERT, UPDATE e DELETE), ou explícita pelo uso de comandos, como BEGIN TRANSACTION, ou similares . E para implementar este recurso há a necessidade de utilização de um log, que pode receber o nome de Transaction Log, Redo Log File, ou qualquer outro.

Utilizar log de transações gera uma implicação importante, que deve ser levada em consideração pelo desenvolvedor: o seu preenchimento. Geralmente, os bancos de dados possuem recursos manuais e automáticos para controlar como o log de transações é preenchido e limpo, porém fica a cargo do desenvolvedor saber que uma transação muito longa, ou seja, que afete muitas linhas, vai gerar um impacto significativo no log e também afetar o desempenho da instrução. Em poucas palavras: use transações curtas para se obter um bom desempenho, pois assim o log será preenchido de forma mais adequada e também serão minimizados os recursos de locks (ou qualquer outro mecanismo de controle de concorrência) necessários para a execução da instrução. Cabe ao desenvolvedor descobrir quando é pouco e quando é muito (em relação à quantidade de linhas por instrução) de acordo com o seu ambiente e modelo de dados.

Para ficar fácil de entender, basta imaginar a analogia do consumo do um bife. Você não vai querer comê-lo todo de uma vez (o que pode causar uma grande indigestão). É preciso cortá-lo em pedaços menores e abocanhá-los um por vez.

9. Cuidado com a recursividade

Trabalhar com recursividade em instruções SQL ainda é um desafio muito grande para diversos desenvolvedores. Apesar de já existirem soluções consolidadas, com muito tempo de mercado e até presentes no padrão SQL, não é raro encontrar instruções SQL não otimizadas para se trabalhar com recursividade. Além disso, ainda há a opção dos bancos NoSQL, que também permitem trabalhar com estruturas hierárquicas, em árvore, ou qualquer combinação entre elas de diversas maneiras.

De acordo com padrão SQL, existem um recurso chamado CTE (Common Table Expression), que permite manipular recursivamente partes de uma instrução SQL. Apesar de nem todos os bancos de dados implementarem este recursos em seus dialetos SQL, como o padrão sugere, ainda sim é possível fazer uso de CTEs em diversas situações. Do ponto de vista de entendimento prepare-se para encontrar instruções SELECT complexas e de difícil compreensão quando se emprega CTE. Do ponto de vista de desempenho, é muito fácil cair em uma recursão que realiza mais instruções do que uma solução interativa e, além disso, faz um uso excessivo da pilha interna que controla a recursividade.

Devido à estes fatores, deve-se utilizar com muita cautela soluções recursivas implementadas diretamente no SQL, principalmente pelo fato de já existirem diversos algoritmos e técnicas de manipulação de estruturas de dados otimizadas, testadas, conhecidas e estudadas para se realizar operações em estruturas hierárquicas.

10. Mantenha-se atualizado para aprender novas técnicas

Esta última técnica muitas vezes é menosprezada por profissionais mais experientes. Assim como o modelo de dados e as características do dado em si podem mudar a qualquer momento, os bancos de dados também evoluem (apesar do padrão SQL mais ou menos estacionado há algum tempo).

E isso quer dizer que as técnicas de otimização também devem evoluir. Algo que hoje é válido pode não ser mais depois de um curto período de tempo. Por exemplo, em certas versões de um banco de dado,s diversos livros, sites, blogs e vídeos indicavam que determinada técnica era melhor para otimizar o desempenho naquele momento. Mas com novas versões de bancos de dados, algumas destas técnicas não fazem mais sentido.

Por isso é importante ter sempre a consciência do contexto da técnica que está sendo aplicada. Muitas vezes o banco de dados é o mesmo, porém houve uma mudança na característica dos dados (seletividade, ordem, modelo, tipo de dados, etc) que tornaram certa otimização obsoleta e que não mais obtém o desempenho de outrora. Devido a isso, é sempre importante manter-se atualizado em relação não apenas ao que o mercado de banco de dados apresenta, mas também em relação ao ambiente na qual seus dados estão sendo manipulados.

Para finalizar, gostaria de fazer um pedido aos leitores: estou participando de um concurso que premiará as melhores histórias de otimização de desempenho. Bem, a minha entrada se chama “A day in a DBA Life” e os leitores que gostarem dela podem me ajudar clicando no botão “I Like this Story” nesta página (é preciso se logar no Facebook para votar).

Fonte: Mauro Pichiliani/IMaster

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

29

out
2011

Sem Comentários

Em Blog

Por Allison

REST tem impacto sobre NoSQL?

Em 29, out 2011 | Sem Comentários | Em Blog | 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/Lucas Machado

Tags | , , , , ,

20

out
2011

Sem Comentários

Em Blog

Por Allison

Versão 1.0 do Apache Cassandra é lançada

Em 20, out 2011 | Sem Comentários | Em Blog | Por Allison

A equipe de desenvolvimento do Cassandra anunciou a versão 1.0 do banco de dados altamente escalável, orientado a coluna e distribuído “NoSQL” Cassandra. O lançamento acontece apenas cinco meses depois da versão anterior, a 0.8.0.

Entre as melhorias da nova versão estão adição de suporte para a compressão de dados para reduzir o volume de dados no disco dos nós, implementação de melhorias na gerência de memória e de espaço em disco com o “off-heap storage” do cache em linha (row cache) e otimização automática das tabelas em memória.

Disponibilizado abertamente em julho de 2008, o Cassandra é um sistema de gerenciamento de banco de dados distribuído originalmente desenvolvido pelo Facebook.

O download do Cassandra 1.0.0 pode ser feito através de http://cassandra.apache.org/download/

Com Informações do NoSQL

Fonte: IMasters

Tags | , ,

30

set
2011

Sem Comentários

Em Blog

Por Allison

MongoDB 2.0 ganha novo serviço de monitoração em nuvem

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

Foi anunciado o MongoDB Monitoring Service (MMS), um novo serviço de monitoração no modelo SaaS (Software as a Service) para instâncias do MongoDB, o banco noSQL orientado a documentos, da 10Gen. A proposta do serviço é exigir o mínimo de configuração por parte dos usuários, e ainda assim disponibilizar uma monitoração de desempenho abrangente, incluindo detalhes sobre a utilização de recursos, disponibilidade, e tempos de resposta de instâncias do MongoDB.

O serviço é composto de uma interface web que se conecta aos agentes das instâncias do MongoDB. Diferentemente de ferramentas de monitoração genérica, o MMS consegue extrair dados mais precisos e informações específicas do MongoDB. O serviço MMS é gratuito e já está disponível para todos os usuários da ferramenta.

Lembrando que o novo release 2.0 MongoDB foi lançado há poucas semanas, com as seguintes melhorias e implementações:

  1. Melhoria no processo de concorrência: Em certas operações (atualização por id, remoções e longas iterações de cursores), o servidor irá evitar a escrita de locks, quando os dados não estiverem em memória e for necessário o acesso a disco rígido.
  2. Melhoria no tamanho e na performance dos índices: houve ganho de aproximadamente 25%, tanto em diminuição do tamanho quanto aumento de desempenho, na criação e execução de índices. (Se houver índices criados em versões anteriores do MongoDB, será necessário a reconstrução dos índices para que se beneficiem destas melhorias.).
  3. Journaling: Para plataformas de 64bits, o sistema de journaling será habilitado por padrão, e será comprimido para permitir commits mais rápidos no disco. Agora o intervalo entre commits (100 ms por padrão) pode ser redefinido através de parâmetros de configuração.

Todas as novas implementações do MongoDB podem ser vistas nos release notes.

Fonte: Rafael Nunes/InfoQ

Tags | , , ,

17

set
2011

Sem Comentários

Em Blog

Por Allison

Um olhar sobre alguns bancos de dados NoSQL

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

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.

MongoDB

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.

Redis

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.

Basho Riak

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.

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/

Fonte: Mikayel Vardanyan/Imaster

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