Базы данных *

Привет! Меня зовут Антон Касимов, я руководитель Gals Software, а еще сертифицированный тренер и эксперт по Zabbix. В общем, могу сказать, что знаю эту систему чуть больше уровня «видел пару раз интерфейс». Zabbix — одна из самых популярных в мире систем мониторинга. Наверное, не существует компаний с собственной инфраструктурой, у которых не было бы Zabbix. Не так давно мы запустили услугу аудита Zabbix и обнаружили некоторые закономерности, на которые я хотел бы обратить внимание в этой статье. В нашем телеграм-канале Zabbix Recipes мы регулрно делимся нашими находками и публикуем анонсы вебинаров (скоро и по этой теме тоже будет), поэтому приглашаю присоединиться. Я построю повествование так, чтобы вы могли пройтись по статье как по чек-листу и проверить свою инсталляцию на предмет возможных улучшений. Погнали!

Один аналитический запрос способен испортить p99 latency всего OLTP-трафика — на время, пока горячий рабочий набор не прогреется заново с диска. Это cache pollution, и с ним рано или поздно сталкивается любая СУБД с честным LRU.

Разбираем, как мы решили эту проблему в нашем OLTP-движке: почему выбрали Clock-sweep вместо LRU, как BufferRing изолирует полные сканы от горячих данных, и почему no-steal — это не стилистический выбор, а требование корректности recovery. С кодом, инвариантами и честными оговорками про то, что ещё не сделано.

Apache Doris 4.1 добавляет UPDATE, DELETE и MERGE INTO на Iceberg-таблицы прямо из SQL-клиента — без отдельного Spark job. Iceberg V3 Deletion Vectors и Row Lineage делают этот DML архитектурно здоровым: нет линейной деградации от delete files, нет false positives в CDC после compaction. Перевод и адаптация статьи Mingyu Chen (CC BY 4.0) с бенчмарками, SQL-примерами и Quick Start.

Объектный построитель SQL-запросов без ORM и моделей. Позволяет писать сложные SQL-запросы в виде цепочек Python-методов (table[‘person’].filter(…).join(…).get()) и получать результат в виде списка словарей. Под капотом — параметризованные запросы для защиты от инъекций, продуманная система кеширования с инвалидацией по таблицам (in-memory и Redis), поддержка синхронного и асинхронного кода из коробки. Для тех случаев, когда ORM избыточна, а сырой SQL небезопасен.

Утилита резервирования pgBackRest перестала поддерживаться, стало актуальным найти ей замену. Главными альтернативами называют WAL-G и Barman. Можно использовать pg_basebackup+pg_receivewal. Преимущество WAL-G в том, что резервирование возможно по протоколу S3, WAL-G обеспечивает более высокую скорость резервирования и сжатия, имеет неплохие перспективы развития. Кроме протокола S3, WAL-G может резервировать и восстанавливать из директории в файловой системе, работает с Patroni. Директория с бэкапами не обязательно должна находиться на локальном диске, можно смонтировать любую файловую систему, например, NFS. Утилита свободно распространяемая.

В статье рассматриваются примеры команд, которыми можно резервировать и восстанавливать PostgreSQL утилитой WAL-G с обеспечением защиты от потерь транзакций (zero data loss).

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

Меня зовут Денис Пашков, я – ведущий архитектор данных в группе компаний GlowByte. В этой публикации я бы хотел поделиться опытом работы с MPP-решением StarRocks, набирающим популярность на российском рынке. Все, кто интересуется данной темой, уже, наверное, не сомневаются, что StarRocks очень хорошо себя показывает в аналитической нагрузке. Мои коллеги из Data Sapience регулярно делятся результатами нагрузочных испытаний платформы данных Data Ocean Nova (ознакомиться можно: 1, 2 и 3). Сегодня же речь пойдет о неочевидном сценарии использования – OLTP-нагрузке.

Когда сервис поднимается по 8-15 минут, команда почти всегда начинает крутить одни и те же ручки: увеличивает initialDelaySeconds, добавляет startupProbe, поднимает progressDeadlineSeconds, иногда переносит миграцию в initContainer и считает, что стало «по-кубернетесному». Обычно это не лечение. Это способ аккуратнее завернуть проблему в YAML. Если тяжёлая миграция живёт внутри старта приложения, вы связали жизненный цикл Pod, rollout Deployment и поведение базы в один общий узел. А такие узлы в проде рвутся не там, где их ждут.

Привет! Меня зовут Ильсаф, я инженер данных в MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов. В этой статье я собрал свои практические наблюдения по работе Kafka Connect и Debezium с PostgreSQL: от настройки репликации до мониторинга и бэкфиллинга.

jsonb легко полюбить. Он даёт гибкую схему, позволяет не плодить десятки мелких колонок, хорошо подходит для полуструктурированных данных и обычно очень удобен на старте проекта. Пока документы маленькие и меняются редко, кажется, что всё отлично.

Проблемы начинаются позже. Данные растут, в документ добавляются новые поля, часть из них начинает часто обновляться, а потом внезапно выясняется, что вроде бы безобидный UPDATE одного ключа внутри jsonb стоит заметно дороже, чем ожидалось.

В этой статье мы не собираемся доказывать, что jsonb плохой тип данных. Наоборот: jsonb – один из самых полезных инструментов PostgreSQL. Хотелось бы разобраться в более узком вопросе:

что именно происходит, когда мы обновляем один ключ внутри большого JSONB-документа, и чем это отличается от обновления обычной колонки рядом с таким же большим документом?

Привет, Хабр! Меня зовут Катя, я продакт-менеджер в Lenta Tech («Группа Лента»). Сегодня хочу рассказать о том, как цифровой клон покупателя помогает сделать персональные офферы с конверсией в лиды.

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

В логистике всё редко выглядит как аккуратная CRM из презентации.

Заявки (аукционы/тендеры/грузы приходят из разных источников. Часть данных живёт в 1С/Битрикс/Excel/Амбарная книга, часть — в SQL, часть — в интерфейсах сайтов, часть — в голове менеджера. Перевозчики отвечают неравномерно, менеджеры работают через звонки и таблицы, а руководителю нужно быстро понимать: какие заявки есть сегодня, где рента, какие маршруты повторяются, кто из менеджеров проседает, где найти транспорт.

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

Но довольно быстро стало понятно: сама таблица не закрывает главный сценарий.

Человеку всё равно нужно руками формулировать фильтр, помнить названия полей, переключаться между поиском, аналитикой и рекомендациями. Плюс в логистике своя внутренняя бизнес кухня, прибыль идет от типа ТС (реф/тент/изотерм/прочие) + сезонность, А если надо спросить что‑то вроде «какая ставка/руб‑км Краснодар — Москва тент?» или «сравни двух менеджеров за неделю», таблица превращается в набор ручных действий.

Так внутри поиск‑панели появился нейробот.

Привет, Хаброжители! Исправление ошибок в базах данных PostgreSQL может быть трудоемким и рискованным процессом — особенно при внесении изменений в работающую систему в реальном времени. К счастью, можно учиться на ошибках, которые уже совершили другие! Автор подробно описывает, как выявлять и предотвращать самые распространенные, опасные и скрытые антипаттерны проектирования при работе с PostgreSQL.

Redis всё чаще встречается в вакансиях для QA, и понимание его работы становится полезным навыком для тестировщика.

В статье простым языком объясняется, что такое Redis, где он используется, чем отличается от реляционных баз данных и почему он работает быстрее SQL.

Также разбираются практические случаи применения Redis в тестировании: проверка данных, ускорение тестов, подготовка нужного состояния системы и отладка.

Подойдёт для подготовки к собеседованиям и для работы на реальных проектах.

Привет, Хабр! Меня зовут Евгений Грибков, я ведущий разработчик в центре технологий VK. В этой статье я покажу решение, к которому мы с коллегами пришли при работе над одной из наших внутренних систем.

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

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

Базовые RAG-системы уже научились неплохо справляться с прямыми вопросами по тексту. Но только если ответ лежит в одном конкретном абзаце, а вопрос сформулирован почти так же, как сам исходный документ. Попробуйте заставить систему связать факты из трёх разных источников или сделать банальный логический вывод. В большинстве случаев результат будет неутешительным. А уж про поиск скрытых связей я даже спрашивать боюсь.

Сегодня рассмотрим open-source RAG-фреймворк HippoRAG 2. В сфере RAG главным преимуществом данного фреймворка является качество ответов, потому что принципы его работы основаны на реальном человеческом мозге. Давайте разберёмся, откуда он взялся, как устроен изнутри и как его запустить.

Меня зовут Дмитрий Кудряшов. За моими плечами 12 лет службы в структуре ФНС, из которых последние годы я занимал должность заместителя начальника отдела анализа и планирования налоговых проверок в региональном Управлении ФНС.

С недавнего времени я веду свой Telegram-канал «Налоговый инсайдер», где показываю как в действительности осуществляется налоговый контроль, отвечаю на вопросы и разбираю ситуации из комментариев. Сегодня на площадке Хабра я хочу поделиться ответом на комментарий, в котором читатель искренне усомнился в реальных возможностях баз данных ФНС и написал следующее:

Работать с Kafka в DBaaS — удобно: инфраструктура поддерживается сильно проще, пока вы фокусируетесь на логике приложения. Но есть нюанс: прямой доступ к брокерам и CLI ограничен. Это усложняет отладку, анализ данных и диагностику consumer — особенно если у вас десятки топиков и групп.

Kafka UI — это Open Source-инструмент, который решает описанную проблему: он предоставляет веб-интерфейс для просмотра топиков, сообщений и состояния consumer groups без прямого доступа к брокерам.

На связи Ксения Ершова, проектировщик интерфейсов в Selectel. В статье расскажу, как развернуть на облачном сервере Kafka UI в публичном доступе, подключить его к Kafka-кластеру в DBaaS Selectel и проверить, что все работает.

Всем привет!

На одном из проектов я настраивал дашборд в Yandex DataLens, который объединяет данные о трафике из Яндекс Метрики с данными о заказах из CRM и позволяет анализировать доход в разрезе источников трафика.

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

Привет, Хабр! Меня зовут Ян Пиле, руковожу в MAGNIT TECH направлением развития алгоритмов доступности товаров. Задача моей команды: сделать так, чтобы в магазине, куда вы зашли за своим любимым майонезом, он с большей вероятностью оказался на полке. А если не оказался — чтобы сотруднику магазина как можно быстрее прилетело задание: «проверь, почему именно этой позиции сейчас нет, и, если возможно, верни её обратно».

Мы уже дважды писали про OSA (On-Shelf Availability — уровень доступности товара на полке). В статье «Как OSA превращает пустые полки в полные корзины?» рассказывали про продуктовый контекст: зачем эта история нужна бизнесу и почему «товар числится в системе» и «товар реально лежит на полке» — это два совершенно разных утверждения. А в статье «Когда 0 в продажах — аномалия? CUSUM для поиска проблем в ритейле» мы подробно разбирали один из рабочих алгоритмов команды. В этот раз я хочу пройтись по всему стеку детекции целиком — от самых простых правил до А/Б-тестов, в которых приходится бороться с зависимыми наблюдениями.

Привет, меня зовут Юля, я дата-инженер в департаменте аналитических решений ЮMoney. Мы разрабатываем и поддерживаем ETL(ELT)-процессы загрузки данных для BI-продуктов компании: отчётов, дашбордов, витрин, API и других.

В этой статье поделюсь, как мы разрабатывали MVP для построения data lineage системы и к каким выводам пришли, — так вы сможете адаптировать подход под свои процессы.

Проблема, которая привела нас к разработке MVP, заключается в том, что в начале работы над большинством задач требуется подготовительная аналитика: восстановить путь происхождения данных, чтобы понимать, какие ETL(ELT)-процессы будут затронуты и на что повлияют изменения. Это увеличивает время выполнения задачи. Но, что ещё существеннее, процесс достаточно рутинный: каждый раз необходимо проводить статический анализ кода и изучать документацию (при её наличии). Мы решили автоматизировать эту работу, чтобы иметь под рукой инструмент для построения пути данных по точкам их обработки и применения, — то есть создать data lineage систему.