KeyDB како [потенцијална] замена за Redis

Немаше прегледи за „побрза алтернатива на Редис“ на Хабре - KeyDB. Имајќи стекнато прилично неодамнешно искуство во користењето, би сакал да ја пополнам оваа празнина.

Позадината е прилично банална: еден ден, со голем прилив на сообраќај, беше забележано значително влошување на перформансите на апликацијата (имено, времето на одговор). Во тоа време, за жал, не беше можно да се спроведе нормална дијагноза на она што се случува, па потоа беа планирани серија тестови за оптоварување. По нивното спроведување, успеавме да откриеме тесно грло, што беше кешот на базата на податоци во Редис. Како што често се случува, проблемот не можеше да се реши веднаш и на вистински начин - од програмерите (со менување на логиката на работа). Затоа, се вклучи љубопитноста и желбата да се надмине ситуацијата на кружен начин. Вака се појави овој напис.

Прашања

За Редис воопшто

Како што многу луѓе знаат, Redis е база на податоци со една нишка. Да бидам попрецизен, вака е во контекст на работа со кориснички податоци. На крајот на краиштата, од четвртата верзија, услуга, внатрешни операции на Редис преведено за паралелно извршување. Сепак, оваа промена влијаеше само на мал дел од обемот на работа, бидејќи најголемиот дел од работата се врши на кориснички податоци.

На оваа тема беа скршени безброј копии, но програмерите на Redis тврдоглаво одбиваат да спроведат целосен паралелизам, спомнувајќи колку тоа ќе ја комплицира апликацијата и ќе ги зголеми режиските трошоци, како и да додаде повеќе грешки. Нивната позиција е следна: ако сте соочени со проблем со едно јадро, имате проблеми со архитектурата на апликацијата и нешто треба да се промени во неа. Меѓу корисниците, сепак, има и „друг камп“ - оние кои се заглавени на едно јадро и тврдат дека Редис си создава тесно грло за себе. Во случај на навистина големи оптоварувања - порано или подоцна - неизбежно е да се сретнеме со овој проблем, кој наметнува значителни ограничувања на архитектурата и/или принудни компликации во него.

Нема да го оценувам ова или она мислење. Наместо тоа, ќе го споделам нашиот конкретен случај и како го решивме.

Нашиот случај

Во еден од проектите, наидовме на фактот дека тимот за развој конфигурирал исклучително агресивно кеширање на податоци од базата на податоци (PostgreSQL) преку Redis. Ова беше единствениот начин на кој, при ненадејни приливи на сообраќај, се спаси самиот PostgreSQL и, како резултат на тоа, апликацијата од смрт.

По серија тестови за оптоварување, ја анализиравме ситуацијата и откривме дека Редис е ограничен на едно јадро (што се нарекува „полица“), проследено со прилично брзо деградирање на апликацијата. „Гушењето“ беше експоненцијално: штом беше достигнато лимитот за изведба на Редис, сè престана да работи.

Изгледаше нешто вака:

New Relic јасно го идентификуваше проблемот:

Еве ја статистиката за операцијата: get во Редис:

Откако проблемот беше детално пријавен до тимот за развој, се покажа дека „проблемот не може да се реши во моментов“. Така започна потрагата по решение на оперативната страна, а веќе споменатиот KeyDB беше одговорот.

Сепак, пред да започнеме со нашиот преглед, вреди да се спомене дека проектот користи самостоен Redis, бидејќи кластерското решение базирано на Sentinel е многу инфериорно во однос на латентноста. Едно очигледно решение беше да се создадат неколку реплики на кешот: и нека апликацијата оди насекаде со балансирање! Сепак, по консултација со програмерите, бевме принудени да ја отфрлиме оваа опција поради активниот и комплексен механизам за поништување на кешот на апликацијата. Истиот проблем се прошири и на делењето на кешот.

Брз поглед на KeyDB

Додека баравме можно решение за проблемот, откривме апликација наречена KeyDB. Ова е вилушка Redis развиена од Канадска компанија и дистрибуирани под бесплатната BSD лиценца. Проектот е многу млад: постои од почетокот на 2019 година. Неговата историја е дека авторите, исто така, еднаш се сретнале со ограничувањата на Редис... и решиле да направат своја вилушка. Покрај тоа, тој не само што ги реши познатите проблеми, туку доби и дополнителни функции кои се достапни само во ентерпис верзијата на Redis.

За оние кои сакаат подетално да се запознаат со KeyDB, има добро воведна статија за Медиум, кој го претставува DBMS и кратки репери споредувајќи го со неговиот „родител“ - Redis.

Пред сè, нè привлече KeyDB од потенцијалното решение на нашите проблеми, а во исто време бевме заинтересирани за некои дополнителни функции. Користењето на KeyDB ги вети следните предности:

• добивање на целосна мултинишка;
• целосна и апсолутна компатибилност со Redis (ова беше особено важно за нас, бидејќи не беше можно да се направат никакви модификации на страната на апликацијата), што исто така ветуваше миграција без проблеми;
• вграден механизам за резервна копија во складирање на S3;
• лесно да се спроведе активна репликација;
• едноставно кластерирање и делење без Sentinel и друг софтвер за поддршка.

Повеќе од 3 илјади ѕвезди и многу соработници на GitHub исто така изгледаа охрабрувачки. Апликацијата е доста активно развиена и поддржана, што е јасно видливо во заложбите, комуникацијата во прашања, како и затворените (прифатени) ПР. Одговорот од главниот одржувач на сите фронтови е секогаш пријателски и брз. Во принцип, имаше многу расправии.

Миграција и резултати

Иако проектот за миграција беше малку коцкар (поради новоста на KeyDB), немаше многу да се изгуби. На крајот на краиштата, враќањето на промените е прилично брзо и лесно - за среќа, целата инфраструктура е распоредена во Kubernetes, а вградените механизми Ролинг ажурирање Многу добро ги решаваат ваквите проблеми.

Општо земено, подготвивме шаблони на Helm, ја префрливме апликацијата во околината за тестирање во нова база на податоци и сето тоа го префрливме, предавајќи го на одделот за ОК на клиентот.

Започна тестирањето, кое траеше околу една недела и во чии детали не нурнавме. Знаеме само дека клиентот ги тестирал стандардните функции за работа со Redis користејќи PHP драјвер phpredis, а исто така спроведе и QA тестирање на корисничкиот интерфејс. После тоа, ни беше дадено зелено светло: не беа пронајдени никакви несакани ефекти при користењето на новиот софтвер. Тоа е Од апликативна гледна точка, ништо воопшто не се смени.

Вреди да се напомене дека не сменивме ништо во конфигурацијата: буквално, едноставно ја заменивме користената слика. Истото важи и за следење и извоз на метрика во Прометеј: најчести од нив работи совршено со KeyDB и без никакви измени. Така, можеме безбедно да кажеме дека од оперативна гледна точка, ова е едноставно идеален потег.

Благодарение на сето ова, откако ќе ја префрлите апликацијата на нов DBMS, не можете да промените ништо, но како „мерка за стабилизација“ можете да ја оставите во оваа форма да работи извесно време во борба. Меѓутоа, ако сакате да видите зголемување на перформансите (или какви било промени), не смеете да го заборавите тоа стандардно KeyDB параметар одговорен за повеќенишки (server-threads), е еднакво на еден, т.е DBMS работи исто како и Redis.

По префрлувањето, тестирањето и одредено време од животот на новата апликација (со KeyDB), решивме да го повториме тестирањето за оптоварување со истите параметри што беа користени за Redis. Кои беа неговите резултати?..

Според графиконот за потрошувачка на процесорот, отстранувањето на проблемите со „таванот“ на едно јадро веднаш стана забележливо: процесот почна да ги користи достапните ресурси:

А подоцна се обидов да ја „мачам“ апликацијата доста силно и видов потрошувачка до три јадра...

Според New Relic, веб-апликацијата како целина, со исто оптоварување, почнала да се однесува забележливо поадекватно. Сè уште беше забележано одредено деградирање на перформансите, но, споредено со сличен графикон погоре, можете сами да го процените значителниот напредок:

Латентноста на новата база на податоци (KeyDB) исто така се влоши, но остана во рамките на прифатливите вредности:

Следниот графикон јасно покажува дека бројот на барања до самиот KeyDB е сличен:

За да ги сумираме овие синтетички тестови, можеме да кажеме дека и Redis и KeyDB покажуваат значителна деградација на перформансите во латентноста (40 ms+) со значително зголемување на бројот на паралелни врски (1000+). Во нашиот случај, веб-апликацијата можеше да ја „троши“ латентноста на Redis дури и со помал број на врски (400+), иако за KeyDB таквото оптоварување остана прифатливо.

Наоди

Овој пример јасно ја покажува силата на заедницата со отворен код во развојот на проекти за кои е заинтересирана. Наидов на одлична изјава на Интернет, чиешто општо значење се сведуваше на следново: „Некоја голема компанија создава интересен производ, прави некои свои функции отворени, но најважниот дел го остава платен. Заедницата го користи и го користи, а потоа некој се откажува и прави вилушка, имплементирајќи ги истите платени функции во неа и отворајќи ги за сите. Овде KeyDB е истиот случај.

Зборувајќи за самата миграција, која беше изненадувачки едноставна, не ја добивме така значително зголемување на перформансите, што може да се очекува со гледање на графиконите на авторите на KeyDB... Сепак, ова е само нашиот посебен случај, во кој може да има многу отстапувања, вклучувајќи ја и озлогласената архитектура на апликацијата (на пр. , огромен број на команди get во Redis наместо поперформативната опција на збирни барања mget...). Сепак, успеавме да постигнеме позитивни резултати, а заедно со нив и многу корисни функции кои ќе ги спроведеме во блиска иднина.

Општо земено, KeyDB изгледа ветувачко: како што стекнуваме практично искуство со овој DBMS (и сè уште треба да го стекнеме!) и го развиваме самиот проект, ќе ја разгледаме можноста да го користиме во други ситуации.

Сепак, овој напис не треба да се смета како водич (а камоли повик) за акција за широко распространето напуштање на Redis во корист на KeyDB. И покрај нашето позитивно искуство, јасно е дека ова не е сребрен куршум. Случајот беше многу специфичен: конкретно за решавање на моментален проблем во ситуација кога беше неопходно тоа да се направи брзо и со минимални трошоци, ова решение беше оправдано. Дали KeyDB ќе биде корисен во вашиот случај? Барем сега знаете дека оваа потенцијална можност постои.

PS

Прочитајте и на нашиот блог:

• «Бази на податоци и Kubernetes (преглед и видео извештај)";
• «Миграција на Касандра во Кубернетес: карактеристики и решенија";
• «Беспрекорна миграција на MongoDB во Kubernetes";
• «Беспрекорна миграција на RabbitMQ во Kubernetes".

Извор: www.habr.com