[Moscow.pm] persisten storage под AnyEvent

Ср Сен 29 09:02:14 PDT 2010

29 сентября 2010 г. 18:12 пользователь Alexander Lourier
<aml на rulezz.ru> написал:
> On Wednesday 29 September 2010 17:53:54 Oleg Kostyuk wrote:
>
>> <aml на rulezz.ru> написал:
>> > 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
>> >>
>> >> <ruz на bestpractical.com> написал:
>> >> > 2010/9/29 Vany Serezhkin <ivan на serezhkin.com>:
>> >> >> On 09/29/2010 04:58 PM, Ruslan Zakirov wrote:
>> >> >>> Решил написать проект на AnyEvent, но нуна БД. Чего выбрать не знаю.
>> >> >>> Можно Pg взять и попробовать его async интерфейс, но как-то не
>> >> >>> хочется по таймеру чекать запросы.
>> >> >>>
>> >> >>> Вполне подойдет key/value storage, но тут сплошной пробел в опыте.
>> >> >>> Какие есть у меня опции?
>> >> >>
>> >> >> AnyMongo.
>> >> >>
>> >> >> Только очень подумай в начале.
>> >> >
>> >> > О чем подумать? Я как раз и пытаюсь подумать, но о чем думать не
>> >> > уверен.
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>

-- 
Sincerely yours,
Oleg Kostyuk (CUB-UANIC)