BASE vs ACID

6.1 Муборизаи ихтисорот: BASE vs. ACID

Дар кимиё, pH сатҳи кислотаи нисбии маҳлули обиро чен мекунад.
Шкалаи pH аз 0 (маводи хеле кислота) то 14 (маводи хеле ишкоратор) меояд;
оби тоза дар ҳарорати 25°C pH 7 дорад ва бетараф аст.

Муҳандисҳо ин метафораро гирифта, базаҳои маълумотро аз рӯи боэътимодии транзаксияҳо муқоиса карданд.
Чӣ қадар базаи маълумот ба "ишкоратор" ("BASE") наздик бошад, он қадар камтар боэътимод мебошанд транзаксияҳо.

Базаҳои маълумоти реляционии машҳур, ба монанди MySQL, дар заминаи ACID пайдо шуданд. Дар даҳсолаи охир, базаҳои маълумоти NoSQL пайдо шуданд, ки якчанд намуди базаҳои маълумотро муттаҳид мекунанд. Онҳо бе ACID ҳам хуб кор мекунанд. Бисёре аз таҳиягарон бо NoSQL кор мекунанд ва дар бораи транзаксияҳо ва боэътимодии онҳо фикр намекунанд. Биёед бубинем, оё онҳо дурустанд.

Дар бораи NoSQL дар умум сухан гуфтан мумкин нест, зеро ин танҳо як абстраксияи муваффақ аст. Базаҳои маълумоти NoSQL аз якдигар фарқ мекунанд, дар тарҳбандии зерсистемаҳои нигоҳдории маълумот ва моделҳои маълумот: масалан, CouchDB документо-ориентирована ва Neo4J графовая. Аммо, агар дар контексти транзаксияҳо дар бораи онҳо сухан гӯем, онҳо одатан дар як ҷиҳат ба ҳам монанданд: онҳо нусхаҳои маҳдуди атомарият ва изоляцияро пешниҳод мекунанд, ва ин маънои онро дорад, ки онҳо кафолатҳои ACID-ро намедиҳанд. Барои фаҳмидани ин, биёед бубинем, ки онҳо чӣ пешниҳод мекунанд, агар на ACID? Ҳеҷ чиз?

Не, на ҳама. Ҳамчунин бояд худро дар шакли ҷолиб фурӯшанд. Онҳо номи ихтисории худро ихтироъ карданд - BASE.

6.2 BASE ҳамчун антагонист

Ва ин ҷо ман боз дар бораи ҳарфҳо на дар тартиби, балки аз истилоҳи асосии - consistency оғоз мекунам. Ин истилоҳ дар амал бо тавофуқе, ки дар ACID аст, каме ҳаммаъно аст. Масъала дар он аст, ки он дар бисёр контекстҳо корбаст мешавад. Аммо ин тавофуқ дар истифодаи васеътаре дорад ва маҳз ҳамон тавофуқе, ки дар бораи системаҳои тақсимшуда сухан меравад.

Базаҳои маълумоти реляционӣ, ки мо дар боло дар бораи онҳо сухан кардем, дараҷаҳои гуногуни изоляцияи транзаксияҳоро пешниҳод мекунанд. Строгترین онҳо кафолат медиҳанд, ки як транзаксия дигар транзаксияҳо гирифтани тағйироти нодурустро намебинад.

Масалан, агар шумо дар кассаи мағоза истода бошед, ва дар ин вақт аз ҳисоби шумо маблағ барои пардохти манзил бароварда шавад, аммо транзаксияи интиқоли пул барои пардохти манзил ноком шавад, ва ҳисоби шумо дубора ба арзиши пешина баргардад (маблағ кам намешавад), пас транзаксияи пардохти шумо дар касса ҳама ин ҳаракатҳоро намебинад. Ин ба он вобаста аст, ки мувофиқи талаботи изоляцияи транзаксияҳо, тағйироти муваққатӣ дар транзаксияи нодуруст аз ҷониби транзаксияҳои дигар дидан мумкин нест.

Бисёри базаҳои NoSQL кафолати изоляцияро тарк мекунанд ва «тавофуқи дар натиҷа» (eventual consistency)-ро пешниҳод мекунанд, ки мувофиқи он дар ниҳоят шумо маълумоти дурустро хоҳед гирифт, аммо имкон дорад, ки транзаксияи шумо арзишҳои нодуруст хонда шавад - яъне, муваққатӣ, қисман навшуда ё кӯҳнашуда. Шояд, ки маълумот дар реҷаи «танбал» ҳангоми хондан тавофуқ ёбад ("lazily at read time").

NoSQL барои таҳлили дар вақти воқеӣ таҳия шуда буд, ва барои ноил шудан ба суръати бештар, онҳо ба тавофуқ қурбон карданд. Эрик Бривер, ҳамон шахсе, ки истилоҳи BASE-ро ихтироъ кардааст, CAP-теоремаро баён кардааст, ки мувофиқи он:

Барои ҳар кадом татбиқ аз ҳисобҳои тақсимшуда, имкон дорад ки на бештар аз ду аз се хусусиятҳои зеринро таъмин кунад:

• тавофуқи маълумот (consistency) — маълумот дар узлҳо (instances) гуногун аз якдигар зид намебошанд;
• дастрасӣ (availability) — ҳар як дархост ба системаи тақсимшуда бо ҷавоби дуруст анҷом меёбад, аммо бе кафолат, ки ҷавобҳои ҳама узлҳо системаи зидди якдигар намебошанд;
• устуворӣ ба ҷудошавӣ/тақсимшавӣ (partition tolerance) — Ҳатто агар байни узлҳо робита набошад, онҳо ба таври мустақил кор карданро идома медиҳанд.

Агар ба шумо фаҳмиш дар бораи CAP лозим бошад, ин аст:

Мавҷуданд ақидаҳое, ки теоремаи CAP кор намекунад ё қонеъкунанда баён нашудааст. Бо вуҷуди ин, базаҳои маълумоти NoSQL аксар вақт мувофиқатро дар доираи теоремаи CAP тарк мекунанд. Ин маънои онро дорад, ки маълумот дар якчанд экземпляри кластёр нав карда шудаанд, аммо тағйирот ҳанӯз дар ҳама экземплярҳояш синхронизатсия нашудааст. Масалан, DynamoDB метавонад хабар диҳад: тағйироти шумо шуданд durable, ва шумо HTTP 200 гирифтед, аммо тағйирот танҳо дар 10 сония ба назар мерасиданд. Другой пример из повседневной жизни разработчика – это система доменных имён (DNS), которая преобразует http(s)-адреса в IP-адреса.

Запись DNS, ки обновлена шудааст мувофиқи танзимоти интервалҳои кэш пешакӣ мешавад, бинобар ин, обновления намоён намешаванд тамме. Таким образом, временная несогласованность (которая в конечном счёте приводит к согласованности) может произойти и в кластере реляционной базы данных (например, MySQL), поскольку эта согласованность не связана с понятием ACID. Поэтому важно понимать, что в этом смысле SQL и NoSQL вряд ли будут значительно отличаться, если речь идёт о нескольких экземплярах в кластере.

Помимо это, согласованность в конечном счёте означает, что запросы на запись будут осуществлены не в порядке поступления: то есть, все данные будут записаны, но значение, которое будет принято в конечном счёте, не будет тем, что поступило последним в очередь на запись.

Базаҳои маълумоти NoSQL, ки кафолатҳои ACID-ро намедиҳанд, "ҳолати мулоим" (“soft state”) доранд бинобар модели согласованности в конечном счёте. Ин маънои онро дорад, ки ҳолати система метавонад бидуни маълумоти воридотӣ тағйир ёбад. Аммо чунин системаҳо мекӯшанд, ки дастрасии баландтареро, ки "дастрасии асосӣ" номида мешавад, таъмин кунанд. Ин се мафҳум - "дастрасии асосӣ" ("basically available"), "ҳолати мулоим" ("soft state") ва "тавофуқи дар натиҷа" ("eventual consistency") - ихтисори BASE-ро ташкил медиҳанд. Але это больше пустая маркетинговая обёртка, чем ACID, и может запутать разработчиков. Поэтому лучше вернуться к понятию изоляции.

6.3 Получается, базы данных BASE совсем не выполняют критерии ACID?

Дар асоси фарқияти базаҳои маълумоти ACID аз базаҳои маълумоти не-ACID он аст, ки не-ACID аз изоляция даст мекашанд. Муҳим аст, ки инро фаҳмидан. Аммо боз ҳам муҳимтар аст, ки ҳуҷҷатгузорӣ хонед ва онҳоро санҷидан, ҳамон тавр ки лоиҳаи Hermitage онро мекунад. Новобаста аз он, ки чӣ гуна офарида худи ё дигар базаи маълумот худро меномад - ACID ё BASE, CAP ва ё на CAP. Муҳим аст, ки базаи маълумот чӣ таъмин мекунад.

Агар офаридгорони базаи маълумот мегӯянд, ки он кафолатҳои ACID таъмин мекунад, пас шояд ба ин асосҳо дошта бошад. Аммо беҳтар аст, ки худи худро санҷидан, ки то чӣ андоза ин дуруст аст ва дар кадом дараҷа. Агар онҳо мегӯянд, ки базаи маълумоти онҳо чунин кафолатҳо надорад, ин метавонад маънои чизҳои гуногунро дошта бошад.

• Базаи маълумоти атомариятро кафолат намедиҳад. Однако некоторые базы данных NoSQL предоставляют отдельный API для атомарных операций (например, DynamoDB).
• Базаи маълумоти изоляцияро кафолат намедиҳад. Ин метавонад маънои онро дошта бошад, ки маълумот метавонад ба тартиби дигар, на аломати навсозӣ навишта шавад.

Для сравнения различных баз данных по гарантии durability нужно знать, какие структуры данных используются для хранения и извлечения данных. Некоторые из них позволяют быстрее записывать данные, другие – быстрее читать. Но нельзя обще сказать, что определенные структуры данных делают durability выше или ниже.

6.4 Чӣ тавр базаҳои маълумоти гуногун маълумотро индекс мекунанд, ва чӣ гуна ин ба durability таъсир мерасонад, ва на танҳо

Существует два основных подхода к хранению и поиску данных.

Барои нигоҳдории маълумот амалҳои замимаро дар охири файл истифода мебаранд, зеро ҳама амалҳои CRUD ба журнал навишта мешаванд. Для быстрого поиска используется индекс - структура данных, которая хранит метаданные. Самым простым индексом является хэш-таблица, которая связывает ключ и значение. Значения - это смещения данных в файле-журнале, который хранится на диске. Эта структура данных называется LSM-деревом и хранится в памяти, а данные на диске.

Возможно, вы спросили себя: если мы записываем действия в журнал, не будет ли он слишком большим? Да, поэтому была придумана техника сжатия ("compaction") для удаления или оставления лишь самого актуального значения для каждого ключа. Если мы будем использовать несколько журналов, отсортированных на диске, то создадим структуру данных, известную как SSTable («sorted string table»), что повысит производительность. Если же мы попытаемся сортировать данные в памяти, то получим так называемую таблицу MemTable. Но данные, записанные позже всего (находящиеся в MemTable, но еще не записанные на диск), будут потеряны при фатальном сбое базы. Вот и проблема с durability у базы данных, основанных на LSM-деревьях.

Другой подход к индексации основывается на B-деревьях («B-trees»). В B-дереве данные записываются на диск в блоках фиксированного размера. Эти блоки данных имеют размер около 4 КБ и содержат пары ключ-значение, отсортированные по ключу. Каждый узел B-дерева представляет собой массив со ссылками на диапазон страниц. Максимальное количество ссылок в массиве называется фактором ветвления. Каждый диапазон страниц является другим узлом B-дерева со ссылками на другие диапазоны страниц.

В конце концов, на уровне листа вы найдете отдельные страницы. Эта идея похожа на указатели в языках программирования низкого уровня, за исключением того, что эти ссылки на страницы хранятся на диске, а не в памяти. Когда происходят INSERTs и DELETEs, то некоторые узлы могут быть разделены на два поддерева, чтобы соответствовать коэффициенту ветвления. Если база данных по какой-либо причине выйдет из строя в середине процесса, то целостность данных может быть нарушена.

Чтобы предотвратить такое, использующие B-деревья базы ведут журнал упреждающей записи («write-ahead log», или WAL), в котором записывается каждая транзакция. Этот WAL используется для восстановления состояния B-дерева в случае его повреждения. Поэтому можно сказать, что использующие B-деревья базы лучше в плане durability. Однако и базы данных на основе LSM могут вести файл, который выполняет похожую функцию, как WAL. Поэтому следует внимательно изучить механизмы работы выбранной базы.

О B-деревьях мумкин аст гуфт, ки онҳо барои транзакционность мувофиқанд: ҳар як калид дар индексе танҳо як маротиба мебарояд, дар ҳоле ки дар подсистемаҳои нигоҳдорӣ бо журналҳо метавонад якчанд нусхаи як калид дар сегментҳои гуногун (масалан, то иҷрои нави кам кардани нав) бошад.

Тарҳрезии индекси база ба иқтидори базаи маълумот таъсир мерасонад. Сабт ба диск пайдарпай дар LSM-ҷенге анҷом ёфта, дар B-деревьях дастрасии тасодуфии зиёдеро талаб мекунад. Ин сабаб мешавад, ки сабт дар LSM тезтар аст, нисбат ба B-деревьях, хусусан дар дискҳои сахт (HDD). Чтение же выполняется медленнее на LSM-деревьях, потому что нужно просматривать несколько структур данных и SS-таблиц. При простом запросе к базе данных с LSM мы сначала ищем ключ в MemTable, а затем последовательно просматриваем каждую SSTable. Если ключ не существует, то мы это узнаем последней.

LSM-деревьях в:

• LevelDB
• RocksDB
• Cassandra
• HBase

Я так подробно описываю это всё, чтобы вы поняли, какие вещи нужно учитывать при выборе базы данных: например, больше писать или читать данные. Также необходимо рассмотреть различия в моделях данных (нужно ли делать обход данных, как позволяет графовая модель? Есть ли какие-то отношения между различными единицами данных? Нужно ли использовать при записи или чтении данных разные схемы?) и стойкость данных. Любая база данных, записывающая на диск, может предоставить хорошие гарантии стойкости данных, но нужно проанализировать каждую базу отдельно.

6.5 Чӣ тавр кор мекунанд in-memory DB

Аз ҷиҳати дигар, илова бар он базаҳои маълумоте, ки ба диск менависанд, инчунин базаҳои дар хотира буда, баъзан "in-memory" номида мешаванд. Онҳо асосан бо RAM кор мекунанд ва барои дастрасии қавитар ба суръати баланди сабт ва хондан пешниҳод мекунанд. Ин метавонад барои бисёре аз барномаҳо, ки вақти ҷавоб муҳим аст, муфид бошад. Масалан, ин метавонад барои дархостҳои ҷустуҷӯӣ ё таҳлили маълумоти бузург ҳангоми дастури зуд истифода шавад.

Ҳодиса дар он аст, ки хотираи RAM дарозмуддат гаронтар аз дискҳо буд, аммо дар зери солҳои наздик арзонтар шуд. Ин ба пайдоиши нави базаҳои маълумот, бо хондан ва навиштани зуд аз RAM, оварда расонд. Савол: пас чӣ гуна бо нигоҳдории маълумот дар ин базаҳо кор мекунад? Таҳиягарон барои таъмини нигоҳдорӣ механизмҳои гуногун пешниҳод мекунанд.

• Истифодаи хотираи воқеӣ, ки аз аккумуляторҳо ғизо мегирад.
• Ба диск журнали тағйиротро навиштан (масалан, чунин ки WAL, ки дар боло зикр шудаанд), аммо худи маълумотро не.
• Периодически записывать на диск копии состояния базы данных (что без использования других опций не даёт гарантий, а лишь улучшает надёжность);
• Реплицировать состояние оперативной памяти на другие машины.

Например, базаи маълумоти Redis дар хотираи воқеият, ки одатан ҳамчун қаторҳои паёмҳо ё кэш истифода мешавад, нигоҳдории дарозмуддати ACID-ро таъмин намекунад: он кафолат намедиҳад, ки фармони муваффақона иҷрошуда дар диск нигоҳодорӣ мешавад, зеро Redis маълумотро ба диск (агар ин фаъол карда шуда бошад) танҳо асинхронӣ, периодически нигоҳ мекунад.

Однако не для всех приложений это важно. Например, EtherPad - онлайн-редактор для коллективного использования - делал flush раз в 1-2 секунды. Это могло привести к потере нескольких букв или слов, но это не критично. Redis хорош тем, что предоставляет модель данных, которую трудно реализовать с помощью дисков. Она также позволяет выполнять транзакции через свою очередь по приоритетам.