Привет френды.

Дима. Илья. Жук-Ботан. Руслан. Экп98. И все-все кодеры и сочувствующие.

Вся прошедшая неделя для меня прошла под флагом оптимизации взаимодействия Amazon/Lambda и S3 хранилища.
S3 - это тоже API от амазона который переводится как S3==SSS==SimpleStorageService и по внешнему виду
похож на гибрид файловой системы и хеш-таблички. Имеет дохрена опций мета-информации и QOS. На каждый
файл можно цеплять атрибуты mime и индексировать. Вобщем налицо веб-ориентированность.

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

Цель - ускорить бизнес-процессы которые за 1 сеанс будут читать и писать порядка 50 000 тысяч мелких файлов в S3.

Собсно вопрос.

Кто работал с
Memcached

Redis

Общие вопросы.
1) Типы данных тут и там?
2) Репликация-кластеры.
3) Интеграция с приложениями. Роли? Архитектуры? Будет классно если есть картинки или диаграммы взаимодействия.
4) Только-ли кеш? Или можно сказать БД?
5) Параметр time-to-leave для записей. Рекомендации? Кто юзал и как? Что было достигнуто?
6) Интересные юзкейсы. В рекламных видео знатоки хайлоад показывают
как редиска-мемкеш ускоряют работу в БД. И мне в этой части интересны коробочные решения.
7) CLI. Инструменты мониторинга и бекапа.

Какие фидбеки? Какие есть инструменты для загрузки туда данных? Какие типы данных и прочее.
По сабжу (чуть позже меня будут интересовать технологии AmazonElastiCache но это просто фронт
для этих двух вышеперечисленных штук).

ЯП. На данный момент рассматриваю всю линейку языков. В продуктиве у нас Java/Python/Go
Вообще язык - не проблема тем более что одна их технологий просто поднимает телнет и позволяет
вести с ним диалог по сокету.

Порты листнеров по умолчанию.

Лысый дядька4) у него есть pub/sub, то есть его можно юзать как брокер сообщений, что наша контора успешно юзает
Это.. модель publisher-subscriber? Какой-там протокол?

Лысый дядькаmaytonпропущено...

Это.. модель publisher-subscriber? Какой-там протокол?

Если не лезть в википедию, то предположу - сугубо свой, это точно не AMQP, возможно, MQTT. Я не задавался вопросом соответствия какому-то протоколу.
ОК. Спасибо. Еще. Для моего юзкейса нужно в час времени X перебрать все ключи
и выполнить по каждому какое-то бизнес-действие. После этого базу можно дропнуть.
Она не нужна.

Вот здесь загвоздка. Не все key-value хранилища позволяют итератор.

Это .. странно. Мне надо 50 тысяч ключей сначала обработать. При этом каждый ключ - это суть файловый путь.
Обработка заключается в последовательном тректинге статуса. Грубо говоря все бизнес-объекты проходят статусы.
И в конце некий итоговый процесс должен посчитать сколько выпалов ошибки. Принять решение.

Ну. В SQL это было-бы аналогом.

Ладно. Пока проехали со списками. Я тут поставил клиент memcache из пакетов nodejs.

Интересно. Почему вызов SET key,vale - depracated?

В редиске есть запрос ключей. По всей видимости я уже определился с кешом. Memcached уже неинтересен.

Долговременным будет S3.
Редиска или memcache по моей задумке должен быть прослойкой.

alex55555maytonДля моего юзкейса нужно в час времени X перебрать все ключи
и выполнить по каждому какое-то бизнес-действие. После этого базу можно дропнуть.
А просто копить их в памяти не? Зачем вообще редис и прочие овощи? Обычная мапа, ну или BTree, при желании.
maytonВ SQL это было-бы аналогом.


То есть модель тривиальна - однозначно просто в памяти хранить и обрабатывать без сторонних бетономешалок с функцией инжекции спирта прямо в желудок.
Нет. Концепция работы с AWS lambda предполагает stateless обработку каждого бизнес объекта.
В качестве хранилищ состояний предлагается Dynamo, S3, Elasticache.
Dynamo нам пока недоступен. Поэтому довольствуемся S3 и эластичным кешом который просто имплементирует либо редис либо memcache.

Anatoly Moskovskymayton,

Посмотрите еще tarantool.
Ок. Спасибо.

alex55555maytonКонцепция работы с AWS lambda предполагает stateless обработку каждого бизнес объекта.
stateless это "без состояния". То есть обработчик не зависит ни от чего, кроме входных данных. Но как раз обработка без редисок даёт наименее зависимый от всего остального обработчик. А вот что добавляет редис?
maytonВ качестве хранилищ состояний предлагается Dynamo, S3, Elasticache.
Ну вот, есть какие-то внешние хранилища (или это редискины запчасти?), из них надо данные взять, обработать и, как было замечено ранее, просто выкинуть (хотя результат всё же куда-то нужно пристроить). Опять получается - зачем редис?

Я вообще конечно не настаиваю, но реально смысла в лишней прокладке не вижу.
Ты слышал про FAAS?

Давайте так.

Тема топика - кеши. В принципе я уже выбрал Редис.

И тему можно закрыть.

полудухmaytonЭто .. странно. Мне надо 50 тысяч ключей сначала обработать. При этом каждый ключ - это суть файловый путь.
Обработка заключается в последовательном тректинге статуса. Грубо говоря все бизнес-объекты проходят статусы.
И в конце некий итоговый процесс должен посчитать сколько выпалов ошибки. Принять решение.

Ну. В SQL это было-бы аналогом.


я бы демона на C++ сваял
Амазон не поддерживает С++ в AWS Lambda.

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

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

Но да. Это все off.

Попрошу закрыть. Я уже выбрал технологию.
Модератор: Закрыто по просьбе ТС