Introdução ao modelo de dados em Cassandra
O Apache Cassandra se tornou um dos mais poderosos bancos de dados NoSQL. É a escolha certa quando você deseja alta disponibilidade e escalabilidade sem comprometer o desempenho, especialmente para aplicativos que não podem perder dados. Neste tópico, vamos aprender sobre o Modelo de Dados no Cassandra.
Um fato rápido, os engenheiros da Cassandra estão entre os profissionais de tecnologia mais bem pagos atualmente. Empresas como Netflix, Instagram e Apple usam Cassandra para fornecer uma experiência altamente individualizada ao cliente. Para obter o desempenho certo, é necessário projetar cuidadosamente o esquema específico do problema de negócios. Neste artigo, veremos o Cassandra Data Model, que é significativamente diferente do que vemos no RDBMS.
Regras do Modelo de Dados Cassandra
Em palavras simples, o modelo de dados é a estrutura lógica de um banco de dados. Ele descreve como os dados são armazenados e acessados, e os relacionamentos entre diferentes tipos de dados.
Escolher o modelo de dados correto pode ser a parte mais difícil de usar um banco de dados NoSQL como o Cassandra. Como mencionei anteriormente, a modelagem de dados no Cassandra é diferente do que vemos em um RDBMS.
Chave de partição e Chave de cluster são os termos que qualquer pessoa que lide com Cassandra deve estar ciente. Antes de mergulharmos nas regras básicas de modelagem de dados do Cassandra, vejamos rapidamente o que esses termos significam,
Partição
Cassandra é um banco de dados distribuído no qual os dados são particionados e armazenados em diferentes nós em um cluster. Os dados são divididos em partes usando uma chave de partição, que pode ser um ou mais campos de dados. Essa chave de partição é usada para criar um mecanismo de hash para espalhar dados uniformemente por todos os nós.
Grupo
Um cluster é uma coleção de nós que representam um único banco de dados lógico. Uma chave de cluster é composta de um ou mais campos usados para agrupar dados em uma partição.
Nesta tabela restaurantes, os dados serão particionados usando country_code, state_name e city_name e, dentro dessa partição, os dados serão agrupados e classificados com base em Opening_data e restaurant_name.
Agora, vejamos as duas regras para modelagem de dados que devem ser lembradas.
- Os dados são distribuídos uniformemente por todo o cluster
- Leia a partir do menor número possível de partições
Vejamos o que essas regras estão tentando transmitir
- Sabemos o que é um cluster certo? Um cluster consiste em vários nós. Queremos particionar os dados entre esses nós, de modo que cada nó tenha aproximadamente a mesma quantidade de dados. Como sabemos, os dados são particionados em diferentes nós usando um hash da chave de partição (que é a primeira chave da Chave Primária); portanto, em resumo: “Você deve escolher uma boa Chave Primária”.
- Cada partição reside em um nó diferente; portanto, ao recuperar dados, você deseja garantir que os dados sejam recuperados do menor número possível de partições. Se sua consulta exigir dados de partições diferentes, será emitido um comando para separar nós para obter esses dados, que serão sobrecarregados e levarão à latência.
A chave para um modelo de dados eficiente seria um equilíbrio entre essas duas regras.
Lidar com relacionamentos em Cassandra
Lembre-se de que a modelagem de dados no Cassandra é feita usando a abordagem orientada a consultas, diferente do RDBMS, onde você identifica primeiro entidades, cria tabelas e forma consultas usando JOINS para recuperar dados.
Em palavras simples, não modelamos em torno de relações ou objetos, modelamos em torno de consultas.
1. Relacionamento um a um
Considere em uma universidade que um aluno pode se inscrever em apenas um seminário. Este é um relacionamento individual. Mantendo a regra número 1, pensamos nas consultas que queremos. Quero pesquisar o seminário em que um aluno está participando. Nesse caso, criaremos apenas uma tabela. A tabela deve conter os detalhes do aluno e os detalhes do seminário.
2. Um para muitos relacionamentos
No mesmo contexto, e se eu quisesse procurar todos os alunos que participavam de um seminário. Em vez de usar a mesma tabela e iterar sobre cada linha para obter o nome do aluno para esse seminário específico, posso criar outra tabela que particione os dados pelo nome do seminário. Portanto, quando eu emito a consulta, ela atinge apenas um nó em vez de ir a todos os nós para obter o nome do seminário.
3. Relacionamento Muitos para Muitos
Agora, vamos considerar, um aluno pode participar de muitos seminários e um seminário pode ser assistido por muitos estudantes. Aqui temos muitos para muitos relacionamentos. Nesse caso, você pode explorar as duas tabelas acima para fazer consultas sem ter a sobrecarga de fazer consultas complexas usando Joins, o que você normalmente faria no RDBMS.
Importância de Cassandra
Com a rápida expansão dos dados digitais, torna-se mais importante ter um banco de dados altamente escalável e tolerante a falhas. Deixe-me listar alguns pontos sobre por que você deve usar Cassandra
- Iluminação das operações de leitura rápida: discutimos como modelar seus dados da maneira correta pode otimizar as operações de leitura em grande escala.
- Tolerante a falhas: os dados são replicados entre os nós, portanto, mesmo que um nó desça, seus dados estarão seguros.
- Ajuste personalizado: você pode configurar o Cassandra para funcionar de acordo com sua carga de trabalho. Se você escrever muitos dados, como o log, poderá ajustá-los para lidar com sistemas com muita gravação. Existem várias outras opções de ajuste disponíveis.
- Lidando com grandes volumes de dados: Com base no tamanho do cluster, Cassandra pode lidar com grandes volumes de dados.
Como modelar os dados no Cassandra?
Uma boa modelagem de dados segue estas etapas
- Conceitualize as consultas exigidas pelo seu aplicativo
- Criando tabelas para satisfazer essas consultas
Antes de aplicar essas regras, lembre-se de: "Nos concentramos em otimizar nossas operações de leitura, mesmo que isso exija duplicação de dados". Podemos ter muitas tabelas que podem conter dados quase semelhantes.
Agora, considere que queremos um banco de dados que armazene informações sobre restaurantes. Vamos colocar uma restrição de que os nomes de restaurantes devem ser únicos.
A tabela abaixo pode ser usada quando queremos pesquisar com base no nome do restaurante:
Agora, se quisermos procurar os restaurantes em um local específico, escreveremos uma consulta que itera por todas as linhas e recupera os nomes dos restaurantes.
Em vez disso, tendo em mente a regra nº 2, podemos criar facilmente outra tabela que atenda a nossa necessidade.
Agora, nossos dados serão particionados de forma que um nó no cluster tenha restaurantes para um local específico. Isso otimizará nossas consultas de leitura, pois a pesquisa de consultas ocorrerá apenas em um nó com linhas muito menores que a primeira tabela que criamos.
E se quiséssemos procurar restaurantes em uma cidade específica, podemos criar outra tabela em vez de iterar por todas as linhas em uma única partição da tabela acima.
Conclusão
Neste artigo, abordamos algumas práticas recomendadas que você pode seguir como abordar a modelagem de dados no Cassandra. Se você entende esses conceitos e consegue reconhecer com eficiência o tipo de consulta que seu aplicativo precisa, é possível projetar um ótimo modelo de dados para obter alto desempenho do seu banco de dados.
Artigos recomendados
Este é um guia para o Modelo de Dados no Cassandra. Aqui discutimos como modelar nossos dados no Cassandra, juntamente com as regras e a importância dos modelos de dados do Cassandra. Você também pode consultar nossos outros artigos sugeridos para saber mais -
- O que é modelagem de dados?
- Modelos de dados no DBMS
- Perguntas da entrevista sobre modelagem de dados
- Modelagem de Dados Cassandra