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.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 > >> > >> <[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
