[Moscow.pm] persisten storage под AnyEvent

Alexander Lourier aml на rulezz.ru
Ср Сен 29 08:12:30 PDT 2010


On Wednesday 29 September 2010 17:53:54 Oleg Kostyuk wrote:

> <aml на rulezz.ru> написал:
> > On Wednesday 29 September 2010 17:20:18 Oleg Kostyuk wrote:
> >> CouchDB, не?
> >> AnyEvent::CouchDB или KiokuDB (через KiokuDB::Backend::CouchDB)
> >
> > CouchDB - великий тормоз. Подходит только для академических задач.
>
> Благородного дона конечно же не затруднит обосновать своё заявление?...

Конечно, уважаемый сэр :)

CouchDB даёт очень большую нагрузку на процессор, поскольку вычисление 
индексов (исполнение кода на JavaScript) осуществляется на сервере. Там, где 
SQL-базы обходятся вычислением простейших индексов (по одной или нескольким 
колонкам), CouchDB выполняет скриптовую программу. Вычисление индексов совсем 
необязательно делать на сервере базы данных - оно вполне себе выносится на 
бэкенды, которые горизонтально масштабировать очень просто. Впрочем, будем 
анализировать то, что есть. Посмотрим на скорость последовательного 
исполнения запросов на CouchDB. Бенчмарков полно в сети. С ходу нагуглил:

http://rwsleep.blogspot.com/2010/02/tokyotyrant-vs-mongodb-vs-couchdb.html
http://metalelf0dev.blogspot.com/2008/09/mysql-couchdb-performance-comparison.html
http://www.snailinaturtleneck.com/blog/2009/06/29/couchdb-vs-mongodb-benchmark/
http://www.codeweblog.com/couchdb-vs-mysql-insert-performance-test-data-of-the-speed-test/

CouchDB всегда отстаёт. Однако, последовательное исполнение запросов - не 
самый ценный показатель базы. Всегда есть несколько процессорных ядер и, 
наконец, несколько серверов, которые позволят исполнять несколько запросов 
одновременно, и если не будет хватать одного сервера, то можно будет добавить 
других и обеспечить такую пропускную способность, какую захотим. 

Однако, и тут у CouchDB проблемы. Встроенных средств масштабирования у неё нет 
(хотя тут могу ошибаться - erlang-программы умеют работать поверх кластера, 
но поскольку у меня такого опыта нет, то в таких условиях не тестировал). 
Зато есть внешняя прокси, которая позволяет получить запрос от пользователя, 
разослать его на нужные узлы кластера, а потом собрать (reduce) результат 
обратно. И снова эта операция требует исполнения javascript-кода, и эти 
прокси опять же нагружают процессор - нужно ставить отдельные серверы под 
прокси и т.д.

База данных - это узкое место большинства проектов, его очень сложно 
масштабировать, и все операции, которые можно вынести за пределы сервера с 
базой данных, должны быть вынесены. С CouchDB это явно не так.

Как-то так.

> > Если сможете запустить thrift over AnyEvent, то есть отличная СУБД -
> > Cassandra.
> >
> >> А расскажите, как вам подходит key/value? Я для себя сделал вывод, что
> >> key/value - весьма специфическая штука. И для работы с ней надо
> >> пересмотреть устоявшиеся (реляционные) принципы. Конечно, бывает так,
> >> что просто задача не подходящая для key/value... но если подходящая -
> >> надо "выворачивать" мозг.
> >
> > Key/value - специфическая модель, зато в правильную сторону мозги
> > разворачивает. Всё, что сложно реализовать на key/value, наверняка будет
> > тормозить на SQL. А если уж реализуешь на key/value, да и минимальным
> > количеством запросов, то это будет и работать быстро.
>
> Это всё круто, но слегка не в тему - ведь это не рассказ "как вы
> используете key/value". Интересует именно реальное применение, а-ля
> "вот тут можно было вот так, реляционно (+детали), но я подумал и
> сделал вот так, на key/value (+детали), потому что ... (+ ещё
> детали)". Есть кому поделиться таким опытом?
>
> >> 29 сентября 2010 г. 16:04 пользователь Ruslan Zakirov
> >>
> >> <ruz на bestpractical.com> написал:
> >> > 2010/9/29 Vany Serezhkin <ivan на serezhkin.com>:
> >> >> On 09/29/2010 04:58 PM, Ruslan Zakirov wrote:
> >> >>> Решил написать проект на AnyEvent, но нуна БД. Чего выбрать не знаю.
> >> >>> Можно Pg взять и попробовать его async интерфейс, но как-то не
> >> >>> хочется по таймеру чекать запросы.
> >> >>>
> >> >>> Вполне подойдет key/value storage, но тут сплошной пробел в опыте.
> >> >>> Какие есть у меня опции?
> >> >>
> >> >> AnyMongo.
> >> >>
> >> >> Только очень подумай в начале.
> >> >
> >> > О чем подумать? Я как раз и пытаюсь подумать, но о чем думать не
> >> > уверен.




Подробная информация о списке рассылки Moscow-pm