AKTUALIZACE: níže uvedené platí pro verze Redis do 3.2. Od této verze replikace založená na efektech ruší zákaz nedeterminismu, takže všechny sázky jsou vypnuté (nebo spíše zapnuté).
Nemůžete (a neměli byste) kombinovat SCAN rodina příkazů s libovolným příkazem zápisu ve skriptu, protože odpověď prvního závisí na interních datových strukturách Redis, které jsou zase jedinečné pro proces serveru. Jinak řečeno, u dvou procesů Redis (např. master a slave) není zaručeno, že vrátí stejné odpovědi (takže v kontextu replikace Redis [který není založen na operaci, ale na příkazu] by to přerušilo).
Redis se proti takovým případům snaží chránit blokováním jakéhokoli příkazu zápisu (jako je DEL ), pokud je spuštěn po náhodném příkazu (např. SCAN ale také TIME , SRANDMEMBER a podobně). Jsem si jistý, že existují způsoby, jak to obejít, ale chtěli byste to udělat? Pamatujte, že půjdete do neznámého území, kde chování systému není definováno.
Místo toho se smiřte s tím, že byste neměli míchat náhodné čtení a zápisy, a zkuste vymyslet jiný přístup k řešení vašeho problému, totiž atomické smazání svazku klíčů podle vzoru.
Nejprve se zeptejte sami sebe, zda můžete zmírnit některý z požadavků. Musí to být atomové? Atomicita znamená, že Redis bude po dobu smazání (bez ohledu na konečnou implementaci) zablokován a že délka operace závisí na velikosti úlohy (tj. počtu klíčů, které jsou smazány, a jejich obsahu [smazání velké sady je dražší než například odstranění krátkého řetězce]).
Pokud atomicita není nutností, pravidelně/líně SCAN a mazat po malých dávkách. Pokud je to nutné, pochopte, že se v podstatě snažíte napodobit zlé KEYS příkaz :) Ale můžete to udělat lépe, pokud máte předchozí znalosti o vzoru.
Za předpokladu, že vzor je znám během běhu vaší aplikace, můžete shromáždit příslušné klíče (např. v sadě) a poté tuto sbírku použít k aktualizaci odstranění atomickým a replikačně bezpečným způsobem, který je efektivnější ve srovnání s přechodem přes celý klíčový prostor. .
Nejobtížnějším problémem však je, pokud potřebujete spouštět ad-hoc porovnávání vzorů při zajištění atomicity. Pokud ano, problém se scvrkává na získání snímku klíčového prostoru filtrovaného podle vzoru, po kterém bezprostředně následuje řada mazání (znovu zdůraznění:když je databáze blokována). V tom případě můžete velmi dobře použít KEYS ve vašem skriptu Lua a doufejte v to nejlepší... (ale dobře víte, že se můžete uchýlit k SHUTDOWN NOSAVE docela rychle :P).
Poslední optimalizací je indexování samotného klíčového prostoru. Oba SCAN a KEYS jsou v podstatě úplné skenování tabulky, takže co kdybychom tuto tabulku indexovali? Představte si udržování indexu názvů klíčů, které lze během transakce dotazovat – pravděpodobně můžete použít třídenou sadu a lexikografické rozsahy (HT @TwBert ), aby se odstranila většina potřeb porovnávání vzorů. Ale se značnými náklady... nejen že budete vést dvojité účetnictví (ukládat náklady na názvy jednotlivých klíčů v RAM a CPU), budete nuceni svou aplikaci zkomplikovat. Proč přidávat složitost? Protože k implementaci takového indexu byste jej museli sami udržovat v aplikační vrstvě (a možná i ve všech vašich ostatních skriptech Lua), přičemž každou operaci zápisu do Redis pečlivě zabalíte do transakce, která také aktualizuje index.
Za předpokladu, že jste to všechno udělali (a vezmeme-li v úvahu zřejmá úskalí, jako je přidaná složitost potenciálu pro chyby, alespoň zdvojnásobené zatížení zápisu na Redis, RAM a CPU, omezení škálování atd.), můžete se poplácat po ramenem a gratulujeme si, že používáte Redis způsobem, pro který nebyl navržen. Zatímco nadcházející verze Redis mohou (nebo nemusí) obsahovat lepší řešení pro tuto výzvu (@TwBert – chcete udělat společný RCP/příspěvek a znovu trochu hacknout Redis? ), než to vyzkoušíte, opravdu vás žádám, abyste přehodnotili původní požadavky a ověřili, že používáte Redis správně (tj. navrhněte své „schéma“ podle vašich potřeb v oblasti přístupu k datům).