Добре си спомням времето, когато писането в текстов файл беше напълно достатъчно за покриването на нуждите от от бази данни. Дори и в момента могат да бъдат намерени адресни книги, книги за гости, а дори и малки форумчета базирани на текстови файлове. Разбира се тяхното време отдавна отмина – нерационални са. С това дойде и времето на сериозните бази данни. Една тях е MySQL – най-използваната към момента. Разбира се една от основните причини за това е бързия темп на развитие на уеб, който най-добре пасна с възможностите, които се предлагат от MySQL. Но дойде време, когато MyISAM и InnoDB взеха да се задъхват. Каквито и оптимизации, и хакове да се правят базата по дизайн има своите лимити (дори се ограничава функционалността за да не се губи ефективност) и те най-сериозно се усещат при големи натоварвания.
Google е една от компаниите широко използваща MySQL. Mакар много неща покрай Google да се пазят в тайна те неотдавна публикуваха собствените си доработки на MySQL, който вече са включени в новите официални версии.
На къде е бъдещето? Всъщност Facebook вече са крачка напред! Те разработват собствена (NoSQL) база данни, позволяваща обработването на много по-сериозни обеми от данни, натоварвания и лесна скалируемост. Става дума за Cassandra, която вече е под крилото на Apache и е един от топ проектите на Apache Software Foundation.
Тази вечер излезе новина, че Twitter провеждат сериозни тестове и се подготвят за миграцията към Cassandra, което ме подтикна да напиша този пост. Интервю с Ryan King, инженер в Twitter, хвърля светлина върху проекта Cassandra и защо е бил избран сред десетки други. Cassandra единствено отговаря на всички критерии.
Към официалните ползватели на касандра се причисляват: Facebook, Digg, WebEx на Cisco, мейл система на IBM, а скоро и Twitter.
Хм, интересно. Попрочетох и доколкото виждам има си проблеми системата, включително и доста сериозни, заложени в дизайна (например всички машини, на които работи трябва да са с приблизително еднакъв капацитет). Другото е, че за приложения със значително повече read трафик, отколкото write трафик ще е много по-неефективна от MySQL+InnoDB. Голяма част от съществуващите системи са именно такива, така че смятам че в обозримо бъдеще няма да има изместване на MySQL/InnoDB от малките и средно големи уеб проекти, а само в ограничен брой от огромните проекти като тези, които си дал за примери.
Да, за изместване при малките проекти не може и да става дума – там MySQL доминира.
За малкия и средния бизнес тези бази са силно неудобни – най-малкото заради това, че са noSQL. Все едно да си косиш ливадата с танк 😀
Хардуера не е чак проблем – ако решиш да използваш подобна система едвали ще почнеш да събираш машини от където ти падне:)
Всъщност важното е, че четенията и писанията при Cassandra са по-бързи от тези на MySQL, тоест няма положение в което MySQL да е по-ефективен. Това, че писанията са по-бързи, не означава, че четенията са по-бавни от тези при MySQL.
Всъщност на MySQL основен проблем са му писанията, заради които се налага агрегирането на информацията и записването й отложено. Все пак говорим при големи натоварвания, които не са проблем на малкия и среден бизнес:-)
MySQL определено не е за големи проекти. Особено много дразнят непрекъснато срещаните думички “parsed but ignored by all storage engines”. Например за CHECK – пишеш си го, приема си го, доволен си… и изведнъж се оказва, че ти е бъгав софтуера. Толкова много кусури си има, че в един момент ти писва и си купуваш Oracle 🙂
Има повече от един верен начин да направиш нещо.