Всем привет. 26 февраля в OTUS стартовали занятия в новой группе по курсу «MS SQL Server разработчик». В связи с этим я хочу поделиться с вами своей публикацией про оконные функции. Кстати, в ближайшую неделю еще можно записаться в группу ;-).

---

Оконные функции прочно вошли в нашу практику, но мало кто знает как работают фреймы RANGE и ROWS.

Возможно поэтому они несколько реже встречаются. Цель этой статьи привести примеры использования, чтобы у вас точно не осталось вопросов “Кто есть кто?” и “Как это применять?”. Вопрос “Зачем?” в статье останется не освещенным.

Давайте разберемся что такое фрейм, и как схожего эффекта достичь с помощью ORDER By в предложении OVER().

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

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

Сначала небольшое введение о том, что же такое Collation. В SQL Server параметр Collation указывает серверу, как нужно сортировать и сравнивать строки. Вот, например, строки “Apple” и “apple”. Они разные или нет? Это зависит от указанного Collation. Если с регистром все более менее понятно, то что делать с примером “елка” и “ёлка”? Считать их как одинаковые или как разные? Это все тоже в Collation.

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

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

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

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

Почему нужно рассказывать о таких случаях, если вы разработчик?

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

Друзья, в конце января у нас стартует новый курс под названием «MS SQL Server разработчик». В преддверии его запуска мы попросили преподавателя курса, Кристину Кучерову, подготовить авторскую статью. Эта статья будет вам полезна, если у вас есть очень популярная таблица на проде с доступом 24/7 и вдруг неожиданно вы поняли, что срочно нужно добавить индекс и ничего не сломать в процессе.

Итак, что же делать? Традиционный способ CREATE INDEX WITH (ONLINE = ON) вам не подходит, потому что, например, вызывает падение системы и сердечный приступ вашего ДБА, все топы пристально следят за response time вашей системы и в случае увеличения оного приходят к вам и вашему ДБА на разговор по поводу завышенных цифр вашей компенсации за труд.

Скрипты и описанные приёмы были использованы на системе с нагрузкой 400К requests per minute, версии SQL Server 2012 и 2016 (Enterprise).

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

Кейс № 1. Маленькая, но очень популярная таблица

Таблица 50 тыс. записей (небольшая), но очень популярная (несколько тысяч обращений в минуту). Вам нужен новый индекс и минимальное время простоя и блокировок на таблице.
В приложении весь доступ к БД только через процедуры.

При ошибке приложение сделает повторную попытку обратится к таблице.

5 сентября в Москве состоялся Круглый стол «Архитектор ИТ проекта» в ВШЭ. Организатор круглого стола, Максим Смирнов, ведет блог про архитектуру и канал на Facebook.

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

На круглом столе было представлено 4 доклада по 15-20 минут, после чего были вопросы из аудитории и обсуждение.

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

Статья о том, как решали задачу оптимизации процесса удаления файлов из шардированной системы. Речь пойдет о проекте для совместного доступа и работы с файлами. Система была стартапом лет 8 назад, потом он успешно выстрелил и был несколько раз продан. В проекте 4 разработчика, которые с проектом с самого начала, что очень ценно. Документацию, традиционно, либо не успели написать, либо она не очень актуальна.

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

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

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



Международная конференция CMG impact ежегодно проводится американской ассоциацией специалистов в области улучшения производительности IT систем. Ежегодная конференция CMG проводится с 1980 года.

Конференция посвящена Performance engineering and capacity planning (улучшение производительности и планирование пропускной способности). Организаторы, докладчики и участники конференции – это высококвалифицированные специалисты в IT или в области capacity planning, многие из которых начинали работать еще на мейнфреймах, потом ушли в распределенные системы, и в настоящее время продолжают работать в ведущих компаниях отрасли. Квалификация многих из них поражает воображение. На конференции были компании или их представители, которые относятся к мониторингу или тестированию производительности Dynatrace, NewRelic, Soasta, Jmeter, BMC, Moviri, BezNext и многие другие.

Возможно, многие сталкивались с исторически сложившейся за годы, до появления на проекте, ситуацией, когда на таблице создали все возможные индексы со всеми include’ами. Я видела индекс на доставшейся «в наследство» БД, который содержал все поля таблицы. При этом, не всегда есть возможность быстро поменять индексы, так как часто нужна гарантия, что изменения не повлияют на работоспособность системы.

При росте объема таблицы становится мучительно больно за бесцельно занятое место, но просто так индекс уже не убьешь, а статистика использования показывает, что индекс используется.
Описаный пример консолидации индексов на высоконагруженной БД, работающей в режиме 24/7. Приложение использует только хранимые процедуры. Версия MS SQL Server 2012 SP3.

Иногда, при дизайне БД разработчики недооценивают масштабы проекта. А потом, проект выстреливает и становится высоконагруженным. Затем, в какой-то момент, кто-то замечает, что в качестве первичного ключа большой таблицы выбран identity типа INT, с ограничением 2,147,483,647.

Изначально кажется, что 2 миллиарда записей – это много. Но если, у вас ежедневно добавляется 10 млн. новых записей? И уже израсходовано более 1 млрд. значений? У вас приложение, работающее в режиме 24/7? То у вас осталось всего 114 дней, чтобы это исправить тип первичного ключа. Это не так уж и много, если у вас используется значение ключа как в веб-приложении, так и в клиентском.

В статье описаны проблемы при проектировании баз данных и немного всего приложения, которые потом с ростом проекта все сложнее и сложнее решить. Моменты, которые важно учесть на этапе дизайна, и не задумываться о них в последствии. Ну или задумываться за чашкой чая и фразой «А помнишь, как мы решили это сделать сразу? Сколько времени мы этим себе сэкономили!», а не с ощущением зубной боли и болезненном вздрагивании при каждом воспоминании. По мере роста системы и числа пользователей, дизайн базы все сложнее и сложнее изменить, и масштаб изменений становится все более глобальным и трудоемким.

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

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

Я работала ведущим разработчиком в компании и, когда проект стал расширяться, стали брать еще людей и меня сделали руководителем группы. Так вышло, что я долго упиралась и хотела быть хорошим разработчиком, и чтобы от меня все отстали с руководством людьми. Через много лет, моему руководителю, все-таки, удалось меня научить как руководить, но этот путь был долгим и трудным. Я недавно прочитала статью "Delegation as Art" и вспомнила грабли, по которым прошла не один раз. Вот они во всей красе:

Это моя задача!. «Я ее хочу решить и никому не хочу отдавать. Как же я отдам эту задачу другому человеку, мне же так интересно придумывать и воплощать, а потом смотреть, как замечательно все работает.»

Сборник вредных советов, составленный по собственным ошибкам и ошибкам моих руководителей, а также руководителей друзей и знакомых.

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

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

Хочу поделиться интересными и полезными приемами в организации процессов компании в США. Я 9 лет работала в одной продуктовой компании, с момента окончания института, там было много хорошего, но мне с какого-то момента стало интересно «а как у других?». Примерно 8 месяцев назад мне постучался HR и позвал на собеседование в проектную компанию на позицию DBA для работы на компанию из США. В этот момент я работала на позиции заместителя технического директора. Такое предложение было довольно неожиданным, я не отнеслась к нему серьезно – посмотреть как у других хотелось, но не с таким резким снижением в карьере. Но, я согласилась прийти на собеседование – интересен был процесс.