- Possíveis surpresas com 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:
- 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.
- 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.
- 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.
- Sem transações, sem JOINs