Удалить из отсортированного набора Redis на основе свойства JSON

У меня есть большое количество элементов, хранящихся в отсортированном наборе Redis (порядка 100 000), которые довольно часто обновляются. Эти элементы являются объектами, закодированными как строки JSON, и ранг для сортировки в наборе получается (при вставке, согласно моему коду) из свойства даты/времени объекта.

Каждый элемент в наборе имеет свойство Id (которое представляет собой Guid, закодированный в виде строки), которое однозначно идентифицирует элемент в системе.

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

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

У кого-нибудь есть какие-либо предложения относительно того, как сделать это более эффективным образом? Единственный уникальный идентификатор, который у меня есть для элементов, — это свойство Id, закодированное в элементе.

Огромное спасибо,

Ричард.


json redis sortedset
person Richard Comish    schedule 27.08.2015    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Возможно, ваш случай - просто неудачный выбор дизайна.

Не следует хранить строки JSON в отсортированных наборах: вам нужно хранить идентификаторы, а все сериализованные объекты JSON должны храниться в хэше.

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

С другой стороны, любой ключ в хэше должен присутствовать в вашем отсортированном наборе. Когда вы добавляете объект в отсортированный набор, вы добавляете его уникальный идентификатор.

Когда вам нужно перечислить свои объекты в определенном порядке, вы выполняете следующие операции:

  1. Вы получаете страницу идентификаторов из отсортированного набора (например, используя zrange).
  2. Вы получаете все объекты со страницы, передавая их идентификаторы команде hmget.
person Matías Fidemraizer    schedule 27.08.2015
comment
Использование хэша для хранения данных ID->JSON рекомендуется, но не обязательно, поскольку вы можете использовать строку для хранения JSON каждого идентификатора под своим собственным ключом. Тем не менее, хэш предпочтительнее с точки зрения оперативной памяти из-за накладных расходов Redis на ключ. - person Itamar Haber; 27.08.2015
comment
@ItamarHaber Привет, как дела? ;) Да, я использовал подход со строковыми ключами, пока не понял, что hases лучше не только из-за оптимизации памяти, но и потому, что кому нужно глобальное пространство ключей, забитое миллионами ключей, когда вы можете организовать их в подразделы - person Matías Fidemraizer; 27.08.2015
comment
Hola:) Как товарищ-подражатель OCD, я понимаю это, но по всем практическим причинам (исключая оптимизацию ОЗУ) подключи не очень полезны, если вы не сканируете пространство ключей - плохая идея в большинстве случаев - или выполняете пакетные операции над подразделы (например, массовое удаление). OTOH, они добавляют еще один O (logn) для получения значения... - person Itamar Haber; 27.08.2015
comment
@ItamarHaber Ну, вы правы ... Это мой случай, когда я использую хэши для хранения сериализованных объектов по некоторому ключевому свойству, а затем мне нужно получить их по некоторым критериям. Вот почему я склонен использовать набор с сортировкой по хешу (или просто набор, список или что-то еще). - person Matías Fidemraizer; 27.08.2015
comment
Вы абсолютно правы в том, что это был плохой выбор дизайна — я пришел из мира SQL, и это было первое, что я написал с помощью Redis. Я бы не стал делать это снова, и я думаю, что пришло время переделать так, как предлагает @MatíasFidemraizer. - person Richard Comish; 27.08.2015
comment
@RichardComish Что ж, вы увидите, что как только вы привыкнете работать с простыми структурами данных, SQL будет казаться вам беспорядком; P - person Matías Fidemraizer; 27.08.2015
comment
@MatíasFidemraizer Я очень подозреваю, что ты прав! - person Richard Comish; 27.08.2015