Valkey – najlepszy bezpośredni zamiennik Redis spośród rozwiązań open source, niewymagający zmian w istniejącym oprogramowaniu
W marcu 2024 r. firma Redis Inc. zastąpiła dotychczasową liberalną licencję BSD licencjami RSALv2/SSPLv1, stwarzając realne ryzyko związane z przestrzeganiem warunków licencyjnych dla zespołów tworzących oprogramowanie komercyjne.
W odpowiedzi społeczność open source i użytkownicy niemal natychmiast utworzyli na bazie kodu źródłowego Redis niezależny projekt o nazwie Valkey. Valkey, uruchomiony w tym samym miesiącu pod auspicjami Linux Foundation, stanowi prawdziwy bezpośredni zamiennik Redis, pozwalający uniknąć komplikacji prawnych wynikających ze zmiany warunków licencyjnych Redis.
Zastąp Redis bez konieczności przebudowy aplikacji
W odpowiedzi na zmianę warunków licencyjnych dotyczącą funkcji Redis społeczność zaczęła poszukiwać rozwiązań, które można szybko opracować i rozwijać w skoordynowany sposób, przy odpowiednim wsparciu i dostępie do zasobów, przede wszystkim niezależnego projektu opartego na kodzie Redis i rozwijanego przez społeczność. Valkey nie jest jedynie projektem wydzielonym z Redis na znak protestu i pozbawionym solidnego wsparcia. Valkey korzysta ze znaczącego wsparcia instytucjonalnego i jest aktywnie rozwijany – stanowi więc alternatywę udostępnianą w całości na licencji BSD, w pełni kompatybilną z kodem Redis, z którego korzysta już większość zespołów.
Valkey: Poczucie bezpieczeństwa wpisane w projekt i usługę
![[object Object]](https://assets.ovhcloud.com/1fiLCdLm2rnpzzL64g7Ebupwy_sN2JmNTk4MzJkMDY1NjMw/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_96bcf0ea.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fihA7kvoqCdjbpFh8CSqrAFg_sODM3OGYwNzczYjJhNGI5/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_a2fe1080.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fi4ELnwoChAbqnnwm3zvgAv5_sODJhOTlmMGI0OTUzYWJl/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_f9914d17.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fiz8uqm8kwozpmrpt2nCdg5F_sNzRjNjI0Y2U4ZDlmOWQ0/fde60b08-8e21-4aab-8c78-ddfe838a0c77_ite_fe1d1635.svg){kind=small}
Dlaczego programiści szukają alternatywy dla Redis w 2026 roku
Wyjaśnienie zmiany licencji Redis w 2024 roku
Przez większość swojego istnienia Redis był udostępniany na trzyklauzulowej licencji BSD, jednej z najbardziej liberalnych licencji open source. Można było bez ograniczeń korzystać z Redis, modyfikować go i tworzyć na jego podstawie produkty komercyjne. Zmieniło się to 20 marca 2024 r., kiedy firma Redis Inc. ogłosiła, że Redis 7.4 i wszystkie przyszłe wersje wprowadzające nowe funkcje będą udostępniane w modelu podwójnego licencjonowania: RSALv2 (Redis Source Available License v2) i SSPLv1 (Server Side Public License). Żadna z tych licencji nie została zatwierdzona przez organizację Open Source Initiative (OSI), a obie nakładają wyraźne ograniczenia na wykorzystywanie oprogramowania w środowiskach komercyjnych i chmurowych.
Dlaczego SSPL stwarza ryzyko naruszenia warunków licencyjnych w przypadku produktów komercyjnych
Licencja SSPL została pierwotnie opracowana przez firmę MongoDB, aby uniemożliwić dostawcom usług chmurowych oferowanie usług zarządzanych baz danych bez wnoszenia wkładu w rozwój projektu. Głównym problemem dla zespołów tworzących produkty komercyjne jest punkt 13 licencji: jeśli udostępniasz aplikację jako usługę i korzysta ona z oprogramowania objętego licencją SSPL, możesz być zobowiązany do udostępnienia kodu źródłowego całego stosu technologicznego tej usługi, w tym opracowanych przez siebie komponentów własnościowych
Dla większości zespołów inżynierskich taki obowiązek jest nie do przyjęcia przy opracowywaniu nowych funkcji i alternatywnych rozwiązań. Nawet jeśli prawnicy uznają, że w praktyce ryzyko jest niewielkie, sama niepewność komplikuje procesy zakupowe, przeglądy bezpieczeństwa i zawieranie umów z klientami korporacyjnymi. Licencja RSALv2 dodatkowo komplikuje sytuację, wyraźnie zakazując wykorzystywania oprogramowania w konkurencyjnych produktach lub funkcjach i pozostawiając firmie Redis Inc. dużą swobodę w określaniu, co stanowi konkurencję… Ponownie naraża to użytkowników Redis na ryzyko licznych sporów prawnych, którego można łatwo uniknąć, korzystając z kodu objętego licencją zatwierdzoną przez OSI.
Pozostanie przy Redis 7.2 – ukryty dług związany z bezpieczeństwem
Ostatnią wersją Redis do buforowania danych udostępnioną na licencji BSD była wersja 7.2. Niektóre zespoły decydują się pozostać przy tej wersji, zamiast zaakceptować nowe warunki licencyjne. W krótkiej perspektywie może to być pragmatyczne rozwiązanie, które jednak wiąże się z długoterminowymi kosztami. Redis 7.2 nie otrzymuje już od Redis Inc. poprawek zabezpieczeń ani poprawek błędów, co oznacza, że podatności CVE wykryte po zmianie licencji nie są usuwane w tej gałęzi. Dla zespołów korzystających z Redis 7.2 do buforowania danych w środowisku produkcyjnym, przetwarzających dane wrażliwe lub podlegających wymaganiom takim jak NIS2 czy SOC 2 nie jest to ryzyko czysto teoretyczne. Pozostanie przy Redis 7.2 powoduje powstanie rzeczywistej luki w zapewnieniu zgodności z wymaganiami, która pogłębia się z każdym miesiącem.
Dlaczego AGPLv3 w Redis 8.0 nie stanowi trzeciej opcji
Wraz z wydaniem Redis 8.0 w 2025 r. firma Redis Inc. ponownie zmieniła podejście do licencjonowania, tym razem wprowadzając licencję AGPLv3, zatwierdzoną przez OSI. Jest to realny krok naprzód w kierunku uznania Redis za oprogramowanie open source i odpowiedź na jeden z głównych zarzutów wobec zmiany z 2024 r. AGPLv3 jest jednak licencją typu „silny copyleft”, co wiąże się z dodatkowymi komplikacjami dla zespołów tworzących oprogramowanie komercyjne.
Każde oprogramowanie, które komunikuje się przez sieć z komponentem objętym licencją AGPLv3, może podlegać obowiązkowi udostępnienia swojego kodu źródłowego na tej samej licencji. W przypadku własnościowych produktów SaaS pozostaje to istotnym ograniczeniem przy rozważaniu alternatywnych rozwiązań. Kilku znanych przedstawicieli branży, w tym współtwórcy projektu Valkey, zwróciło uwagę, że AGPLv3 (choć bardziej zgodna z zasadami open source niż SSPL) nadal stawia Redis w innej kategorii niż alternatywne rozwiązania open source udostępniane na rzeczywiście liberalnych licencjach.
Zachowaj dotychczasowe działanie aplikacji i kontroluj lokalizację danych
Layout wielowęzłowy pozwala również zachować znane mechanizmy zapewniające odporność na awarie. Kompatybilność nadal wymaga przetestowania. Moduły, zachowania specyficzne dla poszczególnych wersji i nietypowe kombinacje poleceń mogą powodować zwracanie innych odpowiedzi. Architektura Storage, parametry klientów i topologia również mogą wpływać na stabilność lub prędkość transmisji danych. Nie należy zakładać, że po migracji wszystkie przypadki brzegowe będą obsługiwane szybciej lub identycznie. Licencja Valkey zatwierdzona przez OSI zapewnia zespołom tworzącym produkty komercyjne trwałą alternatywę open source dla Redis, bez uzależniania architektury aplikacji od restrykcyjnych warunków licencyjnych.
Wybór sposobu wdrożenia wiąże się również z kwestiami operacyjnymi. Zarządzana usługa europejska może łączyć przetwarzanie wielowątkowe, rozmieszczenie węzłów zapewniające odporność na awarie oraz kontrolę nad miejscem przechowywania danych. Takie podejście wspiera europejską suwerenność danych, zapewniając przejrzystość lokalizacji danych, zasad dostępu do nich i warunków umownych, a jednocześnie ograniczając bieżące obowiązki związane z zarządzaniem platformą.
W niektórych testach DragonflyDB osiąga najwyższą prędkość transmisji danych na pojedynczym węźle, ale jego przewaga znacznie maleje w konfiguracjach klastrowych. Valkey zapewnia pełną zgodność funkcji z Redis 7.2, a plan rozwoju Valkey objął od tego czasu usprawnienia przetwarzania wielowątkowego i efektywności wykorzystania pamięci, dzięki którym przy niektórych obciążeniach roboczych osiąga on lepszą wydajność niż wersja Redis, na której został oparty.
Inne technologie mogą odpowiadać specjalistycznym wymaganiom, takim jak wyszukiwanie wektorowe czy sporadyczne bezserwerowe obciążenia robocze. Podczas analizy można korzystać z materiałów technicznych znalezionych za pomocą Google, dyskusji społeczności i dokumentacji dostawców, jednak większą wagę należy przywiązywać do dokumentacji źródłowej i wyników testów przeprowadzonych w kontrolowanych warunkach. Należy porównać alternatywne rozwiązania pod kątem koniecznych zmian w aplikacji, dojrzałości operacyjnej, dostępnego wsparcia, modelu zarządzania i całkowitego nakładu pracy związanego z migracją. Odpowiednia technologia to taka, która spełnia wymagania określone na podstawie pomiarów przy akceptowalnym ryzyku licencyjnym i operacyjnym.
Dostosuj model operacyjny do swoich wymagań
Zarządzana usługa Valkey
Usługa Managed Databases for Valkey sprawdza się w firmach, którym zależy na łatwym zarządzaniu i przewidywalnych kosztach infrastruktury. OVHcloud zapewnia wysoką dostępność oraz zajmuje się utrzymaniem, monitorowaniem i tworzeniem kopii zapasowych, ograniczając nakład pracy wewnętrznych zespołów potrzebny do zapewnienia odporności usługi na awarie. Przepustowość i operacje wejścia/wyjścia (IOPS) są również wliczone w cenę, co ułatwia planowanie budżetu. Jest to praktyczne rozwiązanie domyślne dla zespołów odpowiedzialnych za platformę, które potrzebują Valkey, ale nie chcą samodzielnie wykonywać wszystkich zadań operacyjnych.
Samodzielne zarządzanie Valkey
Samodzielne zarządzanie zapewnia kontrolę nad wersjami oprogramowania, topologią, parametrami zabezpieczeń i lokalizacją wdrożenia. Takie rozwiązanie może sprawdzić się w firmach o szczególnych wymaganiach lub posiadających już ugruntowane procesy zarządzania bazami danych. Wady są jednak równie istotne: wewnętrzny zespół odpowiada za aktualizacje, tworzenie kopii zapasowych, obserwowalność, testowanie przełączania awaryjnego i reagowanie na incydenty. Wsparcie społeczności jest pomocne, ale nie zastąpi profesjonalnego wsparcia dla środowisk produkcyjnych ani odpowiednich zasobów operacyjnych.
KeyDB
KeyDB może sprawdzić się w zespołach rozważających przetwarzanie wielowątkowe w przypadku określonych obciążeń roboczych związanych z danymi przechowywanymi w pamięci operacyjnej i wymagań dotyczących opóźnień. Przed podjęciem decyzji oceń kompatybilność, częstotliwość wydawania nowych wersji, kondycję projektu i dostępność wsparcia. Przetestuj wydajność rzeczywistej aplikacji, zamiast zakładać, że określona cecha architektury usprawni obsługę każdego rodzaju żądań. Informacje pochodzące od założyciela projektu lub zawarte we wczesnych komunikatach dotyczących projektu należy również weryfikować na podstawie aktualnej dokumentacji.
Wyspecjalizowane rozwiązania alternatywne
Usługi bezserwerowe mogą ograniczyć konieczność planowania zasobów przy sporadycznych obciążeniach roboczych, natomiast wektorowe bazy danych umożliwiają wyszukiwanie podobieństw i obsługę innych specjalistycznych modeli danych. Inne oprogramowanie działające w pamięci operacyjnej może odpowiadać na specyficzne wymagania, takie jak prędkość transmisji danych lub ich trwałość. Narzędzia te mogą rozwiązywać konkretne problemy, ale nie zawsze umożliwiają bezpośrednie zastąpienie dotychczasowych rozwiązań. Zanim wybierzesz je zamiast Valkey, uwzględnij konieczne zmiany w aplikacji, przenoszenie danych, odpowiedzialność za obsługę operacyjną i koszty długoterminowe.
Wybierz metodę migracji dostosowaną do dopuszczalnego czasu przestoju
Zatrzymaj instancję Redis, aby zapewnić spójność danych, skopiuj plik do katalogu danych Valkey i uruchom Valkey – gotowe. Całkowity czas migracji zależy od wielkości zbioru danych, a nie od złożoności aplikacji. W środowiskach produkcyjnych, w których przestoje są niedopuszczalne, bezpieczniejszym rozwiązaniem jest replikacja podczas pracy systemu. Valkey można skonfigurować jako replikę działającej instancji Redis 7.2 za pomocą standardowego polecenia REPLICAOF.
Po pełnej synchronizacji repliki zmień ciąg połączenia aplikacji tak, aby wskazywał na Valkey, przełącz replikę do roli instancji głównej, a następnie wycofaj instancję Redis z eksploatacji. Ponieważ oba systemy korzystają z tego samego protokołu replikacji, proces ten jest prosty i został dokładnie przetestowany w środowiskach produkcyjnych przez zespoły korzystające ze wszystkich głównych platform chmurowych.
![[object Object]](https://assets.ovhcloud.com/1fiX676v6wSp4t82zXEm6hhry_sNzAzOTNmMTIyZWVkYzg0/555a10a6-71ae-4d77-959e-b2a8dc0e9831_ima_c8d0550b.png)
Opracuj czteroelementowy model oceny gotowości do migracji
1. Kompatybilność aplikacji
Sporządź wykaz wszystkich używanych poleceń, bibliotek klienckich i wersji protokołu. Udokumentuj wykorzystywane funkcje RESP3, skrypty Lua, transakcje, działanie mechanizmu Pub/Sub, zależności od JSON lub modułów oraz specyficzny dla aplikacji sposób obsługi przekroczenia limitu czasu. Kompatybilny rdzeń nie gwarantuje identycznego działania wszystkich rozszerzeń. Porównaj obecne środowisko z wersją docelową i przetestuj reprezentatywne żądania. Uwzględnij obsługę awarii, zarządzanie pulą połączeń i mechanizmy ponawiania prób. Jeśli aplikacja korzysta z technologii dostarczanej przez zewnętrzną wtyczkę, sprawdź osobno, czy jest ona nadal utrzymywana. Taki wykaz pozwala potwierdzić ogólną kompatybilność dowodami dotyczącymi konkretnych wymagań.
2. Chroń integralność danych
Przed migracją określ parametry zbioru danych, w tym liczbę kluczy, rozkład terminów ich wygaśnięcia, rozmiary obiektów i szczytowe zużycie pamięci. Środowisko docelowe musi dysponować wystarczającą ilością pamięci do normalnej pracy, replikacji oraz pokrycia dodatkowego, tymczasowego zapotrzebowania podczas synchronizacji lub utrwalania danych. Przeanalizuj parametry tworzenia snapshotów i zapisu AOF, zamiast kopiować je bez wcześniejszej weryfikacji. Po przeniesieniu danych porównaj liczbę kluczy, wartości wybranych kluczy oraz sposób ich wygasania. Kontrole na poziomie aplikacji mogą ujawnić problemy niewidoczne w zbiorczych danych liczbowych, takie jak nieprawidłowe dane sesji lub niekompletny stan kolejki. Przed przełączeniem na nowe środowisko przekaż kryteria akceptacji osobom odpowiedzialnym za usługi, aby wszyscy stosowali tę samą definicję prawidłowego zbioru danych.
3. Określ topologię środowiska docelowego
Udokumentuj, czy obecna platforma działa jako pojedyncza instancja, wykorzystuje replikację czy jest rozproszona w klastrze. Sporządź wykaz wszystkich węzłów, tras sieciowych, reguł bezpieczeństwa, zależności od DNS i lokalizacji fizycznych. Taki schemat pomaga zespołom wybrać docelowy layout odpowiadający wymaganiom dotyczącym odporności na awarie, zamiast powielać wcześniejsze rozwiązania. Testy łączności powinny obejmować aplikację, systemy monitorowania i narzędzia administracyjne. W przypadku rozproszonych obciążeń roboczych sprawdź obsługę slotów, rozmieszczenie replik i zachowanie systemu w razie awarii węzła. Wymagania dotyczące lokalizacji danych mogą również decydować o tym, które regiony lub strefy dostępności można wykorzystać.
4. Nadzoruj przełączenie na nowe środowisko
Przed przekierowaniem ruchu ustal wartości bazowe opóźnień, wskaźnika błędów i wykorzystania zasobów. Gdy usługa działa stabilnie, określ progi monitorowania, kryteria wycofania migracji i osoby odpowiedzialne za podejmowanie decyzji. Pozwoli to uniknąć sporów o to, jakie zachowanie systemu jest dopuszczalne podczas incydentu. Jeśli architektura na to pozwala, przekierowuj ruch etapami. Zacznij od wewnętrznych obciążeń roboczych lub obciążeń o niskim poziomie ryzyka, monitoruj błędy po stronie klientów i porównuj wyniki, a następnie stopniowo zwiększaj udział przekierowywanego ruchu. Zachowaj możliwość przywrócenia środowiska źródłowego do czasu zakończenia weryfikacji. Bezpieczne przełączenie na nowe środowisko wymaga wyników pomiarów, jasno określonej odpowiedzialności i możliwości wycofania zmian, a nie tylko deklaracji kompatybilności.
Dlaczego warto wybrać OVHcloud Managed Databases for Valkey
Jednym z częstych problemów związanych z zarządzanymi bazami danych w chmurze jest nieprzewidywalność kosztów. Pomyśl o opłatach, które gwałtownie rosną wraz z obciążeniem, ponieważ przepustowość, operacje wejścia/wyjścia (IOPS) i przechowywanie kopii zapasowych są rozliczane oddzielnie. Model cenowy OVHcloud uwzględnia wszystkie te koszty w jednej stałej opłacie miesięcznej. Przepustowość, operacje wejścia/wyjścia (I/O) i automatyczne kopie zapasowe są wliczone w cenę, więc koszt podany podczas uruchamiania usługi odpowiada kosztowi jej eksploatacji w środowisku produkcyjnym. Dla zespołów finansowych i zakupowych w szybko rozwijających się firmach o ograniczonych budżetach na infrastrukturę oznacza to znacznie łatwiejsze planowanie zasobów.
