Файл CouchDB.view выходит из-под контроля?

Недавно я столкнулся с ситуацией, когда мой экземпляр CouchDB использовал все доступное дисковое пространство на экземпляре VM объемом 20 ГБ. После расследования я обнаружил, что в каталоге/usr/local/var/lib/couchdb/содержится куча файлов .view, самая большая из которых - 16 ГБ. Мне удалось удалить файлы *.view, чтобы восстановить нормальную работу. Я не уверен, почему файлы .view стали такими большими и как CouchDB управляет файлами .view.

Немного больше информации. У меня есть виртуальная машина Ubuntu 9.10 (кармическая) с 512 МБ и CouchDB 0.10. VM имеет задание cron, которое вызывает Python script, который запрашивает представление. Задача cron выполняется каждые пять минут. Каждый раз, когда запрос запрашивается, размер файла .view увеличивается. Я написал работу, чтобы следить за этим на почасовой основе, и через несколько дней я не вижу, чтобы файл перевернулся или каким-то другим образом уменьшился.

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

Ответ 1

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

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

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

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

Ответ 2

Что ваши файлы .view растут, каждый раз, когда вы получаете доступ к виду, это потому, что CouchDB обновляет представления при доступе. В представлениях CouchDB требуется уплотнение, например, базы данных. Если у вас часто происходят изменения в ваших документах, что приводит к изменениям в вашем представлении, вы должны время от времени запускать уплотнение представления. См. http://wiki.apache.org/couchdb/HTTP_view_API#View_Compaction

Чтобы уменьшить размер ваших просмотров, просмотрите данные, которые вы используете. Когда вы испускаете (foo, doc), весь документ копируется в представление, поэтому он очень мгновенно доступен, когда вы запрашиваете представление. функция (doc) {emit (doc.title, doc); } приведет к представлению размером с базу данных. Вы также можете испустить (doc.title, nil); и используйте параметр include_docs, чтобы позволить CouchDB извлекать документ из базы данных при доступе к представлению (что приведет к небольшому снижению производительности). См. http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options

Ответ 3

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

Да, couchdb очень голоден, и ему нужны регулярные компиляции. Но есть еще одна вещь, которая может помочь уменьшить использование этого диска, особенно иногда, когда это не нужно.

Couchdb использует деревья B + для хранения данных/документов, что является очень хорошей структурой данных для выполнения поиска данных. Однако использование B-tree торгует производительностью при использовании дискового пространства. С полностью случайным Id, B + -tree вентиляторы быстро. Поскольку минимальная заполняющая скорость составляет 1/2 для каждого внутреннего node, узлы в основном заполняются до 1/2 (поскольку данные распределяются равномерно из-за его случайности) генерируют больше внутренних узлов. Также новые вставки могут привести к перезаписи полного дерева. То, что может вызвать случайность;)

Вместо этого использование последовательных или монотонных идентификаторов может избежать всех.

Ответ 4

У меня тоже была эта проблема, попробовав CouchDB для игры на основе браузера.

В первый день запуска сайта у нас было около 100 000 неожиданных посетителей, и в течение 2 дней база данных CouchDB занимала около 40 ГБ. Это привело к сбою сервера, потому что HD был полностью заполнен.

Уплотнение привело к примерно 50 МБ. Я также установил _revs_limit (по умолчанию - 1000) на 10, так как мы не заботились о истории изменений, и с тех пор он отлично работает. После почти 1M пользователей размер базы данных обычно составляет около 2-3 ГБ. Когда я запускаю уплотнение, оно составляет около 500 МБ.

Ограничение срока действия документа до 10:
curl -X PUT -d "10" http://dbuser:[email protected]:5984/yourdb/_revs_limit

Или без пользователя: пароль (не рекомендуется):
curl -X PUT -d "10" http://127.0.0.1:5984/yourdb/_revs_limit