вынос: Ведущий Эрик Кавана обсуждает прогнозирование с доктором Робином Блором, Риком Шерманом и IDERAs Bullett Manale.
Вы должны зарегистрироваться для этого события, чтобы просмотреть видео. Зарегистрируйтесь, чтобы посмотреть видео.
Эрик Кавана: Дамы и господа, еще раз привет и добро пожаловать в серию трансляций 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 и Spark SQL - которую мой сын, ученый по данным, все время использует, - безусловно, является доминирующим способом получения людьми данных.
Теперь, на стороне базы данных, есть две широкие категории использования баз данных. Один из них касается операционных систем управления базами данных, таких как планирование корпоративных отношений, управление отношениями с клиентами, ERP-системы Salesforce, Oracle, EPIC, N4 и т. Д. В мире. И, тем не менее, существует большое количество и расширяющийся объем данных, которые хранятся в хранилищах данных и других системах на основе бизнес-аналитики. Потому что все, независимо от того, где и как оно захвачено, сохранено или передано, в конечном итоге подвергается анализу, и поэтому существует огромный спрос и увеличение использования баз данных, особенно реляционных баз данных, представленных на рынке.
Теперь, когда у нас есть спрос, мы получаем огромное количество данных. И я на самом деле не говорю только о больших данных, я говорю об использовании данных во всех видах предприятий. Но в дополнение к этому, с точки зрения предложения, для людей, которые могут управлять этими ресурсами, у нас есть прежде всего недостаток DBA. По данным Бюро статистики труда, в 2014–2024 годах рабочие места DBA будут только расти на 11 процентов - теперь это люди, у которых есть должности DBA, но хорошо об этом поговорим в секунду - по сравнению с 40 с лишним процентов годовой объем роста данных. И у нас много администраторов баз данных; в среднем в том же исследовании говорилось о том, что средний возраст довольно высок по сравнению с другими ИТ-профессиями. И затем у нас много людей, покидающих поле, не обязательно уходящих в отставку, но переходящих в другие аспекты, переходящих в управление или что-то еще.
Теперь одна из причин, по которой они уходят, заключается в том, что работа DBA становится все сложнее и сложнее. Во-первых, у нас есть администраторы баз данных, которые сами управляют многими различными базами данных, физическими базами данных, расположенными повсеместно, а также различными типами баз данных. Теперь это могут быть реляционные или другие типы баз данных. Но даже если он реляционный, у них может быть один, два, три, четыре разных поставщика, которыми они на самом деле пытаются управлять. Администраторы базы данных обычно участвуют после разработки базы данных или приложения. Робин рассказал о том, как создаются базы данных или приложения, как создается SQL. Что ж, когда речь шла о моделировании данных, моделировании ER, расширенном моделировании ER, моделировании измерений, расширенном моделировании измерений, что бы то ни было, обычно программисты приложений и разработчики приложений проектируют с учетом своей конечной цели - они не проектируют для эффективности самой структуры базы данных. , Так что у нас много плохого дизайна.
Сейчас я не говорю о поставщиках коммерческих приложений для предприятий; у них обычно есть модели ER или расширенные модели ER. О чем я говорю, так это о том, что разработчики приложений в каждой компании создают гораздо больше бизнес-процессов и приложений - они не обязательно предназначены для эффективности или результативности развертывания. А сами администраторы баз данных перегружены работой, и иногда они несут круглосуточную ответственность, все больше и больше получая базы данных. Я думаю, что это немного связано с тем, что люди не совсем понимают, что они делают, или как они это делают. Их собственная небольшая группа и люди просто продолжают думать: «Ну, все эти инструменты настолько просты в использовании, что мы можем просто использовать все больше и больше баз данных для их рабочей нагрузки», что не так.
Что приводит нас к неполной занятости и случайным администраторам баз данных. У нас есть небольшие ИТ-команды, и они не могут позволить себе выделенного администратора баз данных. Теперь это верно для малых и средних предприятий, где расширение базы данных и приложений баз данных в последнее десятилетие резко возросло и продолжает расширяться. Но это также относится и к крупным корпорациям, которые долгое время занимались аналитикой бизнес-аналитики. Давным-давно мы получали специальных администраторов для этих проектов; мы больше никогда не получим выделенного администратора. Были ответственны за разработку базы данных, что хорошо, если это кто-то, кто имеет опыт.Но в целом администраторы баз данных являются разработчиками приложений, они часто принимают эту роль в качестве части неполного рабочего дня, у них нет формального обучения этому, и опять же, они разрабатывают его для своих конечных целей, а не разрабатывают его для повышения эффективности.
И есть большая разница между проектированием и разработкой, а не развертыванием и управлением. Таким образом, у нас есть «мудрый пенни, глупый фунт» с маленькой копилкой, пропускающей получение навыков и ресурсов, необходимых для проектов. Думая, что все из «Мести полудурков», моя маленькая картинка там. Теперь, что касается потребностей людей, мы расширили использование баз данных и данных в SQL. У нас ограниченное количество администраторов баз данных - людей, которые являются опытными и опытными в этих настройках, проектировании, управлении и развертывании. И у нас появляется все больше и больше неполных или случайных администраторов баз данных, людей, у которых нет формального обучения.
Итак, каковы другие вещи, которые также затрагивают тот факт, что эти базы данных также не настраиваются и не управляются? Во-первых, многие люди предполагают, что сами системы баз данных имеют достаточно инструментов для управления собой. Теперь инструменты становятся все проще и проще - проектирование и разработка - но это отличается от разработки хорошего дизайна и хорошего управления, планирования емкости, мониторинга и т. Д. Для развертывания. Итак, во-первых, люди предполагают, что у них есть все необходимые инструменты. Во-вторых, если вы работаете неполный рабочий день или случайно DBA, вы не знаете, что вы не знаете.
Я думаю, что я забыл некоторые фразы там, так что часто они просто не понимают, что им даже нужно посмотреть в дизайне или когда они управляют или работают с базами данных. Если это не ваша профессия, то вы не поймете, что вам нужно делать. Третий - это то, что SQL - инструмент для перехода, поэтому Робин говорил о SQL и о том, как плохо SQL иногда создается или часто создается. Кроме того, одна из моих любимых задач в области хранилищ данных BI, переноса данных, пространства разработки данных заключается в том, что вместо использования инструментов люди склонны писать код SQL, хранимые процедуры, даже если они используют дорогой инструмент интеграции данных или дорогой Инструмент BI, они часто действительно используют его только для запуска хранимых процедур. Так что важность понимания проектирования баз данных, построения SQL становится все более и более важной.
И, наконец, существует такой подход, в котором отдельные люди смотрят на отдельные базы данных. Они не смотрят на то, как работают приложения, и взаимодействуют друг с другом. И они также часто смотрят на базы данных по сравнению с приложениями, для которых они их используют. Таким образом, рабочая нагрузка, которую вы получаете на базу данных, критически важна при проектировании, критически важна при ее настройке, критически важна при попытке выяснить, как планировать емкость и т. Д. Итак, глядя на лес с деревьев, люди оказываются в сорняках , глядя на отдельные таблицы и базы данных и не глядя на общее взаимодействие этих приложений в рабочей нагрузке.
Наконец, люди должны взглянуть на ключевые области, на которые им нужно обратить внимание. Когда они планируют управлять базами данных, им нужно сначала подумать о разработке некоторых метрик производительности, ориентированных на приложения, чтобы им нужно было взглянуть не только на то, как эта таблица структурирована, как она конкретно моделируется, но как она используется? Итак, если у вас есть корпоративное приложение, предназначенное для управления цепочками поставок, если вы принимаете заказы из Интернета, если вы занимаетесь бизнес-аналитикой (что бы вы ни делали), вам нужно посмотреть, кто ее использует, как они ее используют, каковы объемы данных. когда это произойдет. То, что вы действительно пытаетесь найти, это время ожидания, потому что, несмотря ни на что, все приложения оцениваются по тому, сколько времени требуется, чтобы что-то сделать, будь то человек или просто обмен данными между приложениями или процессорами. И какие узкие места? Так часто, когда вы пытаетесь отладить проблемы, конечно, вы действительно пытаетесь понять, что является настоящими узкими местами - не обязательно, как настроить все, а как избавиться и повысить производительность, увеличить время ожидания и пропускную способность - что угодно вам нужно посмотреть.
И вам действительно необходимо отделить сбор данных, транзакции, аспекты преобразований в базе данных вместе с аналитикой. Каждый из них имеет разные шаблоны проектирования, каждый из них имеет разные шаблоны использования, и каждый из них должен быть настроен по-разному. Итак, вам нужно подумать о том, как используются эти данные, когда они используются, для чего они используются, и выяснить, какие показатели производительности и какие ключевые моменты вы хотите проанализировать, связанные с этим использованием. Теперь, когда вы смотрите на мониторинг производительности, вы хотите посмотреть на сами операции с базой данных; вы хотите рассмотреть как структуры данных, так и индексы, разбиение и другие физические аспекты базы данных, даже структуру базы данных - будь то модель ER или размерную модель, как бы она ни была структурирована - все эти факторы влияют на производительность особенно в различных минусах аналитики захвата данных и происходящих преобразований.
И, как упоминал Робин на стороне SQL, очень важно посмотреть на SQL, который запускается этими различными приложениями в этих базах данных, и настроить его. И, глядя на общую нагрузку приложений и инфраструктуру среды, в которой работают эти базы данных и приложения. Таким образом, чтобы сети, серверы, облако - независимо от того, на чем они работают - также смотрели на влияние, которое эти приложения и эти базы данных оказывают на это условие, все они имеют возможность настраивать базу данных.
И наконец, когда вы смотрите на инструменты, вы хотите иметь возможность взглянуть на три различных вида аналитики, связанных с этим. Вы хотите взглянуть на описательный анализ: что и где происходит, связанные с базой данных и производительностью приложения. Вы хотите иметь возможность проводить диагностическую аналитику, чтобы выяснить не только то, что происходит, но и почему, где существуют узкие места, где проблемы, что хорошо работает, что плохо работает? Но вы можете анализировать и анализировать проблемные области, чтобы решать их, будь то дизайн или все, что вам нужно сделать.
И, наконец, самый агрессивный или проактивный тип анализа - это на самом деле сделать некоторый прогнозный анализ, моделирование прогнозной аналитики, что угодно. Мы знаем, что база данных и приложения работают в этом направлении, если мы увеличим пропускную способность, если мы получим больше пользователей, если мы увеличим пропускную способность, что бы мы ни делали, имея возможность прогнозировать, что, как и где это повлияет на базу данных, приложения позволяют нам планировать и заранее выяснять, где находятся узкие места, где может пострадать время ожидания и что нам нужно сделать, чтобы исправить ситуацию. Поэтому мы хотим иметь инструменты, способные реализовывать метрики производительности, отслеживать производительность, как и в случае этих трех типов анализа. И это мой обзор.
Эрик Кавана: Хорошо, позвольте мне передать это - между прочим, это две отличные презентации - позвольте мне передать это Буллетту Манале, чтобы они взяли его оттуда. И люди, не забудьте задать хорошие вопросы; у нас уже есть хороший контент. Убери это, Буллетт.
Bullett Manale: Звучит хорошо. Спасибо, Эрик. Итак, многое из того, что сказали Рик и Робин, очевидно, я согласен со 100%. Я бы сказал, что я поднял этот слайд, потому что я думаю, что он подходит, я не знаю, для тех из вас, кто является фанатами «A-Team» еще в 80-х, у Джона Ганнибала Смита было высказывание, которое он всегда говорил: «Я люблю это когда план собирается вместе », и я думаю, что когда вы говорите, в частности, о SQL Server, на котором сосредоточились, о продукте, о котором собирались поговорить сегодня, SQL Diagnostic Manager, это определенно одна из тех вещей, которые у тебя должно быть; вы должны иметь возможность использовать имеющиеся у вас данные и принимать решения на основе этих данных, а в некоторых случаях вы не ищете решения; Вы ищете что-то, что скажет вам, когда что-то исчерпает ресурсы, когда вы исчерпаете ресурсы, когда у вас будет узкое место, такие вещи.
Речь идет не только о мониторинге конкретной метрики. Итак, с помощью Diagnostic Manager одна из вещей, которые он делает очень хорошо, поможет вам с точки зрения прогнозирования и понимания конкретных рабочих нагрузок, и мы собирались поговорить об этом сегодня. Инструмент предназначен для менеджера данных, администратора баз данных или действующих администраторов баз данных, поэтому многие вещи, о которых упоминал Рик, действующие администраторы баз данных настолько правдивы. Во многих случаях, если вы не являетесь администратором баз данных, у вас будет много вопросительных знаков, которые вы будете иметь, когда речь заходит об управлении средой SQL, то, чего вы не знаете. И поэтому вы ищете что-то, чтобы помочь вам, провести вас через этот процесс, а также обучить вас в этом процессе. И поэтому важно, чтобы инструмент, который вы используете для такого рода решений, дал вам некоторое представление о причинах принятия этих решений, а не просто говорил вам: «Эй, сделай это».
Поскольку я действующий администратор баз данных, в конце концов я мог бы стать полноценным администратором баз данных с фактическим опытом и знаниями, подтверждающими этот титул. Итак, это говорит о том, что когда я говорил о том, чтобы быть администратором базы данных - я всегда сначала показываю этот слайд, потому что администратор базы данных играет несколько разных ролей, и в зависимости от организации, с которой вы работаете, они будут отличаться от одно место в другое - но, как правило, вы всегда будете в какой-то мере отвечать за свое хранилище, за планирование этого хранилища и за понимание, я должен сказать, сколько места вам понадобится, будь то для резервного копирования или будь то для самих баз данных. Вам нужно будет понять и оценить это.
Кроме того, вам понадобится уметь понимать и оптимизировать вещи по мере необходимости, и, проходя мониторинг среды, очевидно, что вы должны вносить изменения по мере необходимости, основываясь на вещах, которые меняются в среде. сам. Таким образом, такие вещи, как количество пользователей, такие как популярность приложений, сезонность базы данных, должны учитываться при прогнозировании. И затем, очевидно, рассматривая другие вещи с точки зрения возможности предоставления отчетов и информации, необходимой для принятия этих решений. Во многих случаях это означает проведение сравнительного анализа; это означает, что вы можете посмотреть конкретно на конкретную метрику и понять, какова была ценность этой метрики с течением времени, чтобы вы могли предвидеть, куда она будет двигаться дальше.
Так что у многих инструментов Diagnostic Manager есть эти возможности, и люди используют его каждый день для выполнения таких задач, как прогнозирование, и я привел здесь определение планирования мощности. И это довольно широкое и на самом деле довольно расплывчатое определение, которое представляет собой просто процесс определения производственных мощностей, необходимых организации для удовлетворения меняющихся потребностей в ее продуктах, и, в конце концов, в этом и заключается все: о возможности получения информации, которая у вас есть, так или иначе, и принятия этой информации и принятии решений, которые помогут вам двигаться вперед по мере продвижения по жизненному циклу ваших баз данных. Итак, типы вещей, которые являются причинами, почему люди должны делать это, очевидно, в первую очередь, в большинстве случаев, чтобы сэкономить деньги. Очевидно, что основной целью бизнеса является заработать деньги и сэкономить. Но вместе с этим, это также означает, что вы можете быть уверены, что время простоя не будет. И способность быть уверенным в том, что вы минимизируете вероятность возникновения простоев, поэтому не допускайте, чтобы это происходило с самого начала, другими словами, не ожидая, пока это произойдет, а затем отреагировав на него.
Помимо общей возможности повысить производительность ваших пользователей, очевидно, что ключом к этому является то, что они делают их более эффективными, чтобы вы могли делать больше бизнеса, так что это такие вещи, которые, как администратор БД или кто-то, кто вовлечен в прогнозирование или потенциал Планирование должно быть в состоянии разбираться с информацией, чтобы иметь возможность принимать эти решения. И затем, в целом, это, очевидно, поможет вам избавиться от лишних затрат, не только с точки зрения денег, но также с точки зрения времени и просто ресурсов, которые могут быть использованы для других целей, возможно. Таким образом, возможность устранить эти отходы, чтобы у вас не было альтернативных издержек, связанных с самими отходами.
Итак, с учетом сказанного, какие типы вопросов мы получаем, специфичные для человека, который является администратором баз данных? Когда я выбегу из космоса? Это большое, не только, сколько места я сейчас потребляю, но когда я собираюсь закончиться, основываясь на тенденциях и прошлой истории? То же самое с реальными экземплярами SQL, базами данных, какие серверы я могу консолидировать? Я собираюсь разместить некоторые на виртуальных машинах, что имеет смысл с точки зрения того, какие базы данных я собираюсь консолидировать и на каких экземплярах SQL они должны находиться? На все эти типы вопросов нужно ответить. Потому что в большинстве случаев, если вы DBA или действующий DBA, вы собираетесь объединить это когда-нибудь в вашей карьере. Во многих случаях вы будете делать это на постоянной основе. Таким образом, вы должны быть в состоянии быстро принимать эти решения, а не играть в угадайку, когда дело доходит до этого.
Мы говорили о узких местах и о том, где они будут происходить дальше, имея возможность предвидеть это еще раз, вместо того, чтобы ждать их возникновения. Итак, очевидно, что все эти вещи говорили о том, что имеет смысл в том смысле, что вы полагаетесь на исторические данные, в большинстве случаев, чтобы иметь возможность генерировать эти рекомендации, или в некоторых случаях быть в состоянии самостоятельно формулировать решения, чтобы иметь возможность придумать эти ответы. Но это напоминает мне о том, что когда вы слышите рекламу по радио о ком-то, кто продает ценные бумаги или что-то в этом роде, это всегда «прошлые результаты не указывают на будущие результаты» и тому подобное. И то же самое здесь верно. Вы будете иметь ситуации, когда эти прогнозы и эти анализы могут быть не на 100 процентов правильными. Но если вы имеете дело с вещами, которые произошли в прошлом и известном, и способны ответить на вопрос «что, если» со многими из этих типов вопросов, с которыми вы столкнетесь, это очень ценно, и это получить гораздо больше, чем играть в угадайку.
Итак, эти типы вопросов, очевидно, будут возникать, поэтому, как мы решаем многие из этих вопросов с помощью Diagnostic Manager, прежде всего, у нас есть возможности прогнозирования, возможность делать это в базе данных, за столом, а также диск или объем. Чтобы иметь возможность не только сказать: «Эй, я был полон места», но и через шесть месяцев, через два года, через пять лет, если я планирую это на бюджет, сколько места на диске мне понадобится для бюджета за? Это те вопросы, которые мне нужно будет задать, и мне нужно будет иметь возможность использовать какой-то метод для этого, вместо того, чтобы угадывать и поднимать палец вверх, и ждать, чтобы увидеть, куда дует ветер, что очень много. раз, к сожалению, то, как многие из этих решений принимаются.
В дополнение к этому, возможность - похоже, что мой слайд немного обрезался - но была возможность оказать некоторую помощь в виде рекомендаций. Таким образом, это одна вещь, чтобы иметь возможность показать вам панель мониторинга, полную метрик, и сказать: «Хорошо, здесь все метрики и где они находятся», но затем иметь возможность сделать некоторые или иметь некоторое представление о том, что сделать, основанный на том, что это еще один скачок. А в некоторых случаях люди достаточно образованы в роли администратора баз данных, чтобы принимать такие решения. И поэтому в инструменте есть некоторые механизмы, которые помогут с этим, которые хорошо покажут вам всего за секунду. Но будучи в состоянии показать не только, что это за рекомендация, но и дать некоторое представление о том, почему эта рекомендация делается, а также, кроме того, в некоторых случаях, возможность фактически создать сценарий, который автоматизирует исправление этой проблемы также идеально.
Переходя к следующему здесь, что хорошо видно, это просто общее понимание, вплоть до метрического уровня, что является нормальным. Я не могу сказать вам, что не нормально, если я не знаю, что нормально. И так, имея какой-то способ измерить это является ключевым, и вы должны иметь возможность принимать во внимание различные типы областей, например - или, я бы сказал, временные рамки - разные группы серверов, которые могут делать это динамически, от другими словами, в середине ночи, во время моего окна обслуживания, я ожидаю, что мой ЦП будет работать на 80%, исходя из всего происходящего обслуживания. Итак, я мог бы хотеть увеличить свои пороги выше, в те временные рамки по сравнению с, может быть, в середине дня, когда у меня не так много активности.
Это некоторые вещи, которые, очевидно, будут экологическими, но вещи, которые вы можете применить к тому, что управляется, чтобы помочь вам более эффективно управлять этой средой и упростить это. Другая область, очевидно, заключается в возможности просто предоставлять отчеты и информацию, чтобы иметь возможность ответить на такие вопросы типа «что если». Если я только что внес изменения в свою среду, я хочу понять, как это повлияло, чтобы я мог применить это же изменение к другим экземплярам или другим базам данных в моей среде. Я хочу, чтобы у меня была какая-то информация или боеприпасы, чтобы можно было сделать это с некоторым спокойствием и осознанием того, что это будет хорошее изменение. Итак, возможность составлять такую сравнительную отчетность, иметь возможность ранжировать мои экземпляры SQL, иметь возможность ранжировать мои базы данных друг против друга, говоря: «Какой мой процессор потребляет больше всего?» Или какой из них занимает больше всего времени? сроки ожидания и тому подобное? Так что большая часть этой информации также будет доступна с помощью инструмента.
И, наконец, последнее, но не менее важное, это просто общая способность, что вам нужен инструмент, который сможет справиться с любой ситуацией, которая возникнет у вас на пути, и вот что я имею в виду, если у вас есть большая среда с большим количеством В некоторых случаях вы, вероятно, столкнетесь с ситуациями, когда вам нужно получить метрики, которые традиционно не являются метриками, которые администратор БД хотел бы даже отслеживать в некоторых случаях, в зависимости от конкретной ситуации. Таким образом, имея инструмент, который вы можете расширять, чтобы иметь возможность добавлять дополнительные метрики и иметь возможность использовать эти метрики в той же форме и в том же стиле, в котором вы их использовали бы, если бы использовали готовый комплект метрика, например. Таким образом, способность создавать отчеты, возможность оповещения, исходные данные - все, о чем говорилось, - также является ключевой частью способности делать это прогнозирование и делать его таким, чтобы вы получали ответы, которые вы ищете, чтобы иметь возможность сделать эти решения, двигаясь вперед.
Теперь, когда Diagnostic Manager делает это, у нас есть централизованная служба, группа служб, которая выполняет сбор данных по экземплярам с 2000 по 2016 год. И затем мы берем эти данные и помещаем их в центральный репозиторий, а затем, что хорошо с этими данными, очевидно, так это то, что мы делаем многое для того, чтобы обеспечить дальнейшее понимание. Теперь, в дополнение к этому - и одна из вещей, которых здесь нет - это то, что у нас также есть служба, которая работает среди ночи, которая является нашей службой прогнозного анализа, которая выполняет некоторые вычисления и помогает понять и помочь вам как администратору БД или действующему администратору баз данных, чтобы иметь возможность давать рекомендации такого типа, чтобы иметь возможность дать некоторое представление о базовых показателях.
Итак, что я хотел бы сделать, и это всего лишь быстрый пример архитектуры, большой вывод здесь заключается в том, что здесь нет агентов или служб, которые фактически находятся в тех случаях, когда вы управляете. Но то, что я хотел бы сделать, это просто ввести вас в приложение и показать вам короткую демонстрацию. И позвольте мне тоже выйти и сделать это. Итак, дай мне знать, я думаю, Эрик, ты видишь, что все в порядке?
Эрик Кавана: Я понял это сейчас, да.
Bullett Manale: Хорошо, я собираюсь рассказать вам о некоторых из этих частей, о которых я говорил. И, по сути, давайте начнем с того, что больше похоже на то, что вам нужно сделать, или вот что-то, что является моментом времени в будущем и собирается дать вам некоторое представление об этом. И это способность действительно предвидеть - или я должен сказать, динамически предвидеть - вещи, как они происходят. Теперь, в случае отчетов, в инструменте есть три разных прогнозных отчета. И в случае, например, прогноза базы данных, что я, вероятно, сделал бы в ситуации, когда я смогу предвидеть размер базы данных в течение определенного периода времени, и я просто приведу вам пару примеров этого. Итак, я собираюсь взять мою аудиторскую базу данных, которая довольно интенсивно вводит / выводит - в нее поступает много данных. У нас есть, давайте посмотрим, хорошо, сделайте это здесь, и давайте просто выберем базу данных здравоохранения здесь.
Но суть в том, что я не просто вижу, сколько места для этого, я могу сказать: «Послушайте, давайте возьмем данные последних лет» - и я собираюсь выдумать здесь немного, у меня действительно нет лет ценность данных, у меня есть данные за два месяца - но, поскольку я выбираю здесь частоту выборки месяцев, я буду в состоянии предвидеть или прогнозировать в этом случае следующие 36 единиц, потому что наша частота выборки установлена на месяцы - это единица, это месяц, - и тогда я смогу, а затем запустить отчет, который в основном покажет мне, где мы ожидаем наш будущий рост, для этих трех баз данных. И мы можем видеть, что у нас есть различная степень различий или различий между тремя различными базами данных, особенно в отношении объема данных, которые они потребляли исторически.
Здесь мы видим точки данных, представляющие исторические данные, а затем линии, которые будут предоставлять нам прогноз, а также цифры, подтверждающие это. Таким образом, мы можем сделать это на уровне таблицы, мы можем сделать это даже на уровне дисков, где я могу предвидеть, насколько большими будут мои диски, включая точки монтирования. Мы могли бы прогнозировать этот же тип информации, но еще раз, в зависимости от частоты выборки, я смогу определить, сколько единиц и откуда брали то, что мы хотим прогнозировать. Обратите внимание, что у нас есть разные типы прогнозов. Таким образом, вы получаете множество вариантов и гибкость, когда дело доходит до прогнозирования. Это одно, что нужно сделать, фактически предоставив вам конкретную дату и возможность сказать: «Эй, в эту дату, это то место, где мы ожидаем рост ваших данных». В дополнение к этому, тем не менее, мы можем предоставить вам с другими соображениями, связанными с анализом, который мы проводим в нерабочее время, и обслуживанием, когда оно выполняется. Некоторые из вещей, которые он делает, это то, что он пытается предвидеть то, что, скорее всего, произойдет, основываясь на истории того, что происходило в прошлом.
Таким образом, мы можем видеть здесь, на самом деле, прогноз дает нам некоторое представление о вероятности возникновения у нас проблем в течение вечера, основанных на событиях, которые снова произошли в прошлом. Итак, очевидно, что это здорово, особенно если я не администратор баз данных, я могу посмотреть на эти вещи, но что еще лучше, если я не администратор баз данных, это вкладка анализа. Итак, до того, как это было здесь в инструменте, мы должны были пройти и показать продукт людям, и они были бы «Это здорово, я вижу все эти цифры, я вижу все, но я не знаю, что делать» (смеется) «как результат этого ». Итак, то, что мы имеем здесь, это лучший способ для вас понять, если я собираюсь принять меры, чтобы помочь с производительностью, если я собираюсь принять меры, чтобы даже помочь со здоровьем моего окружающая среда, способная предоставить ранжированный способ предоставления этих рекомендаций, а также полезные советы в информации, чтобы узнать больше об этих рекомендациях и даже иметь внешние ссылки на некоторые из этих данных, которые покажут мне и приведут меня к причинам, почему эти рекомендации сделаны.
И во многих случаях, будучи в состоянии предоставить сценарий, который автоматизировал бы, как я сказал, исправление этих проблем. Теперь, часть того, что здесь делалось с этим анализом - и я покажу вам, когда я войду, чтобы настроить свойства этого экземпляра, и я перейду к разделу конфигурации анализа - у нас есть много разных категорий, которые перечислены здесь, и часть этого, у нас есть оптимизация индекса и оптимизация запросов. Таким образом, оценивали не только сами метрики и тому подобное, но и такие вещи, как рабочие нагрузки и индексы. В данном случае, на самом деле, сделайте дополнительный анализ гипотетического индекса. Итак, это одна из тех ситуаций, когда я не хочу, во многих случаях я не хочу добавлять индекс, если мне это не нужно. Но в какой-то момент наступает переломный момент, когда я говорю: «Ну, таблица приближается к размеру, или типы запросов, выполняющихся в рабочей нагрузке, теперь имеют смысл добавить индекс. Но это не имело бы смысла, может быть, за шесть недель до этого ». Таким образом, это позволяет вам динамически получить представление о вещах, которые, вероятно, как я уже сказал, улучшат производительность на основе того, что происходит в среде, что происходит в рабочих нагрузках, и делать такие вещи.
И поэтому вы получаете много полезной информации здесь, а также возможность автоматически оптимизировать эти вещи. Так что это еще одна область, в которой мы могли бы помочь с точки зрения того, что мы называем предиктивным анализом. Теперь, в дополнение к этому, я должен сказать, что у нас есть и другие области, которые, как мне кажется, в целом пригодны для оказания вам помощи в принятии решений. И когда мы говорим о принятии решений, еще раз, имея возможность взглянуть на исторические данные, предоставим некоторую информацию, которая поможет нам понять, где мы должны быть, чтобы улучшить эту производительность.
Теперь, одна из вещей, которые мы можем сделать, - у нас есть базовый визуализатор, который позволяет нам выборочно выбирать любую метрику, которую мы хотели бы - и позвольте мне найти приличную здесь - я собираюсь использовать ЦП SQL, но суть в том, что вы можете пойти Вернитесь, однако, на многие недели, чтобы нарисовать эти картинки, чтобы вы могли видеть, когда ваши выбросы находятся, чтобы увидеть в целом, где это значение находится в пределах периодов времени, когда мы собирали данные. И затем, в дополнение к этому, вы также заметите, что когда мы переходим к самому фактическому экземпляру, у нас есть возможность настроить наши базовые показатели. И базовые показатели - это действительно важная часть способности автоматизировать вещи, а также получать уведомления о них. И проблема, как сказали бы большинство администраторов баз данных, заключается в том, что ваша среда не всегда работает одинаково в течение дня, по сравнению с вечером и так далее, как мы упоминали ранее в примере с периодами обслуживания, когда мы иметь высокий уровень процессора или что-то, что может происходить.
Таким образом, в данном случае, с этими фактическими базовыми показателями, у нас может быть несколько базовых показателей, поэтому у меня может быть, например, базовый уровень, то есть во время моего технического обслуживания. Но я мог бы так же легко создать основу для своих рабочих часов. И смысл этого заключается в том, что когда мы входим в экземпляр SQL, и у нас фактически есть эти многочисленные базовые показатели, тогда мы сможем предвидеть и иметь возможность выполнять некоторый тип автоматизации, некоторый тип исправления или просто оповещение вообще, по-разному характерны для этих окон времени. Итак, одна из вещей, которые вы увидите здесь, это то, что эти исходные данные, которые мы генерируем, используют исторические данные для обеспечения этого анализа, но, что более важно, я могу изменить эти пороги статически, но я также могу автоматизировать их также динамически. Итак, когда появляется окно обслуживания, или я должен сказать, что окно базового уровня обслуживания, эти пороги будут автоматически переключаться в зависимости от нагрузок, с которыми я сталкиваюсь в течение этого периода времени, по сравнению с, возможно, в середине дня, когда мои нагрузки не так велики. много, когда рабочие нагрузки не столь значительны.
Итак, это еще кое-что, что нужно иметь в виду, с точки зрения базовой линии. Очевидно, что это будет очень полезно для вас, с точки зрения понимания того, что является нормальным, и способности также понимать, участвовать, когда у вас также будут исчерпаны ресурсы. Теперь, другая вещь, которую мы имеем в инструменте, которая поможет вам принимать решения, в дополнение к базовым линиям и возможности устанавливать оповещения вокруг этих базовых уровней и порогов, которые вы создаете динамически, как я уже говорил ранее, просто возможность составлять целое множество отчетов, которые помогают мне отвечать на вопросы о том, что происходит.
Так, например, если бы у меня было 150 экземпляров, которыми я управляю - в моем случае я этого не делаю, поэтому мы должны сыграть здесь в притворную игру - но если у меня были все мои производственные экземпляры, и мне нужно было понять, где находится область, которую я нуждаемся во внимании, другими словами, если у меня будет только ограниченное количество времени на выполнение какого-либо администрирования для повышения производительности, я хочу сосредоточиться на ключевых областях. И поэтому, сказав это, я мог бы сказать: «Исходя из этой среды, оцените мои экземпляры друг против друга и дайте мне это ранжирование по каналу конкуренции». Так ли это - использование диска, использование памяти, ожидание, будь то время отклика, я могу сопоставить - или я должен сказать, ранжирование - эти случаи друг против друга. Очевидно, что экземпляр, который находится вверху каждого списка, если это один и тот же экземпляр, вероятно, на этом я действительно хочу сосредоточиться, потому что он, очевидно, снова в верхней части списка.
Итак, у вас есть много отчетов в инструменте, которые помогут вам с точки зрения ранжирования среды на уровне экземпляра; Вы можете сделать это также на уровне базы данных, где я могу сравнить свои базы данных друг с другом. В частности, для порогов и областей, которые я могу установить, я даже могу установить здесь шаблоны, если хочу, чтобы сосредоточиться только на конкретных базах данных, но дело в том, что я могу сравнивать свои базы данных таким же образом. Кроме того, что касается других видов сравнительного анализа и большого в этом инструменте, это базовый анализ, который мы имеем. Так что, если вы прокрутите вниз до представления службы здесь, вы увидите, что есть базовый статистический отчет. Теперь этот отчет, очевидно, поможет нам понять не только то, что представляют собой значения метрик, но и для конкретного случая, который я мог бы использовать, и для любой из этих метрик можно было бы реально взглянуть на базовые показатели для этих метрик.
Итак, какой бы он ни был, в процентах или как я мог бы выйти и сказать: «Давайте посмотрим на базовую линию для этого разбитого за последние 30 дней», и в этом случае он покажет мне фактические значения по сравнению с базовой линией и Я мог бы принять некоторые решения, используя эту информацию, очевидно, так что это одна из тех ситуаций, когда она будет зависеть от того, какой это вопрос, который вы задаете в то время. Но это, очевидно, поможет вам во многих из этих вопросов. Хотелось бы сказать, что у нас был один отчет, который делает все это, и вроде как простой отчет, где вы нажимаете и нажимаете кнопку, и он просто отвечает на каждый вопрос «что если», на который вы когда-либо могли ответить. Но реальность такова, что в этих раскрывающихся списках у вас будет множество атрибутов и множество вариантов, из которых вы сможете выбирать, чтобы иметь возможность формулировать те вопросы типа «что, если», которые вы ищете.
Поэтому многие из этих отчетов направлены на то, чтобы отвечать на вопросы такого типа. И поэтому очень важно также, чтобы эти отчеты и, кроме того, все то, что мы уже показали вам в инструменте, как я уже упоминал ранее, обладает гибкостью для включения новых метрик, которыми можно управлять, даже имея возможность создавать счетчики, или SQL-запросы, включенные в ваши интервалы опроса, чтобы помочь мне ответить на эти вопросы, которые, возможно, из коробки, которую мы не ожидали отслеживать, вы можете добавить эту штуку. И тогда вы сможете делать все то же самое, что я только что показал вам: базовый уровень, запускать отчеты и создавать отчеты по этой метрике, а также иметь возможность отвечать и выполнять многие из этих различных типов вещей, которые я покажу вам здесь.
Теперь, в дополнение к этому - и одна из вещей, с которыми мы, очевидно, сталкивались в последнее время, - это то, что все переключались или переключались на виртуальные машины. И теперь у нас есть много людей, которые направляются в облако. И есть много вопросов, которые возникают вокруг этих типов вещей. Имеет ли смысл переходить в облако? Собираюсь ли я сэкономить, перейдя в облако? Если бы я положил эти вещи на виртуальную машину, на машину с общими ресурсами, сколько денег я смог бы сэкономить? Эти типы вопросов, очевидно, также будут возникать. Итак, многое из этого следует иметь в виду, с помощью Diagnostic Manager мы можем добавлять и извлекать из виртуализированных сред как VMware, так и Hyper-V. Мы также можем добавлять экземпляры, которые находятся в облаке, поэтому в ваших средах, таких как, например, Azure DB, или даже RDS, мы также можем получать метрики из этих сред.
Таким образом, существует большая гибкость и возможность ответить на эти вопросы, поскольку они связаны с другими типами среды, в которую мы направляем людей. И есть еще много вопросов вокруг этого материала, и, как мы видим, люди, консолидирующие эти среды, должны будут также иметь возможность ответить на эти вопросы. Итак, это довольно хороший обзор, я бы сказал, Диагностического менеджера, поскольку он относится к этой теме. Я знаю, что возникла тема бизнес-аналитики, и у нас также есть инструмент для бизнес-аналитики, о котором мы сегодня не говорили, но он также даст вам представление о том, как ответить на эти типы вопросов, так как это относится к вашим кубам и все эти разные типы вещей, а также. Но, надеюсь, это был хороший обзор, по крайней мере, с точки зрения того, как этот продукт может помочь в разработке хорошего плана.
Эрик Кавана: Хорошо, хорошие вещи. Да, я брошу это Рику, если он все еще там. Рик, есть вопросы от тебя?
Рик Шерман: Да, во-первых, это здорово, мне это нравится. Мне особенно нравится расширение до виртуальных машин и облаков. Я вижу, что многие разработчики приложений думают, что если он находится в облаке, им не нужно настраивать его. Так-
Bullett Manale: Да, мы все еще должны заплатить за это, верно? Вам все еще нужно платить за то, что люди помещают в облако, поэтому, если оно работает плохо или вызывает много циклов ЦП, вам нужно платить больше денег, так что нет, вам все равно нужно измерить этот материал, абсолютно.
Рик Шерман: Да, я видел много плохих дизайнов в облаке. Я действительно хотел спросить, будет ли этот продукт также использоваться - я знаю, что вы упомянули продукт BI, и у вас есть тонны других продуктов, которые взаимодействуют друг с другом - но вы бы начали смотреть на производительность SQL, отдельные запросы в этом инструменте? Или это будут другие инструменты, которые будут использоваться для этого?
Bullett Manale: Нет, это было бы абсолютно. Вот одна из вещей, которые я не рассмотрел и я имел в виду, это часть запросов. У нас есть много разных способов определить производительность запросов, независимо от того, связано ли это с, в частности, с ожиданиями, которые мы видим в этом представлении, или с тем, связано ли это с потреблением ресурсов для запросов в целом, и существует целый ряд способов, которыми мы можем проанализировать запрос. представление. Будь то его продолжительность, процессор, ввод-вывод и еще раз, мы также можем взглянуть на сами рабочие нагрузки, чтобы дать некоторое представление. Мы можем предоставить рекомендации в разделе анализа, а также у нас есть веб-версия, которая предоставляет информацию о самих запросах. Так что я могу получить рекомендации по отсутствующим индексам и возможность просмотра плана выполнения и всего такого; это также возможность, а также. Так что, безусловно, мы можем диагностировать запросы по семи путям до воскресенья (смеется) и быть в состоянии обеспечить это понимание с точки зрения количества выполнений, будь то потребление ресурсов, ожидания, продолжительность, и все такое хорошее.
Рик Шерман: Ок, отлично. И какова нагрузка на сами экземпляры со всем этим мониторингом?
Bullett Manale: Это хороший вопрос. Проблема с ответом на этот вопрос заключается в том, зависит ли оно, как и все остальное. Многое из того, что может предложить наш инструмент, обеспечивает гибкость, и часть этой гибкости заключается в том, что вы можете сказать ему, что собирать, а что не собирать. Так, например, с самими запросами мне не нужно собирать информацию об ожидании, или я могу. Я могу собирать информацию, связанную с запросами, которые превышают продолжительность выполнения. Например, если я зайду в монитор запросов конфигурации и скажу: «Давайте изменим это значение на ноль», то реальность такова, что инструмент фактически собирает все запросы, которые выполняются, и на самом деле это не дух того, что есть, но, вообще говоря, если бы я хотел предоставить полную выборку данных для всех запросов, я мог бы это сделать.
Таким образом, это очень по отношению к тому, что ваши настройки, вообще говоря, из коробки. Это где-то от 1 до 3 процентов накладных расходов, но есть и другие условия, которые будут применяться. Это также зависит от того, сколько запросов к порту выполняется в вашей среде, верно? Это также зависит от метода сбора этих запросов и версии SQL. Так, например, SQL Server 2005 не собирался извлекать данные из расширенных событий, в то время как для этого мы извлекли бы из себя трассировку. Таким образом, было бы немного по-другому с точки зрения того, как мы собираемся собирать эти данные, но это говорит о том, что, как я уже сказал, мы были примерно с 2004 года с этим продуктом. Это было давно, у нас было тысячи клиентов, поэтому последнее, что мы хотим сделать, это иметь инструмент мониторинга производительности, который вызывает проблемы с производительностью (смеется). И поэтому мы стараемся держаться подальше от этого, насколько это возможно, но, вообще говоря, примерно 1-3 процента - это хорошее эмпирическое правило.
Рик Шерман: Хорошо, и это довольно низко, так что это потрясающе.
Эрик Кавана: Хороший. Робин, есть вопросы от тебя?
Робин Блур: Извините, я был на немом. У вас есть возможность работы с несколькими базами данных, и мне интересно, как вы можете просматривать несколько баз данных, и, следовательно, вы можете знать, что большая база ресурсов может быть разделена между различными виртуальными машинами и так далее, и так далее. Мне интересно, как люди на самом деле используют это. Мне интересно, что клиенты делают с этим. Потому что это выглядит для меня, ну, конечно, когда я возился с базами данных, то, чего у меня никогда не было под рукой. И я бы только когда-либо рассматривал один случай любым значимым образом в любой данный момент времени. Итак, как люди используют это?
Bullett Manale: Вообще говоря, вы говорите вообще о самом инструменте? Как они это используют? Я имею в виду, как правило, возможность иметь центральную точку присутствия окружающей среды. Имея душевное спокойствие и зная, что если они смотрят на экран и видят зеленый, они знают, что все хорошо. Это когда возникают проблемы и, очевидно, в большинстве случаев с точки зрения администраторов баз данных, часто эти проблемы возникают, когда они находятся перед консолью, поэтому они могут быть уведомлены, как только возникнет проблема. Но в дополнение к этому, способность понимать, когда проблема действительно возникает, быть способной проникнуть в суть информации, которая предоставляет им некоторую связь с точки зрения того, почему она возникает. И это, я думаю, самая большая часть: быть проактивным, а не реагировать.
Большинство администраторов баз данных, с которыми я общаюсь - и я не знаю, их значительный процент - к сожалению, все еще находятся в реактивной среде; они ждут, пока потребитель приблизится к ним и расскажет им о проблеме. Итак, мы видим, что многие люди пытаются от этого избавиться, и я думаю, что большая часть причины, по которой людям нравится этот инструмент, заключается в том, что он помогает им быть активными, но также дает им понимание того, что происходит. В чем проблема, но во многих случаях, по крайней мере, то, что мы находим - и, может быть, это только администраторы баз данных, которые говорят нам об этом, - но администраторы баз данных всегда считают их проблемой, даже если разработчик приложения написал приложение. которые не написали это правильно, это те, кто возьмет на себя вину, потому что они переносят это приложение на свои системы или серверы, а затем, когда производительность плохая, все указывают на то, что администратор БД говорит: «Эй, это твоя вина».
Таким образом, этот инструмент много раз будет использоваться, чтобы помочь с точки зрения обоснования для DBA сказать: «Эй, это проблема, а не я». (Смеется.) Нам нужно улучшить это, будь то изменение запросов или что-то еще. В некоторых случаях это падает в их ведении с точки зрения их ответственности, но, по крайней мере, наличие инструмента, который поможет им понять это и знать это, и делать это своевременно, очевидно, является идеальным подходом.
Робин Блур: Да, большинство сайтов, с которыми я знаком, но прошло много времени с тех пор, как я был там, просматривая различные сайты с несколькими базами данных, но в основном я обнаружил, что там будут администраторы баз данных, которые сосредоточены на нескольких базы данных. И это будут базы данных, которые, если они когда-нибудь выйдут из строя, станут большой проблемой для бизнеса, и так далее, и тому подобное. А другие, они просто будут время от времени собирать статистику, чтобы увидеть, что у них не осталось свободного места, и они вообще никогда на них не смотрят. И пока вы делали демонстрацию, я смотрел на это, и я хорошо думал, так или иначе, вы расширяете, просто предоставляя что-то подобное для баз данных, которые часто никого не заботили, потому что у них рост данных , они имеют рост приложений в разы. Вы расширяете охват DBA довольно драматическим образом. Так вот в чем вопрос, на самом деле, в том, что с таким набором инструментов вы в конечном итоге сможете в значительной степени предоставлять услугу DBA для каждой базы данных, находящейся в корпоративной сети?
Bullett Manale: Конечно, я имею в виду, проблема в том, что, как вы сказали довольно красноречиво, это похоже на то, что есть некоторые базы данных, о которых заботятся администраторы баз данных, а затем есть некоторые, которые им не безразличны. И способ, которым этот конкретный продукт, способ, которым его лицензируют, является для каждого отдельного случая. Так что, я думаю, вы бы сказали, что порог, когда люди решают: «Эй, это не достаточно критичный случай, чтобы я мог управлять им с помощью этого инструмента». Тем не менее, есть и другие инструменты, которые у нас есть, и которые более Наверное, угождаю тем менее важным экземплярам SQL. Один из них похож на Менеджера инвентаризации, где мы проводим легкие проверки работоспособности экземпляров, но в дополнение к этому мы делаем обнаружение, поэтому мы идентифицируем новые экземпляры, которые были переведены в сеть, а затем, с этого момента, как администратор базы данных, я могу сказать: «Хорошо, вот новый экземпляр SQL, теперь это Express? Это бесплатная версия или версия для предприятий? ». Вероятно, это вопрос, который я хочу задать себе, но, во-вторых, насколько важен этот экземпляр для меня? Если это не так важно, я мог бы сделать так, чтобы этот инструмент выходил и выполнял его, общий, то, что я назвал бы общими проверками работоспособности, в том смысле, что они представляют собой элементарные типы вещей, о которых я забочусь как администратор баз данных: Заполняется ли накопитель? Сервер отвечает на проблемы? Главное, правда?
Принимая во внимание, что с Diagnostic Manager, инструмент, который я только что показал вам, он собирается перейти на уровень запросов, он собирается перейти к рекомендации по индексам, посмотреть на план выполнения и все такое хорошее, в то время как это в основном сфокусировано о том, кому что принадлежит, чем я владею и кто за это отвечает? Какие пакеты обновления и исправления у меня есть? И работают ли мои серверы с основными компонентами того, что я считаю здоровым экземпляром SQL? Итак, чтобы ответить на ваш вопрос, есть небольшая смесь. Когда у нас есть люди, которые смотрят на этот инструмент, они обычно смотрят на более критичный набор примеров. Тем не менее, у нас есть некоторые люди, которые покупают каждый экземпляр и управляют им, так что это просто зависит. Но я говорю вам, что в целом определенно существует порог тех людей, которые считают, что их среда достаточно важна, чтобы иметь такой инструмент для управления этими экземплярами.
Робин Блур: Хорошо, еще один вопрос, прежде чем я передам его Эрику. Создается впечатление, что, наблюдая за отраслью, создается впечатление, что у баз данных еще есть жизнь, но все данные перетекают во все эти озера данных и так далее, и так далее. Это обман, правда, и обман никогда не отражает реальность, поэтому мне интересно, какую реальность вы там воспринимаете? Являются ли важные базы данных в организации, они испытывают традиционный рост данных, который я привык считать 10% в год? Или они растут больше, чем это? Большие данные делают эти базы всплывающими? Какую картинку вы видите?
Bullett Manale: Я думаю, что во многих случаях некоторые данные перемещались в те другие сегменты, где это имеет больше смысла, когда появляются другие технологии, которые становятся доступными. В последнее время некоторые из больших данных. Но я бы сказал, что эти базы данных трудно обобщать во многих случаях, потому что все немного разные. Вообще говоря, я вижу некоторое расхождение. Я вижу, как я уже сказал, люди переходят на эластичные модели во многих случаях, потому что они хотят наращивать ресурсы, а не так сильно в других областях. Некоторые люди переходят на большие данные. Но, скажем так, сложно почувствовать восприятие, потому что, вообще говоря, люди, с которыми я общаюсь, имеют традиционные базы данных и используют это в среде SQL Server.
Тем не менее, я бы сказал, что с точки зрения самого SQL, я определенно думаю, что его завоевание доли рынка. И я думаю, что есть много людей, которые все еще стремятся к SQL из других мест, таких как Oracle, потому что он более доступный и, очевидно, очевиден, так как версии SQL становятся более продвинутыми - и вы видите это с более поздними событиями, которые происходят с SQL, с точки зрения шифрования и всех других возможностей, которые делают его средой или платформой базы данных - это, очевидно, очень важно для критически важных задач, я полагаю. Так что, думаю, я тоже это видел. Где вы видите сдвиг, это все еще происходит. Я имею в виду, что это происходило 10 лет назад, и, как мне кажется, все еще происходит с точки зрения SQL Server, где среда растет, а доля рынка растет.
Робин Блур: Хорошо, Эрик, я полагаю, у аудитории есть вопрос или два?
Эрик Кавана: Да, позвольте мне бросить один быстрый вам. Это довольно хороший вопрос, на самом деле. Один из участников спрашивает, будет ли этот инструмент сообщать мне, если таблице может понадобиться индекс для ускорения запроса? Если да, можете ли вы показать пример?
Bullett Manale: Да, так что я не знаю, есть ли у меня один для конкретного добавления индекса, но вы можете видеть здесь, у нас есть рекомендации фрагментации здесь. Я также просто верю, что мы только что это сделали, и это было частью Diagnostic Manager, предлагающего веб-версию, где он говорит мне, что у меня отсутствует индекс. И мы можем просмотреть эти рекомендации, и это расскажет нам о потенциальной выгоде от этого путем индексации этой информации. Еще одна вещь, которую я должен упомянуть, это то, что когда мы выполняем рекомендации, для многих из них для них будет создан сценарий. Это не хороший пример, но вы сможете увидеть, да, ситуации, когда индекс - или дублирующий индекс, или добавление индекса - улучшит производительность, и, как я уже говорил ранее, мы делаем много что с помощью анализа гипотетического индекса. Таким образом, это действительно помогает с точки зрения понимания рабочей нагрузки, чтобы иметь возможность применить это к рекомендации.
Эрик Кавана: Это отличная штука, и это даст мне хороший переход к последним комментариям здесь. Робин, я и Рик слышали уже много лет, что говорят о самонастраивающихся базах данных. Это самонастраивающаяся база данных! Все, что я могу вам сказать: не верьте им.
Bullett Manale: Не верьте обману.
Эрик Кавана: Могут быть небольшие мелочи, которые выполняются динамически, но даже если вы захотите проверить это и убедиться, что он не выполняет то, чего вы не хотите. Так что в течение некоторого времени нам понадобились такие инструменты, чтобы понять, что происходит на уровне базы данных, и, как сказал Робин, озёра данных - это увлекательная концепция, но, вероятно, вероятность того, что они вступят во владение, столь же высока, как и вероятность существования Лох-Несское чудовище в ближайшее время. Итак, я бы еще раз сказал, что в реальном мире много технологий баз данных, нам нужны люди, администраторы баз данных, чтобы посмотреть на это и синтезировать его. Вы можете сказать, что вам нужно знать, что вы делаете, чтобы этот материал работал. Но вам нужны инструменты, чтобы дать вам информацию, чтобы знать, что вы делаете. Итак, суть в том, что администраторы баз данных будут работать очень хорошо.
И большое спасибо Bullett Manale и нашим друзьям в IDERA. И конечно же Рик Шерман и Робин Блур. Мы архивируем все эти веб-трансляции, поэтому пройдите онлайн на сайте insideanalysis.com или на наш партнерский сайт www.techopedia.com для получения дополнительной информации обо всем этом.
И с этим, хорошо прощай, ребята. Еще раз спасибо, хорошо поговорим с вами в следующий раз. Береги себя. Пока-пока.