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

Нямаше отзиви за „по-бърза алтернатива на Redis“ на Habré - KeyDB. След като придобих сравнително скорошен опит в използването му, бих искал да запълня тази празнина.

Фонът е доста банален: един ден, с голям приток на трафик, беше записано значително влошаване на производителността на приложението (а именно времето за реакция). По това време, за съжаление, не беше възможно да се извърши нормална диагностика на случващото се, така че впоследствие бяха планирани серия от тестове за натоварване. След като ги извършихме, успяхме да открием пречка, която беше кеша на базата данни в Redis. Както често се случва, проблемът не може да бъде решен веднага и по правилния начин - от разработчиците (чрез промяна на логиката на работа). Затова се включи любопитството и желанието да се преодолее ситуацията по заобиколен начин. Ето как се появи тази статия.

Проблеми

За Redis като цяло

Както много хора знаят, Redis е база данни с една нишка. По-точно така е в контекста на работа с потребителски данни. В края на краищата, от четвъртата версия, услугата, вътрешните операции на Redis прехвърлен за паралелно изпълнение. Тази промяна обаче засегна само малка част от натоварването, тъй като по-голямата част от работата се извършва върху потребителски данни.

По тази тема са счупени безброй копия, но разработчиците на Redis упорито отказват да внедрят пълен паралелизъм, като споменават колко много ще усложни приложението и ще увеличи режийните разходи, както и ще добави още грешки. Тяхната позиция е следната: ако сте изправени пред проблем с едно ядро, имате проблеми с архитектурата на приложението и нещо трябва да се промени в него. Сред потребителите обаче има и „друг лагер“ - тези, които са останали на едно ядро ​​и твърдят, че Redis създава пречка за себе си. При наистина големи натоварвания - рано или късно - е неизбежно да се сблъскате с този проблем, който налага значителни ограничения върху архитектурата и/или принудителни усложнения в нея.

Няма да давам оценка на това или онова мнение. Вместо това ще споделя нашия конкретен случай и как го решихме.

Нашият случай

В един от проектите се сблъскахме с факта, че екипът за разработка беше конфигурирал изключително агресивно кеширане на данни от базата данни (PostgreSQL) чрез Redis. Това беше единственият начин, който при внезапни напливи на трафик спаси самия PostgreSQL и в резултат на това приложението от смърт.

След поредица от тестове за натоварване анализирахме ситуацията и установихме, че Redis е ограничен до едно ядро ​​(това, което се нарича „рафт“), последвано от доста бързо влошаване на приложението. „Задушаването“ беше експоненциално: веднага щом лимитът на производителност на Redis беше достигнат, всичко спря да работи.

Изглеждаше така:

New Relic ясно идентифицира проблема:

Ето и статистиката за операцията: get в Redis:

След като проблемът беше докладван подробно на екипа за разработка, се оказа, че „проблемът не може да бъде решен в момента“. Така започна търсенето на решение от страна на операциите и вече споменатият KeyDB беше отговорът.

Въпреки това, преди да започнем нашия преглед, струва си да споменем, че проектът използва самостоятелен Redis, тъй като клъстерното решение, базирано на Sentinel, е много по-ниско по отношение на латентността. Едно очевидно решение беше да се създадат няколко копия на кеша: и да се позволи на приложението да върви навсякъде с балансиране! Въпреки това, след консултация с разработчиците, бяхме принудени да отхвърлим тази опция поради активния и сложен механизъм за анулиране на кеша на приложението. Същият проблем се разшири и до разделянето на кеша.

Бърз поглед върху KeyDB

Докато търсихме възможно решение на проблема, открихме приложение, наречено KeyDB. Това е разклонение на Redis, разработено от канадска компания и се разпространява под безплатния BSD лиценз. Проектът е много млад: съществува от началото на 2019 г. Неговата история е, че авторите също веднъж се сблъскаха с ограниченията на Redis... и решиха да направят своя собствена вилица. Нещо повече, той не само реши известни проблеми, но също така получи допълнителни функции, които са налични само в корпоративната версия на Redis.

За тези, които искат да се запознаят по-подробно с KeyDB, има добро уводна статия за Medium, който представя СУБД и кратки бенчмаркове, сравняващи го с неговия “родител” - Redis.

На първо място, ние бяхме привлечени от KeyDB от потенциалното решение на нашите проблеми и в същото време се интересувахме от някои допълнителни функции. Използването на KeyDB обещава следните предимства:

• получаване на пълна многопоточност;
• пълна и абсолютна съвместимост с Redis (това беше особено важно за нас, тъй като не беше възможно да се направят каквито и да било модификации от страна на приложението), което също обещаваше безпроблемна миграция;
• вграден механизъм за архивиране в S3 хранилище;
• лесна за изпълнение активна репликация;
• просто клъстериране и шардинг без Sentinel и друг поддържащ софтуер.

Повече от 3 хиляди звезди и много участници в GitHub също изглеждаха обнадеждаващи. Приложението е доста активно разработено и поддържано, което е ясно видимо в ангажиментите, комуникацията в проблемите, както и затворените (приети) PR-и. Отговорът от главния поддържащ на всички фронтове винаги е приятелски настроен и бърз. Като цяло имаше много аргументи.

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

Въпреки че проектът за миграция беше малко хазарт (поради новостта на KeyDB), нямаше много за губене. В крайна сметка връщането на промените е доста бързо и лесно - за щастие цялата инфраструктура е разгърната в Kubernetes и вградените механизми Текуща актуализация Много добре решават такива проблеми.

Като цяло подготвихме шаблони на Helm, превключихме приложението в тестовата среда към нова база данни и го внедрихме, като го предадохме на QA отдела на клиента.

Започнаха тестове, които продължиха около седмица и в чиито подробности не навлизахме. Знаем само, че клиентът е тествал стандартните функции за работа с Redis, използвайки PHP драйвер phpredis, а също така проведе QA тестване на потребителския интерфейс. След това ни беше дадена зелена светлина: не бяха открити странични ефекти при използването на новия софтуер. Това е От гледна точка на приложението нищо не се е променило.

Струва си да се отбележи, че не променихме нищо в конфигурацията: буквално, просто заменихме използваното изображение. Същото важи и за наблюдението и експортирането на показатели към Prometheus: най-често срещаните от тях работи перфектно с KeyDB и без никакви модификации. Така че можем спокойно да кажем, че от оперативна гледна точка това е просто идеален ход.

Благодарение на всичко това, след като превключите приложението към нова СУБД, не можете да промените нищо, но като „мярка за стабилизиране“ можете да го оставите в тази форма да работи в битка за известно време. Въпреки това, ако искате да видите увеличение на производителността (или някакви промени изобщо), не трябва да забравяте това по подразбиране Параметър KeyDB, отговорен за многонишковостта (server-threads), е равно на едно, т.е СУБД работи точно по същия начин като Redis.

След превключване, тестване и известно време на живот на новото приложение (с KeyDB), решихме да повторим теста за натоварване със същите параметри, които бяха използвани за Redis. Какви бяха резултатите от него?...

Според графиката на потреблението на процесора, премахването на проблемите с „тавана“ на едно ядро ​​веднага стана забележимо: процесът започна да използва наличните ресурси:

И по-късно се опитах да "мъча" приложението доста силно и видях консумация до три ядра ...

Според New Relic уеб приложението като цяло, имайки същото натоварване, започна да се държи значително по-адекватно. Все още се наблюдава известно влошаване на производителността, но в сравнение с подобна графика по-горе можете сами да оцените значителния напредък:

Забавянето на новата база данни (KeyDB) също се влоши, но остана в приемливи стойности:

Следната графика ясно показва, че броят на заявките към самата KeyDB е подобен:

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

Данни

Този пример ясно показва силата на Open Source общността в разработването на проекти, от които се интересува. В интернет попаднах на отлично твърдение, чийто общ смисъл се свеждаше до следното: „Някаква голяма компания създава интересен продукт, прави някои от функциите си отворени, но оставя най-важната част платена. Общността го използва и го използва, а след това някой се отказва и прави разклонение, прилагайки същите платени функции в него и ги отваря за всички. Тук KeyDB е същият случай.

Говорейки за самата миграция, която беше учудващо проста, не получихме толкова много значително увеличение на производителността, което може да се очаква, като се видят графиките на авторите на KeyDB... Това обаче е само нашият специален случай, в който може да има много отклонения, включително прословутата архитектура на приложението (напр. , огромен брой команди get в Redis вместо по-производителната опция за обобщени заявки mget...). Въпреки това успяхме да постигнем положителни резултати, а заедно с тях и много полезни функции, които ще внедрим в близко бъдеще.

Като цяло KeyDB изглежда обещаващо: тъй като натрупаме практически опит с тази СУБД (и все още трябва да го натрупаме!) и разработим самия проект, ще разгледаме възможността да го използваме в други ситуации.

Въпреки това, тази статия не трябва да се разглежда като ръководство (да не говорим за призив) за действие за широко разпространеното изоставяне на Redis в полза на KeyDB. Въпреки нашия положителен опит е ясно, че това не е сребърен куршум. Случаят беше много специфичен: конкретно за решаване на моментен проблем в ситуация, когато трябваше да се направи бързо и с минимални разходи, това решение беше оправдано. KeyDB ще бъде ли полезна във вашия случай? Сега поне знаете, че тази потенциална възможност съществува.

PS

Прочетете също в нашия блог:

• «Бази данни и Kubernetes (преглед и видео отчет)»;
• «Миграция на Cassandra към Kubernetes: функции и решения»;
• «Безпроблемна миграция на MongoDB към Kubernetes»;
• «Безпроблемна миграция на RabbitMQ към Kubernetes".

Източник: www.habr.com