16 практических советов по работе с CouchDB

    Где-то год назад при разработке нашего проекта мы дошли до некой точки развития, когда или начинается кропотливая настройка и оптимизация MySQL-сервера, или начинается опять же кропотливое изучение запросов, которые идут в БД. Так получилось, что именно тогда был бум статей про MongoDB, CouchDB и прочие NoSQL базы данных и соблазн попробовать их на живом проекте был крайне велик.

    При выборе главную роль сыграла фраза «CouchDB предназначен именно для веба», а также то, что для доступа не требовались никакие прослойки — доступ осуществляется по любимому мной REST, а API выглядит очень простым и изящным. Вдобавок к этому CouchDB имеет крайне удобный веб-интерфейс для администрирования Futon, чего на тот момент не было у MongoDB, а также железную устойчивость к падениям.

    Забегая вперед скажу, что выбор полностью себя оправдал — мы избавились от огромного количества проблем при разработке и проектировании БД, код проекта сильно упростился и стал гораздо лучше структурирован, но самое главное — тот самый поворот в сознании, который нам дал CouchDB. За это время я лично набил множество шишек при разработке и хотел бы поделиться опытом с Хабрасообществом. Эти советы не для начинающих — это советы по использованию CouchDB на живом production.


    Используйте больше баз данных


    Во многих пособиях для начинающих (в том числе CouchDB: The Definitive Guide) примеры выглядят очень красиво, но совершенно не сочетаются с жизнью. Суть в том, что как только количество ваших документов перерастает сколько-нибудь реальные масштабы, скажем 100000 документов в БД, разработка temporary views становится практически нереальной, поскольку серверу теперь уже нужно прошерстить все ваши документы на предмет соответствия map-функции. Плюс к этому, каждый map будет содержать что-то в таком роде:
    function(doc) {
     if (doc.type == 'photo') {
      ...
     }
    }
    что напоминает небольшой велосипед.

    Логика CouchDB такова, что при обновлении одного документа в БД это обновление «затрагивает» все выборки. То есть абсолютно все выборки обновят свои ETag при обновлении всего лишь одного документа. Это еще один минус использования множества документов с различными полями type в одной БД. В то же время обновление одного документа не затрагивает ETag, который будут отдавать другие документы этой БД, поскольку ETag'ами для документов служат их последние ревизии.

    Репликация должна происходить в одной локальной сети


    Именно репликация считается одним из конкурентных преимуществ CouchDB. Она запускается POST-запросом и может работает в фоне. На живом сервере выснилось, что процесс репликации успешно проходит только в локальной сети. Как только ваши сервера начинают находиться далеко друг от друга, то начинаются совершенно неотлавливаемые глюки, как например: обрыв соединения, невозможность получения изменений и прочее-прочее. При всем этом реплика может выдать сообщение в лог и спокойно делать вид, что все хорошо. Потому совет: реплицируйте данные только в одной локальной сети.

    Используйте нативные reduce-функции на Erlang


    Не изобретайте велосипедов. В документации в качестве примеров reduce-функций часто используются такие вещи:
    function (key, values, rereduce) {
      return sum(values);
    }
    Старайтесь избегать их и используйте нативные reduce, написанные на Erlang: "_count" и "_sum", которые к тому же работают горадо быстрее своих Javascript-аналогов.

    Трижды подумайте перед тем как использовать сложные reduce-функции


    Этот момент не освещен в документации, однако в ней говорится о том, что если вы не используете reduce-функции, то вполне возможно, вы очень много теряете. Reduce может вызывать саму себя при слишком большой выборке, порождая rereduce. Но в жизни все это теряет смысл как только ваша выборка становится чуть более сложной.

    В нашем проекте мы имеем базу comments, в которой храним комментарии. Каждый комментарий находится в отдельном документе, также в этом документе хранится город комментария (у нас российский портал, несколько городов), а также его т.н. принадлежность — поле belongs. Задача заключается в том, чтобы вывести N последних обсуждений. Если говорить языком MySQL, задача сводится к чему-то в таком духе:
    SELECT * FROM comments GROUP BY (belongs, city) ORDER BY timestamp
    Основная проблема выборки в CouchDB заключается в том, что она сортируется по ключу, а вперед нам необходимо выводить самые новые ветки обсуждений. Значит, группировку через group / group_level мы применить уже не сможем. Вот в этом месте мы и обратились к (re)reduce. Функция усечения выборки в конце выглядела так:
    function(key, values, rereduce) {
     if (rereduce) {
      var data = [], meta = [], record, tmp, index, total = [];

      for (var i in values) {
       for (j=0; j<values[i].length; j++) {
        record = values[i][j];

        tmp = record[2] + '_' + record[3];
        index = meta.indexOf(tmp);

        if (index === -1) {
         meta.push(tmp);
         data.push(record);
        } else {
         data[index][1] = Math.max(data[index][1], record[1]);
        }
       }
      }

      data.sort(function(a, b) {
       if (a[1] === b[1]) {
        return 0;
       }

       return (a[1] > b[1])
        ? -1
        : 1;
      });

      return data.slice(0, 7);
     } else {
      var output = [];
      for (var i in values) {
       output.push([values[i]._id, values[i].ts, values[i].belongs, values[i].city]);
      }

      return output;
     }
    }
    И все работало хорошо, но возникла проблема скорости обновления выборки. После занесения одного комментария, обновление этой выборки занимало 2 секунды на сервере с 4Гб памяти и процессором Athlon 64 X2 5600+ (ссылка). А при постоянном потоке комментариев постоянное провисание БД было недопустимо. Сейчас количество документов в БД — 22,000, в выборке — 258,000. Отсюда вывод: используйте мощные reduce-функции только при мощном сервере. В противном случае вся идея становится бессмысленной.

    Кэшируйте данные через ETag


    Получение данных через связку «If-Modified-Since / ETag» действительно быстрее простого получения данных примерно в 3 раза (синтетические тесты). Не забывайте о том, что когда вы используете заголовки If-None-Match, при статусе ответа 304 тело ответа всегда пустое, поскольку сервер подразумевает, что вы храните данные на своей в стороне. В нашем проекте для этих целей мы используем Memcached с небольшой простой оболочкой для работы с CouchDB (ссылка)

    Думайте в стиле CouchDB


    Thinking in CouchDB — отдельная, требующая вникания вещь. Мало написать парсер из %СУБД% в CouchDB, важно действительно привыкнуть мыслить в стиле CouchDB, и тогда все задачи будут восприниматься вами с совершенно иной точки зрения.

    Приведу простой пример. Есть события, которые проходят в какой-то промежуток времени. Если нам надо узнать в MySQL, какие события проходят именно сегодня, то мы пишем такой запрос:
    SELECT * FROM table_name WHERE UNIX_TIMESTAMP() BETWEEN start_timestamp AND finish_timestamp
    А теперь вернумся к CouchDB и вспомним о том, что в выборках нет такого понятия как текущее время. Все выборки формируются 1 раз, а в дальнейшем при изменении/создании/удалении документов в них они только обновляются. Соответственно мы имеем только документы и ничего больше. Важно понять, что вы должны составить выборку так, чтобы можно было передать в качестве ключа к ней какой-либо параметр. То есть вы можете только ограничить выборку по ключу. Решением этой задачи является составление выборки, в которой для каждого документа в выборку в качестве ключа попадут все дни, в которые проходит событие. А в дальнейшем чтобы получить все события, проходящие в этот день, вам будет достаточно обратиться к виду с ключом "?key=текущий_день"

    Почти все, что вы делаете на SQL, реализовывается на CouchDB гораздо проще и красивее


    Я лишь разбавлю этот псевдожелтый заголовок своим наблюдением 3-летней давности. В свое время мне довелось работать младшим программистом в фирме, штампующей сателлиты. На этих сайтах посещаемость была не больше 30 человек в день, но под каждым из них стоял мощный движок с преобразователем XSL-шаблонов на серверной стороне. Я даже не хочу объяснять, почему это глупо. Общая идея — вы всегда должны выбирать именно то средство, которое наиболее хорошо подходит к решению проблем. В случае саттелитов это простые html-страницы, которые может генерировать ваша CMS; в случае мощных порталов с большой посещаемостью это ни в коем случае не может быть бесплатная Joomla.

    Вернемся к заголовку. Не все программисты понимают как работает их код, а особенно как происходит взаимодействие с БД. Зачастую встречаются запросы, в которых есть огромное количество JOIN'ов для выборки простых данных, и даже EXPLAIN не поможет этому человеку определить, какая часть его запроса тормозит, поскольку весь запрос составлен без применения головы. Более того, на живом проекте все сводится к простым выборкам по PRIMARY KEY, все остальные запросы становятся обузой, а знания по составлению сложных SQL-запросов становятся бесполезными.

    В настоящий момент я глубоко убежден, что CouchDB позволяет начинающим программистам включать голову и не городить мощнейшие запросы только ради того, чтобы они работали. Удобство reduce-функций позволяет не писать глупые усечения данных, выбрасывая memory overflow. Почти все вещи, которые используются при работе простых сайтов с посещаемостью до 5,000 человек в день, гораздо красивей и проще реализовываются на CouchDB: получение страниц по URL, получение списка новостей, работа с гостевой книгой, фотогалереи и прочее. В то же время единственно возможная используемая кодировка UTF-8 избавит вас от множества вещей, о которых при разработке думать не нужно.

    Используйте утилиты для просмотра текущих действий


    Все текущие действия в CouchDB можно просмотреть. В MacOS утилита для работы с CouchDB называется CouchDBX. Похожая утилита есть и для Windows. Они запускают CouchDB-сервер на порту 5984 и позволяют смотреть текущие запросы к серверу в реальном времени. В Linux достаточно запустить сервер не в режиме демона (за это отвечает параметр -d в /usr/bin/couchdb) и все запросы будут выводиться в консоль.

    Также все текущие действия можно смотреть во вкладке «Status» в «Futon».

    Не используйте CouchDB для часто обновляемых данных


    У каждой вещи есть свои наиболее лучшие методы применения. У CouchDB к этим сторонам точно не относится работа с часто обновляемыми данными. Выборка же данных в CouchDB — это идеал. Почему так происходит? Когда обновляется один документ в БД, то ETag сбрасываются для всех выборок в БД. Это означает, что все они становятся невалидными, устаревшими. Для выборок это означает обновление и обновление их ETag при следующем вызове (т.е. min +1 запрос для всех выборок в БД). На уровне сервера это означает разрастание БД в размерах, с чем придется бороться с помощью операции Compaction.

    Не забывайте про Compaction


    Каждое обновление документа ведет к созданию его более новой ревизии. Также это ведет к регенерации выборок, в которых участвует этот документ (на регенерацию также влияют операции добавления и удаления документов) при их следующем вызове. Все старые ревизии сохраняются, и далеко не всегда вам необходимо иметь доступ к 600 ревизии документа, в то время как его нынешняя — тысячная. Размер БД растет, а место на сервере не всегда резиновое, поэтому не забывайте выполнять операцию compaction для видов и документов. Это сэкономит массу свободного места на дисках.

    Регенерация видов. Stale=update_after


    До релиза CouchDB версии 1.10 небольшой проблемой была выборка данных из несгенерированных видов. Для этого предлагалось использовать параметр «stale=ok» при выборе вида, а саму регенерацию видов повесить, допустим, в crontab. Начиная с версии 1.10 появился параметр «stale=update_after», который действует так же, как и «stale=ok», однако вызывает обновление вида после его получения. Вместе с простым получением данных вида, мы имеем все возможности для быстрой работы с даже сложными design-документами.

    Добавление или изменение вида на продакшн сервере влияет на соседние виды design-документа


    При добавлении вида в design-документ происходит его сборка. Это значит, что все время пока будет собираться вид (скажем, _design/list/_view/by_name), соседние с ним виды (скажем, _design/list/_view/by_age) будут недоступны. Не забывайте про это, когда добавляете вид на production-сервере.

    Устанавливайте из исходных кодов. Обновляйтесь чаще.


    Как многие уже привыкли, мэйнтейнеры Ubuntu/Debian не торопятся обновлять пакеты в репозиториях. Это значит, что в Ubuntu Maverick CouchDB имеет версию 1.0.1, а в Lucid так вообще 0.10, в то время как CouchDB давно включен в список приоритетных проектов Apache и все время развивается. Последняя версия на данный момент (1.10) содержит следующие вещи:
    • Нативная поддержка SSL
    • Список баз данных наконец-то отсортирован по алфавиту
    • Более точная поддержка ETag для видов (в обсуждении говорят, что выборки не будут менять свои ETag при обновлении документов, не входящих в них);
    • Поддержка CommonJS модулей в map-функциях (вспоминаем про NodeJS)
    • Опция «stale=update_after», которая действует так же, как и «stale=ok», однако вызывает обновление вида после его получения

    Полнотекстовый поиск


    Я говорил о том, что CouchDB подходит для многих задач, но не всех. Полнотекстовый поиск как раз попадает под это исключение. Поскольку мы не можем передать какой-либо параметр прямиком в вид, мы не можем искать что-то точно в БД. Поэтому вы не сможете организовать поиск на сайте, используя CouchDB. Есть различные решения этих проблем, но все это — велосипеды. Скажу честно — это не всегда так плохо: зачастую это позволяет вам понять, что захотят искать ваши посетители. Есть еще один важный момент: на малопосещаемом сайте поиск почти не нужен. А на большом портале поиск должен быть достаточно релевантным, что не позволит вам обойтись простыми LIKE/LOCATE-запросами.

    Простым решением данной проблемы является использование Поиска по сайту от Яндекса или Custom Search Engine от Google.

    Более сложным и цельным решением этой проблемы может стать использование отдельного поискового сервера. Это может быть Sphinx, Apache Solr, Lucene (есть связка couchdb-lucene, упомянутая в документации). По сути это тема для отдельной статьи, поэтому сейчас заострять внимание на этом не буду.

    Помимо этого вы должны четко отделять в голове полнотекстовый поиск и поиск по тэгам, хотя внешне по URL-адресам они похожи.

    Геопоиск


    Еще одной проблемой в CouchDB является геопоиск, например нахождение всех объектов в радиусе N метров. В SQL-подобных БД данная задача реализуется с помощью небольшой функции, которая позволяет по широте и долготе определить расстояние между двумя точками. В CouchDB мы имеем только одну шкалу сортировки в ключах, поэтому найти все точки, попадающие в квадрат — почти невыполнимо. Однако автор CouchDB в твиттере упомянул, что вы можете реализовать геопоиск точно так же, как он реализован в MongoDB, а именно с использованием идеи Geohash. заключается она в том, что любые координаты могут быть представлены в виде численно-буквенного хэша. При этом чем точнее указаны координаты, тем больше будет длина хэша. Таким образом, вы можете передавать геохэш в качестве ключа и варьировать его длину в параметрах startkey/endkey для уточнения радиуса поиска (конечно, это не совсем радиус). Реализаций geohash существует великое множество, вы всегда можете ознакомиться с ними или же написать свою.

    Бэкапы данных


    Бэкапы данных — одна из вещей в CouchDB, за который его стоит любить. Бэкапы делаются простым копированием файлов БД из директории /var/lib/couchdb. Помните, что копировать файлы можно только при выключенном сервере CouchDB, иначе все ваши файлы БД будут побитыми. Таким образом, общий порядок действий таков:
    1. выключаем CouchDB-сервер
    2. копируем нужные нам БД
    3. включаем CouchDB-сервер
    Репликация же осуществляется при работающем сервере. Файлы с расширением *.couch содержат все документы соответствующих баз данных. Директории .%database_name%_design содержат сгенерированные виды сооответствующих баз данных. Если вы не скопируете директории с видами, ничего страшного не будет: при первом запросе к видам, они будут сгенерированы на вашем компьютере.

    Не забывайте о том, что все файлы БД и видов должны принадлежать соответствующему пользователю CouchDB, поэтому проверяйте права файлов при копировании и устанавливайте их при необходимости через утилиту chown.



    Пост написан хабраюзером 1999 и опубликован по его просьбе.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 45

      +2
      При выборе главную роль сыграла фраза «CouchDB предназначен именно для веба»


      MongoDB Is Web Scale!!111
        0
        Этот лозунг значит несколько другое — его можно использовать без дополнительной сервисной прослойки ( couchapp.org/page/index )
          0
          Я все же думаю, что это говорилось не о CouchApp, а о самой идее REST-доступа к данным. Ведь не будете же вы делать энтерпрайз приложение, получающее данные через REST, а для веб-приложений такой подход выглядит вполне обоснованным.
          Еще один довод — доступ к attachments.
            0
            почему ентерпрайз нельзя сделать рест (и что вы под этим поразумеваете)
              0
              По той же причине — для каждой задачи есть свое решение. REST хорошо подходит для веба, но не очень для других задач. Чем гонять данные по http с постоянным оверхедом, лучше использовать хотя бы тот же MongoDB
                0
                это у вас не база пользователей случаем?
                  0
                  не понял :)
                    0
                    Пардон, не туда =(
            0
            habrahabr.ru/post/204392/
            для тех, кто не в курсе, вот перевод «MongoDB is web scale»
            0
            Отсутствие геопоиска решается установкой Geocouch.
            Использую его на mapchat.me/

            Если установить вот эту версию: rcouch.refuge.io/. Или версию от Couchbase: couchbase.com/ — он будет идти в комплекте.
              0
                +3
                Это выглядит интересно. Как там реализован геопоиск? Тоже через Geohash или есть какой-то свой механизм?
              0
              Мне вот интерестно, а никто не пробовал мускул под каллгриндом помучать?
                0
                > Используйте больше баз данных

                На практике (моей) обычно выходит так: есть некое количество сущностей, которое меняется редко и растут медленно и какое-то, которое меняется (растет) быстро (отличие на порядки). Соответственно, все редкоменяющиеся и нерастущие сущности я храню в одной базе данных (разделяю из по type), а быстрорастущие — в отдельные базы данных, по одной на сущность.
                  0
                  > Используйте утилиты для просмотра текущих действий

                  tail -f /var/log/couchdb/couch.log

                  > Бэкапы данных
                  > копировать файлы можно только при выключенном сервере CouchDB, иначе все ваши файлы БД будут побитыми

                  В общем, это не совсем правда. Бэкапить можно и при включенном. И файлы не будут побитыми, потому что структура базы данных подразумевает, что процесс couchdb может быть прибит в любой момент.

                  У меня в практике был момент, когда пришлось восстанавливать базу данных, попавшую на bad-секторы. Выяснив, какие документы база не может прочитать впринципе (валилась), я написал скрипт, игнорировавший эти документы. Все остальное скопировалось без проблем. Так что хранилище у них очень надежное.
                    +1
                    Отмечу две вещи:

                    + аттачменты. очень удобная штука, позволяющая хранить в документе (записи) дополнительные файлы. скорость отдачи, конечно, меньше, чем отдача простого локального файла, но масштабируемость, ETag-и и версионность побеждают данный недостаток. тем более, что можно эти файлы кешировать на баллансере (теми же нативными средствами nginx)

                    — compact. стоит всегда помнить о нем и делать относительно часто. на больших объемах базы couch просто падает. буквально сегодня у нас он завалился при компакте 22Gb базы (сжалась в 150Mb, хранилась версионность документов за последний месяц).
                      0
                      > — compact. стоит всегда помнить о нем и делать относительно часто. на больших объемах базы couch просто падает. буквально сегодня у нас он завалился при компакте 22Gb базы (сжалась в 150Mb, хранилась версионность документов за последний месяц).

                      Есть такая фигня. Старый файл базы долго удаляется и оно валится из-за таймаута. Какую файлуху юзаете? На XFS вроде не встречается такого.
                        0
                        ext3…
                        если база в полтора-два раза меньше, то сжимается нормально…
                          +2
                          Я им там постил баг
                          issues.apache.org/jira/browse/COUCHDB-1187
                          И там в комментах предложили патч. Сам не пробовал, после перехода на xfs проблема вроде бы исчезла.
                            0
                            спасибо

                            я, конечно, все равно подожду пока это релизнется. но вот зато не удивлюсь если данный патч так же решил бы проблему умирания кауча на точечном реплицировании большого количества данных.
                        +2
                        22Gb в 150Мб подразумевает, что это была или какая-то база для временных данных, или данные там часто обновлялись? У нас максимальный размер составляет примерно столько же, но после compaction так сильно не сжимается. Какая у вас версия CouchDB стоит кстати?
                          0
                          просто у нас определенная специфика:
                          1) ~3500 документов, каждый с 5-10 аттачментами. используются в качестве кеша
                          2) примерно 50-60 процентов обновляются ежедневно (грохаются все аттачменты) автоматически
                          3) примерно 2-3 процента обновляются в течении дня мануально (после обновления кешируемого документа аттачменты удаляются)
                          4) не компактим автоматом, потому что периодически приходится смотреть ревизии документов чтобы разобраться кто конкретно опубликовал или не опубликовал (сбросил или не сбросил кеш = удалил или не удалил аттачменты) определенные изменения

                          версия кауча 0.11.2
                            +2
                            Это гадание на кофейной гуще. После компакта база занимает столько, сколько занимают последние версии ее документов с аттачами плюс небольшой оверхед.

                            У меня вот есть база, за неделю вырастающая из 2 мегабайт в 20 гигабайт. После компакта опять 2 мегабайта. Всего лишь потому, что там фиксированное количество документов, меняющихся несколько раз в минуту, с номерами ревизий за миллион.
                              +1
                              1999 не может писать чаще, чем раз в час, поэтому попросил написать за него:

                              Именно об этом я и говорил в посте — CouchDB не подходит для часто изменяющихся данных. То есть решить задачу можно, но это уже изобретение велосипедов, и в других СУБД над реализацией этого даже не приходится задумываться. Именно поэтому я советую использовать CouchDB при частой выборке, но не частом обновлении.
                          0
                          Репликация отлично работает через WAN. Мы стабильно реплицируем в обе стороны данные между сервером в EC2, и сервером в Украине.

                          Для полнотекстового, и геопоиска можно использовать ElasticSearch с его CoudhDB river.
                            0
                            Репликация на какой версии couchdb? У меня (и в gentoo и в ubuntu) на couchdb 1.0.1 репликация падает на примитивной мелочи — обновление всего-лишь одного документа. На 1.1.0 этой проблемы нет.
                            +1
                            хорошая статья, спасибо.

                            стоит отметить про «все остальные запросы становятся обузой, а знания по составлению сложных SQL-запросов становятся бесполезными» — имхо, как раз знания по составлению сложных запросов позволяют делать такие схемы данных, где выборка достаточна по primary key почти всегда:)
                              +4
                              Я хотел поработать с CouchDB, но после этой статьи как-то стрёмно. Всё что она вроде должна обеспечивать она не делает. Полнотекстового поиска нет, много документов надо хранить в разных базах, бэкап по документации можно делать в любой момент, по статье надо базу останавливать, с репликацией вообще беда — может не состояться и отрапортовать об успехе, ставить надо из исходников последнюю версию — значит текущая версия будет скоро устаревшей и что делать?, база из 2-х мегабайт вырастает до 20-ти гигабайт и это считается нормой. А преимущества тогда в чём?

                              Наверняка стоит, конечно, поработать с ней чтобы понять преимущества по сравнению с хранением данных в postgres…
                                0
                                > Полнотекстового поиска нет

                                Не сказал бы, что это большой минус, мало где он есть из коробки.

                                >много документов надо хранить в разных базах

                                базы в кауче создается очень просто, можно хоть по базе на пользователя создавать (только бы прослойка это поддерживала, Couchrest::Model умеет например создавать базы на лету)

                                > бэкап по документации можно делать в любой момент, по статье надо базу останавливать

                                Так и можно. Автор, что-то напутал.

                                > с репликацией вообще беда — может не состояться и отрапортовать об успехе,

                                Первый раз слышу.

                                > база из 2-х мегабайт вырастает до 20-ти гигабайт и это считается нормой.

                                А в postgres есть хранение прошлых копий документа из коробки?
                                  0
                                  > можно хоть по базе на пользователя создавать
                                  ИМХО — во многих случаях где стоит применять couchdb, так и придётся делать.

                                  > Так и можно. Автор, что-то напутал.
                                  Да не совсем, особенно весело поднимать бекап на другой версии couchdb.

                                  > Первый раз слышу.
                                  bugs.launchpad.net/ubuntu/+source/couchdb/+bug/803567

                                  > А в postgres есть хранение прошлых копий документа из коробки?
                                  триггер на before update пойдёт?
                                    0
                                    >> можно хоть по базе на пользователя создавать
                                    >ИМХО — во многих случаях где стоит применять couchdb, так и придётся делать.
                                    не совсем. если проецировать реляционную модель на документ-ориентированную, то:
                                    база кауча = таблица в РСУБД
                                    документ кауча = строка из таблицы в РСУБД

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

                                    полностью мигрировать с РСУБД в кауч никто не предлагает.
                                  0
                                  Так и есть, все преимущества сводятся к RESTful JSON API.
                                  И вместо того что-бы написать SELECT * FROM comments GROUP BY (belongs, city) ORDER BY timestamp, обязательно надо соорудить 3-х этажную конструкцию…

                                    +1
                                    @RNZ: Я только скажу, что везде есть свои минусы и плюсы. Конкретно в CouchDB именно эта операция является не особенно красивой в отличие от того же SQL, но есть и простые преимущества, например та же нечеткая структура документов. Тут можно поспорить насчет плюсов и минусов.

                                    @Pilat: Я совершенно не хотел отпугнуть вас этой статьей. Но ведь наверняка и многие пользователи MySQL испугались при прочтении статей по настройке InnoDB. Версия 1.0.1 уже устойчива, а версия 1.10 лишь добавляет важные и приятные «плюшки». Вы можете спокойно пользоваться версией 1.0.1, как мы, и никаких минусов от этого не увидите.
                                    Полнотекстовый поиск, как верно написал andoriyu, нигде не реализован из коробки. Поиск с помощью LIKE едва ли вожно назвать полнотекстовым в его правильном понимании. А про то, что БД из 2М вырастает в 20Гб — ну это же слишком особые случаи, чтобы считать их нормой. В нашем случае БД вырастает в 2 раза больше своего размера примерно за 3 месяца. Ничего страшного в этом нет.

                                    @andoriyu: а тут вы не правы. Попробуйте скопировать файлы БД, когда в нее идет запись. Вот тогда и получится битая БД.
                                      0
                                      У меня в основном чтение, поэтому наверное ни разу не сталкивался. Кроме того в кауче такая простая репликация, что быстрее ее сделать.
                                        +1
                                        При чтении разумеется все должно пройти гладко, виды же не меняются. Про репликацию верно.
                                        0
                                        >Полнотекстовый поиск, как верно написал andoriyu, нигде не реализован из коробки.

                                        Во-первых, он такого не писал, во-вторых есть уже почти везде. Oracle, postgres, mysql — есть.
                                          0
                                          Что вы называете полнотекстовым поиском в MySQL? Может быть [sarcasm] LIKE-запросы или FULLTEXT-индексы? [/sarcasm]
                                            +1
                                            Думается мне, что имеется ввиду MATCH AGAINST и SOUNDEX.
                                              0
                                              Это сравнение велосипедов и мощных средств для поиска. SOUNDEX не сможет искать применительно к определенным морфологиям (привет stemming в sphinx), а MATCH AGAINST… Ну да какой смысл сравнивать поисковый движок и MATCH AGAINST?
                                              +1
                                              Да бог его знает что там так называется. Я в mysql не специалист, вот оно — dev.mysql.com/doc/refman/5.0/en/fulltext-search.html
                                                0
                                                все равно этим поиском вменяемо пользоваться невозможно: и медленный и кривой и не эффективный. поэтому станет вопрос в выборе внешнего поискового полнотекстового сервиса.

                                                если пользоваться MySQL, то Sphinx отлично подходит. если пользоваться CouchDB, то он замечательно интегрируется Apache Lucene
                                                  0
                                                  Да это как раз понятно. Непонятно из статьи зачем вообще пользоваться CouchDb.
                                                    0
                                                    Вам вбрасывать говно на вентилятор не надоело? Пользуйтесь тем, чем удобнее.
                                                      0
                                                      Потому что это нереляционная СУБД без жёсткой схемы. Говорят (с) на некоторых задачах ещё и на порядки шустрее популярных РСУБД.

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

                                      Самое читаемое