Контекст:
Я разрабатываю приложение, которое требует обработки таблиц, которые не обязательно имеют однородную структуру (например, разные / дополнительные столбцы). Эти неструктурированные файлы также должны быть сгруппированы (скажем, 5 таблиц вместе составляют группу, каждая таблица имеет разное содержимое). И каждый файл в группе должен быть версионирован, желательно простым и эффективным способом (например, нет необходимости копировать весь файл, если изменяется только строка).
Текущее решение, о котором я думал:
- Определите схему с некоторыми стандартными полями, которые нужны приложению, например
name of a file group, ..., timestamps, path_to_repository, hash_of_repository_content (to invalidate), status (eg. being_updated, for concurrency) }
- На
path_to_repository у меня будет git-репозиторий, и я буду хранить файлы в формате csv (создайте подмодуль для каждого файла, чтобы каждый файл в файловой группе мог быть версионирован независимо).
- Чтобы получить доступ к этим файлам, я получу хранилище, и заголовок будет текущей версией файлов. Тогда я могу легко управлять версиями, хранить таблицы неограниченного размера без какой-либо структуры и не будет ограничен максимальным размером файла mongodb. Если есть какая-либо дополнительная информация для версионирования, я могу просто добавить ее в репозиторий.
- Чтобы справиться с параллелизмом, я обновлю флаг в mongodb, чтобы он позаботился о параллелизме для меня. Если два приложения одновременно пытаются выполнить запись в репозиторий, они сначала устанавливают флаг / блокировку. если флаг уже кем-то обновлен, им нужно подождать.
Вопрос:
Я не уверен, что это хорошая практика (независимо от того, переизобретаю ли я колесо или нет, будет ли оно иметь хорошие характеристики, можно ли его масштабировать, если возникнут какие-либо проблемы, которые я не вижу). Любой совет / опыт / критика было бы здорово.
Возможно, не имеет значения дополнительная информация:
это будет использоваться nodejs/mongoose, а также скриптом Python.