Співробітники компанії «Техопедія», 19 квітня 2017 року
Винос: Ведучий Ерік Кавана обговорює прогнозування з докторами Робіном Блором, Ріком Шерманом та програмою Bullett Manale від IDERA.
Ви повинні зареєструватися для цієї події, щоб переглянути відео. Зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Дами та панове, привіт ще раз, і ласкаво просимо повернутися до веб-трансляції серії Hot Technologies! Мене звуть Ерік Кавана, я буду вашим господарем сьогоднішнього веб-семінару під назвою "Економити час, гроші та проблеми з оптимальними прогнозами". "Звичайно, я пропустив першу частину заголовка там, " Найкращі планові плани ". завжди говорити про це на цьому шоу. Отже, Hot Technologies - це, звичайно, наш форум для розуміння того, що деякі круті продукти є сьогодні у світі, світ технологій підприємств, що люди роблять з ними, як вони працюють, і все таке цікаве.
І тема сьогодні, як я пропоную, стосується прогнозування. Дійсно, ви намагаєтесь зрозуміти, що буде у вашій організації. Як ви збираєтеся підтримувати своїх користувачів щасливими, незалежно від того, що вони роблять? Якщо вони роблять аналіз, якщо вони роблять реальну роботу, вони стикаються з реальними клієнтами з транзакційними системами, незалежно від конкретного випадку, ви хочете зрозуміти, як працюють ваші системи і що відбувається, і це ми ' Поговоримо сьогодні. Це щось смішно, тому що прогнозування - це не те, що я люблю робити, тому що я забобонний, як я думаю, якщо я прогнозую занадто багато, погані речі трапляться, але це тільки я. Не слідкуйте за моїми поводами.
Отже, ось наші сьогодні ведучі, ваші справді у верхньому лівому куті, Рік Шерман набирає номер з Бостона, наш приятель Буллетт Манале з IDERA і наш власний доктор Робін Блор. І з цим я передам це Робіну і просто нагадаю людям: Задайте питання, не соромтеся, ми любимо хороші запитання, ми їх сьогодні викладемо нашим ведучим та іншим. І з цим, Робіне, забирай це.
Робін Блор: Гаразд, тому що, як вони кажуть, я думав, що сьогодні розповім історію SQL, тому що це фон для того, що триває дискусія, і вона неминуче не зіткнеться з тому що Рік не зосереджується на цьому, і не зіткнеться з тим, що має сказати Рік. Отже, історія SQL, є кілька цікавих речей про SQL, оскільки вона настільки домінуюча. Дивіться, це помилка друку, SQL - це декларативна мова. Ідея полягала в тому, що ви можете створити мову, якою ви будете запитувати те, чого хочете. І база даних розробила б, як її отримати. Насправді це все досить добре, але є ряд речей, про які варто сказати про це, наслідки, що базують всю ІТ-індустрію на декларативній мові. Користувач не знає і не піклується про фізичну організацію даних, і це добре в декларативній мові - вона відокремлює вас від усього цього і навіть переживає про це - просто запитайте все, що вам потрібно, і базу даних піде і дістане.
Але користувач не має уявлення, чи спосіб їх структурування SQL-запиту вплине на ефективність запиту, і це трохи недоліки. Я бачив запити завдовжки сотень і сотень рядків, які є лише одним запитом SQL, ви знаєте, починається з "select" і просто продовжується і продовжується з підзапитів і так далі і так далі. І насправді виявляється, що якщо ви хочете певний збір даних із бази даних, ви можете попросити його різними способами з SQL і отримати таку саму відповідь, якщо ви начебто ознайомитесь з даними. Отже, один SQL-запит не обов'язково є найкращим способом запиту даних, і бази даних відповідатимуть зовсім інакше відповідно до SQL, який ви вводите до них.
Отже, SQL насправді впливає на продуктивність, тому люди, які використовують SQL, це правда для них, це також стосується програмістів SQL, які використовують SQL, і вони ще менше думають про вплив, який вони матимуть, тому що більшість їх фокусується саме на маніпулюванні даними, а не на отриманні та передачі даних. І те ж саме стосується і інструментів BI, я бачив, що SQL, який, якщо вам подобається, видаляє з BI-інструментів різних баз даних, і треба сказати, що багато цього є, ну, я б не хотів ' не пишіть такі запити SQL. Це хтось створив, якщо ви хочете, маленький мотор, що якими б не були параметри, він викине деякі SQL, і знову ж таки, що SQL не обов'язково буде ефективним SQL.
Тоді я подумав, що згадаю невідповідність імпедансу, дані, які використовують програмісти, відрізняються від даних, які вони сортують. Отже, наші DMS зберігають дані в таблицях, організований об'єктно-орієнтований код - це здебільшого кодери, в даний час програмують об'єктно-орієнтовану форму і вони впорядковують дані в об'єктних структурах, тому він не відображає одне до іншого. Отже, необхідно перекласти з того, що програміст вважає, що дані є тим, що база даних думає, що це за дані. Що здається, ми повинні були зробити щось не так, щоб це було так. У SQL є DDL для визначення даних, у нього є DML - мова маніпулювання даними - вибирайте, проектуйте та приєднуйтесь для отримання цих даних. Зараз дуже мало математики і дуже мало часу, тому це недосконала мова, хоча слід сказати, що вона продовжена і продовжується.
І тоді, ви отримуєте проблему SQL-бар'єру, яка завжди виразніше діаграми, але багато людей задавали питання з аналітичних причин, як тільки вони отримали відповідь на умови запитання, хочуть задати інше запитання. Отже, це стає діалогічною річчю, ну SQL не був побудований для діалогів, він був побудований для того, щоб запитати, що ви хочете, всі відразу. І це варто щось знати, оскільки там є деякі продукти, які фактично відмовляються від SQL, щоб зробити можливою розмову між користувачем та даними.
Що стосується продуктивності бази даних - і цей вид поширюється на все - так, є процесор, є пам’ять, є диск, є мережеві накладні витрати і є проблема блокування більшої кількості людей, які бажають ексклюзивно використовувати дані в заданий момент часу. Але є і погані дзвінки SQL, є дуже багато, що можна зробити, якщо ви оптимізуєте SQL з точки зору продуктивності. Отже, фактори продуктивності бази даних: поганий дизайн, поганий дизайн програми, паралельність завантаження роботи відсутня, балансування навантаження, структура запитів, планування потенціалу. Це зростання даних. І кількома словами, SQL є зручним, але він не самооптимізується.
Сказавши це, я думаю, ми можемо перейти до Ріка.
Ерік Кавана: Гаразд, Рік, дозволь мені передати вам ключі від машини WebEx. Відняти її.
Рік Шерман: Добре, чудово. Ну дякую Робін, як ми почали на початку презентації, моя графіка все ще досить нудна, але ми підемо з цим. Отже, я погоджуюся з усім, про що Робін говорив на стороні SQL. Але на чому я хочу трохи зосередитись - це попит на дані, який ми пройдемо дуже швидко, пропозиція як в інструментах, що використовуються в цьому просторі, чи потреба в інструментах цього простору.
По-перше, у кожній прочитаній статті є щось, що стосується великих даних, безлічі даних, неструктурованих даних, що надходять із хмари, великих даних скрізь, які ви можете собі уявити. Але зростання ринку баз даних постійно спостерігається за допомогою SQL, реляційна база даних, можливо, станом на 2015 рік, все ще становить 95 відсотків ринку баз даних. Три кращі реляційні постачальники мають близько 88 відсотків частки ринку в цьому просторі. Отже, ми все ще говоримо, як говорив Робін, про SQL. І насправді, навіть якщо ми дивимось на платформу Hadoop, Hive and Spark SQL - якою мій син, який є вченим даними, весь час використовує - це, безумовно, домінуючий спосіб для людей отримати доступ до даних.
Тепер на базі даних є дві широкі категорії використання баз даних. Перша - це система управління операційними базами даних, тому планування відносин з підприємствами, комплектування відносин із клієнтами, ERPs Salesforce, Oracles, EPIC, N4s тощо. І ось, у сховищах даних та інших системах, що базуються на бізнес-аналітиці, існує широкий обсяг даних, що розширюються. "Тому що все, незалежно від того, де і як воно захоплюється, зберігається чи здійснюється транзакція, з часом аналізується, і тому існує величезний попит та збільшення використання баз даних, особливо реляційних баз даних на ринку.
Зараз ми отримали попит, надходить величезна кількість даних. І я насправді не кажу лише про великі дані, я про використання даних на всіляких підприємствах. Але супроводжуючи це тим, що з боку пропозиції, для людей, які можуть керувати цими ресурсами, ми спочатку маємо дефіцит DBA. За даними Бюро статистики праці, з 2014–2024 рр. Робочі місця DBA збільшаться лише на 11 відсотків - тепер це люди, які мають посади DBA, але про це ми поговоримо за секунду - проти 40- плюс відсоток річного простору даних. І у нас багато DBA; в середньому те саме дослідження говорило про середній вік досить високий порівняно з іншими ІТ-професіями. І тоді у нас багато людей виходять з поля, не обов’язково виходячи на пенсію, а переходячи на інші аспекти, переходячи до управління, чи будь-чого іншого.
Тепер частина причини, яку вони залишають, полягає в тому, що робота DBA стає все складніше і складніше. По-перше, у нас є DBA, які керують багатьма різними базами даних, фізичними базами даних, розташованими всюди, а також різними типами баз даних. Тепер це може бути реляційним, а можуть бути й інші бази даних, типи баз даних. Але навіть якщо це стосунки, вони можуть мати будь-якого одного, двох, трьох, чотирьох різних постачальників, якими вони насправді намагаються керувати. DBA зазвичай включаються після створення бази даних або програми. Робін розповів, як розробляються бази даних або програми, як розробляється SQL. Ну а коли ми говоримо про моделювання даних, моделювання ER, розширене моделювання ER, моделювання розмірів, вдосконалене розмірне моделювання, що завгодно, як правило, програмісти прикладних програм та розробники додатків розробляють з метою їх кінцевої мети - вони не розробляють для підвищення ефективності сама структура бази даних. Тож у нас багато поганого дизайну.
Зараз я не говорю про продавців додатків для комерційних підприємств; зазвичай вони мають моделі ER або розширені моделі ER. Я говорю про те, що розробники додатків створюються набагато більше бізнес-процесів та додатків у кожній компанії - саме ті не обов'язково розроблені для ефективності та ефективності розгортання. І самі DBA перевантажені роботою, і вони несуть відповідальність 24/7, вони постійно отримують все більше і більше баз даних. Я думаю, що це трохи зробило те, що люди не зовсім розуміють, що вони роблять, або як вони це роблять. Їх власна маленька група і люди просто думають: "Ну всі ці інструменти просто такі прості у використанні, ми можемо просто продовжувати набирати все більше і більше баз даних на їх робочому навантаженні", що не так.
Це призводить нас до неповних та випадкових DBA. У нас є ІТ-команди, які невеликі, і вони не можуть дозволити собі виділити спеціальну DBA. Тепер це стосується малого та середнього бізнесу, де розширення програм та баз даних вибухнуло за останнє десятиліття та продовжує розширюватися. Але це також стосується великих корпорацій, як правило, тривалий час займаються зберіганням даних, аналітикою бізнес-аналітики. Здавна ми отримували спеціальні DBA для цих проектів; ми ніколи більше не отримуємо виділених DBA. Ми відповідаємо за розробку бази даних, що добре, якщо хтось має досвід. Але в цілому DBA є розробниками додатків, вони часто беруть цю роль як частину своєї роботи, вони не мають офіційної підготовки до неї, і знову, вони розробляють це для своїх кінцевих цілей, вони не проектуючи це для підвищення ефективності.
І між дизайном і розробкою існує велика різниця, а не розгортання та управління. Отже, у нас є "копійки мудрі, нерозумні фунти", з маленькою скарбничкою, яка переходить до отримання необхідних навичок та ресурсів для проектів. Думаючи, що всі походять з "Помста бородавок", моя маленька картинка там. Тепер, що стосується того, що потрібно людям, то ми маємо все ширше використання баз даних і даних у SQL. У нас обмежена кількість DBA - людей, які є кваліфікованими та досвідченими в цих налаштуваннях, розробці та управлінні та розгортанні ситуацій. І у нас все більше і більше випадкових або випадкових DBA, людей, які не пройшли офіційне навчання.
Отже, які ще є інші речі, які також вступають у питання про те, що ці бази даних також не налаштовані або керуються ними? По-перше, багато людей припускають, що в самій системі баз даних є достатньо інструментів для управління ними. Тепер інструменти стають простішими та простішими - розробка та розробка, - але це відрізняється від того, щоб зробити хороший дизайн та добре керувати, планувати потужність, моніторинг тощо для розгортання. Отже, спочатку люди припускають, що у них є всі необхідні інструменти. По-друге, якщо ви неповний робочий день або випадковий DBA, ви не знаєте, чого не знаєте.
Напевно, я забув деякі фрази там, так що багато разів вони просто не розуміють, що їм навіть потрібно дивитись в дизайні або коли вони керують або керують базами даних. Якщо це не ваша професія, то ви не збираєтесь розуміти, що вам потрібно робити. По-третє, це те, що SQL - це інструмент, що рухається, тому Робін говорив про SQL і про те, як погано SQL іноді будується або часто будується. А також одним із моїх вихованців, що займається зберіганням даних BI, міграцією даних, простором інженерії даних, є те, що замість використання інструментів люди мають тенденцію писати SQL-код, що зберігаються процедури, навіть якщо вони використовують дорогий інструмент інтеграції даних або дорогий інструмент BI, вони часто дійсно використовують його просто для запуску збережених процедур. Так що важливість розуміння дизайну баз даних, побудови SQL стає все більш важливою.
І нарешті, є такий силосний підхід, в якому ми бачимо, як окремі люди переглядають окремі бази даних. Вони не дивляться на те, як працюють програми та взаємодіють між собою. Вони також дійсно часто переглядають бази даних порівняно з програмами, для яких вони використовують. Отже, навантаження, яку ви отримуєте в базі даних, є критично важливою для дизайну, критичною в налаштуванні її, критичною при спробі розібратися, як планувати потужність тощо. Отже, дивлячись на ліс з дерев, люди перебувають у бур'янах, дивлячись на окремі таблиці та бази даних і не дивлячись на загальну взаємодію цих додатків у робочому навантаженні.
Нарешті, людям потрібно подивитися на ключові сфери, на які вони повинні дивитися. Коли вони планують керувати базами даних, їм потрібно спочатку подумати про те, розробити деякі показники продуктивності, орієнтовані на додатки, тому вони повинні дивитися не лише на те, як структура цієї таблиці, як вона особливо моделюється, а як вона використовується? Отже, якщо у вас є корпоративна програма, яка належить до управління ланцюгами поставок, якщо ви знімаєте замовлення в Інтернеті, якщо ви робите BI - що б ви не робили - вам потрібно подивитися, хто ним користується, як вони використовуючи його, якими є обсяги даних, коли це станеться. Те, що ви насправді намагаєтеся шукати, - це терміни очікування, тому що незалежно від того, всі додатки оцінюються за тим, скільки часу потрібно, щоб щось зробити, будь то людина чи просто обмін даними між додатками чи процесорами. А які вузькі місця? Тому часто, коли ви намагаєтеся налагоджувати проблеми, звичайно, ви дійсно намагаєтесь подивитися на те, що є справжніми вузькими місцями - не обов’язково, як налаштувати все, але як ви позбудетесь та перемістите продуктивність до часу очікування і пропускна здатність - все, що вам потрібно подивитися.
І вам дійсно потрібно відокремити захоплення даних, транзакції, аспекти перетворень у базі даних разом з аналітикою. Кожен з них має різні шаблони дизайну, кожен з них має різні схеми використання, і кожен з них повинен бути налаштований по-різному. Отже, вам потрібно подумати про те, як ці дані використовуються, коли вони використовуються, для чого вони використовуються, і розібратися, які показники ефективності та які ключові речі, які ви хочете проаналізувати, пов’язані з цим використанням. Тепер, дивлячись на моніторинг продуктивності, ви хочете переглянути самі операції з базою даних; Ви хочете переглянути обидві структури даних, тому індекси, розділення та інші фізичні аспекти бази даних, навіть структура бази даних - будь то модель ER чи розмірна модель, проте вона структурована - всі ці речі впливають на продуктивність, особливо в різних контекстах аналітики збору даних та трансформацій, що відбуваються.
І як згадував Робін на стороні SQL, дивлячись на SQL, який управляється цими різними додатками в цих базах даних, і налаштування його є критичним. А також дивлячись на загальну завантаженість додатків та інфраструктурне середовище, на якому працюють ці бази даних та програми. Отже, що мережі, сервери та хмара - що б вони не працювали - також дивляться на вплив, який ці програми та ці бази даних мають у цьому контексті, все це взаємодіє з можливістю налаштування бази даних.
І нарешті, дивлячись на інструменти, ви хочете мати змогу переглянути три різні види аналітики, пов'язані з цим. Ви хочете переглянути описовий аналіз: що відбувається і де, пов’язаний з базою даних та продуктивністю програми. Ви хочете мати можливість робити діагностичну аналітику, щоб з’ясувати не тільки те, що відбувається, але чому це відбувається, де вузькі місця, де проблеми, що добре працює, що не працює добре? Але вміти аналізувати та деталізувати проблематичні місця, щоб вирішити їх, будь то для дизайну чи того, що вам потрібно зробити.
І нарешті, найбільш агресивним чи ініціативним типом аналізу є фактично робити якийсь прогнозний аналіз, моделювання прогностичної аналітики, будь-що. Ми знаємо, що база даних та додатки працюють у цьому контексті, якщо ми збільшили потенціал, якщо ми отримаємо більше користувачів, якщо ми зробимо більше пропускної здатності, що б ми не робили, змогли спроектувати, що, як і де це буде Вплив на базу даних, додатки, дозволяє нам планувати і визначати, де саме існують вузькі місця, де можуть страждати терміни очікування і що нам потрібно зробити, щоб виправити щось. Тому ми хочемо мати інструменти, які здатні реалізовувати показники ефективності, контролювати ефективність, як це роблять у цих трьох типах аналізу. І це мій огляд.
Ерік Кавана: Добре, дозвольте передати це - до речі, це дві чудові презентації - дозвольте передати це Буллетту Манале, щоб забрати його звідти. А люди, не забудьте поставити хороші запитання; у нас вже є хороший зміст. Забирай це, Буллет.
Bullett Manale: Звучить добре. Спасибі, Еріку. Отже, багато того, що сказав Рік і сказав Робін, очевидно, я згідний на 100 відсотків. Я б сказав, що я підтягнув цей слайд вгору, тому що я думаю, що він підходить, я не знаю для тих із вас, хто є фанатами "команди" ще в 80-х, Джон Ганнібал Сміт говорив, що завжди скажіть: "Мені це подобається, коли складається план", і я думаю, що, коли ви говорите саме про SQL Server, саме там ми зосереджуємось, це продукт, про який ми сьогодні поговоримо, SQL Diagnostic Manager - це, безумовно, одна з тих речей, які вам доведеться мати; ви повинні мати можливість використовувати дані, які у вас є, і вміти приймати рішення з цих даних, а в деяких випадках ви не шукаєте рішення; ти шукаєш щось, щоб сказати тобі, коли щось втрачає ресурси, коли у тебе закінчуватиметься ресурси, коли у тебе буде вузьке місце, такі речі.
Йдеться не лише про моніторинг конкретної метрики. Отже, з діагностичним менеджером, одна з речей, яка дуже добре працює, - це допомогти вам у плані прогнозування та розуміння конкретних навантажень, і ми сьогодні поговоримо про багато про що. Інструмент орієнтований на менеджера даних, DBA або діючого DBA, тому багато речей, про які Рік згадував, діючу DBA так правдиво. У багатьох випадках, якщо ви не DBA, у вас буде багато знаків запитання, які ви матимете, коли настане час керувати середовищем SQL - речі, які ви не знаєте. А значить, ви шукаєте щось, що допоможе вам, проведе вас через цей процес, а також навчить вас у цьому процесі. І тому важливо, щоб інструмент, який ви використовуєте для таких рішень, дав вам деяке розуміння причин, через які ці рішення приймаються, це не просто сказати вам: «Ей, роби це».
Оскільки я є діючим DBA, врешті-решт я можу стати повноцінним DBA з фактичним досвідом та знаннями, щоб підтримати цей титул. Отже, це було сказано, коли ми говоримо про те, щоб бути адміністратором бази даних - я завжди на початку показую цей слайд, тому що DBA має деякі різні ролі, і залежно від організації, з якою ти працюєш, ти будеш мати, вони змінюватимуться від одного місця до іншого, але, як правило, ви завжди будете якимось чином нести відповідальність за ваше сховище, ваше планування цього сховища та розуміння того, як передбачити, скільки місця ви збираєтеся потрібно, чи це для ваших резервних копій, чи для самих баз даних. Вам потрібно буде це зрозуміти і оцінити.
Крім того, вам потрібно буде вміти розуміти та оптимізувати речі за потребою, а під час моніторингу навколишнього середовища, очевидно, важливо вносити зміни, як вони потрібні, ґрунтуючись на речах, які зміни всередині самого середовища. Отже, такі речі, як кількість користувачів, такі як популярність програм, сезонність бази даних, все слід враховувати, коли ви робите прогнозування. А потім, очевидно, дивлячись на інші речі з точки зору можливості надання звітів та необхідної інформації, що стосується прийняття цих рішень. У багатьох випадках це означає порівняльний аналіз; це означає, що ви зможете розглянути конкретний показник і зрозуміти, яке значення цього показника минуло з часом, щоб ви могли передбачити, куди він рухатиметься вперед.
Отже, що багато інструментів Diagnostic Manager має ці можливості, і люди користуються ним щодня для того, щоб робити такі речі, як прогнозування, і я поставив тут визначення планування потенціалу. І це досить широке і насправді досить розпливчасте визначення, яке є лише процесом визначення виробничих потужностей, необхідних організації для задоволення мінливих потреб у своїй продукції, і врешті-решт, це справді все. про можливість приймати інформацію, яку ви маєте так чи інакше, і приймати цю інформацію та приймати рішення, які допоможуть вам рухатись вперед під час просування по життєвому циклу ваших баз даних. І так, види речей, які є причинами, через які людям потрібно це робити, очевидно, перш за все, в більшості випадків, щоб заощадити гроші. Очевидно, що це їхня головна мета - заробити гроші та заощадити гроші. Але разом з цим, це також означає можливість переконатися, що у вашому простої немає простоїв. І зможете переконатися, що ви пом’якшите будь-який шанс настання простою, тому не дайте йому початись, інакше кажучи, не чекати, коли це станеться, а потім реагувати на нього.
Очевидно, що, окрім того, що ви зможете загалом збільшити продуктивність своїх користувачів, зробіть їх ефективнішими, щоб можна було більше бізнесу робити, тому це типи речей, які, як DBA або хтось, хто бере участь у прогнозуванні чи спроможності планування повинна мати можливість проникнути через інформацію, щоб мати можливість приймати ці рішення. І тоді, загалом, це, очевидно, допоможе вам позбавити відходів, не лише відходів у грошах, а й з точки зору часу та з точки зору просто загальних ресурсів, які можуть бути використані для інших речей, можливо. Таким чином, можливість утилізувати ці відходи, щоб у вас не було можливих витрат, пов'язаних із самими відходами.
Отже, з урахуванням сказаного, які типи питань, які ми отримуємо, характерні для людини, яка є DBA? Коли мені не вистачить місця? Це велика річ: не тільки скільки місця я споживаю зараз, але коли я збираюся закінчитися, виходячи з тенденцій та минулої історії? Те ж саме з фактичними екземплярами SQL, базами даних, які сервери я можу консолідувати? Я збираюся поставити деякі віртуальні машини, що має сенс з точки зору, в яких базах даних я збираюсь консолідуватись та в яких екземплярах SQL вони повинні перебувати? На всі ці типи питань потрібно відповісти. Тому що в більшості випадків, якщо ви DBA або діючий DBA, ви збираєтесь консолідувати це десь у своїй кар’єрі. У багатьох випадках ви будете робити це постійно. Отже, вам потрібно вміти швидко приймати ці рішення, а не грати в здогадки, коли справа доходить до цього.
Ми говорили про вузькі місця та про те, де вони відбудуться далі, маючи можливість передбачити, що ще раз, замість того, щоб чекати, коли вони відбудуться. Отже, очевидно, що всі ці речі, про які ми говоримо, мають сенс у тому сенсі, що ви покладаєтесь на історичні дані, в більшості випадків, щоб мати можливість генерувати ці рекомендації, або в деяких випадках вміти самостійно формулювати рішення, щоб можна було придумати ці відповіді. Але мені це нагадує те, що коли ви чуєте радіорекламу про те, хто продає цінні папери чи щось подібне, це завжди "минула робота не вказує на майбутні результати" та подібні речі. І те саме стосується і тут. У вас виникнуть ситуації, коли ці прогнози та ці аналізи можуть бути не стовідсотково правильними. Але якщо ви маєте справу з речами, що відбувалися в минулому і відомими, і ви вмієте приймати і робити "що робити" з великою кількістю таких питань, на які ви збираєтеся зіткнутися, дуже цінно і це допоможе вам набагато далі, ніж грати в здогадки.
Отже, ці типи питань, очевидно, збираються підходити, тому, як ми обробляємо багато цих питань з Діагностичним менеджером, насамперед ми маємо можливості прогнозування, маючи змогу зробити це в базі даних, за столом як привід або гучність. Бути в змозі не тільки сказати: "Ей, у нас повно місця", але через півроку, два роки відтепер, п’ять років відтепер, якщо я буду на це бюджету, скільки я забираю місця для бюджету потрібно? Це питання, які мені доведеться задати, і мені потрібно буде мати можливість використовувати якийсь метод цього, а не здогадуватися і піднести палець в повітря і чекати, куди вітер дме, що багато разів, на жаль, так багато, як приймаються ці рішення.
На додаток до цього, бути в змозі - схоже, що мій слайд там трохи відрізали, - але в змозі надати певну допомогу у вигляді рекомендацій. Отже, одна річ - мати змогу показати вам інформаційну панель, сповнену метрик, і бути в змозі сказати: "Добре, ось усі показники і де вони є", але потім мати можливість зрозуміти чи мати певне розуміння що робити, виходячи з цього - ще один стрибок. І в деяких випадках люди достатньо освічені в ролі DBA, щоб мати можливість приймати ці рішення. І тому у нас в інструменті є деякі механізми, які допоможуть у цьому, які ми вам покажемо лише за секунду. Але вміти показати не тільки, що таке рекомендація, а й дати деяке розуміння того, чому ця рекомендація робиться, а потім ще й поверх того, що в деяких випадках, насправді може створити сценарій, який автоматизує вирішення цього питання також ідеально.
Перехід до наступного, який ми побачимо, це просто загальне розуміння до рівня метрики того, що є нормальним. Я не можу сказати тобі, що не нормально, якщо я не знаю, що таке нормально. Отже, маючи певний спосіб виміряти це ключове значення, і ви повинні мати можливість враховувати декілька типів областей, наприклад - або я повинен сказати часові рамки - різних груп серверів, здатних це робити динамічно, з точки зору тривоги, іншими словами, під час ночі, під час мого обслуговування, я очікую, що мій процесор буде працювати на 80 відсотків на основі всього технічного обслуговування. Отже, я можу захотіти підвищити поріг вище, за ті часові рамки порівняно, можливо, посеред дня, коли я не маю такої активності.
Це деякі речі, які, очевидно, будуть екологічними, але це те, що ви можете застосувати до керованого, щоб допомогти вам ефективніше керувати цим середовищем та полегшити це. Інша область, очевидно, здатна просто загалом надавати звіти та інформацію, щоб мати змогу відповісти на такі типи питань "що робити". Якщо я щойно змінив своє оточення, я хочу зрозуміти, що це за вплив, щоб я міг застосувати цю зміну до інших екземплярів чи інших баз даних у моєму середовищі. Я хочу мати змогу мати деяку інформацію чи боєприпаси, щоб мати змогу змінити це з певним спокоєм і знаючи, що це буде хорошою зміною. Отже, будучи здатною робити цю порівняльну звітність, будучи рейтингом моїх примірників SQL, вміючи ранжувати мої бази даних один проти одного, щоб сказати: "Хто є моїм найвищим споживачем процесора?" Або який з них займає найдовше в умови очікування та подібні речі? Тому багато з цією інформацією також буде доступно разом із інструментом.
І тоді, останнє, але не менш важливе, - це просто загальна здатність, що вам потрібен інструмент, який зможе впоратися з будь-якою ситуацією, яка підійде вам, і так, що я маю на увазі під цим, якщо у вас є велике середовище з У багатьох випадках ви, мабуть, зіткнетеся з ситуаціями, коли вам потрібно витягувати показники, які традиційно не є показниками, які DBA хотів би навіть контролювати в деяких випадках, залежно від конкретної ситуації. Отже, маючи інструмент, який ви можете, це розширюється, щоб можна було додавати додаткові показники та мати змогу використовувати ці показники в тій самій формі та способі, що ви використовували б їх, якщо ви використовували нестандартну скриньку метричні, наприклад. Отже, можливість запускати звіти, вміти оповіщати, базові показники - все, про що ми говоримо - також є ключовою частиною того, що можна робити це прогнозування та робити його, щоб ви отримали відповіді, які шукаєте вміти приймати ці рішення, рухаючись вперед.
Тепер, як це робить Diagnostic Manager, ми маємо централізовану службу, групу служб, яка працює, збирає дані від 2000 до 2016 екземплярів. І тоді, що ми робимо, ми беремо ці дані і ставимо їх у центральний сховище, і, очевидно, що ми будемо робити з цими даними, очевидно, чи робимо ми багато для того, щоб дати можливість зрозуміти подальше розуміння Тепер, на додаток до цього - і одне з речей, чого тут немає - це також у нас служба, яка працює посеред ночі, яка є нашою службою прогнозного аналізу, і це робить певну кількість хрускіт, і це допомагає зрозуміти і допомогти вам як DBA або діючий DBA, щоб мати змогу давати рекомендації щодо таких типів, щоб також можна було ознайомитись з базовими поняттями.
Отже, що я хотів би зробити, і це лише швидкий приклад архітектури. Великий винос тут полягає в тому, що тут немає жодних агентів чи служб, які насправді сидять у випадках, якими ви керуєте. Але те, що я хотів би зробити, це просто насправді взяти вас до заявки тут і дати вам швидку демонстрацію. І дозвольте мені просто вийти і зробити це. Отже, дайте мені знати, я думаю, Ерік, чи можете ви це бачити?
Ерік Кавана: Зараз я це зрозумів, так.
Bullett Manale: Гаразд, тому я збираюся вас провести через деякі з цих різних частин, про які я говорив. По суті, давайте почнемо з тих речей, які більше узгоджуються з ось що, що вам потрібно зробити, або ось щось, що є моментом у майбутньому, і ми збираємось дати вам деяке розуміння навколо цього. І це здатне реально передбачити - або я повинен сказати динамічно передбачити - речі, як вони відбуваються. Зараз, у випадку звітів, одним із речей, які ми маємо в цьому інструменті, є три різні звіти прогнозування. У випадку, наприклад, прогнозу бази даних, що я, мабуть, зробив би, коли я міг передбачити розмір бази даних протягом певного періоду часу, і я лише наведу кілька прикладів цього . Отже, я збираюсь взяти мою базу даних аудиту, яка досить інтенсивна вводу / виводу - вона отримує багато даних. У нас є, подивимось, ми це зробимо тут, і давайте просто підберемо тут базу даних про охорону здоров’я.
Але справа в тому, що я не просто бачу, у чому простір, і я можу сказати: "Подивіться, давайте візьмемо минулорічні цінності даних", - і я трохи попростую тут, Я насправді не маю даних за рік, я маю приблизно два місяці даних, але, оскільки тут я вибираю вибірковий показник місяців, я зможу передбачити чи прогнозувати це У випадку наступних 36 одиниць, оскільки наша вибіркова ставка встановлюється місяцями - тобто одиницею, є місяць - і тоді я зможу, щоб потім скласти звіт, щоб в основному показати мені, де ми очікуємо наш майбутній ріст, для цих три бази даних. І ми можемо побачити, що ми маємо різну ступінь різниці або різниці між трьома різними базами даних, зокрема, за кількістю даних, які вони споживають за минулий час.
Ми можемо бачити, що точки даних відображають тут історичні дані, і тоді лінія буде надавати нам прогноз, а також цифри для підтвердження. Тож ми можемо це зробити на рівні таблиці, ми можемо це зробити навіть на рівні приводу, де я можу передбачити, наскільки великі будуть мої накопичувачі, включаючи точки монтажу. Ми зможемо передбачити цей самий тип інформації, але ще раз, залежно від частоти вибірки, я дозволять мені визначити, скільки одиниць і де ми беремо те, що ми хочемо прогнозувати. Зауважте також, що у нас є різні типи прогнозів. Таким чином, ви отримуєте багато варіантів та гнучкості, коли настає час робити прогнозування. Тепер, це одне, що ми зробимо, насправді дамо вам конкретну дату і зможемо сказати: «Ей, в цю дату, саме тут ми могли б передбачити зростання ваших даних». Крім того, ми можемо надамо вам іншу інформацію, пов’язану з деяким аналізом, який ми виконуємо у неробочий час та службою, коли вона працює. Деякі з речей, які він робить, це намагання передбачити те, що, швидше за все, станеться, виходячи з історії того, коли речі відбувалися в минулому.
Тож ми можемо побачити тут, насправді, прогноз дає нам деяке уявлення про ймовірність того, що ми матимемо проблеми протягом вечора, виходячи з речей, що вдруге траплялися в минулому. Отже, очевидно, що це здорово, особливо якщо я не DBA, я можу переглянути ці речі, але що ще краще, якщо я не DBA, це вкладка аналізу. Отже, до того, як це було тут, в інструменті, ми б проходили і показували продукт людям, і вони були б "Це чудово, я бачу всі ці цифри, я все бачу, але не знаю, що робити" (сміється) "В результаті цього". І тому те, що ми маємо тут, - це кращий спосіб ви зрозуміти, чи збираюся я вжити заходів, щоб допомогти у виконанні, якщо я буду вживати заходів до навіть допоможіть здоров’ю мого оточення, будучи в змозі отримати класифікований спосіб надання цих рекомендацій, а також корисні поради щодо інформації, щоб дізнатися більше про ці рекомендації та фактично мати навіть зовнішні посилання на деякі з цих даних, що покаже мені і підведіть мене до причин, чому ці рекомендації зроблені.
І в багатьох випадках, будучи в змозі надати сценарій, який би автоматизував, як я вже сказав, виправлення цих проблем. Тепер, частина того, що ми робимо тут з цим аналізом - і я покажу вам, коли я ввійду, щоб налаштувати властивості цього примірника, і я перейду до розділу конфігурації аналізу - у нас є багато різних категорій, які є перераховані тут, і частина цього, ми маємо оптимізацію індексу та оптимізацію запитів. Отже, ми оцінюємо не тільки самі показники та подібні речі, але й такі речі, як завантаженість та індекси. У цьому випадку ми фактично зробимо додатковий аналіз гіпотетичного індексу. Отже, це одна з тих ситуацій, коли я не хочу, у багатьох випадках я не хочу додавати індекс, якщо мені цього не потрібно. Але в якийсь момент є якась підказка, де я кажу: "Ну, таблиця набуває розміру або типів запитів, що виконуються в межах навантаження, має сенс зараз додавати індекс. Але це не мало б сенсу, можливо, за шість тижнів до цього. "Таким чином, це дозволяє вам динамічно зрозуміти, що може, як я вже сказав, покращити продуктивність, виходячи з того, що відбувається в навколишньому середовищі, що відбувається в межах робочих навантажень. і робити такі речі.
І тому ви отримуєте тут багато хорошої інформації, а також можливість оптимізувати ці речі автоматично. Отже, це ще одна сфера, в якій ми могли б допомогти, з точки зору того, що ми називаємо прогнозним аналізом. Зараз, окрім цього, я маю сказати, у нас є й інші сфери, які, на мою думку, просто піддаються допомозі у прийнятті рішень. І коли ми говоримо про прийняття рішень, ми знову зможемо переглянути історичні дані, щоб зрозуміти, куди нам потрібно бути, щоб покращити ефективність.
Тепер одна з речей, яку ми можемо зробити, - це візуалізатор базової лінії, який дозволяє нам вибірково вибирати ту метрику, яку ми хотіли б - і дозвольте мені знайти гідний тут - я збираюся використовувати процесор SQL, але справа в тому, що ви ми можемо повернутися напродовж багатьох тижнів, щоб намалювати ці картинки, щоб побачити, коли перебувають ваші люди, що переживають люди, щоб побачити, де ця величина потрапляє протягом періодів часу, коли ми збирали дані. І тоді, крім цього, ви також помітите, що коли ми виходимо до власне екземпляра, ми маємо можливість налаштувати наші базові лінії. А базові лінії - це дійсно важлива частина того, що можна автоматизувати речі, а також бути здатними отримувати сповіщення про речі. І завдання, як сказала б більшість DBA, полягає в тому, що ваше оточення не завжди працює однаково протягом дня, порівняно з вечором і тим не менш, як ми згадували раніше в прикладі з періодами технічного обслуговування, коли ми мати високий рівень процесора або все, що може статися.
Отже, у випадку з цими фактичними базовими рівнями ми можемо мати декілька базових ліній, тому, можливо, у мене є базовий рівень, наприклад, це в мої години обслуговування. Але я міг так само просто створити базовий рівень для моїх виробничих годин. І справа в тому, що ми переходимо до екземпляра SQL і насправді мають ці декілька базових ліній, то ми могли б передбачити і мати можливість виконувати якийсь тип автоматизації, якийсь тип виправлення або просто попередження в цілому, по-різному специфічні для тих вікон часу. Отже, одна з речей, яку ви побачите тут, - це базові лінії, які ми створюємо, використовують історичні дані для надання аналізу, але що важливіше, я можу змінити ці пороги статично, але я також можу автоматично їх автоматизувати. Отже, у міру появи вікна технічного обслуговування, або я повинен сказати, базове вікно технічного обслуговування, ці порогові значення автоматично перемикаються на конкретні навантаження, з якими я стикаюсь протягом цього вікна часу, порівняно, можливо, в середині дня, коли мої навантаження не так сильно, коли навантаження не такі сильні.
Отже, це ще щось, про що слід пам’ятати, з точки зору базової лінії. Очевидно, вони будуть дуже корисними для вас, з точки зору розуміння того, що є нормальним і здатного також зрозуміти, займайтеся, коли у вас також буде не вистачати ресурсів. Тепер, інший варіант, який ми маємо в цьому інструменті, - це допоможе вам приймати рішення, крім того, базове визначення та можливість встановити сповіщення навколо цих базових ліній та порогів, які ви створюєте динамічно - це, як я вже говорив раніше, просто мати змогу запустити цілу безліч звітів, які допомагають мені відповісти на запитання про те, що відбувається.
Отже, як приклад, якщо у мене було 150 екземплярів, якими я керую - у моєму випадку я цього не роблю, тому ми маємо тут грати у вигляд, - але якби у мене були всі мої виробничі екземпляри, і мені потрібно було зрозуміти, де область, на яку я потребую уваги, іншими словами, якщо мені потрібно буде мати лише обмежений час, щоб виконати певний тип адміністрування для підвищення продуктивності, я хочу зосередити увагу на ключових областях. І тому, сказавши це, я міг би сказати: "Спираючись на це середовище, класифікуйте мої екземпляри один проти одного і дайте мені це рейтинг за розбіжністю". Отже, чи це використання диска, використання пам'яті, чи це чекає, чи це час відповіді, я в змозі співвіднести - чи слід сказати, ранжирувати ці випадки один проти одного. Очевидно, що екземпляр знаходиться у верхній частині кожного списку, якщо це той самий екземпляр, це, мабуть, те, на що я дійсно хочу зосередити увагу, тому що це, очевидно, знову вгорі списку.
Отже, у вас є багато звітів в цьому інструменті, які допомагають вам з точки зору ранжування середовища на рівні екземпляра; Ви можете це зробити і на рівні бази даних, де я можу класифікувати свої бази даних один проти одного. Зокрема, до порогів і областей, які я можу встановити, я навіть можу тут встановити підстановочні символи, щоб зосередитись лише на певних базах даних, але справа в тому, що я можу порівняти мої бази даних таким же чином. Крім того, що стосується інших видів порівняльного аналізу та великого в цьому інструменті, це базовий аналіз, який ми маємо. Отож, якщо прокрутити вниз до перегляду послуг тут, ви побачите, що існує звіт про статистику базової лінії. Тепер цей звіт, очевидно, допоможе нам зрозуміти не тільки, що таке метричні значення, але для конкретного екземпляра я міг би вийти, і за будь-якою з цих показників я міг би насправді переглянути базові лінії цих показників.
Тож, як би там не було, у відсотках чи тому, що я міг би вийти і сказати: "Давайте подивимось базову лінію для цього, яка вибула за останні 30 днів", і в цьому випадку вона покаже мені фактичні значення порівняно з базовими та Я міг би прийняти деякі рішення, використовуючи цю інформацію, очевидно, тож це одна з тих ситуацій, коли це буде залежати від того, яке саме питання, яке ви запитуєте в той час. Але це, очевидно, допоможе тобі з багатьох питань. Я б хотів сказати, що у нас був один звіт, який робить це все, і це схоже на простий звіт, де ви натискаєте та натискаєте кнопку, і він відповідає лише на кожне питання "що якщо", на який ви коли-небудь могли відповісти. Але насправді, у вас буде багато атрибутів і безліч варіантів, з яких можна вибрати на цих спадах, щоб мати можливість сформулювати ті питання "що робити", які ви шукаєте .
Тож багато цих звітів орієнтовані на можливість відповідати на ці типи питань. І тому, справді важливо також, щоб ці звіти та, крім того, усі речі, які ми вам уже показали в цьому інструменті, як я вже згадував раніше, маючи гнучкість вводити нові показники, якими керувати, навіть вміючи створювати лічильники або запити SQL, включені до ваших інтервалів опитування, щоб допомогти мені відповісти на ці запитання, що, можливо, ви не можете очікувати моніторингу, якщо ви не планували моніторити цю скриньку. І ви могли б потім робити все те саме, що я вам тільки показав: базовий рівень, запускати звіти та створювати звіти з цього показника, і мати змогу відповідати та робити багато цих різних речей, які я вам показую тут.
Тепер, на додаток до цього - і одна з речей, з якою ми, очевидно, стикаємося останнім часом, - спочатку це було, кожен перелітав або перемикався на ВМ. І зараз у нас є багато людей, які прямують до хмари. І є багато питань, які виникають навколо цих типів речей. Чи є сенс для мене переміщення до хмари? Я збираюсь економити гроші, перемістившись у хмару? Якби я розмістив ці речі на машині вільного зв'язку, на машині із загальним ресурсом, скільки грошей я можу заощадити? Ці види питань, очевидно, теж будуть виникати. Отже, багато з цього матеріалу майте на увазі, за допомогою Diagnostic Manager ми можемо додавати та витягувати з віртуалізованих середовищ як VMware, так і Hyper-V. Ми також можемо додавати екземпляри, які перебувають у хмарі, тому для ваших середовищ, таких як Azure DB, наприклад, або навіть RDS, ми можемо також виводити показники з цих середовищ.
Тож існує велика гнучкість і багато можливостей відповісти на ці запитання, оскільки це стосується тих інших типів середовища, до яких ми бачимо людей, куди прямують. І все ще існує багато питань навколо цього матеріалу, і, як ми бачимо, як люди консолідують ці середовища, їм потрібно буде відповісти і на ці запитання. Отже, це досить хороший огляд Diagnostic Manager, як це стосується цієї теми. Я знаю, що предмет бізнес-аналітики з'явився, і ми також маємо інструмент для бізнес-розвідки, про який ми не говорили сьогодні, але він також надасть вам розуміння щодо відповідей на ці типи питань, що стосуються ваших питань кубики та всі ці різні речі. Але, сподіваємось, це був хороший огляд, принаймні з точки зору того, як цей продукт може допомогти формувати хороший план.
Ерік Кавана: Добре, добрі речі. Так, я викину його Ріку, якщо він ще там. Ріку, якісь питання до тебе?
Рік Шерман: Так, так спочатку, це чудово, мені це подобається. Мені особливо подобається розширення візків та хмар. Я бачу, що багато розробників додатків думають, що якщо він знаходиться у хмарі, то їм не потрібно його налаштовувати. Так-
Буллет Манале: Так, ми все одно повинні платити за це, правда? Вам все одно доведеться платити за все, що люди кладуть на хмару, тож якщо вона погано працює або якщо це спричиняє багато циклів процесора, вам доведеться платити більше грошей, так що ні, ви ще потрібно вимірювати цей матеріал, абсолютно.
Рік Шерман: Так, я бачив багато бідних конструкцій у хмарі. Я хотів би запитати, чи буде цей продукт також використовуватися - я знаю, ви згадали про продукт BI і у вас є багато інших продуктів, які взаємодіють між собою, - але ви б почали дивитися на продуктивність SQL, індивідуальні запити в цьому інструменті? Або це були б інші інструменти, які були б використані для цього?
Буллет Манале: Ні, це було б абсолютно. Це одна з речей, яку я не висвітлював, і я мав на увазі, це частина запитів. У нас є багато різних способів визначити ефективність запиту, будь то пов’язаний, зокрема, з очікуванням, як ми бачимо на цьому перегляді, чи пов’язаний він із загальним споживанням ресурсів запитів, існує цілий ряд способів аналізу запитів. виконання. Незалежно від того, чи це тривалість, процесор, введення / виведення, і ще раз ми можемо також переглянути самі навантаження, щоб дати деяку інформацію. Ми можемо надати рекомендації в розділі аналізу, а також у нас є веб-версія, яка надає інформацію про самі запити. Тож я можу отримати рекомендації щодо відсутніх індексів та можливості перегляду плану виконання та всіх подібних матеріалів; це також можливість. Тож абсолютно ми можемо діагностувати запити на сім способів до неділі (сміється) і зможемо дати зрозуміти кількість покарань, будь то споживання ресурсів, очікування, тривалість і все таке добре.
Рік Шерман: Добре, чудово. І тоді яке навантаження на самі екземпляри з усім цим моніторингом?
Bullett Manale: Це гарне питання. Завдання відповіді на це питання полягає в тому, чи залежить це, як і все інше. Багато з того, що може запропонувати наш інструмент, він забезпечує гнучкість, і частину цієї гнучкості ви маєте сказати, що потрібно збирати, а що не збирати. Так, наприклад, із самими запитами мені не потрібно збирати інформацію про очікування, або я можу. Я можу збирати інформацію, що стосується запитів, що перевищують тривалість часу виконання. Як приклад цього, якби я зайшов у монітор запитів налаштування, і я повинен був би сказати: «Давайте змінимо це значення на нуль», реальність полягає в тому, що в основному інструмент змушує збирати кожен запит, який працює, і це насправді не дух того, чому це є, але загалом кажучи, якщо я хотів би надати повний зразок даних для всіх запитів, я міг би це зробити.
Отже, це дуже відносно того, які ваші налаштування є, взагалі кажучи, поза рамками. Це десь приблизно на 1–3 відсотки накладних витрат, але є інші умови, які застосовуватимуться. Це також залежить від того, скільки запитів на порт працює у вашому оточенні, правда? Це також залежить від способу збирання цих запитів та якої версії SQL це. Так, наприклад, SQL Server 2005, ми не зможемо витягнути з розширених подій, тоді як для цього нам слід відтягнути сліди. Отже, це було б дещо по-іншому з точки зору того, як ми б пішли збирати ці дані, але це сказало, як я вже сказав, ми, мабуть, існували приблизно з 2004 року з цим продуктом. Це вже давно, у нас є тисячі клієнтів, тому останнє, що ми хочемо зробити, - це інструмент моніторингу продуктивності, який спричиняє проблеми з роботою (сміється). І тому ми намагаємось максимально уникати цього, але загалом кажучи, приблизно так 1–3 відсотки є хорошим правилом.
Рік Шерман: Гаразд, і це досить низько, тому це приголомшливо.
Ерік Кавана: Добре. Робін, якісь питання до тебе?
Робін Блор: Вибачте, що я відключив звук. У вас є можливість функціонування декількох баз даних, і мене цікавить, як ви можете переглядати декілька баз даних, і, отже, ви можете знати, що більша база ресурсів, можливо, поділяється між різними віртуальними машинами тощо і так далі. Мене цікавить, як люди насправді цим користуються. Мене цікавить, що з цим роблять клієнти. Тому що це дивиться на мене, ну, звичайно, коли я возився з базами даних, те, чого я ніколи не мав під рукою. І я б коли-небудь розглядав один екземпляр будь-яким змістовним способом у будь-який момент часу. Отже, як люди цим користуються?
Bullett Manale: Взагалі кажучи, ви говорите загалом лише про сам інструмент? Як вони це використовують? Я маю на увазі, як правило, мова йде про те, щоб мати можливість мати центральну точку присутності довкілля. Маючи душевний спокій і знаючи, що якщо вони дивляться на екран і бачать зелений колір, вони знають, що все добре. Це коли виникають проблеми, і, очевидно, більшість випадків з точки зору DBA, багато разів трапляються ці проблеми, коли вони знаходяться перед консоллю, і таким чином можна отримувати сповіщення, як тільки проблема виникає. Але на додаток до цього, будучи здатним зрозуміти, коли проблема трапляється, бути здатним дістати до серця інформацію, яка надає їм певний контекст з точки зору, чому це відбувається. І тому, я думаю, найбільша частина: бути активним щодо цього, не бути реактивним.
Більшість DBA, з якими я розмовляю - і не знаю, це хороший відсоток - на жаль, все ще знаходяться в реактивному середовищі; вони чекають, коли споживач звернеться до них і скаже їм, що існує проблема. І тому ми бачимо, що багато людей намагаються відірватися від цього, і я думаю, що це велика частина причини, чому людям подобається цей інструмент, що він допомагає їм бути ініціативними, але він також дає їм уявлення про те, що відбувається, в чому проблема, але в багатьох випадках ми виявляємо щонайменше - і, можливо, про це говорять саме DBA, - але DBA, це сприйняття - це завжди їхня проблема, навіть якщо розробник програми написав програму які не написали це належним чином, вони винні, але вони беруть цю програму у свої системи чи сервери, і тоді, коли продуктивність погана, всі вказують на DBA, "Гей, це вини".
Таким чином, цей інструмент багато разів буде використовуватися, щоб допомогти з точки зору вирішення питання про те, що DBA скаже: "Ей, тут проблема полягає, і це не я". (Сміється) покращити це, будь то зміна запитів чи все, що це може бути. У деяких випадках вони потраплять у їхнє відро з точки зору їх відповідальності, але принаймні мати інструмент, який зможе допомогти їм зрозуміти це і знати це, і робити це своєчасно, очевидно, ідеальний підхід.
Робін Блор: Так, більшість сайтів, з якими я знайомий, але пройшов час, коли я був там, дивлячись на різні сайти з багатьма базами даних, але в основному я знайшов, що там DBA, орієнтовані на кілька баз даних. Це були б бази даних, що якщо вони колись знизяться, це буде справді великою проблемою для бізнесу, і так далі, і так далі. А інші, вони просто збиратимуть статистику раз у раз, щоб побачити, що у них не вистачає місця, і вони ніколи не дивляться на них взагалі. І поки ви робили демонстрацію, я дивився на це, і я добре думав, так чи інакше, ви розширюєте, просто надаючи щось подібне для баз даних, які часто були, нікого не надто хвилювали, оскільки вони мають зростання даних, вони також мають зростання додатків у рази. Ви розширюєте покриття DBA досить драматично. Тож ось про що йдеться насправді, чи з таким набором таких інструментів ви зможете в значній мірі надати послугу DBA кожній базі даних у корпоративній мережі?
Bullett Manale: Впевнений, я маю на увазі, що проблема полягає в тому, що, як ви сказали, досить красномовно, це схоже на те, що є деякі бази даних, про які піклуються DBA, і тоді є деякі, про які вони не хвилюються. І те, як цей конкретний продукт, як його ліцензувати, залежить від конкретного випадку. Отже, є, я думаю, ви б сказали, поріг, коли люди вирішать: «Ей, це не досить критичний екземпляр, що я хочу керувати ним цим інструментом». Тоді, є й інші інструменти, які ми робимо маю, що більше, я думаю, що обслуговує ті менш важливі екземпляри SQL. Один із них був би таким, як Менеджер інвентаризації, де ми робимо легкі перевірки стану здоров’я щодо випадків, але крім того, що ми робимо, ми робимо відкриття, тому ми визначаємо нові випадки, які були виведені в Інтернеті, а потім, з цього моменту, як DBA я можу сказати: «Добре, ось новий екземпляр SQL, зараз це Express? Це безкоштовна версія чи це корпоративна версія? "Це, мабуть, питання, яке я хочу собі задати, але по-друге, наскільки важливий цей екземпляр для мене? Якщо це не так важливо, я, можливо, цей інструмент вимкне і робить це загальним, як я б назвав загальні перевірки здоров'я в тому сенсі, що вони є елементарними типами речей, про які я дбаю як DBA: Чи накопичувач заповнюється ? Чи відповідає сервер на проблеми? Основні речі, правда?
Тоді як з Diagnostic Manager, інструментом, який я вам тільки показував, він перейде до рівня запитів, він перейде до рекомендацій індексів, дивлячись на план виконання та все, що добре, тоді як це в основному зосереджено про те, кому належить, чим я володію і хто за це відповідальний? Які пакети послуг та гарячі виправлення у мене є? І чи працюють мої сервери з основними інгредієнтами того, що я вважаю б здоровим екземпляром SQL? Отже, щоб відповісти на ваше запитання, є трохи суміші. Коли у нас є люди, які переглядають цей інструмент, вони зазвичай розглядають більш критичний набір примірників. Однак, у нас є кілька людей, які купують кожен екземпляр, який вони мають, і керують ним, тому це просто залежить. Але я вам кажу, в цілому, безумовно, є поріг тих людей, які вважають, що їх оточення є досить важливим, щоб мати такий інструмент для управління цими екземплярами.
Робін Блор: Гаразд, ще одне питання, перш ніж я передам його Еріку. Створюється враження, що тільки спостерігаючи за галуззю, полягає в тому, що в базах даних все ще існує життя, але всі дані заливаються у всі ці озера даних тощо і так далі. Це справді галас, і ажіотаж ніколи не відображає реальність, тому мене цікавить, яку реальність ви сприймаєте там? Чи є важливими базами даних в організації, чи переживає вони традиційне зростання даних, про яке я раніше вважав 10 відсотків на рік? Або вони більше ростуть? Чи великі дані роблять ці бази повітряними кулями? Яку картину ви бачите?
Bullett Manale: Я думаю, що у багатьох випадках ми спостерігаємо переміщення деяких даних у ті інші сегменти, де це має більше сенсу, коли є доступні інші технології. Останнім часом деякі більші дані. Але ці бази даних, я б сказав, важко узагальнити у багатьох випадках, тому що всі трохи інші. Взагалі кажучи, я бачу певну розбіжність. Я бачу, як я вже говорив, у багатьох випадках люди переходять до еластичних моделей, оскільки вони хочуть нарощувати ресурси, а не в інших сферах. Деякі люди переходять до великих даних. Але важко відчути сприйняття, скажімо, сприйняття, тому що загалом люди, з якими я спілкуюся, мають традиційні бази даних і використовують це в середовищі SQL Server.
Однак, я б сказав, що стосується самого SQL, я, безумовно, все ще думаю, що він завойовує частку ринку. І я думаю, що є багато людей, які все ще прямують до SQL з інших місць, таких як Oracle, оскільки це більш доступно і, мабуть, очевидно, оскільки версії SQL стають більш досконалими - і ви бачите це з останніми речами, які продовжують працювати з SQL, з точки зору шифрування та всіх інших можливостей, що роблять його середовищем або платформою бази даних - це, очевидно, дуже критично важлива місія. Отже, я думаю, що ми також бачимо це. Там, де ви бачите зміну, це все ще відбувається. Я маю на увазі, це відбувалося 10 років тому, але, я думаю, це все ще відбувається в умовах SQL Server, де середовище зростає і зростає частка ринку.
Робін Блор: Гаразд, Еріку, я гадаю, у аудиторії є питання чи два?
Ерік Кавана: Так, дозвольте мені перенести одну швидку. Насправді це досить гарне питання. Один із присутніх запитує, чи скаже мені цей інструмент, якщо таблиці може знадобитися індекс для прискорення запиту? Якщо так, чи можете ви показати приклад?
Bullett Manale: Так, я не знаю, чи є у мене конкретно додавання індексу, але ви можете побачити тут, у нас є рекомендації щодо фрагментації. Я також просто вірю, що ми щойно мали, і це було частиною Менеджера діагностики, який пропонує веб-версію, де він говорить мені, що у мене відсутній індекс. І ми можемо переглянути ці рекомендації, і це покаже нам потенційний прибуток, індексуючи цю інформацію. Інша річ, яку я мушу лише зазначити, це те, що коли ми виконуємо рекомендації, для багатьох з них сценарій буде створений для цього. Це не є хорошим прикладом, але ви зможете побачити, так, ситуації, коли індекс - або дублікат індексу, або додавання індексу - покращив би ефективність, і, як я вже говорив раніше, ми робимо багато що за допомогою гіпотетичного аналізу індексу. Отже, це дійсно допомагає з точки зору розуміння навантаження, щоб мати можливість застосувати це до рекомендації.
Ерік Кавана: Це чудові речі, і це дасть мені хороший погляд на остаточні коментарі тут. Робін, і я, і Рік, вже багато років чули, що там говорили про самонастроювання баз даних. Це база даних про самонастроювання! Все, що я можу вам сказати, це: не вірте їм.
Bullett Manale: Не вірте шуміху .
Ерік Кавана: Можливо, є деякі дрібниці, які динамічно робляться, але навіть це, можливо, ви захочете перевірити це і переконатися, що він не робить те, чого ви не хочете. Отже, нам давно знадобляться такі інструменти, щоб зрозуміти, що відбувається на рівні бази даних, і, як сказав Робін, озера даних є захоплюючими поняттями, але, мабуть, існує приблизно стільки шансів, що вони захоплять, наскільки це є там незабаром буде монстр Лох-Несса. Отже, я б лише повторив: у реальному світі є багато технологій баз даних, нам потрібні люди, DBA, щоб подивитися на цей матеріал і синтезувати його. Ви можете сказати, що вам потрібно знати, що ви робите, щоб цей матеріал працював. Але вам потрібні інструменти, щоб дати вам інформацію, щоб знати, що ви робите. Отже, підсумок - це DBA будуть робити добре.
І велика подяка Буллетту Манале та нашим друзям із IDERA. І звичайно, Рік Шерман та Робін Блор. Ми архівуємо всі ці веб-трансляції, тому перейдіть на веб-сайт insideanalysis.com або на наш партнерський сайт www.techopedia.com для отримання додаткової інформації про все це.
І з цим ми попрощаємося, люди. Ще раз дякую, ми поговоримо з вами наступного разу. Піклуватися. Бувай.
