Реализовать для табличных частей и реквизитов свойство compress

[unpete]

архивировать при сериализации и разархивировать при получении с сервера

[leemuar]

Предлагаю более говорящее свойство: compress. zip может означать и почтовый индекс
А цель задачи в чем? Уменьшить размер передаваемых по сети данных?

[unpete]

А цель задачи в чем? Уменьшить размер передаваемых по сети данных?

Да, статистика, основанная на реальных данных крупных клиентов Заказа дилера показала, что экономия трафика и места на диске может достигать 7-10 раз. Экономия 800Gb на каждом терабайте, выглядит привлекательно.
С компрессией в направлении от сервера, хорошо справляется nginx, но в веб-приложении, трафик от клиента бывает в разы больше встречного.
А еще, couchdb будет меньше напрягаться при сериализации и десериализации строки в 10Kb в сравнении с массивом объектов в 100Kb.

[leemuar]

Поясните еще немного, пожалуйста, я до конца не понимаю задумку:

на стороне CouchDB табличная часть или реквизит будет храниться сжатым (обфусцированным)? т.е. поиск по такие реквизитам/табличным частям на стороне СУБД будет невозможен?

[unpete]

поиск [...] будет невозможен?

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

[leemuar]

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

И последний вопрос: какие примерно компоненты metadata.js предполагается менять для этой функциональности?

[unpete]

Только core - остальная часть никаких изменений не заметит.
Вообще, это задача с низким приоритетом - места на дисках пока хватает.