Пишу сюда, так как вопрос на уровне идеи работы с базой, а не реализации.

что у нас есть - у нас есть два хранища, база и файловая система. содержимое Юфайла(юзера) храниться в серии мелких файлов разкиданых по разным серверам. Метаинформация о Юфайле и данные для сборки Юфайла из физических на шдд в БД.

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

СТРУКТУРА БАЗЫ ОПУСКАЯ информационные поля.

FILES(idfile as PK, ...)

NODES(idnode as PK, ...)

CHUNKS(idchunk as PK,number,FK_idfile, FK_idnode1, FK_idnode1, FK_idnode1 )

обяснение.
Файл разбиваеться на части пронумерованные(chunks.number), каждую которую сохраняем трижды(на трёх разных серверах) - fk_idnode(1|2|3)

ТРУДНОСТИ.
у нас трижды ссылка на одну таблицу - денормализация, выбрал потому что

---нормализация привела бы к увеличению размера физического таблицы.

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


одна из задач - получить все файлы которые должны быть на данной ноде.

при нормализованой структуре(nodes, chunk_2_nodes, chunks запрос был бы

(LET @idnode=5)



при денормализованой




ну и я пощитал что никчему постоянно делать джоин лишний при выборке.
лучше я при даной(менее частой задаче) буду делать юнион индекс(вывод на основании плана выполнения запроса)


ЗАДАЧА.
стоит задача - 100%надёжно удалить файл из системы
-удалить из базы
-стереть всю с шдд на всех нодах.

ТЕКУЩЕЕ РЕШЕНИЕ. из базы удаляем данные по файлам, по чанкам каскадно.
периодически каждая нода сравнивает снимок базы с сканом файловой системы, и ищет различия.
файл есть на шдд - нету в базе = мусор=делете
файла нет на шдд - есть в базе = потеря = востановить.

но понимаете в чом дело.
при большом обёме, (200 млн файлов - чанков 2 млрд=файлов на шдд) делать часто снимки файловой системы и базы, сравнивать - дело будет накладное мне кажеться (для базы прежде всего)

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

у меня идея одна, но мне кажеться это глупо.

1)при удалении файлов мы их маркируем лишь на удаление.
2)каждая нода получает список файлов из базы, помеченых на удаление(файл + номер кусочка файла) - удаляет у себя на шдд, и в базе ставит вкачестве ссылки на ноду размещения нулл.

и так каждая нода повытерав киски на себе файлов предназначеных на удаление, вкачесве ссылки на ноду хранения ставит нулл.

3) все чанки для которых fk_idnode1 is null AND fk_idnode2 is null and fk_idnode3 is null - удалить.

4)все файлы , для которых нету чанков удалить.

это исключает появление новых файлов с именами совпадающими со старыми, и гарантирует безошибочность данного процеса. Но это ёмкий процесс. или я зря смущаюсь?!

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

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

хотя конечно хотелось бы и это разрулить болле мудро.

вцелом задача такая, как добиться синхронности метаданных в базе, с реальностью на шдд.

alex564657498765453,

выше допущена ошибка, нащот появления нового файла с такимже именем - это уже решено.

а задача 100% надёжного способа стирания данных по другому, изза

1 - не делать полные сканы хранищ постоянно , хочеться более точечно работать по удалению муссора

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

поэтому и хочеться пойти по пути.
файлы не удалять а потом фулсканы и сравнения.
а помечать, и потом удалять "синхронно"