Index-waanzin: hoe database-chaos te voorkomen

2024

Inhoudsopgave:

Techopedia Content Partner
Techopedia Content Partner

Door Techopedia Staff, 5 oktober 2016

Takeaway: gastheer Eric Kavanagh bespreekt database-indexering met Dr. Robin Bloor, Dez Blanchfield en IDERA's Bert Scalzo.

Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.

Techopedia Content Partner

Techopedia Staff is aangesloten bij Bloor Group en kan worden gecontacteerd met behulp van de opties aan de rechterkant. Klik hier voor informatie over hoe we samenwerken met partners uit de industrie.

Profiel
Website

Eric Kavanagh: Dames en heren, hallo en welkom weer terug. Het is een woensdag om vier uur Eastern en degenen onder jullie die het programma kennen, weten wat dat betekent, het is tijd voor een nieuwe aflevering van Hot Technologies. Ja inderdaad. Mijn naam is Eric Kavanagh, ik zal uw moderator zijn voor de sessie van vandaag: "Index Insanity: How To Database Chaos." Of zoals ik het noemde in de laatste e-mailontploffing om 'database-ruzie' uit te gaan. Hot term tegenwoordig, 'ruzie'. Iedereen doet het. Er is echt een dia over die van jou. En genoeg over mij.

Dus de Hot Technology-serie is echt ontworpen om een bepaalde ruimte te definiëren, in tegenstelling tot de Briefing Room, die slechts één-op-één live analist briefing is, voor Hot Tech krijgen we twee analisten. Vandaag wordt het onze eigen dokter Robin Bloor en onze datawetenschapper Dez Blanchfield. En we hebben het over een onderwerp waarvan ik denk dat het vrij symbolisch is voor wat er vandaag op de markt gebeurt.

Het komt erop neer dat we ons tegenwoordig in een wereld van complexiteit bevinden. Echt, als je vijftien of twintig jaar terugdenkt, was het toen een heel andere wereld, vooral met betrekking tot databasetechnologie. Vroeger waren databases vrij eenvoudig. Er waren er maar een handvol; de meeste waren relationeel. Nu hebben we een hele reeks databasetechnologieën. Letterlijk talloze opties op tafel voor iedereen die een applicatie wil bouwen of iets met data wil doen. Alles verandert en dat beïnvloedt de mensen die proberen deze systemen te beheren. We gaan vandaag praten met Bert Scalzo, die een echte expert in het veld is; hij is het senior productmanagement voor IDERA, over wat u kunt doen om grip te krijgen op al die gegevens. Daarmee ga ik het overhandigen aan dokter Robin Bloor om het weg te nemen. Robin, de vloer is van jou.

Robin Bloor: Oké, bedankt voor die introductie. Ik denk het - omdat het iets met twee handen is, denk ik dat ik het gewoon zou hebben over database-optimalisatie in het algemeen als een inleiding tot deze Hot Tech-show. Ik begon mijn leven - in technologie en analyse - Ik begon dit leven omdat ik artikelen schreef over de mogelijkheden van databases op het DEC VAX-platform. En om die reden gebruikten database-uitgevers mij vroeger. En het enige dat mij opvalt is dat, waarom zou je een database hebben? Ik bedoel, in die dagen maakten heel veel mensen bestanden met sleutelwaarden en gebruikten ze om een soort index sequentiële denkfout te maken zoals we ze noemen, maar om een soort database-capaciteit te creëren, en weet je, waarom zou je hebben nog iets anders?

En het antwoord daarop, ik denk dat Michael Stonebraker daar het beste antwoord op gaf, en hij zei: "Een database kan meer weten over waar de gegevens zijn en hoe snel ze kunnen worden verkregen dan welk programma ooit kan weten." En ik vind dat interessant; het is de aard van het spel. Maar in de 19 - nou ja, rond 1989 dat ik begon in technologie-analyse en weet je, op dat moment waren databases heel eenvoudig en relationele databases waren super eenvoudig. Ze hadden zo weinig mogelijkheden, ik bedoel, ze konden natuurlijk gegevens opslaan, en je kon een back-up maken en ze hadden, ze waren ACID-compatibel, maar ze hadden echt heel zwakke optimizers. Het zou zelfs moeilijk zijn om te beweren dat ze überhaupt over de optimalisatiecapaciteit beschikten.

En later werden ze alleen maar beter en beter, maar weet je, wanneer een database niet werkt - omdat deze kangoeroes op de een of andere manier lijken te wijzen - kunnen er heel wat redenen zijn waarom het langzaam gaat. En dat brengt me op het punt: databases hebben veel functies, maar de belangrijkste is query-optimalisatie. Als ze dat niet deden, zou je ze niet gebruiken. Het gaat erom snel informatie te krijgen, het gaat om het kunnen doen wanneer er veel gelijktijdige gebruikers zijn, en dat is een moeilijk probleem. En als je kijkt naar de, laten we ze volwassen databases noemen, als je wilt - maar zeker Oracle, in iets mindere mate, Microsoft SQL Server, zeker Teradata en DB2 - de optimizers van die databases hebben decennia in de gebouw. Weet je, ze deden niet - iemand ging niet zitten - zes jongens op een twee-man, jaar, project en klopten er gewoon één samen. Zo werkt het niet. De optimalisatiemogelijkheden zijn geleidelijk gegroeid en er is veel groei nodig. Hoe dan ook, laten we het hebben over de achtergrond van de database. Nou, er is heel veel gezegd over de NoSQL-database nu, en er is zelfs veel enthousiasme voor de grafische database. En het gebruik van SQL boven Hadoop en dat soort dingen. Maar de waarheid is dat als u nu een database wilt, als u een volledig functioneel, geschikt voor OLTP en groot queryverkeer wilt, het een relationele database is, of niets.

Onder relationele databases is Oracle dominant in populariteit. Microsoft SQL Server is denk ik tweede. Ze kunnen allebei worden gebruikt voor OLTP en querywerkbelasting, maar eigenlijk kun je echt niet wegkomen met het mixen van die werkbelastingen. U hebt verschillende incidenten nodig voor OLTP-workloads en queryworkloads. Er zijn alternatieven voor SQL en grafiek. De meeste bedrijven standaardiseren op één specifieke database, en dat is de reden - ik bedoel dat na tientallen jaren vechten met alle andere spelers, Oracle de meest dominante werd. Simpelweg omdat ze uiteindelijk bedrijfslicenties konden verkopen, en dus bedrijven alleen alternatieve producten in uitzonderlijke producten zouden gebruiken, zou Oracle ze gewoon niet doen. En databases zijn strategisch omdat ze ook evolueren. En weet je, ik heb een klein beetje onderzoek gedaan voor deze presentatie, en het is een beetje - ik kom er een tijdje op terug, maar het is best interessant hoe ze evolueren, in termen van ernaar te kijken vanuit de positie van een DBA. Dit noem ik de onzichtbare trend. Het is de wet van Moore. Het is ongeveer zo: de grootste database is, en nieuwe databases, er is geen oude database die veel meer gegevens heeft om in te nemen. Het is normaal een database die wordt toegepast op een nieuw probleem. En ze groeien eigenlijk in termen van datavolumes. Ongeveer bij de kubus van Moore wet. De wet van Moore is dus een factor tien keer om de zes jaar. VLDB's hebben de neiging om elke zes jaar een factor duizend te groeien. In 1991, 1992 worden de grote databases gemeten in megabytes. In '97 en '98, gigabytes. 2003, '4, terabytes. 2009, '10, begon je petabyte-databases te zien. Ik denk dat er op dit moment mogelijk een of twee exabyte-databases zijn, maar de grootste die ik heb gehoord is de 200 petabytes op tijd, en weet je, geen gegevens naar een petabyte-database krijgen. Maar het zijn vooral de nieuwe grote web 2.0-bedrijven, misschien heb je Facebook die kant op.

Maar goed, als je daar echt naar kijkt en verwacht dat een database dat soort escalatie in volume doorloopt, vraagt het veel. En opmerkelijk genoeg, zeker tot op het niveau van de petabyte, lijken ze het redelijk goed te hebben gedaan. Ik bedoel, ik heb het over de oudere producten in plaats van iets nieuws. Ze lijken het buitengewoon goed te hebben gedaan. Als we kijken naar databaseprestaties, knelpunten, brengt dit me terug naar de tijd dat ik er vroeger echt om gaf en me er zorgen over moest maken. Je weet dat dit fundamenteel het uitvallen van de hardware is. Er zijn CPU-knelpunten, mogelijk zijn er geheugenknelpunten, mogelijk zijn er schijfknelpunten, mogelijk. Het kan het netwerk zijn dat je verdriet bezorgt, en je kunt ook problemen krijgen met vergrendelen, afhankelijk van wat je doet, maar normaal gesproken is dat omdat het programma niet weet wie vergrendeling moet bellen. Dus als u een database gaat afstemmen, probeert u deze in feite zo af te stemmen dat deze tussen deze vijf mogelijke knelpunten danst. En dat is niet eenvoudig, want de hoeveelheid geheugen die u op elke server kunt configureren, is aanzienlijk toegenomen. Dan zijn CPU's multicore geworden, schijf, nou we kunnen het nu doen, denk ik, zelfs op commodity-servers, ik denk dat je honderden en honderden terabytes, een kwart petabyte kunt doen, misschien zelfs op een commodity-server. Dus met al deze dingen waar je mee kunt spelen, kan het netwerk natuurlijk op verschillende snelheden gaan, maar meestal als je met databases te maken hebt, wil je echt glasvezelkabels tussen de servers hebben en niets anders dat daarop draait, in het bijzonder op die manier.

Databaseprestatiefactoren. Ik bedoel, ik ga weg waar dit allemaal over gaat, omdat ik weet dat Dez erover gaat praten, maar slecht databaseontwerp betekent een slecht presterende database. Slecht programmeerontwerp kan mogelijk betekenen dat je hele domme SQL naar een database gooit, wat gewoon veel langer zal duren. Gelijktijdigheid en werklastmenging, te veel gelijktijdigheid zal knelpunten veroorzaken. De werklastmenging, wanneer u grote vragen hebt met zeer kleine, korte, scherpe vragen, die problemen veroorzaken. Er is een probleem met taakverdeling. De meeste databases zorgen daarvoor, maar als u geen geavanceerd product hebt, weet u, met slechts enkele servers toevoegen, is dit niet alles wat u doet als u de omvang van een cluster wilt vergroten. U moet de belasting in evenwicht houden voordat u optimale prestaties krijgt. U moet capaciteitsplanning doen. Absoluut. Zeker nu in deze dagen, wanneer datavolumes dramatisch toenemen dan voorheen voor databases. En er zijn hele problemen met de gegevenslaag hoe u de gegevens opneemt, hoe u gegevens verplaatst. Het niet op tijd krijgen van gegevens in een database kan later een prestatieprobleem zijn, omdat we zijn overgegaan van databases die in Windows werken naar vierentwintig bij zeven bij driehonderdvijfenzeventig en er zijn geen vensters waar u de database niet beschikbaar of het is onwaarschijnlijk dat deze er tegenwoordig zullen zijn.

Het Oracle DBA-probleem. Dit was waar ik aan dacht. Ik ben in Oracle's DBA geweest met Oracle 7 en ik weet nog hoe ik dat moest afstemmen. En als je nu echt naar Oracle kijkt, is het manier, manier - het heeft manier, veel meer mogelijkheden. Het heeft bitmapindexering en dat soort dingen, maar ik heb eigenlijk de tijd genomen om te kijken hoeveel afstemmingsparameters er momenteel op dit moment in een Oracle-database zijn. En er zijn meer dan driehonderdvijftig afstemmingsparameters en er zijn nog eens honderd verborgen parameters, die gespecialiseerde DBA's misschien kennen, maar normale Oracle DBA's niet weten. En dat betekent dat het afstemmen van dit soort databases een lastige zaak is. Het is helemaal niet eenvoudig. Je moet er gevoel voor hebben, je moet het al heel lang doen, en je moet precies weten wat het probleem is dat je denkt op te lossen, omdat de afstemming begint wanneer de de prestaties worden slecht, maar het is misschien niet de prestatie van alles. Het kan de prestatie van specifieke query's zijn die ertoe doen, en u kunt dit mogelijk oplossen door bepaalde gegevens en geheugen vast te zetten, of u moet dit mogelijk oplossen door te indexeren, of u moet mogelijk beginnen met partitioneren op een andere manier. Er zijn veel dingen die je kunt doen, dat is het punt. Daarom gaan ze het niet in hun hoofd doen - DBA's hebben hulpmiddelen nodig. Ik zal het nu doorgeven aan Dez die je gaat vertellen over indexeren, denk ik.

Eric Kavanagh: Oke Dez, haal het weg.

Dez Blanchfield: Bedankt Robin en ik ben dol op het voorblad. Ik denk dat je de handschoen naar beneden hebt gegooid om zelfs op afstand in de buurt te komen van iets spannends. Maar ik heb een afbeelding van onze kleine melkweg gebruikt, als mijn visie op wat de uitdaging van vandaag voor databasebeheerders is geworden, omdat dit het mentale beeld is dat ik vaak oproep wanneer ik in een omgeving kom en ik niet langer ben in de wereld van het beheren van databases of het ontwerpen van databases op dat niveau. Maar net als jij zijn Robin en ik vele jaren betrokken geweest bij de wereld van databases, hetzij als beheerder of ontwikkelaar, of uiteindelijk architect, en beseften toen dat ik betere dingen kon doen om een korst te verdienen. Maar het heeft de neiging te voelen alsof je naar deze melkweg van gegevens staart, en meer nog, wanneer we, zoals je hebt aangegeven, in een zeer korte periode van megabytes naar petabytes en exo-schaal zijn gegaan, in het grote geheel der dingen. Maar de zin die ik in gedachten heb, is dat database-indexen nu een zwarte kunst zijn en dat ze niet echt het soort dingen zijn waar gewone stervelingen zich in zouden moeten verdiepen, voor zakelijke bedrijfstoepassingen en het type dat u formuleert hadden het er net over. Maar ik wilde een kort overzicht van het soort geschiedenis dat ik heb gehad met database-werelden doornemen en in context brengen waar we een conclusie gaan trekken, en dan vandaag wat materiaal doornemen met onze vrienden bij IDERA, omdat ik denk dat er heel wat anders wordt nagedacht over hoe je de prestaties van de database kunt afstemmen en een van hen gooit er wat naar. Voor veel winkels die ik tegenkom, komen ze steevast niet op het punt om het afstemmen van de prestaties op de database-laag en met name de index-laag uit te voeren totdat ze de moeilijke weg hebben door te denken dat ze er een tuner op kunnen gooien .

Veel mensen kiezen er gewoon voor, denk ik, en ik heb hier een foto van The Flash, want als je ooit naar oude films hebt gekeken of zeker de nieuwste tv-show met The Flash, zoals in Flash Gordon het oude personage, en nu hij 'The Flash' wordt genoemd, heeft hij de neiging heel, heel snel te gaan en steevast raakt zijn energie op. En dit is wat er gebeurt wanneer u groot ijzer gooit naar databaseprestaties. Volgens mijn ervaring kunt u steevast hoge prestaties en hard werken in de game zetten, uw besturingssystemen optimaliseren en op een bepaald punt afstemmen. Je kunt ervoor zorgen dat je snelle multicore, multithreading CPU's hebt om de applicatie sneller te laten werken, je kunt er veel RAM naar gooien, je kunt backplanes met hoge doorvoer hebben, je kunt van harde schijven naar caching van harde schijven gaan naar solid state en krachtige opslagarray. En zelfs nu gooien mensen dingen als flash en NVMe naar hun database-engine, denkend dat ze deze inlogtijden twee keer een prestatieverbetering zullen krijgen. En altijd krijgen ze wat winst. Maar het komt allemaal terug op dezelfde basisafstemmingsproblemen. Veel netwerkverbindingen met lage latentie, zodat de clusters snel werken. En van het clusteren van database-infrastructuur, dus u hebt meer dan één machine die al het werk doet. Maar je hebt de neiging om terug te keren naar hetzelfde basisprestatieprobleem, en dat is het lezen van gegevens. Het schrijven van gegevens is voor het grootste deel een vrij lineaire uitdaging en tenzij het goed wordt gedaan.

En dan hebben we de uitdaging in de wereld van vandaag: niet alle databases zijn hetzelfde. Er zijn databases en quote-on-quote "database". En als we aan database-engines denken, denken mensen vaak aan de traditionele, gebruikelijke verdachten zoals in de SQL-wereld. Weet je, we hebben Oracle en Microsoft SQL Server, en er zijn er een paar in de open source wereld met MySQL, nu eigendom van Oracle, maar het is nog steeds open source. En dan hebben we de niet-zo-gebruikelijke verdachten, de NoSQL-engines, die nog steeds een probleem hebben met indexering en prestatiebeheer, en ik zal er niet in detail op ingaan, maar er zijn steeds meer van deze dingen duiken elke dag op en ze zien eruit en voelen aan als database-engines vanuit het oogpunt van de ontwikkelaars en vanuit het oogpunt van prestaties, maar ze zijn heel, heel verschillende beesten en ze hebben hun eigen kleine niche in de wereld om te carven prestaties in geheugen of lineaire schaal op schijf. Maar zo ziet de wereld er in de databasewereld uit. Dit is de 2016, dit is de versie drie van de kaart van, door een reeks mensen die deze doorlopende landschapskaart produceren van hoe databases eruit zien, en dit is waar het - zelfs een bovenmenselijke database-architect of databasebeheerder zou zinvol kunnen zijn ervan. Letterlijk honderden en honderden en honderden verschillende merken, modellen, fabrikanten van databases, steevast SQL-compatibel. En het interessante is dat ze allemaal dezelfde uitdaging aangaan. Prestaties en afstemming van prestaties rond de database-engine, en met name door de manier waarop gegevens worden geïndexeerd.

Dus laten we het snel hebben over database-indexering, omdat het een interessant onderwerp is en je moet er meer in detail op ingaan met de demo, geloof ik. Maar ik denk dat het redelijk goed geaccepteerd en standaard in de branche gebruikelijk is dat het afstemmen van de prestaties van database-indexen is waar de wereld begint en eindigt in zoverre dat uw gegevens toegankelijk zijn in een snel en snel formaat. Maar wat is database-indexering? Als we denken aan indexeren in de vorm die we als gewone mensen gewend zijn, denk dan aan een indexpagina in een boek. Als je iets in een boek wilt vinden - met name het soort van een encyclopedie, of iets als een referentiemateriaal van een of andere vorm - als je op zoek bent naar iets als deze pagina, waar ik dingen zoek zoals het onderwerp dammen in een encyclopedie. Ik wil elke verwijzing vinden naar dammen, de stroom van water en een groot bebouwd gebied, in het algemeen door de mens gemaakt. Ik ga naar achteren, ik vind het in een alfabetische, gesorteerde lijst, A tot Z, van links naar rechts, en ik vind D. Ik zal het woord "dammen" vinden en ik kan dat zien op pagina's 16, 38, 41 er is een verwijzing naar, en dan kan ik naar die pagina's gaan, ik kan mijn ogen naar beneden scannen en ik zal de verwijzing naar het woord "dam" vinden. Het is in wezen hetzelfde concept in een database, maar het is nu in veel opzichten een raketwetenschap. Zozeer zelfs, dat effectief elke databasebeheerder die ik ooit goed heb leren kennen, indexen beschouwt als het meest cruciale hulpmiddel voor het afstemmen van prestaties in elke databasewereld, ongeacht wat hun ervaring kan zijn om er naar te gooien, of wat het geval ook is.

Over het algemeen zijn er een aantal gemeenschappelijke benaderingen als we het hebben over database-indexering. En hoe complexer de database-indexen worden, hoe complexer de benadering van het indexeren van gegevens. Maar als u denkt aan het indexeren van gegevens, stel u dan voor dat we een bestand hebben met een lijst met namen; ze kunnen niet in alfabetische volgorde worden gesorteerd. Laten we ons voorstellen dat het er twintig zijn. Als we gaan sorteren - als we naar gegevens in die lijst gaan zoeken, van boven naar beneden, en laten we zeggen dat het een lijst met namen is. Als ik een willekeurige naam kies en ik begin die lijst van boven naar beneden in een lineair formaat te scrollen en het is een ongeordende lijst, zijn er twee criteria die ik beschouw als mijn gemiddelde zoektijd en mijn maximale zoektijd - en Ik heb een typefout op de tweede regel, zou 'maximale zoektijd' moeten zijn, sorry - maar mijn gemiddelde zoektijd is in wezen N plus één, gedeeld door twee, en dat is gemiddeld vijftig procent van de tijd om van de bovenkant van de lijst naar de onderkant van de lijst te scannen om willekeurig iets in die lijst te vinden. En de tweede regel daar, onder lineair, zou "maximale zoektijd" moeten zijn. Maar de maximale zoektijd is in wezen het aantal items, en dat is dat als ik een lijst van twintig dingen heb, dit me de meeste tijd kan kosten zoeken naar iets in die database is van boven naar beneden gaan, dat wil zeggen 20 items in dit vereenvoudigde voorbeeld. En het is een zeer langzaam proces en er is echt geen manier om dat af te stemmen. En dan zijn er andere soorten manieren om die gegevens te nemen en een index te maken, wat in feite een korte lijst is met verwijzingen naar waar de feitelijke gegevens zich bevinden, zoals binair, B-structuur, bitmap, hashing, geclusterd en niet-geclusterd, en dan zijn er verschillende soorten gegevens, zoals ruimtelijke, gefilterde, XML en volledige tekst.

Binair is een veelgebruikt gegeven voor dingen waar de gegevens zich daarvoor lenen. B-tree is historisch gezien waarschijnlijk de meest voorkomende in algemene zin, omdat het een veel voorkomende manier is om een index voor elke vorm van gegevens te structureren en loggers, selecties en invoegingen en verwijderingen relatief eenvoudig te maken terwijl u wijzers over de verwijzing naar de wijzers, de punten. Er zijn andere typen, zoals bitmap, waarbij gegevenstypen bezorgd zijn, bijvoorbeeld als we een bijbehorend bereik van een bepaalde vorm hebben. Hashing werkt heel goed voor grote objecten, met name blogs en afbeeldingen. En u kunt zien dat er een aantal verschillende soorten wetenschappelijke benaderingen, wiskundige benaderingen, zijn voor het indexeren van gegevens. Alleen al voor stervelingen zijn ze een interessante uitdaging om op dit niveau over te praten. Als je er op prestatieniveau over praat voor een databasebeheerder, worden ze echt een raketwetenschapper en doen mensen graden in hen, en ik weet dat dokter Robin Bloor dat zeker heeft gedaan, en boeken erover geschreven voor IBM en andere grote merken in de afgelopen decennia. En dus is het - mijn mening, dat we eigenlijk een tijd zijn verstreken waarin, weet je, ooit eens persoonlijk voor een systeem zou kunnen zitten en ik het uit elkaar zou kunnen trekken en je kan laten zien precies waar de prestatieproblemen zich bevonden op een opdrachtregel of bij een grafisch startprogramma voor de gebruikersinterface, en begin je in de gegevens te verdiepen en je te vertellen waar de problemen waren, en indexen of subindexen of primaire en secundaire indexen daarin te bouwen gegevens en begin deze te gebruiken om dingen te vinden. Maar als je denkt aan dat landschap dat ik je heb laten zien, waar we honderden en honderden merken, merken en modellen, en fabrikanten en soorten databases hebben, zijn we die tijd nu echt voorbij, waar een mens kan maken gevoel voor de soorten database-engines die we hebben. Vooral als we tegenwoordig maar terugkomen op Oracle, overheersende merken in relationele databaseplatforms.

Het aantal databases waarmee ze te maken hebben, hetzij van een eigen platform, zoals een ERP- of HR-systeem of een financieel systeem, of het om verschillende redenen een zelfgebouwd platform is, het aantal databases en databasetabellen en -records dat we eindigen omgaan met zijn gewoon astronomisch en je kunt het fysiek niet met de hand doen. En we hebben nu een extra complicatie, waar eens een databaseserver misschien gewoon onder uw bureau zat. Weet je, als een jong kind na school ging ik vroeger werken met databasesoftware op de, oorspronkelijk, Apple IIes en daarna op DOS PC-gebaseerde systemen, zoals dBase II, dBase III, ging een tijdperk door met mainframes en mid- bereik en zelfs VAX's en PDP's en logbestanden daarop. En zoiets als Sabre, en uiteindelijk toen er enkele SQL-databases kwamen. Maar tegenwoordig, wanneer we aan database-engines denken, zien ze eruit als de linkerbenedenhoek. Een databaseserver is niet meer slechts één machine die op de vloer onder een bureau staat; het zijn honderden machines waarop kopieën van database-engines en clusters worden uitgevoerd, en ze schalen tot honderden en honderden terabytes aan gegevens, zo niet petabytes aan gegevens, wat duizenden terabytes is. En zelfs tot het uiterste, zoals Doctor Robin Bloor al zei, kunnen sommige specifieke gebruiksscenario's - met name luchtvaartmaatschappijen, overheidsinstellingen - exabytes bereiken. Ze zijn nog steeds redelijk niche-y, maar honderden terabytes en zelfs tientallen petabytes is niet meer ongewoon, vooral vanaf de dotcom-boom tot nu toe, een soort van wat we web 2.0-bedrijven noemen, zoals Facebook, Google, Yahoo enzovoorts.

We hebben ook de complicatie nu dingen naar externe service gaan. We hebben infrastructuurplatform en software als een serviceaanpak die infrastructuur biedt. En met name platformservice waarbij we niet alleen kunnen kopen voor Oracle en hun cloudplatform, databases en servers. En dit stelt ons in staat om een zeer snelle ontwikkeling van de applicatie te doen en gewoon een database weer in de servers te steken. We hoeven niet na te denken over wat er onder de motorkap ligt. Het nadeel is dat we vaak niet nadenken over hoe we de database opnieuw ontwerpen en implementeren totdat deze pijn gaat doen en de prestaties een probleem worden. Uiteindelijk moeten we zoeken naar de juiste tool om te diagnosticeren waarom onze database pijn doet en waar de prestatieproblemen zijn. En steevast brengt het het terug naar dat veel voorkomende probleem van hoe we die gegevens hebben geïndexeerd en de soorten indexen die we voor die gegevens hebben gebruikt en dat brengt ons vervolgens terug naar bovenmenselijke prestatie-eisen. En iemand die toegang heeft tot de juiste systemen en de juiste tools om die motoren af te stemmen, en een hotspot begint te zoeken en te kijken naar waar de vragen zijn, waar de gegevens naartoe gaan, de soorten vragen, hoe de vragen zijn gestructureerd, wie de vragen doet, en of de vragen in de wachtrij staan en in de cache moeten worden geplaatst. Welke replicatie zoekt u?

En dus zijn we naar mijn mening goed en waar nu zelfs 's werelds beste database-goeroes, in wezen onze database-architecten en onze database-beheerder en performance bases, naar mijn mening heel hard moeten beginnen met het gebruik van de juiste tools om optimale prestatie-indexafstemming te leveren voor elke database-engine. Omdat de schaal waarmee we te maken hebben en de snelheid waarmee dingen bewegen, we het gewoon niet met de hand kunnen doen, en proberen dat te doen steevast kan andere prestatieproblemen veroorzaken, omdat we misschien geen ervaring hebben in die ruimte die we proberen een probleem op te lossen. En ik geloof dat we dat op het punt staan aan Bert te overhandigen, en we staan op het punt te praten over hoe ze dit gevarieerde probleem hebben opgelost en het soort dingen dat hun tool kan doen, met name voor de Oracle-wereld. En daarmee, Bert, ga ik je overgeven.

Bert Scalzo: Bedankt. Welkom iedereen, mijn naam is Bert Scalzo, ik werk voor IDERA. Ik ben de senior productmanager voor sommige van onze databaseproducten. Ik zal vandaag enkele daarvan demonstreren. Maar ik wil het hebben over indexen, omdat ik het eens ben met alles wat iedereen hier heeft gezegd, vooral de laatste dia, dat indexen zo complex zijn dat je een hulpmiddel nodig hebt en ik hoop je te overtuigen. Dus het ontwerp van de Oracle-index, het is niet zo eenvoudig als vroeger. Veel mensen zullen niet zeker van zichzelf zijn als ze naar de opties kijken, en ik vind het leuk om te zeggen dat ik me uit de geschiedenis terugtrok, "in deze zaken is de enige zekerheid dat niets zeker is." En dat is hoe ik voel tegenwoordig aan indexen, want zelfs als u denkt dat u het antwoord moet weten, moet u X, Y of Z indexeren, u weet het pas zeker als u het probeert, omdat die optimizers zich soms anders gedragen dan u verwacht. En dus is er veel vallen en opstaan met indexontwerp. Als je vroeger een index nodig had, waren er over het algemeen slechts twee vragen, of één vraag. Was het uniek of was het niet uniek? En je hebt misschien gedacht aan andere dingen zoals: "Hoeveel indexen kan ik maximaal hebben op een enkele tabel?" Omdat te veel indexen je invoegingen, updates en verwijderingen vertragen. Je was misschien ook in je database-systeem, had beperkingen voor het aantal kolommen in een index met meerdere kolommen, omdat er soms limieten waren op basis van de pagina- of blokgrootte van je database-engine, maar in werkelijkheid was het vrij eenvoudig terug in de goede oude tijd. Je hebt het geïndexeerd of niet. En echt, alles was in een B-boom. We konden de duplicaten toestaan of niet, en dat was het dan ook. Het leven was goed, het leven was eenvoudig.

Nou vandaag is het leven niet zo goed of zo simpel. Ik heb het rode Ghostbuster-teken gebruikt zoals we dat vroeger deden, omdat we nu een B-tree versus bitmap hebben, versus bitmap join. En ik ga uitleggen wat sommige hiervan in een moment zijn. Geclusterd en niet-geclusterd, uniek of duplicaten, voorwaartse of omgekeerde volgorde, op functies gebaseerd, gepartitioneerd of niet gepartitioneerd. Als er sprake is van partitionering, is dit dan globale of lokale partitionering? Dat zal ik ook uitleggen. En dan is er ook iets dat een geïndexeerde georganiseerde tabel wordt genoemd. En er zijn eigenlijk een half dozijn anderen die ik hier heb achtergelaten, omdat ik denk dat ik hier nu genoeg heb die je moeten overtuigen dat indexen veel moeilijker zijn dan je misschien dacht. In deze specifieke dia ga ik linksboven in het diagram beginnen en ik heb een tabel. En het eerste wat ik moet beslissen is, afhankelijk van uw databaseversie en uw databaseleverancier, staan ze objecttabellen toe of zijn ze alleen relationeel? Ik ga naar rechts en zeggen dat we een relationele tafel bouwen. Nu, de volgende vraag die ik mezelf moet stellen, is die in een cluster? En velen van jullie die al enige tijd Oracle hebben gedaan, zullen onthouden dat clusters terug waren voor de Oracle 6 dagen. Ze worden vandaag waarschijnlijk niet erg veel meer gebruikt, maar laat me eerst die tak afdalen.

Als ik mijn tabel in een cluster zou plaatsen, zou ik een geclusterde index op die tafel moeten hebben. Nu, in Oracle, toen u een tabel clusterde, waren de rijen in feite opgeslagen of lagen de rijen dicht bij elkaar waar de waarden vergelijkbaar waren. En dus moet u een geclusterde index hebben en die geclusterde index kan niet-gepartitioneerd zijn. Met andere woorden, er waren niet echt partitioneringsmethoden voor hoe je een geclusterde tabel zou doen. Het was strikt niet-gepartitioneerd. En omdat het niet gepartitioneerd was, was het wereldwijd. Ik zal zo meteen uitleggen wat globaal is. En het was altijd B-boom. Met andere woorden, toen ik langs die tak ging, was het vrij eenvoudig, ik had niet veel keuzes. Nu, als ik een niet-geclusterde index op een geclusterde tabel deed, wat in sommige versies was toegestaan, was het opnieuw niet-gepartitioneerd; als het niet is gepartitioneerd, is uw enige keuze globaal. En dus heb je de keuze uit B-structuur of bitmap. Nogmaals, het hing af van uw versie van de database. Maar nu, laten we teruggaan naar de relationele tafel en beginnen aan de rechterkant weer naar beneden te gaan en nu hebben we gewoon een eenvoudige, oude, normale, volle tafel: relationeel. Het zal in een tafelruimte zijn. Ik ga hier eerst rechts langs. Dus het is organisatie, hoop. De volgende vraag die ik mezelf moet stellen is: "Wil ik deze tabel partitioneren of niet?" Nu, soms, zou u partitioneren omdat u dacht: "Hé, de optimizer zal slimmer zijn over hoe het query's kan optimaliseren. “Maar veel DBA's zullen je vertellen dat de reden dat je dat doet voor administratieve doeleinden is. Als u een tabel met honderd miljard rijen hebt, als u deze opsplitst in partities of emmers, wanneer u gegevens aan de laatste bucket wilt toevoegen, kunt u die enkele miljoenen rijen neerzetten en indexeren. U kunt die gegevens invoegen en vervolgens kunt u die index opnieuw opbouwen op alleen die bucket.

Hoewel het voor sommigen een goede techniek was, optimalisatietechnieken zoals het elimineren van partities, was de echte waarde ervan om kleinere taken te beheren of te beheren. Toen ik naar de organisatiehoop ging, was de eerste vraag: "Heb ik het al dan niet opgedeeld?" Laten we naar links gaan, ik ga de tafel niet opdelen. Nu kan het vreemd lijken als ik je dit vertel, maar je zou een niet-gepartitioneerde tabel kunnen hebben en dan kun je de index niet partitioneren zoals je gewend bent, of je kunt de index partitioneren. Stop en Denk. Uw tafel heeft in principe één bucket, zoals u altijd al hebt gedacht, en toch heeft uw index meerdere buckets. Wanneer dat gebeurt, waar er een verschil is tussen het aantal emmers en de tabel en het aantal emmers in de index, is dat wat wordt bedoeld met globaal. En dus, als de tabel niet is gepartitioneerd, en als de index is gepartitioneerd, wordt deze als globaal beschouwd, omdat er een mismatch is. Laat me nu teruggaan naar de hoop van mijn organisatie en in plaats daarvan naar beneden gaan aan de kant van de partitie. Als ik nu een partitietabel heb, en laten we zeggen dat de tafel vier emmers, vier partities heeft, kan mijn index vier emmers bevatten zodat mijn index overeenkomt met mijn tafelontwerp. En dat is nu voorbij, aan de rechterkant. Dat zou als lokaal worden beschouwd. Een lokale index betekent in feite dat het partitioneren van de tabel en de index op dezelfde manier gebeurt en hetzelfde aantal emmers heeft. En als ik eenmaal de lokale index heb, kan het een B-boom of een bitmap zijn, en die groene pijl die omhoog gaat, laat je zien dat zelfs als het een B-boom is, er nog steeds keuzes kunnen worden gemaakt. Het kan functie-gebaseerd zijn. En als het een bitmap is, zijn er verschillende soorten bitmaps. Er is iets dat een bitmap join-index wordt genoemd. Als u data warehousing doet, is dat een zeer populair soort index voor star schema of ontwerp. Wat er gebeurt, is dat de index de rij-ID's heeft waarnaar wordt verwezen in de tabel, maar het zal ook rij-ID's hebben voor de bovenliggende tabellen zodat wanneer je - je schemaontwerp moet star en je kijkt bij een feitentabel verwijst die index op de feitentabel naar de gegevens waarin u bent geïnteresseerd en verwijst u naar elke rij in uw dimensies, zodat u slechts één index hoeft te hebben.

En eigenlijk is dit ontstaan door Red Brick, dat vele jaren geleden een database was - veel mensen herinneren zich dat misschien. En dus, als je naar deze foto kijkt - en bedenk dat ik niet alles in deze foto heb gezet omdat de foto een stuk groter zou zijn - zijn er nog steeds extra problemen, die ik hier in de tekst heb in het gedeelte rechtsboven . Is het een omgekeerde volgorde index? En je zou kunnen zeggen: "Waarom zou ik een index in omgekeerde volgorde willen? Dat slaat helemaal nergens op. ”Welnu, als u zich in een clusteromgeving in Oracle bevindt, als u echte applicatieclusters doet, als u uw indexen op orde houdt, dus niet omgekeerd, als u veel bewerkingen heeft die dezelfde waarden of dezelfde indexwaarden, wat er zou gebeuren is, u zou hete gebieden van uw B-boom hebben. Dit betekent dat je een twist hebt en mogelijk vergrendelt om toegang te krijgen tot dat soort dingen, en dat zou je doen via knooppunten in een netwerk. Als u een index in omgekeerde volgorde invoert, kunt u dat nu ongedaan maken. Je kunt zeggen: "Wel, de vergelijkbare waarden zijn in verschillende delen van de bomen, dus ik heb geen afzonderlijke knooppunten die strijden om hete gebieden in de boom." En merk vervolgens op dat uniek niet werkt met sommige van de opties . Als je kijkt, heb ik drie, vijf, acht en elf genummerd, dus er zijn enkele gevallen waarin ik geen unieke index kan hebben. Evenzo zijn er enkele gevallen waarin ik geen omgekeerde index kan hebben, en dan zijn er extra problemen, zoals loggen of geen loggen, en parallel en niet-parallel. Ik kan dingen toewijzen aan een specifiek geheugengebied.

En dit laat nog steeds behoorlijk wat functies in Oracle achter. Ik zou zeggen dat als je naar Oracle 12 kijkt, er waarschijnlijk weer ongeveer een half dozijn dingen zijn die ik aan deze foto zou kunnen toevoegen. Indexeren is erg complex en ik ben het echt eens met de vorige spreker, om hier doorheen te navigeren en een goede keuze te maken, heb je een tool nodig. Je hebt misschien een soort van deze foto nodig, en een soort methode om dingen te kiezen en hopelijk helpt de tool je daar te komen. En dan wordt het vallen en opstaan. Ik vertel mensen bij het indexeren altijd: "kijk voordat je springt." En dan zie je het kleine hondje hier, hij springt zonder te kijken, hij komt in het water met de haai, of de man maakt zich klaar om in het water te springen, en hij gaat zichzelf spuwen. U moet nadenken over uw indexering, omdat het maken van een index niet altijd betekent dat dingen beter worden. Het maken van een index kan de zaken zelfs vertragen. En zoekopdrachtprestaties kunnen een orde van grootte beter zijn met de ene keuze boven de andere. En ik zal je een goed voorbeeld geven. Als je een ontwerpschema met sterren gebruikt, en in je dimensietabellen gebruik je in één geval bitmapindexen, en in een ander geval zeg je: "Ik gebruik B-boomindexen", heb je bitmap versus B- boom. Ik kan u vertellen dat de ene oplossing een orde van grootte is of mogelijk meerdere grootteorden sneller dan de andere. Maar houd in gedachten wat werkt in één omgeving, zoals in een datawarehousingomgeving, waarschijnlijk geen goede keuze is in een OLTP-omgeving.

Als u bijvoorbeeld een transactietabel neemt en bitmapindexen op een transactietabel plaatst, is het duur om bitmaps, deze lange tekenreeksen te berekenen en opnieuw in te stellen, en dus in een OLTP-tabel kunt u de tafel zo zwaar raken dat de bitmap index kan corrupt worden en uw systeem vertragen omdat ze alleen niet bedoeld zijn voor updates. Ze zijn geweldig voor snelle toegang, maar zijn niet goed voor updates. Ik denk dat index met vallen en opstaan werkt. Er is echt geen gouden regel meer - er zijn teveel verschillende variabelen in deze vergelijking om te weten - en uiteindelijk zul je de uitvoering moeten bekijken of plannen in je database moeten uitleggen om te zien of je goede selecties maakt of niet. En soms kan de plananalyse bijna een wetenschap op zichzelf zijn. Ik ga dat vandaag niet behandelen - dat is een ander onderwerp - maar neem indexontwerp niet als vanzelfsprekend aan. Er zijn legitieme redenen waarom er al die gekke indextypen zijn die ik je in het vorige plaatje heb laten zien en waar de vorige spreker over sprak. Deze zijn niet alleen gemaakt omdat het een handige functie was om ergens op een checklist te zetten voor een databaseverkoper; er zijn use cases of scenario's waarin deze indexen belangrijk zijn en een aanzienlijk verschil zullen maken. Daarmee ga ik u enkele voorbeelden van verschillende soorten indexen laten zien in een van onze tools. Laat me mijn scherm omhoog halen zodat je het kunt zien. Oké, hier zit ik dan - laat me deze applicatie minimaliseren. Ik zit in de VMware en gebruik een Windows Server 2012 VM.

En je kunt zien, ik heb zowat elk gereedschap dat de mens kent. Als productmanager moet ik me bewust blijven van mijn concurrentie, dus het is niet alleen welke tools ik heb, maar wat doen mijn concurrenten? En we hebben deze tool hier genaamd DBArtisan, die ik al heb uitgevoerd, maar ik ga - dus ik zal het gewoon ter sprake brengen. En wat je kunt zien, is dat dit een erg leuke tool is, want in plaats van te hoeven gebruiken, zeg maar een enterprise manager voor Oracle en een SQL Management Studio voor SQL Server, en de MySQL Workbench voor MySQL en twaalf andere databases die we ondersteunen, nou, ik heb al mijn databases ingebouwd in deze ene tool. Er is DB2, er is MySQL, Oracle, Postgres, SQL Server en Sybase, en dat is - ik heb slechts zes databases in dit specifieke ding omdat ik dat niet kan - de tool ondersteunt twaalf databases, maar mijn arme VM, die zes databases tegelijkertijd uitvoert en probeert om een demo te doen, is ongeveer net zoveel als mijn hardware zal vergemakkelijken. Dus laat me nu teruggaan naar Oracle, en als je opmerkt, zijn al deze dingen hetzelfde. Als ik mijn prestaties in DB2 wil meten, zijn het dezelfde keuzes die ik in Oracle zou hebben. Nu doen we onder de covers veel verschillende dingen, zodat je niet hoeft te weten wat er aan de hand is, maar we geven je een consistente interface zodat je een expert kunt zijn met meerdere databaseplatforms. En dat zou het werken met indexen inhouden, het onderwerp van deze discussie.

Laat me hier binnenkomen en laat me eerst beginnen met het bekijken van enkele tabellen, en ik heb een filmdatabase met slechts een paar tabellen. En als ik naar een bepaalde tafel kijk, zoals de klantentabel, zie ik hier mijn tafelontwerp, hier zijn mijn kolommen in mijn tabel en hier is informatie over elke kolom. Ik heb eigenschappen voor de tabel, maar houd er rekening mee dat ik hier een tabblad heb voor indexen en ik zie hier de indexen op de tafel. Merk op dat een van deze indexen mijn PK-index is, mijn primaire sleutel. Deze andere lijken slechts indexen te zijn om de toegang tot zoekopdrachten te verbeteren, misschien zoeken we op voornaam of achternaam, of kijken we naar telefoons en postcodes. En als ik een bepaalde index kies, zoals deze postcode hier, en ik dubbelklik erop, nu kan ik zien dat het een niet-unieke index is en hier zijn enkele van de andere typen, bitmap, niet-unieke, uniek, of het nu wel of niet is gesorteerd, of dat loggen al dan niet is, of het in omgekeerde volgorde is, of het een functiebasis is. Oh, hier is een leuke die ik niet heb behandeld. U kunt zelfs onzichtbare indexen hebben. En u zou zeggen: "Wel, waarom zou ik in godsnaam een onzichtbare index willen maken?" Wel, ik zal u een goed voorbeeld geven. Je zit in je productiesysteem en je hebt een prestatieprobleem en je weet niet zeker of het maken van de index het probleem zal oplossen, dus je wilt geen index maken en de productie vertragen, maar op de een of andere manier in staat zijn om het te testen. U kunt de index in productie als onzichtbaar maken, wat betekent dat niet veel toepassingscode, die de optimizer aanroept, die index zal gebruiken. Het is gemaakt, het is geldig, maar het zal niet worden gebruikt. Vervolgens kunt u een vraag nemen waarvan u denkt dat deze index zou helpen, of een reeks vragen, en u kunt een hint erin stoppen en zeggen: "Hé, optimizer, er is een onzichtbare index die ik wil gebruiken en laat ik weet of ik dingen beter heb gemaakt. ”En nu heb ik iets in productie getest, maar ik heb de applicaties in de productie die actief waren niet gebroken. Dat is het gebruik voor een onzichtbare index. Het klinkt dom als je er voor het eerst over hoort, maar het heeft zin.

We kunnen ook op indexen bepalen of ze parallel zijn, en ook hoeveel instanties ze parallel zijn. Nu, in een niet-geclusterde of een niet-echte applicatieclusteromgeving, zou dus niet-rack, parallel betekenen hoeveel subprocessen mijn vraag kan opleveren om te proberen, en werkprocessen, om dingen sneller of sneller door te komen . En parallelle instanties zouden zijn, als ik in een echt applicatiecluster zit, zeg dat ik tien knooppunten heb, hoeveel van de knooppunten mag ik het werk verdelen? Misschien is het vier van de tien, en op elk van hen, vier subprocessen. Dat is een voorbeeld. En dan hebben we toetscompressie. U kunt indexen eigenlijk comprimeren? Ja of nee. En dan heb je natuurlijk je opslagparameters die je kunt opgeven in indexen. Nu heb ik deze niet behandeld omdat ze echt meer een opslagparameter zijn dan een indexprobleem. En ten slotte moeten we deze al dan niet gepartitioneerd maken. Laat me dat even hier neerzetten. Ik ga naar een ander schema. Dit is een sterschema en deze periodetabel is bijvoorbeeld een dimensietabel. Als je ooit een star-schema-ontwerp hebt gedaan, heb je meestal een tijdsdimensie. In deze database en dit star-schema is periode dus een tijdsdimensie. Nu, ik weet dat het er grappig uit zal zien, zul je zeggen: "Goh, kijk eens naar al die kolommen - heeft de man ooit gehoord van normalisatie?" Nou, als je in een datawarehouse of een star schema-ontwerp bent, moet je hebben meestal niet - u hebt tabellen waar een doorsnee persoon naar zou kijken en zegt: "Goh, deze zijn niet erg goed ontworpen." Maar dat is de manier waarop u het doet in een datawarehouse-omgeving.

Kijk nu wat er gaat gebeuren, want er zijn al deze kolommen, kijk daar eens, ik heb een index voor elke kolom. Nu zou dat in een OLTP-omgeving een nee-nee zijn. Het zou al mijn operaties vertragen. In een datawarehouse-omgeving zou ik ze laten vallen tijdens mijn batch-laadcycli. Laad zonder de overhead of de indexen, en ik zou de indexen opnieuw maken. En als ik mijn tafel in partities zou verdelen, dan zou ik in plaats van de index voor elke bucket in de tabel te laten vallen, gewoon de index op de bucket of buckets kunnen laten vallen waar gegevens naar toe zouden gaan tijdens die batch-laadcyclus. En maak vervolgens alleen het indexgedeelte voor die emmers opnieuw. En dus is het zeer beheersbaar. En als ik ernaar kijk - dus hier is een kolom met de naam "Vakantievlag" en eigenlijk is dat een ja of nee. Merk op dat dit een bitmapindex is, en voor de meesten van jullie zul je zeggen: "Wel, dat is logisch." Ja of nee, Y of N, er zijn maar twee waarden die logisch zijn. En omdat wanneer u de documentatie voor bitmapindexen leest, ze u altijd vertellen iets te kiezen met een lage cardinaliteit.

Laat me nu in een van mijn feitentafels gaan, dus hier hebben we mijn bestellingen. En dit zijn mijn bestellingen per dag. En je zult nu zien, dat ik weer een flink aantal kolommen heb, en nogmaals, ik ga meer dan een paar indexen hebben. En hier hebben we iets dat de universele prijscode wordt genoemd. Dit was voor een winkel, dus je kent die kleine streepjescodes als je iets in de winkel koopt, dit is de universele prijscode. Nu zijn er miljoenen universele prijscodes. Nu, voor dit specifieke bedrijf dat spullen verkocht, hadden ze waarschijnlijk 1, 7 tot 2 miljoen universele prijscodes, dus je gaat verwachten dat dit geen bitmapindex wordt, omdat 1, 7 miljoen verschillende waarden als hoge kardinaliteit klinken. Maar in werkelijkheid wilt u in een datawarehousing-omgeving een bitmap zijn. Laat me nu uitleggen waarom. Welnu, er kunnen 1, 7 miljoen verschillende waarden zijn voor deze universele prijscode, het aantal rijen in deze ordertabel is in de honderden miljoenen tot miljarden rijen. Mijn index is lage kardinaliteit in vergelijking met de grootte of kardinaliteit van de tabel. Dat maakt het lage kardinaliteit. Dat maakt de bitmapindex nuttig, ook al is het contra-intuïtief met 1, 7 miljoen verschillende waarden die u hier voor bitmap zou kiezen. Nu, als ik wist dat ik een bitmap join-index wilde gebruiken, ondersteunt het product dit momenteel niet, ik krijg dat toegevoegd voor de volgende release, maar dat zou een ander alternatief hier zijn. En vergeet niet dat de bitmapindex in een sterschema op de feitentabel zou staan en dat één index in de B-boom naar de rij in de feitentabel zou verwijzen en vervolgens naar elke rij die in de dimensietabel voor dat feit zichtbaar was . En dus heb je daar een andere optie. En dus, laten we eens kijken, ik wil nu uit tabellen komen en ik wil je gewoon snel laten zien dat ik dezelfde informatie heb, onder indexen, en ik ga hetzelfde doen.

Nu, de reden dat ik dit ter sprake heb gebracht is dat je misschien opmerkt, hé, hier zijn geen primaire sleutels. Primaire sleutels worden uitgevoerd met een sleutelbeperking, dus ze vallen eigenlijk onder de beperkende definities. Dit zouden indexen zijn die geen deel uitmaken van de beperking. Nu zou je kunnen zeggen: "Wacht eens even, dat lijkt misschien op een externe sleutel en een buitenlandse sleutel is een beperking, " maar buitenlandse sleutels en de meeste databases maken niet automatisch een index op de kolom met de externe sleutel, ook al is het raadzaam, en daar ga je - ik heb weer dezelfde keuzes. En als ik wil veranderen om alleen te worden gecomprimeerd, kan ik dat doen.

Nu werkt compressie alleen op een B-tree index. Wat dat toestaat, is dat wanneer je naar de verschillende knooppunten in de B-boom kijkt, het mogelijk is sommige van de waarden te comprimeren. Het is echt geen compressie zoals tabelcompressie, het is een compressie van wat is opgeslagen in de B-structuur in de niet-bladknooppunten. Het bespaart niet veel ruimte, maar het kan een verschil maken. En daarmee merkte ik dat ik behoorlijk dicht bij de tijd kom, dus wat ik wil doen is, ik wil teruggaan en stoppen met delen. En we hebben ons product beschikbaar voor een proefperiode van veertien dagen op idera.com. Het is een redelijk goed product, vooral als u met meerdere databaseplatforms werkt. Als u met twee of drie verschillende databases werkt, maakt deze tool uw leven een stuk eenvoudiger. We hebben tools om u te helpen bij het ontwerpen en selecteren van de index, we hebben een tool genaamd DB Optimizer. Ik kon dat vandaag gewoon niet dekken, dat zou teveel zijn. En als je contact met me wilt opnemen, is daar mijn e-mailadres, of je kunt me op mijn privé-e-mailadres vinden en ik heb blogs, ik heb een website en blogs en een LinkedIn-profiel daar. Dus neem gerust contact met me op, zelfs als het geen productgerelateerd is, als je alleen maar over databases wilt praten, ben ik een geek in hart en nieren en praat ik graag over techniek.

Eric Kavanagh: Oké, nou Dez, Robin, ik weet zeker dat jullie allemaal een paar vragen hebben, we hebben hier nog een paar minuten. Dez, wat denk jij ervan?

Dez Blanchfield: Ik heb een grote vraag die ik je moet stellen, die zit me in het achterhoofd. Wat is het gekste scenario dat je hebt gezien? Ik heb je blog gelezen, ik volg je op de voet, de - jij bent waarschijnlijk een van de weinige mensen die bijna onwaarschijnlijk heeft geleefd, en ik denk dat Dr. Robin Bloor de tweede is die ik heb ontmoet in mijn leven. Maar weet je, je hebt waarschijnlijk elk gek scenario gezien, wat zijn enkele van de gekste scenario's die je hebt gezien, die je bent tegengekomen, en net als mensen die het gewoon niet aankonden, is het je gelukt om te lopen en Jedi mind tricks uitvoeren met deze hele DBArtisan?

Bert Scalzo: We hadden ooit een klant die in hun databaseontwerp heel erg dacht zoals ze zouden denken in een bestandslay-outontwerp, en dat is het - als je een database normaliseert, is het eerste wat je probeert te doen van herhalende groepen. Nou, ze hadden een kolom en ze maakten er een lange, of een BLOB of CLOB, en daarin zouden ze waarde, nummer één, puntkomma, waarde nummer twee, puntkomma, waardegetal, puntkomma zetten, en ze zouden duizenden waarden hebben daarbinnen, maar ze moesten in die kolom zoeken en ze waren van: "Waarom loopt dit ding zo traag?" En ik heb zoiets van: "Wel, je kunt geen index maken van wat je deed, het is gewoon niet toegestaan. ”Dus we lieten ze eigenlijk zien, met behulp van de plannen, dat ze gewoon die tafel moesten normaliseren. Niet omdat normalisatie een academische oefening is die dingen beter maakt, maar omdat ze een query op dat veld wilden, wat betekende dat ze het wilden kunnen indexeren, en je het niet kon indexeren op een herhalende groep, of althans niet gemakkelijk . En dus dat is waarschijnlijk het ergste dat ik ooit heb gezien.

Dez Blanchfield: Ja, het is interessant hoe vaak je tegenkomt, ik denk dat de uitdaging met databases, mensen vergeten dat het een wetenschap is. En er zijn mensen die graden en doctoraten in deze hele ruimte doen, er papieren over schrijven, en je hebt een hele swag geschreven inclusief je TOAD-handboeken en andere dingen uit het geheugen. De trend in de richting van "big data", offerte-op-offerte - ik zie veel mensen de basisprincipes van database-architectuur en database-technologie, database science vergeten, als je wilt. Wat zie je in het veld wat betreft de verschuiving van traditionele databaseplatforms en het traditionele database-denken dat we effectief op de grond hebben geslagen, en het was gewoon een kwestie van performance tuning en schaling. Zie je veel mensen opnieuw leren en hebben ze een ervaring waar ze gewoon zitten en een "a-ha" -moment hebben, zoals een eureka-moment, waar ze zich realiseren dat dit big data-spul eigenlijk gewoon een soort echt grote databases is? Is dat iets daarbuiten en mensen antwoorden je terug en zeggen: "We zijn vergeten, wat we wisten en kun je ons terugbrengen van de duistere kant?"

Bert Scalzo: Nou, nee, en dit is verschrikkelijk om toe te moeten geven, maar de relationele database-leveranciers hebben ook dat Kool-Aid gedronken. Weet je nog, ik weet het niet, ongeveer tien jaar geleden begonnen we ongestructureerde gegevens in relationele databases te plaatsen, wat een beetje vreemd was om te doen, en dan voegen de gegevens, de relationele databases, nu het NoSQL-type toe stuff. In feite, in Oracle 12, CR2 - ik weet dat het er nog niet is - maar als je naar de bèta kijkt, als je in het bètaprogramma zit, ondersteunt het sharding. En dus heb je nu een relationele database waaraan het concept van NoSQL-sharding niet is toegevoegd. En dus lijkt het 'a-ha'-moment meer te zijn voor de mensen aan de relationele kant die' a-ha 'gaan. Niemand zal het ooit nog goed doen, zelfs niet de databasebeheerders, dus we hebben moet gaan en zich bij de donkere kant voegen.

Dez Blanchfield: Juist, dus je zegt een verschuiving naar veel van de rommelige gegevens, als ik het goed begrijp, in de, wat we nu big data-platforms noemen, te vinden, wat best grappig is, omdat ze niet zo oud, maar betekent dat niet dat ze zich opnieuw richten op wat ze doen met hun relationele database om meer waar voor hun geld te krijgen?

Bert Scalzo: Nee, meestal als ze een behoefte hebben in de - dat zou een 'big data-type behoefte' zijn geweest, ontdekken ze dat in plaats van naar het andere databaseplatform te gaan en iets te doen in een niet -relationele manier, de database leveranciers geven hen nu dezelfde niet-relationele technieken binnen hun relationele database, om die dingen te doen. Ik bedoel, een goed voorbeeld zou zijn, als je ongestructureerde gegevens hebt, zoals een JSON-gegevenstype of een ander complex gegevenstype dat een betekenis heeft ingebed in de gegevens zelf, ondersteunen de databaseverkopers niet alleen dat, maar ze geven je ACID naleving van ongestructureerde gegevens. De relationele databases hebben de nieuwere technieken en technologieën omarmd en dus lijkt de "a-ha" meer niet dat, "Hey wij, de applicatie-ontwikkelaars, hebben iets afgeleerd en we moeten het opnieuw leren, " het is "Hey, we doen het nu op deze manier, hoe kan ik het op die manier doen in je traditioneel relationele database en het doen zoals ik hier in deze database doe? ”en dat komt steeds vaker voor, en zoals ik al zei, de databaseverkopers zelf maken het mogelijk dat.

Dez Blanchfield: Juist, wie zijn de traditionele verdachten in deze ruimte voor de tool DBArtisan en dat? Ik heb wat huiswerk gemaakt over wat je recentelijk hebt geschreven, en vanuit het geheugen heb je iets geschreven, ik denk dat het een van je blogs was, over extreme databaseprestaties in de Oracle-wereld. Ik kan me niet herinneren wanneer het was, ik denk dat het ergens dit jaar uit je geheugen was of van eind vorig jaar, je had dit ding geschreven. En het leek mij dat het de traditionele, gebruikelijke verdachte was voor het soort onderwerp waar we het vandaag over hebben, waar mensen naar een zeer grootschalige databaseomgeving gaan en op zoek gaan naar wat u extreme voordelen daarin noemt. Wie zijn de gebruikelijke verdachten die je ziet die DBArtisan gebruiken en goed gebruiken?

Bert Scalzo: Nou, we hebben veel klanten, vandaag was ik in dienst bij een zeer grote overheidsinstantie die - en ze hebben letterlijk waarschijnlijk bijna 1.000 exemplaren van onze software, omdat het mensen in staat stelt zich te concentreren op wat ze ' opnieuw doen, en niet hoe het te doen. En het is oke, ik bedoel, iedereen zou moeten weten hoe iets te doen, maar productiviteit is het krijgen van "wat" gedaan wordt. Als het bedrijf me vraagt om een taak uit te voeren, is dat alles waar ze in geïnteresseerd zijn. Wanneer kreeg ik een vinkje om te zeggen wanneer de taak is voltooid? Niet welke techniek of welke techniek ik gebruikte om daar te komen. En dus laat onze tool hen focussen op wat, en laat ze veel productiever zijn, en dat is echt het enorme voordeel, en zoals ik al zei, sommige databases bieden een tool alleen voor hun databaseplatform. We bieden het voor twaalf databaseplatforms. Ik heb dezelfde workflow, dezelfde grafische gebruikersinterface, dezelfde navigaties. Als u weet hoe u een gebruiker een privilege kunt geven of hoe u een tabel of een index in een database kunt maken, kunt u dit in alle twaalf doen omdat het dezelfde look and feel en dezelfde workflow heeft. Dat heeft grote waarde voor onze klanten.

Dez Blanchfield: Ja, ik denk dat mensen veel meer waar voor hun geld willen krijgen van hun menselijke hulpbronnen. En de dagen van het hebben van een individuele specialist in Oracle, Ingres en DB2 zijn allemaal voorbij. Van mensen wordt verwacht dat ze de duizendpoot zijn, dus ik denk dat dit ding absoluut hun leven heeft gered.

Nog een laatste snel ding voordat ik het aan dokter Robin Bloor overhandig. Je zei dat er veertien dagen lang een gratis download is, wat als ik ga doorgaan en dat ga ik trouwens in het Bloor tech lab zetten en dit ding draaien om het zelf te bemachtigen - dat had ik voor vandaag niet kunnen doen. Je noemde een 14-daagse proef, je zei dat je het op een VM op je computer draait, ik neem aan dat het een laptop is. Wat zijn de, wat is de instap op het instapniveau voor iemand om de 14 dagen durende proefversie te krijgen en te gebruiken, net voordat ik Robin zijn vragen overhandig?

Bert Scalzo: Elke Windows-omgeving, dus Windows 7, virtuele machine met één CPU en vier optredens geheugen. We zijn geen echt dik of duur hulpmiddel. Als u nu uw databaseserver op dezelfde VM onder dezelfde Windows wilt uitvoeren, ja, moet u meer toevoegen, maar als u uw database op een databaseserver of op een afzonderlijke VM uitvoert, moet de VM worden geladen en run ons product is zeer licht van gewicht: één CPU, vier optredens geheugen, vrijwel elke versie van Windows - en we ondersteunen zowel tweeëndertig- als vierenzestig-bits installaties. Maar u moet wel de client van uw databaseverkoper installeren. Dus als u verbinding wilt maken met Oracle, moet u de SQL-netwerkclient installeren, want dat is wat Oracle nodig heeft om met een database te kunnen praten.

Dez Blanchfield: Het klinkt vrij eenvoudig. Ik denk dat één ding hiervan meer dan wat dan ook dat ik hoop dat mensen zullen wegnemen, anders dan het besef dat deze tool hun leven gaat redden, is dat ze het moeten gaan downloaden en ermee spelen, aangezien u een gratis proefperiode van veertien dagen aanbiedt. En het kan worden uitgevoerd op hun huidige laptop zonder iets extra's te installeren, want als ze al databasebeheer doen, werken ze al met databases, hebben ze al die tools op hun plaats en of het nu op een lokale VM of op hun lokale desktop, het klinkt alsof het pijnloos is om te installeren en om mee te spelen. Dus ik raad mensen ten zeerste aan dat te doen.

Robin, ik weet zeker dat je vragen hebt en Eric, je hebt waarschijnlijk wat van het publiek, dus Robin, hoe zit het met jou en ik dan terug naar Eric?

Robin Bloor: Ja, oké, nou, ik heb dingen te zeggen, ik bedoel, ik heb dit gebied altijd fascinerend gevonden omdat het was - ik sneed er mijn tanden op. Maar de waarheid is, waarschijnlijk sinds ongeveer 1998, 1999, ik ben op drift geraakt van wat Oracle eigenlijk in staat is. En ik kende Sybase en Microsoft SQL Server, beide zijn vrij eenvoudig in vergelijking met wat Oracle zou kunnen doen. Je maakte me aan het lachen toen je - ik bedoel, ik bedekte mijn mond, toen je begon te praten over scherf. Oracle deed dit eerder. Oracle introduceerde op een bepaald moment, ze werden nerveus van het object-relationele idee, dus introduceerden ze de mogelijkheid om een soort objectnotatie en objectopslag in Oracle te maken, en ik sprak met een van hun ingenieurs, zoiets als een paar jaar nadat ze het introduceerden en ik vroeg hoeveel mensen het gebruikten, en hij zei dat ik denk dat twee klanten het hadden geprobeerd en dat was het. En ik denk dat hetzelfde zal gebeuren als ze beginnen met trending NoSQL-dingen te doen. Weet je, ik denk dat het een vergissing is, ik bedoel, ik ben een beetje geïnteresseerd in wat je gedachten zijn. Zeker, zij drinken de Kool-Aid. Ze hebben het gevoel dat ze claims moeten kunnen maken die vergelijkbaar zijn met de grote NoSQL-databases zoals Cassandra, maar weet je, is het logisch voor jou?

Bert Scalzo: Nee, je hebt de spijker precies op het hoofd geslagen. Voor mij zou ik, als ik relationeel ga doen, een relationele leverancier kiezen zoals een Oracle of een SQL Server of een DB2 of een Postgres, maar als ik iets ga doen dat niet-relationeel is, in de big data-ruimte, of de NoSQL-ruimte, ga ik de juiste tool kiezen voor de juiste taak. En ik denk niet dat dat natuurlijk eerst naar mijn leverancier van relationele databases zou gaan. En dan voeg je de andere rimpel eraan toe, wat is er beschikbaar in de cloud? Zoveel mensen die hun databases niet thuis willen hebben. Dan moet je naar je cloudprovider kijken en zeggen: “Oké, wat voor provider, welke databases heb je voor mij beschikbaar die aan mijn behoeften voldoen en hoe verkoopbaar zijn ze, en eerlijk gezegd wat is het tarief of de kosten voor het gebruik van die database in de cloud per uur of per dag. En per gigabyte of terabyte? ”En wat je zult vinden zijn misschien enkele van de relatief nieuwere databases zoals Mongo of Cassandra, misschien zijn hun tarieven goedkoper, dus als je big-data van meerdere petabytes gaat doen, zou je kunnen moeten - alleen vanuit kostenoogpunt - de NoSQL-databases in de cloud in overweging nemen, omdat dit de meest kosteneffectieve manier is om dit te doen.

Robin Bloor: Ja, toch. Ik bedoel, mijn soort - het ding over relationele databases in mijn ervaring - dat lang genoeg is om littekens te hebben, dat is zeker - er is veel gezond verstand dat als je begint het toe te passen en - je begrijpt wat relationeel eigenlijk is, dat, Ik bedoel, ik herinner me dat ik ooit eens wat consultancy met één klant ging doen, en ze leidden me naar een kamer en ze hadden een soort entiteitsschema gemaakt en een derde normale vorm gemaakt, een model van hoe de primaire systemen van het bedrijf waren. Het had tweehonderdveertig tafels en ze zeiden: "Wel, wat vindt u daarvan? We gaan hiervoor een database bouwen, "en zei:" Wat vind je daarvan? "Ik zei:" Ik denk niet dat het gaat werken. "En het is precies goed, weet je, omdat ze eindigden omhoog om een specifieke structuur te creëren binnen elfvoudige verbindingen. En dat is het ding om te begrijpen over relationele. Dus ik ben een beetje geïnteresseerd in hoeveel slecht ontwerp je tegenkomt. Ik bedoel, ik heb geen probleem met DBArtisan - het doet zeer verstandige dingen en het feit dat je daadwerkelijk op meerdere platforms kunt verschijnen, vind ik geweldig, maar hoeveel kom je daar tegen waar het ontwerp een probleem is waar mensen zichzelf allerlei hartzeer hadden kunnen oplossen als ze naar een sterrenschema kwamen in plaats van er sneeuwvlok over te krijgen, weet je?

Bert Scalzo: Nou, ik wil niet als aanmatigend of arrogant klinken, maar ik zou vaker zeggen dan niet. Het is duidelijk dat het merendeel van de databases waar ik bij betrokken raak, problemen of problemen hebben. Dat is goed, omdat onze tools, zoals onze database optimizer tool, hen kunnen helpen om die problemen op te lossen, en, maar wat echt grappig is voor mij, is dat veel van de problemen steeds dezelfde simpele problemen zijn. Ik werkte onlangs met een klant die onlangs een elf-weg-join-vraag had en ik heb zoiets van: "Oké, waarom heb je geen met-clausule gebruikt?" En ze zeggen: "Wel, ik heb weet niet wat dat is. "En toen zei ik:" En kijk naar je sub-selecties hier op je gecorreleerde en je niet-gecorreleerde, "zei ik, " in sommige gevallen heb je in je waar-clausule op het diepste niveau, een tabelverwijzing uit de buitenste. "Ik zei:" Dat is, verplaats het naar het juiste niveau, sluit het niet dieper in dan het moet zijn, je zult de optimizer verwarren. "En met een paar tweaks nam iets dat ongeveer twee uur draaide en bracht het terug tot tien minuten en het was gewoon - in dat geval hebben we niets anders gedaan dan het verbeteren van de SQL die ze hadden geschreven. Ik denk dat het probleem is dat veel universiteiten en veel mensen die programmeren leren in een niet-academische omgeving, ze het leren als opgenomen tijdprocessen of rijgeoriënteerd proces en relationeel is een set georiënteerd door de natuur, en dus jij moeten in sets denken om goede SQL te schrijven.

Robin Bloor: Ja, ik denk dat dat klopt. En je moet begrijpen, het zijn dingen zoals, mensen zouden het ABC van dit soort dingen moeten weten. Het maakt niet uit. Je zult niet in staat zijn om rationele dingen te doen als je je niet realiseert dat zelfs een goed ontworpen, goed gemodelleerde database, joins tijd zullen kosten, soorten tijd zullen kosten. Ze doen het omdat de wereld nooit een manier heeft gevonden om die snel te laten gaan. Ze hebben manieren gevonden om de gegevens te organiseren, zodat ze sneller gaan dan anders, en veel van het enthousiasme dat ik moet zeggen voor de NoSQL-databases is gewoon dat ze het vermijden van het doen van joins. Ze beginnen gewoon met het bouwen van de databases met dezelfde spreiding van gegevens erin, want als je je aanmeldt bij een van de NoSQL-databases zuigen ze enorm. Vind je niet?

Bert Scalzo: Oh absoluut. En ik moet lachen, want ik begon al lang voordat relationele databases en toen Ingres RTI was, Relational Technology Institute, en we hadden geen SQL, we hadden pre-SQL relationele talen. Ik denk dat het toen in Ingres heette, Quel. Dus je komt uit deze oude databaseparadigma's zoals een netwerk en een hoger grafisch of hiërarchisch systeem, en je gaat door de relationele paradigma's na een paar decennia en nu voor mij voelt het alsof we teruggaan naar bijna een hiërarchisch systeem. Het is bijna alsof we zijn teruggekeerd.

Robin Bloor: Ja, toch. Je kunt beter Eric doorgeven, ik ben te veel tijd kwijt, maar hebben we vragen van het publiek, Eric?

Eric Kavanagh: Dat doen we, we hebben er een paar. We gaan hier een beetje lang maar ik gooi er een paar naar je toe. We hadden een paar vragen over de onzichtbare indexen. Een vraag was: "Moet iemand je tool gebruiken om die te zien?" Een andere vraag was: "Wel, wat als je blind bent?"

Bert Scalzo: Dat is een goede.

Eric Kavanagh: Nieuwsgierige vraag ook, dus gewoon FYI.

Bert Scalzo: Nee, u hoeft onze tools niet te hebben. Dat is een functie van Oracle, de onzichtbare index. Kort gezegd, in het datawoordenboek bewaart Oracle slechts een stukje metadata dat zegt: “Optimizer, negeer deze index. Het is hier, maar tenzij u fysiek wordt geïnstrueerd via een hint in de, een optimalisatietip in het SQL-commando, moet u dit niet gebruiken. ”En dus, nee, u hoeft onze tools niet te hebben, en in elk opzicht is een eenvoudige oude index, je kunt het in elk hulpprogramma zien, het is gewoon de optimizer zal zeggen: "We zullen het negeren in de normale queryverwerking." U moet het sturen als u wilt dat het wordt gebruikt. Het is echt handig voor het scenario dat ik heb beschreven, namelijk: als je een index in productie wilt bouwen, maar niet het risico loopt de rapporten te breken, of de dingen die al lopen, maar je wilt ze testen, je zou het kunnen doen. Daar is het het meest nuttig voor.

Eric Kavanagh: Dat is goed spul en toen was er nog een goede vraag. “Hoe zit het met enkele van deze nieuwe in-memory-databases? Hoe kan in-memory-databasetechnologie het spel veranderen met betrekking tot indexering? "

Bert Scalzo: Tjonge, nou, dat is goed, ik ben blij dat iemand die vraag stelde, we moeten nog een half uur gaan. Nee, het geheugen hangt af van de verkoper van de database. Normaal gesproken spreek ik niets dan lof over alles wat Oracle doet, want het is verbazingwekkend de technologie die ze hebben gebouwd, maar wanneer je je terugtrekt onder de dekens en je kijkt naar wat in het geheugen is in Oracle, in het Oracle database, wat het in werkelijkheid is, is dat het nog steeds rijopslag op schijf bewaart, en het zal kolomopslag in het geheugen krijgen, en als er onvoldoende geheugen is om de hele tabel te houden, zal het terugkeren naar de porties; het past niet in het geheugen, om het in rijen op te slaan, en dus kun je een selectie maken aan de tafel en voor de helft van de tafel, gebruik je een indexering die traditionele rijen aan de tafel raakt, en voor de andere helft van de selectie dat het daadwerkelijk uit gaat en gewoon alles uit een zoekopdracht in het geheugen haalt, en dus is het anders in de manier waarop SQL Server het bijvoorbeeld heeft geïmplementeerd met hun Hekaton-technologie, weet je, en SQL 2014, en het is verbeterd in SQL 2016, maar in sommige opzichten is die van hen een meer waarheidsgetrouwe versie van in-memory, en, maar elke implementatie heeft voor- en nadelen, maar je moet een beetje onder de covers kijken en je realiseren. Omdat ik een klant had die zei: "Oh, het geheugen van deze tafel - ik ga gewoon alle indexen opstellen", en ik heb zoiets van: "De tafel is groter dan het geheugen dat je op de server hebt, dus op een gegeven moment moeten sommige van de zoekopdrachten op schijf raken. "

Eric Kavanagh: Dat is een goede beschrijving; dat is goed spul. Welnu, mensen, we zullen de rest van dit jaar nog een paar webcasts met deze jongens hebben, kom elke keer terug als je hoort dat Bert op een presentatie is omdat we weten dat hij zijn dingen kent. Het is altijd leuk om met de experts te praten. We archiveren al deze webcasts om ze later te bekijken. Hier zijn nogmaals de contactgegevens van Bert, en we zullen proberen die link op te graven voor de download en deze ook per e-mail te verzenden, maar je kunt de jouwe altijd echt e-mailen: we hebben nog een aantal webcasts klaarstaan jaar en we doen nu de ed cal, dus mensen, als er onderwerpen zijn waar je echt volgend jaar over wilt horen, wees dan niet verlegen: wees voorzichtig, mensen, we zullen de volgende keer met je praten. Tot ziens.