Зміст:
Співробітники компанії «Техопедія», 9 травня 2016 року
Винос: Ведучий Ерік Кавана інтерв'ює Марка Мадсена, Дез Бланшфілд та Буллетт Манале про затримку та продуктивність.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Партнер з вмісту Techopedia
Персонал Techopedia пов'язаний з Bloor Group і з ним можна зв’язатися, скориставшись опціями праворуч. Для отримання інформації про те, як ми працюємо з галузевими партнерами, натисніть тут.- Профіль
- Веб-сайт
Ерік Кавана: Дами та панове, привіт, вітайте ще раз до Hot Technologies! Так, справді! Мене звуть Ерік Кавана, це наше шоу Hot Tech, партнерство з нашими добрими друзями з Техопедії. Хоп онлайн на Techopedia.com для найновіших у широкій галузі корпоративних технологій; вони, звичайно, охоплюють і споживчі речі. Ми зосереджені на підприємстві тут, в нашій програмі, тож саме цим ми сьогодні будемо займатися.
Є місце про ваше справді і достатньо про мене, зачепи мене на Twitter @eric_kavanagh, я люблю Twitter, я люблю перевіряти ці речі, це прекрасний спосіб підтримувати зв’язок з людьми і вести хороші розмови, і один на один -одні розмови.
То про що ми говоримо? Цей рік гарячий, це цілий всесвіт можливостей, який ми сьогодні дивимося у світі управління інформацією, і те, про що ми сьогодні говоримо, - це запити, це буде прискорення запитів.
Думаю, я забув згадати заголовок: "Гра в виставі: Попрощайтеся із затримкою". Ну хто хоче затримки? Ніхто не хоче затримки, затримка - це коли ти сидиш там, натискаєш кнопку і чекаєш, що щось станеться, і ніхто цього не хоче. Дітям це не подобається, вони не вважають, що це круто, дорослим теж не подобається. Всі ми були зіпсовані швидкістю Інтернету, і ми хочемо все швидко, ми хочемо все зараз, і ми будемо говорити про це сьогодні на нашому шоу.
Аналітик Марк Мадсен сьогодні з нами з "Третьої природи", одного з наших постійних людей. Наш новий науковець, Дез Бланчфілд, зателефонував із Сіднея, Австралія. І тоді Буллет Манале, так, справді, це його ім'я, насправді це повинні бути два Т. Буллет Манале, як наш гість від Idera, дуже, дуже цікава компанія, робить багато чого. Я вже знаю про них, один з яких вони купували компанію під назвою "Точна". Я знав їхнього генерального директора на ім’я Зохар Гілад, як це за ім’я? Він був одним чортом розумного хлопця.
Але люди, ви граєте важливу роль у цій веб-трансляції у своїх запитаннях, тому, будь ласка, не соромтеся, надсилайте свої запитання в будь-який час - ви могли це зробити, використовуючи компонент Q&A на консолі веб-трансляції, ось тут в нижньому правому куті. Ви також можете поспілкуватися зі мною, і я поговоріть із доповідачами. У нас уже є хтось, хто дзвонить з Італії, так: "Ciao, ciao. Приходь, Стай? »Добре, коли я збираюся просунути перший рядок Марка, я передам колоду Марку. Позначте, тепер у вас є WebEx. Забирай його, підлога твоя.
Марк Мадсен: Дякую, Ерік. Я не збираюся починати з середини, але почну на початку. Отож лише кілька коментарів, щоб налаштувати дискусію з Dez та Idera, свого роду стан держави з розвитком, а також базами даних та операціями. І ви знаєте, якщо ви на це погляньте, у нас є такі проблеми з двома світами, як і раніше, на ринку баз даних та прикладних програм, оскільки розробники розглядають DBA як люди, які їх клопотуть. Ви повинні будувати моделі даних, ви не можете мати доступ до цього, ви не можете створити цю річ, ви не можете помістити індекс у кожен стовпчик кожної таблиці бази даних, щоб зробити це швидше. І звичайно, навіщо нам потрібні моделі? Це просто структури даних, якщо ми їх змінимо, чи не можете ви їх просто виписати в серіалізованому вигляді?
Проблема полягає в тому, що розробники знають код і програми, але дві речі, які вони часто не знають, - це паралельність, одночасне програмування, бази даних та операційні системи під ними. Будучи розробником ядра та операційними системами та базами даних, можу сказати, що паралелізм і паралелізм справді важкі, і тому багато речей, які ви навчитесь отримувати хороші показники роботи свого коду, насправді починає руйнуватися, коли ви робота з базою даних. І продуктивність виглядає чудово, тестова обстановка виглядає чудово, і середовище Q&A, і тоді вона потрапляє в реальну систему, а потім раптом це не так чудово. Оскільки він багатогранний, як працює код з базою даних, як він працює з навколишнім середовищем, і дійсно прості невеликі практики можуть мати суттєві ефекти в залежності від того, який масштаб ви використовуєте.
І коли ви починаєте говорити про зовнішні програми, звичайно, зовнішні програми, веб-додатки, можуть бути справді важкими, тому що все чудово, поки раптом вони не зрівняються, а їх немає. Ви потрапите на ці цікаві плато, для розуміння яких потрібно багато нюансів.
Перелом речей - вид DBA. Думка DBA полягає в тому, що існують операції, вони витрачають основну частину свого часу, від 80 до 90 відсотків, в оперативі, і, можливо, від 10 до 20 відсотків займаються питаннями розвитку, які відбуваються наперед. З цього погляду ви або платите зараз, або платите пізніше, і якщо ви витрачаєте весь свій час вперед, то згодом у вас буде набагато більший шанс, на відміну від розвитку, який, як правило, вивчає особливість простір і намагаються зрозуміти, як найкраще робити речі. І тому у нас виникають проблеми, і тепер у нас є несумісні методології - безперервне розгортання, згортання ваших додатків, коли вони готові, періодично роблячи код, працюючи в магазині, який практикує розробники. Така річ прискорює розвиток, але всі практики, пов’язані з базою даних, і те, що роблять DBA, і те, що системні менеджери пройшли навчання, практикували ІТ-оператори, не відставали від темпів.
Якщо ви подумаєте над цим, більшість DBA працюють в середовищі управління зміною проти середовища безперервного розгортання. Вся справа в стабільності та контролі, порівняно зі швидкістю змін та оборотністю. Безперервне розгортання, якщо ви не можете відмовитися від змін, ви перебуваєте у біді, тому все має бути побудовано для того, щоб бути легко реверсивним та перемиканням коду, що дуже не так, як спрацювала реляційна база даних, практика розробки та практики управління. .
Ви також стикаєтесь з цими проблемами, коли ви можете бути більш ініціативними, якщо ви можете, як DBA, оскільки до моменту, коли ви дізнаєтесь про проблему, сто тисяч людей заповнюють форми скарг на вашому веб-сайті. Це залишає вам потрібні нові речі, які ви не виходите зі свого старого оточення. Ви знаєте, такі речі, як краще моніторинг та оповіщення. У той же час, бази даних розмножуються, у нас є більше програм, ніж будь-коли, щоб підтримувати більше речей, ніж коли-небудь, вони знаходяться всередині, вони знаходяться на вулиці, вони всюди. І більш незалежні набори даних для аналізів, люди запускають бази даних по всьому, тому що, звичайно, зараз просто, ви можете налаштувати віртуальну машину. Якщо у вас є постачальник хмарних послуг або внутрішня хмара, ви можете негайно з’явитись, і це змінить весь ваш шлях закупівель.
Старий шлях закупівель був: "У мене є час отримати сервер, засунути його в стійку, виділити місце, отримати місце для зберігання, встановити базу даних і робити все", проти того, як хтось провів кредитну карту і пройшов за п'ять хвилин. Якщо ви це зробите, то сучасне середовище розробки працює з дуже різними темпами, і тому легко створювати бази даних, і це просто створює цю проблему розповсюдження, як ніщо, що ми бачили раніше. І це триває вже десять років, це ні для кого не новина, але це також означає, що операційні середовища виросли в складності.
Все середовище клієнтського сервера дійсно змінилося, оскільки це вже не світ сервера клієнтів. Тоді у вас був сервер, у вас була база даних, якщо щось було не так, ви знали, на який сервер перейти, ви знали, як керувати ресурсами на ньому, оскільки найкраща практика - одна база даних, один сервер. Віртуалізація почала це розбивати, хмара розбиває її ще більше, тому що те, що ви думаєте, це сервер бази даних, - це лише програмне забезпечення. Отже, навколишнє середовище не реально. Це те, що містить навколишнє середовище, що є реальністю, і це може бути стелаж з лезами або великий сервер, вирізаний на шматки, ви насправді не знаєте.
Все, що стосується адміністрування баз даних та управління продуктивністю, а також те, що бази даних були побудовані навколо жорсткого контролю з одним сервером, або ж декількома серверами та парою баз даних, ви не можете контролювати все. Ви сидите там на машині, але пропускну здатність не може бути легко розділена віртуальними менеджерами, і тому все може бути добре з пам’яттю та процесором, але у вас є вузький вузол на деякому ресурсі, з яким неможливо розібратися, і тоді, коли ви спробуєте виправити це, стара модель могла б бути важкою роботою, отримати більший сервер і зробити щось подібне, тепер це може бути справді просто, просто додайте віртуальний курс, просто додайте пам'ять у віртуальний комп'ютер і це вирішено. Але що станеться, якщо ваш VM знаходиться на переповненому сервері і йому потрібно мігрувати? Або що станеться, якщо ви розміру системи AWS і досягнуто максимального розміру, то куди ви йдете?
Отже, у вас є всі ці проблеми, коли середовище зараз є частиною бази даних, ви пакуєте середовище з базою даних, усі спеціальні ресурси, все в додатку, яке є частиною конфігурації, конфігурація висувається туди. Це з середовища баз даних, керувати та контролювати набагато складніше.
Якщо ви подивитеся на те, що роблять центри баз даних, вони сидять на руках, правда? Ми відходили від цієї ідеї поводження з базами даних та серверами, як з домашніми тваринами. Сервери мають назви, ви ставитесь до них так, як до індивідуальних унікальних речей, ви ставитесь до них як до худоби, це керування стадом. І проблема з керуванням стадами полягає в тому, що якщо ви не контролюєте їх, вони в кінцевому підсумку можуть заступитись, а штампування - це не дуже добре. Нам потрібні кращі інструменти моніторингу, нам потрібні кращі способи боротьби з цими матеріалами та знати, на що це вплинуло. У старій моделі це було простіше, тому що ваші операційні системи та всі ваші системи управління сказали вам, але коли ім'я вашого сервера - це UPC-код, важко з'ясувати речі.
Ви не можете дозволити собі помилкові сповіщення, ви не можете дозволити собі речі, які говорять: "З цією машиною є проблема, і вона містить 30 баз даних". Ви не можете дозволити собі, щоб речі не давали історії. Консолі моніторингу чудові, коли вони загоряються, але якщо червоне світло знову стає зеленим, і ви не знаєте чому, і у вас немає історії, щоб повернутися назад, щоб подивитися, що до цього призводить, і що контекст був, ти в біді. Нам потрібні системи, які здійснюватимуть моніторинг за нами, нам потрібен кращий моніторинг, вирішення короткочасних проблем, що підтримують цю історію даних.
Кращі речі та прості пороги метрики, які дають нам ключові показники, але не спрямовують нас безпосередньо до того, що нормально, що ненормально та як часто виникають ці проблеми. Те, про що ми говоримо насправді, - це поєднання моніторингу навколишнього середовища та розгляду ефективності, а постачальники сидять на руках. Вони не дали нам кращих інструментів. У нас є системи з більш процесором і пам’яттю, ніж ми знаємо, що з цим робити, і все ж ми все ще покладаємось на моделі ручного втручання, ми не ставили машину працювати, керувати нами, щоб довести нас до проблеми, ми не довелися до цього нового стилю, який є: "Тут є проблема, ви можете це виправити", або "Існує проблема продуктивності. Це насправді з цим конкретним оператором SQL. Ось три речі, які ви могли б зробити Використовуйте для виправлення цього оператора SQL. "Застосовуючи евристику, застосовуючи моделі машинного навчання, які можуть переглядати схеми використання вашої системи, щоб виявити проблеми та уникнути помилкових попереджень. Використання машини для того, щоб зробити те, що працює найкраще, збільшити DBA або збільшити кількість людей, які мають вирішити проблеми з продуктивністю.
Це новий спосіб, на відміну від старого стилю. У цій базі є проблеми, все відбувається повільно, і тому у нас є нові методи, нові способи зробити це, і ми повинні застосовувати їх, і ось куди рухається ринок. Ви бачите, що він починає з'являтися не у великих постачальників, а з сторонніми компаніями, і це відображає те, що трапилося 20 років тому, коли постачальники баз даних не надавали жодної речі, яка допомогла б керувати системами. Тож ось такий напрямок ринку, і з цим я хотів би повернути його до Еріка.
Ерік Кавана: Добре, я передам його Дезу. А Дез, забирай його, підлога твоя.
Дез Бланшфілд: Дякую, Марку. Ви зробили фантастичну роботу щодо висвітлення технічної складової. Я піду на це з дещо іншого кута, щоб висвітлити те, що сталося в решті світу, що стосується впливу на бізнес та бази даних навколо них. Дозвольте мені просто перейти до мого першого слайда.
На задній частині того, що ви щойно висвітлювали з технічної сторони речей і з боку розробників, я бачу, що підприємства повинні зіткнутися з викликом даних і баз даних, зокрема, і, очевидно, у нас відбувся цей значний перехід до це поняття великих даних, але ефективні бази даних все ще є серцем і душею того, де організації зберігають свою ділову інформацію, і це від вхідних дверей аж до бек-офісу. Кожна частина організації торкається якоїсь бази даних, яка працює на базі даних, і дуже рідко я вступаю або в обговорення проектів, або в якусь інноваційну стратегічну розмову в організації, де тема бази даних або система бази даних не підходить, і завжди виникають питання щодо типів речей, про які ми щойно чули, щодо продуктивності та безпеки, і як розробка підходить до цього виклику, і куди підходять бази даних, а також наші обізнані про оточення та застосування з якими середовищами спілкуються, а що стосується пристроїв та мобільності?
Це все ще дуже, дуже гаряча тема, і вона довгий-довгий час була в грандіозній схемі речей, наскільки йде сучасна технологія. До цього моменту я вважаю, що це факт, що майже все, що ми робимо у своєму повсякденному житті, щоденне життя, тобто це підтримується деякою формою бази даних. Коли ми думаємо про все, що навколо нас, будь то законопроект, який щодня надходить по пошті за якусь послугу, яку ми купуємо, вона неминуче друкується системою, яка розмовляє з базою даних, і ми там. Наші телефони мають на них бази даних із контактами та журналами викликів та ін.
Куди б ми не йшли, за розмовою та системами, якими ми користуємось, є якась форма бази даних, і вони частіше за все вони досить прозорі для нас, але факт полягає в тому, що вони там є. Тож я подумав, що я швидко висвітлю, чому це стало проблемою за дуже короткий проміжок часу. На початку концепція бази даних походила від цього прекрасного джентльмена Едгара Кодда. Працюючи в IBM, він змінив світ щодо управління даними, створивши концепцію, яку ми сьогодні називаємо реляційною базою даних.
На початку база даних була базою даних, і життя було хорошим, вона була досить простою як у стовпцях, так і посиланнях і так далі, і таблицях, і розробка програмного забезпечення була досить простою, і продуктивність насправді не була такою великою проблемою - це була нова захоплююча технологія. Ми отримали доступ до баз даних через якусь форму терміналу, і ви можете дійсно створити стільки хаосу в кінці терміналу 3270 на мейнфреймі, і незмінно інших типів терміналів, ці інші системи прийшли разом. І в більшості випадків термінали старого стилю були дуже схожими на теперішні веб-середовища, і це те, що ви заповнили б форму на екрані в самому терміналі і натиснули Enter і off it go, це було б знімати як один пакет, як запит, і бек-енд-система би вирішувала це. Це, по суті, те, що відбувається з веб-браузером в ці дні, коли ви набираєте посилання на веб-браузері, і в такому вигляді він зазвичай не повертається до системи в режимі реального часу, хоча сьогодні AJAX це не зовсім справа.
Але потім щось сталося, прийшло майбутнє, а нещодавно Інтернет, і майже вчора, в секційній веб-2.0, і вже за кутом, у нас з'явився Інтернет речей. І в процесі майбутнього, світ баз даних просто вибухнув, і взаємодія з базами даних просто стала тією річчю, яку ми всі робили за замовчуванням. Це був не випадок, коли б ви кудись щось робили, наприклад купувати Квиток на літак, і хочуть подорожувати на інший бік планети, хтось повинен був набрати в терміналі всі ваші дані та зайти в базу даних та роздрукувати квиток.
Практично все, що ми робимо зараз, будь то виклик таксі в Google із додатком, чи то стрибки в Інтернет-банкінгу, все, що ми робимо щодня, з якоюсь системою, це працює на базі даних. І коли Інтернет з'явився, це було трохи легше донести до нас, наше повсякденне життя через веб-браузер, а потім веб-2.0 з’явився, і все стало мобільним, а масштаби речей просто вибухнули. Насправді, моя улюблена лінія в цій темі полягає в тому, що "Інтернет підключив все, web 2.0 зробив це мобільним і соціальним, і все стало дуже-дуже великим, і тепер у нас є Інтернет і речі, і IoT … Yikes !!" Ми навіть не почали уявляти вплив Інтернету речей, коли мова йде про світ на системи баз даних.
Отже, по-сучасному, те, що ми звикли вважати терміналом, фактично стали цими речами, це мобільні телефони, це різні види планшетів, або персональні планшети з великим екраном для споживачів, або підприємства, це ноутбуки, і це традиційний настільний ПК в якійсь формі. У цьому одному зображенні ви бачите майже кожну форму інтерфейсу, який ми зараз використовуємо для розмови з системами баз даних та додатками, які працюють від них, від маленьких гаджетів у наших руках, які ходять навколо, і ми, здається, приклеєні до всіх шлях до дещо більших версій, iPad, інших планшетів та Microsoft Surface, до повсякденних ноутбуків, які незмінно зараз у професійних умовах тощо. Люди, як правило, отримують ноутбук, а не стаціонарний робочий стіл, але, на мій погляд, вони є сучасним терміналом, і це є причиною того, що в базах даних виникають усілякі проблеми в продуктивності управління частиною нашого життя, а не лише розвитку.
Тож я припускаю, що це одна з найбільших проблем, з якою бізнес щодня стикається щодня. Всі вважали, що бази даних - наша єдина проблема, це не так. То в чому вся суєта? Добре, коли ми переходимо від одного кінця до іншого з усіма речами, пов’язаними з базами даних, з комерційного сенсу, і Марк висвітлював технічні компоненти дуже, дуже добре, але в комерційному сенсі, як організація, ми думаємо про бази даних. Ми маємо справу з усіма речами, починаючи від базового дизайну та розробки. Коли бізнес починається, вони будуть думати про розробку програм, розвиток можливостей або навіть реалізацію існуючої програми в якійсь формі. Певна форма проектування та розробки повинна мати місце, і потрібно багато думати про те, як ці системи баз даних будуть впроваджені, підтримувані та керовані, а також відстежуються виступи тощо.
Інтеграція середовища баз даних та додатків, а також типів API, типи доступу, які надаються зараз, стають все складнішими, складнішими. Повсякденне адміністрування, підтримка та резервне копіювання, знову ж таки, це речі, які, на наш погляд, були вирішені, але тоді раптом масштаб став значно більшим, і все рухалось швидше, а обсяг настільки більший; розмір середовищ, системи баз даних повинні були підтримувати швидкість, з якою рухаються транзакції.
Подумайте про базу даних у дуже, дуже високочастотній торговій обстановці, просто немає можливості людям відстежувати це, це просто кластер машин, які борються з іншим кластером машин, щоб робити високочастотні торги, купівлю та продаж, а обсяг на які ці угоди трапляються. Подумайте про сучасний сценарій, як-от достроковий випуск фільму Netflix, де ви не говорите лише про сотні чи тисячі, а то й сотні тисяч, потенційно мільйони людей хочуть переглянути цей фільм із тієї самої секунди, коли він вийшов. Вся ця інформація збирається, відстежується, записується та аналізується на платформі бази даних.
І тоді є постійно свідомий світ, у якому ми живемо зараз, 24/7, а не просто слідувати за Сонцем, але завжди є хтось опівночі, який хоче щось зробити, а робочі години слідують за Сонцем у всьому світі. Тож тривалість роботи та доступність за замовчуванням - це клімат зараз, а відключення дійсно просто не прийнятна річ. І надмірність, якщо виникає проблема з продуктивністю або якщо нам потрібне вікно технічного обслуговування, щоб здійснити оновлення або виправлення, або безпеку, насправді нам потрібно мати можливість вирізати з одного середовища баз даних до іншого і робити це безперебійно та автоматично.
Безпека та стандарти та відповідність. У нас у світі пізно трапляються досить великі речі, зокрема, GFC, і тому у нас є цілий ряд нових викликів, які потребують вирішення навколо відповідності, безпеки та відповідності стандартам, і нам потрібні мати можливість звітувати про них у режимі реального часу, а в ідеалі - у формі інформаційної панелі. Ми не хочемо відправляти команду мавп до центру обробки даних, які намагаються знайти речі, нам потрібна система, щоб сказати нам це негайно, в режимі реального часу.
І дві великі забави, про які майже ніхто ніколи не розмовляє, ми, як правило, підштовхуємо їх під килим і сподіваємось, що вони ніколи не піднімуть свою потворну голову, але відновлення після катастроф та безперервність бізнесу - це теж речі, які повинні здебільшого, відбуваються автоматично, у разі потреби.
Ми могли проводити дні, розмовляючи про типи речей, які можуть піти не так у середовищі бази даних, і про те, що люди взагалі реагували, але зараз для цього нам потрібні системи та інструменти. Одним із прикладів є порушення даних, і так, коли ми думаємо про бази даних, і я задаю це питання досить відкрито в різних формах: що відбувається з базами даних, коли ми знімаємо очі з кулі, і щось критичне йде не так? Особливо, якщо немає системи, яка б переглядала продуктивність та безпеку та інші основні аспекти роботи баз даних.
Ну, що може статися, це таке, це скріншот деяких останніх порушень за останні два-три роки. Незмінно, всі вони походять із системи баз даних, і незмінно виникла якась проблема безпеки чи контролю, або доступу, що виникає, і у верхньому лівому куті ми дивимося 152 мільйони акаунтів Adobe, де кожна деталь цих клієнтів було порушено. І якби у випадку відповідних інструментів, можливо, були б відслідковувати та фіксувати інцидент, а також контролювати безпеку, ми могли б уникнути деяких із них, можливо, перші пару сотень записів, що були викрадені, нас би попередили, і ми мали б зупинив наступні сто п’ятдесят мільйонів.
Тоді ми дістаємось до ключового пункту всієї цієї подорожі, який ми провели через, тобто: навіщо нам потрібні кращі системи? Чому ми не можемо просто кинути більше тіл на цю річ, що ми добре і по-справжньому перетнули переломну точку на мій погляд, і, звичайно, я вважаю, що є випадок, який свідчить про запізнення, що кидає більше DBA, адміністраторів та більше людей на ця річ не вирішує проблему. Нам потрібен кращий набір інструментів і кращий набір систем.
Ось мої п’ять найкращих причин, на які я вважаю, що це підтримують, і вони класифікуються за важливістю, виходячи з того, що я бачу на цих приватних підприємствах і в штатах, які керуються середовищем, і з якими проблемами вони стикаються з середовищем баз даних, та керуючи ними.
Безпека та дотримання - номер один. Ви знаєте, контролювати, хто має доступ, звідки вони мають доступ, коли вони мають доступ, як часто вони мають доступ, звідки вони отримували доступ до нього. Потенційно пристрої, яких вони насправді торкнулися, і типи речей, які вони подивилися, і відповідність, яка існує навколо цього. Після того, як люди через 30 днів надсилають звіти, щоб сказати нам, чи все добре, просто більше не підходить, це повинно відбуватися в режимі реального часу.
Продуктивність та моніторинг - це, здається, не мастери, але незмінно це не так. Незалежно від того, використовуємо ми інструменти з відкритим кодом чи якісь сторонні комерційні інструменти, ми багато разів не пропустили човен із необхідними видами моніторингу продуктивності та деталями, які та здатністю реагувати вчасно. .
Виявлення та реагування на інциденти - це повинно бути миттєвою справою в реальному часі, і незмінно нам потрібна система, яка б це зробила для нас, або принаймні швидко повідомила нас, щоб ми могли вирішити це, щоб вирішити кілька проблем, що виникають. швидко і не каскадуйте поза контролем.
Управління та адміністрація - знову ж таки, ми вважаємо, що ці проблеми вирішені, їх немає. Мета, з якою стикаються команди баз даних, зокрема, БДД, де система повинна піклуватися про нас, ми ще не вирішили цю проблему, вона все ще реальна річ.
І вже з переднього кінця з розробкою та розробкою, коли ми починаємо створювати ці інструменти, ми створюємо середовища баз даних, зможемо кинути відповідні інструменти при розробці та тестуванні та інтеграції платформ. Це все ще непроста річ для нас, і вся ця поїздка наштовхує нас на те саме повідомлення, що на мій погляд нам потрібні кращі системи та кращі інструменти, які допоможуть нам досягти результатів, які нам потрібні наше середовище бази даних, так що компанії, які користуються великою вартістю від наших клієнтів. Ми не можемо просто кидати більше тіл і більше DBA, шкала занадто велика, швидкість занадто швидка і гучність занадто висока. З цим, Ерік, я можу перейти до тебе.
Ерік Кавана: Мені це подобається, у нас там дуже багато землі, багато перспективних ведучих, і ми продовжуємо і передаємо ключі Буллетту за одну секунду.
Bullett Manale: Гаразд.
Ерік Кавана: О, давайте відберемо його та Буллетт, зараз я передаю вам його, а слово - ваше.
Bullett Manale: Добре, дякую. Думаю, багато хороших моментів зроблено. Мені хотілося швидко на секунду поговорити про Ідеру, хто ми, і тоді ми заскочимо. Я поговорю про інструмент, про який я думаю, що багато цього, про що ми говоримо, ми можемо набір і вид обговорення деяких областей, за якими вони узгоджуються, за допомогою цього інструменту, продукту Diagnostic Manager.
Тепер, те, що я хочу зробити спочатку, - це лише трохи ознайомитись з інформацією про те, хто така Ідея; ми існували приблизно з 2003 року, і тому ми розпочали лише інструменти SQL Server, і саме на цьому ми сьогодні зупинимось, це продукт Diagnostic Manager. Але ви можете бачити всі відра речей, які ми маємо тут, і ми нещодавно, як уже згадувалося, ми придбали точність і через придбання, у нас також є Embarcadero, і тому у нас є досить непоганий асортимент продукції.
Щодо моніторингу продуктивності, то з точки зору SQL Server продуктом, про який я хочу поговорити, який вирівнює ці теми, про які ми говоримо, є «Діагностичний менеджер». Тепер це продукт, який існував з досить близьких до початку днів Ідеї, і мені пощастило бути частиною цього приблизно з 2005 року. І я побачив багато змін у плані SQL Server, перехід від фізичного до віртуального, все таке, що трапляється, а також потреби DBA в міру зростання середовищ, а також такі речі.
З чого я розпочав, типовим користувачем нашого продукту є DBA, і тому, коли ми вперше розмовляємо з людьми, потенційними клієнтами, це, здебільшого, ЗБД. Ми не розмовляємо з ІТ-менеджерами чи директорами, можливо, в якийсь момент вони вийдуть на цей рівень, але початковий початок полягає в тому, що у DBA є проблема, DBA намагається виправити проблему, і ми багато разів Підійду і завантажую та пробую пробу продукту як частину цього. Ви або отримаєте менеджер даних, або DBA, або діючу DBA, хлопець, якому пощастило бути найбільш технічним в кімнаті, в деяких випадках. Тепер, коли ви потрапите в більші корпоративні середовища, очевидно, тоді ви збираєтеся отримати повномасштабні DBA, як правило, вони будуть тими, хто використовує цей інструмент. І я пішов вперед і просто додав сюди трохи розмитості з Вікіпедії. Це ніби перебирає обов'язки DBA, як каже Вікіпедія, саме так вони і роблять.
Якщо ви переглянете тут список, багато цих речей, я не збираюсь його читати, але ви отримуєте багато типових речей, про які ви б подумали, а потім за одним із них у вас є моніторинг і оптимізація продуктивності бази даних, і це досить велика. І що цікаво, це коли ви спілкуєтесь з DBA, вони завжди є тими, хто звинувачується в першу чергу, коли йдеться про проблеми, і це, можливо, не в їхній вині, але коли виникає проблема продуктивності, як правило, з додатком, який прив’язаний до бази даних DBA, вони винні, тому вони завжди шукають причини, чому це не їхня вина. У багатьох випадках саме вони можуть використовувати цей інструмент, Diagnostic Manager, щоб допомогти їм зробити це.
Але в кінці дня також, якщо база даних не працює, багато цього іншого насправді не має значення, ваші програми не працюють, значить, для багатьох з них це не має значення. речі. Перш за все, ми хочемо переконатись, що користувач відчуває так, як ми його знаємо, не зменшується, це те, до чого завжди прагнуть DBA. І я вважаю, що якщо ви подивитесь на причини, через які люди зазвичай купують та використовують продукт SQL Diagnostic Manager, одна з перших причин, мабуть, не найголовніша, не остання чи найменша, але це все рівно, і залежно від того, з ким ти розмовляєш, цих причин майже одна чи дві завжди є, навколо є якась потреба.
Але перший - це лише можливість мати централізоване уявлення про екземпляри як SQL, яким вони керують. І найсмішніше, що у багатьох випадках, якщо ви запитаєте у DBA: «Скільки екземплярів ви керуєте?» Число змінюється так часто, що в деяких випадках вони не дуже впевнені. Тож вам потрібно щось більше, ніж просто вміти перекидати все на екран. Ви хочете скористатися цією інформацією, ви хочете осмислити її, і тому це одна з речей, з якою Diagnostic Manager безумовно може допомогти, - це можливість надати вам такий вид зору.
І це не просто погляд на навколишнє середовище, але це погляд на те, що DBA, адміністратор бази даних, комфортний, і це консоль, орієнтована на DBA, якщо ви хочете. Він створений для адміністратора бази даних. Там є багато інструментів для моніторингу, є багато інструментів для роботи, але, як я вже сказав, наприкінці дня DBA хоче інструмент, призначений для DBA, тому що є багато речей, специфічних для того, що вони роблять в їх день у день.
І з урахуванням сказаного, у вас є SCOM, у вас HPF, у вас є всі ці інші технології, але вони хочуть чогось, що є особливим для того, що вони роблять. Я думаю, що ми можемо допомогти в цій галузі з цим продуктом, ви побачите, коли ми потрапимо в нього за секунду. Інша річ, яку ми бачимо з DBA, що, безумовно, є однією з речей, яких ми торкалися і раніше, - це те, що вони повинні мати можливість бачити, що відбувається, очевидно, і вони повинні мати можливість переглядати все підприємство і мати спокій у розумінні того, що відбувається. Але в той же час вони не сидять і дивляться на консолі.
Пам’ятаєте всі ті пункти кулі, які ви бачили в цьому списку, що я щойно підняв? Вони також повинні робити і інші речі, тому справа не лише в тому, щоб чекати, поки пожежі будуть погашені. У багатьох випадках будуть зустрічі, або багато вікон технічного обслуговування, пов’язаних з адміністратором бази даних, працюють посеред ночі, коли вони сплять, тому вони повинні мати можливість повертатися назад і дивитися, що сталося . У багатьох випадках, якщо ви щось не вловили, коли це відбувається, як тільки проблема пішла, або, принаймні, з SQL Server, це стає певною проблемою, коли ви маєте справу з ситуацією, коли ви цього не робите вже немає залишків цієї проблеми. І ці проблеми зникають, а також залишки, а це означає, що вам менше вирішувати проблеми, у вас менше інформації для роботи.
З урахуванням сказаного, це, безумовно, одна з речей, з якою може допомогти Діагностичний менеджер, - це надати вам такий погляд у минуле, щоб запитувати інформацію з минулого: "Чи було у мене попередження про блокування, чи були проблеми з тупиковим блокуванням, чи були у нас речі, що відбувалися з точки зору наших ресурсів? "Я можу повернутися назад і запитати цю інформацію. Я можу детально вивчити конкретні моменти. Я зможу зробити все це безпосередньо з інструменту.
Усі ці речі, незважаючи на те, чи це внутрішня чи зовнішня програма, 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 інших віртуальних машин, до яких вони намагаються отримати доступ, і вони мають суперечки на тих самих ресурсах. І єдиний спосіб насправді це побачити - це спілкування з тими іншими середовищами та з тими інтерфейсами, у цьому випадку, що ми робимо.
У вас є можливість додати ці інструменти інших типів лічильників в інструмент. Тепер справа не лише в тому, щоб мати змогу контролювати ці лічильники, а про те, щоб зробити ці нові лічильники, щоб ви познайомилися з продуктом, зробили їх частиною інструменту, як ніби вони були вичерпаними показниками . Нестандартна річ, яку ви хочете стежити; тож це означає можливість включити їх до своїх панелей приладів. Це означає, що можна додати їх до власних спеціальних звітів, мати можливість очевидно встановлювати порогові показники та сповіщати про них, а також базувати їх та мати змогу встановлювати поріги з деякими знаннями про те, де їх встановити на основі таких речей, як ваш базові лінії і що нормально. Отже, у вас дуже багато таких речей, які також є у виробі.
Те, що я вам надавав, - це те, що я називаю «основними результатами для Діагностичного менеджера», і я можу продовжувати і лише трохи покуштувати це, зайшовши в продукт. Що я збираюся робити поділіться моїм екраном, добре, і просто перетягніть це. Отже, що ви збираєтеся бачити, це консоль діагностичного диспетчера. І як я вже згадував раніше, переходжу до цього першого ядра, який можна отримати, щоб мати можливість подивитися речі з вигляду на рівні підприємства. Є багато різних прикладів цього в інструменті. У нас є вид ескізів; у нас є більше сітчастого вигляду. Ми також маємо, з точки зору гнучкості, ми мати також веб-консоль. Веб-консоль має інші види, доступні вам, як-от ключові карти та подібні речі. Але справа в тому, що ви маєте таку здатність переглядати та бачити речі Але коли виникають проблеми, ви збираєтеся копати трохи далі в інструмент і насправді бачите конкретну проблему леми, і мати якийсь спосіб зрозуміти і знати, що відбувається. І очевидно, що це дуже важливо.
Тепер, з точки зору можливості реально побачити, що відбувалося в минулому; якщо я дивлюся на проблему, яка сталася вчора або тиждень тому, то в цій ситуації, ви знаєте, у вас виникне потреба мати можливість вийти до конкретного примірника SQL. І гарна новина полягає в тому, що якщо ви знаєте, в який час ця проблема сталася в межах продукту, ви можете перейти безпосередньо до браузера історії. І я можу вказати на конкретний час доби; це може бути від пари тижнів тому, може бути і з вчорашнього дня. Але який би день я не вибрав у календарі, мені потім будуть представлені різні інтервали опитування. У такому випадку зараз я фактично бачу те, що бачив би, якби переглядав консоль 20 квітня о 13:37
Тож я можу повернутися назад у часі, а потім, коли я це зроблю, усі різні вкладки, які ми бачимо тут, відображатимуть цей конкретний момент часу, включаючи запити, які, можливо, погано працюють, включаючи, можливо, якщо У мене були сеанси з блокуванням. Усі подібні речі відображатимуться в інструменті, і це дозволить мені явно використовувати цю історичну інформацію, щоб мати можливість, ви знаєте, вирішити проблему. Тепер на цій замітці, коли ми говоримо про історію, інше, що тут варто зазначити, це не просто використання історії для вирішення проблем. Ця історія дуже цінна, очевидно, з інших причин. І одне з найбільших - вміти ефективно приймати рішення та швидко приймати рішення з потрібною інформацією. Тож усю цю історію, всю інформацію, яку ми збираємо, ми можемо звітувати проти.
Якщо хтось приходить до мене і каже: "Я отримав цю справді чудову нову програму. Це змінить світ так, як ми його знаємо. О, до речі, для цього потрібна база даних, і, до речі, це дійсно буде прив'язувати I / O на машині, де знаходиться ця база даних ". Якщо я знаю, що вдаючись до цього, я можу використовувати цю інформацію, щоб можна було скласти рейтинг усіх моїх виробничих серверів, виходячи, можливо, за останні сім днів збору. І я міг би дуже швидко дійти висновку про те, які екземпляри мають найбільш сенс використовувати цю базу даних. Так що це той тип історичної інформації, який також, очевидно, дуже цінний.
З точки зору самих запитів; з точки зору розгляду запитів, у нас в інструменті є багато різних способів. І те, на що я люблю дивитись, - це Перегляд очікувань на запити, оскільки перегляд очікування запитів дуже корисний з точки зору можливості оцінити. Якщо у мене є вузьке вузьке місце, щоб мати можливість по суті визначити всі різні області, які впливають на конкретний, конкретний запит; не тільки сам запит і який вплив має цей запит, але також, ви знаєте, з якої програми він прийшов, з якого сеансу він прийшов, який користувач назвав його і всі ці речі, я можу побачити, що, очевидно, інформація в реальному часі, але я також маю можливість переглядати ці дані з минулого. І ось це одна з речей тут, і я розпочав сценарій, але мені доведеться чекати, коли він спливе.
Поки ми чекаємо на це, я хочу - і я знаю, що нам не вистачає часу, тому я хотів трохи поговорити і про попередження про попередження. І коли ви говорите про такі речі, як я вже казав, є проактивною частиною, є багато інструментів, які бдиво. Важкою частиною є не надсилання електронного листа. Важка частина - не запис у журнал подій або генерування лову SNMP. Важка частина - це знати, коли потрібно надіслати це сповіщення у відповідний час. І тому з цим виникає багато необхідності робити деякі обчислення, розуміючи: "Що це за конкретний екземпляр і що нормально, як це стосується цього екземпляра?"
І тому для всіх показників, які мають сенс робити це, ми базуємо ці показники. Ми фактично показуємо вам базову лінію, ми покажемо вам поріг, на який вона встановлена. І тоді інша приємна річ у тому, що, скажімо, я встановив свої пороги в цьому випадку шість і десять лише для цього прикладу. Через шість тижнів, якщо я повернусь до цього випадку, ця базова лінія може повністю змінитися, тому що одна з речей, які ми робимо, коли ми обчислюємо базову лінію, за замовчуванням - це розрахований семиденний розрахунок. Тому мені завжди надається найновіша версія базової лінії. А що станеться, якщо ця базова лінія зміститься на мої пороги? У цьому випадку я бачу і попереджую рекомендації, які в основному говорять: "Ей, у вас є поріг, який, мабуть, встановлений неправильно, специфічний для того, де ми бачимо поріг, і, очевидно, де базовий рівень, ви, ймовірно, збираєтесь отримувати сповіщення про щось, що є нормальним явищем ".
І тому замість того, щоб лікувати симптом чогось нормального, я можу визначити той тип ситуації, коли фактичний поріг встановлено неправильно. І те, що дозволяє мені робити, очевидно, - це встановити пороги відповідно до того, де я буду отримувати попередження. Я знаю, що це більше заклик до дії, а не розслідування, щоб зрозуміти, чи справді це проблема. І я вважаю, що частина інструменту справді корисна з точки зору базової лінії та з можливістю розрахувати.
Тепер із цим продуктом ви маєте можливість мати декілька базових ліній; ви можете встановити їх на різні періоди часу, і ви можете динамічно регулювати пороги на основі базових ліній, що також є дуже важливою частиною свого роду пристосуванням до змін, що відбуваються щодня до ваших екземплярів SQL Server . Тепер у цьому випадку ми начебто висвітлюємо багато параметрів порогів і показуємо вам базові лінії. Що ж стосується фактичних сповіщень, то саме сповіщення, приємна річ про Діагностичний менеджер, - це чи дає вам кілька профілів оповіщення. Отже, якщо у вас є, наприклад, профіль дзвінка, який працює з 2:00 до 5:00 ранку, тоді я можу мати профіль, специфічний саме для цього періоду часу, і я можу тут встановити всі умови та відповідні налаштування. за мою відповідь.
Тепер річ у відповіді полягає в тому, що в деяких випадках так, я можу надіслати електронний лист, або можу знімати та генерувати SNMP-пастку, або записувати у журнал подій. Ми можемо зробити багато інших речей, але, як я розмовляю з DBA, те, що їм насправді дуже подобається, це той факт, що в більшості випадків багато роботи, яку виконують, - це повторювані речі. Це речі, які вони точно знають, коли виникає проблема, що робити, щоб її усунути. Вони просто повинні піти і втрутитися. І тому, коли ви робите своє оточення, оскільки у вас є більше примірників, це стає набагато складніше. Отже, одна з речей, яку ви можете зробити в цьому інструменті, який, на мою думку, заслуговує на увагу, - це у вас є можливість встановити умову, але виходячи з цієї умови, щоб мати можливість встановити відповідь на запуск сценарію, запустити команду робота, запустити виконуваний файл. І справа в тому, якщо ви все-таки вирішите запустити скрипт, я можу використовувати параметри, всередині цього сценарію, які будуть під час виконання, заповнені фактичною інформацією.
Отже, якщо є проблеми з певною базою даних, скрипт буде розроблений для роботи саме проти бази даних, де проблема виникає. Отже, ви можете динамічно вирішувати проблеми автоматизованим способом, і тоді я все одно можу отримати електронний лист, щоб повернутися і сказати мені, що: "Ей, виникла проблема, але, до речі, вона була виправлена". Сценарій був запущений, і як DBA ви знаєте про це, але вам насправді не потрібно було заходити та втручатися. Тепер, на тій же примітці про активність, очевидно, у нас є ще одна особливість, яка є "Аналіз". І що це буде робити, це буде робити регулярну перевірку проти екземпляра SQL. І, в деяких випадках, він здійснить глибше занурення з точки зору того, що шукає. Буде проведено такі речі, як аналіз гіпотетичного індексу. Чи потрібно додати індекс? Чи потрібно видалити індекс? І всі ці речі, очевидно, допоможуть у моєму виконанні, але, знову ж таки, справа в тому, щоб бути ініціативною. Йдеться про те, щоб можна було приймати рішення перед тим, як перерватись, і зробити це краще. І так, у багатьох випадках, саме це ми намагаємось зробити тут.
Повернення до запиту чекає, про який ми говорили раніше; як бачите, тут великий колосок. Раніше я запускав сценарій, який просто викликав деяку активність очікування, і, як я вже згадував раніше, у нас є дійсно унікальний спосіб, коли ви можете детально ознайомитися з цією інформацією. Якщо я хочу подивитися, що це за програма; Я можу бачити, що він надходить із програми NoSQL. Ми зможемо побачити базу даних, до якої вона прив’язана, сеанс, користувача, і тоді, якщо я хочу, я можу оцінити це, з точки зору мого очікування, також. Тож, я можу сказати, з усіх очікувань, що відбувалися в той вікон часу, які з них відбувалися найбільше? І якщо я бачу, що коли це сталося найбільше, справді приємна річ, що я можу вивчити цей тип очікування і я можу побачити всі команди. Якщо подивитися тут, вони змусили цього чекати. І я також бачу в першу чергу, яка саме програма була, що змушувала цього чекати.
Так воно стирчить, як біль у великому пальці. Я можу негайно перейти і сказати: "Це програма, яка спричиняє моє вузьке місце. Тепер який запит був запущений? Який користувач запустив його? З якою базою даних він працював?" І так далі. Тож, сподіваємось, це має сенс, і це також допомагає переконатися, що у вас немає затримок у вашому оточенні, оскільки це стосується ваших баз даних. Сподіваємось, це корисно. Я збираюся йти вперед і передати його назад, і я думаю ми можемо продовжувати звідти.
Ерік Кавана: Безумовно. Тож, мабуть, я просто кину це нашим експертам дня. Позначте, можливо, спершу ви хочете прокоментувати і задати пару питань. Тоді Дез, ти можеш зазивати.
Марк Мадсен: Так, дякую, мені дуже сподобалось переглядати щось із цього. Це набагато розумніший моніторинг, ніж я звик бачити. Мені цікаво управління даними, що стоять за цим; управління показниками, які ви можете відстежувати, і ви знаєте, шукайте такі речі, як зміщення базових ліній, зокрема, що є однією з больових точок мого домашнього улюбленця, за допомогою інформаційних панелей. Як ви поводитеся з цими даними, а друга частина цього - це, знаєте, базові показники, як-от зсув - чи є у вас можливість також автоматично змінювати порогові значення, щоб мені не довелося повернутися назад і скинути пороги вручну, коли зміщується базова лінія?
Bullett Manale: Ви це робите, і тому приємна річ, це ви можете вирішити. Ви можете зробити будь-яке. Я можу встановити поріг і зробити його статичним, або можу встановити прапорець, щоб сказати: "Зробіть це динамічним порогом, який зміниться, коли змінитимуться мої базові лінії". І у мене є можливість та інструмент встановити вікно за замовчуванням. час для моєї базової лінії. Але тоді, якщо мені доведеться, у мене може бути окреме вікно базової лінії, наприклад, з мого вікна обслуговування з 02:00, скажімо, до 5:00 ранку, тому що я буду оподатковувати свою Процесор, мої накопичувачі та все інше, тому що тоді ми виконуємо все своє обслуговування. Тоді автоматично, якби я його вибрав для цього, воно автоматично відрегулює мої порогові значення, щоб вони не були там, де це нормально для тих показників, які Я б вирішив це зробити з. Це дозволило б мені це зробити. В основному у вас є можливість встановити вікна часу, тобто ваші базові вікна, і кожне вікно може розглядатися як окрема сутність, з точки зору динамічне регулювання базового рівня, що можна зробити. Ви можете додати стільки вікон базової лінії, скільки років вам потрібно, якщо це має сенс. У вас може бути вікно вихідного дня, будній день у робочий час, вікно технічного обслуговування, яке відбувається посеред ночі тощо, і так далі.
Марк Мадсен: Дякую.
Bullett Manale: Я думаю, повертаючись до першої частини питання, яку ми маємо, і збираємо всю цю інформацію. Я не дуже говорив про архітектуру, але у нас є резервне сховище, що ви маєте повний контроль над збереженням цих даних, але у нас також є сервіс, який працює посеред ночі, що йде і робить всі наші розрахунки за базовою лінією, і дані беруть до уваги, збирають і мають сенс. І очевидно, що поряд з цим у вас є також численні звіти, які ми можемо використовувати для звітування проти ваших базових ліній для конкретних показників. І навіть у вас є можливість порівнювати базові лінії одного і того ж сервера за тією ж метрикою за різні періоди часу. Ви можете бачити, чи є відмінності, що відбулися, або що таке дельта. Існує дуже багато таких варіантів.
Ерік Кавана: Дез.
Дез Бланчфілд: Одне швидке запитання, яке я маю до вас, - є широкий спектр того, що може зробити цей інструмент. Чи бачите ви зараз сприйняття його використання на ранній стадії розвитку, чи це все ще насамперед інструмент виробничого середовища? Іншими словами, чи отримують розробники доступ та використовують його через ранню розробку, а потім тестують фазу інтеграції? Або все ще використовується переважно у виробничих середовищах?
Bullett Manale: Я б сказав, що більшість випадків ми бачимо це у виробничих умовах. Це залежить від ситуацій, але здебільшого я б сказав, головним чином, виробництво і ми - і, також, знаєте, справедливо зазначити, що у нас різні ціни на розробку та тестові середовища, тому це трохи привабливіше. Ми бачимо людей, які використовують це для тих середовищ, але я б сказав, якби я мав дати вам відповідь так чи інакше, я б сказав, що це перш за все виробничі середовища, де ми бачимо, як люди вкладають гроші в цей продукт .
Дез Бланчфілд: Звичайно, так, і було цікаво почути, що у вас різні точки ціноутворення, оскільки, очевидно, є різні навантаження, і чим важчі робочі місця будуть там, де виконується вся реальна робота. Але я бачу багато організацій, особливо в уряді, і, звичайно, в обороні, де розвиток зараз отримує той же рівень інвестицій в інструменти та системи, як виробничі середовища, тому що вони роблять набагато більше попереднього тестування. Наприклад, у захисті є команди, які виконують мільярди тестів, сотні мільярдів тестів на додатки та системи та інструменти, і стежать за ними, перш ніж вони навіть перейдуть на інтеграційне тестування, тому що вони хочуть переконатися, що вбудований код та база даних воно сидить під ним. Це дістається до сто мільйона ітерацій чи чогось іншого, тоді як ви виїжджаєте в поле, стріляючи в когось, це не йде "на удар".
Bullett Manale: Звичайно.
Дез Бланчфілд: У моєму досвіді у базі даних старих шкіл, думаючи, що середовище бази даних - це те, що лише залишилось у даних, і дехто з вас знає, дуже рідко зустрічається і про нього дуже рідко говорять, тому коли ми розбираємося, де інструменти та програми розробляються, особливо з аналітичними платформами, вони зараз є у наших телефонах та на наших пристроях. Чи бачите ви, щоб клієнти піднімали розмову щодо продуктивності бази даних та управління базою даних як би то не було щоденного обговорення на відміну від чисто технічних? І я знаю, що ви згадали раніше про те, що переважно ви розмовляєте з DBA, але чи існує зараз така тенденція, коли вона є загальною лексикою, чи бачите ви людей, де вони обговорюють ці теми, на відміну від просто вундеркіндів?
Буллет Манале: Ну це важко сказати. Я маю на увазі, як я вже говорив здебільшого, люди, з якими ми маємо справу з точки зору процесу продажу, - це практикуючі, які є DBA. Отже, з точки зору вашого запитання ви просто говорите: "З точки зору людей, що знаходяться в ІТ-організації, вони все більше розуміють базу даних?" Я думаю, це питання, і я б сказав, ймовірно, відповідь "так". Я, мабуть, не бачу цього настільки, виходячи з того, де я перебуваю, щодня, але я думаю, якщо я розумію ваше запитання, це була б моя відповідь.
Дез Бланчфілд: Так, це нормально. Це, мабуть, завантажене питання, вибачте, адже, очевидно, ваші переважні інтереси у вашому світі - це технічна сторона речей. Мені цікаво, що в своїй щоденній діяльності я бачу, як організації дуже рано починають вносити це в розмову. Тож, коли вони говорять про нові ініціативи, нові проекти, нові програми роботи, одна з речей, яка приходить негайно, - це "як ми моніторимо її, як ми відстежуємо її, як вирішуємо питання, коли вони виникають" на відміну від запуску, виходу наживо? "
Буллет Манале: Я б сказав, що -
Дез Бланшфілд: Вибачте, продовжуйте.
Буллет Манале: Я збирався сказати, що я бачу тенденцію, яку, мабуть, варто сказати - ви знаєте, багато разів у минулому ви отримували: "У нас були проблеми, і тому зараз нам потрібен інструмент. " І я думаю, що ми бачимо трохи більше прийняття щодо того, щоб мати інструмент на місці до того, як проблема виникне, якщо це має сенс. Тож я б сказав, що це, безумовно, стає більш нормальним, щоб бути, ви знаєте, "Ей, нам потрібен інструмент моніторингу, нам потрібно щось". І люди, безумовно, бачать цінність цього продукту, тому що, як ви сказали раніше, просто додаючи DBA та додаючи нові екземпляри, вам потрібно щось, що управляє цим. Вам потрібно щось, що допомагає в управлінні цим, і тому ми також бачимо багато сприйняття навколо цього продукту, або у нас є.
Dez Blanchfield: Швидке запитання. Де це потрібно жити? Чи повинен він сидіти прямо на задньому опіку в локальній мережі, в центрі обробки даних, як можна ближче до середовищ бази даних, чи зручно розміщувати його десь, потенційно в хмарі, стороннє хмара з якоюсь формою або тунель VPN, або віддалений доступ до різних середовищ? Де це потрібно сидіти, що стосується навколишнього середовища та моніторингу?
Bullett Manale: З точки зору архітектури є резервне сховище, і це база даних SQL Server. У нас є консоль, яка може бути товстим клієнтом, або тонким клієнтом; ми надаємо вам можливість обох. А ще у нас є тонкий клієнт, який дійсно орієнтований саме на мобільні пристрої. Але з точки зору, де це може насправді сидіти; він може сидіти в оточенні, насправді складніше в цьому, оскільки багато інформації, яку нам потрібно зібрати, вимагає адміністративних прав, в деяких випадках або в багатьох випадках. Тепер ми не змушуємо вас це робити; якщо ви хочете, ви можете збирати дані і тільки для речей, які ми не можемо зібрати, оскільки ми не маємо прав адміністратора, ми просто дозволимо вам не бачити цю інформацію, якщо це вибір.
Залежно від аромату, наприклад, якщо ви говорите про AWS, деяких середовищах, це працює краще, ніж інші, але що стосується власне середовища, як правило, або використовуючи автентифікацію SA для збору даних проти екземплярів, все, що потрібно. Або якщо це недостовірний домен, зазвичай це потрібно, коли ви хочете це зробити, але кілька доменів; доки між ними існує довіра, ми можемо збирати проти них. Насправді не важливо, чи це в локальній мережі, чи в мережі WAN, сама фактична колекція є досить незначною з точки зору кількості даних, які ми збираємо. Якщо у нас є достатній розмір WAN-з'єднання, це не проблема. Я бачив середовища, де у них є відділення, де є сервери SQL по всій території США. І це один сервер на кожному з цих різних місць, і вони контролюють його централізовано. Хитра частина - це просто переконатись у тому, що у вас є пристойний об'єм зв'язку. Сподіваємось, це відповість на ваше запитання, все було на всій карті.
Дез Бланшфілд: Так, абсолютно. Дякую. Отже, два швидких запитання, які надійшли через присутніх сьогодні вранці; одне: що таке вплив - часто ми бачимо, що інструменти системного моніторингу створюють навантаження, просто відстежуючи речі, тому питання було, вибачте, це зараз прокручується з мого екрану, але просто перефразовуючи це; контролюючи, чи ми створюємо навантаження самі? Чи є вимірюваний вплив інструменту, просто спостерігаючи за навколишнім середовищем, чи це незначний вплив?
Bullett Manale: Завжди завжди буде невеликий вплив, оскільки він повинен запитувати екземпляр SQL Server, щоб повернути дані. Питання, як ви сказали: "Чи це мізерно мало чи важливо?" З поля, на яке ви вказуєте екземпляр, це незначно. Ми робимо це, як я вже сказав, досить давно. У нас понад 20 000 клієнтів, і я можу запевнити, що якщо це спричинить значний вплив на ефективність роботи, ми б не працювали. Зважаючи на це, ми також дозволяємо користувачеві вирішувати, що вони хочуть контролювати. Тож я думаю, що важливо сказати, що кожне середовище дещо інше.
Прикладом може бути те, що компонент моніторингу запитів - одна з речей, яку ми можемо зробити, - це ми можемо встановити поріг того, що ви вважаєте своєю межею нормальності. Тож це могло б базуватися на часі виконання запиту. Це може бути засноване на процесорі, вводу / виводу, але, як приклад, скажімо, що я встановив час виконання нуля мілісекунд. Ефективно те, що я кажу інструменту, це зібрати всі запити, які запускалися з останнього інтервалу тягнення, і зробити цю частину моєї історичної колекції.
Тепер, коли ми це зробимо, ми збираємо будь-яку кількість запитів, які ми виконували у вікні з часу останнього опитування. Тепер це вибір, і користувач має можливість це робити. Ми говоримо: "Це те, що ви повинні зробити?" Ні. Але ми також надаємо вам можливість зробити це у випадку, якщо ви хочете зразок даних, що дозволяє збирати цю інформацію. Отже, загалом кажучи, у вас є кошти в межах інструмент, щоб налаштувати його і налаштувати саме так, як ви хочете, виходячи з того, що вам зручно. Але у вас є можливість дійсно відкрити його, якщо ви хочете, і зібрати багато додаткової інформації, яка вам не обов'язково регулярно збирати, якщо це має сенс.
Дез Бланчфілд: Так, абсолютно. Я знаю, що ми біжимо трохи довше, але є два справді чудових питання, які я хочу кинути на тебе, перш ніж я завершу. Вони обидва приходять безпосередньо до мене, але я думаю, що найкраще, якщо ти їм відповідеш. Питання, як правило, полягало в тому, "Яка сфера дії інструменту стосується знань про існуючі системи?" Тож ми можемо просто підключити це, і чи зможе він автоматично визначити ту платформу, яка є там, і знати, що нормально для цієї платформи, і негайно Деякі основні знання платформ, вкладаючи, знаєте, я не знаю, це може бути Microsoft Dynamics. Яка сфера знань платформи з тим, що нормально і що в деяких з поточних інструментів, які використовуються в бізнесі?
Bullett Manale: Я б сказав, що, загалом кажучи, коли ми починаємо збирати дані про екземпляр SQL, ми працюємо з найкращими методами, для початку, з точки зору наших порогових значень та того, де вони встановлені. Зважаючи на це, ми також визнаємо, що з ким ви спілкуєтесь, з точки зору кращих практик, кожне середовище відрізняється. Що ми будемо робити спочатку, ми просто збираємо дані, і що ми радимо людям робити, ви можете спробувати продукт на 14 днів довше, якщо вам потрібно. Але приблизно через два дні ви почнете бачити заповнення базових даних. Як тільки у нього буде достатньо зразкової інформації, з якою можна працювати, тоді вона почне надавати вам контекст з точки зору базової лінії, де знаходиться діапазон, і всі подібні речі. Тоді звідти, якщо ви хочете, ви можете автоматично встановити ваші пороги з тієї зібраної інформації. Потрібно трохи почати збір та опитування, щоб можна було почати визначати, що є нормальним, щоб ви могли почати зміщувати свої пороги.
Але, на мою думку, варто також зазначити, що коли ви змінюєте ці пороги, це можна зробити по групі за групою ваших примірників. Це може бути конкретним для одного екземпляра, або ви можете зробити це проти всіх ваших примірників, а також можливість створювати такі речі, як шаблони, щоб ви могли сказати: "Це виробничий екземпляр, але це шаблон, який я хочу призначити його ". І тому, коли новий примірник виробництва з’являється в Інтернеті, ми автоматично застосовуємо ці пороги до нього, оскільки він має один і той же тип апаратного забезпечення, і він, як правило, має однакові робочі навантаження, тож ми зможемо зробити це і таким чином. Сподіваємось, це допомагає з точки зору питання.
Дез Бланшфілд: Так, абсолютно. Насправді ви насправді відповіли на ще одне запитання, яке щойно прийшло до мене, і це було: "Чи є пробне завантаження?" Я можу відповісти на це, я знаю. Я впевнений, ви підтвердите, що є безкоштовне завантаження, і я думаю, ви сказали, що це було 14 днів із веб-сайту. Ви можете завантажити його і пограти з ним. Думаю, просто швидко з цим: "Яке середовище мені потрібно, щоб мати змогу запустити пробну версію? Чи можу я запустити його на своєму ноутбуці та пограти з ним чи мені справді потрібен сервер?"
Bullett Manale: Головне, що йому потрібно, - це сховище, база даних SQL Server 2005 або вище. Крім цього, є деякі мінімальні потреби в ресурсах, вимога .NET, і все. Отже, це лише питання встановлення продукту та створення бази даних.
Дез Бланчфілд: Ідеально. Останнє запитання, яке я вам накину, тому що зараз у нас просто час, але швидко близько двох-трьох людей запитували мене: "Чи потрібно мені бути DBA, щоб насправді можна було встати і бігти з це, і грати з цим? "
Bullett Manale: Ні. Я б сказав, що якщо ви DBA, ви будете використовувати різні інструменти. Я маю на увазі, якщо ви досвідчений DBA, мабуть, буде трохи більше цінності. Ви збираєтеся побачити набагато більше глибини інструменту, яким ви могли б скористатися. Але також як новий DBA або навіть людина, яка, це не DBA, у нас є багато рекомендацій, і я зараз на цій сторінці. Ці рекомендації будуть надходити регулярно, і дійсно приємна річ щодо рекомендацій - це вони надають вам причини, чому рекомендації складаються. Але на додаток до цього вони також матимуть посилання на зовнішній контент, які детальніше описують причини, через які ці рекомендації також робляться. Отже, це посилання на зовнішні веб-сайти, блоги та всі подібні речі Microsoft, такі зовнішні.
Але, щоб відповісти на ваше запитання, це щось на зразок, ви знаєте, якщо ви старший DBA, тут буде щось, ви, ймовірно, скористаєтесь цим, що ви, ймовірно, не стали б початківцем DBA. Але в той же час це і своєрідний інструмент навчання, тому що, переглядаючи ці рекомендації, ви почнете самостійно збирати деякі з цих речей, використовуючи рекомендації.
Dez Blanchfield: Фантастичний. Дякую. Мені дуже сподобалася демонстраційна частина. Презентація була чудовою. Демо було фантастичним. Швидко з пам’яті на вашому веб-сайті є цілий ресурсний центр, який рекомендую людям також оглянути. Я пам’ятаю, як проходив у минулу ніч, щоб отримати детальну інформацію. У вас є ціла низка речей, лише від ваших блогів, даних та розмов до пам’яті, ви також отримали більшість документації щодо своїх продуктів в Інтернеті, так?
Bullett Manale: Так, це правильно, і форму, на яку я думаю, що ви посилаєтесь, це веб-сайт community.idera.com. І тоді я хотів би згадати ще одне, про що раніше ви запитували: "Чи буде це визнавати довкілля?" Щодо нових екземплярів чи додавання екземплярів, у нас є ще один інструмент, який дозволяє виявити екземпляри. І це все про інвентаризацію та управління вашим інвентарем. Я просто націлю вас у цьому напрямку на предмет фактичного виявлення випадків. Але що стосується насправді продуктивності та моніторингу, то все, про що ми говорили, саме тут розпочнеться дія Діагностичного менеджера.
Dez Blanchfield: Фантастичний. Дивіться, чудове покриття. Дуже сподобалась ваша презентація. Полюбила демонстрацію в прямому ефірі, і це все від мене сьогодні вранці, оскільки я знаю, що ми пішли, мабуть, за 10 хвилин. Еріку, я повернуся до тебе.
Ерік Кавана: Добре. Я просто любив демо. Я радий, що ви зробили демонстрацію. Я радий, що ми повинні приємно поглянути на це, коли ми пройшли питання Q&A.
Bullett Manale: Чудово .
Ерік Кавана: Тому що це дає людям уявлення про те, на що ти дивишся, і насправді це мене дивує, думаючи, що ми все ще вчимося, як розмовляти з цими комп'ютерами, коли ви переходите до цього. Я маю на увазі, цей рівень діагностики досить складний, і з кожним днем він стає кращим. Ми отримуємо набагато більше розуміння того, що насправді відбувається. Але вам справді потрібна людина, яка оглядає цей матеріал, читає його, ставлячи цю пізнавальну здатність за те, що ви робите, правда?
Bullett Manale: Так, я маю на увазі у багатьох випадках - я хотів би сказати вам, що це DBA у полі, але там надто багато речей. Я маю на увазі, ми надаємо вказівки і допомагаємо, але в кінці дня це вимагає від людей, які приймають рішення щодо даних, які ми представляємо. Я не думаю, що це скоро зміниться.
Ерік Кавана: Ну, це хороші новини для реальних людей, люди.
Bullett Manale: Правильно.
Ерік Кавана: Ви хочете, щоб хтось спостерігав за цим, команда, яка спостерігала за цим, і ви дізнаєтесь, як ви чули від Буллетта, дивлячись на ці рекомендації, що ви збираєтеся підбирати те, що відбувається. І я здогадуюсь з тієї історії, і я думаю, що ти торкнувся цього, Буллетт, але дуже швидко, що історія дозволяє розпізнати значущі закономірності, а потім зможеш ідентифікувати їх, коли вони відбудуться в майбутньому, правда?
Bullett Manale: Це правильно. Одне з тих, що ми можемо зробити - це відстежувати ефективність запиту в часі. Ми також можемо очевидно дивитись на інші речі, як-от базові лінії, і бачити, як вони змінюються, і, очевидно, отримувати сповіщення та подібні речі, коли це відбувається, тож ви, безумовно, маєте таку можливість.
Ерік Кавана: Це добре звучить, люди. Ми б тут не давно були, але я хотів перейти до цих питань. Дуже дякую за ваш час та увагу. Ми робимо архів всіх цих трансляцій. Перейдіть через Інтернет на Techopedia.com або на InsideAnalysis.com, ви побачите посилання з обох місць.
І з цим ми вітаємо вас. Ще раз дякую, люди, ми наздоженемо вас наступного тижня, ще три веб-трансляції наступного тижня, вівторок, середа, четвер. Тож ми поговоримо з вами на наступному тижні, люди. Піклуватися. Бувай.
Партнер з вмісту Techopedia
Персонал Techopedia пов'язаний з Bloor Group і з ним можна зв’язатися, скориставшись опціями праворуч. Для отримання інформації про те, як ми працюємо з галузевими партнерами, натисніть тут.- Профіль
- Веб-сайт
