Hello, mga higala. Sa wala pa mobiya alang sa ikaduha nga bahin sa Mayo holidays, among gipaambit kanimo ang materyal nga among gihubad sa pagpaabut sa paglansad sa usa ka bag-ong sapa sa rate .
Ang mga nag-develop sa aplikasyon naggugol og daghang oras sa pagtandi sa daghang mga database sa operasyon aron mapili ang usa nga labing maayo alang sa ilang gitinguha nga workload. Ang mga panginahanglan mahimong maglakip sa gipasimple nga modelo sa datos, mga garantiya sa transaksyon, pasundayag sa pagbasa/pagsulat, pinahigda nga pag-scale, ug pagtugot sa sayup. Sa naandan, ang pagpili nagsugod sa kategorya sa database, SQL o NoSQL, tungod kay ang matag kategorya naghatag usa ka tin-aw nga hugpong sa mga trade-off. Ang taas nga pasundayag sa mga termino sa ubos nga latency ug taas nga throughput sa kasagaran makita ingon usa ka kinahanglanon nga dili makompromiso ug busa hinungdanon alang sa bisan unsang database sa sample.
Ang katuyoan niini nga artikulo mao ang pagtabang sa mga nag-develop sa aplikasyon sa paghimo sa husto nga pagpili tali sa SQL ug NoSQL sa konteksto sa pagmodelo sa datos sa aplikasyon. Atong tan-awon ang usa ka database sa SQL, nga mao ang PostgreSQL, ug duha ka database sa NoSQL, Cassandra ug MongoDB, aron pagtabon sa mga sukaranan sa disenyo sa database, sama sa paghimo og mga lamesa, pagpopulasyon niini, pagbasa sa datos gikan sa usa ka lamesa, ug pagtangtang niini. Sa sunod nga artikulo, tan-awon gyud nato ang mga index, transaksyon, JOINs, TTL directives, ug database design base sa JSON.
Unsa ang kalainan tali sa SQL ug NoSQL?
Ang mga database sa SQL nagdugang sa pagka-flexible sa aplikasyon pinaagi sa mga garantiya sa transaksyon sa ACID, ingon man ang ilang abilidad sa pagpangutana sa datos gamit ang mga JOIN sa wala damha nga mga paagi sa ibabaw sa kasamtangan nga na-normalize nga relational database nga mga modelo.
Tungod sa ilang monolithic/single node nga arkitektura ug paggamit sa master-slave replication model para sa redundancy, ang tradisyonal nga SQL database kulang sa duha ka importanteng feature - linear write scalability (ie automatic splitting sa daghang node) ug automatic/zero data loss. Kini nagpasabot nga ang gidaghanon sa datos nga nadawat dili molapas sa kinatas-ang pagsulat sa throughput sa usa ka node. Dugang pa, ang pipila nga temporaryo nga pagkawala sa datos kinahanglan nga tagdon alang sa pagtugot sa sayup (sa usa ka dili gipaambit nga arkitektura). Dinhi kinahanglan nimong hinumdoman nga ang mga bag-ong nahimo wala pa makita sa kopya sa ulipon. Walay mga pag-update sa downtime nga lisud usab makab-ot sa mga database sa SQL.
Ang mga database sa NoSQL kasagarang giapod-apod sa kinaiyahan, i.e. sa kanila, ang datos gibahin sa mga seksyon ug giapod-apod sa daghang mga node. Nagkinahanglan sila og denormalization. Kini nagpasabut nga ang gisulod nga datos kinahanglan usab nga kopyahon sa daghang mga higayon aron matubag ang piho nga mga hangyo nga imong ipadala. Ang kinatibuk-ang tumong mao ang pagkuha sa taas nga performance pinaagi sa pagkunhod sa gidaghanon sa mga shards nga anaa sa pagbasa sa panahon. Kini nagpasabot nga ang NoSQL nagkinahanglan kanimo sa pagmodelo sa imong mga pangutana, samtang ang SQL nagkinahanglan kanimo sa pagmodelo sa imong datos.
Gipasiugda sa NoSQL ang pagkab-ot sa taas nga performance sa usa ka gipang-apod-apod nga cluster ug kini ang nag-unang rason alang sa daghang mga trade-off sa disenyo sa database, nga naglakip sa pagkawala sa mga transaksyon sa ACID, JOINs, ug makanunayon nga global secondary index.
Adunay usa ka opinyon nga bisan kung ang mga database sa NoSQL naghatag og linear write scalability ug taas nga fault tolerance, ang pagkawala sa transactional nga mga garantiya naghimo kanila nga dili angay alang sa kritikal nga datos.
Ang mosunud nga talaan nagpakita kung giunsa ang pagmodelo sa datos sa NoSQL lahi sa SQL.
SQL ug NoSQL: Nganong gikinahanglan ang duha?
Ang mga aplikasyon sa tinuod nga kinabuhi nga adunay daghang mga tiggamit, sama sa Amazon.com, Netflix, Uber ug Airbnb, ang responsable sa paghimo sa komplikado nga mga buluhaton sa lainlaing mga lahi. Pananglitan, ang usa ka aplikasyon sa e-commerce sama sa Amazon.com kinahanglan nga magtipig gaan, sensitibo kaayo nga datos sama sa kasayuran bahin sa mga tiggamit, produkto, mga order, mga invoice, kauban ang bug-at apan dili kaayo sensitibo nga datos sama sa mga pagsusi sa produkto, mga mensahe sa suporta. , kalihokan sa tiggamit , mga review ug rekomendasyon sa user. Natural, kini nga mga aplikasyon nagsalig sa labing menos usa ka database sa SQL kauban ang labing menos usa ka database sa NoSQL. Sa inter-regional ug global nga mga sistema, ang NoSQL database naglihok isip geo-distributed cache alang sa datos nga gitipigan sa usa ka kasaligang tinubdan, SQL database, nga naglihok sa bisan asa nga rehiyon.
Giunsa paghiusa sa YugaByte DB ang SQL ug NoSQL?
Gitukod sa log-oriented mixed storage engine, auto-sharding, sharded distributed consensus replication, ug ACID distributed transactions (inspirado sa Google Spanner), ang YugaByte DB mao ang unang open source database sa kalibutan nga dungan nga NoSQL (Cassandra & Redis) compatible. ) ug SQL (PostgreSQL). Sama sa gipakita sa lamesa sa ubos, ang YCQL, usa ka YugaByte DB API nga compatible sa Cassandra, midugang sa mga konsepto sa single ug multi-key nga mga transaksyon sa ACID ug global secondary indexes ngadto sa NoSQL API, sa ingon nagsugod sa panahon sa transactional NoSQL databases. Dugang pa, ang YCQL, usa ka YugaByte DB API nga compatible sa PostgreSQL, nagdugang sa mga konsepto sa linear write scaling ug automatic failover sa SQL API, nga nagdala sa gipang-apod-apod nga mga database sa SQL sa kalibutan. Tungod kay ang database sa YugaByte DB kay kinaiyanhon nga transactional, ang NoSQL API magamit na karon sa konteksto sa kritikal nga datos.
Sama sa giingon kaniadto sa artikulo , ang pagpili tali sa SQL o NoSQL sa YugaByte DB hingpit nga nagdepende sa mga kinaiya sa nagpahiping workload:
- Kung ang imong nag-una nga workload kay multi-key JOIN nga mga operasyon, unya sa pagpili sa YSQL, hibaloi nga ang imong mga yawe mahimong mokaylap sa daghang mga node, nga moresulta sa mas taas nga latency ug/o mas ubos nga throughput kay sa NoSQL.
- Kung dili, pilia ang bisan hain sa duha nga NoSQL API, hinumdomi nga makakuha ka labi ka maayo nga pasundayag ingon usa ka sangputanan sa mga pangutana nga giserbisyuhan gikan sa usa ka node matag higayon. Ang YugaByte DB mahimong magsilbi nga usa ka database sa operasyon alang sa tinuud nga komplikado nga mga aplikasyon nga kinahanglan magdumala daghang mga workload sa parehas nga oras.
Ang Data modeling lab sa sunod nga seksyon gibase sa PostgreSQL ug Cassandra compatible YugaByte DB database APIs, sukwahi sa orihinal nga mga database. Kini nga pamaagi naghatag og gibug-aton sa kasayon sa pagpakig-uban sa duha ka lain-laing mga API (sa duha ka lain-laing mga pantalan) sa sama nga database cluster, sukwahi sa paggamit sa hingpit nga independente clusters sa duha ka lain-laing mga database.
Sa mosunod nga mga seksyon, atong tan-awon ang Data Modeling Lab aron iilustrar ang kalainan ug pipila sa mga komonidad sa mga database nga gipangutana.
Data Modeling Lab
Pag-instalar sa mga database
Gihatag ang pokus sa disenyo sa modelo sa datos (imbes nga komplikado nga mga arkitektura sa pag-deploy), i-install namon ang mga database sa mga sudlanan sa Docker sa lokal nga makina ug dayon makig-uban kanila gamit ang ilang tagsa-tagsa nga mga shell sa command line.
PostgreSQL & Cassandra compatible, 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:latestPag-access sa command line
Magkonektar kita sa mga database gamit ang command line shell para sa tagsa-tagsa ka mga API.
PostgreSQL
mao ang usa ka command line shell alang sa pagpakig-uban sa PostgreSQL. Alang sa kasayon sa paggamit, ang YugaByte DB adunay psql diha mismo sa bin folder.
docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgresCassandra
kay usa ka command line shell para sa interaksyon sa Cassandra ug sa mga compatible database niini pinaagi sa CQL (Cassandra Query Language). Alang sa kasayon sa paggamit, ang YugaByte DB nag-uban cqlsh sa katalogo bin.
Timan-i nga ang CQL giinspirar sa SQL ug adunay susama nga mga konsepto sa mga lamesa, mga laray, mga kolum, ug mga indeks. Bisan pa, ingon usa ka sinultian nga NoSQL, nagdugang kini usa ka piho nga hugpong sa mga pagdili, kadaghanan niini hisgutan usab namon sa ubang mga artikulo.
docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlshMongoDB
mao ang usa ka command line shell alang sa pagpakig-uban sa MongoDB. Makita kini sa direktoryo sa bin sa pag-install sa MongoDB.
docker exec -it my-mongo bash
cd bin
mongoPaghimo og lamesa
Karon mahimo na kaming makig-uban sa database aron mahimo ang lainlaing mga operasyon gamit ang linya sa mando. Magsugod kita pinaagi sa paghimo og usa ka lamesa nga nagtipig sa kasayuran bahin sa mga kanta nga gisulat sa lainlaing mga artista. Kini nga mga kanta mahimong bahin sa usa ka album. Usab ang opsyonal nga mga hiyas alang sa kanta mao ang release year, presyo, genre ug rating. Kinahanglan natong tagdon ang dugang nga mga hiyas nga mahimong gikinahanglan sa umaabot pinaagi sa field nga "tag". Mahimo kining magtipig sa semi-structured nga datos isip key-value pairs.
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 paghimo og lamesa sa Cassandra susama kaayo sa PostgreSQL. Usa sa mga nag-unang kalainan mao ang pagkawala sa mga pagpugong sa integridad (sama sa DILI NULL), apan kini ang responsibilidad sa aplikasyon, dili ang database sa NoSQL.. Ang nag-unang yawe naglangkob sa usa ka partition key (Artist column sa pananglitan sa ubos) ug usa ka set sa clustering columns (SongTitle column sa example sa ubos). Ang partition key nagtino kung asa nga partition/shard ang ibutang sa row, ug ang clustering columns nagpakita kon unsaon pag-organisar ang data sulod sa kasamtangang 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
Ang MongoDB nag-organisar og mga datos ngadto sa mga database (Database) (susama sa Keyspace sa Cassandra), diin adunay mga koleksyon (Collections) (susama sa mga lamesa) nga adunay mga dokumento (Mga Dokumento) (susama sa mga laray sa usa ka lamesa). Sa MongoDB, sa prinsipyo, wala'y gikinahanglan nga pasiunang kahulugan sa eskema. Team "gamita ang database", nga gipakita sa ubos, nag-instantiate sa database sa unang tawag ug nag-usab sa konteksto alang sa bag-ong gibuhat nga database. Bisan ang mga koleksyon dili kinahanglan nga mugnaon nga klaro, kini awtomatiko nga gihimo, kung ang una nga dokumento idugang sa usa ka bag-ong koleksyon. Timan-i nga ang MongoDB naggamit sa usa ka database sa pagsulay pinaagi sa default, busa ang bisan unsang operasyon sa lebel sa pagkolekta nga wala magtino sa usa ka piho nga database ang himuon niini nga default.
use myNewDatabase;Pagkuha og impormasyon bahin sa usa ka lamesa
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;Pagsulod sa datos sa usa ka lamesa
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
Sa kinatibuk-an, ang ekspresyon INSERT sa Cassandra susama kaayo sa usa sa PostgreSQL. Bisan pa, adunay usa ka dako nga kalainan sa semantiko. Sa Cassandra INSERT sa tinuod usa ka operasyon UPSERT, diin ang pinakabag-o nga mga kantidad idugang sa hilo, kung ang hilo anaa na.
Ang pagsulod sa datos susama sa PostgreSQL
INSERTmas taas nga
.
MongoDB
Bisan kung ang MongoDB usa ka database sa NoSQL sama sa Cassandra, ang operasyon sa pagsulod sa datos niini wala’y kalabotan sa semantiko nga pamatasan ni Cassandra. Sa MongoDB walay kahigayonan UPSERT, nga naghimo niini nga susama sa PostgreSQL. Pagdugang sa default data nga wala _idspecified moresulta sa usa ka bag-ong dokumento nga idugang 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"
}
}
);
Pangutana sa lamesa
Tingali ang labing hinungdanon nga kalainan tali sa SQL ug NoSQL sa mga termino sa pagpangutana mao ang paggamit sa FROM и WHERE. Gitugotan sa SQL pagkahuman sa ekspresyon FROM pagpili og daghang mga lamesa, ug usa ka ekspresyon nga adunay WHERE mahimong bisan unsang pagkakomplikado (lakip ang mga operasyon JOIN tali sa mga lamesa). Bisan pa, ang NoSQL lagmit nga magpahamtang usa ka lisud nga limitasyon sa FROM, ug pagtrabaho uban sa usa lamang ka piho nga lamesa, ug sa WHERE, ang panguna nga yawe kinahanglan kanunay nga ipiho. Kini tungod sa tinguha nga mapauswag ang pasundayag sa NoSQL, nga among gihisgutan kaniadto. Kini nga tinguha nagdala sa matag posible nga pagkunhod sa bisan unsang cross-tab ug cross-key nga interaksyon. Makapaila kini sa usa ka dako nga paglangan sa inter-node nga komunikasyon sa pagtubag sa usa ka hangyo ug busa labing maayo nga malikayan sa prinsipyo. Pananglitan, gikinahanglan ni Cassandra ang mga hangyo nga higpitan sa pipila ka mga operator (gitugotan lang =, IN, <, >, =>, <=) sa mga yawe sa partisyon, gawas sa pagpangutana sa usa ka sekondaryang indeks (ang = operator ra ang gitugotan dinhi).
PostgreSQL
Ang mosunod mao ang tulo ka mga pananglitan sa mga pangutana nga daling ipatuman sa SQL database.
- Ipakita ang tanang kanta sa artist;
- Ipakita ang tanang kanta sa artist nga mohaum sa unang bahin sa ulohan;
- Ipakita ang tanan nga mga kanta sa usa ka artista nga adunay usa ka piho nga pulong sa ilang titulo ug adunay presyo nga ubos 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 pangutana sa PostgreSQL nga gilista sa ibabaw, ang una ra ang molihok nga wala mausab sa Cassandra, tungod kay ang pahayag LIKE dili magamit sa clustering columns sama sa SongTitle. Sa kini nga kaso, ang mga operator ra ang gitugotan = и 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
Sama sa gipakita sa miaging mga pananglitan, ang panguna nga pamaagi sa paghimo og mga pangutana sa MongoDB mao ang . Kini nga pamaagi klaro nga naglangkob sa ngalan sa koleksyon (music sa panig-ingnan sa ubos), mao nga ang pagpangutana sa daghang mga koleksyon dili gitugotan.
db.music.find( {
artist: "No One You Know"
}
);
db.music.find( {
artist: "No One You Know",
songTitle: /Call/
}
);Pagbasa sa tanang laray sa usa ka lamesa
Ang pagbasa sa tanan nga mga laray usa lamang ka espesyal nga kaso sa sumbanan sa pangutana nga among gihisgutan sa sayo pa.
PostgreSQL
SELECT *
FROM Music;Cassandra
Susama sa panig-ingnan sa PostgreSQL sa ibabaw.
MongoDB
db.music.find( {} );Pag-edit sa datos sa usa ka lamesa
PostgreSQL
Naghatag ang PostgreSQL og pahayag UPDATE aron usbon ang datos. Wala siyay kahigayonan UPSERT, busa kini nga pahayag mapakyas kung ang laray wala na sa database.
UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';Cassandra
Si Cassandra adunay UPDATE susama sa PostgreSQL. UPDATE adunay parehas nga semantika UPSERT, sama sa INSERT.
Susama sa panig-ingnan sa PostgreSQL sa ibabaw.
MongoDB
Operasyon sa MongoDB kini hingpit nga maka-update sa usa ka kasamtangan nga dokumento o mag-update lamang sa pipila ka mga natad. Pinaagi sa default kini nag-update lamang sa usa ka dokumento nga adunay mga semantics nga gi-disable UPSERT. I-refresh ang daghang mga dokumento ug parehas nga pamatasan UPSERT mahimong magamit pinaagi sa pagbutang og dugang nga mga bandila alang sa operasyon. Sama pananglit sa pananglitan sa ubos, ang genre sa usa ka partikular nga artista gi-update sa iyang kanta.
db.music.update(
{"artist": "The Acme Band"},
{
$set: {
"genre": "Disco"
}
},
{"multi": true, "upsert": true}
);Pagtangtang sa datos gikan sa usa ka lamesa
PostgreSQL
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';Cassandra
Susama sa panig-ingnan sa PostgreSQL sa ibabaw.
MongoDB
Ang MongoDB adunay duha ka matang sa operasyon para sa pagtangtang sa mga dokumento - и . Ang duha ka mga tipo nagtangtang sa mga dokumento apan nagbalik sa lainlaing mga resulta.
db.music.deleteMany( {
artist: "The Acme Band"
}
);
Pagtangtang sa usa ka lamesa
PostgreSQL
DROP TABLE Music;Cassandra
Susama sa panig-ingnan sa PostgreSQL sa ibabaw.
MongoDB
db.music.drop();konklusyon
Ang debate bahin sa pagpili tali sa SQL ug NoSQL nag-away sa sobra sa 10 ka tuig. Adunay duha ka nag-unang aspeto niini nga debate: ang arkitektura sa database engine (monolithic, transactional SQL vs. distributed, non-transactional NoSQL) ug ang pamaagi sa database design (data modeling sa SQL vs. modeling sa imong mga pangutana sa NoSQL).
Uban sa usa ka gipang-apod-apod nga transactional database sama sa YugaByte DB, ang debate sa arkitektura sa database dali nga mawala. Samtang ang mga volume sa datos mahimong mas dako kaysa kung unsa ang mahimong isulat sa usa ka node, usa ka hingpit nga gipang-apod-apod nga arkitektura nga nagsuporta sa linear write scalability nga adunay awtomatik nga sharding / rebalancing gikinahanglan.
Dugang pa sa giingon sa usa sa mga artikulo , transactional, lig-on nga makanunayon nga mga arkitektura karon mas kaylap nga gisagop aron sa paghatag og mas maayo nga development flexibility kay sa dili-transaksyon, sa katapusan makanunayon nga mga arkitektura.
Pagbalik sa diskusyon sa disenyo sa database, makatarunganon nga isulti nga ang duha nga mga pamaagi sa disenyo (SQL ug NoSQL) gikinahanglan alang sa bisan unsang komplikado nga aplikasyon sa tinuud nga kalibutan. Ang "data modeling" nga pamaagi sa SQL nagtugot sa mga developers nga mas daling makab-ot ang nag-usab-usab nga mga kinahanglanon sa negosyo, samtang ang "query modeling" nga pamaagi sa NoSQL nagtugot sa mga sama nga developers sa pagdumala sa daghang mga datos nga adunay ubos nga latency ug taas nga throughput. Mao kini ang hinungdan nga ang YugaByte DB naghatag sa SQL ug NoSQL API sa usa ka komon nga kinauyokan, ug wala magpasiugda sa bisan unsa nga mga pamaagi. Dugang pa, pinaagi sa paghatag og compatibility sa popular nga database nga mga pinulongan, lakip ang PostgreSQL ug Cassandra, ang YugaByte DB nagsiguro nga ang mga developers dili kinahanglan nga magkat-on og laing pinulongan aron magtrabaho uban sa usa ka gipang-apod-apod nga lig-on nga makanunayon nga database engine.
Niini nga artikulo, among gitan-aw kung giunsa ang pagkalainlain sa mga sukaranan sa disenyo sa database tali sa PostgreSQL, Cassandra, ug MongoDB. Sa mosunod nga mga artikulo, kita mosalom sa mga advanced design concepts sama sa index, transactions, JOINs, TTL directives, ug JSON documents.
Nanghinaut kami nga usa ka maayo nga katapusan sa semana ug giimbitahan ka nga mahitabo sa Mayo 14.
Source: www.habr.com