Basit Örnekle Cassandra Veri Modeli

Cassandra sorgu dili SQL diline benzese de, veri modelleme yöntemleri tamamen farklıdır.

Cassandra'da, kötü bir veri modeli, özellikle kullanıcılar Cassandra'da RDBMS kavramlarını uygulamaya çalıştıklarında performansı düşürebilir. Aşağıda ayrıntıları verilen birkaç kuralı akılda tutmak en iyisidir.

Bu eğitimde öğreneceksiniz-

Cassandra Veri Modeli Kuralları
Cassandra'da Verilerinizi Modelleyin
Bire Bir İlişkiyi Yönetmek
Birden çok ilişkiyi idare etmek
Birçok İlişkiye Başlamak

Cassandra Veri Modeli Kuralları

Cassandra'da yazılar pahalı değil. Cassandra birleştirme, gruplama, OR yan tümcesi, toplamalar, vb. Desteklemez. Bu nedenle, verilerinizi tamamen geri alınabilecek şekilde depolamanız gerekir. Bu yüzden Cassandra'da verileri modellerken bu kurallar akılda tutulmalıdır.

Yazma sayısını en üst düzeye çıkarın
Cassandra'da yazılar çok ucuz. Cassandra, yüksek yazma performansı için optimize edilmiştir. Bu nedenle, daha iyi okuma performansı ve veri kullanılabilirliği için yazma işlemlerinizi en üst düzeye çıkarmaya çalışın. Veri yazma ve okuma arasında bir denge vardır. Bu nedenle, veri yazma sayısını en üst düzeye çıkararak veri okuma performansınızı optimize edin.
Veri Çoğaltmayı En Üst Düzeye Çıkarın
Verilerin normalleştirilmesi ve veri çoğaltılması, Cassandra'ya aittir. Disk alanı, bellek, CPU işleme ve IO işlemlerinden daha pahalı değildir. Cassandra dağıtılmış bir veritabanı olduğundan, veri çoğaltma anında veri kullanılabilirliği sağlar ve tek bir hata noktası yoktur.

Veri Modelleme Hedefleri

Cassandra'da verileri modellerken aşağıdaki hedeflere sahip olmalısınız.

Verileri Kümenin Etrafına Eşit Şekilde Yayın
Cassandra kümesinin her düğümünde eşit miktarda veri istiyorsunuz. Veriler, birincil anahtarın ilk bölümü olan bölüm anahtarlarına göre farklı düğümlere yayılır. Bu nedenle, verileri kümenin etrafına eşit olarak yaymak için birincil anahtar olarak tam sayıları seçmeyi deneyin.
Verileri sorgularken okunan bölüm sayısını en aza indirin
Bölüm, aynı bölüm anahtarına sahip bir kayıt grubudur. Okuma sorgusu yayınlandığında, farklı bölümlerden farklı düğümlerden veri toplar.

Çok sayıda bölüm olacaksa, sorgu verilerini toplamak için tüm bu bölümlerin ziyaret edilmesi gerekir.

Bu, bölümlerin oluşturulmaması gerektiği anlamına gelmez. Verileriniz çok büyükse, bu kadar büyük miktarda veriyi tek bir bölümde tutamazsınız. Tek bölüm yavaşlayacak.

Bu yüzden dengeli sayıda bölüm seçmeye çalışın.

İyi Birincil Anahtar

Bir örnek alalım ve hangi birincil anahtarın iyi olduğunu bulalım.

İşte MusicPlaylist tablosu.

Create table MusicPlaylist(SongId int,SongName text,Year int,Singer text,Primary key(SongId, SongName));

Yukarıdaki örnekte, tablo MusicPlaylist,

Songid, bölüm anahtarıdır ve
SongName, kümeleme sütunudur
Veriler SongName temelinde kümelenecektir. SongId ile sadece bir bölüm oluşturulacaktır. MusicPlaylist tablosunda başka bir bölüm olmayacak.

Veri alma, hatalı birincil anahtar nedeniyle bu veri modeli tarafından yavaş olacaktır.

İşte başka bir MusicPlaylist tablosu.

Create table MusicPlaylist(SongId int,SongName text,Year int,Singer text,Primary key((SongId, Year), SongName));

Yukarıdaki örnekte, tablo MusicPlaylist,

Songid ve Year bölüm anahtarıdır ve
SongName, kümeleme sütunudur.
Veriler SongName temelinde kümelenecektir. Bu tabloda her yıl yeni bir bölüm oluşturulacaktır. Yılın tüm şarkıları aynı düğümde olacak. Bu birincil anahtar, veriler için çok faydalı olacaktır.

Veri erişimimiz bu veri modeli sayesinde hızlı olacaktır.

Cassandra'da Verilerinizi Modelleyin

Sorgularınızı modellerken aşağıdaki hususlar akılda tutulmalıdır.

Hangi sorguları desteklemek istediğinizi belirleyin

Her şeyden önce, hangi sorguları istediğinizi belirleyin.

Örneğin ihtiyacınız var mı?

Katılır
Gruplama ölçütü
Hangi sütun vb. Üzerinden filtreleme

Sorgularınıza göre tablo oluşturun
Sorgularınıza göre tablo oluşturun. Sorgularınızı tatmin edecek bir tablo oluşturun. Minimum sayıda bölümün okunması gerekecek şekilde bir tablo oluşturmaya çalışın.

Bire Bir İlişkiyi Yönetmek

Bire bir ilişki, iki tablonun bire bir karşılık geldiği anlamına gelir. Örneğin, öğrenci yalnızca bir derse kaydolabilir ve ben belirli bir öğrencinin kayıtlı olduğu bir öğrenciyi aramak istiyorum.

Bu durumda, tablo şemanız, dersin adı, öğrencinin rulo numarası, öğrenci adı vb. Gibi o derse karşılık gelen öğrencinin tüm ayrıntılarını kapsamalıdır.

Create table Student_Course(Student rollno int primary key,Student_name text,Course_name text,);

Birden çok ilişkiyi idare etmek

Bire çok ilişki, iki tablo arasında birden çoğa karşılık gelen anlamına gelir.

Örneğin, bir ders birçok öğrenci tarafından incelenebilir. Belirli bir dersi okuyan tüm öğrencileri aramak istiyorum.

Yani kurs adını sorgulayarak, belirli bir dersi okuyacak birçok öğrenci ismine sahip olacağım.

Create table Student_Course(Student_rollno int,Student_name text,Course_name text,);

Aşağıdaki sorgu ile belirli bir ders için tüm öğrencileri geri getirebilirim.

Select * from Student_Course where Course_name='Course Name';

Birçok İlişkiye Başlamak

Çoktan çoğa ilişki, iki tablo arasında çoktan çoğa yazışma olması anlamına gelir.

Örneğin, bir ders birçok öğrenci tarafından incelenebilir ve bir öğrenci birçok dersi de okuyabilir.

Belirli bir dersi okuyan tüm öğrencileri aramak istiyorum. Ayrıca, belirli bir öğrencinin çalıştığı tüm dersleri aramak istiyorum.

Yani bu durumda, iki tablom olacak, yani problemi iki duruma ayıracağım.

İlk olarak, belirli bir öğrencinin derslerini bulabileceğiniz bir tablo oluşturacağım.

Create table Student_Course(Student_rollno int primary key,Student_name text,Course_name text,);

Belirli bir öğrenciye ait tüm dersleri aşağıdaki sorgu ile bulabilirim. ->

Select * from Student_Course where student_rollno=rollno;

İkinci olarak, belirli bir dersi kaç öğrencinin çalıştığını bulabileceğiniz bir tablo oluşturacağım.

Create table Course_Student(Course_name text primary key,Student_name text,student_rollno int);

Aşağıdaki sorgu ile belirli bir kursta öğrenci bulabilirim.

Select * from Course_Student where Course_name=CourseName;

RDBMS ve Cassandra Veri Modellemesi Arasındaki Fark

RDBMS	Cassandra
Verileri normalleştirilmiş biçimde depolar	Verileri normal olmayan biçimde depolar
Eski dbms; yapılandırılmış veriler	Geniş sıralı mağaza, Dinamik; yapılandırılmış ve yapılandırılmamış veriler

Özet

Cassandra'daki veri modelleme, diğer RDBMS veritabanlarından farklıdır. Cassandra veri modellemesinin bazı kuralları vardır. İyi veri modellemesi için bu kurallara uyulmalıdır. Bu kuralların yanı sıra, üç farklı veri modelleme vakası ve bunlarla nasıl başa çıkılacağını gördük.