Microsoft SQL Server *

Основная статья Взаимодействие 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 прежних версий.

ORM (Object-Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений, приводит к мысли что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С и ORM на Java, и наверняка в других ORM . Причины приоткрывает данная статья.

21 сентября 2022 г. Itzik Ben-Gan

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

В практике использования T-SQL не характерна манипуляция данными на битовом уровне, но иногда приходится сталкиваться с такой необходимостью. Можно встретить решения, в которых набор флагов (да/нет, вкл/выкл, истина/ложь) хранятся в одной целочисленной или двоичной колонке, где каждый бит представляет отдельный флаг. Одним из примеров является использование битового представления набора разрешений пользователя/роли. Другой пример — использование битового представления набора настроек, включенных или отключенных в данной среде. Даже SQL Server хранит некоторые данные на основе флагов, используя битовое представление.

Некоторые структурные проблемы в запросах 1С поменять невозможно без изменения платформы. Сколько производительности мы на этом теряем? На примере простого регистра сведений видно, что достаточно много.

В наличии была база данных MSSQL (с которой забираем данные), а также PostgreSQL Pro Enterprise 10.3, развернутая на CentOS 7 (на которую импортируем). Ну и полное отсутствие интернета.

Мне всегда было интересно (и не только мне) есть ли смысл запуска 1С в диске из оперативной памяти, потому что если посмотреть на графики скорости чтения различных типов накопителей, то преимущества  очевидны:

В мире кровавого энтерпрайза есть некоторое количество проектов-мамонтов. Они большие, у них базы данных на SQL Server, в этих базах тысячи и десятки тысяч объектов, миллионы строк кода T-SQL, огромная вариативность данных, всё хрупкое, неидемпотентное, недетерминированное и фигово документированное. Короче, как писал Roy Osherove в своей The art of unit-testing:

Finally, as a friend once said, a good bottle of vodka never hurts when dealing with legacy code.

В вольном переводе "Да там без поллитры не разберёшься!"

И вот у этих проектов есть беда — большие контуры тестирования и разработки, часто так или иначе модифицированные и уменьшенные копии основного продуктового контура. Да-да-да, тут сразу поналетят умные да в белой одежде и начнут объяснять, что надо писать тестовые наборы данных (а кто спорит?), что тестовый контур должен быть небольшим (а кто спорит?), что код должен быть переносимым между СУБД (спасибо, Кэп!), что всё было бы лучше, если бы проект переписали N лет назад (ха-ха) и прочие "станьте ёжиками" и "пусть едят пирожные". Нет, дорогие мои. Просто представьте, что у вас есть БД SQL Server с 25К объектов (таблиц и ХП) и миллионами строк запросов, и часть объектов создана с SET ANSI NULLS ON, а часть с SET ANSI NULLS OFF. И точно известно, что в части запросов эта разница используется. И БД на десятки ТиБ. И однодневный простой системы стоит больше, чем квартиры всех разработчиков, которые за последние 20 лет трогали этот код (из которых, кстати, сейчас работает только 7 последних самураев). Одно это может не давать перейти с SQL Server 2008 R2 на что-то более свежее пару лет.