SQL *

Посчитаем по пунктам потенциальные грабли и проблемы, с которым встречается DBA на своем рабочем месте. Сколько получилось у вас? Отпишитесь в комментариях.

Привет, Хабр! Одной из важных задач в аналитических запросах является расчет долей, который позволяет узнать, какая часть записей из общего количества по всей таблице соответствует какому-либо критерию. Также нередко полезными оказываются коэффициенты проникновения (в общем-то тоже являющиеся долями). Они позволяют оценить продажи, найти взаимосвязи признаков и сделать много еще чего полезного. Чтобы проводить такого рода расчеты идеально подходит язык DAX. Если Вам интересно, насколько это удобно и как именно сделать это в DAX — добро пожаловать под кат :)

Вход в профессию Data Engineer требует не только владения инструментами для построения данных, но и уверенного знания SQL для решения задач различной сложности.

Несмотря на то, что многие SQL-запросы могут казаться «аналитическими», на практике именно Data Engineers часто отвечают за их написание и оптимизацию. Ведь аналитикам и специалистам по продукту требуется быстрый и точный доступ к данным для их анализа, а это означает, что DE должны обеспечить доступ к нужным данным и помочь в создании запросов для обработки больших объемов информации.

В этой статье я привожу примеры SQL-запросов, которые соответствуют уровню владения языком, необходимому для Junior Data Engineer.

Эта статья открывает цикл о новостях будущей, 18-ой, версии PostgreSQL. Рассмотрим следующие возможности попавшие в июльский коммитфест.

Планировщик: поддержка правого полусоединения хешированием
Планировщик: материализация внутреннего набора строк для соединения вложенными циклами в параллельном плане
Вспомогательные функции планировщика для generate_series
EXPLAIN (analyze): статистика рабочих процессов узла Parallel Bitmap Heap Scan
Функции min и max для составных типов
Имена параметров для функций regexp*
Режим отладки в pgbench
pg_get_backend_memory_contexts: столбец path вместо parent и новый столбец type
Функция pg_get_acl
pg_upgrade: оптимизация работы pg_dump
Предопределенная роль pg_signal_autovacuum_worker

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

Готовые LLM для русского языка часто показывают низкую точность и ограниченные возможности. Проблемы конфиденциальности также вынуждают компании выбирать локальные модели.

Наша компания давно занимается искусственным интеллектом и стала часто получать подобные запросы от клиентов — создание ИИ-решения с локальной обработкой данных. Мы задались вопросом, какие LLM хороши для таких решений, что мы можем предложить заказчику? Всё это вылилось в большой рисеч разных языковых моделей.

В статье рассмотрим, какие LLM подходят для задач на русском языке, протестируем их по разным параметрам и выявим лидеров. Мы оценили генерацию текста, ответы на вопросы, исправление ошибок и другие функции.

Это предупреждение, которое выведет хибернейт, если для осуществления пагинации ему придется загрузить ВСЕ данные из таблицы, а не по одной странице.

MariaDB Server исполняется 15 лет! Вот 15 причин, по которым разработчики и администраторы баз данных любят его!

Третья статья цикла по асинхронному SQLAlchemy 2 посвящена оптимизации кода, обновлению и удалению данных. Рассмотрены улучшения базового класса, подходы к обновлению записей и методы удаления, с акцентом на повышение производительности. Нажмите «Читать», чтобы ознакомиться с материалом.

Здравствуйте, дорогие друзья! Сегодня мы окунёмся в мир SQL запросов и рассмотрим различные подходы, которые разработчики используют для работы с данными в БД. В современном мире разработки, где информация становитесь все больше и больше, и скорость получения данных имеет большое значение, умение эффективно извлекать и обрабатывать данные становится неотъемлемой частью работы многих SQL специалистов (особенно тех кто работает с нагруженными системами и DWH). Мы поговорим о таких методах, как Common Table Expressions (CTE), подзапросы, представления и материализованные представления.

Привет, Хабр! При работе с Business Intelligence и дашбордами практически в любой предметной области встречаются даты и календари, поэтому от выбора представления дат и их составных частей (день, месяц, квартал, полугодие, год и т.д.), ключей дат и таблицы с датами зависит производительность всех дашбордов. В этой статье я расскажу о том, как можно оптимизировать работу с датами в Visiology — с использованием DAX и без него. Интересно? Добро пожаловать под кат! :)

Привет, Хабр!

Меня зовут Тимур Маннапов, и я самый обычный senior-разработчик в Mindbox.

На примере нашего продукта я расскажу, почему при загрузке CPU наполовину или меньше скорость параллельных вставок на SQL-сервере упирается в «невидимый» предел, а потом и вовсе замедляется. На нашем железе предел был в районе ~120 тысяч строк в минуту в одну таблицу. Поделюсь, как его преодолеть, не потратив годы на разработку и миллионы на новый сервер.

Уверен многие тру-программисты и без меня знают их, но я решил собрать во едино все реализации циклов через while, которыми я активно пользуюсь, как автоматизатор, тестировщик и разработчик ETL.

Доброго времени суток, товарищи, эта статья, так скажем, продолжение предыдущей статьи об SQLAlchemy 2.0 для новичков, в этой статье мы узнаем что такое Python Generic и как его можно использовать в наших целях при взаимодействии с БД.

В очередной рабочий день поступила задача обновить Gitlab. Задача в общем-то не сложная, ни смотря на то, что там он установлен в докере из многим знакомого образа от sameersbn, что впоследствии было переделано на omnibus (что бы это не значило), т.к. по моему опыту omnibus версия (установка на чистый линукс) гораздо проще и предсказуемей в эксплуатации. Впрочем статья совсем не об этом.

Но как можно понять из наличия этой статьи, что-то пошло не так...

DWH (Data Warehouse или по русски Хранилище данных) - это специализированная система для хранения и управления большими объемами данных, которые объединяются из разных источников с целью анализа и построения отчетов 

Короче, это место, где все нужные данные из разных мест собираются и потом ими уже удобно пользоваться - строить разные отчетики, строить ИИ на благо всему человечеству и подобные вещи

Грубо говоря, задача при построении хорошего DWH состоит в том, чтобы построить Базу Данных и все необходимое вокруг него, в которой будут лежать правильные данные в удобном виде и в которую можно слать большие-сложные SQL запросы и не бояться, что что-то сломается и всем этим было удобно пользоваться

Мы, студенты из МИФИ, Даниил и Александр, пришли на стажировку в Сбербанк в департамент SberData, который занимается развитием внутренней корпоративной аналитической платформы (КАП).Это современная платформа с удобными инструментами созданная для закрытия полного спектра потребностей Сбера в работе с данными, таких как хранение, интеграция, разнообразная аналитика, отчетность, моделирование и контроль качества данных. Все эти направления было бы трудно развивать без отдельного R&D подразделения, в составе которого мы и работаем. Сегодня мы хотим поделиться нашим исследованием в области проектирования алгоритмов в выявлении «токсичных» SQL‑запросов с помощью машинного обучения. Почему же запросы называются именно «токсичные»? Они затрачивают на своё выполнение слишком большое количество ресурсов, а именно времени. На самом деле не только время, но для упрощения мы будем считать только время, так как это ключевой параметр.

Статья посвящена исследованию существующих подходов и их апробации на открытых данных. В качестве общедоступных данных были выбраны данные из таких бенчмарков, как TPC‑H и BIRD. Помимо этого, в статье рассматриваются некоторые трудности, с которыми мы столкнулись при работе над задачей, например, генерация данных и SQL‑запросов, а также миграция между диалектами SQL. В конце статьи мы опишем оригинальный подход, к которому по итогу пришли. В следующей статье мы расскажем о применении полученного опыта для реальной промышленной системы.

Привет, Хабр! Меня зовут Михаил Герасимов. Это продолжение статьи «Как в РСХБ разработали средство генерации SQL-запроса для упрощения задач по тестированию», где описывались принципы работы QueryBuilder. 

В условиях растущего тренда на импортозамещение в ИТ-компаниях, переход с коммерческих СУБД на Open Source решения стал одной из ключевых задач для многих организаций. В частности, в проекте по автоматизации тестирования специалисты РСХБ успешно адаптировали свой инструмент генерации SQL-запросов QueryBuilder к переходу на PostgreSQL.

«Всё это связано с тем, что подобные базы данных, по сути, представляют собой огромную распределённую хеш-таблицу. Единственные операции, работающие без необходимости сканирования всей базы данных — это поиск по секционному ключу и сканы, при которых используется ключ сортировки.

…Если паттерны доступа существенно изменятся, то может потребоваться полная повторная обработка всех данных».

Привет, Хабр! В SQL запросах важно ориентироваться в количестве записей в таблицах и в плане выполнения запроса. Это позволяет, например, уменьшить количество записей при выполнении запроса при помощи группировки GROUP BY. В случае работы над каждым SQL запросом вручную, это можно проверить в среде разработки. Но в случае генерации SQL запросов автоматически появляется задача проверки количества уникальных записей для одного или нескольких полей таблицы, иными словами, кардинальности. В частном случае, при наличии сильных линейных связей между полями таблицы или даже "полей-дубликатов", количество уникальных записей в двух полях практически равно количеству уникальных записей в одном поле, т.е. кардинальность двух линейно зависимых полей таблицы практически равна кардинальности одного поля. В связи с этим актуально применение коэффициентов парной и множественной корреляции при расчете кардинальности нескольких полей. Интересны статистические методы при расчете кардинальности? Добро пожаловать :)

Привет, Хабр!

Представьте, что вам нужно найти иголку в стоге сена, но стог — это ваша БД, а иголка — данные со сложным шаблоном. Деофлтные операторы LIKE и IN тут не помогут — слишком уж они прямолинейны. Но зато здесь отлично зайдут регулярные выражения, которые позволяют выполнять сложные поиски и преобразования строк.