To je iz 2006. godine, vrlo bajato.
Takođe, to im je bio problem u prelasku sa mediumint na unsigned int a ne na bigint.
Bigint je 2^64 iliti 18446744073709551615

Promašio si ponetu,
ako je (dovoljno) popularnom slešdotu dovoljan običan int, zašto se neki plaše da njima neće biti pa koriste bigint za autoincrement?
A vrlo verovatno bi im i mediumint odradio posao.

Naravno postoje extremni slučajevi gde baš treba bigint ali vrrrlo retko.

ima mnoooooooooooogo slucajeva gde treba bigint ... posebno za myisam .. recimo da logujes traffic sa rutera za firmu od 500 racunara ... imas svake sekunde 500 puta po insert .. dakle za dan imas 43200000 slogova dakle za 100 dana stizes 4bajtni limit int-a... to sto ces ti povremeno da pobijes starije od mesec ili 2 nema veze, tebi id non stop raste ..

no u svakom slucaju, pravilno dimenzionisanje ce vrlo da pomogne....

Interesantna tema, i ranije sam hteo da pitam za ovako nesto, pa je ovo mozda malo skretanje sa teme.
Ja sam napravio logger koji sa PLC uredjaja uzima svake 2 sekunde stotinak i kusur decimalnih vrednosti, tako da sam morao da koristim tip bigint. Indeksirano polje je i vreme akvizicije koje je tipa datetime. Doduse, da bih malo ustedeo svaka vrednost ima prag tolerancije do 10% od prethodno logovane vrednosti. I sve je to ok, jer je za takav sistem da nije neophodna velika preciznost (gledaju se minimalne, maksimalne i prosecne vrednosti za neki period koji je najmanje sat vremena pa sekunde ne igraju ulogu).

Ali, my spider sense is tingling Nisam provalio kako to rade 'veliki sistemi' da bi se smanjila kolicina podataka, ali ipak zadrzala preciznost. Pretpostavljam da bi se to moglo uraditi lineranom interpolacijom, ali me brine taj overhead oko racunanja, pride da moze klijent da trazi podatke koji su jos u kesu i nisu upisani u bazu.

Na primer InSQL (ili po novom Historian) korisi kao backend fajlove i MS SQL, ali ima provider u MS SQL-u koji ih spaja. Trenutne podatke smesta u fajl, i kada ih skupi dovoljno upise ih u bazu.

ima mnooooooogo razlicitih nacina da se to odradi ... generalno koristi se uvek neki RRD tip sistema (pogledaj http://oss.oetiker.ch/rrdtool/index.en.html ) ... za mysql ima RRD storage engine koji je idealan za tako nesto (da me ubijes nemerem naci gde je ali ako se dobro secam nije ni dzaba ni opensource) ...

imas ovde primer kako da implementiras rrd sa trigerima u mysql-u .. nisam zagledao ali moguce da mu fali presipanje iz jednog u drugi rrd sistem (iz minuta u sate, iz sata u dane, iz dana u nedelje ...): http://www.shinguz.ch/MySQL/rrd.pdf

Ja koristim RRDTool (http://oss.oetiker.ch/rrdtool/index.en.html) za logovanje signala (sa CPE opreme) i generisanje grafikona ... Strašna stvar...

rrdtool je majka ... nemerem naci .. bio je RRD storage engine za mysql .. znam da smo ga testirali pre jedno godinu dana, al nemam vise link :(

Ok je RRDTool, sem sto ja pricam o skladistenju podataka bez round robin-a Nije poenta smanjiti velicu baze tako sto ce se stariji podaci prepisivati, vec smanjiti velicinu baze tako sto ce se upisivati manje podataka, a ipak zadrzati velika preciznost reda 100ms. Drugo mislim da je veliku 'udar' na bazu i ceo server (koji nije dedicated) ako se u toku par stotina milisekundi upisuje nekoliko hiljada vrednosti.

Postoje komercijalna resenja (kao sto sam naveo Wonderware Historian u sprezi sa ActiveFactory), ali ono sto me interesuje kako ti sistemi radi.

ja odvedoh pricu na rrd sorry ...

za ove koji mogu da stuku cudo i karate ... sve se svodi na IO, IO, IO i IO ..

Hmmm, nisam te bas razumeo?

ma pusti budalu .. opet sam se ukocio pa su me stavili na neke fine lekice .. .nemam pojma sta pricam ..

ono sto je za svaku bazu usko grlo je IO .. (input output) .. i to uglavnom disk io posto je te sve podatke bitno spucati nekako na disk .. svi ti sistemi koji izdrzavaju cuda i karate inserta u piko sekundi realno koriste razne fore da bi ili fizicki povecali broj io operacija u jedinici vremena (uglavnom tako sto particionisu data na vise fizickih spindlova ili podrzavaju samoi "in memory" tabele ili .. ) ili transformisu podatke tako da se isti volumen podataka moze stuci u menje io operacija (obicno na ustrb memorije i procesora)