LINUX.ORG.RU

Нужны мысли по организации хранения файлов.

 , , , ,


3

4

Задача — утягивать файлы по url (видео, картинки) и складировать в хранилище. Так, чтобы впоследствии по url можно бы было получить сразу локальный файл. Без БД.

Файлов много, десятки, сотни тысяч. Количество год от года растёт.

Первый, много лет назад вариант был тупым — берём md5(url), разбиваем на две вложенности по два символа и сохраняем файл — storage/dd/75/dd753e96f09cf8afedc9882da55977a2.jpg

Попутно можно там же положить одноимённый .txt со ссылкой на исходный файл для обратного поиска.

Вариант всем хорош для небольших объёмов. На больших, да ещё под ext4, которая по мере старения на таких структурах начинает чудовищно тормозить, получился ад при любых работах по бэкапу/настройкам. rsync, занимающий десятки минут — это жесть. Если для аналогичного подхода с аттачами, имеющими дату вопрос решается просто — Мысли вслух. Предостережение от наступления на грабли. , то для произвольных ссылок так уже не поступить.

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

Вторая версия была устроена чуть иначе. Файлы кладутся в каталоги, напоминающие исходные домены и пути. Например, storage/ru/li/linux.org.ru/tango/img/opensource-logo.png

Как ни странно, такая структура даже чуть легче при копировании, гораздо удобнее при анализе. Но всё равно очень избыточна и тяжела. Кроме того, возникают проблемы с URL, содержащими сложные для имён файлов символы — get-запросы и т.п.

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

Есть мысли, куда копать?

Update из темы:

— Задача: «архивирование Интернета». Через 5..10..15 лет остаётся очень мало доступных картинок, видео, аудио, на которые ссылаются на форумах. Хочется это дело эффективно кешировать, да ещё и раздавать потом через btsync желающим, тем более, что форумы планируется переводить на распределённый формат — Распределёные форумы/блоги. Продолжаем разговор. Нужен совет.

— Подразумевается использование в рамках p2p-системы на базе btsync или будущих аналогов. Т.е. никаких файлоспецифичных вещей, метаданных, спецсимволов и т.п. Должно работать хоть на vfat.

— Желательно, чтобы система могла уметь дробиться на отдельные архивы/репозитории.

— Вопрос индексирования мало актуален, т.к. данная система подразумевается бэкендом. Перед фронтедом может стоять кеширующая полноценная БД.

— Желателен человекочитаемый формат, чтобы можно было разгребать систему вручную.

— Участники обмена должны иметь возможность передавать данные в т.ч. из-за «серых NAT», потому и ориентируюсь на btsync и аналоги.

Так как-то.

★★★★★

Последнее исправление: KRoN73 (всего исправлений: 2)

Ответ на: комментарий от anonymous

Желательно, чтобы система могла уметь дробиться на отдельные архивы/репозитории.

хранить отдельно от документа список его список

что есть «список его список»? я это понимаю так, как метаданные (в виде наподобие HTTP-заголовков, или git заголовков для tree object, commit и т.п.)

то есть: контент (данные) отдельно, метаданные — отдельно. контент может быть сархивирован, в метаданных останется только ссылка на архив (вставить ленту с бекапом такую-то, например). при этом из-за CAM такие архивы можно будет срегенерировать с любого второго бекапа, то есть, в первом можно вообще грохнуть.

anonymous
()
Ответ на: комментарий от KRoN73

Но это всё дальние этапы, где будет много сложностей

ну те же ii-шники в своей сети какие-то из этих этапов вполне успешно прошли. а там вообще простая как палка структура.

тут тоже нужно что-то простое, только если у ii это мессаги — тут будут файлы как документы = данные+метаданные+адрес_в_CAM

anonymous
()
Ответ на: комментарий от blexey

или не как попало последовательные иноды, а хеш от содержимого блоба.

anonymous
()
Ответ на: комментарий от KRoN73

Тупо md5(url).

не md5(url), а md5(curl(url)). это путь в CAM-памяти для блоба. а md5(url)  — один индекс этого блоба, url — второй , local_physical_cached_filepath(url) — третий, my_ЧПУ_semantic_logical_filepath(url) — четвёртый.

и все эти индексы связаны друг с другом, разумеется.

anonymous
()
Ответ на: комментарий от emulek

то осталось выбрать СУБД, структуру таблиц, и тема решена.

таблицы не нужны, как и РСУБД. нужно key-value, или например, MUMPS.

anonymous
()
Ответ на: комментарий от anonymous

хранить отдельно от документа список его список

хранить отдельно от документа список его ссылок, вероятно

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.