Av Techopedia Staff, 24. august 2016
Takeaway: Vert Eric Kavanagh diskuterer databasetrender med Dr. Robin Bloor, Dez Blanchfield og Scott Walz i denne episoden av Hot Technologies.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Mine damer og herrer, hei og velkommen tilbake til det hotteste showet i verden av bedrifts-IT, Hot Technologies i 2016. Ja, ja! Mitt navn er Eric Kavanagh, jeg vil være din vert i dag for et show med tittelen "The Art of Synlighet: Enabling Multi-Platform Management, " ja, ja. Noen få raske notater, det er et lysbilde om dine virkelig, riktignok fra fem år siden og nok om meg, slo meg opp på Twitter @Eric_Kavanagh. Året er varmt, dette er vårt vanlige lysbilde for Hot Technologies. Det vi gjorde med dette showet, var at vi ønsket oss et program som ville hjelpe oss med å definere en bestemt type teknologi, så hele ideen er at vi får to analytikere som kommer inn og gir sitt tak på et bestemt rom eller en bestemt type funksjon som bedriften trenger, og så kommer leverandøren inn og demonstrerer hva de har bygd og forklarer hvordan det stemmer overens med det du hører fra analytikerne.
Og grunnen til det, som du kanskje forestiller deg, er fordi det i verdenen av markedsføring av bedriftsprogramvare er det termer som blir båndet om og det som alltid skjer, er at leverandører tar seg til det siste hot term, ting som big data eller analytics for eksempel, eller til og med SOA eller forskjellige uttrykk som plattform, og noen ganger er disse ordene veldig nøyaktige for en bestemt teknologi, og noen ganger er de ikke det. Dette showet ble designet for å virkelig hjelpe oss med å artikulere for deg, publikum, hva spesifikke typer teknologier gjør, hvordan de fungerer og når du skal bruke dem.
Med det skal jeg introdusere foredragsholderne våre. Vi har vår helt egen Dr. Robin Bloor, som ringer fra hans beliggenhet i Austin, Texas, Dez Blanchfield, som ringer fra den andre siden av planeten, og vår gjest Scott Walz som ringer inn fra Kentucky. Og din, jeg er faktisk utenfor Pittsburgh, så vi har en helt geografisk organisasjon i dag fra flere forskjellige steder. Med det kommer jeg til å skyve Robins første lysbilde, gjerne stille spørsmål forresten, folkens, ikke vær sjenert. Du kan gjøre det ved å bruke spørsmål og svar-komponenten på webcast-konsollen. Og med det skal jeg overlevere det til Dr. Bloor. Gulvet er ditt.
Robin Bloor: Ok, takk for introduksjonen, Eric. La meg bare komme til det første lysbildet. Dette er en samling av meerkats som tenker på database. Hele presentasjonen som jeg gjør her, er egentlig bare et generelt sett med tanker om databasen som jeg har hatt nylig, og poenget var at virkelig rundt år 2000 virket det som om databasespillet var over i den forstand at de aller fleste databaseimplementeringer skjedde på relasjonsdatabase. Og så endret det seg, du vet, alle disse tingene som meerkatene tenker på, kolonnebutikker, nøkkelverdibutikker, dokumentdatabaser, database i minnet, grafdatabase og en hel masse flere ting dukket plutselig opp. Og det var nesten som en ny type geologisk epoke som har fossiler av forskjellige slags dyr plutselig dukket opp.
Nyheten fra Lake Wobegon, det er virkelig over for databasen med en modell. Det er ingen tvil om at RDBMS fremdeles dominerer, men det er nå etablert andre typer databaser. Virkelig, det er ganske mye oversikten over hva jeg skal si her.
Dimensjonene til databasen, noen av disse ble faktisk viktigere nylig, men de som jeg kunne tenke på da jeg gjorde dette lysbildet, uansett, var det oppskalert i form av å bruke ressursene til en gitt server? Skala den ut slik at den kan gå over store klynger? Utnytter den maskinvaren som er tilgjengelig som er slags databaser i minnet som går i den retningen? Er det distribuerbart? Det er en rekke databaser som har størst betydning for variabilitet å distribuere. Hva slags egenskaper har det? Den grunnleggende SYRE-egenskapen til databasen. Men nå, i stedet for å ha faktisk konsistens, har en rekke databaser en endelig konsistens, folk bruker dem og de har ikke noe problem med dem, så de har vist at ACID ikke var absolutt nødvendig, bare en god ting å ha i en mange situasjoner.
Når det gjelder metadataorganisasjon, har hele spillet endret seg. Vi har forskjellige metadataorganisasjoner i stedet for et typisk RDBMS-skjema. Når det gjelder optimalisatoren, er det en god del optimaliseringsaktivitet på gang avhengig av datastrukturer du prøver å optimalisere. Når det gjelder håndterbarhet, er det mye varians i dette som jeg vil komme videre til senere, men i utgangspunktet er hele poenget med en DBMS håndterbar og igjen bestemmer omfanget av dens håndterbarhet til en viss grad omfanget av nytten.
Når det gjelder maskinvarefaktorer, er dette poenget som virkelig sier - jeg mener at det bare er et poeng som blir gjort her - poenget som blir gjort her er at hva vi ser på i dag når det gjelder databasearkitekturer kommer til å endre seg. Det kan være de samme databasene, men de må på en eller annen måte ta hensyn til hva som faktisk skjer på maskinvarenivå. I mange, mange år hadde vi denne relativt enkle situasjonen CPU, minne og spinningsdisk - vel, det er borte, egentlig.
Poenget som er her, først og fremst har vi CPU-er, men de er langt mer parallelle evner enn de hadde før med mange, mange forskjellige prosesseringskjerner. Vi har også fått GPU-er, vi har også FPGA-er, forskjellige typer silisium, men Intel har giftet seg med en FPGA med en CPU i den neste utgivelsen, og - OG - har giftet seg med GPU og CPU-er på samme brikke. Du har chips med forskjellige egenskaper. Fordelen med en GPU er at den virkelig er stor for tung parallellitet og spesielt med numerisk beregning. FPGA-er kan du på en eller annen måte sette koden på brikken, og den fungerer langt raskere enn hvis du bare mater den til brikken.
Det er en kryssavl av disse tingene som skjer. Vi har fått 3D XPoint fra Intel og PCM fra IBM, som er nye typer minne, som er tregere enn RAM, rimeligere enn RAM, men ikke-flyktige. Og disse skaper litt spenning blant en rekke programvareleverandører som jeg har snakket med. Vi har SSD-er, men nå blir de veldig, veldig store og gir parallell tilgang. Med parallell tilgang til en veldig stor SSD kan du nærme deg lesehastigheter som ligner på RAM lesehastigheter. Vi har denne muligheten for tre typer lagrings-RAM, 3D XPoint-ting og SSD-er, som alle vil gå ekstremt raskt. Og siden hastighet er essensen i databasen, vil all databaseteknologien prøve å utnytte disse så raskt som mulig. Og det kommer til å involvere og har vært involvert i parallellarkitektur, men utskilt parallell arkitektur. Ytelsen på maskinvarenivået akselererer hele tiden, har gjort i mange år, fortsetter å gjøre det, og de generelle kostnadene synker.
Sti av tårer. Dette er bare forskjellige forsøk på databaser, de første databasene før relasjon ble generelt referert til som nettverksdatabaser, så kom relasjonsdatabaser, så kom objektdatabaser, de fikk ikke mye trekkraft, så kom kolonnebutikkdatabasene som var relasjonsdatabaser gjort veldig annerledes. Og så hadde vi dokumentdatabasene og SQL-databasene som var objektdatabaser gjort annerledes, eller hvis du vil, den samme kolonnen med objektdatabaser og de fanget på. Og nylig har vi hatt grafdatabaser som får trekkraft og RDF-databaser. Og det du ser på der er minst tre forskjellige sett med datastrukturer som blir tatt imot. Den relasjonsdatabasen gjør tabeller og rader veldig bra. Dokumentdatabasen og objektdatabasene - de gjør vanskelig datastruktur, spesielt hierarkiske datastrukturer, veldig bra. Og grafdatabaser og RDF-databaser gjør nettverksdatastrukturer veldig bra. Og disse forskjellige, jeg tenker på dem som tre linjer, disse linjene kommer til å fortsette på ubestemt tid. Det kommer ikke til å stoppe fordi motorene som gjør disse tingene ikke fungerer spesielt godt på den andre datastrukturen.
Og så har vi den ødeleggende faktoren til Hadoop. Hadoop er ikke en database, men det er databaser som bruker HDFS som lagringsstruktur. Og mange ting Hadoop gjør, er den typen styring som må gjøres for en database. Verdt å nevne at Spark heller ikke er en database, men den har, og den er en umoden, men den har en SQL-optimizer, og derfor er den som en kjerne i en database uten nødvendigvis å vite hvor du skal lagre dataene, men hvis du stikker det på HDFS, oppfylles faktisk mye av databaskravet, ganske enkelt av funksjonene til det underliggende filsystemet. Spesielt gnister har blitt en del av databaseøkosystemet, og det er ofte samlet med kraftigere databaser, og grunnen til det er analytics. Analytics - Spark er, vel, det går veldig, veldig raskt på analytics. Analytics er den viktigste applikasjonen som folk flest investerer i akkurat nå, så de to går litt hånd i hånd. Dataføderasjon snarere enn konsentrasjonsregler, bør det slags være åpenbart av det faktum at du har minst tre forskjellige behov, strukturerte typer databaser der ute, og derfor dataforening hvis du vil dele dataene mellom dem. Det er ofte nødvendig, men du har også databaser som skalerer ut, og databaser som ikke gjør det, virkelig kraftige motorer som Teradata eller Vertica har et veldig spesielt sted, men mindre motorer som kan gjøre veldig mye arbeid, så, føderasjon vil sannsynligvis være der i lang, lang tid selv mellom relasjonsdatabaser.
Den siste tingen å si, IoT, det er ikke over før den fete damen begynner å disgorging data. IoT kan godt skape på en eller annen måte en annen dynamikk i databaseverdenen og som vil komplisere ting enda mer. Forhåpentligvis vil det være - på en eller annen måte - det vil være en slags konvergens som skjer, men jeg ser ikke at det hele kommer sammen som det gjorde med de relasjonsdatabaser. Ikke noen gang snart uansett.
Og jeg tror det er alt jeg har å si, så jeg overleverer det til Australia.
Dez Blanchfield: Takk, Robin. Takk til alle for at du ble med, takk for at du hadde meg i morges, eller i ettermiddag. Dette er et veldig varmt tema fordi vi har opplevd en ganske eksplosjon det siste tiåret og litt, i mengden data vi må håndtere, og alltid at dataene ligger innenfor en form for system som i de fleste tilfeller er en database av en eller annen form. Jeg tenkte at jeg raskt ville ta oss gjennom en veldig høy grad av tur gjennom hvordan vi kom hit og problemet som blir skapt og hvilke typer ting vi trenger å løse nå, og så skal vi snakke om hvilke typer løsning som kan brukes på det. La meg bare ta tak i mitt første lysbilde her. Jeg er av den oppfatning at vi er på det punktet der DB admin 2.0, eller database admin 2.0, er slags der vi er slags nå, en gang var databaseadministratoren en ganske grei rolle og utfordring og du kan trene noen ganske raskt. I dagens verden er det ikke lenger tilfelle, og jeg skal vise deg hvorfor det er slik.
En gang i tiden ville en databaseadministrator være i stand til å koble seg til DB back end og gjøre en hurtigvisning-databaser, og det ville være en liste over databaser i systemet som de måtte være klar over, og de kunne veldig raskt komme over disse databasene og velg dem og ha litt av en poke og en sonde rundt og bruk oversett, beskriv tabell for å finne ut hva som er i en tabell og hver av kolonnene og radene, og det var en relativt grei utfordring, og hvis du leser gjennomsnittet to eller tre hundre sider bok om databaseadministrasjon for hver plattform, kunne du nesten lære deg selv uten å måtte gjøre en rakettvitenskap.
Men det er ikke lenger tilfelle, og grunnen til det, i mine tanker, er at det er altfor mange alternativer i databasesamfunnet for at enhver person kan være en ekspert hos en spesialist hos og å kunne administrere og administrere manuelt. . Og grunnen til det er at i løpet av de siste fire til fem tiårene når det kommer til en verden av servere og databasesystemer, databaseservere og applikasjonssuiter, har vi kommet veldig, veldig langt. En gang i tiden hadde vi stort strykejern som måtte takle det som effektivt var små data, og lattermildt lite når vi ser tilbake nå. Jeg så et skikkelig pent bilde på Twitter her om dagen, av denne fantastiske damen som var hovedprogrammerer og utvikler for NASA den gangen da vi satte menn på månen, og koden hennes ble skrevet ut i hundre og tretti- to kolonnelinjeskrivere og viftet, og den sto faktisk høyere enn hun var, mengden kode hun skrev.
Og når jeg tenkte på det, var jeg som, faktisk er det sannsynligvis omtrent to eller tre hundre megs data der hun måtte skrive det inn maksimalt, om ikke mindre. Og dermed var den totale datamengden for å holde koden hennes, selv om den fysisk sto høyere enn henne da den ble skrevet ut på papir, faktisk en veldig, veldig liten mengde. Selv disse massive datamaskinene i romstørrelse, og dette er et IBM System / 360 i akkurat dette lysbildet, datamengden den faktisk kunne inneholde var liten sammenlignet med dagens verden. Faktisk har smarttelefonene våre 60 og 128, og 256 spillejobber, og vi vil snart ha terabyte i telefonene våre før lenge når prisen på blitz synker.
Og så på den tiden og den tiden, var databaseadministrasjon ganske grei. Her er et øyeblikksbilde av en 3270 terminaløkt, og for en DBA, å kunne logge inn og se på antall filer som var relatert til databasen, og indeksene som var der og radene og kolonnene var greie. Og du kan se her i dette skjermdumpet, at konteksten til dette er en tabell og et antall tabellplasser, det ville vært hele hovedrammen som administrerte en databasetabell. Mens vi i dag har milliarder av rekorder i databasesystemer. Og endringen skjedde gjennom et skifte i teknologi som gjorde at vi kunne bygge databaseplattformer og datahåndteringssystemer.
Hvis vi tenker på den typen originale mainframes og mange datamaskiner som kjører database og til slutt relasjonsdatabaser, for så femti pluss år siden, og den store jernformen verden og de små datasettene vi hadde, da vi kom til åttitallet, vi var liksom på, vi gikk gjennom hovedbildene fra mini til mikro, og vi hadde PC-er som kjørte ting som dBase II og dBase III, og på DOS og CP / M, og vi hadde en veldig tidlig relasjonsdatabase- tilgjengelige stilteknologier, og de skalerte ganske bra sammenlignet med hva vi var vant til i hovedrammen. Da vi kom til nittitallet, hadde vi slike som Oracle og DB2. Og på slutten av nittitallet hadde vi mennesker, som hemmelige datamaskiner som kunne lime som en nettverksmodell, veldig, veldig store maskiner, maskiner i kabinettstørrelse sammen og ta slike og bygge disse klyngene datamaskiner. Men selv da var den fremdeles liten sammenlignet med hva vi ser i dag.
Men i lysbildet som jeg har kommet opp her, er dette Hadoop-klyngen og fungerer effektivt som en maskin, og egentlig er det bare en virkelig, virkelig stor datamaskin, og den kan inneholde typer webskala-data vi er vant til nå . Og slik har utfordringen med databaseadministrasjon, databaseadministrasjon på de forskjellige plattformene virkelig blitt, etter mitt sinn, rakettvitenskap. Du må være en ekstremt smart karakter for å kunne forstå teknologien den kjører på, plattformen den kjører på, dataene som er der, hvilke typer bruk av disse dataene. Og ja, vi så denne eksplosjonen fra begynnelsen av 2000-tallet, hvor vi hadde Microsoft SQL blitt en ting, Lotus Notes var ganske godt etablert og der ute, og antallet Lotus Notes-databaser som krøp rundt stedet var ganske skremmende. Og vi hadde de vanlige etablerte myndighetene til Oracle og DB2 og begynte virkelig å ta tak. Noen av merkene som begynte å forsvinne. Men vi gjorde fremdeles egentlig bare tradisjonell databaseadministrasjon helt fram til det punktet, rundt den slags 2006-æra der, hvis jeg går tilbake til det bildet av den klyngen, hadde vi det vi kalte Beowulf-klynger blitt en ting, der vi kunne ta PC-er fra hyllen og lim dem sammen og lag store supercomputere.
Men fra omtrent det punktet og framover krysset vi et vippepunkt der mennesker var i stand til å administrere databaser for gammel skole og - som jeg sier, etter mitt syn, ble skalaen veldig, veldig stor veldig, veldig raskt. Det er nesten som om vi hadde denne big bang-hendelsen innen teknologi som drev bruken av datateknologi og datastyringsteknologi og spesielt databasene rundt dem. Og fordi vi i virkeligheten bygde høykvalitets kalkulatorisk stilklynger for å være vert for data i forskjellige former. Og for å punktere dette punktet, her er et øyeblikksbilde av landskapet fra 2016 av databaseteknologier som er tilgjengelige for oss. Alt fra nedre høyre hjørne og åpen kildekode, helt til øverste venstre hjørne i infrastruktur. Og i øverste høyre hjørne i applikasjonsløsninger som er tilgjengelige for oss, og i nedre venstre hjørne, en blanding av infrastruktur og ytelsesmotorer som gjør analyse, og så videre. Og i midten er det selvfølgelig enhetene som smarttelefonene våre, som faktisk kjører på veldig små versjoner av databaser, for å gjøre ting som å administrere kontaktene våre og så videre, eller samtaleloggene og andre ting vi har.
Og så i mitt sinn var det denne eksplosjonen, som en kambrisk eksplosjon til den slags ting, hvor mengden teknologiutvikling som skjedde i løpet av den veldig korte tiden fra 2006 til 2016, som faktisk er et tiår, Som det var. Vi har nå sett grafdatabaser bli en stor ting, databaser i minnet blir en stor ting, SQL-databaser kommer med. Overgangen til forskjellige datamodeller, Hadoop ble til, vi hadde MapReduce-modellen, nå har vi Spark og streaming analytics og streaming datamaskiner, spenstige distribuerte data, rammer som folk må utvikle for dem, for å komme til skalaene vi trenger, og når vi tenker på den reisen, for å gå gjennom den slags, hva er de relasjonelle databasestyringssystemene med de vanlige mistenkte, Oracle, PostgreS, Sybase, IBM DB2, MySQL og Microsoft SQL Server-plattformen. Vi har sett noen nye barn komme på blokka nå, Clustrix, Xeround, NuoDB, MemSQL, og det er flere titalls flere som du så på det lysbildet før. Hvis du kunne forestille deg utfordringen med å måtte kjenne til disse plattformene, og kunnskap til å kjøre dem og få den eneste ruten med glassutsikt, som du trenger å være en DBA og gjøre disse tingene, er utfordringen langt fra triviell. Og så plutselig kom NoSQL-motorene som er en helt ny rase av morsomme utfordringer.
Og så er det endelige lysbildet jeg har her en slags den ultimate en-to-tre knockout-stansen, og det er at vi har tatt noen av disse teknologiene nå, og vi har skapt en servicefunksjon for dem, vi har lagt dem inn i skymodeller, og de er nå tilgjengelige som et verktøy, som en tjeneste, du kan i utgangspunktet få database som en tjeneste, og de vanlige merkene som vi ser der på Amazons Web Services og Googles Cloud Compute-plattform og Microsoft Azure er de som kommer til folks tankene, men det er faktisk titalls og dusinvis av skyplattformer nå. Og i Australia, for eksempel, er det noe som hundre og tolv selskaper som er i god tro, storskala offentlig sky som tilbyr databasetjenester i forskjellige former.
Å tenke på utfordringen som den gjennomsnittlige DBA har for å komme seg ut av sengen og gå på jobb og takle nå, er ganske en overveldende utfordring. Og derfor er jeg veldig opptatt av at vi som mange ting i livet har skalert opp de horisontale og vertikale, det er infrastrukturen som er skalert i en veldig horisontal, nesten lineær vekstmodell, og kompleksiteten i stabelen i en vertikal forstand, antall databaseplattformer, antall applikasjonsrammer og modeller vi må håndtere, har kommet langt utover hva mennesker skal være i stand til å takle i en enkelt rute med glassvisning og hva poenget nå med databaseadministratorer trenger et helt sett med nye verktøy for å kunne snakke med alle disse plattformene, mangle dem, administrere dem og støtte dem, og jeg tror det er hele temaet i samtalene våre i morges, eller i ettermiddag, og med det i tankene, Jeg skal overlate til gjesten vår som vil snakke mye om produktet sitt og hvordan det skal takle utfordringen.
Eric Kavanagh: Alright Scott, jeg kommer til å gi hånden -
Scott Walz: Tusen takk, ok, takk. Takk Dez, takk Robin, og takk til alle for at du ble med og hadde meg på samtalen i dag. Jeg vil takke Robin og Dez for at de tok meg med på en spasertur nedover minnefeltet, etter å ha vært på plassen siden begynnelsen av nittitallet, brakte dere tilbake mange gode minner. Minnet som jeg ikke så på noen av disse lysbildene og bildene, var hullkortene. Og det var den aller første tingen som ble introdusert for meg da jeg først begynte på den første jobben min på universitetet, kollegaen min i kuben ved siden av meg, ba meg om ikke å røre punch-kortene hans. Så ja, absolutt, og det har virkelig vært en utfordring, og en utfordring som vi har jobbet med å hjelpe kundene våre å ta tak i og siden midten av nittitallet, og dette er et produkt som jeg vil snakke om i dag. La oss ta en titt på multiplattformadministrasjonen, og dette er bare et delsett. Jeg valgte en graf, men som Dez la opp -
Eric Kavanagh: Du må dele skjermen.
Scott Walz: Å, det gjør jeg vel, takk.
Eric Kavanagh: Ingen bekymringer. Og folkens, ikke vær sjener, still spørsmål, vi har tre smarte bukser på samtalen i dag, så send dem de vanskelige spørsmålene. Du kan bruke spørsmål og svar-komponenten på webcast-konsollen, eller du kan tweete med hashtaggen til BriefR. Ok, Scott, ta den bort.
Scott Walz: Der går vi, takk. Jeg tok tak i dette lysbildet, og dette bildet. Bildet fra Dez sprengte meg virkelig fordi det er, det er virkelig den verdenen vi lever i i dag, og verden som DBA opptrer i. Og som de nevnte, det er ikke lenger du, egentlig, sliter med å kunne å gjøre dette med bare brute kraft. Du trenger virkelig verktøyene, og det er, vi kommer inn for å spille og vi ser hele bryteren, momentumendringen der den var tidlig og var veldig tøyset som du nevnte, og så gikk vi til å jobbe med flere databaseplattformer, så det var vårt første forsøk på verktøyene, og så var det tilbake til hvor organisasjoner, og etter år 2000 og når det snakket litt sammen. Med organisasjonene og ønsket å gå solid, men så kom det tilbake, og det blåste virkelig opp når du introduserte alle de nye plattformene. Og nå, i stedet for å bli pigeonholed til en bestemt plattform eller en bestemt teknologi, er det ingen av disse organisasjonene som finner ut hva som er best. Hva er den beste applikasjonsdatabasen, hva er den beste plattformen å bruke? Og med det sagt, vil jeg lede deg litt gjennom hva vi gjør med DBwartan. Og DBbrevan har vært vårt flaggskip-produkt som administrerer, som det sier plattformsmiljøer i over 20 år, og det er her vi bor, og det er her vi liker å understreke og samarbeide med våre kunder og gi dem verktøyene for å gjøre dem produktive og fremført.
La oss fortsette, så skal jeg hoppe rett inn. Jeg viser produktet mer etter hvert som jeg går gjennom lysbildene, og det tror jeg du også gjør. For de av dere som ikke har sett DBwartan før, ser vi på kompisen, og jeg tror Dez brukte betegnelsen “en enkelt rute med glass”, og det er noe vi er stolte av å gi DBA et enkelt blikk på alle plattformene deres. Helt riktig, ingen grunn til å åpne opp for noen annen applikasjon, vi kommer til å koble deg til og få deg dit og begynne å jobbe med plattformen. Ser vi på databaseutforskeren til venstre, kan vi opprette dette slik vi vil, vi kan organisere det vi vil. Og du vil se at jeg har en blanding, jeg noen av Oracle-serverne mine, jeg har MySQL, jeg har PostgreS her, jeg har også en - det er merkede produksjonsservere som noen inkluderer noen av MySQL-servermiljøet. Igjen, kan vi se akkurat der at vi har passet godt. Hvis jeg ser på å registrere en ny database, vil du se en av plattformene vi støtter, det er et par jeg vil ta opp. Du vil legge merke til når dette er din SQL, støtte for det, Teradata, Apache, PostgreS, her er generikkene som vi støtter.
Hvis vi har JDBC-driver eller LDBC-driver til noen av plattformene, er vi i stand til å koble deg, gi deg en forbindelse og tillate deg å jobbe med plattformen rett fra DBwartan. Igjen, la deg fokusere på jobben for hånden, og ikke hvordan du skal få det til. Gå gjennom alt det. Men jeg vil vise noen få ting om produktet. La i så fall åpne for at vi skal forholde oss til Oracle, for eksempel. Dette er bare den lille destinasjonssiden min her, men jeg vil gå og se på noen av skjemaene mine som jeg jobber med. Vi kommer til å trekke inn et av de større skjemaene, så igjen, så tar vi tilbake listen over tabeller. Akkurat, i dette tilfellet skal jeg åpne et bord, så vi skal bare velge dem, og det kommer til å føre dem opp i objektredigereren vår.
Nå er Oracle noe jeg har jobbet med i årevis, det jeg skal vise deg er sannsynligvis en enkel uttalelse for deg. Men hvis Oracle er plattformen, eller hvis PostgreS er plattformen, eller Teradata er plattformen du nettopp har fått, og du trenger å komme opp i fart, er oppgaven å legge til en kolonne. Eller kanskje oppgaven for hånden er å slette en kolonne. Men du ønsker ikke å bekymre deg for syntaks, ikke sant? Vi vil gå, bare skriv inn det vi trenger, sett det opp, og vi lar DBwartan generere. Her skal vi trykke "Alter." Det vil generere skriptet for oss. Igjen, et veldig enkelt eksempel, men poenget er at det kommer til å gjøre jobben for oss for å generere og plassere denne kolonnen i tabellen.
Det vi imidlertid også kan gjøre er å flytte kolonner rundt i tabellen. Hvis du noen gang har prøvd å gjøre det med det tradisjonelle, er det litt mer komplisert enn bare en enkelt kodelinje som dette. Men igjen skal DBbrevan jobbe bak kulissene, generere koden for deg og igjen produsere SQL. Vi stenger herfra. Før jeg gjør det, legger jeg merke til alle fanene over toppen igjen, brukergrensesnittet er veldig intuitivt. Hvis jeg kommer inn i utforskeren, hvis jeg hopper ned til PostgreS, ikke sant? Hvis jeg går inn i skjemamodusen min der, ser på bordet, veldig likt utseende og preg, ikke sant? Vi åpner dette, igjen får vi se informasjonen her. Egenskapene, forfedrene, kolonnene. Vi er spesifikke for plattformen, vi kommer til å gi deg dette, brukergrensesnittet, for å kunne vise dette og å jobbe med objektene. Du kommer til å vite hva du trenger å gjøre, og det vil gjøre det mulig for deg å gjøre det på en effektiv og betimelig måte, slik at du ikke trenger å bekymre deg for nøyaktig hva som er klausulen som trenger å gå dit for å gi det alternativet. Vi tar vare på det for deg.
Når vi ser på det, skal jeg hoppe til SQL Server nå og snakke litt om noen av de andre funksjonene, så vi trenger alle å overvåke databasen. Så igjen, start det opp, la oss se alle økter som skjer, økter som kjører. Hvordan skal vi se hvilke uttalelser som blir utført og kunne ha kontroll over det? Må vi stoppe en økt? Må vi se noen låser som kan være i databasen? Noen blokkering av låser? Igjen, vi har all den informasjonen her til fingerspissene for at vi raskt kan reagere, iverksette korrigerende tiltak om nødvendig og snu den. Vi kommer tilbake til utforskeren vår. Det er her, dette er drivpunktet, det er her jeg alltid kommer tilbake til, det er her jeg personlig liker å få ting i gang og jobbe herfra. Da jeg er koblet til en SQL Server-database for å se på verktøyene. Fordi vi er plattform, kan vi begynne å se på utdrag, migrasjoner. Vi kan bevege oss over plattformer hvis vi trenger å migrere objekter fra en plattform til en annen, kan vi gjøre det, forutsatt at disse objektene finnes på de forskjellige plattformene. Pakk ut skjemaene, publiser til rapporter, last inn og last av data og sikkerhetskopier databaser.
Igjen, alt det fra UI. Og når du kommer hit til verktøyene, kan du se et komplett sett med verktøy som vi kan betjene fra, ikke sant? Fra "Finn i filer" kan vi gjøre et komplett databasesøk der vi leter inne i systemtabellene for å finne den strengen du søker etter. "Skrift og fileksekvering", hvis du har en standarderklæring som kan kjøres mot flere plattformer, flere datakilder, kan vi sette det opp rett fra en DBwartan som peker mot målene vi ønsker at den skal kjøres mot. Trykk på "Gå", og det vil løpe og bringe oss tilbake resultatene mot alle disse måldatakildene. La deg jobbe fra den ene glassruten igjen.
Og "Analyst Series, " igjen, de er mer dyptgående. Disse er mer rettet mot relasjonsdatabaser når vi begynner å komme inn på flere av de nyere plattformene. Du vil også se oss utvide denne funksjonaliteten til disse arenaene. Og generelt bare mange forbedringer av brukergrensesnittet. Funksjoner rettet spesielt for DBA. Elementer som vi har muligheten til å gjøre et skriptbibliotek. Disse SQL-skriptene som du kjører ofte mot flere plattformer, lagrer det her, dra det, så snart vi har satt opp et nytt ISQL-vindu, kan vi bare dra inn skriptet, og vi har nå skriptet klart til å gå. Igjen, å ha det til hånden for å være i stand til å gjøre og klare seg. Du vil legge merke til at vi leverer med skript som allerede er definert for noen av plattformene, slik at vi kan fortsette og lage så mange vi trenger når som helst.
En fin ting som jeg liker og mange av våre kunder gjør, hvis du noen gang er interessert, og jeg får dette spørsmålet mye med hensyn til, “Hvordan gjør jeg det? Det er ganske kult. Hvordan gjør DBwartan det? "Det er en liten funksjon her, " Logfile, "du kan logge alle SQL-setningene som vi utfører, så hvis du vil vite hvordan vi fyller den undersøkende eller hvordan vi fyller redaktøren for en PostgreSQL-tabell eller en Teradata-tabell, logg inn SQL, så registrerer vi alt som DBbrevan kjører mot databasen, og du kan komme tilbake og se på den SQL og ha alt vi trenger. Kanskje du vil innlemme det som en del av et av skriptene dine. Absolutt. Helt greit.
Vi liker å være veldig gjennomsiktige med hva vi gjør og hva vi utfører mot databasen. Derfor vil vi la deg lagre og registrere alt vi bruker på databasen. Vi har konfigurasjonsalternativer også. Du vil merke at jeg har den satt opp som "Organisering av objekteier." Jeg kan også konfigurere etter "Objekttype." Hvis jeg kom inn i PostgreSQL-miljøet mitt igjen, gikk jeg inn i ordningen hvis jeg så på SQL-ene i stedet for bare GIM-tabellene mine som tilhører det skjemaet, jeg skal se alle tabellene, uavhengig av skjemanavn. Igjen forskjellige måter å organisere ting som virkelig tilpasser det for din egen arbeidsflyt og hvordan du ønsker å se det.
Og det siste jeg vil snakke om, er muligheten til å stille inn "Bokmerker." Hvis jeg driller inn, hvis jeg jobber på en av plattformene mine og jeg vil fokusere på bare tabellmodus, kan jeg legge til et bokmerke. Jeg vet, en veldig enkel funksjon, men så fin å ha, spesielt når du jobber med så mange datakilder og så mange plattformer som dagens DBA er. For å kunne komme inn i systemet, start opp DBbrevan og la bokmerkeansvarlig ta deg rett til stedet i treet der du trenger å være og kunne jobbe. Og så herfra kunne jeg lage et nytt bord, og igjen, på plattformene som vi støtter som du så tidligere, og vi kommer til å lede deg gjennom “Wizard” for å la deg kjøre og utvikle og lage tabellen. Og vi kommer til å generere all syntaks som er nødvendig for å gjøre det bak kulissene for deg og deretter presentere det for deg på slutten i en forhåndsvisningsrute. Du kan komme til å validere, se nøyaktig hva vi skal generere. Du kan trykke på "Utfør" -knappen, deretter på "Fullfør" -knappen, la den utføre. Eller du kan lagre det eller skyve det av til et annet ISQL-vindu, så lag det igjen, kanskje det må være en del av et større, et større skript som du vil lagre og distribuere i løpet av batchvinduets timer.
Det er en oversikt over DBbrevan. Når vi snakker om det, igjen, er det et produkt som har sett mange plattformer, støtte for disse plattformene og god brukeropplevelse, gode tilbakemeldinger fra våre kunder også. Og hvis du er interessert, som en av paneldeltakerne, men hvis du trenger å finne noe IDERA-relatert eller DBwartan-relatert, kan du gjerne nå ut og du kan absolutt finne meg på e-postadressen min.
Eric Kavanagh: OK, jeg antar at jeg vil åpne den for Robin for spørsmål og deretter Dez, og så overvåker jeg spørsmål og svar fra de fremmøtte. Robin, ta den bort.
Robin Bloor: Ok, vel, det første spørsmålet, jeg har faktisk vært kjent med DBwartan en god stund, så jeg er litt klar over dens evner. Det jeg vil være interessert i at du tar opp er dens, slags fremtidige stier herfra. Jeg mener, jeg skjønner, du vet, sist jeg så på det, må det ha vært lenge siden. Jeg ser at du støtter minst tre databaser som jeg ikke visste at du støttet før. Hva er fremadstien for DBwartan? Er det sannsynlig at du bare vil legge til flere og flere databaser, eller er det en tingutvidelsesgreie? Hvor har du tenkt å gå med det?
Scott Walz: Det er et flott spørsmål, og jeg vil gjerne ha alt det ovennevnte. Vi kommer til å fortsette å bygge ut fordi de tradisjonelle RDBMS-plattformene ikke sitter stille, ikke sant? De fortsetter å bygge ut. Vi vil fortsette å følge den veien. Og så vil du se oss begynne å se og gå i den retningen om å støtte netto nye plattformer. Fordi vi erkjenner at selv om noen av disse plattformene fortsetter å vokse, den tradisjonelle RDBMS, er det visse situasjoner som de nye plattformene er de rette plattformene for kundene å gå med. Vi følger virkelig med på det markedet, på det segmentet og prøver å ta de riktige beslutningene om hvilke plattformer vi skal gå til. Det ser ut til at de endres praktisk talt hver dag.
Robin Bloor: Det er som både jeg og Dez sa, det er et veldig livlig marked, er muligens en måte å se på det. En annen ting jeg ville være interessert i - tydeligvis vil du ikke være i stand til å svare på dette spørsmålet nøyaktig, men jeg har kommet over nettsteder i min tid der det er tusenvis av tilfeller av Oracle, og Oracle var ikke den eneste databasen som ble brukt, som ble distribuert, vet du. Og da jeg faktisk snakket med dem om hvordan i all verden klarer du at mange tilfeller sa de: "Vel, du vet, det er bare rundt fem eller seks store forekomster, og vi har omtrent tre DBA-er vi spredte over det." Jeg er interessert i å bruke DBwartan, fordi du kan gjøre veldig mye med det, hvor mange databaser sitter det over, la oss si typisk, eller til og med hva er de største eksemplene på hvor mange strenger den kan administrere samtidig?
Scott Walz: Vel, jeg har sett situasjoner - og igjen, det er litt komplisert, det spørsmålet er, fordi DBwartan lar meg få flere tilkoblinger eller flere datakilder definert til en enkelt instans. Kanskje jeg vil gjøre en syslogin og deretter logge inn med lavere tillatelser, men jeg har jobbet med kunder som med alt kollapset kommer flere skjermbilder. Da jeg spurte dem det, er spørsmålet du har stilt meg, "Hvordan klarer du så mange?" Og da sier han: "Jeg har ikke det." Ikke sant? "Jeg klarer det jeg kan, men jeg trenger tilgang til alt." Jeg ser ennå ikke noe som stopper, du vet, de øvre grensene for hva folk kan administrere er virkelig den øvre grensen for hva den personen, individet, kan håndtak. Men du vet, som jeg nevnte, de menneskene som jeg utfordrer, de innrømmer åpent at de har alle disse forbindelsene, men det er ingen måte at de kan klare det. De stoler på teamet sitt. Som jeg er sikker på at du har opplevd, ja.
Robin Bloor: Vel, jeg har faktisk vært en DBA selv, selv om jeg ikke gjorde det veldig lenge. Og den ene tingen som du vet, jeg husker, utover alt annet i relasjonsdatabaser, er at du kan gjøre en enorm mengde ting med SQL. Ofte mer enn du tror du kunne. Noe som på en eller annen måte forklarer noe av funksjonaliteten som DBbrevan har, fordi det bare oversettes direkte til SQL. Men, du vet, jeg er sikker på at du gjør andre ting. Det hele er SQL-scripting, eller er det andre spesielle rutiner som er skrevet for esoteriske situasjoner?
Scott Walz: Ja, mye av det, hoveddelen av det er SQL, det er bare det. Men vi skriver rutiner som kan kjøres fra en kommandolinje ved hjelp av leverandørens verktøy, leverandørens frontender. Vi vil sette frontend på, for eksempel, for datalastverktøyene i plattformene, ikke sant? Dette er ikke SQL-skript, ikke sant, det er kommandolinjejobber. Det vil generere disse og være i stand til å gi dem til DBA som de deretter kan utføre. Se ja, vi gjør litt av begge deler, men flertallet av det er SQL-skript.
Robin Bloor: Når du ser på, for selvsagt må du på en eller annen måte ta en titt på utviklingen som skjer som jeg ser på som ganske ny. Jeg mener, en av tingene som jeg synes er interessante som skjer, er at Spark tydeligvis tar av som en rakett, men Sparks SQL, det er borte fra å være fryktelig umoden til å begynne å se litt mer moden ut med litt mer SQL-evner. Ser du på sånne ting, og lurer på om du kommer til å begynne å administrere de med DBbrevan?
Scott Walz: Visst og det gjør jeg. Det er alltid der. Jeg vet at vårt produktlederteam alltid ser på hvor vi skal hen og absolutt, alt ligger på bordet for oss, med hensyn til hva vi ser på i fremtiden.
Robin Bloor: Ok, Dez, vil du hakke inn?
Dez Blanchfield: Ja, faktisk er det en haug med flotte ting du åpnet døren for meg der, Robin. Tusen takk. Jeg er opptatt av å bare utforske noen av tingene som hopper ut på meg når jeg ser på produkter som dette, og jeg blir veldig spent. Da jeg sjekket leksene mine, for som Dr. Robin Bloor nevnt før, så har jeg, som jeg også, sporet dette etter en stund, og jeg husker at jeg så på spesifikasjonskravene dine her om dagen og tenkte, faktisk, denne tingen kjører på veldig lener seg av hva den faktisk gjør. Og jeg tenker fra minnet - korriger meg hvis jeg tar feil - jeg tror det var så lite som en bærbar PC-ytelse komfortabelt ville kjørt DBwartan, og likevel var det i stand til å kjøre noen ganske betydningsfulle databaser bakenden. Og jeg var ganske interessert i å se at du hadde Firebird også nå og Greenplum. Jeg var ganske imponert over kravet eller spesifikasjonen av maskinvaren som bokstavelig talt kunne fungere som en spillejobb på en en gigahertz-CPU. Det var ganske imponerende.
Men brukstilfellene er noe jeg vil fordype meg i litt. Ser du at opptaket av produktet er et behov av behov på grunn av eksisterende miljøer som nettopp har kommet ut av kontroll, eller ser du at folk nå er litt mer proaktive og sier, du vet, vi bygger noe veldig stort, det er sammensatt. Og jeg tenker på fusjoner og oppkjøp for eksempel her, der en organisasjon kan kjøpe en haug med firmaer - små, mellomstore, store, uansett - og ende opp med å arve alle disse miljøene og måtte bygge en ny DB-evne. Hva er de typiske brukssakene for dette så langt som organisasjonstype og søknadstype? Er det overveiende mennesker som har eksisterende miljøer og bare må rydde opp i dem og få kontroll over dem, eller er folk litt mer proaktive og tenker på kompleksiteten de skal bygge og få deg om bord tidlig?
Scott Walz: Vi ser mer på å komme tidlig av akkurat den grunnen du nevnte, konsolideringen. Med bredden av plattformstøtte som vi har, er det ikke total fremtidssikring, ikke sant, men det setter deg og dine DBAer i en virkelig god situasjon at når de ser på et potensielt anskaffelsesmål, ikke sant, er de litt mindre, du vet, tanken på hvilke plattformer kan vi arve, ikke sant? Selv om det er viktig, ikke sant, er bekymringen der litt mindre enn hva det kommer til å bety for våre DBA-er, ikke sant? DBA-ene har et produkt nå som de vet at de kan koble seg til, og hvis de er kjent med å bruke produktet, vil de bli kjent med å koble seg til den plattformen de nettopp har skaffet seg. Så det er absolutt et område som vi ser, igjen vet du, lenge, kundene med den blandingen av alle disse plattformene, ikke sant? Hvordan skal jeg få hendene rundt dette, ikke sant? Og de har prøvd det fordi tankeprosessen er at hver av plattformene har et verktøy, ikke sant? Vi kan bruke vårt eget verktøy, ikke sant? Men det kommer etter hvert tilbake at, du vet hva, ja, det kan du, men ikke bare må jeg lære hver av plattformene, nå lærer jeg hvert av verktøyene som følger med hver plattform og så du har akkurat forsterket jobben som en DBA. Så vi ser også den situasjonen der de kommer tilbake til oss og sier: ”Du vet, vi trenger å få hendene rundt dette. La oss få ett verktøy for DBA, fordi jeg har viktigere ting for DBA å gjøre enn å lære brukergrensesnittet til et nytt verktøy. Eller forskjellige verktøy. ”
Dez Blanchfield: Ja, nei, definitivt. Og du vet, når du ser, tenker jeg fra hukommelsen da jeg så i går bare for å dobbeltsjekke at jeg ikke tok feil, jeg husker at du for eksempel hadde støttet Sybase, så denne tingen har eksistert en liten stund. Det er et annet spørsmål jeg bare hadde for deg - ja, det er deilig å ha Greenplum og Firebird på listen, men Sybase, den typen aldre veldig raskt, som viser at den har eksistert en stund og gjort en god jobb.
Klynger. Så en av de største hodepine for en DBA er at de i det vesentlige vil peke på det som ser ut som en IP-adresse og et knippe APIer, eller om det er JDBC eller LDBC eller hva vi måtte snakke med, men bak det er det en klynge. Hva kan, eller vet DBbrevan om hva som står bak døren nummer én, som det var, når jeg kobler til databasen bakenden, får jeg se alle miljøene bak der, og spesielt, så det er to deler til spørsmål, kanskje. Klyngen, for eksempel når du tenker på, du vet, støtter du IBM DB2 og Microsoft SQL Database Server og MySQL og PostgreSQL og Oracle og noen av de tradisjonelle RDBMS-ene, og du vet, alltid at vi driver en master-slave eller master-master miljø for redundans og høy tilgjengelighet og også ytelse. Vet DBbrevan at det er noe bak døren nummer en som ikke bare er en database i seg selv, men en klynge, og i så fall, hva vet den om det? Og å flyte raskt inn i det slik at du kan svare på det samme spørsmålet, beklager. Så bak klyngene i noen av de scenariene du har, hvordan takler folk blandingen mellom produksjonsmiljøer og katastrofegjenopprettingsmiljøer, så langt bruken av DBwartan går?
Scott Walz: Flotte spørsmål. Jeg vil gi deg det kommer til å være betinget av de spesifikke plattformene, for så mye som vi prøver, vil vi ha forskjellige støttenivåer for noen av de dyptgående, de dypere nedfunksjonene. For Oracle, for eksempel, og deres RAC-miljø, Real Application Cluster, kan du koble til den primære noden i den klyngen, men likevel gå gjennom databasemonitoren som jeg viste, vil vi la deg se SQL kjører og vi vil faktisk fortelle deg hvilken nod i klyngen den kjører på, ikke sant? For å la deg se nøyaktig om, du vet, sakte kjørespørsmål, la oss følge med på det, hvilken node kjører den på? Fordi uunngåelig hele grunnen til klyngen, ikke sant, er for sluttbrukeren, bryr han seg ikke hvor den er blitt kjørt, men for DBA må vi følge med på den typen informasjon. Vi kan for eksempel gå ned til det detaljnivået i Oracle. De andre plattformene som vi har tilkobling, sannsynligvis ikke så mye detalj enn vi gjør for Oracle.
Når det gjelder produksjon og utviklingsmiljø, er det et godt spørsmål. Vi gir samme støtte. Den virkelige primære måten vi kommer til å hjelpe, tilkoblingslaget kommer til å være der, ikke sant? Vi kommer til å kunne koble til og utføre alle funksjonene. Jeg har kunder som bruker noen av funksjonene i DBwartan for å kategorisere datakildene sine, ikke sant? Og igjen, dette kan være litt av for det nøyaktige spørsmålet du stiller, men vi kommer til å gjøre dem i stand til grafisk å betegne når de jobber. Fordi det er en av tingene med DBwartan, er at jeg raskt kan skifte mellom datakilder. Og den neste tingen du vet at jeg gjør meg klar til å føre en avkortet uttalelse, og jeg ser etter om jeg er koblet - kjørte jeg dette mot produksjon eller utvikling? Og så tilbyr vi noen funksjoner i DBbrevan som hjelper DBAene der ute også i å håndtere det og holde dem utenfor problemer, hvis du vil, med noen av DBA-aktivitetene.
Dez Blanchfield: Med det i bakhodet, på den lange listen over plattformer du støtter for øyeblikket, og jeg er sikker på at det vil eksplodere veldig snart av åpenbare grunner. Jeg mener, du støtter slike som f.eks. DB2 på z / OS, for eksempel på mainframe, og da støtter du tydeligvis slike som vi pleide å kalle mellomtoner, men nå bare UNIX-systemer, og slags mer moderne plattformer, du vet, Linux, og så til slutt blir det portert til Bluemix og Cloud Foundry, så du ender opp med at DB2 kjører på Cloud Foundry på Bluemix, med IBM og skyen på soft. Driver folk for tiden ikke bare styring og overvåking, men også du nevnte før muligheten til å migrere og flytte data rundt. Ser du folk hoppe i senga med DBwartan og si: “Du vet hva, vi har en haug med ting på de gamle hovedbildene som vi bare trenger å stikke av og det var en skikkelig problem å gjøre det. Hvis jeg kan peke, klikke og dra herfra og dit, kan jeg faktisk flytte og migrere dataene og skjemaet mitt. ”Er det noe folk gjør?
Scott Walz: De er faktisk i bevegelse, ikke sant? De flytter dataene, ikke sant? Nå bruker de DBbrevan som et verktøy for det. Gjør det alt for dem? Nei. Vi begynner, dra og slipp, ikke akkurat der, men vi lar dem generere noen skript, fordi du ideelt sett vil ønske å bruke - du vil ikke at denne jobben skal være kjører på klienten din, på den bærbare datamaskinen, av den grunnen du nevnte. Vi kan kjøre på et veldig lavt fotavtrykk, ikke sant? Vi hjelper dem med å generere skript og deretter snu det og bygge det, og så kan de levere dette skriptet og få det kjørt på serveren, ikke sant? Og få kraften, hestekrefter bak serveren til å gjøre det. Vi hjelper dem med å generere noen av jobbene sine for å gjøre noe av det arbeidet.
Dez Blanchfield: Rett. Et par siste for deg, og så kan vi komme tilbake. Det som virkelig slo meg bare ved å gå gjennom tillegget ditt, som er fantastisk, og faktisk skulle jeg ønske vi hadde en time til å gå nærmere inn på. En veldig stor utfordring for DBA, ikke sant, er grunnleggende etterlevelse, generell styring av infrastrukturen, revisjonene, rapportering om dagens tilstand, se på fremtidig prepping for ting som, du vet, bare generell miljøvekst. Det slår meg at selv om det i kjernen av det produktet ditt ser ut til å gjøre, som bare gjør livet enkelt, at den eneste ruten med glass, en enkel utsikt over verden, og jeg i det vesentlige kan klikke og peke og dra og jeg elsker det faktum at jeg kunne trene noen til å gjøre dette veldig raskt nå, de trenger ikke lese bruksanvisningen som den var. Det slår meg at verktøyet også gir meg muligheten til å gjøre en hel haug med ting rundt styring og etterlevelse og revisjoner, som jeg lurer på om folk faktisk har våknet til, det er jeg sikker på at de har.
Men ser du folk nå se på det og gå, og det er som dette eureka, a-ha-øyeblikket, går, “Hei, vet du hva, dette gjør DBAs liv veldig enkelt fra nå, eller enklere fra et operasjonelt synspunkt eller utviklingssynspunkt. Men her, vi kunne faktisk bare rapportere om alle databasene våre nå og alle datasettene og alle innholdsløse data og alle metadataene rundt. Som hvem som har tilgang, når de har tilgang, hvorfor de har tilgang, og hvilken type tilgang de har fått. ”Og så plutselig tar jeg opp noen av utfordringene rundt etterlevelse. Spesielt når vi har noen store ting som skjer rundt brudd på data. Vi har noen fantastiske ting som de globale finanskrisene, alle disse utfordringene kommer til, men hvordan i all verden skal vi måle og overvåke og møte samsvar? Er det den slags store tingen for folk ennå, eller er det stille, slags, tidlige dager så langt som å bruke DBwartan på det?
Scott Walz: Jeg har kunder som ikke kan si nok om DBbrevan. Nå er det de som har innsett det. Lyspæren er på. De sier: ”Vent litt. Jeg kan svare og svare og generere noen av rapportene du nevnte, riktig, alt fra ett verktøy. Jeg har det. ”Nå er det andre som fremdeles ikke kan ta tak i det, og det kan være av forskjellige grunner, ikke sant? De er kanskje ikke ennå, eller kanskje blir det håndtert av noen andre, men kundene våre som vi har funnet som bruker det, er det et a-ha øyeblikk, ikke sant? Det er ikke bare jeg som er i stand til å lage en tabell over alle disse tingene. Og absolutt, med alle kravene til overholdelse, er det enormt. Det er en jobb i seg selv.
Dez Blanchfield: Vel. Og du vet, jeg mener, helt fra toppen av hodet mitt, tenker jeg med en gang, du vet, hvis det er noen som kommer med og sier at de ønsket å opprette en konfigurasjonsadministrasjonsdatabase, CMD, hvis de må møte alt fra Sarbanes -Oksley å COBIT til ITIL, du vet, SWIFT compliance og bank, til og med å gå ned til slike som International Standards Organization, ISO 27001, 27002. Det er alle disse virkelig store rammene. En av utfordringene er bare å finne hvor dataene er, hvem som administrerer det, hvilket format de er i, og jeg tenker, det har for meg, som for meg bare å se på det nå som eureka-øyeblikket bare gikk av, det var som, henge på et sekund kunne jeg kaste dette inn på til og med noen som ikke nødvendigvis er en DBA, men jeg kunne trent ham raskt opp og sagt: "Det er et compliance-verktøy." Jeg synes det er flott at det gjør jobben sin i en administrasjonsdatabase. ledelsesverden.
Men jeg sitter her og tenker, gud, du vet det faktum at du kan administrere flere plattformer som en i disse dager, og du kan dykke helt ned i som sagt å logge transaksjonene du gjør. Du vet, kan du tenke deg å ta dette verktøyet med i en datainnbruddshendelse, og du har fått sikkerhetsgruppen til å løpe rundt for å finne hva som er hvor og hvorfor, og hvem har sett hva. Og når de beveger seg rundt, må de logge og spore alle handlinger de gjør, fordi de kan bli en del av problemet hvis de ikke kan annet. Ja, jeg tror det er en utrolig evne her, du vet du umiddelbart kunne begynne å gjøre det. Spesielt når vi ser på utfordringene med data revisjoner du kjenner, har vi dette enormt som en funksjonskryp, som den var, med datasett og data.
Og en av tingene vi har snakket om i et annet par show vi har gjort er, du vet, hvordan går du og finner dataene dine, og ofte snakker vi om det faktum at når du starter i en organisasjon, har du en tendens til stå opp i avlukket ditt og legg hånden i lufta og vift og gå, “Vet noen hvor denne databasen er? Hvordan kommer jeg til denne datakilden? Hvor er denne filen? "" Gå og spør mottakelse. "Ikke sant? Verktøyet ditt kan umiddelbart gi den muligheten til å finne ting og oppdage dem og til og med rapportere om dem.
Tilbake til et av spørsmålene bare kort, så vil jeg pakke meg sammen og levere tilbake til Eric. Det slår meg at omfang kommer til å bli en utfordring i løpet av de neste 12 månedene for deg. Kan du gi oss litt innsikt, bare på et tretti tusen fot synspunkt, antar jeg, i skalaen eller skalaen som DBwartan har kommet til å fungere. Jeg kan tenke meg at når jeg legger dette på den bærbare datamaskinen og jeg berger meg og jeg peker det mot et miljø, kan jeg oppdage det og jeg kan begynne å gjøre ting på det. Jeg kan tenke meg at det går fra som en liten, åpen kildekode databasemotor med noen få rader og tabeller. Hvilken skala ville den gå opp til? Du snakket om DB2 på mainframes, det er stort. Og klynger. Hva er størrelsesområdet vi kan takle her? Og Robin rørte på det tidligere, men jeg trenger bare å komme inn på det litt mer detaljert for hvor stort vi kan bli med DBwartan.
Scott Walz: Visst. Det kommer sikkert til å være utfordringene dine, fordi det er et klientprogramvare. Og så, igjen, hvis jeg jobber med en mainframe, når jeg jobber mot testsystemet vårt på mainframe som vi har, kan jeg peke det mot millioner av rader og gjøre et kryssforbindelse mot millioner av rader. Alt arbeidet skal gjøres på en server, ikke sant, fordi vi sender den kommandoen, og det er bare et spørsmål om DBwartan håndterer resultatsettene, ikke sant? Og så er det utfordringen, og det er skjønnheten, riktig, av det vi gjør. Det meste av tunge løft blir gjort på serveren. Vi håndterer bare alle resultatene. Og så, igjen, kommer du selvfølgelig inn i situasjoner når du ønsker å kjøre ti spørsmål samtidig som alle returnerer millioner av rader, ja absolutt, kanskje du befinner deg i noen forestillinger der, ikke sant? Men på ingen tid har jeg kunder som viker unna å kjøre store spørsmål mot DBwartan, du vet, mot databasen deres. Igjen, som sagt, varierer kjørelengde avhengig av mange faktorer, ikke sant, men igjen, som sagt, har jeg med millioner av rader som kommer tilbake, og så lenge det fyller rutenettet, vet du, jeg ' m klar til å gå. Men noen ganger må jeg tydeligvis vente på at resultatene kommer tilbake.
Dez Blanchfield: Jeg har et spørsmål til deg før jeg slutter, fordi jeg har tatt for mye av tiden din og takker for det. Bare fortell oss litt mer rundt, vet du, og les de siste spesifikasjonene i går bare for å forsikre meg om at jeg var så bra som jeg trodde jeg var. Prosessovervåking og slags varsler og varsler, du vet, kapasitetsplanlegging bringer opp alle de massive problemene med DBA-er, hele dagen hver dag, vet du. Skal noen fylle ut denne tabellen, skal han fylle ut databasen, skal de fylle ut diskplassen jeg har, hvordan klarer jeg den? Gi oss en rask gjennomgang av slags prosessovervåkning og spesielt overvåkingsvarsler og deretter ideelt rundt kapasitetsplanlegging. Jeg tror det er et område som jeg tror det kan være mye interesse for.
Scott Walz: Prosessovervåkning viste sannsynligvis at funksjonen som flertallet av kundegrunnlaget bruker, og som er en databasemonitor for å kunne vise og gjøre det. Og vi har noen i analytikeren. Performance Analyst har noen varsler du kan sette opp når visse terskler er oppfylt. Det kan varsle deg. Kanskje X antall logger, feil i loggfilen, vet du, det vil gi ut et varsel for deg. Tabellplass treffer en viss prosentandel full, du kan få et nytt varsel. Og det fine med det er, er at du er i det samme verktøyet, ikke sant, det er en del av DBwartan, slik at du bare høyreklikker på feilen, varselet, og du klarer deg med DBwartan, og det tar deg rett til tabellplassredigereren . Og du kan løse problemet akkurat der.
Når det gjelder kapasitet, er det absolutt en hurtigknapp, og kapasitetsanalytiker som vi har for øyeblikket, blir portert til SQL Server, Oracle, DB2 LUW og Sybase ASE. Og det gjør akkurat det du beskrev. Du kan starte, når vi først har fått noen samlinger, ikke sant, og når vi først har fått en prøvestørrelse, og kanskje radstørrelsen, kanskje dens antallet, mange alternativer i verktøyet, og så kan du begynne å trending, ikke sant? Og hvordan ser det ut om seks måneder? Hvordan kommer det til å se ut om tolv måneder? Jeg kan trend til, bare trend til en dato, eller jeg kan trend til en verdi, ikke sant? Og et eksempel du hadde, jeg har en mengde diskplass, basert på det, når skal jeg nå den grensen? Basert på veksten jeg har og disse samlingene som jeg har gjort, når skal jeg nå den grensen? Jeg vet i det minste at jeg kan begynne å planlegge for det. Kommer det til å være seks måneder, skal det gå to år? Men igjen kan vi bruke kapasitetsanalytikeren til å trende mot det.
Dez Blanchfield: Det er kjempebra. Fantastisk demo. Jeg likte det virkelig. Jeg kommer til å gi meg tilbake til Eric fordi jeg vet at det er et par spørsmål som har dukket opp fra vårt fantastiske publikum i dag. Tusen takk, det har vært veldig bra å bli kjent med produktet, og jeg ser frem til å følge nøye med på det.
Eric Kavanagh: OK bra. Vi har et par gode spørsmål. Og vi går litt etter hvert, så vi prøver å pakke oss raskt opp, for jeg vet, Scott, du har et lukket hardt stopp. Her er et stort spørsmål. Hva med å jobbe på gamle datalagre som VSAM, og Model 205, og IMS og IDMF og den slags? Ser du det veldig ofte i disse dager, og hvor bra fungerer det?
Scott Walz: Jeg vil ikke fortelle deg at du sitter fast. Noen av disse miljøene, hvis de har ODBC eller JDBC, og jeg vet at noen av dem er der ute, kan vi koble oss til det, og du kan jobbe med det på den måten. Men for det meste er den grønne skjermen veien til å gå stille.
Dez Blanchfield: Jeg elsker den grønne skjermen.
Eric Kavanagh: Du vet, som Dez påpekte med det ene lysbildet, der han hadde alle de forskjellige applikasjonene og verktøyene som er tilgjengelige i dag, det er en veldig skremmende virkelighet for alle som ønsker å utføre funksjonen til en databaseadministrator på en ansvarlig måte. Og jeg gjetter at dere over tid kan bygge kontakter til et av disse verktøyene når og når kundene krever, og så videre, ikke sant? Slik at du aktiverer den ene glassruten.
Scott Walz: Og det var den store nøkkelen bak å gjøre DBwartan utstyrt for å kunne håndtere disse JDBC- og ODBC-forbindelsene. Vi har virkelig utvidet det nå. Nå, så lenge vi har den forbindelsen, ikke sant, så lenge vi har den sjåføren, kan vi koble oss sammen og jobbe mot den.
Eric Kavanagh: Det er gode ting. Vel folkens, vi arkiverer alle disse for senere visning. Jeg la ut en lenke til lysbildene, forhåpentligvis kan du se det, via SlideShare. Tusen takk for all din innsats, herrer. Fantastisk webcast i dag igjen. Mange gode lysbilder. Mye godt innhold. Jeg elsket den demoen. Det er veldig interessant at dere har målrettet et veldig søtt sted på markedet fordi det er en slik eksplosjon av databasetyper i disse dager. Og vi trenger bare som ledere et sted å håndtere alt dette. Godt gjort, folkens. Vi henter deg i morgen for en annen Hot Technologies. Forhåpentligvis har du skåret ut en time i morgen. Samme tid. Samme stasjon. Vi henter deg neste gang, folkens. Ha det fint. Ha det.
