Cassandra Modelo de dados com exemplo de banco de dados simples
Apesar Cassandra linguagem de consulta se assemelha a SQL linguagem, seus métodos de modelagem de dados são totalmente diferentes.
In Cassandra, um modelo de dados ruim pode degradar o desempenho, especialmente quando os usuários tentam implementar os conceitos do RDBMS em Cassandra. É melhor ter em mente algumas regras detalhadas abaixo.
Cassandra Regras do modelo de dados
In Cassandra, as gravações não são caras. Cassandra não suporta junções, agrupamento por, cláusula OR, agregações, etc. Portanto, você deve armazenar seus dados de forma que sejam totalmente recuperáveis. Portanto, essas regras devem ser mantidas em mente ao modelar dados em Cassandra.
Maximize o número de gravações
In Cassandra, as gravações são muito baratas. Cassandra é otimizado para alto desempenho de gravação. Portanto, tente maximizar suas gravações para obter melhor desempenho de leitura e disponibilidade de dados. Há uma compensação entre gravação e leitura de dados. Portanto, otimize o desempenho de leitura de dados maximizando o número de gravações de dados.
Maximize a duplicação de dados
A desnormalização e a duplicação de dados são de fato Cassandra. O espaço em disco não é mais caro que a memória, o processamento da CPU e a operação de IOs. Como Cassandra é um banco de dados distribuído, portanto, a duplicação de dados fornece disponibilidade instantânea de dados e nenhum ponto único de falha.
Cassandra Metas de modelagem de dados
Você deve ter os seguintes objetivos ao modelar dados em Cassandra:
Distribua os dados uniformemente pelo Cluster
Você deseja uma quantidade igual de dados em cada nó do Cassandra Cluster. Os dados são distribuídos para diferentes nós com base em chaves de partição que são a primeira parte da chave primária. Portanto, tente escolher números inteiros como chave primária para espalhar os dados uniformemente pelo cluster.
Minimize o número de partições lidas durante a consulta de dados
Partição é um grupo de registros com a mesma chave de partição. Quando a consulta de leitura é emitida, ela coleta dados de diferentes nós de diferentes partições.
Se houver muitas partições, todas essas partições deverão ser visitadas para coletar os dados da consulta.
Isso não significa que partições não devam ser criadas. Se seus dados forem muito grandes, você não poderá manter essa enorme quantidade de dados em uma única partição. A partição única ficará mais lenta.
Portanto, tente escolher um número equilibrado de partições.
Boa chave primária Cassandra
Vamos dar um exemplo e descobrir qual chave primária é boa.
Aqui está a tabela MusicPlaylist.
Create table MusicPlaylist ( SongId int, SongName text, Year int, Singer text, Primary key(SongId, SongName) );
No exemplo acima, tabela MusicPlaylist,
- Songid é a chave de partição e
- SongName é a coluna de cluster
- Os dados serão agrupados com base no SongName. Apenas uma partição será criada com o SongId. Não haverá nenhuma outra partição na tabela MusicPlaylist.
A recuperação de dados será lenta por este modelo de dados devido à chave primária incorreta.
Aqui está outra tabela MusicPlaylist.
Create table MusicPlaylist ( SongId int, SongName text, Year int, Singer text, Primary key((SongId, Year), SongName) );
No exemplo acima, tabela MusicPlaylist,
- Songid e Year são a chave de partição, e
- SongName é a coluna de cluster.
- Os dados serão agrupados com base no SongName. Nesta tabela, a cada ano, será criada uma nova partição. Todas as músicas do ano estarão no mesmo nó. Esta chave primária será muito útil para os dados.
Nossa recuperação de dados será rápida por este modelo de dados.
Modele seus dados em Cassandra
Os seguintes itens devem ser mantidos em mente ao modelar suas consultas:
Determine quais consultas você deseja oferecer suporte
Em primeiro lugar, determine quais consultas você deseja.
Por exemplo, você precisa?
- Junta
- Agrupar por
- Filtrando em qual coluna etc.
Crie tabela de acordo com suas consultas
Crie tabela de acordo com suas dúvidas. Crie uma tabela que satisfaça suas dúvidas. Tente criar uma tabela de forma que seja necessário ler um número mínimo de partições.
Lidando com relacionamento um para um em Cassandra
Relacionamento um para um significa que duas tabelas têm correspondência um para um. Por exemplo, o aluno pode matricular apenas um curso, e quero pesquisar em um aluno em qual curso um determinado aluno está matriculado.
Portanto, neste caso, o esquema da sua tabela deve abranger todos os detalhes do aluno correspondentes a esse curso específico, como o nome do curso, o número do aluno, o nome do aluno, etc.
Create table Student_Course ( Student rollno int primary key, Student_name text, Course_name text, );
Lidando com relacionamentos um para muitos em Cassandra
Relacionamentos um para muitos significa ter correspondência um para muitos entre duas tabelas.
Por exemplo, um curso pode ser estudado por muitos alunos. Quero pesquisar todos os alunos que estão cursando um determinado curso.
Portanto, ao consultar o nome do curso, terei muitos nomes de alunos que estudarão um determinado curso.
Create table Student_Course ( Student_rollno int, Student_name text, Course_name text, );
Posso recuperar todos os alunos de um determinado curso por meio da seguinte consulta.
Select * from Student_Course where Course_name='Course Name';
Lidando com relacionamentos muitos para muitos Cassandra
Relacionamentos muitos para muitos significa ter muitas correspondências entre duas tabelas.
Por exemplo, um curso pode ser cursado por muitos alunos e um aluno também pode cursar muitos cursos.
Quero pesquisar todos os alunos que estão cursando um determinado curso. Além disso, quero pesquisar todo o curso que um determinado aluno está cursando.
Então neste caso terei duas tabelas, ou seja, dividirei o problema em dois casos.
Primeiro, criarei uma tabela na qual você poderá encontrar os cursos de um determinado aluno.
Create table Student_Course ( Student_rollno int primary key, Student_name text, Course_name text, );
Posso encontrar todos os cursos de um determinado aluno através da seguinte consulta.
Select * from Student_Course where student_rollno=rollno;
Em segundo lugar, criarei uma tabela na qual você poderá saber quantos alunos estão cursando um determinado curso.
Create table Course_Student ( Course_name text primary key, Student_name text, student_rollno int );
Posso encontrar um aluno em um determinado curso através da seguinte consulta.
Select * from Course_Student where Course_name=CourseName;
Diferença entre RDBMS e Cassandra Modelagem de Dados
RDBMS | Cassandra |
---|---|
Armazena dados em formato normalizado | Armazena dados em formato desnormalizado |
Bancos de dados legados; dados estruturados | Loja ampla, dinâmica; dados estruturados e não estruturados |
Resumo
- Modelagem de dados em Cassandra é diferente dos outros Bancos de dados RDBMS.
- Cassandra a modelagem de dados tem algumas regras. Estas regras devem ser seguidas para uma boa modelagem de dados. Além dessas regras, vimos três casos diferentes de modelagem de dados e como lidar com eles.
- Relacionamento um para um significa que duas tabelas têm correspondência um para um.
- Relacionamentos um para muitos significa ter correspondência um para muitos entre duas tabelas.
- Relacionamentos muitos para muitos significa ter muitas correspondências entre duas tabelas.