Комментарии 57
используете CouchDB, чтобы хранить документы с низкой продолжительностью жизни (сессии, лок-файлы, очереди)
Очень странное использование для этих целей в продакшене решения, которое никогда не претендовало на быструю запись. Redis не просто так ведь придумали, например.
Запись достаточно быстрая. А если хранить сессии в отдельной базе и без индексов, то вообще хорошо. Проблема с разрастающимся B+ деревом, а вот понять это до того как начнёшь манипулировать миллионами записей сложно.
CouchDB — не лучшее решение для очень динамических данных. Оно идеально для статистических обработок, где данные в прошлом не меняются, база не сжимается по 10 раз в неделю, но и тут обычно выносят оперативные данные в отдельную базу, а по уменьшению их актуальности реплицируют в общий котел, если не было сделано с самого начала, и удаляют её за ненадобностью. Партицирование и в RDBMS актуально, так и тут.
Тогда коуч работать будет быстро и действительно relax.
Тогда коуч работать будет быстро и действительно relax.
Это да. И работая с CouchDB 2 года, я могу сказать, что я до сих пор не знаю, есть ли такая ситуация, где нужно использовать именно CouchDB, а не другие базы.
wiki
Там нет такой информации. Там есть информация вида: когда не нужно использовать CouchDB и кто её использует. Однако если кто-то её и используют это совсем не означает, что она оптимальна для них.
Wiki — та самая ситуация, где нужно использовать именно CouchDB, а не другие базы. Я смотрел вовнутрь MediaWiki, DokuWiki и MoinMoin. Поверьте — это та самая ситуация :)
Вы имеете ввиду встроенное хранилище репликаций? Да это подходит для вики, пока кто-нибудь случайно не нажмёт compact. Кроме того, постоянные правки статей сделают вам большой облом, ибо пересчёт индексов для миллионов документов будет очень тормозить.
Возможно ревизий? Эти ревизии не предназначены для версионирования данных — нужно хранить либо инлайново, если нужна историческая индексация (и нам не важен размер документа), либо вложением. Сжимать базу не обязательно для потерь старых ревизий — первая же репликация убивает их в новой копии.
А при больших количествах обновлений обычно настраивают автообновление всех view функций, чтобы не было застоя и не тормозило.
А при больших количествах обновлений обычно настраивают автообновление всех view функций, чтобы не было застоя и не тормозило.
It depends. За 2 года CouchDB очень сильно изменился, но как минимум две задачи он решал и решает прекрасно: обработка больших массивов статистических данных во времени, при условии, что все map/reduce функции были заранее продуманы, и самодостаточные couchapp web-приложения.
Ждем окончательный выход на мобильные платформы — из андроид.маркета они как то быстро выпилились.
Ждем окончательный выход на мобильные платформы — из андроид.маркета они как то быстро выпилились.
Например когда нужен MVCC и репликация между удалёнными нодами через ненадёжные соединения. Ваш К.О.
Да и вобще, помимо «нужно» есть ещё «хочется» :)
Да и вобще, помимо «нужно» есть ещё «хочется» :)
Обязательно вставлять несвежие раковые рожи с 9gag.com, которые корнями уходят в древний АиБ-контент?
От этого статья тут же начинает выглядеть стильно, модно, молодёжно? Хабр стал филиалчиком фейсбука?
От этого статья тут же начинает выглядеть стильно, модно, молодёжно? Хабр стал филиалчиком фейсбука?
Я хотел передать ощущение. Если вы пришлёте мне ссылку на другие рожи с тем же смыслом, я с удовольствием поменяю.
НЛО прилетело и опубликовало эту надпись здесь
То есть теперь негативное отношение к тому, что является признаком современного сетевого разложения, называется «нонкомформизм». Ок.
> Не обязательно вставлять rage-faces, но, имхо, тут было всё к месту.
Я мог бы процитировать пункт 4 правил или упомянуть о том, что это в первую очередь серьёзный информационный ресурс, но видимо вы этого не поймете.
> Не обязательно вставлять rage-faces, но, имхо, тут было всё к месту.
Я мог бы процитировать пункт 4 правил или упомянуть о том, что это в первую очередь серьёзный информационный ресурс, но видимо вы этого не поймете.
4 пункт притянут за уши.
Во всём этом меня удивляет одно. Вы уверены, что эти рожи с «9gigs» или как там его, а не с форчана, где человек описывает неприятные аспекты работы его сантехники?
Я знаю об истоках этого мема, но между проблемой, годной статьи на хабре и комиксом по проблеме заливания филейной части тела брызгами из унитаза при дефекации мало общего. Когда-то они были контентом форчана. Теперь они являются контентом сетевых хомячков.
То есть в принципе, кроме популярности, изменилось немногое.
То есть в принципе, кроме популярности, изменилось немногое.
Не обращайте внимания на минусы. Вы всё правильно сказали.
Странно, почему они не ограничили время жизни удалённых записей. Если сделать это конфигурируемым параметром — то можно и по старой схеме работать (бесконечное время жизни), так и по-новой, удаляя их через, скажем, 10 дней. В этом случае запись может «воскреснуть», если реплики были разломаны и не синхронизировались дольше 10 дней, но, чаще всего, это разумная плата за повышение производительности.
Разработчики CouchDB понимают, что они живут не в идеальном мире. А в неидеальном мире программисты очень часто не дочитывают документацию. Вот и перестраховались.
В новых версиях есть compaction daemon, который при накоплении определенного буфера через заданный интервал времени в фоне сжимает базу, тем самым минимизируя нагрузку и сохраняя место. Все настраивается в конфиге.
Уважаемый автор, неплохо бы проверять грамматику перед постингом, интересная статья, но читать местами неприятно.
Шлите ошибки в личку, я проверял 2-мя утилитами, вроде всё ок. Если конечно вас не смущают буквы ё.
Проблема, в щедро рассыпаных, по всему тексту, запятых ;)
Если ужи показывать как не надо делать, то так:
Проблема, в, щедро, рассыпанных, по, всему, тексту, за, пятых ;,)
Проблема, в, щедро, рассыпанных, по, всему, тексту, за, пятых ;,)
>Проблема, в щедро рассыпаных, по всему тексту, запятых ;)
Деепричастных и причастных оборотов нет, основа (подлежащее и сказуемое) однп. Запятых в этом предложении не надо вообще.
Простите, чесслово, за оффтоп, нетрезвый.
В комментарии полез, чтобы узнать, куда чувачка с комикса убрали и почему вместо него рогатого поставили.
Деепричастных и причастных оборотов нет, основа (подлежащее и сказуемое) однп. Запятых в этом предложении не надо вообще.
Простите, чесслово, за оффтоп, нетрезвый.
В комментарии полез, чтобы узнать, куда чувачка с комикса убрали и почему вместо него рогатого поставили.
Нет, проблема, конечно, не в ё. А в тся/ться и опечатках, не думаю что какая-то утилита могла бы пропустить такое. А чем проверяли, как называются утилиты?
Плагин к Firefox, Libre office, Word. Вы бы пару ошибок в личку прислали, а то, что-то дальше обвинений дело не доходит.
Если я их Вам пришлю, то вопрос будет исчерпан, а мне хотелось бы сейчас понять какими утилитами не стоит пользоваться для исправления ошибок. А какая версия Word? Только что проверил у себя, всё отлично определилось. Не воспринимайте это как обвинения, это был не более чем совет проверять грамматику, а сейчас мне интересно вычеркнуть для себя ненадёжный в этом плане софт.
Бросьте, всё замечательно. Обвинения — фигня, знания, которыми Вы делитесь — всё.
Что происходит? То что база помечает документ как удалённый. Как она это делает? Она считывает документ, удаляет все поля из документа, вставляет дополнительное свойство _deleted:true и записывает документ под новой ревизией.
И это отлично. У CouchDB это одна из основных фишек.
Если WRITE у вас не самая редкая операция, то имея в дереве несколько миллионов документов вы неожиданно (причём именно неожиданно) можете обнаружить, что база начинает сильно тормозить. Например вы используете CouchDB, чтобы хранить документы с низкой продолжительностью жизни (сессии, лок-файлы, очереди).
Хранить в CouchDB документы с низкой продолжительность жизни — не лучшая для него задача.
А насчет тормозов вы имеете ввиду долгий ответ views при огромном количестве документов (милионы записей...)? Тогда stale=update_after в помощь, и будет он быстр даже на огромных колекциях.
>> А насчет тормозов вы имеете ввиду долгий ответ views при огромном количестве документов (милионы записей...)?
Не только, но также вставка новых записей.
Тогда stale=update_after в помощь, и будет он быстр даже на огромных колекциях.
Будет быстр, но процессор всё-равно будет постоянно их пересчитывать, а это потери.
Не только, но также вставка новых записей.
Тогда stale=update_after в помощь, и будет он быстр даже на огромных колекциях.
Будет быстр, но процессор всё-равно будет постоянно их пересчитывать, а это потери.
> И наконец, остаётся понять, насколько erlang быстр.
Тут проблема не в Erlang'е, а в архитектуре CouchDB.
Тут проблема не в Erlang'е, а в архитектуре CouchDB.
база users-lock, дальше можно не читать. Архитектурный изъян в твоем мозге.
Например, вы используете CouchDB, чтобы хранить документы с низкой продолжительностью жизни (сессии, lock-файлы, очереди).
каждый инструмент должен использоваться там, для чего он предназначен, можно и микроскопом гвозди забивать — неудобно, но это не значить? что это плохой инструмент…
в целом статья не плохая
Кстати, CouchBase содержит встроенный memcached, который позволяет хранить документы с низкой продолжительностью жизни в отдельной области.
нет ничего удивительного:
memcached, MemBase и CouchBase — это все дети от одной фирмы
По ссылке — binary tree на Erlang берет 1/41 времени от PHP :D
Ага — настолько разные что их производительность на Erlang будет отличаться в 41 раз чтобы аргумент статье придать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектурный изьян CouchDB