Основи на дизайна на бази данни - Сравняване на PostgreSQL, Cassandra и MongoDB

Здравейте приятели. Преди да заминем за втората част на майските празници, споделяме с вас материала, който сме превели в очакване на стартирането на нов поток със скорост "Релационна СУБД".

Разработчиците на приложения прекарват много време в сравняване на множество оперативни бази данни, за да изберат тази, която работи най-добре за тяхното планирано работно натоварване. Нуждите може да включват опростено моделиране на данни, транзакционни гаранции, производителност при четене/запис, хоризонтално мащабиране и толерантност към грешки. Традиционно изборът започва с категорията база данни, SQL или NoSQL, тъй като всяка категория предоставя ясен набор от компромиси. Високата производителност по отношение на ниска латентност и висока производителност обикновено се разглежда като изискване, което не може да бъде компрометирано и следователно е от съществено значение за всяка база данни в извадката.

Целта на тази статия е да помогне на разработчиците на приложения да направят правилния избор между SQL и NoSQL в контекста на моделирането на данни на приложението. Ще разгледаме една SQL база данни, а именно PostgreSQL, и две NoSQL бази данни, Cassandra и MongoDB, за да покрием основите на дизайна на база данни, като създаване на таблици, попълването им, четене на данни от таблица и изтриването им. В следващата статия определено ще разгледаме индекси, транзакции, JOIN, TTL директиви и дизайн на база данни, базиран на JSON.

Каква е разликата между SQL и NoSQL?

SQL базите данни увеличават гъвкавостта на приложенията чрез транзакционни гаранции на ACID, както и тяхната способност да заявяват данни, използвайки JOIN по неочаквани начини в допълнение към съществуващите нормализирани модели на релационни бази данни.

Като се има предвид тяхната монолитна/единична възлова архитектура и използването на модел на репликация главен-подчинен за излишък, на традиционните SQL бази данни липсват две важни характеристики - мащабируемост на линейно записване (т.е. автоматично разделяне между множество възли) и автоматична/нулева загуба на данни. Това означава, че количеството получени данни не може да надвишава максималната производителност на запис на един възел. Освен това трябва да се вземе предвид известна временна загуба на данни за устойчивост на грешки (в несподелена архитектура). Тук трябва да имате предвид, че последните ангажименти все още не са отразени в подчиненото копие. Актуализациите без прекъсване също са трудни за постигане в SQL бази данни.

NoSQL базите данни обикновено са разпределени по природа, т.е. в тях данните са разделени на секции и разпределени в няколко възела. Те изискват денормализиране. Това означава, че въведените данни също трябва да се копират няколко пъти, за да се отговори на конкретните заявки, които изпращате. Общата цел е да се постигне висока производителност чрез намаляване на броя на сегментите, налични по време на четене. Това означава, че NoSQL изисква да моделирате заявките си, докато SQL изисква да моделирате вашите данни.

NoSQL набляга на постигането на висока производителност в разпределен клъстер и това е основната обосновка за много компромиси при дизайна на бази данни, които включват загуба на ACID транзакции, JOIN и последователни глобални вторични индекси.

Има мнение, че въпреки че NoSQL базите данни осигуряват линейна скалируемост на запис и висока устойчивост на грешки, загубата на транзакционни гаранции ги прави неподходящи за критични данни.

Следната таблица показва как моделирането на данни в NoSQL се различава от SQL.

SQL и NoSQL: Защо са необходими и двете?

Реалните приложения с голям брой потребители, като Amazon.com, Netflix, Uber и Airbnb, отговарят за изпълнението на сложни задачи от различни видове. Например, приложение за електронна търговия като Amazon.com трябва да съхранява леки, силно чувствителни данни, като информация за потребители, продукти, поръчки, фактури, заедно с тежки, но по-малко чувствителни данни, като отзиви за продукти, съобщения за поддръжка. , потребителска активност , потребителски отзиви и препоръки. Естествено, тези приложения разчитат на поне една SQL база данни заедно с поне една NoSQL база данни. В междурегионални и глобални системи NoSQL базата данни работи като гео-разпределен кеш за данни, съхранявани в доверен източник, SQL база данни, работеща във всеки един регион.

Как YugaByte DB съчетава SQL и NoSQL?

Изграден върху лог-ориентиран смесен механизъм за съхранение, автоматично шардинг, шардинг разпределена консенсусна репликация и ACID разпределени транзакции (вдъхновени от Google Spanner), YugaByte DB е първата в света база данни с отворен код, която едновременно е съвместима с NoSQL (Cassandra & Redis). ) и SQL (PostgreSQL). Както е показано в таблицата по-долу, YCQL, YugaByte DB API, съвместим с Cassandra, добавя концепциите за ACID транзакции с един и много ключове и глобални вторични индекси към NoSQL API, като по този начин поставя началото на ерата на транзакционните NoSQL бази данни. В допълнение, YCQL, YugaByte DB API, съвместим с PostgreSQL, добавя концепциите за линейно мащабиране на запис и автоматичен отказ към SQL API, предоставяйки на света разпределени SQL бази данни. Тъй като базата данни YugaByte DB е присъщо транзакционна, NoSQL API вече може да се използва в контекста на критични данни.

Както беше посочено по-рано в статията „Представяне на YSQL: Разпределен SQL API, съвместим с PostgreSQL за YugaByte DB“, изборът между SQL или NoSQL в YugaByte DB зависи изцяло от характеристиките на основното работно натоварване:

• Ако основното ви работно натоварване са операции JOIN с множество ключове, тогава когато избирате YSQL, имайте предвид, че вашите ключове може да бъдат разпръснати в множество възли, което води до по-висока латентност и/или по-ниска пропускателна способност от NoSQL.
• В противен случай изберете един от двата NoSQL API, като имате предвид, че ще получите по-добра производителност в резултат на заявки, обслужвани от един възел наведнъж. YugaByte DB може да служи като единна оперативна база данни за реални сложни приложения, които трябва да управляват множество натоварвания едновременно.

Лабораторията за моделиране на данни в следващия раздел е базирана на съвместимите с PostgreSQL и Cassandra API на бази данни YugaByte DB, за разлика от оригиналните бази данни. Този подход подчертава лекотата на взаимодействие с два различни API (на два различни порта) на един и същ клъстер от база данни, за разлика от използването на напълно независими клъстери от две различни бази данни.
В следващите раздели ще разгледаме лабораторията за моделиране на данни, за да илюстрираме разликата и някои от общите черти на въпросните бази данни.

Лаборатория за моделиране на данни

Инсталиране на бази данни

Като се има предвид фокусът върху дизайна на модела на данни (вместо сложните архитектури за внедряване), ние ще инсталираме базите данни в Docker контейнери на локалната машина и след това ще взаимодействаме с тях, използвайки съответните им обвивки на командния ред.

Съвместим с PostgreSQL и Cassandra, база данни YugaByte DB

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

Достъп до командния ред

Нека се свържем с базите данни, като използваме обвивката на командния ред за съответните API.

PostgreSQL

psql е обвивка на командния ред за взаимодействие с PostgreSQL. За по-лесно използване YugaByte DB идва с psql точно в папката bin.

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

Касандра

sqlsh е обвивка на командния ред за взаимодействие с Cassandra и нейните съвместими бази данни чрез CQL (Cassandra Query Language). За по-лесна употреба, YugaByte DB идва с cqlsh в каталога bin.
Имайте предвид, че CQL е вдъхновен от SQL и има подобни концепции за таблици, редове, колони и индекси. Въпреки това, като NoSQL език, той добавя определен набор от ограничения, повечето от които също ще разгледаме в други статии.

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

MongoDB

Монго е обвивка на командния ред за взаимодействие с MongoDB. Може да се намери в директорията bin на инсталацията на MongoDB.

docker exec -it my-mongo bash 
cd bin
mongo

Създаване на таблица

Сега можем да взаимодействаме с базата данни, за да извършваме различни операции, използвайки командния ред. Нека започнем, като създадем таблица, която съхранява информация за песни, написани от различни изпълнители. Тези песни може да са част от албум. Също незадължителни атрибути за песента са година на издаване, цена, жанр и рейтинг. Трябва да вземем предвид допълнителни атрибути, които може да са необходими в бъдеще чрез полето "тагове". Може да съхранява полуструктурирани данни като двойки ключ-стойност.

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 е много подобно на PostgreSQL. Една от основните разлики е липсата на ограничения за интегритет (като NOT NULL), но това е отговорност на приложението, а не на NoSQL базата данни.. Първичният ключ се състои от разделителен ключ (колона „Изпълнител“ в примера по-долу) и набор от колони за групиране (колона „SongTitle“ в примера по-долу). Ключът на дяла определя в кой дял/шард да се постави редът, а колоните за клъстериране показват как трябва да бъдат организирани данните в текущия шард.

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 организира данни в бази данни (Database) (подобно на Keyspace в Cassandra), където има колекции (Collections) (подобно на таблици), които съдържат документи (Documents) (подобно на редове в таблица). В MongoDB по принцип не се изисква първоначална дефиниция на схема. Екип "използване на база данни", показан по-долу, инстанцира базата данни при първото извикване и променя контекста за новосъздадената база данни. Дори колекциите не трябва да се създават изрично, те се създават автоматично, точно когато първият документ се добави към нова колекция. Обърнете внимание, че MongoDB използва тестова база данни по подразбиране, така че всяка операция на ниво събиране без посочване на конкретна база данни ще бъде извършена в нея по подразбиране.

use myNewDatabase;

Получаване на информация за маса
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)

Касандра

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;

Въвеждане на данни в таблица
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}'
);

Касандра

Като цяло изразът INSERT в Cassandra изглежда много подобен на този в PostgreSQL. Има обаче една голяма разлика в семантиката. В Касандра INSERT всъщност е операция UPSERT, където последните стойности се добавят към низа, в случай че низът вече съществува.

Въвеждането на данни е подобно на PostgreSQL INSERT горе

.

MongoDB

Въпреки че MongoDB е NoSQL база данни като Cassandra, нейната операция за въвеждане на данни няма нищо общо със семантичното поведение на Cassandra. В MongoDB вмъкване () няма възможност UPSERT, което го прави подобен на PostgreSQL. Добавяне на данни по подразбиране без _idspecified ще доведе до добавяне на нов документ към колекцията.

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

Заявка за таблица

Може би най-съществената разлика между SQL и NoSQL по отношение на заявките е използването на FROM и WHERE. SQL позволява след израз FROM изберете няколко таблици и израз с WHERE може да бъде с всякаква сложност (включително операции JOIN между маси). NoSQL обаче има тенденция да налага твърдо ограничение на FROMи работят само с една посочена таблица и в WHERE, първичният ключ винаги трябва да бъде посочен. Това се дължи на желанието да се подобри производителността на NoSQL, за което говорихме по-рано. Това желание води до всяко възможно намаляване на всяко взаимодействие между раздели и клавиши. Това може да доведе до голямо забавяне в комуникацията между възлите при отговор на заявка и следователно е най-добре да се избягва като цяло. Например Cassandra изисква заявките да бъдат ограничени до определени оператори (разрешени само =, IN, <, >, =>, <=) на ключове на дялове, освен когато се прави заявка за вторичен индекс (само операторът = е разрешен тук).

PostgreSQL

Следват три примера за заявки, които могат лесно да бъдат изпълнени от SQL база данни.

• Показване на всички песни на изпълнителя;
• Показване на всички песни на изпълнителя, които отговарят на първата част от заглавието;
• Показване на всички песни на изпълнителя, които имат определена дума в заглавието и имат цена под 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;

Касандра

От заявките на PostgreSQL, изброени по-горе, само първата ще работи непроменена в Cassandra, тъй като изразът LIKE не може да се приложи към групиране на колони като SongTitle. В този случай са разрешени само оператори = и 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

Както е показано в предишните примери, основният метод за създаване на заявки в MongoDB е db.collection.find(). Този метод изрично съдържа името на колекцията (music в примера по-долу), така че заявките за множество колекции не са разрешени.

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

Четене на всички редове на таблицата

Четенето на всички редове е само специален случай на модела на заявката, който обсъдихме по-рано.

PostgreSQL

SELECT * 
FROM Music;

Касандра

Подобно на примера за PostgreSQL по-горе.

MongoDB

db.music.find( {} );

Редактиране на данни в таблица

PostgreSQL

PostgreSQL предоставя изявление UPDATE за промяна на данни. Тя няма възможност UPSERT, така че този оператор ще се провали, ако редът вече не е в базата данни.

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

Касандра

Касандра има UPDATE подобно на PostgreSQL. UPDATE има същата семантика UPSERT, като INSERT.

Подобно на примера за PostgreSQL по-горе.

MongoDB
Операция актуализация () в MongoDB може напълно да актуализира съществуващ документ или да актуализира само определени полета. По подразбиране актуализира само един документ с деактивирана семантика UPSERT. Опресняване на множество документи и подобно поведение UPSERT може да се приложи чрез задаване на допълнителни флагове за операцията. Както например в примера по-долу, жанрът на даден изпълнител се актуализира от неговата песен.

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

Премахване на данни от таблица

PostgreSQL

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

Касандра

Подобно на примера за PostgreSQL по-горе.

MongoDB

MongoDB има два вида операции за изтриване на документи − deleteOne() /deleteMany() и Премахване(). И двата вида изтриват документи, но връщат различни резултати.

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

Изтриване на таблица

PostgreSQL

DROP TABLE Music;

Касандра

Подобно на примера за PostgreSQL по-горе.

MongoDB

db.music.drop();

Заключение

Дебатът относно избора между SQL и NoSQL бушува повече от 10 години. Има два основни аспекта на този дебат: архитектурата на двигателя на базата данни (монолитен, транзакционен SQL срещу разпределен, нетранзакционен NoSQL) и подходът към дизайна на базата данни (моделиране на данни в SQL срещу моделиране на вашите заявки в NoSQL).

С разпределена транзакционна база данни като YugaByte DB, дебатът за архитектурата на базата данни може лесно да бъде разсеян. Тъй като обемите данни стават по-големи от това, което може да се запише на един възел, става необходима напълно разпределена архитектура, която поддържа скалируемост на линейно записване с автоматично шардинг/ребалансиране.

В допълнение към казаното в една от статиите Google Cloud, транзакционните, силно последователни архитектури сега са по-широко възприети, за да осигурят по-добра гъвкавост на разработката, отколкото нетранзакционните, в крайна сметка последователни архитектури.

Връщайки се към дискусията за дизайна на базата данни, справедливо е да се каже, че и двата подхода за проектиране (SQL и NoSQL) са необходими за всяко сложно приложение в реалния свят. Подходът на SQL за „моделиране на данни“ позволява на разработчиците по-лесно да отговарят на променящите се бизнес изисквания, докато подходът на NoSQL за „моделиране на заявки“ позволява на същите тези разработчици да обработват големи количества данни с ниска латентност и висока производителност. Поради тази причина YugaByte DB предоставя SQL и NoSQL API в общо ядро ​​и не препоръчва нито един от подходите. В допълнение, чрез осигуряване на съвместимост с популярни езици за бази данни, включително PostgreSQL и Cassandra, YugaByte DB гарантира, че разработчиците не трябва да учат друг език, за да работят с разпределена силно последователна база данни.

В тази статия разгледахме как се различават основите на дизайна на бази данни между PostgreSQL, Cassandra и MongoDB. В следващите статии ще се потопим в концепции за усъвършенстван дизайн като индекси, транзакции, JOIN, TTL директиви и JSON документи.

Пожелаваме ви страхотен уикенд и ви каним безплатен уеб семинаркойто ще се проведе на 14 май.

Източник: www.habr.com