ProHoster > Blogs > Administrācija > Datu bāzes dizaina pamati ā€” PostgreSQL, Cassandra un MongoDB salÄ«dzināŔana

Datu bāzes dizaina pamati ā€” PostgreSQL, Cassandra un MongoDB salÄ«dzināŔana

Sveiki draugi. Pirms doÅ”anās uz maija brÄ«vdienu otro daļu, mēs dalāmies ar jums materiālā, ko mēs tulkojām, gaidot jaunas straumes uzsākÅ”anu kursā. "Relāciju DBVS".

Datu bāzes dizaina pamati ā€” PostgreSQL, Cassandra un MongoDB salÄ«dzināŔana

Lietojumprogrammu izstrādātāji pavada daudz laika, salÄ«dzinot vairākas operatÄ«vās datu bāzes, lai izvēlētos to, kas vislabāk atbilst paredzētajai darba slodzei. VajadzÄ«bas var ietvert vienkārÅ”otu datu modelÄ“Å”anu, darÄ«jumu garantijas, lasÄ«Å”anas/rakstÄ«Å”anas veiktspēju, horizontālo mērogoÅ”anu un kļūdu toleranci. Tradicionāli izvēle sākas ar datu bāzes kategoriju ā€” SQL vai NoSQL, jo katrai kategorijai ir skaidrs kompromisu kopums. Augsta veiktspēja zema latentuma un lielas caurlaidspējas ziņā parasti tiek uzskatÄ«ta par prasÄ«bu, kas nav kompromisa prasÄ«ba, un tāpēc tā ir bÅ«tiska jebkurai datubāzes paraugam.

Å Ä« raksta mērÄ·is ir palÄ«dzēt lietojumprogrammu izstrādātājiem lietojumprogrammu datu modelÄ“Å”anas kontekstā izdarÄ«t pareizo izvēli starp SQL un NoSQL. Mēs apskatÄ«sim vienu SQL datu bāzi, proti, PostgreSQL, un divas NoSQL datu bāzes, Cassandra un MongoDB, lai aptvertu datu bāzes dizaina pamatus, piemēram, tabulu izveidi, aizpildÄ«Å”anu, datu nolasÄ«Å”anu no tabulas un to dzÄ“Å”anu. Nākamajā rakstā mēs noteikti apskatÄ«sim indeksus, transakcijas, JOIN, TTL direktÄ«vas un uz JSON balstÄ«tu datu bāzes dizainu.

Kāda ir atŔķirība starp SQL un NoSQL?

SQL datu bāzes palielina lietojumprogrammu elastÄ«bu, izmantojot ACID darÄ«jumu garantijas, kā arÄ« spēju pieprasÄ«t datus, izmantojot JOIN neparedzētos veidos papildus esoÅ”ajiem normalizētajiem relāciju datu bāzes modeļiem.

Ņemot vērā to monolÄ«tu/viena mezgla arhitektÅ«ru un galvenā-pakalpojuma replikācijas modeļa izmantoÅ”anu dublÄ“Å”anai, tradicionālajām SQL datu bāzēm trÅ«kst divu svarÄ«gu funkciju - lineārās rakstÄ«Å”anas mērogojamÄ«bas (t.i., automātiska sadalÄ«Å”ana vairākos mezglos) un automātiska/nulles datu zuduma. Tas nozÄ«mē, ka saņemto datu apjoms nedrÄ«kst pārsniegt viena mezgla maksimālo rakstÄ«Å”anas jaudu. Turklāt, veicot kļūdu toleranci, ir jāņem vērā daži Ä«slaicÄ«gi datu zudumi (koplietojamā nekāda arhitektÅ«rā). Å eit jums jāpatur prātā, ka nesenās saistÄ«bas vēl nav atspoguļotas vergu kopijā. SQL datu bāzēs ir grÅ«ti sasniegt arÄ« atjauninājumus bez dÄ«kstāves.

NoSQL datu bāzes parasti tiek izplatÄ«tas pēc bÅ«tÄ«bas, t.i. tajos dati ir sadalÄ«ti sadaļās un sadalÄ«ti pa vairākiem mezgliem. Viņiem nepiecieÅ”ama denormalizācija. Tas nozÄ«mē, ka ievadÄ«tie dati ir arÄ« vairākas reizes jāpārkopē, lai atbildētu uz konkrētajiem jÅ«su sÅ«tÄ«tajiem pieprasÄ«jumiem. Vispārējais mērÄ·is ir iegÅ«t augstu veiktspēju, samazinot lasÄ«Å”anas laikā pieejamo lauskas. Tas nozÄ«mē, ka NoSQL ir jāmodelē vaicājumi, savukārt SQL ir jāmodelē dati.

NoSQL koncentrējas uz augstas veiktspējas sasniegÅ”anu sadalÄ«tā klasterÄ«, un tas ir daudzu datu bāzes dizaina kompromisu pamatā, kas ietver ACID darÄ«jumu zudumu, JOIN un konsekventus globālos sekundāros indeksus.

Pastāv arguments, ka, lai gan NoSQL datu bāzes nodroÅ”ina lineāru rakstÄ«Å”anas mērogojamÄ«bu un augstu kļūdu toleranci, darÄ«jumu garantiju zaudÄ“Å”ana padara tās nepiemērotas misijai kritiskiem datiem.

Å ajā tabulā parādÄ«ts, kā datu modelÄ“Å”ana NoSQL atŔķiras no SQL.

Datu bāzes dizaina pamati ā€” PostgreSQL, Cassandra un MongoDB salÄ«dzināŔana

SQL un NoSQL: kāpēc abi ir nepiecieÅ”ami?

Reālās pasaules lietojumprogrammām ar lielu lietotāju skaitu, piemēram, Amazon.com, Netflix, Uber un Airbnb, ir uzdots veikt sarežģītus, daudzpusÄ«gus uzdevumus. Piemēram, e-komercijas lietojumprogrammai, piemēram, Amazon.com, ir jāsaglabā viegli, ļoti kritiski dati, piemēram, lietotāja informācija, produkti, pasÅ«tÄ«jumi, rēķini, kā arÄ« smagi, mazāk sensitÄ«vi dati, piemēram, produktu apskati, atbalsta ziņojumi, lietotāju aktivitātes, lietotāju atsauksmes un ieteikumi. Protams, Ŕīs lietojumprogrammas balstās uz vismaz vienu SQL datu bāzi kopā ar vismaz vienu NoSQL datu bāzi. StarpreÄ£ionālās un globālās sistēmās NoSQL datu bāze darbojas kā Ä£eogrāfiski sadalÄ«ta keÅ”atmiņa datiem, kas tiek glabāti uzticama avota SQL datubāzē, kas darbojas noteiktā reÄ£ionā.

Kā YugaByte DB apvieno SQL un NoSQL?

YugaByte DB ir veidota uz žurnāliem orientēta jauktas krātuves dzinēja, automātiskās sadalÄ«Å”anas, sadalÄ«tās izplatÄ«tās vienprātÄ«bas replikācijas un ACID izplatÄ«tiem darÄ«jumiem (iedvesmojoties no Google Spanner), un tā ir pasaulē pirmā atvērtā pirmkoda datu bāze, kas vienlaikus ir saderÄ«ga ar NoSQL (Cassandra & Redis) un SQL (PostgreSQL). Kā parādÄ«ts tālāk esoÅ”ajā tabulā, YCQL, YugaByte DB API, kas ir saderÄ«ga ar Cassandra, pievieno NoSQL API viena un vairāku taustiņu ACID transakciju un globālo sekundāro indeksu jēdzienus, tādējādi ievadot darÄ«jumu NoSQL datu bāzu laikmetu. Turklāt YCQL, YugaByte DB API, kas ir saderÄ«ga ar PostgreSQL, pievieno SQL API lineārās rakstÄ«Å”anas mērogoÅ”anas un automātiskās kļūdu tolerances jēdzienus, nodroÅ”inot izplatÄ«tas SQL datu bāzes pasaulē. Tā kā YugaByte DB ir transakciju raksturs, NoSQL API tagad var izmantot misijai svarÄ«gu datu kontekstā.

Datu bāzes dizaina pamati ā€” PostgreSQL, Cassandra un MongoDB salÄ«dzināŔana

Kā minēts iepriekÅ” rakstā "IepazÄ«stinām ar YSQL: ar PostgreSQL saderÄ«gu izplatÄ«to SQL API YugaByte DB", izvēle starp SQL vai NoSQL YugaByte DB pilnÄ«bā ir atkarÄ«ga no pamatā esoŔās darba slodzes Ä«paŔībām:

  • Ja jÅ«su primārā darba slodze ir vairāku taustiņu JOIN darbÄ«bas, tad, izvēloties YSQL, ņemiet vērā, ka atslēgas var tikt sadalÄ«tas vairākos mezglos, kā rezultātā ir lielāks latentums un/vai mazāka caurlaidspēja nekā NoSQL.
  • Pretējā gadÄ«jumā izvēlieties vienu no divām NoSQL API, paturot prātā, ka jÅ«s iegÅ«sit labāku veiktspēju, ja vaicājumi tiks apkalpoti no viena mezgla vienlaikus. YugaByte DB var kalpot kā vienota operatÄ«va datu bāze reālām, sarežģītām lietojumprogrammām, kurām vienlaikus jāpārvalda vairākas darba slodzes.

Datu modelÄ“Å”anas laboratorija nākamajā sadaļā ir balstÄ«ta uz PostgreSQL un Cassandra API saderÄ«gām YugaByte DB datu bāzēm, nevis vietējām datu bāzēm. Å Ä« pieeja uzsver vienkārŔību mijiedarbÄ«bā ar divām dažādām vienas un tās paÅ”as datu bāzes klastera API (divos dažādos portos), pretstatā divu dažādu datu bāzu pilnÄ«gi neatkarÄ«gu klasteru izmantoÅ”anai.
Nākamajās sadaļās apskatÄ«sim datu modelÄ“Å”anas laboratoriju, lai ilustrētu aplÅ«koto datu bāzu atŔķirÄ«bas un dažas kopÄ«gās iezÄ«mes.

Datu modelēŔanas laboratorija

Datu bāzes uzstādīŔana

Ņemot vērā uzsvaru uz datu modeļu izstrādi (nevis sarežģītām izvietoÅ”anas arhitektÅ«rām), mēs instalēsim datu bāzes Docker konteineros vietējā datorā un pēc tam mijiedarbosimies ar tām, izmantojot atbilstoŔās komandrindas čaulas.

PostgreSQL un Cassandra saderīga YugaByte DB datu bāze

mkdir ~/yugabyte && cd ~/yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl
docker pull yugabytedb/yugabyte
./yb-docker-ctl create --enable_postgres

MongoDB

docker run --name my-mongo -d mongo:latest

Piekļuve komandrindai

Izveidosim savienojumu ar datu bāzēm, izmantojot atbilstoÅ”o API komandrindas apvalku.

PostgreSQL

psql ir komandrindas apvalks mijiedarbÄ«bai ar PostgreSQL. LietoÅ”anas ērtÄ«bai YugaByte DB ir aprÄ«kots ar psql tieÅ”i bin mapē.

docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres

Cassandra

cqlsh ir komandrindas apvalks mijiedarbÄ«bai ar Cassandra un tās saderÄ«gām datu bāzēm, izmantojot CQL (Cassandra Query Language). LietoÅ”anas ērtÄ«bai YugaByte DB nāk komplektā cqlsh katalogā bin.
Ņemiet vērā, ka CQL iedvesmoja SQL, un tai ir līdzīgi tabulu, rindu, kolonnu un indeksu jēdzieni. Tomēr kā NoSQL valoda tā pievieno noteiktu ierobežojumu kopumu, no kuriem lielāko daļu mēs apskatīsim arī citos rakstos.

docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh

MongoDB

Mongo ir komandrindas apvalks mijiedarbībai ar MongoDB. To var atrast MongoDB instalācijas bin direktorijā.

docker exec -it my-mongo bash 
cd bin
mongo

Izveidojiet tabulu

Tagad mēs varam mijiedarboties ar datu bāzi, lai veiktu dažādas darbÄ«bas, izmantojot komandrindu. Sāksim, izveidojot tabulu, kurā tiek glabāta informācija par dažādu mākslinieku sarakstÄ«tām dziesmām. Å Ä«s dziesmas var bÅ«t daļa no albuma. ArÄ« dziesmas izvēles atribÅ«ti ir izdoÅ”anas gads, cena, žanrs un vērtējums. Mums ir jāņem vērā papildu atribÅ«ti, kas var bÅ«t nepiecieÅ”ami nākotnē, izmantojot lauku "tags". Tas var uzglabāt daļēji strukturētus datus atslēgu un vērtÄ«bu pāru veidā.

PostgreSQL

CREATE TABLE Music (
    Artist VARCHAR(20) NOT NULL, 
    SongTitle VARCHAR(30) NOT NULL,
    AlbumTitle VARCHAR(25),
    Year INT,
    Price FLOAT,
    Genre VARCHAR(10),
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

Cassandra

Tabulas izveide programmā Cassandra ir ļoti lÄ«dzÄ«ga PostgreSQL. Viena no galvenajām atŔķirÄ«bām ir integritātes ierobežojumu trÅ«kums (piemēram, NOT NULL), taču par to atbild lietojumprogramma, nevis NoSQL datubāze.. Primārā atslēga sastāv no nodalÄ«juma atslēgas (kolonna IzpildÄ«tājs tālāk esoÅ”ajā piemērā) un klasteru kolonnu kopas (kolonna SongTitle tālāk esoÅ”ajā piemērā). SadalÄ«juma atslēga nosaka, kurā nodalÄ«jumā/sardā ir jāievieto rinda, un klasteru kolonnas norāda, kā dati ir jāsakārto paÅ”reizējā fragmentā.

CREATE KEYSPACE myapp;
USE myapp;
CREATE TABLE Music (
    Artist TEXT, 
    SongTitle TEXT,
    AlbumTitle TEXT,
    Year INT,
    Price FLOAT,
    Genre TEXT,
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

MongoDB

MongoDB sakārto datus datu bāzēs (datu bāzē) (lÄ«dzÄ«gi kā Cassandra Keyspace), kur ir kolekcijas (lÄ«dzÄ«gi tabulām), kas satur dokumentus (lÄ«dzÄ«gi tabulas rindām). MongoDB bÅ«tÄ«bā nav nepiecieÅ”ams definēt sākotnējo shēmu. Komanda "izmantot datu bāzi", parādÄ«ts zemāk, pirmajā izsaukumā izveido datubāzi un maina kontekstu jaunizveidotajai datubāzei. Pat kolekcijas nav Ä«paÅ”i jāizveido; tās tiek izveidotas automātiski, vienkārÅ”i pievienojot jaunai kolekcijai pirmo dokumentu. Ņemiet vērā, ka MongoDB pēc noklusējuma izmanto testa datu bāzi, tāpēc jebkura kolekcijas lÄ«meņa darbÄ«ba, nenorādot konkrētu datu bāzi, tajā darbosies pēc noklusējuma. 

use myNewDatabase;

Informācijas iegūŔana par tabulu
PostgreSQL

d Music
Table "public.music"
    Column    |         Type          | Collation | Nullable | Default 
--------------+-----------------------+-----------+----------+--------
 artist       | character varying(20) |           | not null | 
 songtitle    | character varying(30) |           | not null | 
 albumtitle   | character varying(25) |           |          | 
 year         | integer               |           |          | 
 price        | double precision      |           |          | 
 genre        | character varying(10) |           |          | 
 criticrating | double precision      |           |          | 
 tags         | text                  |           |          | 
Indexes:
    "music_pkey" PRIMARY KEY, btree (artist, songtitle)

Cassandra 

DESCRIBE TABLE MUSIC;
CREATE TABLE myapp.music (
    artist text,
    songtitle text,
    albumtitle text,
    year int,
    price float,
    genre text,
    tags text,
    PRIMARY KEY (artist, songtitle)
) WITH CLUSTERING ORDER BY (songtitle ASC)
    AND default_time_to_live = 0
    AND transactions = {'enabled': 'false'};

MongoDB

use myNewDatabase;
show collections;

Datu ievadīŔana tabulā
PostgreSQL

INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Year, Price, Genre, CriticRating, 
    Tags)
VALUES(
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2.14, 'Country', 7.8,
    '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, CriticRating)
VALUES(
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1.98, 'Country', 8.4
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre)
VALUES(
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0.99, 'Rock'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, 
    Tags)
VALUES(
    'The Acme Band', 'Still In Love', 'The Buck Starts Here',
    2.47, 'Rock', 
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}'
);

Cassandra

Kopējā izteiksme INSERT Cassandra izskatās ļoti lÄ«dzÄ«gi kā PostgreSQL. Tomēr semantikā ir viena liela atŔķirÄ«ba. Kasandrā INSERT patiesÄ«bā ir operācija UPSERT, kur rindai tiek pievienotas pēdējās vērtÄ«bas, ja rinda jau pastāv.

Datu ievade ir līdzīga PostgreSQL INSERT iepriekŔ

.

MongoDB

Lai gan MongoDB ir NoSQL datu bāze, piemēram, Cassandra, tās ievietoÅ”anas darbÄ«bai nav nekā kopÄ«ga ar Cassandra semantisko uzvedÄ«bu. Vietnē MongoDB ievietot () nav iespēju UPSERT, kas padara to lÄ«dzÄ«gu PostgreSQL. Noklusējuma datu pievienoÅ”ana bez _idspecified izraisÄ«s jauna dokumenta pievienoÅ”anu kolekcijai.

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

Tabulas vaicājums

Iespējams, visnozÄ«mÄ«gākā atŔķirÄ«ba starp SQL un NoSQL vaicājumu uzbÅ«ves ziņā ir izmantotā valoda FROM Šø WHERE. SQL atļauj pēc izteiksmes FROM atlasiet vairākas tabulas un izteiksmi ar WHERE var bÅ«t jebkuras sarežģītÄ«bas pakāpes (ieskaitot darbÄ«bas JOIN starp tabulām). Tomēr NoSQL mēdz uzlikt nopietnus ierobežojumus FROM, un strādāt tikai ar vienu norādÄ«tu tabulu, un iekŔā WHERE, vienmēr ir jānorāda primārā atslēga. Tas ir saistÄ«ts ar NoSQL veiktspēju, par kuru mēs runājām iepriekÅ”. Å Ä« vēlme noved pie jebkādas starptabulu un atslēgu mijiedarbÄ«bas samazināŔanas. Tas var izraisÄ«t lielu aizkavi starpmezglu saziņā, atbildot uz pieprasÄ«jumu, un tāpēc no tā vislabāk izvairÄ«ties. Piemēram, Cassandra pieprasa, lai vaicājumi tiktu ierobežoti ar noteiktiem operatoriem (tikai =, IN, <, >, =>, <=) uz nodalÄ«juma atslēgām, izņemot sekundārā indeksa pieprasÄ«Å”anu (Å”eit ir atļauts tikai operators =).

PostgreSQL

Tālāk ir sniegti trīs vaicājumu piemēri, kurus var viegli izpildīt SQL datu bāzē.

  • ParādÄ«t visas izpildÄ«tāja dziesmas;
  • ParādÄ«t visas izpildÄ«tāja dziesmas, kas atbilst nosaukuma pirmajai daļai;
  • Parādiet visas izpildÄ«tāja dziesmas, kuru nosaukumā ir noteikts vārds un kuru cena ir mazāka par 1.00. 
SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%'
AND Price > 1.00;

Cassandra

No iepriekÅ” uzskaitÄ«tajiem PostgreSQL vaicājumiem tikai pirmais Cassandra darbosies nemainÄ«gs, jo operators LIKE nevar piemērot klasterizācijas kolonnām, piemēram, SongTitle. Å ajā gadÄ«jumā ir atļauti tikai operatori = Šø IN.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot')
AND Price > 1.00;

MongoDB

Kā parādÄ«ts iepriekŔējos piemēros, galvenā metode vaicājumu izveidei MongoDB ir db.collection.find(). Å Ä« metode nepārprotami satur kolekcijas nosaukumu (music tālāk esoÅ”ajā piemērā), tāpēc vaicājumi vairākām kolekcijām ir aizliegti.

db.music.find( {
  artist: "No One You Know"
 } 
);
db.music.find( {
  artist: "No One You Know",
  songTitle: /Call/
 } 
);

Visu tabulas rindu lasīŔana

Visu rindu lasÄ«Å”ana ir vienkārÅ”i Ä«paÅ”s vaicājuma modeļa gadÄ«jums, ko mēs aplÅ«kojām iepriekÅ”.

PostgreSQL

SELECT * 
FROM Music;

Cassandra

LÄ«dzÄ«gi kā iepriekÅ” minētajā PostgreSQL piemērā.

MongoDB

db.music.find( {} );

Datu rediģēŔana tabulā

PostgreSQL

PostgreSQL sniedz norādÄ«jumus UPDATE lai mainÄ«tu datus. Viņai nav iespēju UPSERT, tāpēc Å”is paziņojums neizdosies, ja rinda vairs nebÅ«s datu bāzē.

UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

Cassandra

Kasandrai ir UPDATE līdzīgi kā PostgreSQL. UPDATE ir tāda pati semantika UPSERT, līdzīgi INSERT.

LÄ«dzÄ«gi kā iepriekÅ” minētajā PostgreSQL piemērā.

MongoDB
DarbÄ«ba Atjaunināt() MongoDB var pilnÄ«bā atjaunināt esoÅ”u dokumentu vai atjaunināt tikai noteiktus laukus. Pēc noklusējuma tas atjaunina tikai vienu dokumentu ar atspējotu semantiku UPSERT. Vairāku dokumentu atjaunināŔana un lÄ«dzÄ«ga rÄ«cÄ«ba UPSERT var pielietot, iestatot operācijai papildu karogus. Piemēram, zemāk esoÅ”ajā piemērā konkrēta izpildÄ«tāja žanrs tiek atjaunināts, pamatojoties uz viņa dziesmu.

db.music.update(
  {"artist": "The Acme Band"},
  { 
    $set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

Datu noņemÅ”ana no tabulas

PostgreSQL

DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

Cassandra

LÄ«dzÄ«gi kā iepriekÅ” minētajā PostgreSQL piemērā.

MongoDB

MongoDB ir divu veidu operācijas dokumentu dzÄ“Å”anai - deleteOne() /deleteDaudz() Šø noņemt (). Abi veidi dzÄ“Å” dokumentus, bet atgriež dažādus rezultātus. 

db.music.deleteMany( {
        artist: "The Acme Band"
    }
);

Tabulas dzēŔana

PostgreSQL

DROP TABLE Music;

Cassandra

LÄ«dzÄ«gi kā iepriekÅ” minētajā PostgreSQL piemērā.

MongoDB

db.music.drop();

Secinājums

Debates par izvēli starp SQL un NoSQL ir plosÄ«juŔās vairāk nekā 10 gadus. Å ajās debatēs ir divi galvenie aspekti: datu bāzes dzinēja arhitektÅ«ra (monolÄ«ta, transakciju SQL pret izplatÄ«tu, netransakciju NoSQL) un datu bāzes dizaina pieeja (datu modelÄ“Å”ana SQL versijā vaicājumu modelÄ“Å”ana NoSQL).

Izmantojot izplatÄ«tu darÄ«jumu datu bāzi, piemēram, YugaByte DB, debates par datu bāzes arhitektÅ«ru var viegli apturēt. Tā kā datu apjoms kļūst lielāks par to, ko var ierakstÄ«t vienā mezglā, kļūst nepiecieÅ”ama pilnÄ«bā izplatÄ«ta arhitektÅ«ra, kas atbalsta lineāro rakstÄ«Å”anas mērogojamÄ«bu ar automātisku sadalÄ«Å”anu/pārbalansÄ“Å”anu.

Turklāt, kā teikts vienā no rakstiem Google mākonis,Transakciju, stingri konsekventas arhitektūras tagad vairāk tiek izmantotas, lai nodroŔinātu labāku izstrādes veiklību, nekā netransakciju, galu galā konsekventas arhitektūras.

Atgriežoties pie datu bāzes dizaina diskusijas, ir godÄ«gi teikt, ka jebkurai sarežģītai reālās pasaules lietojumprogrammai ir nepiecieÅ”amas abas dizaina pieejas (SQL un NoSQL). SQL ā€œdatu modelÄ“Å”anasā€ pieeja ļauj izstrādātājiem vieglāk izpildÄ«t mainÄ«gās biznesa prasÄ«bas, savukārt NoSQL ā€œvaicājumu modelÄ“Å”anasā€ pieeja ļauj tiem paÅ”iem izstrādātājiem darboties ar lielu datu apjomu ar zemu latentumu un lielu caurlaidspēju. Å Ä« iemesla dēļ YugaByte DB nodroÅ”ina SQL un NoSQL API kopējā kodolā, nevis veicina kādu no pieejām. Turklāt, nodroÅ”inot saderÄ«bu ar populārām datu bāzes valodām, tostarp PostgreSQL un Cassandra, YugaByte DB nodroÅ”ina, ka izstrādātājiem nav jāmācās cita valoda, lai strādātu ar izplatÄ«tu, ļoti konsekventu datu bāzes dzinēju.

Å ajā rakstā mēs apskatÄ«jām, kā datu bāzes dizaina pamati atŔķiras starp PostgreSQL, Cassandra un MongoDB. Nākamajos rakstos mēs apskatÄ«sim uzlabotas dizaina koncepcijas, piemēram, indeksus, transakcijas, JOIN, TTL direktÄ«vas un JSON dokumentus.

Novēlam jums lielisku atlikuÅ”o nedēļas nogali un aicinām jÅ«s uz to bezmaksas vebinārs, kas notiks 14. maijā.

Avots: www.habr.com

Pievieno komentāru