Базы данных *

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

На первый взгляд работа с данными может показаться скучной, состоящей из перетаскивания данных из одного хранилища в другое. В этом действительно есть часть правды :) но не вся правда… Если присмотреться, мы увидим, что дата-инженеры помогают компаниям сокращать время на поиск инсайтов, обучение моделей и понимание нужд пользователей. Данные — это новая нефть, поэтому важно понимать, как правильно их организовывать и какие сложности в работе могут повлиять на успешность бизнеса.

Привет, Хабр! Меня зовут Алёна Катренко, и я уже больше 10 лет работаю с данными. Сейчас занимаю позицию руководителя платформы данных в Циане, но начинала как BigData-инженер в Неофлексе. Сегодня расскажу, как мы приручали петабайты данных, искали призраков забытых таблиц и нашли инструмент, который сделал работу с метаданными понятной, безопасной и полезной для бизнеса. А ещё о том, как сейчас развиваться дату-инженеру, чтобы успевать за тенденциями на рынке.

 Привет!

У бизнеса на практике часто встречается задача построить полноценную аналитику, используя данных из excel, csv файлов. Разнообразие подходов к заполнению и образованию таких файлов может быть разное:

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

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

1. Анализ рабочей нагрузки и требований
2.Разработка схемы данных
3. Настройка хостовых машин
4. Настройка конфигурации Cassandra
= ВЫ НАХОДИТЕСЬ ЗДЕСЬ =
5. Настройка топологии кластера
6. Подключение Prometheus Cassandra Exporter
7. Подключение Prometheus Node Exporter
8. Вывод всех метрик в Grafana
9. Проведение нагрузочного тестирования
10. Дополнительный тюнинг по результатам теста

Двинемся дальше?

В этой статье мы подробно рассмотрим все ключевые параметры OpenSearch, включая дашборды, документы, индексы, узлы, кластеры, шардирование, инвертированные индексы и сам процесс индексации. Понимание этих аспектов позволит максимально эффективно использовать OpenSearch для решения задач поиска и анализа данных в любых проектах.

Привет, Хабр! Меня зовут Евгений Ляшенко, я старший разработчик IBS. В эпоху, когда объемы данных растут с каждым днем, эффективный поиск информации становится критически важным для бизнеса и разработчиков. OpenSearch как мощный инструмент для полнотекстового поиска и аналитики предлагает гибкие решения для работы с большими массивами данных. Чтобы наглядно продемонстрировать его работу, я создал pet-проект с поиском по библиотеке книг и фильмов. Но сначала немного теории.

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

 Пару слов о нашей команде и о том, чем мы занимаемся. У нас 6 инженеров данных и 5 аналитиков — вместе мы помогаем продуктовым командам (тем, кто развивает сайты и приложения) создавать дашборды и отчёты. Они нужны для того, чтобы коллеги видели, как их изменения влияют на бизнес-метрики и поведение пользователей.

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

Как появилась задача

Наши пользователи — маркетологи — каждую неделю сталкивались с одной проблемой. По вторникам у них проходят планёрки с руководством, где они разбирают результаты прошлой недели: что сработало, что можно улучшить. Им критично важно к этому времени уже иметь готовый отчёт, чтобы успеть проанализировать данные и принять решения по рекламе.

Однако наш продукт выдавал отчёты только к 16:00. Кому-то хватает часа на подготовку, кому-то трёх, но пользователи жаловались: они просто не успевают осмыслить данные и сформулировать выводы.

Коллеги обратились к нам с запросом: перенести формирование отчетов на 12:00, чтобы оставалось больше времени на анализ. И мы стали думать, как это сделать своими силами без увеличения команды.  

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

Недавно я понял, что не знаю, что такое Hadoop.

(На этом моменте становится понятно, что данная статья ориентирована на людей, которые не имеют экспертизы и реального опыта взаимодействия с продуктами экосистемы Hadoop)

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

В этот момент я решил узнать, чем обоснована необходимость использования этих инструментов и что они из себя представляют.

17.06.2025 г. ФСТЭК России зафиксирована критическая уязвимость в платформе 1С:Предприятие 8 под номером BDU-2025-07182. Этот дефект позволяет злоумышленникам, действующим удаленно, получить несанкционированный доступ к системе от имени произвольного пользователя, что создает серьезные риски для компаний, использующих решения 1С в своих бизнес-процессах.

Что грозит в связи с этим малому и среднему бизнесу? И как защититься? Подробно рассказываю далее.

Миф о волшебном параметре fast=true жив и здоров, но в распределённых СУБД появляется ещё один — distributed=true. Ни тот, ни другой не спасут, если не пересобрать схему, ключи шардирования, последовательности, запросы и процесс миграции. Мы трезво проходим по всем углам: от выбора ключей и colocated-таблиц до CDC, топологий и ограничений внешних ключей; показываем, где действительно ускорится, а где станет дороже — и что с этим делать.

Проект Trino (ранее PrestoSQL) изначально разработан в Meta, чтобы аналитики могли выполнять интерактивные запросы по широкому спектру хранилищ данных на базе Apache Hadoop. Благодаря эффективной обработке крупных наборов и сложных запросов, а также гибкому подключению к множеству источников данных, Trino быстро стал предпочтительным инструментом аналитики для крупных организаций.

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

StarRocks как новый аналитический движок получил широкое признание отрасли. Он демонстрирует заметные преимущества по производительности, поддержке высокой степени параллелизма и низкой задержке, привлекая внимание крупных компаний, таких как WeChat , Xiaohongshu (RedNote), Ctrip, Beike и др. Как именно StarRocks формирует свои преимущества? В чём его сходства и различия с Trino? Ниже — подробный разбор.

Я Евгений Прочан, в платформенной команде Magnit OMNI развиваю инфраструктуру DWH. Расскажу здесь, почему нам понадобилось перейти от батчинга к CDC и как мы это делали. Причин перехода было две: потребность бизнеса в расширении возможностей инфраструктуры и нестабильность нашего старого процесса репликации. 

Мы используем в основном базы данных PostgreSQL. Оттуда пакетами раз в час передаём данные в S3, ClickHouse и таблицы Iceberg. Наша потоковая нагрузка достигает примерно полутора терабайта данных, 6000 операций в секунду (около 1500 в самой нагруженной базе данных). 

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

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

Быть или не быть? Стоит ли использовать key-value-базы данных в большом продакшне? На связи Иван Храмов, CTO МТС ID, и Николай Диденко, техлид из команды инфраструктуры МТС Web Services. Мы используем Cassandra в МТС ID и за годы эксплуатации познали и сильные, и слабые стороны этого решения.

Главная особенность и одновременно ограничение Cassandra и ScyllaDb — это то, что они строго key-value-хранилища. Именно с этим они справляются отлично — быстрое чтение и запись по ключу, георезервирование и масштабирование. На этом этапе все выглядит радужно.

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

Привет, Хабр! На связи Сергей Гайдамаков. Продолжаем обсуждать и тестировать набор реплик MongoDB. 

В предыдущей статье мы рассмотрели структуру отдельного узла MongoDB, разобрали свойства параметров writeConcern и readConcern для работы с набором реплик MongoDB. 

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

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

Привет, Хабр! Меня зовут Олег Доронин, и мы с командой делаем СУБД Яндекса, которая называется YDB. Каждый транзакционный запрос к базе данных обычно работает с небольшим набором строк и быстро отрабатывает за единицы или десятки миллисекунд, но таких запросов каждую секунду поступает огромное количество. А вот аналитические запросы обычно выполняются не так часто, но каждый из них может требовать обработки вплоть до всех строк в одной или нескольких таблицах. Такие запросы могут выполняться секунды, минуты, или даже часы в зависимости от объёмов данных и сложности запрошенных вычислений.

Чтобы эти два принципиально разных паттерна нагрузки не мешали друг другу, гибридным базам данных важно изолировать транзакционную нагрузку от аналитической. Под катом я расскажу, как мы сделали в YDB компоненты для управления смешанной нагрузкой, которые изолируют миллионы RPS от аналитики, и как менеджер смешанной нагрузки устроен внутри.

Поводом для насписания статьи послужил доклад Евгения Воропаева "Разработка и отладка 64-битного счётчика транзакций" на конференции PG BootCamp 2025. При написании статьи была найдена реальная история патча и раскрыта тайна зоны special блоков PostgreSQL.

В статье описывается история создания патча, вводящего поддержку 64-битных номеров транзакций в PostgreSQL и почему он есть только в коммерческих форках. Статья особенно ценна тем, что под ней есть комментарий автора патча, Александра Короткова.

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

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

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

Эпоха, когда бизнесу достаточно было просто владеть данными, осталась в прошлом. Теперь их нужно интерпретировать, делать легкодоступными, встраивать системы, поддерживающие принятие решений. При этом объемы данных растут, их форматы множатся, а сценарии использования — усложняются.

Чтобы справиться с этим, компании переходят на более гибкие подходы к управлению данными. В этой статье разберем четыре наиболее популярные архитектуры: Data Warehouse, Data Lake, Data Lakehouse и Data Mesh. Обсудим, чем они отличаются и какую выбрать под конкретные задачи.