Cassandra Basit Veritabanı Örneği ile Veri Modeli

Rağmen Cassandra sorgu dili benzer SQL dil, veri modelleme yöntemleri tamamen farklıdır.

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

Cassandra Veri Modeli Kuralları

In Cassandra, yazmalar pahalı değildir. Cassandra birleştirmeleri, gruplandırmayı, OR cümlesini, toplamaları vb. desteklemez. Bu nedenle verilerinizi tamamen geri alınabilecek şekilde saklamanız gerekir. Bu nedenle verileri modellerken bu kuralların akılda tutulması gerekir. Cassandra.

Yazma sayısını en üst düzeye çıkarın

In Cassandra, yazmalar ç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 veri 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ı fiilen Cassandra. Disk alanı bellekten, CPU işlemesinden ve IO işleminden daha pahalı değildir. Gibi Cassandra dağıtılmış bir veritabanı olduğundan, veri çoğaltma anında veri kullanılabilirliği sağlar ve tek bir hata noktası oluşmaz.

Cassandra Veri Modelleme Hedefleri

Verileri modellerken aşağıdaki hedeflere sahip olmalısınız: Cassandra:

Verileri Çevreye Eşit Şekilde Dağıtın Cluster

Her düğümde eşit miktarda veri istiyorsunuz Cassandra ClusterVeriler, birincil anahtarın ilk kısmı olan bölümleme anahtarlarına göre farklı düğümlere dağıtılır. Bu nedenle, verileri küme içinde eşit şekilde dağıtmak için bölümleme anahtarı olarak yüksek kardinaliteli bir sütun seçmeye çalışın.

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ümlerdeki farklı düğümlerden veri toplar.

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

Bu, bölümlemelerin oluşturulmaması gerektiği anlamına gelmez. Verileriniz çok büyükse, bu kadar büyük miktarda veriyi tek bir bölümleme üzerinde tutamazsınız. Tek bölümleme yavaşlayacaktır.

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

İyi Birincil Anahtar Cassandra

Yukarıdaki her iki hedef de tek bir karara bağlıdır, bu nedenle aşağıdaki iki şema, önce zayıf bir anahtarla, sonra da sağlam bir anahtarla aynı tabloyu göstermektedir.

Bir örnek üzerinden hangi birincil anahtarın daha 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 MusicPlaylist tablosu,

• SongId, bölümleme anahtarıdır ve
• SongName kümeleme sütunudur
• Veriler SongName temelinde kümelenecektir. Her SongId için yalnızca bir bölüm oluşturulacak ve her şarkının ayrı bir tanımlayıcısı olduğundan, her bölüm tek bir satır içerecektir.

Kötü birincil anahtar nedeniyle bu veri modelinde veri alımı yavaş olacaktır.

İşte başka bir tablo MusicPlaylist.

CREATE TABLE MusicPlaylist (
    SongId int,
    SongName text,
    Year int,
    Singer text,
    PRIMARY KEY ((SongId, Year), SongName)
);

Yukarıdaki örnekte MusicPlaylist tablosu,

• SongId ve Year, bölümleme anahtarlarıdır ve
• SongName kümeleme sütunudur.
• Veriler ŞarkıAdı temel alınarak 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.

Bu veri modeli sayesinde veri alımımız hızlı olacaktır.

Verilerinizi Modelleyin Cassandra

Sorgularınızı modellerken aşağıdaki hususlara dikkat etmelisiniz:

Hangi sorguları desteklemek istediğinizi belirleyin

Öncelikle hangi sorguları istediğinizi belirleyin.

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

• Katıldı
• Tarafından gruba göre
• Hangi sütuna göre filtreleme vb.

Sorgularınıza göre tablo oluşturun

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

Aşağıdaki üç bölüm, bu prensibi hemen hemen her şemada bulunan üç ilişki türüne uygulamaktadır.

Bire Bir İlişkiyi Yönetmek Cassandra

Bire bir ilişki, iki tablonun bire bir yazışması olduğu anlamına gelir. Örneğin öğrenci sadece bir derse kayıt olabiliyor ve ben o öğrencinin hangi derse kayıtlı olduğunu sorgulamak istiyorum.

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

Yukarıdaki diyagramda sorguya hizmet eden tek bir tablo gösterilmektedir, çünkü her öğrenci yalnızca bir derse karşılık gelir.

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

Student_rollno bölümleme anahtarı olduğundan, öğrenci numarasına göre yapılan bir arama yalnızca bir bölümü okur.

Bire Çok İlişkiyi Yönetmek Cassandra

Bire çok ilişkiler, iki tablo arasında birden çoğa yazışma olması anlamına gelir.

Örneğin bir ders çok sayıda öğrenci tarafından incelenebilir. Belirli bir kursa katılan tüm öğrencileri aramak istiyorum.

Yani ders adını sorgulayarak, belirli bir derse çalışacak birçok öğrenci ismine sahip olacağım.

Burada ders adı bölümleme anahtarı haline gelir, böylece bir dersteki her öğrenci aynı bölüme dahil olur ve öğrenci numarası kümeleme sütunu haline gelir, böylece her öğrenci ayrı bir satırda kalır.

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

Aşağıdaki sorguyu kullanarak belirli bir derse ait tüm öğrencileri bulabilirim.

SELECT * FROM Student_Course WHERE Course_name = 'Course Name';

Çoktan Çoğa İlişkiyi Yönetmek Cassandra

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

Örneğin bir ders çok sayıda öğrenci tarafından çalışılabileceği gibi, bir öğrenci de çok sayıda ders çalışabilir.

Belirli bir kursa katılan tüm öğrencileri aramak istiyorum. Ayrıca belirli bir öğrencinin okuduğu tüm dersleri aramak istiyorum.

Bu durumda, iki tablo oluşturacağım, yani problemi iki ayrı duruma ayıracağım. Bu, tekrarlama kuralının en açık örneğidir: aynı gerçekler iki kez yazılır, böylece her sorgu bir bölümü okur.

Öncelikle belirli bir öğrencinin derslerini bulabileceğiniz bir tablo oluşturacağım.

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

Aşağıdaki sorguyu kullanarak belirli bir öğrencinin tüm derslerini bulabilirim.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

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

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

Aşağıdaki sorguyu kullanarak belirli bir dersteki bir öğrenciyi bulabilirim.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

Öğrenci bir derse katıldığında her iki tabloya da yazılmalıdır; bu işlem genellikle tek bir oturum açılmış toplu işlem içinde yapılır, böylece iki kopya senkronize kalır.

ortak Cassandra Veri Modelleme Hataları

Çoğu yetersiz şema aynı birkaç hatayı tekrarlar ve her biri tracBu, ilişkisel tasarımdan miras kalan bir alışkanlığa geri dönmek anlamına geliyor.

• Sınırsız bölümler: Ülke adı gibi bir bölümleme anahtarı seçmek, milyonlarca satırı tek bir bölüme yerleştirir. Bölümlerin makul bir boyutta kalmasını sağlamak için örneğin (ülke, ay) gibi bir zaman dilimi ekleyin.
• Çok düşük kardinaliteli anahtarlar: Durum bayrağı gibi yalnızca birkaç olası değere sahip bir bölümleme anahtarı, tüm trafiği birkaç düğümde yoğunlaştırır ve geri kalanını boşta bırakır.
• ALLOW FILTERING kullanarak sorgunun çalışmasını sağlamak: Her bölümü tarar ve bir modelleme sorununu gizler. Eğer bir sorgu buna ihtiyaç duyarsa, şemanın başka bir tabloya ihtiyacı olur.
• Sorgular yerine varlıkları modelleme: Öğrenciler tablosu ve dersler tablosu oluşturup, daha sonra bunları uygulamada birleştirmeye çalışmak, tasarımın amacını ortadan kaldırır.
• Sık sık silme ve üzerine yazma işlemleri: Her silme işlemi, sıkıştırma işlemi onu kaldırana kadar okunması ve atlanması gereken bir silme kaydı oluşturur; bu da yoğun kullanılan bölümlerdeki okuma işlemlerini yavaşlatır.

Bunlardan kaçınmak, şemanın bu sayfanın üst kısmında belirtilen kurallarla ve aşağıda özetlenen ilişkisel karşıtlıklarla uyumlu kalmasını sağlar.

RDBMS ve arasındaki fark Cassandra Veri Modelleme

Bu şema kararları pratikte şu alanlarda uygulanır: Cassandra tablo hem de anahtar alanı öğreticiler.

SSS