Система управления реляционными базами данных
Привет, Хабр!
Temporal tables позволяют следить за историями изменений уровне движка. SQL Server сам хранит полную историю изменений каждой строки — без триггеров, без дополнительного кода и без самописного аудита. Фича появилась в SQL Server 2016 и к сегодняшнему дню обросла возможностями. Разберём, как все устроено и как использовать.
Ключевые аспекты проектирования и реализации SCADA-систем в автоматизированных системах управления технологическими процессами (АСУТП). Основное внимание уделяется интеграции с базами данных, такими как SQL Server, и использованию протокола OPC UA для взаимодействия с контроллерами.
Рассматривается процесс подключения к контроллерам с использованием библиотеки open62541, включая настройку безопасности и создание подписок для мониторинга данных.
У нас есть продукт и нам нужно рассчитать ключевые метрики, которые показывают здоровье продукта:
• DAU/MAU – вовлеченность
• Conversion Rate – конверсия в целевое действие (у нас это создание объявления)
• Retention – удержание пользователей
• LTV – жизненная ценность клиента
• ARPPU – средний доход с платящего пользователя
В статье разберем последовательный расчет с примером синтетических данных и готового кода на SQL.
Почему SUM() OVER (ORDER BY ...) иногда даёт неожиданный результат, даже когда запрос синтаксически правильный? В статье на практических примерах разбираю, как работают оконные фреймы в SQL, чем отличаются ROWS, RANGE и GROUPS, где чаще всего возникает путаница и как писать накопительные итоги и скользящие метрики без сюрпризов. Если используете оконные функции в аналитике, этот разбор поможет сделать их поведение предсказуемым и управляемым.
Всем привет! Я Игорь Эльяс — бэкенд-разработчик, сейчас работаю в МТС Веб Сервисы. Однажды мне досталась задача «перенести приложение в другую БД, за XX времени», где ХХ — короткий интервал с точки зрения потенциального объема работ при подходе «переделываем все по-нормальному — на Entity Framework» :-)
Проект на C#, изначальная БД — MS SQL + мы использовали самодельный ORM. Возможно, вы сейчас подумали — «очередное легаси!». И да и нет. Проект родился еще во времена Framework 2.0, но регулярно обновлялся и сейчас работает на .NET8. Он пережил десятки циклов рефакторинга, поэтому не безнадежен для доработок.
В материале расскажу, что мы в итоге решили со всем этим делать, почему и для чего выбрали именно Dapper, а еще — познакомлю вас с мощным, но малоизвестным инструментом Dynamitey, благодаря которому удалось выполнить все в срок и без лишний приключений.
Договоримся о терминах:·
*Шардинг БД (db sharding) — это метод горизонтального масштабирования, при котором большая база данных разбивается на более мелкие, независимые части (shards), размещаемые на разных физических или виртуальных серверах. Каждый шард содержит подмножество данных, что снижает нагрузку на отдельные узлы, ускоряет запросы и позволяет хранить большие объемы информации, преодолевая ограничения вертикального масштабирования
**Read consistency (согласованность чтения) в БД — это гарантия того, что транзакция видит согласованное состояние данных, соответствующее определенному моменту времени (обычно моменту начала транзакции или запроса).
SQL в 2026: что реально нужно знать аналитику? 🤔
Спойлер: не только JOIN и GROUP BY, а еще и оконные функции, когортный анализ, оптимизация запросов и работа с BigQuery.
Пошаговый план для новичков с бесплатными тренажерами, курсами (да, Карпов там есть) и списком тем, без которых вас не наймут.
Давайте разберем четкий план: что учить, где брать практику и как не потеряться в море информации 👇
Недавно я посвятил время проблеме производительности на продакшене. Приложение работало в горячке — загрузка процессора в среднем превышала 50% и периодически подскакивала до 90%. Мы сделали диагностический снапшот и начали работать с топом запросов по процессорному времени.
Нарушитель номер один? Простой запрос Dapper. Незамысловатое условие WHERE по проиндексированному столбцу. Должно было быть молниеносным, но в среднем потребляло тысячи миллисекунд процессора при сотнях тысяч выполнений в день.
Несоответствие типов на пару символов, совсем невидимое в C#‑коде. Я очень долго глазел на запрос, прежде чем понял происходящее.
Бывают ситуации, когда есть список значений, и нужно найти значения, которых нет в БД. Прямым SQL-запросом найти отсутствующие значения невозможно, так как из базы нельзя получить значения, которых там нет. В статье рассмотрим какие есть замены временным таблицам в SQL.
В ритейле каждый сантиметр полки – это деньги (буквально). В этой статье я разберу примеры задач, которые решает аналитик в ритейле, и покажу, как их решать на SQL.
Каждая задача сложнее предыдущей для каждой есть код и готовые синтетические данные, поэтому все результаты можно получить самостоятельно, повторив код.
SQL для аналитика: разбор 4 задач со скриптами и примерами данных
Собрала 4 задачи, которые решала на старте карьеры на реальных проектах, и показываю:
- как обычный GROUP BY превращается в полноценный ABC-анализ;
- как оконные функции помогают увидеть динамику, которую в Excel считать часами;
- как найти неэффективные категории (даже если по цифрам всё "нормально");
- как построить прогноз на паре оконных функций.
Внутри:
- Скрипты с пояснениями;
- Сгенерированные данные (можно скопировать и проверить);
- Пример бизнес-вывода к каждому запросу.
Статья для аналитиков, которые хотят прокачать SQL и понимать, что на самом деле происходит в их данных.
Продолжим разбирать тему параллелизма для баз 1С, но сегодня разговор будет не о MS SQL, а о PostgreSQL. Принципы работы тут отличаются, поэтому нужно пояснение.
В статье разберем реальную задачу аналитика ассортимента в ритейле: «Какие товары люди покупают вместе», на учебных данных, с кодом SQL, со всей необходимой математикой и с примером выводов.
Когда я решила стать аналитиком, я не знала про SQL вообще ничего, совсем, базовое образование у меня экономическое и в университете SQL нам никто не преподавал.
В этой статье приведу пример 5 задач, которые меня научили SQL по-настоящему, все они построены на том, с чем работает аналитик ассортимента: товары, категории, продажи и поставки.
Строковые константы в MS SQL кажутся очень простыми в использовании. Но эта простота не всегда очевидна и порой приводит к тяжело выявляемым ошибкам в коде.
По этой причине данная статья может оказаться полезной не только новичкам, но и тем, кто уже использует T-SQL в своей работе.
Документация явно описывает два типа констант: обычные строковые и юникодные. Но на самом деле ситуация несколько сложнее, что и будет рассмотрено ниже.
Иногда может возникнуть необходимость запрашивать данные из ClickHouse в реальном времени при выполнении запросов или хранимых процедур на MS SQL. Последний "из коробки" представляет для этого средства только через Linked Server, OLE DB for ODBC и ClickHouse ODBC.
Если запрос возвращает немного данных - это вполне рабочий путь. Но если запрос к ClickHouse возвращает десятки тысяч строк, то производительность связки OLE DB for ODBC и ClickHouse ODBC не выдерживает никакой критики.
Работая с MS SQL, я привык воспринимать название Ring Buffer как небольшую структура в памяти, организованную по принципу FIFO overwrite. И чаще всего в контексте Extended Events. Но как-то я встретил упоминание того же Ring Buffer в заголовке статьи про секционирование таблиц! Купился на название, прочёл статью и сохранил себе идею.
В статье описывалось, как Ring Buffer решает задачу ротации данных во времени, которую принято решать с помощью Sliding Window. И я постараюсь передать эту идею так, чтобы после прочтения у вас появился еще один способ решить обычную задачу необычным способом. Не для галочки в резюме, а для рассказов на встречах с коллегами. В моей работе этот подход позволил сделать интересной скучную задачу организации хранения статистики производительности сервера, но может быть использован и для других данных с ограниченным сроком хранения или иначе фиксированным количеством секций. Например, данных аудита.
Продолжаю рубрику «Мысли вслух». Цель данной публикации – описать алгоритмы и новизну моих исследований по созданию кластера СУБД с горизонтальным масштабированием производительности – распределенного вычислительного кластера (РВК). Набралась очередная порция материалов в следствие новых изысканий и натурных экспериментов, которыми и делюсь. Сегодня речь пойдет о возможных протоколах работы РВК. Создание распределённого кластера СУБД обычно приносит серьёзные потери в производительности одиночных операций, плюс сложности в разработке, эксплуатации и сопровождении. Цель моей работы – создать РВК без этих недостатков.
Представьте: вы работаете в крупной компании с федеральной сетью. У вас более 300 баз данных Microsoft SQL Server, сотни тысяч объектов — таблиц, процедур, функций, триггеров. Значительная часть бизнес-логики реализована с использованием cross-database references и распределённых запросов через linked servers, что создаёт сложные зависимости между объектами на разных базах и даже серверах.
А теперь представьте, что все изменения в схему вносятся напрямую в production — через SSMS, без версионирования, без ревью, без возможности отката.
Звучит как кошмар? Но именно так работала наша команда более 10 лет.
«Так исторически сложилось» — и это было нормой. Такой подход неизбежно порождал инциденты: от локальных нарушений целостности данных до масштабных простоев, напрямую влияющих на выручку и репутацию компании.
Мы поняли: нужно внедрять CI/CD. Но главная проблема оказалась не в технологиях — а в людях.
Продолжаем публиковать некоторые детали проектов по миграции больших баз данных 1С с MS SQL Server на PostgreSQL. В прошлый раз речь шла о миграции только одной 10+ Тб базы данных 1С с MS SQL на PostgreSQL. Сегодня речь пойдет о проекте миграции на PostgreSQL сразу сорока с лишним распределенных информационных систем 1C с базами размером от 50 Гб до 2 Тб каждая.