LINUX.ORG.RU

SQLite/in-memory в роли хранилища сессий


0

2

Есть ли смысл использования in-memory SQLite в роди хранилища сессий (короче, key-value) - т.е. там, где торадиционно фапнатеют от Redis (или Memcached)?

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

Ваши мнения, господа?

sqlite, безусловно, использовать можно. Но вот нужно ли? Вам подойдет обычная хэш-таблица.

dmitry_vk ★★★ ()

пока что из читанного узрел, что SQLite раз в 6 шустрее Redis

Это не та газета, где инопланетян видели. Как-то ОЧЕНЬ сомнительно.

feofil ()

key-value

SQLite имхо избыточен. Обычный DBM вполне подойдёт.

DELIRIUM ☆☆☆☆☆ ()

Возможно просто используйте нужную структуру данных? Поищите в бибилиотеках своего ЯП

Мне хватает

scala.collection.concurrent.TrieMap

A concurrent hash-trie or TrieMap is a concurrent thread-safe lock-free implementation of a hash array mapped trie. It is used to implement the concurrent map abstraction. It has particularly scalable concurrent insert and remove operations and is memory-efficient. It supports O(1), atomic, lock-free snapshots which are used to implement linearizable lock-free size, iterator and clear operations. The cost of evaluating the (lazy) snapshot is distributed across subsequent updates, thus making snapshot evaluation horizontally scalable.
vertexua ★★★★★ ()
Ответ на: комментарий от feofil

Если вы сами напишите мапу, то будет не только в 6 раз быстрее. Вопрос будет в сложных запросах.

vertexua ★★★★★ ()

если быстрее то имеет. Только вот redis у тебя расшареный, а sqlite :memory: доступен только одному процессу.

true_admin ★★★★★ ()

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

true_admin ★★★★★ ()

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

dycore ()

У меня были проблемы только с конкурентным доступом. Допустим вы безостановочно пишите в бд, одновременно с этим другой процесс решит прочитать только что записанные данные и в итоге получите дедлок. У BerkeleyDB таких проблем нет, но читающий процесс может уснуть/ждать разблокировки несколько секунд, что выливается в ненужные тормоза. По идее bdb можно вылечить от этого недостатка, но я не углублялся. SQLite чисто для одного процесса идеально подходит, как шаринг ресурсов - нет. Этим побеждает redis, mongo, etc т.к. заточены под такую архитектуру.

gh0stwizard ★★★★★ ()

Более того, mmap'ed files on tmpfs порой быстрее, чем sqlite в качестве стораджа ключ-значение, особенно, если у вас в качестве значений только текст (пропускается этап сериализации). Если в вашем яп уже имеется апи под mmap рекомендую взглянуть сначала на него. Что это дает? Определенный контроль над потребляемой памятью (возрат памяти в ОС), а также конкурентый доступ между процессами в рамках одной машины.

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