Érdemes-e indexelni egy TimeStamp MySQL oszlopot, ha az az egyetlen oszlop?
Egy számlálón dolgozom, ami bizonyos eseményeket (forgalomszámlálás) számlál, a kritériumok (személyautó, teherautó stb.) és a versengés is kezeltek.
Az eseményeket (elhalad az autó) rögzítem a táblákba a kritériumok (személyautó, teherautó stb.) szerint, az egyetlen oszlop TimeStamp típusú, és ide kerül bele az esemény ideje. Később bármilyen időintervallumra tudnom kell szűrni, ezért nem használhatok sima számlálót.
Most épp töltöm fel az adatbázist néhány millió random tesztadattal, de nem tudom, hogy mi lenne a teljesítmény szempontjából a legjobb. Ha indexelném az oszlopot, vagy ha nem? Még talán sosem csináltam ilyet, de nem használok elsődleges kulcsot, mert jelen esetben nem látom semmi értelmét. Jól látom, ha nem látom?
Persze, ki fogom próbálni így is, meg úgy is, de lehet, hogy van az egésznek valami elméleti háttere, ami elkerüli a figyelmemet?
válasza:> Érdemes-e indexelni egy TimeStamp MySQL oszlopot, ha az az egyetlen oszlop?
Az az egyetlen oszlop? Akkor már a táblának sincs a világon semmi értelme, nem hogy még indexelgetni azt az árva oszlopot. :)
Ha eltekintek az "az az egyetlen oszlop" kifejezéstől a szövegedben, kihámozom, hogy van még legalább 2 oszlopod:
> Az eseményeket (elhalad az autó) rögzítem a táblákba a kritériumok (személyautó, teherautó stb.) szerint
> Ha indexelném az oszlopot, vagy ha nem? Még talán sosem csináltam ilyet, de nem használok elsődleges kulcsot
Azt kéne eldönteni, hogyan fogod használni később a táblát. Mi alapján fogsz benne keresni? Hogyan fogod azonosítani a rekordokat (pl. szerkesztéshez), ha nincs ID? Vagy nem akarsz vele semmit csinálni, csak belehányod az adatokat (akár redundánsan is), később meg csak egyben kilistázod valahol? Akkor meg egyáltalán minek az adatbázis, egy sima log fájl is pontosan ezt tudja.
A sémát is leírhatnád esetleg, hogy egyértelmű dolgokról tudjunk értekezni.
A kérdésektől függetlenül egyébként az adatok betöltése nyilván index nélkül lesz gyorsabb (akár betöltés előtt törölhető, aztán visszarakható). A betöltés módszerének a bulk INSERT az ajánlás általában, de még jobban jársz ha LOAD DATA-val töltöd be, az nagyságrendeket javít a betöltési időn.
Köszi a gyors és segítő választ, és az iránymutatást!
Nem vagyok benne teljesen biztos, hogy jól ragadtam meg a probléma lényegét, pláne az ismertetését. :)
Szóval a lényeg, hogy nincs szükségem másra, csak az időpontra, hogy az adott esemény (jármű elhaladása) mikor következett be. A különböző fajtájú eseményeket (személygépkocsi, tehergépkocsi) külön-külön táblában tárolom, azonos struktúrával, azaz egyetlen TimeStamp mezővel. Lehetne egybe is, és akkor egy táblában több mező lenne, de nem hinném, hogy ez lényegét tekintve változtatna a problémámon.
Nincs semmi szükségem arra, hogy a rekordokat később módosítsam, valójában még listázásukra sincs szükség. Ami kell, hogy egy SQL lekérdezésben /kb. SELECT COUNT(*) FROM Table WHERE (Table.TimeStamp>=x) AND (Table.TimeStamp<=y)/ megszámolhassam, hogy az adott időintervallumban hány esemény történt. És az időintervallum az, ami szabadon választható: 1 perc, 1 óra, 1 nap, 1 hét, 1 hónap, 1 év stb. és persze ezek ésszerű kombinációi. :)
A feltöltést - valamelyik adatbázistábla írását - egy esemény (elhaladó jármű) váltja ki, ezt egy sima INSERT-tel oldom meg, beszúrja a tábla végére a rekordot. Ez a séma, pofon egyszerű, a sebessége több, mint kielégítő, persze index használata nélkül.
Valójában azért kell adatbázis, mert több lekérdező (_csak_és_kizárólag_ lekérdező) kliens egyidejű kiszolgálása az igény, ezt pedig nem - vagyis sokkal nehezebben - tudom megoldani egy log fájllal. :)
válasza:Hálás köszönet neked is, #3-as!
Az egyetlen, amire szükségem van - ahogyan az eredeti kérdésben is írtam - "hogy mi lenne a teljesítmény szempontjából a legjobb".
Azóta már végeztem teszteket, nagyon meglepő eredmények születtek!
A SELECT COUNT(*) FROM Table WHERE (Table.TimeStamp>=x) AND (Table.TimeStamp<=y) lekérdezést a 2 db 1.000.000+ soros táblán cache nélkül sokszor (egy kis programkódhiba miatt 144-szer 12-szer helyett, de így szerencsére jobban is kijött a különbség), eltérő paraméterekkel az alábbi időeredmények születtek:
Nincs index és nincs primary key: 3 perc 24 másodperc
Van index, de nincs primary key: 20 másodperc
Van index és van primary key: 14 másodperc
Tehát az eddigi tesztjeim szerint jót tesz a lekérdezésnek, ha van index és van elsődleges kulcs, ez mintegy 14.5x-es sebességnövekedést eredményezhet.
A hibás programkód korrigálásával a 14 másodperc kb. 1 másodpercre csökkent.
Lehet-e valamilyen módon tovább javítani a lekérdezés sebességét?
Szerencsére az index és az elsődleges kulcs az új rekord beszúrásának sebességét nem rontotta le számottevően, kb. 550-600/sec a jelenlegi felviteli sebesség, ami bőven elfogadható.
Kapcsolódó kérdések:
Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!