När jag hade ett liknande problem slutade jag använda tempabord av olika orsaker, men det gjorde det mycket lättare. Vad jag gjorde ser väldigt ut som vad du gör, så långt som schemat går. Gör schemat något som ID-identitet, startdatum, slutdatum, värde. När du väljer gör du en underval avg av de föregående 20 baserat på identitets-ID. Gör bara det här om du tycker att du redan använder temp-tabeller av andra skäl (jag slog samma rader om och om igen för olika mätvärden, så det var till hjälp att ha den lilla datasatsen). Enligt min erfarenhet tenderar Mysql från 5.5.x att inte använda index på beroende val, vare sig en underfråga eller gå med. Detta kan ha en väsentlig inverkan på prestanda där de beroende valda kriterierna ändras på varje rad. Flyttande medelvärde är ett exempel på en fråga som faller in i denna kategori. Exekveringstiden kan öka med rutans ruta. För att undvika detta valde man en databasmotor som kan utföra indexerade sökningar på beroende val. Jag finner postgres fungerar effektivt för detta problem. svarade 2 juli kl 14:01 Ditt svar 2017 Stack Exchange, Inc Med ett enkelt glidande medelvärde för att släta ut data är en ganska populär teknik. Det är för dåligt att det primära exemplet i SQL Anywhere Help är långt ifrån enkelt: Vad gör det exemplet så komplicerat Förutom problemformuleringen är det: beräkna det rörliga genomsnittet av all produktförsäljning, per månad år 2000. Heres vad som gör det komplexa: två referenser till AVG () - funktionen, en GROUP BY (som i sig gör bara om vilken som helst SELECT en huvudskrapa),. en snygg WINDOW-klausul en WINDOW-klausul som inte ens använder WINDOW-sökordet. så till de oinitierade (de som behöver exempel mer än någon annan) är det inte uppenbart att en Windows är inblandad alls. Inte bara en WINDOW-klausul, tänka dig, men en som innehåller varje enskild komponent som du kan koda i en Windows: en PARTITION BY, en RANGE-klausul. inte en enkel ROWS-klausul, men fullblåst RANGE-klausul, en som har ett intimt förhållande med ORDER BY. Jag vet vad en rad är men vad redigeras är en RANGE Men vänta, det finns mer: Valet av RANGE över ROWS i det här exemplet är avgörande för att sökningen ska fungera korrekt. (för en mer fullständig diskussion om det här exemplet, se exempel 23 - Beräkna ett rörligt medelvärde i Glenn Paulleys utmärkta OLAP-vit papper.) Nu kan vi komma tillbaka på rätt spår: Ett riktigt enkelt enkelt rörligt medelvärde Följande exempel visar 10 dagars värde av data tillsammans med glidande medelvärdet för dagens värde och gårdagar: WINDOW-klausulen på rad 21 till 23 definierar ett rörligt fönster som innehåller två rader: rad för dagens rad (CURRENT ROW) och yesterdays row (1 PRECEDING): WINDOW ORDER BY-klausulen bestämmer vad PRECEDING betyder (föregående rad med t. entrydate) och ROWS-klausulen bestämmer storleken på fönstret (alltid två rader). Uttrycket AVG (t. value) Över twodays på rad 19 hänvisar till WINDOW-klausulen med namnet, och det berättar SQL Anywhere att beräkna medelvärdet av de två värdena för t. value som finns i 2-radie skjutfönstret, för varje rad i resultatuppsättningen. Så för 2012-02-02 är genomsnittet 10 och 20 15,000000, för 2012-02-03 är genomsnittet 20 och 10 15,000000, för 2012-02-04 är genomsnittet 10 och 30 20,000000, för 2012- 02-10 är genomsnittet 10 och 60 35,000000. Oj, vad sägs om den första raden Raden 2012-02-01 har inte en föregående rad, så vad är genomsnittet över det rörliga fönstret Enligt Glenn Paulleys vitt papper i fallet med ett rörligt fönster antas det att rader som innehåller Null värden finns före första raden och efter sista raden i ingången. Det betyder att när det rörliga fönstret har 2012-02-01 som CURRENT ROW, innehåller raden 1 PRECEDING NULL-värden. och när SQL Anywhere beräknar en AVG () som innehåller ett NULL-värde, räknar det inte alls NULL. inte i täljaren eller i nämnaren vid beräkning av medelvärdet. Heres bevis: Det är varför twodayaverage 10.000000 för första raden 2012-02-01. Upplagt av Breck Carter kl. 15:47 I mitt senaste samtal på Surge och Percona Live om adaptiv feldetektering (slides) hävdade jag att hårdkodade trösklar för att varna om felförhållanden är oftast bäst för att undvika för dynamiska eller adaptiva trösklar. (Jag gick faktiskt mycket längre än det och sa att det är möjligt att upptäcka fel med stort förtroende för många system som MySQL utan att ange några trösklar alls.) I det här inlägget vill jag förklara lite mer om de glidande medelvärdena jag använde bestämma normalt beteende i exemplen jag gav. Det finns två uppenbara kandidater för glidande medelvärden: raka glidande medelvärden och exponentiellt vägda glidande medelvärden. Ett rakt glidande medelvärde beräknar bara medelvärdet (medelvärdet) över de sista N-samplarna av data. I mitt fall använde jag 60 prov. Detta kräver att man behåller en rad av de föregående N-proverna och uppdaterar genomsnittsvärdet för varje prov. Ett exponentiellt rörligt medel behöver inte behålla prov. Medelvärdet är ett enda nummer och du har en så kallad utjämningsfaktor. För varje nytt prov multiplicerar du det gamla genomsnittet med 1- och lägger sedan till det nya provet gånger: avg: (1-alfa) avg alfa-prov. Båda teknikerna har sina nackdelar. Båda kräver en uppvärmningsperiod, till exempel. Självklart, om det rör sig om ett 60-provsfönster, behöver du 60 prov innan du kan börja. Det exponentiella glidande medlet kan primeras från medelvärdet av de första 10 proverna, enligt min erfarenhet. Båda teknikerna lagrar också trenden i proverna till viss del. När det är en dramatisk förändring i mönstret tar de ett tag att komma ikapp. Här är en plot av några riktiga data och de två teknikerna. Klicka igenom för att se en större bild. Den blå linjen är samplad data, den röda linjen är ett exponentiellt rörligt medelvärde med ett genomsnittligt 60 sekunders minne och den gula linjen är ett 60 sekunders glidande medelvärde. Lägg märke till hur den röda linjen tenderar att korrigera snabbare och vara mer trogen mot den blå linjens nuvarande beteende. Detta är en fördel med exponentiell glidande medelvärde om det är vad du önskar. Det är inte uppenbart i dessa data, men det enkla glidande medlet har en annan nackdel. Antag att det finns en uppsving av mycket höga värden i de samplade data i några sekunder. Under de närmaste 60 sekunderna kommer denna spik att ligga inom fönstret och uppblåsa det glidande medlet. När det kasseras från fönstret, orsakar det att det rörliga genomsnittet sjunker plötsligt. Jag har funnit att detta är problematiskt i flera fall. Det är särskilt uppenbart när du beräknar standardavvikelsen för proverna (eller annan känslig statistik) över det rörliga fönstret. Det exponentiella glidande medlet har inte det problemet eftersom den spiken aldrig rör sig ut ur fönstret. Dess inflytande finns där för alltid men när tiden går, blir den gradvis mindre, smidigt. Så du får inte abrupta spikes i det nuvarande genomsnittet baserat på vad som hände för 60 sekunder sedan. Det är bara att skrapa ytan av de tekniker som Ive utforskade på en stor uppsättning dagar till veckor data från tiotusentals riktiga servrar. När jag får tid försöker Ill skriva mer om det i framtiden.
No comments:
Post a Comment