Недавно я изучал детали реализации взаимодействия клиента PostgreSQL с базой данных и был удивлён, насколько легко просматривать трафик PostgreSQL с помощью wireshark. Когда я поделился своим удивлением в социальной сети, меня попросили привести пример того, как это сделать.
Substrait — это промежуточный формат (IR) для обмена планами запросов между системами. Он снимает боль диалектов SQL, позволяет делать pushdown в разные бэкенды и избавляет от повторного парсинга/оптимизации федеративных системах и позволяет относительно безболезненно заменять один бэкенд другим. Ниже - зачем он нужен, как устроен и кто поддерживает.
В первой части мы обсудили философские основы и принципы работы рейтинговой системы, где у каждого человека разная сила голоса, отражающая его полезность для конкретного сайта (офелократия). Теперь перейдём к техническим деталям реализации на MySQL.
Некоторые из IT-компаний говорят, что поддерживают open source. На деле это нередко означает использование чужого кода и PR-активность. Мы считаем, что настоящий вклад — это коммиты в ядро. И чтобы делать это системно, мы открыли инженерный центр не в столичном бизнес-парке, а в месте, где фундаментальная наука — часть культурного кода. Рассказываем, почему будущее системного программирования мы строим в новосибирском Академгородке.
Последние несколько лет я параллельно писал код, преподавал и экспериментировал с форматами обучения. В какой-то момент понял, что преподавание — это тоже проект, просто с другим типом пользователей. И за 2 года обучил более 1000 студентов. В этой статье подробно расскажу, зачем вообще разработчику делать курсы и как системно подойти к их созданию. Бонусом в конце поделюсь советами и инсайтами.
Во время выполнения очередного проекта мне пришлось работать с Битрикс ORM, при этом параллельно в системе был инстанс Laravel. Две разные ORM работали с единой базой данных. Не буду вдаваться в причины, по которым был выбран такой подход, и воздержусь от его оценки. Суть в том, что мне приходилось одновременно работать с двумя принципиально разными системами. Этот опыт привел меня к фундаментальному выводу: ORM — не для меня.
Когда мы пишем запрос, СУБД делает гораздо больше, чем просто ищет данные. Она оценивает десятки сценариев выполнения, сравнивает стоимость операций и выбирает оптимальный путь к результату. От этого выбора зависит, будет ли запрос выполняться секунду или минуту. Почему одни системы находят лучший план, а другие выстраивают менее эффективный алгоритм? Попробуем разобраться, как планировщики СУБД принимают решения и что определяет их эффективность.
Apache Iceberg — табличный формат для озёр данных с поддержкой ACID, Schema Evolution, Hidden Partition и версионирования, но при больших метаданных и работе через S3 страдает планирование запросов и латентность. В связке со StarRocks мы показываем, как распределённый Job Plan, Manifest Cache, CBO с гистограммами, Data Cache и материализованные представления выводят lakehouse‑аналитику на уровень DWH: снижают накладные расходы на метаданные, ускоряют планы и выполнение, а запись обратно в Iceberg сохраняет единый источник истины. Разбираем архитектуру Iceberg, типовые узкие места и практики оптимизации на StarRocks 3.2–3.3, включая кейс WeChat/Tencent.
Алгоритм двухфазной блокировки (Two-Phase Locking, 2PL) — один из старейших механизмов управления параллелизмом, используемых реляционными СУБД для обеспечения целостности данных. В этой статье я расскажу, как работает алгоритм 2PL и как его можно реализовать на любом языке программирования.
В предыдущей статье обсуждали регламентное обслуживание с акцентом на пересчет статистик. Операция крайне полезная, необходимая и чем интенсивнее меняются данные в базе, тем важнее актуальные статистики. Сегодня поговорим про еще одну регламентную операцию – пересчет индексов. Как всегда с акцентом на высоконагруженные системы 1С.
"Нужно?", "Не нужно?", "А если у меня SSD-диск?", "А какой эффект от перестроения индексов?", "А я не успеваю за ночь. Что делать?"
Разберем подробно все нюансы.
Транзакции — не про «магическое ACID», а про конкретную механику согласованного доступа к данным под нагрузкой.
Эта статья объясняет как реально работают уровни изоляции и чем отличаются популярные СУБД на практике.
Мы разберём:
Началось все весьма прозаично, клиент позвонить к нам в техподдержку и спросил «а как бы мне поставить ваш софт но в другую схему БД». Собственно вопрос проще некуда — мы писали на спринге, а значит лезем в application.yml и ставим схему. Но, клиент не из тупых и уже это попробовал — не сработало.
Начинаем разбираться что сломалось и кто виноват. Первым делом ДевОпс повторяет кульбиты клиента и выдает простой вердикт: «В 151 миграции лажа». Я открываю и: «батюшки родный, да это же лосенок явное указание схемы!»
Всем привет! В этой коротенькой статье я попытаюсь вам доказать, что внешние ключи (foreign keys) в СУБД — не нужны и только вредны.
Можно ли смоделировать хаос пуассоновских потоков бронирований и конечный автомат состояний рейса (от «по расписанию» до «приземлился») целиком внутри PostgreSQL? Мы решили, что для создания идеальной учебной базы данных — можно. Вместо старых статичных таблиц мы построили генератор, имитирующий жизнь глобальной авиакомпании. Рассказываем, зачем это было нужно и почему старая база на 2,5 ГБ перестала справляться с задачами.
Один запрос выполняется 100 мс, другой — меньше 1 мс. Оба делают одно и то же, но второй написан на странном, почти алхимическом SQL. В чём подвох? Первый использует OR, а второй — хитрую комбинацию AND. Этот перевод — расследование того, почему условие OR так дорого обходится вашей базе данных, и практическое руководство по тому, как проектировать схемы, чтобы избежать этой ловушки производительности.
Задача: быстро выполнять агрегирующие запросы (JOIN, GROUP BY, COUNT) по десяткам миллионов строк в офлайновых сценариях на Big Data‑платформе. Мы сравнили три подхода: Parquet + Impala в экосистеме CDH, MPP‑движок Greenplum и MPP‑СУБД StarRocks. В единой тестовой среде (SAD ~7 млн, ITEM ~3 млн записей) выполнили серию запросов JOIN + GROUP BY + ORDER BY и замерили суммарное время 10 прогонов. Показано, что внедрение MPP заметно ускоряет аналитику (типично 1–2 с на запрос), при этом StarRocks в среднем немного обходит Greenplum. В статье — методика, параметры развертывания, нюансы импорта из Oracle (CloudCanal) и сводные метрики.
Лайфхаки для миграций, оптимизации и избегания граблей
Реальные лайфхаки и проверенные практики по миграциям, оптимизации запросов, управлению индексами и обратной совместимости кода. Узнайте, как:
• Не сломать прод при миграции.
• Избежать N+1 и других проблем SQL-запросов.
• Планировать откаты и работать безопасно на высоконагруженных БД.
В прошлый раз, в первой части нашего гида по Apache Cloudberry™, мы поговорили об истории проекта, его архитектуре, ядре СУБД и функциях платформы.
Но помимо ядра СУБД, мы также хотим использовать data‑lakehouse‑запросы. В Data Lakehouse есть некоторые проблемы: мы не можем получать данные оттуда напрямую. В Cloudberry разработана технология, с помощью которой можно это делать, так что поговорим об этом подробнее. А также рассмотрим ещё несколько интересных возможностей и расскажем о планах проекта.
Все мы видели, как нейросети рисуют крокодило бомбардино и балерин-капучино. Но я хочу рассказать, как нейросеть помогла с реальным бизнес процессом.
Это история о том, как я написал полноценную CRM-систему с помощью ChatGPT, работая обычным менеджером по работе с заказчиками.
В статье я расскажу о практических кейсах и сложностях, возникающих (и возникавших) в процессе миграции данных между СУБД (Oracle -> Postgres), а также о собственном инструменте миграции данных, который вы также можете попробовать.
