SQL *

Привет, Хабр! Меня зовут Дмитрий, я инженер данных, и это моя первая статья. В ней я хочу поделиться своим пет-проектом, который посвящен созданию ETL-процесса — важного элемента в работе любого Data Engineer. Мой проект направлен на извлечение данных из электронной почты и их загрузку в базу данных Greenplum для анализа.

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

Готовые приложения часто ограничены в настройке, поэтому я решил использовать Python для автоматизации обработки данных, а Greenplum для их хранения и аналитики. В статье я расскажу, как мне удалось автоматизировать процесс извлечения данных из писем "ВкусВилл", структурировать их и загрузить в базу для дальнейшего анализа.

Язык Transact SQL является процедурным расширением языка SQL и используется в СУБД Microsoft SQL Server. В этой статье мы рассмотрим использование некоторых элементов T-SQL для анализа данных. Сначала мы рассмотрим оконные функции, а затем поговорим о методах сводки (pivoting) данных и его отмены. При сводки данные преобразуются из состояния строк в столбцы, а при отмене обработки данные преобразуются из столбцов в строки, аналогично Excel.

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

Однажды, я столкнулся с инцидентом на проде и обратился за помощью к самому опытному инженеру. Он пришел на помощь и с легкостью изменил значение в БД с помощью... ручного обновления. 🤯 Проблема заключалась в том, что набор SQL-обновлений не был выполнен внутри транзакции.

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

SQL кажется чем-то, что мы все хорошо знаем, и мало чем может удивить. (Ему уже 50 лет!) Возможно, пришло время пересмотреть подходы, так как мы уже прошли фазу хайпа по поводу NoSQL, и снова возвращаемся к “используйте просто Postgres”, а иногда и к “SQLite тут за глаза”.

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

Основной принцип многослойной архитектуры заключается в разделении критически важных частей кода (логики) от деталей реализации (например, SQL-запросов). Одним из способов достижения такого разделения является паттерн «Репозиторий». Однако, наиболее сложным аспектом такой архитектуры является обработка транзакций.

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

Предполагается, что вы знакомы с базовым синтаксисом языка Python и, возможно, новичок в программировании.

Недавно, на хабре вышла статья про один нюанс в оптимизаторе 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 этих СУБД. Надеюсь, их понимание поможет сэкономить время и нервы тем, кто сталкивается с аналогичной задачей.