[Moscow.pm] persisten storage под AnyEvent

Чт Сен 30 01:12:44 PDT 2010

Да, похоже, вы пробовали CouchDB не в её области применения.

CouchDB используется для хранения описаний узлов сети, RabbitMQ - как
высокопроизводительный движок очередей.

Оба продукта из категории "поставил и забыл".

29 сентября 2010 г. 19:55 пользователь Alexander Lourier <aml на rulezz.ru>написал:

> On Wednesday 29 September 2010 19:32:41 Akzhan Abdulin wrote:
>
> > Я бы рекомендовал ознакомится именно с последней версией CouchDB и именно
> > вживую.
>
> Лично знакомился с 0.11, она мне понравилась по задумке, но по
> проиводительности ни в какие ворота не влазила. Последнюю как-нибудь гляну,
> спасибо.
>
> > Да, так называемые Views используют JavaScript, но они вычисляются сразу
> > при попадании документов базу. То есть на скорость выборок это не влияет.
>
> Да это понятно. Но вообще выборки и так обычно хорошо кешируются, и узким
> местом базы остаются как раз вставки.
>
> > У нас используются CouchDB и RabbitMQ, к обоим продуктам нареканий пока
> > нет.
>
> А что за задача у вас?
>
> > 29 сентября 2010 г. 19:12 пользователь Alexander Lourier
> <aml на rulezz.ru>написал:
> > > 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.htm
> > >l
> > >
> > >
> http://metalelf0dev.blogspot.com/2008/09/mysql-couchdb-performance-compar
> > >ison.html
> > >
> > >
> http://www.snailinaturtleneck.com/blog/2009/06/29/couchdb-vs-mongodb-benc
> > >hmark/
> > >
> > >
> http://www.codeweblog.com/couchdb-vs-mysql-insert-performance-test-data-o
> > >f-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 mailing list
> > > moscow-pm на pm.org | http://moscow.pm.org
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20100930/8633b9c6/attachment-0001.html>