Наткнулся на любопытную статейку. Статья рассказывает как давно в гугле для системы рекламных объявлений выбрали MySQL, чтобы побыстрее запустить проект и как потом пытались перейти на "настоящую", дорогостоящую коммерческую СУБД и что из этого получилось.
Хе, там в комментариях ещё описана настоящая trueЪ - система для работы с данными:
> oleganza. Я про left join благополучно забыл уже давно. Под "настоящей субд" я понимаю не такую раскрутую субд, чтоб внутри нее все само как-то работало. Я понимаю набор специализированных библиотек, интегрирующихся в код приложения. Причем, приложение может в равной степени использовать стандартные структуры (скажем, индексы на Б+ деревьях), так и свои собственные. Например, скип-списки. А "настоящая субд" представляет спектр инструментов - от верхнего до нижнего уровня. Если стандартная структура не подходит, то приложение конструирует свою собственную и пользуется лишь низкоуровневыми средствами децентрализации, репликации, блокировки, сериализации и восстановления данных (то, что и обеспечивает либа "настоящая субд"). Причем, полнота SQL здесь уже нафик не сдалась, раз уж приложение само формирует необходимые ему специализированные алгоритмы.
> Итого: "настоящая субд" - это не SQL-база данных, а библиотека алгоритмов для работы с распределенными данными. Желательно, сверху до низу написанная на рубине.
> Под описание подходят: Mnesia и CouchDB на эрланге, GemStone на Smalltalk. Может, что-нибудь еще. Идея там простая: никакой отдельно стоящей СУ (от СУБД) нет, т.к. самое интересно происходит в приложении. Традиционные SQL-интерфейсы подходят разве что для типовых банковских приложений. (Да, я передергиваю, но для подробного объяснения нужно найти место и время.) Таким образом, управление базой данных должно лежать на самом приложении ибо только оно лучше всех знает, как наиболее эффективно работать со своими собственными данными. Всякие геммороидальные вещи типа сериализации/блокировки/репликации и разных известных примитивов (Б-деревьев, двусвязных списков, хешей и т.п.) можно вынести в отдельную библиотеку (которую и обозвать "базой данных").
> Концептуально, Mnesia, GemStone - это очень умные вещи. Но они хороши до тех пор, пока вы пользуетесь родными для них средствами: эрлангом или смолтоком соответственно. Если вы используете, к примеру, Си+Руби, то вы испытаете огромные трудности интеграции. Вывод отсюда такой: нужно красть их идеи и создавать среду для своего языка. В моем случае, на рубине.
> Лично у меня есть ряд примитивных библиотек (собственных и чужих), решающих лишь часть проблем Настоящей Распределенной Базы Данных, ориентированной на приложение. Пока что данные тупо кладутся на диск через MySQL, но для меня эта субд уже не более чем готовое Б+дерево и сериализация. Огромная часть работы делается в приложении. И не только потому, что "бд тупая", но и потому, что это эффективнее: сделать единиц мускульных бд в том же количестве, что и экземпляров веб-серверов почти невозможно. Мускль - не распределенная БД изначально.
> Насколько я помню Google отказались от Oracle по причине отсутствия какой-то встроенной фичи, которую им не дали написать самим, а сам Oracle отказался написать её за $. Собственно поэтому на всех Tech Talks Google рассказывает почему он выбирает OpenSource, часто приводя этот пример.
Да, я когда подумаю, что MySQL называют сервером БД и вспоминаю, что там нет транзакций.... Причем разработчики это обосновывают тем, что там и без транзакций "всё очень надежно"....