PszemoPL | 2020-11-12 14:13:40 UTC | #1
Witam mam pytanie skończyłem pisać plugin na Gildie pod MySQL ale mam możliwość pisania pluginów pod redisa i szukam rozwiązania na taki problem próbuje zrobić coś takiego:
select FROM table WHERE guildName = this.tag
ale w redisie szukałem na różnych forach jak zrobić ale nie widziałem rozwiązania
Nieznajomy11 | 2020-11-12 14:39:01 UTC | #2
Redis nie jest bazą relacyjną, więc nie ma tutaj takich zapytań, to jest key-value. Nie powinno się go aplikować, do wszystkiego jak leci, tylko dlatego, że “fajnie by było” lub z innych podobnych zachcianek. Powinna być to przemyślana decyzja.
Podczas gdy noSQL bez problemu można zaaplikować do tego zastosowania (z odpowiednią wiedzą), bazy relacyjne to nadal dobre, a być może nawet lepsze rozwiązanie na tego typu rzeczy (większa dostępność i powszechność MySQL).
Bez świadomości projektowej i doświadczenia z bazami noSQL przy tego typu rzeczach można łatwo zrobić więcej złego niż dobrego i uzyskać gorszą wydajność oraz cięższy do rozwijania projekt.
Realnie prawdopodobnie chciałbyś stworzyć oddzielne klucze na każdego gracza oraz na każdą gildię i w kluczu zawrzeć odpowiedni dla ciebie identyfikator.
Chciałbym też od razu zauważyć, że redis nie gwarantuje zapisu danych na dysku, robi to tylko cyklicznie. Jeśli wydarzy się taka sytuacja, że baza padnie w losowym momencie, zostanie utracona część danych. Problem ten nie występuje z MySQL korzystającym z modelu ACID.
PszemoPL | 2020-11-12 14:46:33 UTC | #3
Wiem że ta baza nie ma takich zapytań dlatego się pytam czy może ktoś wie jak zrobić takie zapytanie ale właśnie dla bazy Redis
Nieznajomy11 | 2020-11-12 14:47:25 UTC | #4
[quote=”PszemoPL, post:3, topic:16695”]
nie ma takich zapytań
[/quote]
[quote=”PszemoPL, post:3, topic:16695”]
takie zapytanie ale właśnie dla bazy Redis
[/quote]
Tak jak sam mówisz: nie ma takich zapytań. Odpowiedź jak to się robi wynika z faktu tego jak działa noSQL i jest zawarta w poprzednim poście:
[quote=”Nieznajomy11, post:2, topic:16695”]
Realnie prawdopodobnie chciałbyś stworzyć oddzielne klucze na każdego gracza oraz na każdą gildię i w kluczu zawrzeć odpowiedni dla ciebie identyfikator.
[/quote]
PszemoPL | 2020-11-12 15:04:05 UTC | #5
Dobrze dziękuje bardzo za pomoc
Szymonjjay | 2020-11-13 12:17:16 UTC | #6
Chciałbym też od razu zauważyć, że redis nie gwarantuje zapisu danych na dysku, robi to tylko cyklicznie. Jeśli wydarzy się taka sytuacja, że baza padnie w losowym momencie, zostanie utracona część danych. Problem ten nie występuje z MySQL korzystającym z modelu ACID.
Może włączyć tryb “APPEND ONLY MODE”, który po każdej zmianie wartości klucza zapisuje jego zmianę do pliku i jak to redis ujmuje w pliku konfiguracyjnym:
Redis can lose just one second of writes in a
dramatic event like a server power outage, or a single write if something
wrong with the Redis process itself happens
Jeżeli chcesz wykonywać “zapytania” do redisa potrzebna ci będzie jakaś biblioteka np. Jedis, w którym zmiana klucza wywoływana jest metodą .set(key, value) a wzięcie wartości z klucza metodą .get(key)
Nieznajomy11 | 2020-11-13 14:03:49 UTC | #7
[quote=”Szymonjjay, post:6, topic:16695”]
Może włączyć tryb “APPEND ONLY MODE”, który po każdej zmianie wartości klucza zapisuje jego zmianę do pliku i jak to redis ujmuje w pliku konfiguracyjnym:
[/quote]
Móc można, ale trzeba pamiętać o częściowej utracie wydajności. Podczas gdy przy domyślnym appendfsync everysec, które w teorii opisujesz, jest to nie tak wiele, przy bliższym modelowi ACID ustawieniu, tj. appendfsync always, które faktycznie masz na myśli, tracimy znaczną część wydajności poleceń zmieniających dane, np. SET. Uzyskamy wtedy nawet tak mało jak zaledwie kilka, może kilkanaście procent wcześniejszej wydajności, zależnie od używanego dysku (o zgrozo co by było na HDD).
Trzeba mieć to na uwadze, bo tracimy wtedy część zalet tego magicznego redisa, za którymi tak bardzo niektórzy gonią, tj. szybkość. Zwyczajnie MySQL do pewnych zadań jest lepszym wyborem, a dokręcanie śruby redisowi niekoniecznie zawsze ma sens.
Postanowiłem przetestować swoją teorię:
# redis-server
$ redis-benchmark -t set,lpush -n 1000000 -q
SET: 130975.77 requests per second
LPUSH: 128221.57 requests per second
# redis-server --appendonly yes
$ redis-benchmark -t set,lpush -n 1000000 -q
SET: 124610.60 requests per second
LPUSH: 119388.73 requests per second
# redis-server --appendonly yes --appendfsync always
$ redis-benchmark -t set,lpush -n 1000000 -q
SET: 9713.45 requests per second
LPUSH: 9739.00 requests per second
Zaznaczam od razu, że są to testy wykonane na całkiem przyzwoitym sprzęcie:
Podczas gdy jest duża szansa, że mimo polityki appendfsync always redis nadal będzie wystarczająco szybki, jego wpływ na obciążenie serwera wzrośnie znacznie, jeśli porównywać do domyślnych ustawień (zapisów cyklicznych), co może być sprzeczne dla części osób z ich wizją zastosowania tej bazy.
system | 2020-12-15 13:19:45 UTC | #8
Ten temat został automatycznie zamknięty 32 dni po ostatnim wpisie. Tworzenie nowych odpowiedzi nie jest już możliwe.