AnotherUser

Nevaig tikai šīs dienas, bet šīs dienas ir aktuālākie.

Respektīvi, no MySQL (datu glabātuves) ik pa laikam atlasīt datus un jau sakārtotā veidā pieglabāt kāda NoSQL db, no kuras tālāk atrādīt lietotājam?

Thanx ;) Mhhm.., bet ir tomēr gļuks, pamēģini ieliec vēl vienu ierakstu ar 14 datumu, kura cId būs arī 15. datumā, velkam ārā par 15. datumu viss pareizi -1 no iepriekšējā rezultāta, bet paskatoties 14. datumu jābūt 1 unikālajam, a mums 0 :/ WHERE dt != '2013-12-15' Ir problēma

Jā, tur ir viena diena un principā vienas stundas intervālā, tapēc arī ir 99% unikālie, bet man arī ar šādiem datiem ir ~400ms. "Momentā" tas ir cik? Tu uz Percona, vai mysql testē? Un kāds dzelzis?

Ok, skaidrs, paldies.

PHP pusē, nekas nemainās, respektīvi es ar to pašu PDO varu slēgties klāt, ja? Un db/tabulas/dati, kas bija mysql, jāpārmigrē, vai viss paliks?

Paldies, būs ko gremot. http://failiem.lv/u/agdqhtw?k=57fd6f0c Ar JOIN tomēr nevar to realizēt.. tapēc SQL uz doto brīdi ir SELECT COUNT(DISTINCT `cId`) as uniqs FROM `thread_stats` as ts WHERE ts.tId = 1 AND (SELECT DATE(ts2.`date_hour`) FROM `thread_stats` as ts2 WHERE ts.cId = ts2.cId LIMIT 1 ) = '2013-12-15' AND DATE(ts.`date_hour`) = '2013-12-15' ~450ms

Sveiki! Ir kādam pieredze ar migrēšanu no MySQL uz Percona server + XtraDB engine? Kādi klupšanas akmeņi? Cik % tas pozitīvi ietekmē veiktspēju salīdzinājumā ar mysql?

Starp citu manu sākotnējo sql no subquery pārtaisot par JOIN variantu, izpildās uz 1/2 ātrāk, takā tas pagaidām ir ejošākais variants. 1. Atkrīt jo tad pie ierakstīšanas man būs jātaisa selects, ko es nevaru atļauties mega lielā traffika dēļ. 2. Atkrīt jo statistika nepieciešama in live. 3. Tas atrisinās iepriekšējo dienu statistikas ielādi, bet aktuāli ir šodien un tulīt. 4. Var lūdzu šo nedaudz detalizētāk, scala/akka/distributētu actor-us/... ? Paldies.

Jā pa lielam problēma ir ātrdarbībā. Dotā tabula ir piemērs un mans sql ir viens no ntajiem subselectiem, tapēc indexi ir salikti optimāli pret visiem sql, kas izpildās šajā tabulā. Ja citi sql izpildās ~125ms tad, šis ~450ms. Pamēģināju variantu bez DATE() funkcijas, pāatrinājās par 50ms, kas arī nav gluži variants.. Uz doto brīdi tabulā ir ~45K ierakstu, kas ir gandrīz nekas salīdzinājumā ar to apjomu, kas tur gāzīsies iekšā..

Var! SELECT COUNT(DISTINCT `uId`) as uniq FROM `table` as ts WHERE ts.`uId` NOT IN (SELECT ts2.`uId` FROM `table` as ts2 WHERE ts2.`date_hour` != ts.`date_hour`) AND DATE(ts.`date_hour`) = '2013-12-15' Respektīvi kad man tabulā būs 1M ierakstu, iekš NOT IN (būs 1M id'u..), Neder.. Nu kur ir mūsu LV, DB Gurū..?

Briedi, ņemot tavu domu gājienu par pamatu, manā situācijā tas izskatās sekojoši: SELECT SUM(dd.`uniq`) as uniq FROM (SELECT COUNT(d.`date_hour`) as uniq FROM (SELECT `date_hour` FROM `table` WHERE DATE(`date_hour`) = :date GROUP BY `uId`) AS d GROUP BY d.`date_hour`) as dd ..Izpildās 1/3 ilgāk.. Vēl varianti?

Šādi tu dabūsi unikalos tikai tā datuma ietvaros, bet tāds `uId` varbūt jau ir bijis vakar vai gadu atpakaļ ierakstījies..

1. Ja tu domāji ar substr izvilkt 'gads-mēnesis-diena', tad jāsāk no 1. pozīcijas. 2. Prikškam izmantot substr + date() ? Dubults neplīst? 3. Dotajs piemērs atlasīs vairākus ierakstus (tik cik unikālie datumi), jo tiek grupēts pēc datuma un noteikti ne-unikālos `uId` 4. Mēģināšu vēlreiz izskaidrot: Tātad nepieciešams saskaitīt unikālos `uId` - tā lai rezultātā man atgriež vienu ierakstu (par konkrēto datumu, kuru es pieprasu) ar skaitu cik unikalie, tajā datumā iekrita. Unikalais - unikāls `uId` pa visu tabulu(visām dienam), respektīvi ja tabulā eksistē ieraksts ar `uId` - 101, tad tas ir viens unikals ieraksts un citās dienās/mēnešos/gados, mēs viņu vairs neuzskatam par unikalu. Mans piemērs darbojas no loģiskā viedokļa perfekti, bet neapmierina pats tehniskais izpildījums/ātrdarbība, šķiet jābūt kādam elegantākam risinājumam.

Uz linuxa, bez grafikiem, ātrais risinājums 'mytop'