Да, похоже, вы пробовали CouchDB не в её области применения.<div><br></div><div>CouchDB используется для хранения описаний узлов сети, RabbitMQ - как высокопроизводительный движок очередей.<br><br></div><div>Оба продукта из категории "поставил и забыл".</div>
<div><br><div class="gmail_quote">29 сентября 2010 г. 19:55 пользователь Alexander Lourier <span dir="ltr"><<a href="mailto:aml@rulezz.ru">aml@rulezz.ru</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wednesday 29 September 2010 19:32:41 Akzhan Abdulin wrote:<br>
<br>
> Я бы рекомендовал ознакомится именно с последней версией CouchDB и именно<br>
> вживую.<br>
<br>
</div>Лично знакомился с 0.11, она мне понравилась по задумке, но по<br>
проиводительности ни в какие ворота не влазила. Последнюю как-нибудь гляну,<br>
спасибо.<br>
<div class="im"><br>
> Да, так называемые Views используют JavaScript, но они вычисляются сразу<br>
> при попадании документов базу. То есть на скорость выборок это не влияет.<br>
<br>
</div>Да это понятно. Но вообще выборки и так обычно хорошо кешируются, и узким<br>
местом базы остаются как раз вставки.<br>
<div class="im"><br>
> У нас используются CouchDB и RabbitMQ, к обоим продуктам нареканий пока<br>
> нет.<br>
<br>
</div>А что за задача у вас?<br>
<div><div></div><div class="h5"><br>
> 29 сентября 2010 г. 19:12 пользователь Alexander Lourier<br>
<<a href="mailto:aml@rulezz.ru">aml@rulezz.ru</a>>написал:<br>
> > On Wednesday 29 September 2010 17:53:54 Oleg Kostyuk wrote:<br>
> > > <<a href="mailto:aml@rulezz.ru">aml@rulezz.ru</a>> написал:<br>
> > > > On Wednesday 29 September 2010 17:20:18 Oleg Kostyuk wrote:<br>
> > > >> CouchDB, не?<br>
> > > >> AnyEvent::CouchDB или KiokuDB (через KiokuDB::Backend::CouchDB)<br>
> > > ><br>
> > > > CouchDB - великий тормоз. Подходит только для академических задач.<br>
> > ><br>
> > > Благородного дона конечно же не затруднит обосновать своё заявление?...<br>
> ><br>
> > Конечно, уважаемый сэр :)<br>
> ><br>
> > CouchDB даёт очень большую нагрузку на процессор, поскольку вычисление<br>
> > индексов (исполнение кода на JavaScript) осуществляется на сервере. Там,<br>
> > где<br>
> > SQL-базы обходятся вычислением простейших индексов (по одной или<br>
> > нескольким колонкам), CouchDB выполняет скриптовую программу. Вычисление<br>
> > индексов совсем<br>
> > необязательно делать на сервере базы данных - оно вполне себе выносится<br>
> > на бэкенды, которые горизонтально масштабировать очень просто. Впрочем,<br>
> > будем анализировать то, что есть. Посмотрим на скорость последовательного<br>
> > исполнения запросов на CouchDB. Бенчмарков полно в сети. С ходу нагуглил:<br>
> ><br>
> > <a href="http://rwsleep.blogspot.com/2010/02/tokyotyrant-vs-mongodb-vs-couchdb.htm" target="_blank">http://rwsleep.blogspot.com/2010/02/tokyotyrant-vs-mongodb-vs-couchdb.htm</a><br>
> >l<br>
> ><br>
> > <a href="http://metalelf0dev.blogspot.com/2008/09/mysql-couchdb-performance-compar" target="_blank">http://metalelf0dev.blogspot.com/2008/09/mysql-couchdb-performance-compar</a><br>
> >ison.html<br>
> ><br>
> > <a href="http://www.snailinaturtleneck.com/blog/2009/06/29/couchdb-vs-mongodb-benc" target="_blank">http://www.snailinaturtleneck.com/blog/2009/06/29/couchdb-vs-mongodb-benc</a><br>
> >hmark/<br>
> ><br>
> > <a href="http://www.codeweblog.com/couchdb-vs-mysql-insert-performance-test-data-o" target="_blank">http://www.codeweblog.com/couchdb-vs-mysql-insert-performance-test-data-o</a><br>
> >f-the-speed-test/<br>
> ><br>
> > CouchDB всегда отстаёт. Однако, последовательное исполнение запросов - не<br>
> > самый ценный показатель базы. Всегда есть несколько процессорных ядер и,<br>
> > наконец, несколько серверов, которые позволят исполнять несколько<br>
> > запросов одновременно, и если не будет хватать одного сервера, то можно<br>
> > будет добавить<br>
> > других и обеспечить такую пропускную способность, какую захотим.<br>
> ><br>
> > Однако, и тут у CouchDB проблемы. Встроенных средств масштабирования у<br>
> > неё нет<br>
> > (хотя тут могу ошибаться - erlang-программы умеют работать поверх<br>
> > кластера, но поскольку у меня такого опыта нет, то в таких условиях не<br>
> > тестировал). Зато есть внешняя прокси, которая позволяет получить запрос<br>
> > от<br>
> > пользователя,<br>
> > разослать его на нужные узлы кластера, а потом собрать (reduce) результат<br>
> > обратно. И снова эта операция требует исполнения javascript-кода, и эти<br>
> > прокси опять же нагружают процессор - нужно ставить отдельные серверы под<br>
> > прокси и т.д.<br>
> ><br>
> > База данных - это узкое место большинства проектов, его очень сложно<br>
> > масштабировать, и все операции, которые можно вынести за пределы сервера<br>
> > с базой данных, должны быть вынесены. С CouchDB это явно не так.<br>
> ><br>
> > Как-то так.<br>
> ><br>
> > > > Если сможете запустить thrift over AnyEvent, то есть отличная СУБД -<br>
> > > > Cassandra.<br>
> > > ><br>
> > > >> А расскажите, как вам подходит key/value? Я для себя сделал вывод,<br>
> > > >> что key/value - весьма специфическая штука. И для работы с ней надо<br>
> > > >> пересмотреть устоявшиеся (реляционные) принципы. Конечно, бывает<br>
> > > >> так, что просто задача не подходящая для key/value... но если<br>
> > > >> подходящая - надо "выворачивать" мозг.<br>
> > > ><br>
> > > > Key/value - специфическая модель, зато в правильную сторону мозги<br>
> > > > разворачивает. Всё, что сложно реализовать на key/value, наверняка<br>
> ><br>
> > будет<br>
> ><br>
> > > > тормозить на SQL. А если уж реализуешь на key/value, да и минимальным<br>
> > > > количеством запросов, то это будет и работать быстро.<br>
> > ><br>
> > > Это всё круто, но слегка не в тему - ведь это не рассказ "как вы<br>
> > > используете key/value". Интересует именно реальное применение, а-ля<br>
> > > "вот тут можно было вот так, реляционно (+детали), но я подумал и<br>
> > > сделал вот так, на key/value (+детали), потому что ... (+ ещё<br>
> > > детали)". Есть кому поделиться таким опытом?<br>
> > ><br>
> > > >> 29 сентября 2010 г. 16:04 пользователь Ruslan Zakirov<br>
> > > >><br>
> > > >> <<a href="mailto:ruz@bestpractical.com">ruz@bestpractical.com</a>> написал:<br>
> > > >> > 2010/9/29 Vany Serezhkin <<a href="mailto:ivan@serezhkin.com">ivan@serezhkin.com</a>>:<br>
> > > >> >> On 09/29/2010 04:58 PM, Ruslan Zakirov wrote:<br>
> > > >> >>> Решил написать проект на AnyEvent, но нуна БД. Чего выбрать не<br>
> ><br>
> > знаю.<br>
> ><br>
> > > >> >>> Можно Pg взять и попробовать его async интерфейс, но как-то не<br>
> > > >> >>> хочется по таймеру чекать запросы.<br>
> > > >> >>><br>
> > > >> >>> Вполне подойдет key/value storage, но тут сплошной пробел в<br>
> > > >> >>> опыте. Какие есть у меня опции?<br>
> > > >> >><br>
> > > >> >> AnyMongo.<br>
> > > >> >><br>
> > > >> >> Только очень подумай в начале.<br>
> > > >> ><br>
> > > >> > О чем подумать? Я как раз и пытаюсь подумать, но о чем думать не<br>
> > > >> > уверен.<br>
> ><br>
> > --<br>
> > Moscow.pm mailing list<br>
> > <a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
<br>
<br>
--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</div></div></blockquote></div><br></div>