Гадните бази данни

от IvanK

Каквото и да си говорим, RDBMS (чети MYSQL) не са много хубаво нещо, ама хич даже. Единствената им добра страна е, че внасят стандарт в работата – като тръгне човек да прави сайт, онлайн приложение та даже и нормално desktop приложение, к’во да използва? ми Mysql, Postgre, Sqlite или даже Access – и ако някой каже нещо друго, което не използва SQL, всички почват да го гледат като римляни евреин, демек “кви са тия богохулствия, по-добре си дръж устата затворена, че да не те линчуваме”.

Но, поне според мен, цялата тази религиозност вече много здраво ни е ухапала за задните части. Толкова повсеместно ги използваме тия SQL-ли че не си личи зверския anti-pattern, от който вече е почти невъзможно да избягаме.

Нека поясня какъв безумно сложен процес е в момента запазването на информацията. Да предположим, че не сме някакви ламерчета, и знаем 1-2 неща за програмирането, следователно, за да сме “готини”, използваме обекти за да представим своята информация в програмата – засега всичко ток. В един прекрасен слънчев летен ден, обаче, решаваме да съхраним всичко това, дето сме го нашлякали – обектите се обръщат в string-ове по невероятно засукани и сложни начини (за да ги знае човек на 6 трябва да е поне магистър в MIT по RDBMS), използвайки псевдо-език (SQL-а) който даже не е истински език за програмиране (не е turing-compatible), след което това отпътува “по мрежата” – използвайки socket-и за да бъде най накрая запазена на харда на сървъра, след като пак е парснато и преобърнато в разни там обекти. А и цялата тази идея с “таблиците” е супер глупава. В програмите (а и в истинския свят) информацията не се пази така, там са просто обекти, които имат някакви взаимовръзки помежду си. Самият абсурд на денормализирането показва колко вече сме назад.

И всички ние продължаваме да ги използваме, просто защотот “е стандарт” и “всички така правят”.

Принципно в света на интернет стандартите са си много хубаво нещо, проблемът е, че тези RDBMS са измислени много преди интернет и въобще самите тези стандарти, и следователно не са пригодени за тях. Едно онлайн приложение не се нуждае от тази монолитна тежест на RDBMS, (някои от тях имат повече код от windows). Те просто не са оптимизирани за такъв вид работа(не съм чул досега някой да препоръчва Oracle за сайта на местната аптека например). Сигурно са много добри в пазенето на медицинските архиви на американците, или на архивите на ЦРУ, но на един basecamp, т’ва си е чист трън в маратонката.

Да не говорим, че с парите, влезли за разработката на тия системи, сигурно можем да дадем на африканчетата повече лаптопи, отколкото там има калашници. И пак не е постигнато кой-знае какво. Транзакции? Заключване? на кого му трябват? един revision control би свършил къде-къде по-добра работа – за какво е нужно цялата система да спре в очакване на някакво действие, като пенсионери, наредили се в опашка, вместо то просто да се извърши, и ако има гаф да се върне предишната версия? Но май RDBMS още не са дорасли до такива неща.

Искате още доказателства – самият факт, че всеки уважаващ себе си framework използва абстрахиране на базата данни в някаква степен, за да не виждаме SQL-а а да работим само с обекти:

  • Ruby On Rails – ActiveRecord
  • Django – Django ORM
  • Pylons – SQLAlchemy
  • Symphony – Propel
  • CakePHP – няк’ва своя недоразвита имплементация, ама пак я имат

Всичко това е писано, защото на хората им е втръснало от SQL, и просто не искат да го помирисват повече.

“Добре де” – ще кажеш, “като си толкоз отворен, к’во друго да използвам?”

През годините съм се натъквал на няколко “алтернативи” – например:

  • Cog – много яка идя – както си имате добрите стари обекти, които са логиката в програмата, то просто “ги запазва” на диска, и след това връща състоянието им при презареждане, пропускаме целия калабалък със SQL-а. Не съм вниквал в това нещо, но доколкото разбирам, т’ва е за приложения, а не сайтове. Само за питонджии
  • ZoDB – т’ва е базата данни на прословутия Zope, който едно време имаше статута на Rails в python-ските среди, ама от доста време е вече на фотосинтеза. Zope-a може и да не струва особено, но базата му данни си е доста интересна – това си е истинска имплементация на OODB идеята. Доста добро, само че пак само за питонджии
  • CouchDB – новата мома в кошарата. Няма таблици, разменяш си JSON обекти със сървъра, като използваш “url” адреси, и javascript за дообработка на информацията. Всичко това със нашумелия REST. Колкото и абсурдно и детинско да звучи, май работи доста добре, поне от коментарите на които се натъкнах. Написано е на Erlang и затова е невероятно жилава и издържлива гадина(0.999999 … reliability и т.н.), Струва си поне да се погледне

Има и още доста, но според мен се иска още работа, докато станат годни за консумиране. Най-якото, обаче е, че вече се работи по темата, на хората почват да им се отварят очите. Кой знае, след година-две може да си имаме стандартизирано и добре работещо решение, което да е по-добро от сегашните бази данни.

Коментари:3

  1. Браво! Базите не са ми дружка от детската градина, но ме спечели за каузата. А и този затрогващ почти-латино драматизъм ;)

  2. Проблемите са два.

    Първият е, че повечето main stream езици са файлово базирани и правят чисто разделение между код и данни. Това прави задължително наличието на някакъв storage механизъм. Дали той ще е база данни или файлове по диска (marshall модули / XML / JSON / YAML) е все едно. Данните остават външни.

    Повечето homoiconic езици, в които данните *са* код, са и image базирани. В Lisp и кодът и данните са s-expressions, в Prolog и кодът и данните са Horn clauses. Повечето имплементации на двата езика позволяват запазватето на моментното състояние на системата, което в последствие може да бъде възстановено, и изпълнението по този начин — продължено.

    Другият проблем е, че данните са *ценното* нещо. Демек, трябва да се предостави достъп до тях, от клиенти писани на множество езици, по множество протоколи. Завършваш описанието на първите две алтернативи със “само за питонджии”. Ако ми трябват данните в ruby проект? Ще трябва да се пише конвертор. Или да се предостави REST / SOAP интерфейс. Или, или, или…

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

    XML / JSON / YAML / flat files предоставят още *по* най-малък общ делител, но ползвайки ги трябва да се грижиш сам за интегритет, транзакции и други важни неща, които обаче са трудни и никой не иска да се занимава с тях. Още по малко, отколкото иска да се занимава с SQL.

    Работата на Damien Katz се казва CoUchDB (като диван), а не CoAchDB. :-)

  3. След толкоз много десетилетия развитие, девовете са стигнали до консенсуса, че е хубаво логика и данни да се държат на различни места – демек база данни са добро нещо, мене просто не ме кефи сегашната имплементцаия.

    Ако говорим за съвместимост – доколкото разбирам, една система за бази данни от рода на ZODB, пази съдържанието си в много прост формат – класове, обекти, и всеки от тях има указатели към други класове. Определено не искам да работя с език, който не може да имплементира поне това… Така че адаптери ще се направят ако се налагат.

    А както вече казах, не мисля че ZODB или CouchDB е решението, но поне е крачка в правилната поска. И най-вече – RDBMS в момента са оптимизирани да работят ефективно със всички типове задачи, затова и не са особено оптимизирани за всяка една от тях. Вземи C++ за сравнение -с него можеш да направиш всичко, включително и да си напишеш сайт, но едва ли ще ти е весело да го правиш full time. Все пак като намалиш нишата на ползване, може да се оптимизират бая нещата. Това за което си мечтая аз е база, която е удобна за web, но да е приложима и за останали ситуации.

    И мерси за спелинга – понякога дори и spellcheck – а не може да ме спаси :)

Коментирай