Od zaměstnanců Techopedia, 19. dubna 2017
Take away : Host Eric Kavanagh diskutuje o prognóze s Dr. Robin Bloor, Rick Sherman a IDERA Bullett Manale.
Chcete-li si prohlédnout toto video, musíte se zaregistrovat do této události. Chcete-li zobrazit video, zaregistrujte se.
Eric Kavanagh: Dámy a pánové, ještě jednou ahoj a vítejte zpět v seriálu webového vysílání Hot Technologies! Jmenuji se Eric Kavanagh, budu vaším hostitelem pro dnešní webový seminář s názvem „Úspora času, peněz a problémů s optimálním předpovědím.“ „Samozřejmě, že mi chyběla první část názvu„ Nejlepší plánované plány “. vždy mluvit o tom na této show. Takže, Hot Technologies je samozřejmě naším fórem pro pochopení toho, co některé skvělé produkty dnes existují na světě, ve světě podnikové technologie, co s nimi lidé dělají, jak fungují, všeho druhu zábavných věcí.
A téma dnes, jak navrhuji, se zabývá prognózami. Opravdu se snažíte pochopit, co se bude dít ve vaší organizaci. Jak udržíte své uživatele šťastnými, bez ohledu na to, co dělají? Pokud dělají analýzu, dělají skutečnou práci, čelí skutečným zákazníkům s transakčními systémy, ať už je to jakýkoli případ, chcete pochopit, jak vaše systémy běží a co se děje, a to je to, Budu o tom mluvit dnes. Je to trochu vtipné, protože předpovídání není něco, co bych rád dělal, protože jsem pověrčivý, jako když si myslím, že když předpovídám příliš mnoho, stane se špatné, ale to jsem jen já. Nesleduj můj náskok.
Takže tady jsou naši moderátoři dnes, vaši opravdu v levém horním rohu, Rick Sherman se volí z Bostonu, našeho kamaráda Bulletta Manaleho z IDERA a našeho vlastního Dr. Robina Bloora. A s tím předám Robinovi a jen připomenu lidem: Ptejte se, nestyďte se, milujeme dobré otázky, dnes je rozdáme našim moderátorům a ostatním. A s tím, Robine, vezmi to pryč.
Robin Bloor: Dobře, dobře, protože jsem v pozici pole, jak se říká, myslel jsem, že bych dnes vyprávěl příběh SQL, protože je to zázemí pro to, k čemu bude diskuse pokračovat a nevyhnutelně se nebude střetávat s protože Rick se na to nezaměřuje a nebude se střetávat s tím, co Rick říká. Takže, příběh SQL, tam jsou některé zajímavé věci o SQL, protože je tak dominantní. Vidíte, to je překlep, SQL je deklarativní jazyk. Myšlenkou bylo, že byste mohli vytvořit jazyk, ve kterém byste požadovali, co jste chtěli. A databáze by zjistila, jak ji získat. A ve skutečnosti je to docela dobře vypracované, ale existuje řada věcí, které stojí za to říci, důsledky spočívající v tom, že celý IT průmysl je založen na deklarativním jazyce. Uživatel neví a nestará se o fyzickou organizaci dat, a to je dobré o deklarativním jazyce - odděluje vás od toho všeho, a dokonce se o něj obává - jednoduše požádejte o cokoli chcete a databázi půjde a dostane to.
Uživatel ale netuší, zda způsob, jakým strukturují dotaz SQL, ovlivní výkon dotazu a to je trochu nevýhoda. Viděl jsem dotazy, které jsou dlouhé stovky a stovky řádků, které jsou jen jedním požadavkem SQL, začínají „výběrem“ a prostě pokračují a pokračují dílčími dotazy atd. A tak dále. A ve skutečnosti se ukazuje, že pokud chcete konkrétní sbírku dat z databáze, můžete o ni požádat mnoha různými způsoby s SQL a získat stejnou odpověď, pokud máte nějaké znalosti s daty. Jeden dotaz SQL tedy nemusí být nutně nejlepším způsobem, jak požádat o data, a databáze budou odpovídat zcela odlišně podle SQL, který jste do nich vložili.
A tak SQL skutečně ovlivňuje výkon, takže lidé, kteří používají SQL, to platí o nich, platí to také o programátorech SQL, kteří používají SQL, a je dokonce méně pravděpodobné, že přemýšlejí o dopadu, který budou mít, protože většina jejich zaměření je ve skutečnosti na manipulaci s daty a ne na získávání, vkládání dat. A totéž platí také o BI nástrojích, viděl jsem SQL, který dostane, pokud se vám líbí, vytlačuje z BI nástrojů různých databází a je třeba říci, že mnoho z toho je, no, já bych ' t takovéto dotazy SQL. Je to někdo, kdo vytvořil, pokud se vám líbí, malý motor, který ať jsou parametry jakékoli, vyhodí nějaké SQL a znovu, že SQL nemusí být nutně efektivní SQL.
Pak jsem si myslel, že bych zmínil nesoulad impedance, data, která programátoři používají, se liší, než data, jak se třídí. Naše DMS tedy ukládá data do tabulek, organizovaný objektově orientovaný kód jsou většinou kodéry, v dnešní době programují objektově orientovanou formu a objednávají data v objektových strukturách, takže se navzájem nemapují. Je tedy nutné překládat z toho, co si programátor myslí, že data jsou, do co si databáze myslí, co jsou data. Což vypadá, že jsme museli udělat něco špatného, aby tomu tak bylo. SQL má DDL pro definici dat, má DML - jazyk pro manipulaci s daty - pro získávání těchto dat vyberte, promítněte a připojte se. Nyní existuje velmi málo matematiky a velmi málo času založených věcí, takže je to nedokonalý jazyk, třebaže je třeba říci, že byl rozšířen a stále rozšiřován.
A pak dostanete problém s bariérou SQL, který je vždy přísnější než diagram, v tom, že ale mnoho lidí se ptalo analytických důvodů, jakmile dostanou odpověď na termíny dotazů na otázku, chtějí se zeptat na další otázku. Takže se to stává věcí dialogu, dobře, SQL nebyl vytvořen pro dialogy, byl postaven pro dotaz na to, co chcete najednou. A stojí za to to vědět, protože tam jsou některé produkty, které vlastně opustí SQL, aby bylo možné konverzovat mezi uživatelem a daty.
Pokud jde o výkon databáze - a tento druh se šíří do všeho - ano, existuje procesor, paměť, disk, režijní náklady v síti a problém s uzamykáním více než jedné osoby, která si přeje exkluzivně využívat data v daném okamžiku bod v čase. Ale jsou tu také špatná volání SQL, je tu strašně mnoho, co můžete udělat, pokud skutečně optimalizujete SQL, co se týče výkonu. Faktory výkonu databáze: špatný design, špatný návrh programu, souběžnost chybějící pracovní zátěže, vyrovnávání zatížení, struktura dotazů, plánování kapacity. To je růst dat. A v několika slovech, SQL je výhodné, ale není samooptimalizováno.
Když to řeknu, myslím, že můžeme přenést na Ricka.
Eric Kavanagh: Dobře, Ricku, dovolte mi dát klíče od auta WebEx. Vzít to pryč.
Rick Sherman: Dobře, skvělé. No díky Robin, když jsme začali na začátku prezentace, moje grafika je pořád docela nudná, ale půjdeme s tím. Souhlasím tedy se vším, o čem Robin mluvil na straně SQL. Teď se ale chci trochu soustředit na poptávku po datech, kterými projdeme velmi rychle, dodávku jako v nástrojích používaných v tomto prostoru nebo potřebu nástrojů v tomto prostoru.
Za prvé, v každém článku, který čtete, je něco, co souvisí s velkými daty, spoustou dat, nestrukturovanými daty přicházejícími z cloudu, velkými daty všude, co si dokážete představit. Růst databázového trhu však nepřetržitě rostl s relační databází SQL pravděpodobně od roku 2015, což je stále 95 procent databázového trhu. Tři nejlepší prodejci relačních produktů mají v tomto prostoru asi 88 procent tržního podílu. Takže stále mluvíme, jak Robin mluvil, o SQL. A ve skutečnosti, i když se díváme na platformu Hadoop, Hive and Spark SQL - který teď můj syn, který je datovým vědcem, neustále používá - je určitě dominantním způsobem, jak se lidé k datům dostanou.
Nyní, na straně databáze, existují dvě široké kategorie použití databází. Jedním z nich jsou operační systémy pro správu databází, tedy plánování vztahů s podniky, řízení vztahů se zákazníky, ERP Salesforce, Oracles, EPIC, N4 atd. Na světě. A v datových skladech a dalších systémech založených na business intelligence je velké množství a rozšiřující se množství dat. Protože všechno, bez ohledu na to, kde a jak je zachyceno, uloženo nebo provedeno, se nakonec analyzuje, takže existuje obrovská poptávka a větší využívání databází, zejména relačních databází, na trhu.
Nyní máme požadavek, máme obrovské množství dat přicházející. A nemluvím jen o velkých datech, mluvím o využití dat napříč všemi druhy podniků. Ale doprovázející to, že ze strany nabídky, pro lidi, kteří mohou tyto zdroje spravovat, máme první, máme nějaký nedostatek DBA. Podle Úřadu statistik práce máme od roku 2014–2024 pracovní místa v DBA vzrůst pouze o 11 procent - nyní to jsou lidé, kteří mají pracovní tituly v DBA, ale o tom budeme mluvit za sekundu - oproti 40– plus procento ročního prostoru pro růst dat. A máme spoustu DBA; v průměru stejné studium hovořilo o průměrném věku je ve srovnání s jinými IT profesemi docela vysoké. A pak máme hodně lidí opouštějících pole, ne nutně odchodu do důchodu, ale přesouváme se do jiných aspektů, chodí do managementu, nebo cokoli.
Nyní je důvod, proč odcházejí, protože práce DBA je stále těžší a těžší. Za prvé, máme DBA spravující mnoho různých databází samotných, fyzické databáze, umístěné všude, stejně jako různé typy databází. Teď to může být relační, nebo to může být jiná databáze, také typy databáze. Ale i když je to relační, mohli by mít jednoho, dva, tři, čtyři různé prodejce, které se vlastně snaží spravovat. DBA se obvykle zapojí až po návrhu databáze nebo aplikace. Robin hovořil o tom, jak se navrhují databáze nebo aplikace, jak se navrhuje SQL. No, když mluvíme o modelování dat, ER modelování, rozšířeném ER modelování, dimenzování modelování, pokročilém dimenzionálním modelování, cokoli, obvykle se návrháři aplikačních programátorů a vývojářů aplikací zaměřují na svůj konečný cíl - nenavrhují účinnost samotná struktura databáze. Takže máme hodně špatného designu.
Teď nemluvím o prodejcích komerčních podnikových aplikací; obvykle mají modely ER nebo rozšířené modely ER. Hovořím o tom, že v každé společnosti je mnohem více podnikových procesů a aplikací vytvářených vývojáři aplikací - to jsou ty, které nemusí být nutně navrženy pro efektivitu nebo efektivitu nasazení. A samotné DBA jsou přepracované a někdy mají nepřetržitou odpovědnost, stále více a více databází. Myslím, že to má něco společného s tím, že lidé nerozumí tomu, co dělají nebo jak to dělají. Jejich vlastní malá skupina a lidé stále přemýšlejí: „No, všechny tyto nástroje jsou snadno použitelné, můžeme na jejich pracovní vytížení stále házet více a více databází, “ což není pravda.
Což nás vede k částečným a náhodným DBA. Máme IT týmy, které jsou malé a nemohou si nutně dovolit vyhrazenou DBA. Totéž platí o malých a středních podnicích, kde expanze databázových a databázových aplikací v posledním desetiletí explodovala a stále se rozšiřuje. Ale je to také případ velkých korporací, které obvykle dělají datové sklady, analytiku business intelligence po dlouhou a dlouhou dobu. Kdysi dávno jsme pro tyto projekty získávali vyhrazené DBA; už nikdy nedostaneme vyhrazenou DBA. Jsme zodpovědní za vytvoření databáze, což je v pořádku, pokud je to někdo, kdo má zkušenosti. Ale obecně jsou DBA vývojáři aplikací, které často plní tuto roli jako částečný úvazek ve své práci, nemají formální školení a znovu, navrhují to pro své konečné cíle, jsou ne navrhování pro efektivitu.
A existuje velký rozdíl mezi designem a vývojem, versus nasazení a správa. Máme tu tedy „penny moudrou, hloupou libru“, s malou prasečí bankou, která přeskočí na získání dovedností a zdrojů potřebných v projektech. Myslel jsem si, že všichni pocházejí z „Pomsty pitomců“, můj malý obrázek. Nyní, pokud jde o to, co lidé potřebují, máme rozšířené využití databází a dat v SQL. Omezujeme počet DBA - lidí, kteří jsou v těchto situacích ladění a navrhování a správy a nasazení nasazeni. A máme stále více a více náhodných DBA, lidí, kteří neměli formální výcvik.
Jaké jsou tedy některé další věci, které se také dostávají do problému skutečnosti, že tyto databáze nejsou také vyladěny nebo spravovány? Za prvé, mnoho lidí předpokládá, že samotný databázový systém má dostatečné nástroje, aby se mohl sám řídit. Nyní se nástroje stávají snazšími a snazšími - návrh a vývoj - ale to je jiné, než dělat dobrý návrh a dobré řízení, plánování kapacity, monitorování atd. Pro nasazení. Za prvé, lidé předpokládají, že mají všechny nástroje, které potřebují. Zadruhé, pokud jste na částečný úvazek nebo náhodný DBA, nevíte, co nevíte.
Myslím, že jsem na tu frázi zapomněl, takže mnohokrát prostě nechápou, na co se dokonce potřebují podívat v návrhu nebo když spravují nebo provozují databáze. Pokud to není vaše profese, nebudete rozumět tomu, co musíte udělat. Třetí z nich je, že SQL je nástrojem go-to, takže Robin mluvil o SQL a o tom, jak špatně je SQL někdy konstruováno nebo často konstruováno. A také jeden z mých mazlíčků v BI datových skladech, migrace dat, datový inženýrský prostor je to, že lidé místo používání nástrojů mají tendenci psát SQL kód, uložené procedury, i když používají nákladný nástroj pro integraci dat nebo jako drahý nástroj BI, často jej používají pouze ke spuštění uložených procedur. Takže význam porozumění návrhu databáze, konstrukce SQL, je stále důležitější.
A konečně je zde tento přístup k silu, ve kterém máme individuální lidi, kteří se dívají na jednotlivé databáze. Nedívají se na to, jak aplikace fungují a jak spolu komunikují. A také se často dívají na databáze versus aplikace, pro které je používají. Takže pracovní zátěž, kterou získáte v databázi, je kritická při návrhu, kritická při ladění, kritická při pokusu zjistit, jak plánovat kapacitu atd. Takže při pohledu na les ze stromů jsou lidé v plevele, při pohledu na jednotlivé tabulky a databáze a nehledě na celkovou interakci těchto aplikací v pracovní zátěži.
Nakonec se lidé musí podívat na klíčové oblasti, na které se musí podívat. Když plánují správu databází, musí nejprve promyslet, vyvinout některé metriky výkonu zaměřené na aplikace, takže se musí podívat nejen na to, jak je tato tabulka strukturována, jak je konkrétně modelována, ale jak se používá? Takže pokud máte podnikovou aplikaci, která je splatná v řízení dodavatelského řetězce, pokud odebíráte objednávky z webu, pokud děláte BI - ať už děláte cokoli - musíte se podívat na to, kdo ji používá, jak na to pomocí toho, co jsou objemy dat, když se to stane. To, co se opravdu snažíte hledat, jsou čekací doby, protože bez ohledu na to, všechny aplikace jsou posuzovány podle toho, jak dlouho trvá, než se něco stane, ať už je to osoba, nebo jen výměna dat mezi aplikacemi nebo procesory. A jaké jsou úzká místa? Takže často, když se pokoušíte ladit problémy, samozřejmě, opravdu se snažíte zjistit, jaké jsou skutečné překážky - ne nutně, jak naladit všechno, ale jak se zbavíte a posunete výkon nahoru po dobu čekání a propustnost - cokoli, na co se musíte podívat.
A opravdu musíte oddělit sběr dat, transakce, transformační aspekty v databázi spolu s analytiky. Každý z nich má odlišné vzory designu, každý z nich má odlišné vzory použití a každý z nich musí být vyladěn odlišně. Musíte tedy přemýšlet o tom, jak se tato data používají, kdy se používají, k čemu se používají, a zjistit, jaké metriky výkonu a jaké klíčové věci chcete analyzovat, související s tímto použitím. Nyní, když se díváte na sledování výkonu, se chcete podívat na samotné operace databáze; chcete se podívat na jak datové struktury, tak indexy, rozdělení a další fyzické aspekty databáze, dokonce i strukturu databáze - ať už je to model ER nebo rozměrový model, ať už je strukturovaný - všechny tyto věci mají vliv na výkon, zejména v různých kontextech analytiky sběru dat a transformací, ke kterým dochází.
A jak Robin zmínil na straně SQL, při pohledu na SQL, který tyto různé aplikace používají v těchto databázích, je jeho ladění kritické. A při pohledu na celkové pracovní zatížení aplikací a prostředí infrastruktury, na které tyto databáze a aplikace běží. Takže sítě, servery, cloud - ať už běží na jakémkoli místě - také přihlížejí k dopadu, který tyto aplikace a tyto databáze mají v tomto kontextu, mají všechny tyto souhry schopnost vyladit databázi.
A konečně, když se díváte na nástroje, chcete se podívat na tři různé druhy analytiků, které s tím souvisí. Chcete se podívat na popisnou analýzu: co se děje a kde souvisí s databází a výkonem aplikace. Chcete mít možnost provádět diagnostické analýzy, abyste zjistili nejen to, co se děje, ale proč se to děje, kde jsou úzká místa, kde jsou problémy, co běží dobře, co nefunguje dobře? Ale být schopen analyzovat a podrobně analyzovat problémové oblasti, abychom je mohli řešit, ať už jde o návrh nebo cokoli, co musíte udělat.
A konečně, nejagresivnějším nebo nejaktivnějším typem analýzy je skutečně provést nějakou prediktivní analýzu, prediktivní analytické modelování, cokoli. Víme, že databáze a aplikace v této souvislosti fungují, pokud jsme zvýšili kapacitu, pokud získáme více uživatelů, pokud děláme větší propustnost, ať už děláme cokoli, budeme schopni navrhnout, co, jak a kde to bude dopad na databázi, aplikace, nám umožňuje naplánovat a proaktivně zjistit, kde jsou úzká místa, kde by mohly trpět čekací doby a co musíme udělat, abychom věci napravili. Chceme tedy mít nástroje, které jsou schopny implementovat metriky výkonu, sledovat výkon, stejně jako tyto tři typy analýz. A to je můj přehled.
Eric Kavanagh: Dobře, nech mě to podat - mimochodem, jsou to dvě skvělé prezentace - nech mě to podat Bullettovi Manaleovi, abych to odtamtud vzal. A lidé, nezapomeňte položit dobré otázky; už máme nějaký dobrý obsah. Vem si to, Bullette.
Bullett Manale: Zní to dobře. Díky, Ericu. Takže hodně z toho, co řekl Rick a Robin, samozřejmě souhlasím se 100 procenty. Řekl bych, že jsem tento snímek vytáhl, protože si myslím, že je to vhodné, nevím pro ty z vás, kteří jsou fanoušky „týmu A“ v 80. letech, John Hannibal Smith řekl, že vždycky řekni: „Líbí se mi, když se plán spojí, “ a myslím si, že když mluvíme zejména o serveru SQL, na který se zaměřujeme, což je produkt, o kterém dnes budeme mluvit, SQL Diagnostic Manager, je to určitě jedna z věcí, které musíte mít; musíte být schopni využít data, která máte, a musí být schopna se z nich rozhodnout av některých případech nehledáte rozhodnutí; hledáte něco, co vám řekne, když se něco vyčerpá, když se vám vyčerpají zdroje, když budete mít úzký profil, takové věci.
Nejde jen o sledování konkrétní metriky. S Diagnostickým manažerem vám tedy jednou z věcí, které se daří velmi dobře, pomůže předpovědět a porozumět konkrétním pracovním vytížením a dnes o tom budeme hodně mluvit. Tento nástroj je určen pro správce dat, DBA nebo úřadující DBA, takže spousta věcí, o kterých se Rick zmínil, je úřadující DBA tak pravdivá. V mnoha případech, pokud nejste DBA, existuje spousta otazníků, které budete mít, když přijde čas na správu prostředí SQL, věci, které nevíte. A tak hledáte něco, co by vám mohlo pomoci, probrat vás tímto procesem a také vás v tomto procesu vzdělávat. A proto je důležité, aby vám nástroj, který používáte pro tyto druhy rozhodnutí, poskytl nějaký vhled do důvodů, proč se tato rozhodnutí dělají, nejen vám říká: „Hej, udělej to.“
Protože jsem úřadující DBA, nakonec bych mohl být plně rozvinutý DBA se skutečnou odborností a znalostmi, které tento titul podporují. To znamená, že když mluvíme o tom, že jsem administrátorem databáze - vždycky jsem si nejprve představil tento snímek, protože DBA má různé role a v závislosti na organizaci, se kterou jste, budete mít, ty se budou lišit z jednoho místa na druhé - ale obvykle budete vždy nějakým způsobem zodpovědní za vaše úložiště, za plánování tohoto úložiště a porozumění předvídání, měl bych říci, kolik místa jdete potřebovat, ať už je to pro vaše zálohy, nebo zda je to pro samotné databáze. Musíte to pochopit a posoudit.
Kromě toho budete muset být schopni porozumět a optimalizovat věci podle potřeby, a jak procházíte monitorováním životního prostředí, je samozřejmě důležité, abyste provedli změny podle potřeby na základě věcí, které jsou změna v samotném prostředí. Při provádění předpovědí by se tedy mělo brát v úvahu například počet uživatelů, věci jako popularita aplikací, sezónnost databáze. A pak, očividně se podíváme na další věci, pokud jde o schopnost poskytovat zprávy a informace, které jsou nezbytné, pokud jde o přijímání těchto rozhodnutí. V mnoha případech to znamená provést srovnávací analýzu; to znamená být schopen podívat se konkrétně na konkrétní metriku a porozumět tomu, jaká hodnota této metriky byla v průběhu času, takže můžete předvídat, kam se bude posunout vpřed.
To, co mnoho nástrojů Diagnostic Manager dělá, má tyto schopnosti a lidé je používají každý den, aby mohli dělat věci, jako je předpovídání, a já sem definuji plánování kapacit. A je to docela široká a vlastně docela vágní definice, což je pouze proces určování výrobní kapacity, kterou organizace potřebuje ke splnění měnících se požadavků na své produkty, a na konci dne je to opravdu to, o co jde: Je to o tom, že budete moci přijímat informace, které máte nějakým způsobem, a přijímat tyto informace a přijímat rozhodnutí, která vám pomohou posunout se vpřed v průběhu životního cyklu vašich databází. A tak jsou typy věcí, které jsou důvodem, proč to lidé potřebují, v první řadě především v zájmu úspory peněz. Podniky jsou samozřejmě jejich hlavním cílem vydělávat peníze a šetřit peníze. Ale v tomto procesu to také znamená, že se můžete ujistit, že vaše prostoje nejsou žádné prostoje. A být schopen ujistit se, že zmírníte jakoukoli šanci na prostoje, a tak zabránit tomu, aby se to stalo, aby začalo, jinými slovy, nečekáním, až se to stane, a pak na něj reagujete.
Kromě toho, že dokážete celkově zvýšit produktivitu svých uživatelů, je jejich zefektivnění, abyste mohli udělat více práce, zřejmě klíčem zde, takže se jedná o typy věcí, které jako DBA nebo někdo zapojený do předpovědí nebo kapacity plánování bude muset být schopno prokousat se informacemi, aby bylo možné tato rozhodnutí učinit. Celkově to samozřejmě pomůže odstranit odpad, nejen odpad z hlediska peněz, ale také z hlediska času a zpravidla obecně zdrojů, které by mohly být použity na jiné věci. To znamená, že jste schopni tento odpad eliminovat, abyste nemuseli mít příležitostné náklady spojené s odpadem samotným.
Takže, s tím řekl, jaké typy otázek, které dostáváme, specifické pro osobu, která je DBA? Kdy budu mít nedostatek místa? To je velký, nejen to, kolik prostoru nyní spotřebovávám, ale kdy mi došly vyčerpané trendy a minulost? Stejná věc se skutečnými instancemi SQL, databázemi, které servery mohu konsolidovat? Chystám se dát nějaké na VM, co má smysl, pokud jde o to, které databáze budu konsolidovat a jaké instance SQL by měly být umístěny? Na všechny tyto typy otázek musí být možné odpovědět. Protože ve většině případů, pokud jste DBA nebo jednáte DBA, budete ji konsolidovat někdy ve své kariéře. V mnoha případech to budete dělat průběžně. Musíte tedy být schopni rychle se rozhodovat a nehrát při tom hádající hry.
Mluvili jsme o úzkých místech a o tom, kde se budou dále vyskytovat, a mohli jsme to předvídat, místo aby čekali, až k nim dojde. Samozřejmě všechny tyto věci, o kterých mluvíme, mají smysl v tom smyslu, že se spoléháte na historická data, ve většině případů, na to, aby byla schopna tato doporučení vygenerovat, nebo v některých případech na formulaci rozhodnutí sami, být schopen přijít s těmito odpověďmi. Připomíná mi to však, že když uslyšíte rozhlasové reklamy na někoho, kdo prodává cenné papíry nebo něco podobného, je to vždy „minulý výkon nesvědčí o budoucích výsledcích“ a podobné věci. A to samé platí i zde. Budete mít situace, kdy tyto prognózy a tyto analýzy nemusí být na 100% správné. Ale pokud máte co do činění s věcmi, které se odehrály v minulosti a se známými, a jste schopni brát a dělat „co kdyby“ s mnoha těmito typy otázek, na které narazíte, je velmi cenné a dostane vás to mnohem dále, než hraní hádanky.
Takže tyto typy otázek zjevně přijdou, takže jak zvládáme spoustu těchto otázek s Diagnostickým manažerem, v první řadě máme předpovědní schopnosti, abychom to dokázali udělat v databázi, také u stolu. jako jednotka nebo svazek. Abychom mohli nejen říci: „Hej, jsme plné vesmíru, “ ale za šest měsíců, za dva roky, za pět let, pokud na to budu počítat, kolik místa budu řídit potřebovat rozpočet? To jsou otázky, na které se budu muset zeptat, a budu muset být schopen použít nějakou metodu, než abych hádal a zvedl prst do vzduchu a čekal, jak vítr fouká, což je bohužel mnohokrát způsob, jakým se tato rozhodnutí přijímají.
Kromě toho, že jsem schopen - vypadá to, že se můj snímek tam trochu odřízl -, ale jsem schopen poskytnout nějakou pomoc ve formě doporučení. Je tedy jedna věc, kterou vám mohu ukázat na hlavním panelu, který je plný metrik, a být schopen říci: „Dobře, tady jsou všechny metriky a kde jsou, “ ale pak mít možnost něco udělat nebo porozumět co dělat, na základě toho je další skok. A v některých případech jsou lidé dostatečně vzdělaní v roli DBA, aby byli schopni učinit tato rozhodnutí. A tak máme v nástroji nějaké mechanismy, které vám s tím pomohou, které vám ukážeme za vteřinu. Ale být schopen ukázat nejen to, co je doporučení, ale také poskytnout určitý pohled na to, proč se toto doporučení vydává, a pak také na vrcholu toho, že v některých případech může skutečně přijít se skriptem, který automatizuje Náprava tohoto problému je také ideální.
Jdeme-li na další, což uvidíme, je to obecně řečeno pochopení až k metrické úrovni, co je normální. Nemůžu vám říct, co není normální, pokud nevím, co je normální. A tak máte nějaký způsob, jak změřit to, co je klíčové, a musíte mít možnost vzít v úvahu několik typů oblastí, například - nebo bych měl říci časové rámce - různá seskupení serverů, která jsou schopna to dělat dynamicky, z pohledu upozornění, jinými slovy, během noci, během okna údržby očekávám, že můj procesor bude běžet na 80 procent na základě veškeré údržby, která se děje. Takže bych mohl chtít zvýšit své prahy výše, během těch časových rámců versus během možná uprostřed dne, kdy nemám tolik aktivity.
To jsou některé věci, které samozřejmě budou ekologické, ale věci, které můžete použít na to, co je spravováno, abyste byli schopni pomoci vám efektivněji spravovat toto prostředí a usnadnit to. Druhá oblast je samozřejmě schopna pouze poskytnout zprávy a informace, aby byla schopna odpovědět na tyto typy otázek „co kdyby“. Pokud jsem právě provedl změnu svého prostředí, chci pochopit, jaký dopad to mělo, abych mohl stejnou změnu použít na jiné instance nebo jiné databáze v mém prostředí. Chci mít nějaké informace nebo munici, abychom mohli tuto změnu provést s jistým klidem a vědomím, že to bude dobrá změna. Takže, když mohu udělat srovnávací reportování, umět porovnat své instance SQL, umět porovnat své databáze proti sobě, říci: „Který je můj největší spotřebitel CPU?“ Nebo který z nich je nejdelší v podmínky čekání a podobné věci? Spousta těchto informací bude tedy k dispozici také s tímto nástrojem.
A v neposlední řadě je to jen celková schopnost, že potřebujete nástroj, který bude schopen zvládnout jakoukoli situaci, která vám přijde na cestu, a tím myslím, že pokud máte velké prostředí s v mnoha případech se pravděpodobně setkáte s situacemi, kdy budete muset vytáhnout metriky, které tradičně nejsou metriky, které by DBA v některých případech chtěla dokonce sledovat, v závislosti na konkrétní situaci. Mít nástroj, který můžete rozšířit, abyste mohli přidávat další metriky a mohli tyto metriky používat ve stejné podobě a způsobem, jaký byste použili, kdybyste použili out-of-the-box metrika, například. Takže schopnost spouštět zprávy, být varovný, základní - všechny věci, o kterých mluvíme - je také klíčovou součástí schopnosti provádět tuto prognózu a dělat ji tak, abyste dostali odpovědi, které hledáte. být schopen činit tato rozhodnutí a postupovat vpřed.
Nyní, jak to Diagnostic Manager provádí, máme centralizovanou službu, skupinu spuštěných služeb, která shromažďuje data v případech 2000 až 2016. A pak to, co děláme, je, že vezmeme ta data a vložíme je do centrálního úložiště a pak to, co s těmito daty uděláme, je zjevné, že děláme hodně pro to, abychom mohli poskytnout další informace. Nyní kromě toho - a jednou z věcí, která zde není - máme také službu, která běží uprostřed noci, což je naše služba prediktivní analýzy, a která dělá určité množství křupání a pomáhá porozumět a pomůže vám jako DBA nebo jako DBA, abyste byli schopni vydat tyto typy doporučení, abyste mohli také poskytnout určitý vhled do základních linií.
Takže to, co bych chtěl udělat, a to je jen rychlý příklad architektury, je tu velká cesta s sebou, že neexistují agenti ani služby, kteří by ve skutečnosti seděli na instancích, které spravujete. Ale to, co bych chtěl udělat, je to, že vás ve skutečnosti vezmu do aplikace a dá vám rychlé ukázky. A dovolte mi, abych také vyšel ven a aby se to stalo. Takže, dejte mi vědět, myslím, Ericu, můžete to vidět dobře?
Eric Kavanagh: Mám to hned, jo.
Bullett Manale: Dobře, takže vás provedu některými z těchto různých částí, o kterých jsem mluvil. A v podstatě začněme s věcmi, které jsou více v souladu s tu, je něco, co musíte udělat, nebo tady je něco, co je časovým bodem v budoucnosti a my vám poskytneme nějaký vhled do toho. A to je schopno opravdu předvídat - nebo bych měl říci dynamicky předvídat - věci, které se dějí. Nyní, v případě zpráv, jednou z věcí, které v nástroji máme, jsou tři různé prognostické zprávy. A například v případě předpovědi databáze, co bych asi udělal v situaci, kdy budu schopen předvídat velikost databáze po určitou dobu, a uvedu jen několik příkladů . Takže si vezmu svou auditní databázi, což je docela I / O intenzivní - je do toho spousta dat. Máme, podívejme se, uděláme to tady a pojďme si jen vybrat zdravotní databázi sem.
Jde ale o to, že nejenom vidím, v čem je prostor, ale mohu říci: „Podívejme se, vezmeme data z loňského roku“ - a trochu se sem trochu vrhnu, Opravdu nemám roční data, mám asi dva měsíce dat - ale protože zde volím vzorkovací frekvenci měsíců, budu v tom moci předvídat nebo předpovídat případ dalších 36 jednotek, protože naše vzorkovací frekvence je nastavena na měsíce - to je jednotka, je měsíc - a pak bych byl schopen, pak spustit zprávu, která mi v podstatě ukáže, kde bychom očekávali náš budoucí růst, pro tyto tři databáze. A vidíme, že mezi těmito třemi různými databázemi máme různý stupeň rozdílnosti nebo rozptylu, zejména co se týče množství dat, která historicky spotřebovávají.
Vidíme, že datové body zde představují historická data, a pak nám linka poskytne prognózu spolu s čísly, která ji zálohují. Můžeme to udělat na úrovni stolu, můžeme to udělat i na úrovni jednotky, kde mohu předvídat, jak velké budou moje disky, včetně bodů připojení. Byli bychom schopni předpovědět stejný typ informací, ale znovu, v závislosti na vzorkovací frekvenci, mi dovolím určit, kolik jednotek a kam bereme to, co chceme předpovědět. Všimněte si také, že máme různé typy předpovědí. Takže, když přijde čas na předpovědi, získáte spoustu možností a flexibilitu. Nyní je to jedna věc, kterou uděláme, ve skutečnosti, že vám poskytneme konkrétní datum a budeme moci říci: „Ahoj k tomuto datu, tady bychom očekávali růst vašich dat.“ Kromě toho však můžeme poskytnout vám další informace, které se vztahují k některým analýzám, které provádíme v době mimo provoz a službě, když je spuštěna. Některé z věcí, které dělá, je to, že se snaží předvídat věci, které se pravděpodobně stanou, na základě historie, kdy se věci odehrály v minulosti.
Takže zde vidíme, prognóza nám skutečně poskytuje určitý náhled na pravděpodobnost, že budeme mít problémy během celého večera na základě věcí, které se znovu staly v minulosti. Takže to je samozřejmě skvělé, zejména pokud nejsem DBA, mohu se na tyto věci podívat, ale co je ještě lepší, když nejsem DBA, je tato karta analýzy. Takže předtím, než to tady bylo v nástroji, bychom procházeli a ukazovali produkt lidem a byli by „To je skvělé, vidím všechna tato čísla, vidím všechno, ale nevím, co dělat“ (směje se) "V důsledku toho." A tak to, co tady máme, je pro vás lepší způsob, jak porozumět, pokud se chystám jednat, abych pomohl s výkonem, pokud se chystám podniknout kroky i pomoci se zdravím mého prostředí, mít možnost uspořádat způsob poskytování těchto doporučení, jakož i užitečné tipy v informacích, aby se dozvěděli více o těchto doporučeních a dokonce mít dokonce externí odkazy na některá z těchto údajů, které mi ukážou a vezměte mě k důvodům, proč jsou tato doporučení učiněna.
A v mnoha případech je schopen poskytnout skript, který by automatizoval, jak jsem řekl, nápravu těchto problémů. Nyní, část toho, co tady děláme s touto analýzou - a ukážu vám, když se chystám konfigurovat vlastnosti této instance, a jdu do sekce konfigurace analýzy - máme mnoho různých kategorií, které jsou jsou zde uvedeny a součástí toho je optimalizace indexů a optimalizace dotazů. Hodnotíme tedy nejen samotné metriky a podobné věci, ale také věci, jako je pracovní vytížení a indexy. V tomto případě skutečně provedeme další hypotetickou analýzu indexů. Takže je to jedna z těch situací, kdy nechci, v mnoha případech nechci přidat index, pokud to nepotřebuji. Ale v určitém okamžiku existuje nějaký bod zvratu, kde říkám: „No, tabulka se dostává do velikosti nebo typů dotazů, které jsou spuštěny v rámci pracovního vytížení, nyní má smysl přidat index. Ale to by nedávalo smysl možná šest týdnů předtím. “Takže vám to umožní dynamicky získat přehled o věcech, které pravděpodobně, jak jsem řekl, zlepší výkon založený na tom, co se děje v životním prostředí, co se děje v rámci pracovního vytížení a dělat takové věci.
A tak získáte spoustu dobrých informací a schopnost automaticky optimalizovat tyto věci. To je další oblast, kde bychom mohli pomoci, pokud jde o to, čemu říkáme prediktivní analýza. Nyní bych kromě toho měl říci, že máme i další oblasti, o kterých si myslím, že se vám obecně mohou pomoci při rozhodování. A když hovoříme o rozhodování, znovu, když se můžeme podívat na historická data, poskytněte nám nějaký náhled, abyste nás dostali tam, kde musíme být, abychom zlepšili tento výkon.
Jednou z věcí, které můžeme udělat, je, že máme základní vizualizér, který nám umožňuje vybrat si libovolnou metriku, kterou chceme - a dovolte mi najít slušnou metriku - jdu na využití SQL CPU, ale jde o to, že jste můžete se však vrátit o mnoho týdnů, abyste tyto obrázky namalovali, abyste viděli, kdy jsou vaše odlehlé hodnoty, a obecně mluvíme, kde tato hodnota spadá do období, ve kterém shromažďujeme data. A pak si navíc všimnete, že když jdeme na samotnou skutečnou instanci, máme možnost nakonfigurovat naše základní linie. A základní linie jsou opravdu důležitou součástí o tom, že jsou schopny automatizovat věci a být informováni o věcech. A výzvou, jak by vám většina DBA řekla, je, že vaše prostředí neběží vždy stejně, v průběhu dne, proti večeru a co jiného, jak jsme se zmínili dříve v příkladu s udržovacími časovými obdobími, když jsme mají vysokou úroveň CPU nebo cokoli, co by se mohlo stát.
Takže v tomto případě s těmito skutečnými základními hodnotami můžeme mít několik základních linií, takže bych mohl mít například základní linii, to je během mých hodin údržby. Ale stejně snadno jsem mohl vytvořit základní linii pro své produkční hodiny. A smysl toho je, když jdeme na instanci SQL a máme skutečně tyto více základních linií, pak bychom byli schopni předvídat a být schopni provést nějaký typ automatizace, nějaký typ nápravy nebo jen upozornit obecně, jinak specifické pro tato okna času. Jedna z věcí, které zde uvidíte, jsou tedy tyto základní linie, které vytváříme, pomocí historických dat k poskytnutí této analýzy, ale co je důležitější, mohu tyto prahy staticky změnit, ale také je mohu také automatizovat také dynamicky. Když se objeví okno údržby, nebo bych měl říci, že se objeví základní okno údržby, tyto prahové hodnoty by se automaticky přepínaly podle zatížení, s nimiž se setkávám v tomto časovém okně, oproti možná uprostřed dne, kdy jsou moje zatížení ne tolik, když pracovní zátěž není tak působivá.
Takže na něco jiného je třeba mít na paměti, pokud jde o základní hodnotu. Je zřejmé, že pro vás budou opravdu užitečné, pokud jde o pochopení toho, co je normální, a také o porozumění, zapojte se, když vám docházejí i zdroje. Teď, další věc, kterou v nástroji máme, to vám pomůže při rozhodování, kromě toho, že budete mít základní linie a budete moci nastavit upozornění kolem těchto základních linií a prahových hodnot, které dynamicky vytváříte, je, jak jsem již řekl dříve, prostě umím spouštět nespočet zpráv, které mi pomáhají odpovídat na otázky o tom, co se děje.
Například, kdybych měl 150 instancí, které řídím - v mém případě ne, tak musíme hrát předstíranou hru - ale kdybych měl všechny své produkční instance a potřeboval jsem pochopit, kde je na oblast, na kterou potřebuji pozornost, jinými slovy, pokud budu mít jen omezené množství času na provedení nějakého typu správy ke zlepšení výkonu, chci se zaměřit na klíčové oblasti. A tak, s tím řekl, bych mohl říci: "Na základě tohoto prostředí, pořadí mé instance proti sobě, a dát mi, že pořadí podle soupeření potrubí." Takže ať už je to využití disku, využití paměti, ať už to čeká, ať už je to doba odezvy, dokážu korelovat - nebo bych měl říci hodnost - ty případy proti sobě. Je zřejmé, že instance, která je na začátku každého seznamu, je-li to stejná instance, je to pravděpodobně něco, na co se opravdu chci zaměřit, protože je to evidentně znovu v horní části seznamu.
V nástroji máte tedy mnoho zpráv, které vám pomohou z hlediska hodnocení prostředí na úrovni instance; můžete to udělat také na úrovni databáze, kde mohu své databáze zařadit proti sobě. Zejména s ohledem na prahy a oblasti, které mohu nastavit, mohu zde dokonce nastavit zástupné znaky, pokud se chci, soustředit pouze na konkrétní databáze, ale jde o to, že své databáze mohu srovnávat stejným způsobem. Pokud jde o jiné typy srovnávací analýzy a velký v tomto nástroji, je také základní analýza, kterou máme. Pokud tedy přejdete dolů do zobrazení služby, uvidíte, že existuje základní statistická zpráva. Nyní tato zpráva nám zjevně pomůže pochopit nejen to, co jsou metrické hodnoty, ale v konkrétním případě bych mohl jít ven, a pro kteroukoli z těchto metrik se budu moci podívat na základní linie těchto metrik.
Takže ať už to bude cokoli, jako procento nebo cokoli, co bych mohl jít ven a říci: „Podívejme se na základní linii pro toto vypuknutí za posledních 30 dní, “ v tom případě mi ukáže skutečné hodnoty versus základní linii a Já bych byl schopen učinit některá rozhodnutí s využitím těchto informací, samozřejmě, takže toto je jedna z těch situací, kdy bude záležet na tom, jaká otázka to je, na kterou se v tu chvíli ptáte. Ale to vám očividně pomůže při mnoha těchto otázkách. Přál bych si, abych řekl, že máme jednu zprávu, která to všechno zvládne, a je to něco jako snadná zpráva, kde stisknete a stisknete tlačítko a jen odpoví na každou otázku „co kdyby“, na kterou byste mohli kdy odpovědět. Ale realita je, že budete mít spoustu atributů a spoustu možností, ze kterých si budete moci v těchto rozbalovacích nabídkách vybrat, abyste mohli formulovat ty otázky typu „co kdyby“, které hledáte .
Mnoho těchto zpráv je tedy zaměřeno na to, aby byly schopny odpovědět na tyto typy otázek. A tak je opravdu důležité, aby tyto přehledy a navíc všechny věci, které jsme vám již v nástroji ukázali, jak jsem již zmínil, mají flexibilitu pro začlenění nových metrik, které mají být spravovány, a dokonce mohou vytvářet čítače nebo dotazy SQL, které jsou začleněny do vašich intervalů dotazování, aby mi mohly pomoci odpovědět na tyto otázky, které možná po vybalení z krabice, které jsme neočekávali, že budeme sledovat, můžete tyto věci přidat. A pak byste mohli dělat všechny stejné věci, které jsem vám právě ukázal: základní, spouštět přehledy a vytvářet zprávy z této metriky a být schopen odpovídat a dělat mnoho z těchto různých typů věcí, které vám ukazuji tady.
Nyní kromě toho - a jednou z věcí, se kterou jsme se v poslední době zřejmě potkali - je to nejprve, všichni přepínali nebo přecházeli na VM. A teď máme mnoho lidí, kteří míří do cloudu. A kolem těchto typů věcí se objevuje spousta otázek. Má smysl se přesunout do cloudu? Budu šetřit peníze přesunem do cloudu? Kdybych měl dát tyto věci do virtuálního počítače, do počítače se sdílenými prostředky, kolik peněz mohu ušetřit? Tyto typy otázek se samozřejmě také objeví. Takže s řadou těchto věcí mějte na paměti, že s Diagnostickým manažerem můžeme přidávat a stahovat z virtualizovaných prostředí VMware i Hyper-V. Můžeme také přidat instance, které jsou mimo cloud, takže vaše prostředí, jako je například Azure DB, nebo dokonce RDS, můžeme také z těchto prostředí vytahovat metriky.
Takže existuje spousta flexibility a spousta schopností odpovědět na tyto otázky, protože se týká těch jiných typů prostředí, do kterých vidíme lidi mířící. A kolem toho je stále spousta otázek a jak vidíme lidi, jak konsolidují tato prostředí, musí na tyto otázky také odpovědět. Řekl bych tedy, že je to docela dobrý přehled o nástroji Diagnostic Manager, protože se týká tohoto tématu. Vím, že se objevil předmět business intelligence a máme také nástroj pro business intelligence, o kterém jsme dnes nemluvili, ale také vám poskytne informace o zodpovězení těchto typů otázek, protože se týká vašich kostky a všechny ty různé druhy věcí. Doufejme však, že se jedná o dobrý přehled, alespoň pokud jde o to, jak tento produkt může pomoci s formulací dobrého plánu.
Eric Kavanagh: Dobře, dobré věci. Jo, vyhodím to Rickovi, jestli tam bude pořád. Ricku, máš nějaké otázky?
Rick Sherman: Ano, tak první, je to skvělé, líbí se mi to. Obzvláště se mi líbí rozšíření na VM a mraky. Vidím mnoho vývojářů aplikací, kteří si myslí, že pokud je v cloudu, nemusí to naladit. Tak-
Bullett Manale: Správně, musíme za to stále platit, že? Stále musíte platit za cokoli, co lidé vkládají do cloudu, takže pokud je špatně spuštěný nebo způsobuje mnoho cyklů CPU, je to více peněz, které musíte zaplatit, takže to není stále je třeba měřit tyto věci, absolutně.
Rick Sherman: Jo, viděl jsem v cloudu spoustu špatných návrhů. Chtěl jsem se zeptat, bude tento produkt také použit - vím, že jsi zmínil produkt BI a máš spoustu dalších produktů, které spolu vzájemně reagují - ale začal bys zkoumat výkon SQL, jednotlivé dotazy v tomto nástroji? Nebo by na to byly použity jiné nástroje?
Bullett Manale: Ne, to by rozhodně . To je jedna z věcí, které jsem nezakryl a kterou jsem chtěl, je část dotazů. Máme mnoho různých způsobů, jak identifikovat výkon dotazu, ať už se týká, konkrétně čeká, jak vidíme v tomto zobrazení, nebo zda souvisí s celkovou spotřebou dotazů, existuje celá řada způsobů, jak můžeme analyzovat dotaz. výkon. Je to, zda je to doba trvání, CPU, I / O, a ještě jednou, můžeme se také podívat na pracovní zátěž sami, abychom poskytli určitý náhled. Doporučení můžeme poskytnout v části analýzy a také máme webovou verzi, která poskytuje informace o samotných dotazech. Takže mohu získat doporučení ohledně chybějících indexů a schopnosti zobrazit plán provádění a všechny takové věci; je to také schopnost. Takže, absolutně, můžeme diagnostikovat dotazy sedm způsobů do neděle (směje se) a být schopni poskytnout tento vhled, pokud jde o počet poprav, ať už jde o spotřebu zdrojů, čekání, trvání, vše dobré.
Rick Sherman: Dobře, skvěle. A co je tedy zátěž samotných instancí při tomto sledování?
Bullett Manale: Je to dobrá otázka. Výzvou při zodpovězení této otázky je, že záleží, je to jako cokoli jiného. Spousta toho, co náš nástroj nabízí, poskytuje flexibilitu a součástí této flexibility je, že mu řeknete, co sbírat a co nesbírat. Takže například s dotazy samotnými nemusím shromažďovat informace o čekání, nebo mohu. Dokážu sbírat informace týkající se dotazů, které překračují dobu trvání, provedení. Jako příklad toho, kdybych měl jít do konfiguračního monitoru dotazů a měl jsem říct: „Pojďme tuto hodnotu změnit na nulu“, realita je taková, že nástroj v podstatě dělá nástroj, který shromažďuje každý spuštěný dotaz a to opravdu není ducha, proč je to tam, ale obecně, pokud bych chtěl poskytnout úplný vzorek dat pro všechny dotazy, mohl bych to udělat.
Takže je to velmi relativní k tomu, jaké jsou vaše nastavení, obecně řečeno, mimo krabici. Je to kdekoli od asi 1–3 procent režijních nákladů, ale existují i další podmínky, které budou platit. Záleží také na tom, kolik dotazů na port ve vašem prostředí běží, že? Závisí také na způsobu shromažďování těchto dotazů a na jaké verzi SQL. Například například SQL Server 2005 se nebudeme moci vytahovat z rozšířených událostí, zatímco tak bychom to vytáhli z trasování. Takže by to bylo trochu jiné, pokud jde o způsob, jakým bychom se shromažďovali tato data, ale to řekl, jak jsem řekl, jsme asi asi 2004 asi s tímto produktem. Je to už dlouho, máme tisíce zákazníků, takže poslední věcí, kterou chceme udělat, je nástroj pro sledování výkonu, který způsobuje problémy s výkonem (smích). A tak se snažíme vyhnout tomu co nejvíce, ale obecně řečeno, asi tak 1–3 procenta je dobrým pravidlem.
Rick Sherman: Dobře, a to je docela nízké, takže je to úžasné.
Eric Kavanagh: Dobře. Robine, máš nějaké otázky?
Robin Bloor: Omlouvám se, byl jsem na němý. Máte více databázových schopností a zajímalo by mě, jak se můžete podívat na více databází, a proto můžete vědět, že větší zdrojová základna je možná rozdělena mezi různé virtuální stroje atd. A tak dále. Zajímá mě, jak to lidé skutečně používají. Zajímá mě, co s tím zákazníci dělají. Protože to vypadá na mě, no, určitě, když jsem si hrával s databázemi, něco, co jsem nikdy neměl po ruce. A já bych kdykoli uvažoval o jednom případě jakýmkoli smysluplným způsobem v daném časovém okamžiku. Jak to lidé používají?
Bullett Manale: Obecně řečeno, mluvíte obecně jen o nástroji samotném? Jak to používají? Mám na mysli obecně to, že můžeme mít ústřední místo v životním prostředí. Mají klid a vědí, že když zírají na obrazovku a vidí zelenou, vědí, že je vše v pořádku. Je to, když se vyskytnou problémy a zřejmě většina případů z pohledu DBA, mnohokrát se tyto problémy stanou, když jsou před konzolou, takže mohou být informováni, jakmile se problém objeví. Ale kromě toho, být schopen pochopit, kdy se problém vyskytuje, být schopen dostat se k jádru informací, které jim poskytují nějaký kontext, pokud jde o to, proč se to děje. A to je, myslím, největší část: být aktivní, ne reaktivní.
Většina DBA, s nimiž mluvím - a nevím, je to jejich dobré procento - je bohužel stále v reaktivním prostředí; čekají, až k nim přistoupí spotřebitel a řekne jim, že je problém. A tak vidíme mnoho lidí, kteří se od toho snaží odtrhnout, a myslím si, že to je velká část důvodu, proč se lidem tento nástroj líbí, že jim pomáhá být proaktivní, ale také jim umožňuje nahlédnout do toho, co se děje, v čem je problém, ale v mnoha případech to, co najdeme - a možná je to jen o DBA, které nám to říkají - ale DBA, vnímání je vždy jejich problém, i když aplikaci napsal vývojář aplikace kteří to nenapsali správně, jsou to ti, kteří budou brát vinu, protože berou tuto aplikaci do svých systémů nebo serverů a když je výkon špatný, všichni poukazují na DBA říká: "Hej, je to tvoje chyba."
Tento nástroj je tedy mnohokrát použit na pomoc, pokud jde o to, aby DBA řekl: „Hej, tady leží problém a to nejsem já.“ (Smích) vylepšit to, ať už se jedná o změnu dotazů nebo cokoli jiného. V některých případech to spadne do jejich kbelíku, pokud jde o jejich odpovědnost, ale přinejmenším nástroj, který jim bude schopen pomoci jim to pochopit a vědět to, a dělat to včasným způsobem je zjevně ideální přístup.
Robin Bloor: Jo, většina stránek, které znám, ale už je to dávno, co jsem tam byl, díval jsem se na různá multi-databázová místa, ale většinou jsem zjistil, že tam bude DBA, které se zaměřily na hrst databází. A to by byly databáze, že kdyby někdy šly dolů, byl by to skutečný velký problém pro firmu, a tak dále a tak dále. A ty ostatní budou občas shromažďovat statistiky, aby viděli, že jim nedojde prostor a nikdy se na ně vůbec nepodívali. A zatímco jste dělali demo, na které jsem se díval, a já jsem přemýšlel dobře, tak či onak, rozšiřujete se tím, že poskytujete něco takového pro databáze, které byly často, o které se nikdo nestaral příliš, protože mají růst dat, mají občas i aplikační růst. Rozšiřujete pokrytí DBA celkem dramaticky. To je otázka, o které vlastně jde, je to, že se sadou nástrojů, jako je tento, jste nakonec schopni dát DBA službu každé databázi, která je v podnikové síti?
Bullett Manale: Jistě, myslím, že výzva je, že jak jste řekli docela výmluvně, je to, jako by existovaly nějaké databáze, o které se DBA zajímají, a pak některé, o které se tolik nestarají. A způsob, jakým je tento konkrétní produkt, způsob, jakým je licencován, vychází z jednotlivých instancí. Takže, myslím, že existuje práh, kdy se lidé rozhodnou „Hej, tohle není dostatečně kritická instance, kterou chci s tímto nástrojem spravovat.“ To znamená, že existují další nástroje, které děláme myslím, že to jsou více, myslím, vyhovující těm méně důležitým případům SQL. Jeden z nich by byl jako Správce zásob, kde provedeme lehké zdravotní kontroly s případy, ale kromě toho, co děláme, děláme objev, takže identifikujeme nové instance, které byly přivedeny online, a od té doby jako DBA mohu říci: „Dobře, tady je nová instance SQL, nyní je to Express? Je to bezplatná verze nebo podniková verze? “To je asi otázka, kterou si chci položit, ale za druhé, jak důležitá je pro mě tato instance? Pokud to není tak důležité, mohl bych nechat tento nástroj jít ven a dělat to, generické, co bych nazval generické zdravotní kontroly v tom smyslu, že jsou elementárními typy věcí, na kterých mi záleží jako DBA: Je jednotka zaplněna ? Reaguje server na problémy? Hlavní věci, že?
Zatímco s Diagnostickým manažerem, nástrojem, který jsem vám právě ukazoval, se dostane na úroveň dotazu, dostane se do doporučení indexů, podívá se na plán provádění a na všechny ty dobré věci, zatímco to je hlavně zaměřeno o tom, kdo co vlastní, co vlastním a kdo za to odpovídá? Jaké aktualizace Service Pack a hot opravy mám? A běží moje servery s hlavními složkami toho, co bych považoval za zdravý příklad SQL? Takže na odpověď na vaši otázku je trochu mix. Když se lidé dívají na tento nástroj, obvykle se dívají na kritičtější sadu případů. To znamená, že máme několik lidí, kteří nakupují každý případ, který mají, a spravují jej, takže to prostě záleží. Ale já vám celkově říkám, že je tu určitě práh těch lidí, kteří považují jejich prostředí za dost důležité, aby měli takovýto nástroj pro správu těchto případů.
Robin Bloor: Dobrá, další otázka, než jsem ji předal Ericovi. Dojem, který člověk získává, jen ze sledování průmyslu je, že databáze stále mají život, ale všechna data se nalévá do všech těchto datových jezer a tak dále a tak dále. To je humbuk, opravdu, a humbuk nikdy neodráží realitu, takže mě zajímá, jakou realitu tam venku vnímáš? Existují důležité databáze v rámci organizace, zažívají tradiční růst dat, který jsem kdysi považoval za 10 procent ročně? Nebo rostou víc než to? Vytváří velké množství těchto databází balón? Jaký je obrázek, který vidíš?
Bullett Manale: Myslím, že v mnoha případech vidíme, jak se některá data přesunují do těch dalších segmentů, kde to dává větší smysl, když jsou k dispozici další dostupné technologie. V poslední době se jedná o větší data. Ale tyto databáze, řekl bych, je v mnoha případech obtížné zobecnit, protože každý je trochu jiný. Obecně však vidím nějaké rozdíly. Vidím, jak jsem řekl, lidé se v mnoha případech pohybují k elastickým modelům, protože chtějí pěstovat zdroje a ne tolik v jiných oblastech. Někteří lidé se stěhují do velkých dat. Ale je těžké získat cit pro vnímání, protože obecně mluvíme o lidech, se kterými mluvím, všichni mají tradiční databáze a používají to v prostředí serveru SQL.
To znamená, že bych řekl, pokud jde o samotný SQL, určitě si stále myslím, že získává tržní podíl. A myslím si, že existuje spousta lidí, kteří stále směřují k SQL z jiných míst, jako je Oracle, protože je dostupnější a zdá se, že je evidentní, protože verze SQL se stávají vyspělejšími - a vidíte to s novějšími věcmi, které dělají s SQL, co se týče šifrování a všech dalších schopností, které z něj dělají prostředí nebo databázovou platformu - to je samozřejmě velmi kriticky schopné, myslím. Takže si myslím, že to také vidíme. Tam, kde vidíte posun, se to stále děje. Myslím, že se to stalo před 10 lety, myslím, že se to stále děje v souvislosti se serverem SQL Server, kde roste životní prostředí a roste podíl na trhu.
Robin Bloor: Dobře, Ericu, předpokládám, že publikum má otázku nebo dvě?
Eric Kavanagh: Jo, dovolte mi, abych vám hodil jednu rychlou. Je to vlastně docela dobrá otázka. Jeden z účastníků se ptá, řekne mi tento nástroj, zda může tabulka potřebovat index k urychlení dotazu? Pokud ano, můžete ukázat příklad?
Bullett Manale: Jo, takže nevím, jestli mám jeden pro konkrétní přidání indexu, ale můžete vidět zde, máme zde doporučení k fragmentaci. Věřím také, že jsme to právě měli, a to byla součást Diagnostického manažera nabízejícího webovou verzi, kde mi říká, že mám chybějící index. A můžeme si tato doporučení prohlédnout a to nám řekne potenciální zisk z toho indexováním těchto informací. Další věc, kterou bych měl zmínit, je, že když uděláme doporučení, pro mnoho z nich bude skript pro něj vytvořen. To není dobrý příklad, ale mohli byste vidět, ano, situace, kdy index - buď duplicitní index, nebo přidání indexu - by zlepšil výkon, a jak jsem řekl dříve, děláme hodně to pomocí hypotetické analýzy indexu. Skutečně tedy pomáhá porozumět pracovní zátěži, být schopen ji aplikovat na doporučení.
Eric Kavanagh: To je skvělé, a tohle mi dá dobré segue ke konečným komentářům zde. Robin a já a Rick také, slyšeli jsme už mnoho let, mluví se o samoladících databázích. Je to samoladící databáze! Vše, co vám můžu říct, je: Nevěřte jim.
Bullett Manale: Nevěřte v humbuk.
Eric Kavanagh: Mohou existovat nějaké malé malé věci, které se dynamicky dělají, ale přesto to možná budete chtít zkontrolovat a ujistit se, že nedělá něco, co nechcete. Takže nějakou dobu budeme potřebovat nástroje, jako je tento, abychom pochopili, co se děje na úrovni databáze, a jak řekl Robin, datová jezera jsou fascinující koncepty, ale pravděpodobně existuje asi tolik šancí, že se převezmou, protože existuje kdykoli bude Loch Ness Monster. Takže bych jen řekl, že skutečný svět má hodně databázových technologií, potřebujeme lidi, DBA, aby se na to podívali a syntetizovali. Můžete říct, že potřebujete vědět, co děláte, aby to fungovalo. Ale potřebujete nástroje, které vám poskytnou informace, abyste věděli, co děláte. A konečně, DBA se budou chovat dobře.
A velké díky Bullett Manale a našim přátelům v IDERA. A samozřejmě, Rick Sherman a Robin Bloor. Všechna tato webová vysílání archivujeme, takže hop online insideanalysis.com nebo na naše partnerské stránky www.techopedia.com pro více informací o tom všem.
A s tím vám nabídneme rozloučení, lidi. Ještě jednou díky, promluvíme si s tebou příště. Opatruj se. Ahoj.
