Наши инсталяции в основном on-premise. Что Заказчик умеет лучше — то и используем. Из крупных инсталяций (в которых больше млн. файлов) есть примеры использования: NTFS (еще есть люди на Windows), ext4, ZFS (отказались), CepthFS.
В силу специфики продуктов (файлы в основном PDF/DOCX/XSLX) средний размер файла около 350Кб. По дискам тоже как у кого. У мелких — HDD, у крупных чаще всего HDD + SSD cache (hardware)
В последнее время (когда перешли на создание папки на каждый день) бекапим синком крайней папки (сегодняшней) на бекап + с бекапа на ленту потом раз в Х дней (у кого есть).
Відповідно, той самий sequential read відсутній зовсім + cache miss на кожному файлі
Я неточно выразился — именно ваша реализация (когда жать мелочь в один большой файл) и обеспечит sequential read
Кстати о GDPR для @Alex — на ленту пишет большинство крупных организаций. Оттуда вообще удалить нельзя....
Поддержу Игоря — да — физически данные не трет ни БД ни ФС ни уже тем более Amazon/Azure etc. Да — почти всегда можно восстановить. Есть методы восстановления даже если файл затереть нулями (wipe). Единственный надежный метод — физическое уничтожение носителя (не зря есть HDD в которых встроена процедура физического уничтожения)
Ну так Alfresco как раз и делает то же самое что описано в статье — в корневой папке создает поддиректории по дате записи файла. Матаданные хранит в БД. Мотивация — точно та же что и у нас (docs.alfresco.com/...5.1/concepts/cs-file.html). Как говорится — «все счастливы одинаково»
Не хотелось сильно углубляться в детали реализации. У нас стор побит на тома. Каждый том — имя тома + путь к его корню.
Если мы на «обычной» ФС то когда перелазим за размер диска — добавляем новый диск, монтируем его и прописывем в конфиг путь к точке монтирования.
Пишем всегда в активный том, в БД сохраняем ссылку с учетом имени тома. Таким образом нагрузка на чтение распределяется между несколькими дисками.
Если мы на CepthFS — там в самой ФС есть механизм размазывания данных по разным дискам.
Честно говоря с проблемой неоптимальной реализации именно файловой системы мы столкнулись только один раз — когда писали много мелких файлов на ZFS. Но это известная проблема ZFS. Похоже у Вас файлы небольшие, тогда да — склеивание ( и соответствено Sequential read на уровне диска) существенно поможет при batch обработке.
Так, згоден, aws S3 — це цілий світ. Все від задач залежить. Якщо є гарна експертиза по aws, то можна й ціну питання знижувати. Інколи є необхідність вчити 100500 особливостей aws, а інколи можливо обійтися й знаннями двох десятків (linasm.sourceforge.net/...s/syscalls/filesystem.php) базових ф-й роботи з файлами в POSIX. Перше — вендор лок (інколи оправданий), друге — свобода дії в будь-якому POSIX оточенні / мові програмування. Для проксування викликів fs -> aws s3 є готові рішення, тож перехід від файлової системи до aws s3 можна здійснити майже без затрат при необхідності. А ось в інший бік — навряд чи.
It’s depends. У нас продукт. Стоимость его разработки не ложится на плечи одного клиента. А вот стоимость эксплуатации для заказчика важна. Со временем объемы данных (и соответственно стоимость хранения) только растут, минимально документы (финансовые например) нужно хранить 3 года, некоторые категории документов (по персоналу к примеру) — до 30 лет. Если оценивать общую стоимость владения Amazon S3 вряд ли окажется дешевле.
Но, несомненно, есть категории проектов где выгоднее использовать сервисы облачных провайдеров.
Рассматривали но пока не используем — у нас в основном инсталяции on-premise, заказчики к данным не подпускают, администрируют систему сами. Експертиза по hdfs очень редка в их краях. На данный момент есть примеры успешной експлуатации CephFS (самое крупное — около 10Тб, но динамика роста существенная). CephFS в RHEL из коробки, что сильно упрощает жизнь администраторам.
Спасибо, исправили.
Бекап заменить дублированием не получается. Обычно бекап идет на медленный носитель, часто — на ленту. После Пети так даже очень часто на ленту.
А дублирование многие файловые системы сами умеют, для этого в прикладном софте менять ничего не нужно. Иногда мы его используем для балансировки нагрузки
Метаданные храним в таблицах БД. Был грешок — дублировали их так же в ФС. После того как убили ZFS мелкими файлами, как Вы правильно заметили, больше не дублируем
Да — смотрели на SQL Server FILESTREAM. Отказались по причинам:
1) бекап большой БД — проблема
2) заточка под SQL Server, а он не всем подходит
3) отдача клиенту — правильно отдать файлик сильно проще чем BLOB (даже если СУБД его хранит как файл у себя внутри читать все равно придется через BLOBStream)
Предполагая такой коментарий специально добавил в статью абзац о S3. Иногда использование S3 попросту невозможно в силу специфики хранимой информации. А иногда вопрос в цене — 10Тб только storage без учета трафика и запросов (Europe Frankfurt) ~ 250$/month = 3000$/year (цена 5 хороших 10Tb HDD)
Согласен, такая проблемма есть. Мы настоятельно рекомендуем клиентам конвертировать файлы для долгосрочного хранения в PDF/A, отдельно поставляем сервис для конвертации «на лету» для ворд/ексель -> PDF/A
Да, одна из наших стратегий очень похожа. Но на нагрузке обнаружились проблемы:
1) если в многотопочном режиме пытаться создавать папки возникают блокировки каталога
2) бекапить сложно. Приходится бекапить все или диф вычислять что медленно на больших объемах (даже rsync медленно). Поэтому большинство клиентов используют стратегию — папка на каждый день. То есть структура папок storageRoot/YYYY/MM/DD
Спасибо за borg — обязательно попробуем где можно. Лента пол беды. Часто у нас еще и винда :(