Какую базу данных (или иной инструмент) выбрать под кэш скачанных изображений?

Question

[Валерий]

Здравствуйте, подскажите БД или какой-либо кэш-сервис для кэширования скачанных с внешних ресурсов изображений?

Интересует что-то, чему можно задать лимит потребляемой RAM для горячих данных, а все что не влезет хранилось бы на диске. При этом нужна возможность задания времени жизни объектам. Размер изображений до 1 Мб.

Нужен прямой доступ к хранилищу из nginx чтобы на эти изображения можно было бы указывать прямые ссылки.

Перманентность и высокая сохранность данных не требуется. Перезагрузил/все потерялось - вполне устроит.

Общее потребление RAM желательно не выше 1Гб. Планируемый общий объем около 100 Гб.

Желателен запуск в Docker, но с этим, если что, сам разберусь.

Более менее подходит S3 от Амазона (связка с nginx, ttl объектов и нет запарок с памятью), но проект не на AWS и использовать S3 извне выходит жутко дорого. Хотелось бы self-hosted решение в идеале.
Нашел https://minio.io/ но у них нет TTL объектов.

Можно конечно поставить Memcached, но он не умеет сбрасывать излишки на диск (если умеет, подскажите как), а выделить 100Гб оперативы дороговато. Redis тоже так не умеет, плюс у него есть проблемы с вытеснением старых объектов при переполнении.

Comments

[Валерий]

Дмитрий Беликов, Redis не умеет сбрасывать холодные данные на диск, освобождая RAM.
TTL он, само-собой, умеет ))

Answer 1

[m0nym]

Aerospike

а вообще я бы взял любую БД под метаданные (и отслеживания протухания кэша) и использовал бы обычные файлы для хранения самих файлов.

А если у вас протухание кэша одноразовое, если время жизни не продляется то еще проще - название файла равно дате его создания или дате протухания.

Comments

[Валерий]

А Aerospike умеет в TTL?
Смотрел на него, но потом наткнулся на то, что у них не готова экспирация объектов и даже не пробовал.
UPD: А нет, ошибся. У них проблемы со сбросом холодных данных на диск. По сути там получался тот же Redis, только в профиль.

На счет связки БД под мета данные тоже думал. Пока это, в общем-то, основная идея :)
Просто вдруг есть более готовые решения.

[m0nym]

Валерий Озарничук,

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

Че то вы не то посмотрели.

У Aerospike данные на диске.
В памяти - индексы.

[Валерий]

m0nym, Хм, спасибо, посмотрю.
Сейчас уже не найду, но натыкался на обсуждение именно о том, что он все данные в память грузит как Redis и перемещение данных на диск только в планах.

Если пользовались им, может подскажете сразу чать конфига для ограничения RAM до 1Гб?

[Валерий]

Я так понимаю, нужно что-то вроде такого:

namespace <namespace-name> {
    memory-size 1G  
    storage-engine device { 
    file /opt/aerospike/filename
    filesize 100G  
    data-in-memory false
    }
}

[m0nym]

Валерий Озарничук,

перемещение данных на диск только в планах.

у них принципиально данные на диске.
может вы давно читали.
или поняли прямо наоборот.

Если пользовались им, может подскажете сразу чать конфига для ограничения RAM до 1Гб?

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

[Валерий]

m0nym, пару-тройку месяцев назад.
Ладно, в любом случае спасибо. Я еще тогда заподозрил неладное, надо было потестить )

Answer 2

[Stalker_RED]

CacheFS + ramdrive?

Answer 3

[Андрей К]

Я может не совсем понял суть задачи, но чем не устраивает файловый кэш самой ОС?

Если хотите объектное, но не дорогое, можете посмотреть Digital Ocean, они реализуют API S3.

Ну ещё можно отдельно виртуалку взять и дать ей нужные ресурсы, если не важна персистентность. Можно у того же DO.

В общем, мне кажется, если Вы не уверены с решением, может опишите саму бизнес-задачу, может Вам кто-то подскажет вообще другое решение.

Comments

[Валерий]

Файловый кеш не устраивает отсутствием встроенного механизма автоматического удаления устаревших данных. Как выше предложили: связка БД под мета-данные и файлы - пока основной наш вариант, но все же ищу что-то более автоматизированное, вдруг кто сталкивался.

DO смотрел. Есть еще HotStorage от Mail.ru. Они впринципе дешевле AWS S3, но все же это удаленные хранилища. В идеале найти что-то локальное, чтоб не гонять гигабайты по внешней сети.

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

[Валерий]

Дмитрий Беликов, архивы собираются достаточно быстро, основное время - это именно Web запросы, т.к. сервера-доноры иногда попадаются очень и очень тормознутые.

Пока попробую Aerospike, как советуют выше. Судя по всему в прошлый раз я с ним ошибся.
Ну или остается БД с мета + файлы.

Answer 4

[d'Ivan]

Нужно отдавать изображения через кеширующий обратный прокси.
Linux умеет кешировать файлы с файловой системы. Нужно только дать ей (ОС) возможность выполнить эту работу. ОС сама будет кешировать наиболее часто запрашиваемые файлы и будет автоматически освобождать ресурсы в случае необходимости.
Я полагаю, что достаточно настроить Nginx и больше ничего дополнительного не нужно.
Также стоит проверить с Varnish, Squid, Apache Traffic Server.