LINUX.ORG.RU
ФорумTalks

Как гугл пытался уйти от MySQL


0

0

Наткнулся на любопытную статейку. Статья рассказывает как давно в гугле для системы рекламных объявлений выбрали MySQL, чтобы побыстрее запустить проект и как потом пытались перейти на "настоящую", дорогостоящую коммерческую СУБД и что из этого получилось.

http://habrahabr.ru/blog/mysql/33150.html

Жаль не сказали про какую именно коммерческую СУБД шла речь.

Ответ на: комментарий от lester_dev

> зуб даю, на MSSQL

Вот это вряд-ли, гугл точно не под виндой сидит.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от true

А статья-то этого года, правда перевод. В позапрошлом, наеврное была ссылка на английский оригинал.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от anonymous_incognito

>Где? На LOR'е не нашел =)

вы что, не знаете, что когда Б-г создал мир за шесть дней, на седьмой пришел Миша и сказал "БАЯН".

lester_dev ★★★★★
()
Ответ на: комментарий от router

Хе, там в комментариях ещё описана настоящая trueЪ - система для работы с данными:

> oleganza. Я про left join благополучно забыл уже давно. Под "настоящей субд" я понимаю не такую раскрутую субд, чтоб внутри нее все само как-то работало. Я понимаю набор специализированных библиотек, интегрирующихся в код приложения. Причем, приложение может в равной степени использовать стандартные структуры (скажем, индексы на Б+ деревьях), так и свои собственные. Например, скип-списки. А "настоящая субд" представляет спектр инструментов - от верхнего до нижнего уровня. Если стандартная структура не подходит, то приложение конструирует свою собственную и пользуется лишь низкоуровневыми средствами децентрализации, репликации, блокировки, сериализации и восстановления данных (то, что и обеспечивает либа "настоящая субд"). Причем, полнота SQL здесь уже нафик не сдалась, раз уж приложение само формирует необходимые ему специализированные алгоритмы.

> Итого: "настоящая субд" - это не SQL-база данных, а библиотека алгоритмов для работы с распределенными данными. Желательно, сверху до низу написанная на рубине.

> Под описание подходят: Mnesia и CouchDB на эрланге, GemStone на Smalltalk. Может, что-нибудь еще. Идея там простая: никакой отдельно стоящей СУ (от СУБД) нет, т.к. самое интересно происходит в приложении. Традиционные SQL-интерфейсы подходят разве что для типовых банковских приложений. (Да, я передергиваю, но для подробного объяснения нужно найти место и время.) Таким образом, управление базой данных должно лежать на самом приложении ибо только оно лучше всех знает, как наиболее эффективно работать со своими собственными данными. Всякие геммороидальные вещи типа сериализации/блокировки/репликации и разных известных примитивов (Б-деревьев, двусвязных списков, хешей и т.п.) можно вынести в отдельную библиотеку (которую и обозвать "базой данных").

> Концептуально, Mnesia, GemStone - это очень умные вещи. Но они хороши до тех пор, пока вы пользуетесь родными для них средствами: эрлангом или смолтоком соответственно. Если вы используете, к примеру, Си+Руби, то вы испытаете огромные трудности интеграции. Вывод отсюда такой: нужно красть их идеи и создавать среду для своего языка. В моем случае, на рубине.

> Лично у меня есть ряд примитивных библиотек (собственных и чужих), решающих лишь часть проблем Настоящей Распределенной Базы Данных, ориентированной на приложение. Пока что данные тупо кладутся на диск через MySQL, но для меня эта субд уже не более чем готовое Б+дерево и сериализация. Огромная часть работы делается в приложении. И не только потому, что "бд тупая", но и потому, что это эффективнее: сделать единиц мускульных бд в том же количестве, что и экземпляров веб-серверов почти невозможно. Мускль - не распределенная БД изначально.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от anonymous_incognito

> Где? На LOR'е не нашел =)

дык у ЛОРа и Хабра аудитория почти одна и та же :)

troorl ★★
()
Ответ на: комментарий от lester_dev

> зуб даю, на MSSQL

Нет, таки это был Oracle http://habrahabr.ru/blog/mysql/33150.html#comment574375

> Насколько я помню Google отказались от Oracle по причине отсутствия какой-то встроенной фичи, которую им не дали написать самим, а сам Oracle отказался написать её за $. Собственно поэтому на всех Tech Talks Google рассказывает почему он выбирает OpenSource, часто приводя этот пример.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от anonymous_incognito

> Хе, там в комментариях ещё описана настоящая trueЪ - система для работы с данными:

а такое реально существует в природе? О_О

isden ★★★★★
()
Ответ на: комментарий от alman

>Улыбнуло. Как раз наоборот.

В 2000-м у Постгре не было почти ничего :) Его вообще как серьёзную БД тогда не рассматривали. Его подъём начался с версий 8.x.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>> Улыбнуло. Как раз наоборот.

> В 2000-м у Постгре не было почти ничего :)

А это правда, что у MySQL тогда даже транзакций не было? :D

tailgunner ★★★★★
()
Ответ на: комментарий от KRoN73

> В 2000-м у Постгре не было почти ничего :) Его вообще как серьёзную БД тогда не рассматривали. Его подъём начался с версий 8.x.

Не знаю, не знаю. Юзал его в году, эдак, 1998. Вполне себе БД.

alman ★★★
()
Ответ на: комментарий от tailgunner

>А это правда, что у MySQL тогда даже транзакций не было? :D

Тогда много чего не было... Даже PHP не был самым популярным Web-языком :D

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>> А это правда, что у MySQL тогда даже транзакций не было? :D

> Тогда много чего не было...

Уже была объектно-реляционная СУБД PostgreSQL. С транзакциями :D

tailgunner ★★★★★
()
Ответ на: комментарий от KRoN73

Имеется в виду эта фраза:

Да, я когда подумаю, что MySQL называют сервером БД и вспоминаю, что там нет транзакций.... Причем разработчики это обосновывают тем, что там и без транзакций "всё очень надежно"....

?

8)

tailgunner ★★★★★
()

> [article]решилА[/article]

с каких пор бабы-простые манагеры решают, не спросив у технических СПЕЦИАЛИСТОВ?! удушил бы ее!

temy4
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.