Найм специалиста по SqlServer OLTP. Какой опыт или требования мне нужно искать? [закрыто]

Question

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

Для некоторого фона мы внесли изменения в схему, чтобы денормализовать фрагменты данных, оптимизировали каждый запрос, запустили несколько советников по настройке базы данных, чтобы правильно настроить наши индексы, настроили параметры сервера MSSql.

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

У кого-нибудь есть какие-либо советы или опыт найма администраторов баз данных OLTP? Какие вопросы мы можем задать администратору базы данных во время собеседования?

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

Answer 1

Хорошо, это говорит мне кое-что:

  

Для некоторого фона мы внесли изменения в схему, чтобы денормализовать фрагменты данных, оптимизировали каждый запрос, запустили несколько советников по настройке базы данных, чтобы правильно настроить наши индексы, настроили параметры сервера MSSql.

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

Проблема в том, что многие администраторы баз данных не являются на самом деле программистами, они больше занимаются вопросами системного администрирования. Вам нужен программист DBA, который не только действительно хорош в TSQL, но и знает ваш другой язык (языки) программирования.

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

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

Answer 2

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

Несколько идей:

<Ол>

Возьмите самый сложный запрос, который вы оптимизировали, передайте его администратору-кандидату с QA и попросите его / ее оптимизировать его снова. Пусть они опишут, что они сделали и как они это сделали.

Убедитесь, что этот человек понимает аппаратное обеспечение, когда вы будете использовать несколько файловых групп, raid-массивы, разбиение данных, производительность 64 или 32 бита и т. д.

Ищите кого-то, у кого также есть некоторый опыт архитектуры программного обеспечения.

Задайте им несколько более сложных вопросов, например, о SQL-сервере. Что такое ЗАВЕРШЕНИЕ? Являются ли GUID хорошими первичными ключами и почему предпочтительнее использовать int int?

Answer 3

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

Спросите, почему они выбрали эту технику.

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

Answer 4

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

Этот метод очень быстро отличит мужчин от мальчиков.

Answer 5

Насколько вы близки к максимальной производительности БД? Очень легко создать проблему OLTP, которая неразрешима с этой технологией. Как сказал Эрик, полная модернизация архитектуры может быть в порядке. Больше оперативной памяти, просто добавьте больше оперативной памяти :)

Answer 6

Конечно, не видя базы данных, трудно сказать, что может быть лучшим способом оптимизации. Учитывая то, что вы сделали, скорее всего, вам нужно нанять дизайнера баз данных - тот, у кого есть опыт проектирования и настройки баз данных в имеющемся диапазоне размеров. Спрашивая, как они будут подходить к проблеме, посмотрите, будет ли интервьюер сначала смотреть на плохо выполняющиеся запросы и запускать профилировщик, чтобы увидеть, что происходит, и определить их. Человек должен быть в состоянии ответить на конкретные вопросы о сниффинге параметров и о том, как его избежать, какие методы можно использовать, чтобы избегать курсоров, зачем обновлять статистику, что делает запрос сортируемым. Есть некоторые общие вещи, на которые я хотел бы обратить внимание при настройке производительности. Не исчерпана ли сеть (иногда это не база данных), плохо продуман общий дизайн, используете ли вы код SQl, который в целом работает плохо? Если все ваши поиски разрешают использовать подстановочный знак в качестве первого символа, например, даже невозможно получить их быстро. Если ваши объединения используют естественные ключи из нескольких столбцов, они работают медленнее, чем должны быть. Храните ли вы более одной информации в поле, что вызывает много манипуляций для возврата данных? Вы используете курсоры? Вы используете функции? Вы повторно используете код, когда не должны быть? Вы всегда возвращаете минимально необходимую информацию? Вы закрываете соединения? Вы получаете тупики? Строки вашей таблицы слишком широки? У вас слишком много записей в определенных таблицах (удаление старых записей или их помещение в архивную базу данных может иметь огромное значение)? Какая часть вашего кода ориентирована на строки и не ориентирована на множество? Это примеры того, на что должен смотреть опытный специалист по базам данных, и, следовательно, того, о чем ему следует говорить в интервью.

Некоторые плохие примеры кода (вы знаете, что уже оптимизировали) могут дать вам хорошее представление об их подходе к настройке. Вы хотите кого-то, кто методичен и имеет глубокие знания SQL.

Есть несколько хороших книг по настройке производительности - я бы посоветовал взять их и познакомиться с ними перед собеседованием.