Habari, marafiki. Kabla ya kuondoka kwa sehemu ya pili ya likizo ya Mei, tunashiriki nawe nyenzo ambazo tulitafsiri kwa kutarajia uzinduzi wa mkondo mpya kwenye kozi. .
Wasanidi programu hutumia muda mwingi kulinganisha hifadhidata nyingi za uendeshaji ili kuchagua ile inayofaa zaidi mzigo uliokusudiwa. Mahitaji yanaweza kujumuisha uundaji wa data uliorahisishwa, uhakikisho wa shughuli, utendakazi wa kusoma/kuandika, kuongeza mlalo, na uvumilivu wa makosa. Kijadi, chaguo huanza na kategoria ya hifadhidata, SQL au NoSQL, kwani kila kategoria inatoa seti ya wazi ya biashara. Utendaji wa juu katika suala la muda wa chini wa kusubiri na matokeo ya juu kwa ujumla huonekana kama hitaji lisilo la kibiashara na kwa hivyo ni muhimu kwa hifadhidata yoyote ya sampuli.
Madhumuni ya kifungu hiki ni kusaidia wasanidi programu kufanya chaguo sahihi kati ya SQL na NoSQL katika muktadha wa muundo wa data ya programu. Tutaangalia hifadhidata moja ya SQL, yaani PostgreSQL, na hifadhidata mbili za NoSQL, Cassandra na MongoDB, ili kufunika misingi ya muundo wa hifadhidata, kama vile kuunda majedwali, kuzijaza, kusoma data kutoka kwa jedwali, na kuifuta. Katika makala inayofuata, tutahakikisha kuwa tutaangalia faharasa, miamala, JOIN, maagizo ya TTL, na muundo wa hifadhidata unaotegemea JSON.
Kuna tofauti gani kati ya SQL na NoSQL?
Hifadhidata za SQL huongeza ubadilikaji wa programu kupitia uhakikisho wa miamala wa ACID, pamoja na uwezo wao wa kuuliza data kwa kutumia JOIN kwa njia zisizotarajiwa juu ya miundo iliyopo ya kawaida ya hifadhidata ya uhusiano.
Kwa kuzingatia usanifu wao wa monolithic/nodi moja na utumiaji wa kielelezo cha urudufishaji wa mtumwa mkuu kwa upungufu, hifadhidata za jadi za SQL hazina vipengele viwili muhimu - upanuzi wa uandishi wa mstari (yaani kugawanya kiotomatiki kwenye nodi nyingi) na upotezaji wa data kiotomatiki/sifuri. Hii ina maana kwamba kiasi cha data iliyopokelewa haiwezi kuzidi upeo wa juu wa maandishi ya nodi moja. Kwa kuongeza, baadhi ya kupoteza data kwa muda lazima kuzingatiwa katika uvumilivu wa makosa (katika usanifu wa pamoja-hakuna kitu). Hapa unahitaji kukumbuka kuwa ahadi za hivi karibuni bado hazijaonyeshwa kwenye nakala ya watumwa. Masasisho yasiyo ya muda wa chini pia ni vigumu kufikia katika hifadhidata za SQL.
Hifadhidata za NoSQL kawaida husambazwa kwa asili, i.e. ndani yao, data imegawanywa katika sehemu na kusambazwa katika nodes kadhaa. Wanahitaji denormalilization. Hii ina maana kwamba data iliyoingizwa lazima pia inakiliwe mara kadhaa ili kujibu maombi mahususi unayotuma. Lengo la jumla ni kupata utendaji wa juu kwa kupunguza idadi ya shards zinazopatikana wakati wa kusoma. Hii inamaanisha kuwa NoSQL inakuhitaji utoe mfano wa hoja zako, huku SQL inakuhitaji utengeneze data yako.
NoSQL inalenga kufikia utendakazi wa hali ya juu katika nguzo iliyosambazwa na hii ndiyo sababu ya msingi ya mabadiliko mengi ya muundo wa hifadhidata ambayo yanajumuisha upotevu wa miamala ya ACID, JOIN, na faharasa za upili zisizobadilika za kimataifa.
Kuna hoja kwamba wakati hifadhidata za NoSQL zinapeana usawazishaji wa uandishi wa mstari na uvumilivu wa juu wa makosa, upotezaji wa dhamana za ununuzi huwafanya kutofaa kwa data muhimu ya dhamira.
Jedwali lifuatalo linaonyesha jinsi uundaji wa data katika NoSQL unavyotofautiana na SQL.
SQL na NoSQL: Kwa nini zote zinahitajika?
Programu za ulimwengu halisi zilizo na idadi kubwa ya watumiaji, kama vile Amazon.com, Netflix, Uber, na Airbnb, zimepewa jukumu la kufanya kazi ngumu na zenye sehemu nyingi. Kwa mfano, programu ya e-commerce kama Amazon.com inahitaji kuhifadhi data nyepesi, muhimu sana kama vile maelezo ya mtumiaji, bidhaa, maagizo, ankara, pamoja na data nzito, nyeti sana kama vile ukaguzi wa bidhaa, ujumbe wa usaidizi , shughuli za mtumiaji, hakiki za watumiaji na mapendekezo. Kwa kawaida, programu hizi hutegemea angalau hifadhidata moja ya SQL pamoja na hifadhidata moja ya NoSQL. Katika mifumo ya kikanda na kimataifa, hifadhidata ya NoSQL hufanya kazi kama kache iliyosambazwa kijiografia kwa data iliyohifadhiwa katika hifadhidata ya chanzo inayoaminika ya SQL inayoendeshwa katika eneo fulani.
Je, YugaByte DB inachanganyaje SQL na NoSQL?
Imejengwa kwa injini ya uhifadhi mchanganyiko inayoelekezwa kwa kumbukumbu, kupasua kiotomatiki, uigaji wa makubaliano yaliyosambazwa kwa pamoja na miamala iliyosambazwa kwa ACID (iliyotokana na Google Spanner), YugaByte DB ndiyo hifadhidata ya kwanza ya chanzo huria duniani ambayo inaoana kwa wakati mmoja na NoSQL (Cassandra & Redis ) na SQL (PostgreSQL). Kama inavyoonyeshwa kwenye jedwali lililo hapa chini, YCQL, YugaByte DB API inayooana na Cassandra, inaongeza dhana za miamala ya ACID moja na ya vitu vingi muhimu na faharasa za upili za kimataifa kwa API ya NoSQL, na hivyo kukaribisha enzi ya hifadhidata za shughuli za NoSQL. Zaidi ya hayo, YCQL, API ya DB ya YugaByte inayooana na PostgreSQL, inaongeza dhana za kuongeza maandishi kwa mstari na uvumilivu wa hitilafu kiotomatiki kwa API ya SQL, na kuleta hifadhidata za SQL zilizosambazwa ulimwenguni. Kwa sababu YugaByte DB ni ya shughuli za asili, API ya NoSQL sasa inaweza kutumika katika muktadha wa data muhimu ya dhamira.
Kama ilivyoelezwa hapo awali katika makala , chaguo kati ya SQL au NoSQL katika YugaByte DB inategemea kabisa sifa za mzigo wa kazi:
- Ikiwa mzigo wako wa msingi wa kazi ni utendakazi wa JIUNGE na vitufe vingi, basi unapochagua YSQL, elewa kuwa funguo zako zinaweza kusambazwa kwenye nodi nyingi, na kusababisha ucheleweshaji wa juu na/au upitishaji wa chini kuliko NoSQL.
- Vinginevyo, chagua mojawapo ya API mbili za NoSQL, ukikumbuka kwamba utapata utendaji bora kama matokeo ya hoja zinazotolewa kutoka kwa nodi moja kwa wakati mmoja. YugaByte DB inaweza kutumika kama hifadhidata moja ya uendeshaji kwa ajili ya ulimwengu halisi, programu changamano zinazohitaji kudhibiti mzigo wa kazi nyingi kwa wakati mmoja.
Maabara ya uundaji data katika sehemu inayofuata inategemea hifadhidata za PostgreSQL na Cassandra API zinazooana za YugaByte DB, tofauti na hifadhidata asili. Mbinu hii inasisitiza urahisi wa kuingiliana na API mbili tofauti (kwenye bandari mbili tofauti) za kundi moja la hifadhidata, kinyume na kutumia makundi huru kabisa ya hifadhidata mbili tofauti.
Katika sehemu zifuatazo, tutaangalia maabara ya uundaji data ili kuonyesha tofauti na baadhi ya mambo yanayofanana ya hifadhidata zinazoshughulikiwa.
Maabara ya Kuiga Data
Ufungaji wa hifadhidata
Kwa kuzingatia msisitizo wa muundo wa kielelezo cha data (badala ya usanifu changamano wa upelekaji), tutasakinisha hifadhidata katika vyombo vya Docker kwenye mashine ya ndani na kisha kuingiliana navyo kwa kutumia makombora ya mstari wa amri husika.
Hifadhidata ya PostgreSQL na Cassandra inayolingana ya 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:latestUfikiaji wa mstari wa amri
Wacha tuunganishe kwenye hifadhidata kwa kutumia ganda la mstari wa amri kwa API zinazolingana.
PostgreSQL
ni safu ya amri ya kuingiliana na PostgreSQL. Kwa urahisi wa utumiaji, YugaByte DB inakuja na psql kwenye folda ya bin.
docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgresCassandra
ni safu ya amri ya ganda la kuingiliana na Cassandra na hifadhidata zake zinazolingana kupitia CQL (Lugha ya Maswali ya Cassandra). Kwa urahisi wa matumizi, YugaByte DB inakuja na cqlsh katika orodha bin.
Kumbuka kuwa CQL iliongozwa na SQL na ina dhana sawa za majedwali, safu mlalo, safu wima na faharasa. Walakini, kama lugha ya NoSQL, inaongeza seti fulani ya mapungufu, ambayo mengi tutashughulikia pia katika nakala zingine.
docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlshMongoDB
ni safu ya amri ya kuingiliana na MongoDB. Inaweza kupatikana kwenye saraka ya bin ya usakinishaji wa MongoDB.
docker exec -it my-mongo bash
cd bin
mongoKuunda meza
Sasa tunaweza kuingiliana na hifadhidata kufanya shughuli mbalimbali kwa kutumia mstari wa amri. Wacha tuanze kwa kuunda jedwali ambalo huhifadhi habari kuhusu nyimbo zilizoandikwa na wasanii tofauti. Nyimbo hizi zinaweza kuwa sehemu ya albamu. Pia sifa za hiari za wimbo ni mwaka wa kutolewa, bei, aina na ukadiriaji. Tunahitaji kuhesabu sifa za ziada ambazo zinaweza kuhitajika katika siku zijazo kupitia sehemu ya "lebo". Inaweza kuhifadhi data iliyo na muundo nusu katika mfumo wa jozi za thamani-msingi.
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
Kuunda jedwali huko Cassandra ni sawa na PostgreSQL. Mojawapo ya tofauti kuu ni ukosefu wa vizuizi vya uadilifu (k.m. SI NULL), lakini hili ni jukumu la programu, sio hifadhidata ya NoSQL.. Ufunguo msingi una ufunguo wa kugawa (safu ya Msanii katika mfano ulio hapa chini) na seti ya safu wima za nguzo (safu ya SongTitle katika mfano ulio hapa chini). Ufunguo wa kuhesabu huamua ni kizigeu/mgawanyiko gani wa safu mlalo unapaswa kuwekwa, na safu wima za nguzo zinaonyesha jinsi data inapaswa kupangwa ndani ya shard ya sasa.
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 hupanga data katika hifadhidata (Hifadhidata) (sawa na Keyspace katika Cassandra), ambapo kuna Mikusanyiko (sawa na jedwali) iliyo na Hati (sawa na safu mlalo katika jedwali). Katika MongoDB, kimsingi hakuna haja ya kufafanua schema ya awali. Timu "tumia hifadhidata", iliyoonyeshwa hapa chini, inaanzisha hifadhidata kwenye simu ya kwanza na kubadilisha muktadha wa hifadhidata mpya iliyoundwa. Hata mikusanyiko haihitaji kuundwa kwa njia dhahiri; huundwa kiotomatiki, unapoongeza hati ya kwanza kwenye mkusanyiko mpya. Kumbuka kuwa MongoDB hutumia hifadhidata ya majaribio kwa chaguo-msingi, kwa hivyo operesheni yoyote ya kiwango cha mkusanyiko bila kubainisha hifadhidata maalum itaendeshwa juu yake kwa chaguo-msingi.
use myNewDatabase;Kupata habari kuhusu meza
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;Ingiza data kwenye jedwali
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
Usemi wa jumla INSERT huko Cassandra inaonekana sawa na ile ya PostgreSQL. Hata hivyo, kuna tofauti moja kubwa katika semantiki. Katika Cassandra INSERT kweli ni operesheni UPSERT, ambapo maadili ya mwisho huongezwa kwenye safu mlalo ikiwa safu mlalo tayari ipo.
Ingizo la data ni sawa na PostgreSQL
INSERTjuu ya
.
MongoDB
Ingawa MongoDB ni hifadhidata ya NoSQL kama Cassandra, operesheni yake ya uwekaji haina uhusiano wowote na tabia ya kisemantiki ya Cassandra. Katika MongoDB hana fursa UPSERT, ambayo inafanya kuwa sawa na PostgreSQL. Kuongeza data chaguo-msingi bila _idspecified itasababisha hati mpya kuongezwa kwenye mkusanyiko.
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"
}
}
);
Swali la Jedwali
Labda tofauti kubwa zaidi kati ya SQL na NoSQL katika suala la ujenzi wa hoja ni lugha inayotumiwa FROM ΠΈ WHERE. SQL inaruhusu baada ya kujieleza FROM chagua jedwali nyingi, na usemi na WHERE inaweza kuwa ya ugumu wowote (pamoja na shughuli JOIN kati ya meza). Walakini, NoSQL inaelekea kuweka kizuizi kali kwa FROM, na fanya kazi tu na jedwali moja maalum, na ndani WHERE, ufunguo msingi lazima ubainishwe kila wakati. Hii inafungamana na msukumo wa utendaji wa NoSQL tuliozungumzia hapo awali. Tamaa hii inaongoza kwa kila upunguzaji unaowezekana wa mwingiliano wowote wa tabular na ufunguo wa msalaba. Inaweza kuanzisha ucheleweshaji mkubwa wa mawasiliano kati ya nodi wakati wa kujibu ombi na kwa hivyo ni bora kuepukwa kwa ujumla. Kwa mfano, Cassandra inahitaji maswali kuwekewa kikomo waendeshaji fulani (tu =, IN, <, >, =>, <=) kwenye funguo za kuhesabu, isipokuwa wakati wa kuomba faharisi ya pili (mendeshaji = tu ndiye anayeruhusiwa hapa).
PostgreSQL
Ifuatayo ni mifano mitatu ya maswali ambayo yanaweza kutekelezwa kwa urahisi na hifadhidata ya SQL.
- Onyesha nyimbo zote za msanii;
- Onyesha nyimbo zote za msanii zinazolingana na sehemu ya kwanza ya kichwa;
- Onyesha nyimbo zote za msanii ambazo zina neno fulani katika kichwa na bei yake ni chini ya 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
Kati ya maswali ya PostgreSQL yaliyoorodheshwa hapo juu, ya kwanza tu itafanya kazi bila kubadilika huko Cassandra, kwani mwendeshaji LIKE haiwezi kutumika kwa nguzo za nguzo kama vile SongTitle. Katika kesi hii, waendeshaji pekee wanaruhusiwa = ΠΈ 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
Kama inavyoonyeshwa katika mifano iliyopita, njia kuu ya kuunda maswali katika MongoDB ni . Njia hii ina jina la mkusanyiko (music katika mfano hapa chini), kwa hivyo kuuliza makusanyo mengi ni marufuku.
db.music.find( {
artist: "No One You Know"
}
);
db.music.find( {
artist: "No One You Know",
songTitle: /Call/
}
);Kusoma safu zote za jedwali
Kusoma safu mlalo zote ni kisa maalum cha muundo wa hoja tulioangalia hapo awali.
PostgreSQL
SELECT *
FROM Music;Cassandra
Sawa na mfano wa PostgreSQL hapo juu.
MongoDB
db.music.find( {} );Kuhariri data kwenye jedwali
PostgreSQL
PostgreSQL hutoa maagizo UPDATE kubadilisha data. Yeye hana fursa UPSERT, kwa hivyo taarifa hii itashindwa ikiwa safu mlalo haipo tena kwenye hifadhidata.
UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';Cassandra
Cassandra ana UPDATE sawa na PostgreSQL. UPDATE ina semantiki sawa UPSERT, sawa INSERT.
Sawa na mfano wa PostgreSQL hapo juu.
MongoDB
Operesheni katika MongoDB inaweza kusasisha kabisa hati iliyopo au kusasisha sehemu fulani tu. Kwa chaguo-msingi, inasasisha hati moja pekee huku semantiki ikiwa imezimwa UPSERT. Inasasisha hati nyingi na tabia sawa UPSERT inaweza kutumika kwa kuweka bendera za ziada kwa ajili ya uendeshaji. Kwa mfano, katika mfano hapa chini, aina ya msanii maalum inasasishwa kulingana na wimbo wake.
db.music.update(
{"artist": "The Acme Band"},
{
$set: {
"genre": "Disco"
}
},
{"multi": true, "upsert": true}
);Kuondoa data kutoka kwa jedwali
PostgreSQL
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';Cassandra
Sawa na mfano wa PostgreSQL hapo juu.
MongoDB
MongoDB ina aina mbili za shughuli za kufuta hati - ΠΈ . Aina zote mbili hufuta hati lakini zinarudisha matokeo tofauti.
db.music.deleteMany( {
artist: "The Acme Band"
}
);
Kufuta meza
PostgreSQL
DROP TABLE Music;Cassandra
Sawa na mfano wa PostgreSQL hapo juu.
MongoDB
db.music.drop();Hitimisho
Mjadala kuhusu kuchagua kati ya SQL na NoSQL umekuwa ukiendelea kwa zaidi ya miaka 10. Kuna mambo mawili kuu ya mjadala huu: usanifu wa injini ya hifadhidata (monolithic, SQL ya ununuzi dhidi ya kusambazwa, NoSQL isiyo ya shughuli) na mbinu ya muundo wa hifadhidata (kuiga data yako katika SQL dhidi ya kuiga maswali yako katika NoSQL).
Kwa hifadhidata iliyosambazwa ya shughuli kama vile YugaByte DB, mjadala kuhusu usanifu wa hifadhidata unaweza kukomeshwa kwa urahisi. Kadiri idadi ya data inavyozidi kuwa kubwa kuliko inavyoweza kuandikwa kwa nodi moja, usanifu uliosambazwa kikamilifu ambao unaauni upanuzi wa uandishi wa mstari kwa kupasua/kusawazisha upya inakuwa muhimu.
Aidha, kama ilivyoelezwa katika moja ya makala ,Muamala, usanifu thabiti sasa ni mwingi zaidi,unatumika kutoa wepesi bora wa maendeleo kuliko usanifu usio wa shughuli, hatimaye usanifu thabiti.
Tukirudi kwenye mjadala wa muundo wa hifadhidata, ni sawa kusema kwamba mbinu zote mbili za muundo (SQL na NoSQL) ni muhimu kwa matumizi yoyote changamano ya ulimwengu halisi. Mbinu ya SQL "ya kuiga data" huruhusu wasanidi programu kukidhi kwa urahisi mahitaji yanayobadilika ya biashara, huku mbinu ya "query modeling" ya NoSQL inaruhusu watengenezaji walewale kufanya kazi kwa idadi kubwa ya data na latency ya chini na upitishaji wa juu. Ni kwa sababu hii kwamba YugaByte DB hutoa SQL na API za NoSQL katika msingi wa kawaida, badala ya kukuza moja ya mbinu. Zaidi ya hayo, kwa kutoa uoanifu na lugha maarufu za hifadhidata ikiwa ni pamoja na PostgreSQL na Cassandra, YugaByte DB inahakikisha kwamba wasanidi programu hawahitaji kujifunza lugha nyingine ili kufanya kazi na injini ya hifadhidata iliyosambazwa na thabiti sana.
Katika nakala hii, tuliangalia jinsi misingi ya muundo wa hifadhidata inavyotofautiana kati ya PostgreSQL, Cassandra, na MongoDB. Katika makala yajayo, tutazama katika dhana za muundo wa hali ya juu kama vile faharasa, miamala, JOIN, maagizo ya TTL na hati za JSON.
Tunakutakia mapumziko mema ya mwisho wa wiki na kukualika , ambayo itafanyika Mei 14.
Chanzo: mapenzi.com