Сегодня не будет кейса про успешный успех. Этот кейс о том, как одна массовая операция может за день уничтожить данные, которые собирались годами.
Я Антон Карцев, генеральный директор и основатель Флайск. И сейчас расскажу историю из практики интегратора, с реальными последствиями, о которых, обычно, не говорят.
Привет, Хабр! Делимся переводом статьи о патче, сделанном разработчиком «Тантор Лабс» для 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 человек.
В этой статье я расскажу, что поменялось в проекте за полгода, какие новые возможности появились и какие планы дальше.
Как YDB разворачивается «в бою», что происходит при сбоях, как работает восстановление, как ведет себя кластер под нагрузкой, с какими сюрпризами столкнется команда, которая будет ее администрировать. Весь анализ — с фокусом на уменьшение операционных затрат и повышение надежности.
От поиска по архивам документов и медиафайлам до рекомендательных систем и AI приложений — всюду работают эмбеддинги и векторный поиск. Но когда дело доходит до выбора конкретного инструмента, глаза разбегаются: Qdrant, Milvus, Weaviate, Redis, Elasticsearch, Pgvector…
Если вы:
• планируете внедрять семантический поиск в свой продукт,
• выбираете между проверенными временем БД и специализированными системами обработки векторов,
• ищете независимые бенчмарки,
то этот материал — для вас. Мы разберем основные концепции векторного поиска, сравним популярные open-source решения и протестируем скорость их работы с учетом загрузки процессора и памяти.
Привет, Хабр!
Знаете, что объединяет разработчика из стартапа, архитектора банковской системы и техлида платежного сервиса? Все они хотя бы раз материлась над интеграцией, которая должна была занять день, а растянулась на месяц. Легаси не подружилось с новой системой, протоколы оказались несовместимы, а документация — устаревшей на три года.
Сколько я пользуюсь SQL, столько же он меня бесит. Сегодня хочу рассказать про свой прототип языка для создания больших и сложных аналитических запросов, который компилируется в SQL. Он будет опираться на структуру конкретной БД, и даже больше — он будет опираться на логику данных.
Миграция ЦОД — не новая история. Казалось бы, про важность обследования инфраструктуры перед переездом уже знают все. Но на практике ошибки повторяются снова и снова — даже у тех, кто делает это не впервые.
Меня зовут Артём, я ведущий инженер департамента информационных технологий в iCore. В этой статье я постарался собрать ключевые моменты, на которые стоит обратить внимание при обследовании инфраструктуры перед миграцией. Надеюсь, это поможет избежать распространенных проблем и упростит процесс миграции.
Разработка софта всегда была поиском баланса между разными аспектами, вроде скорости разработки (как быстро ты выкатываешь новые фичи), производительности приложения, потребления им памяти, красотой интерфейса и отполированностью логики.
В большинстве случаев скорость разработки важнее, чем производительность и потребление памяти.
ORM — это как раз инструмент, экономящий время разработки. Но за счёт чего?
This is a hands-on case study of migrating Trip’s UBT from ClickHouse to StarRocks with storage–compute separation. By redesigning partitioning, enabling DataCache and MergeCommit, and backfilling history via SparkLoad, we reduced average query latency from 1.4 s to 203 ms, P95 to 800 ms, cut storage from 2.6 PB to 1.2 PB, and decreased node count from 50 to 40. We detail Compaction tuning, partitioned materialized views, and second‑level elastic scaling without data migration, and compare gohangout vs. Flink in reliability and operability. The article targets data engineers and architects running high‑load real‑time OLAP workloads.
