Hello, kawan-kawan. Sebelum berangkat ke bahagian kedua cuti Mei, kami berkongsi dengan anda bahan yang kami terjemahkan dengan menjangkakan pelancaran aliran baharu pada kursus .
Pembangun aplikasi menghabiskan banyak masa membandingkan berbilang pangkalan data operasi untuk memilih satu yang paling sesuai dengan beban kerja yang dimaksudkan. Keperluan mungkin termasuk pemodelan data yang dipermudahkan, jaminan transaksi, prestasi baca/tulis, penskalaan mendatar dan toleransi kesalahan. Secara tradisinya, pilihan bermula dengan kategori pangkalan data, SQL atau NoSQL, kerana setiap kategori membentangkan satu set pertukaran yang jelas. Prestasi tinggi dari segi kependaman rendah dan daya pemprosesan yang tinggi secara amnya dilihat sebagai keperluan bukan pertukaran dan oleh itu penting untuk mana-mana pangkalan data sampel.
Tujuan artikel ini adalah untuk membantu pembangun aplikasi membuat pilihan yang tepat antara SQL dan NoSQL dalam konteks pemodelan data aplikasi. Kami akan melihat satu pangkalan data SQL, iaitu PostgreSQL, dan dua pangkalan data NoSQL, Cassandra dan MongoDB, untuk merangkumi asas reka bentuk pangkalan data, seperti mencipta jadual, mengisinya, membaca data daripada jadual dan memadamkannya. Dalam artikel seterusnya, kami pasti akan melihat indeks, urus niaga, JOIN, arahan TTL dan reka bentuk pangkalan data berasaskan JSON.
Apakah perbezaan antara SQL dan NoSQL?
Pangkalan data SQL meningkatkan fleksibiliti aplikasi melalui jaminan transaksi ACID, serta keupayaan mereka untuk menanyakan data menggunakan JOIN dengan cara yang tidak dijangka di samping model pangkalan data hubungan normal sedia ada.
Memandangkan seni bina monolitik/nod tunggal dan penggunaan model replikasi tuan-hamba untuk redundansi, pangkalan data SQL tradisional kekurangan dua ciri penting - kebolehskalaan tulis linear (iaitu pembahagian automatik merentas berbilang nod) dan kehilangan data automatik/sifar. Ini bermakna jumlah data yang diterima tidak boleh melebihi daya pemprosesan maksimum bagi satu nod. Di samping itu, beberapa kehilangan data sementara mesti diambil kira dalam toleransi kesalahan (dalam seni bina yang tidak dikongsi). Di sini anda perlu ingat bahawa komitmen baru-baru ini belum lagi ditunjukkan dalam salinan hamba. Kemas kini bukan masa henti juga sukar dicapai dalam pangkalan data SQL.
Pangkalan data NoSQL biasanya diedarkan secara semula jadi, i.e. di dalamnya, data dibahagikan kepada bahagian dan diedarkan merentasi beberapa nod. Mereka memerlukan denormalisasi. Ini bermakna data yang dimasukkan juga mesti disalin beberapa kali untuk membalas permintaan khusus yang anda hantar. Matlamat keseluruhan adalah untuk mendapatkan prestasi tinggi dengan mengurangkan bilangan serpihan yang tersedia semasa bacaan. Ini menunjukkan bahawa NoSQL memerlukan anda memodelkan pertanyaan anda, manakala SQL memerlukan anda memodelkan data anda.
NoSQL menumpukan pada mencapai prestasi tinggi dalam kluster yang diedarkan dan ini merupakan rasional asas untuk banyak pertukaran reka bentuk pangkalan data yang merangkumi kerugian transaksi ACID, JOIN dan indeks sekunder global yang konsisten.
Terdapat hujah bahawa walaupun pangkalan data NoSQL menyediakan kebolehskalaan tulis linear dan toleransi kesalahan yang tinggi, kehilangan jaminan transaksi menjadikannya tidak sesuai untuk data kritikal misi.
Jadual berikut menunjukkan cara pemodelan data dalam NoSQL berbeza daripada SQL.
SQL dan NoSQL: Mengapa kedua-duanya diperlukan?
Aplikasi dunia nyata dengan bilangan pengguna yang besar, seperti Amazon.com, Netflix, Uber dan Airbnb, ditugaskan untuk melaksanakan tugas yang kompleks dan pelbagai aspek. Contohnya, aplikasi e-dagang seperti Amazon.com perlu menyimpan data ringan dan kritikal tinggi seperti maklumat pengguna, produk, pesanan, invois, bersama-sama dengan data berat dan kurang sensitif seperti ulasan produk, mesej sokongan , aktiviti pengguna, ulasan dan cadangan pengguna. Sememangnya, aplikasi ini bergantung pada sekurang-kurangnya satu pangkalan data SQL bersama-sama dengan sekurang-kurangnya satu pangkalan data NoSQL. Dalam sistem merentas wilayah dan global, pangkalan data NoSQL beroperasi sebagai cache teragih geo untuk data yang disimpan dalam pangkalan data SQL sumber yang dipercayai yang berjalan di rantau tertentu.
Bagaimanakah YugaByte DB menggabungkan SQL dan NoSQL?
Dibina pada enjin storan bercampur berorientasikan log, auto-sharding, replikasi konsensus teragih sharded dan transaksi teragih ACID (diilhamkan oleh Google Spanner), YugaByte DB ialah pangkalan data sumber terbuka pertama di dunia yang serasi serentak dengan NoSQL (Cassandra & Redis ) dan SQL (PostgreSQL). Seperti yang ditunjukkan dalam jadual di bawah, YCQL, API DB YugaByte yang serasi dengan Cassandra, menambah konsep urus niaga ACID tunggal dan berbilang kunci serta indeks sekunder global kepada API NoSQL, dengan itu membawa kepada era pangkalan data NoSQL transaksi. Selain itu, YCQL, API DB YugaByte yang serasi dengan PostgreSQL, menambah konsep penskalaan tulis linear dan toleransi kesalahan automatik kepada API SQL, membawa pangkalan data SQL yang diedarkan ke dunia. Oleh kerana YugaByte DB bersifat transaksional, API NoSQL kini boleh digunakan dalam konteks data kritikal misi.
Seperti yang dinyatakan sebelum ini dalam artikel , pilihan antara SQL atau NoSQL dalam YugaByte DB bergantung sepenuhnya pada ciri-ciri beban kerja asas:
- Jika beban kerja utama anda ialah operasi JOIN berbilang kunci, maka apabila memilih YSQL, fahami bahawa kunci anda mungkin diedarkan merentasi berbilang nod, menghasilkan kependaman yang lebih tinggi dan/atau pemprosesan yang lebih rendah daripada NoSQL.
- Jika tidak, pilih salah satu daripada dua API NoSQL, dengan mengingati bahawa anda akan mendapat prestasi yang lebih baik hasil daripada pertanyaan yang disampaikan daripada satu nod pada satu masa. YugaByte DB boleh berfungsi sebagai pangkalan data operasi tunggal untuk aplikasi kompleks dunia nyata yang perlu mengurus berbilang beban kerja secara serentak.
Makmal pemodelan data dalam bahagian seterusnya adalah berdasarkan pangkalan data DB YugaByte DB yang serasi PostgreSQL dan Cassandra API, berbanding pangkalan data asli. Pendekatan ini menekankan kemudahan berinteraksi dengan dua API berbeza (pada dua port berbeza) bagi kluster pangkalan data yang sama, berbanding menggunakan kluster bebas sepenuhnya bagi dua pangkalan data berbeza.
Dalam bahagian berikut, kami akan melihat makmal pemodelan data untuk menggambarkan perbezaan dan beberapa persamaan pangkalan data yang diliputi.
Makmal Pemodelan Data
Pemasangan pangkalan data
Memandangkan penekanan pada reka bentuk model data (bukannya seni bina penggunaan yang kompleks), kami akan memasang pangkalan data dalam bekas Docker pada mesin tempatan dan kemudian berinteraksi dengan mereka menggunakan cangkerang baris arahan masing-masing.
Pangkalan data DB YugaByte yang serasi 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:latestAkses baris arahan
Mari sambung ke pangkalan data menggunakan shell baris arahan untuk API yang sepadan.
PostgreSQL
ialah shell baris arahan untuk berinteraksi dengan PostgreSQL. Untuk kemudahan penggunaan, YugaByte DB disertakan dengan psql terus dalam folder bin.
docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgresCassandra
ialah shell baris arahan untuk berinteraksi dengan Cassandra dan pangkalan data yang serasi melalui CQL (Cassandra Query Language). Untuk kemudahan penggunaan, YugaByte DB disertakan bersama cqlsh dalam katalog bin.
Ambil perhatian bahawa CQL telah diilhamkan oleh SQL dan mempunyai konsep jadual, baris, lajur dan indeks yang serupa. Walau bagaimanapun, sebagai bahasa NoSQL, ia menambah set batasan tertentu, yang kebanyakannya akan kami bincangkan juga dalam artikel lain.
docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlshMongoDB
ialah shell baris arahan untuk berinteraksi dengan MongoDB. Ia boleh didapati dalam direktori bin pemasangan MongoDB.
docker exec -it my-mongo bash
cd bin
mongoMencipta jadual
Kini kita boleh berinteraksi dengan pangkalan data untuk melaksanakan pelbagai operasi menggunakan baris arahan. Mari mulakan dengan mencipta jadual yang menyimpan maklumat tentang lagu yang ditulis oleh artis yang berbeza. Lagu-lagu ini mungkin sebahagian daripada album. Juga atribut pilihan untuk lagu ialah tahun keluaran, harga, genre dan rating. Kami perlu mengambil kira atribut tambahan yang mungkin diperlukan pada masa hadapan melalui medan "tag". Ia boleh menyimpan data separa berstruktur dalam bentuk pasangan nilai kunci.
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
Mencipta jadual dalam Cassandra sangat serupa dengan PostgreSQL. Salah satu perbezaan utama ialah kekurangan kekangan integriti (cth. NOT NULL), tetapi ini adalah tanggungjawab aplikasi, bukan pangkalan data NoSQL. Kunci utama terdiri daripada kunci partition (lajur Artis dalam contoh di bawah) dan satu set lajur pengelompokan (lajur Tajuk Lagu dalam contoh di bawah). Kekunci partition menentukan partition/shard mana baris harus diletakkan, dan lajur pengelompokan menunjukkan cara data harus disusun dalam shard semasa.
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 menyusun data ke dalam pangkalan data (Pangkalan Data) (serupa dengan Keyspace dalam Cassandra), di mana terdapat Koleksi (serupa dengan jadual) yang mengandungi Dokumen (serupa dengan baris dalam jadual). Dalam MongoDB, pada dasarnya tidak ada keperluan untuk menentukan skema awal. Pasukan "gunakan pangkalan data", ditunjukkan di bawah, menjadikan pangkalan data pada panggilan pertama dan menukar konteks untuk pangkalan data yang baru dibuat. Malah koleksi tidak perlu dibuat secara eksplisit; ia dibuat secara automatik, hanya apabila anda menambah dokumen pertama pada koleksi baharu. Ambil perhatian bahawa MongoDB menggunakan pangkalan data ujian secara lalai, jadi sebarang operasi peringkat koleksi tanpa menyatakan pangkalan data tertentu akan dijalankan padanya secara lalai.
use myNewDatabase;Mendapatkan maklumat tentang jadual
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;Memasukkan data ke dalam jadual
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 keseluruhan INSERT dalam Cassandra kelihatan sangat serupa dengan PostgreSQL. Walau bagaimanapun, terdapat satu perbezaan besar dalam semantik. Dalam Cassandra INSERT sebenarnya adalah operasi UPSERT, di mana nilai terakhir ditambahkan pada baris jika baris itu sudah wujud.
Kemasukan data adalah serupa dengan PostgreSQL
INSERTatas
.
MongoDB
Walaupun MongoDB ialah pangkalan data NoSQL seperti Cassandra, operasi sisipannya tidak mempunyai persamaan dengan tingkah laku semantik Cassandra. Dalam MongoDB tidak mempunyai peluang UPSERT, yang menjadikannya serupa dengan PostgreSQL. Menambah data lalai tanpa _idspecified akan menyebabkan dokumen baharu ditambahkan pada 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"
}
}
);
Pertanyaan Jadual
Mungkin perbezaan paling ketara antara SQL dan NoSQL dari segi pembinaan pertanyaan ialah bahasa yang digunakan FROM ΠΈ WHERE. SQL membenarkan selepas ungkapan FROM pilih berbilang jadual, dan ungkapan dengan WHERE boleh mempunyai sebarang kerumitan (termasuk operasi JOIN antara jadual). Walau bagaimanapun, NoSQL cenderung untuk mengenakan had yang teruk pada FROM, dan berfungsi hanya dengan satu jadual tertentu, dan dalam WHERE, kunci utama mesti sentiasa ditentukan. Ini berkaitan dengan dorongan prestasi NoSQL yang kita bincangkan sebelum ini. Keinginan ini membawa kepada setiap kemungkinan pengurangan dalam mana-mana interaksi jadual silang dan kunci silang. Ia boleh memperkenalkan kelewatan yang besar dalam komunikasi antara nod apabila bertindak balas kepada permintaan dan oleh itu sebaiknya dielakkan secara umum. Sebagai contoh, Cassandra memerlukan pertanyaan dihadkan kepada pengendali tertentu (hanya =, IN, <, >, =>, <=) pada kekunci partition, kecuali apabila meminta indeks sekunder (hanya operator = dibenarkan di sini).
PostgreSQL
Di bawah ialah tiga contoh pertanyaan yang boleh dilaksanakan dengan mudah oleh pangkalan data SQL.
- Paparkan semua lagu oleh artis;
- Paparkan semua lagu oleh artis yang sepadan dengan bahagian pertama tajuk;
- Paparkan semua lagu oleh artis yang mempunyai perkataan tertentu dalam tajuk dan mempunyai harga kurang daripada 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
Daripada pertanyaan PostgreSQL yang disenaraikan di atas, hanya yang pertama akan berfungsi tidak berubah dalam Cassandra, kerana pengendali LIKE tidak boleh digunakan untuk mengelompokkan lajur seperti SongTitle. Dalam kes ini, hanya pengendali dibenarkan = ΠΈ 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
Seperti yang ditunjukkan dalam contoh sebelumnya, kaedah utama untuk membuat pertanyaan dalam MongoDB ialah . Kaedah ini secara eksplisit mengandungi nama koleksi (music dalam contoh di bawah), jadi menanyakan berbilang koleksi adalah dilarang.
db.music.find( {
artist: "No One You Know"
}
);
db.music.find( {
artist: "No One You Know",
songTitle: /Call/
}
);Membaca semua baris jadual
Membaca semua baris hanyalah satu kes khas bagi corak pertanyaan yang kami lihat sebelum ini.
PostgreSQL
SELECT *
FROM Music;Cassandra
Sama seperti contoh PostgreSQL di atas.
MongoDB
db.music.find( {} );Mengedit data dalam jadual
PostgreSQL
PostgreSQL menyediakan arahan UPDATE untuk menukar data. Dia tidak mempunyai peluang UPSERT, jadi pernyataan ini akan gagal jika baris itu tidak lagi dalam pangkalan data.
UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';Cassandra
Cassandra ada UPDATE serupa dengan PostgreSQL. UPDATE mempunyai semantik yang sama UPSERT, serupa INSERT.
Sama seperti contoh PostgreSQL di atas.
MongoDB
Operasi dalam MongoDB boleh mengemas kini sepenuhnya dokumen sedia ada atau mengemas kini medan tertentu sahaja. Secara lalai, ia hanya mengemas kini satu dokumen dengan semantik dilumpuhkan UPSERT. Mengemas kini berbilang dokumen dan tingkah laku yang serupa UPSERT boleh digunakan dengan menetapkan bendera tambahan untuk operasi. Contohnya, dalam contoh di bawah, genre artis tertentu dikemas kini berdasarkan lagunya.
db.music.update(
{"artist": "The Acme Band"},
{
$set: {
"genre": "Disco"
}
},
{"multi": true, "upsert": true}
);Mengalih keluar data daripada jadual
PostgreSQL
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';Cassandra
Sama seperti contoh PostgreSQL di atas.
MongoDB
MongoDB mempunyai dua jenis operasi untuk memadam dokumen β ΠΈ . Kedua-dua jenis memadam dokumen tetapi mengembalikan hasil yang berbeza.
db.music.deleteMany( {
artist: "The Acme Band"
}
);
Memadamkan jadual
PostgreSQL
DROP TABLE Music;Cassandra
Sama seperti contoh PostgreSQL di atas.
MongoDB
db.music.drop();Kesimpulan
Perdebatan tentang memilih antara SQL dan NoSQL telah berlarutan selama lebih daripada 10 tahun. Terdapat dua aspek utama untuk perbahasan ini: seni bina enjin pangkalan data (monolitik, SQL transaksi vs diedarkan, NoSQL bukan transaksi) dan pendekatan reka bentuk pangkalan data (memodelkan data anda dalam SQL berbanding memodelkan pertanyaan anda dalam NoSQL).
Dengan pangkalan data transaksi yang diedarkan seperti YugaByte DB, perdebatan tentang seni bina pangkalan data boleh dihentikan dengan mudah. Apabila volum data menjadi lebih besar daripada apa yang boleh ditulis pada satu nod, seni bina teragih sepenuhnya yang menyokong kebolehskalaan tulis linear dengan sharding/pengimbangan semula automatik menjadi perlu.
Selain itu, seperti yang dinyatakan dalam salah satu artikel , Seni bina transaksional dan sangat konsisten kini lebih banyak digunakan untuk menyediakan ketangkasan pembangunan yang lebih baik daripada seni bina bukan transaksi, , akhirnya konsisten.
Berbalik kepada perbincangan reka bentuk pangkalan data, adalah wajar untuk mengatakan bahawa kedua-dua pendekatan reka bentuk (SQL dan NoSQL) adalah perlu untuk sebarang aplikasi dunia nyata yang kompleks. Pendekatan "pemodelan data" SQL membolehkan pembangun lebih mudah memenuhi keperluan perniagaan yang berubah-ubah, manakala pendekatan "pemodelan pertanyaan" NoSQL membolehkan pembangun yang sama beroperasi pada volum data yang besar dengan kependaman rendah dan daya pemprosesan yang tinggi. Atas sebab inilah YugaByte DB menyediakan API SQL dan NoSQL dalam teras yang sama, dan bukannya mempromosikan salah satu pendekatan. Selain itu, dengan menyediakan keserasian dengan bahasa pangkalan data popular termasuk PostgreSQL dan Cassandra, YugaByte DB memastikan bahawa pembangun tidak perlu mempelajari bahasa lain untuk bekerja dengan enjin pangkalan data yang diedarkan dan sangat konsisten.
Dalam artikel ini, kami melihat bagaimana asas reka bentuk pangkalan data berbeza antara PostgreSQL, Cassandra dan MongoDB. Dalam artikel akan datang, kami akan menyelami konsep reka bentuk lanjutan seperti indeks, urus niaga, JOIN, arahan TTL dan dokumen JSON.
Kami mengucapkan selamat berehat di hujung minggu dan menjemput anda , yang akan berlangsung pada 14 Mei.
Sumber: www.habr.com