Innehållsförteckning:
Av Techopedia Staff, 5 oktober 2016
Takeaway: Värd Eric Kavanagh diskuterar databasindex med Dr. Robin Bloor, Dez Blanchfield och IDERAs Bert Scalzo.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Techopedia Content Partner
Techopedia Staff är anslutet till Bloor Group och kan kontaktas med alternativen till höger. För information om hur vi arbetar med branschpartner klicka här.- Profil
- Hemsida
Eric Kavanagh: Mina damer och herrar, hej, och välkomna igen. Det är en onsdag, klockan fyra östra, och de av er som känner till programmet, vet vad det betyder, det är dags för ytterligare ett avsnitt av Hot Technologies. Ja verkligen. Jag heter Eric Kavanagh, jag kommer att vara din moderator för dagens session: "Index Insanity: How to Understanding Database Chaos." Eller som jag hänvisade till det i den senaste e-postblasten för att gå ut, "databas wrangling." Hot term dessa dagar, "wrangling." Alla gör det. Det finns en bild om din verkligen. Och nog med mig.
Så var Hot Technology-serien verkligen utformad för att definiera ett visst utrymme, i motsats till Briefing Room som bara är en-på-en live analytikerbriefing, för Hot Tech får vi två analytiker. Idag kommer det att bli vår egen doktor Robin Bloor och vår datavetare Dez Blanchfield. Och vi pratar om ett ämne som jag tycker är verkligen ganska emblematiskt för vad som händer på marknaden idag.
Sammanfattningen är att vi befinner oss i en värld av komplexitet idag. Verkligen, om du tänker tillbaka femton år, eller tjugo år, var det en oerhört annorlunda värld då, särskilt med avseende på databasteknologi. Databaser brukade vara ganska enkla. Det fanns bara en handfull av dem; de flesta av dem var relationella. Nu har vi hela panopiet av databasteknologier. Bokstavligen massor av alternativ på bordet för alla som vill bygga en applikation eller göra något med data. Allt förändras och det påverkar de människor som försöker hantera dessa system. Vi ska prata idag med Bert Scalzo, som är en riktig expert på området; han är seniorproduktledningen för IDERA, om vad du kan göra för att ta hand om all den informationen. Med det ska jag överlämna det till doktor Robin Bloor för att ta bort det. Robin, golvet är ditt.
Robin Bloor: Okej, tack för den introduktionen. Jag tror det - eftersom det är en tvåhandig sak tror jag att jag bara skulle prata om databasoptimering i allmänhet som en introduktion till denna Hot Tech-show. Jag började livet - inom teknik och analys - jag började livet med att göra detta eftersom jag brukade skriva artiklar om databasernas funktioner på DEC VAX-plattformen. Och av den anledningen brukade databasförbrukare att informera mig. Och det som händer med mig är att varför skulle du ha en databas? Jag menar, i dessa dagar använde en fruktansvärd massa människor för att skapa nyckelvärdesfiler och använda dem för att ha ett slags indexföljdefall som vi kallar dem, men för att skapa en slags databasfunktion, och du vet, varför skulle du ha något annat?
Och svaret på det, jag tror att Michael Stonebraker gav det bästa svaret på det, och han sa: "En databas kan veta mer om var data är och hur snabbt det går att få, än något program någonsin kan veta." Och jag tycker att det är intressant; det är spelets natur. Men under 19 - ja omkring 1989 som jag började inom teknikanalys och du vet, i den tidpunkten var databaser väldigt enkla och relationella databaser var superenkla. De hade så liten kapacitet, jag menar, de kunde naturligtvis lagra data, och du kunde säkerhetskopiera och de hade, de var ACID-kompatibla, men de hade verkligen mycket svaga optimisatorer. I själva verket skulle det vara svårt att hävda att de alls hade optimeringsförmågan.
Och senare blev de bara bättre och bättre, men, du vet, när en databas inte fungerar - eftersom dessa känguruer verkar vara på ett eller annat sätt indikerar - det kan finnas en hel del skäl till varför det går långsamt. Och det leder mig till punkten: Databaser har många funktioner, men den viktigaste är frågaoptimering. Om de inte gjorde det skulle du inte använda dem. Det handlar om att få information snabbt, det handlar om att kunna göra det när det finns många samtidiga användare, och det är ett svårt problem. Och när du faktiskt tittar på, låt oss kalla dem mogna databaser, om du gillar - men säkert Oracle, i något mindre utsträckning, Microsoft SQL Server, verkligen Teradata och DB2 - optimisatorerna för dessa databaser har varit i årtionden i byggnad. Vet du, de gjorde inte - någon satt inte ner på - sex killar på en tvåman, år, projekt och bara slog en ihop. Det fungerar inte så. Optimeringsförmågan har gradvis vuxit och det krävs mycket växande. Hur som helst, låt oss prata om bakgrunden till databasen. Det finns mycket hemskt som sägs om NoSQL-databasen nu, och det finns till och med mycket entusiasm för grafdatabasen. Och användningen av SQL över Hadoop och liknande saker. Men sanningen är att om du vill ha en databas just nu, om du vill ha en fullt funktionell, kapabel till OLTP och stor frågetrafik, så är det en relationsdatabas, eller så är det ingenting.
Bland relationella databaser är Oracle dominerande i popularitet. Microsoft SQL Server, tror jag, är andra. De kan båda användas för OLTP och fråga arbetsbelastning, men du kan faktiskt inte komma undan med att blanda dessa arbetsbelastningar. Du behöver olika incidenter för OLTP-arbetsbelastningar och fråga-arbetsbelastningar. Det finns alternativ till SQL och graf. De flesta företag standardiserar en specifik databas, och det är därför - jag menar efter decennier av att ha kämpat den med alla andra spelare blev Oracle den mest dominerande. Helt enkelt för att de slutade kunna sälja företagslicenser, och därför skulle företag bara använda alternativa produkter i exceptionella produkter som Oracle helt enkelt inte skulle göra. Och databaser är strategiska eftersom de också utvecklas. Och du vet att jag gjorde lite research för den här presentationen, och det är typ av - jag kommer till det på ett tag, men det är lite intressant hur de utvecklas, när det gäller att titta på det från en DBA: s position. Det här är vad jag kallar den osynliga trenden. Det är Moores lag i kub. Det är ungefär så här: Den största databasen är, och nya databaser, det finns inte en gammal databas som har mycket mer data att äta. Det är normalt en databas som används för ett nytt problem. Och de växer faktiskt när det gäller datamängder. Grovt vid kuben i Moore's lag. Så Moores lag är en faktor tio gånger var sjätte år. VLDB tenderar att växa en faktor på tusen var sjätte år. 1991, 1992, mäts de stora databaserna i termer av megabyte. Under '97 och '98, gigabyte. 2003, '4, terabyte. 2009, '10, började du se petabyte-databaser. Jag tror att det fanns en eller två exabyte-databaser där ute just nu, men den största jag har hört talas om är 200 petabyte i tid, och du vet att du inte får data till en petabyte-databaser. Men det är för det mesta de nya stora webb 2.0-företagen, kanske du har Facebook på väg i den riktningen.
Men hur som helst, om du faktiskt tittar på det och förväntar dig att en databas ska gå igenom den typen av upptrappning i volym, ber det mycket. Och anmärkningsvärt, verkligen upp till petabyte-nivån, verkar de ha gjort ganska bra. Jag menar, jag pratar om de äldre produkterna snarare än något nytt. De verkar ha gjort utomordentligt bra. Om vi tittar på databasprestanda, flaskhalsar tar det mig tillbaka till den tid jag faktiskt brukade bry sig om dem och var tvungen att oroa dem. Du vet att detta i grunden är hårdvarans fördelning. Det finns CPU-flaskhalsar, kanske finns det flaskhalsar i minnet, kanske finns det flaskhalsar på skivan, eventuellt. Det kan vara nätverket som orsakar sorg, och du kan också få problem med låsning, beroende på vad du gör, men normalt beror det på att programmet inte vet vem du ska ringa låsning. Så om du kommer att ställa in en databas försöker du faktiskt ställa in den så att den dansar mellan dessa fem möjliga flaskhalsar så bra som den kan göra. Och det är ingen enkel sak, eftersom mängden minne som du kan konfigurera på en given server ökar dramatiskt. Sedan har CPU: er blivit multicore, disk, och vi kan nu göra, tror jag, även på råvaraservrar, jag tror att du kan göra hundratals och hundratals terabyte, fjärdedel av petabyte, kanske, till och med på en handelsserver. Så av alla dessa saker kan du spela med, nätverk kan naturligtvis gå i olika hastigheter, men mestadels när du har att göra med databaser vill du verkligen ha fiberkablar mellan servrarna och inget annat kör på det, särskilt på det sättet.
Databasprestationsfaktorer. Jag menar, jag lämnar bort vad det här kommer att handla, för jag vet att Dez kommer att prata om det, men dålig databasdesign betyder en databas med dåligt resultat. Dålig programmeringsdesign kan möjligen innebära att man kastar mycket dum SQL till en databas, vilket bara tar väldigt mycket längre tid. Samtidighet och blandning av arbetsbelastning, för mycket samtidighet kommer att orsaka flaskhalsproblem. Arbetsbelastningen blandar, när du har stora frågor med mycket små, korta, skarpa frågor, som orsakar problem. Det finns en lastbalanseringsfråga. De flesta databaser tar hand om det, men om du inte har en sofistikerad produkt, vet du, bara att lägga till några servrar, är inte allt du gör om du faktiskt vill öka storleken på ett kluster. Du måste faktiskt balansera belastningen innan du får optimal prestanda. Du måste göra kapacitetsplanering. Absolut. Särskilt nu i dessa dagar som när datamängderna ökar mer dramatiskt än de brukade för databaser. Och det finns problem med hela dataskiktet för hur du tar in data, hur du flyttar data om. Att inte få data till en databas i tid kan vara ett prestationsproblem senare eftersom vi har gått från databaser som arbetar i Windows, till tjugofyra av sju av trehundra sjuttiofem operation och det finns inga fönster där du kan bromsa databasen ner eller det är osannolikt att det kommer att finnas idag.
Oracle DBA-problemet. Det här är vad jag tänkte på. Jag har varit i Oracle's DBA med Oracle 7, och jag kommer ihåg hur jag skulle ställa in det. Och om du faktiskt tittar på Oracle nu är det sätt, sätt - det har vägen, sättet mer kapacitet. Det har indexering av bitmappar och sådant, men jag tog mig faktiskt tid att titta och se hur många inställningsparametrar som finns i en Oracle-databas just nu. Och det finns över tre hundra och femtio inställningsparametrar och det finns ytterligare hundra dolda parametrar, som specialiserade DBA-kanske känner till, men vanliga Oracle DBA-känner inte till. Och det betyder att det är svårt att ställa in den här typen av databaser. Det är inte en enkel sak alls. Du måste ha en känsla för det, du måste ha gjort det under lång, lång tid, och du måste veta exakt vad problemet du tror att du löser, eftersom inställningen börjar när prestanda blir dålig, men det kanske inte är resultatet för allt. Det kan vara prestandan för specifika frågor som är viktiga, och du kanske kan fixa det genom att fästa vissa data och minne, eller så kan du behöva fixa det genom att indexera, eller så kan du behöva börja göra partitionering på ett annat sätt. Det finns många saker du kan göra, är poängen. Så därför kommer de inte att göra det i deras huvuden - DBA behöver verktyg. Jag ska nu vidarebefordra till Dez som kommer att berätta om indexering, tror jag.
Eric Kavanagh: Okej Dez, ta bort det.
Dez Blanchfield: Tack, Robin, och jag älskar försidan. Jag tror att du har kastat klingan där nere för att jag ska komma till och med komma långt nära till något så spännande. Men jag har använt en bild av vår lilla galax, som min syn på vad dagens utmaning för databasadministratörer har förvandlats, eftersom det här är den mentala bilden som jag tenderar att trylla fram när jag kommer in i en miljö och jag är inte längre i världen med att administrera databaser eller designa databaser längre på den nivån. Men som du själv har Robin och jag haft många år av att vara involverade i databasvärlden, antingen som administratör eller utvecklare, eller så småningom som arkitekt, och insåg sedan att jag kunde göra bättre saker för att tjäna en skorpa. Men det känner ofta att du stirrar på denna galax med data, och mer så idag, när vi går från, som du skisserade, har vi gått från megabyte till petabyte och exo-skala på mycket kort tid, i det stora planen för saker. Men den fras som jag har i mitt sinne är att databasindex nu är en svart konst och de är inte riktigt den typ av saker som bara dödliga bör sortera på, för affärsapplikationer för företag och typen av att formulera dig pratade bara om. Men jag ville gå igenom en snabb sammanfattning av den typ av historia som jag har haft med databasvärldar och föra till sammanhang där vi ska dra en slutsats och sedan gå igenom lite material idag med våra vänner på IDERA, för jag tror att det finns mycket olika tankar om hur man kan ställa in databasprestanda och en av dem kastar tenn på saken. För många butiker som jag stöter på kommer de alltid inte att göra prestandajustering på databasskiktet och särskilt indexlagret förrän de har kommit igenom den hårda vägen att tro att de kan kasta en tuner på det .
Många människor tar bara ett stort järntillstånd till det, i mitt sinne, och jag har en bild av The Flash här för om du någonsin har sett några gamla filmer eller säkert det senaste TV-programmet med The Flash, som i Flash Gordon, den gamla karaktären, och nu när han heter "Blixten" tenderar han att gå väldigt, mycket snabbt och alltid går hans energi slut. Och det här är vad som händer när du kastar stort järn på databasprestanda. Ofta kan jag, enligt min erfarenhet, sätta hög prestanda, hårt arbete i spelet, du kan optimera dina operativsystem och ställa in dem till en viss punkt. Du kan säkerställa att du har snabba flerkärniga, flertrådiga CPU: er för att göra att applikationen körs snabbare, att du kan kasta massor av RAM på det, att du kan ha bakgrundsplan med hög kapacitet, du kan gå från hårddiskar till cache-hårddiskar till fast tillstånd och högpresterande lagringsarray. Och till och med nu kastar folk in saker som flash och NVMe på sina databasmotorer och tänker att de kommer att få den här inloggningen gånger två prestandaförvärv. Och alltid får de viss vinst. Men allt kommer tillbaka till samma grundläggande prestandastämningsproblem. Massor av nätverksanslutningar med låg latens, så att klustren fungerar snabbt. Och för att klustera databasinfrastruktur, så att du har mer än bara en maskin som gör allt arbete. Men du brukar komma tillbaka till samma grundläggande prestandaproblem, och det är att läsa data. Att skriva data är för det mesta en ganska linjär utmaning och om det inte görs ordentligt.
Och sedan har vi utmaningen i dagens värld: Inte alla databaser skapas lika. Det finns databaser och "offert-på-offert" -databas. Och när vi tänker på databasmotorer tänker människor ofta på de traditionella, vanliga misstänkta som de var i SQL-världen. Du vet, vi har Oracle och Microsoft SQL Server, och det finns ett par runtom i open source-världen med MySQL, som nu ägs av Oracle, men det är fortfarande open source. Och så har vi de inte så vanliga misstänkta, NoSQL-motorerna, som fortfarande har problem kring indexering och prestandahantering, och jag kommer inte att gå in på dem i mycket detalj, men det finns ett ökande antal av dessa saker dyker upp varje dag och de ser ut och känner sig som databasmotorer från utvecklarnas synvinkel och ur en prestationssynpunkt, men de är väldigt olika väldjur och de har sin egen lilla nisch i världen att skära ut antingen prestanda i minnet eller linjär skala på disken. Men så ser världen ut i databasvärlden. Det här är 2016, detta är versionen tre av kartan över, av en rad människor som producerar denna pågående landskarta över hur databaser ser ut, och det är här det - inte ens en övermänsklig databasarkitekt eller databasadministratör kan vara vettigt av det. Bokstavligen hundratals, och hundratals, och hundratals olika märken, modeller, tillverkare av databaser, alltid SQL-kompatibla. Och det intressanta är att de kommer tillbaka till samma utmaning. Prestanda och prestandajustering runt databasmotorn, och särskilt av hur data indexeras.
Så låt oss bara snabbt täcka databasindexering, eftersom det är ett intressant ämne, och du måste gå in på det mer detaljerat med demon, tror jag. Men jag tror att det är ganska väl accepterat och standardbranschpraxis att databasindexprestanda är där världen börjar och slutar så långt som att säkerställa att dina data är tillgängliga i ett snabbt och snabbt format. Men vad är databasindex? Om vi funderar på indexering i den form som vi är vana med som vardagliga människor, tänk på en indexsida i en bok. Om du vill hitta något i en bok - speciellt som en uppslagsverk, eller något liknande ett referensmaterial av någon form - om du letar efter något liknande den här sidan, där jag letar efter saker som ämnet dammar i ett uppslagsverk. Jag vill hitta alla hänvisningar till dammar, avrinningsvatten och ett stort uppbyggnadsområde, allmänt tillverkat. Jag går tillbaka, jag hittar det i en alfabetiserad, sorterad lista, A till Z, från vänster till höger, och jag hittar D. Jag hittar ordet "dammar" och jag kan se det på sidorna 16, 38, 41 finns en hänvisning till dem, och sedan kan jag gå till de sidorna, jag kan skanna ner mina ögon och jag hittar referensen till ordet "dam." Det är i princip samma koncept i en databas, men det är nu en raketvetenskap på många sätt. Så mycket att faktiskt varje databasadministratör som jag någonsin har lärt känna väl anser att index är det enskilt mest kritiska verktyget för att ställa in prestanda i vilken databasvärld som helst, oavsett vad deras erfarenhet kan vara för att kasta tenn på det, eller oavsett fall.
I allmänhet när vi pratar om databasindexering finns det ett antal vanliga metoder. Och ju mer komplexa databasindex blir, desto mer komplex är metoden att indexera data. Men i huvudsak när du funderar på att indexera data - föreställ dig att vi har en fil som har en lista med namn; de får inte sorteras i alfabetisk ordning. Låt oss föreställa oss att det finns tjugo av dem. Om vi ska sortera - om vi ska söka efter data i listan, från topp till botten, och låt oss säga att det är en lista med namn. Om jag väljer ett slumpmässigt namn och börjar rulla ner den listan, från topp till botten, i ett linjärt format och det är en oordnad lista, finns det två kriterier som jag tänker på som min genomsnittliga söktid och min maximal söktid - och Jag har en skrivfel i den andra raden, borde vara "maximal söktid", ledsen - men min genomsnittliga söktid är i princip N plus en, dividerad med två, och det är i genomsnitt, det tar mig femtio procent av tiden för att skanna från toppen av listan, till botten av listan för att hitta någon slumpmässig sak i den listan. Och den andra raden där, under linjär, borde vara "maximal sökningstid." Men den maximala söktiden är i huvudsak antalet artiklar, och det är att om jag har en lista med tjugo saker, att det mest tid kan ta mig att söka efter något i den databasen är att gå från toppen till botten, vilket säger 20 artiklar i detta förenklade exempel. Och det är en mycket långsam process och det finns verkligen inget sätt att prestanda stämma in det. Och så finns det andra typer av sätt att ta den informationen och skapa ett index, som i själva verket är en kort lista med pekare till var de faktiska uppgifterna är, till exempel binär, B-träd, bitmapp, hashing, klusterad och icke-klusterad, och sedan finns det olika typer av data som rumslig, filtrerad, XML och fulltext.
Binär är en mycket vanlig användning för saker där uppgifterna lämpar sig för det. B-träd är förmodligen den enskilt vanligaste i allmänna bemärkelser, historiskt sett, eftersom det är ett vanligt sätt att strukturera ett index till vilken form av data som helst och gör att loggar, markeringar och infogningar och raderingar är relativt enkla när du flyttar pekare runt hänvisning till pekarna, punkterna. Det finns andra typer, till exempel bitmapp, där datatyper gäller som om vi har ett associerat intervall av någon form. Hashing fungerar mycket bra för stora objekt, särskilt bloggar och bilder. Och du kan se att det finns ett antal olika typer av vetenskapliga tillvägagångssätt, matematiska tillvägagångssätt, för att indexera data. För de dödliga är de en intressant utmaning att prata om på denna nivå. När du pratar om det på prestandanivå för en databasadministratör blir de verkligen en raketforskare och folk gör grader i dem, och jag vet att doktor Robin Bloor verkligen har gjort det och skrivit böcker om det som IBM och andra stora varumärken under de senaste decennierna. Och så, min åsikt, är att vi faktiskt har gått en tid där, du vet en gång skulle jag personligen kunna sitta framför ett system och jag skulle kunna dra det isär och visa dig exakt var prestandafrågorna befann sig på en kommandorad eller ett grafiskt användargränssnitt startverktyg, och börja fördjupa i data och berätta var problemen var, och bygg index, eller subindex eller primära och sekundära index i det data och börja använda dem för att hitta saker. Men när du tänker på det landskapet som jag visade dig, där vi har hundratals och hundratals märken, märken och modeller och tillverkare och typer av databaser, är vi väl och verkligen förbi den tiden nu, där en människa kan skapa känsla av vilka typer av databasmotorer vi har. Särskilt, även om vi bara kommer tillbaka till liknande som Oracle, dominerande domäner idag i relationella databasplattformar.
Antalet databaser de måste hantera antingen från en egen plattform som ett ERP- eller HR- eller finanssystem, eller om de är en hembakad plattform av olika skäl, antalet databaser och databastabeller och poster som vi slutar att hantera är bara astronomiska och du kan fysiskt inte göra det för hand. Och vi har fått en ytterligare komplikation nu, där en gång ibland en databaseserver bara kan sitta under skrivbordet. Du vet att jag som ung efter skolan brukade arbeta med databasprogramvara på, ursprungligen Apple IIes och sedan DOS PC-baserade system, som dBase II, dBase III, genomgick en era med mainframes och mid- räckvidd och till och med VAX och PDP och loggfil på det. Och liknande av Saber, och så småningom när några av SQL-databaserna kom med. Men i dag när vi funderar på databasmotorer ser de ut som i det nedre vänstra hörnet. En databaseserver är inte bara en maskin som sitter på golvet under ett skrivbord längre; det är hundratals maskiner som kör kopior av databasmotorer och kluster, och de skalar upp till hundratals och hundratals terabyte data, om inte petabyte med data, vilket är tusentals terabyte. Och till det yttersta, som doktor Robin Bloor nämnde, att vissa specifika användningsfall - flygbolag, särskilt myndigheter - kan komma till exabyter. De är fortfarande ganska nisch, men hundratals terabyte och till och med dussintals petabyt är inte ovanligt längre, särskilt från dotcom-boom till nu, typ av vad vi kallar webb 2.0-företag, som Facebook, Google, Yahoo och så vidare.
Vi har också komplikationen nu när saker flyttas till extern tjänst. Vi har infrastrukturplattform och mjukvara som en serviceinriktning som tillhandahåller infrastruktur. Och särskilt plattformstjänster där vi inte bara kan köpa för Oracle och deras molnplattform, databaser och servrar. Och så gör det möjligt för oss att göra en snabb utveckling av applikationen och bara ansluta en databas tillbaka till servrarna. Vi behöver inte tänka på vad som är under huven. Nackdelen är att vi ofta inte tänker på hur vi designar och implementerar databasen igen förrän den börjar skada och prestanda blir ett problem och sedan måste vi leta efter rätt verktyg för att diagnostisera varför vår databas gör ont och där prestationsfrågorna är. Och alltid leder det tillbaka till det vanliga problemet med hur vi har indexerat dessa data och de typer av index som vi har använt för den informationen och som sedan leder oss tillbaka till supermänskliga prestandakrav. Och någon som har tillgång till de rätta systemen och de rätta verktygen för att prestanda ställa in de motorerna och börja hitta en het plats och titta på var frågorna är, var data rör sig, vilka typer av frågor, hur frågorna är strukturerade, vem gör frågorna och om frågorna står i kö och måste cache. Vilken replikering letar du efter?
Och så är vi väl och verkligen - enligt min mening - vid en tidpunkt där till och med världens bästa databasguruer, i huvudsak våra databasarkitekter och vår databasadministratör och prestandabaser, enligt min uppfattning de verkligen behöver börja använda rätt verktyg för att leverera optimal prestandaindexjustering för alla databasmotorer. Eftersom skalan som vi har att göra med och hastigheten som saker rör sig på kan vi helt enkelt inte göra det för hand, och att försöka göra det alltid kan introducera andra prestationsproblem, eftersom vi kanske inte har erfarenhet i det utrymmet som vi försöker lösa ett problem i. Och jag tror att det är där vi håller på att lämna till Bert, och vi håller på att prata om hur de har löst detta varierande problem och den typ av saker som deras verktyg kan gör, särskilt för Oracle-världen. Och med det där, Bert, ska jag överföra till dig.
Bert Scalzo: Tack. Välkommen alla, jag heter Bert Scalzo, jag arbetar för IDERA. Jag är senior produktchef för några av våra databasprodukter. Jag kommer att demonstrera några av dem idag. Men jag vill prata om index, eftersom jag håller med om allt som alla har sagt här, särskilt den sista bilden, att index är så komplicerade nu att du behöver ett verktyg, och jag hoppas övertyga dig. Så Oracle indexdesign, det är inte så lätt som det brukade vara i gamla dagar. Många människor kommer att vara osäkra på sig själva när de tittar på alternativen, och jag gillar detta att säga att jag drog ut från historien, "i dessa frågor, den enda säkerheten, är att ingenting är säkert." Och det är så jag typ av känsla för index i dag, för även om du tror att du vet att svaret ska du indexera X, Y eller Z kan du verkligen inte vara säker förrän du försöker det, eftersom dessa optimisatorer ibland uppför sig annorlunda som du förväntar dig. Och så det finns mycket test och fel med indexdesign. I de gamla goda dagarna, om du behövde ett index fanns det i allmänhet bara två frågor, eller en fråga. Var det unikt eller var det inte unikt? Och du kanske har tänkt på andra saker som "Hur många index kan jag ha maximalt på ett enda bord?" Eftersom för många index bromsar dina insatser, uppdateringar och raderar. Du kanske också varit i ditt databassystem, hade begränsningar för hur många kolumner som kan vara i ett flerspaltarindex, för ibland fanns det gränser baserade på databasmotorns sida eller blockstorlek, men i verkligheten var det ganska enkelt tillbaka under de goda gamla dagarna. Du indexerade antingen eller så gjorde du det inte. Och egentligen var allt i ett B-träd. Vi kunde tillåta dubbletter eller inte, och det handlade om det. Livet var bra, livet var enkelt.
Tja idag, livet är inte så bra eller så enkelt. Jag har lagt den röda Ghostbuster-skylten på det sätt vi brukade göra det, för nu har vi B-tree kontra bitmapp, kontra bitmappsanslutning. Och jag kommer att förklara vad några av dessa är på ett ögonblick. Klusterade och icke-klusterade, unika eller duplicerade, framåt eller omvänd ordning, funktionsbaserad, partitionerad eller inte partitionerad. Om det är partitionering är det globala eller lokala partitioneringar? Jag förklarar det också. Och sedan finns det också något som kallas ett indexerat organiserat bord. Och det finns faktiskt ett halvt dussin andra som jag har slutat härifrån, för jag tror att jag har tillräckligt här nu som borde övertyga dig om att index är mycket tuffare än du kanske trodde. I den här bilden kommer jag att börja längst upp till vänster i diagrammet och jag har en tabell. Och det första jag måste bestämma är, beroende på din databasversion och din databasleverantör, tillåter de objekttabeller eller är de bara relationella? Jag kommer att gå ner till höger och säga att vi bygger ett relationstabell. Nu är nästa fråga jag måste ställa mig själv, är den i ett kluster? Och många av er som har gjort Oracle under en tid kommer att komma ihåg att kluster var tillbaka för Oracle 6 dagar. De används förmodligen inte särskilt hårt längre idag, men låt mig gå ner den grenen först.
Om jag skulle lägga mitt bord i ett kluster, måste jag ha ett klusterindex på det bordet. Nu, i Oracle, när du grupperade ett bord lagrade du i grund och botten raderna eller raderna var nära varandra där värdena var liknande. Och så måste du ha ett klusterindex och det klusterindexet kan inte delas upp. Med andra ord fanns det egentligen inga partitionsmetoder för hur du skulle göra en grupperad tabell. Det var strikt icke-partitionerat. Och eftersom den inte var uppdelad var den global. Jag kommer att förklara vad det globala är på en minut. Och det var alltid B-träd. Med andra ord, när jag gick ner den grenen, var det ganska enkelt, jag hade inte många val. Nu, om jag gjorde ett icke-klusterindex på ett klustertabell, vilket var tillåtet i vissa versioner, var det igen icke-partitionerat; när det inte är partitionerat, är ditt enda val globalt. Och så, där har du valet av B-träd eller bitmapp. Återigen berodde det på din version av databasen. Men nu, låt oss gå tillbaka till relationstabellen och börja gå ner till höger sida igen och nu ska vi bara ha ett vanligt, gammalt, regelbundet, högt bord: relationellt. Det kommer att ligga på ett bord. Jag går lite ner till höger här först. Så det är organisation, hög. Nästa fråga som jag måste ställa mig är: "Vill jag dela upp tabellen eller inte?" Nu, ibland skulle du partitionera eftersom du tänkte, "Hej, optimeringsprogrammet kommer att vara smartare om hur den kan optimera frågor. ”Men många DBA kommer att säga att skälet till att du gör det är för administrativa ändamål. Om du har ett bord med hundra miljarder rader, om du delar upp det i partitioner eller hinkar, när du vill lägga till data i den sista skopan, kan du släppa och indexera det är bara några miljoner rader. Du kan infoga den informationen och sedan kan du bygga om det indexet på just den hinken.
Även om det var en bra teknik för vissa, optimeringstekniker som eliminering av partitioner, var dess verkliga värde att kunna administrera eller utföra administrativa uppgifter på mindre delar. När jag går till organisationshögen var den första frågan: "Delade jag in den eller inte?" Låt oss gå till vänster, jag kommer inte att dela upp bordet. Nu kan det tyckas konstigt när jag berättar det här, men du kan ha en icke-partitionerad tabell och då kan du inte partitionera indexet som du är van vid, eller så kan du partitionera indexet. Stanna upp och tänk efter. Ditt bord har i princip en hink, som du alltid har tänkt, och ändå kommer ditt index att ha flera hinkar. När det händer, där det finns ett missförhållande mellan antalet hinkar och bordet, och antalet hinkar i indexet, är det vad som menas med globala. Och så, om tabellen inte är partitionerad, och om indexet är partitionerat, betraktas det som globalt, eftersom det finns ett missförhållande. Låt mig nu gå tillbaka till min organisationshöga och komma ner istället på partitionssidan. Om jag nu har en partitionstabell, och låt oss säga att bordet har fyra hinkar, fyra partitioner, kan mitt index ha fyra hinkar så att mitt index matchar min borddesign. Och så är det över, långt över, på höger sida. Det skulle betraktas som lokalt. Ett lokalt index betyder i princip att uppdelningen av tabellen och indexet görs på samma sätt och har samma antal skopor. Och när jag väl har det lokala indexet kan det vara ett B-träd eller en bitmapp, och den gröna pilen som den typen går upp visar dig att även om det är ett B-träd finns det fortfarande val som kan göras. Det kan vara funktionsbaserat. Och om det är en bitmapp finns det olika typer av bitmappar. Det finns något som kallas ett bitmappsanslutningsindex. Om du gör datalagring är det en mycket populär typ av index för stjärnschema eller design. Vad som händer är att indexet har rad-ID: er för vad det pekar på i tabellen, men det kommer också att ha rad-ID: er för överordnade tabeller så att när du är - du måste stjärna schema design och du letar vid ett faktabord pekar det indexet på faktabellen dig på de data du är intresserad av och pekar dig till varje rad i dina dimensioner, så att du bara måste ha ett index.
Och faktiskt kom detta till på grund av Red Brick, som var en databas för många år sedan - många kanske kommer ihåg det. Och så om du tittar på den här bilden - och kom ihåg att jag inte lagt allt i den här bilden eftersom bilden skulle bli mycket större - finns det fortfarande ytterligare problem, som jag har i texten här längst upp till höger. . Är det ett omvänd ordningsindex? Och du kan säga, "Varför skulle jag vilja ha ett omvänd ordningsindex? Det är inte alls vettigt. ”Tja om du befinner dig i en klustermiljö i Oracle, om du gör riktiga applikationskluster, om du håller dina index i ordning, så omvända, om du har mycket bearbetning som slår samma värden eller samma indexvärden, vad som skulle hända är att du har heta områden i ditt B-träd. Vilket innebär att du skulle ha stridighet och eventuellt låsning för att försöka få tillgång till det, och du skulle göra det över noder i ett nätverk. Tja, om du lägger in ett omvänd ordningsindex kan du ångra det. Du kan säga, "Tja, de liknande värdena finns i olika delar av träden, så jag har inte mina separata noder som tävlar om heta områden i trädet." Och märker också att det unika inte fungerar med några av alternativen . Om du tittar har jag numrerat tre, fem, åtta och elva, så det finns några fall där jag inte kan ha ett unikt index. På samma sätt finns det några fall där jag inte kan ha ett omvänt index, och sedan finns det ytterligare problem som loggning eller ingen loggning, och parallell och icke-parallell. Jag kan tilldela saker till ett specifikt område i minnet.
Och detta lämnar fortfarande en hel del funktioner i Oracle. Jag skulle säga att när du tittar på Oracle 12 finns det förmodligen igen cirka ett halvt dussin saker jag kan lägga till den här bilden. Indexering är verkligen komplex och jag håller verkligen med tidigare talare. För att navigera igenom detta och göra ett bra val behöver du ett verktyg. Du kanske behöver en bild som denna och någon form av metod för hur du skulle välja saker och förhoppningsvis skulle verktyget hjälpa dig att komma dit. Och då kommer det att vara rättegång och fel. Jag berättar alltid för folk om indexering, "titta innan du hoppar." Och så kan du se den lilla hunden här, han hoppar utan att titta, han kommer att hamna i vatten med hajen, eller killen redo att hoppa i vattnet, och han kommer att impalera sig själv. Du måste tänka på din indexering, för att skapa ett index betyder inte alltid att saker blir bättre. Att skapa ett index kan faktiskt bromsa ner saker. Och frågeställningar kan vara en storleksordning bättre med ett val framför ett annat. Och jag ska ge dig ett bra exempel. Om du gör ett stjärnschema med design, och på dina dimensionstabeller använder du bitmappsindex i ett fall, och i ett annat fall säger du: "Jag kommer att använda B-trädindex", har du bitmapp kontra B- träd. Jag kan säga er att en lösning kommer att vara en storleksordning eller eventuellt flera storleksordningar snabbare än den andra. Men kom ihåg vad som fungerar i en miljö, som i en datalagermiljö, förmodligen är inte ett bra val i en OLTP-miljö.
Om du till exempel skulle ta en transaktionstabell och sätta bitmappsindex på ett transaktionsbord är det dyrt att beräkna och återställa bitmappar, dessa långa strängar, och så i en OLTP-tabell, kan du slå tabellen så kraftigt att bitmappen index kan bli skadat och sakta ner systemet eftersom de bara inte är avsett för uppdateringar. De är bra för snabb åtkomst, men är inte bra för uppdateringar. Jag tror att index tar prov och fel. Det finns verkligen ingen gyllene regel längre - det finns för många olika variabler i denna ekvation att veta - och i slutändan måste du titta på utförandet eller förklara planer i din databas för att se om du gör bra val eller inte. Och ibland kan plananalysen nästan vara en vetenskap för sig själv. Jag tänker inte täcka det idag - det är ett annat ämne - men tar inte indexdesign för givet. Det finns legitima skäl till varför det finns alla dessa galna indextyper som jag visade dig, i föregående bild, och som den tidigare talaren talade om. Dessa skapades inte bara för det var en snygg funktion att sätta på en checklista någonstans för en databasleverantör; det finns användningsfall eller scenarier där dessa index är viktiga och kommer att göra en betydande skillnad. Nu med det ska jag visa dig några exempel på olika typer av index i ett av våra verktyg. Låt mig bara få upp min skärm så att du kan se den. Okej, så här sitter jag inne i - låt mig minimera den här applikationen. Jag sitter inne i VMware och kör en Windows Server 2012 VM.
Och du kan se, jag har nästan alla verktyg som man känner till. Som produktchef måste jag hålla mig medveten om min konkurrens, så det är inte bara vilka verktyg jag har, utan vad gör mina konkurrenter? Och vi har det här verktyget som heter DBbrevan, som jag redan har kört, men jag kommer - så jag ska bara ta upp det. Och vad du kan se är att detta är ett riktigt trevligt verktyg, för istället för att behöva använda, säger en företagschef för Oracle och en SQL Management Studio för SQL Server, och MySQL Workbench för MySQL, och tolv andra databaser som vi stöder, Tja, jag har alla mina databaser inbyggda i det här verktyget. Det finns DB2, det finns MySQL, Oracle, Postgres, SQL Server och Sybase, och det är - jag har bara sex databaser i just denna sak eftersom jag inte kan - verktyget stöder tolv databaser men min dåliga VM, som kör sex databaser samtidigt och försöker att göra en demo, är ungefär lika mycket som min hårdvara kommer att underlätta. Så låt mig gå tillbaka till Oracle nu, och om du märker att alla dessa saker är desamma. Om jag vill mäta mina prestanda i DB2 är det samma val som jag skulle ha i Oracle. Nu under omslagen gör vi massor av olika saker så att du inte behöver veta vad som händer, men vi ger dig ett konsekvent gränssnitt så att du kan vara en expert med flera databasplattformar. Och det skulle inkludera att arbeta med index, ämnet för denna diskussion.
Låt mig komma in här och låt mig först börja med att titta på några tabeller, så har jag en filmdatabas som bara har några tabeller. Och om jag ser ett visst bord, som kundtabellen, när jag tar upp det här, kan jag se min borddesign, här är mina kolumner i min tabell och här är information om varje kolumn. Jag har egenskaper för tabellen, men observera att jag har en flik här för index och jag kan se att här är indexen på bordet. Lägg märke till att ett av dessa index är mitt PK-index, min primära nyckel. Dessa andra ser ut som att vara bara index för att förbättra åtkomst till frågor, kanske vi frågar efter förnamn eller efternamn, eller vi tittar på telefoner och postnummer. Och om jag väljer ett visst index, som det här postnumret här, och jag dubbelklickar på det, nu kan jag se att hej, det är ett icke-unikt index och här är några av de andra typerna, bitmapp, icke-unik, unikt, oavsett om det är sorterat eller inte, oavsett om det loggar eller inte, om det är omvänd ordning eller inte, oavsett om det är en funktionsbas. Åh, här är en rolig som jag inte täckte. Du kan faktiskt ha osynliga index. Och du skulle säga, "Tja, varför skulle jag vilja göra ett osynligt index?" Tja, jag ska ge dig ett bra exempel. Du är i ditt produktionssystem och du har ett prestandaproblem och du är inte säker på att skapa indexet kommer att lösa problemet, så du vill inte skapa indexet och bromsa produktionen, men på något eller annat sätt vill du kunna testa det. Du kan skapa indexet i produktionen som osynlig, vilket betyder att inte många applikationskoder, kallar optimeringsprogrammet, kommer att använda det indexet. Det har skapats, det är giltigt, men det kommer inte att användas. Då kan du ta en fråga som du tror att detta index skulle hjälpa till, eller en serie frågor, och du kan sätta in en antydan och säga, "Hej, optimizer, det finns ett osynligt index där ute. Jag vill att du ska använda och låta jag vet om jag har gjort saker och ting bättre. ”Och nu har jag testat något i produktionen, men jag har inte brytts med applikationerna i produktionen som var igång. Det är användningen för ett osynligt index. Det låter dumt när du först hör om det, men det har en användning.
Vi kan också på index definiera om de är parallella och även hur många instanser de är parallella över. Nu, i en icke-klusterad eller en icke-verklig applikationsklusmiljö, så att icke-rack, parallell skulle betyda hur många delprocesser kan min fråga ta upp för att försöka, och arbetarprocesser, för att försöka få saker igenom snabbare eller snabbare . Och parallella instanser skulle vara, om jag är i en riktig applikationskluster, säger att jag har tio noder, hur många av noderna får jag dela upp arbetet? Kanske är det fyra av de tio, och på var och en av dem, fyra delprocesser. Det är ett exempel. Och sedan har vi nyckelkomprimering. Du kan faktiskt komprimera index? Ja eller nej. Och så har du naturligtvis dina lagringsparametrar som du kan ange i index. Nu täckte jag inte dessa eftersom de egentligen är mer en lagringsparameter än ett indexproblem. Och slutligen har vi om vi ska göra dessa partitionerade eller icke-partitionerade eller inte. Låt mig släppa det här en stund. Jag ska gå till ett annat schema. Detta är ett stjärnschema och till exempel är denna periodtabell en dimensionstabell. Om du någonsin har gjort stjärnschema design har du vanligtvis en dimension för tiden och så i den här databasen och detta stjärnschema är period en tidsdimension. Nu, jag vet att det kommer att se roligt ut, du kommer att säga, "Gee, titta på alla de kolumnerna - har killen någonsin hört talas om normalisering?" Tja, när du är i ett datalager eller en stjärnschema design, du har vanligtvis icke - du har tabeller som en typisk person skulle titta på och säga: "Tja, dessa är inte särskilt väl utformade." Men det är så du gör det i en datalagermiljö.
Nu, se vad som kommer att hända eftersom okej, det finns alla dessa kolumner, titta på det, jag har ett index på varje kolumn. Nu, i en OLTP-miljö som skulle vara ett nej. Det skulle bromsa alla mina aktiviteter. I en datalagringsmiljö skulle jag släppa dem under min batch-belastningscykel. Ladda utan omkostnaderna eller indexen, och jag skulle återskapa indexen. Och om jag partitionerade mitt bord, i stället för att behöva släppa indexet för varje hink i tabellen, kunde jag bara släppa indexet på skopan eller skoporna där data skulle gå in under den batchbelastningscykeln. Och återskapa sedan bara indexdelen för dessa hinkar. Och så det gör det mycket hanterbart. Och om jag tittar på - så här är en kolumn som heter "Holiday Flag" och i princip är det ett ja eller nej. Lägg märke till att det här är ett bitmappsindex, och för de flesta av er säger du: "Det är meningsfullt." Ja eller nej, Y eller N, det finns bara två värden som är vettiga. Och eftersom du läser dokumentationen för bitmappsindex säger de alltid att du väljer något med låg kardinalitet.
Låt mig nu gå in i ett av mina faktabord, så här har vi mina beställningar. Och det här är mina beställningar per dag. Och du kommer att se nu, att jag igen har en hel del kolumner, och igen, jag kommer att ha mer än några index. Och just här har vi något som kallas den universella priskoden. Detta var för en butik, så du känner till de små streckkoderna när du köper något i butiken, det här är den universella priskoden. Nu finns det miljoner universella priskoder. För just det här företaget som sålde saker hade de förmodligen 1, 7 till 2 miljoner universella priskoder, så du kommer att förvänta dig att detta inte kommer att bli ett bitmappsindex eftersom 1, 7 miljoner distinkta värden låter som hög kardinalitet. Men i verkligheten, i en datalagermiljö, vill du att det ska vara en bitmapp. Låt mig nu förklara varför. Det kan finnas 1, 7 miljoner distinkta värden för denna universella priskod, antalet rader i denna ordertabell är i hundratals miljoner till miljarder rader. Mitt index är låg kardinalitet jämfört med tabellens storlek eller kardinalitet. Det gör det till låg kardinalitet. Det gör bitmappsindex användbart, även om det är intuitivt med 1, 7 miljoner distinkta värden som du skulle välja bitmapp här. Om jag nu visste att jag ville använda ett bitmappsanslutningsindex, för närvarande stöder inte produkten det, så får jag det till för nästa utgåva, men det skulle vara ett annat alternativ här. Och i ett stjärnschema, kom ihåg att bitmappsindexet skulle ligga på faktabordet och att ett index i B-trädet skulle peka på raden i faktabellen och sedan till varje rad som var uppenbar i dimensionstabellen för det faktum . Och så har du ett annat alternativ där. Och så, låt oss se, jag vill komma ut ur tabellerna nu och jag vill bara visa er snabbt att jag har samma information, under index, och jag kommer att göra samma grundläggande sak.
Anledningen till att jag tog upp detta är att du kanske märker, hej det finns inga primära nycklar här. Primära nycklar görs med en nyckelbegränsning, så de täcks faktiskt av begränsningsdefinitionerna. Dessa skulle vara index som inte ingår i begränsningen. Nu kan du säga: "Tja, vänta en stund, det kan se ut som en utländsk nyckel och en utländsk nyckel är en begränsning." Men utländska nycklar och de flesta databaser skapar inte automatiskt ett index i kolumnen med utländsk nyckel, även om det är rekommenderas, och där går du - jag har alla samma val igen. Och om jag vill ändra bara för att komprimeras, kan jag göra det.
Nu fungerar komprimering bara på ett B-trädindex. Det som tillåter är att när du tittar på de olika noderna i B-trädet gör det möjligt att komprimera några av värdena. Det är verkligen inte komprimering som tabellkomprimering, det är en komprimering av vad som är lagrat i B-trädet i icke-bladnoderna. Det sparar inte massor av utrymme, men det kan göra en skillnad. Och med det märkte jag att jag kommer ganska nära tiden, så det jag vill göra är att jag vill gå tillbaka och sluta dela med mig. Och vi har vår produkt där ute för en fjorton dagar rättegång på idera.com. Det är en ganska bra produkt, särskilt om du arbetar med flera databasplattformar. Om du arbetar med två eller tre olika databaser kommer detta verktyg att göra ditt liv mycket enklare. Vi har verktyg som hjälper dig med indexdesign och val, vi har ett verktyg som heter DB Optimizer. Jag kunde inte täcka det idag, det skulle bli för mycket. Och om du vill kontakta mig, det finns min e-postadress, det är, eller så kan du hämta mig på min privata e-post, och jag har bloggar, jag har en webbplats och bloggar och en LinkedIn-profil där. Så känn dig fri att nå ut till mig om allt, även om det inte är produktrelaterat, om du bara vill prata databaser, jag är en nörd i hjärtat och jag älskar att gabba om technobabble.
Eric Kavanagh: Okej, tja, Robin, jag är säker på att du alla har ett par frågor åtminstone, vi har några minuter kvar här. Dez, vad tycker du?
Dez Blanchfield: Jag har en bra fråga jag måste ställa dig, det har satt mig bakom mitt sinne. Vad är det galnaste scenariot du har sett? Jag har läst din blogg, jag följer dig noggrant, du är förmodligen en av de få människor som har bott i nästan alla osannolika, och jag tror att Dr. Robin Bloor är den andra som jag träffat i min livstid. Men, du vet, du har förmodligen sett alla galna scenarier, vad är några av de galnaste scenarierna du har sett, att du har stött på, och som människor som bara inte kunde klara, har du lyckats gå och utföra Jedi-mind-tricks med hela DBarusan?
Bert Scalzo: Vi hade en kund en gång som de i sin databasdesign tänkte mycket på det sätt de skulle tänka i en fillayoutdesign, och så, det - när du normaliserar en databas, det första du försöker göra är att bli av med att upprepa grupper. Tja, de hade en kolumn och de gjorde den till en lång, eller en BLOB eller CLOB, och i den skulle de sätta värde, nummer ett, semikolon, värde nummer två, semikolon, värde nummer, semikolon, och de skulle ha tusentals värden där inne, men de behövde söka i den kolumnen och de är som, "Varför går den här saken så långsam?" Och jag är, "Tja, du kan inte skapa ett index för vad du gjorde, det är bara inte tillåtet. ”Så vi visade dem faktiskt med planerna att det de behövde göra var att normalisera den tabellen. Inte för att normalisering är en akademisk övning som gör saker bättre, utan för att de ville ha en fråga på det fältet, vilket innebar att de ville kunna indexera det, och du kunde inte indexera det på en upprepande grupp, eller åtminstone inte lätt . Och så det är förmodligen det värsta jag någonsin sett.
Dez Blanchfield: Ja, det är intressant hur ofta du stöter på, jag tror att utmaningen med databaser, människor glömmer att det är en vetenskap. Och det finns människor som gör examen och doktorander i hela detta utrymme, skriver papper om det, och du har skrivit en hel swag inklusive dina TOAD-handböcker och andra saker från minnet. Trenden mot typ av "stor data" offert-på-offert nu - jag ser många människor glömma grunderna i databasarkitektur och databasteknologi, databasvetenskap, om du vill. Vad ser du ute i fältet så långt som skiftet från traditionella databasplattformar och traditionell databas tänker att vi effektivt spikade till marken, och det var bara ett fall av prestandatuning och skalning. Ser du att många människor läser igenom och har en upplevelse där de bara sitter där och har ett "a-ha" ögonblick, som ett eureka-ögonblick, där de inser att detta big data-grej egentligen bara är en sorts riktigt stora databaser? Är det något där ute och människor svarar dig tillbaka och typ: "Vi har glömt, vad vi visste och kan du föra oss tillbaka från den mörka sidan?"
Bert Scalzo: Tja, nej, och det är hemskt att behöva erkänna, men de relationella databasleverantörerna har också drack den Kool-Aid. Om du kommer ihåg, jag vet inte, för ungefär ett decennium sedan började vi lägga ostrukturerad data i relationella databaser, vilket var något av en konstig sak att göra, och sedan lägger nu data, de relationsdatabaser, NoSQL-typen grejer. Faktum är att i Oracle 12, CR2 - jag vet att det inte är ute än - men om du tittar på beta, om du är i beta-programmet, stöder det skärning. Och så, nu har du en relationsdatabas som inte har lagt till konceptet från NoSQL-skärning. Och så, "a-ha" -momentet verkar vara mer för människorna på den relationella sidan som går "a-ha." Ingen kommer någonsin att göra det rätt igen, inte ens databashanterarna, så vi har fick gå över och gå med i den mörka sidan.
Dez Blanchfield: Okej, så du säger en övergång till en hel del av röriga data, om jag förstår rätt, läggs in i det vi nu kallar big data-plattformar, vilket är lite roligt, för de är inte så gammal, men betyder det inte att de åter fokuserar på vad de gör med deras relationella databas för att få mer utrymme för pengarna?
Bert Scalzo: Nej, vanligtvis, om de har ett behov i - det skulle ha citerat ett "big data-typbehov", upptäcker de att istället för att behöva gå till den andra databasplattformen och göra något i en icke -relaterat sätt, databasleverantörerna ger dem nu samma icke-relationella tekniker i sin relationsdatabas för att göra dessa saker. Jag menar, ett bra exempel skulle vara, om du har ostrukturerad data, som en JSON-datatyp eller någon annan komplex datatyp som har betydelse inbäddad i själva uppgifterna, stöder databasleverantörerna inte bara det, utan de ger dig syra efterlevnad av ostrukturerad data. De relationella databaserna har tagit emot de nyare teknikerna och teknologierna, och återigen verkar ”a-ha” vara mer inte, ”Hej vi, applikationsutvecklarna, har avläst något och vi måste lära oss det igen”, det är ”Hej, vi gör det så här nu, hur kan jag göra det på så sätt i din traditionella relationella databas och göra det som jag gör i den här databasen här? ”och det blir mer utbredd, och som sagt, databasleverantörerna själva möjliggör det där.
Dez Blanchfield: Höger, vem är de traditionella misstänkta i det här utrymmet för verktyget DBwartan och det? Jag gjorde några läxor om det du skrev nyligen, och från minnet hade du skrivit något, jag tror att det var en av dina bloggar, om extrem databasprestanda i Oracle-världen. Jag kan inte komma ihåg när det var, jag tror att det var någon gång i år från minnet, eller från slutet av förra året, du hade skrivit den här saken. Och det verkade för mig att det var den traditionella, vanliga misstänkte för den typ av ämne vi pratar om idag, där människor kommer att gå till en mycket stor databasmiljö och leta efter vad du kallar extrema vinster i det. Vem är de vanliga misstänkta att du ser där ute som tar upp DBwartan och använder den bra?
Bert Scalzo: Tja, vi har många kunder, faktiskt idag var jag på med en mycket stor myndighet som - och de har bokstavligen antagligen nära 1 000 exemplar av vår programvara, eftersom det gör att människor kan fokusera på vad de har gör igen, och inte hur man gör det. Och det är okej, jag menar, alla borde veta hur man gör något, men produktiviteten får "vad" gjort. Om företaget ber mig att göra en uppgift är det allt de är intresserade av. När fick jag en bock för att säga när uppgiften var klar? Inte vilken teknik eller vilken teknik som jag använde för att komma dit. Och så låter vårt verktyg dem fokusera på vad, och låter dem vara mycket mer produktiva, och det är verkligen den enorma fördelen, och som sagt, vissa databaser erbjuder ett verktyg bara för deras databasplattform. Vi erbjuder det för tolv databasplattformar. Jag har samma arbetsflöde, samma grafiska användargränssnitt, samma navigeringar. Om du vet hur man beviljar ett privilegium till en användare eller hur man skapar en tabell eller skapar ett index i en databas kan du göra det i alla tolv eftersom det är samma utseende och samma arbetsflöde. Det har enormt värde för våra kunder.
Dez Blanchfield: Ja, jag antar att folk vill få mycket mer knep för sina pengar från sina mänskliga resurser. Och dagarna med att ha en individuell specialist inom Oracle, Ingres och DB2 är alla borta. Människor förväntas vara Jack of all handel, så jag tror att den här saken absolut har räddat deras liv.
Bara en sista snabb sak innan jag överlämnar det till doktor Robin Bloor. Du nämnde att det finns en gratis nedladdning i fjorton dagar, vad gör - om jag ska gå vidare och jag ska göra det, förresten, jag kommer att lägga det i Bloor tech lab och snurra det här upp och ta hand om det själv - jag hade inte haft en chans att göra det före idag. Du nämnde en fjorton dagar rättegång, du sa att du kör den på en VM på din dator, jag antar att det är en bärbar dator. Vad är det, hur är inställningen på startnivå för någon att ta hand om och använda den fjorton dagar långa rättegången, precis innan jag lämnar tillbaka till Robin till hans frågor?
Bert Scalzo: Varje Windows-miljö, så Windows 7, virtuell maskin med en CPU och fyra spelningar. Vi är inte ett riktigt fett eller dyrt verktyg. Om du nu vill köra din databasserver på samma VM under samma Windows, ja, du skulle behöva lägga till mer, men om du kör din databas på en databaseserver eller på en separat VM, kommer VM att ladda och kör vår produkt är väldigt lätt: en CPU, fyra minne, nästan vilken version av Windows som helst - och vi stöder både trettiotvå- och sextifyra-bitars installationer. Men du måste installera din databasförsäljares klient. Så om du ville ansluta till Oracle, måste du installera SQL-netklienten, eftersom det är vad Oracle kräver för att du ska kunna prata med en databas.
Dez Blanchfield: Det låter ganska enkelt. Jag tror att en sak härifrån mer än någonting som jag hoppas att människor kommer att ta bort, annat än insikten att detta verktyg kommer att rädda sina liv, är att de bör gå och ladda ner det och leka med det, med tanke på att du erbjuder en fjorton dagar gratis provperiod. Och den kan köras på deras nuvarande bärbara dator utan att installera något extra, för om de redan gör databasadministration, arbetar de redan med databaser har de alla dessa verktyg på plats och om de körs på en lokal VM eller på deras lokalt skrivbord, det låter som det är smärtfritt att installera och spela med. Så jag rekommenderar starkt att folk gör det.
Robin, jag är säker på att du har frågor och Eric, du har antagligen fått några från publiken, så Robin, vad sägs om att jag skickar till dig och sedan tillbaka till Eric?
Robin Bloor: Ja, okej, jag har saker att säga, jag menar, jag har alltid tyckt att detta område är fascinerande eftersom det var - jag klippte tänderna på det. Men sanningen är, antagligen sedan omkring 1998, 1999, har jag använt vad Oracle faktiskt kan. Och jag kände till Sybase och Microsoft SQL Server, båda är relativt enkla jämfört med vad Oracle kunde göra. Du fick mig att skratta när du - jag menar, jag täckte min mun, när du började prata om skärning. Oracle gjorde det tidigare. Oracle introducerade vid någon tidpunkt, de blev nervösa av den objektrelationella idén, så de introducerade förmågan att skapa en slags objektnotation och objektlagring i Oracle, och jag pratade med en av deras ingenjörer, något som ett par av år efter att de introducerade det och jag frågade hur många som använde det, och han sa att jag tror att två kunder hade provat det och det var det. Och jag tror att samma sak kommer att hända om de börjar försöka göra trendiga NoSQL-saker. Du vet, jag tror att det är ett misstag, jag menar, jag är lite intresserad av vad dina tankar är. Visst, de - de dricker Kool-Aid. De känner sig som om de måste kunna göra anspråk som liknar de stora NoSQL-databaserna som Cassandra, men du vet, har det någon mening för dig?
Bert Scalzo: Nej, du har slagit spiken på huvudet. För mig skulle jag, om jag ska göra relationellt, jag välja en relationeleverantör som en Oracle eller en SQL Server eller en DB2 eller en Postgres, men om jag ska göra något som är icke-relationellt, i big data-utrymmet, eller NoSQL-utrymmet, ska jag välja rätt verktyg för rätt jobb. Och jag tror inte att det skulle naturligtvis gå till min relationella databasleverantör först. Och sedan lägger du till den andra rynken till det, det vill säga, vad är tillgängligt i molnet? Så många som vill ha sina databaser från premisset. Då måste du titta på din molnleverantör och säga: "Okej, vad levererar du, vilka databaser har du tillgängliga för mig som passar mina behov och hur säljbara är de, och ärligt talat vad är kursen eller avgiften för att använda den databasen i molnet per timme eller per dag. Och per gigabyte eller terabyte? ”Och vad du hittar är kanske några av de relativt nyare databaserna som Mongo eller Cassandra, kanske är deras priser billigare, så om du ska göra stordata av multi-petabyte-typ, kan du måste - bara ur kostnadssynpunkt - tänka på NoSQL-databaserna i molnet eftersom de kanske är det mest kostnadseffektiva sättet att göra det på.
Robin Bloor: Ja, rätt. Jag menar, min typ av - saken med relationella databaser i min erfarenhet - som är tillräckligt lång för att ha ärr, det är säkert - det finns mycket sunt förnuft att om du börjar tillämpa det och - du förstår vad relationen egentligen är, att Jag menar att jag kom ihåg att jag skulle göra en konsultation med en kund en gång, och de ledde mig in i ett rum och de hade gjort ett slags entitetsdiagram och skapat en tredje normal form, en modell för hur företagets primära system var. Den hade två hundra fyrtio bord om och de sa: ”Tja, vad tycker du om det? Vi kommer att bygga en databas för detta, "och sa" Vad tycker du om det? "Jag sa, " Jag tror inte att det kommer att fungera. "Och det är exakt rätt, du vet, för de slutade upp för att skapa en viss struktur inom elva-vägs sammanfogningar. Och det är det man ska förstå om relationellt. Så jag är lite intresserad av hur mycket dålig design du stöter på. Jag menar, jag har inga problem med DBwartan - det gör väldigt förnuftiga saker och det faktum att du faktiskt kan visa ut på flera plattformar, tycker jag, är underbart - men hur mycket möter du där ute där designen är frågan där människor kunde ha löst sig alla typer av hjärta om de kom till ett stjärnschema snarare än att få snöflinga om det, vet du?
Bert Scalzo: Tja, jag vill inte låta som, presumptuous eller arrogant, men jag skulle säga ofta än inte. Det är uppenbart att majoriteten av databaserna som jag engagerar mig där ute har problem eller problem. Vilket är bra, eftersom våra verktyg, som vårt databasoptimeringsverktyg, kan hjälpa dem att lösa dessa problem, och, men det som verkligen är roligt för mig, är att många av problemen är samma enkla problem om och om igen. Jag jobbade bara med en kund häromdagen som hade en elva-vägs anslutningsfråga, och jag är, "Okej, varför använde du inte en med klausul?" Och de är som, "Tja, jag gjorde inte vet inte vad det är. "Och sedan sa jag, " Och titta på dina underval här på dina korrelerade och dina icke-korrelerade, "sa jag, " I vissa fall har du i din där klausul på djupaste nivå, en tabellreferens från det yttre. "Jag sa:" Det är, flytta den ut till rätt nivå, bädda inte in den djupare än den måste vara, du förvirrar optimisatorn. ”Och med några par tweaks vi tog något som körde ungefär två timmar och fick ner det till tio minuter och det var bara - i så fall gjorde vi inte annat än att förbättra SQL som de hade skrivit. Jag tror att problemet är att många universitet och många människor som lär sig programmering i en icke-akademisk miljö, de lär sig det som inspelade tidsprocesser eller radorienterad process och relation är en uppsättning orienterad av naturen, och så du måste tänka i uppsättningar för att skriva bra SQL.
Robin Bloor: Ja, jag tror att det är exakt rätt. Och du måste förstå, det är saker som, människor borde veta ABC: s sådana saker. Det spelar ingen roll. Du kommer inte att kunna göra rationella saker om du inte inser att även en väl utformad, välmodellerad databas, sammanfogningar tar tid, sorterar tar tid. De gör för att världen aldrig har hittat ett sätt att få dem att gå snabbt. De har hittat sätt att organisera data så att de går snabbare än annars, och mycket av den entusiasm jag har att säga för NoSQL-databaserna är helt enkelt att de undviker att gå med. De börjar bara bygga databaserna med samma spridning av data i dem, för om du går med i någon av NoSQL-databasarna suger de kraftigt. Tror du inte?
Bert Scalzo: Åh absolut. Och jag måste skratta, för jag började långt tillbaka före relationsdatabaser och tillbaka när Ingres var RTI, Relational Technology Institute, och vi hade inte SQL, vi hade för-SQL-relationella språk. Jag tror att Ingres, då, kallades det Quel. Så du fick från dessa gamla databasparadigmer som nätverk och ett högre grafiskt eller hierarkiskt, och du går igenom de relationella paradigmerna efter några decennier och nu känns det som om vi återgår till nästan en hierarkisk igen. Det är nästan som vi har återvänt.
Robin Bloor: Ja, rätt. Bättre överlämna dig till Eric, jag tar för mycket tid, men har vi några frågor från publiken, Eric?
Eric Kavanagh: Vi gör, vi har några. Vi går lite länge här men jag slänger ett par på dig. Vi hade ett par frågor kring de osynliga indexen. En fråga var: "Behöver någon använda ditt verktyg för att se dem?" En annan fråga var: "Tja, vad händer om du är blind?"
Bert Scalzo: Det är bra.
Eric Kavanagh: Nyfiken fråga också, så bara FYI.
Bert Scalzo: Nej, du behöver inte ha våra verktyg. Det är en Oracle-funktion, det osynliga indexet. I dataordlistan behåller Oracle bara en metadata som säger: ”Optimizer, ignorera detta index. Det är här, men såvida du inte fysiskt har instruerats via en antydning i, en optimeringstips i SQL-kommandot, använd inte detta. ”Och så, nej, du behöver inte ha våra verktyg och i alla avseenden det är ett vanligt gammalt index, du kan se det i vilket verktyg som helst, det är bara optimeringsprogrammet kommer att säga, "Vi kommer att ignorera det i normal frågeställning." Du måste rikta det om du vill att det ska användas. Det är verkligen praktiskt för det scenarie som jag beskrev vilket är att om du ville bygga ett index i produktionen men inte riskerar att bryta rapporterna eller de saker som redan körs, men du ville testa dem kan du göra det. Det är vad det är mest användbart för.
Eric Kavanagh: Det är bra grejer och då fanns det en annan bra fråga här. ”Vad sägs om några av dessa nya databaser i minnet? Hur förändrar databastekniken i minnet spelet när det gäller indexering? "
Bert Scalzo: Pojke, ja, det är nu bra, jag är glad att någon ställde den frågan, vi måste gå ytterligare en halvtimme. Nej, minnet, det beror på databasleverantören. Nu är jag normalt sett, jag talar inget annat än beröm för allt som Oracle gör för det är fantastiskt den teknik de har byggt, men när du riva tillbaka under täcken och du tittar på vad som finns i minnet i Oracle, i Oracle databas, vad det är i verkligheten är att det fortfarande hålls radlager på disken, och det kommer att laddas kolumnlager i minnet, och om det inte finns tillräckligt med minne för att hålla hela tabellen, kommer den att återgå till delarna; det passar inte i minnet, att göra det radlager, och så att du faktiskt kan göra ett val mot bordet och för halva bordet använder du en indexering som träffar traditionella rader vid bordet, och för den andra hälften av den väljer att den faktiskt går ut och bara tar tag i allt från en sökning i minnet, och så är det annorlunda på det sätt som till exempel SQL Server implementerade det med sin Hekaton-teknik, du vet, och SQL 2014, och det har förbättrats i SQL 2016, men i vissa avseenden, är deras en mer sann version av minnet och, men varje implementering har fördelar och nackdelar, men du måste snälla titta under omslagen och inse. Eftersom jag hade en kund som sa: "Åh det här bordets minne - jag kommer bara att skapa alla index, " och jag är, "Tabellen är större än det minne du har på servern, så vid någon tidpunkt måste en del av frågan träffa disken. ”
Eric Kavanagh: Det är en bra beskrivning; det är bra grejer. Tja, folkens, vi kommer att ha några webbsändningar till med dessa killar under resten av året, kom tillbaka när du hör att Bert är på en presentation eftersom vi vet att han känner till hans grejer. Det är alltid kul att prata med experterna. Vi arkiverar alla dessa webbsändningar för senare visning. Här är Berts kontaktinformation ännu en gång, och vi försöker gräva upp den länken för nedladdningen och skicka ut den också via e-post, men du kan alltid skicka din e-post verkligen: vi har ett antal fler webbsändningar upprättade för detta år och vi håller på med utbildningen just nu, så folkens, om det finns några ämnen som du verkligen vill höra om nästa år, var inte blyg: Var försiktig, folk, vi pratar med dig nästa gång. Hejdå.
Techopedia Content Partner
Techopedia Staff är anslutet till Bloor Group och kan kontaktas med alternativen till höger. För information om hur vi arbetar med branschpartner klicka här.- Profil
- Hemsida
