ProHoster > Блог > Administrasi > Dhasar Desain Database - Mbandhingake PostgreSQL, Cassandra, lan MongoDB

Dhasar Desain Database - Mbandhingake PostgreSQL, Cassandra, lan MongoDB

Halo, kanca-kanca. Sadurunge budhal ing bagean kapindho preian Mei, kita bareng karo sampeyan materi sing diterjemahake kanggo nunggu peluncuran aliran anyar ing kursus kasebut. "DBMS relasional".

Dhasar Desain Database - Mbandhingake PostgreSQL, Cassandra, lan MongoDB

Pangembang aplikasi nglampahi akeh wektu mbandhingake sawetara database operasional kanggo milih sing paling cocog karo beban kerja sing dituju. Kabutuhan bisa uga kalebu modeling data sing disederhanakake, jaminan transaksional, kinerja maca / nulis, skala horisontal, lan toleransi kesalahan. Sacara tradisional, pilihan kasebut diwiwiti kanthi kategori basis data, SQL utawa NoSQL, amarga saben kategori menehi pilihan sing jelas. Kinerja dhuwur ing babagan latensi sing kurang lan throughput sing dhuwur umume katon minangka syarat sing ora dituku lan mulane penting kanggo database sampel.

Tujuan artikel iki kanggo mbantu pangembang aplikasi nggawe pilihan sing tepat antarane SQL lan NoSQL ing konteks modeling data aplikasi. Kita bakal nliti siji database SQL, yaiku PostgreSQL, lan rong basis data NoSQL, Cassandra lan MongoDB, kanggo nutupi dhasar desain basis data, kayata nggawe tabel, ngisi, maca data saka tabel, lan mbusak. Ing artikel sabanjure, kita mesthi bakal ndeleng indeks, transaksi, JOIN, arahan TTL, lan desain basis data berbasis JSON.

Apa bedane SQL lan NoSQL?

Database SQL nambah keluwesan aplikasi liwat jaminan transaksional ACID, uga kemampuan kanggo takon data nggunakake GABUNGAN kanthi cara sing ora dikarepke ing ndhuwur model database relasional sing wis normal.

Amarga arsitektur monolitik / simpul tunggal lan nggunakake model replikasi master-budak kanggo redundansi, database SQL tradisional ora duwe rong fitur penting - skalabilitas nulis linier (yaiku partisi otomatis ing pirang-pirang simpul) lan mundhut data otomatis / nul. Iki tegese jumlah data sing ditampa ora bisa ngluwihi throughput nulis maksimum siji simpul. Kajaba iku, sawetara mundhut data sauntara kudu dijupuk menyang akun ing toleransi fault (ing arsitektur sambungan-ora ana). Ing kene sampeyan kudu ngelingi manawa komitmen anyar durung katon ing salinan budak. Nganyari non-downtime uga angel digayuh ing database SQL.

database NoSQL biasane mbagekke dening alam, i.e. ing wong-wong mau, data dipérang dadi bagean lan disebarake ing sawetara kelenjar. Dheweke mbutuhake denormalisasi. Iki tegese data sing dilebokake uga kudu disalin kaping pirang-pirang kanggo nanggapi panjaluk tartamtu sing dikirim. Sasaran sakabèhé yaiku entuk kinerja sing dhuwur kanthi nyuda jumlah pecahan sing kasedhiya sajrone maca. Iki nuduhake yen NoSQL mbutuhake sampeyan nggawe model pitakon, dene SQL mbutuhake sampeyan nggawe model data.

NoSQL fokus kanggo nggayuh kinerja dhuwur ing kluster sing disebarake lan iki minangka alasan dhasar kanggo akeh tradeoffs desain database sing kalebu mundhut transaksi ACID, GABUNGAN, lan indeks sekunder global sing konsisten.

Ana bantahan manawa database NoSQL nyedhiyakake skalabilitas nulis linear lan toleransi kesalahan sing dhuwur, mundhut jaminan transaksional ndadekake dheweke ora cocog kanggo data kritis misi.

Tabel ing ngisor iki nuduhake carane modeling data ing NoSQL beda karo SQL.

Dhasar Desain Database - Mbandhingake PostgreSQL, Cassandra, lan MongoDB

SQL lan NoSQL: Napa loro-lorone dibutuhake?

Aplikasi ing donya nyata kanthi akeh pangguna, kayata Amazon.com, Netflix, Uber, lan Airbnb, ditugasake nindakake tugas sing rumit lan macem-macem. Contone, aplikasi e-commerce kaya Amazon.com kudu nyimpen data sing entheng lan kritis kayata informasi pangguna, produk, pesenan, invoice, bebarengan karo data sing abot lan kurang sensitif kayata review produk, pesen dhukungan, aktivitas pangguna, reviews pangguna lan Rekomendasi. Mesthine, aplikasi iki gumantung ing paling ora siji database SQL bebarengan karo paling siji database NoSQL. Ing sistem lintas-regional lan global, basis data NoSQL beroperasi minangka cache sing disebarake geo kanggo data sing disimpen ing basis data SQL sumber sing dipercaya sing mlaku ing wilayah tartamtu.

Kepiye YugaByte DB nggabungake SQL lan NoSQL?

Dibangun ing mesin panyimpenan campuran berorientasi log, auto-sharding, replikasi konsensus sing disebarake sharded lan transaksi sing disebarake ACID (inspirasi saka Google Spanner), YugaByte DB minangka basis data open source pisanan ing donya sing kompatibel karo NoSQL (Cassandra & Redis) lan SQL (PostgreSQL). Kaya sing ditampilake ing tabel ing ngisor iki, YCQL, API DB YugaByte sing kompatibel karo Cassandra, nambahake konsep transaksi ACID siji lan multi-tombol lan indeks sekunder global menyang API NoSQL, saéngga nuwuhake jaman database NoSQL transaksional. Kajaba iku, YCQL, API DB YugaByte sing kompatibel karo PostgreSQL, nambahake konsep skala nulis linear lan toleransi kesalahan otomatis menyang SQL API, nggawa database SQL sing disebarake ing saindenging jagad. Amarga YugaByte DB sifate transaksional, API NoSQL saiki bisa digunakake ing konteks data kritis misi.

Dhasar Desain Database - Mbandhingake PostgreSQL, Cassandra, lan MongoDB

Kaya sing kasebut sadurunge ing artikel "Introducing YSQL: A PostgreSQL Compatible Distributed SQL API for YugaByte DB", pilihan antarane SQL utawa NoSQL ing YugaByte DB gumantung banget marang karakteristik beban kerja sing ndasari:

  • Yen beban kerja utama sampeyan yaiku operasi JOIN multi-tombol, banjur nalika milih YSQL, mangertos manawa kunci sampeyan bisa disebar ing pirang-pirang node, sing nyebabake latensi lan/utawa throughput sing luwih murah tinimbang NoSQL.
  • Yen ora, pilih salah siji saka loro API NoSQL, elinga yen sampeyan bakal entuk kinerja sing luwih apik amarga pitakon sing dilayani saka siji simpul sekaligus. YugaByte DB bisa dadi basis data operasional siji kanggo aplikasi nyata, kompleks sing kudu ngatur macem-macem beban kerja bebarengan.

Lab modeling Data ing bagean sabanjure adhedhasar database DB YugaByte DB sing kompatibel karo PostgreSQL lan Cassandra API, minangka lawan saka database asli. Pendekatan iki nandheske ease saka sesambungan karo loro API beda (ing rong bandar beda) saka kluster database padha, minangka gantos kanggo nggunakake kelompok rampung sawijining saka loro database beda.
Ing bagean ing ngisor iki, kita bakal nliti lab modeling data kanggo nggambarake bedane lan sawetara kesamaan database sing dicakup.

Laboratorium Pemodelan Data

Instalasi database

Amarga penekanan ing desain model data (tinimbang arsitektur penyebaran kompleks), kita bakal nginstal database ing wadhah Docker ing mesin lokal banjur sesambungan karo dheweke nggunakake cangkang baris perintah.

Database DB YugaByte sing kompatibel karo 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_postgres

MongoDB

docker run --name my-mongo -d mongo:latest

akses baris printah

Ayo nyambung menyang basis data nggunakake cangkang baris perintah kanggo API sing cocog.

PostgreSQL

psql yaiku cangkang baris perintah kanggo sesambungan karo PostgreSQL. Kanggo gampang digunakake, YugaByte DB dilengkapi psql ing folder bin.

docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres

Cassandra

cqlsh yaiku cangkang baris perintah kanggo sesambungan karo Cassandra lan database sing kompatibel liwat CQL (Cassandra Query Language). Kanggo ease saka nggunakake, YugaByte DB nerangake karo cqlsh ing katalog bin.
Elinga yen CQL diilhami dening SQL lan nduweni konsep tabel, baris, kolom lan indeks sing padha. Nanging, minangka basa NoSQL, nambahake watesan tartamtu, sing umume uga bakal dibahas ing artikel liyane.

docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh

MongoDB

mongo minangka cangkang baris perintah kanggo sesambungan karo MongoDB. Bisa ditemokake ing direktori bin instalasi MongoDB.

docker exec -it my-mongo bash 
cd bin
mongo

Nggawe meja

Saiki kita bisa sesambungan karo database kanggo nindakake macem-macem operasi nggunakake baris printah. Ayo diwiwiti kanthi nggawe tabel sing nyimpen informasi babagan lagu sing ditulis dening seniman sing beda-beda. Lagu-lagu iki bisa dadi bagéan saka album. Uga atribut opsional kanggo lagu yaiku taun rilis, rega, genre lan rating. Kita kudu nyathet atribut tambahan sing bisa uga dibutuhake ing mangsa ngarep liwat kolom "tag". Bisa nyimpen data semi-terstruktur ing wangun pasangan kunci-nilai.

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

Nggawe tabel ing Cassandra meh padha karo PostgreSQL. Salah sawijining prabédan utama yaiku kekurangan kendala integritas (contone, NOT NULL), nanging iki minangka tanggung jawab aplikasi, dudu database NoSQL.. Tombol utami kasusun saka tombol partisi (kolom Artis ing conto ing ngisor iki) lan sakumpulan kolom clustering (kolom SongTitle ing conto ing ngisor iki). Tombol partisi nemtokake partisi / shard baris sing kudu diselehake, lan kolom clustering nuduhake carane data kudu diatur ing shard saiki.

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 ngatur data menyang basis data (Database) (padha karo Keyspace ing Cassandra), ing ngendi ana Koleksi (padha karo tabel) sing ngemot Dokumen (padha karo baris ing tabel). Ing MongoDB, ora perlu kanggo nemtokake skema awal. tim "nggunakake database", ditampilake ing ngisor iki, instantiates database ing telpon pisanan lan ngganti konteks kanggo database mentas digawe. Malah koleksi ora perlu digawe kanthi eksplisit; padha digawe kanthi otomatis, mung nalika sampeyan nambahake dokumen pisanan menyang koleksi anyar. Elinga yen MongoDB nggunakake basis data tes kanthi standar, mula operasi tingkat koleksi apa wae tanpa nemtokake basis data tartamtu bakal mbukak kanthi standar. 

use myNewDatabase;

Njupuk informasi babagan meja
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;

Ngetik data menyang tabel
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

Ekspresi sakabèhé INSERT ing Cassandra katon meh padha karo ing PostgreSQL. Nanging, ana siji prabédan gedhe ing semantik. Ing Cassandra INSERT iku bener operasi UPSERT, ing ngendi nilai pungkasan ditambahake ing baris yen baris kasebut wis ana.

Entri data padha karo PostgreSQL INSERT luwih

.

MongoDB

Sanajan MongoDB minangka basis data NoSQL kaya Cassandra, operasi sisipan ora ana sing padha karo prilaku semantik Cassandra. Ing MongoDB masang () ora duwe kesempatan UPSERT, sing ndadekake padha karo PostgreSQL. Nambahake data standar tanpa _idspecified bakal nyebabake dokumen anyar ditambahake menyang koleksi.

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"
}
}
);

Tabel Pitakonan

Mbok menawa prabédan paling signifikan antarane SQL lan NoSQL babagan konstruksi query yaiku basa sing digunakake FROM и WHERE. SQL ngidini sawise expression FROM pilih sawetara tabel, lan expression karo WHERE bisa dadi kerumitan apa wae (kalebu operasi JOIN antarane tabel). Nanging, NoSQL cenderung ngetrapake watesan sing abot FROM, lan mung bisa digunakake karo siji tabel tartamtu, lan ing WHERE, kunci utama kudu tansah ditemtokake. Iki ana hubungane karo push kinerja NoSQL sing wis diomongake sadurunge. Kepinginan iki ndadékaké saben pengurangan sing bisa ditindakake ing interaksi salib-tabular lan lintas-tombol. Bisa ngenalake wektu tundha gedhe ing komunikasi antar-simpul nalika nanggapi panjaluk lan mulane paling apik dihindari ing umum. Contone, Cassandra mbutuhake pitakon diwatesi kanggo operator tartamtu (mung =, IN, <, >, =>, <=) ing tombol partisi, kajaba nalika njaluk indeks sekunder (mung operator = sing diidini ing kene).

PostgreSQL

Ing ngisor iki ana telung conto pitakon sing bisa gampang dieksekusi dening database SQL.

  • Tampilake kabeh lagu dening artis;
  • Tampilake kabeh lagu dening artis sing cocog karo bagean pisanan judhul;
  • Nampilake kabeh lagu dening artis sing duwe tembung tartamtu ing judhul lan duwe rega kurang saka 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

Saka pitakon PostgreSQL sing kadhaptar ing ndhuwur, mung sing pisanan sing ora bisa digunakake ing Cassandra, amarga operator LIKE ora bisa ditrapake kanggo kolom clustering kayata SongTitle. Ing kasus iki, mung operator sing diijini = и 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

Kaya sing dituduhake ing conto sadurunge, cara utama kanggo nggawe pitakon ing MongoDB yaiku db.collection.find(). Cara iki kanthi eksplisit ngemot jeneng koleksi (music ing conto ing ngisor iki), supaya takon macem-macem koleksi dilarang.

db.music.find( {
  artist: "No One You Know"
 } 
);
db.music.find( {
  artist: "No One You Know",
  songTitle: /Call/
 } 
);

Maca kabeh larik meja

Maca kabeh baris mung minangka kasus khusus saka pola pitakon sing kita deleng sadurunge.

PostgreSQL

SELECT * 
FROM Music;

Cassandra

Padha karo conto PostgreSQL ing ndhuwur.

MongoDB

db.music.find( {} );

Ngowahi data ing tabel

PostgreSQL

PostgreSQL nyedhiyakake instruksi UPDATE kanggo ngganti data. Dheweke ora duwe kesempatan UPSERT, supaya statement iki bakal gagal yen baris ora ana maneh ing database.

UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

Cassandra

Cassandra wis UPDATE padha karo PostgreSQL. UPDATE nduweni semantik sing padha UPSERT, mirip INSERT.

Padha karo conto PostgreSQL ing ndhuwur.

MongoDB
Operasi nganyari () ing MongoDB bisa nganyari dokumen sing wis ana utawa mung nganyari lapangan tartamtu. Kanthi gawan, mung nganyari siji dokumen kanthi semantik dipateni UPSERT. Nganyari pirang-pirang dokumen lan prilaku sing padha UPSERT bisa diterapake kanthi nyetel panji tambahan kanggo operasi kasebut. Contone, ing conto ing ngisor iki, genre artis tartamtu dianyari adhedhasar lagune.

db.music.update(
  {"artist": "The Acme Band"},
  { 
    $set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

Mbusak data saka tabel

PostgreSQL

DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

Cassandra

Padha karo conto PostgreSQL ing ndhuwur.

MongoDB

MongoDB duwe rong jinis operasi kanggo mbusak dokumen − deleteOne() /deleteMany() и mbusak (). Loro-lorone jinis mbusak dokumen nanging ngasilake asil sing beda. 

db.music.deleteMany( {
        artist: "The Acme Band"
    }
);

Mbusak tabel

PostgreSQL

DROP TABLE Music;

Cassandra

Padha karo conto PostgreSQL ing ndhuwur.

MongoDB

db.music.drop();

kesimpulan

Debat babagan milih antarane SQL lan NoSQL wis raging luwih saka 10 taun. Ana rong aspek utama kanggo debat iki: arsitektur mesin database (monolitik, SQL transaksional vs disebarake, NoSQL non-transaksional) lan pendekatan desain database (modeling data sampeyan ing SQL vs modeling pitakon sampeyan ing NoSQL).

Kanthi basis data transaksi sing disebarake kaya YugaByte DB, debat babagan arsitektur database bisa gampang dilebokake. Nalika volume data dadi luwih gedhe tinimbang sing bisa ditulis ing simpul siji, arsitektur sing disebarake kanthi lengkap sing ndhukung skalabilitas nulis linear kanthi sharding / rebalancing otomatis dadi perlu.

Kajaba iku, kaya sing kasebut ing salah sawijining artikel Google Cloud, Arsitek transaksional, konsisten banget saiki luwih , digunakake kanggo nyedhiyakake ketangkasan pangembangan sing luwih apik tinimbang arsitektur non-transaksional, , pungkasane konsisten.

Mbalik maneh menyang diskusi desain basis data, bener yen loro pendekatan desain (SQL lan NoSQL) perlu kanggo aplikasi apa wae sing rumit. Pendekatan "modeling data" SQL ngidini pangembang luwih gampang nyukupi syarat bisnis sing owah-owahan, dene pendekatan "pemodelan pitakon" NoSQL ngidini pangembang sing padha bisa ngoperasikake data kanthi volume gedhe kanthi latensi sing sithik lan throughput sing dhuwur. Mulane YugaByte DB nyedhiyakake SQL lan NoSQL API ing inti umum, tinimbang promosi salah sawijining pendekatan. Kajaba iku, kanthi menehi kompatibilitas karo basa basis data populer kalebu PostgreSQL lan Cassandra, YugaByte DB mesthekake yen pangembang ora kudu sinau basa liya kanggo nggarap mesin basis data sing disebarake lan konsisten banget.

Ing artikel iki, kita ndeleng carane dhasar desain database beda antarane PostgreSQL, Cassandra, lan MongoDB. Ing artikel sabanjure, kita bakal nyilem menyang konsep desain canggih kayata indeks, transaksi, JOIN, arahan TTL, lan dokumen JSON.

Kita pengin sampeyan ngaso gedhe ing akhir minggu lan ngajak sampeyan webinar gratis, sing bakal ditindakake tanggal 14 Mei.

Source: www.habr.com

Add a comment