Система управления реляционными базами данных
Написание нового кода = ошибки. С этим всё просто.
Избавится от ошибок – вот это сложная задача.
Программисты привыкли, что в их средствах разработки есть встроенные инструменты, показывающие, какая строка кода сейчас работает, отображают текущее содержимое переменных, выводят сообщения о процессе выполнения и т.д. Какое-то время в SQL Server Management Studio тоже был отладчик кода, но, начиная с версии SSMS v18, он был удален. Хотя даже когда отладчик был, я не фанател от него: SQL Server буквально мог прекратить обработку других запросов, пока выполнял ваш запрос. Это была катастрофа, особенно когда ваш запрос блокировал других пользователей, и всё это происходило на рабочей базе.
Мне бы хотелось, чтобы у нас был простой способ отладки T-SQL на рабочей базе без блокировок, но отладка T-SQL отличается от отладки в C#. Так что если ваш T-SQL код делает не то, что вы ожидали, вот несколько хороших способов для его отладки.
Данные временных рядов — это набор значений, упорядоченных так, как они появляются и поступают для обработки. В отличие от транзакционных данных SQL Server, которые не зависят от времени и могут часто обновляться, данные временных рядов обычно записываются один раз и, если обновляются, то крайне редко.
Вот несколько примеров данных временных рядов: цены на акции, телеметрия от датчиков, счётчики производительности SQL Server (например, утилизация ЦПУ, памяти, устройств ввода‑вывода и сети).
Данные временных рядов часто используются для сравнений в истории наблюдений, обнаружения аномалий и уведомления о достижении заданного порога, прогнозного анализа и составления отчетов, где время является осью значений при просмотре или анализе данных.
Привет! Я Владимир Колосков, ведущий разработчик в Softpoint. Сегодня я хочу поделиться своими соображениями по поводу миграции больших и огромных БД с MSSQL Server на PostgreSQL: зачем это делать, стоит ли это делать сейчас и как я вижу такой переход.
Сразу пару слов про «Почему с SQL Server?» и «Почему на PostgreSQL?».
Самая распространенная в России платформа для бизнес-систем – это 1С:Предприятие 8. Причем в компаниях любого размера. Исторически платформа работала всегда с MS SQL Server. Есть, конечно, инсталляции и на других СУБД, но их крайне мало в общей массе. А связке 1С+MSSQL Server уже не один десяток лет, она отлажена, понятна и более-менее предсказуема. На основании собственного опыта и опыта Softpoint могу уверенно утверждать, что если в компании есть крупная ИТ-система, то она почти всегда на MSSQL Server (даже если это не 1С). И чем больше база данных, тем сложнее компании решиться на миграцию, т.к. это длительный процесс, с серьезным функциональным и нагрузочным тестированием, не укладывающийся ни в одно технологическое окно. А перспектива простоев ИТ-систем в бизнесе – такое себе.
Что касается вопроса «Почему на PostgreSQL?», то на данный момент других вариантов просто нет, ниже по тексту я разверну это утверждение.
Одна из целей статьи – показать, что использование гетерогенной информационной системы как инструмента перехода с одной СУБД на другую – это очень оправданный шаг как с экономической точки зрения, так и с учетом возможных рисков. Это позволит, с одной стороны, пользоваться и хранить данные в привычной СУБД, которая годами и десятилетиями оттачивалась крупным вендором, и которая имеет минимальные нарекания в производительности, в поддержке, в ошибках. А, с другой стороны, параллельно пользоваться СУБД с открытым исходным кодом, анализировать ее поведение при таком же профиле нагрузки, плавно увеличивать нагрузку, проводить тестирование столько времени, сколько нужно.
Я очень люблю визуализации. Человек лучше всего воспринимает информацию через образы. Для трех часто встречающихся баз (MSSQL, Postgres и MySQL) я смастерил плагины к проекту Bell, хотя этот код на Python можно использовать и отдельно. Поэтому для каждой визуализации я буду в скобочках писать имя файла из репозитория GitHub - вы можете этот файл вытащить и использовать его отдельно от проекта (для этого нудны минимальные модификации).
Отмечу только, что я считаю себя экспертом только в MSSQL, а то что сделал с другими базами - сделал по наитию. Кроме того, в отличие от MSSQL у меня нет реальных баз под большой нагрузкой для Postgres и MySQL. Поэтому ошибки/пожелания для скриптов Postgres и MySQL очень и очень welcome!
В основном я задействовал TreeMap.
В этой статье мы обсудим, как устроен агрегат WITH ROLLUP. Использование предложения WITH ROLLUP позволяет выполнить несколько «уровней» агрегации в одном операторе. Например, предположим, что у нас есть некие данные о продажах (это те же данные, которые я использовал в серии статей об операторе PIVOT).
Виртуальные файлы журналов (Virtual Log Files – VLF) — это внутреннее разбиение реальных физических файлов, которое создает Database Engine SQL Server для работы с журналом транзакций. У VLF нет четко определенного размера, и их количество на один физический файл не является фиксированным. VLF создаются компонентом Database Engine во время создания или расширения файлов журналов. Размер VLF рассчитывается динамически на основе размеров существующего журнала и нового файла приращения. За VLF, однако, числится дурная слава, которая заключается в том, что слишком большое количество VLF может вызвать ряд проблем, среди которых можно выделить существенное снижение скорости запуска базы данных, операции резервного копирования и восстановления журналов. Чем больше VLF было сгененрировано, тем дольше процесс восстановления базы данных, что может привести к превышению времени ожидания, ошибкам, связанным с памятью, и целому ряду других проблемам.
Вы когда-нибудь задавались вопросом, насколько Extended Events влияют на производительность вашей рабочей нагрузки? Я много писал о Extended Events и был активным сторонником их использования в качестве альтернативы SQL Trace даже дольше, чем я работаю на SQLskills.com. Но хоть Extended Events и дают нам множество преимуществ при сборе данных с минимальными накладными расходами, все же бывают случаи, когда нам не обойтись без дополнительных накладных расходов на наблюдение даже при использовании Extended Events.
Хорошо, если у вас небольшие (сотни гигабайт) базы, а ночью или в выходные вы можете себе позволить иметь 'maintenance window' и дефрагментировать таблицы. А если нет? В любом случае дефрагментация многих терабайт может занять дни, так что существование maintenance window становится непринципиальным.
Case study: многие терабайты данных, деятельность связанная с процессингом карт (24/7, maintenance window нет в принципе), MSSQL. Разумеется, Enterprise Edition, разумеется AlwaysOn.
Миф: у нас SSD, поэтому дефрагментация нам не нужна. Еще как нужна! Часто в высоко нагруженных системах не делают дефрагментацию, потому что это сложно. В итоге процент фрагментации выходит на уровень почти 100%, и таблицы занимают в два раза больше страниц, чем нужно. В два раза больше места - это в два раза хуже Buffer Cache Hits Ratio. Это в два раза больше размер full backups. Это в два раза дольше full table scans. Это выше CPU (потому что страницы перемещаются с помощью процессора, а не сами по себе).
Рассмотрим следующий пример:
CREATE TABLE T (PK INT PRIMARY KEY, A INT, B INT)
CREATE INDEX TA ON T(A)
CREATE UNIQUE INDEX TB ON T(B)
INSERT T VALUES (0, 0, 0)
INSERT T VALUES (1, 1, 1)
Теперь предположим, что мы выполним обновление:
UPDATE T SET A = 1 – A
Это изменение влияет на кластерный индекс (PK__T__15502E78) и на некластерный индекс TA. План в значительной степени такой, какой мы ожидали:
|--Clustered Index Update(OBJECT:([T].[PK__T__15502E78]), OBJECT:([T].[TA]), SET:([T].[A] = [Expr1003]))
|--Compute Scalar(DEFINE:([Expr1016]=[Expr1016]))
|--Compute Scalar(DEFINE:([Expr1016]=CASE WHEN [Expr1004] THEN (1) ELSE (0) END))
|--Compute Scalar(DEFINE:([Expr1003]=(1)-[T].[A], [Expr1004]=CASE WHEN [T].[A] = ((1)-[T].[A]) THEN (1) ELSE (0) END))
|--Top(ROWCOUNT est 0)
|--Clustered Index Scan(OBJECT:([T].[PK__T__15502E78]))
Это типичный «узкий» план обновления. В одном операторе обновления затрагиваются кластерный и некластерный индексы. План содержит Compute Scalar, которые определяют, нужно ли изменять соответствующую строку некластерного индекса. О подобных планах я писал в этой статье.
Оперативно узнавать о новостях MS SQL Server можно в телеграмм-канале: MS SQL Server - дело тонкое...
1С работает с СУБД Postgres более 10 лет, а сейчас это единственный легальный вариант для инсталляций в России. Много ли мы потеряем в производительности по сравнению с MS SQL ? Выдержит ли Postgres 15.2 жесткий Highload со стороны 1С? Цель этой статьи - ответить на данные вопросы, с цифрами, которые можно использовать при расчете архитектуры.
Хочется поделиться опытом преображения одного представления кода в другой с помощью ETL процесса и графовой базы данных на актуальном в наши дни примере.
Вкратце есть база на mssql сервере есть хранимые процедуры. Есть база на postgres. Есть ETL процесс на Apache Air Flow. Запускаем процесс, по окончании в базе postgres появляются процедуры и данные.
Скажу сразу данный подход не является полным автоматом, который перенесет любую mssql базу на postgres. Это попытка систематизировать подобный переход, разбить переход на управляемые небольшие части, которые типизируются и над которыми выполняются преобразования с возможностью контроля результата.
Это выдержка из восьмой главы книги Rodney Landrum: «SQL Server Tacklebox», в которой описывается, как DBA может устранить последствия повреждения данных. Будут продемонстрированы инструменты и сценарии, необходимые для своевременного поиска и устранения повреждений данных и предотвращения их попадания в резервные копии.
ORM (Object‑Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений, приводит к мысли что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С и ORM на Java, и наверняка в других ORM. В предыдущих частях показана глубина проблемы
Концепция ORM как двигатель прогресса — выдержит ли ее ваша СУБД? / Хабр (habr.com)
Концепция ORM как двигатель прогресса – выявит слабое место Вашей СУБД / Хабр (habr.com)
В этой части предложено решение со стороны СУБД (MS SQL , Oracle, Postgres)
ORM (Object‑Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений, приводит к мысли что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С и ORM на Java, и наверняка в других ORM. В предыдущей части статьи Концепция ORM как двигатель прогресса — выдержит ли ее ваша СУБД? были изложены результаты теста, в этой статье ответы на самые часто задаваемые вопросы и новый тест.
В предыдущей статье было показано как SQL Server выполняет изменения в некластерных индексах, но пока только в тех случаях, когда данные в индексе действительно изменяются. В примере из прошлой статьи использовался простой оператор UPDATE, который порождает построчный или «узкий» план запроса. В этой статье будет показано как оптимизируется план с изменениями данных с индексами в «широком» плане запроса.
Планы запросов на вставку, изменение и удаление состоят из двух частей. Первая часть называется курсор чтения, и она определят то множество строк, которое необходимо вставить, изменить или удалить. Вторая часть называется курсор записи, и в этой части непосредственно происходит вставка, изменение или удаление данных. Давайте рассмотрим простой пример:
Применение практик модульного тестирования для кода базы данных улучшает качество и архитектуру кода, а также позволяет своевременно обнаруживать и устранять ошибки.
В этой статье я покажу вам, как работать с Microsoft SQL Server в C# проектах посредством скриптинга. Реализовать это можно как в Windows, так и в macOS. Поскольку Windows, очевидно, является намного более популярной целевой платформой для C# и SQL Server, больше внимания я уделю настройке под macOS. В конце концов, код для этих платформ будет одним и тем же.
