Skip to content

Instantly share code, notes, and snippets.

@v0ff4k
Created February 4, 2026 13:22
Show Gist options
  • Select an option

  • Save v0ff4k/2ee4ee0480253cb079953efa47506f84 to your computer and use it in GitHub Desktop.

Select an option

Save v0ff4k/2ee4ee0480253cb079953efa47506f84 to your computer and use it in GitHub Desktop.
3 review old imagestore

Шаг 1. Определить единый способ идентификации изображения

- Выбрать **устойчивый к изменениям "отпечаток"** (например, перцептивный хеш — pHash).
- Этот отпечаток должен вычисляться **одинаково** для любого изображения, независимо от того, старое оно или новое.
- Отпечаток — это **ключ для проверки дублей**.

Важно: все дальнейшие действия строятся вокруг этого отпечатка.


Шаг 2. Создать централизованное хранилище отпечатков

- Завести единый индекс (БД или специализированное хранилище), где:
- Ключ = отпечаток (pHash)
- Значение = факт существования (и, возможно, ID изображения)
- Это хранилище будет использоваться и для старых, и для новых изображений.

Цель: одна точка истины по дублям.


Шаг 3. Настроить обработку новых изображений (приоритет №1)

- Любое новое изображение:
  1. Вычисляет свой отпечаток.
  2. Проверяется сразу в едином индексе.
  3. Если отпечаток уже есть → отклоняется как дубль.
  4. Если нет → добавляется в индекс + сохраняется как новое.
- Эта логика всегда активна и имеет высший приоритет.

Новые изображения никогда не ждут окончания обработки старых.


Шаг 4. Запустить фоновую обработку старого архива

- Старые изображения обрабатываются пачками (например, по 1000 файлов).
- Для каждой пачки:
  1. Вычисляется отпечаток для каждого изображения.
  2. **Проверяется в том же едином индексе (как и новые!).
  3. Если отпечаток уже есть- пропускается (значит, уже есть в системе — возможно, как новое изображение!).
  4. Если нет -добавляется в индекс + помечается как "обработанное из архива".

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


Шаг 5. Обеспечить согласованность во времени

- Поскольку новые изображения могут прийти во время обработки старых, важно:
  - Не удалять и не пересоздавать индекс.
  - Использовать атомарные операции: "проверить + добавить, если нет".
- Это исключает гонку: даже если старое и новое изображение одинаковы и поступают одновременно, в индекс попадёт только одно.

Шаг 6. Отслеживать прогресс и избегать повторной обработки

- Вести список уже обработанных файлов из архива (например, по пути или хешу имени)(у меня был статус изображения).
- При рестарте — продолжать с последней точки.
- Не трогать файлы, которые уже прошли через систему.

Шаг 7. Гарантия завершения

- Обработка архива — фоновая, низкоприоритетная задача.
- Она может занять часы или дни — это нормально.
- Главное: **новые изображения всегда обрабатываются мгновенно и корректно**.
- После завершения — весь архив либо в индексе, либо пропущен как дубль.

TL-DR Итоговая логика в двух тезисах:

1. Единый индекс отпечатков — общая память системы, куда смотрят и старые, и новые изображения.
2. Новые изображения имеют приоритет и работают синхронно,  

старые — обрабатываются асинхронно, но через тот же индекс,
поэтому дубли между эпохами невозможны.

Такой подход масштабируем, отказоустойчив и логически целостен.

Работал над подобной задачей: на ~1.5 млн объявлений в одной категории и ~50млн записей в другой, каждое объявление 1-40 изоображений(10+в среднем). Делал перехеширование на новую структуру(perceptual_hash hamming_distance) и удаление неактуальных, так как файлы остались а записи в БД уже нет.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment