×Закрыть

Как хранить миллионы файлов с контролем доступа: обзор решений

Всем привет! Меня зовут Павел. В разработке 25+ лет, начинал с Object Pascal, затем Unix + C, затем по наклонной: Delphi, JS, HTML5, немножко Java, Go, Rust. Работал практически со всеми СУБД, иногда довольно больших размеров (>10 TB). Последние 8 лет — на должности архитектора в компании InBase. Один из продуктов компании — система электронного документооборота Megapolis Doc.Net (разрабатывается с 1998 года). Моей задачей была миграция этой системы на веб-технологии. Собственно, о решении одной из проблем, с которой мы столкнулись, а именно — о поиске оптимального способа хранения неструктурированной информации и доступа к ней с учетом прав пользователей — я и хочу рассказать.

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

Решаемые задачи

Например, такие:

  • Необходимо хранить на серверах значительное (более 100 000) количество документов (скан-копии, файлы PDF, Word, XML и т. д.) и метаинформации к ним (расширенный набор атрибутов). Например: № документа, идентификатор контрагента, который его прислал, состояние документа и т. д.
  • Обеспечить доступ к документам по протоколу HTTP(s) (браузер/WebDAV) с авторизацией.
  • Обеспечить динамическое определение прав доступа к документам. Например: в зависимости от должности или роли пользователя в системе, значения атрибутов документа (директор видит все, менеджер — только документы, которые касаются его контрагентов), данных внешних систем (сотрудник отдела финансового мониторинга видит документы контрагентов из черного списка, определяется вызовом к внешнему сервису) и тому подобные правила.

В общем, это — типичные задачи, которые стоят перед разработчиками большинства корпоративных приложений. Проще всего решать их как? Правильно, с помощью базы данных. Но оказалось, что когда документов становится очень много, возникают сложности. Дальше о них подробнее.

Базы данных. У всего есть предел

Это, казалось бы, очевидно. Если есть база данных, то можно спокойно пользоваться всеми ее благами: целостностью, транзакционностью, бэкапами и так далее. То есть архитектура довольно простая: есть приложение, есть база данных, мы в нее пишем файлы в BLOB- поле, и у нас все хорошо. Надо откатить транзакцию — откатили. Надо забэкапиться — забэкапились. И это работает. До поры до времени. Пока есть 100 пользователей и 100К документов — все хорошо. Но когда документов становится больше или количество пользователей увеличивается, начинают возникать проблемы (вне зависимости от выбранной СУБД). Рассмотрим их.

Проблема № 1

Чем больше база данных, тем сложнее ее бэкапить. Понятно, что можно выделить какие-то отдельные табличные пространства для BLOBов, бэкапить частично, но все равно — это сложно. И когда мы оказываемся перед фактом, что у нас есть табличка, и в ней, предположим, 100 млн строк с BLOBами по 200к каждый (при этом она не партиционирована), то бэкапить ее придется всю. Впрочем, даже если есть partition, периодически бэкапить таблицу полностью все равно придется. И когда эта табличка «дорастет» до пары десятков терабайт, ее бэкап будет длиться очень долго.

Проблема № 2

Еще одна проблема баз данных — масштабирование. Зачастую можно легко масштабировать серверы приложений горизонтально: поставить десять или двадцать серверов приложений. Но сервер базы данных горизонтально масштабируется очень плохо. Его можно масштабировать только вертикально, наращивая мощность, добавляя память, установив более мощный процессор. И рано или поздно мы упремся в потолок. После этого либо начинается экспоненциальный рост цены вопроса, либо обнаружится, что достаточно мощного оборудования для решения задачи в природе еще не существует. Добавление шардирования (если архитектура изначально его не предусматривала) — тоже задача не из простых.

Таким образом, если система будет продолжать писать все в базу, то в конце концов это закончится тем, что именно база станет самым слабым звеном. А когда база становится слабым звеном, это — очень плохо. С этим практически ничего нельзя сделать, и останется только одно — бросить все и уехать в Ладакх. Этот вариант решения проблемы мы обсудим позже. Когда-нибудь. А сейчас рассмотрим другие опции.

Не храни в базе — храни в файлах

В итоге возникла идея вынести из базы данных все, что можно из нее вынести. То есть: убираем BLOBы из БД, вместо них оставляем текстовое поле с информацией о том, где сохранен контент файла, сам файл пишем в файловую систему. Транзакция БД подтвердилась — файл будет доступен пользователям, транзакция откатилась — файл останется в файловой системе как «мусор».

Во втором поколении UnityBase (платформа, на которой работает наш документооборот) так и сделали. Но оказалось, что не все так просто.

Не клади все файлы в одну корзину

Пока было 1000 файлов или 10 000 файлов, проблем не возникало. Все прекрасно работало. Файлы лежали в одной папке файловой системы, с ними можно было легко работать, а бэкапить с помощью robocopy/fsync. Но когда файлов стало больше, дала о себе знать проблема файловых систем — система начинает работать очень медленно, когда в одной папке много файлов. Эту проблему надо было как-то решать.

Очевидное решение — создавать подпапки. Раскладываем файлики по подпапкам, путь к файлам храним в поле БД.

Схема хорошая, но свои подводные камни в ней тоже есть. Один из них — организация процесса создания папок и распределения файлов по ним. В первой версии алгоритма мы создавали сразу X папок, дальше по кругу помещали в них файлы: первый файл помещаем в первую папку, второй — во вторую и так далее. Бег по кругу. Говорят, это полезно для здоровья... Почему создавали папки сразу? Потому что этот процесс тоже занимает время. Сначала надо проверить, есть такая папка или нет, и если нет, нам надо ее создать на уровне файловой системы.

Оказалось, что это — плохая идея, так как возникают сложности с бэкапом. Для того чтобы забэкапить такую структуру, нужно определить, какие файлы изменились, а для этого необходимо пробежать по всей структуре каталогов. Причем количество папок может быть довольно большим, так как если файлов у вас миллион, то разложив их в сто папок, мы получим по 10 000 файлов в каждой. А это — очень много. Поэтому внутри папок первого уровня надо создать еще X подпапок, чтобы обойти все эти лимиты (на платформе UnityBase есть построенные решения, в которых хранится порядка 70 млн файлов, а это — около 40 терабайт). Но тогда время бэкапа увеличивается до неприличия.

Папка последнего дня

В зависимости от аппетита заказчика, объема данных и количества пользователей можно применять разные стратегии создания папок. Наиболее эффективной оказалась та, которая получила внутреннее название «стратегия Daily». Ежедневно создается новая папка. В ней, при необходимости, можно создать ряд подпапок, но их будет не очень много. Даже если за день появится 100 000 файлов, достаточно будет создать всего 100 папок, чтобы в каждой из них было по 1000. Таким образом, можно легко бэкапить эту однодневную папку. Даже если возникнет необходимость бэкапить чаще, достаточно создавать резервную копию только одной этой папки, а все остальные уже не меняются, они в архиве.

У такой стратегии есть еще один бонус: можно легко переносить старые папки с быстрых дисков на медленные. Зачем это нужно? Все просто: SSD стоят дорого, а SATA хоть и медленнее, но стоят дешевле, и на них можно переместить старые файлы, которыми пользуются редко.

Профит

  • Нам не нужно заранее создавать все папки. Мы просто можем каждую ночь, к примеру, в 12 часов, создать папку на следующий день и в течение дня с ней работать.
  • Нам очень легко бэкапить.
  • Все счастливы!

Отдача файлов

Отдавать файлы можно по-разному. В Linux есть возможность использовать функцию ядра sendfile. В Windows, на уровне API HTTP.SYS, можно отдать файл по файловому дескриптору. Можно самому читать файл и писать в сокет (кстати, при хранении файлов в БД это, наверное, единственный вариант). Вариантов много, и, казалось бы, можно с этим не париться. Но не все так просто. Клиент может поддерживать докачку файлов, сжатие, частичную загрузку и т. д., и все это имплементировать довольно сложно.

Поскольку в нашем случае отдача файлов идет по HTTP, есть и другой путь: поставить обратный прокси перед сервером приложений и использовать прекрасную фичу: X-Accel-Redirect (nginx)/x-sendfile(Apache). Схема становится простой и кросс-платформенной: клиент просит файл, сервер приложений проверяет права доступа (может быть сложная логика, может быть простой RLS), и если все ОК — отдает путь к файлу в специальном заголовке HTTP-ответа. Как NGINX/Apache отдаст файл — это уже не наша проблема: он его отдаст. Что это дает? То, что сервер приложений вообще не тратит ресурсы на передачу файла.

Данная схема позволяет обслуживать довольно много людей. На обычных внедрениях вряд ли возникнет вопрос производительности этой схемы — скорее, производительности сети. В практике InBase бывали случаи, когда 300-мегабитная сеть оказывалась забита намертво из-за большого количества пользователей и файлов. Много — это тысячи одновременных пользователей. При этом сервер приложений был не особо нагружен. Прокси-сервер тоже. Загружена сеть.

Облачные хранения. Хорошо, но не всегда

Конечно, можно пользоваться Amazon S3 (Azure, Google etc). Прекрасные сервисы! Но есть, опять-таки, нюансы, при которых хранить данные в облаке невозможно или не рационально:

  • Информация может быть строго конфиденциальной, и хранить ее на сторонних серверах не хочется. Кроме того, теоретически (а при благоприятном стечении обстоятельств — и практически), с одной виртуальной машины можно залезть в другую виртуальную машину, которая находится на том же хосте, и вытащить данные.
  • Существуют законы, запрещающие хранение данных за пределами страны. И есть организации, которые в принципе не хотят ходить в интернет, а их сеть полностью закрыта.
  • Цена вопроса. Ценообразование облачных провайдеров зачастую очень сложное, зависит не только от объема и времени хранения информации, но и от того, сколько раз и в каком объеме ее прочитали/записали. Если железяка будет стоять у вас (или в дата-центре), очень вероятно, что это обойдется значительно дешевле, чем арендовать место для хранения в облаке. В долгосрочной перспективе может быть гораздо дешевле — десятки, сотни тысяч долларов, в зависимости от объема. Поэтому стратегия «сделай все сам и храни под подушкой» иногда имеет смысл.
  • Можно развернуть S3 совместимое хранилище на собственных мощностях, но это потребует дополнительного администрирования и на малых/средних объемах не имеет особого смысла.

Сжатие, репликация и дедупликация

Почему это важно? Со сжатием понятно — сжимать средствами файловой системы не так уж накладно, но можно хорошо сэкономить на объеме дисков. С дедупликацией не совсем очевидно. Возьмем, к примеру, PDF. Жать его не очень эффективно. Но каждый PDF-A содержит в себе файл шрифта. Сам файл не сжимается, но когда файловая система поддерживает дедупликацию, все эти кусочки со шрифтом будут лежать на диске в одном экземпляре. И тогда каждый из этих PDF будет занимать на 20 Кб меньше. Так что если файловая система поддерживает дедупликацию, грех этим не воспользоваться. При этом мы практически не теряем в производительности.

Что касается репликации, то очень многие файловые системы ее поддерживают, и в некоторых случаях мы можем вообще не париться с бэкапами, а просто использовать, к примеру, Btrfs/CephFS/NTFS etc — все они поддерживают возможность сразу перебросить только что созданный файл на удаленный хост и сделать там его копию. Профит: у нас получится автоматический фейловер. Бэкапить все равно нужно. Если придет какой-то Petya и зашифрует файлы на мастере, они успешно реплицируются на подчиненный узел, и тогда спасет только бэкап. Но можно бэкапить реже. Ну и да — CephFS. к примеру, рассчитана на петабайтные хранилища.

В сухом остатке

Использование файловой системы для хранения неструктурированной информации вместо BLOBов базы данных дает нам множество преимуществ. Особенно в случае, когда количество файлов постоянно растет. Но если вдруг нам захочется использовать, например, Amazon S3, существуют решения в виде прокси, которые преобразуют вызовы к файловой системе в вызовы API S3. Можно поставить такой прокси и, фактически, работать со своей файловой системой, а с другой стороны, это будет S3 хранилище.

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

LinkedIn

50 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Может почитать как squid (кеширующий proxy-сервер) хранил свой кеш в ФС и обеспечивал доступ к файлам практически «на лету»?

Питання «мільйонів» не розкрито.

В нас була задача зберігати декілька десятків мільйонів фоток. І всі файлові системи, що ми пробували працювали дуууже повільно. Особливо, якщо треба отримати список усіх файлів, їх обробити (прогнати всі через нейронку), або скопіювати (єдиний варіант — dd на розмонтованому образі, інакше 2Mb/s — стеля, ssd не дуже допомагає ... та й дорого це на ssd)

Фінт «розмістити по різним папкам» до якоїсь межі допомагає, але потім не принципово краще.

І єдиним робочим варіантом стало «склеювання» файлів в пачки десь 100Гіг пачка. Такий собі tar на коліні. Трохи метаданих там і ефективний (окремий файл + in-memory) індекс з зміщеннями. Файл в базі можна адресувати як назву пачки + зміщення.

Таким чином, файл адресується за «один seek», швидко архівується/бекапиться/копіюєтьтя. Видалення зроблено як «флажок». І час від часу треба робити «garbage collect» ... але в таких сховищах видаляти «не прийнято», тому «не сильно й хотілося».

Не хочу вас розчарувати, але видалення файлу, як і DELETE в БД, фізично даних НЕ витирає практично ніколи. А ставиться лише прапорець «тут нічого немає». При цьому дамп диску дозволить виколупати багато всього, якщо постаратися.

Чи ви хочете сказати, що всі GDPR-сумісні роблять так званий wipe?
А навіть якщо і так, то в запропонованій моделі це робиться абсолютно аналогічним чином.

Поддержу Игоря — да — физически данные не трет ни БД ни ФС ни уже тем более Amazon/Azure etc. Да — почти всегда можно восстановить. Есть методы восстановления даже если файл затереть нулями (wipe). Единственный надежный метод — физическое уничтожение носителя (не зря есть HDD в которых встроена процедура физического уничтожения)

Не хотелось сильно углубляться в детали реализации. У нас стор побит на тома. Каждый том — имя тома + путь к его корню.
Если мы на «обычной» ФС то когда перелазим за размер диска — добавляем новый диск, монтируем его и прописывем в конфиг путь к точке монтирования.
Пишем всегда в активный том, в БД сохраняем ссылку с учетом имени тома. Таким образом нагрузка на чтение распределяется между несколькими дисками.
Если мы на CepthFS — там в самой ФС есть механизм размазывания данных по разным дискам.
Честно говоря с проблемой неоптимальной реализации именно файловой системы мы столкнулись только один раз — когда писали много мелких файлов на ZFS. Но это известная проблема ZFS. Похоже у Вас файлы небольшие, тогда да — склеивание ( и соответствено Sequential read на уровне диска) существенно поможет при batch обработке.

CepthFS не пробував, якщо чесно ... тому не скажу.
А щодо томів ... то ... все може бути ... просто ж тут фішка не в розмірі диска. В описаному випадку, якщо буде лям файлів по 10к — це 10Гб. Не різати ж розділи по 10-20Гб?

А лям файлів — це ще та заноза, якщо треба їх всі прочитати (при копіюванні, наприклад).

Проблема в тому, що list директорії не видає файли в порядку їх розміщення на диску. Відповідно, той самий sequential read відсутній зовсім + cache miss на кожному файлі.

Доречі, якщо про вашу реалізацію ... Яку файлову систему використовуєте? Який середній розмір файла? Які диски (HDD, SSD, NVME)? Чи використовуєте LVM чи щось подібне? Як відбувається бекап?

Наши инсталяции в основном on-premise. Что Заказчик умеет лучше — то и используем. Из крупных инсталяций (в которых больше млн. файлов) есть примеры использования: NTFS (еще есть люди на Windows), ext4, ZFS (отказались), CepthFS.
В силу специфики продуктов (файлы в основном PDF/DOCX/XSLX) средний размер файла около 350Кб. По дискам тоже как у кого. У мелких — HDD, у крупных чаще всего HDD + SSD cache (hardware)
В последнее время (когда перешли на создание папки на каждый день) бекапим синком крайней папки (сегодняшней) на бекап + с бекапа на ленту потом раз в Х дней (у кого есть).

Відповідно, той самий sequential read відсутній зовсім + cache miss на кожному файлі

Я неточно выразился — именно ваша реализация (когда жать мелочь в один большой файл) и обеспечит sequential read
Кстати о GDPR для @Alex — на ленту пишет большинство крупных организаций. Оттуда вообще удалить нельзя....

Alfresco даже в коммьюнити версии без проблем справляется с 350 тыс. файлов (шаманили её совсем немного). Почти все файлы — пдфки, важно было сохранить метаинформацию. Заливали все по ftp (просьба клиента), хотя она поддерживает и WebDAV. Это то, с чем приходилось сталкиваться на практике. На форумах пишут, что были кейсы с 2 миллионами файлов и особых проблем не возникало, но этого мы не проверяли.

P. S. Спасибо за материал!

Ну так Alfresco как раз и делает то же самое что описано в статье — в корневой папке создает поддиректории по дате записи файла. Матаданные хранит в БД. Мотивация — точно та же что и у нас (docs.alfresco.com/...​5.1/concepts/cs-file.html). Как говорится — «все счастливы одинаково»

ЗЫ: а ещё у вас с прямо гугла ведёт битая ссылка inbase.com.ua/ua/megapolis-docnet.html #404

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

мимо проходил xxi век версионность файловой системы ещё не открыли всё остальное в том же ж ключе вижу такие «решения» в среднем раз в год и несколько раз в год в виде «красивых презентаций солюшин архитекторов» селяви ))

а это — около 40 терабайт

это 4 10 ТБ диска я уже в этом году но ещё до вируса как раз докупил на «домашний» дисковый массив

В практике InBase бывали случаи, когда 300-мегабитная сеть оказывалась забита намертво из-за большого количества пользователей и файлов. Много — это тысячи одновременных пользователей. При этом сервер приложений был не особо нагружен. Прокси-сервер тоже. Загружена сеть.

(беспомощно разводит руками) я вообще признаюсь не понял что именно вы «решали» 300 мегабит это даже не гигабит может описка? может таки 300 гигабит ещё куда ни шло?

чтобы перелить 40 ТБ по 2-м 10 гигабитным интерфейсам уходит 5 часов это конечно если всё остальное построено так чтобы грузить эти 10 гигабитные по полной этого на сегодняшний день пока хватит для работы с документами средней корпорации для тяжёлых данных уже не хватит но это уже совсем другая история

сжатие туда же ж ценность его скорее никакая стоимость дискового пространства на сегодня мизерна чтобы реально беспокоиться но на «красивых презентациях» конечно смотрится )) другое дело что сжатый файл вы не сможете отдавать sendfile но с другой стороны при условии системы кеширования и когда сжатие имеет смысл для передачи уже на конечном сегменте сети то сжатые файлы имеет смысл подкладывать на ssd кеш который кстати уже и стоит дороже и меньшего объёма соотв.

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

я не знаю что вы «решали» ))

В практике InBase бывали случаи, когда 300-мегабитная сеть оказывалась забита намертво из-за большого количества пользователей и файлов.

увести ваши файловые потоки в отдельный vlan которому настроить пониженный уровень приоритета qos я так понимаю говорить про это на уровне ... неизвестно чего но примерно

на малых/средних объемах

+

но это потребует дополнительного администрирования

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

хранить на серверах значительное (более 100 000) количество документов

признаю специально дочитал только сейчас а сперва читал невнимательно так вот «значительное» это 100,000,000 а 100,000 это «ну такое» из интереса я сосчитал сколько у меня сейчас файлов в _dev папке на рабочем компе и как раз чуть больше половины 58 тысяч штук ))

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

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

Даже если за день появится 100 000 файлов

это как раз 100 миллионов файлов за 3 года но проблема тут в том что 3 года как раз «срок годности» после чего все «старые» можно и даже нужно «передать в архив» имеющий уже своё отдельное решение и работающий уже с другими профилями нагрузки

ок я сдаюсь )) честно ожидал тут найти что-то соотв. заголовку но видимо какой-то кликбейт

Если не секрет — рассматривали ли Hadoop как вариант ?

Из того что вижу то описанная задача это решается через hdfs, kerberos, sentry, ranger, atlas (если не хотите идти в клауд)

Рассматривали но пока не используем — у нас в основном инсталяции on-premise, заказчики к данным не подпускают, администрируют систему сами. Експертиза по hdfs очень редка в их краях. На данный момент есть примеры успешной експлуатации CephFS (самое крупное — около 10Тб, но динамика роста существенная). CephFS в RHEL из коробки, что сильно упрощает жизнь администраторам.

Що тільки люди не придумають, аби не платити за S3:
In praise of S3, the greatest cloud service of all time

Предполагая такой коментарий специально добавил в статью абзац о S3. Иногда использование S3 попросту невозможно в силу специфики хранимой информации. А иногда вопрос в цене — 10Тб только storage без учета трафика и запросов (Europe Frankfurt) ~ 250$/month = 3000$/year (цена 5 хороших 10Tb HDD)

А иногда вопрос в цене — 10Тб только storage без учета трафика и запросов (Europe Frankfurt) ~ 250$/month = 3000$/year (цена 5 хороших 10Tb HDD)

цікаво скільки за те саме заплатять команді яка буде робити in-house рішення. Я чомусь думаю що S3 буде дешевшим (відкинемо на мить питання про специфіку яка не дозволяє зберігати дані в кладі).

У якості middleware можна використовувати minio, який має сумісність з протоколом S3.

Сумісність з S3 зараз мають всі, і власне AWS — не єдиний провайдер S3, хоча підозрюю, що найбільш надійний.

It’s depends. У нас продукт. Стоимость его разработки не ложится на плечи одного клиента. А вот стоимость эксплуатации для заказчика важна. Со временем объемы данных (и соответственно стоимость хранения) только растут, минимально документы (финансовые например) нужно хранить 3 года, некоторые категории документов (по персоналу к примеру) — до 30 лет. Если оценивать общую стоимость владения Amazon S3 вряд ли окажется дешевле.
Но, несомненно, есть категории проектов где выгоднее использовать сервисы облачных провайдеров.

Ну так aws s3 має різні типи. Наприклад доки які вам треба тримати N років не всі мають мати миттєву доступність. Тому можна вказати тип storage glacier archieve чи glacier deep archive і імхо ціна питання буде низчою. Якщо підібрати стратегії зберігання правильно під use-case то можна дуже непогано триматися в ціновій політиці.

Так, згоден, aws S3 — це цілий світ. Все від задач залежить. Якщо є гарна експертиза по aws, то можна й ціну питання знижувати. Інколи є необхідність вчити 100500 особливостей aws, а інколи можливо обійтися й знаннями двох десятків (linasm.sourceforge.net/...​s/syscalls/filesystem.php) базових ф-й роботи з файлами в POSIX. Перше — вендор лок (інколи оправданий), друге — свобода дії в будь-якому POSIX оточенні / мові програмування. Для проксування викликів fs -> aws s3 є готові рішення, тож перехід від файлової системи до aws s3 можна здійснити майже без затрат при необхідності. А ось в інший бік — навряд чи.

Що тільки люди не придумають, аби не платити за S3

ще одна зовнішня залежність, яка дає ілюзію контролю?

Треба завжди розрізняти логіку зберігання від логіки управління та контролю доступу. Дуже часта помилка початківців — змішування даних та метаданих

А возможность использования SQL Server для хранения файлов в полях с атрибутом FILESTREAM не рассматривалась?

Бекап больших баз — главная проблема.

Да — смотрели на SQL Server FILESTREAM. Отказались по причинам:
1) бекап большой БД — проблема
2) заточка под SQL Server, а он не всем подходит
3) отдача клиенту — правильно отдать файлик сильно проще чем BLOB (даже если СУБД его хранит как файл у себя внутри читать все равно придется через BLOBStream)

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

И как? Это on-prem или клауд? Чем мониторите?

собственный клоуд на K8, для мониторинга prometeus и самопальные тулзы

А какое железо/сеть?

железки в глаза не видел, все это в датацентрах стоит, но няз сервера Supermicro Bigtwin и сторадж IBM Flash 9000

А файлы метаданных вы тоже храните на дисках? Это на мой взгляд неоптимальная стратегия, так как такие файлы крайне малы в размере и на итоговый размер базы не сильно влияют, но добавляется дополнительная нагрузка на обьединение результатов запросов в базу с физическими файлами и их чтением.

Метаданные храним в таблицах БД. Был грешок — дублировали их так же в ФС. После того как убили ZFS мелкими файлами, как Вы правильно заметили, больше не дублируем

Метаданные доков на серваке лежат в базе на том же серваке
Группа серваков работает как облако или кластер

a vdrug formati ustareut i ih nevozmojno budet otkrit’ so vremenem. Togda v pomosh digital preservation www.dpconline.org/...​ital-preservation-matters

Согласен, такая проблемма есть. Мы настоятельно рекомендуем клиентам конвертировать файлы для долгосрочного хранения в PDF/A, отдельно поставляем сервис для конвертации «на лету» для ворд/ексель -> PDF/A

Mi kak raz dlya takogo ispol’zovali sistemu Rosetta ot Exlibris. Tam est’ takie moduli kak communiy watch i technology watch, kotorie sami reagiruut na izmeneniya v formatah dannih i predlogaut v zavisimosti ot etogo massoviy format migration v luschiy bolee sustainable format. Libo esli file uje ne spasti, to est’ vozmjnost’ emulirovat’ sistemu, gde on rabotal kogda-ti. www.exlibrisgroup.com/...​agement-and-preservation

Один из них — организация процесса создания папок и распределения файлов по ним.

У меня была похожая задача, я сделал нечто вроде шардирования. Имя файла конвертируется в GUID, далее значения Data1, Data2 и т д используются для создания структуры поддиректорий типа StorageRoot\Data1\Data2\..., по полученному пути и сохраняется файл.

Да, одна из наших стратегий очень похожа. Но на нагрузке обнаружились проблемы:
1) если в многотопочном режиме пытаться создавать папки возникают блокировки каталога
2) бекапить сложно. Приходится бекапить все или диф вычислять что медленно на больших объемах (даже rsync медленно). Поэтому большинство клиентов используют стратегию — папка на каждый день. То есть структура папок storageRoot/YYYY/MM/DD

Храните один документ на двух разных серваках и решен вопрос с бекапами

Бекап заменить дублированием не получается. Обычно бекап идет на медленный носитель, часто — на ленту. После Пети так даже очень часто на ленту.
А дублирование многие файловые системы сами умеют, для этого в прикладном софте менять ничего не нужно. Иногда мы его используем для балансировки нагрузки

если в многотопочном режиме пытаться создавать папки возникают блокировки каталога

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

бекапить сложно. Приходится бекапить все или диф вычислять что медленно на больших объемах

У вас же уже используется база для хранения имени файла? Что, если там хранить ещё и историю изменений файла, которую обновлять при каждом его перезаливе? Запись в историю изменений добавлять, только если контрольная сумма файла изменилась.

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

На больших объемах borg решает. Но у вас специфика — лента. Если бы не лента, то можно было бы использовать borg backup. После него нет никакого желания для бекапов использовать всякие бакулы-шмакулы и rsync-подобные утилиты. Из современных утилит бекапирования есть еще restic.

Спасибо за borg — обязательно попробуем где можно. Лента пол беды. Часто у нас еще и винда :(

Я працюю в компанії StorageMadeEasy storagemadeeasy.com
Наш продукт якраз і робить все те, що ви описали

Подписаться на комментарии