Bug #544
closedServer: klientovi se neaktualizuje ID pokud v DB jeste neni ulozen jeho pozadovany type
Added by Tomáš Plesník about 12 years ago. Updated about 10 years ago.
0%
Description
Pokud si klient vyzada nejaky typ, ktery jeste neni ulozen v DB serveru, tak dany SELECT nic nevrati, klientovi se neposlou zadna data a ID mu zustane na puvodni hodnote. Server pak pri dalsim dotazu klienta musi znovu prochazet jiz jednou projita data i kdyz uz jednou zjistil, ze v nich nic neni.
Updated by Tomáš Plesník about 12 years ago
Tady jsme se Sukim vymysleli reseni v podobe vytvoreni provozni tabulky events.stats:
CREATE TABLE events.stats ( type varchar, id int )
K updatu tabulky by dochazelo pri prijeti udalosti. Slet udalosti by byl pak nasledujici:
1. klient by si napriklad zazadal o udalosti typu 'portscan'2. server by se prvne podival do tabulky events.stats, zjistil by, ze udalost typu portscan nikdo jeste neposlal a tudiz se v DB nenachazi
3. server by odeslal prazdnou odpoved (nemusi prochazet celou databazi aby se dozvedel, ze tam nic pro klienta nema)
4. prisla by nova udalost typu 'portscan' => update tabulky events.stats
5. klient by si po druhe zazadal opet o udalosti typu 'portscan'
6. server by se podival do tabulky events.stats, zjistil by, ze udalost tohoto typu uz v DB je, spustil by select na DB a vratil dane udalosti, klient by udalosti prijal a ulozil si ID posledni z nich
7. klient by si po treti zazadal opet o udalosti typu 'portscan'
8. server by se opet podival do tabulky events.stats, zjistil by, zdali je ID posledni prichozi udalosti typu 'portscan' vetsi nez LAST_ID od klienta
- pokud ano, tak by spustil select od LAST_ID klienta
- pokud ne, tak by vratil prazdnou odpoved
Timto zpusobem bychom se zbavili zbytecnych selectu do DB i v pripade, ze se udalosti daneho typu v DB vubec nevyskytuji.
Updated by Pavel Kácha about 12 years ago
Myslím, že tu trochu mícháme dvě věci:
- klientovi se nezmění ID, protože nedostal žádnou zprávu
- server "prochází" databázi
První - problém vidím jen v tom, že se klient nedozví, zda došlo k chybě nebo žádné nové zprávy toho typu nejsou. To už se současným klientem nevyřešíme, museli bychom změnit API. V novém musíme hlášení chyb rozumně zohlednit.
Druhý - to, co navrhujete, je vlastně varianta "indexu" pro specifický dotaz, s výhodami i nevýhodami indexování - tj. zvýhodníte "dotaz na událost, která ještě v databázi není", který je poměrně specifický a předpokládám řídky, na úkor "ostatních dotazů", které budou muset statistickou tabuli číst a updatovat, a kterých je většina. Dle mého stačí na sloupec typů událostí nasadit standardní databázový index a server by měl mít odpověď okamžitě.
Nebo chápu problém špatně?
Updated by Pavel Kácha about 12 years ago
- Priority changed from Normal to Low
Otestoval jsem si několik dotazů s existujícími i neexistujícími typy a výsledky dávají okamžitě. Nahoďte tedy nějaký konkrétní příklad, kdy dotaz na typ, který v db není, dělá výkonový problém. Nejošklivější varianta dotazu je:
SELECT * FROM events WHERE type != 'test' AND id > ? AND type = ? AND valid = 't' AND hostname NOT LIKE ? ORDER BY id ASC LIMIT ?;
První klauzule where je na id (což je primární klíč s indexem), čímž se výrazně
omezí počet položek k procházení v ostatních klauzulích where. Pro velké dotazy (třeba od id 0) se zase obvykle omezí LIMITem. Pokud by nám začal padat výkon, máme prostor k optimalizacím:
- index na 'type' (rychlé zjištění, že typ neexistuje)
- zrušení 'valid' a přesypávání nevalidních zpráv jinam
- přepracování vyřazení vlastních zpráv - like '%.doména' je zvrhlost, s % na začátku se dostáváme na lineární procházení, které nejde nijak indexovat
Updated by Pavel Kácha almost 12 years ago
- Target version changed from 2.1 to Future
Updated by Tomáš Plesník almost 12 years ago
- Subject changed from warden-server-2.1: klientovi se neaktualizuje ID pokud v DB jeste neni ulozen jeho pozadovany type to Server: klientovi se neaktualizuje ID pokud v DB jeste neni ulozen jeho pozadovany type
Updated by Tomáš Plesník about 10 years ago
- Priority changed from Low to High
Bude vyreseno jeste do stavajiciho releasu.
Updated by Tomáš Plesník about 10 years ago
- Status changed from New to Closed
Problem jsem overil a potrebny kus kodu do serveru dodelal, nicmene ale jelikoz starsi klienti (2.0 a 2.1) nejsou na tuto zmenu pripraveni, rozhodl jsem se tuto upravu do serveru verze 2.2 nedavat, jelikoz bychom zpusobili nemale problemy vsem prijimacim klientum verze <= 2.1. Tato uprava by jim totiz vyskakovala jako nova udalost s jedinou polozkou ID a vsemi ostatnimi nastavenymi jako undef, na coz nejsou pripraveni a vyhazovali by chybove hlasky.
Ticket tedy uzaviram.