SQL *

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

Если не видели дайджест за прошлый год — время наверстать упущенное!

Привет, Habr! Меня зовут Руслан Габдрахманов, я руководитель команды разработки информационных систем в «МосТрансПроекте». Сегодня расскажу, как мы создавали городской сервис «Узнай про ЖК», упрощающий выбор квартиры или жилья. 

У вас есть таблицы, либо ряд таблиц, строки которых нужно очистить и единственный способ, которым вы можете это сделать - это операция DELETE.

Помимо очевидной цели - очистки ненужных данных из таблицы, хотелось бы также увеличить свободное место в области диска, доступного для данных postgresql. Но при определенных условиях - операция DELETE не возвращает место, а операция UPDATE дополнительно его забирает.

Ноябрьский коммитфест принес немало интересного! Без лишних предисловий приступаем к обзору.

Самое интересное об июльском и сентябрьском коммитфестах ― в предыдущих статьях серии: 2023-07, 2023-09.

Немного отвлечемся от простых SELECT и посмотрим на реальной бизнес-задаче построения различных "тепловых карт" и "шахматок", как знание возможностей SQL может облегчить жизнь и разработчику, и его базе.

Сразу хочу отметить перед читателем, что это не просто вольные рассуждения на тему, а в том числе и презентация моей библиотеки для Python, которую можно найти на github и установить через pip, и которая трудится в моей многопользовательской игре как SQL движок проекта.

Проблемы ORM известны всем, кто хоть раз ими пользовался. Об этом существует множество статей как у нас, так и в зарубежных источниках. Эти проблемы в общем можно объединить довольно сложным термином Object‑relational impedance mismatch, что позволю себе вольно перевести как «Объектно‑реляционная разница потенциалов».

Альтернативой использованию ORM всегда было использование чистых драйверов баз данных и написание сырых SQL запросов, которые в свою очередь очень тяжело поддерживать и рефакторить в реальных проектах.

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

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

Сегодня поговорим о самых простых, но важных, возможностях команды SELECT, наиболее часто используемой при работе с базами данных - формировании выборок (VALUES), их ограничении (LIMIT/OFFSET/FETCH), фильтрации (WHERE/HAVING), сортировке (ORDER BY), уникализации (DISTINCT) и группировке (GROUP BY).

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

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

Данная статья в первую очередь для тех, кто только начинает знакомство с оптимизацией в Greenplum и хочет разобраться на что стоит обратить внимание в первую очередь. Будут рассмотрены три ключевых аспекта: компрессию данных, распределение и партиционирование. Узнаем – как правильно применять эти стратегии, чтобы улучшить производительность запросов, снизить потребление ресурсов и повысить эффективность работы базы данных.

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

В программе: рассказ об основах SQL, возможностях простых и сложных SELECT, анализ производительности запросов, разбор [не]эффективного применения индексов и особенностей работы транзакций и блокировок в этой СУБД.

Курс не претендует на лавры "войти в айти", поэтому подразумевает наличие у слушателя опыта программирования или работы с другими СУБД, и, главное, желания самостоятельно изучать тему работы с PostgreSQL глубже.

Для тех, кому комфортнее смотреть и слушать, а не читать - доступна видеозапись и слайды.

При работе с данными часто приходится сталкиваться с ситуацией, когда имеется некоторая функциональная зависимость y_i = f(x_i), которая получена в результате эксперимента или сбора статистики. То есть исходные данные представлены набором точек (x₁, y₁), (x₂, y₂) … (x_n, y_n), где n – количество экспериментальных значений. Если аналитическое выражение функции f(x) неизвестно или весьма сложно, то возникает чисто практическая задача: найти такую функцию Y = F(x), значения которой при x=x_i будут близки к экспериментальным данным. Приближение функции f(x_i) к более простой F(x) называется аппроксимацией. Аппроксимация позволяет исследовать числовые характеристики и качественные свойства объекта, сводя задачу к изучению более простых или более удобных объектов. Как правило, выбор модели аппроксимации определяется по минимальному значению погрешности на всем интервале исходных данных. Для расчетов необходимо использовать несколько видов аппроксимаций, чтобы определить более точное описание зависимости экспериментальных данных y = f(x_i).

Привет, Хабр!  На связи команда разработки «МосТрансПроекта».

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

Необходимые данные (а их суммарный объем измеряется в петабайтах) собирают ЦОДД, Московский метрополитен, «Организатор перевозок», «Мосгортранс», «Администратор московского парковочного пространства» и другие структуры транспортного комплекса. В целом, ничего сложного: получаем доступ к базам, берем информацию, «причесываем», анализируем, действуем, решаем задачу. Но, как обычно это бывает с данными, все не так просто.

В поисках склада

Проблема в том, что для неподготовленного специалиста обособленные друг от друга базы напоминают склады с наваленными коробками — чтобы быть уверенным в результате, нужно заглянуть в каждую. Старожилы «МосТрансПроекта», конечно, знают, где взять ту или иную информацию, но без их помощи работать с данными было трудно. Иногда нужно было пройти увлекательный квест, чтобы забрать сведения, которые есть лишь у конкретного специалиста.

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

‎Как собрать pgmodeler, если о Qt вы услышали первый раз, а о существовании C++, знаете только то, что он существует?

Привет, Хабр! Меня зовут Андрей Околелов, я работаю ведущим инженером в Блоке обеспечения и контроля качества выпуска изменений ПО в РСХБ. В банковской сфере я работаю с 1992 года, с 2018 основная деятельность — тестирование банковских приложений.

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

В жизни каждого инженера-фронтендера наступает момент, когда осознаёшь: далее не обойтись без кэширования данных из API. Всё может начаться с самых невинных вещей: сохраняем предыдущую страницу с данными, чтобы кнопка «Назад» срабатывала мгновенно; реализуем простенькую логику отмены действия или обеспечиваем слияние нескольких состояний от различных запросов к API. Но все мы знаем, чем такое кончается. Один за другим возникают запросы на новые фичи, и вскоре мы уже не покладая рук реализуем кэши данных, индексы для работы вручную, оптимистические мутации и рекурсивную инвалидацию кэша.

Эти фичи явственно смахивают на внутренние механизмы баз данных. Действительно, в любом достаточно сложном клиентском приложении программисту непременно придётся реализовывать такое множество фич для управления данными, что эта работа будет напоминать построение предметно-ориентированной базы данных. Такая дополнительная сложность удваивается в каждом проекте, над которым мы работаем, поэтому приходится тратить время на решение бизнес-проблем, а радовать пользователя – уже как успеем.

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

Рассмотрим вариант расширения стандартного CADLib API в части выборки объектов с некоторыми параметрами из базы при помощи SQL-запросов на примере получения всех файлов публикации, в которых встречаются объекты коллизий. Подобную задачу мы решим сперва вручную при помощи только лишь методов CADLib API, а затем комбинированным способом, с переносом части логики в SQL-запрос. Весь исходный код доступен на GitHub по ссылке.

Периодически сталкиваюсь с однотипными задачами вида "показать TOP-N позиций на каждом из вложенных интервалов некоторого периода".

Это может быть "5 лучших по успеваемости студентов в каждом семестре за последний учебный год", или "помесячная динамика позиции 10 наиболее продающихся товаров", или, как у нас в сервисе визуализации PostgreSQL-планов explain.tensor.ru, "3 наиболее активных страны за каждый день":

Как не грабить память, не пытать диск, не мучать кластер. Или делать все это всего одним запросом на Impala к Hadoop.

Среди задач аналитиков данных, в рамках которых необходимо иметь дело с большими объемами однотипных данных, выделяются задачи построения витрин данных, автоматизации процессов сбора и обработки данных. Многие аналитики используют различные реляционные базы данных, в таблицах которых хранятся огромные объемы информации, агрегация и доступ к которым может занимать долгое время, поэтому правильное составление и оптимизация запросов к этим таблицам становится критически необходимым фактором для работы аналитиков, инженеров данных и data scientist.