Simplenaut & VioletRook
Если бы тебе пришлось создавать систему хранения доказательств в минималистичном стиле, чтобы ускорить поиск и сохранить всё в чистоте, какое первое правило ты бы сформулировал?
Одно правило: складывай все улики в одну папку с уникальным названием, никаких дубликатов, чтобы всё было под рукой и не было никаких перепутываний.
Прикольно, конечно, но без системы версий ты просто выбрасываешь единственную копию в чёрную дыру – удачи найти оригинал, когда его перезапишут.
Второе правило: используй лог, в котором записи добавляются только в конец, с именем файла на основе хеша, чтобы каждая версия была неизменной, и поддерживай справочник, который соотносит текущее состояние с его историей, гарантируя, что оригинал никогда не будет перезаписан.
Это здорово, но ты планируешь индексировать хеши по дате или по содержанию? Просто плоский список без структуры – это потом аудит превратится в кошмар.
Индексировать нужно только по содержимому, с минимальным файлом метаданных для даты, чтобы каждый поиск был простым хэш-запросом, а история изменений – детерминированным списком, где записи добавляются последовательно.
Здорово, план неплохой, но если два файла окажутся с одинаковым содержимым, всё равно получишь дубликаты, указывающие на один и тот же хеш – твой индекс это не отловит.
Третье правило: добавляй уникальную монотонно возрастающую последовательность к имени файла, даже если содержимое одинаковое. И сохраняй вторичный индекс, который отмечает одинаковые хеши. Так мы отслеживаем дубликаты, но сами они не занимают лишнего места. Это делает список простым и удобным для аудита.
Это остроумно, но теперь ты управляешь тремя индексами – хешем содержимого, порядком и флагом дубликата. Каждый поиск по-прежнему требует трех проверок; твой "плоский" список может оказаться скрытой вложенной структурой.
Четвертое правило: нужно объединить три индекса в одно B-дерево, которое будет использовать составной ключ – хеш содержимого и порядковый номер; флаги дубликатов можно сделать легким флагом в листовых узлах, чтобы каждый поиск требовал всего лишь один проход.
Это изящное решение, но ты за плоский список даёшь дерево, которое всё равно придётся перестраивать при добавлении новых узлов. Вставка может и так вылиться в логарифмический обход. Обязательно продумай план отката, если узел расколется в середине транзакции.