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

Question

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

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

Answer 1

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

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

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

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

Answer 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

Answer 3

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

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

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

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

Answer 4

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

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

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

Установка предела редакции документа на 10:
curl -X PUT -d "10" http://dbuser:dbpassword@127.0.0.1:5984/yourdb/_revs_limit

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