Hämtmat: Värd Eric Kavanagh diskuterar databastrender med Dr. Robin Bloor, Dez Blanchfield och Scott Walz i detta avsnitt av Hot Technologies.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Mina damer och herrar, hej och välkommen tillbaka till den hetaste showen i företagens IT-värld, Hot Technologies 2016. Ja, verkligen! Mitt namn är Eric Kavanagh, jag kommer att vara din värd idag för en show med titeln "The Art of Synlighet: Enabling Multi-Platform Management", ja verkligen. Några snabba anteckningar, det finns en bild om dina verkligen, riktigt från för fem år sedan och nog om mig, slog mig upp på @Eric_Kavanagh. Året är varmt, detta är vår vanliga bild för Hot Technologies. Vad vi gjorde med den här showen är att vi ville ha ett program som skulle hjälpa oss att definiera en viss typ av teknik, så hela tanken är att vi får två analytiker som kommer in och ger sitt tag på ett visst utrymme eller en viss typ av funktion som företaget behöver, och sedan kommer leverantören in och demonstrerar vad de har byggt och förklarar hur det anpassar sig till det du hör från analytikerna.
Och orsaken till det, som du kanske föreställer dig, beror på att i världen av företagsmjukvarumarknadsföring finns det termer som blir bandade om och vad som händer alltid är att leverantörer tar sig till den senaste hot termen, saker som big data eller analys för exempel, eller till och med SOA eller olika termer som plattform, och ibland är dessa ord mycket exakta för en viss teknik och ibland är de inte. Denna show var utformad för att verkligen hjälpa oss att formulera för dig, publiken, vad specifika typer av teknik gör, hur de fungerar och när du bör använda dem.
Med det kommer jag att presentera våra högtalare. Vi har vår helt egen Dr. Robin Bloor, som ringer in från sin plats i Austin, Texas, Dez Blanchfield, ringer från andra sidan planeten, och vår gäst Scott Walz som ringer in från Kentucky. Och din är verkligen, jag är faktiskt utanför Pittsburgh, så vi har en helt geo-lokaliserad organisation idag från flera olika platser. Med det kommer jag att driva Robins första bild, känn dig fri att ställa frågor förresten, folk, var inte blyg. Du kan göra det med hjälp av Q & A-komponenten i din webcastkonsol. Och med det ska jag överlämna det till Dr. Bloor. Golvet är ditt.
Robin Bloor: Okej, tack för introduktionen, Eric. Låt mig bara komma till den första bilden. Detta är en samling av meerkats som tänker på databasen. Hela presentationen som jag verkligen gör här är egentligen bara en allmän uppsättning tankar om databasen som jag har haft nyligen, och poängen var att verkligen runt år 2000 verkade det som att databasspelet var över i meningen att de allra flesta databasimplementeringar inträffade på relationsdatabasen. Och då förändrades det bara, du vet, alla dessa saker som meerkatterna tänker på, kolumnlagrar, nyckelvärdeslagrar, dokumentdatabaser, databas i minnet, grafdatabas och en hel del fler saker plötsligt dyker upp. Och det var nästan som en ny typ av geologisk era som har fossil av olika slags djur plötsligt dykt upp.
Nyheten från Lake Wobegon, det är verkligen över för databasen med enstaka modeller. Det råder ingen tvekan om att RDBMS fortfarande dominerar, men andra typer av databaser är nu etablerade. Det är verkligen översikten över vad jag ska säga här.
Måtten på databasen, några av dessa blev faktiskt viktigare nyligen, men de som jag kunde tänka på när jag gjorde den här bilden, ändå, var den uppskalad i termer av att använda resurserna för en given server? Skalar den ut så att den kan gå över stora kluster? Utnyttjar den den tillgängliga maskinvaran som är typ av databaser i minnet går i den riktningen? Är det utdelningsbart? Det finns ett antal databaser som främst beror på variationer att distribuera. Vilken typ av egenskaper har det? Den grundläggande ACID-karakteristiken för databasen. Men nu istället för att ha en verklig konsistens, har ett antal databaser slutligen konsistens, människor använder dem och de har inga problem med dem så de har visat att ACID inte var absolut nödvändigt, bara bra att ha i en många situationer.
När det gäller metadataorganisationen har hela spelet förändrats. Vi har olika metadataorganisationer snarare än ett typiskt RDBMS-schema. När det gäller optimeringsprogrammet finns det en hel del optimeringsaktiviteter på gång beroende på de datastrukturer du försöker optimera. När det gäller hanterbarhet finns det mycket variation i detta som jag kommer att komma på senare, men i princip är hela punkten med en DBMS hanterbar och återigen bestämmer omfattningen av dess hanterbarhet i viss utsträckning omfattningen av dess användbarhet.
När det gäller hårdvarufaktorer är detta just det som säger - jag menar att det bara är en sak som görs här - poängen som görs här är att allt vi tittar på i dag när det gäller databasarkitekturer kommer att förändras. Det kan vara samma databaser, men de måste på ett eller annat sätt ta hänsyn till vad som faktiskt händer på hårdvarunivå. Under många, många år hade vi denna relativt enkla situation med CPU, minne och spinndisk - det är väl försvunnen.
Poängen som är här, för det första har vi CPU: er men de är väldigt mer parallella förmågor än de hade tidigare med många, många olika processorkärnor. Vi har också fått GPU, vi har också FPGA, olika typer av kisel, men Intel har gifte sig med en FPGA med en CPU i nästa utgåva, och - OCH - har gifterat sig med GPU och CPU tillsammans på samma chip. Du har chips med olika egenskaper. Fördelen med en GPU är att den är riktigt bra för tung parallellitet och särskilt med numerisk beräkning. FPGA: er kan du på ett eller annat sätt sätta koden på chipet och det fungerar mycket snabbare än om du bara matar den till chipet.
Det finns en korsning av dessa saker som händer. Vi har fått 3D XPoint från Intel och PCM från IBM, som är nya typer av minne, som är långsammare än RAM, billigare än RAM men inte flyktiga. Och dessa skapar lite spänning bland ett antal mjukvaruleverantörer som jag har pratat med. Vi har SSD: er men nu blir de mycket, väldigt stora och de ger parallell åtkomst. Med parallell åtkomst till en mycket stor SSD kan du närma dig läshastigheter som liknar RAM-läshastigheter. Vi har denna möjlighet till tre typer av lagrings-RAM, 3D XPoint-grejer och SSD: er, som alla kommer att gå extremt snabbt. Och eftersom hastighet är kärnan i databasen kommer all databasteknologi att försöka utnyttja dessa så snabbt som möjligt. Och det kommer att involvera och ha involverat parallellarkitektur, men parallellarkitektur. Hårdvaranivån påskyndas hela tiden, har gjort i många år, fortsätter att göra det och de allmänna kostnaderna sjunker.
Trail of Tears. Det här är bara olika försök på databaser, de första databaserna före relationen betecknades generellt som nätverksdatabaser, sedan kom relationsdatabaser, sedan kom objektdatabaser, de fick inte en hel del dragkraft, sedan kom kolumnlagringsdatabaserna som var relationsdatabaser gjort mycket annorlunda. Och sedan hade vi dokumentdatabaser och SQL-databaser som var objektdatabaser gjort på annat sätt, eller om du vill, samma kolumn med objektdatabaser och de fångade på. Och nyligen har vi haft grafidatabaser som får dragkrafts- och RDF-databaser. Och det du tittar på där är minst tre olika uppsättningar av datastrukturer som anpassas. Relationsdatabasen gör tabeller och rader mycket bra. Dokumentdatabasen och objektdatabaserna - de gör besvärliga datastrukturer, särskilt hierarkiska datastrukturer, mycket bra. Och grafdatabaser och RDF-databaser klarar nätverksdatastrukturer mycket bra. Och dessa olika, jag tänker på dem som tre rader, dessa linjer kommer att fortsätta på obestämd tid. Det kommer inte att stoppa eftersom motorerna som gör dessa saker inte fungerar särskilt bra på den andra datastrukturen.
Och sedan har vi den bortskämda faktorn från Hadoop. Hadoop är inte en databas men det finns databaser som använder HDFS för sin lagringsstruktur. Och många saker som Hadoop gör är den typ av hanteringssaker som måste göras för en databas. Också värt att nämna att Spark inte är en databas heller, men den har, och det är en omogen, men den har en SQL-optimizer och därför är den som en kärna i en databas utan att nödvändigtvis veta var du ska lagra data , men om du klistrar på det på HDFS uppfylls faktiskt mycket av databaskravet helt enkelt genom funktionerna i det underliggande filsystemet. Särskilt gnista har blivit en del av databasekosystemet och det är ofta förenat med mer kraftfulla databaser, och skälet till det är verkligen analys. Analytics - Spark är, det går väldigt, mycket snabbt vid analys. Analytics är den främsta applikationen som de flesta investerar i just nu, så de två går typ hand i hand. Dataförening snarare än koncentrationsregler, det bör vara uppenbart av det faktum att du har minst tre olika behov, strukturerade typer av databaser där ute och därför dataförening om du vill dela informationen mellan dem. Det är ofta nödvändigt, men du har också databaser som skalar ut och databaser som inte gör det, riktigt kraftfulla motorer som Teradata eller Vertica har en mycket speciell plats, men mindre motorer som kan göra mycket fruktansvärt, så, federationen kommer sannolikt att vara där en lång, lång tid även mellan relationella databaser.
Det sista att säga, IoT, det är inte över förrän den feta damen börjar föraktande data. IoT kan mycket väl skapa på ett eller annat sätt en annan dynamik i databasvärlden och det kommer att komplicera saker ännu mer. Förhoppningsvis kommer det - på ett eller annat sätt - att finnas någon form av konvergens som pågår, men jag ser inte att allt kommer samman som det gjorde med de relationsdatabaser. Inte någon tid snart ändå.
Och jag tror att det är allt jag har att säga, så jag ska överlämna det till Australien.
Dez Blanchfield: Tack, Robin. Tack till alla för att du gick med oss, tack för att du har mig i morse eller i eftermiddag din tid. Detta är ett riktigt hett ämne eftersom vi har upplevt en ganska explosion under det senaste decenniet och lite, i mängden data som vi måste ta itu med, och alltid att uppgifterna ligger inom någon form av system som i de flesta fall är en databas av någon form. Jag trodde att jag snabbt skulle ta oss genom en mycket hög nivå av promenader genom hur vi kom hit och problemet som skapas och vilka typer av saker vi behöver ta itu med nu, och sedan ska vi prata om typen av lösning som kan tillämpas på det. Låt mig bara ta tag i min första bild här.Jag är av den uppfattningen att vi är vid den punkt där DB admin 2.0, eller databasadministration 2.0, är typ där vi är typ av nu, en gång i tiden var en databasadministratör en ganska enkel roll och utmaning och du kan träna någon ganska snabbt. I dagens värld är det inte längre fallet, och jag ska visa er varför det är så.
En gång i tiden skulle en databasadministratör kunna ansluta till DB back end och göra en snabbvisning-databaser och det skulle finnas en lista över databaser i systemet som de var tvungna att vara medvetna om och de mycket snabbt kunde komma över dessa databaser och välj dem och ha lite av en poke och en sond runt och använda översätta, beskriva tabellen för att ta reda på vad som finns i en tabell och var och en av kolumnerna och raderna, och det var en relativt enkel utmaning och om du läser genomsnittet två eller tre hundra sidor om databasadministration för varje plattform, du kunde nästan lära dig själv utan att behöva göra en raketvetenskap.
Men det är inte längre fallet, och skälet till det är enligt min mening att det finns alldeles för många alternativ i databasvärlden för att en person ska kunna vara expert på en specialist och att kunna hantera och administrera manuellt . Och orsaken till detta är att vi under de senaste fyra till fem decennierna när det gäller en värld av servrar och databasesystem och databaseservrar och applikationssviter har kommit mycket väldigt långt. En gång i tiden hade vi stort järn som behövde ta itu med vad som faktiskt var små data och skrattande små när vi tittar tillbaka nu. Jag såg ett riktigt snyggt foto häromdagen av den fantastiska damen som var huvudprogrammerare och utvecklare för NASA vid tiden då vi satte män på månen, och hennes kod togs ut i ett hundra och trettiotvå kolumnraders och fan-vikta, och det stod faktiskt högre än hon var, mängden kod hon skrev.
Och när jag tänkte på det var jag som, faktiskt handlar det antagligen om två eller tre hundra megs data där hon var tvungen att skriva in det mest, om inte mindre. Och den totala mängden data för att hålla hennes kod, även om den fysiskt stod högre än henne när den togs ut på papper, var faktiskt en mycket, mycket liten mängd. Till och med dessa massiva datorer i rymdstorlek, och det är ett IBM System / 360 i just denna bild, mängden data det faktiskt kunde innehålla var liten jämfört med dagens värld. Faktum är att våra smartphones har 60 och 128 och 256 spelningar och vi kommer snart att ha terabyte i våra telefoner innan länge när priset på blixt sjunker.
Och så vid den tiden och den eran var databasadministrationen ganska enkel. Här är en ögonblicksbild av en 3270 terminalsession och för en DBA, att kunna logga in och titta på antalet filer som var relaterade till databasen, och de index som fanns där och raderna och kolumnerna var enkla. Och du kan se här i den här skärmdumpen, att det här är en tabell och ett antal tabellutrymmen, det skulle ha varit hela stordatorn som hanterade en databastabell. Medan vi idag har miljarder rader med poster i databasesystem. Och förändringen skedde genom en teknisk förändring som gjorde det möjligt för oss att bygga databasplattformar och datahanteringssystem.
Om vi tänker på den typ av ursprungliga stordatorer och många datorer som kör databas och så småningom relationsdatabaser, så för femtio år sedan, och den stora järnformen värld och de små datauppsättningar vi hade, när vi kom till ungefär åttiotalet , vi var typ på, vi gick igenom stordatorerna från mini till mikro, och vi hade datorer som kör saker som dBase II och dBase III, och på DOS och CP / M och vi hade en mycket tidig relationsdatabas- tillgängliga stiltekniker och de skalade ganska bra jämfört med vad vi var vana vid i stordatorn. När vi kom till nittiotalet hade vi liknande och Oracle och DB2. Och i slutet av nittiotalet hade vi människor, som hemliga datorer som kunde limmas som en nätverksmodell, väldigt stora maskiner, skåpstora maskiner tillsammans och ta liknande och bygga dessa kluster av datorer. Men även då var den fortfarande liten jämfört med vad vi ser idag.
Men i bilden som jag har kommit upp här är detta Hadoop-klustret och fungerar effektivt som en maskin och i princip är det bara en riktigt, riktigt stor dator och den kan innehålla de typer av webbskaladata vi är vana med nu . Och så utmaningen med databasadministration, databashantering på dessa typer av plattformar har verkligen i min mening blivit raketvetenskap. Du måste vara en extremt smart karaktär för att kunna förstå tekniken den kör på, plattformen den körs på, de data som finns där, vilka typer av användningar av dessa data. Och ja, vi såg denna explosion från början av 2000-talet, där vi hade Microsoft SQL blivit en sak, Lotus Notes var ganska väl etablerat och där ute och antalet Lotus Notes-databaser som kröp runt platsen var ganska skrämmande. Och vi hade de vanliga åkarna av Oracle och DB2 och började verkligen ta tag. Några av märkena började blekna. Men vi gjorde fortfarande egentligen bara traditionell databasadministration fram till den punkten, runt den sorten 2006-eran där, om jag går tillbaka till den bilden av det klustret, hade vi vad vi kallade Beowulf-kluster bli en sak där vi kunde ta PC-er från hyllan och klistra in dem och skapa stora superdatorer.
Men från ungefär den punkten och framåt korsade vi en tipppunkt där människor kunde göra databasadministration av gamla skolan och - som jag säger, enligt min uppfattning - skalan blev väldigt, väldigt stor, mycket, mycket snabbt. Det är nästan som om vi hade denna big bang-händelse inom teknik som drev införandet av datateknik och datahanteringsteknologi och i synnerhet databaserna runt dem. Och eftersom vi i själva verket byggde högpresterande kluster i datorstil för att vara värd för data i olika former. Och för att punktera den punkten, här är en ögonblicksbild av landskapet från 2016 av databasteknologier som är tillgängliga för oss. Allt från nedre högra hörnet och öppen källa, hela vägen till det övre vänstra hörnet i infrastruktur. Och i det övre högra hörnet i applikationslösningar som finns tillgängliga för oss, och i det nedre vänstra hörnet, en blandning av infrastruktur och prestandamotorer som gör analyser, och så vidare. Och i mitten finns naturligtvis enheter som våra smartphones, som faktiskt körs på mycket små versioner av databaser, för att göra saker som hantera våra kontakter och så vidare, eller våra samtalsloggar och andra saker som vi har.
Och i min mening var det denna explosion, som en kambrisk explosion i den typen, där mängden teknikutveckling som ägde rum under den mycket korta tiden från 2006 till 2016, som faktiskt är ett decennium, som det var. Vi har nu sett grafidatabaser bli en stor sak, databas i minnet blir en stor sak, SQL-databaser kommer med. Övergången till olika datormodeller, Hadoop kom till, vi hade MapReduce-modellen, nu har vi Spark och strömningsanalyser och strömningsdatorer, elastiska distribuerade data, ramar som människor måste utveckla för dem, för att komma till de skalor som vi behöver, och när vi tänker på den resan, gå igenom den typ av, vad är de relationella databashanteringssystemen med de vanliga misstänkta, Oracle, PostgreS, Sybase, IBM DB2, MySQL och Microsoft SQL Server-plattformen. Vi har sett några nya barn komma i block nu, Clustrix, Xeround, NuoDB, MemSQL, och det finns dussintals och flera dussintals fler som du såg på den bilden tidigare. Om du kan föreställa dig utmaningen att behöva känna till dessa plattformar, och kunskap att köra dem och få en enda ruta med glasvy, som du behöver vara en DBA och göra dessa saker, är utmaningen långt ifrån trivial. Och sedan plötsligt kom NoSQL-motorerna som är en helt ny ras av rolig utmaning.
Och så är den sista bilden som jag har här en slags den ultimata knock-out-en-två-tre-utslaget och det är att vi har tagit några av dessa tekniker nu och vi har skapat en servicefunktion för dem, vi har lagt dem in i molnmodeller och de är nu tillgängliga som ett verktyg, som en tjänst, du kan i princip få databas som en tjänst och de vanliga märkena som vi ser där på Amasons webbtjänster och Googles Cloud Compute-plattform och Microsoft Azure är de som kommer till människors tänker, men det finns faktiskt dussintals och dussintals molnplattformar nu. Och till exempel i Australien finns det något som ett hundra och tolv företag som är bona fide storskaliga offentliga moln som erbjuder databastjänster i olika former.
Att tänka på den utmaning som den genomsnittliga DBA har för att komma ur sängen och gå till jobbet och hantera nu är en ganska förvirrande utmaning. Och så är jag väldigt av den uppfattningen nu att vi som många saker i livet har skalat upp de horisontella och vertikala, det är infrastrukturen som skalas i en mycket horisontell, nästan linjär tillväxtmodell och komplexiteten i stacken i en vertikal känsla, antalet databasplattformar, antalet applikationsramar och modeller vi måste ta itu med har kommit långt utöver vad människor ska kunna hantera i en enda ruta med glasvy och vad poängen nu med databasadministratörer behöver en hel uppsättning nya verktyg för att kunna prata med alla dessa plattformar, klara av dem, administrera dem och stödja dem, och jag tror att det är hela ämnet för våra samtal i morgon, eller i eftermiddag din tid, och med det i åtanke, Jag ska överlämna till vår gäst som kommer att prata mycket om sin produkt och hur det kommer att ta itu med utmaningen.
Eric Kavanagh: Okej Scott, jag kommer att lämna -
Scott Walz: Tack så mycket, okej, tack. Tack Dez, tack Robin, och tack till alla för att du gick med och hade mig på samtalet idag. Jag vill tacka Robin och Dez för att ha tagit mig på en promenad ner i minnesfältet, efter att ha varit i rymden sedan början av nittiotalet, du fick tillbaka många bra minnen. Minnet som jag inte såg på någon av dessa bilder och bilder var stanskorten. Och det var det allra första som introducerades för mig när jag först började på mitt första jobb från universitetet, min kollega i kuben bredvid mig, sa till mig att inte röra vid hans punchkort. Så ja, absolut, och det har verkligen varit en utmaning och en utmaning som vi har arbetat för att hjälpa våra kunder att ta itu med och sedan mitten av nittiotalet, och det är en produkt som jag vill prata om idag. Låt oss ta en titt på hanteringen av flera plattformar, och detta är bara en deluppsättning. Jag valde en graf men som Dez satte upp—
Eric Kavanagh: Du måste dela din skärm.
Scott Walz: Åh, det gör jag säkert, tack.
Eric Kavanagh: Inga problem. Och folk, var inte blyg, ställ frågor, vi har tre smarta byxor på samtalet idag, så dem är de svåra frågorna. Du kan använda Q & A-komponenten i din webcastkonsol eller du kan tweeta med hashtaggen från BriefR. Okej, Scott, ta bort det.
Scott Walz: Där går vi, tack. Jag tog tag i den här bilden och den här bilden. Bilden från Dez sprängde mig verkligen för det är, det är verkligen den värld vi lever i idag, och världen som DBA presterar i. Och som de nämnde är det inte längre, du verkligen, kämpar för att kunna att göra detta med bara brute kraft. Du behöver verkligen verktygen och det är, vi kommer in för att spela och vi ser hela växeln, momentumförändringen där det var tidigt och var väldigt tyst som du nämnde, och sedan gick vi till att arbeta med flera databasplattformar , så det var vår första spridning av verktygen, och sedan var det tillbaka till organisationerna, och efter år 2000 och när det snarare förträngdes lite. Med organisationerna och ville gå solid, men sedan kom det tillbaka och det sprängde verkligen när du introducerade alla dessa nya plattformar. Och nu istället för att duva i en specifik plattform eller en specifik teknik, är ingen av dessa organisationer att ta reda på vad som är bäst. Vad är den bästa applikationsdatabasen, vad är den bästa plattformen att använda? Och med det sagt, vill jag gå igenom dig lite om vad vi gör med DBwartan. Och DBwartan har varit vår flaggskeppsprodukt som hanterar, som det säger plattformsmiljöer i över 20 år, och det är här vi bor och det är här vi vill betona och arbeta med våra kunder och ge dem verktygen för att göra dem produktiva och utförs.
Låt oss gå vidare och jag kommer att hoppa direkt in. Jag visar produkten mer när jag går igenom bilder och jag tror att du förmodligen gör det också. För er som inte har sett DBwartan förut tittar vi på kompisen, och jag tror att Dez använde termen ”en enda glasruta”, och det är något som vi stolta över för att ge DBA ett enda blick i alla deras plattformar. Okej, inget behov av att öppna upp någon annan applikation, vi kommer att ansluta och få dig dit och börja arbeta med plattformen. När vi tittar på databasutforskaren till vänster, kan vi skapa det så som vi finner lämpligt, vi kan organisera det hur vi vill. Och du ser att jag har en blandning, jag några av mina Oracle-servrar, jag har MySQL, jag har PostgreS här inne, jag har också en - det är märkta produktionsserver som vissa inkluderar en del av MySQL-servermiljön. Återigen kan vi se just där att vi har passat bra. Om jag ser på att registrera en ny databas så ser du en av de plattformar som vi stöder, det finns ett par som jag vill ta upp. Du kommer att märka när detta är ditt SQL, support för det, Teradata, Apache, PostgreS, här är de generiska som vi stöder.
Om vi har JDBC-drivrutin eller LDBC-drivrutin till någon av plattformarna, kan vi ansluta, ge dig en anslutning och låta dig arbeta med plattformen direkt från DBwartan. Återigen låter du fokusera på jobbet och inte hur du ska få det gjort. Gå igenom allt det. Men jag vill visa några saker om produkten. Låt oss i så fall öppna upp och vi kommer att ta itu med till exempel Oracle. Det här är bara min lilla målsida här, men jag vill gå och titta på några av mina scheman som jag arbetar med. Vi kommer att dra in ett av de större schemorna, så igen, vi tar tillbaka listan med tabeller. Okej, i det här fallet kommer jag att öppna upp ett bord, så vi ska bara välja dem, och det kommer att ta dem upp i vår objektredigerare.
Nu är Oracle någonting som jag har arbetat med i åratal, vad jag ska visa dig är förmodligen ett enkelt uttalande för dig. Men om Oracle är plattformen, eller om PostgreS är plattformen, eller Teradata är den plattform som du just har fått och du måste komma snabbt, är uppgiften att lägga till en kolumn. Eller kanske är uppgiften att ta bort en kolumn. Men du behöver inte oroa dig för syntaxen, eller hur? Vi vill gå, bara skriva vad vi behöver, ställa in det och vi lämnar DBwartan att generera. Här kommer vi att trycka på "Alter." Det kommer att generera skriptet för oss. Återigen, ett mycket enkelt exempel, men poängen är att det kommer att göra jobbet för oss för att generera och placera den här kolumnen i tabellen.
Men vad vi också kan göra är att flytta kolumner runt i tabellen. Om du någonsin har försökt att göra det med det traditionella är det lite mer komplicerat än bara en enda kodrad som den här. Men igen kommer DBwartan att arbeta bakom kulisserna, generera koden åt dig och återigen producera SQL. Vi stänger härifrån. Innan jag gör det, lägg märke till alla flikar över toppen igen, användargränssnittet är väldigt intuitivt. Om jag kommer in i utforskaren, om jag hoppar ner till PostgreS, eller hur? Om jag går in i mitt schemaläge där, titta på bordet, mycket liknande utseende och känsla, eller hur? Vi öppnar det igen, igen får vi se informationen här. Egenskaperna, förfäder, kolumnerna. Vi är specifika för plattformen, vi kommer att ge dig detta, användargränssnittet, för att kunna visa detta och arbeta med objekten. Du kommer att veta vad du behöver göra, och det gör att du kan göra det på ett effektivt och snabbt sätt, så att du inte behöver oroa dig för exakt vad som är den klausul som måste gå dit för att ge det alternativet. Vi tar hand om det åt dig.
När vi tittar kommer jag också att hoppa till SQL Server nu och prata lite om några av de andra funktionerna, så vi måste alla övervaka databasen. Så igen, starta det, låt oss se alla sessioner som sker, sessioner som körs. Hur ska vi se vilka uttalanden som verkställs och kunna ha kontroll över det? Behöver vi stoppa en session? Behöver vi se några lås som kan finnas i databasen? Några spärrlås? Återigen har vi all den informationen här till hands för att vi snabbt kan reagera, vidta korrigerande åtgärder om det behövs och vända den. Vi kommer tillbaka till vår utforskare. Det är här, detta är drivpunkten, det är här jag alltid kommer tillbaka till, det är här jag personligen gillar att få saker igång och arbeta härifrån. När jag är ansluten till en SQL Server-databas för att titta på verktygen. Eftersom vi är platt-plattform kan vi börja titta på extraktioner, migreringar. Vi kan flytta över plattformar om vi behöver migrera objekt från en plattform till en annan, vi kan göra det, förutsatt att dessa objekt finns på de olika plattformarna. Extrahera schema, publicera till rapporter, ladda och lossa data och säkerhetskopiera databaser.
Återigen allt från UI. Och när du kommer hit till verktygen kan du se en komplett uppsättning verktyg som vi kan använda från, eller hur? Från "Hitta i filer" kan vi göra en fullständig databassökning där vi letar inuti systemtabellerna för att hitta den strängen som du söker efter. "Exekvering av skript och fil", om du har ett standarduttalande som kan köras mot flera plattformar, flera datakällor, kan vi ställa in det direkt från en DBwartan som pekar på de mål vi vill att den ska köras mot. Tryck på ”Gå” så kommer det att köras och få tillbaka resultaten mot alla dessa måldatakällor. Återigen, låter dig arbeta från den enda rutan med glas.
Och "Analyst Series", igen, de är mer djupgående. De är mer inriktade på relationella databaser när vi börjar komma in i fler av de nyare plattformarna. Du kommer också att börja se oss utöka denna funktionalitet till dessa arenor också. Och i allmänhet bara många förbättringar av användargränssnittet. Funktioner anpassade specifikt för DBA. Objekt som vi har möjlighet att göra ett skriptbibliotek.De SQL-skript som du kör ofta mot flera plattformar, spara det här, dra det, så snart vi får ett nytt ISQL-fönster, kan vi bara dra in skriptet och vi har nu skriptet redo att gå. Återigen, ha det till hands för att kunna göra och hantera. Du kommer att märka att vi levererar med skript som redan är definierade för några av plattformarna så att vi kan gå vidare och skapa så många vi behöver när som helst.
En trevlig sak som jag gillar och många av våra kunder gör, om du någonsin är intresserad, och jag får den här frågan mycket när det gäller: "Hur gör jag det? Det är ganska coolt. Hur gör DBwartan det? "Det finns en liten funktion här," Logfile ", du kan logga in alla SQL-uttalanden som vi kör, så om du vill veta hur vi fyller det utforskande eller hur vi fyller redigeraren för en PostgreSQL-tabell eller en Teradata-tabell, logga in SQL så registrerar vi allt som DBbrevan kör mot databasen och du kan komma tillbaka och titta på den SQL och ha allt vi behöver. Kanske vill du integrera det som en del av ett av dina skript. Absolut. Helt bra.
Vi gillar att vara väldigt öppen med vad vi gör och vad vi utför mot databasen, därför kommer vi att låta dig spara och spela in allt vi använder i databasen. Vi har också konfigurationsalternativ. Du kommer att märka att jag har den inställd som "Organisering av objektägare." Jag kan också ställa in med "Objekttyp." Om jag kom in i min PostgreSQL-miljö igen, gick jag in i schemat om jag tittade på SQL i stället för bara mina GIM-tabeller som tillhör det schemat, jag kommer att se alla tabellerna, oavsett schemanamn. Återigen, olika sätt att organisera saker som verkligen anpassar det för ditt eget arbetsflöde och hur du vill se det.
Och det sista jag vill prata om är förmågan att ställa in "Bokmärken." Om jag borrar in, om jag arbetar i en av mina plattformar och jag vill fokusera på bara mitt tabellläge, kan jag lägga till ett bokmärke. Jag vet, en väldigt enkel funktion, men så trevligt att ha, särskilt när du arbetar med så många datakällor och så många plattformar som dagens DBA är. För att kunna komma in i systemet, starta DBbrevan och låt bokmärkehanteraren ta dig rätt till platsen i trädet där du behöver vara och kunna arbeta. Och sedan härifrån kunde jag skapa ett nytt bord, och igen, på de plattformar som vi stöder som du såg tidigare, och vi kommer att leda dig genom "Wizard" för att låta dig driva och utveckla och skapa tabellen. Och vi kommer att generera all syntax som behövs för att göra det bakom kulisserna för dig och sedan presentera det för dig i slutet i ett förhandsgranskningsfönster. Du kan få validera, se exakt vad vi kommer att generera. Du kan trycka på "Kör" -knappen, sedan på "Slutför" -knappen, låt den köra. Eller så kan du spara det eller skjuta det till ett annat ISQL-fönster, så gör det igen, kanske det måste vara en del av ett större, ett större skript som du vill spara och distribuera under dina buntfönstertimmar.
Det är en översikt av DBbrevan. När vi pratar om det igen är det en produkt som har sett många plattformar, stöd för dessa plattformar och bra användarupplevelse, bra feedback från våra kunder också. Och om du är intresserad som en av paneldeltagarna, men om du behöver hitta något IDERA-relaterat eller DBwartan-relaterat, känn dig fri att nå ut och du kan säkert hitta mig på min adress.
Eric Kavanagh: Okej, jag antar att jag kommer att kasta det öppet för Robin för frågor och sedan Dez och sedan övervakar jag frågan och svaret från de deltagande. Robin, ta bort den.
Robin Bloor: Okej, jag menar, den första frågan, jag har faktiskt varit bekant med DBwartan ganska länge så jag är lite medveten om dess kapacitet. Det jag skulle vara intresserad av att du tar upp är dess, typ av framtida vägar härifrån. Jag menar, jag vet, du vet, förra gången jag tittade på det, måste det ha varit för länge sedan. Jag ser att du stöder åtminstone tre databaser som jag inte insåg att du stödde tidigare. Vad är framåtvägen för DBwartan? Är det troligt att du bara kommer att lägga till fler och fler databaser eller är det en funktion med förlängningsfunktioner? Var tänker du gå med det?
Scott Walz: Det är en fantastisk fråga och jag skulle vilja ha alla ovanstående. Vi kommer säkert att fortsätta bygga ut eftersom de traditionella RDBMS-plattformarna inte sitter stilla, eller hur? De fortsätter att bygga ut. Vi kommer att fortsätta följa den vägen. Och då ser du oss börja titta och gå i den riktningen för att stödja nya nya plattformar. Eftersom vi inser att även om vissa av dessa plattformar fortsätter att växa, den traditionella RDBMS, finns det vissa situationer som de nya plattformarna är rätt plattformar för kunderna att gå med. Vi håller verkligen noga med på den marknaden, på det segmentet och försöker fatta rätt beslut på vilka plattformar vi ska gå med. De verkar förändras varje dag, praktiskt taget.
Robin Bloor: Det är som både jag och Dez sa, det är en mycket livlig marknad, är kanske ett sätt att titta på. En annan sak som jag skulle vara intresserad av - uppenbarligen kommer du inte att kunna svara på denna fråga exakt, men jag har stött på webbplatser i min tid där det finns tusen instanser av Oracle, och Oracle var inte den enda databas som används, som distribuerades, du vet. Och när jag faktiskt pratade med dem om hur i världen hanterar du så många instanser som de sa: "Du vet, det finns bara cirka fem eller sex stora instanser och vi har ungefär tre DBA som vi sprider över det." Jag är intresserad av att använda DBwartan, eftersom du kan göra väldigt mycket med det, hur många databaser sitter det över, låt oss säga vanligtvis, eller till och med vad är de största exemplen på hur många strängar den kan hantera på en gång?
Scott Walz: Tja, jag har sett situationer - och igen, det är lite komplicerat, den frågan är, eftersom DBwartan tillåter mig att ha flera anslutningar eller flera datakällor definierade till en enda instans. Jag kanske vill göra en syslogin och sedan en inloggning med lägre behörigheter men jag har behandlat kunder som med allt kollapsade kommer det att bli flera skärmar. Nu när jag frågade dem det, är frågan som du ställde mig: "Hur hanterar du så många?" Och då säger han: "Jag gör det inte." "Jag klarar av vad jag kan, men jag behöver tillgång till allt." Jag ser ändå något som stoppar, du vet, de övre gränserna för vad människor kan hantera är verkligen den övre gränsen för vad den personen, individen, kan hantera. Men du vet, som jag nämnde, de människor som jag utmanar med, de medger öppet att de har alla dessa förbindelser men det finns inget sätt att de kan hantera det. De litar på sitt team. Som jag är säker på att du har upplevt, ja.
Robin Bloor: Jag har faktiskt varit en DBA själv, även om jag inte gjorde det så länge. Och en sak som du vet, jag minns, utöver allt annat i relationella databaser, är att du kan göra en enorm mängd saker med SQL. Ofta mer än du tror att du kunde. Som på ett eller annat sätt förklarar en del av funktionaliteten som DBbrevan har, eftersom det bara översätts direkt till SQL. Men du vet, jag är säker på att du gör andra saker. Det är allt SQL-skript eller finns det andra specialrutiner som har skrivits för esoteriska situationer?
Scott Walz: Ja, mycket av det, huvuddelen av det är SQL, det är bara det. Men vi skriver rutiner som kan köras från en kommandorad med hjälp av leverantörens verktyg, leverantörens frontändar. Vi lägger frontändarna på, du vet till exempel för datalastverktygen i plattformarna, eller hur? Det är inte SQL-skript, rätt, det är kommandoradsjobb. Det kommer att generera dem och kunna ge dem till DBA som de sedan kan köra. Se ja, vi kommer att göra lite av båda men majoriteten av det är SQL-skript.
Robin Bloor: När du tittar på, för uppenbarligen måste du på ett eller annat sätt ta en titt på den utveckling som pågår som jag anser vara ganska ny. Jag menar, en av de saker som jag tycker är intressant som händer är att Spark uppenbarligen tar fart som en raket, men Sparks SQL, det har gått från att vara hemskt omogen till att börja se lite mogenare ut med lite mer SQL-kapacitet. Ser du på sådana saker och undrar om du kommer att börja hantera dem med DBbrevan?
Scott Walz: Visst och det gör jag. Det är alltid där. Jag vet att vårt produktledningsteam alltid tittar på vart man ska åka och helt och hållet, allt ligger på bordet för oss, när det gäller vad vi tittar på i framtiden.
Robin Bloor: Okej Dez, vill du stapla in?
Dez Blanchfield: Ja, faktiskt finns det ett gäng fantastiska saker som du öppnade dörren för mig där, Robin. Tack så mycket. Jag är bara intresserad av att bara utforska några av de saker som hoppar ut när jag tittar på produkter som det här och jag blir väldigt upphetsad. När jag dubbelkontrollerade mina läxor, för som Dr. Robin Bloor nämnde tidigare, så har jag, liksom jag, spårat efter detta under en tid och jag minns att jag tittade på dina speciella krav häromdagen och tänkte, faktiskt, den här saken går på lutar av vad den faktiskt gör. Och jag tänker från minnet - korrigera mig om jag har fel - jag tror att det var så lite som att en bärbar datorprestanda bekvämt skulle köra DBwartan och ändå kunde den köra några ganska betydande databas baksidor. Och jag var ganska intresserad att se att du hade Firebird också nu och Greenplum. Jag var ganska imponerad av kravet eller specifikationen av hårdvaran som bokstavligen kunde köras som en gig RAM på en en gigahertz CPU. Det var ganska imponerande.
Men användningsfallen är något som jag bara vill gå in i lite. Ser du att upptaget av produkten är ett behov av behov på grund av befintliga miljöer som just har kommit ut ur kontroll, eller ser du att människor nu är lite mer proaktiva och säger, du vet, vi bygger något mycket stort, det är komplext. Och jag funderar på fusioner och förvärv till exempel här, där en organisation kan köpa ett gäng företag - små, medelstora, stora, vad som helst - och i slutändan ärva alla dessa miljöer och behöva bygga en ny DB-kapacitet. Vilka är de vanligaste användningsfallen för detta när det gäller organisationstypen och vilken applikationstyp det är? Är det övervägande människor som har befintliga miljöer och bara måste städa upp dem och få kontroll över dem eller är människor lite mer proaktiva och tänker på komplexiteten de ska bygga och få dig ombord tidigt?
Scott Walz: Vi ser mer om att komma igång tidigt av samma anledning som du nämnde, konsolideringen. Med den bredd av plattformsstöd som vi har är det inte en total framtida bevisning, rätt, men det sätter dig och dina DBA i en riktigt bra situation att när de ser på ett potentiellt förvärvsmål, eller så, de är lite mindre , du vet, tanken på vilka plattformar kan vi ärva, eller hur? Även om det är viktigt, eller så, är bekymret där lite mindre än vad det kommer att betyda för våra DBA, eller hur? DBA: er har en produkt nu när de vet att de kan ansluta sig och om de är bekanta med att använda produkten kommer de att bli bekanta med att ansluta till den plattformen som de just har förvärvat. Så det är verkligen ett område som vi ser, återigen vet du länge, kunderna med den här sammanslagningen av alla dessa plattformar, eller hur? Hur ska jag ta hand om det här, eller hur? Och de har provat det eftersom tankeprocessen är att alla plattformar har ett verktyg, eller hur? Vi kan använda vårt eget verktyg, eller hur? Men det kommer så småningom tillbaka att du vet vad, ja du kan, men inte bara kommer jag att behöva lära mig var och en av plattformarna, nu lär jag mig ett av de verktyg som följer med var och en av plattformarna och så du har precis förvärrat jobbet som en DBA. Så vi ser också den situationen där de kommer tillbaka till oss och säger: ”Du vet, vi måste ta hand om det här. Låt oss få ett verktyg för DBA, eftersom jag har viktigare saker för DBA att göra än att lära sig användargränssnittet för ett nytt verktyg. Eller olika verktyg. ”
Dez Blanchfield: Ja, nej definitivt. Och du vet, när du ser, tror jag från minnet när jag tittade igår bara för att dubbelkontrollera att jag inte hade fel, jag kommer ihåg att du har stött Sybase till exempel, så den här saken har funnits en liten stund. Det finns en annan fråga som jag hade till dig faktiskt bara - ja, det är fantastiskt att ha Greenplum och Firebird på din lista, men din Sybase, den typen av åldrar mycket snabbt, som visar att den har funnits ett tag och gjort ett bra jobb.
Kluster. Så en av de största huvudvärkarna för en DBA är att de kommer att peka på väsentligen vad som ser ut som en IP-adress och ett gäng API: er eller om det är JDBC eller LDBC eller vad vi än pratar med, men bakom det finns ett kluster. Vad kan, eller vet DBarusan om vad som ligger bakom dörr nummer ett, som det var, som när jag ansluter till databasen bakifrån, får jag se alla miljöer där bakom, och i synnerhet, så det finns två delar till fråga, kanske. Klustret, till exempel, när du tänker på, vet du, du stöder IBM DB2 och Microsoft SQL-databasserver och MySQL och PostgreSQL och Oracle och några av de traditionella RDBMS: erna, och du vet alltid att vi driver en master-slav eller master-master miljö för redundans och hög tillgänglighet och även prestanda. Vet DBbrevan att det finns något bakom dörren nummer en som inte bara är en databas i sig, utan ett kluster, och i så fall, vad vet den om det? Och att flöda in i det snabbt så att du kan svara på samma fråga, ledsen. Så, bakom klusterna i några av de scenarier du har, hur hanterar människor blandningen mellan produktionsmiljöer och miljöer för återhämtning av katastrofer, såvitt DBwartans användning går?
Scott Walz: Stora frågor. Jag kommer att ge dig det kommer att vara beroende av de specifika plattformarna eftersom så mycket som vi försöker kommer vi att ha olika nivåer av stöd för några av dessa djupgående och djupare funktioner. För till exempel Oracle och deras RAC-miljö, Real Application Cluster, kan du ansluta till den primära noden i det klustret men ändå gå igenom databasmonitorn som jag visade, vi kommer att låta dig se SQL kör och vi " kommer faktiskt att berätta vilken nod i klustret den kör på, eller hur? För att låta dig se exakt om, du vet, en långsam körning, låt oss hålla ett öga på det, vilken nod körs den på? Eftersom oundvikligen hela anledningen till klustret, rätt, är för slutanvändaren, bryr han sig inte var den har utförts, men för DBA måste vi hålla reda på den typen av information. Vi kan till exempel gå ner till den detaljeringsnivån i Oracle. De andra plattformarna som vi har anslutning, förmodligen inte så mycket detaljer än vi gör för Oracle.
När det gäller produktion och utvecklingsmiljö är det en bra fråga. Vi ger samma stödnivå. Det verkliga primära sättet att vi ska hjälpa till, anslutningsskiktet kommer att vara där, eller hur? Vi kommer att kunna ansluta och göra alla funktioner. Jag har kunder som använder några av funktionerna i DBwartan för att kategorisera sina datakällor, eller hur? Och igen, detta kan vara lite för den exakta frågan du ställer, men vi kommer att göra det möjligt för dem att grafiskt beteckna när de arbetar. Eftersom det är en av sakerna med DBwartan, är att jag snabbt kan byta mellan datakällor. Och nästa sak du vet att jag är redo att köra ett trunkerande uttalande och jag ser att jag är ansluten - körde jag detta mot produktion eller utveckling? Och så tillhandahåller vi några funktioner inom DBwartan för att hjälpa DBA: s där ute och hantera det och hålla dem ur problem, om du vill, med några av DBA-aktiviteterna.
Dez Blanchfield: Med det i åtanke, på den långa listan med plattformar som du för närvarande stöder, och jag är säker på att det kommer att explodera mycket snart av uppenbara skäl. Jag menar, du stöder sådana som säger DB2 på z / OS till exempel på mainframe, och sedan stöder du uppenbarligen sådana som vi brukade kalla mellanklass men nu bara UNIX-system och slags modernare plattformar, du vet Linux, och så småningom kommer det att överföras till Bluemix och Cloud Foundry, så du kommer att hamna med DB2 som körs på Cloud Foundry på Bluemix, med IBM och molnet på soft. Kör människor för närvarande inte bara hantering och övervakning, utan också du nämnde innan möjligheten att migrera och flytta data runt. Ser du att folk hoppar i sängen med DBwartan och säger: "Vet du vad, vi har en massa saker på de gamla stordatorerna som vi bara behöver gå av och det var ett riktigt problem att göra det. Om jag kan peka, klicka och dra härifrån och dit kan jag faktiskt flytta och migrera mina data och mitt schema. ”Är det något som folk gör?
Scott Walz: De rör sig verkligen, eller hur? De flyttar uppgifterna, eller hur? Nu använder de DBracyan som ett verktyg för det. Gör det allt för dem? Nej. Vi börjar, du vet, dra och släpp, inte precis där, men vi gör det möjligt för dem att generera några skript, för idealiskt kommer du att vilja använda - du vill inte att det här jobbet ska vara kör på din klient, på din bärbara dator, just av den anledningen du nämnde. Vi kan springa på en mycket låg fot, eller hur? Vi hjälper dem att skapa skript och sedan vända det och bygga det och sedan kan de leverera det skriptet och få det kört på servern, eller hur? Och få kraften, hästkraften bakom servern för att göra det. Vi hjälper dem att skapa några av sina jobb för att göra något av det arbetet.
Dez Blanchfield: Höger. Ett par sista till dig och då kan vi komma tillbaka. Det som verkligen slog mig genom att gå igenom ditt tillägg, vilket är fantastiskt, och i själva verket önskar jag att vi hade ytterligare en timme att gå mer i detalj. En riktigt stor utmaning för DBA, rätt, är grundläggande efterlevnad, övergripande styrning av infrastrukturen, granskningarna, rapportering om nuvarande tillstånd, titta på framtida prepping för saker som, du vet, bara allmän tillväxt av miljön. Det slår mig att även om det i kärnan i vad din produkt verkar göra, som bara gör livet enkelt, så är det en enda ruta av glas, en enda bild av världen, och jag kan i princip klicka och peka och dra och jag älskar det faktum att jag kunde utbilda någon att göra detta mycket snabbt nu, de behöver inte läsa manualen som den var.Det slår mig att verktyget också ger mig förmågan att göra en hel massa saker kring styrning och efterlevnad och granskningar, som jag undrar om folk verkligen har vaknat upp till det, jag är säker på att de har det.
Men ser du folk nu titta på det och gå, och det är som det här eureka, a-ha-ögonblicket, går, "Hej, du vet vad, detta gör DBA: s liv verkligen enkelt från nu, eller lättare ur en operativ synvinkel eller utvecklingssynpunkt. Men jag kan faktiskt bara rapportera om alla våra databaser nu och alla datauppsättningar och alla innehållslösa data och alla metadata runt omkring. Som vem har tillgång, när de har tillgång, varför de har tillgång och vilken typ av tillgång de har. ”Och sedan plötsligt, ta itu med några av utmaningarna om efterlevnad. Särskilt när vi har riktigt stora saker som händer kring dataöverträdelser. Vi har några fantastiska saker som de globala finansiella kriserna, alla dessa utmaningar kommer till men hur i all världen ska vi mäta och övervaka och hantera efterlevnad? Är det den typen av stor sak för människor ännu eller är det fortfarande, typ av, tidiga dagar så långt som att använda DBbrevan på det?
Scott Walz: Jag har kunder som inte kan säga tillräckligt om DBbrevan. Nu är det de som har insett det. Glödlampan är på. De säger: ”Vänta lite. Jag kan svara och svara och skapa några av de mycket rapporter du nämnde, rätt, allt från ett verktyg. Jag har det. ”Nu finns det andra som fortfarande kommer att fånga det och det kan vara av olika skäl, eller hur? De kanske inte är ännu eller kanske det hanteras av någon annan, men våra kunder som vi har hittat som använder det, det är ett a-ha ögonblick, eller hur? Det är inte bara jag som kan skapa en tabell över allt detta. Och absolut, med alla efterlevnadskrav, är det enormt. Det är ett jobb i sig själv.
Dez Blanchfield: Ja, verkligen. Och du vet, jag menar, från toppen av mitt huvud tänker jag omedelbart, du vet, om det finns någon som kommer med och säger att de ville skapa en konfigurationshanteringsdatabas, CMD, om de måste uppfylla allt från Sarbanes -Oxley till COBIT till ITIL, du vet, SWIFT-överensstämmelse och banker, till och med att gå ner till sådana som International Standards Organization, ISO 27001, 27002. Det är alla dessa riktigt stora ramar. En av utmaningarna är bara att hitta var data är, vem som hanterar det, vilket format det är i och jag tänker, det har för mig, som för mig som bara tittar på det nu när eureka-ögonblicket bara gick, det var som, hänga på en sekund kunde jag kasta in detta till och med någon som inte nödvändigtvis är en DBA, men jag kunde snabbt träna upp honom och säga, ”Det finns ett verktyg för efterlevnad.” Jag tycker att det är fantastiskt att det gör sitt jobb i en administrationsdatabas ledningsvärld.
Men jag sitter här och tänker, gud, du vet, det faktum att du kan hantera flera plattformar som en i dessa dagar, och du kan dyka ner i, som sagt, logga in de transaktioner du gör. Du vet, föreställ dig att ta det här verktyget i en datainbrottshändelse och du har ditt säkerhetsteam springer runt och försöker hitta vad som är var och varför, och vem har sett vad. Och när de rör sig måste de logga in och spåra alla åtgärder de gör för de kan bli en del av problemet om de inte kan göra något annat. Ja, jag tror att det är en otrolig förmåga här att du omedelbart skulle kunna börja göra, du vet. Särskilt när vi tittar på utmaningarna med dataanalyser som du känner, har vi detta massivt som en funktionskryp, som det var, med datauppsättningar och data.
Och en av de saker som vi har pratat om i ett annat par shower vi har gjort är, du vet, hur går du och hittar dina data och ofta pratar vi om det faktum att när du börjar i någon organisation tenderar du att stå upp i din skåp och lägg handen i luften och vinka och gå, "Vet någon var denna databas är? Hur kommer jag till den här datakällan? Var är den här filen? "" Gå och fråga mottagning. "Rätt? Ditt verktyg kan omedelbart ge den förmågan att hitta saker och upptäcka dem och till och med rapportera om dem.
Tillbaka till en av frågorna bara kort och sedan kommer jag att samla in och lämna tillbaka till Eric. Det slår mig att skalan kommer att bli en utmaning under nästa, 12 månader för dig. Kan du ge oss lite inblick, bara på en trettusen tusen fot synvinkel, antar jag, i den skala eller skala som DBwartan har kommit att fungera. Jag kan föreställa mig att när jag lägger detta på min bärbara dator och jag vaggar upp och jag riktar det mot en miljö så kan jag upptäcka det och jag kan börja göra saker på det. Jag kan föreställa mig att det går från en enda liten, du vet, open source minuscule databasmotor med några rader och tabeller. Vilken skala skulle den gå upp till? Du pratade om DB2 på stordatorer, det är stort. Och kluster. Hur stor skala kan vi här hantera? Och Robin berörde sånt tidigare, men jag behöver bara gå in på det mer detaljerat för hur stort vi kan få med DBwartan.
Scott Walz: Säker. Det kommer verkligen att vara dina utmaningar eftersom det är ett klientprogram. Och så, igen, om jag arbetar med en stordator, när jag arbetar mot vårt testsystem på det stordator som vi har, kan jag peka det mot miljoner rader och göra en korssamling mot miljoner rader. Allt arbete kommer att göras på en server, rätt, för vi skickar det kommandot, och det är bara en fråga om DBwartan hanterar resultatuppsättningarna, eller hur? Och så är det utmaningen, och det är skönheten, rätt, för det vi gör. Det mesta av det tunga lyftet sker på servern. Vi hanterar bara alla resultat. Och så återigen, du kommer naturligtvis i situationer när du vill köra tio frågor samtidigt som alla returnerar miljontals rader, ja absolut, du kanske känner dig själv i någon prestanda där, eller hur? Men jag har inte på något tillfälle att kunder är borta från att köra stora frågor mot DBwartan, du vet, mot deras databas. Återigen, som sagt, varierar körsträckan beroende på många faktorer, rätt, men återigen, som sagt, har jag att göra med miljoner rader som kommer tillbaka och så länge det fyller upp nätet, du vet, jag " m redo att gå. Men ibland måste jag självklart vänta på att resultaten kommer tillbaka.
Dez Blanchfield: Jag har en fråga till dig innan jag slutar, för jag har tagit för mycket av din tid och tack för det. Berätta bara lite mer runt, du vet att du läste de senaste specifikationerna igår bara för att se till att jag var så bra som jag trodde att jag var. Processövervakning och typ av varningar och meddelanden, du vet, kapacitetsplanering tar upp alla massiva problem med DBA: er, hela dagen varje dag, du vet. Kommer någon att fylla i den här tabellen, kommer han att fylla i databasen, kommer de att fylla på det diskutrymme jag har, hur hanterar jag det? Ge oss en snabb översikt över typ av processövervakning och särskilt övervakning av varningar och sedan idealiskt kring kapacitetsplanering. Jag tror att det är ett område som jag tror att det kan finnas mycket intresse för.
Scott Walz: Processövervakning visade förmodligen att den funktion som majoriteten av vår kundbas använder och det är en databasmonitor för att kunna visa och göra det. Och vi har några i analytikerpaketet. Performance Analyst har några varningar du kan ställa in när vissa trösklar uppfylls. Det kan varna dig. Kanske X antal loggar, fel i loggfilen, du vet, det kommer att få en varning för dig. Tabellutrymmet träffar en viss procentandel full, du kan få en ny varning. Och det vackra med det är att du är i samma verktyg, rätt, det är en del av DBwartan så att du bara högerklickar på felet, varningen och du hanterar med DBwartan och det tar dig rätt till tabellutrymmet redigeraren . Och du kan ta itu med problemet där.
När det gäller kapacitet, det är absolut en snabb knapp, och kapacitetsanalytiker som vi har för närvarande, portas till SQL Server, Oracle, DB2 LUW och Sybase ASE. Och det gör exakt vad du beskrev. Du kan börja, när vi har fått några samlingar, rätt, och när vi en gång får en provstorlek, och kanske dess radstorlek, kanske dess objektantal, massor av alternativ i verktyget, och sedan kan du börja trender, eller hur? Och hur kommer det att se ut om sex månader? Hur kommer det att se ut om tolv månader? Jag kan trenda till, bara trenda till ett datum eller jag kan trenda till ett värde, eller hur? Och ett exempel du hade, jag har X mängd diskutrymme, baserat på det, när ska jag träffa den gränsen? Baserat på den tillväxt som jag har och dessa samlingar som jag har gjort, när ska jag nå den gränsen? Åtminstone vet jag att jag kan börja planera för det. Kommer det att vara sex månader, kommer det att bli två år? Men återigen kan vi använda kapacitetsanalytiker för att trenda mot det.
Dez Blanchfield: Det är jättebra. Fantastisk demo. Jag njöt verkligen. Jag kommer att gå tillbaka till Eric eftersom jag vet att det finns ett par frågor som har dykt upp från vår fantastiska publik idag. Tack så mycket, det har varit riktigt bra att lära känna produkten väl, och jag ser fram emot att hålla ett mycket nära öga på den.
Eric Kavanagh: Okay bra. Vi har ett par bra frågor. Och vi kommer lite över tiden så vi kommer att försöka sluta snabbt för jag vet, Scott, du har ett stängt hårt stopp. Här är en stor fråga. Vad sägs om att arbeta på gamla datalagrar som VSAM och Model 205, och IMS och IDMF och sådana saker? Ser du det mycket ofta i dag och hur bra fungerar det?
Scott Walz: Jag vill inte säga att du har fastnat. Vissa av dessa miljöer, om de har ODBC eller JDBC och jag vet att några av dem är ute, vi kan ansluta till det och du kan arbeta med det på det sättet. Men för det mesta är den gröna skärmen vägen att gå stilla.
Dez Blanchfield: Jag älskar den gröna skärmen.
Eric Kavanagh: Du vet, som Dez påpekade med den ena bilden, där han hade alla de olika applikationerna och verktygen som finns tillgängliga idag, det är en väldigt skrämmande verklighet för alla som vill ansvarsfullt utföra en databasadministratörs funktion. Och jag antar att ni med tiden kan bygga anslutningar till något av dessa verktyg när och när kunder kräver, och så vidare, eller hur? Så att du aktiverar den ena glasrutan.
Scott Walz: Och det var den stora nyckeln bakom att göra DBwartan utrustad för att kunna hantera dessa JDBC- och ODBC-anslutningar. Vi har verkligen utökat det nu. Nu, så länge vi har den anslutningen, eller så länge vi har den föraren, kan vi ansluta och arbeta mot den.
Eric Kavanagh: Det är bra grejer. Tja folkens, vi arkiverar alla dessa för senare visning. Jag publicerade en länk till bilderna, förhoppningsvis kan du se det via SlideShare. Tack så mycket för alla dina ansträngningar, mina herrar. Underbar webcast idag igen. Många bra bilder. Mycket bra innehåll. Jag älskade den demonstrationen. Det är verkligen lite intressant att ni har riktat in sig på en väldigt söt plats på marknaden eftersom det finns en sådan explosion av databastyper i dag. Och vi behöver bara som chefer någon plats att hantera allt detta. Bra jobbat killar. Vi hämtar dig i morgon för en annan Hot Technologies. Förhoppningsvis har du tagit ut en timme imorgon. Samma tid. Samma station. Vi kommer att komma ikapp dig nästa gång, folkens. Ta hand om dig. Hejdå.