Перейти к основному содержимому

Хранение

Замер от: 2026-08-14 · чем проверено: ZAMER-BAZY-2026-08-14.md (живая база s3), сверка числа CREATE TABLE в DDL-снимках с табличным замером (186/27/16 — сходится) Для кого: кто добавляет таблицу, миграцию или чинит «куда делись мои данные». Читать до первой правки схемы.

Что делает​

Держит данные системы в MySQL на s3. В живом замере десять схем; рабочих — восемь и в них 364 таблицы, ещё две схемы тестовые и в этот счёт не входят. Схем raw и stage в живой базе нет (замер базы):

СхемаТаблицРод и состояние на 14.08
gwptd_intake186приём; живая
gwptd_kernel27ядро и витрины; живая
gwptd_monitoring16журналы и указатели; живая, девять таблиц пусты
gwptd_next_app23хозяйство Laravel; живая, к данным площадок отношения не имеет
gwptd_core32товарный мастер 1С и склад; наполнена, заморожена на 05.08
lamoda_reports65старый контур, имя историческое; заморожена
s2_ref9зеркало s2; заморожено на 02.07
s20_ref6зеркало s20; живое
gwptd_kernel_test10тестовая, в рабочий счёт не входит
gwptd_intake_test13тестовая, в рабочий счёт не входит

Львиная доля приёма — gwptd_intake.raw_payload (8 134 349 строк, 14 198 МБ) плюс payload_lineage_receipt (3 942 697 строк): вместе 67 % объёма схемы приёма.

Точка входа в код​

scripts/deploy/deploy-s3-next.sh — единственное место, по которому видно, какие миграции действительно применяет выкладка. Сами миграции лежат в marketplace-collector-v3/kernel/schemas/migrations/, а отражение живой структуры — в docs/domain/data-model/ddl/.

Чем задаётся​

Проверенное изменение трёх V3-схем — gwptd_intake, gwptd_kernel и gwptd_monitoring — обязано идти миграцией, которую поимённо применяет выкладка. Это не делает миграции единственным источником DDL: CREATE TABLE IF NOT EXISTS ещё есть, например, в wb_analytics.py и refresh_onec_warehouse_stock.py, а у остальных схем свои писатели и жизненный цикл. Наполнение дают СБОР, РАЗБОР и служебные задачи. Три поддерживаемых снимка docs/domain/data-model/ddl/gwptd_*.sql сняты вручную с боевого сервера командой mysqldump --no-data --skip-dump-date --skip-triggers: 14.08 их освежили, и по числу таблиц они совпали с живой базой; прежние снимки не знали о 89 таблицах (замер карты). Штатного порождателя именно этих трёх раздельных файлов нет. refresh-schema-snapshot.sh существует, но создаёт один общий снимок в другом месте и эти файлы не обновляет; поэтому они протухают молча.

Какие правила обязан соблюдать​

  • 14 триггеров держат односторонность записей. Восемь в приёме (marketplace-collector-v3/kernel/schemas/migrations/2026-07-16_writer_trust_boundary.sql): trg_collection_run_state_guard разрешает связать договор запроса и затем один раз запечатать прогон (:234-290), а trg_collection_run_receipt_no_delete запрещает удалять только прогоны с версионным договором (:293-301). trg_payload_lineage_state_guard допускает ровно одно терминальное запечатывание происхождения (:304-328); ещё пять триггеров запрещают удалять расписку происхождения и менять либо удалять расписки и события справочных снимков (:331-373). Имена всех восьми проверяет marketplace-collector-v3/tests/test_intake_writer_trust_boundary.py:206-225. Шесть триггеров ядра находятся в marketplace-collector-v3/kernel/schemas/migrations/2026-07-16_kernel_publication_receipt.sql: попытка создаётся только в состоянии prepared без итоговых полей (:154-171), затем допускается один переход в activated или failed; при активации проверяются манифест, последовательность шагов и итог строк (:174-562). Удалять попытку нельзя (:565-572), но её единственное терминальное обновление разрешено — поэтому называть весь журнал полностью неизменяемым нельзя. Расписка принимается только для точно совпавшей активированной попытки (:575-617), после чего её нельзя менять или удалять (:620-637).
  • Две тестовые схемы пересоздаёт прогон golden-тестов. Фикстура harness вызывает reset_schemas() перед каждым таким тестом (marketplace-collector-v3/tests/kernel_golden/conftest.py:62-66). Имена по умолчанию gwptd_kernel_test/gwptd_intake_test задаёт marketplace-collector-v3/tests/kernel_golden/harness.py:175-176, а сам reset_schemas() удаляет и создаёт обе схемы заново (:227-241). Эти имена в исполняемом коде проекта использует только тестовый харнесс; отдельной плановой службы их обслуживания в дереве нет.
  • Миграции вписываются в выкладку поимённо: scripts/deploy/deploy-s3-next.sh (нельзя добавить файл и забыть упомянуть).
  • Статусы и формулы — INTAKE-RAZBOR-STATUS.md, DO-NOT-REGRESS.md; связь описаний и схемы приёма — check_intake_schema_contract.py.
  • Зеркала нельзя менять вручную: s20_ref обновляет штатная синхронизация, s2_ref заморожено; S2 в целом неприкосновенен (RULES.md).

Чем проверяется​

  • grep -c 'CREATE TABLE' docs/domain/data-model/ddl/gwptd_intake.sql docs/domain/data-model/ddl/gwptd_kernel.sql docs/domain/data-model/ddl/gwptd_monitoring.sql — 186/27/16, сходится с tsv-замером (прогнал 14.08).
  • python3 scripts/docs/check_doc_links.py — проверяет, что пути со страницы существуют; общий результат следует читать пофайлово, потому что проверка охватывает весь репозиторий.

Чего делать нельзя​

  • Выдавать снимки DDL за автоматически свежие: порождателя трёх поддерживаемых файлов нет, их соответствие живой базе доказывает только новый замер.
  • Забывать вписать новую миграцию в deploy-s3-next.sh — на s3 она не применится.
  • Менять вручную замороженную lamoda_reports и зеркала; S2 доступен только для чтения.

Что НЕ установлено​

  • Свежесть данных внутри таблиц и заполненность колонок — не замерено.

Куда за подробностью​