Глава 2. Типы данных

Когда дело доходит до проектирования приложения и разработки с помощью Redis, тип данных является центральным понятием. В отличии от RDBMS (relational database management system, системы управления реляционной базой данных), нет никаких таблиц или схем, о которых вам следует беспокоиться в Redis. Когда дело доходит до того, как организовать ваши данные в Redis, единственная вещь, которую вам следует рассмотреть в первую очередь, это какой из поддерживаемых естественным образом типов данных в Redis подходит вашему варианту применения наилучшим образом. Более того, у вас нет возможности манипулировать вашими данными в Redis при помощи SQL, как в реляционной базе данных. Вместо этого вы вызываете команду напрямую для своих целевых данных при помощи соответствующего API в сопровождении необходимых данных. Таким образом, другой момент, о котором вам следует задумываться, это могут ли соответствовать вашим бизнес- требованиям эти операции с определёнными данными в Redis.

В данной главе мы рассмотрим все типы данных и важные операции, которые относятся к Redis. Чтобы наилучшим образом проиллюстрировать имеющиеся типы данных и операции с ними, Будет показан проект демонстрационного приложения, подобного Yelp (для данного демонстрационного примера в этой книге мы будем называть его Relp). Relp является неким приложением для пользовательских обзоров и рекомендаций топовых ресторанов, торговых центров и прочих служб. С помощью Relp вы можете просматривать различные рестораны в некотором городе, находить первый в топе десяток гимназий в пределах определённого расстояния, выставлять рейтинги и обзорные комментарии для локальных служб и тому подобное. Все те данные, которые мы намереваемся хранить в Redis и скоторыми собираемся работать, будут целиком применяться в Redis.

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

Вам требуется завершить установку вашего Сервера Redis, как это описывалось в рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis и подключиться к этому Серверу Redis при помощи redis-cli.

Для понимания того как применять строковый тип данных, выполните следующую последовательность:

Redis также предоставляет пару команд для прямой манипуляцией строками без применения GET для выборки необходимого значения и SET для обратного его назначения:

Возможно, GET и SET наиболее часто используемые команды в Redis. Формат команды SET очень простой:

SET <key> <value>
 	   

Если команда SET исполнена успешно, Redis возвращает OK. Команда APPEND добавляет некую строку в конец имеющейся строки и возвращает значение длины новой строки. Если указанный ключ не существует, Redis вначале создаст для этого ключа пустую строку и затем исполнит APPEND. Команда SETRANGE переписывает часть имеющейся строки, начиная со значения определяемого смещения и вплоть до окончания всей этой строки. Смещение строки в Redis начинается с 0. SETRANGE возвращает получаемое значение длины новой строки после осуществления определяемой в ней замены.

Если уже имеется некое связанное с заданным ключом значение, команда SET перепишет это значение. Порой мы не желаем чтобы установленное значение было перезаписано вслепую, раз уж этот ключ существует; одна из вещей, которую мы можем сделать для этого, это воспользоваться командой EXIST для проверки наличия данного ключа перед исполнением своего SET. Тем не менее, Redis предоставляет некую команду SETNX (сокращение от SET если данный ключ Not Exist), которая может быть применена для установки соответствующего значения ключа только в том случае, если он не определён, причём в атомарной операции. SETNX возвращает значение 1 если данный ключ был успешно установлен и 0 когда ключ уже имеется и поэтому старое значение не перезаписывается:

127.0.0.1:6379> SETNX "Lobster Palace" "437 Main St, Chicago, IL"
(integer) 1
127.0.0.1:6379> SETNX "Extreme Pizza" "100 Broadway, New York, NY"
(integer) 0
 	   

Параметр NX в команде SET делает то же самое что и SETNX. В то же время обратного параметра XX в команде SET, который заставлял бы команду SET устанавливать значение данного ключа только если оно уже имеется, не существует.

Мы можем выполнять установку и выборку множества ключей за раз применяя MSET и MGET. Основное преимущество операции MSET состоит в том, что эта операция целиком атомарная, что означает, что все значения ключей устанавливаются за один проход от клиента к серверу. Таким образом мы можем избегать излишних накладных расходов в сети применяя команду MSET вместо исполнения множества команд SET. Приведём формат команд MSET и MGET:

MSET key value [key value...]
MGET key value [key value...]

127.0.0.1:6379> MSET "Sakura Sushi" "123 Ellis St, Chicago, IL" "Green Curry
Thai" "456 American Way, Seattle, WA"
OK

127.0.0.1:6379> MGET "Sakura Sushi" "Green Curry Thai" "nonexistent"
1) "123 Ellis St, Chicago, IL"
2) "456 American Way, Seattle, WA"
3) (nil)
 	   

Будет полезно отметить каким образом строки кодируются внутри объектов Redis. Redis применяет три различных кодировки для сохранения объектов и будет принимать решение по определению кодирования автоматически в зависимости от значения строки:

Для знакомства с внутренним представлением кодировки значения объекта Redis, связанного с данным ключом, мы можем воспользоваться имеющейся командой OBJECT:

127.0.0.1:6379> SET myKey 12345
OK
127.0.0.1:6379> OBJECT ENCODING myKey
"int"
127.0.0.1:6379> SET myKey "a string"
OK
127.0.0.1:6379> OBJECT ENCODING myKey
"embstr"
127.0.0.1:6379> SET myKey "a long string whose length is more than 39 bytes"
OK
127.0.0.1:6379> OBJECT ENCODING myKey
"raw"
 	   

Тип данных списков является очень полезным типом при разработке приложений, так как некий перечень сохраняет последовательность объектов и запросто может применяться в качестве стека или очереди. В Redis конкретное значение, связанное с неким ключом, может выступать в качестве списка строк. Перечень в Redis больше походит на двусвязный список в конкретном мире структур данных. Данный рецепт демонстрирует все основные команды манипуляции списками в Redis.

Вам требуется завершить установку вашего Сервера Redis, как это описывалось в рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis и подключиться к этому Серверу Redis при помощи redis-cli.

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

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

LPUSH, RPUSH и LINSERT возвращают значение длины обрабатываемого списка после вставки. Нет необходимости инициализировать некий пустой перечень для какого- то ключа перед помещением элементов. Если мы помещаем элементы в заданный перечень для несуществующего ключа, Redis создаст вначале некий пустой список и свяжет его с данным значением ключа. Аналогично, нам нет нужды удалять ключи, у которых связанные с ними списки пустые, так как Redis выполняет очистку сам за нас.

Для удаления некоторого элемента из какого- то списка мы можем применять LPOP или RPOP, которые удаляют самый первый элемент с левого или с правого конца данного перечня и возвращает его значение. Исполнение LPOP или RPOP для non_existent ключа возвратит (nil):

127.0.0.1:6379> LPOP favorite_restaurants
"Olive Garden"
127.0.0.1:6379> RPOP favorite_restaurants
"Red Lobster"
127.0.0.1:6379> LPOP non_existent
(nil)
		

Для выборки элементов из некоторого перечня мы можем применять соответствующую команду LINDEX для получения одного элемента по заданному индексу, а также команду LRANGE для получения некоторого диапазона элементов.

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

 
127.0.0.1:6379> LRANGE favorite_restaurants 0 -1
1) "PF Chang's"
2) "Indian Tandoor"
3) "Outback Steakhouse"
127.0.0.1:6379> LTRIM favorite_restaurants 1 -1
OK
127.0.0.1:6379> LRANGE favorite_restaurants 0 -1
1) "Indian Tandoor"
2) "Outback Steakhouse"
		

Для установки определённого значения некоторого элемента в данном перечне с заданным индексом можно воспользоваться командой LSET:

 
127.0.0.1:6379> LSET favorite_restaurants 1 "Longhorn Steakhouse"
OK
127.0.0.1:6379> LRANGE favorite_restaurants 0 -1
1) "Indian Tandoor"
2) "Longhorn Steakhouse"
		

Существуют версии команд LPOP и RPOP с блокировкой: BLPOP и BRPOP. Обе эти команды выдадут некий элемент с левой или с правой стороны данного списка, так же как и команды без блокировки, однако, их клиент будет блокирован в случае пустого перечня. Для максимального значения времени ожидания в этих командах блокируемой выдачи необходимо устанавливать максимальное значение таймаута в секундах. Нулевое значение таймаута означает бесконечное ожидание. Это свойство полезно при сценариях диспетчеризации заданий, при которых множество исполнителей (Клиентов Redis, workers) ожидают конкретного планирования для назначения нового задания. Такие исполнители могут применять BLPOP и BRPOP в некоторм списке Redis. Всякий раз, когда имеется некое новое задание, имеющийся диспетчер пропихивает это задание в данный список, а один из исполнителей подхватывает его.

Давайте откроем ещё два Терминала, которые представляют собой двух Клиентов Redis: worker-1 и worker-2 и позволим им выполнить соединение с тем же самым Сервером Redis при помощи redis-cli. Позволим первоначальному Клиенту Redis выступать в роли диспетчера.

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

worker-1> BRPOP job_queue 0
worker-2> BRPOP job_queue 0
		

Из своего диспетчера вытолкните некий новый элемент в данный список:

dispatcher> LPUSH job_queue job1
(integer) 1
		

Так как worker-1 исполняет BRPOP до worker-2, worker-1 является не блокированным в начале и получает job1:

worker-1> BRPOP job_queue 0
1) "job_queue"
2) "job1"
(170.81s)
		

Так как worker-2 всё ещё блокирован, давайте вытолкнем ещё два элемента в свой список из нашего диспетчера:

dispatcher> LPUSH job_queue job2 job3
		

worker-2 не блокирован и получает job2, в то время как job3 остаётся в списке, ожидая того, что его кто- нибудь прихватит:

worker-2> BRPOP job_queue 0
1) "job_queue"
2) "job2"
(358.12s)

dispatcher> LRANGE job_queue 0 -1
1) "job3"
		

Redis для хранения объектов применяет внутреннее кодирование quicklist. Для настройки применения хранения в памяти перечня объектов применяются два параметра настройки:

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

Вам требуется завершить установку вашего Сервера Redis, как это описывалось в рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis и подключиться к этому Серверу Redis при помощи redis-cli.

Для понимания того, как использовать тип данных хэша, выполните следующую последовательность шагов:

Аналогично тому, как мы это уже упоминали в Применение типа данных списков, нам нет необходимости инициализировать некий пустой хэш перед добавлением полей. При помощи HSET и HMSET Redis будет делать это автоматически. Аналогично, Redis будет выполнять работу по очистке когда некий хэш становится пустым.

По умолчанию HSET и HMSET будут переписывать любые имеющиеся поля. Для предотвращения такого определяемого по умолчанию поведения перезаписи HSET можно применять команду HSET, которая устанавливает значение определяемого поля только если такое поле не существует:

127.0.0.1:6379> HSETNX "Kyoto Ramen" "phone" "555-555-0001"
(integer) 0
127.0.0.1:6379> HGET "Kyoto Ramen" "phone"
"555-123-6543"
 	   

Для всякого не существующего ключа или поля HSET и HMSET будут возвращать (nil):

127.0.0.1:6379> HMGET "Kyoto Ramen" "rating" "hours"
1) "4.9"
2) (nil)

127.0.0.1:6379> HGET "Little Sheep Mongolian" "address"
(nil)
 	   

Максимальное число полей, которое может быть помещено в хэш составляет 232-1. Если в некотором хэше имеется большее число полей, исполнение команды HGETALL. При таких обстоятельствах мы можем применять HSCAN для выборки приращениями вснх необходимых полей и значний.

HSCAN является одной из определяемых в Redis команд SCAN (SCAN, HSCAN, SSCAN, ZSCAN), которые инкрементально выполняют итерации по всем элементам и, следовательно, не блокируют имеющийся сервер. Такая команда является основанным на курсоре итераторе, поэтому вам требуется определять какой- то курсор при каждом вызове такой команды, причём начальным значением курсора является 0. После того, как данная команда завершена, Redis возвратит некий перечень элементов совместно с каким-то новым курсором, который можно применять для следующей итерации.

HSCAN может вызываться в следующих форматах:

Представим себе, что у нас имеется очень большой хэш в котором имеются миллионы, а может быть и ещё больше, полей. Давайте применим HSCAN для итераций по тем полям, которые содержат конкретное ключевое слово garden:

127.0.0.1:6379> HSCAN restaurant_ratings 0 MATCH *garden*
1) "309"
2) 1) "panda garden"
   2) "3.9"
   3) "chang's garden"
   4) "4.5"
   5) "rice garden"
   6) "4.8"
 	   

Для выполнения нового сканирования мы можем воспользоваться полученным от нашего сервера значением курсора 309 для начала нового сканирования:

127.0.0.1:6379> HSCAN restaurant_ratings 309 MATCH *garden*
1) "0"
2) 1) "szechuwan garden"
   2) "4.9"
   3) "garden wok restaurant"
   4) "4.7"
   5) "win garden"
   6) "4.0"
   7) "east garden restaurant"
   8) "4.6"
 	   

Отметим, что возвращаемое сервером новое значение курсора 0 означает, что выполнено полное сканирование.

Для внутреннего хранения объектов хэша Redis использует два вида кодировки:

Тип данных множества является собранием уникальных и неупорядоченных объектов. Они часто применяются в приложениях для проверки участия, удаления дублирований, а также операций установки соответствия (объединения, пересечения и вычитания). Значениями объектов Redis могут быть наборы строк. В данном рецепте мы будем сохранять в наборе Redis теги ресторанов и демонстрировать основные команды для манипуляции неким множеством.

Вам требуется завершить установку вашего Сервера Redis, как это описывалось в рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis и подключиться к этому Серверу Redis при помощи redis-cli.

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

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

Максимальное значение элементов, которое может быть помещено в некий набор Redis составляет 232-1.

Имеется команда с названием SMEMBERS, которая может применяться для перечисления всех элементов в некотором множестве, однако, аналогично тому, как мы уже упоминали в отношении HGETALL в разделе Применение типа данных хэшей, применение SMEMBERS в больших наборах может блокировать ваш сервер и, следовательно, не рекомендуется лоя применения. Для больших множеств вместо этого следует применять SSCAN. Исользование SSCANво многом аналогично применению команды HSCAN, которую мы представили в разделе Применение типа данных хэшей.

Redis предоставляет некую группу команд для объединения (SUNION, SUNIONSTORE), пересечения (SINTER, SINTERSTORE) и операции вычитания (SDIFF, SDIFFSTORE). Данные команды в отсутствии постфикса STORE просто возвращают получаемое в результате соответствующих операций множество, в то время как применение команды STORE сохраняет получаемый результат в некотором ключе назначения.

Вот некий пример использования SINTER и SINTERSTORE. Давайте добавим теги к другому ресторану, "Big Bear Wings", и получим общие теги для "Original Buffalo Wings" и "Big Bear Wings":

127.0.0.1:6379> SMEMBERS "Original Buffalo Wings"
1) "affordable"
2) "great taste"
127.0.0.1:6379> SADD "Big Bear Wings" "affordable" "spacious" "great music"
(integer) 3
127.0.0.1:6379> SINTER "Original Buffalo Wings" "Big Bear Wings"
1) "affordable"

127.0.0.1:6379> SINTERSTORE "common_tags" "Original Buffalo Wings" "Big Bear Wings"
(integer) 1
127.0.0.1:6379> SMEMBERS "common_tags"
1) "affordable"
 	   

Внутри себя Redis использует два метода кодировки для хранения множества объектов:

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

Вам требуется завершить установку вашего Сервера Redis, как это описывалось в рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis и подключиться к этому Серверу Redis при помощи redis-cli.

Для понимания того как применять тип данных сортированного множества выполните следующую последовательность шагов:

В команде ZADD при помощи опции NX мы можем только добавлять новые элементы для данного множества если они уже имеют в своёс составе некие элементы:

127.0.0.1:6379> ZADD ranking:restaurants NX 50 "Olive Garden"
(integer) 0

127.0.0.1:6379> ZREVRANGE ranking:restaurants 0 -1 WITHSCORES
 1) "Kung Pao House"
 2) "213"
 3) "Olive Garden"
 4) "100"
 5) "Longhorn Steakhouse"
 6) "88"
 7) "Red Lobster"
 8) "46"
 9) "Outback Steakhouse"
10) "34"
11) "PF Chang's"
12) "23"
		

Аналогично, другая имеющаяся опция, XX, позволяет вам обновлять определённое множество без добавления в него новых элементов. Заметьте, пожалуйста, что данные опции могут применяться только с версии Redis 3.0.2 и выше.

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

Для выполнения объединения из двух сортированных множеств и сохранения значения в некий ключ назначения применяется команда ZUNIONSTORE. Могут применяться различные веса. Краткий синтаксис команды ZUNIONSTORE может быть перечислен следующим образом:

ZUNIONSTORE destination numkeys key [key ...] [WEIGHTS weight [weight ...]] [AGGREGATE SUM|MIN|MAX]
		

Начальный и конечный индексы в команде ZREVRANGE следуют соглашениям индекса Redis, которые мы уже упоминали в своём рецепте Применение типа данных хэшей. Таким образом, 0 означает самый первый элемент, а 1 является последующим элементом, -1 означает самый последний элемент, а -2 второй с конца и так далее. Следовательно, топ перечня трёх ресторанов может быть выделен при помощи следующей команды:

127.0.0.1:6379> ZREVRANGE totalranking 0 2 WITHSCORES
1) "Kung Pao House"
2) "380"
3) "Olive Garden"
4) "200"
5) "Outback Steakhouse"
6) "144
		

Когда дело доходит до имеющегося комплекса Redis API, всегда следует уделять внимание значениям времени и сложности. В сортированном множестве вариантом применения являются API ZINTERSTORE и ZUNIONSTORE.

К вашему сведению, Redis также применяет внутри себя два метода кодирования для хранения объектов сортированных множеств, как и в типе данных перечня, который мы упоминали в рецепте Применение типа данных хэшей:

Подсчёт отдельных значений является общей задачей в различных сценариях ежедневной обработки данных. В Redis, в то время как чудесно, а иногда и просто необходимо реализовать отличный подсчёт с использованием множества, следует учитывать потребление памяти и снижение производительности в том случае, когда размер набора увеличивается до десятков миллионов. Если вам не нужно извлекать содержимое набора данных, а просто нужно уникальное значение подсчёта, единственная вещь, которую вы можете сделать, это для оптимизации проблем с памятью и производительностью, вызванных таким набором, применять в Redis тип данных HyperLogLog (HLL). В данном рецепте мы расскажем, как использовать HLL в Redis.

Вам требуется завершить установку вашего Сервера Redis, как это описывалось в рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis и подключиться к этому Серверу Redis при помощи redis-cli.

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

Другой более сложный пример, когда вы желаете показать значение числа уникальных посетителей для Olive Garden в неделю через Relp как некий индикатор еженедельной популярности; вы можете сохранять по одному HLL в день и сливать их в семь дней при помощи команды PFMERGE для генерации требуемого результата:

127.0.0.1:6379> PFADD "Counting:Olive Garden:20170903" "0023992" "0023991" "0045992"
(integer) 1
127.0.0.1:6379> PFADD "Counting:Olive Garden:20170904" "0023992" "0023991" "0045992"
(integer) 1
127.0.0.1:6379> PFADD "Counting:Olive Garden:20170905" "0024492" "0023211" "0045292"
(integer) 1
127.0.0.1:6379> PFADD "Counting:Olive Garden:20170906" "0023999" "0063991" "0045922"
(integer) 1
127.0.0.1:6379> PFADD "Counting:Olive Garden:20170907" "0023292" "0023991" "0045921"
(integer) 1
127.0.0.1:6379> PFADD "Counting:Olive Garden:20170908" "0043282" "0023984" "0045092"
(integer) 1
127.0.0.1:6379> PFADD "Counting:Olive Garden:20170909" "0023992" "0023991" "0045992"
(integer) 1

127.0.0.1:6379> PFMERGE "Counting:Olive Garden:20170903week" "Counting:Olive Garden:20170903" "Counting:Olive Garden:20170904" "Counting:Olive Garden:20170905" "Counting:Olive Garden:20170906" "Counting:Olive Garden:20170907" "Counting:Olive Garden:20170908" "Counting:Olive Garden:20170909"
OK
127.0.0.1:6379> PFCOUNT "Counting:Olive Garden:20170903week"
(integer) 14
 	   

Все команды в Redis HLL начинаются с символов PF, в честь Philippe Flajolet, который был изобретателем структуры данных HLL. В данной книге мы не будем погружаться в подробности алгоритмов HLL. Основным преимуществом HLL в Redis является то, что он вычисляет различные количества применяя некий фиксированный объём памяти (менее чем 12кБ на ключ для кардинальных чисел 264) и постоянную сложность по времени (O(1) на ключ). Тем не менее, имеется некий компромисс относительно алгоритмов HLL, состоящий в том, что возвращаемое значение кардинального числа {мощности} не является точным со стандартной ошибкой, не превышающей 1%.

HLL на практике хранится в виде строк и он является простым для удержания и восстановления пар ключ- значение.

К вашему сведению: HLL в Redis применяет два внутренних представления хранения объектов HLL:

Всё большую популярность приобретают службы на основе местоположения по мере того, как смартфоны становятся всё более распространёнными. Для поддержки хранения и запросов географических координат в таких связанных с местоположением сценариях, начиная с выпуска 3.2 в Redis официально был предложен API Geo. В данном рецепте мы исследуем тип данных Geo в Redis.

Вам требуется завершить установку вашего Сервера Redis, как это описывалось в рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis и подключиться к этому Серверу Redis при помощи redis-cli.

Чтобы разобраться с тем как применять тип данных Geo выполните следующую последовательность действий:

При определении координат с помощью GEOADD они внутренне преобразуются в некий 52- битный GEOHASH, который является некоторой общеупотребимой системой кодирования в Geo. Вам следует принимать во внимание, что существует небольшое отличие между тем как хранит данные Geo и теми координатами, которые возвращаются GEOPOS, поэтому вы не должны ожидать, что эти два значения будут в точности одними и теми же.

В соответствующих командах GEORADIUS и GEORADIUSBYMEMBER вы можете применять параметр WITHDIST для получения значения расстояния. Следующий параметр ASC/DESC заставляет возвращаемые результаты выдаваться в порядке возрастания/ убывания. Кроме того, при помощи имеющегося параметра STORE/STOREDIST вы можете также сохранять результаты посредством GEORADIUS и GEORADIUSBYMEMBER в другом наборе Geo в Redis.

Рассматриваемый нами набо Geo на самом деле хранится как сортированное множество (в Redis zset) и все имеющиеся для сортированного множества команды применимы и для самого типа данных Geo. К примеру, чтобы удалить некий индекс из какого- то набора Geo может быть выполнено при помощи ZREM, а выборки всех имеющихся участников в наборе Geo можно осуществить через ZRANGE.

К вашему сведению, имеющаяся реализация GEOHASH основана на 52- битном целочисленном представлении, (что даёт точность менее одного метра). Когда вам требуется некая стандартная строка GEOHASH, вы можете вызвать GEOHASH для получения некоторого строкового значения с длиной 11.

С точки зрения производительности, GEORADIUS имеет временную сложность алгоритма O(N+log(M)), где N является общим числом элементов ограниченного блока заданной круговой области, ограничиваемой центром и радиусом в соответствии с документацией Redis. Поэтому, если вы нуждаетесь в максимальной производительности, вам следует иметь ввиду, что значение параметра радиуса в одном запросе следует устанавливать настолько малым, насколько это возможно для охвата как можно меньшего числа пунктов.

До сих пор в данной главе мы обсуждали все имеющиеся в Redis типы данных. Говоря в целом, данные в Redis составляются из пар ключ- значение. Таким образом, управление ключами является другим существенным знанием при разработке приложений и администрировании в Redis. В данном рецепте мы обсудим управление ключами.

Вам требуется завершить установку вашего Сервера Redis, как это описывалось в рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis и подключиться к этому Серверу Redis при помощи redis-cli.

Чтобы ясно ознакомить вас с работой с ключами, мы для начала наполним Redis некими поддельными данными с использованием fake2db, применив следующие шаги:

Для того чтобы разобраться с управлением ключами выполните следующую последовательность шагов:

Управление ключами в Redis достаточно простое. Тем не менее, некоторые API могут стать настоящими убийцами производительности.

Для начала, вы можете столкнуться с тем, что если у вас в Redis имеется достаточно большое число ключей, вызов KEYS вызовет блокировку вашего Сервера Redis не то время, пока не будут возвращены все ключи (в нашем примере это заняло 6.8). Если вы уяснили такое основное концептуальное понимание в рецепте Общее представление о модели событий Redis Главы 1, Приступая к Redis, вы знаете, что в процессы исполнения в Redis одной команды, все прочие уже принятые команды ожидают своего исполнения. Таким образом, вызов команды KEYS является рискованным действием в отношении производительности при промышленном применении. Для решения данной проблемы мы рекомендуем применять, как уже упоминалось в предыдущих рецептах, соответствующие команды SCAN, такие как HSCAN или SSCAN, которые могут применяться для итераций значений ключей в вашем Сервере Redis без блокирования данного сервера.

Команда DEL также требует подобной дополнительной предосторожности. Если значение подлежащего удалению ключа является тип данных, отличный от строкового, вы можете столкнуться с латентностью сервера когда общее число элементов в этом ключе велико. Чтобы предотвратить это, хорошей идеей будет воспользоваться UNLINK. Он будет выполнять удаление в другом потоке, отличном от самого потока основного цикла, следовательно, такой процесс не будет блокировать вашу обработку событий.

Помимо всего прочего, на первый взгляд RENAME выглядит безобидно. Тем не менее, RENAME удалит имеющийся целевой ключ, если он уже имеется. Как уже упомянуто выше, DEL может вызывать большую задержку. Таким образом, лучшим практическим приёмом является отсоединение (unlink) целевого ключа в случае, когда он имеется, с последующим переименованием.

Для упорядочения и параллельной обработки (serialization и deserialization) могут применяться команды DUMP/ RESTORE. Вы можете применять эти две команды для создания частичных резервных копий Redis.