Door Techopedia Staff, 24 augustus 2016
Takeaway: Host Eric Kavanagh bespreekt database trends met Dr. Robin Bloor, Dez Blanchfield en Scott Walz in deze aflevering van Hot Technologies.
Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.
Eric Kavanagh: Dames en heren, hallo en welkom terug bij de heetste show in de wereld van enterprise IT, Hot Technologies van 2016. Ja, inderdaad! Mijn naam is Eric Kavanagh, ik zal vandaag je gastheer zijn voor een show getiteld "The Art of Visibility: Enabling Multi-Platform Management", inderdaad. Een paar snelle opmerkingen, er is echt een dia over die van jou, toegegeven van vijf jaar geleden en genoeg over mij, sloeg me op Twitter @Eric_Kavanagh. Het is een warm jaar, dit is onze standaard dia voor Hot Technologies. Wat we met deze show hebben gedaan, is dat we een programma wilden dat ons zou helpen een bepaald soort technologie te definiëren, dus het hele idee is dat we twee analisten krijgen die binnenkomen en hun mening geven over een bepaalde ruimte of een bepaald type functie die de onderneming nodig heeft, en dan komt de leverancier binnen en laat zien wat ze hebben gebouwd en legt uit hoe het aansluit op wat u van de analisten hoort.
En de reden daarvoor is, zoals je je misschien kunt voorstellen, omdat er in de wereld van enterprise software marketing termen zijn die overvallen en wat er altijd gebeurt, is dat leveranciers zich vastklampen aan de nieuwste hot term, dingen zoals big data of analyse voor bijvoorbeeld, of zelfs SOA of andere termen zoals platform, en soms zijn die woorden zeer nauwkeurig voor een bepaalde technologie en soms zijn ze dat niet. Deze show is ontworpen om ons echt te helpen articuleren voor u, het publiek, wat specifieke soorten technologieën doen, hoe ze werken en wanneer u ze moet toepassen.
Daarmee ga ik onze sprekers voorstellen. We hebben onze eigen Dr. Robin Bloor, die belt vanuit zijn locatie in Austin, Texas, Dez Blanchfield, belt vanuit de andere kant van de planeet, en onze gast Scott Walz belt vanuit Kentucky. En de jouwe echt, ik sta eigenlijk buiten Pittsburgh, dus we hebben vandaag een volledig geolocatieorganisatie vanuit meerdere verschillende plaatsen. Daarmee ga ik Robin's eerste dia duwen, voel je vrij om trouwens vragen te stellen, mensen, wees niet verlegen. U kunt dit doen met behulp van de Q & A-component van uw webcastconsole. En daarmee geef ik het door aan Dr. Bloor. De vloer is van jou.
Robin Bloor: Oké, bedankt voor die introductie, Eric. Laat me even naar de eerste dia gaan. Dit is een verzameling stokstaartjes die nadenken over een database. De hele presentatie die ik hier doe, is eigenlijk gewoon een algemene set van gedachten over de database die ik onlangs heb gehad, met als punt dat het echt rond het jaar 2000 leek alsof de database-game in die zin voorbij was dat de overgrote meerderheid van database-implementaties plaatsvond op relationele database. En toen veranderde het gewoon, weet je, al deze dingen waar de stokstaartjes over nadenken, kolomarchieven, sleutelwaardewinkels, documentdatabases, in-memory database, grafiekdatabase, en er kwamen plots veel meer dingen naar voren. En het was bijna als een nieuw soort geologisch tijdperk waarin fossielen van verschillende soorten dieren plotseling verschenen.
Het nieuws van Lake Wobegon, het is echt voorbij voor de enkele modeldatabase. Er is geen twijfel dat RDBMS nog steeds domineert, maar andere soorten databases zijn nu opgezet. Echt, dat is zo'n beetje het overzicht van wat ik hier ga zeggen.
De dimensies van de database, sommige daarvan zijn recentelijk zelfs belangrijker geworden, maar degene die ik kon bedenken toen ik deze dia maakte, was het in ieder geval opgeschaald in termen van efficiënt gebruik van de bronnen van een bepaalde server? Schaalt het op zodat het over grote clusters kan gaan? Maakt het gebruik van de beschikbare hardware die een soort in-memory-databases in die richting gaat? Is het te verdelen? Er zijn een aantal databases die belangrijk zijn om te verspreiden. Wat voor soort eigenschappen heeft het? Het fundamentele ACID-kenmerk van de database. Maar nu, in plaats van daadwerkelijke consistentie, hebben een aantal databases uiteindelijk consistentie, mensen gebruiken ze en ze hebben er geen probleem mee, dus ze hebben aangetoond dat ACID niet absoluut noodzakelijk was, gewoon een goede zaak in een veel situaties.
Wat de metadata-organisatie betreft, is de hele game veranderd. We hebben verschillende metadata-organisaties in plaats van een typisch RDBMS-schema. In termen van de optimizer is er ontzettend veel optimalisatie-activiteit gaande, afhankelijk van de datastructuren die u probeert te optimaliseren. Wat betreft de beheersbaarheid, hier zit veel variatie in waar ik later op terug zal komen, maar in principe is het hele punt van een DBMS beheersbaar en opnieuw bepaalt de mate van beheersbaarheid tot op zekere hoogte de mate van bruikbaarheid.
In termen van hardwarefactoren is dit het punt dat echt zegt - ik bedoel, er wordt hier maar één punt gemaakt - het punt dat hier wordt gemaakt, is dat wat we vandaag bekijken in termen van database-architecturen gaat veranderen. Het kunnen dezelfde databases zijn, maar ze zullen op de een of andere manier rekening moeten houden met wat er feitelijk gaande is op hardwareniveau. Vele, vele jaren hadden we deze relatief eenvoudige situatie van CPU, geheugen en draaiende schijf - nou dat is echt weg.
Het punt dat hier is, we hebben allereerst CPU's, maar ze zijn veel meer parallelle mogelijkheden dan voorheen met veel, veel verschillende verwerkingskernen. We hebben ook GPU's, we hebben ook FPGA's, verschillende soorten silicium, maar Intel is in de volgende release met één FPGA getrouwd met een CPU en - EN - heeft GPU en CPU's samen op dezelfde chip getrouwd. Je hebt chips met verschillende kenmerken. Het voordeel van een GPU is dat het echt geweldig is voor zware parallelliteit en met name bij numerieke berekeningen. Met FPGA's kunt u op een of andere manier de code op de chip plaatsen en deze werkt veel sneller dan wanneer u deze gewoon aan de chip toevoert.
Er vindt een kruising van deze dingen plaats. We hebben 3D XPoint van Intel en PCM van IBM. Dit zijn nieuwe soorten geheugen, langzamer dan RAM, minder duur dan RAM maar niet-vluchtig. En deze creëren een beetje opwinding bij een aantal softwareleveranciers waarmee ik heb gesproken. We hebben SSD's, maar nu worden ze heel, heel groot en bieden ze parallelle toegang. Met parallelle toegang tot een zeer grote SSD kunt u leessnelheden benaderen die vergelijkbaar zijn met RAM-leessnelheden. We hebben deze mogelijkheid van drie soorten opslag-RAM, de 3D XPoint-dingen en SSD's, die allemaal extreem snel gaan. En aangezien snelheid de essentie van database is, zal alle database-technologie proberen deze zo snel mogelijk te benutten. En dat gaat gepaard gaan met parallelle architectuur, maar schaalbare parallelle architectuur. De prestaties op hardwareniveau worden steeds sneller, doen dit al jaren, blijven dit doen en de algemene kosten dalen.
Pad van tranen. Dit zijn gewoon verschillende pogingen tot databases, de eerste databases vóór relationele werden over het algemeen netwerkdatabases genoemd, daarna kwamen relationele databases, daarna objectdatabases, ze kregen niet veel tractie, daarna kwamen de kolomarchiefdatabases die waren relationele databases heel anders gedaan. En toen hadden we de documentdatabases en de SQL-databases die objectdatabases waren, anders gedaan, of, als u dat wilt, dezelfde kolom met objectdatabases en ze volgden. En onlangs hebben we grafische databases verkregen die tractie- en RDF-databases kregen. En waar u naar kijkt, zijn ten minste drie verschillende sets gegevensstructuren die worden ondergebracht. De relationele database doet tabellen en rijen erg goed. De documentdatabase en objectdatabases - ze doen onhandige gegevensstructuur, met name hiërarchische gegevensstructuren, zeer goed. En grafische databases en RDF-databases werken heel goed in netwerkdatastructuren. En deze verschillende, ik denk aan hen als drie lijnen, deze lijnen zullen voor onbepaalde tijd doorgaan. Het zal niet stoppen omdat de motoren die deze dingen goed doen niet goed werken op de andere gegevensstructuur.
En dan hebben we de bederffactor van Hadoop. Hadoop is geen database, maar er zijn databases die HDFS gebruiken voor hun opslagstructuur. En veel dingen die Hadoop doet, zijn het soort beheerzaken dat moet worden gedaan voor een database. Ook vermeldenswaard dat Spark ook geen database is, maar wel, en het is een onvolwassen, maar het heeft een SQL-optimizer en daarom is het als de kernel van een database zonder noodzakelijk te weten waar je de gegevens gaat opslaan, maar als u het op HDFS houdt, wordt aan veel van de databasevereisten voldaan, simpelweg door de mogelijkheden van het onderliggende bestandssysteem. Vooral Spark is onderdeel geworden van het database-ecosysteem en wordt vaak samengevoegd met krachtigere databases, en de reden daarvoor is eigenlijk analyse. Analytics - Spark is, nou ja, het gaat heel, heel snel in analyses. Analytics is de belangrijkste toepassing waarin de meeste mensen nu investeren, dus de twee lopen hand in hand. Datafederatie in plaats van concentratieregels, het moet duidelijk zijn uit het feit dat je ten minste drie verschillende behoeften hebt, gestructureerde soorten databases die er zijn en daarom datafederatie als je de gegevens met hen wilt delen. Het is vaak nodig, maar je hebt ook databases die schaalbaar zijn en databases die dat niet doen, echt krachtige engines zoals Teradata of Vertica hebben een heel specifieke plek, maar kleinere engines die heel veel werk kunnen doen, dus federatie is er waarschijnlijk voor een lange, lange tijd, zelfs tussen relationele databases.
Het laatste ding om te zeggen, het IoT, het is nog niet voorbij totdat de dikke dame gegevens begint te ontladen. Het IoT kan op de een of andere manier een andere dynamiek in de database-wereld creëren en dat zal de zaken nog ingewikkelder maken. Hopelijk komt er - op de een of andere manier - een soort convergentie aan de gang, maar ik zie het niet allemaal samenkomen zoals bij de relationele databases. Hoe dan ook niet snel.
En ik denk dat dat alles is wat ik te zeggen heb, dus ik zal het overhandigen aan Australië.
Dez Blanchfield: Bedankt, Robin. Bedankt aan iedereen voor het meedoen, bedankt voor het vanmorgen, of vanmiddag jullie tijd. Dit is een heel actueel onderwerp, omdat we de afgelopen tien jaar nogal wat explosies hebben meegemaakt, wat betreft de hoeveelheid gegevens waarmee we te maken hebben, en steevast dat de gegevens zich in een systeemvorm bevinden dat in de meeste gevallen is een database van een of andere vorm. Ik dacht dat ik ons snel door een heel hoog niveau zou leiden door hoe we hier kwamen en het probleem dat wordt gecreëerd en de soorten dingen die we nu moeten aanpakken, en dan gaan we het hebben over de soorten oplossing die daarop kan worden toegepast. Laat me gewoon mijn eerste dia hier pakken. Ik ben van mening dat we nu op het punt zijn dat DB admin 2.0, of database admin 2.0, een beetje is waar we nu een beetje zijn, ooit was een databasebeheerder een vrij eenvoudige rol en uitdaging en je zou vrij snel iemand kunnen trainen. In de wereld van vandaag is dat niet langer het geval en ik ga je laten zien waarom dat zo is.
Er was eens een databasebeheerder die in staat zou zijn om verbinding te maken met de back-end van de DB en een snelle showdatabase te maken en er zou een lijst met databases in het systeem zijn waar ze zich bewust van moesten zijn en ze konden heel snel overkomen die databases en selecteer ze en heb een beetje een por en een sonde in de buurt en gebruik vertalen, tabel beschrijven om erachter te komen wat er in een tabel en elk van de kolommen en rijen zit, en het was een relatief eenvoudige uitdaging en als je het gemiddelde leest twee- of driehonderd pagina's tellend boek over databasebeheer voor elk platform, je was in staat om bijna jezelf te onderwijzen zonder een diploma in raketwetenschap te hoeven halen.
Maar dat is niet langer het geval, en de reden daarvoor is naar mijn mening dat er gewoon veel te veel opties in de databasewereld zijn voor een persoon om expert of specialist te zijn bij en om handmatig te kunnen beheren en beheren . En de reden daarvoor is dat we de afgelopen vier tot vijf decennia op het gebied van servers en databasesystemen en databaseservers en applicatiesuites een heel, heel lange weg hebben afgelegd. Er was eens een groot ijzer dat te maken had met wat eigenlijk kleine data was, en lachend klein als we nu terugkijken. Ik zag onlangs een heel nette foto op Twitter, van deze geweldige dame die de hoofdprogrammeur en ontwikkelaar was voor NASA op het moment dat we mannen op de maan zetten, en haar code werd afgedrukt in honderddertig twee kolomlijnprinters en waaiervormig gevouwen, en het was eigenlijk groter dan ze was, de hoeveelheid code die ze schreef.
En toen ik erover nadacht, dacht ik, eigenlijk is dat waarschijnlijk ongeveer twee- of driehonderd megabyte aan gegevens waar ze het hoogstens, zo niet minder, allemaal in moest typen. En dus was de totale hoeveelheid gegevens om haar code vast te houden, hoewel deze fysiek groter was dan zij toen deze op papier werd afgedrukt, eigenlijk een heel, heel kleine hoeveelheid. Zelfs deze enorme computers in de ruimte, en dit is een IBM System / 360 in deze specifieke dia, de hoeveelheid gegevens die het daadwerkelijk kon bevatten was klein in vergelijking met de wereld van vandaag. In feite hebben onze smartphones een capaciteit van 60 en 128 en 256 gig en we zullen binnenkort terabytes in onze telefoons hebben als de prijs van flash omlaag gaat.
En dus was het databasebeheer in die tijd en dat tijdperk vrij eenvoudig. Hier is een momentopname van een 3270 terminalsessie, en voor een DBA, in staat zijn om in te loggen en te kijken naar het aantal bestanden dat gerelateerd was aan de database, en de indexen die er waren en de rijen en kolommen waren eenvoudig. En u kunt hier in dit screenshot zien dat de context hiervan één tabel en een aantal tabelruimten is, dat zou het hele mainframe zijn geweest dat één databasetabel beheert. Terwijl we vandaag miljarden rijen records in databasesystemen bewaren. En de verandering kwam tot stand door een technologische verandering waardoor we databaseplatforms en gegevensbeheersystemen konden bouwen.
Als we denken aan het soort originele mainframes en veel computers met database en uiteindelijk relationele databases, dus meer dan vijftig jaar geleden, en die grote ijzeren wereld en de kleine datasets die we hadden, tegen de tijd dat we rond de jaren tachtig kwamen, we waren een beetje bij, we gingen door de mainframes van de mini naar de micro, en we hadden pc's met dingen als dBase II en dBase III, en op DOS en CP / M en we hadden een zeer vroege relationele database- beschikbare stijltechnologieën en deze zijn redelijk goed geschaald in vergelijking met wat we in het mainframe gewend waren. Tegen de tijd dat we in de jaren negentig aankwamen, hadden we zoals Oracle en DB2. En eind jaren negentig hadden we mensen, zoals geheime computers die als een netwerkmodel konden lijmen, heel, heel grote machines, machines ter grootte van een kast samen en nemen dergelijke computers en bouwen deze. Maar zelfs toen was het nog steeds klein in vergelijking met wat we vandaag zien.
Maar in de dia die ik hier heb, is dit het Hadoop-cluster en werkt het effectief als één machine en in wezen is het gewoon een heel, heel grote computer en het kan de soorten webschaalgegevens bevatten die we nu gewend zijn . En dus is de uitdaging van databasebeheer, databasebeheer op dat soort platforms inderdaad, in mijn ogen, raketwetenschap geworden. Je moet een buitengewoon slim personage zijn om de technologie te begrijpen waarop het draait, het platform waarop het draait, de gegevens die erin staan, de soorten gebruik van die gegevens. En ja, we zagen deze explosie vanaf het begin van de jaren 2000, waar Microsoft SQL een ding werd, Lotus Notes was behoorlijk goed ingeburgerd en daar en het aantal Lotus Notes-databases dat rond de plek sloop was behoorlijk beangstigend. En we hadden de gebruikelijke gevestigde exploitanten van Oracle en DB2 en begonnen echt vast te houden. Sommige van de merken zoals begonnen te vervagen. Maar we deden nog steeds echt gewoon traditionele database-administratie tot op dat moment, rond dat soort 2006-tijdperk waarin, als ik terug zou gaan naar dat beeld van dat cluster, we hadden wat we Beowulf-clusters noemden een ding werden, waar we konden neem kant-en-klare pc's en lijm ze aan elkaar en maak grote supercomputers.
Maar vanaf dat punt passeerden we een omslagpunt waar mensen ouderwetse database-administratie konden uitvoeren en - zoals ik zeg, naar mijn mening - werd de schaal zeer, zeer groot, zeer snel. Het is bijna alsof we dit oerknalevenement in de technologie hebben gehad dat heeft geleid tot de acceptatie van datatechnologie en datamanagementtechnologie en in het bijzonder de databases eromheen. En omdat we in feite krachtige rekenclusters aan het bouwen waren om gegevens in verschillende vormen te hosten. En om dat punt te onderstrepen, hier is een momentopname van het landschap vanaf 2016 van databasetechnologieën die voor ons beschikbaar zijn. Variërend van de rechteronderhoek en open source, helemaal tot de linkerbovenhoek in de infrastructuur. En in de rechterbovenhoek in applicatieoplossingen die voor ons beschikbaar zijn, en in de linkerbenedenhoek, een combinatie van de infrastructuur en performance-engines die analyses uitvoeren, enzovoort. En in het midden zijn er natuurlijk de apparaten zoals onze smartphones, die eigenlijk op zeer kleine versies van databases draaien, om dingen te doen zoals het beheren van onze contacten, enzovoort, of onze oproeplogboeken en andere dingen die we hebben.
En dus in mijn gedachten was er deze explosie, een soort Cambrische explosie in dat soort dingen, waarbij de hoeveelheid technologische ontwikkeling die plaatsvond in die zeer korte periode van ongeveer 2006 tot 2016 nu, die eigenlijk een decennium is, als het ware. We hebben nu gezien dat grafische databases een groot iets worden, in-memory-databases een groot ding worden, SQL-databases komen eraan. De overstap naar verschillende computermodellen, Hadoop kwam tot stand, we hadden het MapReduce-model, nu hebben we Spark- en streaming-analyses en streaming-computers, veerkrachtige gedistribueerde gegevens, frameworks die mensen voor hen moeten ontwikkelen, om de weegschalen te krijgen die we nodig hebben, en als we nadenken over die reis, om door het soort te gaan, wat zijn de relationele databasebeheersystemen met de gebruikelijke verdachten, Oracle, PostgreS, Sybase, IBM DB2, MySQL en het Microsoft SQL Server-platform. We hebben nu een aantal nieuwe kinderen zien komen, Clustrix, Xeround, NuoDB, MemSQL, en er zijn nog tientallen en tientallen meer die je eerder op die dia zag. Als je je de uitdaging zou kunnen voorstellen om deze platforms te moeten kennen, en de knowhow om ze te runnen en het enkele glasvenster te krijgen, dat je een DBA moet zijn en deze dingen moet doen, is de uitdaging verre van triviaal. En toen kwamen ineens de NoSQL-motoren die een heel nieuw soort leuke uitdaging zijn.
En dus is de laatste dia die ik hier heb een soort van de ultieme één-twee-drie knock-out punch en dat is dat we sommige van deze technologieën nu hebben genomen en we hebben een servicemogelijkheid voor ze gecreëerd, we hebben ze in cloudmodellen en ze zijn nu beschikbaar als een hulpprogramma, als een service, je kunt in principe database als een service krijgen en de gebruikelijke merken die we daar zien op Amazon's Web Services en Google's Cloud Compute Platform en Microsoft Azure zijn degenen die naar mensen komen denk eraan, maar er zijn nu tientallen en tientallen cloudplatforms. En in Australië bijvoorbeeld zijn er zoiets als honderdtwaalf bedrijven die bonafide grootschalige openbare cloud zijn die databaseservice in verschillende vormen aanbieden.
Nadenken over de uitdaging die de gemiddelde DBA moet hebben om uit bed te komen en aan het werk te gaan en het hoofd te bieden is een behoorlijk verbijsterende uitdaging. En dus ben ik heel erg van mening dat, zoals zoveel dingen in het leven, we die horizontaal en verticaal hebben opgeschaald, dat wil zeggen dat de infrastructuur is geschaald in een zeer horizontaal, bijna-lineair groeimodel, en de complexiteit van stapel in in verticale zin, het aantal databaseplatforms, het aantal applicatie-frameworks en modellen waarmee we te maken hebben, is veel verder gegaan dan wat mensen in één venster zouden moeten kunnen verwerken en wat het nut van databasebeheerders nu is een hele reeks nieuwe tools om met al deze platforms te kunnen praten, ze te beheren, te beheren en te ondersteunen, en ik geloof dat dat het hele onderwerp is van onze gesprekken vanmorgen, of vanmiddag uw tijd, en met dat in gedachten, Ik ga het overhandigen aan onze gast die veel zal praten over hun product en hoe het de uitdaging aan gaat.
Eric Kavanagh: Oké Scott, ik ga bij de hand-
Scott Walz: Heel erg bedankt, oké, bedankt. Bedankt Dez, bedankt Robin en bedankt iedereen voor het meedoen en me vandaag op de oproep. Ik wil Robin en Dez bedanken voor het meevoeren op een wandeling door het geheugen, sinds de vroege jaren negentig in de ruimte was, je hebt veel goede herinneringen teruggebracht. De herinnering die ik op geen van die dia's en de foto's zag, waren de ponskaarten. En dat was het allereerste wat me werd voorgesteld toen ik voor het eerst begon aan mijn eerste baan op de universiteit, mijn collega in de kubus naast me, zei me dat ik zijn ponskaarten niet moest aanraken. Dus ja, absoluut, en het is inderdaad een uitdaging geweest, en een uitdaging waar we onze klanten sinds het midden van de jaren negentig aan hebben geholpen, en dit is een product waar ik het vandaag over wil hebben. Laten we eens kijken naar het multi-platformbeheer, en dit is slechts een subset. Ik koos voor een grafiek, maar zoals Dez zei:
Eric Kavanagh: Je moet je scherm delen.
Scott Walz: Oh, dat weet ik zeker, dank je.
Eric Kavanagh: Geen zorgen. En mensen, wees niet verlegen, stel vragen, we hebben vandaag drie slimme broeken aan de lijn, dus stuur ze de moeilijke vragen. U kunt de Q&A component van uw webcast-console gebruiken of u kunt tweeten met de hashtag van BriefR. Oké, Scott, haal het weg.
Scott Walz: Daar gaan we, dank je. Ik pakte deze dia en deze afbeelding. Het beeld van Dez blies me echt weg, want dat is, dat is echt de wereld waarin we vandaag leven, en de wereld waarin de DBA's optreden. En zoals ze al zeiden, het is niet langer, je echt, moeite om te kunnen om dit met brute kracht te doen. Je hebt echt de tools nodig en dat is, we komen binnen om te spelen en we zien die hele schakelaar, de momentumverandering waar het vroeg was en erg stil was zoals je zei, en toen gingen we werken met meerdere databaseplatforms, dus dat was onze eerste poging in de tools, en toen was het terug naar waar organisaties, en na het jaar 2000 en toen het soort van een beetje vernauwde. Met de organisaties en wilden we solide gaan, maar toen kwam het terug en het blies gewoon echt op toen je al die nieuwe platforms introduceerde. En nu, in plaats van in een specifiek platform of een specifieke technologie te worden ondergedompeld, komt geen van die organisaties erachter wat het beste is. Wat is de beste applicatiedatabase, wat is het beste platform om te gebruiken? En met dat gezegd, ik wil je een beetje doornemen over wat we met DBArtisan doen. En DBArtisan is ons vlaggenschipproduct en beheert al meer dan 20 jaar platformonafhankelijke omgevingen, en dit is waar we wonen en dit is waar we onze klanten graag willen benadrukken en met hen de tools geven om ze productief te maken en uitgevoerd.
Laten we doorgaan en ik spring er meteen in. Ik laat het product meer zien terwijl ik door dia's ga en ik denk dat jij dat waarschijnlijk ook doet. Voor degenen onder u die DBArtisan nog niet eerder hebben gezien, kijken we naar de comp en ik denk dat Dez de term 'single glass' gebruikt, en dat is iets waar we trots op zijn om de DBA een enkele blik te geven in al hun platforms. Juist, het is niet nodig om een andere applicatie te openen, we gaan verbinding maken en je daar krijgen en met het platform beginnen te werken. Kijkend naar de database-verkenner aan de linkerkant, kunnen we dit naar eigen inzicht maken, we kunnen het organiseren zoals we willen. En je zult zien dat ik een mix heb, ik heb enkele van mijn Oracle-servers, ik heb MySQL, ik heb hier PostgreS, ik heb er ook een - het heeft gelabelde productieservers die sommige een deel van de MySQL-serveromgeving bevatten. Nogmaals, we kunnen daar zien dat we goed passen. Als ik kijk naar het registreren van een nieuwe database, zie je een van de platforms die we ondersteunen, er is een paar dat ik wil aankaarten. U zult merken dat dit uw SQL is, ondersteuning hiervoor, Teradata, Apache, PostgreS, hier zijn de generieken die we ondersteunen.
Als we een JDBC-stuurprogramma of LDBC-stuurprogramma hebben voor een van de platforms, kunnen we verbinding maken, u een verbinding geven en u toestaan rechtstreeks vanuit DBArtisan met het platform te werken. Nogmaals, zodat u zich kunt concentreren op het werk dat moet worden gedaan, en niet hoe u het voor elkaar krijgt. Loop daar doorheen. Maar ik wil een paar dingen over het product laten zien. Laten we ons in dat geval openstellen en we zullen bijvoorbeeld Oracle behandelen. Dit is slechts mijn kleine landingspagina hier, maar ik wil gaan kijken naar enkele van mijn schema's waarmee ik werk. We gaan een van de grotere schema's ophalen, dus nogmaals, we zullen de lijst met tabellen terugbrengen. In dit geval ga ik een tabel openen, dus we gaan ze gewoon selecteren en het zal ze naar onze objecteditor brengen.
Nu, Oracle is iets waar ik jaren mee heb gewerkt, wat ik je ga laten zien is waarschijnlijk een gemakkelijke verklaring voor jou. Maar als Oracle het platform is, of als PostgreS het platform is, of Teradata het platform is dat u zojuist hebt gekregen en u op snelheid moet komen, moet u een kolom toevoegen. Of misschien is de taak om een kolom te verwijderen. Maar u wilt zich geen zorgen maken over de syntaxis, toch? We willen gaan, typ gewoon wat we nodig hebben, stel het in en we verlaten DBArtisan om te genereren. Hier gaan we op "Alter" drukken. Het zal het script voor ons genereren. Nogmaals, een heel eenvoudig voorbeeld, maar het punt is dat het het werk voor ons zal doen om deze kolom te genereren en in de tabel te plaatsen.
Wat we echter ook kunnen doen, zijn kolommen in de tabel verplaatsen. Als je ooit hebt geprobeerd om dat te doen met de traditionele, is het een beetje ingewikkelder dan slechts een enkele regel code zoals deze. Maar nogmaals, DBArtisan gaat achter de schermen werken, de code voor u genereren en opnieuw de SQL produceren. We sluiten hier weg. Voordat ik dat doe, merk ik alle tabbladen aan de bovenkant opnieuw op, de gebruikersinterface is erg intuïtief. Als ik in de ontdekkingsreiziger kom, als ik naar PostgreS ga, toch? Als ik daar naar mijn schemamodus ga, kijk dan naar de tafel, heel gelijkaardig uiterlijk, toch? We zullen dit openen, opnieuw zien we de informatie hier. De eigenschappen, voorouders, de kolommen. We zijn specifiek voor het platform, we gaan je dit geven, de gebruikersinterface, om dit te kunnen weergeven en met de objecten te kunnen werken. Je gaat weten wat je moet doen, en het stelt je in staat om het op een efficiënte en tijdige manier te doen, dus je hoeft je geen zorgen te maken over wat precies de clausule is die daar moet gaan om die optie bieden. Wij regelen dat voor u.
Als we kijken, ga ik nu ook naar SQL Server en praat ik een beetje over enkele andere functies, dus we moeten allemaal de database bewaken. Dus nogmaals, start het op, laten we alle sessies bekijken die plaatsvinden, sessies die actief zijn. Hoe gaan we zien welke uitspraken worden uitgevoerd en kunnen we daar controle over hebben? Moeten we een sessie stoppen? Moeten we eventuele vergrendelingen in de database zien? Blokkerende sloten? Nogmaals, we hebben al die informatie hier binnen handbereik zodat we snel kunnen reageren, indien nodig corrigerende maatregelen kunnen nemen en deze kunnen omdraaien. We komen terug naar onze ontdekkingsreiziger. Dit is waar, dit is het drijfpunt, dit is waar ik altijd op terugkom, dit is waar ik persoonlijk graag dingen aan de slag ga en vanaf hier werk. Omdat ik verbonden ben met een SQL Server-database om de hulpprogramma's te bekijken. Omdat we platformoverschrijdend zijn, kunnen we beginnen kijken naar extracties, migraties. We kunnen van platform veranderen als we objecten van het ene naar het andere platform moeten migreren, we kunnen dat doen, op voorwaarde dat die objecten op de verschillende platforms bestaan. Pak de schema's uit, publiceer naar rapporten, laad en ontlaad gegevens en maak een back-up van databases.
Nogmaals, dat alles vanuit de gebruikersinterface. En als je hier naar de tools komt, zie je een complete set van tools waar we vanaf kunnen werken, toch? Tussen de "Zoeken in bestanden" kunnen we een volledige database doorzoeken waarbij we binnen de systeemtabellen kijken om die string te vinden waarnaar u op zoek bent. "Script- en bestandsuitvoering", als u een standaardinstructie heeft die kan worden uitgevoerd op meerdere platforms, meerdere gegevensbronnen, kunnen we dat rechtstreeks vanuit een DBArtisan instellen op de doelen waartegen we het willen uitvoeren. Druk op "Go" en het zal draaien en ons de resultaten terugbrengen tegen al die doelgegevensbronnen. Nogmaals, je laten werken vanuit die ene ruit.
En "Analyst Series, " nogmaals, die zijn meer diepgaand. Die zijn meer gericht op relationele databases naarmate we meer van de nieuwere platforms binnenkomen, je zult zien dat we deze functionaliteit ook in die arena's uitbreiden. En in het algemeen, gewoon veel verbeteringen in de gebruikersinterface. Functies die specifiek zijn afgestemd op de DBA. Items zoals we hebben de mogelijkheid om een scriptbibliotheek te maken. De SQL-scripts die u vaak uitvoert op meerdere platforms, sla het hier op, sleep het, zodra we een nieuw ISQL-venster hebben ingesteld, kunnen we het script gewoon naar binnen slepen en we hebben het script nu klaar voor gebruik. Nogmaals, dat binnen handbereik hebben om te kunnen doen en beheren. U zult merken dat we leveren met scripts die al zijn gedefinieerd voor sommige van de platforms, zodat we er op elk gewenst moment net zoveel kunnen maken als nodig is.
Een leuk ding dat ik leuk vind en veel van onze klanten doen, als je ooit geïnteresseerd bent, en ik krijg deze vraag veel met betrekking tot: “Hoe doe ik dat? Dat is best wel cool. Hoe doet DBArtisan dat? ”Er is hier een kleine functie, “ Logfile ”, u kunt alle SQL-instructies registreren die we uitvoeren, dus als u wilt weten hoe we die verkenning invullen of hoe we de editor vullen voor een PostgreSQL-tabel of een Teradata-tabel, log de SQL en we zullen alles opnemen wat DBArtisan uitvoert in de database en u kunt terugkomen en naar die SQL kijken en alles hebben wat we nodig hebben. Misschien wilt u dat opnemen als onderdeel van een van uw scripts. Absoluut. Helemaal goed.
We willen heel transparant zijn over wat we doen en wat we uitvoeren met de database, daarom gaan we u toestaan alles op te slaan en op te nemen dat we op de database toepassen. We hebben ook configuratie-opties. Je zult merken dat ik het heb ingesteld als "Organiseren door objecteigenaar". Ik kan ook instellen op "Objecttype". Als ik weer in mijn PostgreSQL-omgeving kwam, ging ik naar het schema als ik naar de SQL keek in plaats van alleen mijn GIM-tabellen die bij dat schema horen, ik ga alle tabellen zien, ongeacht de schemanamen. Nogmaals, verschillende manieren om dingen te organiseren die het echt aanpassen aan uw eigen workflow en hoe u het wilt zien.
En het laatste waar ik het over wil hebben, is de mogelijkheid om 'Bladwijzers' in te stellen. Als ik doorsteek, als ik op een van mijn platforms werk en me alleen op mijn tabellenmodus wil concentreren, kan ik een bladwijzer toevoegen. Ik weet het, een heel eenvoudige functie, maar zo leuk om te hebben, vooral als je met zoveel gegevensbronnen en evenveel platforms werkt als de DBA van vandaag. Om in het systeem te komen, start DBArtisan en laat de bladwijzerbeheerder je rechtstreeks naar de plek in de boom brengen waar je moet zijn en kunnen werken. En vanaf hier zou ik een nieuwe tafel kunnen maken, en opnieuw, op de platforms die we ondersteunen die je eerder zag, en we gaan je door “Wizard” leiden om je te laten rijden en de tafel te ontwikkelen en maken. En we gaan alle syntaxis genereren die nodig is om dat achter de schermen voor u te doen en die vervolgens aan het einde in een voorbeeldvenster presenteren. U kunt valideren, precies zien wat we gaan genereren. U kunt op de knop "Uitvoeren" en vervolgens op de knop "Voltooien" drukken en deze laten uitvoeren. Of u kunt het opslaan of naar een ander ISQL-venster pushen, dus maak het opnieuw, misschien moet het deel uitmaken van een groter, een groter script dat u wilt opslaan en implementeren tijdens uw batchvensteruren.
Dat is een overzicht van DBArtisan. Als we daarover praten, is het opnieuw een product dat veel platforms heeft gezien, ondersteuning voor die platforms en geweldige gebruikerservaring, geweldige feedback van onze klanten. En als u geïnteresseerd bent, als een van de panelleden, maar als u iets moet vinden dat verband houdt met IDERA of DBArtisan, neem dan gerust contact met me op en u kunt me zeker vinden op mijn e-mailadres.
Eric Kavanagh: Oké, ik denk dat ik het voor vragen en Robin open zal stellen voor Dez en dan zal ik de Q&A van de aanwezigen in de gaten houden. Robin, haal het weg.
Robin Bloor: Oké, ik bedoel, de eerste vraag, ik ben eigenlijk al een tijdje bekend met DBArtisan, dus ik ben me een beetje bewust van de mogelijkheden ervan. Wat ik zou willen interesseren, is zijn soort van toekomstige paden vanaf hier. Ik bedoel, ik zie, weet je, de laatste keer dat ik er naar keek, moet het lang geleden zijn geweest. Ik zie dat u ten minste drie databases ondersteunt waarvan ik me niet realiseerde dat u eerder ondersteunde. Wat is het voorwaartse pad voor DBArtisan? Gaat u waarschijnlijk alleen maar meer en meer databases toevoegen of is het een functie-uitbreiding? Waar ga je ermee naartoe?
Scott Walz: Dat is een geweldige vraag en ik zou graag al het bovenstaande willen. We gaan zeker verder bouwen omdat de traditionele RDBMS-platforms niet stil zitten, toch? Ze blijven bouwen. We zullen dat pad blijven volgen. En dan zie je ons beginnen te kijken en die kant op te gaan om netto nieuwe platforms te ondersteunen. Omdat we erkennen dat, hoewel sommige van die platforms blijven groeien, de traditionele RDBMS, er bepaalde situaties zijn dat de nieuwe platforms de juiste platforms zijn voor de klanten om mee te gaan. We houden die markt en dat segment echt goed in de gaten en proberen de juiste beslissingen te nemen over welke platforms we moeten gaan. Ze lijken praktisch elke dag te veranderen.
Robin Bloor: Nou, het is zoals zowel ik als Dez zeiden, het is een zeer levendige markt, is mogelijk een manier om ernaar te kijken. Iets anders waar ik in geïnteresseerd zou zijn - het is duidelijk dat je deze vraag niet in detail kunt beantwoorden, maar ik ben in mijn tijd sites tegengekomen waar er duizend exemplaren van Oracle zijn en Oracle niet de enige database die werd gebruikt, die werd geïmplementeerd, weet u. En toen ik daadwerkelijk met hen sprak over hoe je in hemelsnaam zoveel instanties beheert, zeiden ze: "Wel, weet je, er zijn slechts ongeveer vijf of zes grote instanties en we hebben ongeveer drie DBA's die we daarover verspreiden." ben nogal geïnteresseerd in termen van het gebruik van DBArtisan, omdat je er heel veel mee kunt doen, hoeveel databases zit het, laten we zeggen typisch, of zelfs wat zijn de grootste voorbeelden van hoeveel tekenreeksen het tegelijkertijd kan beheren?
Scott Walz: Nou, ik heb situaties gezien - en nogmaals, het is een beetje ingewikkeld, die vraag is, omdat DBArtisan me toestaat om meerdere verbindingen of meerdere gegevensbronnen te definiëren voor een enkele instantie. Misschien wil ik een syslogin doen en dan een lagere permissie-login, maar ik heb met klanten te maken gehad dat met alles ingestort het meerdere schermen ging. Toen ik hen dat vroeg, is de vraag die je me hebt gesteld: "Hoe kun je er zoveel beheren?" En dan zegt hij: "Ik weet het niet." "Ik beheer wat ik kan, maar ik heb toegang tot alles nodig." Ik moet nog iets zien dat stopt, weet je, de bovengrenzen van wat mensen kunnen beheren, is echt de bovengrens van wat die persoon, het individu, kan omgaan met. Maar weet je, zoals ik al zei, die mensen waarmee ik daag, ze geven openlijk toe dat ze al die connecties hebben, maar er is geen manier waarop ze het kunnen beheren. Ze vertrouwen op hun team. Zoals je zeker hebt ervaren, ja.
Robin Bloor: Nou, ik ben zelf ook een DBA geweest, hoewel ik dat niet lang heb gedaan. En het enige dat, weet u, ik herinner me, boven alles boven relationele databases, is dat u een enorm aantal dingen met SQL kunt doen. Vaak meer dan je denkt dat je zou kunnen. Dat verklaart op een of andere manier een deel van de functionaliteit die DBArtisan heeft, omdat het zich rechtstreeks vertaalt in SQL. Maar weet je, ik weet zeker dat je andere dingen doet. Het is allemaal SQL-scripting of zijn er andere speciale routines die zijn geschreven voor esoterische situaties?
Scott Walz: Ja, veel ervan, het grootste deel ervan is SQL, dat is gewoon de aard daarvan. Maar we schrijven wel routines die vanaf een opdrachtregel kunnen worden uitgevoerd met behulp van de tools van de leverancier, de frontends van de leverancier. We plaatsen front-end, bijvoorbeeld, voor de hulpprogramma's voor het laden van gegevens op de platforms, toch? Dat zijn geen SQL-scripts, toch, dat zijn opdrachtregelopdrachten. Het zal deze genereren en in staat zijn om die aan de DBA te geven die ze vervolgens kunnen uitvoeren. Ja, we doen een klein beetje van beide, maar de meeste zijn SQL-scripts.
Robin Bloor: Kijkend naar, want je moet natuurlijk op de een of andere manier kijken naar de ontwikkelingen die aan de gang zijn en die ik als vrij nieuw beschouw. Ik bedoel, een van de dingen die ik interessant vind dat er gebeurt, is dat Spark duidelijk als een raket opstijgt, maar Spark's SQL, het is van verschrikkelijk onvolwassen geworden om er wat volwassener uit te zien met een beetje meer SQL-mogelijkheden. Kijk je naar zulke dingen en vraag je je af of je die gaat beheren met DBArtisan?
Scott Walz: Zeker en ik wel. Dat is er altijd. Ik weet dat ons productmanagementteam altijd kijkt waar we naartoe moeten en absoluut, alles ligt op tafel voor ons, met betrekking tot waar we naar kijken in de toekomst.
Robin Bloor: Oké, Dez, wil je je opstapelen?
Dez Blanchfield: Ja, eigenlijk heb je daar een heleboel geweldige dingen voor me geopend, Robin. Hartelijk dank. Ik wil graag een aantal dingen verkennen die op me afkomen als ik naar dit soort producten kijk en ik word erg enthousiast. Toen ik mijn huiswerk dubbel controleerde, want zoals Dr. Robin Bloor al eerder zei, hij, net als ik, dit al een tijdje volg en ik herinner me dat ik onlangs naar je spec-vereisten keek en dacht dat dit ding eigenlijk leunt van wat het eigenlijk doet. En ik denk vanuit het geheugen - corrigeer me als ik het mis heb - ik denk dat het net zo weinig was als een laptopprestatie comfortabel DBArtisan zou draaien en toch kon het behoorlijk wat database back-end draaien. En ik was heel geïnteresseerd om te zien dat je nu ook Firebird en Greenplum had. Ik was behoorlijk onder de indruk van de vereiste of de specificatie van de hardware die letterlijk als een gig RAM op een CPU van één gigahertz kon worden uitgevoerd. Dat was behoorlijk indrukwekkend.
Maar de use cases is iets waar ik even op in wil gaan. Zie je dat de introductie van het product een geval is van een behoefte vanwege bestaande omgevingen die zojuist uit de hand zijn gelopen, of zie je mensen nu een beetje meer proactief zijn en zeggen, weet je, we bouwen iets heel groot, het is complex. En ik denk bijvoorbeeld aan fusies en overnames, waar een organisatie een aantal bedrijven kan kopen - klein, middelgroot, groot, wat dan ook - en uiteindelijk al deze omgevingen erven en een nieuwe DB-mogelijkheid moeten bouwen. Wat zijn de typische use cases hiervoor, voor zover het het type organisatie en het type toepassing daarop betreft? Zijn het voornamelijk mensen die bestaande omgevingen hebben en ze gewoon moeten opruimen en de controle over hen moeten krijgen of zijn mensen een beetje meer proactief en denken ze na over de complexiteit die ze gaan bouwen en u vroeg aan boord krijgen?
Scott Walz: We zien meer van vroeg opschieten om de reden die u noemde, de consolidatie. Met de breedte van platformondersteuning die we hebben, is het geen totale toekomstbestendigheid, juist, maar het brengt u en uw DBA's in een echt goede situatie dat wanneer ze naar een potentieel acquisitiedoel kijken, ze juist een beetje minder zijn, weet je, de gedachte aan welke platforms zouden we kunnen erven, toch? Hoewel het belangrijk is, toch, is de zorg daar iets minder dan wat het voor onze DBA's gaat betekenen, toch? De DBA's hebben nu een product waarvan ze weten dat ze verbinding kunnen maken en als ze bekend zijn met het gebruik van het product, zullen ze bekend zijn met de verbinding met dat platform dat ze zojuist hebben gekocht. Dus dat is zeker een gebied dat we zien, al lang weer, de klanten met die mash-up van al die platforms, toch? Hoe kom ik hier aan toe, toch? En ze hebben het geprobeerd, omdat het denkproces is dat elk van de platforms een hulpmiddel heeft, toch? We kunnen onze eigen tool gebruiken, toch? Maar het komt uiteindelijk terug dat, weet je, ja dat kan, maar niet alleen zal ik elk van de platforms moeten leren, nu leer ik elk van een van de tools die bij elk van de platforms horen en dus je hebt zojuist de taak van een DBA vergroot. Dus we zien ook die situatie waarin ze bij ons terugkomen en zeggen: “Weet je, we moeten dit in handen krijgen. Laten we één tool voor de DBA kopen, omdat ik belangrijkere dingen voor de DBA heb om te doen dan om de gebruikersinterface van een nieuwe tool te leren. Of verschillende tools. "
Dez Blanchfield: Ja, nee, zeker niet. En weet je, als je het ziet, denk ik uit mijn geheugen toen ik gisteren keek om te controleren of ik niet verkeerd was, ik herinner me dat je bijvoorbeeld Sybase steunde, dus dit ding bestaat al een tijdje. Er is nog een vraag die ik eigenlijk alleen voor je had - ja, het is geweldig om Greenplum en Firebird op je lijst te hebben, maar je Sybase, dat soort leeftijden heel snel, dat laat zien dat het al een tijdje bestaat en goed werk heeft geleverd.
Clusters. Dus een van de grootste problemen voor een DBA is dat ze in wezen zullen wijzen op wat eruit ziet als een IP-adres en een heleboel API's of dat het JDBC of LDBC is of waar we ook mee praten, maar daarachter zit een cluster. Wat kan of weet DBArtisan als het ware achter deur nummer één, zoals wanneer ik de back-end van de database aansluit, krijg ik alle omgevingen daarachter te zien, en in het bijzonder, er zijn twee delen aan de vraag misschien. Het cluster bijvoorbeeld, als je denkt aan, weet je, je ondersteunt IBM DB2 en Microsoft SQL Database Server en MySQL en PostgreSQL en Oracle en sommige van die traditionele RDBMS's en, weet je, steevast voeren we een master-slave of master-master omgeving voor redundantie en hoge beschikbaarheid en ook prestaties. Weet DBArtisan dat er iets achter deur nummer één is dat niet slechts één database per se is, maar een cluster, en zo ja, wat weet het daarvan? En om daar snel in over te gaan, zodat u dezelfde vraag kunt beantwoorden, sorry. Dus, achter de clusters in sommige van de scenario's die je hebt, hoe gaan mensen om met de mix tussen productieomgevingen en noodherstelomgevingen, voor zover het gebruik van DBArtisan gaat?
Scott Walz: Geweldige vragen. Ik zal je geven dat dit afhankelijk is van de specifieke platforms, want zoveel we proberen, we zullen verschillende ondersteuningsniveaus hebben voor sommige van die diepgaande, diepere functies. Voor Oracle, bijvoorbeeld, en hun RAC-omgeving, Real Application Cluster, kunt u verbinding maken met het primaire knooppunt in dat cluster, maar via de databasemonitor die ik heb laten zien, gaan we u de SQL laten zien draaien en we ' ga ik je eigenlijk vertellen op welk knooppunt van het cluster het draait, toch? Om u te laten zien of, weet u, langzaam lopende query, laten we dat in de gaten houden, op welk knooppunt draait het? Omdat onvermijdelijk de hele reden voor het cluster juist is voor de eindgebruiker, maakt het hem niet uit waar het is uitgevoerd, maar voor de DBA moeten we dat soort informatie bijhouden. We kunnen bijvoorbeeld naar dat detailniveau in Oracle gaan. De andere platforms die we wel hebben, zijn waarschijnlijk niet zo gedetailleerd als Oracle.
Met betrekking tot de productie en de ontwikkelomgeving is dat een goede vraag. We bieden hetzelfde ondersteuningsniveau. De echte primaire manier waarop we gaan helpen, de verbindingslaag zal er zijn, toch? We kunnen verbinding maken en alle functies uitvoeren. Ik heb klanten die sommige functies in DBArtisan gebruiken om hun gegevensbronnen te categoriseren, toch? En nogmaals, dit is misschien een beetje af voor de exacte vraag die je stelt, maar we gaan hen in staat stellen grafisch aan te geven terwijl ze werken. Omdat dat een van de dingen van DBArtisan is, kan ik snel schakelen tussen gegevensbronnen. En het volgende dat je weet, ben ik me aan het voorbereiden om een afgekorte verklaring af te leggen en ik ben benieuwd of ik verbonden ben - heb ik dit net tegen productie of ontwikkeling uitgevoerd? En dus bieden we enkele functies binnen DBArtisan om de DBA's daar ook te helpen om dat te beheren en ze, als u wilt, uit de problemen te houden met sommige van de DBA-activiteiten.
Dez Blanchfield: Met dat in gedachten, op de lange lijst van platforms die je momenteel ondersteunt, en ik ben er zeker van dat dit om voor de hand liggende redenen snel zal exploderen. Ik bedoel, je ondersteunt bijvoorbeeld DB2 op z / OS, bijvoorbeeld op mainframe, en dan ondersteun je vanzelfsprekend wat we vroeger mid-range noemden, maar nu alleen UNIX-systemen, en een soort modernere platforms, je weet je, Linux en uiteindelijk wordt het geporteerd naar Bluemix en Cloud Foundry, dus DB2 wordt uitgevoerd op de Cloud Foundry op Bluemix, met IBM en de cloud op soft. Zijn er op dit moment mensen die niet alleen het beheer en de controle uitvoeren, maar ook de eerder genoemde mogelijkheid om te migreren en gegevens te verplaatsen. Zie je mensen in bed springen met DBArtisan en zeggen: "Weet je, we hebben een heleboel dingen op de oude mainframes die we gewoon moeten uitstappen en het was echt een gedoe om dat te doen. Als ik kan wijzen, klikken en slepen van hier naar daar, kan ik mijn gegevens en mijn schema daadwerkelijk verplaatsen en migreren. ”Is dat iets dat mensen doen?
Scott Walz: Ze zijn inderdaad in beweging, toch? Ze verplaatsen de gegevens toch? Nu gebruiken ze DBArtisan als hulpmiddel daarvoor. Doet het alles voor hen? Nee. We beginnen, je weet wel, slepen en neerzetten, niet precies daar, maar we stellen ze in staat om enkele scripts te genereren, omdat je idealiter wilt gebruiken - je wilt niet dat deze taak wordt uitgevoerd op uw client, op uw laptop, precies om de reden die u noemde. We kunnen op een zeer kleine voetafdruk lopen, toch? We helpen hen scripts te genereren en deze vervolgens om te draaien en op te bouwen en dan kunnen ze dat script afleveren en op de server laten draaien, toch? En krijg de kracht, de pk's achter de server om dat te doen. We helpen hen een deel van hun werk te genereren om een deel van dat werk te doen.
Dez Blanchfield: Rechts. Een paar laatste voor jou en dan kunnen we teruggaan. Het ding dat me echt opviel, is gewoon door je addendum gaan, wat fantastisch is, en ik wou dat we nog een uur hadden om meer in detail te treden. Een echt grote uitdaging voor DBA's, toch, is basisconformiteit, algemeen beheer van de infrastructuur, de audits, rapportage over de huidige stand van zaken, kijken naar toekomstige voorbereidingen voor dingen zoals, weet je, alleen algemene groei van het milieu. Het valt me op dat, hoewel dat de kern is van wat je product lijkt te doen, dat is het leven eenvoudig maken, die ene ruit, één blik op de wereld, en ik kan in wezen klikken en aanwijzen en slepen en ik ben dol op het feit dat ik iemand nu kan trainen om dit heel snel te doen, ze hoeven de handleiding als het ware niet te lezen. Het valt me op dat de tool me ook de mogelijkheid biedt om een heleboel dingen rond governance en compliance en audits te doen, dat ik me afvraag of mensen wel een beetje wakker zijn geworden, dat weet ik zeker.
Maar zie je nu dat mensen ernaar kijken en gaan, en het is alsof dit eureka, a-ha moment, gaat: “Hé, weet je wat, dit maakt het leven van de DBA vanaf nu echt gemakkelijk, of gemakkelijker vanuit operationeel oogpunt of ontwikkelingsperspectief. Maar god, we zouden nu eigenlijk gewoon over al onze databases en alle gegevenssets en alle inhoudloze gegevens en alle metagegevens kunnen rapporteren. Zoals, wie toegang heeft, wanneer ze toegang hebben, waarom ze toegang hebben en wat voor soort toegang ze hebben. ”En dan ineens enkele van de uitdagingen rond compliance. Vooral wanneer er een aantal echt grote dingen gebeuren rond datalekken. We hebben een aantal geweldige dingen, zoals de wereldwijde financiële crisis, al deze uitdagingen komen eraan, maar hoe gaan we in vredesnaam de naleving meten en volgen? Is dat nog zoiets groots voor mensen of is het nog steeds een soort van vroege dagen wat betreft het toepassen van DBArtisan daarop?
Scott Walz: Ik heb klanten die niet genoeg over DBArtisan kunnen zeggen. Dat zijn degenen die zich dat hebben gerealiseerd. De gloeilamp is aan. Ze zeggen: "Wacht even. Ik kan antwoorden en reageren en enkele van de zeer genoemde rapporten genereren, juist, allemaal vanuit één tool. Ik heb het. 'Nu zijn er nog anderen die dat nog moeten begrijpen en dat kan om verschillende redenen zijn, toch? Ze zijn er misschien nog niet of misschien wordt het door iemand anders afgehandeld, maar onze klanten die we hebben gevonden die het gebruiken, is dat een a-ha moment, toch? Dat, ik ben niet alleen in staat om al die dingen een tabel te maken. En absoluut, met alle nalevingsvereisten, is het enorm. Dat is een baan op zich.
Dez Blanchfield: Nou, inderdaad. En weet je, ik bedoel, ik denk meteen, weet je, als er iemand langskomt die zegt dat ze een database voor configuratiebeheer wilden maken, CMD, als ze alles van Sarbanes moeten ontmoeten -Oxley om te COBIT naar ITIL, weet je, SWIFT-compliance en bankieren, zelfs als het gaat om de International Standards Organisation, ISO 27001, 27002. Het zijn al deze echt grote kaders. Een van de uitdagingen is gewoon te vinden waar de gegevens zijn, wie ze beheert, in welk formaat ze zijn en ik denk dat dit voor mij is, net als voor mij gewoon kijken nu het eureka-moment net afging, het was alsof, hangen op een seconde zou ik dit zelfs naar iemand kunnen gooien die niet noodzakelijk een DBA is, maar ik zou hem snel kunnen opleiden en zeggen: "Er is een compliance-tool." Ik vind het geweldig dat het zijn werk doet in een administratie-database management wereld.
Maar ik zit hier te denken, god, weet je, het feit dat je tegenwoordig meerdere platforms als één kunt beheren, en je kunt duiken in, zoals je zei, het loggen van de transacties die je doet. Weet je, stel je voor dat je deze tool meeneemt naar een incident met datalekken en je beveiligingsteam rent rond en probeert te achterhalen wat waar en waarom is en wie wat heeft gezien. En terwijl ze zich verplaatsen, moeten ze loggen en elke actie volgen die ze doen, omdat ze een deel van het probleem kunnen worden als ze dat niet kunnen. Ja, ik denk dat het hier een ongelooflijke vaardigheid is die, weet je, je meteen zou kunnen beginnen te doen, weet je. Vooral als we kijken naar de uitdagingen van gegevensaudits die u kent, hebben we zoiets als een soort kruip als het ware met gegevenssets en gegevens.
En een van de dingen waar we het in andere shows over hebben gehad, is, weet je, hoe ga je je gegevens zoeken en vaak praten we over het feit dat wanneer je begint in een organisatie, sta op in je kast en steek je hand in de lucht en zwaai en ga: “Weet iemand waar deze database is? Hoe kom ik bij deze gegevensbron? Waar is dit bestand? '' Ga de receptie vragen. ' Uw tool kan onmiddellijk die mogelijkheid bieden om dingen te vinden en te ontdekken en er zelfs over te rapporteren.
Terug naar een van de vragen, kort en dan zal ik het afronden en teruggeven aan Eric. Het valt me op dat schaal de komende 12 maanden een uitdaging voor je wordt. Kunt u ons enig inzicht geven, slechts vanuit een gezichtspunt van dertig duizend voet, in de schaal of het schaalbereik dat DBArtisan aan het werk is. Ik kan me voorstellen dat wanneer ik dit op mijn laptop zet en ik rock en ik het op een omgeving richt, ik het kan ontdekken en er dingen op kan gaan doen. Ik stel me voor dat het gaat als een enkele kleine, weet je, open source minuscule database-engine met een paar rijen en tabellen. Op welke schaal zou het gaan? Je had het over DB2 op mainframes, dat is groot. En clusters. Wat is het schaalbereik dat we hier kunnen verwerken? En Robin heeft daar eerder op gewezen, maar ik zal daar wat meer in detail op moeten ingaan voor hoe groot we kunnen worden met DBArtisan.
Scott Walz: Natuurlijk. Er zullen zeker uitdagingen zijn omdat het een client-stuk software is. En dus, nogmaals, als ik aan een mainframe werk, wanneer ik tegen ons testsysteem op het mainframe werk dat we hebben, kan ik het tegen miljoenen rijen richten en een cross-join uitvoeren tegen miljoenen rijen. Al het werk zal op een server worden gedaan, toch, omdat we dat commando doorgeven, en dat is gewoon een kwestie van DBArtisan de resultaatsets afhandelen, toch? En dus dat is de uitdaging, en dat is de schoonheid, juist, van wat we doen. Het grootste deel van het zware werk wordt op de server gedaan. We verwerken alleen alle resultaten. En dus, nogmaals, kom je natuurlijk in situaties waarin je tien query's tegelijkertijd wilt uitvoeren die allemaal miljoenen rijen opleveren, ja absoluut, je zou daar in een uitvoering terecht kunnen komen, toch? Maar op geen enkel moment schuwen klanten grote vragen tegen DBArtisan, weet u, tegen hun database. Nogmaals, zoals ik al zei, de kilometerstand varieert afhankelijk van veel factoren, toch, maar nogmaals, zoals ik al zei, ik heb te maken met miljoenen rijen die terugkomen en zolang het de grid vult, weet je, ik ' ben klaar om te gaan. Maar soms moet ik natuurlijk wachten tot de resultaten terugkomen.
Dez Blanchfield: Ik heb een vraag voor je voordat ik afrond, omdat ik teveel van je tijd heb genomen en je daarvoor dank. Vertel ons gewoon wat meer rond, weet je, gisteren de nieuwste specificaties lezen om er zeker van te zijn dat ik er net zo over was als ik dacht. Procesbewaking en soort waarschuwingen en meldingen, weet u, capaciteitsplanning brengt alle enorme problemen met DBA's met zich mee, de hele dag elke dag, weet u. Gaat iemand deze tabel opvullen, gaat hij de database opvullen, vullen ze de schijfruimte op die ik heb, hoe beheer ik deze? Geef ons een kort overzicht van de soort procesbewaking en met name monitoringmeldingen en dan idealiter rond capaciteitsplanning. Ik denk dat dat een gebied is waarvan ik denk dat er veel interesse in zou kunnen zijn.
Scott Walz: Procesmonitoring heeft waarschijnlijk aangetoond dat de functie die het grootste deel van ons klantenbestand gebruikt en dat is een databasemonitor om dat te kunnen tonen en doen. En we hebben er wel wat in het analistenpakket. Performance Analyst heeft enkele waarschuwingen die u kunt instellen wanneer aan bepaalde drempels wordt voldaan. Het kan je waarschuwen. Misschien X aantal logs, fouten in het logbestand, weet je, het zal een waarschuwing voor je krijgen. Tafelruimte raakt een bepaald percentage vol, u kunt nog een waarschuwing krijgen. En het mooie is dat je in dezelfde tool zit, toch, het is een onderdeel van DBArtisan, dus je klikt gewoon met de rechtermuisknop op de fout, de waarschuwing en je beheert met DBArtisan en het brengt je rechtstreeks naar de tabelruimte-editor . En u kunt het probleem daar aanpakken.
Met betrekking tot capaciteit is dit absoluut een sneltoets en de capaciteitsanalist die we momenteel hebben, is geporteerd naar SQL Server, Oracle, DB2 LUW en Sybase ASE. En dat doet precies wat u hebt beschreven. Je kunt beginnen, als we eenmaal wat collecties hebben, toch, en als we een steekproefgrootte hebben, en misschien de rijgrootte, misschien het aantal objecten, veel opties in de tool, en dan kun je beginnen met trending, toch? En hoe gaat het er over zes maanden uitzien? Hoe gaat het er over twaalf maanden uitzien? Ik kan trend, gewoon trend naar een datum of ik kan trend naar een waarde, toch? En een voorbeeld dat je had, op basis daarvan heb ik X hoeveelheid schijfruimte, wanneer ga ik die limiet bereiken? Op basis van de groei die ik heb en deze collecties die ik heb gedaan, wanneer ga ik die limiet bereiken? Ik weet tenminste dat ik daarvoor kan beginnen plannen. Gaat het zes maanden duren, gaat het twee jaar duren? Maar nogmaals, we kunnen de capaciteitsanalist gebruiken om daar naartoe te gaan.
Dez Blanchfield: Dat is geweldig. Fantastische demo. Ik heb er echt van genoten. Ik ga terug naar Eric omdat ik weet dat er vandaag een paar vragen uit ons geweldige publiek zijn opgekomen. Heel erg bedankt, het was echt geweldig om het product goed te leren kennen en ik kijk ernaar uit om het heel goed in de gaten te houden.
Eric Kavanagh: Oke goed. We hebben een paar goede vragen. En we gaan een beetje in de tijd, dus we proberen snel af te ronden omdat ik weet, Scott, je hebt een gesloten harde stop. Hier is een grote vraag. Hoe zit het met het werken aan oude datastores zoals VSAM en Model 205, en IMS en IDMF en dat soort dingen? Zie je dat tegenwoordig heel vaak en hoe goed werkt het?
Scott Walz: Ik wil je niet vertellen dat je vastzit. Sommige van die omgevingen, als ze ODBC of JDBC hebben en ik weet dat sommige van hen daar zijn, kunnen we er verbinding mee maken en kun je er op die manier mee werken. Maar voor het grootste deel is het groene scherm de manier om nog steeds te gaan.
Dez Blanchfield: Ik ben dol op het groene scherm.
Eric Kavanagh: Nou weet je, zoals Dez al zei met die ene dia, waar hij al die verschillende applicaties en tools had die vandaag beschikbaar zijn, dat is een heel ontmoedigende realiteit voor iedereen die op verantwoorde wijze de functie van databasebeheerder wil vervullen. En ik gok dat jullie na verloop van tijd connectoren kunnen bouwen naar elk van deze tools als en wanneer klanten eisen, enzovoort, toch? Zodat u die enkele ruit inschakelt.
Scott Walz: En dat was de grote sleutel om DBArtisan uitgerust te maken om die JDBC- en ODBC-verbindingen te kunnen verwerken. We hebben het nu echt uitgebreid. Nu, zolang we die verbinding hebben, juist, zolang we die driver hebben, kunnen we verbinding maken en ertegen werken.
Eric Kavanagh: Dat is goed spul. Nou mensen, we archiveren deze allemaal voor later bekijken. Ik heb een link naar de dia's geplaatst, hopelijk kun je dat zien via SlideShare. Heel erg bedankt voor al uw inspanningen, heren. Geweldige webcast vandaag opnieuw. Veel goede glijbanen. Veel goede inhoud. Ik hield van die demo. Het is echt een beetje interessant dat jullie op een heel goed plekje op de markt zijn gericht, omdat er tegenwoordig zo'n explosie van databasetypen is. En we hebben als managers gewoon een plek nodig om dat allemaal aan te pakken. Goed gedaan mannen. We zullen u morgen ontmoeten voor een nieuwe Hot Technologies. Hopelijk heb je morgen een uur uitgehakt. Dezelfde tijd. Hetzelfde station. We zullen je de volgende keer inhalen, mensen. Wees voorzichtig. Tot ziens.
