Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
когда-то давно делал перевод Anti-RDBMS: A list of distributed key-value stores, но возможности выложить тут чувствую уже не будет)
так что -> translated.by/you/anti-rdbms-a-list-of-distributed-key-value-stores
так что -> translated.by/you/anti-rdbms-a-list-of-distributed-key-value-stores
Необычное решение!
Автор оригинальной статьи до того, как основал FriendFeed, работал в Google в команде, которая занимается App Engine. Нереляционное хранилище Datastore из App Engine выглядит для программиста почти так же, как и решение из статьи. Только вместо MySQL в основе Datastore лежил распределенный BigTable.
На самом деле ничего необычного. Просто решили построить на основе MySQL key-value базу данных.
Хорошо это или плохо — на этот счет могут быть разные мнения. Я предпочитаю использовать вещи по назначению. Есть отличные вещи, например, Redis, которые гораздо быстрей мускула (т.к. не реализуют много лишнего функционала, который предлагает мускул, а используют быструю событийную epoll-based архитектуру), и для них архитектура key-value родная, поэтому не прийдется писать своего кода на уровне приложения.
Ну если уж очень хотелось использовать реляционное хранилище, то тогда уже можно было использовать Drizzle. Drizzle динамически развивающийся проект, который изначально заточен под хранение данных в вебе.
Хорошо это или плохо — на этот счет могут быть разные мнения. Я предпочитаю использовать вещи по назначению. Есть отличные вещи, например, Redis, которые гораздо быстрей мускула (т.к. не реализуют много лишнего функционала, который предлагает мускул, а используют быструю событийную epoll-based архитектуру), и для них архитектура key-value родная, поэтому не прийдется писать своего кода на уровне приложения.
Ну если уж очень хотелось использовать реляционное хранилище, то тогда уже можно было использовать Drizzle. Drizzle динамически развивающийся проект, который изначально заточен под хранение данных в вебе.
Кстати, например, бенчмарк Drizzle vr. MySQL 5.1
https://lists.launchpad.net/drizzle-discuss/msg03687.html
https://lists.launchpad.net/drizzle-discuss/msg03687.html
Прелесть MySQL в том, что он стабилен, уже отработаны процедуры работы с ним (масштабирование, бекап и т.д.). Как раз на это часто жалуются разработчики, попробовавшие альтернативы из движения NoSQL.
Интересно послушать про масштабирование MySQL.
Для майтов с малым и средним посещениями и объемом хранимых данных — MySQL, либо другая СУРБД вполне приемлемый вариант.
Для сайтов, которые имеют проблемы, описанные в статье MySQL вообще не подходит. В частности потому что очень плохо масштабируется горизонтально. (Если это вообще можно назвать возможностью масштабирования)
Для подобных сайтов нужно использовать нереляционные подходы, key-value в частности.
Для майтов с малым и средним посещениями и объемом хранимых данных — MySQL, либо другая СУРБД вполне приемлемый вариант.
Для сайтов, которые имеют проблемы, описанные в статье MySQL вообще не подходит. В частности потому что очень плохо масштабируется горизонтально. (Если это вообще можно назвать возможностью масштабирования)
Для подобных сайтов нужно использовать нереляционные подходы, key-value в частности.
Прелесть как раз в том, что слушать не надо. Есть специально обученные люди, которые умеют это делать. Крутится же Facebook и другие сайты на нем.
А с любым новым инструментом надо набивать свои шишки, прежде чем появятся люди с опытом. Немного интересуюсь темой NoSQL, пока что отзывы попробовавших не очень. Например, groups.google.ru/group/ror2ru/browse_thread/thread/4d931804805637bd/f4bebb3f225503c9?lnk=gst&q=nosql#msg_61a5a9dbb0f5288e и groups.google.ru/group/ror2ru/browse_thread/thread/11e14f3768e0c2ec/5036099e41591d79?lnk=gst&q=couchdb#msg_15ffdeceb8164a61
А с любым новым инструментом надо набивать свои шишки, прежде чем появятся люди с опытом. Немного интересуюсь темой NoSQL, пока что отзывы попробовавших не очень. Например, groups.google.ru/group/ror2ru/browse_thread/thread/4d931804805637bd/f4bebb3f225503c9?lnk=gst&q=nosql#msg_61a5a9dbb0f5288e и groups.google.ru/group/ror2ru/browse_thread/thread/11e14f3768e0c2ec/5036099e41591d79?lnk=gst&q=couchdb#msg_15ffdeceb8164a61
Facebook крутится как раз на NoSQL — Cassandra. На неё же с MySQL перешел и Digg на днях.
тут вы тоже не совсем правы. Фейсбук не использует какую-то одну технологию, также как и один язык программирования. Масштабы не те.
Изначально Cassandra использовалась в фейсбук для рассылки сообщений
http://www.facebook.com/note.php?note_id=24413138919
Изначально Cassandra использовалась в фейсбук для рассылки сообщений
http://www.facebook.com/note.php?note_id=24413138919
Да, фейсбук использует мускул. О чем, собственно, они говорили http://rutube.ru/tracks/792307.html?v=2562849a5382df69dbd050d4ea9958c4
Фигурировало даже число в 2000 серверов сускула.
Но не стоит путать. Они используют мускул как персистент сторидж, не более и не менне.
Они не выполняют чтений оттуда, т.к. 99,9% чтений выполняются из кешей (мемкеш). Изменения данных, тоже не сразу пишутся. Запись идет булками в какое-то время или по какому-то событию. Это просто сторидж.
Притом какой там мускул тоже сложно сказать. Думаю, что-то больше похожее на Drizzle, чем на обычный мускул. Исходя из интервью, ссылку на которое я дал выше, данные о каждом пользователе лежат на разные БД серверах, т.е. это уже шардинг. Шардинг на уровне БД или приложения (если по userid выбирается сервер БД на который коннектиться) тоже сложно сказать.
Для построения же дерева связей, естественно, ни о каком MySQL речи быть не может. Думаю, для этого испосльзуют касандру. Хотя пруфлинков не нашел.
Ну а про специально оьбученых людей, тут совсем не серьезно… Вы же при выборе технологии не полагаетесь на каких-то абстрактных людей.
Фигурировало даже число в 2000 серверов сускула.
Но не стоит путать. Они используют мускул как персистент сторидж, не более и не менне.
Они не выполняют чтений оттуда, т.к. 99,9% чтений выполняются из кешей (мемкеш). Изменения данных, тоже не сразу пишутся. Запись идет булками в какое-то время или по какому-то событию. Это просто сторидж.
Притом какой там мускул тоже сложно сказать. Думаю, что-то больше похожее на Drizzle, чем на обычный мускул. Исходя из интервью, ссылку на которое я дал выше, данные о каждом пользователе лежат на разные БД серверах, т.е. это уже шардинг. Шардинг на уровне БД или приложения (если по userid выбирается сервер БД на который коннектиться) тоже сложно сказать.
Для построения же дерева связей, естественно, ни о каком MySQL речи быть не может. Думаю, для этого испосльзуют касандру. Хотя пруфлинков не нашел.
Ну а про специально оьбученых людей, тут совсем не серьезно… Вы же при выборе технологии не полагаетесь на каких-то абстрактных людей.
Известность технологии, возможность найти опытных разработчиков — один из важных принципов ее выбора. Если нет разработчиков, то явно нужно будет обучать. С новичками в технологии увеличиваются риски срыва сроков. А это (обучение и увеличение вероятности срыва сроков) не для всех типов проектов подходит.
MySQL был изначально проектирован, имея возможность только вертикального масштабирования. Золотой закон — чем больше памяти, тем лучше для MySQL. Сейчас MySQL уже, слава богу, начал лучше насштабироваться на многоядерные системы, т.к. еще до недавнего времени наилучшие результаты были на четырех ядрах.
Ну о чем говорить, если в мускуле даже шардинга нет? Есть только унылый партишенинг, который в абсолютном большинстве случаев не поможет.
Или вы репликацию называете надежной схемой масштабирования? А как же масштабирование записи? Пока единственно возможно решение это мастер-мастер (активно-пассивный режим, активно-активный). Если вы предлагаете репликацию кольцом, то ИМХО, key-value решения гораздо безопасней и отказоустойчивей.
Ну о чем говорить, если в мускуле даже шардинга нет? Есть только унылый партишенинг, который в абсолютном большинстве случаев не поможет.
Или вы репликацию называете надежной схемой масштабирования? А как же масштабирование записи? Пока единственно возможно решение это мастер-мастер (активно-пассивный режим, активно-активный). Если вы предлагаете репликацию кольцом, то ИМХО, key-value решения гораздо безопасней и отказоустойчивей.
Плохая статья.
В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов.
Да, это исключительно особенность MySQL. Ни одна другая база не работает с индексами настолько медленно. Решать проблему плохого инструмента с помощью смены концепции — это вариант, но мне он не нравится.
Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами.
Это неправда. Достаточно посмотреть, откуда взялась Cassandra и кто использует Tokyo Cabinet, чтобы убедится в обратном.
В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов.
Да, это исключительно особенность MySQL. Ни одна другая база не работает с индексами настолько медленно. Решать проблему плохого инструмента с помощью смены концепции — это вариант, но мне он не нравится.
Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами.
Это неправда. Достаточно посмотреть, откуда взялась Cassandra и кто использует Tokyo Cabinet, чтобы убедится в обратном.
Статье больше года, а NoSQL набирает обороты только сейчас.
Скажите это Berkeley DB :-)
Кстати, в статье Bred и его коллеги по сути превратили MySQL в BDB.
entites — это объект с primary key added_id, а все остальные таблицы-индексы — это secondary key. На том уровне, на котором он поведал — BDB отлично справляется с задачей.
Единственное «но» — если им всё-таки понадобится выполнить один sql запрос — их решение справится, а вот BDB — увы.
entites — это объект с primary key added_id, а все остальные таблицы-индексы — это secondary key. На том уровне, на котором он поведал — BDB отлично справляется с задачей.
Единственное «но» — если им всё-таки понадобится выполнить один sql запрос — их решение справится, а вот BDB — увы.
Скорее термин NOSQL набирает обороты, в то время как подобного класса БД сущестовали ещё до своих SQL собратьев
Разве Cassandra schema-less?
Да
Тогда как объясните это: «You define column families in your storage-conf.xml file, and cannot modify them (or add new column families) without restarting your Cassandra process.»
ну так это зависит от того, что за индекс. Хотя некоторые вот умеют строить индекс не блокируя модификации
Отличная статья! Интересная тема!
Сам этот подход не понравился, а вот ссылки на mysqlperformanceblog.com а из него далее на 37 сигналов хороши.
Файловая система
Тупое ACID место.
man 2 flock
Ok. Индексы тоже не помешают. Мы в качестве «тупого места» используем BDB.
Очень интересное инженерное решение
Я сейчас как раз озабочен проектированием БД для 30-ти сущностей, раздумываю над тем чтобы остановится на 2-х универсальных таблицах — таблице объектов и таблице их отношений
FriendFeed использовал так называемый Scheme-less подход, полгода назад было упоминание на Хабре, сразу заинтересовало.
Я где-то даже видел статью об инструментах проектирования БД на основе хранения XML в полях, но сейчас не могу ее найти, да и вообще, как-то мало информации по этой тематике, к сожалению.
Я где-то даже видел статью об инструментах проектирования БД на основе хранения XML в полях, но сейчас не могу ее найти, да и вообще, как-то мало информации по этой тематике, к сожалению.
К этому гениальному решению приходят, в какой-то момент, все. Если вам нужен безсхемный подход, возьмите безсхемную базу данных, не пытайтесь натянуть чужую парадигму на SQL-базу.
Использовал похожее решение в билинге, когда потребовалось добавить два индекса на одно поле на большой таблице MySQL. Этот костыль дался малой кровью только потому, что позволила специфика (в билинге записи после создания не меняются и их индексирование можно отложить).
Но в общем случае, синхронизацию базовой таблицы и индексов довольно сложно реализовать. Я думаю, это главный из недостатков такой схемы.
Но в общем случае, синхронизацию базовой таблицы и индексов довольно сложно реализовать. Я думаю, это главный из недостатков такой схемы.
интересный подход, конечно, у команды проекта.
практически в каждом случае они просматривали существующие решения только для того, чтобы спроектировать собственный велосипед: сервер Торнадо, фреймворк на нем, теперь по сути NoSQl поверх MySQL.
это мир технологий так беден, или просто у программистов руки чесались до проектирования велосипедов?
практически в каждом случае они просматривали существующие решения только для того, чтобы спроектировать собственный велосипед: сервер Торнадо, фреймворк на нем, теперь по сути NoSQl поверх MySQL.
это мир технологий так беден, или просто у программистов руки чесались до проектирования велосипедов?
На вершине горы всегда одиноко. Большинство решений и технологий — все же для масс-рынка. Вырвавшимся вперед поневоле приходится изобретать что-то свое. Как минимум для сохранения конкурентного преимущества.
да как сказать… вот, к примеру, те же фреймворки или сервера.
на их поддержку и развитие требуется довольно много ресурсов, времени, проектирования. При необходимости поддерживать еще и сам продукт, опирающийся на технологию, усилия команды начинают распыляться.
с другой стороны, появляется возможность принимать архитектурные решения исходя из нужд конкретного проекта.
Но надстройки над БД… Не знаю, мне nosql кажется очень разумным решением, когда вся мощность sql попросту не нужна, а нужна масштабируемость и скорость.
на их поддержку и развитие требуется довольно много ресурсов, времени, проектирования. При необходимости поддерживать еще и сам продукт, опирающийся на технологию, усилия команды начинают распыляться.
с другой стороны, появляется возможность принимать архитектурные решения исходя из нужд конкретного проекта.
Но надстройки над БД… Не знаю, мне nosql кажется очень разумным решением, когда вся мощность sql попросту не нужна, а нужна масштабируемость и скорость.
читал это давно в оригинале. пожимаю плечами. для меня mongodb работает просто отлично. правда, не уверен что так было на момент написания статьи
Масштабы Вашего проекта?
система счетчиков, наподобие google analytics. сотни, тысячи сайтов. при желании мастштабируется неограниченно т.к. данные легко шардятся
baluev'у наверное было интересно ваше личное впечатление, в вашем проекте. Мне бы тоже, если честно, хотелось бы послушать человека используюещего монго в продакшне.
я не единственный, кто использует его в продакшене. из особенностей — обязательно нужно использовать репликацию, databaserepair, при больших объемах данных может длиться довольно долго. от кривых map-reduce запросов сервер падает(к счастью, падает в 100% случаев)
Скажите, а аналитику тоже с помощью MongoDB делаете? Просто читал на их сайте, что она в разделе Less Well Suited.
Ну все равно хотелось бы впечатления от незаинтересованного человека услышать, не все маркетинговые блоги читать.
Да… Вот что бывает, когда иррационалы забивают на изначально качественное проектирование.
Ради того, чтобы постоянно что-то менять менять концепцию и изобретать лисипед?? Ужос тихий.
Хотя цель достигнута — куда деваца.
Ради того, чтобы постоянно что-то менять менять концепцию и изобретать лисипед?? Ужос тихий.
Хотя цель достигнута — куда деваца.
Реализация этого же подхода для ruby/rails:
jamesgolick.com/2009/12/16/introducing-friendly-nosql-with-mysql-in-ruby.html
jamesgolick.com/2009/12/16/introducing-friendly-nosql-with-mysql-in-ruby.html
господи, да это ж баян уже как год.
всё, кто должны были это почитать, давно уже почитали в оригинале и прокнились этой интересной идеей.
всё, кто должны были это почитать, давно уже почитали в оригинале и прокнились этой интересной идеей.
сразу убило «мы имеем»… всё же наверное «у нас есть» или «в нашей базе содержится».
или это гуглотранслейт перевод?
или это гуглотранслейт перевод?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как FriendFeed использует MySQL для хранения данных без схемы