|
Розробка додатків у Redis — це приємний процес, але, як і будь-яка технологія, є кілька речей, які потрібно враховувати при розробці застосунків на основі Redis. Можливо, ви вже знайомі з усією рутиною розробки реляційних баз даних, і розробка додатків на основі Redis має багато спільного, але слід пам'ятати про дві речі — Redis — це база даних у пам'яті, і вона однопотокова. Тому при використанні Redis слід звертати увагу на такі моменти: 1. Керування всіма ключами, збереженими в Redis Основна функція бази даних — зберігати дані, але зазвичай розробники ігнорують деякі дані, що зберігаються в базі даних, через зміни вимог до додатків або методів використання даних, і те саме стосується Redis. Ви можете пропустити деякі ключі, які закінчилися, або забути дані, бо модуль вашого додатку застарілий. У будь-якому випадку Redis зберігає деякі дані, які більше не використовуються, займаючи місце без жодної причини. Слабко структурований патерн даних Redis ускладнює визначення того, що зберігається централізовано, якщо не використовувати дуже зрілу номенклатуру ключів. Правильний метод іменування спростить управління вашою базою даних, і коли ви створюєте простір імен для ключів через свій додаток або сервіс (зазвичай використовуючи двокрапки для поділу імен ключів), ви легко ідентифікуєте дані під час міграції, конвертації або видалення. Ще один поширений випадок використання Redis — це друге сховище даних для гарячих даних, де більшість даних зберігається в інших базах даних, таких як PostgreSQL або MongoDB. У таких випадках розробники часто забувають видалити відповідні дані в Redis при видаленні даних з основного сховища. У такому випадку зазвичай потрібне каскадне видалення, у такому разі його можна зробити, зберігаючи всі ідентифікатори для конкретного елемента даних у конфігурації Redis, щоб після видалення даних у первинній базі даних викликався прибиральник для видалення всіх відповідних копій та інформації. 2. Контролювати довжину всіх ключових імен Як ми вже казали вище, ми використали відповідні системи іменування та додали префікси, щоб визначити, куди йдуть дані, тож це, здається, суперечить цьому. Однак не забувайте, що Redis — це база даних у пам'яті, і чим коротші клавіші, тим менше місця потрібно. Звісно, коли в базі даних є мільйони або мільярди ключів, довжина ім'я ключа має великий вплив. Наприклад, на 32-бітному сервері Redis, якщо ви зберігаєте мільйон ключів довжиною 32 символи, це займатиме близько 96MB простору при використанні ім'я ключа з 6 символів, але якщо використовувати 12-символьне ім'я, споживання місця зросте приблизно до 111MB. З більшою кількістю ключів додаткові 15% накладних витрат матимуть значний вплив. 3. Використовуйте правильну структуру даних Чи то використання пам'яті, чи продуктивність — іноді структури даних можуть мати великий вплив, ось деякі найкращі практики, на які варто звертатися: Замість того, щоб зберігати дані як тисячі (або мільйони) окремих рядків, розгляньте використання хешованих структур даних для групування пов'язаних даних. Хеш-таблиці дуже ефективні і можуть зменшити використання пам'яті; Водночас хешування також корисніше для абстракції деталей і читання коду. Коли доречно, використовуйте list замість 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
|
|
|
