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

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

sqlite в ram

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

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

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

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

etcd

Фигасе ты попроще назвал.

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

Я бы брал редис и не парил себе мозг, не такой уж он и «сложный», зато проверенный временем и с заделом на расширение

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

Для Clojure есть такой велосипед: https://github.com/tonsky/datascript

Который, в свою очередь, альтернатива https://www.datomic.com/.

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

systemV sem and shm

ахринеть кастылище

Херню ты выдумал.

Нужен k-v storage в рантайме - возьми библиотечную структуру данных.

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

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

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

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

memcached

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

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

тебе нужна https://arrow.apache.org/docs/python/plasma.html

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

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

наступать на некоторые неочевидные грабли, которых по моему мнению быть там не должно

А можно подробнее, мне правда интересно.

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

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

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

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

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

Ясно, спасибо за информацию.

Нужен k-v storage в рантайме - возьми библиотечную структуру данных.

+1. HashMap называется, или типа того.

Чем не устраивает ассоциативный массив?