Jaki jest sens wielu baz danych Redis?

Tak więc doszedłem do miejsca, w którym chciałem podzielić dane, które przechowuję w redis na oddzielne bazy danych, ponieważ czasami potrzebuję użyć polecenia kluczy na jednym konkretnym rodzaju danych i chciałem je oddzielić, aby to przyspieszyć .

Jeśli podzielę się na wiele baz danych, wszystko jest nadal jednowątkowe, a nadal mogę używać tylko jednego rdzenia. Jeśli po prostu uruchomię inną instancję Redis na tym samym pudełku, będę mógł użyć dodatkowego rdzenia. Poza tym nie mogę nazwać baz danych Redis ani nadać im żadnego bardziej logicznego identyfikatora. Biorąc to wszystko pod uwagę, dlaczego / kiedy miałbym kiedykolwiek chcieć używać wielu baz danych Redis zamiast po prostu uruchamiać dodatkową instancję Redis dla każdej dodatkowej bazy danych, którą chcę? I w związku z tym, dlaczego Redis nie próbuje wykorzystać dodatkowego rdzenia dla każdej dodatkowej bazy danych, którą dodam? Jaka jest zaleta bycia jednowątkowym między bazami danych?

Zasadniczo bazy danych Redis w tej samej instancji nie różnią się od schematów w instancjach baz danych RDBMS.

Biorąc to wszystko pod uwagę, dlaczego / kiedy miałbym kiedykolwiek chcieć używać wielu baz danych Redis zamiast po prostu uruchamiać dodatkową instancję Redis dla każdej dodatkowej bazy danych, którą chcę?

Istnieje jedna wyraźna zaleta korzystania z baz danych redis w tej samej instancji redis, a jest nią zarządzanie. Jeśli uruchomisz osobną instancję dla każdej aplikacji i załóżmy, że masz 3 aplikacje, to 3 oddzielne instancje redis, z których każda prawdopodobnie będzie potrzebować urządzenia podrzędnego dla HA w środowisku produkcyjnym, więc daje to łącznie 6 instancji. Z punktu widzenia zarządzania, robi się to bardzo szybko bałaganiarskie, ponieważ musisz monitorować je wszystkie, wykonywać aktualizacje / poprawki itp. Jeśli nie planujesz przeciążania redis wysokimi I / O, pojedyncza instancja z slave jest prostsza i łatwiejsze w zarządzaniu, pod warunkiem że spełnia warunki umowy SLA.

Nie chcesz używać wielu baz danych w jednej instancji Redis. Jest przestarzały i, jak zauważyłeś, wiele wystąpień pozwala korzystać z wielu rdzeni. Jeśli korzystasz z wyboru bazy danych, będziesz musiał dokonać refaktoryzacji podczas aktualizacji. Monitorowanie i zarządzanie wieloma instancjami nie jest trudne ani bolesne.

Rzeczywiście, uzyskasz znacznie lepsze wskaźniki dla każdej bazy danych poprzez segregację na podstawie instancji. Każdy przypadek miałby statystyki odzwierciedlające ten segment danych, co może pozwolić na lepsze dostrojenie oraz bardziej responsywne i dokładne monitorowanie. Użyj najnowszej wersji i oddziel dane według instancji.

Jak powiedział Jonaton, nie używaj polecenia keys. O wiele lepszą wydajność znajdziesz, jeśli po prostu utworzysz indeks klucza. Dodając klucz, dodaj nazwę klucza do zestawu. Polecenie keys nie jest zbyt przydatne po zwiększeniu skali, ponieważ powrót zajmie dużo czasu.

Pozwól, aby wzorzec dostępu określił, jak uporządkować dane, zamiast przechowywać je w sposób, w jaki myślisz, że działa, a następnie pracuj nad tym, jak uzyskać do nich dostęp i później. Zobaczysz znacznie lepszą wydajność, a kod zużywający dane często jest znacznie czystszy i prostszy.

Jeśli chodzi o pojedyncze wątki, weź pod uwagę, że redis jest zaprojektowany z myślą o szybkości i atomowości. Pewne akcje modyfikujące dane w jednej bazie danych nie muszą czekać na inną bazę danych, ale co, jeśli ta akcja polega na zapisaniu do pliku zrzutu lub przetwarzaniu transakcji na urządzeniach podrzędnych? W tym momencie zaczynasz wpadać w chwasty programowania współbieżności.

Używając wielu instancji, zmieniasz złożoność wielowątkowości w prostszy system stylu przekazywania wiadomości.

Nawet Salvatore Sanfilippo (twórca Redis) uważa, że ​​używanie wielu baz danych w Redis jest złym pomysłem. Zobacz jego komentarz tutaj:

https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion

Rozumiem, jak to może być przydatne, ale niestety uważam, że wiele błędów bazy danych Redis jest moją najgorszą decyzją w projektowaniu Redis ... bez żadnego realnego zysku, sprawia, że ​​wewnętrzne elementy są znacznie bardziej złożone. W rzeczywistości bazy danych nie skalują się dobrze z wielu powodów, takich jak aktywne wygaśnięcie kluczy i maszyn wirtualnych. Jeśli wybór bazy danych można przeprowadzić za pomocą ciągu znaków, widzę, że ta funkcja jest używana jako skalowalna warstwa słownika O (1), zamiast tego tak nie jest.

Dzięki numerom DB, z domyślną liczbą kilku DB, lepiej komunikujemy się, czym jest ta funkcja i jak myślę, jak można ją wykorzystać. Mam nadzieję, że w pewnym momencie uda nam się w ogóle zrezygnować z obsługi wielu baz danych, ale myślę, że jest prawdopodobnie za późno, ponieważ wiele osób polega na tej funkcji w swojej pracy.

1. Naprawdę nie znam żadnych korzyści z posiadania wielu baz danych w jednym wystąpieniu. Myślę, że jest to przydatne, jeśli wiele usług korzysta z tego samego serwera (ów) bazy danych, aby uniknąć kolizji kluczy.

2. Nie polecałbym budowania za pomocą KEYSpolecenia, ponieważ jest to O (n) i nie jest dobrze skalowane. Do czego go używasz, co możesz osiągnąć w inny sposób? Może redis nie jest dla Ciebie najlepszym rozwiązaniem, jeśli tak KEYSważna jest funkcjonalność .

3. Myślę, że wspominają o zaletach serwera jednowątkowego w swoich często zadawanych pytaniach, ale najważniejsza jest prostota - nie musisz się martwić o współbieżność w żaden rzeczywisty sposób. Każda akcja blokuje, więc żadne dwie rzeczy nie mogą zmienić bazy danych w tym samym czasie. Idealnie byłoby, gdybyś miał jedną (lub więcej) instancji na rdzeń każdego serwera i używał spójnego algorytmu mieszającego (lub serwera proxy) do dzielenia kluczy między nimi. Oczywiście stracisz część funkcjonalności - orurowanie będzie działać tylko dla rzeczy na tym samym serwerze, sortowanie stanie się trudniejsze itp.

Używam redis do implementacji czarnej listy adresów e-mail i mam różne wartości TTL dla różnych poziomów czarnej listy, więc posiadanie różnych baz danych w tej samej instancji bardzo mi pomaga.

Bazy danych Redis mogą być używane w rzadkich przypadkach wdrażania nowej wersji aplikacji, gdzie nowa wersja wymaga pracy z różnymi jednostkami.

Korzystanie z wielu baz danych w jednym wystąpieniu może być przydatne w następującym scenariuszu:

Różne kopie tej samej bazy danych mogą być używane do produkcji, programowania lub testowania przy użyciu danych w czasie rzeczywistym. Użytkownicy mogą używać repliki do klonowania instancji redis, aby osiągnąć ten sam cel. Jednak poprzednie podejście jest łatwiejsze dla istniejących uruchomionych programów, ponieważ wystarczy wybrać odpowiednią bazę danych, aby przełączyć się do zamierzonego trybu.

Wiem, że to pytanie ma lata, ale jest jeszcze jeden powód, dla którego wiele baz danych może być przydatnych.

Jeśli korzystasz z „chmury Redis” od swojego ulubionego dostawcy usług w chmurze, prawdopodobnie masz minimalną wielkość pamięci i zapłacisz za to, co przydzielisz. Jeśli jednak Twój zbiór danych jest mniejszy, zmarnujesz trochę alokacji, a tym samym stracisz trochę pieniędzy.

Korzystając z baz danych, możesz użyć tej samej instancji chmury Redis do świadczenia usług (powiedzmy) dla deweloperów, UAT i produkcji lub wielu wystąpień aplikacji lub czegokolwiek innego - w ten sposób wykorzystując więcej przydzielonej pamięci i przez to trochę drożej. efektywny.

Przypadek użycia, na który patrzę, ma kilka wystąpień aplikacji, które używają 200-300 KB, ale minimalna alokacja u mojego dostawcy chmury wynosi 1 MB. Możemy skonsolidować 10 instancji w pojedynczym Redisie bez rzeczywistego robienia żadnych ograniczeń, a więc zaoszczędzić około 90% kosztów hostingu Redis. Doceniam ograniczenia i problemy z tym podejściem, ale pomyślałem, że warto o tym wspomnieć.