Бази данни – играта се променя

Релационните бази данни, бавно но сигурно излизат от въоръжение. Това, което знаете за нормални форми, SQL, Object/Relational Mapping… се оказва далеч от оптималното.

Какво не е наред с релационните бази данни?

Те не се справят добре с големи обеми данни.
Когато обемът данни в таблиците нарастне на милиони, изпълнението на SQL заявките се забявя. Виждал съм промяна на колона в база данни, която отнема 12-часа. Не е задължително да сте в голяма фирма, за да имате такъв обем записи.

Неудобен език за заявки.
SQL – езикът за заявки към базите данни и бил създаден за счетоводители, които пишат заявки на команден ред. По дизайн той не е предвиден да се използва от софтуер. Твърде лесно е да получите декартово произведение на резултатите. Трябва на внимавате къде ползвате агрегираща функция, в каква последователност използвате sort, group by, having. За извличането на единствен обект може да имате осем join оператора. За изтриване на обект пък трябва да съобразявате в какви таблици е разпределен и да го изтривате на парчета (като пазите парчетата, които може да се използват от други обекти).

Неспазване на стандарт.
За 10 години производителите на бази данни не можаха да стигнат до унификация по базовите въпроси:

• различни типове данни (nvarchar)
• различно генериране на последователни идентификатори (auto_increment)
• различно странициране на резултатите (offset).
• различно интерпретиране на празно поле (null).

Табличен модел.
В базите данни се съхраняват програмни обекти. Те обаче трябва да се разложат до SQL стринг, който да се интерпретира от базата данни и да разпредели обекта на парчета в различни таблици. При четене се извършва обратния процес.

Това не значи, че релационните бази данни са нещо лошо – просто се оказва, че има по-добър начин.

Новите бази данни

Новото поколение бази данни вече не са релационни, работят без SQL и скалират лесно. 
Наричат ги NoSQL бази данни. Известно е, че могат да обработят 50 TB записи (Facebook). Тези бази данни използват JSON вместо SQL. Таблиците са заменени от колекции, които могат да се оприличат на Map обекти (ключ-стойност).

Какви са недостатъците на NoSQL базите данни? Инструментите за генериране на отчети и за управление на бази данни, са направени за релационни бази. Без специален SQL-емулатор те няма да работят с NoSQL база. Транзакциите се поддържат само до някъде. Не сте сигурни, точно в кой момент документът ви е записан.

NoSQL базите данни все още не са преобладаващ вид, но вече няма съмнение, че ще бъдат основния играч. Вижте кой са фирмите зад тях:

• BigTable (Google).
• Cassandra (Facebook).
• SimpleDB (Amazon).
• MongoDB (Twitter, SourceForge). Моят фаворит 
• Sherpa (Yahoo).
• HBase (Adobe).

Големите играчи очевидно залагат на NoSQL… а те имат достатъчно ресурси и влияние върху развитието на индустрията. Очаквам след 5 години, когато започва нов софтуерен проект първият избор на архитектите да бъде MongoDB, а не MySQL.

Ами обектните бази данни?

За софтуер, който не работи с големи масиви данни, обектните бази са съвършеното решение. Те позволяват на програмиста да запише/прочете произволен обект или верига от обекти, без да се занимава изобщо с таблици, мапинги, анотации и прочие. Така се елиминират цели слоеве от приложението (mapping, dao, SQL), което е голямо улеснение и спестява много програмистки грешки.

Например – db4o е обектна база данни, която е безплатна за проекти с отворен код и работата с нея е над 7 пъти по-бърза от тази през Hibernate + HSQLDB (която от своя страна е по-бърза от MySQL). Недостатъците на тази база, са че не поддържа auto_increment функционалност и не е ясно колко струва лицензът за комерсиалната й употреба.

Защо обектните бази не са толкова популярни? Мисля, че фирмите които стоят зад тях не направиха достатъчно за популяризирането им. Също така, обектната база е обвързана с конкретен език за програмиране и не е тривиално да прочетете съдържанието й с програма писана на друг език.

В резюме

Релационните бази данни ще отстъпят място на по-добра технология – NoSQL. Ако стартирате нов проект си струва да помислите за това.