Consideraes sobre o Banco de Dados Apache Cassandra

http://www.ibm.com/developerworks/br/library/os-apache-cassandra/

Portugus (Brasil)

Conecte-se (ou Registrar)

Itens Tcnicos

Downloads e Trials

Comunidade

Consideraes sobre o Banco de Dados Apache Cassandra

Quais so as vantagens e desvantagens desse banco de dados NoSQL? Srinath Perera, Senior Software Architect, WSO2 Inc Resumo: O armazenamento NoSQL uma alternativa flexvel e escalvel aos bancos de dados relacionais, e, entre esses armazenamentos, Cassandra uma das escolhas mais populares. V alm dos detalhes mais conhecidos e explore os detalhes mais obscuros com Cassandra. Ser possvel explorar o modelo de dados do Cassandra, design do esquema de armazenamento, arquitetura e surpresas em potencial associadas a essa soluo. Data: 20/Jul/2012 Nvel: Introdutrio Tambm disponvel em : Ingls Atividade: 5071 visualizaes Comentrios: 0 (Visualizar | Incluir comentrio - Conectar) Mdia de classificao (6 votos) Classificar este artigo

Introduo No artigo sobre a histria dos bancos de dados "What Goes Around Comes Around" (consulte Recursos), Michal Stonebraker descreve em detalhes o desenvolvimento das tcnicas de armazenamento ao longo do tempo. Antes de chegar ao modelo relacional, os desenvolvedores tentaram outros modelos, como hierrquico e de grfico direcionado. importante observar que o modelo relacional baseado em SQL que o padro de facto mesmo agora prevalece h quase 30 anos. Dada a breve histria e rpido ritmo da cincia da computao, esse um feito notvel. O modelo relacional est to bem estabelecido que, por muitos anos, a escolha de um armazenamento de dados para um aplicativo era fcil para o arquiteto de soluo. A escolha era invariavelmente um banco de dados relacional. Desenvolvimentos como o aumento das bases de usurio dos sistemas, dispositivos mveis, maior presena dos usurios online, computao em nuvem e sistemas com mais de um ncleo levaram a sistemas com escala cada vez maior. Empresas de alta tecnologia como Google e Amazon foram os primeiros a atingir esses problemas de escala. Logo eles descobriram que bancos de dados relacionais no so adequados para suportar sistemas em larga escala. Para enfrentar esses desafios, Google e Amazon inventaram duas solues alternativas: Big Table e Dynamo (consulte Recursos), nos quais eles diminuram as garantias proporcionadas pelo modelo de dados relacionais para obter maior escalabilidade. O "Teorema CAP", de Eric Brewer, (consulte Recursos) formalizou posteriormente essas observaes. O artigo afirma que, para sistemas escalveis, tolerncia a partio, disponibilidade e consistncia esto em relao de compensao, sendo impossvel desenvolver sistemas contendo todas essas propriedades. Logo, com base em um trabalho anterior da Google e da Amazon e com o conhecimento adquirido dos sistemas escalveis, uma nova classe de sistemas de armazenamento foi proposta. Eles foram chamados de sistemas "NoSQL". O nome primeiramente significava "no use SQL se voc quer fazer ajuste de escala" e depois foi redefinido para "no apenas SQL", significando que h outras solues alm das que usam SQL. H muitos sistemas NoSQL, e cada um diminui ou altera algum aspecto do modelo relacional. importante observar que nenhuma das solues NoSQL funciona para todos os cenrios. Cada uma supera modelos relacionais e faz ajuste de escala para alguns subconjuntos dos casos de uso. Meu artigo anterior "Finding the Right Data Solution for Your Application in the Data Storage Haystack" discute como associar requisitos de aplicativo a solues NoSQL (consulte Recursos). Apache Cassandra (consulte Recursos) uma das primeiras e mais usadas solues NoSQL. Este artigo examina Cassandra e aponta alguns detalhes e pontos difceis que no so aparentes quando voc observa a soluo pela primeira vez. Apache Cassandra Cassandra uma implementao de famlia de colunas NoSQL que suporta o modelo de dados Big Table e usa aspectos de arquitetura introduzidos por Amazon Dynamo. Alguns dos pontos positivos do Cassandra so: Altas escalabilidade e disponibilidade, sem um ponto nico de falha Implementao da famlia de colunas NoSQL Rendimento de gravao muito alto e bom rendimento de leitura Linguagem de consulta semelhante a SQL (desde 0.8) e suporte para procura por ndices secundrios Consistncia ajustvel e suporte para replicao Esquema flexvel

1 de 10

12/06/2013 01:41

Consideraes sobre o Banco de Dados Apache Cassandra

http://www.ibm.com/developerworks/br/library/os-apache-cassandra/

Esses pontos positivos tornam fcil recomendar o Cassandra, mas fundamental para um desenvolvedor observar os detalhes e pontos difceis da soluo para conhecer os detalhes desse programa. Cassandra armazena dados de acordo com o modelo de dados de famlia de colunas, demonstrado na Figura 1.

Figura 1. Modelo de dados do Cassandra

O que uma coluna?

Coluna no um nome muito apropriado, e talvez o nome clula fosse mais fcil de entender. Continuarei usando coluna por ser de uso comum. O modelo de dados do Cassandra consiste em colunas, linhas, famlias de colunas e keyspaces. Vejamos cada parte em detalhes. Coluna - a unidade mais bsica do modelo de dados do Cassandra, contendo um nome, um valor e um registro de data e hora. Para esta discusso, ignore o registro de data e hora e voc poder representar a coluna como um par de nome e valor (como author="Asimov"). Linha - uma coleo de colunas rotuladas com um nome. Por exemplo, a Listagem 1 mostra como uma linha poderia ser representada: Listagem 1. Exemplo de uma linha
"Second Foundation"-> { author="Asimov", publishedDate="..", tag1="sci-fi", tag2="Asimov" }

O Cassandra consiste em muitos ns de armazenamento e armazena cada linha em um nico n. Em cada linha, Cassandra sempre armazena as colunas classificadas por seus nomes. Usando essa ordem de classificao, o Cassandra suporta consultas de fatia, nas quais, dada uma linha, os usurios podem recuperar um subconjunto de suas colunas que estejam em um dado intervalo de nomes de coluna. Por exemplo, uma consulta de fatia com o intervalo tag0 a tag9999 retornar todas as colunas cujos nomes esto entre tag0 e tag9999. Famlia de colunas - uma coleo de linhas rotuladas com um nome. A Listagem 2 mostra um exemplo de dados: Listagem 2. Exemplo de uma famlia de colunas
Books->{ "Foundation"->{author="Asimov", publishedDate=".."}, "Second Foundation"->{author="Asimov", publishedDate=".."}, }

Dizem frequentemente que uma famlia de colunas como uma tabela no modelo relacional. Como o exemplo anterior mostra, as semelhanas so apenas essas.

2 de 10

12/06/2013 01:41

Consideraes sobre o Banco de Dados Apache Cassandra

http://www.ibm.com/developerworks/br/library/os-apache-cassandra/

Keyspace um grupo de vrias famlias de colunas juntas. apenas um agrupamento lgico de famlias de colunas e fornece um escopo isolado para nomes. Por fim, as supercolunas residem em uma famlia de colunas que agrupa vrias colunas em uma nica chave. Como os desenvolvedores recomendam no usar supercolunas, eu no as discutirei aqui. Cassandra versus modelos de dados RDBMS Pela descrio do modelo de dados do Cassandra acima, os dados so colocados em um espao bidimensional (2D) em cada famlia de colunas. Para recuperar dados em uma famlia de colunas, os usurios precisam de duas chaves: nome da linha e nome da coluna. Nesse sentido, o modelo relacional e o do Cassandra so semelhantes, embora haja vrias diferenas fundamentais. As colunas relacionais so homogneas em todas as linhas na tabela. Existe geralmente um relacionamento vertical claro entre os itens de dados, o que no o caso com as colunas do Cassandra. Esse o motivo pelo qual Cassandra armazena o nome da coluna em cada item de dados (coluna). Com o modelo relacional, o espao de dados 2D completo. Cada ponto no espao 2D deve ter ao menos o valor nulo armazenado. Novamente, esse no o caso do Cassandra, que pode ter linhas contendo apenas alguns itens enquanto outras tm muitos itens. Com um modelo relacional, o esquema predefinido e no pode ser alterado no tempo de execuo, enquanto o Cassandra permite que os usurios alterem o esquema no tempo de execuo. O Cassandra sempre armazena dados de forma que as colunas sejam classificadas de acordo com seus nomes. Isso facilita a procura de dados em uma coluna usando consultas de fatia, mas mais difcil procurar dados em uma linha, a menos que o usurio use um particionador que preserve a ordem. Outra diferena fundamental que os nomes de colunas em RDMBS representam metadados sobre os dados, mas nunca os dados. No entanto, no Cassandra os nomes das colunas podem incluir dados. Consequentemente, as linhas do Cassandra podem ter muitas colunas, enquanto um modelo relacional geralmente tem poucas colunas. Usando um esquema imutvel bem-definido, os modelos relacionais suportam consultas sofisticadas que incluem JOINs, agregaes e mais. Com um modelo relacional, os usurios podem definir o esquema de dados sem se preocupar com consultas. O Cassandra no suporta JOINs e a maioria dos mtodos de procura de SQL. Portanto, os esquemas devem ser ajustados para as consultas exigidas pelo aplicativo. Para explorar as diferenas acima, imagine um site de classificao de livros no qual os usurios podem adicionar livros (autor, classificao, preo, link), comentrios (texto, hora, nome) e tags. O aplicativo precisa suportar as seguintes operaes dos usurios: Incluir livros Incluir comentrios para livros Incluir tags para livros Listar livros ordenados por classificao Listar livros por uma tag especfica Listar os comentrios dado um ID de livro bem comum implementar o aplicativo acima com um modelo relacional. A Figura 2 mostra o relacionamento Entityrelationship (ER) para o design do banco de dados.

Figura 2. Modelo ER do site de classificao de livros

Vejamos como isso pode ser implementado usando o modelo de dados do Cassandra. A Listagem 3 mostra um esquema potencial com o Cassandra, no qual a primeira linha representa a famlia de colunas "Books" que possui diversas linhas, cada uma com propriedades do livro como colunas. <TS1> e <TS2> indicam registros de data e hora.

Listagem 3. Esquema do Cassandra para a amostra de classificao de livros

Books[BookID->(author, rank, price, link, tag<TS1>, tag<TS2> .., cmt+<TS1>= text + "-" + author) ] Tags2BooksIndex[TagID->(<TS1>=bookID1, <TS2>=bookID2, ..) ]

3 de 10

12/06/2013 01:41

Consideraes sobre o Banco de Dados Apache Cassandra

http://www.ibm.com/developerworks/br/library/os-apache-cassandra/

Tags2AuthorsIndex[TagID->(<TS1>=bookID1, <TS2>=bookID2, ..) ] RanksIndex["RANK" -> (rank<TS1>=bookID)]

A Tabela 1 um conjunto de dados de amostra de acordo com o esquema.

Tabela 1. Dados de amostra para o site de classificao de livros Nome da Famlia de Conjunto de Dados de Exemplo Colunas Books "Foundation" -> ("author"="Asimov", "rank"=9, "price"=14, "tag1"="sci-fi", "tag2"="future", "cmt1311031405922"="best book-sanjiva", "cmt1311031405923"="well I disagree-srinath") "I Robot" -> ("author"="Asimov", "rank"=7, "price"=14, "tag1"="sci-fi" "tag2"="robots", "cmt1311031405924"="Asimov's best-srinath", "cmt1311031405928"="I like foundation better-sanjiva") RanksIndex "Rank" -> (9="Foundation", 7="I Robot") Tags2BooksIndex "sci-fi" -> ("1311031405918"="Foundation", "1311031405919"="I Robot" "future" -> Tags2AuthorsIndex "sci-fi" -> (1311031405920="Asimov") "future" -> Esse exemplo mostra vrias diferenas de design entre os modelos relacional e do Cassandra. O modelo do Cassandra armazena os dados sobre livros em uma nica famlia de colunas chamada "Books", e as trs outras famlias de colunas so ndices criados para suportar consultas. Ao examinar a coluna "Books", vemos que o modelo usa uma linha para representar cada livro, com o nome do livro como o ID da linha. Os detalhes do livro so representados como colunas armazenadas na linha. Observando mais detalhadamente, podemos perceber que os itens de dados armazenados (como comentrios e tags que tm um relacionamento 1:M com os livros) tambm esto em uma nica linha. Para fazer isso, anexe o registro de data e hora aos nomes das colunas de tags e comentrios. Essa abordagem armazena todos os dados na mesma coluna. Essa ao evita ter que fazer JOINs para recuperar dados. O Cassandra contorna a ausncia de suporte a JOINs atravs dessa abordagem. Isso proporciona vrias vantagens. possvel ler todos os dados sobre um livro atravs de uma nica consulta lendo a linha completa. possvel recuperar comentrios e tags sem um JOIN usando consultas de fatia que tenham cmt0-cmt9999 e tag0-tag9999 como intervalos de incio e fim. Como o Cassandra armazena colunas classificadas por seus nomes, as consultas de fatia so muito rpidas. importante observar que a classificao de todos os detalhes de um item de dados em uma nica linha e o uso de classificaes de ordem so as ideias mais importantes por trs do design de dados do Cassandra. A maioria dos designs de modelo de dados do Cassandra segue essas ideias em alguma forma. O usurio pode usar as ordens de classificao ao armazenar dados e criar ndices. Por exemplo, outro efeito adverso de anexar registros de data e hora a nomes de coluna que, como esses nomes so armazenados na ordem classificada, os comentrios com nomes de coluna seguidos pelo registro de data e hora so armazenados na ordem em que foram criados, e os resultados de pesquisa teriam a mesma ordem. O Cassandra no suporta mtodos de procura com o design bsico. Embora suporte ndices secundrios, estes so suportados usando ndices criados posteriormente e possuem vrias limitaes, incluindo ausncia de suporte para consultas por intervalo. Consequentemente, para obter os melhores resultados em um design de dados do Cassandra, necessrio que usurios implementem procuras criando ndices customizados e utilizando ordens de classificao de coluna e de linha. Outras famlias de trs colunas (Tags2BooksIndex, Tags2AuthorsIndex e RankIndex) fazem exatamente isso. Como os usurios precisam procurar livros dada uma tag, a famlia de colunas "Tags2BooksIndex" cria um ndice ao armazenar o nome da tag como ID de linha e todos os livros com essa tag como colunas sob a linha. Como mostra o exemplo, registros de data e hora so includos como chaves de coluna, mas isso para fornecer um ID de coluna exclusivo. A implementao de procura simplesmente l o ndice consultando a linha por nome de tag e localizando as correspondncias ao ler todas as colunas armazenadas nesse ID de linha. A Tabela 2 discute como cada uma das consultas exigidas pelo aplicativo implementada usando os ndices do Cassandra acima.

Tabela 2. Comparao de implementaes de consulta Descrio da consulta Consulta como SQL Implementao do Cassandra Listar livros ordenados por Executar a consulta Realizar uma consulta de fatia na famlia de colunas classificao "Selecionar * da ordem Books por classificao" e "RankIndex" para receber uma lista ordenada de em cada resultado "Selecionar tag de Tags em que livros e, para cada livro, realizar uma consulta de bookid=?" e "Selecionar comentrio de Comments fatia na famlia de colunas "Books" para ler os em que bookid=?" detalhes do livro. Selecionar autor distinto de Tags, Books em que Ler todas as colunas procura da tag dada em Dada uma tag, localizar os Tags2Authors usando uma consulta de fatia. autores cujos livros possuem Tags.bookid=Books.bookid e tag=? essa tag. Dada uma tag, localizar livros Selecionar bookid em Tags em que tag=? Ler todas as colunas procura da tag dada em que possuem essa tag. Tags2BooksIndex usando uma consulta de fatia.

4 de 10

12/06/2013 01:41

Consideraes sobre o Banco de Dados Apache Cassandra

http://www.ibm.com/developerworks/br/library/os-apache-cassandra/

Dado um livro, listar seus Selecionar text, time, user em Comments em que comentrios na ordem de bookid=? Classificar por hora classificao da hora em que os comentrios foram criados.

Na famlia de colunas "Books", realizar uma consulta de fatia na linha correspondente ao livro dado. Elas esto na ordem de classificao devido aos registros de data e hora usados como nome da coluna.

Embora o design acima possa suporta eficientemente consultas exigidas pelo site de classificao de livros, ele pode suportar apenas as consultas para as quais foi projetado e no suporta consultas ad hoc. Por exemplo, ele no pode realizar as consultas a seguir sem criar novos ndices.
Selecionar * em Books em que price > 50; Selecionar * em Books em que author="Asimov"

Para alterar o design para suportar essas e outras consultas, possvel criar ndices apropriados ou criar cdigo para passar pelos dados. No entanto, a necessidade de cdigo customizado para suportar novas consultas uma limitao em relao aos modelos relacionais nos quais incluir novas consultas geralmente no demanda alteraes no esquema. A partir do release 0.8, o Cassandra suporta ndices secundrios, nos quais os usurios podem especificar uma procura por uma propriedade dada, e o Cassandra automaticamente cria ndices de procura com base nessa propriedade. No entanto, esse modelo oferece menos flexibilidade. Por exemplo, ndices secundrios no suportam consultas de intervalo e no garantem ordens de classificao nos resultados. Usando o Cassandra a partir do ambiente Java O Cassandra possui muitos clientes escritos em diferentes linguagens. Este artigo foca no cliente Hector (consulte Recursos), que o cliente Java mais usado para Cassandra. Os usurios podem aprimorar seus aplicativos incluindo os JARs do Hector no caminho de classe do aplicativo. A Listagem 4 mostra um cliente Hector de amostra. Primeiro, conecte-se a um cluster do Cassandra. Use as instrues na pgina de Introduo ao Cassandra (consulte Recursos) para configurar um n do Cassandra. A menos que sua configurao tenha sido alterada, ele executa na porta 9160. A seguir, defina um keyspace. Isso pode ser feito atravs do cliente ou do arquivo de configurao conf/cassandra.yaml.

Listagem 4. Cdigo de cliente Hector de amostra para o Cassandra

Cluster cluster = HFactory.createCluster('TestCluster', new CassandraHostConfigurator("localhost:9160")); //define a keyspace Keyspace keyspace = HFactory.createKeyspace("BooksRating", cluster); //Now let's add a new column. String rowID = "Foundation"; String columnFamily = "Books"; Mutator<String> mutator = HFactory.createMutator(keyspace, user); mutator.insert(rowID, columnFamily, HFactory.createStringColumn("author", "Asimov")); //Now let's read the column back ColumnQuery<String, String, String> columnQuery = HFactory.createStringColumnQuery(keyspace); columnQuery.setColumnFamily(columnFamily).setKey(wso2).setName("address"); QueryResult<HColumn<String, String> result = columnQuery.execute(); System.out.println("received "+ result.get().getName() + "= " + result.get().getValue() + " ts = "+ result.get().getClock());

O cdigo completo do exemplo de classificao de livros encontra-se em Download. . Ele inclui amostras de consultas de fatia e outras operaes complexas. Arquitetura do Cassandra Tendo examinado o modelo de dados do Cassandra, vamos retornar a sua arquitetura para entender alguns de seus pontos positivos e negativos do ponto de vista de sistemas distribudos. A Figura 3 mostra a arquitetura de um cluster do Cassandra. A primeira observao que o Cassandra um sistema distribudo. O Cassandra consiste em vrios ns e distribui os dados entre eles (ou divide-os em shards, na terminologia de bancos de dados).

Figura 3. Cluster do Cassandra

5 de 10

12/06/2013 01:41

Consideraes sobre o Banco de Dados Apache Cassandra

http://www.ibm.com/developerworks/br/library/os-apache-cassandra/

O Cassandra usa hashing consistente para designar itens de dados a ns. Em termos simples, o Cassandra usa um algoritmo hash para calcular o hash de chaves de cada item de dados armazenado nele (por exemplo, nome de coluna, ID de linha). O intervalo de hash, ou todos os valores de hash possveis (tambm chamado de keyspace), dividido entre os ns no cluster do Cassandra. Em seguida, o Cassandra designa cada item de dados ao n, e esse n responsvel por armazenar e gerenciar o item de dados. O artigo "Cassandra - A Decentralized Structured Storage System" (consulte Recursos) discute em detalhes a arquitetura do Cassandra. A arquitetura resultante fornece as seguintes propriedades: O Cassandra distribui dados entre seus ns de forma transparente para o usurio. Qualquer n pode aceitar qualquer solicitao (leitura, gravao ou excluso) e encaminh-la ao n correto, mesmo que os dados no estejam armazenados nesse n. Os usurios podem definir quantas rplicas so necessrias, e o Cassandra cuida da criao e gerenciamento de rplicas de forma transparente. Consistncia ajustvel: ao armazenar e ler dados, os usurios podem escolher o nvel de consistncia esperado em cada operao. Por exemplo, quando o nvel de consistncia "quorum" usado ao gravar ou ler, os dados so gravados e lidos em mais de metade dos ns no cluster. O suporte a consistncia ajustvel permite que os usurios escolham o melhor nvel de consistncia para o caso de uso. O Cassandra fornece gravaes muito rpidas (at mesmo mais rpidas que as leituras), transferindo dados a cerca de 80-360 MB/s por n. Para isso, ele usa duas tcnicas. O Cassandra mantm a maior parte dos dados na memria do n responsvel. As atualizaes so feitas na memria e gravadas no armazenamento persistente (sistema de arquivos) de forma lenta. No entanto, para evitar a perda de dados, ele grava todas as transaes em um log de confirmao no disco. Ao contrrio da atualizao de itens de dados no disco, as gravaes em logs de confirmao envolvem apenas anexao e, portanto, evitam o atraso de rotao ao gravar no disco. Para obter mais informaes sobre as caractersticas de desempenho em unidade de disco, consulte Recursos. A menos que a gravao tenha solicitado consistncia total, o Cassandra grava dados em ns suficientes sem resolver inconsistncias de dados, resolvendo-as apenas na primeira leitura. Esse processo chamado de "reparo na leitura". A arquitetura resultante altamente escalvel: possvel desenvolver um cluster do Cassandra com vrios ns, que capaz de lidar com terabytes a petabytes de dados. H uma compensao em sistemas distribudos, e escala quase nunca vem gratuita. Como mencionamos, um usurio pode encontrar muitas surpresas ao passar de um banco de dados relacional para o Cassandra. A prxima sesso discute algumas delas. Possveis surpresas com o Cassandra Fique atento a essas diferenas ao passar de um banco de dados relacional para o Cassandra. Sem transaes, sem JOINs fato conhecido que o Cassandra no suporta transaes ACID. Embora tenha uma operao em lote, no garantido que suboperaes dentro da operao em lote sejam realizadas de forma atmica. Isso ser discutido melhor em Operaes com falha podem deixar mudanas. Alm disso, o Cassandra no suporta JOINs. Quando um usurio precisa unir duas famlias de colunas, necessrio recuperar e unir os dados programaticamente. Isso geralmente caro e demorado para grandes conjuntos de dados. Para contornar essa limitao, o Cassandra armazena o mximo de dados possvel na mesma linha, como descrito no exemplo. Sem chaves estrangeiras. As chaves so imutveis O Cassandra no suporta chaves estrangeiras, portanto, no pode gerenciar a consistncia de dados para o usurio. Por isso, o aplicativo deve lidar com a consistncia de dados. Alm disso, os usurios no podem alterar as chaves. Recomenda-se usar surrogate keys (chaves geradas em vez da chave e gerenciando estas como uma propriedade) com os casos de uso que precisam de alteraes nas chaves.

6 de 10

12/06/2013 01:41

Consideraes sobre o Banco de Dados Apache Cassandra

http://www.ibm.com/developerworks/br/library/os-apache-cassandra/

As chaves devem ser exclusivas Cada chave (por exemplo, chaves de linha e chaves de coluna) deve ser exclusiva em seu escopo. Caso a mesma chave seja usada duas vezes, os dados sero sobrescritos. H duas solues para esse problema. Primeiro, possvel usar uma chave composta. Em outras palavras, criar a chave combinando vrios campos. Essa soluo usada frequentemente com chaves de linha. A segunda soluo, quando h o risco de uma mesma chave ocorrer duas vezes, incluir na chave um valor aleatrio ou registro de data e hora. Isso frequentemente acontece com ndices, quando um ndice armazena um valor como nome da coluna. Por exemplo, no aplicativo de classificao de livros, a classificao foi usada como nome da coluna. Para evitar que duas entradas tenham o mesmo nome de coluna por terem a mesma classificao, o registro de data e hora includo aps o nome. Operaes com falha podem deixar mudanas Como explicado acima, o Cassandra no suporta operaes atmicas. Em vez disso, suporta operaes idempotentes. As operaes idempotentes deixam o sistema no mesmo estado, independentemente de quantas vezes so realizadas. Todas as operaes do Cassandra so idempotentes. Se uma operao falhar, possvel tentar novamente sem problemas. Isso um mecanismo para recuperao de falhas temporrias. Alm disso, o Cassandra suporta operaes em lote, mas elas tambm no tm garantia de atomicidade. Como as operaes so idempotentes, o cliente pode continuar tentando at que todas as operaes do lote tenham xito. Operaes idempotentes no so o mesmo que operaes atmicas. Quando a operao tem xito, tudo fica bem e a sada idntica s operaes atmicas. Quando uma operao falha, o cliente pode tentar de novo e, se tiver sucesso, tudo estar bem novamente. Se, no entanto, a operao falhar mesmo aps tentar novamente, possvel que ela deixe efeitos colaterais, ao contrrio das operaes atmicas. Infelizmente, com o Cassandra, essa uma complexidade com a qual os programadores precisam lidar por si mesmos. A procura complicada A procura no integrada no ncleo da arquitetura do Cassandra, e mecanismos de procura so includos usando ordens de classificao, como descrito anteriormente. O Cassandra suporta ndices secundrios, criados automaticamente pelo sistema, com funcionalidade limitada. Quando os ndices secundrios no funcionam, os usurios precisam aprender sobre o modelo de dados e desenvolver ndices usando ordens de classificao e fatias. Trs tipos de rea de complexidade associados criao de mtodos de procura: 1. Para criar mtodos de procura customizados, os programadores precisam entender indexao e detalhes sobre armazenamento em certo grau. Portanto, o Cassandra requer desenvolvedores mais qualificados que os modelos relacionais. 2. Os ndices customizados dependem muito de ordens de classificao, e so complicados. H dois tipos de ordem de classificao: primeiro, as colunas so sempre classificadas por nome. Segundo, as ordens de classificao de linha funcionam apenas se um particionador que preserva a ordem (consulte Recursos) for usado. 3. A incluso de novas consultas geralmente demanda mais mudanas nos ndices e cdigo, ao contrrio de modelos relacionais. Isso exige que desenvolvedores analisem consultas antes de armazenar os dados. Recomenda-se no usar supercolunas e particionadores de preservao As supercolunas do Cassandra podem ser teis ao modelar dados em mais de um nvel, situao na qual o Cassandra inclu mais um nvel na hierarquia. No entanto, tudo que pode ser modelado com supercolunas tambm pode ser suportado atravs de colunas. Portanto, as supercolunas no fornecem eficincia adicional. Alm disso, elas tambm no suportam ndices secundrios. Portanto, os desenvolvedores do Cassandra recomendam no usar supercolunas. Embora no haja uma data firme para descontinuar o suporte, isso pode acontecer em liberaes futuras. Um particionador no Cassandra decide como distribuir (dividir em shards) dados entre os ns do Cassandra, e h muitas implementaes. Caso seja usado um particionador que preserva a ordem, os IDs de linha so armazenados na ordem de classificao e o Cassandra pode realizar fatias (procuras) em IDs de linha. Esse particionador no distribui os dados de maneira uniforme entre seus ns. No entanto, com grandes conjuntos de dados, alguns dos ns podem estar ocupados enquanto outros possuem carga leve. Por isso, os desenvolvedores tambm recomendam no usar particionadores que preservam a ordem. A recuperao da falha manual Quando um n em um cluster do Cassandra falha, o cluster continua funcionando se houver rplicas. A recuperao completa, que redistribuir dados e compensar pelas rplicas perdidas, uma operao manual atravs da ferramenta de linha de comandos chamada ferramenta node (consulte Recursos). . Alm disso, enquanto a operao manual realizada, o sistema estar indisponvel. Ele se lembra de excluses O Cassandra projetado de forma que continua a funcionar sem problema mesmo que um n fique inativo (ou seja, desconectado) e retorne depois. Uma consequncia que isso complica a excluso de dados. Por exemplo, imagine que um n est inativo. Enquanto ele est inativo, um item de dados excludo nas rplicas. Quando o n indisponvel retorna, ele reapresenta o item de dados excludo no processo de sincronizao, a menos que o Cassandra se lembre de que esse item foi excludo. Portanto, o Cassandra precisa lembrar que o item de dados foi excludo. No release 0.8, o Cassandra estava lembrando-se de todos os dados, mesmo se fossem excludos. Isso fazia com que o uso do disco aumentasse continuamente em operaes com muitas atualizaes. O Cassandra no precisa se lembrar de todos os dados excludos, mas apenas do fato de quem um item de dados foi excludo. Essa correo foi feita em liberaes posteriores do Cassandra.

7 de 10

12/06/2013 01:41

Consideraes sobre o Banco de Dados Apache Cassandra

http://www.ibm.com/developerworks/br/library/os-apache-cassandra/

Concluso Este artigo mostra alguns detalhes que no so aparentes quando se pensa no Cassandra. Eu descrevi o modelo de dados do Cassandra, comparando com o modelo de dados relacional, e demonstrei um design de esquema tpico. Uma observao importante que, ao contrrio do modelo relacional, que divide os dados em vrias tabelas, o Cassandra tende a manter o mximo possvel dos dados na mesma linha, para evitar ter que unir os dados para recuperao. Voc tambm viu vrias limitaes da abordagem baseada no Cassandra. Essas limitaes, no entanto, so iguais na maioria das solues de NoSQL e so, geralmente, renunciadas conscientemente em nome da alta escalabilidade.

Download Descrio Book rating sample code Informaes sobre mtodos de download Nome CassandraSample.zip Tamanho 42KB Mtodo de download HTTP

Recursos Aprender Leia What goes around comes around (Michael Stonebraker e Joey Hellerstein, 2007), se tiver interesse na histria das tecnologias de armazenamento. Leia Pgina de Introduo no Wiki do Cassandra para instalar o Cassandra, execut-lo com um nico n e ter uma viso geral de como configurar clusters com mais de um n. Leia o artigo Cassandra - A Decentralized Structured Storage System (Avinash Lakshman e Prashant Malik, 2009) para entender a arquitetura do Cassandra mais detalhadamente. Leia mais sobre Big Table, da Google, e Dynamo, da Amazon. Leia sobre o teorema de CAP de Eric Brewer (Julian Browne, janeiro de 2009). Consulte Finding the Right Data Solution for Your Application in the Data Storage Haystack (Srinath Perera, InfoQ, outubro de 2011), para obter uma viso geral do cenrio de NoSQL com recomendaes a fim de escolher o armazenamento NoSQL certo. Saiba mais sobre caractersticas de desempenho de unidade de disco na Wikipdia. Leia sobre ferramenta node, uma simples interface da linha de comandos para essas operaes e atributos expostos no Wiki do Cassandra. Encontre mais detalhes sobre nveis de consistncia no wiki da API do Cassandra. Leia mais sobre configuraes de armazenamento. A rea de Software Livre no developerWorks fornece muitas informaes sobre ferramentas de software livre e de como utilizar tecnologias de software livre. Fique por dentro dos Eventos tcnicos e webcasts do developerWorks com nfase em uma srie de produtos IBM e tpicos do segmento de mercado de TI. Participe de um briefing gratuito do developerWorks Live! para se informar sobre os produtos e ferramentas IBM, alm das tendncias do mercado de TI. Acompanhe as demos on demand do developerWorks , que abrangem desde demos de instalao e configurao de produtos para iniciantes at funcionalidades avanadas para desenvolvedores experientes. Siga o developerWorks no Twitter.

Obter produtos e tecnologias Explore o Cassandra no website do projeto. Confira o cliente Hector no website do projeto.

8 de 10

12/06/2013 01:41

Consideraes sobre o Banco de Dados Apache Cassandra

http://www.ibm.com/developerworks/br/library/os-apache-cassandra/

Faa download do Cassandra e encontre instrues sobre como us-lo em cassandra.apache.org. Avalie produtos IBM da maneira que for melhor para voc: faa download da verso de teste de um produto, avalie um produto on-line, use-o em um ambiente de nuvem ou passe algumas horas na SOA Sandbox para saber mais sobre como implementar arquitetura orientada a servio (SOA) de maneira eficiente.

Discutir Confira blogs do developerWorks e participe da comunidade do developerWorks. Participe da comunidade do developerWorks. Entre em contato com outros usurios do developerWorks e explore os blogs, fruns, grupos e wikis voltados para desenvolvedores.

Sobre o autor

Srinath arquiteto de software senior na WSO2 Inc., onde supervisiona a arquitetura geral da plataforma WSO2 com o CTO. Ele tambm trabalha como cientista pesquisador na Fundao Lanka Software e professor visitante do Departamento de Engenharia e Cincia da Computao da Universidade de Moratuwa. cofundador do Apache Axis2 e tem participado do projeto Apache Web Service desde 2002. Tambm membro da Apache Software Foundation, PMC e do projeto Apache Web Service. Srinath tambm committer de Axis, Axis2 e Geronimo, projetos de software livre do Apache. Ele possui doutorado e mestrado em cincia da computao pela Universidade de Indiana, Bloomington, EUA, e bacharelado em Cincia e Engenharia da Computao pela Universidade de Moratuwa, Sri Lanka. Fechar [x]

developerWorks: Registre-se
IBM ID: Precisa de um ID IBM? Esqueceu seu ID IBM? Senha: Esqueceu sua senha? Alterar sua senha Mantenha-me conectado. Ao clicar em Enviar, voc concorda com os termos de uso do developerWorks.

Na primeira vez que voc efetua sign in no developerWorks, um perfil criado para voc. Informaes selecionadas do seu perfil developerWorks so exibidas ao pblico, mas voc pode edit-las a qualquer momento. Seu primeiro nome, sobrenome (a menos que escolha ocult-los), e seu nome de exibio acompanharo o contedo que postar. Todas as informaes enviadas so seguras. Fechar [x]

Selecione seu nome de exibio

Ao se conectar ao developerWorks pela primeira vez, criado um perfil para voc e necessrio selecionar um nome de exibio. O nome de exibio acompanhar o contedo que voc postar no developerWorks. Escolha um nome de exibio de 3 - 31 caracteres. Seu nome de exibio deve ser exclusivo na comunidade do developerWorks e no deve ser o seu endereo de email por motivo de privacidade. Nome de exibio: (Deve possuir de 3 a 31 caracteres.)

Ao clicar em Enviar, voc concorda com os termos de uso do developerWorks.

9 de 10

12/06/2013 01:41

Consideraes sobre o Banco de Dados Apache Cassandra

http://www.ibm.com/developerworks/br/library/os-apache-cassandra/

Todas as informaes enviadas so seguras. Mdia de classificao (6 votos) 1 estrela 1 estrela 2 estrelas 2 estrelas 3 estrelas 3 estrelas 4 estrelas 4 estrelas 5 estrelas 5 estrelas

Incluir comentrio: Conectar or registre-se para deixar um comentrio. Observao: elementos HTML no so suportados nos comentrios.

Notificar-me quando um comentrio for adicionado1000 caracteres restantes

Nenhum comentrio postado para esse artigo

Imprimir esta pgina Compartilhe esta pgina Siga o developerWorks

Sobre Ajuda Entre em contato conosco

Feeds

Relatar abuso Termos de uso Privacidade

Acessibilidade (Ingls) IBM Academic Initiative Programa IBM de Parceria com empresas de software (ISVs) Programa Global de Empreendedorismo

10 de 10

12/06/2013 01:41