Базы данных *

Мы забыли вовремя создать партиции, и все новые данные полетели в events_default_partition. Default дорос до ~1.1 ТБ, а простое «ATTACH PARTITION» требовало часов сканирования и долгой блокировки. В статье — почему «быстрые» рецепты оказываются медленными, как я перенёс данные в нужные диапазоны, и как мы уложили критическую блокировку в 44 с.

Default-партиция — это не озеро Байкал. Если туда всё сливать, экосистема потом мстит.

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

А для нас, коллеги, это мощный инструмент, позволяющий быстрее решать различные задачи. Многие кто уже успел попробовать Cursor и подобные инструменты, восхищаются как ИИ способен писать код.

В этой статье речь пойдёт о менее заезженной, но не менее актуальной теме – как ИИ уже сейчас помогает проектировать базы данных.

Привет, Хабр. Это дайджест для тех, кто занимается бэкендом: от продакшен-Docker, CI/CD и Kubernetes до баз данных, мониторинга и архитектуры сервисов. Мы собрали открытые уроки и курсы, которые фокусируются не на абстрактной теории, а на реальных задачах — масштабировании, отказоустойчивости, наблюдаемости и поддержке сложных систем в проде. Если вы развиваете бэкенд-сервисы, отвечаете за их стабильность или хотите системно расти от уровня к уровню, здесь можно точечно закрыть пробелы и выстроить понятную траекторию обучения.

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

Мы много работаем с компаниями, которым необходимо использовать отечественное ПО для баз данных. В таких проектах часто уже есть инфраструктура на MS SQL Server, PostgreSQL или Oracle Database. Основной конфликт — требования регуляторов и высокая стоимость миграции логики приложений на другую СУБД.

Мы создали продукт, который нативно понимает диалекты и позволяет работать с существующими базами без переписывания кода. В статье расскажем, как развернуть Digital Q.DataBase для начала работы с базами без долгой и затратной миграции.

Привет, Хабр! На связи — технические лидеры направления разработки Apache Spark в составе платформы Data Ocean Андрей Первушин и Дмитрий Паршин из Data Sapience. Мы занимаемся решением нетривиальных задач в области Spark-вычислений, некоторые из которых становятся частью конечного продукта.

Сегодня мы расскажем, с какими проблемами можно столкнуться при реализации Upsert Streaming в Iceberg, что такое equality delete, почему они создают нагрузку при чтении таблиц в Apache Iceberg и как мы оптимизировали Apache Spark, чтобы снизить потребление памяти и ускорить чтение данных.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Чаще всего в интеграциях мы сталкиваемся с настройкой обмена для баз 1С. Предположим, у нас 8 конфигураций 1С, связанных между собой, и нужно навести порядок. В статье расскажу, как мы придумали снизить стоимость разработки, а также значительно сократить время на рутинные задачи.

Мы создали комплексную систему автоматического развертывания кластеров PostgreSQL, протестировали ее более 150 раз, внедрили у заказчика в изолированной инфраструктуре, и все заработало.

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

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

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

Привет, Хабр! Делимся переводом статьи о патче, сделанном разработчиком «Тантор Лабс» для 19 версии PostgreSQL — по сути, частичкой вклада нашей компании. Благодаря коммиту Ильи Евдокимова, в PostgreSQL 19 планирование JOIN’ов станет до 16 раз быстрее. Если раньше алгоритм сравнения частых значений (MCV) работал за O(N²), и при target=10k само планирование запроса могло занимать десятки миллисекунд, то теперь вместо квадратичного перебора будет использоваться хеш-таблица, а это снижает сложность до O(N). Изменение особенно оценят те, кто работает с неравномерными данными и поднимает default_statistics_target выше 1000.

Подробный разбор с тестами и графиками — в переводе статьи о нашем патче.

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

Подход Инмона обещал «единый источник истины» в корпоративном хранилище — и обернулся бюрократией и запредельной стоимостью любого изменения. Подход Кимбалла дал скорость за счет удобных витрин, но ценой стали хаос, дублирование и информационные «силосы». Data Vault 2.0 — гибкий, аудируемый и мощный — без автоматизации превратился в проклятие для многих команд. И, наконец, Data Mesh: отличная организационная модель, которая дала командам автономию. Каждый домен сам владеет данными, сам отвечает за качество, сам развивается.

Но Data Mesh оставил открытым главный вопрос: как заставить всех этих независимых владельцев данных говорить на одном языке? Команды получили свободу, но работают на общей инфраструктуре, единой платформе с ее хранилищами, ETL-процессами, каталогами. И эта платформа осталась прежней: ждет команд от инженеров, требует ручного вмешательства, не умеет сама связывать данные из разных доменов. Дали командам независимость, но забыли дать им общий «мозг».

А что, если изменить непосредственно природу платформы данных? Сделать ее не пассивным набором инструментов, а системой, которая сама понимает данные, сама связывает домены, сама управляет качеством и развивается вместе с бизнесом?

Про концепцию такой платформы мы и хотим рассказать. Мы назвали ее AIDA (Adaptive Intelligence Data Architecture).

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

Чтобы понять цепочку блокировок, обычно строят их дерево рекурсивными запросами. Но частое выполнение таких запросов может существенно замедлить работу СУБД. В худшем случае можно усугубить проблему, которую мы пытаемся диагностировать.

Меня зовут Александра Кузнецова, я бэкенд-разработчик в СберТехе, в команде Platform V Kintsugi — это графический инструмент для сопровождения, разработки и диагностики СУБД на основе PostgreSQL. Расскажу о том, как мы с коллегами интегрировали сбор данных о блокировках в наш мониторинг сессий. Решение работает в фоне и не нагружает БД. И дерево блокировок можно построить для любого момента в прошлом, даже через несколько дней после инцидента. Начнём.

Я из тех, кто всерьёз задумывается о проектировании и реализации хеш-таблиц. Недавно обнаружился донельзя милый вариант, который заслуживает широкой огласки. Это робин-гудовская открытая адресация с применением линейного зондирования, где размер самой таблицы увеличивается как степень двойки. Если вы не знакомы с терминологией хеш-таблиц, то все эти слова могут показаться вам каким-то невразумительным салатиком, но, когда мы разберём этот пример с привлечением кода — всё должно стать понятнее.   

Чтобы не пришлось усложнять код, начнём со следующих допущений:

В мире разработки часто возникает соблазн использовать знакомый инструмент для всех задач. Зачем изучать что-то новое, если есть проверенная реляционная база данных (РСУБД), такая как PostgreSQL или MySQL? Однако, когда дело доходит до реализации мощного, быстрого и релевантного поиска, этот подход терпит неудачу.

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

Чтобы статья была максимально практико-ориентированной, мы рассмотрим, как с помощью Spring Boot быстро поднять приложение с интегрированным Elasticsearch и реализовать поиск, который «летает».

Что общего у запросов из 1С, конструкции IN (VALUES ...) и безобидного выражения x + 0? Все они способны превратить выполнение запроса из миллисекундного дела в многоминутное ожидание, потому что стандартный планировщик PostgreSQL на них «спотыкается». Разбираем, как расширение pgpro_planner переписывает неудобные куски дерева запросов в дружелюбный вид еще до того, как оптимизатор успеет выбрать неудачный план, и почему некоторые из этих решений уже попали в ванильный PostgreSQL 18.

«Обучил, запустил и забыл» — плохая стратегия работы с ML‑моделями, но она часто встречается после удачного тестирования. Качество моделей может незаметно снижаться, и если пропустить этот момент — последствия могут дорого стоить. Когда мы начали задумываться о системе мониторинга, одна из наших моделей начала выдавать предсказания, которые требовали незамедлительного вмешательства в выстроенную работу. Но разум подсказывал, что проблема не в процессе, а в модели. О том, каким трудоемким оказалось наше расследование, и как мы восстанавливали и изучали каждую составляющую процесса почти вслепую, читайте по ссылке.

Быть детективами нам понравилось, но вкладывать столько усилий в каждый подобный случай не хочется. Мы поняли, что нужно научиться контролировать работу модели так, чтобы своевременно находить проблему и чинить ее, используя минимальное количество ресурсов. В серии из двух статей расскажу, как мы построили систему мониторинга ML‑моделей силами одного человека за несколько месяцев. 

В эпоху урбанизации, когда мегаполисы и региональные центры России растут как на дрожжах, вопрос доступности социальной инфраструктуры выходит на первый план. Родители, ищущие ближайший детский сад для своего малыша, урбанисты, планирующие новые жилые кварталы, или городские власти, стремящиеся оптимизировать транспортную сеть, — все они сталкиваются с одной и той же проблемой: как быстро и точно оценить, насколько "дружественен" город к пешеходам? Сколько минут пешком до ближайшей школы? А до игровой площадки? Эти вопросы, кажущиеся простыми, на деле требуют сложных расчетов, анализа геоданных и визуализации, которая была бы интуитивно понятной.

Именно здесь на сцену выходит Георейтинг — инновационный проект, разработанный командой Геоинтеллект. Это мощный инструмент анализа, который превращает абстрактные данные о расстояниях в живые, наглядные инсайты. Запущенный недавно, Георейтинг уже вызывает интерес среди специалистов и обычных пользователей, обещая стать незаменимым помощником в повседневной жизни. 

Города растут, районы меняются, а людям по-прежнему нужно простое и честное понимание: удобно здесь жить или нет?

До сих пор такую оценку каждый делал сам: «вроде недалеко», «дойти можно», «там есть садик, но как далеко?». Георейтинг убирает эти догадки: теперь доступность района — это цифры и визуализация.

Кому это нужно?

Импортозамещение аналитических систем остаётся одной из наиболее трудоемких задач в корпоративной ИТ-среде. Особенно когда речь идёт о платформах уровня SAP BW/4 HANA: больших объемах данных, сложной архитектуре, множестве отчетов и строгих нефункциональных требованиях. В подобных проектах важны не только выбор стека и корректная миграция хранилища, но и организационные решения, планирование и работа с пользователями.

Всем привет! Меня зовут Михаил Синельников, я лидер кластера импортозамещения аналитической отчетности в ВТБ. Вместе с моим коллегой Владимиром Ведяковым, ИТ-лидером проекта со стороны компании «Сапиенс Солюшнс», мы описали в этой статье перенос системы аналитической отчетности SAP BW/4 HANA на импортонезависимый стек. В этом материале представлен наш практический опыт: ключевые решения, подходы к планированию, особенности реализации и выводы, которые могут быть полезны командам, работающим с аналогичными задачами.

Всем привет! Меня зовут Сергей Бунатян, я руководитель службы в Техплатформе Городских сервисов Яндекса. 

На сегодняшний день существует довольно много брокеров сообщений. Наиболее часто используемыми в индустрии, пожалуй, будут те, которые, реализуют парадигму очереди сообщений. Самых известных представителей вы наверняка знаете, — Apache Kafka и RabbitMQ, а внутри Яндекса широко используется Logbroker. И, тем не менее, как нетрудно догадаться из этого вступления, мы зачем‑то решили написать свой брокер сообщений.

Сегодня я расскажу про нашу систему, которая называется STQ — Sharded Tasks Queue. По названию системы можно было бы подумать, что это ещё один сервер очередей, однако это будет не совсем верно. STQ — это скорее message broker. 

В этой статье я постараюсь рассказать о том, какие задачи перед нами стояли и как это нас привело к решению написать что‑то своё. А заодно поделюсь опытом эксплуатации нашей системы и расскажу про влияние STQ на опыт разработчиков.

Здравствуйте, меня зовут Дмитрий Карловский и я.. да не важно кто я. Важно о чём я говорю, и как аргументирую.

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

С момента первого релиза Postgresus прошло 6 месяцев. За это время проект получил 246 коммитов, новые функции, а также ~2.7 звёзд на GitHub и ~40к загрузок из Docker Hub. Сообщество проекта тоже подросло, сейчас в проекте числится 11 контрибьюторов, а группа в Telegram — 85 человек.

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