Warden

Indexovani tabulek dle emailove komunikace z 30. 4. 2013. Vsechny nove indexovane sloupce v tabulkach by mely byt:

• tabulka clients
  • defaultne indexovan clients.id (prim klic)
  • zadne dalsi polozky pro indexaci

• tabulka events
  • detected
  • type
  • valid
  • events.client_id (asi bude lepsi jej nakonec zaindexovat)
    • novy sloupec cizich klicu z (clients.id)

pozn. sloupce hostname a service zmizi z tabulky events pri pridani cizich klicu

Ahoj vsem,
dnes jsem udelal testy na dotazy do databaze a navrhuji tyto indexy:

clients - zatim jen primarni klic, tabulka je mala, upravy lze delat pruzne kdykoliv
events

• detected
• (type, valid)

FYI:

MySQL totiz muze pouzit najednou jen jeden index, takze pokud bude vyraz sloupec1='neco' AND sloupec2='neco' AND sloupec3='', takze je nutny vicesloupcovy index (sloupec1, sloupec2, sloupec3).
Tento sloupec nasledne funguje pro hledani v kombinacich (sloupec1), (sloupec1,sloupec2) a (sloupec1, sloupec2, sloupec3).

Michal.

Jakub Čegan wrote:

Indexovani tabulek dle emailove komunikace z 30. 4. 2013. Vsechny nove indexovane sloupce v tabulkach by mely byt:

• tabulka clients

• defaultne indexovan clients.id (prim klic)
• zadne dalsi polozky pro indexaci

• tabulka events

• detected
• type
• valid
• events.client_id (asi bude lepsi jej nakonec zaindexovat)

• novy sloupec cizich klicu z (clients.id)

pozn. sloupce hostname a service zmizi z tabulky events pri pridani cizich klicu

Naše klíčové dotazy jsou:

SELECT * FROM events WHERE type != 'test' AND id > ? AND valid = 't' ORDER BY id ASC LIMIT ?;
SELECT * FROM events WHERE type != 'test' AND id > ? AND type = ? AND valid = 't' ORDER BY id ASC LIMIT ?;
SELECT * FROM events WHERE type != 'test' AND id > ? AND valid = 't' AND hostname NOT LIKE ? ORDER BY id ASC LIMIT ?;
SELECT * FROM events WHERE type != 'test' AND id > ? AND type = ? AND valid = 't' AND hostname NOT LIKE ? ORDER BY id ASC LIMIT ?;

• (type, valid)
  • naše dotazy se ptají na (type, id, valid), (type, id, type, valid). Variaci s hostname nepočítám, je 'like "%asdf"', takže neindexovatelné. Neměl by tedy index být (type, id, valid)? A nepomohlo by porovnat pořadí v dotazu na (type, type, id, valid)?

Jakému dotazu pomůže detected, to jsi myslel pro wardenWatchdog?

Pavel Kácha wrote:

• naše dotazy se ptají na (type, id, valid), (type, id, type, valid). Variaci s hostname nepočítám, je 'like "%asdf"', takže neindexovatelné. Neměl by tedy index být (type, id, valid)? A nepomohlo by porovnat pořadí v dotazu na (type, type, id, valid)?

Myslim, ze 'query optimizer' to spravne poresi, takze to nema na fukci vliv.

Jakému dotazu pomůže detected, to jsi myslel pro wardenWatchdog?

Zaradil jsem ho tam jen z principu, podle me se nam muze/bude hodit. Lepsi ted, nez nad celou datazi.

Takže, po diskusích jsem pro variantu

• events.(type, valid) (základní dotazy)
• events.client_id (pro wardenWatchdog)
• events.detected (měli bychom se pustit do odlévání dat, tam se nejspíš bude hodit)

Námitky?

Pavel Kácha wrote:

Takže, po diskusích jsem pro variantu

• events.(type, valid) (základní dotazy)
• events.client_id (pro wardenWatchdog)
• events.detected (měli bychom se pustit do odlévání dat, tam se nejspíš bude hodit)

Námitky?

OK, nemam s tim problem, tudiz zadne namitky. Spis mne zajima, zdali stale plati, ze defaultne se tabulka po instalaci/updatu serveru neindexuje automatizovane, pouze je v README v dane sekci doporuceno ktere sloupce tabulek (v nasem pripade tabulky 'events') se vyplati spravci zaindexovat a jak.

Rekapitulace upgradu:

1. alter table clients (rychlé)
2. alter table events (pomalé)
3. update events (pomalé)
4. alter table events (pomalé)
5. create index (pomalé)

Tj. máme potenciálně dlouhotrvajících věcí hodně, nejen indexy. Ok, navrhuju to udělat tak, že upgradeskript bude jeden, do README bych dal do upgrade poznámku, že spuštění upgradovacího skriptu může trvat dlouho a je záhodno se podívat co dělá a naplánovat zálohy/výpadky, a sami si reálně stejně upgrade uděláme po svém. Co vy na to?

OK, nemam s tim problem, tudiz zadne namitky. Spis mne zajima, zdali stale plati, ze defaultne se tabulka po instalaci/updatu serveru neindexuje automatizovane, pouze je v README v dane sekci doporuceno ktere sloupce tabulek (v nasem pripade tabulky 'events') se vyplati spravci zaindexovat a jak.

Spravci se vyplati indexovat vzdy, proto bych dal indexy do zakladu.

Michal Kostěnec wrote:

OK, nemam s tim problem, tudiz zadne namitky. Spis mne zajima, zdali stale plati, ze defaultne se tabulka po instalaci/updatu serveru neindexuje automatizovane, pouze je v README v dane sekci doporuceno ktere sloupce tabulek (v nasem pripade tabulky 'events') se vyplati spravci zaindexovat a jak.

Spravci se vyplati indexovat vzdy, proto bych dal indexy do zakladu.

OK, podle konvenci pro vytvareni indexu v MySQL by to melo tedy vypadat nasledovne, viz revize 7fb15946. Udelat to stejne i pro upgradovaci mysql skript warden21to22.patch (tzn. doplnit tam ALTER TABLE, ktere zajisti doplneni chybejicich indexu po upgradu databaze)? Nebo nam jde ciste jen o vytvoreni indexu na prazdne inicialni databazi? Kdy jsme to do toho skriptu nejak blbe doplnil, tak mne prosim opravte.

Pavel Kácha wrote:

Takže, po diskusích jsem pro variantu

• events.(type, valid) (základní dotazy)
• events.client_id (pro wardenWatchdog)
• events.detected (měli bychom se pustit do odlévání dat, tam se nejspíš bude hodit)

Námitky?

Kdyz uz jsme tak nakousli to odlevani dat. Budeme odlevat ve smyslu mazani, nebo pouze presunu zaznamu do nejake jine databaze? Bude to delat server sam podle nastaveni v configu nebo to budeme delat rucne? A dale pak jeste otazka zdali tuto funkcionalitu budeme mit jiz ve v2.3 (pokud bude) nebo az ve v3.0?

OK, podle konvenci pro vytvareni indexu v MySQL by to melo tedy vypadat nasledovne, viz revize 7fb15946.

Tohle určitě není dobře:

KEY `idx_events_type` (`type`),
KEY `idx_events_valid` (`valid`),

Viz Kostějův rozbor.

Udelat to stejne i pro upgradovaci mysql skript warden21to22.patch (tzn. doplnit tam ALTER TABLE, ktere zajisti doplneni chybejicich indexu po upgradu databaze)? Nebo nam jde ciste jen o vytvoreni indexu na prazdne inicialni databazi? Kdy jsme to do toho skriptu nejak blbe doplnil, tak mne prosim opravte.

Viz můj komentář 7.

Pavel Kácha wrote:

OK, podle konvenci pro vytvareni indexu v MySQL by to melo tedy vypadat nasledovne, viz revize 7fb15946.

Tohle určitě není dobře:

KEY `idx_events_type` (`type`),
KEY `idx_events_valid` (`valid`),

Viz Kostějův rozbor.

Muj zadrhel, pardon. Z nejakeho duvodu jsem si vcera chybne vylozil tvuj zapis type a valid v zavorce:

events.(type, valid) (základní dotazy)

a mel jsem za to, ze znamena vycet a ne dvojici. Chyba by mela byt opravena v revizi fafd3595.

Udelat to stejne i pro upgradovaci mysql skript warden21to22.patch (tzn. doplnit tam ALTER TABLE, ktere zajisti doplneni chybejicich indexu po upgradu databaze)? Nebo nam jde ciste jen o vytvoreni indexu na prazdne inicialni databazi? Kdy jsme to do toho skriptu nejak blbe doplnil, tak mne prosim opravte.

Viz můj komentář 7.

Su hlope, takze nevim jestli si komentar 7 spravne vylozim... Chapu to ale tak, ze ano - indexaci doplnit i do warden21to22.patch, akorat do REEADME sekce Upgrade explicitne napsat, ze to muze trvat dlouho, ma se podivat co to udela a peclive si naplanovat vypadky. Je tak?

Lepší.

Jo, to je můj návrh, pokud nejsi proti.

Pavel Kácha wrote:

Lepší.

OK.

Jo, to je můj návrh, pokud nejsi proti.

Nejsem vubec proti. Zaindexovani jsem pridal do patche a pridal poznamku do UPDATE file, viz revize 30c2efa7.