Salam dostlar. May tətilinin ikinci hissəsinə yola düşməzdən əvvəl, məzənnə ilə yeni axının başlaması ərəfəsində tərcümə etdiyimiz materialı sizinlə paylaşırıq. .
Tətbiq tərtibatçıları nəzərdə tutulan iş yükü üçün ən yaxşısını seçmək üçün çoxsaylı əməliyyat verilənlər bazalarını müqayisə etməyə çox vaxt sərf edirlər. Ehtiyaclara sadələşdirilmiş məlumat modelləşdirməsi, əməliyyat zəmanətləri, oxu/yazma performansı, üfüqi miqyaslama və xətaya dözümlülük daxil ola bilər. Ənənəvi olaraq, seçim verilənlər bazası kateqoriyası, SQL və ya NoSQL ilə başlayır, çünki hər bir kateqoriya aydın güzəştlər toplusunu təmin edir. Aşağı gecikmə və yüksək ötürmə qabiliyyəti baxımından yüksək performans, ümumiyyətlə, güzəşt edilə bilməyən bir tələb kimi qəbul edilir və buna görə də nümunədəki hər hansı bir verilənlər bazası üçün vacibdir.
Bu məqalənin məqsədi proqram tərtibatçılarına proqram məlumatlarının modelləşdirilməsi kontekstində SQL və NoSQL arasında düzgün seçim etməkdə kömək etməkdir. Cədvəllərin yaradılması, onların doldurulması, cədvəldən verilənlərin oxunması və silinməsi kimi verilənlər bazası dizaynının əsaslarını əhatə etmək üçün bir SQL verilənlər bazasına, yəni PostgreSQL-ə və iki NoSQL verilənlər bazasına, Cassandra və MongoDB-yə baxacağıq. Növbəti məqalədə biz mütləq indekslərə, əməliyyatlara, JOIN-lərə, TTL direktivlərinə və JSON əsasında verilənlər bazası dizaynına baxacağıq.
SQL və NoSQL arasındakı fərq nədir?
SQL verilənlər bazaları ACID tranzaksiya zəmanətləri vasitəsilə tətbiq çevikliyini artırır, həmçinin mövcud normallaşdırılmış relational verilənlər bazası modelləri ilə yanaşı gözlənilməz üsullarla JOIN-lərdən istifadə edərək məlumatları sorğulamaq qabiliyyətini artırır.
Onların monolit/tək node arxitekturası və ehtiyat üçün master-slave replikasiya modelindən istifadəni nəzərə alaraq, ənənəvi SQL verilənlər bazalarında iki mühüm xüsusiyyət yoxdur - xətti yazma miqyası (yəni, birdən çox qovşaq arasında avtomatik bölünmə) və avtomatik/sıfır məlumat itkisi. Bu o deməkdir ki, alınan məlumatların miqdarı bir qovşağın maksimum yazma qabiliyyətindən çox ola bilməz. Bundan əlavə, nasazlığa dözümlülük üçün məlumatların bəzi müvəqqəti itkiləri nəzərə alınmalıdır (paylaşılmayan arxitekturada). Burada yadda saxlamaq lazımdır ki, son öhdəliklər hələ də qul nüsxəsində əks olunmayıb. SQL verilənlər bazalarında heç bir fasilə yeniləmələrinə nail olmaq da çətin deyil.
NoSQL verilənlər bazaları adətən təbiətdə paylanır, yəni. onlarda məlumatlar bölmələrə bölünür və bir neçə qovşaq üzərində paylanır. Onlar denormalizasiya tələb edir. Bu o deməkdir ki, göndərdiyiniz xüsusi sorğulara cavab vermək üçün daxil edilmiş məlumatlar da bir neçə dəfə kopyalanmalıdır. Ümumi məqsəd oxuma zamanı mövcud olan parçaların sayını azaltmaqla yüksək performans əldə etməkdir. Bu o deməkdir ki, NoSQL sizdən sorğularınızı modelləşdirməyi tələb edir, SQL isə məlumatlarınızı modelləşdirməyi tələb edir.
NoSQL paylanmış klasterdə yüksək performansa nail olmağı vurğulayır və bu, ACID əməliyyatlarının, JOIN-lərin və ardıcıl qlobal ikincili indekslərin itirilməsini əhatə edən bir çox verilənlər bazası dizaynı üçün əsas səbəbdir.
Belə bir fikir var ki, NoSQL verilənlər bazaları xətti yazma miqyası və yüksək xətaya dözümlülük təmin etsə də, əməliyyat zəmanətlərinin itirilməsi onları kritik məlumatlar üçün yararsız edir.
Aşağıdakı cədvəl NoSQL-də verilənlərin modelləşdirilməsinin SQL-dən necə fərqləndiyini göstərir.
SQL və NoSQL: Hər ikisi niyə lazımdır?
Amazon.com, Netflix, Uber və Airbnb kimi çox sayda istifadəçisi olan real həyat tətbiqləri müxtəlif növ mürəkkəb tapşırıqların yerinə yetirilməsinə cavabdehdir. Məsələn, Amazon.com kimi e-ticarət proqramı istifadəçilər, məhsullar, sifarişlər, hesab-fakturalar haqqında məlumat kimi yüngül, yüksək həssas məlumatları və məhsul rəyləri, dəstək mesajları kimi ağır, lakin daha az həssas məlumatları saxlamalıdır. , istifadəçi fəaliyyəti. , istifadəçi rəyləri və tövsiyələri. Təbii ki, bu proqramlar ən azı bir NoSQL verilənlər bazası ilə birlikdə ən azı bir SQL verilənlər bazasına əsaslanır. Regionlararası və qlobal sistemlərdə NoSQL verilənlər bazası hər hansı bir bölgədə fəaliyyət göstərən etibarlı mənbədə, SQL verilənlər bazasında saxlanılan məlumatlar üçün geo-paylanmış keş kimi işləyir.
YugaByte DB SQL və NoSQL-i necə birləşdirir?
Jurnal yönümlü qarışıq yaddaş mühərriki, avtomatik parçalanma, parçalanmış paylanmış konsensus replikasiyası və ACID paylanmış əməliyyatlar (Google Spanner-dən ilhamlanıb) üzərində qurulmuş YugaByte DB eyni vaxtda NoSQL (Cassandra və Redis) uyğun gələn dünyanın ilk açıq mənbə verilənlər bazasıdır. ) və SQL (PostgreSQL). Aşağıdakı cədvəldə göstərildiyi kimi, Cassandra ilə uyğun gələn YugaByte DB API-si olan YCQL, NoSQL API-yə tək və çox açarlı ACID əməliyyatları və qlobal ikinci dərəcəli indekslər anlayışlarını əlavə edir və beləliklə, əməliyyat NoSQL verilənlər bazaları dövrünü açır. Bundan əlavə, PostgreSQL ilə uyğun gələn YugaByte DB API olan YCQL, paylanmış SQL verilənlər bazalarını dünyaya gətirərək, SQL API-yə xətti yazma miqyası və avtomatik əvəzetmə anlayışlarını əlavə edir. YugaByte DB verilənlər bazası mahiyyət etibarilə tranzaksiya xarakterli olduğundan, NoSQL API indi kritik məlumatlar kontekstində istifadə edilə bilər.
Daha əvvəl məqalədə deyildiyi kimi , YugaByte DB-də SQL və ya NoSQL arasında seçim tamamilə əsas iş yükünün xüsusiyyətlərindən asılıdır:
- Əgər əsas iş yükünüz çox açarlı QOŞULMA əməliyyatlarıdırsa, YSQL-i seçərkən, açarlarınızın bir neçə qovşaq arasında yayıla biləcəyini və nəticədə NoSQL-dən daha yüksək gecikmə və/yaxud daha aşağı ötürmə qabiliyyətinə malik ola biləcəyini unutmayın.
- Əks halda, hər dəfə bir qovşaqdan verilən sorğular nəticəsində daha yaxşı performans əldə edəcəyinizi nəzərə alaraq, iki NoSQL API-dən birini seçin. YugaByte DB eyni vaxtda birdən çox iş yükünü idarə etməli olan real mürəkkəb proqramlar üçün vahid əməliyyat bazası kimi xidmət edə bilər.
Növbəti bölmədəki Məlumat modelləşdirmə laboratoriyası orijinal verilənlər bazalarından fərqli olaraq PostgreSQL və Cassandra uyğun YugaByte DB verilənlər bazası API-lərinə əsaslanır. Bu yanaşma, iki fərqli verilənlər bazasının tamamilə müstəqil klasterlərindən istifadə etməkdən fərqli olaraq, eyni verilənlər bazası klasterinin iki fərqli API (iki fərqli portda) ilə qarşılıqlı əlaqənin asanlığını vurğulayır.
Aşağıdakı bölmələrdə biz sözügedən verilənlər bazalarının fərqini və bəzi ümumi cəhətlərini göstərmək üçün Məlumatların Modelləşdirilməsi Laboratoriyasına nəzər salacağıq.
Məlumatların Modelləşdirilməsi Laboratoriyası
Verilənlər bazalarının quraşdırılması
Məlumat modelinin dizaynına (mürəkkəb yerləşdirmə arxitekturaları əvəzinə) diqqəti nəzərə alaraq, verilənlər bazalarını yerli maşında Docker konteynerlərində quraşdıracağıq və sonra müvafiq əmr xətti qabıqlarından istifadə edərək onlarla qarşılıqlı əlaqədə olacağıq.
PostgreSQL və Cassandra uyğun, YugaByte DB verilənlər bazası
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:latestKomanda xəttinə giriş
Müvafiq API-lər üçün əmr xətti qabığından istifadə edərək verilənlər bazasına qoşulaq.
PostgreSQL
PostgreSQL ilə qarşılıqlı əlaqə üçün əmr xətti qabığıdır. İstifadə rahatlığı üçün YugaByte DB birbaşa bin qovluğunda psql ilə gəlir.
docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgresCassandra
CQL (Cassandra Query Language) vasitəsilə Cassandra və onun uyğun verilənlər bazaları ilə qarşılıqlı əlaqə üçün əmr xətti qabığıdır. İstifadə rahatlığı üçün YugaByte DB ilə gəlir cqlsh kataloqda bin.
Qeyd edək ki, CQL SQL-dən ilhamlanıb və oxşar cədvəllər, sətirlər, sütunlar və indekslər anlayışlarına malikdir. Bununla belə, NoSQL dili olaraq o, müəyyən məhdudiyyətlər dəstini əlavə edir, onların əksəriyyətini digər məqalələrdə də əhatə edəcəyik.
docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlshMongoDB
MongoDB ilə qarşılıqlı əlaqə üçün əmr xətti qabığıdır. Onu MongoDB quraşdırmasının bin kataloqunda tapmaq olar.
docker exec -it my-mongo bash
cd bin
mongoCədvəl yaratmaq
İndi komanda xəttini istifadə edərək müxtəlif əməliyyatları yerinə yetirmək üçün verilənlər bazası ilə qarşılıqlı əlaqə qura bilərik. Fərqli sənətçilərin yazdığı mahnılar haqqında məlumatları saxlayan cədvəl yaratmaqla başlayaq. Bu mahnılar albomun bir hissəsi ola bilər. Həmçinin mahnı üçün əlavə atributlar buraxılış ili, qiymət, janr və reytinqdir. Biz "teqlər" sahəsi vasitəsilə gələcəkdə lazım ola biləcək əlavə atributları nəzərə almalıyıq. O, yarı strukturlaşdırılmış məlumatları açar-dəyər cütləri kimi saxlaya bilər.
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
Cassandra-da cədvəl yaratmaq PostgreSQL-ə çox bənzəyir. Əsas fərqlərdən biri bütövlük məhdudiyyətlərinin olmamasıdır (NOT NULL kimi), lakin bu, NoSQL verilənlər bazası deyil, tətbiqin məsuliyyətidir.. Əsas açar bölmə açarından (aşağıdakı misalda Artist sütunu) və qruplaşma sütunları dəstindən (aşağıdakı nümunədə SongTitle sütunundan) ibarətdir. Bölmə açarı cərgənin hansı bölməyə/parçaya qoyulacağını müəyyənləşdirir və qruplaşma sütunları verilənlərin cari parça daxilində necə təşkil edilməli olduğunu göstərir.
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 məlumatları verilənlər bazalarına (Database) təşkil edir (Cassandra-dakı Keyspace-ə bənzər), burada sənədləri (Sənədlər) ehtiva edən kolleksiyalar (Kolleksiyalar) (cədvəllərə bənzər) (cədvəldəki sətirlərə bənzər). MongoDB-də, prinsipcə, heç bir ilkin sxem tərifi tələb olunmur. Komanda "verilənlər bazasından istifadə", aşağıda göstərilən ilk zəngdə verilənlər bazasını yaradır və yeni yaradılmış verilənlər bazası üçün konteksti dəyişir. Hətta kolleksiyaların açıq şəkildə yaradılmasına ehtiyac yoxdur, onlar avtomatik olaraq yeni kolleksiyaya ilk sənəd əlavə edildikdə yaradılır. Nəzərə alın ki, MongoDB standart olaraq test verilənlər bazasından istifadə edir, ona görə də xüsusi verilənlər bazası göstərilmədən istənilən toplama səviyyəsi əməliyyatı defolt olaraq onda yerinə yetiriləcək.
use myNewDatabase;Cədvəl haqqında məlumat əldə etmək
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;Məlumatların cədvələ daxil edilməsi
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
Ümumiyyətlə, ifadə INSERT Cassandra-da PostgreSQL-dəkinə çox bənzəyir. Ancaq semantikada bir böyük fərq var. Kassandrada INSERT əslində əməliyyatdır UPSERT, sətir artıq mövcud olduqda, ən son dəyərlərin sətirə əlavə edildiyi yerdir.
Məlumat girişi PostgreSQL-ə bənzəyir
INSERTyuxarıda
.
MongoDB
MongoDB Cassandra kimi NoSQL verilənlər bazası olsa da, onun məlumat daxiletmə əməliyyatının Cassandra-nın semantik davranışı ilə heç bir əlaqəsi yoxdur. MongoDB-də imkanı yoxdur UPSERT, bu da onu PostgreSQL-ə bənzədir. Olmadan defolt məlumatların əlavə edilməsi _idspecified kolleksiyaya yeni sənədin əlavə olunması ilə nəticələnəcək.
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"
}
}
);
Cədvəl sorğusu
Sorğu baxımından SQL və NoSQL arasındakı ən əhəmiyyətli fərq bəlkə də istifadə edilməsidir FROM и WHERE. SQL ifadədən sonra icazə verir FROM birdən çox cədvəl və ilə ifadə seçin WHERE istənilən mürəkkəblikdə ola bilər (əməliyyatlar da daxil olmaqla JOIN masalar arasında). Bununla belə, NoSQL sərt bir məhdudiyyət qoymağa meyllidir FROM, və yalnız bir müəyyən cədvəllə işləyin və WHERE, əsas açar həmişə göstərilməlidir. Bu, əvvəllər haqqında danışdığımız NoSQL-in performansını yaxşılaşdırmaq istəyi ilə bağlıdır. Bu istək hər hansı çarpaz nişan və çarpaz açar qarşılıqlı əlaqənin mümkün olan hər cür azalmasına gətirib çıxarır. O, sorğuya cavab verərkən qovşaqlararası əlaqədə böyük gecikmə yarada bilər və buna görə də prinsipcə ən yaxşı şəkildə qarşısını almaq olar. Məsələn, Cassandra sorğuların müəyyən operatorlarla məhdudlaşdırılmasını tələb edir (yalnız icazə verilir =, IN, <, >, =>, <=) bölmə açarlarında, ikinci dərəcəli indeksin sorğulanması istisna olmaqla (burada yalnız = operatoruna icazə verilir).
PostgreSQL
Aşağıda SQL verilənlər bazası tərəfindən asanlıqla yerinə yetirilə bilən sorğuların üç nümunəsi verilmişdir.
- Sənətçinin bütün mahnılarını göstərin;
- Başlığın birinci hissəsinə uyğun gələn ifaçının bütün mahnılarını göstərin;
- Başlığında müəyyən söz olan və qiyməti 1.00-dən aşağı olan bütün ifaçının mahnılarını göstərin.
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
Yuxarıda sadalanan PostgreSQL sorğularından yalnız birincisi Cassandra-da dəyişməz işləyəcək, çünki bəyanat LIKE kimi klaster sütunlarına tətbiq edilə bilməz SongTitle. Bu halda yalnız operatorlara icazə verilir = и 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
Əvvəlki nümunələrdə göstərildiyi kimi, MongoDB-də sorğuların yaradılması üçün əsas üsuldur . Bu üsul açıq şəkildə kolleksiyanın adını ehtiva edir (music aşağıdakı nümunədə), buna görə də birdən çox kolleksiyanın sorğulanmasına icazə verilmir.
db.music.find( {
artist: "No One You Know"
}
);
db.music.find( {
artist: "No One You Know",
songTitle: /Call/
}
);Cədvəlin bütün sətirlərinin oxunması
Bütün sətirlərin oxunması əvvəllər müzakirə etdiyimiz sorğu nümunəsinin sadəcə xüsusi halıdır.
PostgreSQL
SELECT *
FROM Music;Cassandra
Yuxarıdakı PostgreSQL nümunəsinə bənzəyir.
MongoDB
db.music.find( {} );Cədvəldəki məlumatların redaktə edilməsi
PostgreSQL
PostgreSQL bir bəyanat təqdim edir UPDATE məlumatları dəyişdirmək üçün. Onun imkanı yoxdur UPSERT, beləliklə, cərgə artıq verilənlər bazasında deyilsə, bu ifadə uğursuz olacaq.
UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';Cassandra
Cassandra var UPDATE PostgreSQL-ə bənzəyir. UPDATE eyni semantikaya malikdir UPSERT, kimi INSERT.
Yuxarıdakı PostgreSQL nümunəsinə bənzəyir.
MongoDB
Əməliyyat MongoDB-də mövcud sənədi tamamilə yeniləyə və ya yalnız müəyyən sahələri yeniləyə bilər. Varsayılan olaraq o, yalnız semantikası deaktiv edilmiş bir sənədi yeniləyir UPSERT. Çoxlu sənədləri və oxşar davranışı yeniləyin UPSERT əməliyyat üçün əlavə bayraqlar təyin etməklə tətbiq oluna bilər. Məsələn, aşağıdakı misalda, müəyyən bir sənətçinin janrı onun mahnısı ilə yenilənir.
db.music.update(
{"artist": "The Acme Band"},
{
$set: {
"genre": "Disco"
}
},
{"multi": true, "upsert": true}
);Cədvəldən verilənlərin silinməsi
PostgreSQL
DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';Cassandra
Yuxarıdakı PostgreSQL nümunəsinə bənzəyir.
MongoDB
MongoDB sənədləri silmək üçün iki növ əməliyyata malikdir - и . Hər iki növ sənədləri silir, lakin fərqli nəticələr verir.
db.music.deleteMany( {
artist: "The Acme Band"
}
);
Cədvəlin silinməsi
PostgreSQL
DROP TABLE Music;Cassandra
Yuxarıdakı PostgreSQL nümunəsinə bənzəyir.
MongoDB
db.music.drop();Nəticə
SQL və NoSQL arasında seçimlə bağlı mübahisə 10 ildən çoxdur ki, davam edir. Bu mübahisənin iki əsas aspekti var: verilənlər bazası mühərrikinin arxitekturası (monolitik, tranzaksiya SQL-ə qarşı paylanmış, qeyri-transaksion NoSQL) və verilənlər bazası dizaynına yanaşma (SQL-də verilənlərin modelləşdirilməsi və NoSQL-də sorğularınızın modelləşdirilməsi).
YugaByte DB kimi paylanmış tranzaksiya verilənlər bazası ilə verilənlər bazası arxitekturası mübahisəsi asanlıqla aradan qaldırıla bilər. Məlumatların həcmi tək bir node üçün yazıla biləndən daha böyük olduqda, avtomatik parçalanma/yenidən balanslaşdırma ilə xətti yazma miqyasını dəstəkləyən tam paylanmış arxitektura zəruri olur.
Məqalələrin birində deyilənlərə əlavə olaraq , əməliyyat, güclü ardıcıl arxitekturalar indi qeyri-transaksiya, nəticədə ardıcıl arxitekturalardan daha yaxşı inkişaf çevikliyini təmin etmək üçün daha geniş şəkildə qəbul edilir.
Verilənlər bazası dizaynının müzakirəsinə qayıdaraq demək ədalətli olar ki, hər iki dizayn yanaşması (SQL və NoSQL) istənilən mürəkkəb real proqram üçün zəruridir. SQL-in “məlumatların modelləşdirilməsi” yanaşması tərtibatçılara dəyişən biznes tələblərinə daha asan cavab verməyə imkan verir, NoSQL-in “sorğu modelləşdirməsi” yanaşması isə həmin tərtibatçılara aşağı gecikmə və yüksək ötürmə qabiliyyəti ilə böyük həcmdə verilənləri idarə etməyə imkan verir. Məhz bu səbəbdən YugaByte DB ümumi bir nüvədə SQL və NoSQL API təmin edir və yanaşmalardan heç birini müdafiə etmir. Bundan əlavə, PostgreSQL və Cassandra da daxil olmaqla məşhur verilənlər bazası dilləri ilə uyğunluğu təmin etməklə, YugaByte DB, paylanmış güclü ardıcıl verilənlər bazası mühərriki ilə işləmək üçün tərtibatçıların başqa dil öyrənmək məcburiyyətində qalmamasını təmin edir.
Bu yazıda verilənlər bazası dizaynının əsaslarının PostgreSQL, Cassandra və MongoDB arasında necə fərqləndiyinə baxdıq. Növbəti məqalələrdə indekslər, əməliyyatlar, JOIN-lər, TTL direktivləri və JSON sənədləri kimi qabaqcıl dizayn konsepsiyalarına nəzər salacağıq.
Sizə gözəl həftə sonu arzulayırıq və sizi dəvət edirik mayın 14-də baş tutacaq.
Mənbə: www.habr.com