Игра на изпълнение: сбогом на латентността

От персонала на Техопедия, 9 май 2016 г.

Takeaway: Домакинът Ерик Кавана интервюира Марк Мадсън, Дез Бланчфийлд и Булет Манале относно латентността и представянето.

В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.

Партньор за съдържание на Techopedia

Персоналът на Techopedia е свързан с Bloor Group и може да се свърже с тях, като използвате опциите вдясно. За информация как работим с партньорите в бранша, кликнете тук.

• Профил
• уебсайт

Ерик Кавана: Дами и господа, здравей и добре дошли отново за горещи технологии! Да, именно! Казвам се Ерик Кавана, това е нашето Hot Tech шоу, партньорство с нашите добри приятели от Techopedia. Хоп онлайн към Techopedia.com за най-новите в широката сфера на корпоративните технологии; те, разбира се, обхващат и потребителските неща. Ние се фокусираме върху предприятието тук, в нашата програма, така че това ще правим днес.

Има място за вашето наистина и достатъчно за мен, ударете ме в Twitter @eric_kavanagh, аз обичам Twitter, обичам да проверявам тези неща, това е чудесен начин да поддържате връзка с хората и да провеждате добри разговори и еднократно -един разговор.

И така, за какво говорим? Тази година е гореща, това е цяла вселена от възможности, която разглеждаме днес в света на управлението на информацията, а това, за което говорим днес, ще бъде въпрос, ще бъде ускоряване на заявките.

Мисля, че забравих да спомена заглавието, „Игра на изпълнение: Кажете сбогом на латентността.“ Кой иска латентност? Никой не иска латентност, латентността е когато седите там, кликнете върху бутона и изчакайте да се случи нещо и никой не иска това. Децата не го харесват, не мислят, че е готино, възрастните също не го харесват. Всички бяхме разглезени от бързината на мрежата и искаме нещата бързо, искаме нещата сега и ще говорим за това днес в нашето шоу.

Анализаторът Марк Мадсен днес е с нас от Трета природа, един от нашите редовни. Новият ни учен с данни, Дез Бланчфийлд, обаждащ се от Сидни, Австралия. И тогава Bullett Manale, да, наистина, това е неговото име, всъщност трябва да са две T. Bullett Manale работи като наш гост от Idera, много, много интересна компания, прави много неща. Вече знам за тях, едно от които е, че си купиха компания, наречена Precision известно време назад. Знаех, че техният изпълнителен директор на име Зохар Гилад, как е това за име? Той беше един дявол на умен човек.

Но хора, вие играете значителна роля в тази уебкаст във въпросите, които задавате, така че, моля, не се срамувайте, изпращайте въпроси по всяко време - можете да го направите, като използвате компонента Q&A на конзолата за уебкаст, това е там долу в долния десен ъгъл. Можете също така да ми говорите и аз ще го разговарям към говорителите. Вече имаме някой, който се обажда от Италия, така че: „Ciao, ciao. Ела стай? ”Добре, с това, че ще натисна първия ред на Марк, ще предам палубата на Марк. Марк, сега имате WebEx. Отнеси го, пода е твой.

Марк Мадсън: Благодаря, Ерик. Все пак няма да започна в средата, ще започна в началото. Така че само няколко коментара, за да настроите дискусията с Dez и Idera, нещо като състояние на държавата с развитие и бази данни и операции. И знаете, ако погледнете на това, ние имаме подобни проблеми от два свята все още на пазара на базата данни и приложения, защото разработчиците разглеждат DBA като хората, които ги притесняват. Трябва да изградите модели на данни, не можете да имате достъп до това, не можете да създадете това нещо, не можете да поставите индекс на всяка колона на всяка таблица в базата данни, за да го направите по-бърз. И разбира се, защо ни трябват моделите? Това са просто структури от данни, ако ги променим, не може ли просто да ги изпишете в сериализирана форма?

Проблемът е, че разработчиците знаят код и приложения, но две неща, които често не знаят, са паралелността, едновременното програмиране и базите данни и операционните системи под тях. След като разработчик на ядро ​​и операционни системи и бази данни, мога да кажа, че паралелизмът и паралелизмът са наистина трудни и затова много неща, които се научите да получавате добри резултати от вашия код, наистина започват да се разпадат, когато сте работа с база данни. И производителността изглежда страхотна, тестовата среда изглежда страхотна, и Q&A средата, и след това се удря в реалната система, а след това изведнъж не е толкова голяма. Тъй като е многостранен, как кодът работи с базата данни, как работи с околната среда и наистина прости малки практики могат да имат драстични ефекти в зависимост от това коя скала използвате.

И когато започнете да говорите за външни приложения, разбира се, външно изправени приложения, уеб приложения, може да бъде наистина трудно, защото нещата са чудесни, докато изведнъж не се изравнят, а те не са. Ще уцелите тези интересни плата, които изискват много нюанси, за да ги разберете.

На обратната страна на нещата е изгледът на DBA. Прегледът на DBA е, че има операции, те прекарват по-голямата част от времето си, 80 до 90 процента, в операции и може би 10 до 20 процента, занимавайки се с разработките, които вървят напред. От тази гледна точка, или плащате сега, или плащате по-късно, и ако прекарвате цялото си време предварително, тогава ще имате много по-голям шанс по-късно, за разлика от развитието, което има тенденция да изследва функция пространство и се опитвате да разбера как най-добре да правите нещата. И така имаме проблеми и сега имаме несъвместими методологии - непрекъснато внедряване, навиване на вашите приложения винаги, когато са готови, правене на кодове периодично, работа в магазин, който практикува разработки. Този вид ускорява развитието, но всички практики около базата данни и какво правят DBA и какво са обучени да правят системните мениджъри, ИТ операционните практики не са вървели в крак.

Ако се замислите, повечето DBA работят в контролна среда за промяна спрямо среда на непрекъснато внедряване. Всичко е в стабилността и контрола, в сравнение със скоростта на промяна и обратимостта. Непрекъснатото внедряване, ако не можете да се върнете назад от промените, изпитвате проблеми, така че всичко трябва да бъде изградено, за да бъде лесно обратимо и да се превключва с код, което съвсем не е начинът, по който са работили релационната база данни, практиките на развитие и практиките на управление,

Вие също се сблъсквате с тези проблеми, че трябва да бъдете по-активни, ако можете, като DBA, тъй като до момента, когато чуете за проблем, сто хиляди души попълват формуляри за жалби на вашия уебсайт. Това ви оставя да имате нужда от някои нови неща, които да не излезете от старата си среда. Знаеш ли, неща като по-добро наблюдение и сигнализиране. В същото време базите данни се умножават, ние имаме повече приложения от всякога да поддържаме повече неща от всякога, те са вътре, те са навън, навсякъде са. И по-независими набори от данни за анализи, хората започват да стартират бази от данни навсякъде, защото, разбира се, сега е лесно, можете да настроите виртуална машина. Ако имате доставчик на облак или вътрешен облак, можете незабавно да изскачате нещата и това променя целия ви път за поръчки.

Старият път за закупуване беше: „Имам време да взема сървър, да го вкарам в багажник, да разпределя място, да събера място за съхранение, да инсталирате базата данни и да върша нещата“, срещу някой, който плъзне кредитната карта и отиде за пет минути. Ако направите това, съвременната среда за разработка работи с много различно темпо и затова е лесно да се създават бази данни и това просто създава този проблем на разпространение, като нищо, което сме виждали преди. И това продължава вече десет години, това не е новина за никого, но също така означава, че операционната среда е нараснала в сложност.

Цялата среда на клиентския сървър наистина се е променила, защото вече не е свят на клиентски сървър. Тогава имахте сървър, имате база данни, ако нещо не е наред, знаехте към кой сървър да отидете, знаехте как да управлявате ресурсите на него, защото най-добрата практика беше една база данни, един сървър. Виртуализацията започна да се разпада, облакът го разбива още повече, защото това, което смятате за сървър на база данни, е само софтуер. Така че средата не е реална. Това е, което съдържа средата, която е реалността, и това може да е багажник с остриета или голям сървър, изрязан на парчета, всъщност не знаете.

Всичко около администрирането на базата данни и управлението на производителността и какви бази данни са изградени около строг контрол с един сървър или шепа сървъри и няколко бази данни, не можете да контролирате всичко. Вие седите там на машина, но честотната лента не може да бъде разделена лесно от виртуалните мениджъри и така всичко може да се оправи с паметта и процесора, но сте затрупани с някакъв ресурс, който не може да се справи, и тогава, когато опитвате се да го поправите, старият модел щеше да е упорит, да получите по-голям сървър и да направите нещо подобно, сега може да е наистина просто, просто добавете виртуален курс, просто добавете памет към VM и това е решено. Но какво се случва, ако вашият VM е на пренаселен сървър и трябва да мигрира? Или какво се случва, ако сте в размер на AWS система и достигнете максималния размер, сега къде отивате?

Така че имате всички тези проблеми, когато средата е част от базата данни, пакетирате среда с база данни, всички специални ресурси, всичко в приложението, което е част от конфигурацията, конфигурацията се изтласква там. Това е от средата на базата данни, много по-трудно е да се управлява и контролира.

Ако погледнете какво правят центровете за бази данни, те са седяли на ръце, нали? Ние се отдалечаваме от тази идея за третиране на бази данни и сървъри като домашни любимци. Сървърите имат имена, отнасяте се към тях като към уникални неща поотделно, третирате ги като добитък, управлява стадо. Проблемът с управлението на стадата е, че ако не ги контролирате, в крайна сметка те могат да запечатват, а щамповането не е добро нещо. Имаме нужда от по-добри инструменти за мониторинг, имаме нужда от по-добри начини да се справим с тези неща и да знаем какво е засегнато. В стария модел беше по-лесно, защото вашите операционни системи и всичките ви системи за управление ви казаха, но когато името на вашия сървър е UPC код, е трудно да разберете нещата.

Не можете да си позволите фалшиви сигнали, не можете да си позволите неща, които казват: „Има проблем с тази машина и тази машина съдържа 30 бази данни.“ Не можете да си позволите да имате неща, които не ви носят история. Мониторните конзоли са страхотни, когато светнат, но ако червената светлина отново стане зелена и не знаете защо и нямате история, в която да се върнете, за да погледнете какво води до това и какво контекст беше, ти си в затруднение. Нуждаем се от системи, които ще следят за нас, имаме нужда от по-добро наблюдение, справяне с прекъсваемите проблеми, които поддържат тази история на данните.

По-добри неща и прости прагове на показателите, които ни дават ключови показатели, но не ни насочват директно към това какво е нормално, кое е ненормално и колко често се появяват тези проблеми. Това, за което наистина говорим, е комбинация от мониторинг на околната среда и справяне с производителността, а продавачите са седнали на ръце. Не са ни дали по-добри инструменти. Имаме системи с повече процесор и памет, отколкото знаем какво да правим с всичко това и въпреки това ние все още разчитаме на модели за ръчна интервенция, не сме поставили машината да работи, да ни ръководи, за да ни стигне до проблема, не сме стигнали до този нов стил, който е: „Тук има проблем, можете да го направите, за да го поправите“ или „Има проблем с производителността, всъщност е с това специфично SQL изявление, ето три неща, които бихте могли да направите използвайте, за да коригирате това SQL изявление. “Прилагане на евристика, прилагане на модели за машинно обучение, които могат да разгледат моделите на използване на вашата система, за да открият проблеми и да избегнат фалшиви сигнали. Използване на машината, за да направи това, което машината прави най-добре, за увеличаване на DBA или за увеличаване на човека, който трябва да се справи с проблеми с производителността.

Това е новият начин, за разлика от стария стил. Има проблем с тази база данни, нещата са бавни и затова имаме нови техники, нови начини да го направим и трябва да ги прилагаме, и там е тръгнал пазарът. Виждате как започва да се изрязва, не с големите доставчици, а с компании от трети страни, и това е отражение на нещо, което се случи преди 20 години, когато доставчиците на база данни не предоставиха нито едно нещо, което да помогне за управлението на системите. Така че това е каква е посоката на пазара и с това бих искал да го върна на Ерик.

Ерик Кавана: Добре, ще го предам на Дез. А Дез, махни го, пода е твой.

Дез Бланчфийлд: Благодаря ти, Марк. Направихте фантастична работа по покриването на техническия компонент на него. Ще дойда от него от малко по-различен ъгъл, за да подчертая случилото се в останалия свят, що се отнася до въздействието върху бизнеса и базите данни около тях. Нека просто прескоча до първия ми слайд.

На гърба на това, което току-що сте обхванали от техническата страна на нещата и от страна на разработчиците на нещата, виждам, че предприятията трябва да се справят по-специално с предизвикателството на данните и базите данни, и очевидно сме имали това значително изместване тази концепция за големи данни, но ефективно базите данни все още са сърцето и душата на мястото, където организациите запазват своята бизнес информация, и тя е от входната врата чак до задния офис. Всяка част от организацията е докосната от някаква база данни и захранвана от база данни и много рядко влизам или в дискусии по проекти, или в някаква форма на иновативен стратегически разговор в организация, където темата за базата данни или системата от база данни не се появява и винаги има въпроси около типовете неща, за които току-що чухме, по отношение на производителността и сигурността и как развитието идва с това предизвикателство и къде се вписват базите данни, както и познаването ни на средата и приложението срещи говорят, какво ще кажете за устройствата и мобилността?

Това все още е много, много гореща тема и е дълго, дълго време в голямата схема на нещата, доколкото стига съвременните технологии. До този момент смятам, че е факт, че почти всичко, което правим в ежедневния си живот, в ежедневието си, което е, което сега се поддържа от някаква форма на база данни. Когато мислим за всички неща около нас, независимо дали става въпрос за сметка, която всеки ден идва по пощата за някаква услуга, която купуваме, неминуемо се отпечатва от система, която говори с база данни, и ние сме там. Нашите телефони имат бази данни на тях с контактите и дневниците на обажданията и други неща.

Където и да отидем, има някаква форма на база данни зад разговора и системите, които използваме, и по-често, отколкото не, те са доста прозрачни за нас, но факт е, че те са там. Затова реших, че бързо ще разгледам защо това се превърна в проблем за много кратък период от време. В началото концепцията за базата данни идва от този прекрасен джентълмен, Едгар Код. Докато работи в IBM, той промени света, що се отнася до управлението на данни, като създаде концепция, която ние наричаме сега релационна база данни.

В началото базата данни беше база данни и животът беше добър, беше доста лесен и в колони, и в препратки, и така нататък, и в таблици, и разработването на софтуер беше доста просто, а производителността всъщност не беше толкова голям проблем - това беше нова вълнуваща технология. Ние осъществихме достъп до базите данни чрез някаква форма на терминал и можете наистина наистина да създадете толкова много поразия в края на 3270 терминал на мейнфрейм и неизменно други видове терминали, тези други системи се появиха заедно. И в повечето случаи терминалите в стария стил бяха много подобни на сегашните уеб среди и това е, че трябва да попълните формуляр на екрана на самия терминал и да натиснете Enter и off it go, щеше да изстрелвайте като един пакет, като заявка и бек-енд системата ще се справи с него. Това е по същество това, което се случва в уеб браузър в наши дни, когато въвеждате връзка в уеб браузър и тази форма обикновено не се връща в реално време обратно към системата, въпреки че с AJAX в наши дни това не е изцяло случай.

Но тогава се случи нещо, пристигна бъдещето, а наскоро и интернет, и почти вчера, в sec web 2.0 и точно зад ъгъла имаме интернет на нещата. И в процеса на бъдещето, светът на базата данни просто е избухнал и взаимодействията с бази данни просто се превърнаха в нещо, което всички по подразбиране направихме. Не беше случай да отидете някъде да направите нещо, например да купите билет за самолет и иска да пътува до другата страна на планетата, някой трябваше да напише в терминала всичките ви данни и да влезе в база данни и да разпечата билет.

Почти всичко, което правим сега, независимо дали това е хвърляне на такси в Google с приложение, дали скачане в интернет банкиране, всичко, което правим ежедневно, с някаква система, захранва се от база данни. И когато интернет се появи, това беше малко по-лесно да ни донесе, нашето ежедневие чрез уеб браузър, а след това уеб 2.0 се появи и нещата станаха мобилни, а мащабът на нещата просто се взриви. Всъщност любимият ми ред в тази тема е, че „Интернет свърза всичко, web 2.0 го направи мобилен и социален и нещата станаха много, много големи и сега имаме интернет и неща, и IoT… Yikes !!“ Ние дори не сме започнали да си представяме влиянието на Интернет на нещата, когато става дума за света върху системите от бази данни.

Така че в съвременен план това, което използвахме за мислене като терминал, ефективно се превърна в тези неща, това са мобилни телефони, това са различни видове таблети, или персонални потребителски или корпоративни таблети с голям екран, това са лаптопи и това е традиционният десктоп под някаква форма. В това едно изображение можете да видите почти всяка форма на интерфейс, който сега използваме, за да говорим със системи за бази данни и приложения, които се задвижват от тях, от малките джаджи в ръцете ни, които се разхождат и ние сякаш сме залепени, всички пътят към малко по-големите версии, iPad и други таблети и Microsoft Surface, до ежедневните лаптопи, които неизменно са сега в професионална среда и т.н. Хората са склонни да се сдобият с лаптоп, а не с фиксиран работен плот, но според мен те са модерният терминал и част от причината, поради която в базите данни се срещат всякакви предизвикателства в управлението на работата на нашия живот, а не само на развитието.

Така че допускам, че това е едно от най-големите предизвикателства, пред които бизнесът все още се изправя ежедневно. Всички мислеха, че базите данни са наши единствени проблеми, не са. И така, за какво е цялата суматоха? Е, когато преминаваме от единия край до другия с всички неща, свързани с базите данни, от търговски смисъл, а Марк покри техническите компоненти много, много добре, но в търговския смисъл като организация мислим за базите данни. Ние се занимаваме с нещата докрай от основния дизайн и разработка. Когато бизнесът стартира, те ще помислят за разработване на приложения, за развиване на способности или дори за внедряване на съществуващо приложение под някаква форма. Трябва да се осъществи някаква форма на проектиране и разработка и трябва да се включи много мисъл за това как тези системи от бази данни ще бъдат внедрени, поддържани и управлявани, както и проследяваните изпълнения и така нататък.

Интегрирането на средата и приложенията на базата данни и видовете API, видовете достъп, които се предоставят сега, стават все по-предизвикателни, по-сложни. Ежедневното администриране, поддръжка и архивиране, отново, това са неща, които смятахме, че са решени, но изведнъж мащабът стана много по-голям и нещата се движеха по-бързо, а обемът е толкова по-голям; големината на средите, системите от бази данни трябваше да поддържат скоростта, с която се движат транзакциите.

Помислете за база данни в много, много честотна среда за търговия, просто няма как хората да могат да следят това, това е просто струпване на машини, които се борят с друг куп машини за извършване на високочестотна търговия, покупка и продажба и обем на какви са тези транзакции. Помислете за модерен сценарий, като ранно излизане на филм на Netflix, в който не говорите само за стотици или хиляди или дори стотици хиляди, потенциално милиони хора, които искат да видят този филм от първата секунда, в която е пуснат. Цялата тази информация се улавя и проследява, регистрира и анализира в база данни.

И тогава има винаги светещият свят, в който живеем сега, 24/7, а не просто следваме Слънцето, но винаги има някой в ​​полунощ, който иска да направи нещо, а работното време следва Слънцето по целия свят. Така че продължителността на работа и наличността по подразбиране са климат сега, а прекъсването в действителност просто не е приемливо нещо. И излишък, ако има проблем с производителността или ако се нуждаем от прозорец за поддръжка, за да извършим надстройка или кръпка или сигурност, наистина трябва да можем да прекъснем от една среда на база данни в друга и да я правим безпроблемно и автоматично.

Сигурност и стандарти и спазване, имахме доста големи неща в света на късно, по-специално GFC и затова имаме цял набор от нови предизвикателства, за да се справим около спазването, сигурността и съвпадението на стандартите, и ние се нуждаем за да можете да докладвате за тези в реално време и в идеалния случай под формата на табло. Не искаме да изпращаме екип от маймуни до център за данни, които се опитват да намерят неща, ние се нуждаем от системата да ни съобщи това веднага, в реално време.

И двете големи забавления, за които почти никой никога не говори, обикновено ги бутаме под килима и се надяваме, че те никога не вдигнат грозната си глава, но възстановяване след бедствия и непрекъснатост на бизнеса - това са неща, които би трябвало, за в по-голямата си част се случват автоматично, ако възникне нужда.

Бихме могли да прекараме дни в разговори за видовете неща, които могат да се объркат в средите на базата данни и че хората като цяло са реагирали, но сега имаме нужда от системи и инструменти, за да направим това за нас. Един пример е нарушение на данните и така, когато мислим за базите данни, и аз задавам този въпрос съвсем открито под различни форми: какво се случва с базите данни, когато сваляме очи от топката и нещо критично се обърка? Особено, ако няма система, която да наблюдава ефективността и сигурността и други основни аспекти на работа с бази данни.

Е, какво може да се случи е това, това е екранна снимка на някои от последните нарушения през последните две до три години. Неизменно всички те идват от система от бази данни и неизменно има някакъв проблем в сигурността или контрола или достъпа, който се получава, а в горния ляв ъгъл разглеждаме 152 милиона акаунти в Adobe, където всеки детайл от тези клиенти беше нарушено. И ако случаят с подходящите инструменти можеше да е налице за проследяване и заснемане на инцидента и за контрол на сигурността, може би сме избегнали някои от тях, първите няколкостотин записани кражби може да са ни сигнализирали и щяхме да имаме спря следващите сто и петдесет милиона.

Тогава стигаме до ключовата точка на цялото това пътуване, която ни преведе, тоест: защо се нуждаем от по-добри системи? Защо не можем просто да хвърлим повече тела в това нещо, че сме преценили добре и истински пречупената точка според мен и със сигурност вярвам, че има случай, който е доказателство за късно, който хвърля повече DBA, администратори и повече хора в това нещо не решава проблема. Нуждаем се от по-добър набор от инструменти и по-добър набор от системи.

Ето моите пет основни причини, според които подкрепям това, и те се класират по важност въз основа на това, което виждам в тези частни предприятия и държави, които са управлявани среди, предизвикателствата, пред които са изправени средата на базата данни, и да ги управлява.

Сигурност и спазване - номер едно. Знаете, контролиране на това кой има достъп, откъде имат достъп, кога имат достъп, колко често имат достъп, откъде са получили достъп до него. Потенциално устройствата, които всъщност са докоснали, и видовете неща, които са разгледали, и съответствието, което върви около това. След като хората да пускат доклади 30 дни по-късно, за да ни кажат дали нещата са наред, просто не е подходящо, това трябва да се случи в реално време.

Изпълнение и мониторинг - изглежда, че не е мозък, но неизменно не е така. Независимо дали използваме инструменти с отворен код или някои търговски инструменти на трети страни, неизменно не сме пропуснали лодката по много начини с необходимите видове мониторинг на ефективността и подробностите, които и способността да реагираме навреме,

Откриване и реакция на инциденти - това трябва да бъде незабавно нещо в реално време и неизменно се нуждаем от система, която да го направи вместо нас или поне да ни предупреди бързо, за да можем да се справим с него, така че да се решат малкото възникващи проблеми. с бързо и не каскадирайте извън контрол.

Управление и администрация - отново смятаме, че тези проблеми са решени, те не са. Целта на проблемите, с които се сблъскват екипите от бази данни, по-специално DBA, при които системата трябва да се грижи за нещата за нас, все още не сме решили този проблем, все още е истинско нещо.

И точно от предния край с дизайна и разработката, когато започнем да изграждаме тези инструменти, изграждаме среди на базата данни, да можем да хвърлим подходящите инструменти при разработване и тестване и интеграция на платформи. Това все още не е лесно за нас и цялото това пътуване ни подтиква към едно и също послание, че според мен имаме нужда от по-добри системи и по-добри инструменти, които да ни помогнат да постигнем резултатите, от които се нуждаем от нашата база данни, така че фирмите, които водят стойност от нашите клиенти. Не можем просто да продължаваме да хвърляме повече тела и повече DBA, мащабът е твърде голям, скоростта е твърде бърза и силата на звука е твърде висока. С това, Ерик, може да се върна при теб.

Ерик Кавана: Обичам го, ние имаме много настилка, хора, много перспективни водещи, и ние продължаваме и предаваме те ключовете на Булет само за една секунда.

Bullett Manale: Добре.

Ерик Кавана: О, нека да го отнемем и Бълет, сега ти го предавам, а етажът е твой.

Bullett Manale: Добре, благодаря. Мисля, че са направени много добри точки. Исках просто да поговоря за секунда само за Идея, кои сме, и тогава ще скочим. Ще говоря за инструмента, който мисля, че много от тези неща, за които говорим, можем вид набор и вид обсъждане на някои от областите, в които те се подравняват, с този инструмент, продукта Diagnostic Manager.

Това, което искам да направя първо, е просто да ви дам малко предистория за това коя е Идеята; ние сме от около 2003 г. и затова започнахме само с инструменти на SQL Server и това е, върху което днес ще се съсредоточим, е продуктът на Diagnostic Manager. Но можете да видите всички кофи от неща, които имаме тук, а ние наскоро, както беше споменато преди, придобихме Precision и чрез придобиване, ние също имаме Embarcadero и така имаме доста добро портфолио от продукти.

По отношение на мониторинга на производителността, по отношение на SQL Server, продуктът, за който искам да говоря, и който подравнява тези теми, които обсъждаме, е Diagnostic Manager. Това е продукт, който съществува от доста близо до началото на дните на Idera и имах късмета да бъда част от това от около 2005 г. И видях много промени по отношение на SQL Server, преминаването от физическо към виртуално, всички подобни неща, които се случват, както и нуждите на DBA-тата с нарастването на околната среда и тези видове неща.

Това, с което започнах, беше типичният потребител на нашия продукт е DBA и така, когато за първи път говорим с хора, бъдещи клиенти, това са най-вече DBA. Ние не говорим с ИТ мениджърите или с директорите, може в един момент да стигне до това ниво, но първоначалното начало е, че DBA има проблем, DBA се опитва да отстрани проблема и много пъти ние Ще отида и да изтеглите и изпробвам продукта като част от това. Или ще получите мениджъра на данни, или DBA, или действащия DBA, човекът, който е достатъчно късмет, за да бъде най-техничният в стаята, в някои случаи. Сега, когато стигнете до по-големите корпоративни среди, очевидно, тогава ще получите пълноценните DBA, обикновено те ще бъдат тези, които използват инструмента. И продължих напред и просто добавих малко размазване тук от Wikipedia. Това нещо надхвърля отговорностите на DBA, както казва Wikipedia, това правят те.

Ако преминете през списъка тук, много от тези неща, няма да го чета, но получавате много от типичните неща, за които бихте се сетили, и след това върху едно от тях имате наблюдение и оптимизиране на работата на базата данни, а това е доста голямо. И което е интересното е, че когато разговаряте с DBA, те винаги са тези, които са обвинени първо, когато става въпрос за проблеми и всъщност не може да са по тяхна вина, но когато има проблем с производителността, обикновено с приложение, което е обвързан с база данни на DBA, те са тези, които са виновни, така че винаги търсят причините, поради които не е тяхна вина. В много случаи именно това може да използва този инструмент, Diagnostic Manager, за да им помогне.

Но в края на деня, също така, ако базата данни не работи, много от тези други неща всъщност не са от значение, приложенията ви не работят, тогава за много от тях няма значение неща. На първо място, ние искаме да можем да гарантираме, че потребителят изживява начина, по който го познаваме, да не е намален, това е нещо, към което DBA винаги се стремят. И мисля, че ако погледнете причините, поради които хората обикновено купуват и използват продукта SQL Diagnostic Manager, една от първите причини, вероятно не най-важната, не последна или най-малка, но е еднакво равна в целия план, и в зависимост от това с кого говорите, тези причини, почти една или две от тях са винаги, има някаква нужда.

Но първият просто е в състояние да има този централизиран изглед на инстанциите като SQL, който те управляват. И смешното е, че в много случаи, ако попитате DBA: „Колко инстанции управлявате?“ Броят се променя толкова често, че в някои случаи те не са сигурни. Така че се нуждаете от нещо повече от просто да можете да хвърлите всичко на екрана. Искате да хванете тази информация, искате да я осмислите и затова това е едно от нещата, с които Diagnostic Manager определено може да ви помогне, е да може да ви предостави такъв вид поглед в околната среда.

И това не е просто оглед на околната среда, но това е мнението, с което DBA, администраторът на базата данни, е удобен и е конзола, която е центрирана за DBA, ако искате. Той е направен за администратор на база данни. Има много инструменти за мониторинг, има много инструменти за ефективност, но както казах, в края на деня DBA иска инструмент, предназначен за DBA, защото има много неща, специфични за това, което правят в техния ден за ден.

И с казаното, имате SCOM, имате HPF, имате всички тези други технологии, но те искат нещо, което е специфично за това, което правят. Мисля, че можем да помогнем в тази област с този продукт, ще видите, когато влезем в него след секунда. Другото, което виждаме с DBA, което определено е едно от нещата, които засегнахме и по-рано, е, че те трябва да могат да виждат какво става, очевидно и трябва да могат да преглеждат цялото предприятие и имайте спокойствие, когато знаете какво се случва. Но в същото време те не седят там и гледат конзоли.

Спомняте ли си всички онези точки от куршума, които видяхте в този списък, които току-що изтеглих? Те трябва да правят и тези други неща, така че не става въпрос само за изчакване на пожари. В много случаи ще има срещи или много от прозорците за поддръжка, свързани с администратора на базата данни, се изпълняват посред нощ, когато те спят, така че трябва да имат възможност да се върнат и да видят какво се е случило, В много случаи, ако не хванете нещо, когато се случва, след като проблемът изчезне, или поне със SQL Server, това се превръща в някакъв проблем, когато се справяте със ситуацията, в която нямате има останки от този проблем вече. И тези проблеми отшумяват, както и остатъците, което означава, че трябва да се справите по-малко с тях, имате по-малко информация за работа.

С казаното, това определено е едно от нещата, с които Diagnostic Manager може да ви помогне, е да ви даде този поглед в миналото, за да попитате информацията от миналото: „Имах ли предупреждение за блокиране, имах ли проблеми със затвора, имахме ли неща, които се случваха по отношение на нашите ресурси? “Мога да се върна и да попитам тази информация. Мога да проуча конкретни моменти във времето. Бих могъл да направя всички тези неща директно от инструмента.

Всички тези неща, независимо дали е вътрешно или външно приложение, DBA искат да знаят, защото искат да могат да видят какво причинява проблема. Всъщност няма значение дали някой е бил вътре в организацията или някой извън организацията, който е написал кода; те все още искат да могат да го изолират, така че да знаят, че проблемът се случва, и те знаят откъде идва.

Така че ефективността и отчетността са ключова част от нашите продукти. Можем да предоставим всички тези подробности, и какво е хубаво, имате ли възможност да пробиете. Ако има затруднение, можете да го свържете с приложението, с потребителя, с базата данни, със заявката. И още веднъж, това е нещо като пушек за пушене. Получавате директна връзка между това, когато тази заявка работи, какво прави? И не става въпрос само за самото запитване, от гледна точка на самото изпълнение, но и дали заявката с времето се задълбочава? И на тези неща може да се отговори и с продукта, което определено е нещо, което, ако се опитвате да бъдете активни, е хубаво да можете да кажете: „Ей, ето едно запитване, което се получи лошо, но момче погледнете го докато тече по-нататък, можем да видим, че работи още по-лошо и по-лошо, мога да направя нещо по въпроса. "

Ако отидем в следващата зона тук; и това вероятно е - бих казал, че това е едно от големите. Един от въпросите, които задавам, когато показвам нашия продукт, винаги ще задавам на администратора на базата данни: „Как чувате за проблем, свързан с вашите бази данни SQL Server?“ И е много смешно, защото през повечето време - вече предоставено, през повечето време те гледат нашия продукт, защото в много случаи се опитват да решат определена нужда. Но е интересно да чуете първоначалния вид нещо - поне при SQL Server е, че това е било нещо - знаете, в първите дни на SQL Server сте имали SQL Server и тогава сте имали Oracle. И всички имаха Oracle и SQL Server беше нещо като, поради липсата на по-добър израз, червенокосата пасинка на базите данни при първото му стартиране.

И след като Microsoft добави още функции към него, тя стана малко повече от корпоративен инструмент. И очевидно е изминал дълъг път оттогава. Но въпросът е, че един път бихте могли да спорите, че през деня базите данни не са били считани за критични. И това се променя с времето. Поради това в много случаи хората се опитват да се прегърнат и да кажат: „Знаеш ли какво? Имам всички тези бази данни на SQL Server, опитвам се да се справя с него. "И вместо да чувам за проблеми от бюрото за помощ или да чувам за проблеми от конкретни хора, които - като самите потребители, те" търсят някои начини да заобиколят това. Те търсят начини да бъдат запознати с тези ситуации, преди те някога да се случат.

И така с Diagnostic Manager това е едно от нещата, които се опитваме да направим също, най-малкото е в състояние да направим, че DBA е първият, който знае за тези ситуации или тези проблеми, така че да могат нещо за това, било то, когато се случат, или да го направим дори крачка напред, за да анализираме тези системи, които той наблюдава. И за да може да ви даде проактивни съвети, които ще подобрят работата на този инстанция и да можете да го правите редовно. Например трябва да добавим индекс въз основа на натовареността; онези видове неща, инструментите, способни да се справят. Така че ще видим много от това в инструмента.

Другото и последното нещо, което е в този списък, е нещо като по-общо описание, но определено си заслужава да се отбележи. И по-специално, когато навлизате в по-големите типове ситуации на ниво предприятие, където имате много случаи, винаги ще има някакво неясно нещо, което аз искам да наблюдавам, ако съм администратор на база данни, за пример. И така това, което се опитваме да направим, е да предвидим от гледна точка на това, което типичният DBA ще иска да наблюдава.

С казаното, вие бихте могли и по отношение на - винаги ще има нещо ново. Така че ние ви предоставихме начин да добавите каквито и да са показатели, от които се нуждаете, за да наблюдавате и управлявате, след като точката на инсталиране може да бъде добавена. Така че всички броячи на PerfMon, WMI броячи, броячи на обекти на SQL Server; всички тези могат да бъдат включени в инструмента. Имате възможност да добавяте допълнителни заявки, които могат да бъдат включени във вашите интервали за анкетиране.

И последното нещо, което също си заслужава да се отбележи, е, че можем да добавим и всъщност да комуникираме както с vCenter, така и с Hyper-V, за да можем да изтеглим показателите от тези среди. Тъй като едно от нещата, които идентифицирахме с DBA, е, че те обикновено не са част от операциите. И не е задължително да имат, нали знаете, vCenter среда, която им е на разположение или такива видове неща, които са им достъпни.

И така проблемът е, че ако те се занимават с екземпляр на SQL Server и им са разпределени ресурси, но този екземпляр е виртуализиран, може да изглежда, че имат всички ресурси в света, когато те просто наблюдават какво на гост операционната система. Реалността е, че на хоста може да има 30 или 40, или 50 или 100 други виртуални машини, до които се опитват да имат достъп, и да имат същите ресурси. И единственият начин всъщност да видим това е да комуникираме с тези други среди и с тези интерфейси, в случая, което правим.

Имате възможност да добавите тези други видове броячи в инструмента. Сега не става въпрос само за това да можете да наблюдавате тези броячи, но и за да можете да направите тези нови броячи, които да въведете в продукта, да ги направите част от инструмента, сякаш те са изходящи показатели, Извънредно нещо, което бихте искали да наблюдавате; така че това означава да можете да ги включите в своите табла за управление. Това означава да можете да ги добавите към вашите собствени персонализирани отчети, да можете очевидно да задавате прагове и да сигнализирате за тях, но също така да ги базирате и да можете да задавате праговете с известни знания, къде да ги настроите въз основа на неща като вашия базови линии и какво е нормално. Така че, имате много от тези видове неща, които също са в продукт.

Това, което ви предоставих, е това, което наричам „основните резултати за диагностичния мениджър“, и мога да продължа напред и просто да ви дам малко вкус, като вляза в продукта. Това, което ще правя, е споделете екрана ми, добре, и просто ще преместите това. Така че това, което ще видите, това е конзолата за Diagnostic Manager. И както споменах по-рано, отидете на това първо ядро, което може да се прегледа неща от вид изглед на ниво предприятие. Има много различни примери за това в инструмента. Имаме вид изглед от миниатюри; имаме по-голям вид на мрежов изглед. Имаме и по отношение на гъвкавост, има и уеб-базирана конзола. Уеб-базираната конзола има и други изгледи, които са достъпни за вас, като ключови карти и подобни неща. Но въпросът е, че имате тази способност да гледате и виждате нещата на високо ниво. Но когато възникнат проблеми, ще копаете малко по-нататък в инструмента и всъщност ще видите конкретната проба леми и имат някакъв начин да разберат и да знаят какво става. И очевидно това е много важно.

Сега, от гледна точка на възможността да видите действително какво се е случило в миналото; ако гледам проблем, който се случи вчера или преди седмица, тогава в тази ситуация, знаете, ще имате нужда да можете да излезете в конкретен екземпляр от SQL. И добрата новина е, че ако знаете колко време се е случил този проблем в продукта, можете да отидете директно в браузъра за история. И мога да посоча конкретно време на деня; може да е от преди няколко седмици, може да е от вчера. Но какъвто и ден да избера в календара, след това ще бъда представен с различните интервали на гласуване. В този случай сега аз ефективно виждам какво щях да видя, ако бях гледал конзолата на 20 април в 13:37

Така че аз съм в състояние да се върна назад във времето и след това, след като го направя, всички различни раздели, които виждаме тук, ще отразяват този конкретен момент от време, включително заявките, които може би се изпълняват слабо, включително може би ако Имах сесии с блокиране. Всички тези неща ще се покажат в инструмента и ще ми позволи да очевидно използвам тази историческа информация, за да мога да разреша проблема. Сега в тази бележка, когато говорим за историята, другото, което си струва да отбележим тук, е, че не е просто използването на историята за отстраняване на проблеми. Очевидно е, че историята е много ценна по други причини. И едно от големите е да можеш да вземаш решения ефикасно и да можеш бързо да вземаш решения с подходящата информация. Така че цялата тази история, цялата информация, която събираме, можем да отчитаме.

Ако някой дойде при мен и каже: „Получих това наистина страхотно ново приложение. Това ще промени света, какъвто го познаваме. О, между другото, той изисква база данни, и о, по начина, по който наистина ще закачи I / O на машината, където е тази база данни. " Ако знам, че ще вляза в него, тогава мога да използвам тази информация, за да мога да осигуря класиране на всичките ми производствени сървъри въз основа може би на последните седем дни от събирането. И бих могъл много бързо да стигна до заключението кои случаи имат най-смисъл да използвам тази база данни. Значи това е онзи тип историческа информация, който също очевидно е много ценен.

По отношение на самите заявки; що се отнася до разглеждането на заявките, в инструмента имаме много различни начини. И това, което обичам да разглеждам, е View Quits Waits View, защото Query Waits View е много полезен по отношение на възможността да се оцени. Ако имам затруднено място, за да мога по същество да идентифицирам всички различни области, които засягат тази конкретна, конкретна заявка; не само самата заявка и какво е въздействието на тази заявка, но също така, знаете от кое приложение е дошло, от коя сесия е дошъл, кой потребител я е нарекъл и всички тези неща, виждам, че очевидно това е информация в реално време, но аз също имам способността да разглеждам тези данни от миналото. И така, това е едно от нещата тук и стартирах сценарий, но трябва да изчакам да изскочи някак.

Докато чакаме на това, искам - и знам, че ни липсва време, така че исках да поговорим малко и за предупреждението, че предупреждението е проактивно. И когато говорите за такива неща, както казах, като проактивната част, има много инструменти, които сигнализират. Трудната част не е изпращане на имейл. Трудната част не е запис в дневника на събитията или генериране на SNMP капан. Трудната част е да знаем кога да изпратите този сигнал в подходящите моменти. И така с това идва много необходимост да се правят някакви изчисления, като се разбира, "Какво става за този конкретен случай и какво е нормално, що се отнася до този случай?"

И така, за всички показатели, които имат смисъл да се правят с тях, ние ги изброяваме. Всъщност ви показваме основната линия, ще ви покажем прага, на който е зададен в момента. И тогава другото хубаво нещо в него е, че да кажем, аз зададох праговете си в случая шест и десет само за този пример. След шест седмици, ако се върна към този случай, тази базова линия може напълно да се промени, защото едно от нещата, които правим, когато изчисляваме базовата линия, по подразбиране е подвижно седемдневно изчисление. Затова винаги ми предоставя актуална версия на основната линия. И какво се случва, ако тази базова линия се премести в праговете ми? В този случай мога да видя и предупреждавам препоръки, които в основата си казват: „Хей, имате праг, който вероятно е зададен неправилно, специфичен за това, къде виждаме прага и очевидно къде е основната линия, вероятно ще да получавате сигнал за нещо, което е нормално събитие. "

И така, вместо да лекувам симптом на нещо, което е нормално, аз съм в състояние да идентифицирам този тип ситуация, при която действителният праг е зададен неправилно. И това, което ми позволява да направя очевидно, е да определям праговете в съответствие с това къде ще получа сигнал. Това е нещо, което знам, че е по-скоро призив за действие срещу разследване, за да се види дали наистина е проблем. И мисля, че част от инструмента е наистина полезна от гледна точка на самата базова линия и може да се изчисли.

Сега с този продукт имате възможността да разполагате с множество базови линии; можете да ги зададете за различни периоди от време и можете динамично да коригирате праговете въз основа на базовите си линии, което също е много важна част от вид адаптиране към промените, които се случват ежедневно на вашите случаи на SQL Server, Сега, в случая тук, ние покриваме доста от настройките на праговете и ви показваме базовите линии. Но що се отнася до действителните сигнали, самото уведомяване, готиното в Diagnostic Manager, е дали ви предоставя множество профили за предупреждение. Така че, ако имате например профил на повикване, който е от 2:00 до 5:00 ч., Тогава мога да имам профил, специфичен точно за този период от време, и мога да настроя всички условия и съответните настройки тук за моя отговор.

Сега, отговорът е, че в някои случаи, да, мога да изпратя имейл или мога да сваля и генерирам SNMP капан или да пиша в дневника на събитията. Има много други неща, които можем да направим, но докато говоря с DBA, това, което те наистина харесват, е фактът, че в повечето случаи голяма част от работата, която се изпълнява, е повтарящи се неща. Това е нещо, което те знаят точно кога се случва проблемът, какво да направят, за да го отстранят. Те просто трябва да отидат и да се намесят. И така, докато разраствате средата си, тъй като имате повече случаи, това става много по-трудно. Така че едно от нещата, които можете да направите в инструмента, което според мен си струва да се отбележи, е дали имате възможност да зададете условие, но въз основа на това условие да можете да зададете отговор за стартиране на скрипт, за да изпълните работа, за да стартирате изпълним файл. И, въпросът е, че ако решите да стартирате скрипт, мога да използвам параметри, вътре в този скрипт, който ще бъде по време на изпълнение, изпълнен с действителната информация.

Така че, ако има проблеми с конкретна база данни, скриптът ще бъде проектиран да работи точно срещу базата данни, където проблемът се случва. Така че можете динамично да адресирате проблемите по автоматизиран начин и тогава все още мога да получа имейл, за да се върна и да ми кажа, че „Ей имаше проблем, но между другото, той беше отстранен“. Сценарият беше стартиран и като DBA знаете за него, но всъщност не трябваше да влизате и да се намесвате. Сега, при същата бележка за това, че сме проактивни, очевидно имаме и друга характеристика тук, която е функцията „Анализиране“. И това, което ще направи, е, че ще прави редовна проверка срещу инстанцията на SQL. И в някои случаи ще направи по-дълбоко гмуркане по отношение на това, което търси. Ще бъдат извършени неща като хипотетичен анализ на индексите. Да добавя ли индекс? Да премахна ли индекс? И всички тези неща очевидно ще помогнат за представянето ми, но за пореден път всичко е свързано с проактивността. Става въпрос за възможността да взимате решения преди да се прекъснат нещата и да го направите по-добър. И така, в много случаи, това наистина се опитваме да направим тук.

Връщане към Query Waits, за което говорихме по-рано; както виждате, тук има голям шип. Пуснах сценарий по-рано, който просто предизвика известна активност за изчакване и както споменах преди, имаме наистина уникален начин, по който можете да разгледате тази информация. Ако искам да видя какво приложение беше; Виждам, че идва от приложението NoSQL. Ще можем да видим базата данни, към която е свързана, сесията, потребителя и тогава, ако искам, мога да класирам това и по отношение на моите чакания. И така, мога да кажа, от всички чакания, които се случваха в този период от време, кои от тях се случваха най-много? И ако видя, че когато това се случи най-много, наистина хубавото е, че мога да проуча този тип чакане и мога да видя всички команди. Ако погледнете тук, те накараха това да се случи. И също така виждам предимно кое приложение беше, което правеше това чакане.

Така той стърчи като възпален палец. Веднага мога да кажа: „Това е приложението, което причинява затрудненията ми. Сега каква беше заявката, която беше пусната? Кой потребител я изпълни? Коя база данни е стартирала?“ И така нататък. Така че, надявам се, това има смисъл и също така помага по отношение на това, че нямате закъснения във вашата среда, тъй като се отнася до вашите бази данни. Надявам се, че това е полезно. Ще продължа към този момент и ще го предам обратно, и предполагам можем да продължим оттам.

Ерик Кавана: Със сигурност. Така че, предполагам, че просто ще го хвърля на нашите експерти от деня. Марк, може би първо искате да коментирате и да зададете няколко въпроса. Тогава Дез, можете да звъните.

Марк Мадсън: Да, благодаря, много ми хареса да гледам някои от това. Това е много по-интелигентен мониторинг, отколкото съм свикнал да виждам. Любопитен съм с управлението на данните зад това; управление на показателите, които можете да проследявате, и знаете, потърсете неща като изместване на базовите линии, по-специално, че това е една от точките за болка на моя домашен любимец, с табла. Как се справяте с тези данни и втората част от тях е, знаете ли, изходни показатели, като вид изместване - имате ли възможност автоматично да измествате и праговете, така че да не се налага да да се върнете и да нулирате праговете на ръка, когато базовата линия се измести?

Bullett Manale: Направо и така хубавото нещо е, че можете да решите това. Можете да направите и двете. Мога да настроя праг и да го направя статична настройка или мога да отбележа в квадратчето, за да кажа: „Направете това динамичен праг, който ще се промени, когато се променят моите базови линии.“ време за моята базова линия. Но тогава, ако се наложи, може да имам отделен прозорец на основната линия, например от прозореца за поддръжка от 2:00 ч. да речем до 5:00 ч., защото ще облагам данъка си CPU, моите дискове и всичко останало, защото тогава правим цялата си поддръжка. Тогава автоматично, ако го бях избрал да направи това, автоматично ще коригира праговете ми, за да бъде извън мястото, където е нормално за тези показатели, Избрах да направя това с. Това би ми позволило да направя това. По принцип вие имате възможност в инструмента да задавате прозорци на времето, които са вашите основни прозорци, и всеки прозорец може да се третира като отделна единица по отношение на динамично коригиране на базовите настройки, което може да се направи. И можете да добавите толкова прозорци от основната си линия, колкото и на йо трябва, ако това има смисъл. Може да имате прозорец за уикенда, делничен ден през работно време, прозорец за поддръжка, който се случва посред нощ и така нататък и така нататък.

Марк Мадсън: Благодаря.

Bullett Manale: Предполагам, че се връщаме към първата част на въпроса, която имаме, и събираме цялата тази информация. Всъщност не говорих за архитектурата, но ние имаме резервно хранилище, че имате пълен контрол върху запазването на тези данни, но ние също имаме услуга, която работи посред нощ, която отива и прави всички наши базови изчисления и отнема тези данни, събира и има смисъл от тях. И очевидно, заедно с това, имате и многобройни доклади, които можем да използваме, за да докладваме срещу вашите базови линии, за конкретни показатели. И дори имате възможност да сравнявате изходните си линии на един и същ сървър, за един и същ показател за различни периоди от време. Можете да видите дали има разлики, които са възникнали или каква е делтата. Има и много от тези видове опции.

Ерик Кавана: Дез.

Dez Blanchfield: Един бърз въпрос, който имам към вас - има широк спектър от това, което този инструмент може да направи. Наблюдавате ли възприемане на използването му в ранния етап на развитие или все още основно инструмент за производствена среда? С други думи, получават ли разработчиците достъп и го използват чрез ранното си развитие и след това тестват фаза на интеграция? Или все още се използва предимно в производствена среда?

Bullett Manale: Бих казал, че в по-голямата част от случаите го виждаме в производствена среда. Зависи от ситуациите, но в по-голямата си част бих казал предимно производство и ние - а също така, знаете, честно е да споменем, че имаме различни цени за средата за разработка и тестове, така че е малко по-привлекателно. Виждаме хора, които го използват за тези среди, но бих казал, ако трябва да ви дам отговор по един или друг начин, бих казал, че това са предимно производствени среди, където виждаме хората да инвестират в този продукт,

Дез Бланчфийлд: Разбира се, да и беше интересно да чуя, че имате различни точки за ценообразуване, защото очевидно има различни натоварвания и по-тежките работни места ще бъдат там, където се извършва цялата реална работа. Но виждам много организации, особено в правителството и със сигурност в областта на отбраната, където развитието сега получава същото ниво на инвестиции в инструменти и системи като производствената среда, защото те правят много повече предварителни тестове. В защита например има екипи, които провеждат милиарди тестове, стотици милиарди тестове на приложения и системи и инструменти и ги наблюдават, преди те дори да преминат към тестване за интеграция, защото искат да се уверят, че има изграден код и базата данни седи под него. Стига се до сто и един милион итерация или нещо подобно, докато сте навън в полето, стреляйки по някого, това не се случва.

Bullett Manale: Разбира се.

Дез Бланчфийлд: В моя свят на база данни от старите училища, мисленето, че средата на базата данни е нещо, което току-що е оставено в данните и някои от вас знаят, много рядко се вижда и много рядко се говори за това, така че, когато разберем сега къде инструментите и приложения се разработват, особено с аналитични платформи, те вече са в нашите телефони и нашите устройства. Виждате ли, че клиентите водят разговора за ефективността на базата данни и управлението на базата данни в по-ежедневна дискусия, а не само чисто технически? И знам, че споменахте преди, че предимно говорите с DBAs, но има ли тенденция сега, когато това е в общия речник, виждате ли хора, където обсъждат тези теми, за разлика от само отрепки?

Bullett Manale: Ами е трудно да се каже. Искам да кажа, както казах в по-голямата си част, хората, с които така или иначе се занимаваме по отношение на процеса на продажба, са с практикуващите, които са DBAs. Така че по отношение на въпроса ви просто казвате: „По принцип хората в ИТ организацията стават ли по-запознати с базата данни?“ Предполагам, че е въпросът и бих казал, че отговорът е „да“. Вероятно не го виждам толкова много на базата на мястото, където съм, ежедневно, но мисля, че ако разбирам въпроса ви, предполагам, че това би бил моят отговор.

Дез Бланчфийлд: Да, това е добре. Вероятно е натоварен въпрос, извинете, защото очевидно вашите преобладаващи интереси във вашия свят са техническата страна на нещата. Интересно ми е, че в ежедневните си дейности виждам организации да започнат да внасят това в разговора много рано. Така че, когато говорят за нови инициативи, нови проекти, нови програми за работа, едно от нещата, които идват веднага, е: „Как го наблюдаваме, как го проследяваме, как се справяме с възникналите проблеми, за разлика от изстрелването, излизането на живо? "

Bullett Manale: Бих казал това -

Дез Бланчфийлд: Съжалявам, продължавайте.

Bullett Manale: Щях да кажа, че виждам тенденция, предполагам, че би трябвало да го кажа - знаете, много пъти в миналото бихте получили: „Имахме проблем и затова сега ни трябва инструмент. " И мисля, че виждаме малко повече от приемането около използването на инструмента, преди проблемът да се случи, ако това има смисъл. Така че бих казал, че определено става по-нормално да бъдем, знаете: „Ей, имаме нужда от инструмент за наблюдение, имаме нужда от нещо.“ И хората определено виждат стойността на този продукт, защото както казахте по-рано, просто добавяте DBA и добавяйки нови инстанции, имате нужда от нещо, което да управлява това. Имате нужда от нещо, което помага при управлението на това, и затова виждаме много одобрение и около този продукт.

Dez Blanchfield: Бърз въпрос. Къде трябва да живее това? Трябва ли да седи точно на задната изгора в локалната мрежа, в центъра за данни, възможно най-близо до средите на базата данни или е удобно да се постави някъде, потенциално навън в облака, трети облак с някакъв вид или VPN тунел, или отдалечен достъп до различни среди? Къде трябва да седи това, що се отнася до околната среда и мониторинга?

Bullett Manale: По отношение на архитектурата има резервно хранилище и това е база данни на SQL Server. Имаме конзолата, която може да бъде или дебел клиент, или тънък клиент; ние ви даваме възможност и на двете. Имаме и тънък клиент, който също е насочен специално към мобилните устройства. Но по отношение на това къде всъщност може да седи; може да се намира в среда, наистина по-сложната част от нея е, че от много информация, която трябва да съберем, се изискват административни права, в някои случаи или в много случаи. Сега не ви караме да правите това; ако искате, можете да събирате данни и само за нещата, които не можем да съберем, тъй като нямаме администраторски права, просто ще ви позволим да не виждате тази информация, ако това е вашият избор.

В зависимост от аромата, например, ако говорите за AWS, някои среди, той работи по-добре от други, но що се отнася до самата реална среда, обикновено или използвайте автентификацията на SA за събиране на данните срещу инстанциите е всичко, което е необходимо. Или ако това е ненадежден домейн, това обикновено е, когато искате да направите това, но множество домейни; стига да има доверие между тях, можем да събираме срещу тях. Всъщност няма значение дали е в LAN или е по WAN, самата реална колекция е доста пренебрежима по отношение на количеството данни, което събираме. Ако имаме достатъчно WAN връзка с размер, това не е проблем. Виждал съм среди, където имат клонове, където имат SQL сървъри в цяла Съединени щати. И това е един сървър на всяко от тези различни места и го наблюдават централно. Трудната част е просто да се уверите, че имате прилично количество свързаност, за да направите това. Да се ​​надяваме, че това отговаря на въпроса ви, беше вид на цялата карта.

Дез Бланчфийлд: Да, абсолютно. Благодаря ти. И така, два бързи въпроса, които дойдоха през присъстващите тази сутрин; едно е: какво е въздействието - често виждаме, че инструментите за мониторинг на системата генерират натоварване само чрез наблюдение на нещата, така че въпросът беше, съжалявам, че се превъртя сега от екрана ми, но просто да го перифразирам; чрез наблюдение генерираме ли себе си товар? Има ли измеримо въздействие на инструмента, просто наблюдавате околната среда или това е незначително въздействие?

Bullett Manale: Винаги ще има някакво въздействие, тъй като трябва да поиска заявка на SQL Server, за да изтегли данните. Въпросът, какъвто казахте, е: „Пренебрежимо малко ли е или е значителен?“ Извън полето, което сочите към екземпляр, това е нищожно. Правим това от доста време, както казах. Имаме над 20 000 клиенти и мога да ви уверя, че ако това окаже значително въздействие върху производителността, ние няма да работим. С казаното ние също така позволяваме на потребителя да реши какво иска да наблюдава. Така че мисля, че е важно да споменем, че всяка среда е малко по-различна.

Пример е, че компонентът за наблюдение на заявките е едно от нещата, които имаме способността да направим, е дали можем да зададем прага на това, което смятате за ваша граница на нормалност. Така че може да се основава на времето на изпълнение на заявката. Може да се основава на процесора, I / O, но като пример, нека да кажем, че съм определил времето си за изпълнение на нула милисекунди. Ефективно това, което казвам на инструмента, е да събера всички заявки, които се изпълниха от последния интервал на изтегляне, и да направя и тази част от историческата ми колекция.

Сега, когато правим това, ще събираме каквото и да е количество заявки, които бяхме изпълнили на полето след последното анкетиране. Сега това е избирателно и потребителят има възможност да го направи. Ние казваме: „Това трябва да направите?“ Не. Но ние също така ви даваме възможността да го направите, в случай че искате извадка от данни, която ви позволява да събирате тази информация. Така че най-общо казано, имате средства в рамките на инструмент, за да го настроите и настроите точно така, както искате, въз основа на това, което ви е удобно. Но имате възможност наистина да го отворите, ако искате, и да съберете много допълнителна информация, която може да не е задължително редовно събирайте, ако това има смисъл.

Дез Бланчфийлд: Да, абсолютно. Знам, че работим малко дълго, но има два наистина страхотни въпроса, които искам да ви хвърля, преди да се завъртя. И двамата идват директно при мен, но мисля, че е най-добре, ако им отговорите. Въпросът като цяло беше: „Какъв е обхватът на инструмента, що се отнася до познанието на съществуващите системи?“ Така че можем просто да включим това и да го накараме автоматично да открие наличната платформа и веднага да разберем какво е нормално за тази платформа. Вземете така, както Марк говореше по-рано? Някои от базовите знания за платформите, като въведете, знаете, не знам, това може да е Microsoft Dynamics. Какъв е обхватът на познанията на платформата с това, което е нормално и в някои от текущите инструменти, които се използват без рафтове, които се използват в бизнеса?

Bullett Manale: Бих казал, че най-общо казано, когато започнем да събираме данни за SQL инстанцията, ние работим с най-добрите практики за начало, по отношение на нашите прагове и къде са зададени. Това каза, ние също така признаваме, че с когото и да говорите, по отношение на най-добрите практики, всяка среда е различна. Това, което ще направим първоначално, просто събираме данните и това, което препоръчваме на хората, можете да опитате продукта с 14 дни по-дълго, ако се наложи. Но след около два дни ще започнете да виждате данните за изходните данни да се попълват. След като разполага с достатъчно примерна информация, с която да работи, тогава ще започне да ви предоставя контекста по отношение на основната линия, където е диапазонът и всички подобни неща. След това от там, ако искате, можете автоматично да зададете праговете си от тази събрана информация. Необходимо е малко първоначално събиране и проучване, за да можете да започнете да определяте какво е нормално, така че да можете да започнете да измествате праговете си.

Но нещото, което според мен си заслужава да се отбележи, е също така, че когато промените тези прагове, това може да се извърши от група по група на вашите инстанции. Тя може да бъде специфична за един екземпляр или можете да го направите срещу всички ваши инстанции, както и възможността да създавате неща като шаблони, така че да можете да кажете: „Това е производствен екземпляр, но това е шаблонът, който искам да го присвоите. " И така, когато се появи нов екземпляр за производство онлайн, ние автоматично прилагаме тези прагове към него, тъй като той има един и същ тип хардуер и обикновено има същите натоварвания, така че бихме могли да го направим и по този начин. Дано това помогне по отношение на въпроса.

Дез Бланчфийлд: Да, абсолютно. Всъщност, вие всъщност отговорихте на друг въпрос, който току-що ми влезе и беше: „Има ли пробно изтегляне?“. Имам, мога да отговоря на това, знам. Сигурен съм, че ще потвърдите, че има безплатно изтегляне и мисля, че казахте, че е минало 14 дни от уебсайта. Можете да го изтеглите и да играете с него. Предполагам, че бързо с това, "Каква среда ми е необходима, за да мога да стартирам пробния процес? Мога ли да го пусна на моя лаптоп и да играя с него или наистина имам нужда от сървър?"

Bullett Manale: Основното, от което се нуждае, е хранилище, база данни на SQL Server, която е 2005 или по-висока. Освен това има някои минимални изисквания за ресурси, изискване .NET и това е всичко. Така че, просто е въпрос на инсталиране на продукта и създаване на база данни.

Дез Бланчфийлд: Перфектно. Последен въпрос, който ще ви хвърля, тъй като сега вече просто нямаме време, но бързо около двама или трима души ме попитаха: „Трябва ли да бъда DBA, за да мога да стана и да тичам с това и да играете с него? "

Bullett Manale: Не. Бих казал, че ако сте DBA, ще имате различни приложения на инструмента. Искам да кажа, че вероятно ще имате малко по-голяма стойност, ако сте подправен DBA. Ще видите много повече дълбочина на инструмента, от който бихте могли да се възползвате. Но също като нов DBA или дори човек, който, това не е DBA, имаме много препоръки и в момента съм на тази страница. Тези препоръки ще се появяват редовно и наистина приятното нещо за препоръките е дали те ви предоставят причините, поради които препоръките се правят. Но в допълнение към това, те ще имат и връзки към външно съдържание, които описват по-подробно причините, поради които тези препоръки също се правят. Така че това ще свързва към външни уебсайтове на Microsoft, блогове и всякакви подобни неща, това е външно.

Но за да отговоря на въпроса ви, някак си е, знаете, ако сте старши DBA, тук ще има неща, вероятно ще се възползвате от това, което вероятно не бихте като начинаещ DBA. Но в същото време това е и своеобразен инструмент за учене, тъй като докато преминете през тези препоръки, ще започнете да избирате някои от тези неща самостоятелно чрез използването на препоръките.

Дез Бланчфийлд: Фантастичен. Благодаря ти. Много ми хареса демонстрационната част. Презентацията беше страхотна. Демото беше фантастично. Бързо от паметта има цял ресурсен център на вашия уебсайт, който препоръчвам и на хората да разгледат. Спомням си, че мина през онази снощи, за да получа някои подробности. Имате цял набор от неща, само от вашите блогове, данни и разговори до, от паметта, и вие имате по-голямата част от вашата продуктова документация онлайн, нали?

Bullett Manale: Да, това е правилно и формата, която мисля, че препращате, е уебсайтът community.idera.com. И тогава едно нещо, което бих споменал също, по-рано вие ме попитахте: „Ще разпознаете ли околната среда?“ По отношение на нови инстанции или добавяне на инстанции, има и друг инструмент, който ни открива случаи. И всичко е свързано с инвентаризацията и управлението на инвентара ви. Просто бих ви насочил в тази посока по отношение на действителното откриване на инстанциите. Но що се отнася до действителността и мониторинга, всички тези неща, за които говорихме, точно тук ще влезе в действие Диагностичният мениджър.

Дез Бланчфийлд: Фантастичен. Вижте, страхотно покритие. Наистина се наслади на вашата презентация. Обичах демонстрацията на живо и това е всичко от мен тази сутрин, тъй като знам, че сме минали вероятно 10 минути с времето. Ерик, ще се върна към теб.

Ерик Кавана: Добре. Просто обичах демото. Радвам се, че направихте демонстрацията. Радвам се, че трябва да разгледаме доста трудно това, докато преминахме на въпросите.

Bullett Manale: Страхотно.

Ерик Кавана: Тъй като това дава на хората представа за това, което гледате, и наистина наистина ме учудва, като си помисля, че все още се учим как да говорим с тези компютри, когато стигнете веднага. Искам да кажа, че това ниво на диагностика е доста сложно и с всеки изминал ден става все по-добро. Получаваме много повече информация за това, което всъщност се случва. Но наистина се нуждаете от човек, който да пренебрегва тези неща, да го чете, да поставя тази познавателна способност зад това, което правите, нали?

Bullett Manale: Да, искам да кажа в много случаи - бих искал да ви кажа, че това е DBA в полето, но просто има твърде много неща, които се случват. Искам да кажа, ние предоставяме насоки и помагаме, но в края на деня това изисква хората да вземат решения относно данните, които представяме. Не мисля, че това скоро ще се промени.

Ерик Кавана: Това е добра новина за истинските хора, хора.

Bullett Manale: Точно така.

Ерик Кавана: Ще искаш да има някой, който наблюдава това, екип, който наблюдава това, и ще научиш, както сте чували от Bullett тук, като гледате тези препоръки, за да вземете какво става. И аз предполагам от тази история и мисля, че сте се докоснали до това, Булет, но много бързо, че историята ви позволява да разпознавате значими модели и следователно да можете да ги идентифицирате, когато те се случват в бъдеще, нали?

Bullett Manale: Това е правилно. Едно от нещата, които можем да направим, е да проследим изпълнението на заявката във времето. Очевидно можем също така да разгледаме други неща, като базови линии и да видим как се изместват и очевидно получаваме сигнали и такива неща, когато това се случи, така че определено имате тази способност.

Ерик Кавана: Това звучи добре, хора. Не бихме били дълго тук, но исках да стигна до тези въпроси. Благодаря ви много за отделеното време и внимание. Ние архивираме всички тези уеб излъчвания. Хоп онлайн към Techopedia.com или към InsideAnalysis.com, ще видите връзки и от двете места.

И с това ви сбогуваме. Благодаря отново, хора, ще ви догоним следващата седмица, още три уеб предавания следващата седмица, вторник, сряда, четвъртък. Така че ще поговорим с вас следващата седмица, хора. Пази се. Чао чао.

Партньор за съдържание на Techopedia

Персоналът на Techopedia е свързан с Bloor Group и може да се свърже с тях, като използвате опциите вдясно. За информация как работим с партньорите в бранша, кликнете тук.

• Профил
• уебсайт