SQL *

Недавно, на хабре вышла статья про один нюанс в оптимизаторе PostgreSQL [1]. Будучи предельно технической и скучной по-определению, она триггернула интересную дискуссию в комментах и дала мне, как разработчику систем баз данных, возможность взглянуть на систему с точки зрения разработчика приложений. Это оказалось крайне продуктивным и даже привело к патчу и треду в сообществе. Возможно, нам нужно больше таких небольших и узко-специализированных постов? Данная статья - попытка развить это направление.

[1] Странное поведение планировщика запросов PostgreSQL

Enums VS Tables для создания типов моделей...

Зачем использовать вообще одно из этих решений?

Существуют модели, у которых необходимо выделить разновидности и сделать это именно с помощью типов, а не категорий... Разберёмся...

Привет, Хабр! Существуют разные задачи в IT, многие решаются алгоритмически или условно за счет архитектурных решений. Среди всего многообразия задач также интересны задачи, решаемые с применением статистических методов.

Одной из таких задач является приближенный расчет количества уникальных значений в поле таблицы (или кардинальности). Казалось бы, практическая польза от быстрого расчета количества уникальных значений поля без больших затрат памяти невелика, однако это позволяет, например, построить оптимальный с точки зрения производительности SQL запрос с этим полем, или использовать это поле в UI (например, элемент с бесконечной прокруткой или элемент с поиском при значительном количестве уникальных значений, а не отображение конечного списка) и т.д. Задача может быть эффективно решена в СУБД, обладающей соответствующими инструментами, поэтому будет рассмотрен ClickHouse.

Интересно решение задачи расчета количества уникальных значений столбца в ClickHouse? Добро пожаловать :)

Недавно попался на глаза запрос, которым хотели отобрать в таблице (очевидно, для последующего удаления) все id записей интервалов, которые полностью перекрыты каким-то другим интервалом того же owner'а.

Но self-JOIN показал себя не лучшим образом...

Привет всем!

Это вторая часть к продолжению статьи "Оконные функции простым языком с примерами". Рекомендую ознакомиться сначала с ней, а потом вернуться к прочтению данной статьи, чтобы полностью понимать синтаксис и применение оконных функций. В этой статье будет разобрано на примерах такое понятие как "фрейм" оконных функций, который расширяет возможности оконок для решения более сложных аналитических задач.

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

P.S. Если автор что-то не разобрал и не написал, значит он посчитал это не обязательным в рамках этой статьи :-)

Будем разбирать примеры на такой небольшой таблице, где указана прибыль (net_profit) компании на каждый месяц в рамках одного года.

В мире управления базами данных от эффективного хранения больших объемов информации зависит оптимизация производительности и использования дискового пространства. В этой статье разберем основные методы сжатия данных в TOAST, их эволюцию, плюсы и минусы PGLZ и LZ4 и продемонстрируем базовую работу с TOAST в Postgres. В завершение обсудим, как данные с различными методами сжатия могут храниться в одной TOAST-таблице.

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

Сегодня я хотел бы поговорить подробнее о языке DAX, который активно применяется продвинутыми аналитиками во всем мире. Но я уверен, что сфера использования этого мощного инструмента охватывает не только суперпрофессионалов. Именно DAX делает аналитику доступнее для бизнес-пользователей, которые могут сделать сложные расчеты без познаний в программировании вообще. В этой статье мы рассмотрим три примера, в которых DAX помогает гораздо проще и быстрее решить типовые задачи, с которыми сталкиваются аналитики. Использовали ли Вы DAX раньше — неважно! Тех, кто впервые слышит о DAX, я постараюсь порадовать примерами, а опытных пользователей приглашаю к дискуссии.

В этой статье обсудим, что из себя представляет изолированность транзакций в БД, какие есть уровни изоляции транзакций, как их установить, какие бывают аномалии на разных уровнях, и что такое MVCC. Естественно, всё на простых примерах.

Некоторые головоломки можно решать на SQL just for fun, а часть получается выразить на этом декларативном языке даже эффективнее других, императивных.

Попробовать сделать более наглядное решение, а заодно познакомить с некоторыми нетривиальными возможностями PostgreSQL меня натолкнул пост о решении на Python задачи Black and White.

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

Существует множество инструментов для решения задач Business Intelligence, одним из удобных инструментов является функциональный язык DAX, позволяющий работать с различными СУБД и выполнять достаточно сложные аналитические расчеты.

Поскольку язык DAX в рамках Power BI способен работать со множеством различных СУБД (например Oracle, MS SQL, MySQL, PostgreSQL, ClickHouse и т. д.), т. е. работает со множеством диалектов SQL, то в некотором смысле DAX является «надмножеством SQL» и приближается в этом смысле к реляционной алгебре. В данной статье приводится разбор типичного DAX для получения записи этого DAX в нотации реляционной алгебры. Интересующимся погружением в DAX и его реляционное представление — добро пожаловать :)

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

Проблема воспроизводится на последней стабильной на данный момент версии PostgreSQL - 16.2. При этом используются стандартные настройки PostgreSQL. Я пробовал менять разные настройки, но мне не удалось добиться правильного плана в общем случае, поскольку в данном случае проблема скорее логическая, а не в определении стоимости вычислений. Однако, каждый может легко воспроизвести эту ситуацию локально и попробовать поиграться с настройками. 

Рассмотрим простую доменную логику, в которой есть документы и их строки. Для каждой строки вводится сумма. Строки лежат в отдельной таблице и ссылаются на документ :

Как мы ускорили запросы в Trino, научив оптимизатор удалять из плана лишние операторы Join.

Обсудим, почему в аналитических запросах часто возникают избыточные Join, почему это плохо для SQL-движков, какие эквивалентные преобразования позволяют избавиться от ненужных Join, и с какими проблемами мы столкнулись при интеграции данного функционала в наш форк Trino.

Привет, Хабр! В рамках Business Intelligence для расчета KPI и других статистических характеристик могут использоваться различные средства. Универсальным и мощным инструментом является язык DAX, в этой статье я хочу показать его преимущества на примере популярной задачи расчета коэффициента проникновения в Power BI.

Если интересна аналитика с DAX - то добро пожаловать! :)

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

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

Мы на Хабр Карьере помогаем IT-специалистам зарабатывать больше, а компаниям — быть в курсе трендов на рынке найма. 

Сейчас мы активно ударились в создание инструментов для тестирования навыков в IT. Пока начали с одного — SQL. Нам помогли эксперты из Яндекс.Практикума: они подготовили тест, а мы собрали его и принесли вам. Надеемся, он поможет вам оценить знания и понять свой уровень. 

Если вы успешно пройдете тест, он будет красиво подсвечен в вашем профиле на Хабр Карьере — работодатели будут знать, что вы подтвердили свои знания.

Привет, Хабр!
Я Павел Беляев — тимлид дата-аналитиков. Наша компания отвечает за разработку и поддержку витрин данных. Как и многие, мы столкнулись с необходимостью перевести инфраструктуру с иностранного стека на отечественный.

Наша аналитическая база данных несколько лет строилась на базе Google BigQuery. Она содержала сотни представлений на гугл-диалекте SQL, и весь этот технопарк было решено перебазировать на российские платформы. Понятное дело, что ClickHouse и BigQuery — далеко не одно и то же, так что в процессе переезда нам пришлось набить немало шишек. В этой статье я покажу несколько отличий в SQL этих СУБД. Надеюсь, их понимание поможет сэкономить время и нервы тем, кто сталкивается с аналогичной задачей.

Пару дней назад был опубликован пост с решением на MySQL загадки Джиндоша (она же загадка Эйнштейна).

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

Поэтому я попробовал решить эту задачу "в общем виде", используя возможности PostgreSQL, и вот что из этого получилось.

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В первой части лекции мы узнали, что такое план выполнения запроса, как и зачем его читать (и почему это совсем непросто), и о каких проблемах с производительностью базы он может сигнализировать. В этой - разберем, что такое Seq Scan, Bitmap Heap Scan, Index Scan и почему Index Only Scan бывает нехорош.

Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись (часть 1, часть 2) и слайды.

Существуют базы данных различного вида, и для колоночных баз данных, таких как, например, ClickHouse, характерны особые инструменты для вычислений аггрегированных значений.

Из документации ClickHouse не всегда легко сразу понять ценность функций для имплементации бизнес-логики, в частности, ценность функции runningAccumulate. Например, несмотря на богатые возможности runningAccumulate, неотформатированный код и имена вида k и sum_k из документации могут немного ввести в заблуждение.

Если Вам интересно рассмотреть state функции ClickHouse на паре примеров с более понятной логикой, то добро пожаловать :)