Компактизация

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

Во время компактизации CouchDB заново создаёт базу данных или представление в новом файле с расширением .compact. Поскольку для этого требуется примерно вдвое больше дискового пространства, CouchDB сначала проверяет наличие свободного места.

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

Начиная с CouchDB 2.1.1, автоматическая компактизация включена по умолчанию и описана в следующем разделе. При необходимости или желании всё ещё можно запустить компактизацию вручную. Это описано в последующих разделах.

Автоматическая компактизация

Демон автоматической компактизации CouchDB, известный внутри системы как «smoosh», запускает задания компактизации для баз данных и представлений на основе настраиваемых пороговых значений разреженности файла и общего объёма пространства, которое можно освободить.

Каналы

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

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

Важно помнить, что канал действует только на одном узле CouchDB: каждый узел поддерживает и обрабатывает собственный независимый набор компактизаций. Каналы бывают «ratio»-каналами или «slack»-каналами в зависимости от используемого для расстановки приоритетов алгоритма:

Ratio: для вычислений используется отношение sizes.file / sizes.active. Результат X должен быть больше некоторого настраиваемого значения Y, чтобы компактизация попала в очередь. Затем компактизации упорядочиваются по убыванию значения X.
Slack: для вычислений используется разность sizes.file - sizes.active. Результат X должен быть больше некоторого настраиваемого значения Y, чтобы компактизация попала в очередь. Затем компактизации упорядочиваются по убыванию значения X.

В обоих случаях Y задаётся с помощью переменной конфигурации min_priority. В CouchDB предварительно настроены четыре канала: по одному каналу каждого типа для баз данных и ещё два для представлений.

Конфигурация каналов

Каналы задаются с помощью блоков конфигурации [smoosh.{channel-name}] и активируются указанием имени канала в параметре конфигурации db_channels или view_channels в блоке [smoosh]. Конфигурация по умолчанию:

[smoosh]
db_channels = upgrade_dbs,ratio_dbs,slack_dbs
view_channels = upgrade_views,ratio_views,slack_views
cleanup_channels = index_cleanup

[smoosh.ratio_dbs]
priority = ratio
min_priority = 2.0

[smoosh.ratio_views]
priority = ratio
min_priority = 2.0

[smoosh.slack_dbs]
priority = slack
min_priority = 536870912

[smoosh.slack_views]
priority = slack
min_priority = 536870912

Каналы «upgrade» и «cleanup_channels» являются специальными системными каналами. Каналы «upgrade» проверяют, соответствует ли disk_format_version файла текущей версии, и ставят файл в очередь на компактизацию (что также обновляет формат файла), если это не так. Кроме того, upgrade_views ставит представления в очередь на компактизацию после обновления библиотеки сортировки (libicu). Канал «index_cleanup» используется для планирования заданий по удалению устаревших файлов индексов и очистке контрольного документа _local после обновления документов дизайна.

Ниже приведены дополнительные свойства, которые можно настроить для каждого канала; они описаны в API конфигурации

Окна планирования

Для каждого канала компактизации можно настроить выполнение только в определённые часы суток. Это поведение задаётся параметрами конфигурации from, to и strict_window, специфичными для канала. Например:

[smoosh.overnight_channel]
from = 20:00
to = 06:00
strict_window = true

где overnight_channel — имя канала, который требуется настроить.

Примечание: CouchDB определяет время в часовом поясе UTC (GMT), поэтому эти параметры необходимо указывать в UTC (GMT).

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

Примечание

При создании канала запускается таймер на 60 секунд, который проверяет, нужно ли обрабатывать компактизации канала с учётом временного окна, заданного в конфигурации.

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

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

Это означает, что в течение первых 60 секунд после выхода из временного окна, а также после создания канала, если текущее время не входит во временное окно, компактизации выполняются до 60 секунд. Это отличается от поведения старого демона компактизации, который сразу отменял компактизации.

Руководство по миграции

В предыдущих версиях CouchDB использовался более простой демон компактизации. Система конфигурации нового демона несовместима с предыдущей, поэтому пользователям с настроенными правилами компактизации потребуется перенести их в новую конфигурацию. Правила компактизации старого демона выглядели так:

[compaction_daemon]
min_file_size = 131072
check_interval = 3600
snooze_period_ms = 3000

[compactions]
mydb = [{db_fragmentation, "70%"}, {view_fragmentation, "60%"}, {parallel_view_compaction, true}]
_default = [{db_fragmentation, "50%"}, {view_fragmentation, "55%"}, {from, "20:00"}, {to, "06:00"}, {strict_window, true}]

Многие элементы этой конфигурации можно перенести в новую систему. Рассмотрим каждый из них подробнее:

min_file_size теперь настраивается отдельно для каждого канала с помощью параметра конфигурации min_size.
db_fragmentation эквивалентен настройке канала с priority = ratio и min_priority = 1.0 / (1 - db_fragmentation/100), после чего этот канал указывается в параметре конфигурации [smoosh] db_channels.
view_fragmention также эквивалентен настройке канала с priority = ratio и min_priority = 1.0 / (1 - view_fragmentation/100), после чего этот канал указывается в параметре конфигурации [smoosh] view_channels.
from / to / strict_window: каждый из этих параметров можно задать отдельно для каждого канала в новом демоне. Изменение поведения заключается в том, что новый демон при выходе из разрешённого временного окна приостанавливает компактизации, а не отменяет их, и возобновляет при повторном входе в окно.
parallel_view_compaction: для каждого канала компактизации задаётся параметр параллелизма, определяющий, сколько компактизаций будет выполняться в нём одновременно. Общий уровень параллелизма равен сумме значений параметров параллелизма всех активных каналов. Это отличается от прежнего поведения, при котором демон в каждый момент времени обрабатывал только одну базу данных и/или её представления (в зависимости от значения этого флага).

Параметры check_interval и snooze_period_ms устарели в событийно-ориентированной архитектуре нового демона. Новый демон не поддерживает настройку пороговых значений для отдельных баз данных, как в приведённом выше параметре mydb. Вместо этого каналы можно настроить для обработки определённых категорий файлов: больших баз данных, небольших индексов представлений и так далее. В большинстве случаев правила компактизации для именованных баз данных можно выразить через свойства этих баз данных и/или связанных с ними представлений.

Ручная компактизация базы данных

Компактизация базы данных сжимает файл базы данных, удаляя неиспользуемые разделы, созданные при обновлениях. Старые ревизии документов заменяются небольшим объёмом метаданных под названием tombstone, которые используются для разрешения конфликтов при репликации. Количество хранимых ревизий (и их tombstones) можно настроить с помощью конечной точки URL _revs_limit.

Компактизацию можно запустить вручную для каждой базы данных; она выполняется как фоновая задача. Чтобы запустить её для конкретной базы данных, необходимо отправить HTTP-запрос к подресурсу POST /{db}/_compact целевой базы данных:

curl -H "Content-Type: application/json" -X POST http://adm:pass@localhost:5984/my_db/_compact

В случае успеха сразу возвращается код состояния HTTP 202 Accepted:

HTTP/1.1 202 Accepted
Cache-Control: must-revalidate
Content-Length: 12
Content-Type: text/plain; charset=utf-8
Date: Wed, 19 Jun 2013 09:43:52 GMT
Server: CouchDB (Erlang/OTP)

{"ok":true}

Хотя тело запроса не используется, в запросе всё равно необходимо указать заголовок Content-Type со значением application/json. В противном случае будет возвращён ответ с кодом состояния HTTP 415 Unsupported Media Type:

HTTP/1.1 415 Unsupported Media Type
Cache-Control: must-revalidate
Content-Length: 78
Content-Type: application/json
Date: Wed, 19 Jun 2013 09:43:44 GMT
Server: CouchDB (Erlang/OTP)

{"error":"bad_content_type","reason":"Content-Type must be application/json"}

После успешного запуска компактизации сведения о ней можно получить через ресурс информации о базе данных:

curl http://adm:pass@localhost:5984/my_db

HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 246
Content-Type: application/json
Date: Wed, 19 Jun 2013 16:51:20 GMT
Server: CouchDB (Erlang/OTP)

{
    "committed_update_seq": 76215,
    "compact_running": true,
    "db_name": "my_db",
    "disk_format_version": 6,
    "doc_count": 5091,
    "doc_del_count": 0,
    "instance_start_time": "0",
    "purge_seq": 0,
    "sizes": {
      "active": 3787996,
      "disk": 17703025,
      "external": 4763321
    },
    "update_seq": 76215
}

Обратите внимание, что поле compact_running имеет значение true, указывающее на то, что компактизация действительно выполняется. Чтобы отслеживать ход компактизации, можно запросить ресурс _active_tasks:

curl http://adm:pass@localhost:5984/_active_tasks

HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 175
Content-Type: application/json
Date: Wed, 19 Jun 2013 16:27:23 GMT
Server: CouchDB (Erlang/OTP)

[
    {
        "changes_done": 44461,
        "database": "my_db",
        "pid": "<0.218.0>",
        "progress": 58,
        "started_on": 1371659228,
        "total_changes": 76215,
        "type": "database_compaction",
        "updated_on": 1371659241
    }
]

Ручная компактизация представлений

Представления также необходимо компактизировать. В отличие от баз данных, представления компактизируются группами в рамках каждого документа дизайна. Чтобы запустить их компактизацию, отправьте HTTP-запрос POST /{db}/_compact/{ddoc}:

Документ дизайна:

{
    "_id": "_design/ddoc-name",
    "views": {
        "view-name": {
            "map": "function(doc) { emit(doc.key, doc.value) }"
        }
    }
}

curl -H "Content-Type: application/json" -X POST http://adm:pass@localhost:5984/dbname/_compact/ddoc-name

{"ok":true}

Эта операция компактизирует индекс представления для текущей версии указанного документа дизайна. Возвращается код ответа HTTP 202 Accepted (как и при компактизации баз данных), после чего создаётся фоновая задача компактизации.

Очистка представлений

Файлы индексов представлений на диске именуются по их хешу MD5, вычисленному на основе определения представления. При изменении представления старые индексы остаются на диске. Чтобы удалить все устаревшие индексы представлений (файлы, названные по MD5-представлению определений представлений, которые больше не существуют), можно запустить очистку представлений:

curl -H "Content-Type: application/json" -X POST http://adm:pass@localhost:5984/dbname/_view_cleanup

{"ok":true}