Project

General

Profile

Actions
Copy link

Bug #544

closed

Server: 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.

Status:
Closed
Priority:
High
Assignee:
Tomáš Plesník
Category:
-
Target version:
Future
Start date:
09/07/2012
Due date:
% Done:

0%

Estimated time:

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.

Actions
Copy link
 #1

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.

Actions
Copy link
 #2

Updated by Pavel Kácha about 12 years ago

Myslím, že tu trochu mícháme dvě věci:

  1. klientovi se nezmění ID, protože nedostal žádnou zprávu
  2. 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ě?

Actions
Copy link
 #3

Updated by Pavel Kácha almost 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
Actions
Copy link
 #4

Updated by Pavel Kácha almost 12 years ago

  • Target version changed from 2.1 to Future
Actions
Copy link
 #5

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
Actions
Copy link
 #6

Updated by Tomáš Plesník about 10 years ago

  • Priority changed from Low to High

Bude vyreseno jeste do stavajiciho releasu.

Actions
Copy link
 #7

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.

Actions
Copy link

Also available in: Atom PDF