Helo, ffrindiau. Cyn gadael am ail ran gwyliau mis Mai, rydym yn rhannu gyda chi y deunydd a gyfieithwyd gennym yn barod ar gyfer lansio ffrwd newydd ar y cwrs. .
Mae datblygwyr cymwysiadau yn treulio llawer o amser yn cymharu cronfeydd data gweithredol lluosog i ddewis yr un sy'n gweddu orau i'r llwyth gwaith arfaethedig. Gall anghenion gynnwys modelu data wedi'i symleiddio, gwarantau trafodion, perfformiad darllen/ysgrifennu, graddio llorweddol, a goddefgarwch o ddiffygion. Yn draddodiadol, mae'r dewis yn dechrau gyda'r categori cronfa ddata, SQL neu NoSQL, gan fod pob categori yn cyflwyno set glir o gyfaddawdau. Mae perfformiad uchel o ran hwyrni isel a thrwybwn uchel yn cael ei weld yn gyffredinol fel gofyniad nad yw'n gyfaddawdu ac felly mae'n hanfodol ar gyfer unrhyw gronfa ddata sampl.
Pwrpas yr erthygl hon yw helpu datblygwyr cymwysiadau i wneud y dewis cywir rhwng SQL a NoSQL yng nghyd-destun modelu data cais. Byddwn yn edrych ar un gronfa ddata SQL, sef PostgreSQL, a dwy gronfa ddata NoSQL, Cassandra a MongoDB, i gwmpasu hanfodion dylunio cronfa ddata, megis creu tablau, eu poblogi, darllen data o dabl, a'i ddileu. Yn yr erthygl nesaf, byddwn yn sicr o edrych ar fynegeion, trafodion, JOINs, cyfarwyddebau TTL, a dyluniad cronfa ddata yn seiliedig ar JSON.
Beth yw'r gwahaniaeth rhwng SQL a NoSQL?
Mae cronfeydd data SQL yn cynyddu hyblygrwydd cymwysiadau trwy warantau trafodion ACID, yn ogystal â'u gallu i gwestiynu data gan ddefnyddio JOINs mewn ffyrdd annisgwyl ar ben modelau cronfa ddata berthynol normaleiddio presennol.
O ystyried eu pensaernïaeth fonolithig/nôd sengl a’r defnydd o fodel atgynhyrchu meistr-gaethwas ar gyfer diswyddo, nid oes dwy nodwedd bwysig i gronfeydd data SQL traddodiadol - graddadwyedd ysgrifennu llinol (h.y. rhaniad awtomatig ar draws nodau lluosog) a cholli data yn awtomatig/sero. Mae hyn yn golygu na all swm y data a dderbynnir fod yn fwy na'r uchafswm trwybwn ysgrifennu o un nod. Yn ogystal, rhaid ystyried rhywfaint o golli data dros dro mewn goddefgarwch namau (mewn pensaernïaeth dim byd a rennir). Yma mae angen ichi gadw mewn cof nad yw ymrwymiadau diweddar wedi'u hadlewyrchu eto yn y copi caethweision. Mae diweddariadau heb fod yn amser segur hefyd yn anodd eu cyflawni mewn cronfeydd data SQL.
Fel arfer dosberthir cronfeydd data NoSQL yn ôl natur, h.y. ynddynt, rhennir data yn adrannau a'u dosbarthu ar draws sawl nod. Mae angen dadnormaleiddio arnynt. Mae hyn yn golygu bod yn rhaid i'r data a gofnodwyd hefyd gael ei gopïo sawl gwaith i ymateb i'r ceisiadau penodol yr ydych yn eu hanfon. Y nod cyffredinol yw cael perfformiad uchel trwy leihau nifer y darnau darnau sydd ar gael yn ystod darlleniadau. Mae hyn yn awgrymu bod NoSQL yn gofyn ichi fodelu'ch ymholiadau, tra bod SQL yn gofyn ichi fodelu'ch data.
Mae NoSQL yn canolbwyntio ar gyflawni perfformiad uchel mewn clwstwr gwasgaredig a dyma'r rhesymeg sylfaenol ar gyfer llawer o gyfaddawdau dylunio cronfa ddata sy'n cynnwys colledion trafodion ACID, JOINs, a mynegeion eilaidd byd-eang cyson.
Mae dadl, er bod cronfeydd data NoSQL yn darparu graddadwyedd ysgrifennu llinol a goddefgarwch diffygion uchel, mae colli gwarantau trafodion yn eu gwneud yn anaddas ar gyfer data sy'n hanfodol i genhadaeth.
Mae'r tabl canlynol yn dangos sut mae modelu data yn NoSQL yn wahanol i SQL.
SQL a NoSQL: Pam mae angen y ddau?
Mae cymwysiadau byd go iawn gyda nifer fawr o ddefnyddwyr, fel Amazon.com, Netflix, Uber, ac Airbnb, yn cael y dasg o gyflawni tasgau cymhleth, amlochrog. Er enghraifft, mae angen i raglen e-fasnach fel Amazon.com storio data ysgafn, beirniadol iawn megis gwybodaeth defnyddwyr, cynhyrchion, archebion, anfonebau, ynghyd â data trwm, llai sensitif fel adolygiadau cynnyrch, negeseuon cymorth, gweithgaredd defnyddwyr, adolygiadau defnyddwyr ac argymhellion. Yn naturiol, mae'r cymwysiadau hyn yn dibynnu ar o leiaf un gronfa ddata SQL ynghyd ag o leiaf un gronfa ddata NoSQL. Mewn systemau traws-ranbarthol a byd-eang, mae cronfa ddata NoSQL yn gweithredu fel storfa geo-ddosbarthu ar gyfer data sy'n cael ei storio mewn cronfa ddata SQL ffynhonnell ddibynadwy sy'n rhedeg mewn rhanbarth penodol.
Sut mae YugaByte DB yn cyfuno SQL a NoSQL?
Wedi'i adeiladu ar beiriant storio cymysg sy'n canolbwyntio ar foncyffion, carpio, atgynhyrchu consensws gwasgaredig wedi'i rwygo a thrafodion dosbarthedig ACID (wedi'i ysbrydoli gan Google Spanner), YugaByte DB yw cronfa ddata ffynhonnell agored gyntaf y byd sy'n gydnaws ar yr un pryd â NoSQL (Cassandra & Redis ) a SQL (PostgreSQL). Fel y dangosir yn y tabl isod, mae YCQL, yr API YugaByte DB sy'n gydnaws â Cassandra, yn ychwanegu cysyniadau trafodion ACID sengl ac aml-allweddol a mynegeion eilaidd byd-eang i'r API NoSQL, gan arwain at oes cronfeydd data trafodion NoSQL. Yn ogystal, mae YCQL, yr API YugaByte DB sy'n gydnaws â PostgreSQL, yn ychwanegu'r cysyniadau o raddio ysgrifennu llinol a goddefgarwch namau awtomatig i'r API SQL, gan ddod â chronfeydd data SQL dosbarthedig i'r byd. Oherwydd bod YugaByte DB yn drafodol ei natur, gellir defnyddio'r API NoSQL bellach yng nghyd-destun data sy'n hanfodol i genhadaeth.
Fel y dywedwyd yn flaenorol yn yr erthygl , mae'r dewis rhwng SQL neu NoSQL yn YugaByte DB yn dibynnu'n llwyr ar nodweddion y llwyth gwaith sylfaenol:
- Os mai gweithrediadau JOIN aml-allwedd yw eich prif lwyth gwaith, yna wrth ddewis YSQL, deallwch y gall eich allweddi gael eu dosbarthu ar draws nodau lluosog, gan arwain at hwyrni uwch a/neu trwybwn is na NoSQL.
- Fel arall, dewiswch y naill neu'r llall o'r ddau API NoSQL, gan gadw mewn cof y byddwch yn cael gwell perfformiad o ganlyniad i ymholiadau a gyflwynir o un nod ar y tro. Gall YugaByte DB wasanaethu fel un gronfa ddata weithredol ar gyfer cymwysiadau cymhleth yn y byd go iawn sydd angen rheoli llwythi gwaith lluosog ar yr un pryd.
Mae'r labordy modelu Data yn yr adran nesaf yn seiliedig ar gronfeydd data YugaByte DB sy'n gydnaws â API PostgreSQL a Cassandra, yn hytrach na chronfeydd data brodorol. Mae'r dull hwn yn pwysleisio pa mor hawdd yw rhyngweithio â dau API gwahanol (ar ddau borthladd gwahanol) o'r un clwstwr cronfa ddata, yn hytrach na defnyddio clystyrau cwbl annibynnol o ddwy gronfa ddata wahanol.
Yn yr adrannau canlynol, byddwn yn edrych ar y labordy modelu data i ddangos y gwahaniaethau a rhai o nodweddion cyffredin y cronfeydd data dan sylw.
Labordy Modelu Data
Gosod cronfa ddata
O ystyried y pwyslais ar ddylunio model data (yn hytrach na phensaernïaeth defnyddio cymhleth), byddwn yn gosod cronfeydd data mewn cynwysyddion Docker ar y peiriant lleol ac yna'n rhyngweithio â nhw gan ddefnyddio eu cregyn llinell orchymyn priodol.
Cronfa ddata DB YugaByte gydnaws PostgreSQL & Cassandra
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:latestMynediad llinell orchymyn
Gadewch i ni gysylltu â'r cronfeydd data gan ddefnyddio'r gragen llinell orchymyn ar gyfer yr APIs cyfatebol.
PostgreSQL
yn gragen llinell orchymyn ar gyfer rhyngweithio â PostgreSQL. Er hwylustod, daw YugaByte DB gyda psql reit yn y ffolder bin.
docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgresCassandra
yn gragen llinell orchymyn ar gyfer rhyngweithio â Cassandra a'i gronfeydd data cydnaws trwy CQL (Iaith Ymholiad Cassandra). Er hwylustod, daw YugaByte DB gyda cqlsh yn y catalog bin.
Sylwch fod CQL wedi'i ysbrydoli gan SQL a bod ganddo gysyniadau tebyg o dablau, rhesi, colofnau a mynegeion. Fodd bynnag, fel iaith NoSQL, mae'n ychwanegu set benodol o gyfyngiadau, y byddwn yn ymdrin â'r rhan fwyaf ohonynt mewn erthyglau eraill hefyd.
docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlshMongoDB
yn gragen llinell orchymyn ar gyfer rhyngweithio â MongoDB. Mae i'w gael yng nghyfeirlyfr biniau gosodiad MongoDB.
docker exec -it my-mongo bash
cd bin
mongoCreu bwrdd
Nawr gallwn ryngweithio â'r gronfa ddata i gyflawni gweithrediadau amrywiol gan ddefnyddio'r llinell orchymyn. Gadewch i ni ddechrau trwy greu tabl sy'n storio gwybodaeth am ganeuon a ysgrifennwyd gan wahanol artistiaid. Gall y caneuon hyn fod yn rhan o albwm. Hefyd nodweddion dewisol cân yw blwyddyn rhyddhau, pris, genre a sgôr. Mae angen i ni roi cyfrif am briodoleddau ychwanegol y gall fod eu hangen yn y dyfodol trwy'r maes "tagiau". Gall storio data lled-strwythuredig ar ffurf parau gwerth allweddol.
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
Mae creu tabl yn Cassandra yn debyg iawn i PostgreSQL. Un o'r prif wahaniaethau yw'r diffyg cyfyngiadau cywirdeb (e.e. NOT NULL), ond cyfrifoldeb y cais yw hyn, nid cronfa ddata NoSQL. Mae'r allwedd gynradd yn cynnwys allwedd rhaniad (y golofn Artist yn yr enghraifft isod) a set o golofnau clystyru (colofn SongTitle yn yr enghraifft isod). Mae'r allwedd rhaniad yn pennu i ba raniad / teiar y dylid gosod y rhes, ac mae'r colofnau clystyru yn nodi sut y dylid trefnu'r data o fewn y darn presennol.
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
Mae MongoDB yn trefnu data i gronfeydd data (Cronfa Ddata) (tebyg i Keyspace yn Cassandra), lle mae Casgliadau (tebyg i dablau) sy'n cynnwys Dogfennau (tebyg i resi mewn tabl). Yn MongoDB, yn y bôn nid oes angen diffinio sgema cychwynnol. Tîm "defnyddio cronfa ddata", a ddangosir isod, yn cychwyn y gronfa ddata ar yr alwad gyntaf ac yn newid y cyd-destun ar gyfer y gronfa ddata sydd newydd ei chreu. Nid oes angen creu casgliadau’n benodol hyd yn oed; cânt eu creu’n awtomatig, dim ond pan fyddwch yn ychwanegu’r ddogfen gyntaf at gasgliad newydd. Sylwch fod MongoDB yn defnyddio'r gronfa ddata prawf yn ddiofyn, felly bydd unrhyw weithrediad lefel casglu heb nodi cronfa ddata benodol yn rhedeg arno yn ddiofyn.
use myNewDatabase;Cael gwybodaeth am dabl
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;Mewnbynnu data i dabl
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
Mynegiant cyffredinol INSERT yn Cassandra yn edrych yn debyg iawn i'r un yn PostgreSQL. Fodd bynnag, mae un gwahaniaeth mawr mewn semanteg. Yn Cassandra INSERT mewn gwirionedd yn llawdriniaeth UPSERT, lle mae'r gwerthoedd olaf yn cael eu hychwanegu at y rhes os yw'r rhes yn bodoli eisoes.
Mae cofnodi data yn debyg i PostgreSQL
INSERTuchod
.
MongoDB
Er bod MongoDB yn gronfa ddata NoSQL fel Cassandra, nid oes gan ei weithrediad mewnosod ddim byd yn gyffredin ag ymddygiad semantig Cassandra. Yn MongoDB dim cyfleoedd UPSERT, sy'n ei gwneud yn debyg i PostgreSQL. Ychwanegu data rhagosodedig heb _idspecified yn achosi i ddogfen newydd gael ei hychwanegu at y casgliad.
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"
}
}
);
Ymholiad Tabl
Efallai mai'r gwahaniaeth mwyaf arwyddocaol rhwng SQL a NoSQL o ran llunio ymholiad yw'r iaith a ddefnyddir FROM и WHERE. Mae SQL yn caniatáu ar ôl mynegiant FROM dewis tablau lluosog, a mynegiant gyda WHERE gall fod o unrhyw gymhlethdod (gan gynnwys gweithrediadau JOIN rhwng byrddau). Fodd bynnag, mae NoSQL yn tueddu i osod cyfyngiad difrifol ar FROM, ac yn gweithio gydag un bwrdd penodedig yn unig, ac yn WHERE, rhaid nodi'r allwedd gynradd bob amser. Mae hyn yn gysylltiedig â gwthio perfformiad NoSQL y buom yn siarad amdano'n gynharach. Mae'r awydd hwn yn arwain at bob gostyngiad posibl mewn unrhyw ryngweithio traws-dabl a thraws-allweddol. Gall achosi oedi mawr mewn cyfathrebu rhwng nodau wrth ymateb i gais ac felly mae'n well ei osgoi yn gyffredinol. Er enghraifft, mae Cassandra yn ei gwneud yn ofynnol i ymholiadau gael eu cyfyngu i rai gweithredwyr (yn unig =, IN, <, >, =>, <=) ar allweddi rhaniad, ac eithrio wrth ofyn am fynegai eilaidd (dim ond y gweithredwr = a ganiateir yma).
PostgreSQL
Isod mae tair enghraifft o ymholiadau y gellir eu gweithredu'n hawdd gan gronfa ddata SQL.
- Arddangos pob cân gan artist;
- Arddangos holl ganeuon yr artist sy'n cyfateb i ran gyntaf y teitl;
- Dangoswch bob cân gan artist sydd â gair penodol yn y teitl ac sydd â phris yn llai na 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
O'r ymholiadau PostgreSQL a restrir uchod, dim ond yr un cyntaf fydd yn gweithio'n ddigyfnewid yn Cassandra, gan fod y gweithredwr LIKE ni ellir ei gymhwyso i glystyru colofnau megis SongTitle. Yn yr achos hwn, dim ond gweithredwyr a ganiateir = и 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
Fel y dangosir yn yr enghreifftiau blaenorol, y prif ddull ar gyfer creu ymholiadau yn MongoDB yw . Mae'r dull hwn yn cynnwys enw'r casgliad yn benodol (music yn yr enghraifft isod), felly gwaherddir ymholi am gasgliadau lluosog.
db.music.find( {
artist: "No One You Know"
}
);
db.music.find( {
artist: "No One You Know",
songTitle: /Call/
}
);Darllen pob rhes o fwrdd
Yn syml, mae darllen pob rhes yn achos arbennig o'r patrwm ymholiad y gwnaethom edrych arno'n gynharach.
PostgreSQL
SELECT *
FROM Music;Cassandra
Yn debyg i'r enghraifft PostgreSQL uchod.
MongoDB
db.music.find( {} );Golygu data mewn tabl
PostgreSQL
Mae PostgreSQL yn darparu cyfarwyddiadau UPDATE i newid data. Does ganddi hi ddim cyfleoedd UPSERT, felly bydd y datganiad hwn yn methu os nad yw'r rhes yn y gronfa ddata mwyach.
UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';Cassandra
Mae gan Cassandra UPDATE tebyg i PostgreSQL. UPDATE sydd â'r un semanteg UPSERT, tebyg INSERT.
Yn debyg i'r enghraifft PostgreSQL uchod.
MongoDB
Gweithredu gall yn MongoDB ddiweddaru dogfen sy'n bodoli yn llwyr neu ddiweddaru rhai meysydd yn unig. Yn ddiofyn, dim ond un ddogfen y mae'n ei diweddaru gyda semanteg wedi'i hanalluogi UPSERT. Diweddaru sawl dogfen ac ymddygiad tebyg UPSERT gellir ei gymhwyso trwy osod baneri ychwanegol ar gyfer y llawdriniaeth. Er enghraifft, yn yr enghraifft isod, mae genre artist penodol yn cael ei ddiweddaru yn seiliedig ar ei gân.
db.music.update(
{"artist": "The Acme Band"},
{
$set: {
"genre": "Disco"
}
},
{"multi": true, "upsert": true}
);Tynnu data o dabl
PostgreSQL
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';Cassandra
Yn debyg i'r enghraifft PostgreSQL uchod.
MongoDB
Mae gan MongoDB ddau fath o weithrediadau i ddileu dogfennau − и . Mae'r ddau fath yn dileu dogfennau ond yn dychwelyd canlyniadau gwahanol.
db.music.deleteMany( {
artist: "The Acme Band"
}
);
Dileu bwrdd
PostgreSQL
DROP TABLE Music;Cassandra
Yn debyg i'r enghraifft PostgreSQL uchod.
MongoDB
db.music.drop();Casgliad
Mae'r ddadl ynghylch dewis rhwng SQL a NoSQL wedi bod yn gynddeiriog ers mwy na 10 mlynedd. Mae dwy brif agwedd i'r ddadl hon: pensaernïaeth injan cronfa ddata (monolithig, trafodaethol SQL vs dosbarthu, NoSQL nad yw'n drafodion) a dull dylunio cronfa ddata (modelu eich data yn SQL yn erbyn modelu eich ymholiadau yn NoSQL).
Gyda chronfa ddata drafodion ddosbarthedig fel YugaByte DB, gellir rhoi'r gorau i'r ddadl am bensaernïaeth cronfa ddata yn hawdd. Wrth i gyfeintiau data ddod yn fwy na'r hyn y gellir ei ysgrifennu i un nod, bydd angen pensaernïaeth ddosranedig lawn sy'n cefnogi graddadwyedd ysgrifennu llinol gyda darnio / ail-gydbwyso awtomatig.
Eithr, fel y dywedir yn un o'r erthyglau , Mae pensaernïaeth drosiannol, sy'n gyson iawn, bellach yn cael eu defnyddio'n fwy i ddarparu gwell ystwythder datblygu na phensaernïaeth nad yw'n drafodion, sy'n gyson yn y pen draw.
Gan ddod yn ôl at y drafodaeth ar ddylunio cronfa ddata, mae'n deg dweud bod y ddau ddull dylunio (SQL a NoSQL) yn angenrheidiol ar gyfer unrhyw gymhwysiad byd go iawn cymhleth. Mae dull "modelu data" SQL yn galluogi datblygwyr i fodloni gofynion busnes newidiol yn haws, tra bod dull "modelu ymholiad" NoSQL yn caniatáu i'r un datblygwyr weithredu ar symiau mawr o ddata gyda hwyrni isel a thrwybwn uchel. Am y rheswm hwn y mae YugaByte DB yn darparu APIs SQL a NoSQL mewn craidd cyffredin, yn hytrach na hyrwyddo un o'r dulliau gweithredu. Yn ogystal, trwy ddarparu cydnawsedd ag ieithoedd cronfa ddata poblogaidd gan gynnwys PostgreSQL a Cassandra, mae YugaByte DB yn sicrhau nad oes rhaid i ddatblygwyr ddysgu iaith arall i weithio gydag injan cronfa ddata ddosbarthedig, gyson iawn.
Yn yr erthygl hon, buom yn edrych ar sut mae hanfodion dylunio cronfa ddata yn wahanol rhwng PostgreSQL, Cassandra, a MongoDB. Mewn erthyglau yn y dyfodol, byddwn yn plymio i gysyniadau dylunio uwch megis mynegeion, trafodion, JOINs, cyfarwyddebau TTL, a dogfennau JSON.
Rydym yn dymuno gweddill gwych y penwythnos i chi ac yn eich gwahodd i , a fydd yn cymryd lle Mai 14eg.
Ffynhonnell: hab.com