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