|
Разработка приложений с помощью Redis — приятный процесс, но, как и в любой технологии, есть несколько моментов, которые нужно учитывать при проектировании приложений на базе Redis. Возможно, вы уже знакомы со всей рутиной реляционной разработки баз данных, и разработка приложений на основе Redis имеет много сходства, но нужно помнить о следующих двух вещах — Redis — это база данных в памяти и она работает с одной потоковой точкой. Поэтому, используя Redis, нужно обращать внимание на следующие моменты: 1. Управление всеми ключами, хранящимися в Redis Основная функция базы данных — хранение данных, но обычно разработчики игнорируют некоторые данные, хранящиеся в базе данных, из-за изменений требований приложений или методов использования данных, и то же самое верно и в Redis. Вы можете упустить некоторые ключи, которые истекают, или забыть данные, потому что модуль вашего приложения устарел. В любом случае Redis хранит данные, которые больше не используются, занимая место без причины. Слабо структурированный шаблон данных Redis затрудняет определение того, что хранится централизованно, если только вы не используете очень зрелую номенклатуру для ключей. Правильный метод именования упростит управление вашей базой данных, и когда вы создаёте пространство имён для ключей через приложение или сервис (обычно с помощью двоеточия для разделения имён), вы сможете легко определить данные при миграции, конвертации или удалении. Другой распространённый случай использования Redis — это второе хранилище данных для горячих данных, где большая часть данных хранится в других базах данных, таких как PostgreSQL или MongoDB. В таких случаях разработчики часто забывают удалить соответствующие данные в Redis при удалении данных из основного хранилища. В этом случае обычно требуется каскадное удаление, в котором его можно достичь сохранения всех идентификаторов для конкретного элемента данных в конфигурации Redis, чтобы после удаления данных в первичной базе данных вызывается уборщик для удаления всех соответствующих копий и информации. 2. Контролировать длину всех имён клавиш Как мы уже говорили выше, мы использовали соответствующие системы именования и добавили префиксы для определения направления данных, так что это, похоже, противоречит этому. Однако не забывайте, что Redis — это база данных в памяти, и чем короче клавиши, тем меньше места нужно. Естественно, когда в базе данных миллионы или миллиарды ключей, длина имени ключа оказывает большое влияние. Например, на 32-битном сервере Redis, если вы храните миллион ключей длиной 32 символа, использование 6-символьного ключа займёт около 96 МБ места, но при использовании 12-символьного ключа расход пространства увеличится примерно до 111 МБ. С большим количеством клавиш дополнительные 15% накладных расходов окажут значительное влияние. 3. Используйте правильную структуру данных Будь то использование памяти или производительность, иногда структуры данных могут оказывать большое влияние, вот некоторые лучшие практики, на которые стоит обратиться: Вместо того чтобы хранить данные в виде тысяч (или миллионов) отдельных строк, рассмотрите возможность использования хешированных структур данных для группировки связанных данных. Хэш-таблицы очень эффективны и могут снизить использование памяти; В то же время хеширование также более полезно для абстракции деталей и читаемости кода. Когда уместно, используйте список вместо set. Если функция set не нужна, List может обеспечивать более высокие скорости, используя меньше памяти. Отсортированные множества — самые дорогие структуры данных как по потреблению памяти, так и по сложности базовых операций. Если вам просто нужен способ запрашивания записей и вы не хотите сортировать такие свойства, настоятельно рекомендуется использовать хэш-таблицы. Часто упускаемая из виду функция в Redis — это битмапы или битсеты (после V2.2). Битсеты позволяют выполнять несколько операций на уровнях битов над значениями Redis, например, некоторый лёгкий анализ. 4. Не используйте клавишу при использовании SCAN Начиная с версии Redis v2.8, команда SCAN уже доступна, позволяющая извлекать ключи из пространства ключей с помощью курсора. По сравнению с командой KEYS, хотя SCAN не может вернуть все совпадающие результаты одновременно, она избегает высокого риска блокировки системы, что позволяет выполнять некоторые операции на главном узле. Важно отметить, что команда SCAN — это итератор на основе курсора. Каждый раз при вызове команды SCAN пользователю возвращается новый курсор, и пользователю нужно использовать этот курсор в качестве параметра команды SCAN в следующей итерации, чтобы продолжить предыдущий процесс итерации. В то же время с помощью SCAN пользователи могут настраивать команды с помощью режима ключевых имён и параметров подсчёта. Команды, связанные с SCAN, также включают команды SSCAN, команды HSCAN и команды ZSCAN, которые используются соответственно для коллекций, хеш-ключей и продолжений. 5. Используйте серверные скрипты Lua В процессе использования Redis поддержка скриптов Lua, несомненно, предоставляет разработчикам очень дружелюбную среду для разработки, что значительно освобождает творческий потенциал пользователей. При правильном использовании скрипты Lua могут значительно повысить производительность и потребление ресурсов. Вместо передачи данных процессору скрипты позволяют выполнять логику, ближайшую к данным, снижая сетевую задержку и избыточную передачу данных. В Redis очень классическим примером использования Lua является фильтрация данных или агрегирование данных в приложении. Инкапсулируя рабочий процесс в скрипт, вы можете просто вызвать его, чтобы получить меньший ответ, используя мало ресурсов за меньшее время. Совет:Lua отличная, но у неё есть некоторые проблемы, например, сложности с отчетом и обработкой ошибок. Разумный подход — использовать функцию Pub/Sub от Redis и позволить скрипту отправлять сообщения логов по выделенному каналу. Затем создайте процесс подписчика и обработайте его соответственно.
| 
Опубликовано 29.12.2015 12:22:28
|
|
|
