Я бы рекомендовал ознакомится именно с последней версией CouchDB и именно вживую.<div><br></div><div>Да, так называемые Views используют JavaScript, но они вычисляются сразу при попадании документов базу. То есть на скорость выборок это не влияет.</div>
<div><br></div><div>У нас используются CouchDB и RabbitMQ, к обоим продуктам нареканий пока нет.</div><div><br><div class="gmail_quote">29 сентября 2010 г. 19:12 пользователь 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 17:53:54 Oleg Kostyuk wrote:<br>
<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>
</div>Конечно, уважаемый сэр :)<br>
<br>
CouchDB даёт очень большую нагрузку на процессор, поскольку вычисление<br>
индексов (исполнение кода на JavaScript) осуществляется на сервере. Там, где<br>
SQL-базы обходятся вычислением простейших индексов (по одной или нескольким<br>
колонкам), CouchDB выполняет скриптовую программу. Вычисление индексов совсем<br>
необязательно делать на сервере базы данных - оно вполне себе выносится на<br>
бэкенды, которые горизонтально масштабировать очень просто. Впрочем, будем<br>
анализировать то, что есть. Посмотрим на скорость последовательного<br>
исполнения запросов на CouchDB. Бенчмарков полно в сети. С ходу нагуглил:<br>
<br>
<a href="http://rwsleep.blogspot.com/2010/02/tokyotyrant-vs-mongodb-vs-couchdb.html" target="_blank">http://rwsleep.blogspot.com/2010/02/tokyotyrant-vs-mongodb-vs-couchdb.html</a><br>
<a href="http://metalelf0dev.blogspot.com/2008/09/mysql-couchdb-performance-comparison.html" target="_blank">http://metalelf0dev.blogspot.com/2008/09/mysql-couchdb-performance-comparison.html</a><br>
<a href="http://www.snailinaturtleneck.com/blog/2009/06/29/couchdb-vs-mongodb-benchmark/" target="_blank">http://www.snailinaturtleneck.com/blog/2009/06/29/couchdb-vs-mongodb-benchmark/</a><br>
<a href="http://www.codeweblog.com/couchdb-vs-mysql-insert-performance-test-data-of-the-speed-test/" target="_blank">http://www.codeweblog.com/couchdb-vs-mysql-insert-performance-test-data-of-the-speed-test/</a><br>
<br>
CouchDB всегда отстаёт. Однако, последовательное исполнение запросов - не<br>
самый ценный показатель базы. Всегда есть несколько процессорных ядер и,<br>
наконец, несколько серверов, которые позволят исполнять несколько запросов<br>
одновременно, и если не будет хватать одного сервера, то можно будет добавить<br>
других и обеспечить такую пропускную способность, какую захотим.<br>
<br>
Однако, и тут у CouchDB проблемы. Встроенных средств масштабирования у неё нет<br>
(хотя тут могу ошибаться - erlang-программы умеют работать поверх кластера,<br>
но поскольку у меня такого опыта нет, то в таких условиях не тестировал).<br>
Зато есть внешняя прокси, которая позволяет получить запрос от пользователя,<br>
разослать его на нужные узлы кластера, а потом собрать (reduce) результат<br>
обратно. И снова эта операция требует исполнения javascript-кода, и эти<br>
прокси опять же нагружают процессор - нужно ставить отдельные серверы под<br>
прокси и т.д.<br>
<br>
База данных - это узкое место большинства проектов, его очень сложно<br>
масштабировать, и все операции, которые можно вынести за пределы сервера с<br>
базой данных, должны быть вынесены. С CouchDB это явно не так.<br>
<br>
Как-то так.<br>
<div><div></div><div class="h5"><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>
> > тормозить на 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>
> >> >>> Можно Pg взять и попробовать его async интерфейс, но как-то не<br>
> >> >>> хочется по таймеру чекать запросы.<br>
> >> >>><br>
> >> >>> Вполне подойдет key/value storage, но тут сплошной пробел в опыте.<br>
> >> >>> Какие есть у меня опции?<br>
> >> >><br>
> >> >> AnyMongo.<br>
> >> >><br>
> >> >> Только очень подумай в начале.<br>
> >> ><br>
> >> > О чем подумать? Я как раз и пытаюсь подумать, но о чем думать не<br>
> >> > уверен.<br>
<br>
<br>
--<br>
</div></div><div><div></div><div class="h5">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>