Microsoft SQL Server *

 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. В конце концов, код для этих платформ будет одним и тем же.

tSQLt — это мощный фреймворк с открытым исходным кодом для модульного тестирования кода SQL Server. 

Модульное тестирование SQL-кода — полезная практика в разработке баз данных, которая позволяет обнаруживать ошибки до попадания их в продакшн. Хотя надо сказать, есть разные мнения, и некоторые разработчики все еще спорят о необходимости модульного тестирования SQL-кода. Модульное тестирование очень важно для контроля и проверки поведения отдельных частей базы данных и не стоит игнорировать написание модульных тестов кода базы данных. По сути, модульные тесты позволяют автоматически проверять поведение объектов базы данных (хранимых процедур, триггеров, функций и т. д.) при регрессионном тестировании. 

Основная статья Взаимодействие DWH Oracle и MS SQL

Завершающим этапом для загрузки, обработки данных и наполнения данных куба, можно назвать автоматизацию выполнения задач по расписанию. Для реализации этого в MS SQL Server имеется SQL Agent.

Предварительно необходимо создать учетную запись (Credential) (см. Рис. 1), из-под которой будет выполняться запуск заданий (Job).  Эта учетная запись должна быть связана с доменной учетной записью, которой будет предоставлены привилегии. Этой учетной записи можно выдавать доступы, например, в каталогах для загрузки и выгрузки файлов, доступа к серверам и т.п. Если данную учетную запись не создавать, то необходимо выдавать доступы для учетной записи SQL Agent, что может не соответствовать с вашей политикой безопасности в организации.

Основная статья Взаимодействие DWH Oracle и MS SQL

Одним из методов для оптимизации обработки, хранения и администрирования данных в базе данных и кубах MS SQL — это процесс создании партицирования данных.

Partitioning (партицирование или по-другому секционирование) —  это разбиение таблицы на несколько частей, а эти части на одну или несколько файловых групп. Партицирование необходимо для целей ускорения доступа чтения или изменения данных и администрирования. Так как выровненный индекс по таблице будет содержаться в каждой условно своей секции, то при чтении или изменении данных будет обращение к конкретной секции и конкретному индексу в этой секции.

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

Пример кода для переноса в таблицу:

Финальным результатом при построении аналитического хранилища является передача готовых данных пользователям.

Для отображения данных из OLAP кубов используется настольное приложение Business Analytics tools (BAT). Данное приложение состоит фактически из двух приложений: приложение для просмотра, редактирования отчетов пользователями и приложение для
администрирования, в котором создается подключение к кубам данных, выполняется настройка ролей для распределения прав доступов и создается базовая структура отчетов.

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

Таблицы измерений должный иметь primary key на ключевое поле. Таким образом таблица будет содержать unique clustered index (уникальный кластеризованный индекс), и таблица будет в нужном нам отсортированном порядке.

Таблица фактов должна иметь партицирование по отчетной дате и clustered index с составным ключом. И если это позволяет наш режим работы иметь партицирование по отчетной дате и clustered column store index (колоночный индекс). Данный тип хранения таблицы имеет ряд преимуществ - это 10-ти кратное сжатие данных и ускорение считывания данных при наборе их в куб, но обязательным условием для эффективного применения данного индекса является необходимость хранить более 1 миллиона строк на одну секцию.

В ряде статей планирую рассказать о подготовке данных, основных этапах разработки и дальнейшего использования данных в Microsoft Analysis Services (SSAS), о процессе построения аналитического хранилища данных на Microsoft SQL Server (MS SQL), о взаимодействии с базами данным Oracle и другими источниками нашего банка Совкомбанк, а также рассказать о возможностях MS SQL которые мы используем.  

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

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

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

Привет! Меня зовут Александр Денисов, и я не боюсь перемен. Будучи сеньором-программистом, я перешёл на мидл-позицию и стал заниматься СУБД. А восемь лет спустя, уже став опытным аудитором и экспертом по MS SQL Server, снова шагнул на ступеньку вниз, чтобы устремиться к новым высотам, на этот раз в дата-аналитике. 

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

В прошлой статье я писал об особом виде оператора TOP, известного как ROWCOUNT TOP. Теперь рассмотрим несколько других интересных сценариев появления в плане оператора TOP. 

Новшеств довольно много, о некоторых можно сказать кратко, а что-то лучше описать более развёрнуто. Те новшества, которые относятся к облачным хранилищам, мы тут и вовсе опустим ввиду неактуальности на сегодняшний день. Также тут не будет ничего про новый синтаксический «сахар» T-SQL и небольшие улучшения там и сям, типа сжатия XML.

Автор Liwei Yin

В статье SQL Server Cardinality Estimation: несколько статистик по одному столбцу рассказывалось о том, как SQL Server вычисляет статистику по одному столбцу. Сегодня поговорим о статистике по нескольким столбцам.

BigQuery и другие аналитические хранилища в сочетании с современными BI инструментами перевернули работу с данными за последние годы. Возможность обрабатывать терабайты информации за секунды, интерактивные дашборды в DataStudio и PowerBI, сделали работу очень комфортной.

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

Не секрет, что тема перехода в IT-сфере на технологии, не требующие дорогостоящего лицензирования становится всё более актуальной. В то же время, очевидно и стремление компаний попасть в Реестр отечественного ПО, чтобы получить разного рода преференции для себя и своих сотрудников.

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

В данной статье предлагаю рассмотреть путь по миграции географического микросервиса с MS SQL на PostgreSQL с фокусом на пространственные (spatial) типы данных.

Вопрос стоимости лицензий и непосредственного сравнения MS SQL vs PostgreSQL опустим, т.к. эта тема весьма хорошо раскрыта в DotNext-докладе моего коллеги, Стаса Флусова. Рекомендую к просмотру!

Автор Liwei Yin

Опубликовано 06.09.2021

Оптимизатор SQL Server оценивает запросы на основе затрат ресурсов. Для каждого конкретного запроса SQL Server создает план на основе оценки числа возвращаемых из таблицы строк. Именно поэтому понимание того, как SQL Server вычисляет предполагаемое число возвращаемых строк помогает находить и устранять неоптимальные элементы плана запроса. Эта статья начинает серию рассказов о SQL Server Cardinality Estimation (SQL Server CE) старых и новых версий.

Способ, используемый SQL Server для оценки числа строк, возвращаемых запросом с одним предикатом прост и понятен. Всё становится немного сложнее когда в запросе к SQL Server присутствует больше одного предиката. В отличие от случая с одним предикатом, у SQL Server разные стратегии в старой и новой реализации SQL Server CE.

Для прежних версий SQL Server CE предполагается что распределение данных по разным столбцам не зависят друг от друга. В новом SQL Server CE предполагается, что распределение данных по разным столбцам коррелируется. Короче говоря, ожидаемое количество строк у нового CE предсказывается лучше, чем количество строк для такого же запроса, но с CE прежних версий.