Cassandra Modelo de dados com exemplo de banco de dados simples

Apesar Cassandra A 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 O sistema é otimizado para alto desempenho de gravação. Portanto, tente maximizar suas gravações para obter melhor desempenho de leitura e disponibilidade de dados. Existe uma relação de compromisso entre gravação e leitura de dados. Assim, otimize o desempenho de leitura de dados maximizando o número de gravações.

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 ClusterOs dados são distribuídos entre os diferentes nós com base nas chaves de partição, que são a primeira parte da chave primária. Portanto, tente escolher uma coluna de alta cardinalidade como chave de partição para distribuir 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 não se deva criar partições. Se seus dados forem muito grandes, você não poderá armazenar essa enorme quantidade de dados em uma única partição. Uma única partição ficará mais lenta.

Portanto, tente escolher um número equilibrado de partições.

Boa chave primária Cassandra

Os dois objetivos acima se resumem a uma única decisão, portanto, os dois esquemas abaixo mostram a mesma tabela com uma chave inadequada e, em seguida, com uma chave adequada.

Vamos pegar 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 nome da música (SongName). Apenas uma partição será criada para cada ID da música (SongId) e, como cada música possui um identificador distinto, cada partição conterá uma única linha.

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.

As três seções que se seguem aplicam esse princípio aos três tipos de relacionamento encontrados em quase todos os esquemas.

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.

O diagrama acima mostra uma única tabela atendendo à consulta, porque cada aluno corresponde a exatamente um curso.

CREATE TABLE Student_Course (
    Student_rollno int PRIMARY KEY,
    Student_name text,
    Course_name text
);

Como Student_rollno é a chave de partição, uma pesquisa pelo número de matrícula retorna exatamente uma partição.

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.

Nesse caso, o nome do curso se torna a chave de partição, de forma que todos os alunos de um curso sejam alocados na mesma partição, e o número de matrícula se torna a coluna de agrupamento, garantindo que cada aluno permaneça em uma linha distinta.

CREATE TABLE Student_Course (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

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.

Neste caso, terei duas tabelas, ou seja, dividirei o problema em dois casos. Esta é a ilustração mais clara da regra de duplicação: os mesmos dados são escritos duas vezes para que cada consulta leia uma partição.

Primeiro, criarei uma tabela na qual você poderá encontrar os cursos de um determinado aluno.

CREATE TABLE Student_Course (
    Student_rollno int,
    Course_name text,
    Student_name text,
    PRIMARY KEY (Student_rollno, Course_name)
);

Posso encontrar todos os cursos de um determinado aluno através da seguinte consulta.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

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,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

Posso encontrar um aluno em um determinado curso através da seguinte consulta.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

Ambas as tabelas devem ser atualizadas sempre que um aluno se inscreve em um curso, normalmente dentro de um único lote de login, para que as duas cópias permaneçam sincronizadas.

comum Cassandra Erros na modelagem de dados

A maioria dos esquemas ruins repete os mesmos poucos erros, e cada um tracretomamos um hábito herdado do design relacional.

• Partições ilimitadas: Escolher uma chave de partição como o nome de um país coloca milhões de linhas em uma única partição. Adicione um intervalo de tempo, por exemplo (país, mês), para manter as partições em um tamanho razoável.
• Chaves de cardinalidade muito baixa: Uma chave de partição com apenas alguns valores possíveis, como um indicador de status, concentra todo o tráfego em alguns nós e deixa o restante ocioso.
• Utilizando ALLOW FILTERING para que uma consulta funcione: Ele examina todas as partições e oculta um problema de modelagem. Se uma consulta precisar disso, o esquema precisará de outra tabela.
• Modelagem de entidades em vez de consultas: Criar uma tabela de alunos e uma tabela de cursos, e depois tentar uni-las no aplicativo, anula o propósito do projeto.
• Exclusões e sobrescritas frequentes: Cada exclusão cria um marcador de exclusão que precisa ser lido e ignorado até que a compactação o remova, o que torna as leituras mais lentas em partições frequentemente acessadas.

Evitar esses erros mantém o esquema alinhado com as regras estabelecidas no início desta página e com os contrastes relacionais resumidos abaixo.

Diferença entre RDBMS e Cassandra Modelagem de Dados

Essas decisões de esquema são aplicadas na prática em Cassandra mesa e espaço de chave tutoriais.

Perguntas Frequentes