Duomenų modeliavimo pagrindai - „PostgreSQL“ ir „Cassandra“ prieš „MongoDB“

Programų kūrėjai paprastai praleidžia daug laiko vertindami kelias operacines duomenų bazes, kad surastų tą duomenų bazę, kuri labiausiai tinka jų darbo krūviui patenkinti. Šie poreikiai apima supaprastintą duomenų modeliavimą, operacijų garantijas, skaitymo / rašymo atlikimą, horizontalųjį mastelį ir atsparumą gedimams. Tradiciškai šis pasirinkimas prasideda nuo SQL ir NoSQL duomenų bazių kategorijų, nes kiekviena kategorija pateikia aiškų kompromisų rinkinį. Didelis našumas, susijęs su mažu vėlavimu ir dideliu pralaidumu, paprastai laikomas nepažeidžiamu reikalavimu, todėl to tikimasi bet kurioje pasirinktoje duomenų bazėje.

Šiuo įrašu siekiama padėti programų kūrėjams suprasti SQL ir NoSQL pasirinkimą atsižvelgiant į programos duomenų modeliavimo poreikius. Mes naudojame vieną SQL duomenų bazę, būtent „PostgreSQL“, ir 2 „NoSQL“ duomenų bazes, būtent „Cassandra“ ir „MongoDB“, kaip pavyzdžius, paaiškinančius duomenų modeliavimo pagrindus, tokius kaip lentelių sudarymas, duomenų įterpimas, nuskaitymas ir duomenų trynimas. Tolesniame pranešime apimsime pažangias temas, tokias kaip rodyklės, operacijos, prisijungimai, tiesioginio gyvenimo (TTL) direktyvos ir JSON pagrįstų dokumentų duomenų modeliavimas.

Kuo „NoSQL“ skiriasi nuo SQL duomenų modeliavime?

SQL duomenų bazės padidina programų judrumą, suteikdamos ACID operacijų garantijas, taip pat dėl ​​jų galimybės užklausti duomenis naudojant JOIN nenumatytais būdais, be esamų normalizuotų reliacinių duomenų modelių.

Atsižvelgiant į jų monolitinę / vieno mazgo architektūrą ir pagrindinio-pavaldinio replikacijos modelio naudojimą pertekliui, tradicinėse SQL duomenų bazėse trūksta dviejų svarbių galimybių - linijinio rašymo mastelio (t. Y. Automatinis sukrėtimas keliuose mazguose) ir automatinio / nulinio duomenų praradimo failover. Tai reiškia, kad perimti duomenų kiekiai negali viršyti maksimalios vieno mazgo rašymo spartos. Be to, turėtų būti tikimasi tam tikro laikino duomenų praradimo dėl netinkamo failo naudojimo (dėl bendro saugojimo nieko saugojimo architektūros), atsižvelgiant į tai, kad paskutiniai įsipareigojimai dar nebūtų pasirodę vergo replikoje. SQL duomenų bazių pasaulyje taip pat labai sunku pasiekti nulinį prastovų atnaujinimą.

„NoSQL“ duomenų bazės paprastai yra platinamos gamtoje, kai duomenys suskaidomi arba suskaidomi keliuose mazguose. Jie įpareigoja denormalizavimą, tai reiškia, kad įterptus duomenis taip pat reikia kelis kartus nukopijuoti, kad būtų pateiktos konkrečios jūsų mintys. Pagrindinis tikslas yra išgauti aukštą našumą aiškiai sumažinant skaldų, kuriomis pasiekiama skaitymo metu, skaičių. Taigi teiginys, kad „NoSQL“ reikalauja, kad jūs modeliuotumėte savo užklausas, o SQL reikalauja, kad modeliuotumėte savo duomenis.

„NoSQL“ dėmesys aukšto našumo paskirstytoje klasteryje pasiekimui yra pagrindinė priežastis, kelianti daugybę duomenų modeliavimo kompromisų, apimančių ACID operacijų, JOIN ir nuoseklių visuotinių antrinių indeksų praradimą.

Bendras supratimas yra tas, kad nors NoSQL duomenų bazės suteikia linijinį rašymo mastelį ir aukštą toleranciją gedimams, praradę operacijų garantijas jie tampa netinkami misijai svarbiems duomenims.

Šioje lentelėje aprašoma, kaip „NoSQL“ duomenų modeliavimas skiriasi nuo „SQL“.

SQL ir NoSQL - pagrindiniai duomenų modeliavimo skirtumai

SQL ir NoSQL: kodėl jums reikia abiejų?

Daugelį realaus pasaulio programų su patrauklia vartotojo patirtimi, tokioms kaip „Amazon.com“, „Netflix“, „Uber“ ir „Airbnb“, teikia vidinė energija, kurią sudaro sudėtingas kelių darbo krūvių mišinys. E. g. elektroninės komercijos programoje, tokioje kaip „Amazon.com“, reikia saugoti mažos apimties, labai svarbius duomenis, tokius kaip vartotojai, produktai, užsakymai, sąskaitos faktūros, kartu su didelės apimties ir mažiau svarbiais duomenimis, tokiais kaip produktų apžvalgos, pagalbos tarnybos pranešimai, vartotojo veikla, vartotojo rekomendacijos. Natūralu, kad šios programos remiasi bent viena SQL duomenų baze šalia bent vienos „NoSQL“ duomenų bazės. Keliuose regionuose ir visuotiniame diegime „NoSQL“ duomenų bazė taip pat veikia kaip geografiškai paskirstytas talpyklos duomenų, saugomų tiesos šaltinyje, SQL duomenų bazės, veikiančios viename regione, talpykla.

Kaip „YugaByte DB“ sujungia SQL ir „NoSQL“ į bendrą duomenų bazės branduolį?

„YugaByte DB“, sukurta remiantis unikaliu žurnališko struktūrizuoto sujungimo saugojimo variklio, automatinio sutrumpinimo, paskirstyto bendro sutarimo replikacijos ir paskirstytų ACID operacijų (įkvėptų „Google Spanner“) deriniu, „YugaByte DB“ yra pirmoji pasaulyje atvirojo kodo duomenų bazė, kuri yra ir „NoSQL“ („Cassandra“ ir „Redis“). suderinamas) ir SQL (suderinamas su PostgreSQL). Kaip parodyta toliau pateiktoje lentelėje, „YCQL“, „YugaByte DB“ suderinama API, prideda „vieno rakto“ ir „kelių raktų“ ACID operacijų ir pasaulinių antrinių indeksų sąvoką „NoSQL API“, tokiu būdu įvesdama „Transactional NoSQL“ erą. Be to, „YSQL“, „YugaByte DB“ suderinama „PostgreSQL“ API, prie SQL API prideda linijinio rašymo mastelio keitimo ir automatinio toleravimo gedimams sąvokas, taip parodydama paskirstyto SQL pasaulį. Kadangi „YugaByte DB“ yra pagrindinė operacija, net „NoSQL“ API dabar gali būti naudojama svarbių misijos duomenų kontekste.

„YugaByte DB“ - SQL ir „NoSQL“ vienoje duomenų bazėje

Kaip anksčiau buvo aprašyta skyriuje „Pristatome YSQL:„ PostgreSQL “suderinamą paskirstytą SQL API, skirtą„ YugaByte DB “,„ SQL “ir„ NoSQL “pasirinkimas„ YugaByte DB “visiškai priklauso nuo daugumos darbo krūvio ypatybių.

  • Jei didžiąją darbo dalį sudaro kelių klavišų operacijos su JOINS, tada rinkitės YSQL suprasdami, kad jūsų raktai gali būti paskirstyti keliuose mazguose, todėl padidėja delsos ir (arba) mažesnis pralaidumas nei „NoSQL“.
  • Kitu atveju pasirinkite vieną iš dviejų „NoSQL“ API suprasdami, kad gausite didesnę našumo naudą, jei užklausos pirmiausia bus teikiamos iš vieno mazgo vienu metu. „YugaByte DB“ gali tarnauti kaip vieninga operacinė duomenų bazė sudėtingoms realaus pasaulio programoms, kurios paprastai turi kelis darbo krūvius vienu metu valdyti.

Kitame skyriuje esanti duomenų modeliavimo laboratorija yra pagrįsta „YugaByte DB“ „PostgreSQL“ ir „Cassandra“ suderinamomis API, o ne originaliomis duomenų bazėmis. Šis požiūris pabrėžia sąveikos su dviem skirtingomis tos pačios duomenų bazės klasterio API (dviem skirtingais prievadais) paprastumą, o ne visiškai nepriklausomų dviejų skirtingų duomenų bazių grupių naudojimą.

Tolesniuose skyriuose mes apžvelgsime duomenų modeliavimo praktinę laboratoriją, kad būtų parodyti įvairūs duomenų bazių skirtumai ir keli bendrumai.

Duomenų modeliavimo laboratorija

Įdiekite duomenų bazes

Dėmesį sutelkdami į duomenų modeliavimą (o ne į sudėtingas diegimo architektūras), mes įdiegsime duomenų bazes „Docker“ konteineriuose savo vietinėse mašinose ir tada sąveikausime su jais naudodami atitinkamas komandų eilutės kriaukles.

„YugaByte DB“, suderinama su „PostgreSQL“ ir „Cassandra“ duomenų baze

„mkdir ~ / yugabyte && cd ~ / yugabyte
programėlė https://downloads.yugabyte.com/yb-docker-ctl && chmod + x yb-docker-ctl
dokininkas traukti „yugabytedb“ / „yugabyte“
./yb-docker-ctl sukurti - įgalinti_pavadinimus

„MongoDB“

doko paleidimas - vardas my-mongo -d mongo: vėliausias

Prieiga naudojant „Command Line Shell“

Kitas prisijungsime prie duomenų bazių naudodami atitinkamų API komandų eilutės apvalkalus.

„PostgreSQL“

psql yra komandų eilutės apvalkalas sąveikai su PostgreSQL. Kad būtų patogiau naudotis, „YugaByte DB“ yra šiukšliadėžėje su psql versija.

„docker“ vykdo yb-postgres-n1 / namai / jugabaitas / postgres / bin / psql -p 5433 -U postgres

Kasandra

„cqlsh“ yra komandų eilutės apvalkalas sąveikai su „Cassandra“ ir jos suderinamomis duomenų bazėmis per CQL („Cassandra Query Language“). Kad būtų patogiau naudotis, „YugaByte DB“ yra šiukšliadėžėje su „cqlsh“ versija.

Atminkite, kad CQL labai įkvepia SQL, panašios lentelių, eilučių, stulpelių ir rodyklių sąvokos. Tačiau, kaip „NoSQL“ kalba, pridedami konkretūs apribojimai, kuriuos dažniausiai peržiūrėsime savo tinklaraščių serijos metu.

„docker exec -it yb-tserver-n1“ / namai / „yugabyte“ / šiukšliadėžė / „cqlsh“

„MongoDB“

mongo yra komandų eilutės apvalkalas sąveikai su MongoDB. Jį galima rasti „MongoDB“ diegimo aplanke.

dokininkas vykdo mano mongo basą
kompaktinis diskas
mongo

Sukurkite lentelę

Dabar naudodamiesi komandų eilutės apvalkalu galime sąveikauti su įvairių operacijų duomenų baze. Pradėkime nuo lentelės, kurioje kaupiama informacija apie atlikėjų paskelbtas dainas, sudarymo. Šios dainos kartais būna albumo dalis. Kiti neprivalomi dainos atributai yra išleidimo metai, kaina, žanras ir kritiko reitingas. Mums reikia papildomų atributų, kurių mums gali prireikti ateityje, lauke „žymės“, kuriame galima laikyti pusiau struktūruotus duomenis kaip raktų ir reikšmių poras.

„PostgreSQL“

CREATE LABLE Muzika (
    Atlikėjas VARCHAR (20) NE NULL,
    „SongTitle VARCHAR“ (30) NE NULL,
    AlbumTitle VARCHAR (25),
    Metai INT,
    Kaina plūduriuoja,
    Žanras VARCHAR (10),
    Kritikuojantis PELNAS,
    Žymos TEKSTAS,
    PAGRINDINIS RAKTAS (atlikėjas, „SongTitle“)
);

Kasandra

Kurti lentelę „Cassandra“ yra labai panašu į „PostgreSQL“. Vienas didelis skirtumas yra vientisumo apribojimų (tokių kaip NOT NULL), už kuriuos atsakinga programa, o ne duomenų bazė NoSQL, atsakomybė. Pirminį raktą sudaro skaidinio raktas (stulpelis Atlikėjas žemiau pateiktame pavyzdyje) ir grupavimo stulpelių rinkinys („SongTitle“ stulpelis žemiau pateiktame pavyzdyje). Pasiskirstymo raktas nustato, į kurį skaidinį / šerdį įterpti eilutę, o grupavimo stulpeliai nurodo, kaip turėtų būti organizuojami duomenys tam tikroje šablone.

CREATE KEYSPACE „myapp“;
NAUDOTI „myapp“;
CREATE LABLE Muzika (
    Atlikėjo TEKSTAS,
    „SongTitle TEXT“,
    Albumo pavadinimo TEKSTAS,
    Metai INT,
    Kaina plūduriuoja,
    Žanras TEKSTAS,
    Kritikuojantis PELNAS,
    Žymos TEKSTAS,
    PAGRINDINIS RAKTAS (atlikėjas, „SongTitle“)
);

„MongoDB“

„MongoDB“ tvarko duomenis duomenų bazėse (lygiavertes „Cassandra Keyspace“), kuriose yra kolekcijos (lygiavertės lentelėms), turinčios dokumentus (lygiaverčius lentelės eilutei). Kaip „schemaless“ duomenų bazė, „MongoDB“ nereikia iš anksto apibrėžti schemos. Žemiau parodyta komanda „naudoti duomenų bazę“ suaktyvina duomenų bazę pirmą kartą, kai ji iškviečiama, keičiant kontekstą į naujai sukurtą duomenų bazę. Netgi kolekcijos nereikia kurti aiškiai, jos greičiau sukuriamos automatiškai, tiesiog įdedant pirmąjį dokumentą į naują kolekciją. Atminkite, kad „MongoDB“ numatytoji duomenų bazė yra bandymas, todėl visos rinkinio lygio operacijos, atliktos nenurodžius duomenų bazės, bus atliekamos šiame numatytajame kontekste.

naudoti „MyNewDatabase“;

Gaukite informacijos apie lentelę

„PostgreSQL“

\ d Muzika
Lentelė „public.music“
    Stulpelis | Tipas | Palyginimas | Nulinis | Numatytas
-------------- + ----------------------- + ----------- + ---------- + --------
 menininkas | pobūdis kintantis (20) | | nėra niekinis |
 dainos pavadinimas | pobūdis kintantis (30) | | nėra niekinis |
 albumo pavadinimas | pobūdis kintantis (25) | | |
 metai | sveikasis skaičius | | |
 kaina | dvigubas tikslumas | | |
 žanras | skiriasi simboliais (10) | | |
 kritikuojantis | dvigubas tikslumas | | |
 žymės | tekstas | | |
Rodyklės:
    „music_pkey“ PRIMARY KEY, btree (atlikėjas, dainos pavadinimas)

Kasandra

APRAŠYTI LENTELĖS MUZIKĄ;
KŪRIMO LENTELĖ „myapp.music“ (
    atlikėjo tekstas,
    dainos pavadinimo tekstas,
    albumo pavadinimo tekstas,
    metų int,
    kaina kintama,
    žanro tekstas,
    žymų tekstas,
    PRIMARY KEY (atlikėjas, dainos pavadinimas)
) SU KLASTERIJOS UŽSAKYMU (dainos pavadinimas ASC)
    IR „default_time_to_live“ = 0
    IR operacijos = {'įgalinta': 'klaidinga'};

„MongoDB“

naudoti „MyNewDatabase“;
parodų kolekcijos;

Įdėkite duomenis į lentelę

„PostgreSQL“

INSERT INTO Music
    (Atlikėjas, „SongTitle“, „AlbumTitle“
    Metai, Kaina, Žanras, Kritinis vertinimas,
    Žymos)
VERTYBĖS (
    „Niekas, ko nepažįsti“, „Skambink man šiandien“, „Šiek tiek garsus“,
    2015 m., 2.14, „Šalis“, 7.8,
    '{„Kompozitoriai“: [„Smith“, „Jones“, „Davis“], „LengthInSeconds“: 214} “
);
INSERT INTO Music
    (Atlikėjas, „SongTitle“, „AlbumTitle“
    Kaina, žanras, kritika vertinama)
VERTYBĖS (
    „Niekas, ko nepažįsti“, „Mano šuo vietoje“, „Ei, dabar“,
    1,98, „Šalis“, 8,4
);
INSERT INTO Music
    (Atlikėjas, „SongTitle“, „AlbumTitle“
    Kaina, žanras)
VERTYBĖS (
    „The Acme Band“, „Look out, World“, „The Buck Starts Here“,
    0,99, 'Rokas'
);
INSERT INTO Music
    (Atlikėjas, „SongTitle“, „AlbumTitle“
    Kaina, žanras,
    Žymos)
VERTYBĖS (
    „The Acme Band“, „Still In Love“, „The Buck Starts Here“,
    2,47, „Rokas“,
    '{„radioStationPlaying“: [„KHCR“, „KBQX“, „WTNR“, „WJJH“], „tourDates“: {„Sietlas“: „20150625“, „Cleveland“: „20150630“}, „rotacija“: Sunkus} '
);

Kasandra

„Cassandra INSERT“ teiginiai atrodo labai panašūs į „PostgreSQL“ apskritai. Tačiau yra vienas didelis semantikos skirtumas. INSERT iš tikrųjų yra viršutinė operacija Kasandroje, kur eilutė atnaujinama naujausiomis vertėmis, jei eilutė jau egzistuoja.

Tas pats, kaip aukščiau pateiktuose „PostgreSQL INSERT“ teiginiuose.

„MongoDB“

Nors „MongoDB“ taip pat yra „NoSQL“ duomenų bazė, panaši į „Cassandra“, jos įterpimo operacija neturi tokios pačios semantinės elgsenos kaip „Cassandra“. „MongoDB insert“ () neturi atnaujinimo galimybės, todėl jis yra panašus į „PostgreSQL“. Numatytasis įterpimo būdas, nenurodant _ids, bus įtrauktas naujas dokumentas į kolekciją.

db.music.insert ({
menininkas: „Niekas, ko nepažįsti“,
   songTitle: „Paskambink man šiandien“,
    albumTitle: "šiek tiek įžymus",
    metai: 2015,
    kaina: 2,14,
    žanras: „Šalis“,
    žymės: {
Kompozitoriai: [„Smith“, „Jones“, „Davis“],
Ilgis sekundėmis: 214
}
   }
);
db.music.insert ({
    menininkas: „Niekas, ko nepažįsti“,
    dainos pavadinimas: „My Dog Spot“,
    albumo pavadinimas: „Ei, dabar“,
    kaina: 1,98,
    žanras: „Šalis“,
    kritikuojantis: 8.4
   }
);
db.music.insert ({
    menininkas: „The Acme Band“,
    dainos pavadinimas: „Žiūrėk, pasaulis“,
    albumTitle: „The Buck Starts Here“,
    kaina: 0,99,
    žanras: „Rokas“
   }
);
db.music.insert ({
    menininkas: „The Acme Band“,
    dainos pavadinimas: „Vis dar įsimylėjęs“,
    albumTitle: „The Buck Starts Here“,
    kaina: 2,47,
    žanras: „Rokas“,
    žymės: {
        „radioStationPlaying“: „„ KHCR “,„ KBQX “,„ WTNR “,„ WJJH “],
        „tourDates“: {
            Sietlas: „20150625“,
            Klivlandas: „20150630“
        },
        sukimas: „sunkus“
}
    }
);

Užklauskite lentelę

Akivaizdu, kad reikšmingiausias SQL ir NoSQL skirtumas modeliuojant užklausas yra FROM ir WHERE sąlygų naudojimas. SQL leidžia FROM sąlygose apimti kelias lenteles, o WHERE sąlyga yra savavališkai sudėtinga (įskaitant JOINs lentelėse). Tačiau „NoSQL“ yra linkusi griežtai apriboti FROM sąlygą, kad būtų nurodyta tik viena lentelė, o WHERE sąlyga - visada turėtų būti nurodytas pagrindinis raktas. Taip yra todėl, kad aukščiau aptarėme „NoSQL“ našumą, kurio tikslas - sumažinti bet kokią kryžminę lentelę ir kryžminę sąveiką. Tokia sąveika gali įvesti labai vėlyvą kryžminių mazgų ryšį į užklausos atsakymo laiką, todėl to geriausia vengti. E. g. „Cassandra“ reikalauja, kad operatoriai apribotų užklausas (leidžiama naudoti tik =, IN, <,>, =>, <=) skaidinių klavišuose, išskyrus atvejus, kai užklausa pateikiama dėl antrinio indekso (kur leidžiama naudoti tik = operatorių).

„PostgreSQL“

Toliau pateikiami 3 užklausų tipai, kuriuos lengvai gali aptarnauti SQL duomenų bazė.

  • Grąžinkite visas atlikėjo dainas
  • Grąžinkite visas atlikėjo dainas, atitinkančias pirmąją pavadinimo dalį
  • Grąžinkite visas atlikėjo dainas su konkrečiu žodžiu pavadinime, bet tik tuo atveju, jei kaina yra mažesnė nei 1,00
PASIRINKITE * IŠ muzikos
KUR menininkas = 'Niekas, ko nepažįsti';
PASIRINKITE * IŠ muzikos
KUR Atlikėjas = 'Niekas, ko nepažįsti' IR 'SongTitle LIKE' skambinti% ';
PASIRINKITE * IŠ muzikos
KUR Atlikėjas = 'Niekas jūsų nepažįsta' IR DAINELĖS PATIKS '% Šiandien%'
IR kaina> 1,00;

Kasandra

Iš aukščiau išvardytų „PostgreSQL“ užklausų tik pirmoji veiks su „Cassandra“ nepakeista, nes „LIKE“ operatoriui neleidžiama klasteruoti stulpelius, tokius kaip „SongTitle“. Šiuo atveju leidžiama naudoti tik = ir IN operatorius.

PASIRINKITE * IŠ muzikos
KUR menininkas = 'Niekas, ko nepažįsti';
PASIRINKITE * IŠ muzikos
KUR menininkas = 'Niekas nepažįsti' IR 'SongTitle IN' ('Paskambink man šiandien', 'Mano šuo vietoje')
IR kaina> 1,00;

„MongoDB“

Kaip parodyta ankstesniuose pavyzdžiuose, pagrindinis „MongoDB“ užklausų pateikimo būdas yra metodas db.collection.find (). Šis metodas kvalifikuojamas atsižvelgiant į kolekcijos pavadinimą (muzika žemiau pateiktame pavyzdyje), kad reikia labai aiškiai paklausti, todėl užklausa visose kolekcijose yra aiškiai neleidžiama.

db.music.find ({
  menininkas: „Niekas, ko nepažįsti“
 }
);
db.music.find ({
  menininkas: „Niekas, ko nepažįsti“,
  songTitle: / Skambinti /
 }
);

Perskaitykite visas eilutes iš lentelės

Visų eilučių skaitymas yra tiesiog ypatingas bendro užklausos modelio, kurį stebėjome anksčiau, atvejis.

„PostgreSQL“

PASIRINKITE *
IŠ muzikos;

Kasandra

Tas pats, kaip aukščiau pateiktame „PostgreSQL SELECT“ teiginyje.

„MongoDB“

db.music.find ({});

Modifikuokite duomenis lentelėje

„PostgreSQL“

„PostgreSQL“ teikia UPDATE pareiškimą duomenims modifikuoti. Tai neleidžia jokios atnaujinimo galimybės, todėl teiginys žlugs, jei eilutės dar nėra duomenų bazėje.

ATNAUJINTI muzika
SET žanras = „Disko“
WHERE Artist = 'The Acme Band' IR SongTitle = 'Vis dar myliu';

Kasandra

„Cassandra“ taip pat turi UPDATE teiginį, panašų į „PostgreSQL“. ATNAUJINIMAS taip pat yra ta pati aukščiausio lygio semantika, kaip ir INSERT teiginyje.

Tas pats, kaip aukščiau pateiktas „PostgreSQL UPDATE“ teiginys.

„MongoDB“

„MongoDB“ atnaujinimo () operacija gali visiškai atnaujinti esamą dokumentą arba atnaujinti tik konkrečius laukus. Pagal numatytuosius nustatymus jis atnaujina tik vieną dokumentą, kai viršutinė semantika išjungta. Kelių dokumentų atnaujinimus ir aukštutinį elgesį galima įjungti nustatant papildomas operacijos vėliavas. E. g. toliau pateiktame pavyzdyje atnaujinamas konkretaus atlikėjo žanras visose atlikėjo dainose.

db.music.update (
  {"atlikėjas": "The Acme Band"},
  {
    JAV dolerių rinkinys: {
      "žanras": "Disko"
    }
  },
  {„multi“: true, „upsert“: true}
);

Ištrinkite duomenis iš lentelės

„PostgreSQL“

IŠtrinti iš muzikos
WHERE Artist = 'The Acme Band' IR SongTitle = 'Žiūrėk, pasaulis';

Kasandra

Tas pats, kaip aukščiau pateiktas „PostgreSQL DELETE“ teiginys.

„MongoDB“

„MongoDB“ turi dviejų tipų operacijas, skirtas tvarkyti dokumentų ištrynimus - deleteOne () / deleteMany () ir pašalinti (). Abu ištrina dokumentą (-us), tačiau jų grąžinimo rezultatai skiriasi.

db.music.deleteDaugelis ({
        menininkas: „The Acme Band“
    }
);

Pašalinkite lentelę

„PostgreSQL“

DROP LENTELĖ Muzika;

Kasandra

Tas pats, kaip aukščiau pateiktas „PostgreSQL DROP TABLE“ teiginys;

„MongoDB“

db.music.drop ();

Santrauka

SQL ir NoSQL diskusijos siautėja daugiau nei dešimtmetį. Yra du šios diskusijos aspektai: duomenų bazės pagrindinė architektūra (monolitinė, transakcinė SQL vs paskirstytoji, ne transakcinė NoSQL) ir duomenų modeliavimo metodas (modeliuokite savo duomenis SQL versijoje, modeliuokite savo užklausas NoSQL).

Naudodamiesi paskirstyta, operatyvine duomenų baze, pavyzdžiui, „YugaByte DB“, duomenų bazės pagrindinę architektūros dalį galima lengvai atstatyti. Didėjant duomenų kiekiui, viršijantį tai, ką galima surašyti į vieną mazgą, būtinai reikalinga visiškai paskirstyta architektūra, leidžianti linijinį rašymo mastelį automatiškai sukonfigūruoti / subalansuoti. Be to, kaip aprašyta šiame „Google Cloud“ įraše, dabar plačiai priimta transakcinė, labai nuosekli architektūra, užtikrinanti aukštesnį kūrėjų ir operacijų judrumą nei ne transakcinės, o galiausiai nuoseklios architektūros.

Atvykstant į diskusiją apie duomenų modeliavimą, reikia pasakyti, kad tiek SQL, tiek NoSQL duomenų modeliavimo metodai yra būtini bet kuriai sudėtingai realaus pasaulio programai. SQL modelio „jūsų duomenys“ metodas leidžia kūrėjams lengviau patenkinti kintančius verslo reikalavimus, o „NoSQL“ modelio „jūsų užklausos“ metodas leidžia tiems patiems kūrėjams valdyti didelius duomenų kiekius su mažu vėlavimu ir dideliu pralaidumu. Būtent dėl ​​šios priežasties „YugaByte DB“ diegia SQL ir NoSQL API į bendrą branduolį, užuot reklamuodama, kad vienas požiūris yra griežčiau geresnis už kitą. Be to, užtikrindama laidų suderinamumą su populiariomis duomenų bazių kalbomis, įskaitant „PostgreSQL“ ir „Cassandra“, „YugaByte DB“ užtikrina, kad kūrėjai nemokys kitos kalbos, kad galėtų naudotis paskirstyta griežtai nuoseklia duomenų bazės šerdimi.

Šis įrašas padėjo mums suprasti, kuo skiriasi duomenų modeliavimo pagrindai tarp PostgreSQL, Cassandra ir MongoDB. Tolesniuose serijos pranešimuose mes panardinsime į sudėtingesnes duomenų modeliavimo sąvokas, tokias kaip rodyklės, operacijos, JOIN, TTL direktyvos ir JSON dokumentai.

Kas toliau?

  • Palyginkite „YugaByte DB“ su tokiomis duomenų bazėmis kaip „Amazon DynamoDB“, „Cassandra“, „MongoDB“ ir „Azure Cosmos DB“.
  • Pradėkite nuo „YugaByte DB“ „macOS“, „Linux“, „Docker“ ir „Kubernetes“.
  • Susisiekite su mumis ir sužinokite daugiau apie licencijavimą, kainų nustatymą arba suplanuokite techninę apžvalgą.

Iš pradžių paskelbta „YugaByte“ duomenų bazės tinklaraštyje.