Пераклад на беларускую мову Patricia Clausnitzer
Сярод альтэрнатыўных СКБД (ака NoSQL) залёгка згубіць з вачэй той факт, што чым больш усталяваных рашэнняў, такіх як рэляцыйныя базы дадзеных, па-ранейшаму ёсць што прапанаваць: стабільны і правераны код базы, драйвераў і прылад для разнастайных моў і функцый больш, чым для DBA. Не кажучы ўжо пра тое, што рэляцыйныя яны ці няма, яны часта выконваюць гэтак жа, як любая іншая інстанцыя "ключ-значэнне, калі сутыкаюцца з вялікімі аб'ёмамі дадзеных - адгэтуль і чыннік таго, што Riak, Voldemort і іншыя выкарыстоўваюць InnoDB у якасці сховішча дадзеных. Вядома, "атлусценне" з'яўляецца чыннікам таго, што перазапіс можа быць добрай ідэяй, але, адчуваецца, што гэта "шэрая зона" занадта часта ігнаруецца ў супольнасці NoSQL - проста таму, што "NoSQL" не азначае, што трэба выкінуць рэляцыйныя базы дадзеных.
Калі пакінуць убаку той факт, што нам яшчэ мае быць вызначыць, што такое "NoSQL", насамрэч, некаторыя з атрыбутаў, якія мы звычайна абагульняем пад гэтым знакам: дакумент, заснаваны на схемах, вольных, размеркаваных і "якія маштабуюцца". Той факт, што распаўсюджваецца і якое маштабуецца - гэта не адно і тое ж (пытанне для іншага паста). Давайце ўважлівей паглядзім на тое, што схемы, вольныя і заснаваныя на дакументах, азначаюць насамрэч. Я жадаў бы трохі забегчы наперад: Я шчыра здзіўлены, што нам яшчэ мае быць убачыць схемы, пабудаваныя на аснове MySQL. Я ведаю, ведаю, але не паверыце ў другі раз, таму што гэта не так абуральна, як здаецца.
Падстава дакументаў: падвойны меч
Асноўны чыннік для зацікаўленасці ў рэляцыйнай мадэлі - тое, што, абмяжоўваючы схемы дадзеных (чытанне, ухіленні структурных складанасцяў дадзеных), вы ўзмацняеце моц і гнуткасць у запытаў, якія можна выканаць у стаўленні базы дадзеных. Інакш кажучы, нармаваныя праектныя дадзеныя дазваляюць нам атрымліваць мова запытаў агульнага прызначэння, што дазваляе выкарыстоўваць запыты, параметры, якія мы нават не ведаем на этапе праектавання, у той час як нестандартных канструкцый няма. Тое, што мы губляем у гнуткасці нашых структур дадзеных, мы атрымліваем у нашай здольнасці ўзаемадзейнічаць з дадзенымі. Такім чынам, у тэорыі, калі ў вас няма магчымасці прагназаваць тыпы запытаў, у будучыні рэляцыйная мадэль - лепшы выбар. У чымсьці прайграваеце, у чымсьці выйграяце!
У той жа час, мы ўсё ведаем, што "не далучыцца хутчэй, чым не ўступаць". Першапачатковы недахоп - разбіўка вашых дадзеных, неабходных для зборкі. Калі вы гоніцеся за "хуткасцю" ці "маштабаванасцю", а затым дэнармалізацыяй дадзеных, як правіла, гэта першы крок. Недахоп? Зараз вы ўнеслі патэнцыйныя анамаліі ў вашы дадзеныя: абнаўленні, устаўкі і выдаленні могуць прывесці да канфлікту дадзеных, калі вы ўлічваеце ўсе дубляванні. Адзін-на-адзін, і адзін-да-шматлікім адносінам, як правіла, простыя ў кіраванні, але шматлікія-да-шматлікім у нестандартным схемам не што іншае, дакладны шлях да катастрофы. Калі вы клапоціцеся о узгодненасці.
Нарэшце, паколькі вы губляеце сілу агульнай мовы запытаў прызначэння (SQL), то ў наш час будзе актуальны DSL, які прадстаўляецца новай базай дадзеных. Mongo, Couch і шматлікія іншыя павінны былі прадставіць сваю ўласную мову запытаў побач з функцыянальнасцю "map-reduce" для рашэння праблемы запытаў адвольных запісаў. Зараз я прыхільнік абодвух, але, адкрыта кажучы, не працаваў з імі дагэтуль. Іх не так лёгка зразумець, як SQL (пункт гледжання) - гэты недахоп прымушае мяне вывучыць яшчэ адну мову запытаў.
Schema-free != Грунтуецца на дакуменце
Грунтуецца на дакуменце і вольныя схемы часта выкарыстоўваюцца як сінонімы, але ёсць важнае адрозненне: схемы не абавязкова азначаюць, што структура дадзеных будзе ўкладзенай. Акрамя таго, тое, што MySQL з'яўляецца "рэляцыйнай", зусім не азначае, што яна павінен замацоўваць наканаваныя схемы - можа быць, на час стварэння, але не падчас выканання. Скрыжаванне гэтых двух становішчаў азначае, што няма абсалютна ніякіх чыннікаў, чаму ў нас не можа быць схемы бясплатнага рухавічка ў MySQL:
mysql> USE noschema;
mysql> CREATE TABLE widgets; /* look ma, no schema! */
mysql> INSERT INTO widgets (id, name) VALUES("a", "apple");
mysql> INSERT INTO widgets (id, name, type) VALUES("b", "blackberry", "phone");
mysql> SELECT * FROM widgets WHERE id = "a";
+---------+---------------+
| id | name |
+---------+---------------+
| a | apple |
+---------+---------------+
mysql> SELECT * FROM widgets;
+---------+---------------+--------+
| id | name | type |
+---------+---------------+--------+
| a | apple | NULL |
| b | blackberry | phone |
+---------+---------------+--------+
Датуль, як мы пазбягаем укладзеных структур дадзеных, няма ніякіх чыннікаў, чаму мы павінны абмяжоўваць колькасць слупкоў у табліцах, паколькі мы можам скласці адносіны падчас выканання. Гэта не толькі азначае, што не патрэбныя міграцыі ці неабходна захаваць нулявыя значэнні, але вы можаце таксама захаваць усе сродкі і мова SQL запытаў, дадаючы поўную гнуткасць у схеме.
Schema-Free DB над MySQL
Не атрымалася знайсці праект, які вырашыць гэту праблему, я ў канчатковым выніку прататыпаў сам за выходныя, і лічым мы так ці не, усё працуе проста выдатна. Сапраўды, выйсце вышэй ад рэальнага сеансу кансолі з MySQL. Усё, што прыняў, гэта EM-проксі-сервера з невялікім пратаколам нізкага ўзроўня і перазапісы запытаў, і раптам мой MySQL забыўся, што ён патрабуе схему. Вазьміце тэст-драйв сябе (вам патрэбен Ruby 1.9):
git clone git://github.com/igrigorik/em-proxy.git && cd em-proxy
ruby examples/schemaless-mysql/mysql_interceptor.rb
mysql -h localhost -P 3307 --protocol=tcp
# snip ...
# build the select statements, hide the tables behind each attribute
join = "select #{table}.id as id "
tables.each do |column|
join += " , #{table}_#{column}.value as #{column} "
end
# add the joins to stich it all together
join += " FROM #{table} "
tables.each do |column|
join += " LEFT OUTER JOIN #{table}_#{column} ON #{table}_#{column}.id = #{table}.id "
end
join += " WHERE #{table}.id = '#{key}' " if key
mysql_interceptor.rb (MySQL Proxy in Ruby)
Вядома, гэта не што іншае, як мілы прыклад кода, і ён нават не ахоплівае ўсе розныя выпадкі выкарыстання, але давайце паглядзім на набор функцый: падтрымка драйвераў для кожнай мовы (вы можаце паказаць Rails + ActiveRecord, JDBC і г.д. на яго з акна, гэта не праблема), прылада падтрымкі (GUI і камандны радок), рэплікацыя, транзакцыі, і гэтак далей. Нядрэнна за паўдня ўзлому з простай мадэллю дадзеных у фонавым рэжыме:
Замест вызначэння слупкоў табліцы, кожны атрыбут мае свой уласную табліцу (новыя табліцы ствараюцца "на лёце"), што азначае, што мы можам дадаваць і выдаляць атрыбуты па сваім меркаванні. У сваю чаргу, гэта проста азначае аб'яднанне ўсіх табліц, асобных клавіш. Для кліентаў гэта абсалютна празрыста, і, хоць проксі-сервер робіць фактычную працу, гэта функцыя можа быць лёгка здабываецца ў MySQL -яя проста здзіўлены, што ніхто не зрабіў гэтага. Для азнаямлення, праверце проксі-код. Ёсць шмат каментароў, якія тлумачаць, як і што ўсё гэта ўтворыць разам.
Шэрая зона SQL супраць NoSQL
Так у чым сэнс усяго гэтага? Ну, я спадзяюся, хтосьці сапраўды напіша такі рухавічок, таму што я лічу, што для яго маецца рынак. Існуе шмат SQL- сумяшчальных схем, вольных рухавічкоў. Можна сказаць, няма абсалютна ніякіх чыннікаў, чаму мы не можам выкарыстоўваць "NoSQL" замест MySQL. Маецца не адно відавочнае пераможца на базе рухавічка ці мадэлі, таму трэба пакласці некаторую думку ў сваім рашэнні загадзя. Проста таму, што Mongo, TC ці Couch з'яўляюцца дакумент-арыентаванымі ці вольнымі схемамі, гэта не азначае, што яны абавязкова лепш для вашага прыкладання. У той жа час, не зразумейце мяне няправільна, я ўсё яшчэ руплюся за ўсё NoSQL-праекты, а таксама ўскладаю вялікія надзеі на Drizzle - усе яны робяць фантастычную працу.
