Спектакль: попрощайся с латентностью

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

Вывод: ведущий Эрик Кавана берет интервью у Марка Мэдсена, Деза Бланчфилда и Буллета Манале о задержке и производительности.

Вы не вошли в систему. Пожалуйста, войдите или зарегистрируйтесь, чтобы увидеть видео.

Techopedia Content Partner

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

• Профиль
• Интернет сайт

Эрик Кавана: Дамы и господа, здравствуйте и еще раз добро пожаловать в Hot Technologies! Да, в самом деле! Меня зовут Эрик Кавана, это наше шоу Hot Tech, партнерство с нашими хорошими друзьями из Техопедии. Посетите Techopedia.com онлайн, чтобы узнать все последние новости в области корпоративных технологий; они, конечно же, охватывают и потребительские товары. Здесь наша программа сосредоточена на предприятии, и именно этим мы и будем заниматься сегодня.

Есть место о твоем правдивом и достаточно обо мне, попадай на меня в Твиттере @eric_kavanagh, я люблю Твиттер, я люблю проверять такие вещи, это отличный способ оставаться на связи с людьми и иметь хорошие разговоры, и один на один одни разговоры.

Так о чем мы говорим? В этом году жарко, это целая вселенная возможностей, которую мы смотрим сегодня в мире управления информацией, и то, о чем мы говорим сегодня, будет запросами, ускорением запросов.

Я думаю, что забыл упомянуть название «Performance Play: попрощайтесь с латентностью». Ну, кто хочет латентность? Никто не хочет задержки, задержка - это когда вы сидите там, нажимаете кнопку и ждете, когда что-то случится, и никто этого не хочет. Детям это не нравится, они не думают, что это круто, взрослым это тоже не нравится. Мы все были избалованы скоростью интернета, и мы хотим чего-то быстро, мы хотим чего-то сейчас, и мы собираемся поговорить об этом сегодня на нашем шоу.

Аналитик Марк Мэдсен сегодня с нами из Третьей Природы, одного из наших постоянных клиентов. Наш новый специалист по данным Дез Бланчфилд звонит из Сиднея, Австралия. А потом Bullett Manale, да, действительно, это его имя, на самом деле это должны быть две буквы. Bullett Manale - наш гость из Idera, очень, очень интересной компании, которая делает много вещей. Я уже знаю о них, одним из которых является то, что они купили компанию под названием Precise некоторое время назад. Я знал, что их генеральный директор по имени Зохар Гилад, как это для имени? Он был чертовски умным парнем.

Но, ребята, вы играете значительную роль в этой веб-трансляции в вопросах, которые вы задаете, поэтому, пожалуйста, не стесняйтесь, присылайте свои вопросы в любое время - вы можете сделать это с помощью компонента Q & A консоли веб-трансляции, которая там внизу в нижнем правом углу. Вы также можете поговорить со мной, и я буду общаться с докладчиками. У нас уже есть кто-то звонящий из Италии, поэтому: «Чао, чао. Приходите, останьтесь? Хорошо, с этим я собираюсь выдвинуть первую линию Марка, я собираюсь передать колоду Марку. Марк, теперь у вас есть WebEx. Убери это, слово твое.

Марк Мэдсен: Спасибо, Эрик. Я не собираюсь начинать с середины, я начну с самого начала. Так что просто несколько комментариев, чтобы начать обсуждение с Dez и Idera, своего рода состоянием государства с разработкой, а также базами данных и операциями. И вы знаете, если вы посмотрите на это, у нас есть проблемы такого рода, которые все еще существуют на рынке баз данных и приложений, потому что разработчики рассматривают администраторов баз данных как людей, которые их беспокоят. Вы должны создавать модели данных, у вас нет доступа к ним, вы не можете создать это, вы не можете поместить индекс в каждый столбец каждой таблицы в базе данных, чтобы сделать это быстрее. И конечно, зачем нам модели? Это просто структуры данных, если мы их изменим, вы не можете просто записать их в сериализованную форму?

Проблема в том, что разработчики знают код и приложения, но они часто не знают, что такое параллелизм, параллельное программирование, базы данных и операционные системы под ними. Будучи разработчиком ядра и операционных систем и баз данных, я могу сказать, что параллелизм и параллелизм действительно сложны, и поэтому многие вещи, которые вы изучаете, чтобы получить хорошую производительность из своего кода, действительно начинают разваливаться, когда вы работа с базой данных. И производительность выглядит великолепно, среда тестирования выглядит великолепно, и среда вопросов и ответов, а затем она попадает в реальную систему, а потом вдруг не так уж и здорово. Поскольку он многогранен, то, как код работает с базой данных, как он работает со средой, и действительно простые небольшие практики могут иметь радикальные эффекты в зависимости от масштаба, в котором вы работаете.

И когда вы начинаете говорить о внешних приложениях, конечно, внешние приложения, веб-приложения, могут быть действительно сложными, потому что все хорошо, пока вдруг они не сглаживаются, и это не так. Вы попадете на эти интересные плато, которые требуют много нюансов, чтобы понять.

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

Если подумать, большинство администраторов баз данных работают в среде управления изменениями, а не в среде непрерывного развертывания. Все дело в стабильности и контроле, а не в скорости изменения и обратимости. Непрерывное развертывание, если вы не можете выйти из изменений, у вас проблемы, поэтому все должно быть построено так, чтобы быть легко обратимым и переключать код, что совсем не так, как работали реляционные базы данных, практики разработки и практики управления,

Вы также сталкиваетесь с этими проблемами, когда вам, как администратору базы данных, нужно быть более активным, потому что к тому времени, когда вы слышите о проблеме, сотни тысяч человек заполняют формы жалоб на вашем веб-сайте. Это оставляет вам необходимость в некоторых новых вещах, которые вы не получите из своей старой среды. Вы знаете, такие вещи, как лучший мониторинг и оповещение. В то же время, базы данных увеличивались, у нас было больше приложений, чем когда-либо, чтобы поддерживать больше вещей, чем когда-либо, они внутри, они снаружи, они повсюду. И больше независимых наборов данных для анализа, люди запускают базы данных повсюду, потому что, конечно, теперь легко, вы можете настроить виртуальную машину. Если у вас есть облачный провайдер или внутреннее облако, вы можете сразу же всплыть, и это изменит весь ваш путь закупок.

Старый путь закупок был: «У меня есть время, чтобы получить сервер, засунуть его в стойку, выделить место, получить хранилище, установить базу данных и делать что-то», в отличие от того, кто украл кредитную карту и ушел через пять минут. Если вы сделаете это, то современная среда разработки будет работать в совершенно ином темпе, и поэтому будет легко создавать базы данных, и это просто создаст проблему распространения, как мы никогда раньше не видели. И это продолжается уже десять лет, это ни для кого не новость, но это также означает, что операционная среда усложнилась.

Вся среда клиент-сервер действительно изменилась, потому что это уже не мир клиент-сервер. Тогда у вас был сервер, у вас была база данных, если что-то не так, вы знали, к какому серверу обращаться, вы знали, как управлять ресурсами на нем, потому что лучшей практикой была одна база данных, один сервер. Виртуализация начала разрушать это, облако еще больше разрушает, потому что то, что вы считаете сервером баз данных, это просто программное обеспечение. Так что среда не реальна. Это то, что содержит среду, которая является реальностью, и это может быть стойка блейд-серверов или большой сервер, разделенный на куски, вы на самом деле не знаете.

Все, что касается администрирования баз данных и управления производительностью, а также того, какие базы данных были построены вокруг жесткого контроля с одним сервером или с несколькими серверами и парой баз данных, вы не можете контролировать все. Вы сидите там на машине, но виртуальные менеджеры не могут легко разделить полосу пропускания, и поэтому все может быть хорошо с памятью и процессором, но вы находитесь в узком месте на каком-то ресурсе, с которым невозможно разобраться, и тогда, когда вы пытаетесь это исправить, старая модель была бы в тяжелом состоянии, получая больший сервер и делая что-то подобное, теперь это может быть очень просто, просто добавьте виртуальный курс, просто добавьте память в ВМ, и это будет решено. Но что произойдет, если ваша виртуальная машина находится на переполненном сервере и нуждается в миграции? Или что произойдет, если у вас размер системы AWS и максимальный размер достигнут, теперь куда вы идете?

Таким образом, у вас есть все эти проблемы, когда среда теперь является частью базы данных, вы упаковываете среду с базой данных, всеми специальными ресурсами, всем, что в приложении, это часть конфигурации, конфигурация выталкивается туда. Это из среды баз данных, намного сложнее управлять и контролировать.

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

Вы не можете позволить себе ложные оповещения, вы не можете позволить себе вещи, которые говорят: «Есть проблема с этой машиной, и эта машина содержит 30 баз данных». Вы не можете позволить себе, чтобы вещи не давали вам историю. Консоли мониторинга хороши, когда они загораются, но если красный свет снова становится зеленым, и вы не знаете почему, и у вас нет истории, чтобы вернуться к тому, что привело к этому, и к чему контекст был, у тебя проблемы. Нам нужны системы, которые будут следить за нами, нам нужен более качественный мониторинг, который решает серьезные проблемы, которые поддерживают эту историю данных.

Лучшие вещи и простые пороги метрик, которые дают нам ключевые метрики, но не направляют нас непосредственно к тому, что нормально, что ненормально и как часто возникают эти проблемы. То, о чем мы на самом деле говорим, - это сочетание среды мониторинга и работы с производительностью, а поставщики сидят в своих руках. Они не дали нам лучшие инструменты. У нас есть системы с большей ЦП и памятью, чем мы знаем, что со всем этим делать, и все же мы по-прежнему полагаемся на модели ручного вмешательства, мы не заставили машину работать, чтобы направлять нас, чтобы вывести нас к точке проблем мы не добрались до этого нового стиля: «Здесь есть проблема, вы можете сделать это, чтобы ее исправить», или «Есть проблема с производительностью, это на самом деле с этим конкретным оператором SQL, вот три вещи, которые вы могли бы используйте для исправления этого оператора SQL ». Применение эвристики, применение моделей машинного обучения, которые могут посмотреть на схемы использования вашей системы, чтобы обнаружить проблемы и избежать ложных предупреждений. Использование машины для того, чтобы делать то, что машина делает лучше всего, для расширения базы данных или для увеличения числа людей, которые сталкиваются с проблемами производительности.

Это новый способ, в отличие от старого стиля. Есть проблема с этой базой данных, все идет медленно, и поэтому у нас есть новые методы, новые способы сделать это, и мы должны применять их, и именно туда движется рынок. Вы видите, что он начинает возникать не с крупными поставщиками, а со сторонними компаниями, и это отражает то, что произошло 20 лет назад, когда поставщики баз данных не предоставили ни одной вещи для управления системами. Так вот каково направление рынка, и с этим я бы хотел вернуть его Эрику.

Эрик Кавана: Хорошо, я передам это Дезу. И Дез, убери это, слово твое.

Дез Бланчфилд: Спасибо, Марк. Вы проделали фантастическую работу по освещению его технической составляющей. Я собираюсь подойти к этому с несколько иной точки зрения, чтобы осветить то, что произошло в остальном мире, в том, что касается влияния на предприятия и базы данных вокруг них. Позвольте мне просто перейти к моему первому слайду.

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

Это все еще очень, очень горячая тема, и она была долгой и долгой историей в том, что касается современных технологий. К этому моменту, я считаю, это факт, что почти все, что мы делаем в нашей повседневной жизни, то есть в нашей повседневной жизни, теперь поддерживается некоторой формой базы данных. Когда мы думаем обо всем, что нас окружает, будь то счет, который приходит по почте каждый день за какую-то услугу, которую мы покупаем, он неизбежно печатается системой, которая обращается к базе данных, и мы находимся там. На наших телефонах есть базы данных с контактами и журналами вызовов и прочим.

Куда бы мы ни пошли, за разговорами и системами, которые мы используем, стоит некая форма базы данных, и чаще всего они довольно прозрачны для нас, но факт в том, что они есть. Поэтому я подумал, что быстро расскажу, почему это стало проблемой за очень короткий промежуток времени. В начале, концепция базы данных пришла от этого прекрасного джентльмена, Эдгара Кодда. Работая в IBM, он изменил мир в части управления данными, создав концепцию, которую мы сейчас называем реляционной базой данных.

В начале база данных была базой данных, и жизнь была хорошей, она была довольно простой, как по столбцам, так и по ссылкам и т. Д., А таблицы и разработка программного обеспечения были довольно простыми, а производительность не была такой уж большой проблемой - это была новая захватывающая технология. Мы обращались к базам данных через какую-то форму терминала, и вы действительно можете создать такой большой хаос только в конце терминала 3270 на мэйнфрейме, и неизменно других типов терминалов появились эти другие системы. И в большинстве случаев терминалы старого стиля были очень похожи на веб-среды сейчас, то есть вы должны были заполнить форму на экране самого терминала и нажать Enter, и он выключился. отбросьте как один пакет, как запрос, и внутренняя система будет иметь дело с этим. Это в основном то, что происходит в веб-браузере в наши дни, когда вы набираете ссылку в веб-браузере и эта форма обычно не возвращается в систему в реальном времени, хотя в наши дни с AJAX это не совсем кейс.

Но затем что-то случилось, пришло будущее, и совсем недавно, в Интернете, и почти вчера, в секунду в Web 2.0, и уже за углом у нас появился Интернет вещей. И в процессе будущего мир баз данных только что взорвался, и взаимодействие с базами данных стало тем, что мы все сделали по умолчанию, не было случая, чтобы вы куда-то делали что-то, например, покупали билет на самолет, и хотите поехать на другую сторону планеты, кто-то должен был ввести в терминал все ваши данные, зайти в базу данных и распечатать билет.

Почти все, что мы делаем сейчас, будь то приложение такси в Google с приложением, будь то интернет-банкинг, все, что мы делаем ежедневно, с какой-то системой, оно работает на базе данных. И когда появился Интернет, нам стало немного легче представить его, нашу повседневную жизнь через веб-браузер, а затем появилась веб-версия 2.0, и все стало мобильным, а масштабы просто взорвались. На самом деле, моя любимая тема в этой теме: «Интернет соединил все, веб 2.0 сделал его мобильным и социальным, и вещи стали очень, очень большими, и теперь у нас есть Интернет и все такое, и, наконец, IoT… Yikes !!» Мы даже не начали представлять влияние Интернета вещей, когда оно приходит в мир, на системы баз данных.

Таким образом, в современных терминах то, что мы привыкли считать терминалом, фактически превратилось в эти вещи: это мобильные телефоны, это различные виды планшетов, либо большие потребительские или корпоративные планшеты с большим экраном, это ноутбуки и это традиционный настольный компьютер в какой-то форме. На этом одном изображении вы можете видеть почти все формы интерфейса, которые мы сейчас используем для общения с системами баз данных и приложениями, которые работают на них, от маленьких гаджетов в наших руках, которые ходят вокруг, и мы, кажется, склеены, все путь к немного более крупным версиям, iPad, другим планшетам и Microsoft Surfaces, к повседневным ноутбукам, которые неизменно встречаются в профессиональной среде и т. д. Люди, как правило, приобретают ноутбук, а не стационарный компьютер, но, на мой взгляд, они являются современным терминалом и являются одной из причин того, что базы данных сталкиваются со всевозможными проблемами в части управления производительностью нашей жизни, а не только с разработкой.

Поэтому я предполагаю, что это одна из самых больших проблем, с которыми предприятия все еще сталкиваются в повседневной жизни. Все думали, что базы данных были нашими единственными проблемами, но это не так. Так в чем суета? Хорошо, когда мы переходим от одного конца к другому со всеми вещами, связанными с базами данных, с коммерческой точки зрения, и Марк очень хорошо освещает технические компоненты, но в коммерческом смысле, как организация, мы думаем о базах данных. Мы имеем дело с вещами, начиная с базового дизайна и разработки. Когда начинается бизнес, они думают о разработке приложений, разработке возможностей или даже реализации существующих приложений в той или иной форме. Должна иметь место некоторая форма проектирования и разработки, и необходимо много думать о том, как эти системы баз данных будут внедряться, поддерживаться и управляться, отслеживаться производительность и так далее.

Интеграция среды базы данных и приложений, а также типов API, типов доступа, которые предоставляются в настоящее время, становятся все более сложными и сложными. Повседневное администрирование, поддержка и резервное копирование, опять же, это то, что, как мы думали, было решено, но затем внезапно масштаб стал намного больше, и дела пошли быстрее, а объем стал намного больше; Размер баз данных системы баз данных должны были поддерживать скорость, с которой транзакции движутся.

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

И еще есть постоянно включенный мир, в котором мы живем сейчас, 24/7, не просто следовать за Солнцем, но всегда в полночь кто-то хочет что-то сделать, и рабочие часы следуют за Солнцем по всему миру. Таким образом, время безотказной работы и доступность по умолчанию являются климатом, поэтому отключение просто недопустимо. И избыточность, если есть проблема с производительностью или если нам нужно окно технического обслуживания для обновления, исправления или безопасности, на самом деле, мы должны иметь возможность переходить из одной среды баз данных в другую и делать это легко и автоматически.

Безопасность, стандарты и соответствие. В последнее время в мире произошли довольно большие события, в частности, GFC, и поэтому у нас есть целый ряд новых задач, связанных с соответствием, безопасностью и соответствием стандартам, и нам нужно чтобы иметь возможность сообщать о них в режиме реального времени и в идеале в виде панели инструментов. Мы не хотим отправлять команду обезьян в центр обработки данных, пытаясь что-то найти, нам нужна система, которая сообщит нам об этом немедленно, в режиме реального времени.

И два больших забавных, о которых почти никто никогда не говорит, мы обычно толкаем их под ковер и надеемся, что они никогда не поднимут свою уродливую голову, но аварийное восстановление и непрерывность бизнеса - это тоже вещи, которые должны, для большая часть, происходит автоматически, в случае необходимости.

Мы могли бы целыми днями говорить о типах вещей, которые могут пойти не так в средах баз данных, и о том, что люди обычно реагируют, но сейчас нам нужны системы и инструменты, чтобы сделать это для нас. Одним из примеров является утечка данных, и поэтому, когда мы думаем о базах данных, я задаю этот вопрос совершенно открыто в различных формах: что происходит с базами данных, когда мы отвлекаемся, и что-то критическое идет не так? Особенно, если нет системы, отслеживающей производительность и безопасность, а также другие важные аспекты работы баз данных.

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

Затем мы подошли к ключевому моменту всего этого путешествия, в котором мы прошли, а именно: зачем нам нужны лучшие системы? Почему мы не можем просто бросить больше тел в эту вещь, что мы хорошо и действительно пересекли переломный момент, на мой взгляд, и, конечно, я верю, что есть случай, который был доказан в последнее время, что бросали больше администраторов баз данных, администраторов и больше людей эта вещь не решает проблему. Нам нужен лучший набор инструментов и лучший набор систем.

Вот мои пять основных причин, по которым я считаю, поддерживают это, и они ранжируются в порядке важности, основываясь на том, что я вижу в этих частных предприятиях и штатах, которые являются управляемыми средами, проблемами, с которыми они сталкиваются в средах баз данных, и управлять ими.

Безопасность и соответствие - номер один. Вы знаете, контролируя, у кого есть доступ, где у них есть доступ, когда у них есть доступ, как часто у них есть доступ, откуда они получили к нему доступ. Потенциально устройства, к которым они действительно прикасались, и типы вещей, на которые они смотрели, и соответствие, которое происходит вокруг этого. Через 30 дней люди будут составлять отчеты, чтобы сообщить нам, все ли в порядке, просто больше не уместно, это должно происходить в реальном времени.

Производительность и мониторинг - кажется, что ежу понятно, но неизменно это не так. Независимо от того, используем ли мы инструменты с открытым исходным кодом или некоторые сторонние коммерческие инструменты, неизменно мы не пропустили лодку во многих отношениях с необходимыми типами мониторинга производительности и подробностями, а также возможностью своевременно реагировать,

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

Управление и администрация - опять же, мы думаем, что эти проблемы решены, но это не так. Цель проблем, с которыми сталкиваются команды баз данных, особенно администраторы баз данных, где система должна заботиться о нас за нас, мы еще не решили эту проблему, это все еще реально.

И с самого начала разработки и разработки, когда мы начинаем создавать эти инструменты, мы создаем среды баз данных, можем использовать соответствующие инструменты для разработки и тестирования, а также для интеграции платформ. Это по-прежнему нелегко для нас, и весь этот путь как бы подталкивает нас к одному и тому же сообщению о том, что, на мой взгляд, нам нужны более совершенные системы и более совершенные инструменты, чтобы помочь нам добиться результатов, которые нам нужны от наша среда баз данных, поэтому компании, которые повышают ценность наших клиентов. Мы не можем просто бросать больше тел и больше администраторов баз данных, масштаб слишком велик, скорость слишком высока, а объем слишком высок. С этим, Эрик, я могу вернуться к тебе.

Эрик Кавана: Я люблю это, у нас есть много материала, много потенциальных клиентов, и мы идем дальше и передаем ключи Буллетту всего за одну секунду.

Bullett Manale: Хорошо.

Эрик Кавана: О, давайте заберем это и Буллетт, теперь я передаю это вам, и вам слово.

Bullett Manale: Хорошо, спасибо. Я думаю, что было сделано много хороших замечаний. Я просто хотел на секунду побыстрее поговорить об Idera, кто мы, а потом мы прыгнем. Я собираюсь поговорить об инструменте, о котором, я думаю, многие из тех вещей, о которых мы говорим, мы можем вид и вид обсуждения некоторых областей, в которых они совпадают, с помощью этого инструмента, продукта Diagnostic Manager.

Теперь, то, что я хочу сделать в первую очередь, это просто дать вам представление о том, кто такая Idera; мы работаем примерно с 2003 года, и поэтому мы начали с использования только инструментов SQL Server, и именно на этом мы собираемся сконцентрироваться сегодня: продукт Diagnostic Manager. Но вы можете увидеть все, что у нас есть, и недавно, как уже упоминалось, мы приобрели Precise, и благодаря приобретению у нас также есть Embarcadero, и поэтому у нас есть довольно хороший портфель продуктов.

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

Я начал с того, что типичным пользователем нашего продукта был администратор баз данных, и поэтому, когда мы впервые общаемся с людьми, потенциальными клиентами, в основном мы говорим с администраторами баз данных. Мы не говорим с ИТ-менеджерами или директорами, возможно, в какой-то момент это может дойти до этого уровня, но с самого начала у администратора базы данных возникает проблема, он пытается решить проблему, и мы часто Пойдем, скачаем и опробуем продукт как часть этого. У вас либо менеджер данных, либо администратор баз данных, либо действующий администратор баз данных, парень, которому в некоторых случаях повезло быть самым техническим в этой области. Теперь, когда вы перейдете к более крупным корпоративным средам, очевидно, что вы получите полноценных администраторов баз данных, обычно это будут те, кто использует инструмент. И я пошел дальше и добавил сюда небольшую рекламу из Википедии. Это как бы переходит в обязанности DBA, как говорит Википедия, это то, что они делают.

Если вы пролистаете список здесь, многие из этих вещей, я не буду его зачитывать, но вы получите много типичных вещей, о которых вы могли подумать, а затем по одному из них вы получите мониторинг и оптимизация производительности базы данных, и это довольно большая. И что интересно, когда вы разговариваете с администратором базы данных, их всегда обвиняют первыми, когда речь идет о проблемах, и это может быть не их ошибкой, а когда возникает проблема с производительностью, как правило, с приложением, которое Он связан с базой данных DBA, и в этом виноваты они, поэтому они всегда ищут причины, по которым они не виноваты. Во многих случаях это то, что они могут использовать этот инструмент, Diagnostic Manager, чтобы помочь им сделать.

Но в конце концов, также, если база данных не работает, то многие другие вещи не имеют значения, ваши приложения не работают, тогда для многих из них это не имеет значения. вещи. Прежде всего, мы хотим быть в состоянии убедиться, что пользовательский опыт, как мы его знаем, не уменьшен, это то, к чему всегда стремятся администраторы баз данных. И я думаю, что если вы посмотрите на причины, по которым люди обычно покупают и используют продукт SQL Diagnostic Manager, то это одна из первых причин, вероятно, не самая главная, не последняя и не последняя, ​​но она в некотором роде одинакова, и в зависимости от того, с кем вы разговариваете, эти причины, почти одна или две из них всегда, есть какая-то необходимость вокруг.

Но первое - просто иметь возможность иметь централизованное представление экземпляров как SQL, которым они управляют. И забавно то, что во многих случаях, если вы спросите администратора баз данных: «Сколько экземпляров вы управляете?» Число меняется так часто, что в некоторых случаях они не совсем уверены. Так что вам нужно нечто большее, чем просто выкинуть все на экран. Вы хотите захватить эту информацию, вы хотите понять ее, и поэтому одна из вещей, с которой определенно может помочь Diagnostic Manager, - это предоставить вам такой взгляд на окружающую среду.

И это не просто представление об окружающей среде, а представление о том, что администратору базы данных удобно работать с базой данных, и это, если хотите, консоль, ориентированная на администраторов баз данных. Это сделано для администратора базы данных. Есть много инструментов для мониторинга, есть много инструментов для повышения производительности, но, как я сказал, в конце концов, администратор баз данных хочет инструмент, разработанный для администраторов баз данных, потому что есть много вещей, специфичных для того, что они делают. в их день ото дня.

И с учетом сказанного, у вас есть SCOM, у вас есть HPF, у вас есть все эти другие технологии, но они хотят чего-то особенного для того, что они делают. Я думаю, что мы можем помочь в этой области с этим продуктом, вы увидите, когда мы в него войдем через секунду. Другая вещь, которую мы видим с администратором базы данных, что, безусловно, является одной из вещей, к которой мы также обращались ранее, это то, что они должны иметь возможность видеть, что происходит, и они должны иметь возможность просматривать все предприятие. и иметь некоторое спокойствие, зная, что происходит. Но в то же время они не сидят и смотрят на консоли.

Помните все те пулевые пункты, которые вы видели в этом списке, которые я только что поднял? Они должны делать и другие вещи, так что это не просто ожидание тушения пожаров. Во многих случаях будут собрания или многие окна обслуживания, связанные с администратором базы данных, запускаются посреди ночи, когда они спят, поэтому они должны иметь возможность вернуться и посмотреть, что произошло, Во многих случаях, если вы не улавливаете что-то, когда это происходит, когда проблема исчезла или, по крайней мере, с SQL Server, это становится своего рода проблемой, когда вы сталкиваетесь с ситуацией, когда вы этого не делаете. есть какие-то остатки этой проблемы больше. И эти проблемы исчезают, как и остатки, а это означает, что у вас меньше проблем, у вас меньше информации для работы.

С учетом вышесказанного, безусловно, одна из вещей, с которыми может помочь Diagnostic Manager, - это дать вам представление о прошлом, чтобы запросить информацию из прошлого: «У меня было предупреждение о блокировке, были ли у меня проблемы с блокировкой, у нас были вещи, которые происходили с точки зрения наших ресурсов? »Я могу вернуться и запросить эту информацию. Я могу углубиться в конкретные моменты времени. Я мог бы делать все эти вещи прямо из инструмента.

Все эти вещи, независимо от того, является ли это внутренним или внешним приложением, администратор БД хочет знать, потому что он хочет видеть причину проблемы. Неважно, если кто-то внутри организации или кто-то вне организации написал код; они все еще хотят быть в состоянии изолировать это, чтобы они знали, что проблема происходит, и они знают, откуда она исходит.

Таким образом, производительность и ответственность являются ключевой частью того, что делает наш продукт. Мы можем предоставить все эти детали, и, что приятно, у вас есть возможность углубиться в детали. Если есть узкое место, вы можете соотнести это с приложением, с пользователем, с базой данных, с запросом. И еще раз, это своего рода дымящийся пистолет. Вы получаете прямую корреляцию между тем, когда этот запрос выполняется, что он делает? И речь идет не только о самом запросе, с точки зрения его выполнения, но и ухудшается ли запрос с течением времени? И на эти вещи тоже можно ответить, с продуктом, который определенно является чем-то таким, что, если вы пытаетесь быть упреждающим, приятно иметь возможность сказать: «Эй, вот запрос, который не удался, но мальчик, посмотрите на него по мере того, как он движется дальше, мы видим, что он работает еще хуже и хуже, я могу с этим что-то сделать ».

Если мы пойдем в следующую область здесь; и это, вероятно, - я бы сказал, что это один из самых больших. Один из вопросов, которые я задаю, когда я показываю наш продукт, я всегда спрашиваю администратора базы данных: «Как вы узнаете о проблеме, связанной с вашими базами данных SQL Server?» И это очень забавно, потому что большую часть времени - теперь, конечно, большую часть времени они смотрят на наш продукт, потому что во многих случаях они пытаются удовлетворить конкретную потребность. Но интересно услышать первоначальный тип вещей - по крайней мере, с SQL Server, - это то, что в начале SQL Server у вас был SQL Server, а затем Oracle. И у всех был Oracle, и SQL Server был своего рода, из-за отсутствия лучшего выражения, рыжеволосым пасынком баз данных, когда он только начинался.

А затем, когда Microsoft добавила к нему больше возможностей, она стала немного более корпоративным инструментом. И, очевидно, с тех пор прошло долгий путь. Но дело в том, что однажды вы могли утверждать, что базы данных не считались критическими в те времена. И это изменилось с течением времени. Из-за этого во многих случаях люди пытаются обойти это и говорят: «Знаете что? У меня есть все эти базы данных SQL Server, я пытаюсь разобраться с этим. «И вместо того, чтобы слышать о проблемах из справочной службы или слышать о проблемах от конкретных людей, которые - как и сами пользователи, они» Они ищут способы обойти это. Они ищут способы, чтобы быть в курсе этих ситуаций, прежде чем они когда-либо произойдут.

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

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

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

И последнее, что также стоит отметить, - это то, что мы можем добавить и фактически обмениваться данными как с vCenter, так и с Hyper-V, чтобы иметь возможность извлекать метрики из этих сред. Потому что одна из вещей, которые мы определили с администратором базы данных, заключается в том, что они обычно не являются частью операций конкретно. И они, как правило, не обязательно имеют, вы знаете, доступную для них среду vCenter или подобные им вещи.

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

У вас есть возможность добавлять эти другие типы счетчиков в инструмент. Теперь речь идет не только о возможности контролировать эти счетчики, но и о том, чтобы сделать новые счетчики, которые вы вводите в продукт, сделать их частью инструмента, как если бы они были готовой метрикой, Готовая вещь, которую вы хотели бы отслеживать; так что это означает возможность включать их в свои панели. Это означает, что вы можете добавлять их в свои собственные пользовательские отчеты, иметь возможность явно устанавливать пороговые значения и оповещать о них, а также устанавливать их базовые уровни и иметь возможность устанавливать пороговые значения с некоторым знанием того, где их устанавливать, основываясь на таких вещах, как ваш базовые показатели и что нормально. Итак, у вас есть много таких вещей, которые также есть в продукте.

Что-то вроде того, что я вам предоставил, - это то, что я называю «основными результатами для Diagnostic Manager», и я могу пойти дальше и просто дать вам небольшой вкус, войдя в продукт. Что я собираюсь сделать, так это поделитесь моим экраном, хорошо, и просто собираюсь перетащить это. Итак, что вы увидите, это консоль для Diagnostic Manager. И, как я упоминал ранее, переходя к первому основному результату, возможность взглянуть на вещи с точки зрения корпоративного уровня. В инструменте есть много разных примеров этого. У нас есть своего рода миниатюрное представление, у нас более сеточное представление. У нас также есть, с точки зрения гибкости, мы у вас также есть веб-консоль. У веб-консоли есть и другие доступные вам представления, такие как карты клавиш и тому подобное. Но дело в том, что у вас есть такая возможность смотреть и видеть вещи на высоком уровне. Но когда возникают проблемы, вы собираетесь немного углубиться в инструмент и фактически увидеть конкретную проблему lems, и есть какой-то способ понять и узнать, что происходит. И, очевидно, это очень важно.

Теперь, с точки зрения возможности реально увидеть, что произошло в прошлом; если я смотрю на проблему, которая произошла вчера или неделю назад, то в этой ситуации, вы знаете, вам понадобится иметь возможность обратиться к конкретному экземпляру SQL. И хорошей новостью является то, что если вы знаете, в какое время возникла эта проблема в продукте, вы можете перейти непосредственно в браузер истории. И я могу указать на конкретное время дня; это может быть пару недель назад, это может быть со вчерашнего дня. Но какой бы день я ни выбрал в календаре, мне будут представлены разные интервалы опроса. В этом случае сейчас я вижу то, что увидел бы, если бы смотрел консоль 20 апреля в 13:37.

Так что я могу вернуться назад во времени, а затем, как только я это сделаю, все различные вкладки, которые мы здесь видим, будут отражать этот конкретный момент времени, включая запросы, которые могли работать плохо, в том числе, возможно, если У меня были сеансы с блокировкой. Все подобные вещи будут отображаться в инструменте, и это позволит мне, очевидно, использовать эту историческую информацию, чтобы иметь возможность, вы знаете, решить проблему. Теперь, на этой ноте, когда мы говорим об истории, здесь стоит отметить еще одну вещь - это не просто использование истории для решения проблем. Эта история очень ценна, очевидно, по другим причинам. И одним из самых важных является умение принимать решения эффективно и быстро принимать решения, используя правильную информацию. Таким образом, всю эту историю, всю информацию, которую мы собираем, мы можем сообщить против.

Если кто-то придет ко мне и скажет: «Я получил это действительно отличное новое приложение. Оно изменит мир, каким мы его знаем. О, кстати, ему потребуется база данных, и, о, кстати, это действительно будет привязывать Ввод / вывод на компьютере, где находится эта база данных. " Если я знаю об этом, то могу использовать эту информацию, чтобы иметь возможность ранжировать все свои производственные серверы, основываясь, возможно, на последних семи днях сбора. И я мог бы очень быстро прийти к выводу, на каких случаях наиболее целесообразно использовать эту базу данных. Так что это тот тип исторической информации, который также, очевидно, очень ценный.

С точки зрения самих запросов; с точки зрения рассмотрения запросов, у нас есть много разных способов сделать это в инструменте. И мне нравится смотреть на Query Waits View, потому что Query Waits View очень полезен с точки зрения возможности оценки. Если у меня возникает узкое место, чтобы иметь возможность идентифицировать все различные области, которые влияют на этот конкретный конкретный запрос; не только сам запрос и каков результат этого запроса, но также, вы знаете, из какого приложения он пришел, из какого сеанса он пришел, какой пользователь вызвал его и все такое, я могу видеть эту, очевидно, информацию в режиме реального времени, но у меня также есть возможность просматривать эти данные из прошлого. И вот одна из вещей здесь, и я запустил сценарий, но я должен ждать, пока он не появится.

Пока мы ждем этого, я хочу - и я знаю, что у нас мало времени, поэтому я хотел немного поговорить и о предупреждении уведомлений о проактивности. И когда вы говорите о таких вещах, как я уже сказал, будучи проактивной частью, есть много инструментов, которые делают оповещения. Сложная часть не отправка электронной почты. Трудная часть не записывает в журнал событий или генерирует SNMP-ловушку. Сложнее всего знать, когда отправлять это оповещение в подходящее время. И вот с этим часто приходится делать некоторые вычисления, понимать: «Что это за конкретный экземпляр и что нормально в отношении этого экземпляра?»

И поэтому для всех метрик, которые имеют смысл делать, мы определяем эти метрики. Мы на самом деле покажем вам базовую линию, мы покажем вам пороговое значение, которое в данный момент установлено. И еще одна приятная вещь об этом, скажем, я установил свои пороги в этом случае шесть и десять только для этого примера. Через шесть недель, если я вернусь к этому экземпляру, эта базовая линия может полностью измениться, потому что одна из вещей, которые мы делаем, когда мы вычисляем базовую линию, по умолчанию, это скользящий семидневный расчет. Так что это всегда дает мне актуальную версию базовой линии. И что произойдет, если эта базовая линия переместится в мои пороги? В этом случае я вижу и предупреждаю рекомендации, которые в основном гласят: «Эй, у вас есть порог, который, вероятно, установлен неправильно, специфично для того, где мы видим порог, и, очевидно, где базовый уровень, вы, вероятно, собираетесь получать оповещение о чем-то, что является нормальным явлением. "

И поэтому вместо того, чтобы лечить симптом чего-то нормального, я могу определить тип ситуации, в которой фактический порог установлен неправильно. И это, очевидно, позволяет мне устанавливать пороговые значения в соответствии с тем, где я собираюсь получить предупреждение. Я знаю, что это скорее призыв к действию, чем расследование, чтобы понять, действительно ли это проблема. И я думаю, что эта часть инструмента действительно полезна с точки зрения самой базовой линии и возможности расчета.

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

Теперь, что касается ответа, так это то, что в некоторых случаях да, я могу отправить электронное письмо, или я могу отстрелить и сгенерировать ловушку SNMP, или записать в журнал событий. Есть много других вещей, которые мы можем сделать, но, когда я говорю с администраторами баз данных, то, что им действительно нравится, так это то, что в большинстве случаев большая часть выполняемой работы является повторяющейся. Это то, что они точно знают, когда возникает проблема, что нужно сделать, чтобы ее исправить. Они просто должны пойти и вмешаться. И по мере того, как вы будете расширять свою среду, когда у вас будет больше экземпляров, это станет намного сложнее сделать. Таким образом, одна из вещей, которую вы можете сделать в инструменте, который, я думаю, стоит отметить, - у вас есть возможность установить условие, но на основе этого условия можно задать ответ для запуска сценария, для запуска работа, чтобы запустить исполняемый файл. И дело в том, что если вы решите запустить сценарий, я могу использовать параметры внутри этого сценария, которые будут во время выполнения заполнены фактической информацией.

Таким образом, если есть проблемы с конкретной базой данных, сценарий будет спроектирован так, чтобы работать только с той базой данных, где происходит проблема. Таким образом, вы можете динамически решать проблемы в автоматическом режиме, и тогда я все еще могу получить электронное письмо, чтобы вернуться и сказать мне, что «Эй, была проблема, но, кстати, она была исправлена». Сценарий был запущен, и как администратор БД вы знаете об этом, но вам не нужно было вмешиваться и вмешиваться. Теперь, на той же заметке о проактивности, очевидно, у нас здесь есть еще одна функция, которая является функцией «Анализ». И что он будет делать, так это регулярно проверять экземпляр SQL. И, в некоторых случаях, он сделает более глубокое погружение с точки зрения того, что он ищет. Такие вещи, как анализ гипотетического индекса будут выполнены. Добавить индекс? Удалить индекс? И все эти вещи, очевидно, помогут с моей игрой, но, опять же, это все проактивность. Речь идет о возможности принимать решения до того, как что-то сломается, и заставить его работать лучше. И во многих случаях именно это мы и пытаемся сделать здесь.

Возвращаясь к Query Waits, о которых мы говорили ранее; как видите, здесь большой всплеск. Ранее я запускал скрипт, который просто вызывал некоторую активность ожидания, и, как я уже говорил, у нас есть действительно уникальный способ углубиться в эту информацию. Если я хочу посмотреть, какое это было приложение; Я вижу, это было из приложения NoSQL. Мы сможем увидеть базу данных, к которой она была привязана, сеанс, пользователя, а затем, если захочу, я смогу также ранжировать это с точки зрения моих ожиданий. Итак, я могу сказать, что из всех ожиданий, которые происходили в это время, какие из них происходили чаще всего? И если я увижу, что когда это произошло чаще всего, то очень приятно, что я могу перейти к этому типу ожидания и увидеть все команды. Если вы посмотрите здесь, они заставили это ожидание произойти. И я также вижу, в первую очередь, какое приложение было, что заставляло происходить ожидание.

Так что он торчит как больной палец. Я могу сразу же пойти и сказать: «Это приложение вызывает мое узкое место. Теперь какой запрос был запущен? Какой пользователь запускал его? С какой базой данных он работал?» И т. Д. Так что, надеюсь, это имеет смысл, и это также помогает с точки зрения обеспечения того, что у вас нет задержки в вашей среде, поскольку это относится к вашим базам данных. Надеюсь, это полезно. Я собираюсь пойти дальше и передать его обратно, и я думаю, мы можем продолжить оттуда.

Эрик Кавана: Конечно. Так что, думаю, я просто скину это нашим экспертам дня. Марк, может, сначала вы захотите прокомментировать и задать пару вопросов. Тогда Дез, ты можешь войти.

Марк Мэдсен: Да, спасибо, мне очень понравилось наблюдать за этим. Это гораздо более интеллектуальный мониторинг, чем я привык видеть. Мне любопытно с управлением данными за этим; Управление метриками, которые вы можете отслеживать, и вы знаете, ищите такие вещи, как смещение базовых линий, в частности, что является одной из моих любимых болевых точек, с панелями мониторинга. Как вы справляетесь с этими данными, и вторая часть этого связана с базовыми метриками, например, с типом сдвига - у вас есть возможность автоматически сдвигать пороговые значения, чтобы мне не пришлось вернуться назад и сбросить пороги вручную, когда базовая линия сместится?

Bullett Manale: Да, и так хорошо, что вы можете решить это. Вы можете сделать либо. Я могу установить порог и сделать его статическим, или я могу установить флажок «Сделать это динамическим порогом, который будет меняться при изменении моих базовых показателей». И у меня есть возможность и инструмент для установки окна по умолчанию. времени для моей базовой линии. Но тогда, если мне нужно, у меня может быть отдельное окно базовой линии, например, из моего окна обслуживания с 2:00 утра, скажем, до 5:00 утра, потому что я собираюсь облагать налогом свою Процессор, мои диски и все остальное, потому что именно тогда мы выполняем все техническое обслуживание. Затем он автоматически, если бы я выбрал его, автоматически настроил мои пороги так, чтобы они находились за пределами того, что является нормальным для тех показателей, которые Я решил сделать это с помощью. Это позволило бы мне сделать это. По сути, у вас есть возможность в инструменте устанавливать окна времени, которые являются вашими базовыми окнами, и каждое окно может рассматриваться как отдельная сущность, с точки зрения динамическая настройка базовой линии, которая может быть сделана. И вы можете добавить столько окон своей базовой линии, сколько вы Вам нужно, если это имеет смысл. У вас может быть окно выходных, будний день в рабочее время, окно обслуживания, которое происходит посреди ночи, и так далее, и так далее.

Марк Мэдсен: Спасибо.

Bullett Manale: Думаю, вернемся к первой части вопроса, которую мы имеем, и соберем всю эту информацию. Я на самом деле не говорил об архитектуре, но у нас есть внутренний репозиторий, который позволяет полностью контролировать хранение этих данных, но у нас также есть служба, которая работает посреди ночи, которая идет и делает все наши базовые расчеты, и он берет эти данные, собирает и имеет смысл их. И, конечно же, наряду с этим у вас также есть многочисленные отчеты, которые мы можем использовать для составления отчетов по вашим базовым показателям, по конкретным показателям. И у вас даже есть возможность сравнивать базовые показатели одного и того же сервера по одному и тому же показателю за разные периоды времени. Вы можете видеть, есть ли различия, которые произошли, или какова дельта. Таких вариантов тоже много.

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

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

Bullett Manale: Я бы сказал, что в большинстве случаев мы видим это в производственных средах. Это зависит от ситуации, но по большей части я бы сказал, в первую очередь, производство, и мы это делаем, и, честно говоря, справедливо отметить, что у нас разные цены для сред разработки и тестирования, так что это немного более привлекательно. Мы видим людей, использующих его для этих сред, но я бы сказал, что если бы мне пришлось дать вам ответ тем или иным способом, я бы сказал, что в основном это все еще производственные среды, в которых мы видим, как люди вкладывают средства в этот продукт.,

Дез Бланчфилд: Конечно, да, и было интересно услышать, что у вас разные ценовые ориентиры, потому что очевидно, что есть разные нагрузки, и чем тяжелее будет работа, где будет выполняться вся настоящая работа. Но я вижу много организаций, особенно в правительстве и, конечно, в обороне, где развитие сейчас требует того же уровня инвестиций в инструменты и системы, что и производственные среды, потому что они проводят гораздо более предварительное тестирование. Например, в области защиты есть команды, которые проводят миллиарды тестов, сотни миллиардов тестов приложений, систем и инструментов и отслеживают их, даже не переходя к интеграционному тестированию, потому что они хотят убедиться, что есть созданный код и база данных. он сидит под ним. Он достигает итерации в сто один миллион или около того, пока вы находитесь в поле, стреляя в кого-то, это не идет «на ура».

Bullett Manale: Конечно.

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

Bullett Manale: Ну, это сложно сказать. Я имею в виду, как я сказал по большей части, люди, с которыми мы в любом случае имеем дело с точки зрения процесса продажи, это практикующие, которые являются администраторами баз данных. Итак, с точки зрения вашего вопроса вы просто говорите: «В целом, люди в ИТ-организации становятся более осведомленными о базе данных?» Я думаю, это вопрос, и я бы сказал, что, вероятно, ответ «да». Я, наверное, не вижу этого слишком часто, исходя из того, где я нахожусь, изо дня в день, но я думаю, что, если я понимаю ваш вопрос, я думаю, это был бы мой ответ.

Дез Бланчфилд: Да, все в порядке. Это, вероятно, очень сложный вопрос, извините, потому что, очевидно, ваши главные интересы в вашем мире - это техническая сторона вещей. Мне любопытно, что в своей повседневной деятельности я вижу, как организации начинают вносить это в разговор очень рано. Итак, когда они говорят о новых инициативах, новых проектах, новых программах работы, одна из вещей, которые приходят сразу же, это: «Как мы отслеживаем это, как мы отслеживаем это, как решаем проблемы по мере их возникновения, в отличие от запуска, собирается жить? "

Bullett Manale: я бы сказал, что -

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

Bullett Manale: Я собирался сказать, что я вижу тенденцию, я думаю, я должен сказать - вы знаете, много раз в прошлом вы получали: «У нас были проблемы, и поэтому сейчас нам нужен инструмент. " И я думаю, что мы видим немного больше признания вокруг наличия инструмента до того, как проблема возникнет, если это имеет смысл. Так что я бы сказал, что это определенно становится более нормальным, вы знаете: «Эй, нам нужен инструмент мониторинга, нам нужно что-то». И люди определенно видят ценность этого продукта, потому что, как вы сказали ранее, просто добавление администраторов баз данных и добавляя новые экземпляры, вам нужно что-то, что управляет этим. Вам нужно что-то, что помогает в управлении этим, и именно поэтому мы наблюдаем широкое признание и в отношении этого продукта, или у нас есть.

Дез Бланчфилд: Быстрый вопрос. Где это нужно жить? Должен ли он находиться на заднем плане в локальной сети, в центре обработки данных, как можно ближе к средам баз данных, или он удобно расположен где-то, потенциально в облаке, в стороннем облаке с чем-то вроде VPN-туннель или удаленный доступ к различным средам? Где это должно сидеть, когда речь идет об окружающей среде и мониторинге?

Bullett Manale: с точки зрения архитектуры, есть внутренний репозиторий, и это база данных SQL Server. У нас есть консоль, которая может быть либо толстым клиентом, либо тонким клиентом; мы даем вам возможность обоих. И у нас также есть тонкий клиент, который действительно предназначен специально для мобильных устройств. Но с точки зрения того, где это может сидеть; он может находиться в окружающей среде, действительно сложнее всего из той информации, которую нам нужно собрать, требует административных прав, в некоторых случаях или во многих случаях. Теперь мы не заставляем вас делать это; если вы хотите, вы можете собирать данные и просто о вещах, которые мы не можем собрать, потому что у нас нет прав администратора, мы просто позволим вам не видеть эту информацию, если это ваш выбор.

В зависимости от вида, как, например, если вы говорите об AWS, в некоторых средах он работает лучше, чем в других, но в той же мере, что и сама среда, обычно используется аутентификация SA для сбора данных по экземплярам. Или, если это ненадежный домен, это обычно, когда вы хотите сделать это, но несколько доменов; до тех пор, пока между ними существует доверие, мы можем собирать против них. На самом деле не имеет значения, находится ли он в локальной сети или в глобальной сети, сам фактический сбор довольно незначителен с точки зрения количества данных, которые мы собираем. Если у нас достаточно WAN-соединения достаточного размера, это не проблема. Я видел среды, где у них есть филиалы, где у них есть SQL-серверы по всей территории Соединенных Штатов. И это один сервер в каждом из этих разных мест, и они контролируют его централизованно. Сложная задача - просто убедиться, что у вас есть приличное количество подключений для этого. Надеюсь, это ответит на ваш вопрос, это было как бы по всей карте.

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

Bullett Manale: всегда будет небольшое влияние, потому что он должен запросить экземпляр SQL Server, чтобы получить данные обратно. Вопрос, как вы сказали, таков: "Это незначительно или это важно?" Из коробки вы указываете на экземпляр, это незначительно. Как я уже говорил, мы занимаемся этим довольно давно. У нас более 20 000 клиентов, и я могу заверить вас, что, если это окажет значительное влияние на производительность, мы не будем в бизнесе. При этом мы также позволяем пользователю решать, что он хочет отслеживать. Поэтому я думаю, что важно упомянуть, что каждая среда немного отличается.

Например, с компонентом мониторинга запросов мы можем установить порог того, что вы считаете своей границей нормальности. Так что это может быть основано на времени выполнения запроса. Он может быть основан на процессоре, вводе / выводе, но в качестве примера, скажем так, я установил время выполнения на ноль миллисекунд. Эффективно, что я говорю инструменту, чтобы собрать все запросы, которые выполнялись с момента последнего интервала извлечения, и также сделать эту часть моей исторической коллекции.

Теперь, когда мы это сделаем, мы будем собирать любое количество запросов, которые мы выполняли на коробке с момента последнего опроса. Теперь это по выбору, и пользователь имеет возможность сделать это. Говорим ли мы: «Это то, что вы должны делать»? Нет. Но мы также даем вам возможность сделать это в случае, если вы хотите получить образец данных, который позволяет вам собирать эту информацию. В общем, у вас есть средства в рамках инструмент для его настройки и точной настройки в зависимости от того, что вам удобно, но у вас есть возможность по-настоящему открыть его, если хотите, и собрать много дополнительной информации, которую вы не обязательно регулярно собирать, если это имеет смысл.

Дез Бланчфилд: Да, абсолютно. Я знаю, что мы бежим немного долго, но есть два действительно замечательных вопроса, которые я хочу задать вам, прежде чем подведу итоги. Они оба приходят ко мне, но я думаю, что лучше, если вы ответите на них. Как правило, вопрос звучал так: «Какова область охвата инструмента в плане знания существующих систем?». Итак, можем ли мы просто подключить его, и он автоматически обнаружит платформу, которая там есть, и узнает, что нормально для этой платформы, и сразу Поднимите, как говорил Марк ранее? Некоторые из базовых знаний о платформах, применив, вы знаете, я не знаю, что это может быть Microsoft Dynamics. Каков объем знаний о платформе с тем, что обычно и в некоторых из текущих готовых инструментов, которые используются в бизнесе?

Bullett Manale: Я бы сказал, что, вообще говоря, когда мы начинаем собирать данные об экземпляре SQL, мы начинаем работать с лучшими практиками с точки зрения наших пороговых значений и того, где они установлены. Тем не менее, мы также признаем, что с кем бы вы ни говорили, с точки зрения лучших практик, каждая среда отличается. Что мы будем делать изначально: мы просто собираем данные, и, что мы рекомендуем людям, вы можете попробовать продукт на 14 дней дольше, если вам нужно. Но примерно через два дня вы начнете видеть заполнение базовых данных. Как только у него будет достаточно информации для примера, он начнет предоставлять вам контекст с точки зрения базовой линии, диапазона и тому подобного. Затем оттуда, если вы хотите, вы можете автоматически устанавливать свои пороговые значения из той информации, которая была собрана. Для того, чтобы определить, что является нормальным, требуется немного первоначального сбора и опроса, чтобы вы могли начать сдвигать свои пороговые значения.

Но, на мой взгляд, стоит также отметить, что когда вы изменяете эти пороговые значения, это может быть сделано для каждой группы в отдельности. Это может быть характерно для одного экземпляра, или вы можете сделать это для всех ваших экземпляров, а также для возможности создавать такие вещи, как шаблоны, так что вы можете сказать: «Это производственный экземпляр, но это шаблон, который я хочу назначить ему. " И поэтому, когда новый производственный экземпляр подключается к сети, мы автоматически применяем к нему эти пороговые значения, поскольку у него одинаковое оборудование и обычно одинаковые рабочие нагрузки, поэтому мы могли бы сделать это также. Надеюсь, это поможет с точки зрения вопроса.

Дез Бланчфилд: Это так. На самом деле, вы на самом деле ответили на другой вопрос, который только что пришел ко мне, и который был, "Есть ли пробная загрузка?" Есть, я могу ответить на это, я знаю. Я уверен, что вы подтвердите, что есть бесплатная загрузка, и я думаю, что вы сказали, что это было 14 дней с сайта. Вы можете скачать его и играть с ним. Я думаю, быстро с этим, хотя: «Какая среда мне нужна, чтобы иметь возможность запустить пробную версию? Могу ли я запустить ее на своем ноутбуке и поиграть с ней или мне действительно нужен сервер?»

Bullett Manale: Главное, что ему нужно - это репозиторий, база данных SQL Server 2005 или выше. Помимо этого, есть некоторые минимальные требования к ресурсам, требования .NET, и все. Так что это просто вопрос установки продукта и создания базы данных.

Дез Бланчфилд: Отлично. Последний вопрос, который я задам вам, потому что сейчас у нас просто не хватает времени, но быстро, примерно два или три человека спросили меня: «Нужно ли мне быть администратором баз данных, чтобы действительно иметь возможность начать работу с и поиграть с этим?

Bullett Manale: Нет. Я бы сказал, что если вы являетесь администратором баз данных, у вас будет другое применение инструмента. Я имею в виду, что если вы опытный администратор баз данных, то, возможно, вам будет немного выгоднее. Вы увидите гораздо больше глубины инструмента, которым сможете воспользоваться. Но также как новый администратор БД или даже человек, который, не БД, у нас есть много рекомендаций, и я сейчас на этой странице. Эти рекомендации будут появляться на регулярной основе, и что самое приятное в рекомендациях, так это то, что они предоставляют вам причины, по которым эти рекомендации выполняются. Но в дополнение к этому у них также будут ссылки на внешний контент, которые более подробно описывают причины, по которым эти рекомендации также делаются. Так что это будет ссылаться на внешние веб-сайты Microsoft, блоги и тому подобное, это внешнее.

Но, чтобы ответить на ваш вопрос, вы знаете, если вы старший администратор баз данных, то здесь есть кое-что, что вы, вероятно, воспользуетесь преимуществами, которых вы, вероятно, не стали бы начинающими администраторами баз данных. Но в то же время это своего рода инструмент обучения, потому что, когда вы будете проходить через эти рекомендации, вы начнете изучать некоторые из них самостоятельно, используя рекомендации.

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

Bullett Manale: Да, это правильно, и я думаю, что вы ссылаетесь на веб-сайт community.idera.com. И еще одна вещь, о которой я бы упомянул ранее, о которой вы спросили: «Будет ли она распознавать окружающую среду?» Что касается новых экземпляров или добавления экземпляров, у нас есть еще один инструмент, который выполняет обнаружение экземпляров. И все дело в инвентаре и управлении вашим инвентарем. Я просто хотел бы указать вам в этом направлении, с точки зрения фактического обнаружения случаев. Но что касается собственно производительности и мониторинга, всего того, о чем мы говорили, вот где в дело вступит Менеджер диагностики.

Дез Бланчфилд: Фантастика. Смотри, отличный охват. Очень понравилась твоя презентация. Мне понравилась живая демоверсия, и это все от меня сегодня утром, поскольку я знаю, что прошло 10 минут с течением времени. Эрик, я собираюсь вернуться к тебе.

Эрик Кавана: Хорошо. Я просто любил демо. Я рад, что вы сделали демо. Я рад, что мы внимательно посмотрели на это, когда проходили вопросы и ответы.

Bullett Manale: Отлично.

Эрик Кавана: Потому что это дает людям представление о том, на что ты смотришь, и меня действительно удивляет мысль, что мы все еще учимся тому, как разговаривать с этими компьютерами, когда ты приступаешь к этому. Я имею в виду, что этот уровень диагностики довольно сложный, и он улучшается с каждым днем. Мы получаем гораздо больше понимания того, что на самом деле происходит. Но вам действительно нужен человек, который упускает из виду этот материал, читает его, помещает эту познавательную способность в основу того, что вы делаете, не так ли?

Bullett Manale: Да, я имею в виду во многих случаях - я хотел бы сказать вам, что это DBA в коробке, но слишком много всего происходит. Я имею в виду, что мы предоставляем руководство и помогаем, но в конечном итоге это требует, чтобы люди принимали решения относительно данных, которые мы представляем. Я не думаю, что это скоро изменится.

Эрик Кавана: Это хорошая новость для настоящих людей, ребята.

Bullett Manale: Это верно.

Эрик Кавана: Вы захотите, чтобы кто-то смотрел это, команда наблюдала за этим, и вы узнаете, как вы слышали от Буллета, что, взглянув на эти рекомендации, вы поймете, что происходит. И я полагаю из этой истории, и я думаю, что вы затронули это, Буллетт, но очень быстро, эта история позволяет вам распознать значительные закономерности и, следовательно, быть в состоянии идентифицировать их, когда они произойдут в будущем, верно?

Bullett Manale: Это правильно. Одна из вещей, которые мы можем сделать, это отслеживать производительность запроса с течением времени. Мы также можем, очевидно, смотреть на другие вещи, такие как базовые показатели, и видеть их смещение, и, очевидно, получать оповещения и тому подобное, когда это происходит, поэтому у вас определенно есть такая возможность.

Эрик Кавана: Звучит хорошо, ребята. Мы не были бы здесь долго, но я хотел добраться до этих вопросов. Большое спасибо за ваше время и внимание. Мы делаем архив всех этих веб-трансляций. Перейдите онлайн на Techopedia.com или InsideAnalysis.com, вы увидите ссылки из обоих мест.

И с этим мы прощаемся с вами. Еще раз спасибо, ребята, мы встретимся с вами на следующей неделе, еще три веб-трансляции на следующей неделе, вторник, среда, четверг. Так что мы поговорим с вами на следующей неделе, ребята. Береги себя. Пока-пока.

Techopedia Content Partner

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

• Профиль
• Интернет сайт