SQL *

Индексы – это «ускорители» доступа к данным в базах данных. Правильно выбранные индексы могут многократно ускорить запросы, что особенно критично в highload-системах с большими объёмами данных и большим числом запросов. Однако за ускорение чтения приходится платить усложнением записи и дополнительным расходом памяти. В этой статье мы подробно рассмотрим, как работают разные типы индексов в реляционных СУБД, как выбирать индекс под конкретный запрос, обсудим подводные камни (например, блоат, переиндексация, избыточные индексы) и затронем индексацию в NoSQL (MongoDB, Cassandra). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.

Привет, Хабр! Меня зовут Александр Овсов, я RnD-разработчик в компании Just AI и занимаюсь продуктом Jay Knowledge Hub. Это умная платформа для поиска по неразмеченным корпоративным данным, созданная на базе RAG и AI-агентов.

Одним из типичных юзкейсов для наших пользователей является аналитика сложных данных хранящихся в CSV-таблицах (финансовые отчеты, продуктовая аналитика и т.д.). Работать с такими данными при помощи классических методов RAG сложно из-за структуры этих данных. Чтобы решить эту проблему, мы решили использовать агентский подход — набирающий популярность метод, который позволяет LLM выполнять сложные задачи, например, отправлять SQL-запросы к таблицам. О реализации такого подхода на примере CSV таблиц я сейчас и расскажу.

Сразу покажу, о чем идет речь, чтобы вы решили, нужно вам это или нет. На текст процедуры мы отображаем данные о числе выполнений, cpu, duration, о числе чтений и записей и числе обработанных записей.

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Рекурсивно вычисляем логические выражения и разбираем устройство двоичного сумматора.

Хочу рассказать, как спроектированы распределённые вычисления в ClickHouse. Вы узнаете, на что влияет схема кластера (и на что не влияет). Расскажу, как можно на ровном месте создать себе проблему при помощи всего одной таблицы Kafka и нескольких матвьюх. Поделюсь опытом про дебаг и оптимизацию SELECT-запросов к Distributed таблицам: поизучаем планы выполнения и поэксперементируем с настройками в блоке SETTINGS.

Запускайте PostgreSQL, ClickHouse, Airflow, Superset и другие инструменты одним кликом: учите, экспериментируйте, осваивайте новое!

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Применяем простые операции над массивами, чтобы определить связность графов.

Привет, Хабр! Мы уже неоднократно поднимали вопросы оптимизации запросов к СУБД ClickHouse, которую все чаще используют как универсальное высокопроизводительное хранилище для аналитических задач. В случае с Visiology этот вопрос приобретает двойную ценность, так как мы используем оптимизацию для эффективного выполнения запросов в языке DAX.

Сегодня мы поговорим о применении группировок GROUP BY с учетом их производительности для относительно больших таблиц, например, с миллионами записей. Таким образом, речь пойдет об оценке кардинальности одного или нескольких столбцов. Эта задача, кстати, является достаточно нетривиальной. Но если Вы можете ее решить, появляется возможность для эффективных оптимизаций SQL. О них мы и поговорим сегодня.

Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных. Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети​.

Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​.

Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации, лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.

По прогнозу Gartner, запросы на естественном языке вытеснят SQL уже в 2026 году. Возможно, прогноз Gartner чересчур оптимистичный, но если они и ошибаются, то только в сроках — сам переход на естественный язык в работе с БД неизбежен.

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

Сегодня я хочу поговорить о том, без чего не обходится практически ни один серьёзный проект с большими данными (да и с не слишком большими тоже) — о промежуточных витринах (или более привычно – staging, core, data mart).

Как экономить до 90% оперативной памяти при загрузке pandas DataFrame из базы данных?

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

В распределённых базах данных YDB, CockroachDB по умолчанию используется уровень изоляции SERIALIZABLE. В PostgreSQL, Oracle Database, MySQL по умолчанию используется READ COMMITED. В стандарте SQL указаны только три аномалии. В статье приводится пример аномалии потерянного обновления в задаче "списания средств" и рассматривается, почему уровень READ COMMITED и ограничения целостности достаточны для решения задачи.

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

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

Сегодня поговорим про RFM-анализ на SQL. Простыми словами: RFM-анализ — это способ понять, насколько ценные у тебя пользователи.

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

Сегодня рассмотрим 5 вопросов на собеседовании про A/B-тестирование в SQL. И начнем с первого – как посчитать конверсии и относительную разницу между группами A и B?

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

В статье разберём, как хранить и извлекать веса, вычислять ключевые метрики и строить графики.

Привет, Хабр! Достаточно часто используются иерархические фильтры или отчеты с иерархией, и представление иерархии может быть актуально как для UI (например, иерархических фильтров), так и для отчетов или дашбордов. Если рассматривать только структуру запроса с иерархией, без расчета промежуточных итогов и т.д., то сохранение структуры иерархического UI элемента при большом уровне вложенности, а также передача этой иерархии с UI на бэкенд и дальше, например, в виде SQL запроса в СУБД может быть относительно нетривиальной задачей. При относительно большом уровне вложенности (например, иерархия в 10 уровней), при решении «в лоб» и сохранении всех 10 выбранных значений на последнем уровне иерархии, станет неудобно хранить и передавать в качестве параметров с UI на бэкенд (для 1000 строк и 10 уровней вложенности может быть уже условно 10000 параметров), также растет и количество параметров в SQL, и проблемы усугубляются в случае микросервисной архитектуры, когда запрос SQL не сразу отправляется, например, в ClickHouse, а ещё эти 10000 параметров «путешествуют» из UI в один или несколько микросервисов, пока не попадут в ClickHouse. В связи с этим хочу рассмотреть одно из возможных решений проблемы с помощью хеширования на примере C# и ClickHouse, но это «не идеи, проверенные на продакшене», больше тема к обсуждению. Тем, кому интересно решение проблем иерархических запросов на примере C# и ClickHouse — добро пожаловать под кат :)

В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.

Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.

Используем оконные функции, чтобы вычислить "третью производную".

Если в вашем коде TSQL много вложенных вызовов stored procedures, вы можете наглядно построить стек вызовов с помощью «flame chart» — стандартным представлением для профилирования вызовов.

Опишем по шагам всю процедуру.

Всем привет! Меня зовут Миша, и я работаю продуктовым аналитиком в Ozon Банке. Мой путь в профессии начался всего 3 года назад, и я отлично помню, как мне самому не хватало подробного плана по входу в профессию. Поэтому я решил написать свой. Надеюсь, что он поможет новичкам и тем, кто только задумывается об аналитике данных)

Для того чтобы мой план был более интерактивным, давайте представим, что, идя по плану мы как Танос из вселенной Marvel – собираем навыки аналитика в свою перчатку бесконечности.