Pull to refresh

Comments 45

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

если пользоваться MySQL, то Sphinx отлично подходит. если пользоваться CouchDB, то он замечательно интегрируется Apache Lucene
Да это как раз понятно. Непонятно из статьи зачем вообще пользоваться CouchDb.
Вам вбрасывать говно на вентилятор не надоело? Пользуйтесь тем, чем удобнее.
Потому что это нереляционная СУБД без жёсткой схемы. Говорят (с) на некоторых задачах ещё и на порядки шустрее популярных РСУБД.
Only those users with full accounts are able to leave comments. Log in, please.

Articles