Нет, это как раз важно. Именно поэтому появилось множество различных файловых систем решающих разные задачи, разные типы БД и т д. В самом общем кейсе - велосипед не нужен, берете любой опенсорсный object storage и получаете "средненькое" решение во всём.
Про каких "миллионов человек" Вы говорите, когда пытаетесь моделировать и "исправлять" ситуацию когда миллион файлов в 1 директории. Что то получается что человек по 50 на сервер, не больше.
Вряд ли там будут 1кб файлики. У "обычных" пользователей средний размер побольше будет.
Да встречался. "Замеряли скорость к файлам" - ШТА ? Да замерял, скорость доступа зависит от многих факторов и в больше степени не от "количества файлов в директории" а от специфики операций чтения/записи происходящих в этот момент в системе. В идеальном случае содержимое всей вашей директории будет в dentry/inode cache и листенинг у Вас будет моментальным.
Что значит "сбалансированная" ? Первоначальное размещение "корневых" директорий пользователей ? С этим наверно согласен, но не вижу смысла приводить всю структуру директорий к такому виду.
А где написано что это учебное задание ? Вы что то додумали и теперь советуете - понимаете что можете оказать медвежью услугу таким советом ?
"это не то, что вообще можно обсуждать на Тостере в его нынешнем виде." - Тостер формирует его коммьюнити, и мне кажется что многие местные посетители считают себя умнее других или то что "им виднее", что делает их ничуть не лучше тех людей которые задают вопросы решающиеся гуглением.
Какой человек будет ложить 13м файлов в 1 каталог ? Он же глазками будет на эти файлики смотреть.
Я исхожу из предположения, что изначально есть сущность "пользователь", так пусть у каждого пользователя будет своя точка входа - бакет, директория, раздел как угодно назовите. Нахрена все укладывать в одну кучу ? Если же предполагается использовать это "облако" как object storage так нечего велосипедить, взять любой подходящий и все.
Станислав Макаров: Задам проще вопрос. Представьте что у вас машины с разного объема дисками. Что будете делать ? Все "претензии" описанные xfg это малая часть тех проблем с которыми придется столкнуться.
Если не ошибаюсь, человек спрашивал про организацию приложения, а не хранения. То что вы описываете реализовано во множестве распределенных ФС, начиная от тупенького glusterfs и заканчивая CEPH/leofs/elliptics. Все это можно подцепить как backend для приложения, и использовать эти object storage для хранения файлов. Там люди уже много раз прошлись по тем граблям, по которым хотите погулять Вы.
В более менее продвинутых решения типа Ceph/elliptics/leofs есть понятия buckets или что то подобного что очень легко маппится на авторизацию. И задача "сервера" сводится к управлению файлами в публичном/приватном бакете конкретного пользователя. Для обеспечения быстрого листенинга и подобных операция, можно хранить метаданные (списки директорий с размерами файлов и правами доступа) в быстрых хранилищах типа редиса. Искренне не понимаю зачем это дублировать еще в одной базе.
Субъективно - вы велосипедите. Оптимальное размещение файлов старается обеспечивать ФС, размещая блоки хранения таким образом чтобы доступ к ним осуществлялся максимально быстро, и при этом файлы были распределены равномерно по пластинам.
Пытаться решать проблему "много файлов в куче", нужно не таким образом, а заставляя пользователей группировать файлы. Либо если пользователю так нужно они сами должны осознавать что это будет не быстро в любом случае. Поскольку тупо объем данных передаваемый на листининге клиент-сервер будет относительно велик.
Дедупликация данных, также может обеспечиваться на уровне ФС, зачем это тащить в приложение ?
Согласен что решение S3+CF будет проще, с точки зрения реализации. Но вот счет ежемесячный будет такой что не сложить в уме цыфорки).
Может тогда лучше взять RunAbove в качестве хранилки, а в качестве CDN присобачить cdn77.com или cdn.net ?
Верно, не стоит ожидать скорости чтения с тома выше 80Mb и 100IOPS. Но может у них что то поменялось, монтируемый драйв потому и дешевый, что он не SSD и используется больше как "архивное" хранилище, а не как оперативное.
Для ускорения можете как раз использовать CDN. Но прежде чем начать использовать, советую посмотреть, каков объем "активного" контента из всего вашего архива. Возможны разные специфические кейсы того как пользователи смотрят Ваш контент : один раз сразу после аплоада, или постоянные просмотры только у 1-2% всего архива, или наоборот смотрят весь архив в течении месяца по чуть-чуть. Исходя из этого, поймете стоит ли Вам использовать CDN, или достаточно парочки кеширующих nginx c SSD.
Все, так. К виртуалке монтируется несколько стораджей. Возьмите и попробуйте, там не такие большие деньги просят. Можно им написать и спросить какое у них ограничение на максимальный размер монтируемого тома.
В большей степени соглашусь с Вами. Но мне кажется системные камеры от fuji(E/M/T), sony NEX, olympus pen /panasonic-lumix, имеют относительно схожие размеры, и при тех же деньгах дают качество получше.
К вопросу о том, что же понимать под съемкой - я выработал для себя правило, что если человек спрашивает то нужно советовать камеру под "стрит". В большинстве случаев это прокатывает :)
Всю информацию о запросе nginx хранит внутри себя, от начала и до конца запроса, с учетом его отправления на backend. Тоесть, в том локейшене которые у вас проксирует запрос на бэкенды, вы должны описать логику как для proxy_request так и для proxy_response который превратится в обычный пользовательский response.
То как это сделать, обуславливается доступными директивами nginx. Часть из них влияет на request, часть на response.
В примере выше, есть директива `proxy_hide_header `, если заглянуть в документацию становится понятно, что она изменяет request который будет направлен бэкенду. С `add_header` тоже самое.
По идее в указанном примере можно обойтись и без set, но я его добавил просто для того, чтобы было понятнее (взяли из запроса и сохранили, скрыли из запроса для прокси, повторно добавили к ответу, каждая директива сработает на своем этапе обработки запроса).
