Да, похоже, вы пробовали CouchDB не в её области применения.
CouchDB используется для хранения описаний узлов сети, RabbitMQ - как высокопроизводительный движок очередей. Оба продукта из категории "поставил и забыл". 29 сентября 2010 г. 19:55 пользователь Alexander Lourier <[email protected]>написал: > On Wednesday 29 September 2010 19:32:41 Akzhan Abdulin wrote: > > > Я бы рекомендовал ознакомится именно с последней версией CouchDB и именно > > вживую. > > Лично знакомился с 0.11, она мне понравилась по задумке, но по > проиводительности ни в какие ворота не влазила. Последнюю как-нибудь гляну, > спасибо. > > > Да, так называемые Views используют JavaScript, но они вычисляются сразу > > при попадании документов базу. То есть на скорость выборок это не влияет. > > Да это понятно. Но вообще выборки и так обычно хорошо кешируются, и узким > местом базы остаются как раз вставки. > > > У нас используются CouchDB и RabbitMQ, к обоим продуктам нареканий пока > > нет. > > А что за задача у вас? > > > 29 сентября 2010 г. 19:12 пользователь Alexander Lourier > <[email protected]>написал: > > > On Wednesday 29 September 2010 17:53:54 Oleg Kostyuk wrote: > > > > <[email protected]> написал: > > > > > 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 > > > > >> > > > > >> <[email protected]> написал: > > > > >> > 2010/9/29 Vany Serezhkin <[email protected]>: > > > > >> >> On 09/29/2010 04:58 PM, Ruslan Zakirov wrote: > > > > >> >>> Решил написать проект на AnyEvent, но нуна БД. Чего выбрать не > > > > > > знаю. > > > > > > > >> >>> Можно Pg взять и попробовать его async интерфейс, но как-то не > > > > >> >>> хочется по таймеру чекать запросы. > > > > >> >>> > > > > >> >>> Вполне подойдет key/value storage, но тут сплошной пробел в > > > > >> >>> опыте. Какие есть у меня опции? > > > > >> >> > > > > >> >> AnyMongo. > > > > >> >> > > > > >> >> Только очень подумай в начале. > > > > >> > > > > > >> > О чем подумать? Я как раз и пытаюсь подумать, но о чем думать не > > > > >> > уверен. > > > > > > -- > > > Moscow.pm mailing list > > > [email protected] | http://moscow.pm.org > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
