Система управления реляционными базами данных
В статье описано, как настроить сервисы машинного обучения для R и Python. Несмотря на большой опыт в IT, сразу у меня не работает примерно ничего. Поэтому будут ссылки на то, что делать, если сразу не завелось. В итоге я поставила новый экземпляр с сервисами машинного обучения, которые, наконец! заработали.
Недавно нам прилетело большое тестовое задание от Тиньков-Банка на должность аналитика данных. Там очень много задач, но сегодня мы разберем несколько — остановимся на мелочах и обратим внимание на тонкие моменты.
И, конечно, попишем SQL-запросы!
Удаление архивных данных из базы это непростая задача как в 1С так и для любой базы данных. В статье изложены различные способы решения задачи, включая самый эффективный для 1С
Entity Framework — это удобный фреймворк для работы .NET-приложения с базой данных. По сути, это такая удобная абстракция над БД, которая сама пишет за разработчика оптимальные (ну, почти) SQL-запросы прямо из высокоуровневых LINQ-конструкций. Одной из киллер-фич фреймворка является возможность относительно легко сменить СУБД приложения на какую-нибудь другую. Предположим, разочаровались вы в MySQL или, наоборот, хотите сменить MSSQL на что-то менее дорогое — пожалуйста, EF как абстракция над СУБД в теории может это предоставить, так сказать, by design.
Проблема в том, что в мире бизнес-разработки СУБД меняют лишь по очень большой нужде, а потому редко кто уже сталкивался с данной фичей EF на практике, но вот мне такая возможность выпала. Поэтому я решил написать небольшой гайд, как это выглядит в реальности, чтобы у вас была возможность оценить применимость данной фичи, если вдруг это понадобится.
По материалам статьи Craig Freedman: The PIVOT Operator.
Несколько статей будут посвящены тому как в SQL Server реализован оператор PIVOT и UNPIVOT. Начнем с оператора PIVOT. Оператор PIVOT берет нормализованную таблицу и преобразует ее в другой вид, в котором столбцы результирующей таблицы получаются из значений исходной таблицы. Например, предположим, что мы хотим хранить данные о суммарной выручке от продаж за год по каждому из сотрудников. Для этих целей можно создать следующую таблицу:
Продолжение статьи 1С + MS SQL против Матрицы виртуализации о методах анализа производительности 1С + MS SQL в виртуальной среде. Заключительная развязка оказалась одновременно неожиданной и банальной в духе современной эпохи.
Виртуализация в облака стала модным трендом. Однако если вы захотите поместить нагруженную систему в облако - Вас ожидает много разочарований. В статье на реальном примере показано, что Вас ожидает под облаками. Пример приведен для связки MS SQL + 1C но такие же эффекты могут быть и в других приложениях.
По материалам статьи Craig Freedman: Decorrelating Subqueries
В статье про скалярные подзапросы было несколько примеров, в которых оптимизатор мог переписать запрос с коррелированным подзапросом как запрос с соединением. Например, можно было видеть, как представленный ниже простой подзапрос с «in»:
Ранее разработки в данном направлении уже велись, и в результате проделанной работы был создан продукт в виде десктопного приложения. К сожалению, он не получил широкого применения, так как использовался узким кругом сотрудников в довольно ограниченной сфере деятельности.
Приложение было разработано на языке программирования Visual Basic 6.0. Для описания содержимого файлов использовалось хранилище, реализованное на SQL server с типом данных varbinary(max).
Завершив в недавнем прошлом очередную доработку своей легковесной технологии SQL-файл, применяемой для эффективной трансляции файлового SQL-кода в базу данных, автор данной статьи решил в очередной раз представить (в этой заметке теперь, на популярном ресурсе) свои реализованные, хотя бы отчасти, идеи касательно программирования MSSQL, а также некоторые соображения относительно применения SQL вообще. Автор полагает, что несмотря на форму предлагаемой им частной реализации SQL-файл (для MSSQL), лежащая в основе подхода концепция имеет определённую силу и смысл.
Выше на картинке: SQL-трансляция исходных файлов из нескольких директорий (скрипты *.sql), запуск fill_with_data.cmd
Полезная программка ведь не обязана быть большой, правда? Пусть у нас есть процессы, для которых известны времена их начала и завершения. Таких в любой системе пруд пруди. Тот же ExecutionLogStorage в MS SQL Reporting Server, SQL server Profiler Trace, плюс куча кастомных метрик, которые есть у каждого.
Как выполняются эти процессы? Спокойно, один за другим, их хотят маршировать все в ногу? Какова средняя и максимальная степень параллелизма выполнения этих процессов? Хотелось бы получить что-то такое (процессы показаны черточками вверху):
В совсем раннем превью MS SQL мне вежливо отказали. И вот, наконец вышел публичный evaluation релиз! Давайте посмотрим, как MS SQL отнесется к самому неприятному - values with irregular selectivity. У меня про это даже была статья.
Использовать Guid.NewGuid() в качестве первичного ключа в базе данных — плохая с точки зрения производительности идея. Это связано с тем, что в SQL Server, MySQL и некоторых других БД для первичных ключей создаются кластерные индексы, которые определяют, как строки будут храниться на диске. GUID — это по сути случайное значение, поэтому новая строка может попасть в начало, середину или конец таблицы. Серверу БД в этом случае придётся перемещать другие строки, что приведёт к фрагментации данных, а их извлечение может занять больше времени, если вам нужно извлечь несколько добавленных последовательно записей (например, когда вы добавляете набор связанных сущностей, которые потом будут извлекаться вместе — БД понадобится прочитать данные из разрозненных страниц вместо последовательного чтения набора данных).
Поэтому, чаще всего, лучше пользоваться сгенерированными БД первичными ключами. В SQL Server, например, есть функция NEWSEQUENTIALID(), которая генерирует последовательные GUIDы. Зачем может понадобиться генерировать ключи именно на клиенте и как это правильно сделать?
По материалам статьи Craig Freedman: Read Committed and Updates
create table t1 (a int, b int)
create clustered index t1a on t1(a)
insert t1 values (1, 1)
insert t1 values (2, 2)
insert t1 values (3, 3)
create table t2 (a int)
insert t2 values (9)
Проведём эксперимент. Начнем с создания следующей простой схемы:
Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp
По материалам статьи Craig Freedman: Serializable vs. Snapshot Isolation Level
Уровни изоляции транзакций Serializable и Snapshot обеспечивают согласованное чтение из базы данных. На любом из этих уровней изоляции транзакция может читать только зафиксированные данные. Более того, транзакция может читать одни и те же данные несколько раз, не заботясь о каких-либо параллельных транзакциях, вносящих изменения в эти же данные. Те нежелательные эффекты, которые были продемонстрированы в предыдущих статьях при Read Committed и Repeatable Read, на уровнях изоляции Serializable и Snapshot просто невозможны.
Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp
По материалам статьи Craig Freedman: Repeatable Read Isolation Level
В двух предыдущих статьях (1, 2) было продемонстрировано как запросы с уровнем изоляции «read committed» могли порождать неожиданные результаты. Это становилось возможным из-за выполняющихся в одно и то же время изменений затронутых запросом строк. Чтобы недопустить подобных неожиданностей (но не всех), следует использовать для выборки уровень изоляции «repeatable read». В этой статье мы как раз и рассмотрим как одновременные изменения ведут себя с уровнем изоляции «repeatable read» (повторяемое чтение).
В отличие от просмотра с «read committed», просмотр с «repeatable read» удерживает блокировки каждой затронутой строки до окончания транзакции. На всём протяжении транзакции заблокированными могут оказаться даже некоторые строки, которые не соответствуют выборке в результате запроса. Такое блокирование гарантирует, что затронутые запросом строки не будут изменены или удалены в параллельном сеансе, пока текущая транзакция не будет завершена (независимо от того, будет ли она зафиксирована или произойдёт её откат). Эти блокировки не защищают от изменения или удаления те строки, которые еще не были охвачены просмотром, и не препятствуют вставке новых строк межу уже заблокированными строками.
Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp
По материалам статьи Craig Freedman: Query Plans and Read Committed Isolation Level
В прошлый раз мы рассмотрели то, как одновременные изменения могут стать причиной просмотра на уровне изоляции read committed. Также было показано что эти условия могут привести к выборке одной и той же строки несколько раз или вообще к отсутствию строки в выборке. Теперь давайте рассмотрим как одновременные изменения могут отразиться на работе более сложных планов запроса.
Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp
По материалам статьи Craig Freedman: Read Committed Isolation Level
В этой статье я рассмотрю используемый по умолчанию уровень изоляции транзакций: read committed. Когда SQL Server выполняет блок операторов с уровнем изоляции read committed, он последовательно накладывает совместную блокировку на записи, которые затрагивает запрос. Продолжительность действия этих блокировок довольно велика, за это время осуществляется чтение и последующие операции с каждой записью выборки. Как правило, сервер снимает блокировку с записи перед тем, как перейти к следующей. Таким образом, если вы выполняете простой оператор «SELECT» с «read committed» и наблюдаете за блокировками (например, с помощью sys.dm_tran_locks), вы, как правило, видите блокировку одной записи за каждую итерацию выборки. Цель этих блокировок является гарантия того, что данные не изменятся во время их считывания и возвращения оператором выборки. Нужда в подобных блокировках возникает потому, что изменения данных всегда приобретают эксклюзивную блокировку, которая блокирует любые операции чтения, пытающиеся наложить совместную блокировку.
Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp
По материалам статьи Craig Freedman: Scalar Subqueries
Пример:
Скалярный подзапрос — это подзапрос, который возвращает одну строку. Для некоторых запросов сразу видно ,что они скалярные.
Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp
По материалам статьи Craig Freedman: Semi-join Transformation
В предыдущих статьях я приводил примеры полу-соединений (semi-joins). Вспомним, что полу-соединение возвращает строку из таблицы, если для этой строки есть хотя бы одна совпадающая строка во второй таблице. Вот простой пример: