LINUX.ORG.RU

Redis vs LevelDB

 , ,


1

1

Предыстория: начал изучать Node.JS и Key-value-Store сначала с NStore, потом по совету консультанта перешел на LevelDB. Переход был правильным и обоснованным (библиотека NStore заброшенна, постоянные падения сервера). Но в LevelDB непонятки с репликацией, хотя она там и есть.

Теперь вызвался писать новый движок для Redis, используя библиотеку node_redis.

Раньше у меня было 2 store: ключи в обеих store одинаковые, а values разные - в первом JSON, во втором binary. Разделение нужно было из-за невозможности одноврменного хранения в LevelDB по одному ключу данных разным encoding. LevelUP предоставлял логичное API:

createReadStream - SELECT всех ключей/значений с условием/фильтрацией/сортировой/ограничением на кол-во записей.

put(key, value), где key - строка, value - JSON объект ну и db.get.

А после посмотра API байндингов для redis, у меня возник один большой вопрос: а как на этом всем уехать? Как реализовать аналогичный фунционал? Где хранить данные обеих store? В разных базах?

Почему, к примеру, в Redis нет

#.getall
, а есть только #.hgetall?

Делается ли автоматическая (де)сериализация JSON данных? Где и как хранить бинарные данные по ключу из 2-го store? Эти данные берутся из файла. Можно ли перенаправить потоки? Если да, то как?

Зы. Или может redis тут тупо не подходит? А что тогда есть с нормально реализованной master-slave репликацией, которая уже может применяться в продакшене?

SELECT всех ключей/значений с условием/фильтрацией/сортировой/ограничением на кол-во записей.

Такого в Redis нет вроде. Там же хеш-таблица используется. Определённого порядка у записей нет.

с условием/фильтрацией

http://redis.io/commands/keys, http://redis.io/commands/get

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

Хеши играют в Redis роль объектов-контейнеров, способных хранить произвольное число пар ключ-значение. ... Хеши хороши тем, что позволяют избежать сохранения данных с ключами, имеющими искусственные префиксы.

Нужно ли использовать в моем случае хэши? что группируются в хэше? Хэш = имя таблицы (в терминах SQL)/имя sublevel (в терминах LevelDB) или все-таки внутри хэша ВСЕГДА хранятся поля?

Т.е. записи

SET users:goku {race: 'sayan', power: 9001}

и

HSET users:goku race sayan
HSET users:goku power 9001

эквивалентаны? Когда нужно использовать первое, когда второе?

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

А теперь понятно:

The difference comes down to how you're going to manipulate and query it. If you need control over individual fields, and you don't want to pull the whole object into your app, use a hash. Otherwise, a String is probably what you want.

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