Microsoft SQL Server

Однажды в моем инстаграме появились сразу несколько блоков рекламы по поводу ознакомительных курсов нескольких Российских онлайн-школ на тему "Аналитика данных на Python для чайников". Подумав о том, что можно с пользой для себя провести несколько часов и прокачать свои навыки по анализу, я записался и посетил данные курсы. Самое забавное, что практически все что я видел начиналось словами: "Давайте выбросим MS Excel (далее с вашего позволения просто - "эксель") и начнем работать на Python". Возмущению моему не было предела. В разумных рамках. Пройдя свой путь от разработчика (до черти как это назвать) и постоянно работая с данными, могу только привести в ответ фразу знаменитого персонажа Alf - "Вы просто не умеете их готовить".

О лицензировании MS SQL по подключениям (CAL)

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

В процессе подготовки инструмента для автоматического определения субъекта РФ по точке (тип данных Point) потребовалась таблица вида "Субъект РФ" - "geography::Object".

Предыстория: есть большой автопарк (>1000 ТС), который отправляет свои координаты на сервер в составе данных "Машина" - "Момент времени UTC" - "geography::Point". На сервере есть вторая таблица определенных событий по транспортному средству в составе данных "Машина" - "Момент времени (местное время)" - "Событие". Две задачи - перевести время во второй таблице из местного в UTC и далее использовать обе таблицы для дальнейшей автоматизации аналитики по событиям ТС в привязке к субъектам РФ.

Поиск в гугле по фразе "geojson субъекты РФ" привел на страницу https://gist.github.com/max107/6571147 - на ней в формате JSON перечислены субъекты и списки точек координат - границ.

Если вы пробежитесь по тексту, то структура этого JSON такая: на верхнем уровне один блок - один субъект. На следующем уровне вниз - блоки с нумерацией от 0 до, кажется, 19. Это означает, что субъект состоит из нескольких областей и каждая из них - это отдельный полигон (многоугольник). В файле нет Крыма, Севастополя. В файле не выделены Москва и СПб. Крым я дорисую сам, а Мск и СПб для моих задач не принципиальны.

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

Скорее всего есть более простые способы решения этой задачи, но, решая её поэтапно, удалось более детально разобраться в структуре объектов, попробовать методы работы с пространственными данными.

Имеем запрос вида:

insert into LocalDatabaseName.dbo.TableName (column1, column2, ..., columnN)

select column1, column2, ..., columnN

from LinkedServerName.RemoteDatabaseName.dbo.TableName

Столкнулся с тем, что подобный запрос выполняется на 40k (40000) записей больше минуты. С ростом количества подобных запросов или количества записей, производительность сильно падает и оптимизировать запрос средствами SQL никак нельзя.

С помощью приложения ImportExportDataSql мне удалось ускорить этот запрос до 2 секунд, не используя LinkedServer.

Мой Дорогой Друг Шон недавно написал пост, рассказывающий о том, как люди неправильно обслуживают индексы. Я собираюсь зайти немного дальше и поговорить о том, что сам метод, которым ваш скрипт, обслуживающий индексы, оценивает фрагментацию индексов - неправильный.

Если вы посмотрите на то, как ваш скрипт решает нужно или нет перестраивать индексы, и тоже самое касается планов обслуживания (я запускал ПРОФАЙЛЕР ДА ЗДРАВСТВУЕТ ПРОФАЙЛЕР ВПЕРЁД ПРОФАЙЛЕР чтобы проверить), вы увидите, что они выполняют запрос к sys.dm_db_index_physical_stats.

Все эти запросы используют столбец avg_fragmentation_in_percent, чтобы понять - нужно ли перестроить индекс

Однажды мне потребовалось забирать регулярно относительно большие объемы данных в MS SQL из PostgreSQL. Неожиданно выяснилось, что самый очевидный способ, через Linked Server на родные ODBC к PostgreSQL, очень медленный.

... с объектной ориентированностью, сериализацией, reflection, полиморфизмом, визуальным программированием, no-code, блэкджеком и шлюхами - и это на MS SQL 6.5 в 1995 году!

Знакомые с историей IT при слове "однозвенка" вспомнят dBase и Clipper. Однако, я расскажу об ERP однозвенке на MS SQL. Интерфейсная программа для этой ERP общалась с базой через несколько интерфейсных таблиц и несколько процедур. То есть фактически она является браузером, который за слой не считается. Да, это #ненормальное программирование, которое дало ряд уникальных свойств.

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

Привет!

Сегодня мы выпустили DataGrip 2021.1: наш самый мощный релиз за последние годы. И это не шутка!

Отправляем графики (peformance, да и вообще все что угодно) по почте с PROD серверов, куда просто так не добраться .

Мужик! Графики по почте? Что, cерьезно? Web интерфейс, интерактивность, Grafana - "нет, не слышал"? Ты бы еще звездочками графики нарисовал бы в письме, ASCII art-ом. - говорит мне мой воображаемый оппонент.

Конечно, он абсолютно прав в идеальном, воображаемом мире. Это вам подтвердит любой пролетающий там розовый единорог. Однако, если мы не в стартапе, а в кровавом enterprise, то все не так розово.

В SQL Server наименьшая единица хранения — это страница в 8 КБ с 96-байтовым заголовком, в котором хранится системная информация. 

Данные в таблицах могут быть организованы двумя способами:

Кластерный индекс  (clustered index)

Данные хранятся в виде B+ — дерева в соответствии с заданным ключом кластерного индекса. SQL Server сохраняет строки в правильной логической последовательности.

Куча (heap)

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

Пару лет назад, в разговоре с кем-то промелькнула примерно такая фраза: "Мы используем In-Memory OLTP - это очень быстро, зачастую даже вместо временных таблиц создаём In-Memory и всем советуем". Спустя какое-то время, мне задали вопрос как можно держать одну таблицу в памяти, чтобы работать с ней максимально быстро. Выяснив подробности - небольшая таблица, данные должны храниться только за последние несколько минут, суммарно не больше 10000 записей "приемлемых" (не LOB) типов данных, потеря данных при перезагрузке/файловере не страшна и даже приветствуется. In-Memory OLTP, без тени сомнения ответил я.

Перед запуском в продакшн я излазил всю документацию, проводил свои тесты - просто огонь. Работает реально быстро, таблица SCHEMA_ONLY и IO не генерирует вообще (я же умный, смотрю sys.dm_io_virtual_file_statss до и после). С обращениями через natively compiled stored procedures - не просто быстро работает, летает. Одним словом мечта.

Правда, оказалось, что у моей мечты есть тёмная сторона.

Я думаю, что все уже знают мое мнение о MERGE и почему я держусь от него подальше. Но вот еще один антипаттерн, который я постоянно встречаю, когда требуется выполнить UPSERT (UPdate inSERT — обновить строку, если она существует, и вставить, если ее нет):

При всем моем двадцатилетнем опыте работы с MS SQL Server и SSIS (когда-то еще DTS), никогда не любил хранимые процедуры с возвращаемым значением. Не знаю, почему так сложилось. Может быть потому, что «хранимки» чаще приходилось использовать для реализации какой-то логики или возвращении набора записей, а для получения одного значения — применял функции. Ну, так вот сложилось. Подразумеваю, что нелюбовь эта взаимная, что подтвердилось в последнем проекте, где хоть убей, но надо было с SSIS присваивать переменным возвращаемые значения процедуры. Изначально, пакет был не мой, а другого разработчика. Ничего плохого говорить не буду, все было сделано достаточно грамотно.

В прошлом году мы активно взялись за быстродействие больших тяжелых баз данных в нашем облаке. На первый взгляд казалось, что у нас только 2 варианта: недорогие СХД с медленными дисками или очень дорогие СХД – с быстрыми. 

Мы же хотели ускорить работу высоконагруженных баз данных Microsoft SQL и при этом предложить клиентам выгодную стоимость услуги. В результате тестов мы собрали решение "Кластер для нагруженных баз данных Microsoft SQL в облаке". Сегодня заглянем внутрь и добавим чуть больше технических вводных и конкретных цифр. 

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

Проблема

Эта статья не является ответом на множество вопросов по базам данных (БД) и системам управлениям базами данных (СУБД). Я как автор выражаю своё собственное мнение о  трендах, стараясь опираться на беспристрастные показатели, статистики и т.д., но для примера приводя собственный опыт. Я не являюсь ангажированным представителем какой-либо компании и выражаю точку зрения опираясь на опыт более 25 лет работы с разными СУБД, в том числе, которую создавал своими руками. Не так много даже опытных программистов и архитекторов, которые знают все термины, технологии, какие подводные камни и куда идёт движение. Тема поистине огромная, поэтому в рамках одной статьи не раскрыть даже верхний уровень информации. Если кто-то не встретит свою любимую СУБД или её невероятный плюс, который стоит упомянуть, то прошу в комментариях указать и этим дополнить общую картину, что поможет другим разобраться и понять лучше предметную область. Поехали!

Open Source DBMS vs Commercial DBMS

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