Kumusta Mga Kaibigan. Bago umalis para sa ikalawang bahagi ng mga pista opisyal sa Mayo, ibinabahagi namin sa iyo ang materyal na isinalin namin bilang pag-asa sa paglulunsad ng isang bagong stream sa kurso .
Ang mga developer ng application ay gumugugol ng maraming oras sa paghahambing ng maraming database ng pagpapatakbo upang piliin ang isa na pinakaangkop sa nilalayon na workload. Maaaring kabilang sa mga pangangailangan ang pinasimpleng pagmomodelo ng data, mga transaksyonal na garantiya, pagganap sa pagbasa/pagsusulat, pahalang na pag-scale, at pagpapahintulot sa pagkakamali. Ayon sa kaugalian, ang pagpili ay nagsisimula sa kategorya ng database, SQL o NoSQL, dahil ang bawat kategorya ay nagpapakita ng isang malinaw na hanay ng mga trade-off. Ang mataas na pagganap sa mga tuntunin ng mababang latency at mataas na throughput ay karaniwang nakikita bilang isang non-trade-off na kinakailangan at samakatuwid ay mahalaga para sa anumang sample na database.
Ang layunin ng artikulong ito ay tulungan ang mga developer ng application na gumawa ng tamang pagpili sa pagitan ng SQL at NoSQL sa konteksto ng pagmomodelo ng data ng application. Titingnan natin ang isang database ng SQL, katulad ng PostgreSQL, at dalawang database ng NoSQL, Cassandra at MongoDB, upang masakop ang mga pangunahing kaalaman sa disenyo ng database, tulad ng paglikha ng mga talahanayan, paglalagay ng mga ito, pagbabasa ng data mula sa isang talahanayan, at pagtanggal nito. Sa susunod na artikulo, tiyak na titingnan namin ang mga index, transaksyon, JOIN, TTL directive, at JSON-based na database design.
Ano ang pagkakaiba sa pagitan ng SQL at NoSQL?
Ang mga database ng SQL ay nagdaragdag ng flexibility ng application sa pamamagitan ng mga garantiyang pangtransaksyon ng ACID, pati na rin ang kanilang kakayahang mag-query ng data gamit ang mga JOIN sa mga hindi inaasahang paraan bukod pa sa mga umiiral nang normalized na relational database models.
Dahil sa kanilang monolithic/single-node na arkitektura at paggamit ng master-slave replication model para sa redundancy, ang mga tradisyonal na SQL database ay kulang ng dalawang mahalagang feature - linear write scalability (ibig sabihin, awtomatikong paghati sa maraming node) at awtomatikong/zero na pagkawala ng data. Nangangahulugan ito na ang dami ng data na natanggap ay hindi maaaring lumampas sa maximum na write throughput ng isang node. Bilang karagdagan, ang ilang pansamantalang pagkawala ng data ay dapat isaalang-alang sa fault tolerance (sa isang shared-nothing architecture). Dito kailangan mong tandaan na ang mga kamakailang commit ay hindi pa naipapakita sa slave copy. Mahirap ding makamit ang mga non-downtime update sa mga database ng SQL.
Ang mga database ng NoSQL ay karaniwang ipinamamahagi ayon sa kalikasan, i.e. sa kanila, ang data ay nahahati sa mga seksyon at ipinamahagi sa ilang mga node. Nangangailangan sila ng denormalization. Nangangahulugan ito na ang data na ipinasok ay dapat ding makopya nang ilang beses upang tumugon sa mga partikular na kahilingan na iyong ipinadala. Ang pangkalahatang layunin ay upang makakuha ng mataas na pagganap sa pamamagitan ng pagbabawas ng bilang ng mga shards na magagamit sa panahon ng pagbabasa. Ipinahihiwatig nito na hinihiling sa iyo ng NoSQL na i-modelo ang iyong mga query, habang hinihiling sa iyo ng SQL na i-modelo ang iyong data.
Nakatuon ang NoSQL sa pagkamit ng mataas na pagganap sa isang distributed cluster at ito ang pinagbabatayan na katwiran para sa maraming mga tradeoff sa disenyo ng database na kinabibilangan ng ACID transaction loss, JOINs, at pare-parehong pandaigdigang pangalawang index.
Mayroong isang argumento na habang ang mga database ng NoSQL ay nagbibigay ng linear write scalability at mataas na fault tolerance, ang pagkawala ng mga transactional na garantiya ay ginagawa silang hindi angkop para sa mission-critical data.
Ipinapakita ng sumusunod na talahanayan kung paano naiiba ang pagmomodelo ng data sa NoSQL sa SQL.
SQL at NoSQL: Bakit pareho silang kailangan?
Ang mga real-world na application na may malaking bilang ng mga user, gaya ng Amazon.com, Netflix, Uber, at Airbnb, ay inatasan sa pagsasagawa ng mga kumplikado, maraming aspeto na gawain. Halimbawa, ang isang e-commerce na application tulad ng Amazon.com ay kailangang mag-imbak ng magaan, mataas na kritikal na data gaya ng impormasyon ng user, mga produkto, mga order, mga invoice, kasama ng mabigat, hindi gaanong sensitibong data tulad ng mga review ng produkto, mga mensahe ng suporta , aktibidad ng user, mga review at rekomendasyon ng user. Naturally, umaasa ang mga application na ito sa kahit isang database ng SQL kasama ng kahit isang database ng NoSQL. Sa cross-regional at global system, ang isang NoSQL database ay gumagana bilang isang geo-distributed na cache para sa data na nakaimbak sa isang pinagkakatiwalaang source SQL database na tumatakbo sa isang partikular na rehiyon.
Paano pinagsasama ng YugaByte DB ang SQL at NoSQL?
Itinayo sa isang log-oriented mixed storage engine, auto-sharding, sharded distributed consensus replication at ACID distributed transactions (inspirasyon ng Google Spanner), ang YugaByte DB ay ang unang open source database sa mundo na sabay na katugma sa NoSQL (Cassandra & Redis ) at SQL (PostgreSQL). Gaya ng ipinapakita sa talahanayan sa ibaba, ang YCQL, ang YugaByte DB API na katugma sa Cassandra, ay nagdaragdag ng mga konsepto ng single at multi-key na mga transaksyon sa ACID at mga pandaigdigang pangalawang index sa NoSQL API, at sa gayon ay nag-uumpisa sa panahon ng transactional NoSQL database. Bilang karagdagan, ang YCQL, ang YugaByte DB API na katugma sa PostgreSQL, ay nagdaragdag ng mga konsepto ng linear write scaling at awtomatikong fault tolerance sa SQL API, na nagdadala ng mga distributed SQL database sa mundo. Dahil transactional ang YugaByte DB, magagamit na ngayon ang NoSQL API sa konteksto ng mission-critical data.
Tulad ng naunang sinabi sa artikulo , ang pagpili sa pagitan ng SQL o NoSQL sa YugaByte DB ay ganap na nakasalalay sa mga katangian ng pinagbabatayan na workload:
- Kung ang iyong pangunahing workload ay multi-key JOIN operations, kapag pumipili ng YSQL, unawain na ang iyong mga key ay maaaring ipamahagi sa maraming node, na magreresulta sa mas mataas na latency at/o mas mababang throughput kaysa sa NoSQL.
- Kung hindi, piliin ang alinman sa dalawang NoSQL API, na tandaan na makakakuha ka ng mas mahusay na pagganap bilang resulta ng mga query na inihatid mula sa isang node sa isang pagkakataon. Ang YugaByte DB ay maaaring magsilbi bilang isang database ng pagpapatakbo para sa totoong mundo, kumplikadong mga application na kailangang pamahalaan ang maramihang mga workload nang sabay-sabay.
Ang Data modeling lab sa susunod na seksyon ay nakabatay sa PostgreSQL at Cassandra API compatible YugaByte DB database, kumpara sa mga native na database. Binibigyang-diin ng diskarteng ito ang kadalian ng pakikipag-ugnayan sa dalawang magkaibang API (sa dalawang magkaibang port) ng parehong kumpol ng database, kumpara sa paggamit ng ganap na independiyenteng mga kumpol ng dalawang magkaibang database.
Sa mga sumusunod na seksyon, titingnan natin ang data modeling lab upang ilarawan ang mga pagkakaiba at ilan sa mga pagkakatulad ng mga database na sakop.
Laboratory ng Pagmomodelo ng Data
Pag-install ng database
Dahil sa pagbibigay-diin sa disenyo ng modelo ng data (sa halip na mga kumplikadong arkitektura ng deployment), mag-i-install kami ng mga database sa mga container ng Docker sa lokal na makina at pagkatapos ay makikipag-ugnayan sa kanila gamit ang kani-kanilang command line shell.
PostgreSQL at Cassandra na katugmang YugaByte DB database
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:latestAccess sa command line
Kumonekta tayo sa mga database gamit ang command line shell para sa kaukulang mga API.
PostgreSQL
ay isang command line shell para sa pakikipag-ugnayan sa PostgreSQL. Para sa kadalian ng paggamit, ang YugaByte DB ay may kasamang psql mismo sa bin folder.
docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgresCassandra
ay isang command line shell para sa pakikipag-ugnayan kay Cassandra at sa mga katugmang database nito sa pamamagitan ng CQL (Cassandra Query Language). Para sa kadalian ng paggamit, kasama ang YugaByte DB cqlsh sa catalog bin.
Tandaan na ang CQL ay inspirasyon ng SQL at may katulad na mga konsepto ng mga talahanayan, mga hilera, mga haligi at mga index. Gayunpaman, bilang isang wikang NoSQL, nagdaragdag ito ng isang tiyak na hanay ng mga limitasyon, karamihan sa mga ito ay tatalakayin din namin sa iba pang mga artikulo.
docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlshMongoDB
ay isang command line shell para sa pakikipag-ugnayan sa MongoDB. Ito ay matatagpuan sa direktoryo ng bin ng pag-install ng MongoDB.
docker exec -it my-mongo bash
cd bin
mongoGumawa ng table
Ngayon ay maaari na tayong makipag-ugnayan sa database upang magsagawa ng iba't ibang mga operasyon gamit ang command line. Magsimula tayo sa pamamagitan ng paglikha ng isang talahanayan na nag-iimbak ng impormasyon tungkol sa mga kanta na isinulat ng iba't ibang mga artist. Ang mga kantang ito ay maaaring bahagi ng isang album. Ang mga opsyonal na katangian din para sa isang kanta ay ang taon ng paglabas, presyo, genre at rating. Kailangan nating isaalang-alang ang mga karagdagang katangian na maaaring kailanganin sa hinaharap sa pamamagitan ng field na "mga tag." Maaari itong mag-imbak ng semi-structured na data sa anyo ng mga pares ng key-value.
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
Ang paglikha ng isang talahanayan sa Cassandra ay halos kapareho sa PostgreSQL. Ang isa sa mga pangunahing pagkakaiba ay ang kakulangan ng mga hadlang sa integridad (hal. NOT NULL), ngunit ito ang responsibilidad ng application, hindi ang database ng NoSQL. Ang pangunahing key ay binubuo ng isang partition key (ang Artist column sa halimbawa sa ibaba) at isang set ng clustering column (ang SongTitle column sa halimbawa sa ibaba). Tinutukoy ng partition key kung saang partition/shard ang row dapat ilagay, at ang mga clustering column ay nagpapahiwatig kung paano dapat ayusin ang data sa loob ng kasalukuyang shard.
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
Inaayos ng MongoDB ang data sa mga database (Database) (katulad ng Keyspace sa Cassandra), kung saan mayroong Mga Koleksyon (katulad ng mga talahanayan) na naglalaman ng Mga Dokumento (katulad ng mga row sa isang talahanayan). Sa MongoDB, karaniwang hindi na kailangang tukuyin ang isang paunang schema. Koponan "gamitin ang database", na ipinapakita sa ibaba, ay nag-i-instantiate ng database sa unang tawag at binabago ang konteksto para sa bagong likhang database. Kahit na ang mga koleksyon ay hindi kailangang likhain nang tahasan; awtomatiko silang nilikha, kapag idinagdag mo ang unang dokumento sa isang bagong koleksyon. Tandaan na ginagamit ng MongoDB ang database ng pagsubok bilang default, kaya ang anumang operasyon sa antas ng koleksyon nang hindi tinukoy ang isang partikular na database ay tatakbo dito bilang default.
use myNewDatabase;Pagkuha ng impormasyon tungkol sa isang talahanayan
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;Pagpasok ng data sa isang talahanayan
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
Pangkalahatang pagpapahayag INSERT sa Cassandra ay mukhang halos kapareho ng sa PostgreSQL. Gayunpaman, mayroong isang malaking pagkakaiba sa semantika. Sa Cassandra INSERT ay talagang isang operasyon UPSERT, kung saan idinaragdag ang mga huling halaga sa row kung mayroon na ang row.
Ang pagpasok ng data ay katulad ng PostgreSQL
INSERTsa itaas
.
MongoDB
Kahit na ang MongoDB ay isang database ng NoSQL tulad ng Cassandra, ang operasyon ng pagpapasok nito ay walang pagkakatulad sa semantikong pag-uugali ni Cassandra. Sa MongoDB walang pagkakataon UPSERT, na ginagawa itong katulad ng PostgreSQL. Pagdaragdag ng default na data nang wala _idspecified ay magiging sanhi ng isang bagong dokumento upang maidagdag sa koleksyon.
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"
}
}
);
Tanong sa Talahanayan
Marahil ang pinaka makabuluhang pagkakaiba sa pagitan ng SQL at NoSQL sa mga tuntunin ng pagbuo ng query ay ang wikang ginamit FROM ΠΈ WHERE. Pinapayagan ng SQL pagkatapos ng pagpapahayag FROM pumili ng maramihang mga talahanayan, at expression na may WHERE maaaring maging anumang kumplikado (kabilang ang mga operasyon JOIN sa pagitan ng mga talahanayan). Gayunpaman, ang NoSQL ay may posibilidad na magpataw ng matinding limitasyon sa FROM, at gumana lamang sa isang tinukoy na talahanayan, at sa WHERE, ang pangunahing susi ay dapat palaging tinukoy. Ito ay nauugnay sa push ng pagganap ng NoSQL na napag-usapan namin kanina. Ang pagnanais na ito ay humahantong sa bawat posibleng pagbawas sa anumang cross-tabular at cross-key na pakikipag-ugnayan. Maaari itong magpakilala ng isang malaking pagkaantala sa inter-node na komunikasyon kapag tumutugon sa isang kahilingan at samakatuwid ay pinakamahusay na iwasan sa pangkalahatan. Halimbawa, hinihiling ni Cassandra na limitado ang mga query sa ilang partikular na operator (lamang =, IN, <, >, =>, <=) sa mga partition key, maliban kapag humihiling ng pangalawang index (ang = operator lang ang pinapayagan dito).
PostgreSQL
Nasa ibaba ang tatlong halimbawa ng mga query na madaling maisagawa ng isang SQL database.
- Ipakita ang lahat ng kanta ng isang artist;
- Ipakita ang lahat ng kanta ng artist na tumutugma sa unang bahagi ng pamagat;
- Ipakita ang lahat ng kanta ng isang artist na may partikular na salita sa pamagat at may presyong mas mababa sa 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
Sa mga query sa PostgreSQL na nakalista sa itaas, ang una lang ang gagana nang hindi nagbabago sa Cassandra, dahil ang operator LIKE hindi maaaring ilapat sa clustering column gaya ng SongTitle. Sa kasong ito, ang mga operator lamang ang pinapayagan = ΠΈ 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
Tulad ng ipinakita sa mga nakaraang halimbawa, ang pangunahing paraan para sa paglikha ng mga query sa MongoDB ay . Ang paraang ito ay tahasang naglalaman ng pangalan ng koleksyon (music sa halimbawa sa ibaba), kaya ipinagbabawal ang pag-query ng maraming koleksyon.
db.music.find( {
artist: "No One You Know"
}
);
db.music.find( {
artist: "No One You Know",
songTitle: /Call/
}
);Binabasa ang lahat ng row ng isang table
Ang pagbabasa ng lahat ng row ay isang espesyal na kaso lamang ng pattern ng query na tiningnan namin kanina.
PostgreSQL
SELECT *
FROM Music;Cassandra
Katulad sa halimbawa ng PostgreSQL sa itaas.
MongoDB
db.music.find( {} );Pag-edit ng data sa isang talahanayan
PostgreSQL
Ang PostgreSQL ay nagbibigay ng mga tagubilin UPDATE upang baguhin ang data. Wala siyang pagkakataon UPSERT, kaya ang pahayag na ito ay mabibigo kung ang hilera ay wala na sa database.
UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';Cassandra
Si Cassandra meron UPDATE katulad ng PostgreSQL. UPDATE ay may parehong semantika UPSERT, katulad INSERT.
Katulad sa halimbawa ng PostgreSQL sa itaas.
MongoDB
Operasyon sa MongoDB ay maaaring ganap na mag-update ng isang umiiral na dokumento o mag-update lamang ng ilang mga patlang. Bilang default, isang dokumento lang ang ina-update nito na hindi pinagana ang semantics UPSERT. Pag-update ng maraming dokumento at katulad na gawi UPSERT maaaring ilapat sa pamamagitan ng pagtatakda ng mga karagdagang flag para sa operasyon. Halimbawa, sa halimbawa sa ibaba, ina-update ang genre ng isang partikular na artist batay sa kanyang kanta.
db.music.update(
{"artist": "The Acme Band"},
{
$set: {
"genre": "Disco"
}
},
{"multi": true, "upsert": true}
);Pag-alis ng data mula sa isang talahanayan
PostgreSQL
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';Cassandra
Katulad sa halimbawa ng PostgreSQL sa itaas.
MongoDB
Ang MongoDB ay may dalawang uri ng mga operasyon upang magtanggal ng mga dokumento β ΠΈ . Ang parehong uri ay nagtatanggal ng mga dokumento ngunit nagbabalik ng magkaibang mga resulta.
db.music.deleteMany( {
artist: "The Acme Band"
}
);
Pagtanggal ng talahanayan
PostgreSQL
DROP TABLE Music;Cassandra
Katulad sa halimbawa ng PostgreSQL sa itaas.
MongoDB
db.music.drop();Konklusyon
Ang debate tungkol sa pagpili sa pagitan ng SQL at NoSQL ay umuusad nang higit sa 10 taon. Mayroong dalawang pangunahing aspeto sa debateng ito: database engine architecture (monolithic, transactional SQL vs distributed, non-transactional NoSQL) at database design approach (pagmomodelo ng iyong data sa SQL vs pagmomodelo ng iyong mga query sa NoSQL).
Sa isang distributed transactional database tulad ng YugaByte DB, ang debate tungkol sa arkitektura ng database ay madaling mapahinto. Habang nagiging mas malaki ang mga volume ng data kaysa sa maaaring isulat sa iisang node, kinakailangan ang isang ganap na distributed architecture na sumusuporta sa linear write scalability na may awtomatikong sharding/rebalancing.
Bukod, gaya ng nakasaad sa isa sa mga artikulo ,Ang mga Transaksyonal, malakas na pare-parehong mga arkitektura ay mas ginagamit na ngayon upang magbigay ng mas mahusay na liksi sa pag-unlad kaysa sa mga di-transaksyonal, , sa kalaunan ay pare-parehong mga arkitektura.
Pagbabalik sa talakayan sa disenyo ng database, makatarungang sabihin na ang parehong mga diskarte sa disenyo (SQL at NoSQL) ay kinakailangan para sa anumang kumplikadong real-world na aplikasyon. Ang diskarte sa "data modeling" ng SQL ay nagbibigay-daan sa mga developer na mas madaling matugunan ang pagbabago ng mga kinakailangan sa negosyo, habang ang NoSQL na "query modeling" na diskarte ay nagpapahintulot sa parehong mga developer na gumana sa malalaking volume ng data na may mababang latency at mataas na throughput. Ito ay para sa kadahilanang ito na ang YugaByte DB ay nagbibigay ng SQL at NoSQL API sa isang karaniwang core, sa halip na isulong ang isa sa mga diskarte. Bukod pa rito, sa pamamagitan ng pagbibigay ng compatibility sa mga sikat na wika ng database kabilang ang PostgreSQL at Cassandra, tinitiyak ng YugaByte DB na hindi na kailangang matuto ng ibang wika ang mga developer para gumana sa isang distributed, highly consistent database engine.
Sa artikulong ito, tiningnan namin kung paano naiiba ang mga batayan ng disenyo ng database sa pagitan ng PostgreSQL, Cassandra, at MongoDB. Sa mga artikulo sa hinaharap, sumisid tayo sa mga advanced na konsepto ng disenyo gaya ng mga index, transaksyon, JOIN, TTL directive, at JSON na dokumento.
Hinihiling namin sa iyo ang isang magandang pahinga sa katapusan ng linggo at imbitahan ka , na magaganap sa ika-14 ng Mayo.
Pinagmulan: www.habr.com