Məlumat modelləşdirmə əsasları - PostgreSQL və Cassandra vs. MongoDB

Tətbiq edənlər adətən iş yükü ehtiyaclarına ən uyğun olan bir verilənlər bazasını tapmaq üçün bir çox əməliyyat verilənlər bazasını qiymətləndirmək üçün xeyli vaxt sərf edirlər. Bu ehtiyaclara sadələşdirilmiş məlumat modelləşdirmə, əməliyyat zəmanətləri, oxumaq / yazmaq performansı, üfüqi miqyaslama və nöqsanlara qarşı dözümlülük daxildir. Ənənəvi olaraq, bu seçim SQL vs NoSQL verilənlər bazası kateqoriyalarından başlayır, çünki hər bir kateqoriya açıq ticarət paketi təqdim edir. Aşağı gecikmə və yüksək ötürmə qabiliyyəti baxımından yüksək performans, ümumiyyətlə, güzəştsiz bir tələb kimi qəbul edilir və buna görə seçilmiş hər hansı bir verilənlər bazasında gözlənilir.

Bu yazı tətbiqi inkişaf etdiricilərinə bir tətbiqin məlumat modelləşdirmə ehtiyacları kontekstində SQL və NoSQL seçimini anlamağa kömək etməkdir. Bir SQL verilənlər bazasını, yəni PostgreSQL və 2 NoSQL verilənlər bazasını, yəni Cassandra və MongoDB-ni, cədvəl yaratmaq, məlumat daxil etmək, taramaları yerinə yetirmək və məlumatları silmək kimi məlumat modelləşdirmə əsaslarını izah etmək üçün nümunələr olaraq istifadə edirik. Sonrakı yazıda indekslər, əməliyyatlar, qoşulmalar, zamanla yaşamaq (TTL) direktivləri və JSON əsaslı sənəd məlumat modelləşdirmə kimi inkişaf etmiş mövzuları əhatə edəcəyik.

NoSQL məlumat modelləşdirməsində SQL-dən necə fərqlənir?

SQL verilənlər bazası, mövcud normallaşdırılmış relyasiya məlumat modellərinin üstündəki gözlənilməz yollarla JOIN-lardan istifadə edərək məlumatları soruşma qabiliyyəti ilə yanaşı ACID əməliyyat zəmanətləri vasitəsi ilə tətbiqi çevikliyini artırır.

Onların monolit / tək qovuşlu arxitekturası və çoxalma üçün usta-qul replikası modelinin istifadəsini nəzərə alaraq, ənənəvi SQL verilənlər bazasında iki vacib imkan yoxdur - xətti yazma miqyası (yəni çox qovşaq boyunca avtomatik qaşınma) və avtomatik / sıfır məlumat itkisi. Bu o deməkdir ki, qəbul edilmiş məlumatların həcmi bir nodun maksimum yazma qabiliyyətindən çox ola bilməz. Əlavə olaraq, son tapşırıqların hələ qul köşkündə göstərilməyəcəyini nəzərə alsaq, müvəqqəti məlumat itkisini (paylanmayan heç bir şey saxlama arxitekturasında) gözləmək lazımdır. Sıfır dayanma yeniləmələrini SQL verilənlər bazası dünyasında əldə etmək çox çətindir.

NoSQL DB-lər, ümumiyyətlə məlumatların çox qovşaq boyunca bölündüyü və ya dəyişdirildiyi təbiətdə paylanır. Əlavə edilmiş məlumatların da nəzərə aldığınız xüsusi sorğulara xidmət etmək üçün birdən çox dəfə kopyalanması lazımdır deməkdir. Ən başlıca məqsəd, oxunuş zamanı əldə edilən şardaların sayını açıq şəkildə azaltmaqla yüksək performans əldə etməkdir. Beləliklə NoSQL, suallarınızı modelləşdirməyinizi tələb edir, SQL isə məlumatlarınızı modelləşdirməyinizi tələb edir.

Paylanmış bir çoxluqda yüksək performans əldə etmək üçün NoSQL-nin diqqəti ACID əməliyyatları, JOIN və ardıcıl qlobal ikincili indeksləri əhatə edən çoxsaylı məlumat modelləşdirmə kompromislərinin əsas səbəbi kimi ifadə edilmişdir.

Ümumi qavrayış budur ki, NoSQL verilənlər bazası xətti yazma ölçüsünü və yüksək günah dözümlülüyünü təmin etsə də, tranzaksiya zəmanətlərinin itirilməsi onları missiya kritik məlumatları üçün yararsız hala gətirir.

Aşağıdakı cədvəldə NoSQL məlumat modelləşdirməsinin SQL-dən nə ilə fərqlənməsi barədə məlumat verilir.

SQL vs. NoSQL - Əsas Məlumat Modelləşdirmə Fərqləri

SQL & NoSQL: Niyə ikisinə ehtiyacınız var?

Amazon.com, Netflix, Uber və Airbnb kimi istifadəçi təcrübələrini cəlb edən real dünya tətbiqlərinin çoxu daxili çoxsaylı iş yükünün mürəkkəb qarışığı ilə təchiz edilmişdir. Məsələn Amazon.com kimi bir e-ticarət tətbiqetməsində məhsulların icmalları, kömək mesajları, yüksək həcmli, az vəzifəli kritik məlumatlarla yanaşı istifadəçilər, məhsullar, sifarişlər, hesab-fakturalar kimi aşağı həcmli, yüksək vəzifəli kritik məlumatları saxlamaq lazımdır. istifadəçi fəaliyyəti, istifadəçi tövsiyələri. Təbii ki, bu tətbiqlər ən azı bir NoSQL verilənlər bazası ilə yanaşı ən azı bir SQL verilənlər bazasına etibar edir. Çoxölçülü və qlobal yayımlarda NoSQL verilənlər bazası eyni zamanda bir bölgədə işləyən SQL verilənlər bazasında, həqiqət mənbəyində saxlanan məlumatlar üçün geo paylanmış bir önbellek rolunu oynayır.

YugaByte DB ümumi verilənlər bazası bazasında SQL və NoSQL'i necə birləşdirir?

Giriş strukturlaşdırılmış birləşmə saxlama mühərriki, avtomatik şardinq, hər şardada paylanmış konsensus təkrarlanması və paylanan ACID əməliyyatları (Google Spanner-dən ilham alaraq) bənzərsiz birləşməsi üzərində qurulmuş YugaByte DB, həm NoSQL (Cassandra & Redis) olan dünyanın ilk açıq mənbə məlumat bazasıdır. uyğun) və SQL (PostgreSQL uyğun) eyni zamanda. Aşağıdakı cədvəldə göstərildiyi kimi, YCQL, YugaByte DB'nin Cassandra uyğun API, Transactional NoSQL dövründə mövcud olan NoSQL API-lərinə tək və çox açarlı ACID əməliyyatları və qlobal ikincili anlayışlar əlavə edir. Bundan əlavə, YSQL, YugaByte DB'nin PostgreSQL uyğun API, SQL API-yə xətti yazma miqyası və avtomatik qüsurlara dözümlülük anlayışlarını əlavə edir. YugaByte DB əsas tranzaksiya olduğundan, indi NoSQL API-ləri də missiya kritik məlumatların kontekstində istifadə edilə bilər.

YugaByte DB - Vahid Verilənlər bazasında SQL və NoSQL

Əvvəllər YSQL təqdimatında deyildiyi kimi: YugaByte DB üçün PostgreSQL uyğun paylanmış SQL API, YugaByte DB-də SQL və NoSQL seçimi tamamilə əksər iş yükünün xüsusiyyətlərindən asılıdır.

  • Əksər iş yüklülüyü JOINS ilə çox düyməli əməliyyatlardırsa, açarlarınızın NoSQL-dən daha yüksək gecikməyə və / və ya daha aşağı ötürmə qabiliyyətinə səbəb olan bir çox qovşaq arasında yayıla biləcəyini anlayaraq YSQL seçin.
  • Əks halda, ilk növbədə bir node-dan xidmət edilən sorğular nəticəsində daha yüksək performans fayda əldə edəcəyinizi anlayaraq iki NoSQL API-dən birini seçin. YugaByte DB, eyni vaxtda idarə etmək üçün bir çox iş yükü olan mürəkkəb real dünya tətbiqləri üçün vahid əməliyyat məlumat bazası kimi xidmət edə bilər.

Növbəti hissədəki məlumat modelləşdirmə laboratoriyası, orijinal verilənlər bazalarından fərqli olaraq YugaByte DB-nin PostgreSQL və Cassandra uyğun API-lərinə əsaslanır. Bu yanaşma eyni fərqli verilənlər bazası iki fərqli API ilə (iki fərqli limanda) qarşılıqlı əlaqənin sadəliyini vurğulayır.

Növbəti hissələrdə müxtəlif verilənlər bazaları arasındakı fərqləri və bir neçə ortaqlığı göstərmək üçün laboratoriyada məlumat modelləşdirmə əlləri ilə gəzəcəyik.

Məlumat Modelləşdirmə Laboratoriyası

Verilənlər bazasını quraşdırın

Məlumatların modelləşdirilməsinə (və mürəkkəb yerləşdirmə arxitekturasına deyil) diqqət yetirildiyini nəzərə alaraq verilənlər bazasını yerli maşınlarımızdakı Docker konteynerlərinə quraşdıracağıq və sonra müvafiq əmr satırı qabığından istifadə edərək onlarla əlaqə quracağıq.

YugaByte DB, bir PostgreSQL və Cassandra uyğun verilənlər bazası

mkdir ~ / yugabayt && cd ~ / yugabayt
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod + x yb-docker-ctl
doker çəkmək yugabytedb / yugabyte
./yb-docker-ctl yaratmaq --enable_postgres

MongoDB

docker run - ad my-mongo -d mongo: son

Command Line Shell istifadə edərək daxil ol

Növbəti API üçün əmr satırı qabığından istifadə edərək məlumat bazalarına qoşulaq.

PostgreSQL

psql, PostgreSQL ilə qarşılıqlı əlaqə üçün bir əmr satırı qabığıdır. İstifadənin rahatlığı üçün YugaByte DB, öz qovluğunda psql versiyası ilə göndərilir.

docker exec -it yb-postgres-n1 / ev / yugabayt / postgres / bin / psql -p 5433 -U postgres

Cassandra

cqlsh, Cassandra və ona uyğun verilənlər bazaları ilə CQL (Cassandra Query Dil) vasitəsi ilə qarşılıqlı əlaqə yaratmaq üçün bir əmr satırı qabığıdır. İstifadənin rahatlığı üçün YugaByte DB, öz qovluğunda cqlsh versiyası ilə göndərilir.

Qeyd edək ki, CQL, masalar, satırlar, sütunlar və indekslər oxşar anlayışı ilə SQL-dən çox ilhamlanır. Ancaq NoSQL dili olaraq, blog seriyamız zamanı nəzərdən keçirəcəyimiz müəyyən məhdudiyyətlər dəsti əlavə edir.

docker exec -it yb-tserver-n1 / ev / yugabayt / bin / cqlsh

MongoDB

mongo, MongoDB ilə qarşılıqlı əlaqə üçün bir əmr satırı qabığıdır. MongoDB quraşdırılmasının qut qovluğunda tapa bilərsiniz.

docker exec -it my-mongo bash
cd bin
mongo

Cədvəl yaradın

İndi əmr satırı qabığından istifadə edərək müxtəlif əməliyyatlar üçün verilənlər bazası ilə qarşılıqlı əlaqə qura bilərik. Gəlin sənətçilərin yayımladığı mahnıları haqqında məlumatları özündə cəmləşdirən bir masa yaratmağa başlayaq. Bu mahnılar bəzən bir albomun bir hissəsidir. Bir mahnının digər isteğe atributları il buraxılış, qiymət, janr və tənqidçi reytinqidir. Gələcəkdə yarı strukturlaşdırılmış məlumatları açar dəyər cütü kimi saxlaya bilən bir 'etiket' sahəsi vasitəsilə ehtiyac duyacağımız əlavə xüsusiyyətlər üçün hesaba ehtiyacımız var.

PostgreSQL

CƏDVƏL CƏDVƏLİ Musiqi (
    Rəssam VARCHAR (20) YOXDUR,
    SongTitle VARCHAR (30) YOXDUR,
    AlbumTitle VARCHAR (25),
    İl INT,
    Qiymət FLOAT,
    Janr VARCHAR (10),
    Tənqidçi FLOAT,
    Teqlər,
    ÖYRƏNİŞ KEY (Sənətçi, SongTitle)
);

Cassandra

Cassandra'da masa yaratmaq PostgreSQL proqramına çox bənzəyir. Bir böyük fərq, tətbiqin məsuliyyəti olan NoSQL dünyasında verilənlər bazası deyil, bütövlük məhdudiyyətlərinin olmamasıdır (məsələn, NULL deyil). Birincili açar bölmə düyməsindən (aşağıdakı nümunədəki Artist sütunu) və çoxluq təşkil edən sütunlardan (aşağıdakı nümunədəki SongTitle sütunu) ibarətdir. Bölmə açarı hansı hissəni / bölüşdürməyi müəyyənləşdirir və çoxluq sütunları verilən şardın içərisindəki məlumatların necə təşkil olunacağını müəyyənləşdirir.

KEYSPACE myapp yaradın;
Myapp istifadə edin;
CƏDVƏL CƏDVƏLİ Musiqi (
    Rəssam TEXT,
    SongTitle TEXT,
    AlbumTitle TEXT,
    İl INT,
    Qiymət FLOAT,
    Janr TEXT,
    Tənqidçi FLOAT,
    Teqlər TEXT,
    ÖYRƏNİŞ KEY (Sənətçi, SongTitle)
);

MongoDB

MongoDB Sənədləri (Cədvəldə bir sətirə bərabər) olan Koleksiyonları (Cədvəllərə bərabər) olan verilənlər bazasında (Cassandra Keyspace-a bərabər) məlumatları təşkil edir. Bir "hiyləsiz" bir verilənlər bazası olaraq, MongoDB-də vaxtından əvvəl sxemin tərifinə ehtiyac yoxdur. Aşağıda göstərilən "istifadə verilənlər bazası" əmri bazanı yeni yaradılan verilənlər bazasına kontekstin dəyişdirilməsi ilə birlikdə ilk dəfə adlandırır. Hətta kolleksiyaların açıq şəkildə yaradılmasına ehtiyac yoxdur, lakin ilk sənədləri yeni bir kolleksiyaya daxil etməklə avtomatik olaraq yaradılır. Qeyd edək ki, MongoDB standart verilənlər bazası testdir, buna görə verilənlər bazası göstərilmədən edilən hər hansı bir toplama səviyyəli əməliyyat bu standart kontekstdə aparılacaqdır.

myNewDatabase istifadə edin;

Bir cədvəl haqqında məlumat əldə edin

PostgreSQL

\ d Musiqi
"Public.music" cədvəli
    Sütun | Növ | Kollektiv | Pozulmayan | Defolt
-------------- + ----------------------- + ----------- + ---------- + --------
 rəssam | xarakter dəyişir (20) | | null deyil |
 songtitle | xarakter dəyişir (30) | | null deyil |
 albumtitle | xarakter dəyişir (25) | | |
 il | tam | | |
 qiymət | ikiqat dəqiqlik | | |
 janr | xarakter dəyişir (10) | | |
 tənqid edən | ikiqat dəqiqlik | | |
 etiketlər | mətn | | |
Göstəricilər:
    "music_pkey" PRIMARY KEY, btree (sənətçi, mahnı adı)

Cassandra

DİQQƏT TABLE MUSİQİ;
Myapp.music cədvəlini yaradın (
    rəssam mətni,
    mahnı mətni,
    albumtitle mətni,
    il int,
    qiymət dəyişir,
    janr mətni,
    etiketlər mətni,
    PRİMERİ KEY (sənətçi, mahnı adı)
) ƏLAQƏ SİFARİŞİ İLƏ (mahnı ASC)
    Və default_time_to_live = 0
    VƏ əməliyyatlar = {'effektiv': 'yalan'};

MongoDB

myNewDatabase istifadə edin;
kolleksiyalar göstərmək;

Məlumatları Cədvələ daxil edin

PostgreSQL

INSERT INTO Musiqi
    (Rəssam, SongTitle, AlbumTitle,
    İl, Qiymət, Janr, Tənqidçi,
    Etiketlər)
Dəyərlər (
    'Bilirsən heç kim', 'Bu gün mənə zəng et', 'Biraz məşhur',
    2015, 2.14, 'Ölkə', 7.8,
    '{"Bəstəkarlar": ["Smith", "Jones", "Devis"], "LengthInSeconds": 214}'
);
INSERT INTO Musiqi
    (Rəssam, SongTitle, AlbumTitle,
    Qiymət, Janr, Tənqidçi)
Dəyərlər (
    'Bildiyiniz heç kim', 'Köpək məkanım', 'İndi Hey'
    1.98, 'Ölkə', 8.4
);
INSERT INTO Musiqi
    (Rəssam, SongTitle, AlbumTitle,
    Qiymət, Janr)
Dəyərlər (
    'The Acme Band', 'Baxın, Dünya', 'Buck buradan başlayır',
    0.99, 'Qaya'
);
INSERT INTO Musiqi
    (Rəssam, SongTitle, AlbumTitle,
    Qiymət, Janr,
    Etiketlər)
Dəyərlər (
    'The Acme Band', 'Hələ Aşiq', 'Buck buradan başlayır',
    2.47, 'Qaya',
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tur günləri": {"Seattle": "20150625", "Klivlend": "20150630"}, "fırlanma": Ağır} '
);

Cassandra

Cassandra INSERT ifadələri ümumilikdə PostgreSQL ifadələrinə çox bənzəyir. Bununla birlikdə semantikada bir böyük fərq var. INSERT, cərgə artıq mövcud olduğu halda satırın son dəyərlərlə yeniləndiyi Cassandra-da bir əməliyyatdır.

Yuxarıdakı PostgreSQL INSERT ifadələri ilə eyni.

MongoDB

MongoDB eyni zamanda Cassandra'ya bənzər bir NoSQL verilənlər bazası olmasına baxmayaraq, daxiletmə əməliyyatı Cassandra ilə eyni semantik davranışa sahib deyil. MongoDB insert () -nin PostgreSQL-ə bənzər hala gətirmə imkanı yoxdur. Normal olaraq daxil edilməmiş bir davranış, toplanmaya əlavə edilmiş yeni bir sənəd gətirəcəkdir.

db.music.insert ({
rəssam: "Bilirsən heç kim",
   songTitle: "Bu gün mənə zəng et",
    albumTitle: "Biraz Məşhur",
    il: 2015,
    qiymət: 2.14,
    janr: "Ölkə",
    etiketlər: {
Bəstəkarlar: ["Smith", "Jones", "Devis"],
UzunluqSekundlar: 214
}
   }
);
db.music.insert ({
    rəssam: "Bilirsən heç kim",
    songTitle: "Mənim it ləkəm",
    albumTitle: "Hey İndi",
    qiymət: 1.98,
    janr: "Ölkə",
    tənqid edən: 8.4
   }
);
db.music.insert ({
    rəssam: "The Acme Band",
    songTitle: "Baxın, dünya",
    albumTitle: "Buck buradan başlayır",
    qiymət: 0.99,
    janr: "qaya"
   }
);
db.music.insert ({
    rəssam: "The Acme Band",
    songTitle: "Hələ Aşiq",
    albumTitle: "Buck buradan başlayır",
    qiymət: 2.47,
    janr: "Qaya",
    etiketlər: {
        radiostansiyalar Oyun: ["KHCR", "KBQX", "WTNR", "WJJH"],
        tur tarixləri: {
            Sietl: "20150625",
            Klivlend: "20150630"
        },
        fırlanma: "Ağır"
}
    }
);

Cədvəl soruşun

SQL və NoSQL arasındakı ən əhəmiyyətli fərq, modelləşdirmə sorğuları baxımından FROM və WHERE bəndlərinin istifadəsindədir. SQL FROM maddəsinə birdən çox cədvəl və HƏR yerə mübahisəli (masalar arasında QOŞULANMAQ) olan bəndin daxil olmasına imkan verir. Bununla birlikdə, NoSQL yalnız bir cədvəlin göstərildiyi və HARADA göstərişin həmişə əsas açarın olması üçün FROM maddəsinə sərt məhdudiyyət qoymağa çalışır. Bunun səbəbi, əvvəllər müzakirə etdiyimiz NoSQL-in hər hansı bir masa üstü və əsas açar qarşılıqlı əlaqəni azaltmağı hədəflədiyimiz yüksək fəaliyyət mərkəzidir. Bu cür qarşılıqlı əlaqə, sorğunun cavab vaxtına yüksək gecikmə çarpaz əlaqəsini təqdim edə bilər və buna görə də ən yaxşı şəkildə qarşısı alınır. Məsələn Cassandra, ikinci bir indeks sorğusu istisna olmaqla (yalnız = operatora icazə verilir) istisna olmaqla, bölmə açarlarında sorğuların operatorlar tərəfindən məhdudlaşdırılmasını tələb edir (yalnız =, IN, <,>, =>, <= icazə verilir).

PostgreSQL

Aşağıda SQL verilənlər bazası tərəfindən asanlıqla xidmət edilə bilən 3 növ sorğu var.

  • Bir sənətçinin bütün mahnılarını geri qaytarın
  • Bir sənətçinin bütün mahnılarını başlığın birinci hissəsinə uyğun qaytarın
  • Bir sənətçinin bütün mahnılarını başlıqda müəyyən bir sözlə qaytarın, ancaq qiyməti 1.00-dən az olduqda
SEÇİM * musiqidən
Harada Rəssam = 'Bildiyiniz Heç kim';
SEÇİM * musiqidən
WHER Artist = 'Bildiyiniz Heç kim' VƏ SongTitle 'Zəng%' 'BİLƏR;
SEÇİM * musiqidən
Harada Müğənni = 'Bildiyiniz Heç kim' VƏ SongTitle '%%%%%' kimi.
VƏ Qiymət> 1.00;

Cassandra

Yuxarıda göstərilən PostgreSQL sorğularından yalnız birincisi Cassandra ilə işləməyəcəkdir, çünki LIKE operatoruna SongTitle kimi çoxluq sütunlarında icazə verilmir. Bu vəziyyətdə yalnız = və IN operatorlarına icazə verilir.

SEÇİM * musiqidən
Harada Rəssam = 'Bildiyiniz Heç kim';
SEÇİM * musiqidən
Harada Sənətçi = 'Bildiyiniz heç kim yoxdur' və SongTitle IN ('Bu gün mənə zəng et', 'köpək məkanım')
VƏ Qiymət> 1.00;

MongoDB

Əvvəlki nümunələrdə göstərildiyi kimi, MongoDB sorğulamağın əsas metodu db.collection.find () metodudur. Bu üsul toplanması adı ilə seçilir (aşağıda göstərilən nümunədəki musiqi), çox açıq şəkildə soruşulur, buna görə koleksiyonlar arasında sorğu açıq şəkildə icazə verilmir.

db.music.find ({
  rəssam: "Bilirsən heç kim"
 }
);
db.music.find ({
  rəssam: "Bilirsən heç kim",
  songTitle: / Zəng et /
 }
);

Bir Cədvəldən Bütün Sıraları oxuyun

Bütün satırları oxumaq, əvvəllər müşahidə etdiyimiz ümumi sorğu nümunəsinin xüsusi bir haldır.

PostgreSQL

SEÇİM *
FROM Musiqi;

Cassandra

Yuxarıdakı PostgreSQL SELECT ifadəsi ilə eyni.

MongoDB

db.music.find ({});

Cədvəldə məlumatları dəyişdirin

PostgreSQL

PostgreSQL məlumatların dəyişdirilməsi üçün UPDATE bəyanatını təqdim edir. Sırat verilənlər bazasında mövcud deyilsə, bəyanat uğursuz olar, buna görə hər hansı bir yüksəliş imkanı vermir.

YENİLƏNİB Musiqi
SET Genre = 'Disko'
WHER Artist = 'The Acme Band' VƏ SongTitle = 'Hələ Aşiq';

Cassandra

Cassandra'nın PostgreSQL-ə bənzər bir UPDATE bəyanatı da var. YENİLƏNİB eyni zamanda INSERT ifadəsi ilə eyni semantika.

Yuxarıdakı PostgreSQL UPDATE bəyanatı ilə eyni.

MongoDB

MongoDB-nin yeniləmə () əməliyyatı mövcud sənədi tamamilə yeniləyə bilər və ya yalnız müəyyən sahələri yeniləyə bilər. Varsayılan olaraq, yuxarı semantika ilə yalnız bir sənəd yeniləyir. Əməliyyata əlavə bayraqlar qoyaraq çox sənədli yeniləmələr və yüksəliş davranışı açıla bilər. Məsələn Aşağıdakı nümunə sənətçinin mahnıları arasında müəyyən bir sənətkarın janrını yeniləyir.

db.music.update (
  {"artist": "The Acme Band"},
  {
    $ təyin olundu: {
      "janr": "Disko"
    }
  },
  {"çox": həqiqi, "upsert": həqiqi}
);

Bir Cədvəldən məlumatları silmək

PostgreSQL

Musiqidən DƏSTƏK
WHER Artist = 'The Acme Band' VƏ SongTitle = 'Baxın, dünya';

Cassandra

Yuxarıdakı PostgreSQL DELETE ifadəsi ilə eyni.

MongoDB

MongoDB sənəd silinməsini idarə etmək üçün iki növ əməliyyata malikdir - deleteOne () / deleteMany () və aradan qaldırılması (). Hər ikisi sənəd (ləri) silir, lakin fərqli dönüş nəticələri var.

db.music.deleteMany ({
        rəssam: "The Acme Band"
    }
);

Bir cədvəl çıxarın

PostgreSQL

DROP TABLE Musiqi;

Cassandra

Yuxarıdakı PostgreSQL DROP TABLE ifadəsi ilə eyni;

MongoDB

db.music.drop ();

Xülasə

SQL vs NoSQL mübahisəsi artıq on ildən bəri davam edir. Bu mübahisənin 2 tərəfi var: verilənlər bazasının əsas arxitekturası (monolit, əməliyyat SQL vs paylanmış, qeyri-əməliyyat NoSQL) və məlumat modelləşdirmə yanaşması (SQL-də məlumatlarınızı modelləşdirin və NoSQL-də sorğularınızı modelləşdirin).

YugaByte DB kimi paylanmış, əməliyyat bazası ilə mübahisənin verilənlər bazası əsas memarlıq hissəsi asanlıqla istirahətə verilə bilər. Məlumatların həcmi bir nodea yazıla biləndən daha çox böyüdükdə, avtomatik sarsıdıcı / yenidən balanslaşdırma ilə xətti yazma ölçüsünü əldə etməyə imkan verən tam paylanmış bir memarlıq zəruridir. Bundan əlavə, Google Cloud-dan bu yazıda göstərildiyi kimi, qeyri-tranzit, nəhayət ardıcıl memarlığa nisbətən daha yüksək inkişaf etdirici və əməliyyat çevikliyini təmin etmək üçün keçidli, güclü ardıcıl memarlıqlar indi geniş qəbul edilir.

Məlumatların modelləşdirilməsi müzakirəsinə gəldikdə, həm SQL, həm də NoSQL məlumat modelləşdirmə yanaşmalarının hər hansı bir mürəkkəb real dünya tətbiqi üçün vacib olduğunu söyləmək ədalətlidir. NoQQL modeli-sorğular yanaşması eyni tərtibatçılara böyük məlumat həcmini aşağı gecikmə və yüksək ötürmə qabiliyyəti ilə idarə etməyə imkan verir. Bu dəqiq bir səbəb budur ki, YugaByte DB həm SQL həm də NoSQL API-lərini ortaq nüvədə tətbiq edir, bunun əvəzinə bir yanaşmanın digərindən daha yaxşı olduğunu təbliğ edir. Bundan əlavə, PostgreSQL və Cassandra da daxil olmaqla populyar verilənlər bazası dilləri ilə tel uyğunluğunu təmin etməklə YugaByte DB, paylanmış güclü ardıcıl verilənlər bazası nüfuzundan faydalanmaq üçün inkişaf etdiricilərin başqa bir dil öyrənməmələrini təmin edir.

Bu yazı bizə məlumat modelləşdirmə əsaslarının PostgreSQL, Cassandra və MongoDB arasında necə fərqləndiyini anlamağa kömək etdi. Serialdakı növbəti yazılarda indekslər, əməliyyatlar, Qoşulma, TTL direktivləri və JSON sənədləri kimi qabaqcıl məlumat modelləşdirmə anlayışlarına girəcəyik.

Sonrakı nədir?

  • YugaByte DB-ni Amazon DynamoDB, Cassandra, MongoDB və Azure Cosmos DB kimi verilənlər bazaları ilə müqayisə edin.
  • MacOS, Linux, Docker və Kubernetes-də YugaByte DB ilə başlayın.
  • Lisenziyalaşdırma, qiymətlər və ya texniki baxış planı haqqında daha çox məlumat əldə etmək üçün bizimlə əlaqə saxlayın.

Əvvəlcə YugaByte Database Blogunda yayımlandı.