Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Тяпничное сравнение Memcached/Redis  [new]
mayton
Member

Откуда: loopback
Сообщений: 39224
Привет френды.

Дима. Илья. Жук-Ботан. Руслан. Экп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
    Вообще язык - не проблема тем более что одна их технологий просто поднимает телнет и позволяет
    вести с ним диалог по сокету.
  • 8 фев 19, 20:58    [21804901]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    Лысый дядька
    Member

    Откуда:
    Сообщений: 330
    mayton,

    Memcached, ИМХО, сравнивать с редисом не вполне корректно. Объясню, ридис, это же не просто in-memory key-value хранилище, он умеет еще многое помимо. Перечислю что знаю: 1) он таки может сохраняться на диск 2) он умеет реплицироваться и кластеризоваться 3) он имеет встроенный язык скриптов на Lua 4) у него есть pub/sub, то есть его можно юзать как брокер сообщений, что наша контора успешно юзает 4) у него есть Module API для впиливания кастомных типов и команд 5) у него есть транзакционность
    Что из этого умеет Memcached?
    Дисклаймер: с Memcached знаком опосредовано, возможно, он чертовски хорош, но мнение о нем на данный момент - кеш для Джанги его стихия, но не больше.
    8 фев 19, 21:13    [21804907]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39224
    Порты листнеров по умолчанию.
    Redis 0.0.0.0:6379 (TCP)
    Memcached 0.0.0.0:11211 (TCP) 
    
    8 фев 19, 21:14    [21804908]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39224
    Лысый дядька
    4) у него есть pub/sub, то есть его можно юзать как брокер сообщений, что наша контора успешно юзает

    Это.. модель publisher-subscriber? Какой-там протокол?
    8 фев 19, 21:18    [21804911]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    Лысый дядька
    Member

    Откуда:
    Сообщений: 330
    mayton
    Лысый дядька
    4) у него есть pub/sub, то есть его можно юзать как брокер сообщений, что наша контора успешно юзает

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


    Если не лезть в википедию, то предположу - сугубо свой, это точно не AMQP, возможно, MQTT. Я не задавался вопросом соответствия какому-то протоколу.
    8 фев 19, 21:24    [21804915]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39224
    Лысый дядька
    mayton
    пропущено...

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


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

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

    Вот здесь загвоздка. Не все key-value хранилища позволяют итератор.
    8 фев 19, 21:34    [21804922]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    Лысый дядька
    Member

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

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

    У редиса есть набор типов, один из них LIST. То есть вы под строковым ключом "key" можете хранить, грубо говоря, вектор и делать из него в цикле pop (справа или слева). Ключ удалится, когда не останется элементов.
    8 фев 19, 21:41    [21804926]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    mayton
    Member

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

    Ну. В SQL это было-бы аналогом.
    SELECT key,value FROM X WHERE value = 'FAILED';
    
    8 фев 19, 21:54    [21804931]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    Лысый дядька
    Member

    Откуда:
    Сообщений: 330
    mayton,

    вы вполне можете итерироваться по списку без удаления, есть команда LINDEX, можно получать сразу большой срез командой LARNGE ну и т.д., там десятки команд для десятка встроенных типов. Наверное, я слишком погряз в своей задаче и поэтому не вижу чужих юз-кейсов. Мы используем редис в основном как очередь для потока телеметрии и как основу для самописной message delivery system. И в этом смысле, мне не нужно хранить сообщения в очереди если они уже вычитаны клиентом. Но если вам нужно - бога ради, представьте, что у вас просто есть интерфейс к удаленным структурам данных типа vector, set, hashmap пр. - делайте что заблагорассудится.
    8 фев 19, 22:08    [21804939]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39224
    Ладно. Пока проехали со списками. Я тут поставил клиент memcache из пакетов nodejs.

    Интересно. Почему вызов SET key,vale - depracated?
    localhost:11211> help
    
      Commands:
    
        help [command...]                Provides help for a given command.
        exit                             Exits application.
        get <key>                        Get the value of a key
        set <key> <value> [expires]      Set the value of a key
        add <key> <value> [expires]      Set the value of a key, fail if key exists
        replace <key> <value> [expires]  Overwrite existing key, fail if key not exists
        delete <key>                     Delete a key
        flush                            Flush all data
        stats                            Show statistics
    
    localhost:11211> set user mayton
     MemJS SET: using deprecated call - arguments have changed
    true
    localhost:11211> 
    
    8 фев 19, 22:13    [21804941]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39224
    В редиске есть запрос ключей. По всей видимости я уже определился с кешом. Memcached уже неинтересен.

    127.0.0.1:6379> set user01 mayton
    OK
    127.0.0.1:6379> set user02 usoff
    OK
    127.0.0.1:6379> keys *
    1) "user01"
    2) "user02"
    
    8 фев 19, 22:40    [21804949]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    Dima T
    Member

    Откуда:
    Сообщений: 13348
    Про Redis не читал, а мemcached это key-value кэш в памяти, при переполнении вытесняются более старые данные. Как долговременное хранилище чего-либо мemcached не подойдет.
    9 фев 19, 08:33    [21805063]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39224
    Долговременным будет S3.
    Редиска или memcache по моей задумке должен быть прослойкой.
    9 фев 19, 09:49    [21805085]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    Ролг Хупин
    Member

    Откуда: Чебаркуль
    Сообщений: 2428
    Dima T
    Про Redis не читал, а мemcached это key-value кэш в памяти, при переполнении вытесняются более старые данные. Как долговременное хранилище чего-либо мemcached не подойдет.


    Я за редис.
    Протокол там свой.

    Еще что интересно: можно устанавливать TTL на элементы.
    Я пользуюсь этим для кеша, ставлю максимальное время жизни кеша, при обновлении - обновляется время если не обновилось редис сам уничтожит записи из кеша и они потом заполнятся, как при первом обращении.Т.е. клиент не должен заморачиваться, это важно.
    9 фев 19, 11:07    [21805116]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    softwarer
    Member

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

    В редисе справедливо решили, что основной тормоз - общение клиента с сервером. Поэтому для ускорения есть парочка хороших механизмов:

    1. Асинхронное общение. Клиент пихает потоком команды, а сервер потоком возвращает ответы. Соответственно, нужна логика, умеющая разобрать, какой ответ к какой команде относится, и алгоритм, позволяющий плевать новые команды прежде чем пришёл ответ на предыдущие.

    2. Скрипты. Если "бизнес-действие" опирается на данные внутри хранилища, то целесообразно весь расчёт провести внутри него и выдать наружу только результаты.
    9 фев 19, 12:59    [21805167]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    Anatoly Moskovsky
    Member

    Откуда: Odessa
    Сообщений: 6340
    mayton,

    Посмотрите еще tarantool.
    9 фев 19, 13:25    [21805172]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    alex55555
    Member

    Откуда:
    Сообщений: 1711
    mayton
    Для моего юзкейса нужно в час времени X перебрать все ключи
    и выполнить по каждому какое-то бизнес-действие. После этого базу можно дропнуть.

    А просто копить их в памяти не? Зачем вообще редис и прочие овощи? Обычная мапа, ну или BTree, при желании.
    mayton
    В SQL это было-бы аналогом.
    SELECT key,value FROM X WHERE value = 'FAILED';
    

    То есть модель тривиальна - однозначно просто в памяти хранить и обрабатывать без сторонних бетономешалок с функцией инжекции спирта прямо в желудок.
    9 фев 19, 14:33    [21805211]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    Лысый дядька
    Member

    Откуда:
    Сообщений: 330
    alex55555
    А просто копить их в памяти не? Зачем вообще редис и прочие овощи? Обычная мапа, ну или BTree, при желании.

    1. При краше обработчика данные превратятся в тыкву
    2. Нужно многопоточное приложение для одновременного приема и обработки
    3. Хреново масштабируется
    4. Нельзя использовать скриптовые языки с GIL
    5. Нет возможности построить цепочку обработчиков
    9 фев 19, 14:53    [21805223]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39224
    alex55555
    mayton
    Для моего юзкейса нужно в час времени X перебрать все ключи
    и выполнить по каждому какое-то бизнес-действие. После этого базу можно дропнуть.

    А просто копить их в памяти не? Зачем вообще редис и прочие овощи? Обычная мапа, ну или BTree, при желании.
    mayton
    В SQL это было-бы аналогом.
    SELECT key,value FROM X WHERE value = 'FAILED';
    

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

    Нет. Концепция работы с AWS lambda предполагает stateless обработку каждого бизнес объекта.
    В качестве хранилищ состояний предлагается Dynamo, S3, Elasticache.
    Dynamo нам пока недоступен. Поэтому довольствуемся S3 и эластичным кешом который просто имплементирует либо редис либо memcache.
    9 фев 19, 15:05    [21805231]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39224
    Anatoly Moskovsky
    mayton,

    Посмотрите еще tarantool.

    Ок. Спасибо.
    9 фев 19, 15:08    [21805236]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    alex55555
    Member

    Откуда:
    Сообщений: 1711
    mayton
    Концепция работы с AWS lambda предполагает stateless обработку каждого бизнес объекта.

    stateless это "без состояния". То есть обработчик не зависит ни от чего, кроме входных данных. Но как раз обработка без редисок даёт наименее зависимый от всего остального обработчик. А вот что добавляет редис?
    mayton
    В качестве хранилищ состояний предлагается Dynamo, S3, Elasticache.

    Ну вот, есть какие-то внешние хранилища (или это редискины запчасти?), из них надо данные взять, обработать и, как было замечено ранее, просто выкинуть (хотя результат всё же куда-то нужно пристроить). Опять получается - зачем редис?

    Я вообще конечно не настаиваю, но реально смысла в лишней прокладке не вижу.
    10 фев 19, 15:35    [21805690]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    alex55555
    Member

    Откуда:
    Сообщений: 1711
    Лысый дядька
    1. При краше обработчика данные превратятся в тыкву
    2. Нужно многопоточное приложение для одновременного приема и обработки
    3. Хреново масштабируется
    4. Нельзя использовать скриптовые языки с GIL
    5. Нет возможности построить цепочку обработчиков

    1. В таком дико редком случае данные снова прочитаются из хранилища.
    2. Что мешает реализовать?
    3. Это как? Много потоков не умеем писать, что ли?
    4. Зачем это убожество? Что бы сильнее тормозило?
    5. Я извиняюсь, а цепочку вызовов функций писать уже совсем не комильфо? Обязательно нужно каждый чих обвесить взаимодействием со станцией на марсе?
    10 фев 19, 15:39    [21805692]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    Лысый дядька
    Member

    Откуда:
    Сообщений: 330
    alex55555
    Лысый дядька
    1. При краше обработчика данные превратятся в тыкву
    2. Нужно многопоточное приложение для одновременного приема и обработки
    3. Хреново масштабируется
    4. Нельзя использовать скриптовые языки с GIL
    5. Нет возможности построить цепочку обработчиков

    1. В таком дико редком случае данные снова прочитаются из хранилища.
    2. Что мешает реализовать?
    3. Это как? Много потоков не умеем писать, что ли?
    4. Зачем это убожество? Что бы сильнее тормозило?
    5. Я извиняюсь, а цепочку вызовов функций писать уже совсем не комильфо? Обязательно нужно каждый чих обвесить взаимодействием со станцией на марсе?


    Это аргументы против чего? Допустим, разработчик не желает по каким-то своим причинам связываться с многопоточностью, допустим ДА ему нужно это убожество, допустим не комильфо. И что? Может еще дышать перестать, потому что лично ты считаешь такой способ существования пустым и убогим?
    10 фев 19, 16:23    [21805713]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 39224
    alex55555
    mayton
    Концепция работы с AWS lambda предполагает stateless обработку каждого бизнес объекта.

    stateless это "без состояния". То есть обработчик не зависит ни от чего, кроме входных данных. Но как раз обработка без редисок даёт наименее зависимый от всего остального обработчик. А вот что добавляет редис?
    mayton
    В качестве хранилищ состояний предлагается Dynamo, S3, Elasticache.

    Ну вот, есть какие-то внешние хранилища (или это редискины запчасти?), из них надо данные взять, обработать и, как было замечено ранее, просто выкинуть (хотя результат всё же куда-то нужно пристроить). Опять получается - зачем редис?

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

    Ты слышал про FAAS?
    10 фев 19, 16:43    [21805723]     Ответить | Цитировать Сообщить модератору
     Re: Тяпничное сравнение Memcached/Redis  [new]
    kealon(Ruslan)
    Member

    Откуда: Нижневартовск
    Сообщений: 4242
    mayton,

    не совсем понял, уже что-то есть и надо с этим как-то жить или пока вынашиваются стратегические планы?
    11 фев 19, 07:32    [21806035]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
    Все форумы / Программирование Ответить