29 сентября 2010 г. 18: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, тут спорить не буду... Но не надо настолько безосновательно очернять хороший продукт :)
> CouchDB даёт очень большую нагрузку на процессор, поскольку вычисление > индексов (исполнение кода на JavaScript) осуществляется на сервере. Там, где > SQL-базы обходятся вычислением простейших индексов (по одной или нескольким > колонкам), CouchDB выполняет скриптовую программу. Использование view-ов (которые могут быть инкрементальными) по сути ничем не отличается от индексов в реляционных базах. Применение JS конечно не ускоряет это дело, но тут как везде: "быстро, дёшево, правильно - выберите любые два". На мой взгляд, выбрали "дёшево и правильно" - получили масштабируемость, но не скорость. > Вычисление индексов совсем > необязательно делать на сервере базы данных - оно вполне себе выносится на > бэкенды, которые горизонтально масштабировать очень просто. Прям сижу и вижу, как вы в MySQL (с которым вы сравниваете ниже) вычисляете индексы не на сервере БД. > Впрочем, будем > анализировать то, что есть. Посмотрим на скорость последовательного > исполнения запросов на CouchDB. В чём великий смысл сравнивать sql и no-sql решения? Они нужны в разных случаях, и требования к базе тоже разные. > Бенчмарков полно в сети. С ходу нагуглил: > > 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 сказано, а не про MySQL. > Однако, и тут у CouchDB проблемы. Встроенных средств масштабирования у неё нет > (хотя тут могу ошибаться - erlang-программы умеют работать поверх кластера, > но поскольку у меня такого опыта нет, то в таких условиях не тестировал). Именно. Ошибаетесь. Репликация есть "из коробки", равно как и Distributed Updates: http://couchdb.apache.org/docs/overview.html. > Зато есть внешняя прокси, которая позволяет получить запрос от пользователя, > разослать его на нужные узлы кластера, а потом собрать (reduce) результат > обратно. И снова эта операция требует исполнения javascript-кода, и эти > прокси опять же нагружают процессор - нужно ставить отдельные серверы под > прокси и т.д. Не могу быть уверен, но вероятно вы пробовали использовать CouchDB не так, как то было задумано разработчиками (например, не использовали view-ы). В таком случае не удивительно, что вы недовольны результатами. > База данных - это узкое место большинства проектов, его очень сложно > масштабировать, и все операции, которые можно вынести за пределы сервера с > базой данных, должны быть вынесены. С CouchDB это явно не так. Учитывая то, что есть поддержка REST и JS "из коробки" - есть мнение, что за пределы базы вынести можно что угодно. Но вот только надо ли?... Проще и надёжней - добавить серверов, железо нынче дешёвое. (естессно, если работа базы уже прооптимизирована) > Как-то так. Вобщем, серьезных обоснований не увидел. Как мне видится, 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 > -- Sincerely yours, Oleg Kostyuk (CUB-UANIC) -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
