Как организовать файловое хранилище пользователей (виртуальная фс или нативная)?

Question

[KonstantoS]

Сейчас пишу систему простенькую, там в одним из пунктов ТЗ есть хранение данных пользователя. Эдакое велосипедное облако.
Предусмотрено, что юзер заливает файлы (разрешеных типов) и есть возможность создавать папки. А так же расшаривать файлы/папки.
Пока только 2 идеи реализации:
1. Заливать все в одно место, а в БД хранить и папки(виртуально) и записи о файлах. Ну и указывать родителя.
2. Для каждого юзера выделить физическую папку, иерархия строится по-человечески. Записи в БД того же типа выходят. Но без указания иерархии.
Плюсом считаю, что можно к такой схеме получать доступ по фтп, чего не будет у первой.

Искал уже, но ничего внятного не нашел, вожможно плохо понимаю как это выразить для поиска.
Подскажите как это делают адепты и в чем причина того или иного решения)
Прим: реализация на NodeJS+Postgresql

Answer 1

[Тимур Шемсединов]

А тут все зависит от количества и размера файлов, от количества пользователей и от распределения файлов по пользователям. Поясняю, если пользовтелей много (миллионы) а файлов у них мало (десятки) то у Вас будет много папок, а в них мало файлов, это не экономный расход файловой системы, будет много уходить на оглавление, и будет папка с медленным доступом (в которой лежат папки пользователей). Если пользователей мало, а файлов много, то так же, будут папки с очень большим оглавлением. Тут можно или выбрать файловую систему, которая решает эти проблемы или самому сбалансировать дерево папок, чтобы поиск был оптимальным. Как добиться оптимального поиска, сделать сбалансированную структуру папок, чтобы в каждой было не много и не мало файлов с очень различающимися названиями. Например, можно сделать 2х или 3х уровневую систему папок, в которой лежат файл переименованные в HEX, например /EA8D253F/2145AE32/F259C201 Нам нужно генерировать случайные имена папок и файлов, а потом в базу данных писать этот путь. это будет оптимально для любой файловой системы и любого кол-ва файлов, просто увеличте длину имен, алфавит и вложенность папок (в завистмости от особенности файловой системы и своих нужд, это нужно изучать). Кроме всего, это решает кучу проблем - файлы с одинаковыми именами и файлы со странными символами в именах (в том числе арабские, китайские и прочие UTF8 имена), исполняемые файлы и вообще вопрос безопасности, относительную деперсонализацию данных, и прочее... Про FTP лучше забудьте, ни какие пользователи по FTP ходить не должны, это архаичный протокол позднего проволочного века, применяемый сейчас только мной и прочими извращенцами. А если Вы еще будете вычислять для файлов хеши, несколько разных хешей на всякий случай, и хранить их вместе с именами и всеми метаданными, в базе, то можно избавиться от дублирования на диске (есть случаи, когда у разных пользователей большой процент одинаковых файлов). Вот тут кое-какие наброски: /lib/impress.files.js#L111-L174 даже файлы на винте сжимаются двумя ZIP и GZIP в зависмсти от размера. Берите, дарю методу...

Comments

[KonstantoS]

Ухх, крутое аргументирование! Спасибо, буду в этом направлении думать.

[Дэн Иванов]

Субъективно - вы велосипедите. Оптимальное размещение файлов старается обеспечивать ФС, размещая блоки хранения таким образом чтобы доступ к ним осуществлялся максимально быстро, и при этом файлы были распределены равномерно по пластинам.
Пытаться решать проблему "много файлов в куче", нужно не таким образом, а заставляя пользователей группировать файлы. Либо если пользователю так нужно они сами должны осознавать что это будет не быстро в любом случае. Поскольку тупо объем данных передаваемый на листининге клиент-сервер будет относительно велик.
Дедупликация данных, также может обеспечиваться на уровне ФС, зачем это тащить в приложение ?

[Тимур Шемсединов]

У Вас бывало 13 млн файлов в каталоге? А 2 млн каталогов по 3 файла? Большинство ФС плохо справляются с оптимальным хранением таких структур, а в природе они встречаются. Переименование файлов в хеш от содержимого или в хеш от времени или в рандомное имя - помогает ФС построить не вырожденный ключ по имени и очень ускоряет потом доступ. Есть конечно специализированные ФС, которые сами все это делают, например ZFS, о чем я сказал.

[Дэн Иванов]

Какой человек будет ложить 13м файлов в 1 каталог ? Он же глазками будет на эти файлики смотреть.
Я исхожу из предположения, что изначально есть сущность "пользователь", так пусть у каждого пользователя будет своя точка входа - бакет, директория, раздел как угодно назовите. Нахрена все укладывать в одну кучу ? Если же предполагается использовать это "облако" как object storage так нечего велосипедить, взять любой подходящий и все.

[Тимур Шемсединов]

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

[Дэн Иванов]

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

[Тимур Шемсединов]

Вы на практике встречались в большими файловыми хранилищами? Замеряли скорость доступа к файлам на разных ФС, это большая проблема вообще.

[Дэн Иванов]

Да встречался. "Замеряли скорость к файлам" - ШТА ? Да замерял, скорость доступа зависит от многих факторов и в больше степени не от "количества файлов в директории" а от специфики операций чтения/записи происходящих в этот момент в системе. В идеальном случае содержимое всей вашей директории будет в dentry/inode cache и листенинг у Вас будет моментальным.

[Тимур Шемсединов]

Это для маленьких объемов данных, а когда это сервис для миллионов человек, то ничего подобного не происходит. В этом конкретном вопросе, скорее всего можно сделать как попало, и ни кто никогда не столкнется с проблемами.

[Дэн Иванов]

Про каких "миллионов человек" Вы говорите, когда пытаетесь моделировать и "исправлять" ситуацию когда миллион файлов в 1 директории. Что то получается что человек по 50 на сервер, не больше.
Вряд ли там будут 1кб файлики. У "обычных" пользователей средний размер побольше будет.

[Тимур Шемсединов]

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

[Дэн Иванов]

Нет, это как раз важно. Именно поэтому появилось множество различных файловых систем решающих разные задачи, разные типы БД и т д. В самом общем кейсе - велосипед не нужен, берете любой опенсорсный object storage и получаете "средненькое" решение во всём.

[Тимур Шемсединов]

У всех этих систем будет фатальный недостаток

Answer 2

[xmoonlight]

Сразу бросилось в глаза:

Плюсом считаю, что можно к такой схеме получать доступ по фтп, чего не будет у первой.

А кто сказал, что к виртуальной структуре нельзя сделать FTP-доступ?!) Правда, придётся свой FTP-сервер написать, который понимает вирт. ФС и то при условии, что существующих не будет достаточно: они как правило позволяют делать виртуальные папки пользователей на основе правил конфига, но в базу лазить (в своём большинстве) не умеют.

Лучше использовать виртуальную ФС потому, что Вы не будете "привязаны" к ограничениям файловой системы (кол-во всего каталогов/файлов, макс. глубина вложений и прочее) и сможете легко шардировать хранилище на несколько серверов с учётом бэкапов, отказоустойчивости/RAID и т.п.

Answer 3

[Станислав Макаров]

Тут уже упомянули хеши, советую вам основательно над ними подумать. Сейчас хэши считаются довольно быстро на современном железе, так что подумайте о content-adressable файловой системе. На классическую ФС мапается элементарно: хэш бьется на нужное количество кусков и по ним формируется вложенная структура, что-то вроде f5/c3/ab/1414.... . Иерархию папок хранить в БД, не знаю правда что для этого лучше использовать, по идее реальная ФС как раз-таки лучше подходит для хранения вложенной структуры, чем например, реляционная БД. Так что нужно будет основательно поисследовать в этом месте - какую БД взять для метаданных о файлах. Ну и собственно помимо остальной метаинфы писать хэш контента, и находить реальное содержимое по хэшу. Шардиться такое решение должно очень хорошо, плюс, как отметил Тимур Шемсединов, будет выигрыш от недублирования файлов (если реализовать более умную систему, которая будет считать ссылки на конкретный хэш). Вероятность совпадения хэша очень очень низкая, для надежности еще можно проверку на размер поставить, хотя врядли за время использования вы с таким случаем столкнетесь.

Comments

[xfg]

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

[Дэн Иванов]

Если не ошибаюсь, человек спрашивал про организацию приложения, а не хранения. То что вы описываете реализовано во множестве распределенных ФС, начиная от тупенького glusterfs и заканчивая CEPH/leofs/elliptics. Все это можно подцепить как backend для приложения, и использовать эти object storage для хранения файлов. Там люди уже много раз прошлись по тем граблям, по которым хотите погулять Вы.
В более менее продвинутых решения типа Ceph/elliptics/leofs есть понятия buckets или что то подобного что очень легко маппится на авторизацию. И задача "сервера" сводится к управлению файлами в публичном/приватном бакете конкретного пользователя. Для обеспечения быстрого листенинга и подобных операция, можно хранить метаданные (списки директорий с размерами файлов и правами доступа) в быстрых хранилищах типа редиса. Искренне не понимаю зачем это дублировать еще в одной базе.

[Станислав Макаров]

Дэн Иванов
С leofs не знаком, а вот elliptics смотрел достаточно подробно, вещь интересная конечно. Только непонятно, зачем это автору, если ему надо
> Эдакое велосипедное облако.

> дублировать еще в одной базе
тут не понял, что вы имеете в виду под дублированием

[Станислав Макаров]

@xfg
я имел в виду шардить контент файлов по хешу, статистически рано или поздно ноды будут загружаться равномерно

[xfg]

Станислав Макаров: ну хорошо, тогда расскажите, как приложению получить доступ к файлу на конкретном шарде. И как делать решардинг, когда в кластер добавляется новая нода. И что будет, если по хешу этот файл нужно сохранить на конкретную ноду, но на этой ноде уже полностью занят жесткий диск?

Есть примеры крупных проектов, где файлы шардятся по нодам используя описанный вами подход?

[Станислав Макаров]

xfg хороший хэш распределяется достаточно равномерно по пространству значений. Делите его по модулю на количество нод и получаете на какую ноду класть или с какой брать. Если на какой-то ноде полностью занят диск, значит и на других тоже места не особо много, новую ноду пора добавить. Решардинг подразумевает использование нового делителя (т.к. число узлов поменялось) и перемещение на нужные ноды тех файлов, для которых результат операции изменился. Разумеется, это тяжелая операция, сильно часто при таком хэшировании ее проводить не захочется.
Если рассчитываете постоянно добавлять ноды - посмотрите, не проще ли взять range-based по id-шнику файла

[Дэн Иванов]

Станислав Макаров: Задам проще вопрос. Представьте что у вас машины с разного объема дисками. Что будете делать ? Все "претензии" описанные xfg это малая часть тех проблем с которыми придется столкнуться.

[Станислав Макаров]

Дэн Иванов так, давайте сразу решим, мы обсуждаем будущую промышленную систему или учебное задание на коленке? Я даю автору советы по реализации второго случая. Как реализовывать полноценное решение это не то, что вообще можно обсуждать на Тостере в его нынешнем виде.
Нюансов в нормальном решении столько, что я думаю тут каждый из участников беседы напишет 3 листа А4 не особо задумываясь)

[Дэн Иванов]

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

[xfg]

Станислав Макаров: я честно мало что понял из ваших ответов, но думаю что на практике это не будет нормально работать. Обсуждаем мы систему с большими объемами данных, иначе нет смысла вообще все это изобретать. Я бы посмотрел на систему, где используется описанный вами подход. Я такой реально вообще никогда не видел и даже не представляю, как это сделать, чтобы не было кучи разных проблем. Я реально рабочих подходов в бою видел всего два:

1. Сетевая файловая система https://ru.wikipedia.org/wiki/Network_File_System
2. Много независимых серверов для статики, файлы на них заливаются рандомно (или по некому алгоритму), приложение перестает записывать данные на сервера на которых исчерпывается объем жесткого диска и только читает с них. Каждый сервер висит на своем поддомене. В базе вместе со всей метаинформацией сохраняется и номер сервера, на котором располагается файл. Яркий пример - Вконтакте.

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

Всё. Других решений не видел.

[Станислав Макаров]

@ptchol
> систему простенькую
> Эдакое велосипедное облако.
я сделал акцент на этом, видимо тут кроется моя ошибка. Не знаю где вы в этом разговоре увидели что я утверждал что мой вариант хотя бы жизнеспособен, не говоря уж о сравнении с крупными известными системами. Для того, чтобы это утверждать, нужно выполнять исследование, я автору подкинул лишь идею. Автор сделает исследование, если у него промышленная система, или просто попробует реализовать, если задача учебная. Задавая такой вопрос, я был бы рад услышать любые идеи, причем чем больше чем лучше, а вы разве нет? Автор вроде интересовался и организацией хранения тоже, по крайней мере те варианты что он привел в вопросе, говорят об этом.
А то, что на Тостере подобную реальную сложно обсуждать - это статистика, и я, безусловно, в ней разочарован. За те ответы и вопросы которые тут дают и задают, на SO будут банить, простите, по IP.
Можете посмотреть другие мои ответы, если вдруг подумали, что я не пытался изменить это стереотип.

[Дэн Иванов]

Я посмотрел :) Но мне кажется изначально ущербным такое оправдание : "Не знаю где вы в этом разговоре увидели что я утверждал что мой вариант хотя бы жизнеспособен". Искренне не понимаю, зачем вообще предлагать нежизнеспособные варианты.

[Станислав Макаров]

xfg идея хэшировать контент безусловно не нова (Git), и шардировать по хэшу - тоже (Redis, Mongo), но конечно не факт, что она будет работать для ваших требований (размеры файлов, количество пользователей и т.д.). Все-таки стоит точнее определить требования: решение с поддоменами действительно часто встречается и работает, но это решение, в котором некоторые операции, например изменение файла, довольно сложно реализовать.
На самом деле я сам в поисках подходящего решения аналогичной задачи для следующего проекта, но пока все туманно. У меня правда требования немного другие (привязка файлов не к пользователям, а к объектам предметной области, которые появляются более контролируемым путем, нежели пользователи), но еще важнее поддержка известных протоколов. Необходимость писать клиентское приложение как у Dropbox или Skydrive выглядит не совсем радужно :) Была идея даже BitTorrent Sync попробовать, однако пока от нее отказались - торрентить маленькие файлы очень неудобно.

[Станислав Макаров]

xfg а вот кстати и хэши в ссылке: https://habrastorage.org/files/240/6a0/538/2406a05...

[Станислав Макаров]

Дэн Иванов видимо у нас разное представление об обмене знаниями на таких ресурсах). Я либо сам буду проверять идеи и советы, которые мне дадут, или спрошу еще 5 человек, прежде чем вкладывать в идею значительные ресурсы.
Т.к. в хэшировании файлов ничего нового нет, как и в хэш-шардинге, не считаю эту идею абсолютно утопичной и непригодной. Автор вообще хотел хоть что-то найти. Если бы он привел N известных распределенных ФС или object-storage, и спросил бы - что из этого применимо для системы с такими-то объемами данных и таким-то дневным трафиком, то конечно в таком контексте идеям не место. А когда пишут "велосипедное облако".. Даже не знаю, как-то само наводит на мысль об экспериментах :D
Через пару месяцев я и сам задам такой вопрос, т.к. в проект понадобится подобное файлохранилище для документов с привязкой к объектам предметной области, и я бы с удовольствием услышал подобный ответ, равно как и ваш совет взять CEPH или эллиптикс.

[Станислав Макаров]

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

[xfg]

Станислав Макаров: ну это понятно, я так же делал, чтобы равномерно распределять файлы по директориям, но это в контексте одного сервера. А хотелось бы видеть пример шардинга по хешу на много серверов. Вот вы сами сказали, что решардинг дорогая операция, а в вашем подходе, делать его придется каждый раз когда добавляется новая нода. Это одна из проблем. Также все сервера разные по своим характеристикам. На одной машине может быть объем жесткого диска в 1ТБ, а на другой 500ГБ. Представьте, что на машине с 500ГБ занятно все дисковое пространство, а на машине с 1ТБ его еще полно, но ваш алгоритм по хешу высчитывает, что вот этот конкретный файл нужно сохранить на машину с 500ГБ, но там уже нет места, что делать?

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

[Станислав Макаров]

xfg как правильно заметил Дэн Иванов, до готовой системы разумеется еще далеко, и граблей будет навалом. Я думаю мы бы с вами могли на пару недель сесть и обдумывать одни только проблемы и пути их решения.
Конечно, файлы было бы неплохо разбивать на кластеры, наподобие того как делают обычные ФС, и хэшировать кластеры, а не весь файл, а сами хэши сохранять в метаинфе, и хранить их как i-blockи хранятся в ext, по иерархическому принципу. Тогда файлы можно сильно фрагментировать (по 1 ГБ к примеру), и разбрасывать куски по хранилищам.
Маппинг пространства хешей на ноды можно немного усложнить, и мапать по принципу хэш-таблицы: если на ноду N файл не влазит уже, класть на N+1 (также и искать потом), позже, по достижению критического количества неверных попаданий, перехешировать, увеличивая длину части хэша, по которой определяется номер ноды (вместо первых 3-х байт хеша - первые 4).
Давайте решим, что вам нужно: вы готовы писать свой велосипед и решать все проблемы выше, или вам все-таки нужно готовое решение. Если готовое - вон, Дэн Иванов отлично посоветовал. Амазоновский S3 в конце-концов есть, даже ставить ничего не надо. Или может у вас файлы по 1кб и вам хватит того же Redis?)

[Дэн Иванов]

Станислав Макаров Все что Вы описываете можно свести к нескольким простым принципам.
1. Все ноды в "кластере" образуют хешринг, разбитый на диапазоны хэшей.
2. Каждая нода в кластере "держит" некую группу этих диапазонов, и желательно последовательную.
3. При добавлении новой ноды, мы выбираем некий объем данных (скажем 100Гб) и исходя из объема пространства выделенного под хранение, формируем N хешей (конечных точек диапазонов).
4. "Таблица маршрутизации" для операций чтения / записи, представляет собой хэш таблицу, где в качестве ключа используется конечные значения хэшей всех диапазонов, а в качестве значения имя ноды.
Т.о. как сайд эффект, в случае выпадения одной из нод, мы получаем "запись" на другую ноду. Но мы без проблем можем осуществлять "скан" соседних узлов, и осуществлять восстановление данных если были проблемы.
5. Для того чтобы не было таких проблем мы можем "задублировать" наше кольцо еще одной такой же группой. В случае возникновения ошибок чтения/записи, мы можем обращаться в эту реплику и с нее производить восстановление данных + сами операции. В качестве позитивного сайд эффекта здесь видится реализация групп с "горячим контентом" и с "устаревшим контентом" в случае необходимости.

Но все это велосипеды. Так работают leo/elliptics.
Решения ceph и подобные имеют альтернативный способ решения проблем: у них есть централизованные ноды хранящие метаданные. Это может быть проще в эксплуатации и первичной реализации, но минусом будет сложность реализации которая бы давала приличную скорость работы с самими данными, поскольку любая операция с ними будет требовать обновления этих метаданных. Если мы начнем говорить о том что наше "облако" гео распределенное, всплывает вопрос консистентности и еще более сложная ее реализация.

Поэтому я и призываю не "велосипедить", а изучить те решения что есть и выбрать подходящее. 2 года назад я столкнулся с такой задачей, потратил порядка 2 месяцев на выбор и тестирование различных решений. И время было потрачено не зря. Сейчас, оглядываясь на те очень тонкие проблемы с которыми мы столкнулись в эксплуатации, мне даже страшно представить с каким бы объемом других более явных проблем (которые просто не замечаешь, пока не прочитаешь архитектурную документацию по стораджам), мы могли бы столкнуться, если бы начали сами "велосипедить".

Answer 4

[Дэн Иванов]

А почему нельзя взять что то готовое типа webDAV. Запилить свой серверную реализацию, в которой осуществлять роутинг клиентов по N серверам если нужно. А публичный \ не публичный делать путем создания симлинков в папку public из папки общего хранения.