Comments 110
>это такая симпатичная игрушка с map/reduce на Javascript,
Поправьте. На Erlang-о написан, на Erlang. Это даже видно на приведенном скриншоте.
Поправьте. На Erlang-о написан, на Erlang. Это даже видно на приведенном скриншоте.
Имелось в виду, что map/reduce в нём на Javascript, а не сам CouchDB — я конечно нечётко выразился, сейчас исправлю, спасибо. CouchDB-то конечно на Erlang написан.
Map/reduce можно и на Эрланге писать.
Можно, но это уже плагины, а плагинами там можно на куче языклв писать.
Хм, разве плагин нужен? Встроенные эрланговские функции типа _sum и _count можно вызывать и без плагинов, по крайней мере в 1.0.
Да вы правы, этот плагин уже давно идет предустановленным.
>> Since version 0.10.0, CouchDB has a native Erlang view server, allowing you to write your map/reduce functions in Erlang.
>> There is no-longer the need to manually install erlview, unless you are running an old version of CouchDB.
wiki.apache.org/couchdb/EnableErlangViews
>> Since version 0.10.0, CouchDB has a native Erlang view server, allowing you to write your map/reduce functions in Erlang.
>> There is no-longer the need to manually install erlview, unless you are running an old version of CouchDB.
wiki.apache.org/couchdb/EnableErlangViews
Прекрасный рисунок на тетрадном листе, серьёзно
потрясающе. спасибо.
буду курить-курить-курить)
а нету где-нибудь чего-то вроде «CouchDB в примерах»?
буду курить-курить-курить)
а нету где-нибудь чего-то вроде «CouchDB в примерах»?
есть довольно исчерпывающая книга от авторов изданная O'Reilly. правда по ссылке она на англ, не знаю переводилась ли. также много юзкейсов и примеров в вики.
мне уже знакомые намекнули, что хорошо бы осветить что такое map/reduce вообще — если тема народу интересна, напишу отдельным постом.
мне уже знакомые намекнули, что хорошо бы осветить что такое map/reduce вообще — если тема народу интересна, напишу отдельным постом.
Полистайте блог lrrr Map/Reduce своими руками — Apache CouchDb.
Может от сюда даже заглянет и чего скажет, как знать.
Может от сюда даже заглянет и чего скажет, как знать.
и да, все-таки, на сколько он быстр? можно ли его сравнивать с тем же мускулем? понятно, что в 95% слчае делаются не высоконагруженные проекты, но тем не менее
как вам сказать, сравнивать не совсем корректно. в кауче любой запрос — это по сути вытаскивание десятка нужных вам значений из B-tree. Это очень быстро. Но не так быстро как могло бы быть, если бы кауч был написал на C и использовал бы какой-нибудь низкоуровневый бинарный формат через unix-sockets — но этого не будет, т.к. цели другие.
С другой стороны на MySQL совсем не сложно написать запрос, который поставит сервер на колени и будет считаться минуту, например, когда вам нужно собирать огромное количество разнородной информации с очень разной структурой и как-то аггрегировать, с использованием пользовательских фильтров :) А в коуче это будет сразу.
Вобщем как всегда всё очень зависит от конкретного приложения.
С другой стороны на MySQL совсем не сложно написать запрос, который поставит сервер на колени и будет считаться минуту, например, когда вам нужно собирать огромное количество разнородной информации с очень разной структурой и как-то аггрегировать, с использованием пользовательских фильтров :) А в коуче это будет сразу.
Вобщем как всегда всё очень зависит от конкретного приложения.
CAUTION The 1.0.0 release has a data-loss bug in its default configuration. Please stand by and wait for the 1.0.1 release.
люблю такие production-ready системы.
люблю такие production-ready системы.
Да ладно, где без багов?
Что самое смешное в этом баге, его долго не могли найти из-за высокой стабильности CouchDB (да, смешно).
Баг воспроизводится так:
1. Создать документ с id X
2. Попытаться создать документ с таким же id (конфликт).
3. Создать документ Y.
4. Перезапустить базу.
Документ Y отсутствует. Бага наблюдается только если включены отложенные коммиты или не было принудительно коммита перед рестартом.
Фактически, если не рестартить базу (а зачем? Апгрейд обычно делается без рестарта, поднятием новой версии рядом и репликацией туда старых данных), то на баг напороться достаточно сложно. Собственно, первые сигналы поступали от windows-юзеров (ну и у кого больше аптайм? хехе), что как бэ намекает.
Что самое смешное в этом баге, его долго не могли найти из-за высокой стабильности CouchDB (да, смешно).
Баг воспроизводится так:
1. Создать документ с id X
2. Попытаться создать документ с таким же id (конфликт).
3. Создать документ Y.
4. Перезапустить базу.
Документ Y отсутствует. Бага наблюдается только если включены отложенные коммиты или не было принудительно коммита перед рестартом.
Фактически, если не рестартить базу (а зачем? Апгрейд обычно делается без рестарта, поднятием новой версии рядом и репликацией туда старых данных), то на баг напороться достаточно сложно. Собственно, первые сигналы поступали от windows-юзеров (ну и у кого больше аптайм? хехе), что как бэ намекает.
>Что такое CouchDB для вас?
Пародия на MongoDB, если честно.
Но статья годная, благодарствую.
Пародия на MongoDB, если честно.
Но статья годная, благодарствую.
Холивор! Холивор!
А вот couchdb на эрланге написан, а у вас плюсы :-Р
А вот couchdb на эрланге написан, а у вас плюсы :-Р
Ну разработка кауча началась на несколько лет раньше.
Время весьма относительное явление в IT истории:
>1936 — Alonzo Church also invents every language that will ever be but does it better. His lambda calculus is ignored because it is insufficiently C-like. This criticism occurs in spite of the fact that C has not yet been invented.
>1964 — John Kemeny and Thomas Kurtz create BASIC, an unstructured programming language for non-computer scientists.
>1965 — Kemeny and Kurtz go to 1964.
>1970 — Niklaus Wirth creates Pascal, a procedural language. Critics immediately denounce Pascal because it uses «x := x + y» syntax instead of the more familiar C-like «x = x + y». This criticism happens in spite of the fact that C has not yet been invented.
james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html
>1936 — Alonzo Church also invents every language that will ever be but does it better. His lambda calculus is ignored because it is insufficiently C-like. This criticism occurs in spite of the fact that C has not yet been invented.
>1964 — John Kemeny and Thomas Kurtz create BASIC, an unstructured programming language for non-computer scientists.
>1965 — Kemeny and Kurtz go to 1964.
>1970 — Niklaus Wirth creates Pascal, a procedural language. Critics immediately denounce Pascal because it uses «x := x + y» syntax instead of the more familiar C-like «x = x + y». This criticism happens in spite of the fact that C has not yet been invented.
james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html
Кстати, зря на JS наезжаете. Если view-функция не делает какой-то сложной арифметики, то 95% времени работы view-сервера будет сериализация и десериализация данных. Причем, JS-ный движок работает не медленнее python'овского. Я сравнивал python'овский view-сервер (с cjson) и дефолтный. Разница в скорости на пустых вьюшках была порядка 1-2% (база — примерно 2M документов).
> Причем, JS-ный движок работает не медленнее python'овского.
В смысле, JS-ный движок сериалиазции/десериализации.
В смысле, JS-ный движок сериалиазции/десериализации.
согласен, я говорил как раз о случаях, когда вьюхи могут быть действительно тяжёлыми или когда хочется воспользоваться питоновскими библиотеками, которые есть на все случаи жизни.
скорость инсертов и тем более расчёта вьюх на самом деле не тот параметр на который нужно обращать внимание, если это критично для приложения, то кауч возможно не лучший выбор.
скорость инсертов и тем более расчёта вьюх на самом деле не тот параметр на который нужно обращать внимание, если это критично для приложения, то кауч возможно не лучший выбор.
Статистика по быстродействию , по крайней мере доступная, совсем не радует.
Вам мало 2000 инсертов в секунду? Это, собственно, не пик.
Увы… Но есть неплохие альтернативные решения… Например Redis.
Redis не является альтернативой. Разные возможности, как следствие — разный перформенс.
map/reduce нету, master-master нету. Вы уверены, что это альтернатива? Да и кауч никто не тестил толком на скорость… В последних версиях там как и в redis появилась отложенная запись, так что скорость должна значительно вырости.
в редисе есть репликация. нет разницы между мастер-мастер и мастер-слейв, все узлы равны
Если нет разницы между нодами, то это master-master, однако на сайте пишут про master-slave. Но я с redis не знаком, настаивать не буду.
Хм, я был уверен что если валится мастер нода, то слейвы автоматом не подымаются. Что-то поменялось? Можно линку где почитать?
сорри, там таки да. В общем — да, вы правы, все же мастер-слейв. Но при падении мастера на слейвах все остается, вопрос репликации от слейвов мастеру при поднятии открыт. Но репликация при наличии развитых систем снапшотирования и аппенд-оли лога является скорее для разнесения данных чем для обеспечения именно сохранности в случае падения.
Вам сессии хранить? Кауч тут не лучший выбор. Тут как раз memcacheddb/redis.
P.S. Да и с тех пор скорость инсертов несколько раз выростала (судя по changelog'ам).
смысл мерять только инсерты — это не является сильной стороной кауча. см. выше мой коммент про вьюхи.
А для чего лично вы используете CouchDB, если не секрет? Теория это хорошо, но уж очень бы хотелось почитать побольше реальных «success stories» использования CouchDB в живых приложениях, чтобы оценить преимущества относительно альтернативных решений.
Мы сами сейчас присматриваемся к CouchDB как к варианту для создания кластеризуемого хранилища изображений (фотографии, иллюстрации к контенту, многочисленные превьюшки и т.д.). В таком контексте не приходилось её использовать?
Мы сами сейчас присматриваемся к CouchDB как к варианту для создания кластеризуемого хранилища изображений (фотографии, иллюстрации к контенту, многочисленные превьюшки и т.д.). В таком контексте не приходилось её использовать?
как только будет паблик бэта — будет и success story, очень надеюсь :) это что-то вроде сайта-информера агрегирующего информацию по конкретному сектору промышленности с социальными фичами.
данные очень разнородные и нужно формировать из них массу предопределённых фидов, поэтому map/reduce очень подходит. до этого была legacy-система на MySQL, которая стала слишком сложной и медленной. а с каучем сейчас расслабляюсь.
относительно вашей области к сожалению ничего сказать не могу — не приходилось использовать в таком контексте, но выглядит довольно логично.
данные очень разнородные и нужно формировать из них массу предопределённых фидов, поэтому map/reduce очень подходит. до этого была legacy-система на MySQL, которая стала слишком сложной и медленной. а с каучем сейчас расслабляюсь.
относительно вашей области к сожалению ничего сказать не могу — не приходилось использовать в таком контексте, но выглядит довольно логично.
Пихать в CouchDB двоичные данные? Что-то мне не кажется, что это хорошая идея…
Возможно, это один из вариантов со своими плюсами и минусами. А что бы предложили использовать вы?
Блин, писал-писал большой пост, но опера с хабром все съели. В общем кратко: в файловой системе на ряде серверов. Т.е. кроме основного сервера есть ряд серверов чисто со статикой на которых стоит nginx. Движок при формировании страницы смотрит на каком из серверов есть картика и формирует на неё ссылку. Причем копию одной картинки можно раскидать по разным сервера.
Плюсы:
+ балансировка нагрузки, одну картинку можно грузить с разных серверов для разных клиентов;
+ надежность, при падении одного из серверов нужная картинка может быть взята с другого;
+ маштабируемость, по сути каждый отдельный сервер независим и связаны они логически только внутри кода нашего движка, значит по ситуации можно удалять/добавлять серверы.
Минусы:
— бизнес логику всего этого еще нужно в приложении реализовать;
— проблемы с кэшированием страницы, если мы кэшируем страницы, то в кэше может оказать страницы с именем сервера который в настоящее время упал.
Эти минусы в приложении учесть можно. К примеру удалять из кэша те страницы, на которых упоминается упавший сервер. Но нужно понимать, что больше серверов, больше точек отказа. Больше серверов, больше время синхронизации, больше уходит ресурсов на актуализацию кэша. В конечном итоге латентность такой системы увеличиться на столько, что указанная схема будет уже не приемлема. Но, имхо, при современном железе нужно действительно имеет очеееень большой проект что бы упереться в невозможность дальнейшей работы.
Плюсы:
+ балансировка нагрузки, одну картинку можно грузить с разных серверов для разных клиентов;
+ надежность, при падении одного из серверов нужная картинка может быть взята с другого;
+ маштабируемость, по сути каждый отдельный сервер независим и связаны они логически только внутри кода нашего движка, значит по ситуации можно удалять/добавлять серверы.
Минусы:
— бизнес логику всего этого еще нужно в приложении реализовать;
— проблемы с кэшированием страницы, если мы кэшируем страницы, то в кэше может оказать страницы с именем сервера который в настоящее время упал.
Эти минусы в приложении учесть можно. К примеру удалять из кэша те страницы, на которых упоминается упавший сервер. Но нужно понимать, что больше серверов, больше точек отказа. Больше серверов, больше время синхронизации, больше уходит ресурсов на актуализацию кэша. В конечном итоге латентность такой системы увеличиться на столько, что указанная схема будет уже не приемлема. Но, имхо, при современном железе нужно действительно имеет очеееень большой проект что бы упереться в невозможность дальнейшей работы.
Все ваши плюсы уже есть «из коробки» в документных бд. Я не совсем вкурсе про CoachDB, но вот например MongoDB, даж имеет спец компонет GridFS. Настраиваете репликацию на несколько серваков, а все остальное оно само сделает.
На самом деле в вашем варианте главный плюс — скорость, как мне кажется. Всё-таки по чистой скорости отдачи статики с nginx мало что может сравниться, а с хорошо затюненным nginx и правильно-приготовленным дисковым кэшем — тем более. CouchDB пока не пришлось протестировать на скорость, но он будет медленнее, точно.
Однако, основной минус вашего варианта, на мой взгляд, в том что всю логику для масштабируемости системы, для балансировки, для обеспечения должной отказоустойчивости и т.д. придется реализовывать самостоятельно, на уровне бизнес-логики системы. Это не удобно, не гибко, не прозрачно для поддержки. С NoSQL же мы работаем с одним-единственным хранилищем (почти как с одной-единственной локальной файловой системой… ну может чуть сложнее :)), и наша система ничего не знает о том, где хранятся файлы, и как именно они будут отдаваться, это разруливается на уровне самого хранилища. Этот подход очень импонирует.
Ну и плюс, не надо забывать, что система не просто картинки раздаёт, а некоторым образом использует их в приложении, а значит для них неплохо было бы и где-то хранить мета-информацию (размеры, например), уметь объединять их в коллекции, и манипулировать целыми группами файлов. Тут NoSQL тоже даст дополнительные плюсы.
Однако, основной минус вашего варианта, на мой взгляд, в том что всю логику для масштабируемости системы, для балансировки, для обеспечения должной отказоустойчивости и т.д. придется реализовывать самостоятельно, на уровне бизнес-логики системы. Это не удобно, не гибко, не прозрачно для поддержки. С NoSQL же мы работаем с одним-единственным хранилищем (почти как с одной-единственной локальной файловой системой… ну может чуть сложнее :)), и наша система ничего не знает о том, где хранятся файлы, и как именно они будут отдаваться, это разруливается на уровне самого хранилища. Этот подход очень импонирует.
Ну и плюс, не надо забывать, что система не просто картинки раздаёт, а некоторым образом использует их в приложении, а значит для них неплохо было бы и где-то хранить мета-информацию (размеры, например), уметь объединять их в коллекции, и манипулировать целыми группами файлов. Тут NoSQL тоже даст дополнительные плюсы.
Нет, не скорость. Клиент будет забирать статику с той скорость, с какой позволяет ему канал и веб сервер. Поэтому для единичного клиента увеличения скорости тут не будет. Но такая схема позволяет обслуживать нам тысячи и десятки тысяч клиентов потребляя при этом не так уж и много ресурсов (если не ошибаюсь nginx на 10000 keep-alive клиентов израсходует всего лишь 2.5МБ).
То, что логику придется реализовывать самостоятельно можно считать как минусом так и плюсом. Плюсом потому что при необходимости можно эту логику в ходе работы изменять/модифицировать. Если это делать по предложенной схеме, то все реализуемо привычными вам средствами и значит не будет проблем в случае чего с поиском разработчиков. В случае же CouchDB вы уверены, что справитесь с ним или сможете найти разработчика для работы с ним?
Мне самому очень нравиться тот же Erlang, но я бы десять раз подумал, прежде чем выкатывать в продакшн CouchDB. Не нужно смотреть на такие системы как на панацею, они не решают чудесным образом все проблемы проекта. Я не говорю, что в вашем случае не стоит использовать CouchDB, может ему как раз там и будет место. Я просто призывая максимально трезво взглянуть на ситуацию, посмотреть CouchDB более детально, погонять его на тестовых установках под бэнчмарками и лишь только после решать, будет ли разумно переходить на него.
То, что логику придется реализовывать самостоятельно можно считать как минусом так и плюсом. Плюсом потому что при необходимости можно эту логику в ходе работы изменять/модифицировать. Если это делать по предложенной схеме, то все реализуемо привычными вам средствами и значит не будет проблем в случае чего с поиском разработчиков. В случае же CouchDB вы уверены, что справитесь с ним или сможете найти разработчика для работы с ним?
Мне самому очень нравиться тот же Erlang, но я бы десять раз подумал, прежде чем выкатывать в продакшн CouchDB. Не нужно смотреть на такие системы как на панацею, они не решают чудесным образом все проблемы проекта. Я не говорю, что в вашем случае не стоит использовать CouchDB, может ему как раз там и будет место. Я просто призывая максимально трезво взглянуть на ситуацию, посмотреть CouchDB более детально, погонять его на тестовых установках под бэнчмарками и лишь только после решать, будет ли разумно переходить на него.
Нет скорость, разумеется, имелась ввиду не скорость единичного клиента, как раз под большой нагрузкой преимущества и проявляются. И да, мы тоже любим nginx как и вы. :)
В целом, я с вами согласен, до продакшна ещё очень далеко, какое бы решение выбрано не было, и пока работаем с тем, что хорошо умеем готовить. Но при этом интересуют и другие success stories, нельзя зацикливаться не используемых технологиях. Скажем, MongoDB нам не очень подходит из-за того, что по-умолчанию очень не стабильно работает с виртуализацией, это не удобно для поддержки.
В целом, я с вами согласен, до продакшна ещё очень далеко, какое бы решение выбрано не было, и пока работаем с тем, что хорошо умеем готовить. Но при этом интересуют и другие success stories, нельзя зацикливаться не используемых технологиях. Скажем, MongoDB нам не очень подходит из-за того, что по-умолчанию очень не стабильно работает с виртуализацией, это не удобно для поддержки.
Насчет конкретно CouchDB ни чего не скажу, но у меня Erlang VM без проблем крутиться на VPS под OpenVZ и пока претензий к работе не было. Хотя ни чем серьезным я её и не нагружал, но о случаях нестабильной работы под виртуализацией даже слышать не приходилось. По крайне мере в официальной рассылке я подобных проблем у пользователей не видел.
Вот не пойму, в чём проблема поставить перед Коучем nginx с настроенным кэшированием?
Есть же Люстра и MogileFS.
Это очень удобно на практике. У меня так блогодвижок сделан (http://elfov.net/diary/, stereoblog.net/). Каждый пост — отдельный документ. Фотки в посте — аттачи в нем же (оригинальные и ресайзнутые). В итоге получается крайне удобно. А уж мигрировать с такой схемой — пальчики оближешь. Делаешь репликацию — и вся база, со всей статикой оказываетя на другом хосте.
а почему нет? одна из фич кауча, что он нативно хранит аттачменты и там же неплохо их сёрвит, т.к. в основе-то обычный HTTP-сервер.
хотя конечно специализированные легковестные веб-серверы могут отдавать статик контент быстрее, но тогда не получится так удобно поддерживать целостность между файлами и их метаинформацией, а всё придётся реализовывать ручками, неизвестно что будет более cost-effective.
хотя конечно специализированные легковестные веб-серверы могут отдавать статик контент быстрее, но тогда не получится так удобно поддерживать целостность между файлами и их метаинформацией, а всё придётся реализовывать ручками, неизвестно что будет более cost-effective.
На самом деле, среднестатистический веб-сайт гораздо лучше ложится на документо-ориентированную базу данных чем на SQL.
Минусующие — комментируем.
Мое видение: сайт — это набор страниц. Каждая страница — документ в couchdb. С тэгами, метатегами, заголовком, содержимым, аттачнутыми картинками, аттачнутыми скриптами. При запросе страницы мы читаем с диска всего несколько килобайт из одного места. Вместо JOIN'а из десятка таблиц, размазанных по всему диску.
Построить ленту сообщений — дергаем вьюшку (читается из кешированной view, без дерганья базы, без блокировки пишущих тредов).
Более сложные сайты в итоге на couchdb кладутся еще нативнее и работают еще лучше.
И это все без упоминания о беслатной master-master репликации. Настройте мне master-master в среднепопулярной СУБД!
Мое видение: сайт — это набор страниц. Каждая страница — документ в couchdb. С тэгами, метатегами, заголовком, содержимым, аттачнутыми картинками, аттачнутыми скриптами. При запросе страницы мы читаем с диска всего несколько килобайт из одного места. Вместо JOIN'а из десятка таблиц, размазанных по всему диску.
Построить ленту сообщений — дергаем вьюшку (читается из кешированной view, без дерганья базы, без блокировки пишущих тредов).
Более сложные сайты в итоге на couchdb кладутся еще нативнее и работают еще лучше.
И это все без упоминания о беслатной master-master репликации. Настройте мне master-master в среднепопулярной СУБД!
В кауч пока нету нативного шардинга, если он нужен (есть сторонние тулзы для этого), а в остальном, думаю, к вашей задаче подходит идеально.
cassandra или hibari, остальные из пробирки еще не выползали
По-моему такая парадигма давно напрашивалась… Конечно, революционна не сама идея, а то что они одни из первых начали делать такое. Управление через HTTP + файловые базы + клиентские системы. Наверно, каждый писал такой вот велосипед :).
UFO just landed and posted this here
У нас была рсубд и программа, в несколько потоков читающая и пишущая в нее. Когда количество записей в одной из таблиц начало перевалило за 300-400 тысяч, она начала зверски тупить (пытались безуспешно тюнить). Выражалось это то в локах (пока не update'нет, селекты ждут), то в нагрузке на перестройку индексов (когда сменили myisam на innodb).
В итоге перейдя на couchdb базу данных перестали видеть в top (mysql стабильно отъедал 100% проца), а количество рабочих процессов можно было поднять с теперешних 8-10 до 30-40 (дальше стали упираться в другие вещи, до потолка базы — очень и очень далеко). При этом и база постоянно растет. Со времени mysql (300-400 тыщ сущностей, повторюсь), база выросла до 3 миллионов и не показывает никаких регрессий. Собственно, база сейчас весит около 40 гигабайт (там еще бинарные аттачи в каждом документе, килобайт по 30-50, сами документы маленькие, с десяток полей + 1-2 сложных поля).
Т.е. скорость выросла как минимум на порядок как минимум.
При этом mysql приходилось долго и мучительно тюнить (8 лет жизни на него убил, итить), а с каучем результат был получен из коробки (любовь навеки).
В итоге перейдя на couchdb базу данных перестали видеть в top (mysql стабильно отъедал 100% проца), а количество рабочих процессов можно было поднять с теперешних 8-10 до 30-40 (дальше стали упираться в другие вещи, до потолка базы — очень и очень далеко). При этом и база постоянно растет. Со времени mysql (300-400 тыщ сущностей, повторюсь), база выросла до 3 миллионов и не показывает никаких регрессий. Собственно, база сейчас весит около 40 гигабайт (там еще бинарные аттачи в каждом документе, килобайт по 30-50, сами документы маленькие, с десяток полей + 1-2 сложных поля).
Т.е. скорость выросла как минимум на порядок как минимум.
При этом mysql приходилось долго и мучительно тюнить (8 лет жизни на него убил, итить), а с каучем результат был получен из коробки (любовь навеки).
Нужно было с PostgreSQL начинать с самого начала. А всякие MyISAM без транзакций, локов на всю таблицу… У него конечно есть сфера применения, но вы его явно использовали не на том месте.
Так о том и речь, что инструмент был неправильный.
Но вот я считал, что MySQL — достаточно подходящий инструмент, благо что опыта работы с ним — лет 8. А на деле оказалось, что все мои знания mysql — абсолютно не нужны и несчастный couchdb в дефолтных настройках уделывает на порядок mysql. Как и уделал бы postgre, пусть не на порядок. Потому что есть классы задач и есть инструменты и документ-оринтированные базы данных имеют право на жизнь там, где, казалось еще недавно, sql — самое подходящее.
Но вот я считал, что MySQL — достаточно подходящий инструмент, благо что опыта работы с ним — лет 8. А на деле оказалось, что все мои знания mysql — абсолютно не нужны и несчастный couchdb в дефолтных настройках уделывает на порядок mysql. Как и уделал бы postgre, пусть не на порядок. Потому что есть классы задач и есть инструменты и документ-оринтированные базы данных имеют право на жизнь там, где, казалось еще недавно, sql — самое подходящее.
Не совсем понял — зачем мап-редус если сервер не масштабируется? Я наверное не совсем понимаю что такое мап-редус, но я думал что это когда несколько серверов работает одновременно. В чем подвох?
в том что мап/редьюс позволяет инкрементно наращивать индексы, в т.ч. и результаты редьюса. если у вас какие-то сложные группировки, то при добавлении/изменении каких-то значений не придётся всё пересчитывать, а обновить можно будет инкрементно.
представьте себе вот хотите вы посчитать суммарные продажи в вашем интернет-магазине. общую сумму можно закешировать куда-нибудь и проблема решена, но что если по какому-то периоду? придётся проходить по всем значениям этого периода и считать. а кауч сможет взять результаты промежуточных редьюсов из дерева и сделать по ним ещё один редьюс, в итоге log2(n) против n элементов обрабатывать.
да и вобще, это удобный вариант работы с данными без схемы — зачем придумывать свой язык/апи с кучей ограничений, если можно писать на уже существующих языках с огромным кол-вом библиотек.
плюс если кауч не масштабируется сам по себе, то это не значит что его нельзя масштабировать самому, а вот тут мап/редьюс очень поможет ;)
представьте себе вот хотите вы посчитать суммарные продажи в вашем интернет-магазине. общую сумму можно закешировать куда-нибудь и проблема решена, но что если по какому-то периоду? придётся проходить по всем значениям этого периода и считать. а кауч сможет взять результаты промежуточных редьюсов из дерева и сделать по ним ещё один редьюс, в итоге log2(n) против n элементов обрабатывать.
да и вобще, это удобный вариант работы с данными без схемы — зачем придумывать свой язык/апи с кучей ограничений, если можно писать на уже существующих языках с огромным кол-вом библиотек.
плюс если кауч не масштабируется сам по себе, то это не значит что его нельзя масштабировать самому, а вот тут мап/редьюс очень поможет ;)
> Я наверное не совсем понимаю что такое мап-редус, но я думал что это когда несколько серверов работает одновременно. В чем подвох?
Это ортогональные понятия.
Простой пример — mysql работает хорошо, когда:
1. База помещается в память
2. Запрос работает только по индексу и не трогает базу.
В остальных случаях начинается резкое падение скорости.
В случае couchdb у тебя всегда либо
1. Требуемые данные находятся в дисковом кэше (врядли будет популярным сразу огромное количество документов, т.е. востребованные документы будут в дисковом кеше).
2. Все сложные запросы опрашивают view-функции, т.е. будут работать очень быстро и, что очень важно, не будут блокировать чтение-записть оригинальных документов.
Это ортогональные понятия.
Простой пример — mysql работает хорошо, когда:
1. База помещается в память
2. Запрос работает только по индексу и не трогает базу.
В остальных случаях начинается резкое падение скорости.
В случае couchdb у тебя всегда либо
1. Требуемые данные находятся в дисковом кэше (врядли будет популярным сразу огромное количество документов, т.е. востребованные документы будут в дисковом кеше).
2. Все сложные запросы опрашивают view-функции, т.е. будут работать очень быстро и, что очень важно, не будут блокировать чтение-записть оригинальных документов.
Давайте ибо сравнивать случай когда и база mysql в памяти, и у couchdb в дисковом кеше, либо когда ни та, ни другая не находится в кеше/памяти.
Потому как иначе такое сравнение не очень-то легитимно. Ведь дисковый кэш — это по сути та же память, а значит если на вашу БД хватает дискового кеша, то скорей всего хватило бы и памяти mysql-у (конечно, с оговорками, но все же). И наоборот — если не хватает памяти, то не хватит и кеша.
Потому как иначе такое сравнение не очень-то легитимно. Ведь дисковый кэш — это по сути та же память, а значит если на вашу БД хватает дискового кеша, то скорей всего хватило бы и памяти mysql-у (конечно, с оговорками, но все же). И наоборот — если не хватает памяти, то не хватит и кеша.
Только одна проблема — доступный объем оперативной памяти никак не сравним с доступным объемом дисковым кешем.
Мне так видится, что alexey_uzhva имеет в виду немножечко другой кэш, чем вам подумалось. Как я понял имеется в виду то кэш что в Linux, т.е. вся свободная ОЗУ.
> Давайте ибо сравнивать случай когда и база mysql в памяти, и у couchdb в дисковом кеше, либо когда ни та, ни другая не находится в кеше/памяти.
Давайте. В случае отсутсвия данных в кеше, у couchdb данные будут считаны быстрее, потому что собраны компактнее :)
> Потому как иначе такое сравнение не очень-то легитимно. Ведь дисковый кэш — это по сути та же память, а значит если на вашу БД хватает дискового кеша, то скорей всего хватило бы и памяти mysql-у (конечно, с оговорками, но все же). И наоборот — если не хватает памяти, то не хватит и кеша.
MySQL кроме непосредственно дискового кэша еще и сам по себе крайне активно память кушает. В couchdb просто нечему память есть в таких объемах (сортировок нету, join'ов нету, все что надо — читаем с диска из компактной области). Поэтому в условиях нехватки памяти couchdb будет вести себя гораздо лучше.
Давайте. В случае отсутсвия данных в кеше, у couchdb данные будут считаны быстрее, потому что собраны компактнее :)
> Потому как иначе такое сравнение не очень-то легитимно. Ведь дисковый кэш — это по сути та же память, а значит если на вашу БД хватает дискового кеша, то скорей всего хватило бы и памяти mysql-у (конечно, с оговорками, но все же). И наоборот — если не хватает памяти, то не хватит и кеша.
MySQL кроме непосредственно дискового кэша еще и сам по себе крайне активно память кушает. В couchdb просто нечему память есть в таких объемах (сортировок нету, join'ов нету, все что надо — читаем с диска из компактной области). Поэтому в условиях нехватки памяти couchdb будет вести себя гораздо лучше.
«едите вы в транспорте» — уж простите за занудство, но не ем в транспорте. Езжу бывает, да =) Просто резануло на фоне остального текста — который, кстати говоря, хорош ещё и в обозревательно-образовательном ключе.
А можно увидеть сайт, который использует эту базу? Причем использует не как один из компонентов типа мелкого виджета, а как основную базу.
На словах все звучит круто, но куда-то надо пихать бизнес-логику. На клиент — нельзя. В базу — тоже. Ставить промежуточный слой?.. Тогда в чем будет преимущество по сравнению с другими базами?
На словах все звучит круто, но куда-то надо пихать бизнес-логику. На клиент — нельзя. В базу — тоже. Ставить промежуточный слой?.. Тогда в чем будет преимущество по сравнению с другими базами?
Кстати, в случае использования CouchDB есть один огромный недостаток — структуру данных сайта приходится продумывать изначально, что бы писать красивые, эффективные view-функции. Это вам не mysql, где есть alter table, тут думать надо :-)
Та ну ладно, куча паттернов миграции и данных и схемы. То что вы сделали при помощи alter table, тож какимито данными надо заполнять так и тут.
а кто здесь мешает сделать «альтер тейбл» двумя строками кода? как раз для SQL структура намного более критична. и если она меняется, то приходится переписывать запросы и постоянно писать миграции. да и оптимизировать-то SQL приходится не меньше.
вобщем думать-то везде надо, но как по мне, так всё наоборот, в кауче можно намного меньше задумываться о структуре, если что, вьюха — не SQL, переварит. хотя конечно лучше когда всё элегантно, но это не всегда cost-effective.
вобщем думать-то везде надо, но как по мне, так всё наоборот, в кауче можно намного меньше задумываться о структуре, если что, вьюха — не SQL, переварит. хотя конечно лучше когда всё элегантно, но это не всегда cost-effective.
с MySQL тоже после alter table приходится переписывать запросы ;)
более того, если размер базы планируется в районе over 20GiB, то с составом view нужно определиться заранее иначе добавление новых будет достаточно тоскливой операцией.
Но лучше заранее продумывать шардинг.
более того, если размер базы планируется в районе over 20GiB, то с составом view нужно определиться заранее иначе добавление новых будет достаточно тоскливой операцией.
Но лучше заранее продумывать шардинг.
Так что вот едИте вы в транспорте…
наверное автор имел ввиду то что мы не кушаем в транспорте а перемещаемся в нем…
наверное автор имел ввиду то что мы не кушаем в транспорте а перемещаемся в нем…
Вообще, штука интересная, но вот такой наивный вопрос возник после беглого ознакомления: а как сделать в Коуче DELETE FROM table WHERE field = …?
Логотип у них не очень — при беглом взгляде кажется, будто человек в красную дырку провалился.
По теме — автору спасибо, для меня как-то что Couch, что MongoDB и иже — все на одно лицо… были :)
По теме — автору спасибо, для меня как-то что Couch, что MongoDB и иже — все на одно лицо… были :)
Господа, я тут уже совсем мозги сварил.
Что лучше для простого веб-приложения, в котором организуется доступ к документам (например, статьи являются doc-файлами и к ним есть развернутое описание и пропарсено в Lucene содержимое doc-файла) + конечно, есть простые страницы, комментарии и пр.?
Я имею в виду выбор между mongo и couch.
Что лучше для простого веб-приложения, в котором организуется доступ к документам (например, статьи являются doc-файлами и к ним есть развернутое описание и пропарсено в Lucene содержимое doc-файла) + конечно, есть простые страницы, комментарии и пр.?
Я имею в виду выбор между mongo и couch.
UFO just landed and posted this here
Кстати, CouchDB используется в популярном проекте Opscode Chef (configuration management software).
А можете в двух словах сказать, за счёт чего (и насколько) она fault-tolerant?
я правильно понимаю что сейчас (4 октября 2010) отсутствует нормальный пакет (с зависимостями и автозапуском) couchdb 1.0.1 для lucid/maverick?
Sign up to leave a comment.
CouchDB сегодня