2016-06-27 2 views
0

Я реализую структуру данных стека с использованием типов данных списка redis-py и Redis. Я не понимаю, как обрабатывать случай, когда соответствующий тип данных списка пуст. Поведение по умолчанию Redis похоже, что после того, как список пуст, связанный ключ удаляется. Например, случай с пустым списком попадает в Redis, когда я выхожу или очищаю все элементы в структуре данных стека на конце Python. В принципе, моя настройка заключается в том, что у меня есть стек объекта в моем коде, который вызывает операции в списке Redis. Например, когда клиент объекта стека выполняет stack.pop(), объект стека затем вызывает BRPOP в соответствующем списке в Redis, используя redis-py. Кроме того, в моей настройке объект стека имеет ключевой атрибут, который является ключом связанного списка в Redis.Реализовать структуру данных стойких стеков, используя Redis

Я думал о 2 возможных решений до сих пор:

  1. Никогда не опустошить список Redis полностью. По крайней мере, поддерживать один элемент в списке. С точки зрения клиента стек пуст, если список Redis содержит только один элемент. Этот подход работает, но мне он в основном не нравится, поскольку он включает отслеживание количества элементов, нажатых/высколых.

  2. Если список пуст и связанный ключ удален. После последующего нажатия просто создайте новый список в Redis. Этот подход также работает, но сложность здесь заключается в том, что я не могу быть уверен, что кто-то создал k, v pair на Redis, используя тот же ключ, что и мой объект-стек.

Итак, я в основном ищу способ сохранить ключ с пустым списком, который не требует ведения бухгалтерии, требуемой в двух вышеуказанных подходах. Благодарю.

+0

2-е решение наилучшим образом подходит. Я не вижу никаких проблем с этим. Вам не нужно создавать список, просто сделайте Lpush или спешите, он будет создан. Аналогично, если вы получаете (nil) в своем pop, стек пуст и обрабатывает его в логике приложения. Я не понимаю, что вы имели в виду, отслеживая жизнь ключей. Кроме того, redis - это база данных без sql, поэтому вы должны иметь контроль над ключами, которые вы вставляете, вы не можете сказать, что у вас нет контроля над кем-то другим, создающим тот же ключ, что и ваш. –

+0

@ KarthikeyanGopall другие ресурсы онлайн, кажется, что для того, чтобы избежать столкновения с ключами, требуется какое-то соглашение об именах. Контроль над тем, какие ключи идут, - это результат процесса (ручного или автоматизированного), который можно ввести в действие. Кажется, что Redis не дает вам этого объекта, а скорее ему нужно обращаться за пределами Redis. Кроме того, бит жизни ключа отслеживания в моем вопросе был неоднозначным, поэтому я отредактировал. – Waqas

ответ

1

Ваше второе решение является лучшим Fit.

Да, вы должны поддерживать соглашения об именах, это очень просто для любых баз данных SQL или хранилища ключей. У вас должен быть контроль над ключами, которые вы ввели. Если у вас нет этого элемента управления, то в течение определенного периода времени вы не знаете, какой ключ используется для этой цели. Для того, чтобы достичь того же, вы можете префикс некоторую содержательную строку во всех ключей вы положили в.

Например, если я хочу сохранить 3 HashMaps для одного пользователя user1 я буду делать, как этот

hmset ACTIONS_user1 a 10 b 20 ... 
hmset VIEWS_user1 home_page 4 login 10 ... 
hmset ALERTS_user1 daily 5 hourly 12 ... 

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

Таким образом, вы всегда будете иметь контроль над ключами, которые вы вставляете, и вы никогда не столкнетесь с столкновением.

Надеюсь, это поможет.

+0

Моей главной проблемой было переопределение/аннулирование данных, связанных с конкретным ключом. Я пошел с вашим предложением и выбрал второй подход. Сложность избежания столкновений должна быть обработана вне моего кода, о чем вы также говорили. – Waqas

+0

Два теоретических момента, не предназначенных для устранения ваших практических советов, но заявляющих о завершении (при отсутствии контроля над ключами): 1) теоретически говоря, вы можете закончить случай, когда разные приложения могут выдавать одинаковые команды HMSET, это может быть маловероятно, но не невозможно; 2) две разные клавиши могут оказаться в одном и том же ковше, что вызывает столкновение, но Redis делает это прозрачным для пользователя. – Waqas

Смежные вопросы