Последние несколько лет я параллельно писал код, преподавал и экспериментировал с форматами обучения. В какой-то момент понял, что преподавание — это тоже проект, просто с другим типом пользователей. И за 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), а также о собственном инструменте миграции данных, который вы также можете попробовать.
StarRocks Lakehouse на практике: пошаговый гайд по интеграции с Apache Hive через Hive Catalog. На прикладочном сценарии «управление заказами» показываем, как построить слой ODS/DWD/DWS/ADS в озере данных и ускорить запросы без миграции данных: от создания таблиц и генерации тестовых наборов до подключения External Catalog. Разбираем включение Data Cache для ускорения чтения из HDFS/S3/OSS (Parquet/ORC/CSV) и применение асинхронных материализованных представлений в StarRocks для витрин DWD/DWS/ADS. Поясняем, как добиться быстрых запросов за счёт векторизированного движка и CBO, а также даём практические советы по настройке (Kerberos/HMS, конфигурация BE/FE, прогрев кэша, сбор статистики, MV‑rewrite). Материал будет полезен инженерам по данным и архитекторам DWH, которым нужна аналитика в реальном времени по данным озера без лишнего ETL.
С распространением сценариев real-time аналитики, lakehouse & modern BI всё чаще сталкиваются две флагманские аналитические СУБД: ClickHouse и StarRocks. Одна из ключевых конкурирующих битв ведётся не на маркетинговом поле, а в производительности, гибкости архитектур и удобстве поддержки сложных аналитических схем.
ClickHouse, будучи зрелым и широко используемым решением, зарекомендовал себя как очень быстрый колонковый движок, оптимизированный для агрегаций, фильтров и чтения узкого поднабора колонок из огромных объёмов данных. ClickHouse+2Instaclustr+2 Он эффективен в задачах логов, телеметрии, веб-аналитики и других OLAP-нагрузках, где схемы часто «расстилаются» — с минимальным числом джоинов и высокой степенью денормализации. Decube+2Wikipedia+2
Однако подход ClickHouse — оптимизация работы с плоскими таблицами и минимизация связанных таблиц — становится ограничением, когда бизнес-сценарии требуют моделирования звёздной схемы (fact + dimension) и выполнения динамических запросов с join’ами. В таких случаях ClickHouse часто вынужден либо смягчать нагрузку через ETL денормализацию, либо сталкиваться с трудоёмкими запросами. CelerData+2StarRocks+2
Вот где StarRocks начинает оспаривать лидерство. Он предлагает архитектуру, ориентированную на эффективные join и агрегации “на лету”, поддерживая материализованные представления (MV), которые автоматически обслуживаются и подменяются при выполнении запросов. DZone+3StarRocks+3StarRocks+3 В бенчмарках StarRocks часто показывает преимущество: в тестах на SSB (набор из 13 запросов) StarRocks в среднем быстрее ClickHouse почти вдвое. StarRocks Docs+2CelerData+2
Если вы когда-нибудь собирали аналитику по кликам, метрикам или логам, то знаете цену вопроса: хочется SQL за миллисекунды, хранение в дёшёвом объектном хранилище, минимум «танцев» с кластером и—если повезёт—MIT-лицензию без ловушек. На одном берегу — «тяжёлые» распределённые OLAP-системы (ClickHouse, Pinot, Druid), на другом — специализированные TSDB (InfluxDB, TimescaleDB, QuestDB). Между ними набирает силу «озёрный» подход: складывать сырые события в Parquet, а считать — встраиваемым движком с Arrow/FlightSQL поверх.
GigAPI как раз из этой когорты: DuckDB + Parquet, чтение из локального диска или S3, запросы через FlightSQL (gRPC) и HTTP, режимы writeonly/readonly/compaction, один контейнер для старта и понятная философия «делай просто, делай быстро». Проект обещает суб-секундные аналитические запросы, компактизацию и дружбу с FDAP-миром (Arrow/DataFusion/Parquet/Flight) — всё то, что нравится инженерам, уставшим от «зоопарков» сервисов.
Привет, Хабр! Если последние годы вас не отпускала фантомная боль от вечного выбора между ураганной скоростью ClickHouse, невозмутимой простотой SQLite и порой адской сложностью настройки InfluxDB, — возможно, вы, как и мы, дождались чего-то по-настоящему нового.
На горизонте появился проект Arc от команды Basekick Labs. Это не просто очередная попытка, а дерзкая заявка на соединение всего лучшего из мира time-series и lakehouse-подхода. Забудьте о тяжёлых серверах и мучительной шардированной архитектуре. Arc предлагает:
