Redis вложение значения в ключ против json

Question

Я планирую сохранить доступность номеров в базе данных Redis. Объект json выглядит так:

{
  BuildingID: "RE0002439",
  RoomID: "UN0002384391290",
  SentTime: 1572616800,
  ReceivedTime: 1572616801,
  Status: "Occupied",
  EstimatedAvailableFrom: 1572620400000,
  Capacity: 20,
  Layout: "classroom"
}

Об этом будут сообщать как устройства, так и приложения (планшет вне комнаты, датчик в комнате в некоторых комнатах, пользователи и др. c). ) и сильно различаются, поскольку у нас есть сотни зданий и более 1000 комнат.

Я собираюсь использовать простую структуру значений ключей в Redis. Основной запрос - какая комната сейчас доступна, но возможны и другие.

Из-за этого я подумал, что ключ должен выглядеть следующим образом:

RoomID,Status,Capacity

Мой вопрос - верен ли он? предположение, потому что это основной запрос, мы ожидаем, что все это в ключе? Должны ли быть и другие поля в ключе или ключ должен быть просто числом с приращением Redis, как если бы это было SQL?

Есть много вопросов, которые я мог бы найти об иерархии, но мой объект не имеет иерархия действительно.

Answer 1

Если вы не будете использовать экземпляр redis исключительно для этого, использование ключей с сопоставлением с шаблоном для общих запросов не является хорошей идеей. KEYS - это O (N) и SCAN при вызове несколько раз для обхода всего пространства ключей.

Рассмотрим Модуль RediSearch , это даст вам много возможностей в этом случае использования.

Если RediSearch не является опцией:

Вы можете использовать один ключ ha sh для хранения всех комнат, но затем вам нужно сохранить всю строку json в качестве значения и всякий раз, когда вы хотите изменить поле, вам нужно получить, затем изменить, а затем установить.

Возможно, вам лучше использовать несколько структур данных, вот идея, с которой можно начать:

Храните каждую комнату как ключ га sh. Если RoomID уникален, вы можете использовать его в качестве ключа или соединить его с идентификатором здания, если это необходимо. Таким образом, вы можете редактировать значение поля за одну операцию.

HSET UN0002384391290 BuildingID RE0002439 Capacity 20 ...

Сохраните набор со всеми идентификаторами комнат. SADD AllRooms UN0002384391290

Используйте наборы и отсортированные наборы в качестве индексов для остальных:

Набор доступных номеров : используйте SADD AvailableRooms UN0002384391290 и SREM AvailableRooms UN0002384391290, чтобы отметить номера как доступно или нет. Таким образом, ваш общий запрос для всех доступных комнат выполняется так же быстро, как и получается. Вы можете использовать это вместо Status внутри данных комнаты. Используйте SISMEMBER, чтобы проверить, доступна ли данная комната.

Сортированный набор вместимостью : Используйте ZADD RoomsByCapacity 20 UN0002384391290. Так что теперь вы можете начать делать хорошие запросы, такие как ZRANGEBYSCORE RoomsByCapacity 15 +inf WITHSCORES, чтобы получить все комнаты с вместимостью> = 15. Затем вы можете пересечь доступные комнаты.

Устанавливается по макету : SADD RoomsByLayout:classroom UN0002384391290. Затем вы можете пересечь по макету, например SINTER AvailableRooms RoomsByLayout:classroom, чтобы получить все доступные классы.

Наборы по зданию : SADD RoomsByBuilding:RE0002439 UN0002384391290. Затем вы также можете пересекать здания, например, SINTER AvailableRooms RoomsByLayout:classroom RoomsByBuilding:RE0002439, чтобы получить все доступные классные комнаты в здании.

Вы можете смешивать наборы с отсортированными наборами, например, ZINTERSTORE Available:RE0002439:ByCap 3 RoomsByBuilding:RE0002439 RoomsByCapacity AvailableRooms AGGREGATE MAX, чтобы получить все доступные комнаты, оцененные по вместимости в здании RE0002439 , Сортированные наборы допускают только ZINTERSTORE и ZUNIONSTORE, поэтому вам необходимо выполнить очистку после выполнения ваших запросов.

Избегать отсортированных наборов можно, используя наборы с сегментами емкости, например Rooms:Capacity:1-5, Rooms:Capacity:6-10 и т. Д. c.

Подумайте о том, чтобы добавить координаты в свои здания, чтобы пользователи могли делать запросы по близости. См. GEOADD и GEORADIUS .

Возможно, вы захотите разрешить резервирование и запросы доступности в будущем. См. Перекрытие диапазона дат на Redis? .