mayton2019

Из быстрых советов - проверь что Subdivision_ID проиндексирован.

По поводу NTFS/ExFat - для самих приложений ничего особо не меняется. Ну я не знаю приложений
которые-бы как-то были завязаны на эти свойства. Это может для админов безопасности там важно.

Хорошая ли это идея. Тут надо рассмотреть опции. Я часто смотрю кино с портативного диска. Иногда
кошка может прыгнуть на системник. Пошатать что-то и диск может отмонтироваться. Бывает. Но с кино ничего не происходит. Доступ read-only. Кошку выгнал. Диск подключил и смотрю себе дальше. А что с приложениями?
Дело в том что когда программист пишет код с I/O - он считает что диск всегда доступен. Совсем всегда.
И ситуация когда диск вдруг отьехал - катастрофична. Может ли ОС работать когда диск c: отключился?
Скорее нет чем да. Вобщем отсутсвие диска - катастрофа для приложений. И особенно для приложений
которые в этот момент что-то сохраняли на диск - это отложенная катастрофа. Вы последствия
почувстуете после следующего запуска. В противоположность - сеть. Она изначально проектируется
как опционально-доступная и все программы при обработке сетевых ошибок используют ретрай-логику.
Тоесть просто ждут и повторяют операции. Толерантны к сбоям.

В противоположность I/O ошибки записи - нихрена не толерантны. Это сразу выпадение программы в ОС
с сообщением "я не шмогла!". Это не относится ко всем программам а просто к большинству. К 80%
программ если хотите.

Вобщем все зависит от класса I/O операций ваших приложений. Если это как просмотр фильмов - то можно.
Если это КАК postgres с журналом - то есть риск получить полностью поломанную файловую системую и
неработающие приложения. Как работают ваши секвенсоры и плагины? Часто они делают запись?
Насколько запись критична для работы "здесь и сейчас"? Что будет если их структуры данных
для записи оказались записаны "наполовину"? Вот это вопросы на которые вы должны ответить.

Если хотите более надежные внешние диски - подключайте SATA-диск через внутренний карман на корпусе.

Два диска это хорошо. Пиши на них по очереди. Четные бекапы - на один. Нечетные на другой.

Данные нужно разделить на классы надежности хранения. Например видеофайл спокойно переживает
повреждение 1 битика внутри внутри видеопотока. На воспроизведении будет небольшой артифакт для одного кадра либо вообще ты ничего не заметишь. Тоесть видеопоток - восстанавливается.

Хуже с архивами бинарей. Многие форматы (наподобие zip, gzip) полностью повреждаются начиная со сбойного
участка. Тоесть могут оказаться полностью негодные. Я обычно такие файлы (бэкапы данных) оборачиваю кодами
восстановления. Для linux это утилита par2 а для Windows - я не знаю. Надо искать. Но возможно какая-то комбинация ключей в WinRAR даст такой-же эффект надо поискать. Что на Маке я тоже невкурсе.

Посмотри графовые бд: Neo4j (например).
Покрывает все твои потребности.

Альтернатив - миллионы. Есть библиотеки которые предоставляют доступ к файлам наподобие баз данных. Это LevelDb например.

Но обсуждать этот вопрос глубоко - нет смысла т.к. неясны требования к твоей системе хранения.

Если тебе достаточно файлов (csv, json, xml) то ради бога! Храни в файлах. Это будет очень даже
экономно с точки зрения TCO и никакой админ не нужен. А вот когда ты будешь гонять запросы
по файлам и тебе понадобится индексирование, транзакции и изоляция - вот с этого момента
можно обуждать всякие dbms или системы на файлах.

Для контроля целостности всего блокчейна используется другая структура данных - Дерево Меркла. Она обычно хранится рядом с блоками и закрепляет контрольные суммы для всех блоков сразу. На вершине дерева стоит главная контрольная сумма которая закрепляет всю известную историю блоков. Поэтому проверить расхождение двух хранилищ очень просто. Достаточно обратиться к дереву. Так-же просто понять где чейн оборвался и очень просто понять как его восстановить и продолжить дальше реплицировать.

(файлы будут в zip архиве и архивы размером от 5 КБ до 250кб, изредка 1-2 мб)?

Да здесь файловая система будет лучше. Zip-архив для БД будет все равно балластом. Движки БД обычно не способны загядывать внутрь сложного архива-блоба. Поэтому фаза вычитывания и распаковки все равно будет. А если такой фазы нет - то тогда и БД выглядит ненужным балластом. Ведь ее суммарная стоимость владения (TCO) всегда выше чем у файловой системы.

Очень зрелой выглядит идея использования облачных файловых систем (Amazon S3, Azure Blob Storage) но тут надо смотреть просто в цены и в удобство поисковых операций. Например S3 вобщем то является скорее хеш-таблицей на диске чем файловой системой. Поэтому группировать файлы в фолдеры для листинга будет так себе идея. Вообще эти ФС строго расчитаны на знание path. В идеале если ваше приложение изначально знает формулу как path формируется.

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

Верное направление мысли. Почитай еще как NGinx работает с атрибутами ETag, If-Modified-Since. Это потребует изменения логики клиента, но результат будет более оптимизированный чем просто даже с кешом.

Я-бы сделал бекап всех шифрованных файлов на любой внешний носитель.

Честно не помню что будет после переноса. Но где-то в недрах doc.microsoft.com есть описанная процедура миграции. И она должна включать в себя опцию чего делать с зашифрованными данными.