Хранить сырые ответы или только разобранное

Спор с напарником, третий день идёт. Я складываю ответы сайта как есть, потом разбираю их отдельным шагом. Он говорит, что это лишний диск и лишний шаг, и предлагает разбирать прямо в момент запроса, а на диск писать готовые поля.

Аргумент у него простой: сырьё за месяц набирает под двести гигабайт, и никто в него ни разу не заглядывал.

Мой аргумент: когда разметка поедет, из готовых полей я прошлое не восстановлю, придётся ходить заново по всему каталогу.

Кто как живёт? Интересуют цифры с рабочих прогонов, вкусовщину можно опустить.

Храню сырьё. Ровно по твоему аргументу.

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

Тоже храню, но не всё подряд. Товарные карточки да, а списки и навигацию выбрасываю сразу после того, как из них вынуты адреса. Списки восстанавливаются дёшево, карточки дорого.

Двести гигабайт это потому, что вы храните HTML как есть.

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

Двести гигабайт превращаются в двадцать пять. Спор про диск после этого обычно заканчивается.

Про сжатие поштучно понял. А если сложить тысячу карточек в один архив, будет ещё лучше? Шаблон-то у них общий.

Будет, и заметно: общий словарь ловит повторы между файлами. У меня пачка из тысячи карточек в общем архиве весит примерно вдвое меньше, чем те же карточки, сжатые по одной.

Минус в том, что достать одну карточку из середины архива тяжело. Поэтому я держу пачки по дню и по домену: файл 2-fevralya-shop-a.tar.zst, внутри карточки за день. Нужно перебрать день, распаковываешь поток и читаешь на лету, не разворачивая на диск.

а зачем вообще держать html, если можно сохранять json с полями и рядом кусок html только того блока, откуда берутся поля?

Так тоже делают, и это разумная середина. Только режьте с запасом: берите всю карточку товара целиком, вместе с соседними блоками. Иначе через месяц вам понадобится поле, которого в вырезке нет, и вы опять пойдёте на сайт.

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

Добавлю про то, чего в споре обычно не хватает: сырьё окупается не только при переезде разметки.

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

Второе. Разбор редко получается верным с первого раза. У меня нормальная жизнь правила такая: написал, прогнал по сохранённой тысяче ответов, увидел, что на трёх сотнях выходит пусто, поправил, снова прогнал. Это цикл в пару минут. Если каждый круг требует ходить наружу, вы либо перестаёте править разбор, либо ловите бан.

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

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

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

Остался вопрос по схеме хранения: класть пачки на обычный диск или сразу в объектное хранилище?

Начните с диска, пока объём в пределах машины. Объектное хранилище имеет смысл, когда прогонов несколько и они на разных серверах.

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

Спор закрыт, спасибо всем.