Optimering af log database

Transkript

1 Optimering af log database Kim Christensen Kongens Lyngby 2009 IMM - B. Eng

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax IMM - B. Eng

3 Abstrakt Dubex A/S har nogle store database, der indeholder informationer trukket ud fra firewall log filer. En måneds informationer fylder ca. 2-3 GB. Der bliver jævnligt søgt i denne data, flere måneder tilbage, hvilket grundet størrelsen og mængden af informationer der trækkes ud af databasen, kan tage flere minutter. Dette er ikke optimalt, hverken for kunderne eller for supporterne. Derfor er Dubex meget interesseret i at undersøge hvordan databasen kan blive optimeret, således at udtrækket ikke tager så lang tid og data ikke fylder så meget. Derfor vil jeg kigge på forskellige muligheder for at optimerer databasen til dette, sammenligne dem, og finde den metoder der fungere bedst, både hastighedsmæssigt, men også tage hensyn til, at ændringer i importen af disse data ikke er så omfattende, at databasen optimeringen ikke kan betale sig. Et af kravene er at MySQL skal bruges som backend database. Blandt de mange muligheder vil jeg blandt andet undersøge, kolonne-baserede databaser, clustered tabeller, bedre opdeling af informationer i tabeller og brug af indeks. Der findes allerede MySQL storage engines til mange af disse ting, hvor performance og simplicitet vil blive testet og opvejet mod andre muligheder.

4 ii

5 Forord Dette projekt er udført i samarbejde med Dubex A/S, som en del de nødvendige krav for at opnå en B.Sc. Projektet udsøger hvordan en log database kan optimeres, både størrelses- og ydeevnemæssigt. Der bliver også kort kigget på hvor fleksible de forskellige løsninger vil være i forhold til nem importering af nye typer log data. Lyngby, April 2009 Kim Christensen

6 iv

7 Tak til Tak til Dubex A/S for at lade mig udfører projektet hos dem, samt for den store støtte og hjælp jeg har fået frem de ansatte, specielt Jens Ramsbøl og David Dindorp. Jeg vil også sige tak for den gode vejledning jeg har fået fra min DTU vejleder, Peter Falster, uden den havde jeg ikke kunne gennemføre projektet.

8 vi

9 Indhold Abstrakt Forord Tak til i iii v 1 Indledning Baggrund for projekt Opgave afgrænsning Problemformulering Opgavens opbygning MySQL Den logiske arkitektur Transaktioner Concurrency Control Indeks Storage Engines Database Optimering Introduktion til optimeringsmetoder Rækkebaserede databaser (Row-oriented databases) Kolonnebaserede databaser (Column-oriented databases) Full text scearch engine Udvalgte optimeringsmetoder Infobright MyISAM optimering Sphinx Test miljø Teste Nuværende database Tabeller Fordele Ulemper Database opsætning Hvad bliver data brugt til? Problemer

10 viii INDHOLD 6.7 Diagram Test Test Infobright MyISAM optimering Sphinx Diskussion 67 9 Konklusion 69 A Test script 71

11 Kapitel 1 Indledning 1.1 Baggrund for projekt Baggrunden for projektet er nogle store log database der indeholder firewall log data fra kunder, hvis firewalls bliver overvåget af Dubex. Der kommer løbende log data fra kunderne, i gennemsnit hver tredje time, hvilket betyder at der i løbet af en døgn samlet set bliver gemt 4-7 GB log data for alle kundernetil sammen, alt efter hvor mange sikkerhedsmoduler der bliver overvåget. Ud fra log data bliver der genereret diverse statistikker til brug i grafer og tabeller, så både Dubex og kunderne, nemt kan se og forstå data. Hvis man har behov for direkte at se i log data er dette også muligt. På grund af de store datamængder, specielt fordi man ofte kigger på flere dage samtidigt, er det blandt andet meget langsomt at søge i log data, det kan ofte tage flere minutter og til sidst ende i en timeout, så det rent faktisk kan blive meget svært at bruge data til noget. Hvor lang det tager, kommer selvfølgelig an på hvor meget data der er for den enkelte kunde. Jeg syntes det kunne være spændende at kigge på de problemer, der er ved den nuværende database struktur og at optimerer strukturen således, at søgninger gik hurtigere, data fylder mindre og gør det muligt relativt nemt at importere andre typer log data. 1.2 Opgave afgrænsning Der er rigtig mange muligheder i projektet, faktisk så mange muligheder, at der er behov for en kraftig afgrænsning af opgave, da det ellers bliver svært at nå på de 12 uger der er til projektet. De tre vigtigste ting i opgaven, er: Størrelse

12 2 Indledning Ydeevne Fleksibilitet På grund af de mange muligheder der er i database optimeringer, og det begrænsede tid der er til projektet, bliver opgaven nødt til at begrænses til de mest væsentligt ting. Efter en del overvejelse er jeg, i samarbejde med Dubex, kommet frem til at jeg hovedsageligt koncentrerer mig omkring database størrelsen og ydeevnen, men dog at jeg stadig tager hensyn til fleksibiliteten under udvælgelse af optimeringsmetoder. I forhold til diskplads betyder database størrelsen ikke det store, men den har en stor indflydelse på databasens ydeevne, specielt når databasen ikke er bygget korrekt op. Selvom det ikke er prisen der er fokus på, er det vigtigt at Dubex sikkert kan opbevare meget data og nemt kan tage backup af det. Ydeevnen hænger en hel del sammen med størrelsen, for database skal være bygget korrekt op, hvis det både skal kunne være stor og have god ydeevne. Der er mange måde databasens ydeevene kan forbedres på, derfor skal forskellige måder undersøges og udvalgte optimeringsmetoder skal testes. Databasens fleksibilitet er noget Dubex er meget interesseret i, da en del af problemet er at databasen ikke nemt kan udvides til at indeholde flere informationer end de nuværende. Flere informationer kan blandt andet være mere firewall log data, men det kan også være nye typer log data. 1.3 Problemformulering Hvordan kan man optimere den nuværende MySQL database der indeholder log data? Opgavens fokus er at gøre databasen mindre og hurtigere at tilgå, men som en ekstra opgave kunne man godt tænke sig at gøre databasen mere fleksible, således at man uden alt for mange problemer, kan gemme andet end firewall log data i databasen. Derfor vil opgaven inkluderer en overvejelse af fleksibiliteten i de forskellige optimerings metoder der undersøges. Da punkterne fleksible, lille og hurtig er lidt selvmodsigende, for eksempel går fleksibilitet ikke godt sammen med lille størrelse, er en del af opgaven at finde en balancegang som er tilfredsstillende for den type data der skal kunne gemmes i databasen. 1.4 Opgavens opbygning Opgaven bliver opbygget ved at jeg først kigger på MySQL s logiske struktur, og hvordan MySQL databaser fungere internt. For at kunne løse opgaven er det vigtigt at vide mere om hvordan databaserne fungerer internt og hvilken funktionalitet der er tilstede i dem, da det ellers er meget svært at gennemskue hvordan man kan optimerer bedst muligt. Det er også vigtigt i forbindelse med at måle en databases ydeevne, da det ellers er meget svært at vide præcis hvad man skal kigge efter og hvordan. Til at starte med er der udvalgt nogen forskellige punkter i MySQL, som bliver nærmere forklaret, men i løbet af opgaven vil der blive inkluderet mere information, som på en eller anden måde har noget med MySQL s interne opbygning at gøre. Grunden til at det bliver gjort på den måde og ikke det hele til at starte med, er at MySQL er meget kompleks og at formålet med denne opgave ikke er at beskrive MySQL, men kun de ting der er nødvendige for at kunne optimerer log databaserne. Det er også meget nemmere løbende at beskrive de forskellige dele af MySQL, end at gøre det hele til at starte med, dog er der visse ting man bliver nødt til at vide på forhånd, og det er disse ting der bliver beskrevet til at starte med.

13 1.4 Opgavens opbygning 3 Dernæst bliver der kigget på den type data, som skal kunne gemmes i databasen. Det bliver beskrevet hvordan denne data ser ud og hvordan data efterfølgende skal bruges. Jeg kigger også kort på de overvejelser der skal gøres i forbindelse med den ønskede fleksibilitet. Derefter kigger jeg nærmere på den nuværende databases opbygning og struktur, for at finde ud af hvilke fordele og ulemper der er ved denne, hvad det er der giver de nuværende problemer og teste dens ydeevne. Grunde til at jeg vil gøre så meget ud af den nuværende database, er at det er vigtigt at vide præcis hvad problemerne er, og for at have noget at teste udvalgte optimeringsmetoder imod. Når de nuværende problemer er blevet defineret mere teknisk og ydeevnen målt, ved jeg mere om hvad den nye database struktur skal gøre bedre, og derfor kan jeg undersøge forskellige optimeringsmetoder nærmere. Jeg vil give en kort introduktion til nogle forskellige optimeringsmetoder, og på baggrund af disse vil jeg udvælge 3-4 metoder der vil blive undersøgt nærmere, testet og sammenlignet med den nuværende database. For hver af de udvalgte optimerings metoder, vil jeg beskrive teorien bag dem, hvilke fordele og ulemper der er ved metoden og om den giver mulighed for større fleksibilitet. Et testsystem vil derefter blive designet og implementeret, således at det metoden kan testes og blive sammenlignet med den nuværende database. Der vil blive lavet en test metode, der gør det muligt at teste alle optimeringer på nogenlunde samme måde, da det ellers kan være meget svært at danne sig et godt indtryk af ydelses forskellen mellem de udvalgte metoder. Til sidst vil jeg udfra de udførte teste, diskuterer og konkluderer hvilke af optimeringerne der er den bedste i dette tilfælde.

14 4 Indledning

15 Kapitel 2 MySQL Arkitekturen i MySQL er meget anderledes i forhold til andre databaser, hvilket gør den brugbar i mange forskellige sammenhænge, og giver mulighed for mange funktionaliteter, som ellers kun findes i databaser der er mere specialiseret. På grund af den specielle arkitektur i MySQL, er det vigtigt at man forstår dens design, og dermed udnytte de fordele det giver. I dette kapitel vil jeg kommer nærmere ind på hvad der gør MySQL speciel, så jeg kan optimerer bedste muligt. Jeg vil også komme ind på generelle database funktioner, der er vigtige for at kunne bedømme hvordan man kan optimere. 2.1 Den logiske arkitektur Det øverste lag, på figur 2.1 set som Connectors, er ikke en del af MySQL, men bliver i stedet styret af operativ systemet. Ting som connection handling, autentificering, sikkerhed, osv. ligger i dette lag. Andet lag, alt i kassen der er over Pluggable Storage Engines, er der hvor MySQL s kerne ligger. Dette lag indeholder blandt andet query parsing, analyse, optimering, caching og alle indbyggede funktioner, så som datoer, tid, matematik og kryptering. Det er også her al funktionalitet på tværs af storage engines ligger, det er blandt andet stored procedures, triggers og views. Tredje lag indeholder alle storage engines. Storage engines gemmer og henter al data der er gemt i en MySQL database, og derfor er det udelukkende dem der styrer opbygningen af selve databasen. Hver enkelt storage engine har fordele og ulemper, hvilket gør det meget vigtigt at vælge den engine der fungere bedste til databasens formål. Storage engines kigger ikke nærmere på SQL statements, snakker sammen eller lignende, i stedet svare de kun på forespørgsler. Der findes mange forskellige typer storage engines, fra meget simple til meget avancerede. Storage engines er derfor meget vigtige, og jeg kommer mere ind på dem i løbet af rapporten. Fjerde lag er selve serverens filsystem, der er visse filsystemer der er bedre til at håndtere databaser end andre, men da det ofte er meget specifikke ting det ene filsystem er bedre til end andre, er det sjældent at det har en reelle indflydelse på databasen ydeevne. Derfor indeholder denne rapport ikke overvejelser omkring dette.

16 6 MySQL Figur 2.1: MySQL s logiske arkitektur Håndtering af forbindelser Hver gang en klient forbinder til database for den sin egen tråd i server processen, og alle forespørgsler fra klient bliver derefter eksekveret inde i den tråd. Dette gør det muligt at flere klienter kan arbejde med databasen på samme tid, udover dette giver det også bedre sikkerhed da trådene ikke kan snakke sammen. En anden fordel er at serveren kan cache tråde, hvilket betyder at når en forbindelse afbrydes bliver tråden ikke lukket ned, i stedet bliver den tilføjet til chachen, og den næste forbindelse der bliver oprette tager tråden derfra. Det giver en bedre ydeevne, da en ny tråd ikke nødvendigvis skal oprettes ved en ny forbindelse. Når en klient forbinder til databasen, bliver han første autentificeret og der bliver tjekket om han har rettigheder til at udføre den ønskede handling på databasen. Normalt har dette ingen indflydelse på ydeevnen, da dette normalt sker meget hurtigt, dog er der undtagelser, for eksempel hvis der er ekstremt mange bruger rettigheder Optimering og eksekvering MySQL parser alle forespørgsler for at danne en intern struktur, som der kan udføres forskellige optimeringer på. Optimeringerne kan inkludere omskrivelse af forespørgslen, finde ud af hvilke rækkefølge tabellerne skal læses i, finde ud af hvilke indeks der skal bruges, og flere andre ting. Selvom optimeringen foregår automatisk, er det muligt at have indflydelse på dens valg. Man kan også få serveren til at forklare hvilke optimeringer der bliver udført på en forespørgsel, hvilket giver mulighed for at se hvilke ting der skal ændres, for at få det hele til at køre så effektivt som muligt. Optimeringen har ikke direkte noget med storage engines at gøre, men den valgte storage engine indflydelse på hvordan en forespørgsel bliver optimeret. Grunden til det er at forskellige storage engines, har forskellig funktionalitet, og derfor er det ikke alle optimeringer der har nogle indflydelse. For eksempel er det ikke alle storage engines der understøtter indeks, og derfor er der ikke noget formål med at undersøger hvilke indeks der kan bruges. Inden serveren overhovedet begynder at parse en forespørgsel, kigger den først i en cache der indeholder

17 2.2 Transaktioner 7 et antal tidligere forespørgsler og deres resultater, for at se om den samme forespørgsel er blevet udført tidligere. Hvis dette er tilfældet bliver resultatet hentet fra cachen i stedet, hvilket forbedre ydeevnen væsentligt ved forespørgsler der bliver udført ofte. 2.2 Transaktioner I databaser støder man meget hurtigt på transaktioner, specielt hvis man kigger nærmere på mere avancerede database funktioner. En transaktion er en gruppe af SQL forespørgsler der bliver behandlet som en enkelt. Hvis databasen kan udføre alle forespørgsler gør den det, men hvis der er bare en af dem, ligegyldigt hvor i gruppen det er, fejler, bliver ingen af dem udført. Når en transaktion bliver udført, bliver det kaldt committed, når den ikke bliver udført bliver der lavet en rollback. Transaktioner findes i mange databaser, og er derfor ikke specielle i MySQL. Forskellen mellem MySQL og andre databaser med hensyn til transaktioner, er hvor logikken til transaktioner er implementeret henne. I andre databaser servere er logikken implementeret i selve database serveren, dette er ikke tilfældet i MySQL, hvor transaktioner er implementeret i storage engines. For at transaktioner skal være nyttige, skal systemet overholde ACID 1. En database der understøtter transaktioner, skal holde styr på mange flere ting end en database der ikke understøtter transaktioner. Det betyder at databaser der understøtter dette, generelt har brug for mere CPU, hukommelse og disk plads, end en der ikke gør. I forbindelse med dette har MySQL en fleksibilitet der ikke er tilstede i andre database servere, her er det nemlig muligt at definere hvilken storage engine der skal bruges til hver database table. Det betyder at det ikke er hele databasen der behøves køre transaktioner, men kun de nødvendige tabeller. Man skal dog huske på at man kan komme i problemer, hvis man blander transaktionelle tabeller sammen med ikke transaktionelle, hvor man nemt komme ud i situationer hvor databasen kan bliver inkonsistent. Man kan selv vælge om der er behov for transaktioner i ens applikation, hvis man ikke behøver dem kan ydeevne måske forbedres ved at fravælge dem. For eksempel kan man i visse tilfælde opnå den ønskede transaktions sikkerhed ved at låse hele tabellen i stedet for at bruge rigtige transaktioner Isolations niveauer Isolation er en essentiel del af transaktioner, og definere hvilke sikkerhed der er nødvendig i den pågældende transaktion. De forskellige niveauer er: READ UNCOMMITTED: På dette niveau kan uncommitted transaktioner læses, og derfor kan der opstå mange forskellige problemer, hvis man ikke er helt sikker på hvad man laver og at der er en god grund til det. Dette niveau bliver sjældent brugt i praksis, da ydeevne ikke er meget bedre end de andre nvieauer som har mange flere fordele. I virkeligheden svare det næsten til ikke at bruge transaktioner overhovedet, bortset fra at man kan rulle ændringer tilbage. Læsning af uncommitted data er også kaldet et dirty read. READ COMIITTED: En transaktion vil kun se data der er committed, og ændringer vil ikke kunne ses før de er blevet committed. Ulempen er at det er muligt at køre den sammen forespørgsle lige efter hinanden og se forskellige data, dette er kaldet et nonrepeatable read. 1

18 8 MySQL REPEATABLE READ: Dette niveau garantere at man vil kunne få det samme data ved forspørgsler der bliver udført lige efter hinanden. I teorien kan der dog opstå et andet problem, phantom reads, som kan opstå hvis man henter et antal rækker og der samtidig er en anden transaktion der indsætte en række. Dermed kan man i teorien bagefter hente det samme antal rækker og i blandt dem se den nye række. Dette problem bliver i nogle storage engines løst ved hjælp af multiversion concurrency control, se afsnit SERIALIZABLE: Er det højeste isolations niveau. Her bliver phantom reads løst ved at transaktioner bliver kørt i sekventielt, og derfor umuligt kan komme i konflikt med hinanden. På dette niveau kan der forekomme mange timeouts, og bliver derfor sjældent brugt i praksis. I MySQL bliver isolations niveauer implementeret i storage engines, og derfor kan der være forskel i hvordan disse fungere og om alle niveauer bliver understøttet. 2.3 Concurrency Control Concurrency control er vigtigt i alle database og håndterer hvordan database reagere når der er to forespørgsler der prøver at redigere i data samtidig. For at løse dette problem er det muligt at låse forskellige dele af database, så de ikke kan ændres i mens der bliver læst fra tabellen, eller at det ikke er muligt at flere forespørgsler skriver til databasen på samme tid. MySQL kan håndterer concurrency control på to forskellige niveauer, server og storage engine. På server niveau bliver de mest simple låse håndteret, for eksempel er det her table locks bliver håndteret. Grunden til at table locks bliver håndteret på server niveau er fordi MySQL selv bruger table locks, for eksempel når en tabels udformning bliver ændret, hvilket skal kunne håndteres lige meget hvilken storage engine der bliver brugt. På storage engine niveau bliver mere avancerede låse håndteret for eksempel row locks. Alle låse der er implementeret i storage engine virker, uden at serveren har nogen ide om at de eksisterer. Dette betyder også at forskellige storage engines kan implementere de samme låse mekanismer på helt forskellige måde. Der findes to forskellige hovedkategorier af concurrency control mekanismer: Optimistisk Pessimistisk Optimistisk concurrency control (OCC) Denne type concurrency control låser ikke noget data, og bygger på ideen om at de fleste database transaktioner ikke kommer i konflikt med andre transaktioner, og at man derfor ikke behøves at forhindre konflikter, men i stedet kun at detektere dem. Denne tankegang gør, at der ikke er behov for at låse noget som helst, men kun at tjekke om vi reelt er stødt på en konflikt inden transaktionen bliver færdiggjort. Der er tre faser i en OCC transaktion: 1. Læsning: Klienten læser fra databasen og gemmer dem privat så klienten kan ændre data. 2. Validering: Når ændringerne er færdige, bliver der tjekket for om ændringer på nogen måde kommer i konflikt med allerede committed eller igangværende transaktioner. Hvis der er nogle konflikter kan transaktionen enten droppes eller en løsning kan på en eller anden måde udføres.

19 2.4 Indeks 9 3. Skrivning: Hvis der ikke er nogen konflikt, bliver transaktionen committed. OCC bliver ofte brugt i systemer hvor der sjældent sker konflikter. Hvis der tilgengæld ofte opstår transaktions konflikter, er der måske andre concurrency control metoder der vil fungere bedre end OCC Pessimistiske concurrency control (PCC) PCC bygger på tankegangen om at konflikter altid sker, hvilket betyder at data bliver låst både ved læsning og skrivning. Fordelen ved PCC er at den er nem at implementere, og giver fuldstændig garanti for at ændringer i databasen bliver udført konsistent og sikkert. Ulempen er at denne metode ikke skalere godt. Hvis et system har mange brugere, hvis en transaktion involvere meget data eller transaktioner tager meget lang tid, så stiger chancen for at man skal vente på at en lås bliver frigivet, betydeligt. Derfor er det begrænset hvor mange bruger der kan være på systemet samtidigt Multiversion Concurrency Control (MVCC) MVCC er en anden form for concurrency control der er meget brugt. MVCC virker ved at beholde et snapshot af data, som det så ud på tidspunkt. Dette betyder at transaktioner kan se en konsistent version af data, lige meget hvor lang tid transaktionen vare. Det betyder også at forskellige transaktioner kan se forskellige data i den samme tabel, hvilket sker når der opstår konflikter. Fordelen ved MVCC er at man i mange tilfælde overhovedet ikke behøver at låse data, og kan dermed i visse tilfælde have bedre ydeevne end row locking. Alt efter hvordan MVCC er implementeret, kan man for eksempel tillade ikke-låsende læsninger, men i stedet kun nøjes med at låse data ved skrive operationer. Ulempen er at MVCC bliver nødt til at gemme meget data for at kunne håndtere de mange forskellige snapshots. Som tidligere nævnt kan MVCC dog i visse tilfælde være en fordel, da låsning ikke altid er nødvendigt. 2.4 Indeks Et indeks er data strukturer der hjælper MySQL, og andre databaser, med at hente data effektivt. De er kritiske for god ydeevne, men folk glemmer dem ofte eller bruger dem forkert, hvilket giver dårlig ydeevne. Indeks, i MySQL også kaldet keys, bliver vigtige efterhånden som data bliver større. Et indeks fungere på samme måde som man bruger et indeks i en bog. Databasen kigger på indekset og kan udfra det se hvilke rækker i tabellen det matcher forespørgslen. For eksempel hvis alle rækker hvor kolonnen id er lig med 5 bliver forespurgt, kigger databasen i indekset hvor der er en reference til alle rækker hvor kriteriet bliver opfyldt. Et indeks kan indeholde værdier fra en eller flere kolonner. Hvis man laver et indeks på mere end en kolonne er rækkefølgen meget vigtig, fordi MySQL kan kun søge effektivt på den venstre del af indekset. Derfor er det at lave en indeks på to kolonner, ikke det samme som at lave to separate indeks på de enkelte kolonner. Der er mange forskellige typer indeks, der alle yder forskelligt i forskellige situationer. I MySQL er indeks implementeret i storage engines, og ikke på i selve serveren. Derfor er der i MySQL ikke nogle standardiseret indeks, hvilket vil sige at selve implementeringen af de forskellige typer indeks ikke fungere helt på samme måde, endvidere er det ikke alle storage engines der understøtter alle typer indeks.

20 10 MySQL Figur 2.2: B-Tree structure Figur 2.3: Eksempel på B-Tree structure B-Tree indeks Når folk snakker om et indeks, er det typisk et B-Tree indeks de snakker om. Et B-Tree indeks bruger typisk en B-Tree eller B+Tree data struktur til gemme data i. De fleste storage engines i MySQL understøtter denne type indeks. Storage engines gemmer B-Tree indeks på forskellige måder på harddisken, hvilket kan have indflydelse på ydeevnen. Jeg vil ikke komme inde på disse forskelle, med mindre det er nødvendigt under optimeringen, men hver enkelt variation har deres egne fordele og ulemper. Den generelle ide i et B-Tree er at hver enkelt leaf er den samme længde fra roden. Figur 2.2 viser en abstrakt repræsentering af et B-Tree indeks, her er det en B+Tree struktur der er bliver vist. Da det kan være svært at forstå den abstrakte repræsentering uden et eksempel, viser figur 2.3 et eksempel på en B-Tree struktur. Et B-Tree indeks virker godt når hele nøglen, et interval af data eller starten af en nøgle, skal findes. Da nøglerne er sorteret, er de gode til at finde både specifikke værdier og sortering.

21 2.5 Storage Engines 11 Nogle af begrænsningerne ved et B-Tree indeks er: De kan ikke bruges hvis opslaget ikke starter med den venstre side af de indeksede kolonner. Man kan ikke springe kolonner i indekset over. Det betyder at man skal lave en forespørgsel på alle de indeksede kolonner. Da rækkefølgen af kolonnerne er vigtigt, kan det ofte være nødvendigt at oprette flere indeks med de samme kolonner for at kunne opfylde kravene til ens forespørgsler Hash indeks Et hash indeks er bygget op omkring en hash tabel, og er derfor kun brugbar når specifik data der bruger alle kolonner i indekset skal findes. For hver rækker bliver en hashcode af de indeksede kolonner, udregnet, og gemt i indekset sammen med en pointer til de enkelte rækker. Da det kun er hash code der bliver gemt i indekset, fylder denne type ikke indeks ikke meget på harddisken. Endvidere har størrelsen på hashen ikke noget med kolonne typer at gøre, et tals hashcode fylder lige så meget som en lang tekststrengs hashcode. Derfor er opslag i et hash index meget hurtigt, men der er også visse begrænsninger, blandt andet: Da indekset kun indeholder hashen kan rækkens værdier ikke tilgås direkte i indekset. Det kan ikke bruges i sorteringer da rækker i indekset ikke er gemt i rækkefølge. Det kan ikke bruges i forespørgsler der kun bruger en del af indekset. Kan kun bruges til eksakte sammenligner, da hashen kun indeholder den en hash af de eksakte værdier. Tilgangen er meget hurtigt med mindre der er mange kollisioner, flere værdier med den samme hash code. I disse tilfælde bliver alle rækker tilgået, for at tjekke hvilke der passer til det forespurgte data. Disse begrænsninger gør at hash indeks kun er effektive i visse tilfælde Andre typer indeks Der findes mange andre typer indeks, blandet andet clustered, covering indeks, og mange andre. Jeg vil kun komme nærmere ind på andre typer indeks, hvis det bliver nødvendigt under optimeringen. 2.5 Storage Engines Som tidligere beskrevet håndtere storage engines, måden hvorpå en tabel bliver gemt, hvilket er meget forskellige fra storage engine til storage engine. For eksempel er der storage engines der kan håndtere indeks, komprimeret data, data der kun ligger i hukommelsen eller transaktioner, og alt sammen uafhængigt af hinanden. Jeg vil kort beskrive to af de mere kendte storage engines, som sandsynligvis også er dem der vil blive brugt i optimeringsmetoderne.

22 12 MySQL MyISAM Engine MyISAM er standard storage engine i MySQL og bliver brugt i alle MySQLs egne tabeller, der blandt andet håndtere brugere og deres adgang til databaser. MyISAM er et godt kompromis mellem ydeevne og flere brugbare funktionaliteter, så som fulltext indeks, komprimering og spatial (GIS) funktioner. MyISAM understøtter hverken transaktioner eller row locking. En anden fordel ved MyISAM er at man uden videre kan kopiere data og indeks filer mellem platforme. En ulempe er dog at tabeller der bruger MyISAM, normalt bliver hurtigere korrupte end tabeller der bruger andre storage engines, men de kan næsten altid repareres nemt og hurtigt uden tab af data. MyISAM understøtter også delayed key writes, hvilket betyder at man kan sætte det op således, at indeks ikke bliver skrevet så snart der bliver redigeret i en tabel, men i stedet bliver det bufferet og opdateret senere. Dette kan forbedre ydeevnen i tabeller der ofte bliver ændret. Af specielle ting der muligt med MyISAM tabeller, er for eksempel at de kan kompimeres samtidig med at de stadig kan læses, men ikke redigeres. Dekomprimering af data betyder ikke noget i langt de fleste tilfælde, da rækker er komprimeret enkeltvis, og derfor er det ikke nødvendigt at dekomprimere hele tabellen for at hente data InnoDB Engine InnoDB er en meget brugt storage engine, da den understøtter transaktioner og er speciel god til at håndtere mange små transaktioner. Dens ydeevne og automatiske crash recovery, gør at den også er populær i systemer der ikke har behov for transaktioner. InnoDB bruger MVCC og implementere alle fire isolations niveauer. I REPEATABLE READ isolations niveauet, forhindre den phantom reads, ved at bruge en strategi kaldet, next-key locking. Alle tabeller der bruger InnoDB bruger automatisk clustered indeks 2, og indeks strukturen er meget forskellige fra de fleste andre storage engines i MySQL. Dette har vise fordele, for eksempel ved opslag på primary keys. InnoDB er dog meget langsom til at oprette og søge i indeks end, for eksempel MyISAM. InnoDB understøtter også foreign keys 3, hvilket er godt i forhold til database normalisering. 2.6 Database Optimering For at kunne optimerer databasen mest muligt er det nødvendigt, at finde ud af hvor hurtig den nuværende database er, både for at have et sammenligningsgrundlag og for at vide hvorhenne det meste af tiden bliver brugt. Forskellige optimeringsmetoder har forskellige steder de er langsomme, men det er altid godt at vide, hvor flaskehalsen ligge i den nuværende database og i de forskellige optimeringsmetoder Benchmarking En benchmark måler systemets ydeevne. Dette hjælper med at bedømme systemets kapacitet, og viser hvilke ændringer der vil have mest betydning, og hvordan systemet yder med andre data end de

23 2.6 Database Optimering 13 nuværende Hvorfor benchmarke? Der er mange grund til at benchmarke systemet. Et par grundene er: At måle hvordan systemet yder på nuværende tidspunkt. Ellers har man ingen idé om hvilke ændringer der kave have indflydelse på ydeevnen. Man kan også bruge gamle benchmarks til at diagnosticere uforudsete problemer. Tjekke hvordan systemet skalere ved at bruge en benchmark til at simulere et meget større pres end der er på produktionssystemet, for eksempel tusind gange mere. Teste hvordan systemet håndtere ændringer. For eksempel, hvordan et stort antal samtidige brugere bliver håndteret, hvilken indflydelse forskellige server konfigurationer har eller forskellige data distribueringer. Hjælpe med at finde ud af hvor meget hardware, netværkskapacitet og andre ressourcer der skal bruges i fremtiden. At test forskellige hardware, software og operativsystem konfigurationer. Benchmarks kan også bruges til mange andre ting, men de nævnte ting er dem der har mest med ydeevnen at gøre, og derfor dem der er vigtigst i forhold til optimering af systemet Benchmark strategier Der findes to hovedstrategier. Man kan benchmarke hele applikationen (full-stack), eller isolere MySQL (single-component). Hver strategi hjælper med at finde problemer i forskellige dele af applikationen. For eksempel er full-stack benchmarking vigtig da: Man tester hele applikationen, inklusiv web serveren, applikationskoden og databasen. Dette er meget brugbart da der ofte ikke er fokus på MySQL specifikt, men i stedet hvordan hele applikationen yder. Databasen er ikke altid problemet, hvilket en full-stack benchmark kan afsløre. Kun ved at teste hele applikationen, kan man se hvordan de forskellige deles cache opføre sig. De er gode til at vise dig hele applikationens ydeevne, hvilket er svært hvis man kun tester en del af applikationen. Benchmarks af hele applikationen kan dog være meget svære at lave og endnu svære at sætte korrekt op. Hvis man bruger en dårlig designet benchmark, kan man hurtigt komme til at tage dårlige beslutninger, fordi resultaterne ikke reflektere virkeligheden. Der er andre gange hvor man ikke er interesseret i hele applikationen, men kun behøver en MySQL benchmark, i hvert fald til at starte med. Derfor er en single-component benchmark brugbar hvis: Man vil sammenligne forskellige tabel opsætninger eller forespørgsler.

24 14 MySQL At man vil undersøge et specifikt problem i applikationen. Hvis man vil undgå en lang benchmark, og i stedet nøjes med en hurtigere en, der nemmere kan måle ændringer. I denne type benchmark er det meget brugbart hvis man kan genskabe applikationens forespørgsler på noget rigtigt data. Både data og dataens størrelse skal være realistisk, og hvis det er muligt skal der bruges et snapshot af produktions data Hvad skal der måles? Inden man starte med at benchmarke, skal man have gjort sig klar hvad det er man vil undersøge, faktisk allerede inden man begynder at designe sin benchmark. Grunden til dette er at alt efter hvad man vil undersøge, bruger man forskellige værktøjer og teknikker for at få meningsfulde resultater. Det er måske ikke klart, men nogen gange må man bruge forskellige metoder til at måle forskellige ting. Der er forskellige typer af målinger, og må man derfor overveje hvordan disse passer ind i ens mål: Transaktioner per tidsenhed: Dette er en måling der bliver brugt i rigtig mange benchmarks, og derfor findes der standardiserede benchmarks, så som TPC-C 4, som ofte bliver brugt under udvikling af nye databaser. Denne type benchmark måler hvor mange transaktioner der kan håndteres per tidsenhed, typisk per sekund. Dette gør at den er mest brugbar i forbindelse med interaktive applikationer med mange brugere. Normalt bliver termet throughput brugt i forbindelse med denne måling. Response tid: Også kaldet latency, måler hvor lang tid en opgave behøver. Alt efter applikationstypen, er det forskelligt hvilken tidsenhed man bruger i denne type måling. Ud fra målingerne kan man finde gennemsnits, minimum og maximum response tiderne, som man kan bruge i forskellige situationer. Maximum response kan sjældent bruges til noget, da længden af målingen har indflydelse på denne. Den kan heller ikke genskabes særlig let, da den ofte varierer mellem kørslerne. Derfor bliver percentile response times ofte brugt i stedet. For eksempel, hvis den 95% response tid er 5 milisekunder, ved du at opgaven bliver udført hurtigere end 5 milisekunder 95% af gangene. Ofte er det en god idé, at vise disse resultaterne på en graf, enten som linjer eller som et scatter plot, så man nemt kan se hvordan resultaterne er fordelt. Endvidere hjælper graferne også med at se hvordan et benchmark vil opføre sig i længden. Skalering: Skalerings målinger er brugbare i systemer, hvor det er vigtigt at ydeevne ikke ændre sig alt for meget under forskelligt workload. Det er et absktrakt koncept, der gør det svært at måle. Typisk bliver ydeevne målt ved throughput eller response tid, hvor workload kan ændre sig med database størrelsen, samtidige forbindelser eller hardware. Dette gør at skalerings målinger kan vise svagheder i applikationen som andre typer benchmarks ikke kan vise. For eksempel, hvis systemet er designet til at yde god response tid med en enkelt forbindelse, kan det være at applikationen yder dårligt når flere forbindelser bliver brugt. Concurrency: Concurrency kan måles mange steder i applikationen, og det brugte sprog har også indflydelse på det, for eksempel om der bliver brugt connection pools eller ej. En godt designet applikation kan have hundredvis af forbindelser til databasen åben, men kun en brøkdel af dem laver forespørgsler samtidigt. Derfor er det vigtige at måle working concurrency, altså hvor mange forbindelser der reelt udføre forespørgsler på samme tid, og ikke hvor mange forbindelser der er 4

25 2.6 Database Optimering 15 åben på samme tid. Mål om ydeevnen falder når concurrency stiger, hvis den gør dette vil applikationen sandsynligvis håndtere workload spikes dårligt. I modsætning til response tid og skalering, der giver faktiske resultater, er concurrency at måle hvordan applikationen yder under forskellige concurrency niveauer. Benchmark måler ydeevne, men ydeevne kan betyder forskellige ting for forskellige personer. Derfor skal der indsamles nogen krav omkring systemes skalerings muligheder, hvad de acceptable response tider er, hvilken type concurrency man kan forvente, og så videre. Når kravene er indsamlet prøver derefter man at designe sine benchmarks til at tage højde for alle kravene. De mest almindelige fejl i benchmarks er: Kun at bruge en lille del af det faktiske data, for eksempel kun at bruge en gigabyte data når applikationen håndtere flere hundrede, eller kun at bruge den nuværende data når applikationen skal kunne håndtere meget mere. At bruge forkert fordelt data, så som urealistisk fordelt data i forhold til applikationen. Brug af urealistisk fordelte parameter. At teste et enkelt bruger scenarie når applikationen skal understøtte flere brugere. Benchmarke en distribueret applikation på en enkelt server. Ikke at tage højde for rigtige brugere, for eksempel på en hjemmeside bliver siderne læst, en bruger trykker ikke på links lige efter hinanden. At køre identiske forespørgsler lige efter hinanden, virkelige forespørgsler er ikke identiske. Ikke at tjekke for fejl hvis resultaterne ikke giver mening. For eksempel en langsom forespørgsle der pludselig bliver hurtig. At ignorere hvordan systemet yder når det ikke er varmet op, så som lige efter en genstart. Grunden til dette er at cachen er tom, og derfor kan man ikke måle hvordan systemet normalt yder. Der er dog tilfælde hvor man er interesseret i hvor lang tid der går for systemet er varmet op. At bruge serverens standard opsætning. Man skal selvfølgelig gå efter at gøre benchmarken så realistiske som overhovedet muligt, selvom det nogen gange giver mening at lave den mere eller mindre realistisk, for eksempel hvis databasen findes på en anden server. I det tilfælde vil det være realistisk at bruge den samme konfiguration, men det inkludere mange flere variable, så som hvor belastet netværket er. Derfor er det nemmere at benchmarke på en enkelt maskine, og i nogle tilfælde er det også præcist nok, men det bliver man nødt til at overveje i den enkelte situation Design og planlægning af benchmarks Den første og vigtigste ting er at finde problemet og målet, derefter bestemmer man om man vil bruge en standard benchmark eller designe sin egen. Hvis man vælger at bruge en standard benchmark er det vigtigt at man vælger den rigtige. Det er ikke en nem opgave at designe sin egen benchmark, det er kompliceret og tager lang tid. Til at starte med skal man tage en snapshot af det faktiske data, og sørger for at det er nemt at rulle tilbage

26 16 MySQL til flere gange. Derefter kører man forespørgsler i mod data. Det bedste måde at finde ud af hvilke forespørgsler der bruges, er at logge alle forespørgsler der bliver kørt i en vis periode, for eksempel på det tidspunkt af dagen hvor der er mest pres på serveren. Hvis man vælger at dele logningen op i mindre tidsintervaler, er det måske nødvendigt at logge i flere forskellige intervaler. Selv hvis man ikke laver sin egen benchmark, er det en god idé at skrive planen ned, da man skal køre benchmarken mange gange, og det er nødvendigt at kunne reproducere den så godt som muligt hver gang. Planen skal indeholde test data, opsætningen af systemet and hvordan systemet bliver varmet op. Find en måde at dokumenterer paramtere og resultater, og gør det for hver benchmark kørsel. Hvis benchmarken giver mulighed for at måle mere data end nødvendigt er det en god idé at gemme det ekstra data alligevel. Det er bedre at have ekstra data end at mangle data, og det ekstra data bliver måske brugbart senere. Det kan også en god idé at måle noget ekstra data, så som CPU tid, disk I/O, netværkstraffik, osv Hvordan får man brugbare resultater? Den bedste måde at få rigtige resultater på, er at sikre sig at man har valgt den rigtige benchmark, at man fanger det rigtige data og at man bruger de rigtige kriterier. For eksempel er det nytteløst at bruge en benchmark der undersøger CPU forbrug hvis man ved at det er mere interessant at undersøge I/O. Det næste man skal sikre sig er at man kan genskabe resultaterne, derfor skal man prøve at få den samme tilstand frem, inden man starter næste kørsel. Det kan for eksempel være en god idé at genstarte systemet mellem hver kørsel, specielt hvis det er en meget vigtig benchmark. Hvis det er vigtigt at systemet er varmet ordentligt op inde man køre sin benchmark, hvilket er meget normalt, er det også meget vigtigt at man sikre sig at opvarmnings perioden er lang nok og kan genskabes. Derfor er det ikke en god idé at varme systemet op med tilfældige forespørgsler, da opvarmningen i så fald ikke kan genskabes. Hvis benchmarken ændre på tabellens udformining eller data, skal den resettes med et nyt snapshot mellem hver kørsel. Data fragmeteringen og layouttet på harddisken kan også have betydning på ydeevnen, desværre kan dette ikke genskabes 100%, men kan kun genskabes tilnærmelsesvis ved hjælp af formaterring og kopiering af data, om det er nødvendigt i den specifikke benchmark er noget man må overveje under planlægningen. Man skal også sikre sig at alle resourcer der skal måles, ikke bliver brugt til andet end benchmarken. Dette kunne være et job der gik i gang under målingerne, hvis dette er tilfældet vil resultaterne ikke nødvendigvis være rigtige. Det er en god idé at ændre så få parametre som muligt mellem kørslerne. Hvis man ændre flere parametre på en gang, kan man hurtig overse noget. Der er dog et lille problem med dette, det er ikke altid man kan ændre en parameter uden at ændre en anden, og nogen gangen ved man ikke at flere parameter hænger sammen, hvilket kan gøre det besværligt. Generelt set hjælper det at ændre parameter iterativt, i stedet for store ændringer mellem kørslerne. Hvis man vil have gode resultater kan man ikke køre den samme benchmark efter en migrering fra en type database til en anden, for eksempel fra Oracle til MySQL, eller fra en storage engine til en anden, da forespørgsler og data struktur bliver håndteret forskellige. Det betyder at det kan være nødvendigt at ændre på databasens struktur, hvilket dermed betyder at man ikke kan bruge den samme benchmark igen. Hvis man får underlige resultater, skal man ikke uden videre smide det væk. Undersøg i det stedet og find ud af hvorfor det skete. Det kan være at man opdager at det er et vigtigt resultat, et stort problem, eller en fejl i benchmark designet.

27 2.6 Database Optimering Kørsel og analyse af resultaterne Det er generelt en god idé at automatisere kørslerne. Det vil gøre resultaterne mere korrekte, da det forhindre at man glemmer ting eller kommer til at gøre ting forskellige dem. Man skal prøve at automatisere så meget af processen som muligt, inklusiv loade data, opvarmning af systemet, kørsel af benchmark og gemmelse af resultater. Man bliver nødt til at køre benchmarken flere gange, hvor mange gange afhænger af hvordan man vil analysere resultaterne. Der er mange måder at analysere resultaterne på, og det kommer an på hvor vigtigt resultatet af analysen er, om man vil bruge statistiske metoder, om tager gennemsnitet, vil se hvor meget de variere eller hvad der nu målet med benchmarken. Det kan også anbefale at automatisere analysen af resultaterne, af samme grund som automatisering af kørslerne, for at kunne genskabe og dokumentere resultatet af analysen, samtidig med at det mindske analyse arbejdet Profiling Profiling viser hvor meget hver enkelt del af systemet har indflydelse på den total kørselstid. Normalt måler man hvor lang tid det tager at få et resultat, men det kan også være antallet af funktions kald, I/O operationer, database forespørgsler og så videre. Målet med profiling er at finde ud af hvorfor systemet gør som det gør, og hvad det gør. Ligesom med benchmarking kan man profile både full-stack og single-component. Normalt giver fullstack profilering bedre indtryk af hvordan applikationen kan optimeres, men da dette projekt handler om optimering af database delen, vil jeg ikke komme nærmere ind på full-stack profilering. Målet med MySQL profilering er at finde ud af hvor MySQL bruger det meste af sin tid henne. Man bestemmer selv hvilke dele af MySQL man vil profile. Nogle af dele der normalt er interessant er: Hvilken data MySQL tilgår mest. Hvilke typer forspørgsler MySQL eksekvere mest. Hvilken tilstand MySQL tråderne befinder sig mest i. Hvilke undersystemer MySQL bruger mest til at eksekvere en forspørgsel. Hvilken type data tilgang MySQL bruger mest under en forespørgsel. Hvor meget tid MySQL bruger på forskellige aktiviter, for eksempel skanning af indeks Logning af forespørgsler I MySQL er der to typer logs der indeholder forspørgsler, den generelle log og slow log. De bruges begge to til at logge forspørgsler, men de gør det i forskellige stadier af eksekveringen. Den generelle log logger alle forespørgsler så snart serveren modtager dem, derfor kan den indeholde forespørgsler der slet ikke er blevet udført på grund af fejl. Udover at logge alle forespørgsler, bliver oprettelse og afbrydelse af forbindelser også logget. Da alle forspørgsler bliver logget så snart serveren modtager dem, indeholde denne log ikke informationer om hvor lang tid forespørgslen har taget eller andre information der første er tilgængelige efter forespørgslen er udført. Modsat logger slow log kun

28 18 MySQL forespørgsler der er blevet udført, og har taget længere tid end en fastsat værdi. Begge logge kan være brugbare under profilering, men slow loggen er det vigtigste for at finde problematiske forespørgsler. Man kan finjustere hvilke forespørgsler der bliver logget i slow log, ved blandt andet at sætte hvor lang tid de må tage, om man vil logge alle forespørgsler der ikke bruger noget indeks lige meget hvor lang tid de tager, og om man vil logge administrative forespørgsler. Alt efter hvor mange forespørgsler der bliver logget, kan databasens ydeevne bliver nedsat og bruge meget diskplads på serveren. Da MySQL som standard ikke logger andet end forespørgslen i slow log, findes der en patch der logger mere information. Blandt andet forbindelses ID, informationer omkring forespørgsles cachen, type af join, midlertidige tabeller og sortering. Hvis man bruger InnoDB bliver informationer omkring I/O og låse også logget. Når man profilere er det en god idé at logge alle forespørgsler lige meget hvor lang tid de tager. Grunden til det er at hvis der er mange forespørgsler der ikke tager lang tid, kan de samlet set være grunden til at hele applikationen er langsom Hvordan profilere man? Der er flere måder man kan gøre dette på, man kan kigge på serverens status ved hjælp af en speciel forespørgsel, SHOW STATUS 5, og se mange informationer om hvad serveren har gjort. I MySQLs dokumentation findes der en liste over alle de informationer der bliver vist af SHOW STA- TUS, Alt efter forespørgslen er der forskellige informationer der er interessante, for eksempel i forbindelse med ORDER BY er sort merge passes interessant. I andre tilfælde, for eksempel med indeks skanninger er de fleste Handles status variabler interessante. For at få det rigtig indtryk af variablerne, skal man nulstille dem ved hjælp af, FLUSH STATUS, da de ellers tæller op og det gør det svært at se deres nøjagtige værdi. Jeg vil komme nærmere ind på de forskellige variables betydning, hvis de bliver taget i brug i løbet af projektet. Profilering hænger meget sammen med forespørgsels optimering, afsnit 2.6.3, da brugen af EXPLAIN funktionen kan give en god idé om hvilke status variabler man skal kigge på. Det kan blandt andet være at en forespørgsel medføre en filesort 6, og dermed er sort merge passes variablen interessant. Profilering er en videnskab i sig selv og derfor er det uden for dette projekts rammer, at beskriver mere om hvordan man profilere. Profilerings metoder der bliver taget i brug under projektet, vil selvfølgelig blive forklaret nærmere når de bliver brugt Forespørgsels optimering Går ud på at optimere de forespørgsler der bliver udført. Dette kan blandt andet hjælpe en med at finde ud af hvordan man opbygger database bedst muligt, og hvilke kolonner der skal være indeks på. Til at hjælpe med at optimere forespørgsler findes der en SQL funktion i MySQL der hedder EXPLAIN 7. Denne funktion kan vise hvordan MySQL vil udføre forespørgslen, for eksempel om den

29 2.6 Database Optimering 19 vil bruge indeks eller ej, hvilket indeks den vil bruge, om der vil blive lavet midlertidige tabeller og andre ting, der kan hjælpe med at optimere forespørgslen. Målet med forespørgsels optimering er i langt de fleste tilfælde at et indeks bliver brugt, således at disken bruges mindst muligt. På MySQLs web side findes der en ganske udemærket forklaring af hvordan man bruger EXPLAIN, html. Da EXPLAIN er forholdsvis simpel at forstå, vil jeg ikke gå nærmere i detaljer med den. Det kan være svært præcist at finde ud af hvad man skal gøre for at optimere forespørgslen, men det har ikke noget med EXPLAIN at gøre, men mere om hvordan indeks virker, osv. Det skal nævnes at EXPLAIN ikke altid er 100% korrekt, men at den er det i langt de fleste tilfælde. Grunden til det er at forespørgslen ikke bliver udført, men kun simuleret.

30 20 MySQL

31 Kapitel 3 Introduktion til optimeringsmetoder I dette kapitel vil jeg give en kort introduktion til mulige optimeringsmetoder, dog der findes mange flere muligheder end beskrevet her. Det betyder at jeg vil kigge de fordele og ulemper der er ved dem, om de har den ønskede fleksibilitet, osv. Udfra dette vil jeg udvælge et par metoder som vil blive undersøgt nærmere, og derefter blive designet, implementeret og testet. Dette kapitel vil blive delt om i almindelige rækkebaserede databaser, kolonnebaserede databaser og andre metoder. Grunden til det er at der er meget forskel på hvordan disse optimerings ting fungere. Kolonnebaserede databaser fungere ved at data bliver gemt efter kolonner i stedet for rækker. For at illusterer dette vil jeg bruge følgende data: EmpID Lastname Firstname Salary 1 Smith Joe Jones Mary Johnson Cathy En almindelig rækkebaseret database vil gemme data således: 1,Smith,Joe,40000;2,Jones,Mary,50000;3,Johnson,Cathy,44000; En kolonnebaseret database gemmer i stedet data således: 1,2,3;Smith,Jones,Johnson;Joe,Mary,Cathy;40000,50000,44000; Kolonnebaserede databaser er ikke en ny tanke, blandt andet Sybase IQ er kolonnebaseret. Denne database type bliver oftes brugt i forbindelse med datawarehousing, hvilket Dubex s log database på sin vis også er. Under de rette omstændigheder er der fordele ved kolonnebaserede løsninger, blandt andet: Effektiv når der er meget data der skal læses fra adskillige rækker, men at det ikke er mange kolonner der skal bruges data fra.

32 22 Introduktion til optimeringsmetoder Effektiv når alle nye værdier i en kolonne er givet for alle rækker på en gang, da kolonne data kan skrives mere effektivt. Data kan nemmere komprimeres da datatypen er ens for al data i kolonnen, og kolonnerne er gemt sammen. Der er dog også visse ting rækkebaserede databaser er bedre til: Når mange kolonner i den samme række skal bruges på samme tid. Når al kolonne data bliver givet på en gang for hver række. Fordelene ved kolonnebaserede databaser passer godt ind i den ønskede fleksibilitet og de mange NULL værdier der bliver gemt i databasen. Det er også muligt at kende en hel del af en kolonnes data på en gang, da log data bliver modtaget relativt få gange i løbet af dagen, men meget af gangen. 3.1 Rækkebaserede databaser (Row-oriented databases) ScaleDB ScaleDB er en transaktionel storage engine til MySQL. ScaleDB bruger en ny metode til at lave indeks med, som de kalder multi-table relationship-aware index. Et normalt B-Tree indeks virker kun på en table, den type indeks der bliver brugt i ScaleDB kan fungere over flere tabeller. Fordelen ved denne type indeks er at man slipper for at lave JOINs i mellem flere tabeller, hvilket er ofte tager lang tid da det er meget CPU intensivt, specielt på store tabeller. Man kunne umiddelbart tror at dette ville betyde at indekset ville fylde meget, da det indeholder meget mere data, det er dog, i følge ScaleDBs dokumentation, ikke tilfældet, rent faktisk fylder indekset typisk syv gange mindre end et B-Tree indeks. Derfor vil databasens ydeevne kunne forbedres væsentligt hvis denne type indeks bliver brugt i database der er designet til det. Selvom der er store ændringer i hvordan et indeks fungere i ScaleDB har det ikke nogen indflydelse på de SQL sætninger der skal bruges, og derfor er det ikke nødvendigt at lave nye SQL sætninger for at bruge ScaleDB. ScaleDB har også indbygget mulighed for clustering, dette er dog ikke noget der vil blive kigget nærmere på, da det ikke er nødvendigt på nuværende tidspunkt. Dette kan dog ændre sig i fremtiden, så det er en god funktion at have. Ulempen ved ScaleDB er at det er et kommercielt produkt og at det på nuværende tidspunkt endnu ikke er færdig udviklet. Det er dog muligt at deltage i et beta program. Grundet at produktet endnu ikke er færdig udviklet, er det ikke relevant i denne sammenhæng, da det ikke er tilfredstillende at bruge et beta produkt i produktions miljøet. Men ScaleDB er alligevel et meget interessant produkt, som der umiddelbart er store muligheder i når det er færdig udviklet MyISAM optimering Den nuværende database bruger MyISAM som storage engine, hvilket der både er fordele og ulemper i. Det er muligt at databasens ydeevne kan forbedres ved at designe tabeller og/eller forespørgslerne anderledes, for eksempel ved hjælp af normalisering og nye indeks. Man kan også formindske størrelsen på databasen ved at bruge den indbyggede MyISAM komprimering af tabeller der ikke skal opdateres længere. Der findes som tidligere beskrevet, en variant af MyISAM der gør det muligt at lave virtuelle

33 3.2 Kolonnebaserede databaser (Column-oriented databases) 23 tabeller, kaldet Merge tabeller som kan vise flere ens tabeller som en enkelt tabel, hvilket kan være brugbart i dette tilfælde. Da MyISAM er blevet beskrevet tidligere, se afsnit 2.5.1, vil jeg ikke gå mere i detaljer omkring den i dette afsnit InnoDB Selvom der ikke umiddelbart er det store behov for transaktioner i log databasen, kan man ikke uden at teste det sige om InnoDB yder dårligere eller bedre end MyISAM, som den nuværende database bruger. På MySQL Performance Blog 1, findes der en test der sammenligner ydeevnen mellem MyISAM og InnoDB, som viser at InnoDB er væsentligt hurtigere end MyISAM til nogle forspørgsler, og generelt ikke har meget dårligere ydeevne end MyISAM. InnoDB er blevet beskrevet tidligere i denne rapport, se afsnit 2.5.2, og vil derfor ikke blive beskrevet mere i dette afsnit. 3.2 Kolonnebaserede databaser (Column-oriented databases) Infobright Infobright er en transaktionel storage engine til MySQL, og gemmer data ligesom en kolonnebaseret database. Infobrights mål er at minimere harddisk I/O og kun at tilgå den nødvendige data. For at løse disse problemer har Infobright udviklet en helt unik arkitektur, som er baseret på følgende koncepter: Kolonnebaseret database Data Packs og Data Pack Nodes Knowledge Nodes og the Knowledge Grid Optimering Data komprimering Data Packs er et koncept der kun bliver brugt i Infobright, og er i bund og grund bare en mindre antal data grupperinger der ligger tæt på hinanden og derfor kan komprimeres bedre. Data Pack Nodes (DPNs) indeholder statistiker omkring data i hver enkelt Data Pack, det betyder at Infobright har informationer omkring al data i databasen, og ikke kun omkring de kolonne der er indeks på. Knowledge Nodes (KNs) indeholder noget metadata relateret til Data Packs eller kolonne relationer. De fleste KNs bliver lavet under load time, men andre bliver lavet i forbindelse med forespørgsler for at optimere ydeevnen. Knowledge Grid bliver dannet udfra DPNs og KNs, og kræver ikke nogen vedligholdelse ligesom normale indeks gør. I bund og grund giver Knowledge Grid en overordnet oversigt over databasens indhold. Infobrights optimerings mekanisme er den højeste intelligens niveau i arkitekturen, og den bruger Knowledge Grid til at bedømme den mindste antal af Data Packs der skal dekomprimeres, for at udføre en forespørgsel hurtigst muligt. Til sammen betyder dette at Inforbright ikke bruger traditionelle indeks, men i stedet bruger Data Packs, Data Pack Nodes, Knowledge Nodes og Knowledge Grid til at udføre komplicerede forespørgsler. Et overordnet billeder over Inforbrights arkitektur kan ses på figur

34 24 Introduktion til optimeringsmetoder Figur 3.1: Infobright arkitektur Figur 3.2: Kickfire system Kickfire Kickfire prøver at løse problemerne med den begrænsede overførselshastighed mellem hukommelse og CPU (von Neumann bottleneck 2 ), og mellem harddisk og hukommelse (I/O bottleneck). Måden problemerne bliver løst på er ved hjælp af en specielt udviklet chip, SQL chip, som håndtere forespørgsler på en bestemt måde. Til at starte med bliver SQL forespørgslen brydt ned til en parallel eksekverings plan, som bliver sendt ind i SQL chippen som processere det parallelt. SQL chippen får data direkte fra hukommelsen, hvilket gør den meget hurtigere end normale servere kan klare. For at løse I/O problemet bruger Kickfire en kolonnebaseret database, komprimering, en stor centraliseret hukommelse og indeks til kun at hente det nødvendige data. For at bruge Kickfire systemet kræver det at man køber nyt hardware. Grunden til dette er at man skal have en af de såkaldte SQL chips. Der er to muligheder for at anskaffe sig sådan en, enten kan man købe en Kickfire appliance der i princippet er en lille server, eller man kan købe et PCI kort hvorpå SQL chippen sidder. Se også figur

35 3.3 Full text scearch engine 25 Med Kickfire følger deres egen storage engine som er kolonnebaseret, hvilket er med at til forbedre ydeevnen. Med Kickfire appliancen følger der et storage system, men man kan også tilføje ekstern storage således at man nemt kan tilføje mere plads. 3.3 Full text scearch engine Sphinx Sphinx er en full-text search engine, og har ikke noget direkte med MySQL at gøre. Sphinx er meget hurtig til at indeksere og søge i tekst. Selvom Sphinx er beregnet til tekst, er det måske muligt at kunne forbedre databasens ydeevne ved at lade Sphinx håndtere alle indeks i stedet for MySQL. Sphinx undersøtter automatisk henting og indeksering af data fra MySQL tabeller. Det er på nuværende tidspunkt dog ikke muligt at opdatere indeks på andre måder end ved at køre indekserings programmet på Sphinx serveren. Ved at give Sphinx ansvaret for at holde styr på indeks og returnere tabellens primær nøgle, som der er hurtigt database opslag på, kan man muligvis forbedre databasens ydeevne.

36 26 Introduktion til optimeringsmetoder

37 Kapitel 4 Udvalgte optimeringsmetoder Efter at have undersøgt de forskellige metoder i afsnit 3, har jeg udvalgt tre metoder, som vil bliver undersøgt mere detaljeret, samtidig med at der vil de vil blive designet, implementeret og teste i forhold til den nuværende database struktur. Jeg har valgt at undersøge følgende metoder nærmere: Infobright storage engine, afsnit MyISAM optimering, afsnit Sphinx, afsnit

38 28 Udvalgte optimeringsmetoder 4.1 Infobright Teori Infobright er en kolonnebaseret database, hvilket gør det muligt at komprimere data meget effektivt, samtidigt med at det er muligt kun at hente enkelte kolonner i database, og ikke alle kolonner per række. Infobright har som tidligere beskrevet en meget speciel data struktur, som vil blive beskrevet mere i dette afsnit Data Packs (DPs) Al data i kolonnerne er gemt i grupperinger på enheder, kaldet Data Packs. På grund af dette er det muligt at komprimerer det bedre, da enhederne ligger tættere på hinanden og at komprimerings algoritmen kan vælges på baggrund af data type Data Pack Nodes (DPNs) En Data Pack Node indeholder analytisk data omkring indeholdet af en Data Pack. For eksempel bliver der for numeriske data typer gemt følgende: Minimum værdi. Maximum værdi. Summen af værdierne. Antallet af elementer der ikke er NULL. Antallet af elementer. Alle Data Packs har en tilsvarende Data Pack Node. Fordelen ved Data Pack Nodes er at de kan tilgås uden at dekomprimere de tilsvarende Data Packs, hvilket betyder at Infobrigth ved kigger på Data Pack Nodes kan finde ud af om det er nødvendigt at dekomprimere en Data Pack. Samtidig betyder det at en Data Pack Node indeholder alle de informationer der er nødvendige for at optimere og eksekvere en forespørgsel Knowledge Nodes (KNs) Knowledge Nodes findes for effektivt at håndtere komplekse, multi-tabel forespørgsler, for eksempel joins, underforespørgsler, osv. De indeholder flere avancerede informationer omkring relationerne mellem data i databasen, både på flere tabeller, flere kolonneer og enkelte kolonner. Det gør det muligt at identificere antallet Data Packs involveret i en forespørgsel, og dermed at minimere antallet af dekomprimeringer. Knowledge Nodes kan sammenlignes med traditionelle database indeks, dog virker Knowledge Nodes på Data Packs i stedet for rækker. Da en Data Pack indeholder rækker, betyder det at Knowledge Nodes er gange mindre end traditionelle indeks. I forbindelse med Pack-to-Pack nodes, som viser relationer mellem data i forskellige tabeller, er de * gange mindre, da indeks i begge tabeller skal regnes med. I følge Infobright er overheadet i Knowledge Nodes generelt 1% af data, sammenlignet med traditionelle indeks som kan være mellem 20% og 50% af datas størrelse.

39 4.1 Infobright 29 Knowledgde Nodes bliver automatisk lavet under data indlæsning, men de kan også blive lavet under en forespørgsel, og kan dermed bruges til at optimere ofte udførte forespørgsler. Al vedligeholdelse bliver udført automatisk og derfor er der ikke behov for at en database administrator blander sig, som det er tilfældet med traditionelle indeks Knowledge Grid (KGet) Knowledge Gridet består af Data Pack Nodes og Knowledge Nodes. Ved at kigge på Knowledgde Gridet kan Infobright optimere mange forespørgsler uden at kigge på den faktiske data, hvilket giver en bedre performance, da data ikke skal dekomprimeres med mindre det nødvendigt. For at kunne håndtere joins og underforspørgsler mellem tabeller, kan Knowledge Gridet bruge såkaldte Pack-to-Pack Knowledge Nodes, der fungere på tværs af tabeller. Pack-to-Pack Nodes indikere hvilke Data Packs fra tabellerne der skal overvejes når man lave en join på tabellerne. Forspørgsels optimeringen er også lavet således at Pack-to-Pack Nodes kan blive brugt sammen med andre Knowledge Nodes Optimizer Optimizeren er det højeste intelligens niveau i Infobright arkitekturen. Den bruger Knowledge Gridet til at finde ud af hvor mange Data Packs, der skal dekomprimeres for at opfylde en forspørgsel hurtigst muligt. Udfra Knowledge Nodes og Data Pack Nodes deler optimizeren Data Packs op i tre forskellige kategorier: Relevante Data Packs Indikere Data Packs der baseret på Knowledge Gridet, kun indeholder relevant data i forhold til den givede forespørgsel. Irrelevante Data Packs Indikere Data Packs der baseret på Knowledge Gridet, ikke indeholder relevant data. Suspect Data Packs Indikere Data Packs hvor det ikke er muligt udfra Knowledge Gridet, at bedømme om de er fuldstændig relevante eller irrelevante. Udfra disse kategorier kan optimizeren finde ud af hvilke Data Packs det er nødvendigt at dekomprimere, for at kunne svare på forespørgslen. For eksempel bliver de irrelevante Data Packs ikke dekomprimeret da optimizeren ved at de ikke indeholder noget data der skal bruges for at svare på forespørgslen Lookup tabeller Lookup kolonner bruges til at lave hurtige opslag i CHAR og VARCHAR kolonner. Måden det fungere på er at tekststrengen bliver byttet ud med med en integer, der henviser til det det oprindelige tekststreng. Hvis der er relativt få unikke værdier i en tekst kolonne, kan lookup tabeller være meget effektive. Selve lookup tabellerne bliver automatisk oprette og vedligeholdt af Infobright, hvis man indikere at der skal oprettes en til en kolonne.

40 30 Udvalgte optimeringsmetoder Figur 4.1: Inforbright Data Loading

41 4.1 Infobright Data Loading Når data bliver indlæst bliver værdier i den udvalgte kolonne behandlet som en sekvens med nul eller flere NULL værdier, som kan eksisterer hvor som helst i sekvensen. Informationer omkring NULL bliver gemt i Null Masken. De resterende værdier der ikke er NULL bliver derefter komprimeret, og dermed bliver regulariteten i data udnyttet fuldt ud. Figur 4.1, illustrere hvordan Inforbright indsætter data. Algoritmen til data indsættelses bruger flere tråde, hvilket gør det muligt at indsætte kolonne data parallelt. På grund af det er muligt at indsætte data meget hurtigt, samtidigt med at data bliver komprimeret. I følge Infobright vil en enkelt tabel i gennemsnit kunne indsætte 100 GB data per time Fordele og ulemper Fordele Data komprimering: På grund af den kolonne baserede struktur kan data komprimeres meget effektivt, hvilket betyder at databasen ikke komme til at fylde ret meget. Data loading: Da data loading bruger flere tråde, er indsættelse af data meget hurtig i forhold til standard MySQL. Kolonne baseret: Hurtig udtrækning og indsættelse af meget kolonne data. Se afsnit 3.2 for forklaring på dette. Lookup tabeller: Lookup tabeller kan bruges til at lave hurtige opslag i CHAR og VARCHAR kolonner. Minimum dekomprimering: På grund af Knowledge Gridet er det kun det nødvendige data der bliver dekomprimeret ved hver forespørgsel Ulemper Unsigned datatyper: Der er ingen support for unsigned datatyper, hvilket betyder at meget data skal gemmes i en tilsvarende større datatype. Dette behøver dog ikke nødvendigvis at have indflydelse på ydeevnen. Indeks: Der er ikke nogen indeks support, da Knowledge Gridet har overtaget denne funktion. Selvom dette reelt skulle have indflydelse på ydeevnen, gør det dog database mindre fleksibel da man ikke kan udnytte specielle former for indeks. MySQL Installation: På grund af den specielle Inforbright optimizer, skal man have en specielt udviklet MySQL installation. Det betyder at man ikke selv har fuld kontrol over hvilken MySQL Server version der bliver brugt. Samtidig er der i denne version, ikke installeret alle de storage engines, der følger med standard MySQL server, for eksempel er InnoDB ikke installeret. Kolonne baseret: Langsom udtrækning og indsættelse af meget række data. Se afsnit 3.2 for forklaring på dette. Optimerede funktioner: Det er ikke alle SQL funktioner der er optimeret til at benytte Knowledge Grid i Infobright, hvilket betyder at der ikke er alle funktioner der drager fordel af Infobright strukturen. En liste over optimerede SQL funktioner kan findes på Infobright s Wiki 1. Hvis man bruger en SQL funktion der ikke er optimeret til Infobright, bliver standard MySQL optimizeren brugt i stedet. 1

42 32 Udvalgte optimeringsmetoder Begrænsnigner i Open Source version: Der er forskellige begræsninger i Infobright Open Source udgave. Blandt andet er det ikke muligt at bruger INSERT, SELECT INTO, TRUNCATE eller DELETE sætninger, på tabeller der bruger Infobright storage engine. Det er dog muligt at bruge disse funktioner i den kommercielle udgave af Infobright Design Til at starte med vil designet af tabellen være det samme som den nuværende database. Grunden til dette, er at jeg godt kunne tænke mig at finde ud af hvordan databasen ville yde, hvis database layoutet ikke ændre sig. Der er dog visse ting der skal ændres for at databasen kan implementeres i Infobright, blandt andet er der ikke support for indeks eller unsigned datatyper. Derfor vil databasen blive designet således: Navn eventid datetime module action srcip dstip proto rule srcport dstport xlatesrc xlatedst xlatesport xlatedport resource user msginfo product type alert ifname sysmessage reason htime srcif dstif bytestx Datatype BigInt Datetime SmallInt SmallInt BigInt BigInt SmallInt MediumInt MediumInt MediumInt BigInt BigInt MediumInt MediumInt Varchar(255) Varchar(255) MediumInt MediumInt MediumInt MediumInt MediumInt Varchar(255) MediumInt SmallInt SmallInt SmallInt Bigint Se figur 6.1 for diagram over den nuværende database struktur, hvilket er den samme Implementering Da Infobright storage engine bruger sin egen optimizer og ikke standard MySQL optimizeren. Er der en specielt udviklet version af MySQL man skal bruge. Dette gør det lidt mere besværligt at overføre

43 4.1 Infobright 33 data mellem standard MySQL og Infobright. Både på grund af den nye installation, men også på grund af de begrænsninger der er nævnt for oven, i afsnit Derfor består implementeringen udelukkende i at installere den specielle MySQL server, lave tabellerne og indsætte data fra bulk filerne.

44 34 Udvalgte optimeringsmetoder 4.2 MyISAM optimering Teori Det er måske muligt at forbedre den nuværende databases ydeevne ved at ændre på datastrukturen, optimere forespørgslerne, ændre på indeks eller redigere indstillinger på serveren Normalisering Hvis databasen bliver normaliseret burde størrelsen på databasen blive mindre, men der er dog visse problemer ved en fuld normalisering, blandt andet bliver det svært at gøre databasen fleksible. Grunden til det er at der lige pludseligt bliver meget arbejde i at understøtte nye typer log data, for eksempel skal der oprettes nye tabeller, indeks og lignende så snart der er en anden type data der skal gemmes, det er dog en mere rigtig måde at gøre tingene på end den nuværende struktur. Fordelen ved normaliseringen er at man relativt nemt kan nøjes med at hente det nødvendige data, og at indeks bliver nemmere at vedligeholde. Ulempen er tilgengæld at det bliver nødvendigt med mange joins, hvilket er meget CPU krævende. Derfor er det vigtigt at finde ud af hvor mange joins der normalt er behov for og før det er klarlagt, er det ikke muligt at bedømme om dette er en metode der kan bruges i fuld udstrækning. Normalisering kan også forhindre forskellige typer af indeks som ellers kunne forbedre ydeevnen, da indeks ikke kan laves over flere tabeller. Med den type database der findes i dette projekt, vil det ikke være optimalt at normalisere databasen fuldt ud. På grund af databasens størrelse vil de joins der er nødvendige i en normaliseret database, blive meget tunge at udføre. Derfor kunne en mulig løsning på det problemet være kun delvist at normalisere databasen. Det er desværre bare ikke en særlig god løsning i dette tilfælde, da data er meget varierende og der kun er få kolonner der har mange ens værdier, for eksempel er srcip og dstip de eneste kolonner der ville give mening at normalisere, da de har relativ lav variation Indeks optimering Indeks optimering går som navnet siger ud på at optimere indeks mest muligt. For at dette kan gøres kræves der en stor forståelse for hvad databasen indeholder og hvordan data skal bruges. I forbindelse med den nuværende database kan indeks godt optimeres, hvilket dog med rimelig stor sandsynlighed vil gøre databasen større og kræve mere hukommelse. Hvis indeks bliver meget store skal man huske at indeks kræver tilfældig I/O for at blive læst, hvilket tager relativt lang tid og derfor kan en fuld tabel skanning være hurtigere. Der er flere forskellige måde at optimere indeks på, for eksempel kan man ændre server variabler der er med til at bestemme hvor meget af indeks der ligger i hukommelsen eller man kan ændre på udformningen af indeks. På grund af den specielle struktur der er i den nuværende database, er det umuligt at lave indeks der dækker alle mulige søgninger. Men det er dog muligt at sikre sig at de forespørgsler der altid bliver udført på samme måde, for eksempel statistikgenerering, bliver dækket af et indeks. Man kan aldrig få dækket alle de logsøgninger der er mulige, men man kan oprette indeks på de kolonne der bliver brugt oftest og dermed hjælp så meget man kan. Hvis man bruger mange indeks skal man også tage højde for langsom data indsættelse, da indeks skal ændres og muligvis genskabes helt hver gang der bliver indsat ny data, hvilket gør at indsættelse af data kan blive meget langsomt.

45 4.2 MyISAM optimering 35 Optimering af indeks vil ikke gøre databasen mere fleksibel, da der overhovedet ikke er nogen relation mellem fleksibilitet og indeks Komprimering Som nævnt i afsnit understøtter MyISAM enginen komprimering, dog skal det nævnes at så snart en tabel er blevet komprimeret kan man ikke længere redigere i den. I forhold til log databasen er dette ikke noget problem, da der findes en seperat tabel for hver dag, så man kan nemt sige hvilke tabeller der ikke længere skal redigeres i. For at komprimere en MyISAM tabel skal man bruge et specielt program, myisampack 2, som køres på serveren, det er ikke muligt at komprimere MyISAM tabeller ved at bruge specielle SQL funktioner. Ved at komprimere tabeller kan man formindske databasens størrelse væsentligt, i følge MySQL dokumentationen normalt 40%-70% mindre. Ulempen er at ydeevnen også kan forringes hvis man henter meget data ad gangen, da rækkerne bliver komprimeret enkeltvis Forespørgsels optimering Ved at undersøge de forespørgsler der bliver udført, kan man se om det er muligt at optimere dem. Både med hensyn til indeks, omskrivning eller ændring af server variable. Ud fra testen af den nuværende database kan man tydeligt se at statistikgenererings delen er langsom. Når man kigger på forespørgslerne der bliver udført under statistikgenerering, ser man at der bliver gjort brug af GROUP BY, som kan være meget langsom hvis der ikke findes et indeks der kan bruges. I så fald vil der enten bliver brugt en midlertig table eller filesort 3, alt efter forespørgslen kan den en ene eller anden metode være bedst, ved at bruge en af følgende optimizer hints, SQL BIG RESULT 4 eller SQL SMALL RESULT, kan man tvinge optimizeren til at vælge en af metoderne. Hvis det er filesort der bliver brugt kan man ved hjælp af server variable sort buffer size være med til at bestemme hvilken hvor mange sort merges 5 der sker. Hvis man vil optimere GROUP BY ved hjælp af indeks kan man bruge et loose eller tight index scan som er beskrevet i MySQL dokumentationen under GROUP BY Optimization 6. Ud over dette indeholder forespørgslen også en unødvendig ORDER BY som gør at der bliver oprette en midlertidig table mere. På grund af de meget frie rammer der omkring log søgninger er det meget svært at optimere dem. Man kan ikke rigtig ændre på forespørgslens struktur, da den bliver bestemt af brugeren. Det bedste man kan gøre er at lave enkelt kolonne index på de kolonne der ofte bliver søgt på. Hvis man kun søger på kolonner der ikke er indeks noget indeks på, vil en fuld tabel skanning blive udført Justering af server variabler Ud over de justering der kan forekomme i forbindelse med forespørgsels optimeringen, er der også andre variable der er vigtige for MyISAM, for eksempel bulk insert buffer size 7 og key buffer size

46 36 Udvalgte optimeringsmetoder Den vigtigste variable i MyISAM er key buffer size. Til forskel fra andre storage engines, cacher My- ISAM kun indeks, ikke data (det lader den operativ systemet om), og hvis man bruger MyISAM meget, er det derfor en god idé at tildele meget hukommelse til indeks. I følge forfatterne af High Performance MySQL, skal man prøve at sætte denne buffer til 25%-50% af den mængde hukommelse man har afsat til sine caches. En anden variable er der være brugbar i forhold til sortering og grupperinger er, read rnd buffer size 9. Den definere størrelse på en speciel buffer der bliver brugt til at hente sorteret data fra hukommelsen, i stedet for at læse fra disken. Den har dog alligevel begrænset brug i nyere version af MySQL, på grund af en ny filesort algoritme, kaldet single-pass 10. Single-pass algoritmen vil blive brugt hvis størrelsen af alle kolonner i forespørgslen er mindre end max length for sort data 11 variablen. Hvis single-pass algoritmen bliver brugt har read rnd buffer size variablen ingen betydning, da den kun bliver brugt i two-pass algoritmen, til at læse alle rækker efter de er blevet sorteret. Variablerne tmp table size 12 og max heap table size 13 sætter tilsammen maksimum størrelse på midlertidige tabeller i hukommelsen. Hvis en midlertidig tabel bliver større end denne værdi, bliver den lagt ned på disken. read buffer size er en variable der definere hvor stor en læse buffer der bliver brugt under skanning af en hel tabel. På MySQL Performance Blog er der en test hvor det tydeligt fremgår, at det ikke nødvendigvis er smart at bruge en meget stor buffer, se /09/17/mysql-what-read_buffer_size-value-is-optimal/. MyISAM bruger en speciel træ ligende cache til at optimere bulk data indsættelse. Variablen bulk insert buffer size sætter cachens maksimum størrelsen per tråd, hvis cachen bliver større end denne værdi, bliver den ikke brugt og dermed går bulk data indsættelse langsommere Fordele og ulemper Fordele Backup Det er meget nemt at tage backup af en MyISAM tabel, da selve filerne på serveren uden problemer kan kopieres en andet sted hen. Komprimering Der er mulighed for at komprimere gamle data, som ikke bliver brugt så meget. Opstilling Der skal ikke bruges meget tid på at sætte det nye system op, da det meste findes i forvejen, og det kun er nogle få ting der skal ændres eller tilføjes. Små indeks MyISAM har i forhold til mange andre storage engines små indeks Ulemper Hænge fast Da optimeringen kun medføre at der bliver ændret eller tilføjet nye ting, kan man hurtigt komme til at hænge fast i den gamle tankegang, og dermed formindske udbyttet af optimeringen. Indeks og I/O MyISAM kan kun i meget få tilfælde hente reelle værdier fra indeks, hvilket betyder at MyISAM ofte skal læse på rækken fra disken alligevel

47 4.2 MyISAM optimering Design Komprimering Der kræves ikke noget specielt design for at komprimere en MyISAM tabel, og derfor vil dette ikke have indfyldelse på designet Tabel struktur I forbindelse med denne optimering er der en lille ændring i tabelstrukturen, kolonne datetime er blevet erstatte af kolonnen time, der til forskel kun gemmer tidspunktet i stedet for også at gemme datoen. Denne ændring betyder at hver række kommer til at fylde 3 byte mindre. Den nye database diagram ser således ud: Forespørgsels optimering Statistik generering Forspørgslen ser således ud,?-tegnene viser at disse værdier ændre sig fra gang til gang: SELECT module, datetime, htime,?, srcip, dstport, proto, COUNT(dstport), COUNT(DISTINCT dstip), SUM(bytestx) AS hits FROM... WHERE module =? AND action =? AND proto IS NOT NULL AND srcif =? AND dstif =? GROUP BY srcip, dstport, proto, datetime, htime, module ORDER BY srcip, hits Ved at køre en EXPLAIN, afsnit 2.6.3, kan man se at forespørgslen bliver udført på følgende måde: 1. Skanner en del af indekset module for at finde delvist matchende rækker. 2. Skanner rækkerne fundet ud fra indekset for at se om de opfylder resten af WHERE. 3. Opretter en midlertidig tabel. 4. En filesort bliver udført. Hvis modulet defineret i WHERE findes i rigtig mange rækker, vælger MySQL at udføre en fuld tabel skanning i stedet, dette kan ændres ved at bruge FORCE INDEX 14, men med test data viser det sig at en fuld tabel skanning er hurtigere end at bruge indeks, og derfor lader vi MySQL vælge selv. Hvis man fjerner ORDER BY, som er unødvendig i forhold til statistik genereringen, forsvinder punkt 3. Flere af de informationer der bliver trukket ud står også i WHERE og er derfor ikke nødvendige og bliver fjernet, det er module, 1 og htime. Det hjælper ikke synderligt på databasens ydeevne, men 14

48 38 Udvalgte optimeringsmetoder Figur 4.2: Database diagram der viser den ændrede tabelstruktur

49 4.2 MyISAM optimering 39 betyder at der bliver sendt mindre data tilbage til brugeren. På grund det data forespørgslen henter, er det ikke muligt at gruppere ved hjælp af indeks, hverken med loose eller tight index scan, men på grund af indekset module, er det ofte der ikke er særlig mange rækker der skal grupperes hvilket gør at det ikke kræver så meget. Efter optimering ser forespørgslen således ud: SELECT srcip, dstport, proto, COUNT(dstport), COUNT(DISTINCT dstip), SUM(bytestx) AS hits FROM... WHERE module =? AND action =? AND proto IS NOT NULL AND srcif =? AND dstif =? GROUP BY srcip, dstport, proto For at se om man kan optimere sorteringen mere, kan man ændre på server variablen sort buffer size, man skal dog være opmærksom på at en stor buffer ikke nødvendigvis forbedre ydeevnen, men faktisk kan forringe hastigheden på forespørgsler hvor der kun er lidt data der skal grupperes eller sorteres. Da der er i test data oftest ikke bliver grupperet særligt meget data ad gangen, er det sandsynligvis en relativt lille buffer der virker bedst. Test viser at en god størrelse på bufferen er standard størrelsen, 2 MB, dette kan dog godt være anderledes i produktionsmiljøet da der er data fra flere kunder. Logsøgning Man kan ikke rigtigt optimere logsøgnings forespørgslerne, da de i bund og grund bliver bestemt af brugeren. Om forespørgslerne kan man dog sige, at der er indeks på de kolonner der bliver søgt i oftest, og hvis man søger på flere dage ad gangen, vil der altid blive oprette en midlertidig tabel som der bliver udført en fuld tabel skanning på, det skyldes den UNION der bliver brugt til returnere alle resultaterne på en gang Justering af andre server variable Det er meget svært at fastsætte server varibale i andre miljøer end den rigtige, grunden til dette er at der er rigtig mange faktore der spiller ind, blandt andet antal samtidige forbindelser til server og hvor mange forspørgsler der bliver udført ad samtidigt og deres type. En anden ting der spiller ind er også hvor meget hukommelse maskinen har, da det hovedsagligt er buffere der bliver justeret, det betyder at man kan blive nødt til at sætte forskellige buffere til andet end det optimale, da der ellers ikke er nok hukommelse til andre buffere. På grund af det er de værdier der er fundet frem til i dette afsnit ikke nødvendigvis de bedste til produktionssystemet, men kan give et indtryk af hvilke variable man kan kigge på for at forbedre ydeevnen, men som udgangspunkt er de kun optimale i det testsystem der er opstillet til formålet. read rnd buffer size Da størrelse på kolonner der skal sorteres i denne database altid er mindre end max length for sort data, standard værdi er 1 KB, bliver single-pass algoritmen altid brugt, og read rnd buffer size variablen har derfor ingen indflydelse. Derfor bliver standard værdien på 256 KB ikke ændret. bulk insert buffer size Ligesom med mange andre buffere har denne buffer også en optimal størrelse. Ved hjælp af test har jeg fundet ud af at standard størrelse på denne buffer, 8 MB, ikke er stor nok i denne database. Test har i stedet vist, at for hurtigst muligt indsættelse af data, skal størrelsen ligge på MB. Lige

50 40 Udvalgte optimeringsmetoder som med de fleste andre server variabler, kan dette ændre sig i produktion på grund af andre caches hukommelses forbrug, eller en anden størrelses fordeling af bulk filer. key buffer size Jeg har valgt at følge anbefalingen fra High Performance MySQL, og sætter key buffer size til 50% af hukommelse der er afsat til caches. Grunden til det er at jeg gerne vil have så mange indeks i hukommelsen som muligt, da det er hurtigt at læse dem derfra. Det betyder at jeg sætter key buffer size til 512 MB på min egen maskine med 2 GB RAM, og 1GB på serveren som har 4 GB RAM, den resterende hukommelse bliver brugt til andre caches og operativsystemet. tmp table size og max heap table size Test viser at der ikke bliver lavet nogle midlertidige tabeller der er større end standard værdien, 16 MB. Derfor er der ingen grund til at ændre på denne værdi. read buffer size Test af forskellige størrelser buffer, viser at standard værdien, 128 KB, ligger ret tæt på det optimale som i dette tilfælde er 512 KB. Testen inkluderede også en buffer størrelse på 64 MB, hvor det i gennemsnit tog 10 sek. længere at lave en fuld tabel skanning Implementering Implmenteringen af denne metode består i at justere server variabler, således at de bliver de værdier der er fundet optimale. På grund af ændringen i tabelstrukturen skal denne også ændres, men det kan nemts gøres ud fra de eksisterende tabeller. Ud over dette skal tabellerne også komprimeres, men det kræver ingen yderlige implementerings taktik.

51 4.3 Sphinx Sphinx Teori Det har været meget svært at finde informationer omkring teorien bag Sphinx. Men jeg har dog fundet et slideshow 15 der beskriver interne dele af Sphinx overfladiske. Da Sphinx er en full-text search engine, stammer mange af termerne også derfra, men det betyder ikke at Sphinx kun kan bruges i denne forbindelse. For at forstå teorien bag Sphinx, kræver det at man kender til nogle forskellig termer. Dokumenter Et dokument, er der hvor Sphinx søger efter ting. Hvert dokument i et indeks indeholder de samme fields. Set i forhold til SQL, betyder det at hver rækker er et dokument og hvert field er en kolonne. Ordinaler Er et matematisk udtryk fra sæt teori 16, der beskriver rækkefølgen i et sorteret sæt. I Sphinx bliver dette brugt til at kunne sortere tekst uden egentligt at opbevare teksten. Attributer Attributer er ekstra værdier tilknyttet et dokument. Disse værdier kan bruges til at udføre ekstra filtering og sortering unde søgning. Attributer bliver gemt sammen med indeks, men det er ikke muligt at søge i dem. MVA (multi-valued attributes) Er en speciel type attribut der kan have flere værdier på en gang. Disse kan for eksempel bruges under filtering, og vil matche hvis bare en af værdier opfylder filteret. Word ID Bruges til at identificere et ord. IDet er i bund og grund en CRC32 eller CRC64 checksum. Morfologi Sphinx har indbygget support for morfologi på engelsk og russisk. Hvis denne funktion er slået til kan det for eksempel betyde at dog og dogs, begge vil blive indekseret som dog, og dermed vil søgninger efter disse ord give samme resultat. Dette kan være meget brugtbart i forbindelse med fuld tekst søgninger, da det kan reduceret indeksets størrelse betydeligt. Indeksering i Sphinx foregår i tre trin. Første trin henter alle dokumenter og ser således ud: 1. Alle dokumenter bliver hente fra data kilden. 2. Dokumenterne bliver delt op i ord. 3. Bearbejd ordene, for eksempel med hensyn til morfologi. 4. Skift ordene ud med deres word IDs. 5. Lav forskellige midlertidige filer. Andet trin består af følgende: 1. Hent og sorter MVA værdier. 2. Sorter ordinaler. 3. Sorter eksterne attributer

52 42 Udvalgte optimeringsmetoder Trejde og sidst trin i indekseringen, som sortere, er således opbygget: 1. Finder ud af hvor mange gang hvert ord optræder, en såkaldt hit list. 2. Inputtet er et antal delvist sorterede hit lists. 3. Den indkommende liste bliver merge 17 sorteret. 4. Outputtet er i bund og grund en enkelt fuldt sorteret hit list. Indeks formattet er meget simpelt, og består udlukkende af sorterede lister. Alle lister ligger linært på disken, hvilket giver god I/O. De forskellige lister er: Dictionary En komplet liste af alle word IDs. Attributer Liste over alle attributer. Denne liste overtræder ikke i alle tilfælde, men kun Sphinx er blevet sat op til det. Dokument lister Lister over hvilke ord der optræder i et dokument. Hit lists Liste over hvor mange gang et ord optræder i et dokument. Søgning i indeks fungere på følgende måde. For hvert indeks der søges bliver: 1. En liste over dokumenter der opfylder forespørgslen bliver lavet. 2. Listen bliver filtreret, hvilket kan ses som WHERE i en SQL forespørgslen. 3. Nogle værdier der indikere dokumenternes relevans bliver udregnet. 4. Listen bliver sorteret, kan ses som ORDER BY i en SQL forespørgslen. 5. Listen bliver grupperet, kan ses som GROUP BY i en SQL forespørgslen. Når dette er blevet gjort for alle indeks, bliver resultaterne fra de de forskellige indeks flettet sammen til et enkelt resultat. Det tidligere nævnte slideshow, beskriver også noget om hvilke dele af søgninger der kræver mest, i forhold til I/O, antallet af resultater og hvordan man kan optimere forespørgsler. Dette vil jeg ikke komme nærmere ind på i dette afsnit, da den del er mere praktisk end teoretisk. Sphinx gruppere i en fast størrelse hukommelse, hvilket betyder at hvis der er for mange grupper til at have i hukommelse, og resultaterne er i en forkert orden rækkefølge, kan grupperingerne være forkerte. Det skal man være opmærksom på hvis man bruger Sphinx til at gruppere, men hvis man kan lave med at resultaterne ikke nødvendigvis er 100% rigtig, er Sphinx hurtigere til det end MySQL er. Det er i Sphinx muligt at implementere forskellige typer af indeks, på nuværende tidspuntk er der dog kun en type indeks implementeret. Den implementerde type indeks er designet til hurtigst muligt at indeksere og søge. Dette betyder at indeks opdateringer er meget langsomme, teoretisk set, kan det være langsommere at opdatere et indeks end at genopbygge det helt. 17

53 4.3 Sphinx Fordele og ulemper Fordele Hurtig indeksering, i følge deres hjemmeside op til 10 MB pr. sek. Hurtige søgninger, i følge deres hjemmeside vare den gennemsnitlige forespørgsler under 0,1 sekund på 2-4 GB tekst kollektioner. Skalere godt, i følge deres hjemmeside op til 100 GB tekst og 100 millioner dokumenter på en CPU. Mulighed for søgning direkte i MySQL ved hjælp af SphinxSE, en MySQL storage engine. Indbygget support for MySQL data kilder. Mulighed for distribuerede søgnigner Ulemper Live indeks er på nuværende tidspunkt ikke implementeret, men vil blive det i version 1.0. Kun en type indeks er implementeret. Indeks skal opdatere eller genopbygges manuelt, eller ved hjælp af et job, ved at køre indeks programmet. Man kan ikke forespørge efter indekseret tekst, da dette ikke bliver opbevaret. Grupperinger er kun estimeret Design I forhold til databasen er der ikke noget specielt design, da Sphinx bare henter data fra databasen og gemmer det i sin egen struktur. I testen vil Sphinx bruge de optimerede tabeller til at hente data fra, tabellernes struktur kan ses på figur 4.2. Sphinx bliver sat op til at lave et indeks på de kolonner der oftest bliver udført logsøgninger på, hvilket vil sige time, srcip, dstip, proto, dstport, srcport og action. Faktisk indeksere Sphinx ikke værdierne i denne kolonne, men i stedet værdierne i kolonnen module, grunden til dette er at Sphinx ikke gemmer indeksere værdier, og derfor bliver de tidligere nævnt kolonner tilføjet som attributer, og dermed kan de trækkes ud fra Sphinx. Jeg har valgt at indeksere på module, da den indeholder få forskellige værdier og derfor vil indekset ikke blive særlig stort. Jeg har valgt kun at bruge Sphinx til at forbedre hastigheden på logsøgninger, da det er det mest oplagte mulighed da man i langt de fleste tilfælde slipper for at spørger databasen efter data som ikke er opbevaret i Sphinx. Det er muligt at Sphinx kan hjælpe med at forbedre hastigheden på statistikgenerering, men i den forbindelse skal databasen under alle omstændigheder bruges til at udføre grupperinger, da man vil risikere at grupperingerne ikke er rigtige, hvilket man kan risikere ved at bruge Sphinx til det. Og fordi man alligevel skal gruppere på databasen og det er det der tager lang tid, er det sandsynligvis ikke meget man kan forbedre ydeevnen. Jeg havde desværre ikke tid til at teste det, og kan derfor ikke med sikkerhed sige noget om det.

54 44 Udvalgte optimeringsmetoder Den medfølgende search daemon 18, vil blive brugt til at udføre forespørgsler om indekset. Den understøtter de mest basale SQL forespørgsler og kan derfor nemt implementeres i eksisterende systemer der bruger databaser Implementering Implementeringen af Sphinx foregår ved at Sphinx bliver installeret, indeks bliver defineret og bygget og til sidst bliver search daemonen startet så man kan udføre forespørgsler mod Sphinx. 18

55 Kapitel 5 Test miljø For at at kunne lave konsistente målinger af både den nuværende databases ydeevne, og af fremtidige database struktures ydeevne, er det vigtigt at der findes et test miljø, der kan bruges til dette. Test miljøet skal kunne bruges i forbindelse med forskellige teste, hvilket betyder at det både skal kunne bruges til at teste den nuværende struktur, men samtidig også være fleksibel nok til at kunne bruges under test af de forbedrede database strukturer. Miljøet skal også inkludere mindst muligt antal parameter, som der er ikke kontrol over, for eksempel netværksbelastning. Det optimale ville være at bruge det samme hardware, osv. i test miljøet som i produktion. Problemet ved det er dog at produktions databasen køre på en virtuel maskine på et SAN 1, hvilket betyder at netværksbelastning og de andre virtuelle serveres SAN forbrug har en indflydelse på databasens ydeevne. Det kunne også være interessant at undersøge databasens ydeevne i test systemer med forskellige CPU hastighed, I/O båndbredde og hukommelse, hvilket vil gør det nemmere at finde ud af hvad der begrænser databasen ydeevne, og dermed nemmere at kunne se hvilket hardware der kunne forbedre ydeevnen. Derfor har jeg i samarbejde med Dubex valgt at oprette to testsystemer, med forskellige mængder hukommelse, og type CPU. Vi ville også gerne have haft et system med stor I/O båndbredde, for eksempel flashdiske, men dette var der ikke mulighed for da Dubex ikke har nogen flashdiske. Systemet med lille hukommelse er min egen maskine i Dubex, som i forhold til serveren har lav I/O båndbredde. Og vil derfor give et indtryk af hvordan databasens ydeevne er på langsommere diske. Systemet køre Windows XP og har følgende specifikationer: Processor: Intel Core2 Duo 3.00 GHz RAM: 2047 MB Test systemet med mere hukommelse er en server der er blevet sat op, udelukkende til test af database ydeevne. Denne maskine giver mulighed for nemt at se om databasen vil yde bedre med mere hukom- 1 Storage Area Network: area network

56 46 Test miljø melse, eller om den blive begrænset af den relativt lave I/O båndbredde. Serveren køre Linux, nærmere bestemt Ubuntu, og har følgende specifikationer: Processor: Intel Xeon CPU 3.40 GHz RAM: 3520 MB Test serverens specifikation er stort set identitiske med maskinen der køre databasen i produktionsmiljøet. Der vil blive installeret MySQL på begge maskiner, og MySQL opsætningen er som udgangspunkt standard, men kan undervejs blive ændret i forbindelse med test og profilering. Hvis opsætningen bliver ændret vil dette tydeligt fremgå under i de enkelte teste. 5.1 Teste På hvert testsystem vil præcis de samme teste blive kørt, da man ellers ikke kan sammenligne resultaterne fornuftigt. Testene der bliver kørt på systemet er: Indsættelse af ny data Generering af statistik Søgning i databasen Der vil i alle test blive brugt data der har været i produktionsdatabasen. Derfor har test data sammen udformning som data der bliver importeret til produktionsmiljøet, og skulle dermed give et bedre resultat end autogenereret data. Samtidig vil forespørgslerne være så tæt som muligt, på dem der er blive forespurgt med i produktion. Alle test vil blive udført lokalt på test maskinerne, for at der ikke er så mange parametre at tage højde for, for eksempel netværksbelastning. Dette er valgt fordi det giver det bedste indtryk af databasens ydeevne og ikke at netværket til tider er mere belastet end andre. Der vil hovedsagligt blive kørt benchmarking på hver enkelt test, hvis det bliver skønnet at der vil give mening profilere testen, vil dette også blive gjort. Meningen med det er selvfølgelige at kunne sammenligne test resultaterne mere detaljeret Indsættelse af data Tester hvor effektivt database indsætter ny log data. Her er der ikke nødvendigt at det går meget stærkt, da det ikke er et realtidssystem og fordi data i forvejen har været undervejs i et par timer. På grund af det gør det ikke særlig meget om det tage 5 minutter eller 30 minutter. Det må dog ikke gå for langsomt da data skal kunne indsættes i databasen mindst lige så hurtigt som der kommer ny data, ellers vil man løbe tør for diskplads hele tiden. Så lang tid databasen kan følge med dataflowet er der ingen problemer, der skal dog også være plads til at der kan importeres mere data end der bliver på nuværende tidspunkt. Samtidig må databasen heller ikke blive låst for længe eller for store dele ad gangen, således at data ikke kan tilgås af andre processer.

57 5.1 Teste 47 Teknisk set vil denne test består af bulk filer der bliver importeret til databasen. Dette vil blive gjort ved hjælp af databasen kommandoen LOAD DATA INFILE INTO... 2, da det er den mest effektive måde at importere bulk filer til databasen på, det er også på den måde der bliver importeret data til den nuværende database Generering af statistik Tester hvordan database yder under statistik generering. Det vil sige at der bliver udført mange forspørgsler på data i databasen, og at der bliver trukket meget data ud. Statistikgenereringen er i princippet mange små forespørgsler. For at generere statistik for et enkelt module, sker der som minimum 32 forespørgsler, hvilket er statistik for en time, men da der normalt bliver der genereret statistik for flere timer ad gangen er tallet reelt højere. Selvom der bliver genereret statistik for flere timer ad gangen, vil hver enkelt time blive behandlet individuelt og derfor har det ikke nogen indflydelse på testen, hvorvidt det 3 eller 24 timer. I denne test vil der blive genereret statistik for 24 timer ad gangen, for at teste flest mulige data situationer og få det bedste indtryk af ydeevnen Log søgning Test hvor hurtigt søgninger bliver udført i databasen. Denne test hænger meget samme med generering af statistik, forskellen er dog at søgninger i databasen bliver udført løbende, når der er behov for at kigge på log data der ikke er blevet processeret til statistik. Disse søgninger henter i forhold til statistik generering normalt ikke særlig meget data ad gange, men i teorien kan den hente nøjagtig det samme data som statistikken. En søgning kunne for eksempel være at finde al information der er blevet logget omkring et bestemt source IP indefor en et givet tidsrum. Når der søges vil man ofte være interesseret i mere end en dags data, og derfor er dette testens udgangspunkt. Denne test vil bestå af forespørgsler der ofte bliver spurgte efter i produktionsmiljøet. Det er ikke alle muligheder der vil blive teste da det er meget forskelligt hvordan der søges, dog vil forespørgslerne være forskellige nok til at dække de mest normale områder der søges i. 2 Se

58 48 Test miljø

59 Kapitel 6 Nuværende database Det nuværende data format består af logfiler fra CheckPoint firewalls. Der bliver også importeret syslog og SMTP data fra enkelte kunder, men disse bliver gemt i andre databaser end firewall loggene gør. Måden systemet håndtere firewall logs på, er som følger: 1. Der bliver løbende dannet log filer på firewallen. 2. Log filerne bliver konverteret fra binært format til ASCII format. 3. Filen bliver sendt indtil Dubex. 4. Diverse informationer i filen bliver konverteret til mere sigende informationer. 5. Udvalgte informationer bliver gemt i databasen, resten bliver smidt væk. 6.1 Tabeller Interface tabellen Er en bindings tabel mellem interfaces og moduler. Det betyder at denne tabel i sig selv ikke indeholder andre informationer omkring de enkelte interfaces end en reference til modulet de tilhøre. Tabellen bliver brugt i log tabellen til at indikere hvilket source interfacet og destinations interfacet hændelsen opstår på. Tabllen ser således ud: Navn Datatype Beskrivelse InterfaceId Unsigned Tinyint Det interne interface ID Module Unsigned Tinyint Reference til modulet interface tilhøre

60 50 Nuværende database I forbindelsen med log database er det kun InterfaceId der er interessant, de andre er kun beskrevet for at vise tabellens udformning Modul tabellen Indeholder de interne module numre, samt nogle reference til andre tabeller der indeholder forskellige informationer omkring det enkelte modul. Denne tabel bliver brugt af log databasen, til at indikere hvilket modul en hændelse er sket på. Tabellen ser således ud: Navn Datatype Beskrivelse ModuleId Unsigned Tinyint Det interne modul ID Name Varchar(127) Det interne navn på modulet Comment Varchar(255) Den interne kommentar til modulet DecryptKey Varchar(63) Nøglen der skal bruges til at dekryptere logs fra modulet. Bliver på nuværende tidspunkt ikke brugt Parent Unsigned Tinyint Navnet på den interne modul gruppe, modulet tilhøre ItemOrder Unsigned Tinyint Hvor modulet skal vise i den interne træstruktur I forbindelse med log tabellen, er det kun ModuleID der er interessant, de andre er kun beskrevet for at vise udformningen af tabellen Firewall besked tabellen For at denne tabel giver mening er det vigtigt at man forstår at den ikke kun indeholder log beskeder, men også alle tekststrenge der kan forekomme i loggen. Tabellen bliver automatisk udfyldt af import systemet når der er plads i den, og hvis beskeden ikke findes i forvejen. Der er på nuværende tidspunkt plads til maksimum beskeder da ID kolonne er af typen unsigned smallint, hvilket betyder at man hurtigt mister tekststrenge. Udformingen af tabellen er således: Navn Datatype Beskrivelse msgid Unsigned Smallint Besked ID msgstring Varchar(255) Selve beskeden Firewall log tabellen Indeholder selve log data, som vil blive beskrevet nærmere i nedenstående tabel Tabellens udformning er således:

61 6.2 Fordele 51 Navn Datatype Beskrivelse eventid Unsigned Int Hændelsens ID datetime Datetime Tidspunktet hvor hændelsen skete module Unsigned Tinyint Det interne module ID action Unsigned Tinyint Hændelsens type srcip Unsigned Int Source IP dstip Unsigned Int Destinations IP proto Unsigned Tinyint Protokol typen rule Unsigned Smallint Det regel ID der blev brugt i forbindelse med hændelsen srcport Unsigned Smallint Source port dstport Unsigned Smallint Destinations port xlatesrc Unsigned Int Den oversatte source IP xlatedst Unsigned Int Den oversatte destinations IP xlatesport Unsigned Smallint Den oversatte source port xlatedport Unsigned Smallint Den oversatte destinations port resource Varchar(255) Informationer fra resource filteret user Varchar(255) Brugeren der er logget ind msginfo Unsigned Smallint Beskeden der er tilknyttet hændelsen, henviser til den tilknyttede besked i besked tabellen product Unsigned Smallint Produktet hændelsen skete på type Unsigned Smallint Hændelses typen alert Unsigned Smallint Hændelses alarmen ifname Unsigned Smallint Navnet på interfacet sysmessage Varchar(255) System besked reason Unsigned Smallint Årsagen til hændelsen htime Unsigned Tinyint Timen hvor i hændelsen skete srcif Unsigned Tinyint Source interface dstif Unsigned Tinyint Destinations interface bytestx Unsigned Bigint Antal bytes overført Alle disse informationer bliver gemt i den samme tabel. Da det ikke er alle informationer der bliver brugt på hver hændelse, eller reelt har noget med hinanden at gøre, er der mange kolonne der har NULL værdier, i hver række. Hver kunde har sin egen database hvor i loggene bliver gemt, og loggene er delt op på dags basis. Det vil sige at der for hver dag, er en ny tabel. Denne opbygning gør at data bliver meget overskueligt, mens det samtidigt er nemt at slette en hel dag ad gangen. 6.2 Fordele Den er overskuelig. Nem at vedligholde. Al firewall log information er samlet et sted. Det er nemt at analysere og søge efter data. 6.3 Ulemper Det ikke nemt at gemme flere informationer fra CheckPoint log filer.

62 52 Nuværende database Det er ikke muligt at gemme andet end CheckPoint firewall logs i samme database/tabel. På grund af de mange informationer der bliver gemt, er søgning meget langsom og databasen fylder meget. 6.4 Database opsætning De interessant ting i den nuværende databases opsætning er følgende variable, de er samtidigt også de eneste ændringer fra standard opsætningen. key buffer size=1024m sort buffer size=256m read buffer size=64m read rnd buffer size=128m bulk insert buffer size=64m max heap table size=256m tmp table size=256m 6.5 Hvad bliver data brugt til? Ud fra log databasen bliver der trukket diverse informationer ud, som derefter bliver analyseret og brugt til at danne grafer og tabeller, som er nemmere at overskue end selve log filen. Den visuelle repræsentation bliver brugt både af kunder og interne supportere, og derfor er det vigtigt at de er korrekte. Dog er det ikke al log data der bliver analyseret, men kun dele som ofte er interessante, for eksempel hvor mange forbindelser der er blevet afvist per IP, og andre ting som kan hjælpe til at opdage eventuelle angreb eller problemet med systemet. Ud over analyserne er det også muligt at søge direkte i log data. Muligheden eksistere da man ikke altid kan se præcis hvad der er galt ud fra analyserne. Søgningen bliver brugt flittigt hvis der er behov for flere informationer, end man umiddelbart kan se på graferne eller i tabellerne, og er derfor et meget vigtigt værktøj. 6.6 Problemer Problemerne med de nuværende database, er bedst beskrevet af ulemper nævnt foroven. Det er meget upraktisk og besværligt at log informationer fra andet end CheckPoint firewall. Dette gør det meget omfattende at importere data fra andre typer af sikkerhedsmoduler, for eksempel BlueCoat produkter. Det betyder at der er mange produkter som ikke bliver overvåget lige så godt som firewalls, eller at disse informationer slet ikke kan ses. Samtidig er det også problematisk, at man er låst fast i de informationer fra firewalls, der bliver importeret på nuværende tidspunkt. Da produkterne løbende bliver videreudvilket af producenterne, ville det være en stor fordel, hvis de nye funktioner nemt kunne tilføjes og analyseres. Dette er ikke

63 6.7 Diagram 53 Figur 6.1: Database diagram over den nuværende database muligt på nuværende tidspunkt uden store ændringer i måden hvorpå data bliver hentet, behandlet og analyseret. Søgning i log databasen er meget langsom, på grund af to ting: størrelsen og de mange informationer. De mange informationer, kolonner, i databasen gør at det aldrig er alle kolonner der har en værdi og at man aldrig ved hvilke data der er interessante. Det betyder at det ikke er muligt at lave et ordentligt indeks på tabellen, hvilket måske kunne forbedre søge hastigheden. De mange informationerne gør også at data fylder meget på harddisken, da der for hvert enkelt række bliver gemt mange flere informationer end nødvendigt, dog er det på nuværende tidspunkt hovedsagtligt indeks der fylder meget. 6.7 Diagram Figur 6.1, viser en udsnit af den nuværende database struktur. Referencer mellem andre tabeller end fw1log tabellerne er ikke vist, da de ikke har noget at gøre med log databasen, og derfor ikke er nødvendige at tage højde for i denne rapport. Det skal også siges at de fremmednøgler der er indikeret på diagrammet er fiktive da der bliver brugt MyISAM som ikke understøtter fremmednøgler. Grunde til at de alligevel er på diagrammet er at man i alle tilfælde tænker på dem, som om de eksisterer, og bruger dem til nøjagtigt det samme.

64 54 Nuværende database 6.8 Test Figur 6.2: Tabel Størrelse - Original Database Dette afsnit indeholder en test af den nuværende database, således at jeg nemt kan sammenligne størrelsen, hastigheden på data loading, statistikgenerering og logsøgninger Størrelse Figur 6.2 viser tabellernes størrelse i den nuværende database Data loading Figure 6.3 viser hvor hurtigt den nuværende database load data fra bulk filerne Statistikgenerering Test af hvor hurtigt den nuværende database generere statistik Logsøgninger Test af hvor hurtigt den nuværende database kan udføre manuelle logsøgninger.

65 6.8 Test 55 Figur 6.3: Data Loading - Original Database Figur 6.4: Statistikgenerering - Original Database

66 56 Nuværende database Figur 6.5: Logsøgning - Original Database

67 Kapitel 7 Test Til at hjælpe med at udføre alle testene fuldstændig ens, er der blevet laver et Perl script der udføre de forskellige tests. Grunden til at dette er blevet gjort i Perl er, at Perl virker på både Linux og Windows og derfor kan bruges i begge test systemer. Perl scriptet er vedlagt denne rapport som bilag A. For en beskrivelse af de teste der er i scriptet, se afsnit 5.1. Scriptet udføre de forskellige teste, måler hvor lang tid de tager og gemmer resultatet i en database til senere analyse. Hvert afsnit i dette kapitel, vil beskrive de tests der er blevet udført på metoder og resultaterne på de to testsystemer. Der vil blive referet til server og workstation testsystemerne, se eventuelt afsnit 5 for nærmere forklaring. Strukturen i hver test vil derfor være: Størrelse beskriver hvilken indflydelse metoden har på størrelsen af databasen. Data loading beskriver hvilken indflydelsen metoden har på hastighed af bulk loading. Statistik generering beskriver metodens ydeevne i forbindelse med statistikgenerering. Log søgninger beskriver metodens ydeevne i forbindelse med manuelle søgninger. 7.1 Infobright Størrelse På grund af data komprimeringen i Infobright forventes det at tabellerne fylder meget mindre end i den nuværende database. Nøjagtigt som forventet er databasens størrelse med mindre med Infobright.

68 58 Test Figur 7.1: Tabel størrelse - Infobright Data loading Jeg forventer at Infobright er væsentligt hurtigere til at importere data end den nuværende database, på grund af dens brug af flere tråde. Ligesom forventet kan man tydeligt at Infobright er meget hurtigere til at indsætte data. Man skal dog huske på at man hurtigt kan gøre databasen meget langsom på grund af de mange tråde der bliver lavet, men det passer også godt med at Infobright er optimeret til serveren med flere kerner og processorere Statistik generering Jeg ved ikke rigtig hvad jeg forventer af resultater i denne test, da jeg ikke tidligere har set Infobright i aktion. Umiddelbart ville jeg forvente at der var en forbedring i forhold til den nuværende database, men da denne test bruger meget data fra rækkerne, kan det være at den kolonnebaserede struktur ikke virker så godt. På server siden kan man tydelig se at Infobright ikke virker bedre end den nuværende database. Det er sværre at tyde resultaterne af testen udført på min workstation, på grund af den manglende måling med de mange rækker, men ved at kigge på data der er brugt til at lave graferne kan man tydeligt se at Infobright heller ikke virker så godt her. Det er ikke til at sige præcis hvorfor Infobright yder så dårligt i dette tilfælde, uden et mere dybdegående kendskab til Infobright. Et kvalificeret gæt vil dog være at kolonnebaserede struktur ikke passer så godt i dette tilfælde, hvor der bliver kigget på meget data per rækker.

69 7.1 Infobright 59 Figur 7.2: Data Loading - Infobright Figur 7.3: Statistikgenerering - Infobright

70 60 Test Figur 7.4: Logsøgning - Infobright Log søgninger Ligesom i testen af statistikgenereringen, ved jeg ikke helt hvad jeg forventer på grund af mit manglende kendskab til Infobright, men jeg regner med at Infobright vil yde bedre end under statistikgenereringen da der bliver kigget på meget mindre data per række i denne test. I denne test er Infobright på min workstation langt hurtigere i de store tabeller, sandsynligvis på grund af den kolonnebaserede struktur, ved de små tabeller er den nogenlunde ligeså hurtig som den nuværende database. På serveren yder Infobright ikke særligt godt, i stedet er den nuværende database langt hurtigere. Grunden til dette er sandsynligvis at serveren ikke har flere kerner ligesom min workstation, og da Infobright er optimeret til det yder den derfor dårligere på en kerne end to kerner Opsummering 7.2 MyISAM optimering I denne test vil jeg teste både med og uden komprimering Størrelse På grund af den nye tabel struktur skulle databasens størrelse være en smule mindre end den nuværendes, dog forventer jeg at den komprimerede udgave er væsentligt mindre. Ligesom forvente er

71 7.2 MyISAM optimering 61 Figur 7.5: Tabel størrelse - MyISAM Optimering database størrelse en smule mindre, men det er ikke meget. I den komprimerede version er forskellen meget større Data Loading På grund af den optimerede server variabel bulk insert buffer size, forventer jeg at data loading er hurtigere i denne test end den er i den nuværende database. Det er ikke muligt at test data loading i komprimereded tabeller, da man ikke kan skrive til dem. Grafen viser at indsættelse af små bulk filer er en lille smule hurtigere i den optimerede database, men en smule langsommere med de store filer. Detet passer meget godt til måde bulk bufferen er blevet optimeret på, men den endelig buffer størrelse kan ikke fastsættes uden at vide hvad forholdet mellem store og små filer er i produktionsmiljøet Statistikgenerering Da forespørgslen der bliver brugt til at genere statistik er blevet optimeret, forventer jeg en forbedring i forhold til den nuværende database. Grafen viser som forventet en forbedring i hastigheden på statistikgenerering på både min workstation og serveren, og jo flere rækker der bliver hentet jo større er forskellen. Dette skyldes sandsynligvis de meget højere buffer værdier i den nuværende database, hvilket gør at de der bliver allokeret en masse ekstar hukommelse. hvilket tager relativt lang tid. Sam sagt tidligere kan buffer størrelserne ikke fastsættes uden yderligere test med al data, da størrelses fordeling af data er meget vigtig, men denne test viser dog er der er plads til optimering her. I den komprimerede version af database forventer jeg ikke nogen forbedring i forhold til den nuværende, hovedsagligt fordi hver enkelt rækker skal dekomprimeres. Ydeevnen er ikke forbedret meget, den er