Udførelse af forskellige tilgange til tidsbaserede data

På den ene side er det godt, at du har åbnet et nyt spørgsmål. Men ved at udtrække en forespørgsel og spørge, om den fungerer hurtigere, mister konteksten af ​​det forrige spørgsmål, det nye spørgsmål er for isoleret. Som jeg er sikker på, du ved, er administration af en database, styring af ressourcer (hukommelse/cache, disk, CPU-cyklusser), styring af kode (god eller dårlig), der bruger disse ressourcer, alt sammen en del af hele billedet. Performance er et handelsspil, intet er gratis.

1. Det vigtigste problem, jeg havde, var duplikeringen af ​​EndDate-kolonnen, som er let at udlede. Duplikerede kolonner er lig med Update Anomalies. Smirkingman har givet det klassiske eksempel:nogle forespørgsler vil få det ene resultat, og andre forespørgsler vil få det andet. Det er simpelthen ikke acceptabelt i store organisationer; eller i banker (i det mindste i udviklede lande), hvor data er revideret og beskyttet. Du har brudt en grundlæggende normaliseringsregel, og der skal betales bøder.

   • Opdater Anomailes; to versioner (allerede detaljeret). Revisorer må ikke bestå systemet.

   • Tabelstørrelse
     I enhver stor tabel er det et problem, og især i tidsserier eller tidsmæssige data, hvor antallet af kolonner er lille, og antallet af rækker er enormt. Så hvad vil nogle sige, diskplads er billig. Ja, det er kønssygdomme også. Det afgørende er, hvad det bruges til, og hvor godt man passer på det.

     • Diskplads
       Kan være billig på en pc, men i en produktionsserver er det ikke. Grundlæggende har du tilføjet 62% til rækkestørrelsen (13 plus 8 er lig med 21) og derfor bordstørrelsen. I den bank, jeg i øjeblikket er tilknyttet, opkræves hver afdeling, der ejer dataene, som følger, SAN-baseret lagring er alt, hvad der er. Tallene er pr. GB pr. måned (dette er ikke en high-end australsk bank):

       1,05 $ for RAID5 Unmirrored
       (vi ved, at den er langsom, men den er billig, bare lad være med at lægge vigtig information på den, for hvis den går i stykker, efter at den nye disk er varm eller kold-skiftet, tager det dage før det for at synkronisere sig selv igen.)

       $2,10 for RAID5 Mirrored
       I SAN, dvs.

       $4,40 for RAID1+0
       Minimum for produktionsdata, sikkerhedskopierede transaktionslogfiler og natlige databasedumps.

       $9,80 for RAID1+0 replikeret
       Til et identisk SAN-layout på et andet, bombesikkert sted. Produktion cut-over på få minutter; næsten nul transaktionstab.

     • Hukommelse/cache
       Ok, Oracle har det ikke, men de seriøse banktjenester har caches, og de administreres. Givet en specifik cachestørrelse, vil kun 62 % af rækkerne passe ind i den samme cachestørrelse.

     • Logisk og fysisk I/O
       Hvilket betyder 50 % mere I/O for at læse tabellen; både streaming til cache og disklæsning.

2. Derfor er det et akademisk spørgsmål om forespørgslen klarer sig bedre eller dårligere isoleret set. I forbindelse med ovenstående, tabellen er langsom og præsterer 62 % dårligere, hele tiden, ved hver adgang. Og det påvirker alle andre brugere på serveren. De fleste DBA'er er ligeglade (det ville jeg bestemt ikke gøre), hvis underforespørgselsformularen udfører halvt så hurtigt, fordi deres bonus er knyttet til revisionsaccept, ikke kun kodeydeevne.

   • Derudover er der den ekstra fordel ved aldrig at skulle gense kode og rette op på transaktioner på grund af opdateringsanomalier.

   • Og transaktionerne har færre point at opdatere, så de er mindre; mindre blokerende låse osv.

3. Enig, den diskussion i kommentarerne er svær. I mit svar har jeg detaljeret og forklaret to underforespørgsler. Der var en misforståelse:du talte om denne underforespørgsel (i WHERE-sætningen, en tabelunderforespørgsel ) og jeg talte om den anden underforespørgsel (i kolonnelisten, en skalær underforespørgsel ), da jeg sagde, at den fungerer lige så hurtigt eller hurtigere. Nu hvor det er blevet ryddet op, kan jeg ikke sige, at den første forespørgsel ovenfor (underforespørgsel i WHERE-sætningen, en tabel) vil fungere lige så hurtigt som den anden forespørgsel (med den duplikerede kolonne); den første skal udføre 3 scanninger, hvor den anden kun udfører 2 scanninger. (Jeg tør dog påstå, at den anden vil bordscanne.)

   Pointen er, at ud over isolationsproblemet er det ikke en fair sammenligning, jeg lavede kommentaren om skalære underforespørgsler. Jeg vil ikke foreslå, at en 3-scanningsforespørgsel er lige så hurtig eller hurtigere end en 2-scanningsforespørgsel.

   Udsagnet, jeg fremsatte om 3-scanningstabel-underforespørgslen (som jeg citerer her) skal tages i den fulde kontekst (enten det indlæg i toto eller ovenstående). Jeg trækker mig ikke tilbage fra det.

   Jeg bruger halvdelen af ​​mit liv på at fjerne ulovlige alternativer såsom duplikerede kolonner, som er baseret på spørgsmålet om ydeevne, hvor skaberne synger mantraet om, at bordet er langsomt, så de har "denormaliseret for ydeevne". Resultatet, der kan forudsiges før jeg starter, er et bord halvt så stort, som klarer sig dobbelt så hurtigt samlet . Times Series er det mest almindelige spørgsmål her (linket linker til et andet spørgsmål; hvilket linker til et andet), men forestil dig problemet i en bankdatabase:daglig OpeningExposure og ClosingExposure efter Security pr. Holding prUnitTrust prPortfolio .

4. Men lad mig svare på et spørgsmål, der ikke er blevet stillet. Denne form for interaktion er normal, ikke ualmindeligt, når man arbejder med interne udviklingsteams; det kommer op mindst en gang om måneden. En crash hot udvikler har allerede skrevet og testet sin kode, ved at bruge en tabel med en duplikeret kolonne, den flyver, og nu er den gået i stå, fordi jeg ikke vil sætte den i db.

   Nej, jeg vil teste det inden for konteksten af ​​hele systemet og:

   • halvdelen af ​​tiden går tabellen ind uden EndDate-kolonnen, fordi der ikke er noget med, at en forespørgsel på et halvt sekund nu udføres på et sekund.

   • Den anden halvdel af tiden er ydeevnen [tabel underforespørgsel] ikke acceptabel, så jeg implementerer en boolsk (bit) indikator til at identificere IsCurrent . Det er meget bedre end en duplikeret kolonne og giver 2-scanningshastigheder.

   • Ikke om en million år vil du få mig til at duplikere en klumme; tilføjelse af 62% til tabelstørrelsen; bremse bordet i den fulde flerbrugerkontekst med 62%; og risikerer at fejle en revision. Og jeg er ikke ansat, jeg får ingen bonus.

   Det ville nu være værd at teste:forespørgsel med en duplikeret kolonne vs forespørgsel med en IsCurrent indikator, i den fulde kontekst af overordnet ressourceforbrug.

5. Smirkingman har bragt en god pointe frem. Og jeg vil gengive det klart, så det ikke bliver fragmenteret, og så bliver det ene eller det andet fragment angrebet. Venligst ikke bryde dette op:

   En relationel database,
   Normaliseret af en erfaren relationel modellør til ægte femte normalform
   (ingen opdateringsanomalier; ingen duplikerede kolonner),
   med fuld overholdelse af relationer
   (IDEF1X, især i forbindelse med minimering af Id Primære nøgler; og dermed ikke ødelægger kraften i den relationelle motor)
   vil resultere i flere, mindre tabeller, en mindre database,
   med færre indekser,
   kræver færre joinforbindelser
   (det er rigtigt, flere borde, men færre joinforbindelser),
   og det vil udkonkurrere alt, der bryder nogen af ​​disse regler
   på den samme hardware og enterprise db platform
   (ekskluderer freeware, MS, Oracle; men lad det ikke stoppe dig),
   i den fulde kontekst af produktions-OLTP-brug
   med mindst én størrelsesorden,
   og det vil være meget nemmere at bruge
   og at ændre
   (behøver aldrig "refactoring").

   Jeg har gjort dette mindst 80 gange. To størrelsesordener er ikke ualmindeligt, hvis jeg gør det selv, frem for at give rammerne for, at en anden kan gøre det.

Hverken jeg, ikke de mennesker, jeg arbejder med, eller som betaler mig, er ligeglade med, hvad en enkelt forespørgsel vil gøre isoleret.