Af Techopedia Staff, 24. august 2016
Takeaway: Værten Eric Kavanagh diskuterer databasetendenser med Dr. Robin Bloor, Dez Blanchfield og Scott Walz i denne episode af Hot Technologies.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Mine damer og herrer, hej og velkommen tilbage til det hotteste show i verden af enterprise IT, Hot Technologies i 2016. Ja, ja! Mit navn er Eric Kavanagh, jeg vil være din vært i dag for et show med titlen "Kunsten om synlighed: Aktivering af ledelse af flere platforme", ja. Et par hurtige bemærkninger, der er et lysbillede om dine virkelig, ganske vist fra fem år siden og nok om mig, ramte mig op på Twitter @Eric_Kavanagh. Året er varmt, dette er vores standard dias til Hot Technologies. Hvad vi gjorde med dette show er, at vi ønskede et program, der ville hjælpe os med at definere en bestemt type teknologi, så hele ideen er, at vi får to analytikere, der kommer ind og giver deres indflydelse på et bestemt rum eller en bestemt type funktion som virksomheden har brug for, og så kommer leverandøren ind og demonstrerer, hvad de har bygget, og forklarer, hvordan den tilpasser sig det, du hører fra analytikerne.
Og grunden til det, som du måske kan forestille dig, er fordi der i verdenen af marketing af enterprise-software er der termer, der bliver bundet om, og hvad der altid sker, er, at leverandører griber ind på den seneste hot term, ting som big data eller analytics til eksempel eller endda SOA eller forskellige udtryk som platform, og nogle gange er disse ord meget præcise for en bestemt teknologi, og nogle gange er de ikke. Dette show var designet til virkelig at hjælpe os med at formulere for dig, publikum, hvad specifikke slags teknologier gør, hvordan de fungerer, og hvornår du skal anvende dem.
Med det vil jeg introducere vores talere. Vi har vores helt egen Dr. Robin Bloor, der kalder ind fra hans placering i Austin, Texas, Dez Blanchfield, ringer fra den anden side af planeten, og vores gæst Scott Walz, der kalder ind fra Kentucky. Og din er virkelig, jeg er faktisk uden for Pittsburgh, så vi har en fuldt geo-lokaliseret organisation i dag fra flere forskellige steder. Med det vil jeg skubbe Robins første lysbillede, er du velkommen til at stille spørgsmål forresten, folk, vær ikke genert. Du kan gøre det ved hjælp af Q & A-komponenten på din webcast-konsol. Og med det overleverer jeg det til Dr. Bloor. Gulvet er dit.
Robin Bloor: Okay, tak for indledningen, Eric. Lad mig bare komme til det første lysbillede. Dette er en samling af meerkats der tænker på databasen. Hele præsentationen, som jeg virkelig laver her, er virkelig bare et generelt sæt tanker om databasen, som jeg for nylig har haft, med det formål at virkelig omkring år 2000 så det ud til, at databasespillet var forbi i den forstand at langt de fleste af databaseimplementeringer forekom på relationsdatabase. Og så ændrede det sig bare, ved du, alle disse ting, som meerkaterne tænker på, kolonnebutikker, nøgleværdibutikker, dokumentdatabaser, database i hukommelsen, grafdatabase og en hel masse flere ting pludselig dukkede op. Og det var næsten som en ny slags geologisk æra, hvor fossiler af forskellige slags dyr pludselig dukkede op.
Nyheden fra Lake Wobegon, det er virkelig forbi for enkeltmodeldatabasen. Der er ingen tvivl om, at RDBMS stadig dominerer, men der er nu etableret andre slags databaser. Det er virkelig overblik over, hvad jeg vil sige her.
Dimensionerne på databasen, nogle af disse blev faktisk mere vigtige for nylig, men dem, som jeg kunne tænke på, da jeg lavede dette lysbillede, blev det alligevel opskaleret i form af effektiv anvendelse af ressourcerne på en given server? Skalerer den ud, så den kan gå på tværs af store klynger? Udnytter den den tilgængelige hardware, der er slags databaser i hukommelsen, går i den retning? Kan det distribueres? Der er en række databaser, der har størst betydning for variationer, der skal distribueres. Hvilke egenskaber har det? Den grundlæggende ACID-karakteristik for databasen. Men nu i stedet for at have faktisk konsistens, har en række databaser til sidst konsistens, folk bruger dem, og de har ikke et problem med dem, så de har demonstreret, at ACID ikke var absolut nødvendigt, bare en god ting at have i en mange situationer.
Med hensyn til metadataorganisation er hele spillet ændret. Vi har forskellige metadataorganisationer i stedet for et typisk RDBMS-skema. Med hensyn til optimeringsprogrammet foregår der en frygtelig masse optimizeraktivitet, afhængigt af de datastrukturer, du prøver at optimere. Med hensyn til håndterbarhed er der en stor variation i dette, som jeg vil komme videre til senere, men dybest set er hele DBBS-punktet håndterbart, og igen bestemmer omfanget af dens håndterbarhed til en vis grad omfanget af dens anvendelighed.
Med hensyn til hardwarefaktorer er dette det punkt, der virkelig siger - jeg mener, at der kun er et punkt, der bliver gjort her - det punkt, der bliver gjort her, er, at hvad vi nu ser på i dag med hensyn til databasearkitekturer vil ændre sig. Det kan være de samme databaser, men de bliver nødt til på en eller anden måde at tage hensyn til, hvad der rent faktisk foregår på hardwareniveau. I mange, mange år havde vi denne relativt enkle situation med CPU, hukommelse og spindisk disk - det er virkelig væk.
Det punkt, der er her, først og fremmest har vi CPU'er, men de er langt mere parallelle muligheder end de havde før med mange, mange forskellige processorkerner. Vi har også fået GPU'er, vi har også fået FPGA'er, forskellige former for silicium, men Intel har giftet sig med en FPGA med en CPU i sin næste udgivelse, og - OG - har giftet sig med GPU og CPU'er sammen på den samme chip. Du har chips med forskellige egenskaber. Fordelen ved en GPU er, at den virkelig er stor til kraftig parallelitet og især ved numerisk beregning. FPGA'er, du kan på en eller anden måde sætte koden på chippen, og den fungerer langt hurtigere, end hvis du bare fodrer den til chippen.
Der er en krydsning af disse ting, der sker. Vi har 3D XPoint fra Intel og PCM fra IBM, som er nye typer hukommelse, der er langsommere end RAM, billigere end RAM, men ikke-flygtige. Og disse skaber en smule spænding blandt en række softwareleverandører, som jeg har talt med. Vi har SSD'er, men nu bliver de meget, meget store, og de giver parallel adgang. Med parallel adgang til en meget stor SSD kan du nærme dig læsehastigheder, der ligner RAM læsehastigheder. Vi har denne mulighed for tre typer lager RAM, 3D XPoint-ting og SSD'er, som alle vil gå ekstremt hurtigt. Og da hastighed er essensen af databasen, vil al databaseteknologien prøve at udnytte disse så hurtigt som muligt. Og det kommer til at involvere og har været involveret parallel arkitektur, men skalere parallel arkitektur. Hardware-niveauets ydelse accelererer hele tiden, har gjort det i mange år, fortsætter med at gøre det, og de generelle omkostninger falder.
Trail of Tears. Dette er bare forskellige forsøg på databaser, de første databaser før relation blev generelt benævnt netværksdatabaser, så kom relationelle databaser, så kom objektdatabaser, de fik ikke en hel del trækkraft, så kom kolonnebutikdatabaserne, som var relationelle databaser gjort meget anderledes. Og så havde vi dokumentdatabaserne og SQL-databaserne, som var objektdatabaser, gjort anderledes, eller hvis du vil, den samme kolonne med objektdatabaser, og de fangede videre. Og for nylig har vi haft grafiske databaser, der vinder trækkraft og RDF-databaser. Og hvad du ser på der, er mindst tre forskellige sæt datastrukturer, der er tilpasset. Den relationelle database gør tabeller og rækker meget godt. Dokumentdatabasen og objektdatabaserne - de gør besværlige datastrukturer, især hierarkiske datastrukturer, meget godt. Og grafdatabaser og RDF-databaser klarer netværksdatastrukturer meget godt. Og disse forskellige, jeg synes om dem som tre linjer, disse linjer vil fortsætte på ubestemt tid. Det stopper ikke, fordi motorerne, der gør disse ting godt, ikke fungerer særlig godt på den anden datastruktur.
Og så har vi den forkæle faktor af Hadoop. Hadoop er ikke en database, men der er databaser, der bruger HDFS til deres lagerstruktur. Og en masse ting, Hadoop gør, er den slags management ting, der skal gøres for en database. Det er også værd at nævne, at Spark heller ikke er en database, men den har det, og det er en umoden, men den har en SQL-optimizer, og derfor er den ligesom en kerne i en database uden nødvendigvis at vide, hvor du skal gemme dataene, men hvis du sætter det på HDFS, er en del af databasekravet faktisk opfyldt, simpelthen ved hjælp af det underliggende filsystem. Gnist er især blevet en del af databaseøkosystemet, og det er ofte forbundet med mere kraftfulde databaser, og grunden til det er virkelig analyse. Analytics - Spark er, ja, det går meget, meget hurtigt ved analyse. Analytics er den vigtigste applikation, som de fleste mennesker investerer i lige nu, så de to går slags hånd i hånd. Data føderation snarere end koncentrationsregler, det burde slags være indlysende af det faktum, at du har mindst tre forskellige behov, strukturerede typer databaser derude, og derfor dataforbindelse, hvis du vil dele dataene imellem dem. Det er ofte nødvendigt, men du har også databaser, der skalerer ud, og databaser, der ikke gør, virkelig magtfulde motorer som Teradata eller Vertica har et meget bestemt sted, men mindre motorer, der kan gøre en frygtelig masse af arbejdet, så, føderation vil sandsynligvis være der i lang, lang tid, selv mellem relationelle databaser.
Den sidste ting at sige, IoT, det er ikke ovre, før den fede dame begynder at skjule data. IoT kan muligvis skabe på en eller anden måde en anden dynamik i databaseverdenen, og det vil komplicere tingene endnu mere. Forhåbentlig er der - på en eller anden måde - der vil være en slags konvergens, der foregår, men jeg kan ikke se, at det hele kommer sammen, som det gjorde med de relationelle databaser. Ikke nogen tid snart alligevel.
Og jeg tror, det er alt, hvad jeg har at sige, så jeg overleverer det til Australien.
Dez Blanchfield: Tak, Robin. Tak til alle for at være sammen med os, tak for at have mig her til morgen eller i eftermiddag din tid. Dette er et rigtig varmt emne, fordi vi har oplevet en ganske eksplosion i det sidste årti og lidt i den mængde data, vi er nødt til at beskæftige os med, og altid at dataene ligger inden for en eller anden form for system, der i de fleste tilfælde er en database af en eller anden form. Jeg tænkte, at jeg hurtigt ville tage os gennem en meget høj grad af gåtur gennem, hvordan vi kom hertil, og det problem, der skabes, og hvilke typer ting, vi har brug for nu, og så skal vi tale om typerne af en løsning, der kan anvendes på det. Lad mig bare få fat i min første dias her. Jeg er af den opfattelse, at vi er på det punkt, hvor DB admin 2.0, eller database admin 2.0, er slags, hvor vi er slags på nu, engang en gang var en databaseadministrator en ret ligetil rolle og udfordring og du kunne træne nogen temmelig hurtigt. I dagens verden er det ikke længere tilfældet, og jeg vil vise dig, hvorfor det er sådan.
Engang en gang ville en databaseadministrator være i stand til at oprette forbindelse til DB backend og udføre en hurtig visningsdatabaser, og der ville være en liste over databaser i systemet, som de måtte være opmærksomme på, og de kunne meget hurtigt komme over disse databaser og vælg dem og har lidt af en poke og en sonde rundt og brug oversæt, beskriv tabel for at finde ud af, hvad der er i en tabel og hver af kolonnerne og rækkerne, og det var en relativt ligetil udfordring, og hvis du læser gennemsnittet to eller tre hundrede siders bog om databaseadministration for hver platform, kunne du næsten undervise dig selv uden at skulle lave en raketvidenskabelig grad.
Men det er ikke længere tilfældet, og grunden til det er efter min mening, at der bare er alt for mange muligheder i databaseverdenen til, at enhver person kan være ekspert hos en specialist hos og være i stand til manuelt at administrere og administrere . Og årsagen hertil er, at vi i de sidste fire til fem årtier, når det kommer til en verden af servere og databasesystemer og databaseservere og applikationssuiter, er nået en meget, meget lang vej. En gang i tiden havde vi stort jern, der skulle beskæftige sig med, hvad der faktisk var små data, og grinende små, når vi ser tilbage nu. Jeg så et rigtig pænt foto på Twitter forleden af denne fantastiske dame, der var hovedprogrammør og udvikler for NASA på det tidspunkt, da vi satte mænd på månen, og hendes kode blev udskrevet i hundrede og tredive- to kolonnelinieprintere og fan-foldet, og det stod faktisk højere end hun var, mængden af kode, hun skrev.
Og da jeg tænkte over det, var jeg som, faktisk er det sandsynligvis omkring to eller tre hundrede megs data, hvor hun skulle indtaste det hele højst, hvis ikke mindre. Og derfor var den samlede mængde data, der var indeholdt hendes kode, selvom den fysisk stod højere end hende, da den blev udskrevet på papir, faktisk en meget, meget lille mængde. Selv disse massive computere i rummelig størrelse, og dette er et IBM System / 360 i netop dette lysbillede, mængden af data, det faktisk kunne indeholde, var lille sammenlignet med nutidens verden. Faktisk holder vores smartphones 60 og 128, og 256 gig, og vi har snart terabyte i vores telefoner inden længe, når prisen på flash falder.
Og så på den tid og den æra var databaseadministration ganske ligetil. Her er et snapshot af en 3270 terminalsession og for en DBA, der kunne logge ind og se på antallet af filer, der var relateret til databasen, og de indekser, der var der, og rækkerne og kolonnerne var ligetil. Og du kan se her i dette skærmbillede, at konteksten af dette er en tabel og et antal tabelpladser, det ville have været hele hovedrammen, der administrerer en databasetabel. Mens vi i dag har milliarder af rækker med poster i databasesystemer. Og ændringen skete gennem et skift i teknologi, der gjorde det muligt for os at bygge databaseplatforme og datastyringssystemer.
Hvis vi tænker på den slags originale mainframes og mange computere, der kører database og til sidst relationelle databaser, så for halvtreds år siden, og den store jernsort af verden og de små datasæt, vi havde, da vi kom til omkring firserne, vi var slags på, vi gik gennem mainframes fra mini til mikro, og vi havde pc'er, der kørte ting som dBase II og dBase III, og på DOS og CP / M, og vi havde en meget tidlig relationel-database- tilgængelige stilteknologier, og de skaleres ret godt sammenlignet med hvad vi var vant til i mainframe. Da vi kom til halvfemserne, havde vi ligesom Oracle og DB2. Og i slutningen af halvfemserne havde vi mennesker, som hemmelige computere, der kunne klæbe som en netværksmodel, meget, meget store maskiner, maskiner i kabinetstørrelse sammen og tage lignende og opbygge disse klynger af computere. Men selv da var den stadig lille sammenlignet med hvad vi ser i dag.
Men i det lysbillede, jeg er kommet op her, er dette Hadoop-klyngen og fungerer effektivt som en maskine, og det er egentlig bare en rigtig, rigtig stor computer, og den kan indeholde de typer webskala-data, vi er vant til nu . Og så udfordringen med databaseadministration, databasestyring på disse typer platforme er faktisk efter min mening blevet raketvidenskab. Du skal være en ekstremt smart karakter for at være i stand til at forstå teknologien, den kører på, platformen, den kører på, de data, der er der inde, hvilke anvendelsesformer der er for disse data. Og ja, vi så denne eksplosion fra begyndelsen af 2000'erne, hvor vi fik Microsoft SQL til at blive en ting, Lotus Notes var ganske veletableret og derude, og antallet af Lotus Notes-databaser, der krøb rundt omkring i stedet, var ret skræmmende. Og vi havde de sædvanlige etablerede medlemmer af Oracle og DB2 og begyndte virkelig at gribe fat. Nogle af mærkerne som begyndte at falme ud. Men vi var stadig egentlig bare ved at udføre traditionel databaseadministration helt op til det punkt, omkring den slags 2006-æra, hvor, hvis jeg går tilbage til det billede af den klynge, havde vi, hvad vi kaldte Beowulf-klynger, blevet en ting, hvor vi kunne tag pc'er fra hylden og lim dem sammen og lav store supercomputere.
Men fra omkring det punkt og frem krydsede vi et vippepunkt, hvor mennesker var i stand til at udføre databaseadministration på oldskolen og - som jeg siger, efter min mening - blev skalaen meget, meget stor meget, meget hurtigt. Det er næsten som om vi havde denne big bang-begivenhed inden for teknologi, der førte til vedtagelsen af datateknologi og datastyringsteknologi og især databaserne omkring dem. Og fordi vi faktisk bygger højeffektive computerstilklynger til at være vært for data i forskellige former. Og for at præcisere dette punkt er her et snapshot af landskabet fra 2016 af databaseteknologier, der er tilgængelige for os. Fra det nederste højre hjørne og open source, helt til øverste venstre hjørne i infrastrukturen. Og i øverste højre hjørne i applikationsløsninger, der er tilgængelige for os, og i nederste venstre hjørne, en blanding af infrastrukturen og ydeevnemotorer, der udfører analyser osv. Og i midten er der selvfølgelig enheder som vores smartphones, som faktisk kører på meget små versioner af databaser, til at gøre ting som at styre vores kontakter og så videre, eller vores opkaldslogger og andre ting, som vi har.
Og så i mit sind var der denne eksplosion, ligesom en kambrisk eksplosion i den slags ting, hvor mængden af teknologiudvikling, der fandt sted i den meget korte periode fra ca. 2006 til 2016, der nu faktisk er et årti, som det var. Vi har nu set grafdatabaser blive en stor ting, i hukommelsesdatabaser bliver en stor ting, SQL-databaser kommer med. Overgangen til forskellige computermodeller, Hadoop skabte, vi havde MapReduce-modellen, nu har vi Spark og streaming analytics og streaming computere, elastiske distribuerede data, rammer, som folk er nødt til at udvikle for dem, for at komme til de skalaer, vi har brug for, og når vi tænker på den rejse, at gennemgå slags, hvad er de relationelle databasestyringssystemer med de sædvanlige mistænkte, Oracle, PostgreS, Sybase, IBM DB2, MySQL og Microsoft SQL Server-platformen. Vi har set nogle nye børn komme på blok nu, Clustrix, Xeround, NuoDB, MemSQL, og der er snesevis og snesevis mere, som du så på det lysbillede før. Hvis du kunne forestille dig udfordringen med at skulle kende disse platforme og know-how til at køre dem og få den eneste rude af glasvisning, som du har brug for at være en DBA og gøre disse ting, er udfordringen langt fra triviel. Og så pludselig kom NoSQL-motorerne, som er en helt ny race af sjov udfordring.
Og så er det sidste objektglas, jeg har her, en slags den ultimative knock-out-en-to-tre-knock-out, og det er, at vi har taget nogle af disse teknologier nu, og vi har skabt en servicefunktion til dem, vi har lagt dem i skymodeller, og de er nu tilgængelige som et hjælpeprogram, som en tjeneste, du kan dybest set få database som en service, og de sædvanlige mærker, som vi ser der på Amazons Web Services og Googles Cloud Compute-platform og Microsoft Azure, er dem, der kommer til folks men der er faktisk snesevis og dusinvis af skyplatforme nu. Og i Australien er der for eksempel noget som hundrede og tolv virksomheder, der er i god tro, storskala offentlig sky, der tilbyder databasetjeneste i forskellige former.
At tænke over den udfordring, som den gennemsnitlige DBA har for at komme ud af sengen og gå på arbejde og klare sig nu, er en ganske uhyggelig udfordring. Og derfor er jeg meget af den opfattelse nu, at vi som mange ting i livet har opskaleret de horisontale og lodrette, det er infrastrukturen, der er skaleret i en meget horisontal, næsten lineær vækstmodel, og kompleksiteten af stakken i en lodret forstand, antallet af databaseplatforme, antallet af applikationsrammer og modeller, vi er nødt til at beskæftige os med, er kommet langt ud over, hvad mennesker skal være i stand til at klare med en enkelt rude af glasvisning, og hvad pointen nu med databaseadministratorer har brug for et helt sæt nye værktøjer til at være i stand til at tale med alle disse platforme, mangle dem, administrere dem og støtte dem, og jeg tror, det er hele emnet for vores samtaler i morges, eller i eftermiddag din tid, og med det i tankerne, Jeg overleverer til vores gæst, der vil tale meget om deres produkt, og hvordan det kommer til at tackle udfordringen.
Eric Kavanagh: Okay Scott, jeg skal give det -
Scott Walz: Mange tak, okay, tak. Tak Dez, tak Robin, og tak til alle for at være med og have mig på opkaldet i dag. Jeg vil gerne takke Robin og Dez for at have taget mig med på en gåtur ned i hukommelsesbanen, efter at have været i rummet siden de tidlige 90'ere, du bragte mange gode minder tilbage. Hukommelsen, som jeg ikke så på nogen af disse lysbilleder og billeder, var stempelkortene. Og det var den allerførste ting, der blev introduceret for mig, da jeg først startede på mit første job på universitetet, min kollega i terningen ved siden af mig, sagde, at jeg ikke skulle røre ved hans stempelkort. Så ja, absolut, og det har virkelig været en udfordring og en udfordring, som vi har arbejdet på at hjælpe vores kunder med at tackle og siden midten af halvfemserne, og dette er et produkt, som jeg vil tale om i dag. Lad os tage et kig på multiplatformadministrationen, og dette er kun et undersæt. Jeg valgte en graf, men som Dez satte -
Eric Kavanagh: Du er nødt til at dele din skærm.
Scott Walz: Åh, det gør jeg bestemt, tak.
Eric Kavanagh: Ingen bekymringer. Og folk, vær ikke sky, still spørgsmål, vi har tre smarte bukser på opkaldet i dag, så send dem de hårde spørgsmål. Du kan bruge Q&A-komponenten i din webcast-konsol, eller du kan tweet med hashtaggen fra BriefR. Okay, Scott, tag det væk.
Scott Walz: Der går vi, tak. Jeg greb dette lysbillede og dette billede. Billedet fra Dez sprang mig virkelig væk, fordi det er, det er virkelig den verden, vi lever i i dag, og den verden, som DBA'erne presterer i. Og som de nævnte, det er ikke længere, du virkelig, kæmper for at være i stand at gøre dette med bare brute kraft. Du har virkelig brug for værktøjerne, og det er, vi kommer ind for at spille, og vi ser den hele switch, momentumændringen, hvor det var tidligt og blev meget tavs, som du nævnte, og så gik vi til at arbejde med flere databaseplatforme, så det var vores første forsøg på værktøjerne, og så var det tilbage til, hvor organisationer, og efter år 2000, og når det på en måde blev indsnævret lidt. Med organisationerne og ønskede at gå solidt, men så kom det tilbage, og det sprang virkelig virkelig, da du introducerede alle disse nye platforme. Og nu i stedet for at blive duehullet til en bestemt platform eller en bestemt teknologi, finder ingen af disse organisationer ud af, hvad der er bedst. Hvad er den bedste applikationsdatabase, hvad er den bedste platform at bruge? Og med det sagt, vil jeg gerne lede dig lidt om, hvad vi gør med DBwartan. Og DBwartan har været vores flagskibsprodukt, der administrerer, som det siger tværplatformiljøer i over 20 år, og det er her vi bor, og det er her vi gerne understrege og arbejde med vores kunder og give dem værktøjerne til at gøre dem produktive og udført.
Lad os gå foran, og jeg vil hoppe lige ind. Jeg viser produktet mere, efterhånden som jeg går gennem dias, og jeg tror, at du sikkert også gør det. For dem af jer, der ikke har set DBwartan før, ser vi på comp, og jeg tror, Dez brugte udtrykket ”enkelt rude af glas”, og det er noget, som vi er stolte af at give DBA et enkelt blik på alle deres platforme. Rigtigt, ingen grund til at åbne op for andre applikationer, vi kommer til at oprette forbindelse og få dig derinde og begynde at arbejde med platformen. Når man ser på databaseudforskeren til venstre, kan vi oprette dette, som vi finder det passende, vi kan organisere det, som vi vil. Og du kan se, at jeg har en blanding, jeg nogle af mine Oracle-servere, jeg har MySQL, jeg har PostgreS her, jeg har også en - det er mærket produktionsservere, som nogle inkluderer nogle af MySQL-servermiljøet. Igen kan vi se lige der, at vi har en god pasform. Hvis jeg ser på at registrere en ny database, ser du en af de platforme, vi understøtter, der er et par, som jeg vil oprette. Du vil bemærke, når dette er din SQL, support til det, Teradata, Apache, PostgreS, her er de generiske data, som vi understøtter.
Hvis vi har JDBC-driver eller LDBC-driver til en af platformene, er vi i stand til at oprette forbindelse, give dig en forbindelse og give dig mulighed for at arbejde med platformen lige indenfor DBwartan. Igen, så du kan fokusere på det aktuelle job, og ikke hvordan du får det til. Gå gennem alt det. Men jeg vil gerne vise et par ting om produktet. Lad os i så fald åbne op, og for eksempel behandle vi Oracle. Dette er bare min lille destinationsside her, men jeg vil gerne tage et kig på nogle af mine skemaer, som jeg arbejder med. Vi kommer til at trække ind i et af de større skemaer, så igen vil vi bringe listen over tabeller tilbage. I dette tilfælde åbner jeg et bord, så vi vælger dem bare, og det vil bringe dem op i vores objekteditor.
Nu er Oracle noget, som jeg har arbejdet med i årevis, hvad jeg vil vise dig er sandsynligvis en let udsagn for dig. Men hvis Oracle er platformen, eller hvis PostgreS er platformen, eller Teradata er den platform, du lige har fået, og du har brug for at komme op til hastighed, er opgaven at tilføje en kolonne. Eller måske er den aktuelle opgave at slette en kolonne. Men du ønsker ikke at skulle bekymre dig om syntaks, ikke? Vi vil gå, bare skriv det, vi har brug for, opsæt det, og vi lader DBwartan til at generere. Her skal vi trykke på ”Alter.” Det vil generere scriptet til os. Igen, et meget simpelt eksempel, men pointen er, at det vil gøre arbejdet for os for at generere og placere denne kolonne i tabellen.
Hvad vi dog også kan gøre, er at flytte kolonner rundt i tabellen. Hvis du nogensinde har forsøgt at gøre det med det traditionelle, er det lidt mere kompliceret end bare en enkelt kodelinje som denne er. Men igen arbejder DBwartan bag kulisserne, genererer koden til dig og producerer igen SQL. Vi lukker herfra. Før jeg gør det, skal du lægge mærke til alle fanerne på tværs af toppen igen, brugergrænsefladen er meget intuitiv. Hvis jeg kommer ind i opdagelsesrejseren, hvis jeg hopper ned til PostgreS, ikke? Hvis jeg går ind i min skematilstand der, skal du se på bordet, meget ens udseende og følelse, ikke? Vi åbner dette, igen vil vi se informationen her. Egenskaber, forfædre, kolonnerne. Vi er specifikke for platformen, vi vil give dig dette, brugergrænsefladen, for at være i stand til at vise dette og arbejde med objekterne. Du vil vide, hvad du skal gøre, og det vil gøre det muligt for dig at gøre det på en effektiv og rettidig måde, så du ikke behøver at bekymre dig om nøjagtigt, hvad der er den klausul, der skal der, for at angiv denne mulighed. Vi tager os af det for dig.
Når vi ser på det, skal jeg springe over til SQL Server nu og tale lidt om nogle af de andre funktioner, så vi er alle nødt til at overvåge databasen. Så igen, start det op, lad os se alle de sessioner, der finder sted, sessioner, der kører. Hvordan skal vi se, hvilke udsagn der udføres og være i stand til at have kontrol over det? Skal vi stoppe en session? Skal vi se nogen låse der kan være i databasen? Eventuelle blokerende låse? Igen, vi har alle disse oplysninger lige ved hånden for at vi hurtigt kan reagere, tage korrigerende handlinger om nødvendigt og vende den rundt. Vi kommer tilbage til vores udforsker. Det er her, dette er drivpunktet, det er her jeg altid vender tilbage til, det er her jeg personligt kan lide at få tingene i gang og arbejde herfra. Da jeg er tilsluttet en SQL Server-database for at se på hjælpeprogrammerne. Fordi vi er tværplatform, kan vi begynde at se på udvindinger, migrationer. Vi kan flytte på tværs af platforme, hvis vi har brug for at migrere objekter fra en platform til en anden, kan vi gøre det, forudsat at disse objekter findes på de forskellige platforme. Ekstraher skemaerne, offentliggør til rapporter, indlæser og aflæs data og sikkerhedskopierer databaser.
Igen alt det fra UI. Og når du kommer over til værktøjerne, kan du se et komplet sæt værktøjer, som vi kan betjene fra, ikke? Fra "Find i filer" kan vi udføre en komplet databasesøgning, hvor vi kigger inde i systemtabellerne for at finde den streng, du leder efter. "Eksekvering af script og fil", hvis du har en standarderklæring, der kan udføres mod flere platforme, flere datakilder, kan vi indstille det lige indefra i en DBwartan, der peger på de mål, vi ønsker, at den skal udføres mod. Tryk på “Gå”, og det vil køre og bringe os resultaterne tilbage mod alle disse måldatakilder. Igen, så du kan arbejde fra den ene rude glas.
Og "Analyst Series" igen, disse er mere dybtgående. Disse er mere rettet mod relationelle databaser, når vi begynder at komme ind på flere af de nyere platforme, og du vil også se os udvide denne funktionalitet til disse arenaer. Og generelt kun mange forbedringer af brugergrænsefladen. Funktioner, der er specielt beregnet til DBA. Elementer som vi har evnen til at lave et script-bibliotek. Disse SQL-scripts, som du ofte udfører mod flere platforme, gem det her, træk det, så snart vi får et nyt ISQL-vindue, kan vi bare trække scriptet ind, og vi har nu scriptet klar til at gå. Igen, ved at have det lige ved hånden for at være i stand til at gøre og styre. Du vil bemærke, at vi leverer med scripts, der allerede er defineret til nogle af platformene, så vi kan gå videre og oprette så mange, som vi har brug for til enhver tid.
En dejlig ting, som jeg kan lide og mange af vores kunder gør, hvis du nogensinde er interesseret, og jeg får dette spørgsmål meget med hensyn til, ”Hvordan gør jeg det? Det er ret cool. Hvordan gør DBwartan det? ”Der er en lille funktion lige her, “ Logfile ”, du kan logge alle de SQL-sætninger, som vi udfører, så hvis du vil vide, hvordan vi udfylder det efterforskende, eller hvordan vi udfylder editoren til en PostgreSQL-tabel eller en Teradata-tabel, log SQL, så registrerer vi alt, hvad DBbrevan udfører mod databasen, og du kan vende tilbage og se på den SQL og have alt, hvad vi har brug for. Måske vil du integrere det som en del af et af dine scripts. Absolut. Helt fint.
Vi kan godt lide at være meget gennemsigtige med, hvad vi laver, og hvad vi udfører overfor databasen, og derfor vil vi give dig mulighed for at gemme og registrere alt, hvad vi anvender til databasen. Vi har også konfigurationsindstillinger. Du vil bemærke, at jeg har det sat op som "Organisering af objektejer." Jeg kan også konfigurere efter "Objekttype." Hvis jeg kom ind i mit PostgreSQL-miljø igen, gik jeg ind i skemaet, hvis jeg kiggede på SQL'erne i stedet for bare mine GIM-tabeller, der hører til det skema, jeg vil se alle tabellerne, uanset skemanavne. Igen forskellige måder at organisere ting, der virkelig tilpasser det til din egen arbejdsgang, og hvordan du gerne vil se det.
Og den sidste ting, jeg vil tale om, er evnen til at indstille "Bogmærker." Hvis jeg borer i, hvis jeg arbejder i en af mine platforme og jeg vil fokusere på netop min tabellstilstand, kan jeg tilføje et bogmærke. Jeg ved, en meget enkel funktion, men så rart at have, især når du arbejder med så mange datakilder og så mange platforme som dagens DBA er. For at kunne komme ind i systemet skal du starte DBwartan og lade bogmærke manager tage dig lige til stedet i træet, hvor du har brug for og være i stand til at arbejde. Og derefter herfra kunne jeg oprette en ny tabel og igen på de platforme, som vi understøtter, som du så tidligere, og vi kommer til at lede dig gennem “Wizard” for at lade dig køre og udvikle og oprette tabellen. Og vi vil generere al den syntaks, der er nødvendig for at gøre det bag kulisserne for dig og derefter præsentere det for dig i slutningen i et eksempelvindue. Du kan komme til at validere, se nøjagtigt, hvad vi vil generere. Du kan trykke på knappen "Udfør" og derefter på "Afslut" -knappen, lad den udføre. Eller du kan gemme det eller skubbe det ud til et andet ISQL-vindue, så gør det igen, måske skal det være en del af et større, et større script, som du vil gemme og distribuere i løbet af batchvinduet.
Det er en oversigt over DBbrevan. Når vi snakker om det igen, er det et produkt, der har set en masse platforme, support til disse platforme og god brugeroplevelse, god feedback fra vores kunder også. Og hvis du er interesseret, som en af panelmedlemmerne, men hvis du har brug for at finde noget IDERA-relateret eller DBwartan-relateret, er du velkommen til at nå ud, og du kan helt sikkert finde mig på min e-mail-adresse.
Eric Kavanagh: Okay, jeg antager, at jeg kaster det åbent for Robin for spørgsmål og derefter Dez, og så overvåger jeg spørgsmål og svar fra de deltagende. Robin, tag det væk.
Robin Bloor: Okay, jeg mener, det første spørgsmål, jeg har faktisk været bekendt med DBwartan i ganske lang tid, så jeg er lidt opmærksom på dens muligheder. Hvad jeg ville være interesseret i, at du adresserer, er dens, slags fremtidige stier herfra. Jeg mener, jeg ved, du ved, sidste gang jeg kiggede på det, må det have været længe siden. Jeg ser, at du understøtter mindst tre databaser, som jeg ikke vidste, at du understøttede før. Hvad er fremadstien for DBwartan? Er det sandsynligt, at du bare vil tilføje flere og flere databaser, eller er det en tingudvidelses ting? Hvor har du til hensigt at gå med det?
Scott Walz: Det er et godt spørgsmål, og jeg vil gerne have alt det ovenstående. Vi vil bestemt fortsætte med at bygge ud, fordi de traditionelle RDBMS-platforme ikke sidder stille, ikke? De fortsætter med at bygge ud. Vi vil fortsætte med at følge den vej. Og så vil du se os begynde at se og gå i den retning af at støtte netto nye platforme. Fordi vi anerkender, at selvom nogle af disse platforme fortsætter med at vokse, den traditionelle RDBMS, er der visse situationer, hvor de nye platforme er de rigtige platforme for kunderne at gå med. Vi holder virkelig øje med det marked, det segment og prøver at træffe de rigtige beslutninger på hvilke platforme vi skal bruge. De ser ud til at ændre sig hver dag praktisk talt.
Robin Bloor: Det er, som både jeg og Dez sagde, det er et meget livligt marked, er muligvis en måde at se det på. En anden ting jeg ville være interesseret i - åbenbart vil du ikke være i stand til at besvare dette spørgsmål præcist detaljeret, men jeg har stødt på websteder i min tid, hvor der er tusind tilfælde af Oracle, og Oracle var ikke den eneste database, der blev brugt, der blev implementeret, ved du. Og da jeg faktisk talte med dem om, hvordan i alverden styrer du, at mange tilfælde sagde de, "Nå, du ved, der er kun omkring fem eller seks store tilfælde, og vi har omkring tre DBA'er, vi spredte over det." Jeg er interesseret i at bruge DBwartan, fordi du kan gøre meget ved det, hvor mange databaser sidder der over, lad os sige typisk, eller endda hvad er de største eksempler på, hvor mange strenge det kan administrere på én gang?
Scott Walz: Nå, jeg har set situationer - og igen, det er en smule kompliceret, det spørgsmål er, fordi DBwartan tillader mig at have flere forbindelser eller flere datakilder defineret til en enkelt instans. Måske vil jeg lave en syslogin og derefter et login med lavere tilladelser, men jeg har behandlet kunder, med at alt sammen kollapsede det går adskillige skærme. Nu, da jeg spurgte dem det, er det spørgsmål, som du har stillet mig, ”Hvordan styrer du så mange?” Og så siger han: ”Det gør jeg ikke.” Ikke? ”Jeg styrer, hvad jeg kan, men jeg har brug for adgang til alt.” Jeg ser endnu, hvad der stopper, ved du, de øverste grænser for, hvad folk kan styre, er virkelig den øvre grænse for, hvad den person, den enkelte, kan håndtere. Men du ved, som jeg nævnte, de mennesker, som jeg udfordrer med, de indrømmer åbent, at de har alle disse forbindelser, men der er ingen måde, de kan styre det på. De stoler på deres hold. Som jeg er sikker på, at du har oplevet, ja.
Robin Bloor: Jeg har faktisk været en DBA selv, selvom jeg ikke gjorde det så længe. Og den ene ting, som du ved, jeg husker ud over alt andet i relationelle databaser, er, at du kan gøre en enorm mængde ting med SQL. Ofte mere, end du tror, du kunne. Hvilket på en eller anden måde forklarer noget af den funktionalitet, som DBbrevan har, fordi det bare oversættes direkte til SQL. Men du ved, jeg er sikker på, at du gør andre ting. Det er alt sammen SQL-scripting, eller er der andre specielle rutiner, der er skrevet til esoteriske situationer?
Scott Walz: Ja, meget af det, hovedparten af det er SQL, det er bare det. Men vi skriver rutiner, der kan køres fra en kommandolinje ved hjælp af sælgers værktøjer, sælgerens frontender. Vi lægger frontend på, ved du for eksempel for datalastværktøjer i platforme, ikke? Det er ikke SQL-scripts, ikke sandt, det er kommandolinjjob. Det vil generere dem og være i stand til at give dem til DBA, som de derefter kan udføre. Se ja, vi laver lidt af begge dele, men størstedelen af det er SQL-scripts.
Robin Bloor: Når man ser på, fordi man selvfølgelig på en eller anden måde skal se på den udvikling, der sker, som jeg betragter som ret ny. Jeg mener, en af de ting, som jeg finder interessant, der sker, er, at Spark naturligvis starter som en raket, men Sparks SQL, det er væk fra at være forfærdeligt umoden til at begynde at se lidt mere moden ud med lidt mere SQL-kapaciteter. Ser du på sådanne ting og spekulerer på, om du vil begynde at styre dem med DBbrevan?
Scott Walz: Det gør jeg bestemt. Der er altid der. Jeg ved, at vores produktadministrationsteam altid kigger på, hvor vi skal hen, og alt er på bordet for os med hensyn til hvad vi ser på i fremtiden.
Robin Bloor: Okay, Dez, vil du hænge ind?
Dez Blanchfield: Ja, faktisk er der en masse gode ting, du åbnede døren for mig der, Robin. Mange tak. Jeg er ivrig efter bare at udforske nogle af de ting, der springer ud mod mig, når jeg ser på produkter som dette, og jeg bliver meget ophidset. Da jeg dobbelt kontrollerede mine hjemmearbejde, for ligesom Dr. Robin Bloor nævnte før, så er han, som jeg også, har sporet dette i nogen tid, og jeg kan huske, at jeg så på dine spec krav her om dagen og tænker, faktisk, denne ting løber meget læner sig, hvad det faktisk gør. Og jeg tænker fra hukommelsen - korriger mig, hvis jeg tager fejl, jeg tror, det var ligesom så lidt som en bærbar computerpræstation komfortabelt ville køre DBwartan, og alligevel var det i stand til at køre nogle temmelig betydningsfulde database-bagenden. Og jeg var ret interesseret i at se, at du også havde Firebird nu og Greenplum. Jeg var ganske imponeret over kravet eller specifikationen af den hardware, der bogstaveligt talt kunne køre som et gig RAM på en en gigahertz CPU. Det var ret imponerende.
Men brugssagerne er noget, som jeg gerne vil gå i dybden med. Ser du, at optagelsen af produktet er et behov for et behov på grund af eksisterende miljøer, der netop er blevet ude af kontrol, eller ser du, at folk nu er lidt mere proaktive og siger, du ved, vi bygger noget meget stort, det er komplekst. Og jeg overvejer fusioner og erhvervelser for eksempel her, hvor en organisation måske køber en masse firmaer - små, mellemstore, store, uanset hvad - og ender med at arve alle disse miljøer og skulle bygge en ny DB-kapacitet. Hvad er de typiske brugssager til dette for så vidt angår organisationstype og typen af applikation til det? Er det overvejende mennesker, der har eksisterende miljøer og bare skal rydde op og få kontrol over dem, eller er folk lidt mere proaktive og tænker over kompleksiteten, de er ved at opbygge og får dig om bord tidligt?
Scott Walz: Vi ser mere på at komme tidligt af netop den grund, du nævnte, konsolideringen. Med bredden af platformstøtte, som vi har, er det ikke total fremtidssikring, ikke sandt, men det sætter dig og dine DBA'er i en rigtig god situation, at når de ser på et potentielt erhvervelsesmål, ret, er de lidt mindre, ved du, tanken om, hvilke platforme kunne være, vi arver, ikke? Selvom det er vigtigt, ikke sandt, er bekymringen der lidt mindre end hvad det vil betyde for vores DBA'er, ikke? DBA'erne har et produkt nu, hvor de ved, at de kan oprette forbindelse, og hvis de er fortrolige med at bruge produktet, bliver de fortrolige med at oprette forbindelse til den platform, de netop har erhvervet. Så det er bestemt et område, vi ser, igen ved du, længe, kunderne med denne mash-up af alle disse platforme, ikke? Hvordan skal jeg få fat i dette, ikke? Og de har prøvet det, fordi tankeprocessen er, at hver af platformene har et værktøj, ikke? Vi kan bruge vores eget værktøj, ikke? Men det kommer til sidst tilbage, at du ved hvad, ja du kan, men ikke kun bliver jeg nødt til at lære hver af platformene, nu lærer jeg hvert af de værktøjer, der følger med hver enkelt af platforme og så du har lige forstærket jobbet med en DBA. Så vi ser også den situation, hvor de kommer tilbage til os og siger: ”Du ved, vi er nødt til at få vores hænder rundt dette. Lad os få et værktøj til DBA, fordi jeg har vigtigere ting for DBA at gøre, end at lære UI for et nyt værktøj. Eller forskellige værktøjer. ”
Dez Blanchfield: Ja, nej bestemt. Og ved du, når du ser, tror jeg fra hukommelsen, da jeg kiggede på i går bare for at dobbelttjekke, at jeg ikke var forkert, jeg kan huske, at du f.eks. Havde støttet Sybase, så denne ting har eksisteret i et lille stykke tid. Der er et andet spørgsmål, jeg havde til dig faktisk bare - ja, det er dejligt at have Greenplum og Firebird på din liste, men din Sybase, den slags aldre meget hurtigt, der viser, at den har været i et stykke tid og gjort et godt stykke arbejde.
Klynger. Så en af de største hovedpine for en DBA er, at de i det væsentlige vil pege på, hvad der ligner en IP-adresse og en masse API'er, eller om det er JDBC eller LDBC eller hvad vi måtte tale med, men bag det er der en klynge. Hvad kan, eller ved DBwartan, hvad der er bag døren nummer et, som det var, som når jeg tilslutter databasen bagenden, får jeg at se alle miljøerne bag der, og især, så der er to dele til spørgsmål, måske. Klyngen, for eksempel, når du tænker over, ved du, du understøtter IBM DB2 og Microsoft SQL-databaseserver og MySQL og PostgreSQL og Oracle og nogle af disse traditionelle RDBMS'er, og du ved, altid at vi kører en master-slave eller master-master miljø for redundans og høj tilgængelighed og også ydelse. Ved DB DB at der er noget bag dør nummer 1, der ikke kun er en database i sig selv, men en klynge, og i bekræftende fald, hvad ved den derom? Og at flyde ind i det hurtigt, så du kan svare på det samme spørgsmål, undskyld. Så bag klyngerne i nogle af de scenarier, du har, hvordan klarer folk sig med blandingen mellem produktionsmiljøer og katastrofegendannelsesmiljøer, så vidt DBracyans brug går?
Scott Walz: Fantastiske spørgsmål. Jeg vil give dig, der vil være betinget af de specifikke platforme, for så meget som vi prøver, vil vi have forskellige niveauer af støtte til nogle af disse dybdegående, de dybere nedefunktioner. For for eksempel Oracle og deres RAC-miljø, Real Application Cluster, kan du oprette forbindelse til den primære node i den klynge, men alligevel gå igennem databasemonitoren, som jeg viste, vi vil lade dig se SQL køre, og vi ' vil jeg faktisk fortælle dig, hvilken knude i klyngen den kører på, ikke? For at lade dig se nøjagtigt, om, du ved, langsomt kørende forespørgsel, lad os holde øje med det, hvilken node kører den på? Fordi uundgåeligt hele grunden til klyngen, ret, er for slutbrugeren, er han ligeglad med, hvor det er blevet udført, men for DBA er vi nødt til at holde styr på den type information. Vi er i stand til at gå ned til det detaljeringsniveau i Oracle, for eksempel. De andre platforme, som vi gør, har forbindelse, sandsynligvis ikke så meget detaljer, end vi gør for Oracle.
Med hensyn til produktion og udviklingsmiljø er det et godt spørgsmål. Vi giver samme niveau af støtte. Den virkelige primære måde, vi kommer til at hjælpe på, forbindelseslaget vil være der, ikke? Vi vil være i stand til at oprette forbindelse og udføre alle funktionerne. Jeg har kunder, der bruger nogle af funktionerne i DBwartan til at kategorisere deres datakilder, ikke? Og igen kan dette være lidt væk for det nøjagtige spørgsmål, du stiller, men vi vil gøre det muligt for dem grafisk at angive, mens de arbejder. Fordi det er en af tingene ved DBwartan, er det, at jeg hurtigt kan skifte mellem datakilder. Og den næste ting, du ved, at jeg gør mig klar til at køre en trunker erklæring, og jeg ser efter, om jeg er tilsluttet - kørte jeg netop dette mod produktion eller udvikling? Og så leverer vi nogle funktioner i DBwartan til at hjælpe DBA'erne derude såvel med at styre det og holde dem ude af problemer, hvis du vil, med nogle af DBA-aktiviteterne.
Dez Blanchfield: Med det i tankerne, på den lange liste med platforme, du i øjeblikket understøtter, og jeg er sikker på, at det snart vil eksplodere af åbenlyse grunde. Jeg mener, du understøtter ligesom f.eks. DB2 på z / OS for eksempel på mainframe, og så understøtter du åbenbart dem, som vi plejede at kalde mellemklasse, men nu bare UNIX-systemer, og slags mere moderne platforme, du ved, Linux og derefter til sidst overføres det til Bluemix og Cloud Foundry, så du ender med at DB2 kører på Cloud Foundry på Bluemix, med IBM og skyen på soft. Kører folk i øjeblikket ikke kun styring og overvågning, men også nævnt før evnen til at migrere og flytte data rundt. Ser du folk hoppe i sengen med DBwartan og siger: ”Ved du hvad, vi har en masse ting på de gamle mainframes, som vi bare har brug for for at komme af, og det var en rigtig besvær at gøre det. Hvis jeg kan pege, klikke og trække herfra og hen, kan jeg faktisk flytte og migrere mine data og mit skema. ”Er det en ting, som folk gør?
Scott Walz: De bevæger sig virkelig, ikke? De flytter dataene væk, ikke? Nu bruger de DBbrevan som et værktøj til det. Gør det alt for dem? Nej. Vi begynder, du ved, træk og slip, ikke nøjagtigt der, men vi gør det muligt for dem at generere nogle scripts, fordi du ideelt set vil ønske at bruge - du ønsker ikke, at dette job skal være kører på din klient, på din bærbare computer, netop af den grund, du nævnte. Vi kan køre på et meget lavt fodaftryk, ikke? Vi hjælper dem med at generere scripts og derefter vende det rundt og bygge det, og så kan de levere det script over og få det kørt på serveren, ikke? Og få magten, hestekræfterne bag serveren til at gøre det. Vi hjælper dem med at generere nogle af deres job til at udføre noget af det arbejde.
Dez Blanchfield: Right. Et par sidste til dig, og så kan vi muligvis cirkle tilbage. Det, der virkelig ramte mig, var at gå gennem dit tillæg, hvilket er fantastisk, og faktisk ville jeg ønske, at vi havde endnu en time til at gå nærmere ind på. En rigtig stor udfordring for DBA'er, ikke desto mindre, er grundlæggende overholdelse, generel styring af infrastrukturen, revisionerne, rapportering om den aktuelle tilstand, se på fremtidig præpping af ting som, du ved, bare generel vækst i miljøet. Det slår mig, at selv om det i kernen af, hvad dit produkt ser ud til at gøre, som bare gør livet let, den ene rude af glas, enkelt syn på verden, og jeg i det væsentlige kan klikke og pege og trække, og jeg elsker det faktum at jeg kunne træne nogen til at gøre dette meget hurtigt nu, de behøver ikke at læse manualen som den var. Det slår mig, at værktøjet også giver mig evnen til at gøre en hel masse ting omkring regeringsførelse og overholdelse og revisioner, som jeg spekulerer på, om folk rent faktisk er blevet vågnet op til, det er jeg sikker på, at de har.
Men ser du folk nu se på det og gå, og det er som dette eureka, a-ha øjeblik, der går, “Hej, ved du hvad, dette gør DBAs liv virkelig let fra nu eller lettere fra et operationelt synspunkt eller udviklingssynspunkt. Men god, vi kunne faktisk bare rapportere om alle vores databaser nu og alle datasættene og alle de indholdsløse data og alle metadataene omkring. Som hvem der har adgang, når de har adgang, hvorfor de har adgang, og hvilken type adgang de har. ”Og så pludselig adresserer nogle af udfordringerne omkring overholdelse. Især når vi har nogle virkelig store ting, der sker omkring dataforbrud. Vi har nogle fantastiske ting som de globale finanskriser, alle disse udfordringer kommer til, men hvordan i alverden skal vi måle og overvåge og tackle overholdelsen? Er det den slags store ting for mennesker endnu, eller er det stadig, slags, tidlige dage, så vidt det gælder DBarusan på det?
Scott Walz: Jeg har kunder, der ikke kan sige nok om DBbrevan. Nu er det dem, der har indset det. Pæren er gået. De siger: ”Vent et øjeblik. Jeg kan svare og svare og generere nogle af de meget rapporter, du har nævnt, rigtigt, alt sammen fra et værktøj. Jeg har det. ”Nu er der andre, der endnu ikke er ved at gribe ind i det, og det kan være af forskellige grunde, ikke? De er muligvis endnu ikke, eller måske bliver det håndteret af nogen anden, men vores kunder, som vi har fundet, der bruger det, det er et a-ha øjeblik, ikke? Det er ikke kun jeg i stand til at skabe en tabel med alt dette. Og med alle overholdelseskravene er det enormt. Det er et job i sig selv.
Dez Blanchfield: Ja, ja. Og du ved, jeg mener, fra toppen af mit hoved tænker jeg straks, ved du, hvis der er nogen, der kommer med og siger, at de ville oprette en konfigurationsadministrationsdatabase, CMD, hvis de skulle opfylde alt fra Sarbanes -Oksley til COBIT til ITIL, du ved, SWIFT-overholdelse og bankvirksomhed, endda gå ned til dem som den internationale standardiseringsorganisation, ISO 27001, 27002. Det er alle disse rigtig store rammer. En af udfordringerne er bare at finde, hvor dataene er, hvem der administrerer dem, hvilket format de er i, og jeg tænker, det har for mig, ligesom for mig bare se dem nu, hvor eureka øjeblik lige gik ud, det var som, hænge på et sekund kunne jeg smide dette ind på endda en person, der ikke nødvendigvis er en DBA, men jeg kunne hurtigt træne ham op og sige: ”Der er et compliance-værktøj.” Jeg synes, det er dejligt, at det gør sit job i en administrationsdatabase. ledelsesverden.
Men jeg sidder her og tænker, gud, du ved, det faktum, at du kan administrere flere platforme som en i disse dage, og du kan dykke helt ned i, som du sagde, logge de transaktioner, du udfører. Du ved, forestil dig at tage dette værktøj i en dataovertrædelseshændelse, og du har fået dit sikkerhedsteam til at løbe rundt for at finde, hvad der er, hvor og hvorfor, og hvem har set hvad. Og når de bevæger sig rundt, er de nødt til at logge og spore enhver handling, de udfører, fordi de muligvis bliver en del af problemet, hvis de ikke ellers kan. Ja, jeg synes, det er en utrolig kapacitet her, at du ved, du straks kunne begynde at gøre, ved du. Især når vi ser på udfordringerne ved dataanalyser, du kender, har vi dette enormt som en funktionskryp, som det var, med datasæt og data.
Og en af de ting, vi har talt om i et andet par shows, vi har lavet, er, du ved, hvordan går du og finder dine data, og ofte taler vi om det faktum, at når du starter i en organisation, har du en tendens til stå op i dit skab og læg hånden i luften og vink og gå, ”Ved nogen, hvor denne database er? Hvordan kommer jeg til denne datakilde? Hvor er denne fil? ”“ Gå og spørg modtagelse. ”Ikke? Dit værktøj kan straks give den mulighed for at finde ting og opdage dem og endda rapportere om dem.
Tilbage til et af spørgsmålene bare kort, og så skal jeg pakke op og give mig tilbage til Eric. Det slår mig, at skalaen bliver en udfordring i de næste 12 måneder for dig. Kan du give os en vis indsigt, lige ved et 30.000 fods synspunkt, antager jeg, i den skala eller det skalaområde, som DBwartan er kommet til at arbejde på. Jeg kan forestille mig, at når jeg lægger dette på min bærbare computer, og jeg rykker op, og jeg peger det mod et miljø, kan jeg opdage det, og jeg kan begynde at gøre ting på det. Jeg kan forestille mig, at det går fra en lille, lille kendt open source-databasemotor med et par rækker og borde. Hvilken skala ville det gå op til? Du talte om DB2 på mainframes, det er stort. Og klynger. Hvad er skalaen, som vi kan sortere her? Og Robin blev berørt af det tidligere, men jeg bliver bare nødt til at komme ind på det lidt mere detaljeret for hvor stort vi kan få med DBwartan.
Scott Walz: Sure. Der vil bestemt være dine udfordringer, fordi det er et klient stykke software. Og så igen, hvis jeg arbejder på en mainframe, når jeg arbejder imod vores testsystem på den mainframe, som vi har, kan jeg pege det mod millioner af rækker og lave et krydsforbindelse mod millioner af rækker. Alt arbejde skal udføres på en server, ikke desto mindre, fordi vi videresender denne kommando, og det er bare et spørgsmål om, hvor DBbrevan håndterer resultatsættene, ikke? Og så er det udfordringen, og det er skønheden, rigtigt, hvad vi laver. Det meste af tunge løft sker på serveren. Vi håndterer bare alle resultaterne. Og så, igen, kommer du selvfølgelig i situationer, når du vil køre ti forespørgsler samtidig, som alle returnerer millioner af rækker, ja absolut, du kan måske finde dig selv i en eller anden præstation der, ikke? Men på ingen tid har jeg kunder, der holder sig væk fra at køre store forespørgsler mod DBwartan, ved du, mod deres database. Igen, som jeg sagde, varierer kilometertal afhængigt af en masse faktorer, rigtigt, men igen, som jeg sagde, har jeg med millioner af rækker at komme tilbage, og så længe det fylder gitteret, ved du, jeg ' m klar til at gå. Men nogle gange er jeg selvfølgelig nødt til at vente på, at resultaterne kommer tilbage.
Dez Blanchfield: Jeg har et spørgsmål til dig, før jeg går sammen, fordi jeg har taget for meget af din tid og tak for det. Bare fortæl os lidt mere rundt, ved du ved at læse de nyeste specifikationer i går bare for at sikre mig, at jeg var på tværs så godt som jeg troede, jeg var. Procesovervågning og slags advarsler og underretninger, du ved, kapacitetsplanlægning bringer alle de massive problemer med DBA'er op, hele dagen hver dag, ved du. Skal nogen udfylde denne tabel, vil han udfylde databasen, skal de udfylde den diskplads, jeg har, hvordan administrerer jeg den? Giv os en hurtig gennemgang af slags procesovervågning og især overvågning af advarsler og derefter ideelt omkring kapacitetsplanlægning. Jeg tror, det er et område, som jeg tror, der kunne være en masse interesse i.
Scott Walz: Processovervågning viste sandsynligvis, at den funktion, som hovedparten af vores kundebase bruger, og det er en databasemonitor for at kunne vise og gøre det. Og vi har nogle i analytikeren. Performance Analyst har nogle advarsler, som du kan indstille, når visse tærskler overholdes. Det kan advare dig. Måske X antal logfiler, fejl i logfilen, ved du, det vil få en advarsel for dig. Bordplads rammer en vis procentdel fuld, du kan få en anden advarsel. Og det smukke ved det er, er du i det samme værktøj, højre, det er en del af DBwartan, så du bare højreklikker på fejlen, alarmen, og du administrerer med DBwartan, og det tager dig lige til redigeringen af tabelpladsen . Og du kan løse problemet lige der.
Hvad angår kapacitet, er det absolut en varm knap, og kapacitetsanalytiker, som vi har i øjeblikket, er portet til SQL Server, Oracle, DB2 LUW og Sybase ASE. Og det gør nøjagtigt, hvad du beskrev. Du kan starte, når vi først har fået nogle samlinger, ikke desto mindre, og når vi først har fået en prøvestørrelse, og måske dens rækkestørrelse, måske dens antallet af objekter, masser af muligheder inden for værktøjet, og så kan du begynde at være trend, ikke? Og hvordan ser det ud om seks måneder? Hvordan ser det ud om tolv måneder? Jeg kan trend til, bare trend til en dato, eller jeg kan trend til en værdi, ikke? Og et eksempel, du havde, jeg har X mængde diskplads, baseret på det, hvornår skal jeg ramme den grænse? Baseret på den vækst, jeg har, og disse samlinger, som jeg har gjort, hvornår skal jeg ramme den grænse? I det mindste ved jeg, at jeg kan begynde at planlægge for det. Blir det seks måneder, bliver det to år? Men igen kan vi bruge kapacitetsanalytikeren til at udvikle sig mod det.
Dez Blanchfield: Det er fantastisk. Fantastisk demo. Jeg nød det virkelig. Jeg vil vende tilbage til Eric, fordi jeg ved, at der er et par spørgsmål, der er dukket op fra vores fantastiske publikum i dag. Tak så meget, det har været virkelig dejligt at lære produktet godt at kende, og jeg ser frem til at holde et meget tæt øje med det.
Eric Kavanagh: Okay godt. Vi har et par gode spørgsmål. Og vi går lidt efterhånden, så vi vil prøve at slå hurtigt sammen, for jeg ved, Scott, du har et lukket hårdt stop. Her er et stort spørgsmål. Hvad med at arbejde på gamle datalagre som VSAM og Model 205, IMS og IDMF og den slags ting? Ser du det meget ofte i disse dage, og hvor godt fungerer det?
Scott Walz: Jeg vil ikke fortælle dig, at du sidder fast. Nogle af disse miljøer, hvis de har ODBC eller JDBC, og jeg ved, at nogle af dem er derude, kan vi oprette forbindelse til det, og du kan arbejde med det på den måde. Men for det meste er den grønne skærm vejen til at gå stille.
Dez Blanchfield: Jeg elsker den grønne skærm.
Eric Kavanagh: Nå, du ved, som Dez påpegede med den ene dias, hvor han havde alle de forskellige applikationer og værktøjer, der er tilgængelige i dag, det er en meget skræmmende virkelighed for alle, der ønsker ansvarligt at udføre funktionen af en databaseadministrator. Og jeg gætter på, at I over tid kan fyre bygge stik til et af disse værktøjer, når og når kunderne kræver, og så videre, ikke? Så du aktiverer den eneste rude af glas.
Scott Walz: Og det var den store nøgle bag at gøre DBwartan udstyret til at kunne håndtere disse JDBC- og ODBC-forbindelser. Vi har virkelig udvidet det nu. Nu, så længe vi har den forbindelse, lige så længe vi har denne driver, kan vi oprette forbindelse og arbejde imod den.
Eric Kavanagh: Det er gode ting. Nå folkens, vi arkiverer alle disse til senere visning. Jeg lavede et link til diaserne, forhåbentlig kan du se det via SlideShare. Tak så meget for alle dine bestræbelser, herrer. Vidunderlig webcast i dag igen. En masse gode lysbilleder. Meget godt indhold. Jeg elskede den demo. Det er virkelig slags interessant, at I fyre har målrettet et meget søde sted på markedet, fordi der er en sådan eksplosion af databasetyper i disse dage. Og vi har bare brug for som ledere et sted at håndtere alt dette. Godt gjort, fyre. Vi henter dig i morgen til en anden Hot Technologies. Forhåbentlig har du skåret en time i morgen. Samme tid. Samme station. Vi henter dig næste gang, folkens. Pas på. Hej hej.
