Сведения о вопросе

nikolya

00:22, 18th August, 2020

Файловая система для авaтарок?

Просмотров: 411   Ответов: 11

Стоит задача хранения, сотен тысяч мелких изображений, в базе не хочу хранить. В ext3 тоже не хочу. Что посоветуете? Может есть какой демон или файлоая система которая это предназначена для этого?



  Сведения об ответе

ASER

22:19, 14th August, 2020

Гугл ничего не выдает, наверное готового нету. Пока на коленке родилось следующее решение.

1) В основной базе (mysql) храним всю мета информацию + ключ для картинки. Ключом является (имя файла sqlite + id)

2) Есть куча небольших (100-200мб) файлов sqlite в которых в блобах хранятся изображения.

Так как запись идет append only и предыдущие не будет меняться — то в ежедневный бекап будет попадать только последний sqlite файл.

Что скажите? бред?


  Сведения об ответе

baggs

15:50, 27th August, 2020

А бы я честно посоветовал бы базу, недавно копировал свои эти самые «маленькие изображения» — 600к их там — заняло день. А дел то было — толи на два, толи на три гига
Еще отчень хорошо отрабатывала tarfs — но она совсем реадонли


  Сведения об ответе

repe

10:04, 14th August, 2020

давным давно ответом на этот вопрос мог быть reiserfs


  Сведения об ответе

lool

05:50, 23rd August, 2020

Btrfs + хранение нескольких картинок в одном файле и указанием позиции в урл или еще где. Почитайте про архитектуру facebook и контакта, там много полезной информации.


  Сведения об ответе

PHPH

21:06, 1st October, 2020

Задумайтесь о том, что аватарки — это скорее всего много запросов на чтение.
При отдаче их из базы вы будете насиловать дисковую подсистему, в то время как при отдаче с диска _все_ аватарки (в зависимости от объема памяти сервера) могут быть закешированы системой в памяти и их отдача будет турбореактивной.


  Сведения об ответе

nYU

05:37, 21st August, 2020

Картинки нужно хранить на жёстком диске и никакая база данных тут не подойдёт т.к. создаётся неоправданная нагрузка на сервер. А вот насчёт как именно хранить, я бы рекомендовал разбивать на подпапки по id-фото таким образом: если фоток < 100k, то достаточно /ff/32123e21.jpg. Если > 100k && < 2m, то /ff/ff/321312312.jpg, ну и c /ff/ff/ff/321312312.jpg можно сразу в космос…


  Сведения об ответе

+-*/

05:26, 29th August, 2020

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


  Сведения об ответе

9090

23:32, 14th August, 2020

предположительно эта задача для couchDB


  Сведения об ответе

DAAA

20:37, 15th August, 2020

Посмотрите в сторону S3+CloudFront. И вам не надо будет заморачиваться с локальным хранением.


  Сведения об ответе

PAGE

13:04, 4th August, 2020

MogileFS ливжурналом была изначально создана для этой цели.


  Сведения об ответе

davran

20:32, 18th August, 2020

Может не совсем в тему, но вот тут sasgis.ru/forum/viewtopic.php?f=2&t=540 обсуждается схожая проблема, суть перенос сотен тысяч — миллионов тайлов от карт гугла и тп в программе сасгис, если кратко, то по крайней мере для переноса на флэш, пока 2 решения на уровне ФС, трукрипт с минимальным размером блока в контейнере(трукрипт по дефолту шифрует,… собака) и архивация tar\gzip, (который не запрашивает список файлов перед операцией архивирования, а сразу начинает архивировать т.е. скорость архивирования ~= скорости копирования).
может поможет

ээээх еслиб в винде можно было подключить таровсий архив как truecrypt или хотябы как iso…, потом одним архивом кидай куда хочешь…


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться