CouchDB сегодня



    Что такое CouchDB для вас? Вероятно любой, кто хоть немного интересуется популярной нынче темой NoSQL, прекрасно знает общие детали: это такая симпатичная игрушка с map/reduce-запросами, которые пишутся на JavaScript, с которой можно работать, гоняя JSON по HTTP-протоколу, а также не исключено, что слышали, что она fault-tolerant, тобишь не ломается вообще. Дальше этого обычно дело не идёт, в результате CouchDB отправляется в delicious в общую кучу со всякими MongoDB, Cassandra, Hadoop и т.п.

    Примерно такого мнения придерживался и я вплоть до недавнего времени, пока не возникла острая необходимость переосмыслить архитектуру текущего проекта (упёршегося лбом в свою реляционную БД) и пересесть на документную базу данных, которая бы умела map/reduce. После того, как более пристально взгялнул на CouchDB, я понял, что он уникален в своём классе, его не следует ставить в один ряд с упомянутыми продуктами. Идеи, которые заложены в CouchDB настолько концептуальны, что способны в корне перевернуть представление о разработке веб-приложений.

    О том, что же меня так впечатлило, постараюсь рассказать под катом.

    Сразу хочу сказать, что если вы уже имеете определённый опыт использования CouchDB, то, вероятно, что вы уже и сами «с усами» и эта статья не для вас. А вот что касается остальных, то может после прочтения появится желание и возможность прилечь на такой вот красный диван и расслабиться, как и рекомендуют разработчики Кауча.

    Следует сказать, что шумиха вокруг CouchDB вплоть до последнего времени несколько поутихла, на хабре нечасто проскакивают упоминания об этой БД, хотя за последний месяц твиттер буквально взорвался новостями о релизе CouchDB 1.0 и о выходе Cloudant из фазы закрытого Beta-тестирования (о чём я расскажу чуть подробнее ниже). Поиск говорит, что на хабре это событие толком-то и не было освещено, тогда как выход MongoDB 1.6 отметили отдельным постом. Такую несправедливость надо исправлять, так как если вы помните CouchDB как сырую альфу с медленными инсертами и бешеным потреблением памяти и процессора, то забудьте — это всё уже в далёком прошлом. На сегодняшний день это production-ready система с доступной комерческой поддержкой и реальными примерами использования в продакшне такими компаниями как BBC, например.



    Я не буду детально расписывать основные возможности, о которых вы при желании сможете прочитать на сайте проекта. Постараюсь рассказать о том, что для меня не было очевидно до тех пор, пока я не решился посмотреть на этот продукт поближе в результате чего не уделял этому продукту должного внимания, тогда как мог бы сэкономить себе кучу времени и нервных клеток.

    map/reduce


    Казалось бы, что здесь сложно кого-то чем-то удивить. Многие NoSQL базы данных используют именно эту парадигму доступа к данным, которые не имеют строго определённой схемы. Плюс ещё настораживает использования JavaScript для описания map/reduce-функций. Первое впечатление — это же должно быть страшно медленно, ведь как минимум map() необходимо выполнять для каждого документа в базе данных. Плюс ещё и движок-то SpiderMonkey — далеко не V8 по быстродействию. В чём же подвох?

    Зоркий глаз узреет, что вобще-то в CouchDB используется не map/reduce чистом виде, а т.н. incremental map/reduce. Вся идея заключается в том, что CouchDB не расчитывает свои представления (так называемые views — результаты выполнения функций вроде map() и reduce()) каждый раз. Это делается только при первом обращении к новому представлению, после чего результат спокойно индексируется и ID документов спокойно попадают в B+-дерево по нужному нам ключу с дополнительной информацией в узлах (а также результатами промежуточных редьюсов). Далее всё просто: когда в базу попадает новый документ (или изменяется старый) для него один раз вызывается map() после чего он кладётся в дерево индекса. Т.е. нет необходимости перерасчитывать индекс целиком, дерево просто инкрементно достраивается.

    Когда нам нужны результаты, Кауч просто отдаёт нам то, что уже посчитано заранее, нет необходимости заново обходить документы, выполняя map(). В отличие от того, чтобы проиндексировать несколько отдельных колонок для ускорения поиска, как делает большинство баз данных, мы проиндексировали все результаты запроса одним махом. Представьте себе MySQL, которому вобще не нужно «выполнять» запрос — он может сразу достать все его результаты из одного единственного индекса.

    Единственный аналог, который приходит в голову — это materialized views из «больших» РСУБД вроде Oracle, но только намного более легковесный. Не забывайте, что хранится только индекс результатов и только нужные вам значения — избыточность не такая уж большая по сравнению с обычными базами данных с кучей индексов, ведь индексируются только результаты map/reduce — те данные, которые вам нужны в контексте данного запроса, а не все колонки. Да и винты нынче дешёвые относительного того потенциала, который сулит этот метод.

    I need more power©


    Тот факт, что map() по сути выполняется один единственный раз для каждого нового/изменённого узла, очень интересен. Это позволяет выполнять довольно тяжёлые операции над новым документом, все равно это делается единожды. И если вам кажется, что со встроенным JavaScript рантаймом особо не разгонешься, то тут всплывает ещё одна интересная особенность CouchDB — на самом деле он не завязан ни на какой конкретный язык, а использует абстракцию в виде View-сервера. Т.е. вы просто подключаете view-сервер для вашего любимого языка программирования и пишите map() и reduce() например на Python, пользуясь его его богатой стандартной библиотекой.

    По большому счёту никто не мешает вам при добавлении нового документа прямо из map() осуществить геокодинг адреса вашего добавляемого в базу клиента с помощью внешнего сервиса (Google Maps API например) и посчитать для него геоиндекс другой внешней библиотекой. Или просто взять и проиндексировать ваш документ с помощью Sphinx, получив ещё и супербыстрый полнотекстовый индекс вашей БД (если недостаточно хорошей интеграции с Apache Lucene). Вобщем простор для творчества ограничен только фантазией.

    Если нужно больше скорости, то все ваши view-функции можно переписать на C, воспользовавшись тем фактом, что интерфейс view-сервера прост как лопата, а view в CouchDB — это точно такой же документ, а точнее design-документ со специальным ID. Поэтому ему совсем не обязательно содержать непосредственно код функций — можно положить туда в том числе любой идентификатор, который будет понятен вашему view-серверу. В общем заметно, что вот это идейное единство данных и инструкций по их обработке в виде точно таких же данных сродни идеологии Lisp.

    Пусть говорят, что map/reduce парадигма не обеспечивает такой мощи как SQL-запросы, но на практике просто нужно научиться мыслить её категорями. Так например заблуждение, что JOIN нельзя сделать без SQL, т.к. джойны не масштабируются и так далее. Это всё не лишено смысла, тем не менее заявление слишком общее. Во-первых документ можно содержать не только пары ключ-значение, но и коллекции, другие объекты и всё остальное, что можно описать пользуясь JSON, ну а во-вторых даже более сложные джойны можно реализовывать, зная основные паттерны — реализация map/reduce в CouchDB очень мощная и в то же время понятная и логичная.

    Веб, как он есть


    В отличие от большинства альтернатив, CouchDB разрабатывался в первую очередь как база данных для нужд веб-приложений. Отсюда корни такого нетривиального решения как доступ к базе через REST-интерфейс. Да, у HTTP в чистом виде, есть оверхэд, но он полностью компенсируется тем, насколько элегантным является это решение. Во-первых вам не нужно искать драйвер для любимого языка программирования — любой HTTP-клиент справится (все примеры — это чаще всего curl прямо из командной строки). Более того, таким клиентом может быть веб-браузер. Можно написать веб-приложение вобще не используя какой-либо middleware на сервере — с базой можно работать при помощи JavaScript через Ajax (например CouchApp — фреймворк на базе jQuery от создателей CouchDB).



    После старта Кауч ведёт себя словно обычный HTTP-сервер, вы можете зайти на него с помощью вашего браузера и выполнять GET-запросы просто используя строку адреса вашего браузера, получая JSON в качестве результата. А также сразу будет доступен Futon — административный интерфейс CouchDB-инстанса. Кстати он реализован полностью на JavaScript без серверного middleware, расширяем и умеет много всего интересного несмотря на свою простоту.

    Едва ли стоит говорить о том, что HTTP-протокол реализован правильно, поддерживается кеширование и Кауч знает когда отдать 304. Аналогично документ может содержать бинарные вложения (attachments — эквивалент (B)LOB), которые Кауч хранит нативными файлами и отдаёт просто как статический контент. Design-документы могут также содержать show() и list(), которые позволяют преобразовывать возвращаемые результаты как угодно, например в HTML-страницы и отдавать их непосредственно браузеру. И если ранее вы придерживались мнения, что хранить аватары пользователей и картинки от товаров вашего Интернет-магазина прямо в вашей [реляционной] БД плохо, то с CouchDB всё обстоит по-другому — иногда даже данные без жесткой схемы могут оказаться в определённых случаях более структурированными и целостными.

    Как известно, всё гениальное просто. В CouchDB масса таких вот несложных вещей, которые делались с расчётом именно на Веб-приложения, а не на абстрактные данные, которые необходимо как-то обрабатывать. В итоге всё выглядит настолько последовательно, что теперь даже непонятно, как это можно было сделать по-другому.

    Масштабирование


    О CouchDB раньше обычно говорили, что он не масштабируется. Действительно не так давно это было правдой, но только на половину. Обо всём по порядку.

    Одна из ключевых и самых интересных особенностей CouchDB — его репликации. Читатель возможно удивится, как репликации могут быть интересными в принципе, воспринимая их как своего рода костыль. В Кауче всё не так, его репликации проектировались изначально при создании БД. Во-первых они умеют master-to-master, что позволяет вам делать все инстансы одинаково функциональными, а не делить их на master/slave. Проблемой такой репликации в «обычных» базах данных являются потенциальные конфликты. Поэтому Кауч (обладающий свойсвом MVCC), при возникновении конфликта сохраняет все конфликтующие версии и умеет эти конфликты разрешать, по сконфигурированным правилам (либо отдать это дело в руки вашего приложения — как вы захотите этим воспользоваться, зависит только от вашей фантазии). Сама по себе репликация сводится к дёрганию URL из REST-ового API CouchDB (или вопрользовавшись Futon, можно просто ввести URL другой базы и клацнуть нажать кнопку) вот так вот это всё сложно.

    Так что вот едите вы в транспорте, пописываете что-то там во всякие твиттеры с вашего Nexus One (я разве не упомянул, что CouchDB полностью функционален на телефонах с Android, а также Maemo/MeeGo?), и тут въезжаете в туннель — коннект теряется. Вы можете спокойно продолжать пользоваться приложением, которое по возвращению коннекта сможет слить новые сообщения и залить то, что вы написали одним API-вызовом, не изобретая велосипедов. Например, если вы пользуетесь Ubuntu One, то вы уже используете CouchDB именно таким образом.



    Но не будем отвлекаться от темы. Такие репликации — это конечно хорошо (особенно в свете HTTP-природы CouchDB: можно поставить перед кластером Каучей обычный балансер и не переживать), но это не является «настоящим» масштабированием. Репликациями и реляционные БД умеют масштабироваться (хоть и далеко не так элегантно), а что насчёт шардинга? Ведь все хотят размазать данные по кластеру и просто путём добавления нода увеличить объём доступного дискового пространства, максимальную нагрузку, пиковое количество юзеров и так далее, не теряя при этом в скорости. CouchDB делать этого из коробки не умеет. Пока. Но это лишь вопрос времени.

    А вот Cloudant умеет. Cloudant — это новый сервис, который буквально пару дней назад завершил Beta-тестирование и теперь доступен каждому. Это хостинг вашей CouchDB-базы данных (на облаке от Amazon), а то и всего приложения, учитывая, что CouchDB может служить не только БД, но и middleware. Ребята воспользовались заложенным в CouchDB потенциалом, и развивают свой форк (который в скором времени имеет шансы стать частью транка), который неограниченно масштабируется шардингом, в который в любой момент можно добавить новый нод, также он обеспечивает избыточность — каждый документ хранится в трёх экземплярах на разных нодах на тот случай, если один из нодов отвалится. Более того, помимо полной поддержки стандартного API, Cloudant позволяет осуществлять map/reduce по результатам другого map/reduce и имеет ещё много интересных особенностей.



    Весь код открыт, так что можете поднять и использовать Cloudant на приватном облаке. А ещё можно зарегистрировать бесплатный аккаунт (до 250 мегабайт дискового пространства без учёта старых ревизий документов) и попробовать CouchDB вживую — все основные возможности доступны, в т.ч. Futon.

    Сегодня


    CouchDB в июле дорос до версии 1.0, чем разработчики подчёркивают его стабильность и готовность к production-использованию. Также релиз Cloudant является знаковым для всего CouchDB-комьюнити. Если вы ещё не пробовали Кауч, потратьте полчаса вашего времени — можете сэкономить намного больше времени в итоге, хотя это, конечно же, будет зависит от специфики вашего конкретного проекта. Продукт делает именно то, для чего он создавался, но не более. Так что не ждите чуда, но надеюсь, что после прочтения, кто-нибудь расслабится, как рекомендуют разработчики (особенно, если есть красный диван).
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 110
    • +2
      >это такая симпатичная игрушка с map/reduce на Javascript,

      Поправьте. На Erlang-о написан, на Erlang. Это даже видно на приведенном скриншоте.
      • +1
        Имелось в виду, что map/reduce в нём на Javascript, а не сам CouchDB — я конечно нечётко выразился, сейчас исправлю, спасибо. CouchDB-то конечно на Erlang написан.
        • 0
          Map/reduce можно и на Эрланге писать.
          • 0
            Можно, но это уже плагины, а плагинами там можно на куче языклв писать.
            • 0
              Хм, разве плагин нужен? Встроенные эрланговские функции типа _sum и _count можно вызывать и без плагинов, по крайней мере в 1.0.
              • +1
                Да вы правы, этот плагин уже давно идет предустановленным.

                >> 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
      • +1
        Прекрасный рисунок на тетрадном листе, серьёзно
      • +27
        Линк на статью твитнули разработчики Кауча. Оперативненько. Особенно понравилась формулировка :)

        • 0
          потрясающе. спасибо.
          буду курить-курить-курить)
          а нету где-нибудь чего-то вроде «CouchDB в примерах»?
          • +8
            есть довольно исчерпывающая книга от авторов изданная O'Reilly. правда по ссылке она на англ, не знаю переводилась ли. также много юзкейсов и примеров в вики.

            мне уже знакомые намекнули, что хорошо бы осветить что такое map/reduce вообще — если тема народу интересна, напишу отдельным постом.
            • +1
              интересна) сам уже гуглить думал )))
              • +1
                интересна, пишите.
                • +2
                  Тема интересна, только обычно ее объясняют на примере «неких абстрактных данных», а как это в жизни может пригодиться — непонятно. Хочется примеры приближенные к реальности, которые не очень хорошо решаются с помощью реляционных баз.
                  • 0
                    Сравняйте количество update с select, поднимите concurency и дайте базе вырости за пределы оперативной памяти :)
                • 0
                  Полистайте блог lrrr Map/Reduce своими руками — Apache CouchDb.

                  Может от сюда даже заглянет и чего скажет, как знать.
                • +2
                  и да, все-таки, на сколько он быстр? можно ли его сравнивать с тем же мускулем? понятно, что в 95% слчае делаются не высоконагруженные проекты, но тем не менее
                  • +3
                    как вам сказать, сравнивать не совсем корректно. в кауче любой запрос — это по сути вытаскивание десятка нужных вам значений из B-tree. Это очень быстро. Но не так быстро как могло бы быть, если бы кауч был написал на C и использовал бы какой-нибудь низкоуровневый бинарный формат через unix-sockets — но этого не будет, т.к. цели другие.

                    С другой стороны на MySQL совсем не сложно написать запрос, который поставит сервер на колени и будет считаться минуту, например, когда вам нужно собирать огромное количество разнородной информации с очень разной структурой и как-то аггрегировать, с использованием пользовательских фильтров :) А в коуче это будет сразу.

                    Вобщем как всегда всё очень зависит от конкретного приложения.
                    • +1
                      Не очень правильный пример про мускуль.

                      При таком запросе нужно часть просчетов и конкактенации данных выносить в middleware.

                      В CouchDB это сможет сделать сама CouchDB (каламбур, но так оно и есть)

                      Что выбрать — решать разработчику/системному архитектору. Подтверждаю — все зависит от задач.
                    • 0
                      Что б не повторятся.
                      habrahabr.ru/blogs/hi/85938/#comment_2569532
                    • +12
                      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 системы.
                      • +6
                        Да ладно, где без багов?

                        Что самое смешное в этом баге, его долго не могли найти из-за высокой стабильности CouchDB (да, смешно).

                        Баг воспроизводится так:
                        1. Создать документ с id X
                        2. Попытаться создать документ с таким же id (конфликт).
                        3. Создать документ Y.
                        4. Перезапустить базу.

                        Документ Y отсутствует. Бага наблюдается только если включены отложенные коммиты или не было принудительно коммита перед рестартом.

                        Фактически, если не рестартить базу (а зачем? Апгрейд обычно делается без рестарта, поднятием новой версии рядом и репликацией туда старых данных), то на баг напороться достаточно сложно. Собственно, первые сигналы поступали от windows-юзеров (ну и у кого больше аптайм? хехе), что как бэ намекает.
                        • 0
                          Я думаю с виндой штука в том, что она чаще используется как дев-машина. Я мускул запускаю для работы, а после — грохаю. Привычка такая. А аптайм у меня уже месяц с прошлых апдейтов. Увы XP на работе в рабочем режиме не всегда обновляется, а семёру пока не поставили.
                      • –6
                        >Что такое CouchDB для вас?
                        Пародия на MongoDB, если честно.

                        Но статья годная, благодарствую.
                        • +4
                          Холивор! Холивор!

                          А вот couchdb на эрланге написан, а у вас плюсы :-Р
                          • 0
                            Ну разработка кауча началась на несколько лет раньше.
                            • –3
                              Время весьма относительное явление в 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
                              • 0
                                при чем тут это?

                                я то, кстати, предпочитаю монго
                          • +2
                            Кстати, зря на JS наезжаете. Если view-функция не делает какой-то сложной арифметики, то 95% времени работы view-сервера будет сериализация и десериализация данных. Причем, JS-ный движок работает не медленнее python'овского. Я сравнивал python'овский view-сервер (с cjson) и дефолтный. Разница в скорости на пустых вьюшках была порядка 1-2% (база — примерно 2M документов).
                            • 0
                              > Причем, JS-ный движок работает не медленнее python'овского.

                              В смысле, JS-ный движок сериалиазции/десериализации.
                              • 0
                                согласен, я говорил как раз о случаях, когда вьюхи могут быть действительно тяжёлыми или когда хочется воспользоваться питоновскими библиотеками, которые есть на все случаи жизни.

                                скорость инсертов и тем более расчёта вьюх на самом деле не тот параметр на который нужно обращать внимание, если это критично для приложения, то кауч возможно не лучший выбор.
                                • 0
                                  Да, по части библиотек питону мало равных. Мне пока, к сожалению, не приходилось что-то сложное писать, да и надо следить, что б результат view-функция был детерминированным, что с увеличением внешних либ может стать затруднительным.
                              • 0
                                Статистика по быстродействию , по крайней мере доступная, совсем не радует.
                                • +2
                                  Вам мало 2000 инсертов в секунду? Это, собственно, не пик.
                                  • 0
                                    Увы… Но есть неплохие альтернативные решения… Например Redis.
                                    • +4
                                      Redis не является альтернативой. Разные возможности, как следствие — разный перформенс.
                                      • –2
                                        map/reduce нету, master-master нету. Вы уверены, что это альтернатива? Да и кауч никто не тестил толком на скорость… В последних версиях там как и в redis появилась отложенная запись, так что скорость должна значительно вырости.
                                        • +2
                                          в редисе есть репликация. нет разницы между мастер-мастер и мастер-слейв, все узлы равны
                                          • 0
                                            Если нет разницы между нодами, то это master-master, однако на сайте пишут про master-slave. Но я с redis не знаком, настаивать не буду.
                                            • 0
                                              ну просто впихнуть свои данные в другой нод — дело нехитрое. естественно о возможных конфликтах редис при этом не задумывается. так что мастер-мастер репликацией это конечно не является — данные то теряются.
                                              • +1
                                                Короче, достаточно простой key-value storage. Не конкурент, в общем :)
                                                • 0
                                                  не простой и не key/value сторадж.
                                                  • 0
                                                    > не простой и не key/value сторадж.

                                                    Под простотой я подразумевал отсутствие map/reduce.

                                                    «Redis is an advanced key-value store» — это у них на сайте.
                                            • 0
                                              Хм, я был уверен что если валится мастер нода, то слейвы автоматом не подымаются. Что-то поменялось? Можно линку где почитать?
                                              • 0
                                                сорри, там таки да. В общем — да, вы правы, все же мастер-слейв. Но при падении мастера на слейвах все остается, вопрос репликации от слейвов мастеру при поднятии открыт. Но репликация при наличии развитых систем снапшотирования и аппенд-оли лога является скорее для разнесения данных чем для обеспечения именно сохранности в случае падения.
                                          • 0
                                            Вам сессии хранить? Кауч тут не лучший выбор. Тут как раз memcacheddb/redis.
                                        • 0
                                          P.S. Да и с тех пор скорость инсертов несколько раз выростала (судя по changelog'ам).
                                          • 0
                                            смысл мерять только инсерты — это не является сильной стороной кауча. см. выше мой коммент про вьюхи.
                                          • +3
                                            А для чего лично вы используете CouchDB, если не секрет? Теория это хорошо, но уж очень бы хотелось почитать побольше реальных «success stories» использования CouchDB в живых приложениях, чтобы оценить преимущества относительно альтернативных решений.

                                            Мы сами сейчас присматриваемся к CouchDB как к варианту для создания кластеризуемого хранилища изображений (фотографии, иллюстрации к контенту, многочисленные превьюшки и т.д.). В таком контексте не приходилось её использовать?
                                            • 0
                                              как только будет паблик бэта — будет и success story, очень надеюсь :) это что-то вроде сайта-информера агрегирующего информацию по конкретному сектору промышленности с социальными фичами.

                                              данные очень разнородные и нужно формировать из них массу предопределённых фидов, поэтому map/reduce очень подходит. до этого была legacy-система на MySQL, которая стала слишком сложной и медленной. а с каучем сейчас расслабляюсь.

                                              относительно вашей области к сожалению ничего сказать не могу — не приходилось использовать в таком контексте, но выглядит довольно логично.
                                              • 0
                                                В таком случае удачи вам в создании публичной беты. Будем ждать продолжения статьи. :)
                                              • +1
                                                Пихать в CouchDB двоичные данные? Что-то мне не кажется, что это хорошая идея…
                                                • +1
                                                  Возможно, это один из вариантов со своими плюсами и минусами. А что бы предложили использовать вы?
                                                  • +4
                                                    Блин, писал-писал большой пост, но опера с хабром все съели. В общем кратко: в файловой системе на ряде серверов. Т.е. кроме основного сервера есть ряд серверов чисто со статикой на которых стоит nginx. Движок при формировании страницы смотрит на каком из серверов есть картика и формирует на неё ссылку. Причем копию одной картинки можно раскидать по разным сервера.

                                                    Плюсы:
                                                    + балансировка нагрузки, одну картинку можно грузить с разных серверов для разных клиентов;

                                                    + надежность, при падении одного из серверов нужная картинка может быть взята с другого;

                                                    + маштабируемость, по сути каждый отдельный сервер независим и связаны они логически только внутри кода нашего движка, значит по ситуации можно удалять/добавлять серверы.

                                                    Минусы:

                                                    — бизнес логику всего этого еще нужно в приложении реализовать;

                                                    — проблемы с кэшированием страницы, если мы кэшируем страницы, то в кэше может оказать страницы с именем сервера который в настоящее время упал.

                                                    Эти минусы в приложении учесть можно. К примеру удалять из кэша те страницы, на которых упоминается упавший сервер. Но нужно понимать, что больше серверов, больше точек отказа. Больше серверов, больше время синхронизации, больше уходит ресурсов на актуализацию кэша. В конечном итоге латентность такой системы увеличиться на столько, что указанная схема будет уже не приемлема. Но, имхо, при современном железе нужно действительно имеет очеееень большой проект что бы упереться в невозможность дальнейшей работы.
                                                    • +1
                                                      Все ваши плюсы уже есть «из коробки» в документных бд. Я не совсем вкурсе про CoachDB, но вот например MongoDB, даж имеет спец компонет GridFS. Настраиваете репликацию на несколько серваков, а все остальное оно само сделает.
                                                      • –1
                                                        GridFS это та фс где нет каталогов и создание файлов является экспериментальной фичей?
                                                      • 0
                                                        На самом деле в вашем варианте главный плюс — скорость, как мне кажется. Всё-таки по чистой скорости отдачи статики с nginx мало что может сравниться, а с хорошо затюненным nginx и правильно-приготовленным дисковым кэшем — тем более. CouchDB пока не пришлось протестировать на скорость, но он будет медленнее, точно.

                                                        Однако, основной минус вашего варианта, на мой взгляд, в том что всю логику для масштабируемости системы, для балансировки, для обеспечения должной отказоустойчивости и т.д. придется реализовывать самостоятельно, на уровне бизнес-логики системы. Это не удобно, не гибко, не прозрачно для поддержки. С NoSQL же мы работаем с одним-единственным хранилищем (почти как с одной-единственной локальной файловой системой… ну может чуть сложнее :)), и наша система ничего не знает о том, где хранятся файлы, и как именно они будут отдаваться, это разруливается на уровне самого хранилища. Этот подход очень импонирует.

                                                        Ну и плюс, не надо забывать, что система не просто картинки раздаёт, а некоторым образом использует их в приложении, а значит для них неплохо было бы и где-то хранить мета-информацию (размеры, например), уметь объединять их в коллекции, и манипулировать целыми группами файлов. Тут NoSQL тоже даст дополнительные плюсы.
                                                        • +1
                                                          Нет, не скорость. Клиент будет забирать статику с той скорость, с какой позволяет ему канал и веб сервер. Поэтому для единичного клиента увеличения скорости тут не будет. Но такая схема позволяет обслуживать нам тысячи и десятки тысяч клиентов потребляя при этом не так уж и много ресурсов (если не ошибаюсь nginx на 10000 keep-alive клиентов израсходует всего лишь 2.5МБ).

                                                          То, что логику придется реализовывать самостоятельно можно считать как минусом так и плюсом. Плюсом потому что при необходимости можно эту логику в ходе работы изменять/модифицировать. Если это делать по предложенной схеме, то все реализуемо привычными вам средствами и значит не будет проблем в случае чего с поиском разработчиков. В случае же CouchDB вы уверены, что справитесь с ним или сможете найти разработчика для работы с ним?

                                                          Мне самому очень нравиться тот же Erlang, но я бы десять раз подумал, прежде чем выкатывать в продакшн CouchDB. Не нужно смотреть на такие системы как на панацею, они не решают чудесным образом все проблемы проекта. Я не говорю, что в вашем случае не стоит использовать CouchDB, может ему как раз там и будет место. Я просто призывая максимально трезво взглянуть на ситуацию, посмотреть CouchDB более детально, погонять его на тестовых установках под бэнчмарками и лишь только после решать, будет ли разумно переходить на него.
                                                          • 0
                                                            Нет скорость, разумеется, имелась ввиду не скорость единичного клиента, как раз под большой нагрузкой преимущества и проявляются. И да, мы тоже любим nginx как и вы. :)

                                                            В целом, я с вами согласен, до продакшна ещё очень далеко, какое бы решение выбрано не было, и пока работаем с тем, что хорошо умеем готовить. Но при этом интересуют и другие success stories, нельзя зацикливаться не используемых технологиях. Скажем, MongoDB нам не очень подходит из-за того, что по-умолчанию очень не стабильно работает с виртуализацией, это не удобно для поддержки.
                                                            • 0
                                                              Насчет конкретно CouchDB ни чего не скажу, но у меня Erlang VM без проблем крутиться на VPS под OpenVZ и пока претензий к работе не было. Хотя ни чем серьезным я её и не нагружал, но о случаях нестабильной работы под виртуализацией даже слышать не приходилось. По крайне мере в официальной рассылке я подобных проблем у пользователей не видел.
                                                            • 0
                                                              Вот не пойму, в чём проблема поставить перед Коучем nginx с настроенным кэшированием?
                                                              • 0
                                                                Не проблема, только тред то немного о другом.
                                                          • 0
                                                            Есть же Люстра и MogileFS.
                                                        • 0
                                                          Это очень удобно на практике. У меня так блогодвижок сделан (http://elfov.net/diary/, stereoblog.net/). Каждый пост — отдельный документ. Фотки в посте — аттачи в нем же (оригинальные и ресайзнутые). В итоге получается крайне удобно. А уж мигрировать с такой схемой — пальчики оближешь. Делаешь репликацию — и вся база, со всей статикой оказываетя на другом хосте.
                                                          • 0
                                                            а почему нет? одна из фич кауча, что он нативно хранит аттачменты и там же неплохо их сёрвит, т.к. в основе-то обычный HTTP-сервер.

                                                            хотя конечно специализированные легковестные веб-серверы могут отдавать статик контент быстрее, но тогда не получится так удобно поддерживать целостность между файлами и их метаинформацией, а всё придётся реализовывать ручками, неизвестно что будет более cost-effective.
                                                            • +2
                                                              > хотя конечно специализированные легковестные веб-серверы могут отдавать статик контент быстрее

                                                              Далеко не факт. Mochiweb очень неплохой сервер.
                                                          • +5
                                                            На самом деле, среднестатистический веб-сайт гораздо лучше ложится на документо-ориентированную базу данных чем на SQL.
                                                            • +6
                                                              Минусующие — комментируем.

                                                              Мое видение: сайт — это набор страниц. Каждая страница — документ в couchdb. С тэгами, метатегами, заголовком, содержимым, аттачнутыми картинками, аттачнутыми скриптами. При запросе страницы мы читаем с диска всего несколько килобайт из одного места. Вместо JOIN'а из десятка таблиц, размазанных по всему диску.

                                                              Построить ленту сообщений — дергаем вьюшку (читается из кешированной view, без дерганья базы, без блокировки пишущих тредов).

                                                              Более сложные сайты в итоге на couchdb кладутся еще нативнее и работают еще лучше.

                                                              И это все без упоминания о беслатной master-master репликации. Настройте мне master-master в среднепопулярной СУБД!
                                                            • +1
                                                              В кауч пока нету нативного шардинга, если он нужен (есть сторонние тулзы для этого), а в остальном, думаю, к вашей задаче подходит идеально.
                                                              • 0
                                                                Тестирование покажет, но спасибо, это звучит обнадеживающе. :)
                                                              • 0
                                                                cassandra или hibari, остальные из пробирки еще не выползали
                                                              • +3
                                                                По-моему такая парадигма давно напрашивалась… Конечно, революционна не сама идея, а то что они одни из первых начали делать такое. Управление через HTTP + файловые базы + клиентские системы. Наверно, каждый писал такой вот велосипед :).
                                                                • +2
                                                                  Документ-ориентированные базы данных придуманы были очень давно. Называется — файловая система.

                                                                  На практике было много попыток на базе SQL сделать файловую систему, но природа взяла своё, появились нормальные решения, а SQL уйдет туда, откуда пришла — бухгалтерия.
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                  • +6
                                                                    У нас была рсубд и программа, в несколько потоков читающая и пишущая в нее. Когда количество записей в одной из таблиц начало перевалило за 300-400 тысяч, она начала зверски тупить (пытались безуспешно тюнить). Выражалось это то в локах (пока не update'нет, селекты ждут), то в нагрузке на перестройку индексов (когда сменили myisam на innodb).

                                                                    В итоге перейдя на couchdb базу данных перестали видеть в top (mysql стабильно отъедал 100% проца), а количество рабочих процессов можно было поднять с теперешних 8-10 до 30-40 (дальше стали упираться в другие вещи, до потолка базы — очень и очень далеко). При этом и база постоянно растет. Со времени mysql (300-400 тыщ сущностей, повторюсь), база выросла до 3 миллионов и не показывает никаких регрессий. Собственно, база сейчас весит около 40 гигабайт (там еще бинарные аттачи в каждом документе, килобайт по 30-50, сами документы маленькие, с десяток полей + 1-2 сложных поля).

                                                                    Т.е. скорость выросла как минимум на порядок как минимум.

                                                                    При этом mysql приходилось долго и мучительно тюнить (8 лет жизни на него убил, итить), а с каучем результат был получен из коробки (любовь навеки).
                                                                    • +2
                                                                      Нужно было с PostgreSQL начинать с самого начала. А всякие MyISAM без транзакций, локов на всю таблицу… У него конечно есть сфера применения, но вы его явно использовали не на том месте.
                                                                      • 0
                                                                        Так о том и речь, что инструмент был неправильный.

                                                                        Но вот я считал, что MySQL — достаточно подходящий инструмент, благо что опыта работы с ним — лет 8. А на деле оказалось, что все мои знания mysql — абсолютно не нужны и несчастный couchdb в дефолтных настройках уделывает на порядок mysql. Как и уделал бы postgre, пусть не на порядок. Потому что есть классы задач и есть инструменты и документ-оринтированные базы данных имеют право на жизнь там, где, казалось еще недавно, sql — самое подходящее.
                                                                  • 0
                                                                    Не совсем понял — зачем мап-редус если сервер не масштабируется? Я наверное не совсем понимаю что такое мап-редус, но я думал что это когда несколько серверов работает одновременно. В чем подвох?
                                                                    • +2
                                                                      в том что мап/редьюс позволяет инкрементно наращивать индексы, в т.ч. и результаты редьюса. если у вас какие-то сложные группировки, то при добавлении/изменении каких-то значений не придётся всё пересчитывать, а обновить можно будет инкрементно.

                                                                      представьте себе вот хотите вы посчитать суммарные продажи в вашем интернет-магазине. общую сумму можно закешировать куда-нибудь и проблема решена, но что если по какому-то периоду? придётся проходить по всем значениям этого периода и считать. а кауч сможет взять результаты промежуточных редьюсов из дерева и сделать по ним ещё один редьюс, в итоге log2(n) против n элементов обрабатывать.

                                                                      да и вобще, это удобный вариант работы с данными без схемы — зачем придумывать свой язык/апи с кучей ограничений, если можно писать на уже существующих языках с огромным кол-вом библиотек.

                                                                      плюс если кауч не масштабируется сам по себе, то это не значит что его нельзя масштабировать самому, а вот тут мап/редьюс очень поможет ;)
                                                                    • +1
                                                                      > Я наверное не совсем понимаю что такое мап-редус, но я думал что это когда несколько серверов работает одновременно. В чем подвох?

                                                                      Это ортогональные понятия.

                                                                      Простой пример — mysql работает хорошо, когда:
                                                                      1. База помещается в память
                                                                      2. Запрос работает только по индексу и не трогает базу.

                                                                      В остальных случаях начинается резкое падение скорости.

                                                                      В случае couchdb у тебя всегда либо
                                                                      1. Требуемые данные находятся в дисковом кэше (врядли будет популярным сразу огромное количество документов, т.е. востребованные документы будут в дисковом кеше).
                                                                      2. Все сложные запросы опрашивают view-функции, т.е. будут работать очень быстро и, что очень важно, не будут блокировать чтение-записть оригинальных документов.
                                                                      • 0
                                                                        Давайте ибо сравнивать случай когда и база mysql в памяти, и у couchdb в дисковом кеше, либо когда ни та, ни другая не находится в кеше/памяти.

                                                                        Потому как иначе такое сравнение не очень-то легитимно. Ведь дисковый кэш — это по сути та же память, а значит если на вашу БД хватает дискового кеша, то скорей всего хватило бы и памяти mysql-у (конечно, с оговорками, но все же). И наоборот — если не хватает памяти, то не хватит и кеша.
                                                                        • 0
                                                                          Только одна проблема — доступный объем оперативной памяти никак не сравним с доступным объемом дисковым кешем.

                                                                          • 0
                                                                            Мне так видится, что alexey_uzhva имеет в виду немножечко другой кэш, чем вам подумалось. Как я понял имеется в виду то кэш что в Linux, т.е. вся свободная ОЗУ.
                                                                          • 0
                                                                            > Давайте ибо сравнивать случай когда и база mysql в памяти, и у couchdb в дисковом кеше, либо когда ни та, ни другая не находится в кеше/памяти.

                                                                            Давайте. В случае отсутсвия данных в кеше, у couchdb данные будут считаны быстрее, потому что собраны компактнее :)

                                                                            > Потому как иначе такое сравнение не очень-то легитимно. Ведь дисковый кэш — это по сути та же память, а значит если на вашу БД хватает дискового кеша, то скорей всего хватило бы и памяти mysql-у (конечно, с оговорками, но все же). И наоборот — если не хватает памяти, то не хватит и кеша.

                                                                            MySQL кроме непосредственно дискового кэша еще и сам по себе крайне активно память кушает. В couchdb просто нечему память есть в таких объемах (сортировок нету, join'ов нету, все что надо — читаем с диска из компактной области). Поэтому в условиях нехватки памяти couchdb будет вести себя гораздо лучше.
                                                                            • 0
                                                                              >Давайте. В случае отсутсвия данных в кеше, у couchdb данные будут считаны быстрее,
                                                                              > потому что собраны компактнее :)

                                                                              Нет. В случае отсутствия данных в кэше (в кэше ОС) данные будут читаться с диска и тут скорость чтения будет зависеть от степени фрагментированности необходимого блока данных.
                                                                      • 0
                                                                        «едите вы в транспорте» — уж простите за занудство, но не ем в транспорте. Езжу бывает, да =) Просто резануло на фоне остального текста — который, кстати говоря, хорош ещё и в обозревательно-образовательном ключе.
                                                                        • 0
                                                                          А можно увидеть сайт, который использует эту базу? Причем использует не как один из компонентов типа мелкого виджета, а как основную базу.

                                                                          На словах все звучит круто, но куда-то надо пихать бизнес-логику. На клиент — нельзя. В базу — тоже. Ставить промежуточный слой?.. Тогда в чем будет преимущество по сравнению с другими базами?
                                                                        • 0
                                                                          Кстати, в случае использования CouchDB есть один огромный недостаток — структуру данных сайта приходится продумывать изначально, что бы писать красивые, эффективные view-функции. Это вам не mysql, где есть alter table, тут думать надо :-)
                                                                          • 0
                                                                            Та ну ладно, куча паттернов миграции и данных и схемы. То что вы сделали при помощи alter table, тож какимито данными надо заполнять так и тут.
                                                                            • +1
                                                                              я там забыл тэг irony, если шо.

                                                                              • +1
                                                                                Слишком уж похоже на правду. Ну да ладно, спишем на жару и познее время.
                                                                            • +1
                                                                              а кто здесь мешает сделать «альтер тейбл» двумя строками кода? как раз для SQL структура намного более критична. и если она меняется, то приходится переписывать запросы и постоянно писать миграции. да и оптимизировать-то SQL приходится не меньше.

                                                                              вобщем думать-то везде надо, но как по мне, так всё наоборот, в кауче можно намного меньше задумываться о структуре, если что, вьюха — не SQL, переварит. хотя конечно лучше когда всё элегантно, но это не всегда cost-effective.
                                                                              • +1
                                                                                эх, и я тоже повёлся…
                                                                              • 0
                                                                                с MySQL тоже после alter table приходится переписывать запросы ;)

                                                                                более того, если размер базы планируется в районе over 20GiB, то с составом view нужно определиться заранее иначе добавление новых будет достаточно тоскливой операцией.
                                                                                Но лучше заранее продумывать шардинг.

                                                                                • 0
                                                                                  Ты ломаеш статистику попавшихся в разрезе национальной принадлежности.
                                                                              • –2
                                                                                Так что вот едИте вы в транспорте…

                                                                                наверное автор имел ввиду то что мы не кушаем в транспорте а перемещаемся в нем…
                                                                                • 0
                                                                                  Вообще, штука интересная, но вот такой наивный вопрос возник после беглого ознакомления: а как сделать в Коуче DELETE FROM table WHERE field = …?
                                                                                  • +1
                                                                                    Возможно сделать view, который вернёт список id where field =… и все их удалить каким нибудь bulk запросом.
                                                                                  • 0
                                                                                    Логотип у них не очень — при беглом взгляде кажется, будто человек в красную дырку провалился.

                                                                                    По теме — автору спасибо, для меня как-то что Couch, что MongoDB и иже — все на одно лицо… были :)
                                                                                    • 0
                                                                                      Господа, я тут уже совсем мозги сварил.
                                                                                      Что лучше для простого веб-приложения, в котором организуется доступ к документам (например, статьи являются doc-файлами и к ним есть развернутое описание и пропарсено в Lucene содержимое doc-файла) + конечно, есть простые страницы, комментарии и пр.?

                                                                                      Я имею в виду выбор между mongo и couch.
                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                        • +1
                                                                                          Спасибо за такой развернутый ответ.)
                                                                                          Я покурил маны коуча и манго, в принципе, по крайней мере, в общих чертах они похожи в плане работы с БД, так что надо было просто решиться на что-то. Я выбрал Couch для изучения, т.к. он есть в пакетах ubuntu и есть симпотишный GUI.)
                                                                                          • 0
                                                                                            можно чуть подробнее насчет симпатичного GUI?
                                                                                            • 0
                                                                                              Так я про Futon говорю.) Он освещался в статье.
                                                                                      • 0
                                                                                        Кстати, CouchDB используется в популярном проекте Opscode Chef (configuration management software).
                                                                                        • 0
                                                                                          А можете в двух словах сказать, за счёт чего (и насколько) она fault-tolerant?
                                                                                          • 0
                                                                                            я правильно понимаю что сейчас (4 октября 2010) отсутствует нормальный пакет (с зависимостями и автозапуском) couchdb 1.0.1 для lucid/maverick?

                                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.