SQL *

Когда фильтра по ключу секционирования нет, локальные индексы превращаются в марафон по секциям. Новый gbtree держит единый каталог ключей и прыгает к строке по PK; покажем алгоритм, реальные цифры и ограничения (PK обязателен, ON CONFLICT не работает) — и где это решает боль в CRM/биллинге.

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

Постгрес – не просто реляционная БД, а настоящий кладезь фич, о которых начинающий разработчик может и не догадываться. Всё началось с того, что PostgreSQL изначально писался на С/C++ и всегда тянуло к расширению стандартного SQL набора возможностей. Так однажды разработчики решили добавить в него JSONB, логику на уровне запросов и многое другое – что в итоге сделало его не хуже NoSQL-систем. Но вернёмся к малоизвестным фичам. Ниже – пять приёмов и возможностей, которые неожиданно полезны в повседневной работе.

Как StarRocks добивается высокой производительности JOIN-запросов в аналитических нагрузках. В материале — практическая кухня оптимизатора: какие типы JOIN эффективнее и когда их стоит конвертировать (например, CROSS→INNER, OUTER→INNER при NULL‑отвергающих предикатах), как работает predicate pushdown, извлечение предикатов из OR, вывод эквивалентностей и pushdown LIMIT. Разбираем Join Reorder для многотабличных запросов (Left‑Deep, Exhaustive, Greedy, DPsub), модель стоимости (CPU*(Row(L)+Row(R))+Memory*Row(R)) и выбор лучшего плана.

На уровне распределённого исполнения — MPP‑архитектура, свойства распределения (Distribution Property) и узлы Exchange; пять базовых планов: Shuffle, Broadcast, Bucket Shuffle, Colocate и экспериментальный Replicate Join. Плюс Global Runtime Filter (Min/Max, IN, Bloom) для ранней фильтрации на Scan. Даем практические принципы: используйте более быстрые типы JOIN, стройте хеш по малой таблице, в многоJOINовых запросах сперва выполняйте высокоселективные соединения, сокращайте объём данных и сетевой трафик. Материал для инженеров данных, DBA, разработчиков OLAP и всех, кто проектирует производительные SQL‑планы.

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

Механизм реализации транзакций - основная часть реляционных баз данных. Он упрощает разработку приложений, в которых гарантируется целостность данных. Стандарт SQL регламентирует, часть свойств по поддержке транзакций, но многие детали не стандартизованы. Как следствие, реализация поддержки транзакций в разных базах данных может существенно различаться. В настоящее время, многие пытаются перейти с Oracle на PostgreSQL. Для миграции приложений важно понимать различия в реализации работы транзакций, иначе можно столкнуться с неприятными сюрпризами, которые могут поставить под угрозу производительность и целостность данных. Поэтому Лоренс Альбе решил, что полезно сравнить реализацию работы транзакций в Oracle и PostgreSQL и свести различия в одной статье.

Миграция с Oracle в «ванильный» PostgreSQL ломается на пакетах, автономных транзакциях и коллекциях — там их просто нет. Разбираем, почему ora2pg спотыкается, что дает нативная реализация этих механизмов в Postgres Pro Enterprise и как ora2pgpro переводит PL/SQL семантически точно, без костылей и регулярок.

Материализованные представления в StarRocks упрощают моделирование данных, ускоряют запросы и повышают актуальность данных в lakehouse‑архитектуре. Разбираем базовые возможности MV, три практических сценария — моделирование, прозрачное ускорение и «lake + warehouse» — и даём ссылки на актуальные рекомендации для StarRocks 3.5.

Вам нужно создать сложный запрос к реляционной БД с изменяющимися параметрами?

В этой статье рассмотрим основные возможности Criteria API. Также рассмотрим более продвинутые вещи, например создание CTE и оконных функций, которые есть у Hibernate Criteria API. В статье много примеров, которые смогут помочь при написании запросов Criteria API на практике.

Привет, Хабр! Думаю, многие сталкивались с необходимостью генерации тысячи пользователей. Вручную - не вариант, слишком долго. В данной статье разберу библиотеку Faker. Это генератор реалистичных тестовых данных, который превращает заполнение базы и создание демо-контента из рутины в дело пары строк кода. В статье продемонстрирую, как генерировать тысячи правдоподобных записей на русском, заполнять БД и создавать собственные типы данных для ваших проектов.

Привет, я Сергей Маркизов, разработчик диджитал-продакшна Далее. В наших проектах часто использую Drizzle — современную, типобезопасную ORM для TypeScript, которая не усложняет базовую задачу: читать и писать данные. В этой статье расскажу, чем библиотека отличается от других и как с ней работать.

Разбирая взаимоблокировки, Лоренс вспомнил, насколько опасным может быть использование SELECT FOR UPDATE при конкурентном доступе. В этом нет ничего нового, но Лоренс заметил, что многие не знают о режимах блокировки строк в PostgreSQL. Лоренс решил подробно описать, когда следует избегать SELECT FOR UPDATE.

Кругом только и разговоров о том, как бы заставить Postgres работать быстрее, эффективнее, и так далее. Но при этом никто даже не задумывается о том, как бы его замедлить. Само собой, о продуктивности и эффективности парятся в основном те, кому за это платят. Я не из из числа (можете это исправить -- дайте мне знать). На днях я работал над чуть более полезным руководством и в какой-то момент решил, что этому миру нужна такая конфигурация Postgres, которая будет выполнять запросы максимально медленно. Нахрена? Черт знает, но вот что у меня получилось.

Басня о коде и мёде

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

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

И вот однажды мудрый старый архитектор, известный как «Пчеловод», собрал молодых строителей. «Вы стремитесь строить «Великие вещи», — сказала она, и ее голос был теплым, как летний мед. «Но вы строите из камня и железа, когда вы должны строить из самой жизни. Посмотрите на пчел. Их ульи — шедевры дизайна, построенные на века на протяжении поколений. Давайте узнаем их секреты».

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

Сегодня мы рассмотрим достаточное простое решение, как ограничить доступ к любому вашему дашборду на Суперсете, зная лишь емейл или логин пользователя, без использования стандартных не самых удобных прав пользователя «зашитых» в Superset.

Месяц назад я опубликовал пост об инструменте для автоматической оптимизации SQL-запросов. Идея была простая — убрать этап «общения» с ИИ и предоставить простой интерфейс, где не нужно придумывать промпты.

За первый месяц сервис использовали более 1000 человек. Ниже — выводы и результаты.

В истории киберпреступности есть имена, которые знают все, и есть те, кто действовал в тени, но при этом оставил след в масштабах целых стран. Один из таких людей — Хьё Минь Нго, хакер из маленького вьетнамского города, который в юности умудрился получить доступ к личным данным почти двухсот миллионов граждан США. Его путь начался с банального подросткового любопытства к интернету и закончился международной охотой, громким арестом и тюремным сроком.

Привет, Хабр. Меня зовут Михаил Тимошкин. Я тимлид в команде Тематических каналов в Дзене.

Одна из классических головных болей при создании сервиса — синхронизация кода приложения со схемой БД. Есть много инструментов для управления изменениями схемы базы данных, таких как Liquibase или Flyway, для которых существуют плагины с кодогенерацией. Но что, если на проекте ничего подобного нет? Хорошая новость в том, что даже в такой ситуации можно найти эффективное решение! В этом мы убедились на собственном опыте при переходе с Hibernate на jOOQ.

В этой статье я расскажу, с какой проблемой мы столкнулись, какие решения рассматривали и что получили в итоге.

Порой, очевидные вещи таят в себе удивительные сюрпризы. Казалось бы, простые SQL конструкции: «IN» и «NOT IN». Что тут обсуждать-то?

Неважно почему, но иногда может появиться желание заняться рефакторингом ваших скриптов liquibase. В моём случае постоянно возникали конфликты в общем файле журнала изменений, количество скриптов превратилось в ужасно длинный список, а в самих скриптах невозможно было ориентироваться, поскольку они содержали по 1–2 команды, а в названии файла были только дата и действие. Долго это терпел, долго взвешивал плюсы и минусы, и всё время боролся с желанием всё отрефачить. И в какой-то момент дошёл до точки, когда желание взяло верх.

Решение принято: рефакторингу быть! Сразу скажу, приступать было страшно, но сейчас я очень доволен результатом. «Идеальную» структуру мы не получили, пришлось идти на компромиссы и заплатить свою цену, зато в новой структуре удалось вылечить все проблемы. Теперь в ней удобно ориентироваться и читать код, конфликты создаются очень редко, а все скрипты автоматически детектируются liquibase-ом. Но только это конец истории. А вначале было вообще непонятно, как рефакторить журнал изменений, да так, чтобы в существующие базы данных он смог пролиться, и ничего не поломал при этом!

Привет, Хабр! На связи Марк — ведущий архитектор группы компаний «ГлоуБайт». В этой статье я поделюсь результатами нагрузочного тестирования, которое мы с коллегами провели для сравнения Greenplum 6 с Greenplum 7 и Cloudberry.