LINUX.ORG.RU

in-memory db: альтернативы для Redis, Memcached

 , ,


0

2

Есть что-нибудь проще, чем Redis?

Требуется хранение набора констант и набора массивов числовых значений, чтобы они были доступны из нескольких воркеров бэкенда на python. Т.е., библиотека доступа к базе данных должна быть thread-safe.

База нужна only in-memory, без хранения в постоянной памяти. Инициализировать я её буду вручную, при старте приложения.

напиши функцию которая будет сохранять переменную и её содержимое в файл в формате самого языка программирования, а затем просто инклюдь этот файл в процессе работы. :) :) :)

Spoofing ★★★★★ ()

Требуется хранение набора констант и набора массивов числовых значений, чтобы они были доступны из нескольких воркеров бэкенда на python

Это ж синглтон.

И если это бэк на питоне, то наверняка в фреймворке есть уже механизм.

vvn_black ★★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от no-such-file

etcd же умеет только key-value, не как в редисе - целый навороченный фреймворк, единственное, что etcd это гео распределённое хранилище, со всеми сетевыми фичами. Если тс’у нужно хранилище только для тредов - это одно, для межпроцессного - это уже лучше в сторону редис или пайпов юникс, вцелом, за дня 3 можно на питоне своё хранилище накостылять, не нужно этого бояться, питон для этого и создан

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

Тоже подумал так первым делом, пока топик не прочёл. Всё же ему key-value нужно. Не ясно при этом, зачем ему вообще отдельное хранилище, так что без уточнения ничего толком посоветовать нельзя.

WitcherGeralt ★★ ()
Ответ на: комментарий от deep-purple

не вижу чем этот метод плох с точки зрения in-memory-storage производительности. да, тут на лицо проблемы с безопасностью, что данные придётся трижды escape'ить. но в остальном то что?

ЯП будет работать с самим с собой, со своими же данными, напрямую. массив переменных будет храниться в памяти. да? да. по логике вещей это должно быть производительнее, чем любое другое in-memory-storage в виде отдельного приложения типа memcached, потому что скрипту не нужно вызывать различные API ядра для обращения по внутренним протоколам, интерфейсам для получения данных у другого процесса. даже если это будет не tcp://127.0.0.1, а вполне себе библиотека, всё равно это ещё остаётся обращение к постороннему процессу за данными.

ну я не буду спорить, если инклюд файла с диска в данном случае окажется всё же ощутимой нагрузкой. если API обращение к in-memory-storage окажется быстрее чем обращение к in-filesystem-storage, условно говоря.

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

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

единственное, что etcd это гео распределённое хранилище, со всеми сетевыми фичами

Я так понял, что ТСу нужно встраиваемое решение, чтобы отдельный сервер не разворачивать. Типа apcu из пыха.

no-such-file ★★★★★ ()
Ответ на: комментарий от eternal_sorrow

чем не устроили озвученные в заголовке варианты? зачем альтернативы?

В принципе, memcache/memcached устраивает - я прочитал по нему фичи на днях. А от Redis я пока откажусь - так как с 2009 года примерно с ним сталкиваюсь, не нравится (работает, но приходилось наступать на некоторые неочевидные грабли, которых по моему мнению быть там не должно).

Mirage1_ ()
Ответ на: комментарий от no-such-file

А можно подробнее

Примерно в 2009-2010 году я смотрел его. Был довольно сырой биндинг в Python. Я так понял, какая-то студенческая поделка.

В 2016-2020е годы пробовал ещё неск.раз. Но каждый раз приходилось настраивать, из коробки приводило к переполнению памяти (не хватало памяти, так как из-за программной ошибки оставались неудалённые значения в хранилище, каждое значение - порядка 1 мегабайта). Прозрачного мониторинга за состоянием памяти Redis тогда в 2016м году я не нашёл. Нашёл только в 2020м году.

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

Ещё какая-то вещь была, из-за которой пришлось потратить несколько часов на гуглёж. Но это уже забылось. Краткий вердикт был такой: довольно сильный, но слишком нестандартный программный продукт. Проще взять какой-то ближний и более стандартный аналог. Я пока думаю остановиться на memcache/memcached.

Mirage1_ ()