Salutami, amichi. Prima di partì per a seconda parte di e vacanze di maghju, spartemu cun voi u materiale chì avemu traduttu in anticipazione di u lanciu di un novu flussu à u ritmu. .
I sviluppatori di l'applicazioni passanu assai tempu paragunendu parechje basa di dati operative per sceglie quella chì funziona megliu per a so carica di travagliu prevista. I bisogni ponu include un mudellu di dati simplificatu, garanzie transazionale, prestazioni di lettura / scrittura, scala horizontale è tolleranza di difetti. Tradizionalmente, a scelta principia cù a categuria di basa di dati, SQL o NoSQL, postu chì ogni categuria furnisce un settore chjaru di cummerci. L'altu rendimentu in termini di bassa latenza è altu throughput hè generalmente vistu cum'è un requisitu chì ùn pò micca esse cumprumessi è hè dunque essenziale per qualsiasi basa di dati in u sample.
U scopu di questu articulu hè di aiutà i sviluppatori di l'applicazioni à fà a scelta bona trà SQL è NoSQL in u cuntestu di a modellazione di dati di l'applicazione. Fighjemu una basa di dati SQL, vale à dì PostgreSQL, è duie basa di dati NoSQL, Cassandra è MongoDB, per copre i principii di cuncepimentu di basa di dati, cum'è a creazione di tavule, a populazione, a lettura di dati da una tavula è l'eliminazione. In u prossimu articulu, guardemu definitivamente indici, transazzioni, JOIN, direttive TTL, è cuncepimentu di basa di dati basatu in JSON.
Chì ghjè a diffarenza trà SQL è NoSQL?
E basa di dati SQL aumentanu a flessibilità di l'applicazioni attraversu e garanzie transazionali ACID, è ancu a so capacità di interrogà e dati usendu JOIN in modi inaspettati in cima à i mudelli di basa di dati relazionali nurmalizzati esistenti.
Data a so architettura di nodu monoliticu / unicu è l'usu di un mudellu di replicazione maestru-slave per a redundanza, e basa di dati tradiziunali SQL mancanu di duie funzioni impurtanti - scalabilità di scrittura lineare (vale à dì, splitting automaticu in parechji nodi) è perdita automatica / zero di dati. Questu significa chì a quantità di dati ricevuti ùn pò micca più di u massimu di scrittura di un unicu node. Inoltre, una certa perdita temporale di dati deve esse cunsiderata per a toleranza di difetti (in una architettura non-shared). Quì ci vole à tene in mente chì i cummissioni recenti ùn sò micca stati ancu riflessi in a copia di schiavi. Nisuna aghjurnamenti di downtime sò ancu difficiuli di ottene in basa di dati SQL.
E basa di dati NoSQL sò tipicamente distribuite in natura, i.e. in elli, i dati sò spartuti in rùbbriche è distribuite nantu à parechji nodi. Hanu bisognu di denormalizazione. Questu significa chì i dati inseriti devenu ancu esse copiati parechje volte per risponde à e dumande specifiche chì mandate. L'obiettivu generale hè di ottene un rendimentu altu riducendu u numeru di frammenti dispunibili in tempu di lettura. Questu implica chì NoSQL hà bisognu di mudificà e vostre dumande, mentre chì SQL hà bisognu di mudificà i vostri dati.
NoSQL enfatiza l'ottenimentu di un altu rendimentu in un cluster distribuitu è questu hè u ragiunamentu principale per parechji scambii di cuncepimentu di basa di dati, chì includenu a perdita di transazzione ACID, JOIN, è indici secundarii globale coerenti.
Ci hè una opinione chì, ancu s'è e basa di dati NoSQL furnisce una scalabilità di scrittura lineale è una alta toleranza di difetti, a perdita di garanzii transazzione li rende inadatti per i dati critichi.
A tavula seguente mostra cumu u mudellu di dati in NoSQL difiere da SQL.
SQL è NoSQL: Perchè sò i dui necessarii?
L'applicazioni di a vita reale cù un gran numaru d'utilizatori, cum'è Amazon.com, Netflix, Uber è Airbnb, sò rispunsevuli di eseguisce compiti cumplessi di varii tipi. Per esempiu, una applicazione di e-commerce cum'è Amazon.com hà bisognu di almacenà dati ligeri, assai sensibili, cum'è infurmazioni nantu à l'utilizatori, i prudutti, l'ordine, e fatture, cù dati pesanti ma menu sensibili cum'è recensioni di prudutti, messagi di supportu. , attività di l'utilizatori. , recensioni d'utilizatori è cunsiglii. Naturalmente, queste applicazioni si basanu in almenu una basa di dati SQL cù almenu una basa di dati NoSQL. In i sistemi inter-regionali è glubale, a basa di dati NoSQL funziona cum'è una cache geo-distribuita per i dati almacenati in una fonte di fiducia, basa di dati SQL, chì opera in ogni regione.
Cumu YugaByte DB combina SQL è NoSQL?
Custruitu nantu à un mutore di almacenamentu mistu orientatu à log, auto-sharding, replicazione di cunsensu distribuitu sharded, è transazzioni distribuite ACID (ispiratu da Google Spanner), YugaByte DB hè a prima basa di dati open source in u mondu chì hè simultaneamente compatible NoSQL (Cassandra & Redis). ) è SQL (PostgreSQL). Cum'è mostra in a tabella sottu, YCQL, una YugaByte DB API cumpatibile cù Cassandra, aghjunghjenu i cuncetti di transazzioni ACID unichi è multi-chiavi è indici secundarii glubale à l'API NoSQL, cusì ushering in l'era di basa di dati NoSQL transazzione. Inoltre, YCQL, una YugaByte DB API cumpatibile cù PostgreSQL, aghjunghjenu i cuncetti di scala di scrittura lineale è failover automaticu à l'API SQL, purtendu e basa di dati SQL distribuite in u mondu. Siccomu a basa di dati YugaByte DB hè intrinsecamente transazionale, l'API NoSQL pò avà esse aduprata in u cuntestu di dati critichi.
Cum'è dichjarata prima in l'articulu , l'scelta trà SQL o NoSQL in YugaByte DB dipende interamente da e caratteristiche di a carica di travagliu sottostante:
- Se a vostra carica di travagliu primariu hè l'operazione JOIN multi-key, allora quandu sceglite YSQL, sia cuscenti chì e vostre chjave pò esse sparse in parechji nodi, risultatu in una latenza più alta è / o un throughput più bassu cà NoSQL.
- Altrimenti, sceglite una di e duie API NoSQL, tenendu in mente chì averete un rendimentu megliu in u risultatu di e dumande servite da un node à u mumentu. YugaByte DB pò serve cum'è una basa di dati operativa unica per applicazioni cumplessi reali chì anu bisognu di gestisce parechje carichi di travagliu à u stessu tempu.
U laboratoriu di modellazione di Dati in a sezione dopu hè basatu annantu à l'API di basa di dati YugaByte DB compatibili PostgreSQL è Cassandra, in uppusizione à e basa di dati originali. Stu approcciu enfatizeghja a facilità di interagisce cù duie API diverse (in dui porti differenti) di u stessu cluster di basa di dati, in uppusizione à l'usu di clusters completamente indipendenti di duie basa di dati differenti.
In e seguenti sezzioni, daremu un ochju à u Laboratoriu di Modelling di Dati per illustrà a diffarenza è alcune di e cumune di e basa di dati in quistione.
Laboratoriu di Mudelle di Dati
Installazione di basa di dati
Data u focusu nantu à u disignu di mudelli di dati (piuttostu cà l'architetture di implementazione cumplesse), installemu e basa di dati in cuntenituri Docker in a macchina locale è poi interagisce cun elli utilizendu e so cunchiglia di linea di cummanda rispettivi.
Compatibile PostgreSQL è Cassandra, basa di dati YugaByte DB
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_postgresMongoDB
docker run --name my-mongo -d mongo:latestAccessu à a linea di cummanda
Cunnettamu à e basa di dati utilizendu a shell di linea di cumanda per e rispettive API.
PostgreSQL
hè una shell di linea di cummanda per interagisce cù PostgreSQL. Per facilità d'utilizazione, YugaByte DB vene cù psql ghjustu in u cartulare bin.
docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgresCassandra
hè una shell di linea di cummanda per interagisce cù Cassandra è e so basa di dati cumpatibili via CQL (Cassandra Query Language). Per facilità d'usu, YugaByte DB vene cun cqlsh in u catalogu bin.
Nota chì CQL hè stata inspirata da SQL è hà cuncetti simili di tabelle, fila, colonne è indici. In ogni casu, cum'è una lingua NoSQL, aghjunghje un certu settore di restrizioni, a maiò parte di quale avemu ancu copre in altri articuli.
docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlshMongoDB
hè una shell di linea di cummanda per interagisce cù MongoDB. Pò esse truvatu in u cartulare bin di l'installazione MongoDB.
docker exec -it my-mongo bash
cd bin
mongoCrea una tavola
Avà pudemu interagisce cù a basa di dati per fà diverse operazioni cù a linea di cummanda. Cuminciamu per creà una tavula chì guarda l'infurmazioni nantu à e canzoni scritte da diversi artisti. Queste canzoni ponu esse parti di un album. Ancu l'attributi opzionali per a canzone sò l'annu di liberazione, u prezzu, u generu è a classificazione. Avemu bisognu di piglià in contu attributi supplementari chì ponu esse necessariu in u futuru attraversu u campu "tags". Pò almacenà dati semi-strutturati cum'è coppie chjave-valore.
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
Crià una tavula in Cassandra hè assai simili à PostgreSQL. Una di e differenzi principali hè l'absenza di limitazioni di integrità (cum'è NOT NULL), ma questu hè a rispunsabilità di l'applicazione, micca a basa di dati NoSQL.. A chjave primaria hè custituita da una chjave di partizione (colonna Artista in l'esempiu quì sottu) è un inseme di colonne di clustering (colonna SongTitle in l'esempiu sottu). A chjave di partizione determina in quale partizione / frammentu mette a fila, è e colonne di clustering indicanu cumu i dati devenu esse urganizati in u frammentu attuale.
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 urganizeghja dati in basa di dati (Database) (simile à Keyspace in Cassandra), induve ci sò cullizzioni (Collections) (simile to tables) chì cuntenenu documenti (Documenti) (simile to rows in a table). In MongoDB, in principiu, ùn hè micca necessariu una definizione di schema iniziale. squadra "usà a basa di dati", mostratu quì sottu, instantiate a basa di dati nantu à a prima chjamata è cambia u cuntestu per a basa di dati di novu creatu. Ancu i cullezzione ùn anu micca bisognu di esse creatu esplicitamente, sò creati automaticamente, ghjustu quandu u primu documentu hè aghjuntu à una nova cullizzioni. Nota chì MongoDB usa una basa di dati di prova per difettu, cusì ogni operazione di livellu di cullezzione senza specificà una basa di dati specifica serà realizatu in questu per automaticamente.
use myNewDatabase;Ottene infurmazione nantu à una tavola
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;Ingressu dati in una tavula
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
In generale, l'espressione INSERT in Cassandra s'assumiglia assai à quellu in PostgreSQL. Tuttavia, ci hè una grande diferenza in semantica. In Cassandra INSERT hè veramente un'operazione UPSERT, induve l'ultimi valori sò aghjuntu à a stringa, in casu chì a stringa esiste digià.
L'entrata di dati hè simile à PostgreSQL
INSERTLingua
.
MongoDB
Ancu s'è MongoDB hè una basa di dati NoSQL cum'è Cassandra, a so operazione di ingressu di dati ùn hà nunda di fà cù u cumpurtamentu semanticu di Cassandra. In MongoDB ùn hà micca opportunità UPSERT, chì face simili à PostgreSQL. Aghjunghjendu dati predeterminati senza _idspecified resultarà in un novu documentu chì hè aghjuntu à a cullezzione.
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"
}
}
);
Interrogazione di a tavola
Forsi a diferenza più significativa trà SQL è NoSQL in quantu à l'interrogazione hè l'usu di FROM и WHERE. SQL permette dopu l'espressione FROM selezziunà parechje tavule, è una spressione cù WHERE pò esse di ogni cumplessità (cumprese operazioni JOIN trà tavule). Tuttavia, NoSQL tende à impone un limitu duru FROM, è travaglià cù una sola tavola specifica, è in WHERE, a chjave primaria deve esse sempre specificata. Questu hè duvuta à u desideriu di migliurà u rendiment di NoSQL, chì avemu parlatu prima. Stu desideriu porta à ogni riduzzione pussibule di ogni interazzione cross-tab è cross-key. Pò intruduce un grande ritardu in a cumunicazione inter-node quandu risponde à una dumanda è hè dunque megliu evitata in principiu. Per esempiu, Cassandra richiede chì e dumande sò limitate à certi operatori (solu permessi =, IN, <, >, =>, <=) nantu à e chjavi di partizione, eccettu quandu si dumanda un indice secundariu (solu l'operatore = hè permessu quì).
PostgreSQL
I seguenti sò trè esempi di dumande chì ponu esse facilmente eseguite da una basa di dati SQL.
- Mostra tutte e canzoni di l'artista;
- Mostra tutte e canzoni di l'artista chì currispondenu à a prima parte di u titulu;
- Mostra tutte e canzoni di un artista chì anu una certa parolla in u so titulu è anu un prezzu menu di 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
Di e dumande PostgreSQL elencate sopra, solu a prima funzionerà senza cambià in Cassandra, perchè a dichjarazione LIKE ùn pò micca esse appiicata à e culonni clustering cum'è SongTitle. In questu casu, solu l'operatori sò permessi = и 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
Comu mostratu in l'esempi precedenti, u metudu principale per creà dumande in MongoDB hè . Stu metudu cuntene esplicitamente u nome di a cullezzione (music in l'esempiu quì sottu), cusì ùn hè micca permessu di dumandà parechje cullezzione.
db.music.find( {
artist: "No One You Know"
}
);
db.music.find( {
artist: "No One You Know",
songTitle: /Call/
}
);Leghje tutte e fila di una tavula
A lettura di tutte e fila hè solu un casu speciale di u mudellu di quistione chì avemu discututu prima.
PostgreSQL
SELECT *
FROM Music;Cassandra
Simile à l'esempiu PostgreSQL sopra.
MongoDB
db.music.find( {} );Edizione di dati in una tavula
PostgreSQL
PostgreSQL furnisce una dichjarazione UPDATE per cambià i dati. Ella ùn hà micca opportunità UPSERT, cusì sta dichjarazione falla se a fila ùn hè più in a basa di dati.
UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';Cassandra
Cassandra hà UPDATE simile à PostgreSQL. UPDATE hà a stessa semantica UPSERT, cum'è INSERT.
Simile à l'esempiu PostgreSQL sopra.
MongoDB
Operazione in MongoDB pò aghjurnà cumplettamente un documentu esistente o aghjurnà solu certi campi. Per automaticamente, aghjurnà solu un documentu cù a semantica disattivata UPSERT. Refresh multiple documents è cumportamentu simili UPSERT pò esse appiicata mettendu bandiere supplementari per l'operazione. Comu per esempiu in l'esempiu sottu, u generu di un artista particulari hè aghjurnatu da a so canzone.
db.music.update(
{"artist": "The Acme Band"},
{
$set: {
"genre": "Disco"
}
},
{"multi": true, "upsert": true}
);Eliminazione di dati da una tavula
PostgreSQL
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';Cassandra
Simile à l'esempiu PostgreSQL sopra.
MongoDB
MongoDB hà dui tipi di operazioni per sguassà documenti - и . I dui tipi eliminanu documenti, ma tornanu risultati diffirenti.
db.music.deleteMany( {
artist: "The Acme Band"
}
);
Eliminazione di una tavola
PostgreSQL
DROP TABLE Music;Cassandra
Simile à l'esempiu PostgreSQL sopra.
MongoDB
db.music.drop();cunchiusioni
U dibattitu nantu à a scelta trà SQL è NoSQL hè in furia per più di 10 anni. Ci hè dui aspetti principali di stu dibattitu: l'architettura di u mutore di basa di dati (monoliticu, SQL transazzione versus NoSQL distribuitu, micca transazzione) è l'approcciu di u disignu di basa di dati (modelamentu di dati in SQL vs.
Cù una basa di dati transazionale distribuita cum'è YugaByte DB, u dibattitu di l'architettura di basa di dati pò esse facilmente dispelled. Cume i volumi di dati diventanu più grande di ciò chì pò esse scrittu à un unicu nodu, una architettura cumpletamente distribuita chì sustene a scalabilità di scrittura lineare cù sharding / rebalancing automaticu diventa necessaria.
In più di ciò chì era dettu in unu di l'articuli , l'architetture transazzione, fermamente consistente sò oghji più largamente aduttate per furnisce una flessibilità di sviluppu megliu cà l'architetture non transazzione, in ultimamente coherente.
Riturnendu à a discussione di u disignu di basa di dati, hè ghjustu dì chì i dui approcci di cuncepimentu (SQL è NoSQL) sò necessarii per qualsiasi applicazione cumplessa di u mondu reale. L'approcciu di "modelamentu di dati" di SQL permette à i sviluppatori di risponde più facilmente à i bisogni di l'affari cambianti, mentre chì l'approcciu di "modelamentu di query" di NoSQL permette à quelli stessi sviluppatori di trattà grandi quantità di dati cù bassa latenza è altu throughput. Hè per questu mutivu chì YugaByte DB furnisce API SQL è NoSQL in un core cumuni, è ùn sustene micca alcunu di l'approcciu. Inoltre, furnisce a cumpatibilità cù e lingue di basa di dati populari, cumprese PostgreSQL è Cassandra, YugaByte DB assicura chì i sviluppatori ùn anu micca bisognu di amparà una altra lingua per travaglià cù un mutore di basa di dati distribuitu forte.
In questu articulu, avemu vistu cumu i fundamenti di cuncepimentu di basa di dati sò diffirenti trà PostgreSQL, Cassandra è MongoDB. In l'articuli seguenti, ci immergeremu in cuncetti di cuncepimentu avanzati cum'è indici, transazzioni, JOIN, direttive TTL è documenti JSON.
Vi pregu un bellu weekend è vi invitamu chì si ferà u 14 di maghju.
Source: www.habr.com