Мне было интересно, почему моя база данных CouchDB быстро росла, поэтому я написал небольшой тестовый скрипт . Этот сценарий изменяет атрибут документа CouchDB 1200 раз и принимает размер базы данных после каждого изменения. После выполнения этих 1200 шагов записи база данных выполняет шаг сжатия , и размер дБ измеряется снова. В конце сценарий строит размер баз данных по номерам ревизий. Бенчмаркинг выполняется дважды:
- При первом использовании номера версии документа по умолчанию (= 1000) ( _revs_limit ).
- Во второй раз число редакций документа устанавливается равным 1.
При первом запуске получается следующий сюжет
первый запуск http://i46.tinypic.com/xayydw.png
Второй прогон производит этот сюжет
второй запуск http://i50.tinypic.com/2l92l8w.png
Для меня это довольно неожиданное поведение. На первом этапе я бы ожидал линейного роста, так как каждое изменение производит новую ревизию. Когда 1000 ревизий достигнуты, значение размера должно быть постоянным, поскольку более старые ревизии отбрасываются. После уплотнения размер должен значительно упасть.
Во втором запуске первая ревизия должна привести к определенному размеру базы данных, который затем сохраняется на следующих этапах записи, поскольку каждая новая ревизия ведет к удалению предыдущей.
Я мог бы понять, если для управления изменениями требуется немного накладных расходов, но такое поведение роста кажется мне странным. Кто-нибудь может объяснить это явление или исправить мои предположения, которые приводят к неправильным ожиданиям?