Тра­дици­онно все сущес­тву­ющие СУБД делят на два клас­са: реляци­онные и нереля­цион­ные (Relational, NoSQL). В свою оче­редь, нереля­цион­ные СУБД мож­но раз­делить еще на 15 катего­рий — по моделям хра­нения дан­ных.

Для упро­щения нашей задачи есть смысл каж­дую из этих катего­рий отнести к СУБД обще­го или спе­циаль­ного наз­начения. Тер­миноло­гия неофи­циаль­ная — она исполь­зует­ся прос­то для понима­ния того, что СУБД спе­циаль­ного наз­начения будут хорошим выбором, если есть соот­ветс­тву­ющий зап­рос. Нап­ример, если пред­сто­ит мно­го работать с вре­мен­ными рядами или коор­дината­ми.

Сто­ит отме­тить, что сегод­ня мно­гие популяр­ные СУБД под­держи­вают муль­тимодель­ное пред­став­ление дан­ных, то есть их мож­но отнести сра­зу к нес­коль­ким катего­риям. Более того, пос­коль­ку мно­гие про­екты активно раз­вива­ются, в них добав­ляет­ся под­дер­жка все новых фун­кций и воз­можнос­тей, в резуль­тате чего они ста­новят­ся все боль­ше похожи друг на дру­га.

Так, сегод­ня мно­жес­тво NoSQL СУБД име­ют под­дер­жку и JOIN, и GROUP BY, и дру­гих SQL-зап­росов. Некото­рые авто­ры любят упо­минать, что NoSQL на самом деле озна­чает Not Only SQL («не толь­ко SQL») — это час­то интер­пре­тиру­ют как «боль­ше, чем SQL». При­нято счи­тать, что NoSQL — все­го лишь некое рас­ширение для име­юще­гося по умол­чанию SQL. На самом деле это не сов­сем так, и пра­виль­нее было бы перевес­ти наз­вание этой тех­нологии как что‑то вро­де «не SQL еди­ным».

Под­дер­жка син­такси­са SQL некото­рыми NoSQL-про­екта­ми — это при­обре­тен­ная фун­кция, а изна­чаль­но такие СУБД про­екти­рова­лись сов­сем для дру­гих целей. Нап­ример, пов­семес­тное исполь­зование JOIN в докумен­тоориен­тирован­ной СУБД — не самое эффектив­ное решение. Поэто­му мы будем делить СУБД на катего­рии сог­ласно пер­вичной модели дан­ных.

Дополнительные критерии

Кро­ме пер­вичной модели хра­нения дан­ных, при выборе СУБД сто­ит обра­тить вни­мание и на дру­гие парамет­ры.

Вторичные модели хранения данных

Мно­гие сов­ремен­ные СУБД под­держи­вают нес­коль­ко моделей хра­нения дан­ных. Нап­ример, в PostgreSQL, MySQL и дру­гих рас­простра­нен­ных СУБД мож­но соз­давать отдель­ные кол­лекции для хра­нения докумен­тов в фор­мате JSON, что поз­воля­ет сох­ранять дан­ные уже сей­час, а со схе­мой хра­нения раз­бирать­ся потом. А боль­шинс­тво рас­простра­нен­ных ком­мерчес­ких СУБД под­держи­вают работу с прос­транс­твен­ными дан­ными. Ком­бинации моделей хра­нения могут быть совер­шенно про­изволь­ными.

Поддерживаемые языки программирования

Что­бы не обре­кать себя на поиск обходных путей и прик­ручива­ние кос­тылей, луч­ше сра­зу убе­дить­ся, что СУБД под­держи­вает выб­ранный тобой язык прог­рамми­рова­ния.

Методы репликации

Реп­ликация дан­ных в реаль­ном вре­мени спа­сет нас в слу­чае потери основной базы дан­ных, а так­же поможет рас­пре­делить наг­рузку за счет перено­са час­ти зап­росов на реп­лики.

На уров­не СУБД реп­ликация может быть физичес­кой или логичес­кой.

Фи­зичес­кая реп­ликация осно­выва­ется на том, что опе­рации, содер­жащи­еся в логах БД, выпол­няют­ся на реп­ликах. Реп­ликация может быть син­хрон­ной или асин­хрон­ной.

Асин­хрон­ный метод отли­чает­ся тем, что всег­да есть набор тран­закций, завер­шенных на основной базе, но еще не дошед­ших до резер­вной. В слу­чае перехо­да на резер­вную базу при сбое основной эти тран­закции будут потеря­ны. Этот метод подой­дет, если для нас про­изво­дитель­ность име­ет мак­сималь­ный при­ори­тет. При син­хрон­ной реп­ликации завер­шение опе­рации commit озна­чает, что все отно­сящи­еся к этой тран­закции жур­наль­ные записи переда­ны на реп­лику. Если реп­лика не отве­чает, commit на основной базе не завер­шает­ся. Это пра­виль­ный выбор, если в при­ори­тете сох­ранность и защита дан­ных.

В слу­чае же, ког­да в мак­сималь­ном при­ори­тете дос­тупность дан­ных, мож­но нас­тро­ить режим син­хрон­ной реп­ликации. Но если реп­лика не отве­чает, то реп­ликация перек­люча­ется в асин­хрон­ный режим, а как толь­ко связь вос­ста­нав­лива­ется — реп­лика сра­зу обновля­ется до акту­аль­ного сос­тояния.

Ло­гичес­кая реп­ликация — это ког­да изме­нения в БД про­исхо­дят в резуль­тате вызовов ее API, нап­ример в ходе выпол­нения SQL-зап­росов.

Поддержка MapReduce API

Ес­ли база дан­ных хра­нит информа­цию в рас­пре­делен­ной сре­де, то есть дан­ные раз­делены и содер­жатся на нес­коль­ких узлах, то наличие API для MapReduce поз­воля­ет выпол­нять вычис­ления MapReduce непос­редс­твен­но на дан­ных внут­ри базы без необ­ходимос­ти извле­кать их наружу. Основная идея MapReduce зак­люча­ется в рас­пре­деле­нии решения задачи на мно­жес­тво узлов, где каж­дый узел выпол­няет локаль­ные вычис­ления, а затем резуль­таты агре­гиру­ются и объ­еди­няют­ся для получе­ния окон­чатель­ного ито­га. Это сок­раща­ет вре­мя переда­чи дан­ных меж­ду узла­ми и повыша­ет про­изво­дитель­ность.

Концепции согласованности в распределенных БД

В кон­тек­сте рас­пре­делен­ных сис­тем сог­ласован­ность дан­ных име­ет осо­бое зна­чение из‑за воз­можнос­ти сущес­тво­вания нес­коль­ких реп­лик дан­ных или узлов, которые могут изме­нять дан­ные асин­хрон­но. Задача сос­тоит в том, что­бы гаран­тировать, что дан­ные син­хро­низи­рова­ны и сог­ласова­ны на всех узлах сис­темы в опре­делен­ный момент вре­мени. Сог­ласован­ность дан­ных быва­ет сле­дующих типов.

Сла­бая сог­ласован­ность (Weak Consistency): при сла­бой сог­ласован­ности сис­тема не гаран­тиру­ет мгно­вен­ное рас­простра­нение изме­нений и сог­ласован­ное сос­тояние дан­ных меж­ду узла­ми. Вмес­то это­го сис­тема может допус­кать вре­мен­ные рас­хожде­ния или кон­флик­ты дан­ных. Это обес­печива­ет высокую дос­тупность и мас­шта­биру­емость в рас­пре­делен­ных сис­темах, но может при­водить к несог­ласован­ности дан­ных в опре­делен­ных ситу­ациях.

Силь­ная сог­ласован­ность (Strong Consistency): при силь­ной сог­ласован­ности сис­тема гаран­тиру­ет, что дан­ные всег­да находят­ся в сог­ласован­ном сос­тоянии меж­ду раз­личны­ми узла­ми в сис­теме. Это озна­чает, что любое чте­ние дан­ных будет учи­тывать пос­ледние изме­нения, сде­лан­ные в сис­теме. Час­то для дос­тижения силь­ной сог­ласован­ности тре­бует­ся допол­нитель­ное вре­мя и ресур­сы.

Пос­ледова­тель­ная сог­ласован­ность (Sequential Consistency): при пос­ледова­тель­ной сог­ласован­ности сис­тема гаран­тиру­ет, что все опе­рации записи и чте­ния будут выпол­нять­ся в стро­гом поряд­ке, как буд­то они осу­щест­вля­ются пос­ледова­тель­но. Это озна­чает, что резуль­таты опе­раций будут соот­ветс­тво­вать некото­рому линей­ному поряд­ку, незави­симо от парал­лель­нос­ти их выпол­нения.

При­час­тная сог­ласован­ность (Eventual Consistency): это свой­ство озна­чает, что при отсутс­твии новых обновле­ний дан­ные в ито­ге будут сог­ласова­ны. В этом слу­чае база дан­ных не гаран­тиру­ет мгно­вен­ной сог­ласован­ности меж­ду копи­ями дан­ных, но с течени­ем вре­мени все копии будут сог­ласова­ны. Это обыч­но дос­тига­ется путем асин­хрон­ного рас­простра­нения обновле­ний и их сли­яния на раз­ных узлах базы дан­ных.

Ка­узаль­ная сог­ласован­ность (Causal Consistency): в этом режиме база дан­ных гаран­тиру­ет, что если опе­рация A зависит от опе­рации B, то опе­рация A будет учи­тывать резуль­таты опе­рации B или более поз­дние резуль­таты. Это обес­печива­ет сог­ласован­ность дан­ных с уче­том их при­чин­но‑следс­твен­ных свя­зей.

Концепции транзакций

Кон­цепции тран­закций обес­печива­ют ато­мар­ность, сог­ласован­ность (в кон­тек­сте тран­закций «сог­ласован­ность» име­ет дру­гое зна­чение), изо­лиро­ван­ность и дол­говеч­ность опе­раций. Одной из кон­цепций тран­закций в базах дан­ных явля­ется ACID (Atomicity, Consistency, Isolation, Durability). ACID — это клас­сичес­кий набор свой­ств тран­закций в базах дан­ных:

• 
  

• Ато­мар­ность (Atomicity) гаран­тиру­ет, что тран­закция либо выпол­няет­ся пол­ностью, либо не выпол­няет­ся сов­сем. Если одна опе­рация в тран­закции не уда­лась, то все пре­дыду­щие опе­рации отме­няют­ся (отка­тыва­ются) и сос­тояние базы дан­ных воз­вра­щает­ся к исходно­му.

• 
  

• Сог­ласован­ность (Consistency) гаран­тиру­ет, что пос­ле завер­шения тран­закции база дан­ных оста­ется в сог­ласован­ном сос­тоянии. Тран­закция дол­жна соб­людать пре­доп­ределен­ные пра­вила целос­тнос­ти дан­ных.

• 
  

• Изо­лиро­ван­ность (Isolation) озна­чает, что одна тран­закция не видит изме­нений, вне­сен­ных дру­гими тран­закци­ями, до тех пор, пока эти изме­нения не будут зафик­сирова­ны (committed). Это пре­дот­вра­щает кон­флик­ты и обес­печива­ет парал­лель­ность выпол­нения тран­закций.

• 
  

• Дол­говеч­ность (Durability) гаран­тиру­ет, что пос­ле успешно­го завер­шения тран­закции ее изме­нения сох­раня­ются даже в слу­чае сбо­ев сис­темы или отклю­чения питания. Изме­нения дол­жны быть сох­ранены в пос­тоян­ном хра­нили­ще, что­бы они мог­ли быть вос­ста­нов­лены при необ­ходимос­ти.

• 
  

Дру­гая кон­цепция называ­ется BASE (Basically Available, Soft state, Eventually consistent). Она отли­чает­ся от ACID и обыч­но исполь­зует­ся в рас­пре­делен­ных сис­темах, где в при­ори­тете высокая дос­тупность и мас­шта­биру­емость, а сог­ласован­ность может быть нес­тро­гой.

• 
  

• Basically Available (основная дос­тупность) озна­чает, что сис­тема дол­жна быть всег­да дос­тупна для опе­раций, даже в слу­чае сбо­ев или раз­деления сети. Это поз­воля­ет обес­печить высокую дос­тупность сис­темы.

• 
  

• Soft state (мяг­кое сос­тояние) допус­кает вре­мен­ную несог­ласован­ность дан­ных в сис­теме. В слу­чай­ный момент вре­мени дан­ные на раз­ных узлах могут ока­зать­ся в некон­систен­тном сос­тоянии.

• 
  

• Eventually consistent (в конеч­ном сче­те сог­ласован­ный) озна­чает, что хотя в какой‑то момент вре­мени дан­ные могут быть несог­ласован­ными, при отсутс­твии обновле­ний они все же при­дут в сог­ласован­ное сос­тояние либо сами по себе, либо с помощью какого‑либо механиз­ма сог­ласова­ния.

• 
  

Возможность работы с данными в оперативной памяти

Эта полез­ная опция раз­реша­ет хра­нить некото­рые или вооб­ще все дан­ные в опе­ратив­ной памяти, которая, как извес­тно, гораз­до быс­трее пос­тоян­ной.

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

Теги: CSS