Considerações sobre o Banco de Dados Apache Cassandra

Quais são as vantagens e desvantagens desse banco de dados NoSQL?

O armazenamento NoSQL é uma alternativa flexível e escalável aos bancos de dados relacionais, e, entre esses armazenamentos, Cassandra é uma das escolhas mais populares. Vá além dos detalhes mais conhecidos e explore os detalhes mais obscuros com Cassandra. Será possível explorar o modelo de dados do Cassandra, design do esquema de armazenamento, arquitetura e surpresas em potencial associadas a essa solução.

Srinath Perera, Senior Software Architect, WSO2 Inc

Srinath PereraSrinath é arquiteto de software senior na WSO2 Inc., onde supervisiona a arquitetura geral da plataforma WSO2 com o CTO. Ele também trabalha como cientista pesquisador na Fundação Lanka Software e é professor visitante do Departamento de Engenharia e Ciência da Computação da Universidade de Moratuwa. É cofundador do Apache Axis2 e tem participado do projeto Apache Web Service desde 2002. Também é membro da Apache Software Foundation, PMC e do projeto Apache Web Service. Srinath também é committer de Axis, Axis2 e Geronimo, projetos de software livre do Apache. Ele possui doutorado e mestrado em ciência da computação pela Universidade de Indiana, Bloomington, EUA, e bacharelado em Ciência e Engenharia da Computação pela Universidade de Moratuwa, Sri Lanka.



20/Jul/2012

Introdução

No artigo sobre a história dos bancos de dados "What Goes Around Comes Around" (consulte Recursos), Michal Stonebraker descreve em detalhes o desenvolvimento das técnicas de armazenamento ao longo do tempo. Antes de chegar ao modelo relacional, os desenvolvedores tentaram outros modelos, como hierárquico e de gráfico direcionado. É importante observar que o modelo relacional baseado em SQL — que é o padrão de facto mesmo agora — prevalece há quase 30 anos. Dada a breve história e rápido ritmo da ciência da computação, esse é um feito notável. O modelo relacional está tão bem estabelecido que, por muitos anos, a escolha de um armazenamento de dados para um aplicativo era fácil para o arquiteto de solução. A escolha era invariavelmente um banco de dados relacional.

Desenvolvimentos como o aumento das bases de usuário dos sistemas, dispositivos móveis, maior presença dos usuários online, computação em nuvem e sistemas com mais de um núcleo 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 não são adequados para suportar sistemas em larga escala.

Para enfrentar esses desafios, Google e Amazon inventaram duas soluções alternativas: Big Table e Dynamo (consulte Recursos), nos quais eles diminuíram as garantias proporcionadas pelo modelo de dados relacionais para obter maior escalabilidade. O "Teorema CAP", de Eric Brewer, (consulte Recursos) formalizou posteriormente essas observações. O artigo afirma que, para sistemas escaláveis, tolerância a partição, disponibilidade e consistência estão em relação de compensação, sendo impossível 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 escaláveis, uma nova classe de sistemas de armazenamento foi proposta. Eles foram chamados de sistemas "NoSQL". O nome primeiramente significava "não use SQL se você quer fazer ajuste de escala" e depois foi redefinido para "não apenas SQL", significando que há outras soluções além das que usam SQL.

Há muitos sistemas NoSQL, e cada um diminui ou altera algum aspecto do modelo relacional. É importante observar que nenhuma das soluções NoSQL funciona para todos os cenários. 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 soluções NoSQL (consulte Recursos).

Apache Cassandra (consulte Recursos) é uma das primeiras e mais usadas soluções NoSQL. Este artigo examina Cassandra e aponta alguns detalhes e pontos difíceis que não são aparentes quando você observa a solução pela primeira vez.


Apache Cassandra

Cassandra é uma implementação de família 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 são:

  • Altas escalabilidade e disponibilidade, sem um ponto único de falha
  • Implementação da família de colunas NoSQL
  • Rendimento de gravação muito alto e bom rendimento de leitura
  • Linguagem de consulta semelhante a SQL (desde 0.8) e suporte para procura por índices secundários
  • Consistência ajustável e suporte para replicação
  • Esquema flexível

Esses pontos positivos tornam fácil recomendar o Cassandra, mas é fundamental para um desenvolvedor observar os detalhes e pontos difíceis da solução para conhecer os detalhes desse programa.

Cassandra armazena dados de acordo com o modelo de dados de família de colunas, demonstrado na Figura 1.

Figura 1. Modelo de dados do Cassandra
Modelo de dados do Cassandra

O que é uma coluna?

Coluna não é um nome muito apropriado, e talvez o nome célula fosse mais fácil de entender. Continuarei usando coluna por ser de uso comum.

O modelo de dados do Cassandra consiste em colunas, linhas, famílias de colunas e keyspaces. Vejamos cada parte em detalhes.

  • Coluna - a unidade mais básica do modelo de dados do Cassandra, contendo um nome, um valor e um registro de data e hora. Para esta discussão, 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 coleção 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 nós 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 classificação, o Cassandra suporta consultas de fatia, nas quais, dada uma linha, os usuários 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 estão entre tag0 e tag9999.

  • Família de colunas - uma coleção de linhas rotuladas com um nome. A Listagem 2 mostra um exemplo de dados:
    Listagem 2. Exemplo de uma família de colunas
        Books->{
        "Foundation"->{author="Asimov", publishedDate=".."},
        "Second Foundation"->{author="Asimov", publishedDate=".."},
        …
        }

    Dizem frequentemente que uma família de colunas é como uma tabela no modelo relacional. Como o exemplo anterior mostra, as semelhanças são apenas essas.

  • Keyspace – um grupo de várias famílias de colunas juntas. É apenas um agrupamento lógico de famílias de colunas e fornece um escopo isolado para nomes.

Por fim, as supercolunas residem em uma família de colunas que agrupa várias colunas em uma única chave. Como os desenvolvedores recomendam não usar supercolunas, eu não as discutirei aqui.


Cassandra versus modelos de dados RDBMS

Pela descrição do modelo de dados do Cassandra acima, os dados são colocados em um espaço bidimensional (2D) em cada família de colunas. Para recuperar dados em uma família de colunas, os usuários precisam de duas chaves: nome da linha e nome da coluna. Nesse sentido, o modelo relacional e o do Cassandra são semelhantes, embora haja várias diferenças fundamentais.

  • As colunas relacionais são homogêneas em todas as linhas na tabela. Existe geralmente um relacionamento vertical claro entre os itens de dados, o que não é 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 espaço de dados 2D é completo. Cada ponto no espaço 2D deve ter ao menos o valor nulo armazenado. Novamente, esse não é o caso do Cassandra, que pode ter linhas contendo apenas alguns itens enquanto outras têm muitos itens.
  • Com um modelo relacional, o esquema é predefinido e não pode ser alterado no tempo de execução, enquanto o Cassandra permite que os usuários alterem o esquema no tempo de execução.
  • 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 difícil procurar dados em uma linha, a menos que o usuário use um particionador que preserve a ordem.
  • Outra diferença 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 imutável bem-definido, os modelos relacionais suportam consultas sofisticadas que incluem JOINs, agregações e mais. Com um modelo relacional, os usuários podem definir o esquema de dados sem se preocupar com consultas. O Cassandra não suporta JOINs e a maioria dos métodos de procura de SQL. Portanto, os esquemas devem ser ajustados para as consultas exigidas pelo aplicativo.

Para explorar as diferenças acima, imagine um site de classificação de livros no qual os usuários podem adicionar livros (autor, classificação, preço, link), comentários (texto, hora, nome) e tags. O aplicativo precisa suportar as seguintes operações dos usuários:

  • Incluir livros
  • Incluir comentários para livros
  • Incluir tags para livros
  • Listar livros ordenados por classificação
  • Listar livros por uma tag específica
  • Listar os comentários dado um ID de livro

É bem comum implementar o aplicativo acima com um modelo relacional. A Figura 2 mostra o relacionamento Entity–relationship (ER) para o design do banco de dados.

Figura 2. Modelo ER do site de classificação de livros
Modelo ER do site de classificação 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 família 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 classificação de livros
Books[BookID->(author, rank, price, link, tag<TS1>, tag<TS2> .., 
    cmt+<TS1>= text + "-" + author) …] 
Tags2BooksIndex[TagID->(<TS1>=bookID1, <TS2>=bookID2, ..) ] 
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 classificação de livros
Nome da Família de Colunas Conjunto de Dados de Exemplo
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 várias diferenças de design entre os modelos relacional e do Cassandra. O modelo do Cassandra armazena os dados sobre livros em uma única família de colunas chamada "Books", e as três outras famílias de colunas são í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 são representados como colunas armazenadas na linha.

Observando mais detalhadamente, podemos perceber que os itens de dados armazenados (como comentários e tags que têm um relacionamento 1:M com os livros) também estão em uma única linha. Para fazer isso, anexe o registro de data e hora aos nomes das colunas de tags e comentários. Essa abordagem armazena todos os dados na mesma coluna. Essa ação evita ter que fazer JOINs para recuperar dados. O Cassandra contorna a ausência de suporte a JOINs através dessa abordagem.

Isso proporciona várias vantagens.

  • É possível ler todos os dados sobre um livro através de uma única consulta lendo a linha completa.
  • É possível recuperar comentários e tags sem um JOIN usando consultas de fatia que tenham cmt0-cmt9999 e tag0-tag9999 como intervalos de início e fim.

Como o Cassandra armazena colunas classificadas por seus nomes, as consultas de fatia são muito rápidas. É importante observar que a classificação de todos os detalhes de um item de dados em uma única linha e o uso de classificações de ordem são as ideias mais importantes por trás do design de dados do Cassandra. A maioria dos designs de modelo de dados do Cassandra segue essas ideias em alguma forma. O usuário pode usar as ordens de classificação 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 são armazenados na ordem classificada, os comentários com nomes de coluna seguidos pelo registro de data e hora são armazenados na ordem em que foram criados, e os resultados de pesquisa teriam a mesma ordem.

O Cassandra não suporta métodos de procura com o design básico. Embora suporte índices secundários, estes são suportados usando índices criados posteriormente e possuem várias limitações, incluindo ausência de suporte para consultas por intervalo.

Consequentemente, para obter os melhores resultados em um design de dados do Cassandra, é necessário que usuários implementem procuras criando índices customizados e utilizando ordens de classificação de coluna e de linha. Outras famílias de três colunas (Tags2BooksIndex, Tags2AuthorsIndex e RankIndex) fazem exatamente isso. Como os usuários precisam procurar livros dada uma tag, a família 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 são incluídos como chaves de coluna, mas isso é para fornecer um ID de coluna exclusivo. A implementação de procura simplesmente lê o índice consultando a linha por nome de tag e localizando as correspondências 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. Comparação de implementações de consulta
Descrição da consulta Consulta como SQL Implementação do Cassandra
Listar livros ordenados por classificação

Executar a consulta
"Selecionar * da ordem Books por classificação" e em cada resultado "Selecionar tag de Tags em que bookid=?" e "Selecionar comentário de Comments em que bookid=?"
Realizar uma consulta de fatia na família de colunas "RankIndex" para receber uma lista ordenada de livros e, para cada livro, realizar uma consulta de fatia na família de colunas "Books" para ler os detalhes do livro.
Dada uma tag, localizar os autores cujos livros possuem essa tag. Selecionar autor distinto de Tags, Books em que Tags.bookid=Books.bookid e tag=? Ler todas as colunas à procura da tag dada em Tags2Authors usando uma consulta de fatia.
Dada uma tag, localizar livros que possuem essa tag. Selecionar bookid em Tags em que tag=? Ler todas as colunas à procura da tag dada em Tags2BooksIndex usando uma consulta de fatia.
Dado um livro, listar seus comentários na ordem de classificação da hora em que os comentários foram criados. Selecionar text, time, user em Comments em que bookid=? Classificar por hora Na família de colunas "Books", realizar uma consulta de fatia na linha correspondente ao livro dado. Elas estão na ordem de classificação devido aos registros de data e hora usados como nome da coluna.

Embora o design acima possa suporta eficientemente consultas exigidas pelo site de classificação de livros, ele pode suportar apenas as consultas para as quais foi projetado e não suporta consultas ad hoc. Por exemplo, ele não 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, é possível criar índices apropriados ou criar código para passar pelos dados. No entanto, a necessidade de código customizado para suportar novas consultas é uma limitação em relação aos modelos relacionais nos quais incluir novas consultas geralmente não demanda alterações no esquema.

A partir do release 0.8, o Cassandra suporta índices secundários, nos quais os usuários 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 secundários não suportam consultas de intervalo e não garantem ordens de classificação 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 usuários 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 instruções na página de Introdução ao Cassandra (consulte Recursos) para configurar um nó do Cassandra. A menos que sua configuração tenha sido alterada, ele executa na porta 9160. A seguir, defina um keyspace. Isso pode ser feito através do cliente ou do arquivo de configuração conf/cassandra.yaml.

Listagem 4. Código 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 código completo do exemplo de classificação de livros encontra-se em Download. . Ele inclui amostras de consultas de fatia e outras operações 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 distribuídos.

A Figura 3 mostra a arquitetura de um cluster do Cassandra. A primeira observação é que o Cassandra é um sistema distribuído. O Cassandra consiste em vários nós e distribui os dados entre eles (ou divide-os em shards, na terminologia de bancos de dados).

Figura 3. Cluster do Cassandra
Cluster do Cassandra

O Cassandra usa hashing consistente para designar itens de dados a nós. 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 possíveis (também chamado de keyspace), é dividido entre os nós no cluster do Cassandra. Em seguida, o Cassandra designa cada item de dados ao nó, e esse nó é responsável 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 nós de forma transparente para o usuário. Qualquer nó pode aceitar qualquer solicitação (leitura, gravação ou exclusão) e encaminhá-la ao nó correto, mesmo que os dados não estejam armazenados nesse nó.
  • Os usuários podem definir quantas réplicas são necessárias, e o Cassandra cuida da criação e gerenciamento de réplicas de forma transparente.
  • Consistência ajustável: ao armazenar e ler dados, os usuários podem escolher o nível de consistência esperado em cada operação. Por exemplo, quando o nível de consistência "quorum" é usado ao gravar ou ler, os dados são gravados e lidos em mais de metade dos nós no cluster. O suporte a consistência ajustável permite que os usuários escolham o melhor nível de consistência para o caso de uso.
  • O Cassandra fornece gravações muito rápidas (até mesmo mais rápidas que as leituras), transferindo dados a cerca de 80-360 MB/s por nó. Para isso, ele usa duas técnicas.
    • O Cassandra mantém a maior parte dos dados na memória do nó responsável. As atualizações são feitas na memória e gravadas no armazenamento persistente (sistema de arquivos) de forma lenta. No entanto, para evitar a perda de dados, ele grava todas as transações em um log de confirmação no disco. Ao contrário da atualização de itens de dados no disco, as gravações em logs de confirmação envolvem apenas anexação e, portanto, evitam o atraso de rotação ao gravar no disco. Para obter mais informações sobre as características de desempenho em unidade de disco, consulte Recursos.
    • A menos que a gravação tenha solicitado consistência total, o Cassandra grava dados em nós suficientes sem resolver inconsistências de dados, resolvendo-as apenas na primeira leitura. Esse processo é chamado de "reparo na leitura".

A arquitetura resultante é altamente escalável: é possível desenvolver um cluster do Cassandra com vários nós, que é capaz de lidar com terabytes a petabytes de dados. Há uma compensação em sistemas distribuídos, e escala quase nunca vem gratuita. Como mencionamos, um usuário pode encontrar muitas surpresas ao passar de um banco de dados relacional para o Cassandra. A próxima sessão discute algumas delas.


Possíveis surpresas com o Cassandra

Fique atento a essas diferenças ao passar de um banco de dados relacional para o Cassandra.

Sem transações, sem JOINs

É fato conhecido que o Cassandra não suporta transações ACID. Embora tenha uma operação em lote, não é garantido que suboperações dentro da operação em lote sejam realizadas de forma atômica. Isso será discutido melhor em Operações com falha podem deixar mudanças.

Além disso, o Cassandra não suporta JOINs. Quando um usuário precisa unir duas famílias de colunas, é necessário recuperar e unir os dados programaticamente. Isso geralmente é caro e demorado para grandes conjuntos de dados. Para contornar essa limitação, o Cassandra armazena o máximo de dados possível na mesma linha, como descrito no exemplo.

Sem chaves estrangeiras. As chaves são imutáveis

O Cassandra não suporta chaves estrangeiras, portanto, não pode gerenciar a consistência de dados para o usuário. Por isso, o aplicativo deve lidar com a consistência de dados. Além disso, os usuários não 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 alterações nas chaves.

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 serão sobrescritos.

Há duas soluções para esse problema. Primeiro, é possível usar uma chave composta. Em outras palavras, criar a chave combinando vários campos. Essa solução é usada frequentemente com chaves de linha. A segunda solução, quando há o risco de uma mesma chave ocorrer duas vezes, é incluir na chave um valor aleatório 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 classificação de livros, a classificação foi usada como nome da coluna. Para evitar que duas entradas tenham o mesmo nome de coluna por terem a mesma classificação, o registro de data e hora é incluído após o nome.

Operações com falha podem deixar mudanças

Como explicado acima, o Cassandra não suporta operações atômicas. Em vez disso, suporta operações idempotentes. As operações idempotentes deixam o sistema no mesmo estado, independentemente de quantas vezes são realizadas. Todas as operações do Cassandra são idempotentes. Se uma operação falhar, é possível tentar novamente sem problemas. Isso é um mecanismo para recuperação de falhas temporárias.

Além disso, o Cassandra suporta operações em lote, mas elas também não têm garantia de atomicidade. Como as operações são idempotentes, o cliente pode continuar tentando até que todas as operações do lote tenham êxito.

Operações idempotentes não são o mesmo que operações atômicas. Quando a operação tem êxito, tudo fica bem e a saída é idêntica às operações atômicas. Quando uma operação falha, o cliente pode tentar de novo e, se tiver sucesso, tudo estará bem novamente. Se, no entanto, a operação falhar mesmo após tentar novamente, é possível que ela deixe efeitos colaterais, ao contrário das operações atômicas. Infelizmente, com o Cassandra, essa é uma complexidade com a qual os programadores precisam lidar por si mesmos.

A procura é complicada

A procura não é integrada no núcleo da arquitetura do Cassandra, e mecanismos de procura são incluídos usando ordens de classificação, como descrito anteriormente. O Cassandra suporta índices secundários, criados automaticamente pelo sistema, com funcionalidade limitada. Quando os índices secundários não funcionam, os usuários precisam aprender sobre o modelo de dados e desenvolver índices usando ordens de classificação e fatias.

Três tipos de área de complexidade associados à criação de métodos de procura:

  1. Para criar métodos de procura customizados, os programadores precisam entender indexação 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 classificação, e são complicados. Há dois tipos de ordem de classificação: primeiro, as colunas são sempre classificadas por nome. Segundo, as ordens de classificação de linha funcionam apenas se um particionador que preserva a ordem (consulte Recursos) for usado.
  3. A inclusão de novas consultas geralmente demanda mais mudanças nos índices e código, ao contrário de modelos relacionais. Isso exige que desenvolvedores analisem consultas antes de armazenar os dados.

Recomenda-se não usar supercolunas e particionadores de preservação

As supercolunas do Cassandra podem ser úteis ao modelar dados em mais de um nível, situação na qual o Cassandra incluí mais um nível na hierarquia. No entanto, tudo que pode ser modelado com supercolunas também pode ser suportado através de colunas. Portanto, as supercolunas não fornecem eficiência adicional. Além disso, elas também não suportam índices secundários. Portanto, os desenvolvedores do Cassandra recomendam não usar supercolunas. Embora não haja uma data firme para descontinuar o suporte, isso pode acontecer em liberações futuras.

Um particionador no Cassandra decide como distribuir (dividir em shards) dados entre os nós do Cassandra, e há muitas implementações. Caso seja usado um particionador que preserva a ordem, os IDs de linha são armazenados na ordem de classificação e o Cassandra pode realizar fatias (procuras) em IDs de linha. Esse particionador não distribui os dados de maneira uniforme entre seus nós. No entanto, com grandes conjuntos de dados, alguns dos nós podem estar ocupados enquanto outros possuem carga leve. Por isso, os desenvolvedores também recomendam não usar particionadores que preservam a ordem.

A recuperação da falha é manual

Quando um nó em um cluster do Cassandra falha, o cluster continua funcionando se houver réplicas. A recuperação completa, que é redistribuir dados e compensar pelas réplicas perdidas, é uma operação manual através da ferramenta de linha de comandos chamada ferramenta node (consulte Recursos). . Além disso, enquanto a operação manual é realizada, o sistema estará indisponível.

Ele se lembra de exclusões

O Cassandra é projetado de forma que continua a funcionar sem problema mesmo que um nó fique inativo (ou seja, desconectado) e retorne depois. Uma consequência é que isso complica a exclusão de dados. Por exemplo, imagine que um nó está inativo. Enquanto ele está inativo, um item de dados é excluído nas réplicas. Quando o nó indisponível retorna, ele reapresenta o item de dados excluído no processo de sincronização, a menos que o Cassandra se lembre de que esse item foi excluído.

Portanto, o Cassandra precisa lembrar que o item de dados foi excluído. No release 0.8, o Cassandra estava lembrando-se de todos os dados, mesmo se fossem excluídos. Isso fazia com que o uso do disco aumentasse continuamente em operações com muitas atualizações. O Cassandra não precisa se lembrar de todos os dados excluídos, mas apenas do fato de quem um item de dados foi excluído. Essa correção foi feita em liberações posteriores do Cassandra.


Conclusão

Este artigo mostra alguns detalhes que não são 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 típico. Uma observação importante é que, ao contrário do modelo relacional, que divide os dados em várias tabelas, o Cassandra tende a manter o máximo possível dos dados na mesma linha, para evitar ter que unir os dados para recuperação.

Você também viu várias limitações da abordagem baseada no Cassandra. Essas limitações, no entanto, são iguais na maioria das soluções de NoSQL e são, geralmente, renunciadas conscientemente em nome da alta escalabilidade.


Download

DescriçãoNomeTamanho
Book rating sample codeCassandraSample.zip42KB

Recursos

Aprender

Obter produtos e tecnologias

  • Explore o Cassandra no website do projeto.
  • Confira o cliente Hector no website do projeto.
  • Faça download do Cassandra e encontre instruções sobre como usá-lo em cassandra.apache.org.
  • Avalie produtos IBM da maneira que for melhor para você: faça download da versão 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 serviço (SOA) de maneira eficiente.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre, Information Management
ArticleID=826278
ArticleTitle=Considerações sobre o Banco de Dados Apache Cassandra
publish-date=07202012