Redis як основна база даних для складних застосунків - javascript.org.ua

Чому інструменти з низьким кодом та за допомогою ШІ не замінять справжнє програмування найближчим часом
Привіт усім! Минуло кілька тижнів з мого останнього посту, і за цей час я експериментував з різними інструментами ШІ та з низьким кодом, такими як GitHub Copilot, Cursor та Bolt. Ці платформи обіцяють прискорити розробку, пропонуючи фрагменти коду, автоматизуючи повторювані завдання або навіть створюючи цілі функції з мінімальними зусиллями програмування. Але чи справді це означає кінець традиційної розробки програмного забезпечення? Давайте розглянемо.

Зростання кодування за допомогою ШІ
Ви, напевно, чули про такі інструменти, як GitHub Copilot. За моїм досвідом, Copilot може бути рятівником, коли я застряг на чомусь простому або мені потрібно швидко згадати синтаксис. Це як мати маленького «колегу по програмуванню», який вказує на скорочення або пропонує рішення. Те ж саме стосується Cursor, Bolt та інших інструментів, заснованих на ШІ, які намагаються взяти на себе повторювану роботу, щоб ви могли зосередитися на складніших завданнях.

Незважаючи на ці переваги, важливо пам’ятати, що ці інструменти — це помічники, а не замінники. Вони залежать від контексту, який ви надаєте, і можуть помилятися. Якщо ви ще не розумієте, що ваш код має досягнути, пропозиції ШІ можуть завести вас у неправильний бік або згенерувати баги, які важко налагодити.

Платформи з низьким кодом: швидше не завжди означає краще
Платформи з низьким кодом (або навіть без коду) є ще однією великою тенденцією. Вони чудові для швидкого створення прототипів і дозволяють непрофесійним розробникам будувати прості додатки. У великих компаніях інструменти з низьким кодом можуть прискорити розробку внутрішніх рішень, де не потрібна повноцінна інженерія.

Однак покладатися на низький код для кожного проекту може обмежити вашу гнучкість. Складні додатки часто вимагають спеціальної логіки, ретельної архітектури та докладних розрахунків продуктивності — сфери, в яких платформи з низьким кодом можуть не дати очікуваного результату. Якщо ви не розумієте основних концепцій, ви можете отримати продукт, який важко підтримувати чи масштабувати.

Програмне забезпечення ніколи не завершується
Одна річ, яка стала для мене очевидною, це те, що програмне забезпечення постійно еволюціонує. Навіть після того, як додаток виходить у реліз, триває його підтримка, виправлення помилок, додавання нових функцій, зміни дизайну та коригування вимог користувачів. Інструменти, підтримувані ШІ, можуть допомогти з деякими з цих завдань, але вони не зможуть усунути потребу в розробниках, які дійсно розуміють внутрішню структуру системи.

Великі технологічні компанії вже адаптуються до швидких змін, спричинених ШІ, але ця адаптація все одно вимагає людської творчості, вирішення проблем і міцного розуміння основ програмного забезпечення.

Примітка для нових розробників
Якщо ви тільки починаєте, то спокуса використовувати платформи з низьким кодом чи інструменти ШІ для швидкого прогресу зрозуміла. Хоча ці ресурси можуть допомогти вам навчатися, вони не повинні заміняти основні навички розробки. Розумійте, чому ваш код працює, а не тільки те, що потрібно набрати. Зосередьтеся на:

Основних алгоритмах та структурах даних
Як різні частини веб-додатку взаємодіють
Практиках чистого коду
Стратегіях налагодження та тестування

Ці базові знання допоможуть вам помітити, коли пропозиції ШІ не зовсім правильні або коли рішення з низьким кодом не є оптимальними.

Прийміть інструменти, але залишайтеся на землі
Майбутнє розробки програмного забезпечення, ймовірно, включатиме більше функцій з підтримкою ШІ та рішень з низьким кодом. Але це не означає, що ми перестанемо потребувати справжніх розробників із сильними навичками кодування. Замість цього розглядайте ці платформи як каталізатори інновацій. Вони можуть допомогти вам швидше створювати прототипи, автоматизувати нудні завдання або запропонувати підхід, який ви могли б не врахувати, але ви залишаєтеся в контролі.

Заключні думки
Мені цікаво побачити, як еволюціонують платформи з підтримкою ШІ та низьким кодом. Вони потужні, але вони далеко не замінять справжнє мистецтво програмування.
So your application also needs to talk to a single data store, which means only one programmatic interface for that data service.
2. Знижена затримка: Затримка зменшується, оскільки ви звертаєтесь до єдиного кінцевого точки даних і усуваєте кілька внутрішніх мережевих стрибків.
3. Кілька типів даних в одному: Маючи одну базу даних, як Redis, яка дозволяє зберігати різні типи даних (тобто кілька типів баз даних в одній) і працювати як кеш, вирішуються подібні проблеми.

Як Redis підтримує кілька форматів даних

Тепер давайте подивимося, як насправді працює Redis. Перш за все, як Redis підтримує кілька форматів даних в одній базі даних?

Зображення 2: Типи даних, які приймає Redis

Основи Redis та модулі

Принцип роботи такий: у вас є основна частина Redis, яка є сховищем типів "ключ-значення" і вже підтримує зберігання кількох типів даних (Зображення 2). Потім ви можете розширити цю основу за допомогою так званих модулів для різних типів даних, необхідних вашому додатку для різних цілей. Наприклад:

RedisSearch для функціональності пошуку (як Elasticsearch)
RedisGraph для зберігання графових даних

Чудова річ в цьому те, що це модульно. Ці різні функціональності бази даних не інтегровані тісно в одну базу даних, як у багатьох інших мультимодальних базах даних, а ви можете вибирати і підключати точно ті функціональності, які вам потрібні для вашого додатку, і потім просто додавати потрібний модуль.

Вбудований кеш

І, звичайно, використовуючи Redis як основну базу даних, вам не потрібен додатковий кеш, тому що ви отримуєте це автоматично з Redis. Це означає менше складнощів у вашому додатку, оскільки вам не потрібно реалізовувати логіку для керування, заповнення та інвалідізації кешу.

Висока продуктивність та швидше тестування

Нарешті, як база даних, що зберігається в пам’яті, Redis дуже швидкий та продуктивний, що, звісно, робить сам додаток швидшим. Але, крім того, він також дозволяє проводити тести додатка значно швидше, оскільки Redis не потребує схеми, як інші бази даних. Отже, не потрібно витрачати час на ініціалізацію бази даних, створення схеми тощо перед запуском тестів. Ви можете почати з порожньої бази даних Redis кожного разу і генерувати дані для тестів, коли це потрібно. Швидкі тести справді можуть підвищити вашу продуктивність у розробці.

Персистентність даних в Redis

Добре, чудово. Тепер ми зрозуміли, як працює Redis і всі його переваги. Але на цьому етапі ви, мабуть, задаєтесь питанням: Як база даних в пам’яті може зберігати дані? Тому що якщо процес Redis або сервер, на якому працює Redis, збійне, всі дані в пам'яті зникнуть, правильно? І якщо я втрачаю дані, як я можу їх відновити? Тобто, як я можу бути впевнений, що мої дані в безпеці?

Найпростіший спосіб мати резервні копії даних — це за допомогою реплікації Redis. Якщо основна інстанція Redis збійне, репліки все ще будуть працювати і матимуть всі дані. Якщо у вас є реплікований Redis, репліки матимуть дані. Але, звісно, якщо всі інстанції Redis зупиняться, ви втратите дані, оскільки не буде жодної залишкової репліки.

Тому нам потрібна реальна персистентність.

Снімки (RDB)

Redis має кілька механізмів для персистенції даних і їх безпеки. Перший з них — це снімки, які ви можете налаштувати залежно від часу, кількості запитів тощо. Снімки ваших даних зберігаються на диску, і ви можете використовувати їх для відновлення даних, якщо вся база даних Redis зникне. Але зверніть увагу, що ви втратите останні кілька хвилин даних, оскільки зазвичай ви робите снімки кожні п’ять хвилин або годину, залежно від ваших потреб.

AOF (Append Only File)

Як альтернатива Redis використовує так званий AOF, що означає Append Only File.
У цьому випадку кожна зміна зберігається на диск для забезпечення персистентності безперервно. І коли Redis перезапускається або після збою, Redis відтворить логи Append Only File для відновлення стану. Отже, AOF є більш стійким, але може бути повільнішим за знімки.

Комбінація знімків та AOF

І, звісно, ви також можете використовувати комбінацію як AOF, так і знімків, де файл лише додавання постійно зберігає дані з пам’яті на диск, а також ви маєте регулярні знімки для збереження стану даних на випадок, якщо їх потрібно відновити. Це означає, що навіть якщо сама база даних Redis або сервери, на яких працює Redis, всі зазнають збою, ви все одно зберігаєте всі свої дані, і можете легко відновити нову базу даних Redis з усіма даними.

Де знаходиться це постійне сховище?

Тепер цікаве питання: де знаходиться це постійне сховище? Тобто, де знаходиться диск, який зберігає ваші знімки та логи лише додавання файлів? Чи вони знаходяться на тих самих серверах, де працює Redis?

Це питання фактично призводить нас до тенденції або найкращої практики для збереження даних у хмарних середовищах, а саме, що завжди краще розділяти сервери, на яких працюють ваші додатки та сервіси даних, з постійним сховищем, яке зберігає ваші дані.

З конкретним прикладом: якщо ваші додатки та сервіси працюють у хмарі, скажімо, на EC2 інстанції AWS, ви повинні використовувати EBS або Elastic Block Storage для збереження даних, замість того, щоб зберігати їх на жорсткому диску EC2 інстанції. Оскільки якщо ця інстанція EC2 зламається, ви не матимете доступу до жодного її сховища, будь то RAM, диск чи інші. Отже, якщо ви хочете зберегти персистентність та стійкість своїх даних, ви повинні зберігати їх поза інстанціями на зовнішньому мережевому сховищі.

Як результат, розділяючи ці два елементи, якщо інстанція сервера збійне або якщо всі інстанції збійнуть, у вас все одно буде диск з усіма даними, що залишились недоторканими. Ви просто запустите інші інстанції та візьмете дані з EBS, і все. Це робить вашу інфраструктуру набагато легшою для управління, оскільки кожен сервер є рівним; у вас немає спеціальних серверів з певними даними чи файлами на них. Тому вам не важливо, якщо ви втратите всю інфраструктуру, оскільки ви можете просто створити нову і забрати дані з окремого сховища, і ви знову готові до роботи.

Повертаючись до прикладу з Redis: сервіс Redis буде працювати на серверах і використовувати серверну RAM для зберігання даних, в той час як логи файлів лише додавання і знімки будуть збережені на диску поза цими серверами, що робить ваші дані більш стійкими.

Оптимізація витрат за допомогою Redis на Flash

Тепер ми знаємо, що можна зберігати дані з Redis для забезпечення стійкості та відновлення, використовуючи RAM або пам’ять для чудової продуктивності та швидкості. Тому питання, яке у вас може виникнути, це: Чи не є зберігання даних у пам’яті дорогим? Оскільки для цього вам знадобиться більше серверів порівняно з базою даних, яка зберігає дані на диску, просто тому, що пам’ять обмежена за розміром. Отже, тут є компроміс між витратами та продуктивністю.

На щастя, Redis має спосіб оптимізувати це, використовуючи сервіс під назвою Redis на Flash, який є частиною Redis Enterprise.

Як працює Redis на Flash?

Це досить проста концепція: Redis на Flash розширює RAM на флеш-диск або SSD, де часто використовувані значення зберігаються в RAM, а рідше використовувані — на SSD. Тому для Redis це просто більше RAM на сервері. І це означає, що Redis може використовувати більше ресурсів сервера або підлеглої інфраструктури, поєднуючи RAM та SSD для зберігання даних, збільшуючи ємність зберігання на кожному сервері і таким чином економлячи витрати на інфраструктуру.

Масштабування Redis: Реплікація та Шардинг

Ми поговорили про зберігання даних для бази даних Redis і як це все працює, включаючи найкращі практики.
Тепер давайте розглянемо ще одну дуже цікаву тему: як масштабувати Redis базу даних?

Реплікація та висока доступність

Припустимо, моя одна інстанція Redis вийшла з меж пам'яті, тому дані стають занадто великими для зберігання в пам'яті, або Redis стає вузьким місцем і не може обробляти більше запитів. В такому випадку, як я можу збільшити ємність і розмір пам'яті для моєї Redis бази даних?

Ми маємо кілька варіантів для цього. По-перше, Redis підтримує кластери, що означає, що можна мати головну (primary) або майстерну (master) інстанцію Redis, яка буде використовуватися для запису та читання даних, а також кілька реплік цієї головної інстанції для читання даних. Таким чином, можна масштабувати Redis для обробки більшої кількості запитів і одночасно збільшити високу доступність вашої бази даних. Якщо головна інстанція вийде з ладу, одна з реплік може її замінити, і ваша Redis база даних продовжить працювати без будь-яких проблем.

Тепер ці репліки будуть зберігати копії даних головної інстанції. Тому чим більше реплік, тим більше пам'яті потрібно. І один сервер може не мати достатньо пам'яті для всіх ваших реплік. Крім того, якщо всі репліки знаходяться на одному сервері і цей сервер вийде з ладу, вся ваша Redis база даних перестане працювати, і у вас буде час простою. Замість цього, ви хочете розподілити ці репліки серед кількох вузлів чи серверів. Наприклад, ваша головна інстанція буде на одному вузлі, а дві репліки — на інших двох вузлах.

8.2 Шардинг для більших наборів даних

Це виглядає досить добре, але що, якщо набір ваших даних стає занадто великим, щоб вміститися в пам'яті на одному сервері? Крім того, ми масштабували читання в базі даних для всіх запитів, які просто запитують дані, але наша головна інстанція все одно залишається одна і все ще повинна обробляти всі записи. Як вирішити це питання?

Для цього використовується концепція шардингу (Sharding), яку підтримує і Redis. Шардинг — це загальна концепція в базах даних, яка означає, що ви берете весь набір даних і ділите його на менші частини або піднабори даних, де кожен шард відповідає за свій піднабір даних. Тобто замість того, щоб мати одну головну інстанцію, яка обробляє всі записи для всього набору даних, ви можете розділити його, скажімо, на чотири шарди, кожен з яких відповідає за читання та запис для піднабору даних. І кожен шард також потребує менше пам'яті, оскільки він зберігає лише чверть даних. Це означає, що ви можете розподілити та запустити шарди на менших вузлах і таким чином горизонтально масштабувати ваш кластер. І, звісно, коли ваш набір даних росте, і вам потрібно ще більше ресурсів, ви можете перерозподілити дані Redis, що означає, що ви просто розділяєте свої дані на ще менші частини та створюєте більше шард.

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

Глобальна реплікація з Redis: Активно-активне розгортання

Тепер давайте розглянемо ще один цікавий сценарій для додатків, яким потрібна ще вища доступність і продуктивність на кількох географічних локаціях.
Припустимо, у нас є цей реплікований, шардований кластер Redis в одному регіоні, в дата-центрі Лондона, Європа. Але в нас є два наступні варіанти використання:

Наші користувачі географічно розподілені, тому вони отримують доступ до додатку з усього світу. Ми хочемо розподілити наш додаток та сервіси даних глобально, ближче до користувачів, щоб покращити продуктивність для них.
Якщо весь дата-центр у Лондоні, Європа, наприклад, виходить з ладу, ми хочемо, щоб відбулося негайне переключення на інший дата-центр, щоб сервіс Redis залишався доступним. Іншими словами, ми хочемо, щоб репліки всього кластера Redis знаходилися в дата-центрах в різних географічних локаціях або регіонах.

Кластери Redis в різних регіонах

Це означає, що один набір даних повинен бути реплікований до багатьох кластерів, розподілених по різних регіонах, причому кожен кластер має повну можливість приймати читання та запис. Тому в такому випадку ви будете мати кілька кластерів Redis, які діятимуть як локальні інстанції Redis в кожному регіоні, а дані будуть синхронізовані між цими географічно розподіленими кластерами. Це функціональність, яка доступна в Redis Enterprise, і називається активно-активне розгортання (active-active deployment), оскільки у вас є кілька активних баз даних в різних локаціях.

З такою конфігурацією ми отримаємо меншу латентність (latency) для користувачів. І навіть якщо база даних Redis в одному регіоні повністю вийде з ладу, інші регіони не будуть на це впливати. А якщо з'єднання або синхронізація між регіонами буде перервана на короткий час через якусь мережеву проблему, наприклад, кластери Redis в цих регіонах зможуть оновлювати дані незалежно, і коли з'єднання буде відновлено, ці зміни знову синхронізуються.

Вирішення конфліктів з CRDT

Тепер, звісно, перше питання, яке може виникнути у вас, це: Як Redis вирішує зміни в декількох регіонах для одного й того ж набору даних? Тобто, якщо одна й та сама інформація змінюється в кількох регіонах, як Redis гарантує, що зміни в даних з жодного з регіонів не будуть втрачені, і що дані будуть правильно синхронізовані, а також як він забезпечує консистентність даних?

Для цього Redis Enterprise використовує концепцію, що називається CRDT, яка означає Conflict-Free Replicated Data Types (Конфліктно-незалежні типи реплікованих даних), і ця концепція використовується для автоматичного вирішення будь-яких конфліктів на рівні бази даних без втрати даних. Тобто, Redis має механізм для об'єднання змін, які були зроблені до того ж самого набору даних з кількох джерел, таким чином, щоб жодна з змін не була втрачена і всі конфлікти були належним чином вирішені. Оскільки Redis підтримує різні типи даних, для кожного типу даних вони використовують власні правила вирішення конфліктів, які є найоптимальнішими для цього конкретного типу даних.

Отже, простими словами, замість того, щоб просто перезаписувати зміни одного джерела і відкидати всі інші, всі паралельні зміни зберігаються та інтелектуально вирішуються. І знову ж таки, це автоматично робиться для вас за допомогою цієї функції активної-активної географічної реплікації, тому вам не потрібно турбуватися про це.

Запуск Redis на Kubernetes

Остання тема, яку я хочу розглянути з Redis, це запуск Redis в Kubernetes. Як я вже сказав, Redis — це чудовий інструмент для складних мікросервісів, які повинні підтримувати кілька типів даних і які потребують легкого масштабування бази даних без турбот про консистентність даних. І ми також знаємо, що новий стандарт для запуску мікросервісів — це платформа Kubernetes. Тому запуск Redis в Kubernetes є дуже цікавим і поширеним варіантом використання.
Як це працює?

Open Source Redis на Kubernetes

З open source Redis ви можете розгорнути реплікований Redis як Helm chart або за допомогою manifest файлів Kubernetes і, в принципі, використовуючи правила реплікації та масштабування, про які ми вже говорили, налаштувати та запустити високо доступну базу даних Redis. Єдина різниця полягає в тому, що хости, на яких буде працювати Redis, будуть Kubernetes pods замість, наприклад, EC2 інстансів або будь-яких інших фізичних чи віртуальних серверів. Але ті ж самі концепції шардінгу, реплікації та масштабування застосовуються і тут, коли ви хочете запускати Redis кластер на Kubernetes, і вам фактично доведеться самостійно керувати цим налаштуванням.

Redis Enterprise Operator

Проте, як я згадував, багато команд не хочуть витрачати зусилля на підтримку цих сторонніх сервісів, тому що вони хочуть інвестувати свій час і ресурси в розробку додатків чи інші завдання. Тому наявність простішої альтернативи також є важливою. Redis Enterprise має керований Redis кластер, який ви можете розгорнути як Kubernetes operator.

Якщо ви не знайомі з операторами, оператор у Kubernetes — це по суті концепція, за якою можна упакувати всі ресурси, необхідні для роботи певного додатку чи сервісу, щоб вам не доводилося керувати цим самостійно чи працювати з цим вручну. Тобто замість того, щоб людина управляла базою даних, ви маєте всю цю логіку в автоматизованій формі для управління базою даних. І багато баз даних мають операторів для Kubernetes, і кожен такий оператор має свою логіку, залежно від того, хто їх написав і як вони це зробили.

Redis Enterprise на Kubernetes operator автоматизує розгортання та налаштування всієї бази даних Redis у вашому Kubernetes кластері. Він також займається масштабуванням, створенням резервних копій і відновленням Redis кластера, якщо це необхідно тощо. Тобто він бере на себе повне управління Redis кластером всередині Kubernetes кластера.

Ну, я сподіваюся, що ви багато чому навчилися з цього блогу, і що я зміг відповісти на багато ваших питань. І якщо ви хочете дізнатися більше про подібні технології та концепції, не забувайте слідкувати за мною, адже я регулярно пишу блоги на теми AI, DevOps та хмарних технологій.

Також залишайте коментарі нижче, якщо у вас є питання щодо Redis або нові пропозиції щодо тем для блогів. І на цьому все, дякую за читання та побачимося в наступному блозі.

Давайте з'єднаємось на LinkedIn!

Вам може бути цікаво прочитати!

👋 Якщо вам це було корисно, натискайте кнопку аплодисментів 👏 кілька разів, щоб показати свою підтримку автору 👇

🚀Приєднуйтесь до спільноти розробників FAUN і отримуйте подібні історії на свою пошту щотижня

Перекладено з: Redis as a Primary Database for Complex Applications