LINUX.ORG.RU

Свопирование записей Redis

 , ,


0

3

Пробую разобраться.
Redis у меня используется для хранения сообщений от брокера - раздача пакетов заданий на вычислительные ноды.
Согласно redis.io, «Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker.»
Но тут проблема. На VDS мало оперативки, а диск - быстрый SSD. Хотелось бы, чтобы по достижении лимита maxmemory, или близко к нему, Redis сбрасывал данные на диск, начиная с самых старых записей. Можно конечно, навелосипедить вручную, установив maxmemory-policy noeviction. Но хочется чтобы БД не ждала до упора, а заранее начинала свопить записи.

При этом, хочется не использовать системный swap.

Или проще в таком случае не заморачиваться, и запихнуть всё в Postgres? Супер-экстремальной производительности мне не требуется, пока достаточно 200-300 записей в секунду, и вряд ли будет сильно больше 1000 записей/сек. Постгрес у меня на сервере всё-равно будет крутиться.

Есть ли простое решение для Redis? P.S.Я решил пока не мучаться с Celery.

нет мозгов на inmemory - не суй в redis. сообщения в редисе ты должен быть готов потерять как только твой редис грохнется, он ничего тебе не обещал. и как ты будешь работать со своими записями в свопе если редис грохнется? вот у тебя приложение уверено, что записи в редис ушли, вот редис грохнулся, оставив половину пакетов заданий в свопе, вот переподнялся - и чо?

anonymous
()

в самом деле, дальше чтения рекламной документации мозгов - ну вот дефицит. один постгрес в докер сует, другой свопит inmemory хранилище.

были же люди как люди и вдруг все сразу стали кретины. не понимаю.

anonymous
()

Redis просто не работает, если твои данные не помещаются в RAM.

anonymous
()

У тебя очень странная очередь если в штатном режиме подразумевается овердохрена ждущих выполнения сообщений. Ты же понимаешь, что средняя скорость накидывания не должна быть больше скорости разгребания. Я понимаю пики вот это все. Но как-то это пованивает.

Постгря твой дохлый vds раком поставит на 300 записях в секунду.

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

Постгря твой дохлый vds раком поставит на 300 записях в секунду.

Спасибо, буду копать в сторону RabbitMQ/Celery.

Mirage1_
() автор топика
Ответ на: комментарий от ggrn

А если попробовать заменить редиску на рэбит?

Да, наверное так и сделаю.
Пока проект на стадии прототипирования, не продакшн. Есть резерв для манёвра.

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

Пока проект на стадии прототипирования, не продакшн. Есть резерв для манёвра.

Был момент когда мы так в бою сделали. Ничего страшного не произошло. ^__^

ggrn ★★★★★
()
Ответ на: комментарий от Mirage1_

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

может тебе лучше бы в проститутки податься? а чо, там кроме часа пик - времени хватает

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

Ты бы лучше образование поднял своё, анонимус =) жизни ещё не видел, а советы по интернету даёшь.

Mirage1_
() автор топика
Ответ на: комментарий от Suntechnic

Сохраняй в файл. Я серьезно.

Хм-хм. Интересный вариант. В плане простоты, а значит и надёжности.

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

Может внезапно оказаться что еще и скорости. На самом деле все зависит от того каково соотношение чтение/запись.

Suntechnic ★★★★★
()
Ответ на: комментарий от AnDoR

А кстати если запихнешь в PostgreSQL - там смотри будет засада: ( особенно если несколько клиентов у тебя очередь будут разбирать ) Прийдется лочить таблицу (LOCK table) перед тем как взять очередной элемент из очереди.

Jopich1
()
Ответ на: комментарий от pru-mike

Ну ты же понимаешь, что нет скорее всего. На самом деле надо пробовать. Без тестов ничего не скажешь.

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