Базы данных *

Что общего у массового применения конфигураций, встроенной поддержки OpenTelemetry и управления HA-кластерами в пару кликов? Всё это — части пазла, который мы собираем, чтобы сделать администрирование PostgreSQL по-настоящему удобным и безопасным. Выход версии Postgres Pro Enterprise Manager (PPEM) 2.3 стал важной вехой в развитии нашего графического интерфейса. Мы добавили поддержку пользовательских пресетов, переработали систему алертинга и усилили RBAC-модель управления доступом. Разбираем ключевые нововведения релиза, которые помогут навести порядок в зоопарке конфигураций и спать спокойно, зная, что система сама предупредит о проблемах.

Всем привет!

Я Senior Java Developer в банке, и за эти годы мне довелось пройти немало собеседований. Где-то было спокойно, где-то — как в допросной, с каверзными вопросами, странными задачами и вечным «а почему так, а не иначе?». В процессе я собрал целую коллекцию тем, которые всплывают снова и снова, особенно когда дело касается баз данных.

Сегодня хочу поделиться этим опытом и разобрать вопросы, которые чаще всего задают именно по SQL-базам.

Этот пост станет глубоким разбором того, как мы снизили задержки P95 конечной точки API с 5 до 0,3 секунды при помощи нишевого трюка computer science под названием «фильтр Блума».

Мы расскажем о том, почему конечная точка была медленной, о решениях, которые мы рассматривали для повышения её скорости, и о критериях выбора между ними. Также мы объясним, как всё это устроено внутри.

Меня зовут Дмитрий Фатов, я разработчик в Газпромбанке — вместе с командой создаю платформу G2, на которой мы разрабатываем свои решения. Одно из решений — SaaS, система, в которой есть внешние интеграции через xml. До какого-то момента к нам приходило максимум 30 тыс. документов в одной выгрузке, но после подключения очень крупного клиента в одной выгрузке начали получать до 2 млн документов. Это около 4 млн записей в базе данных. 

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

В этой статье расскажу именно про последнюю часть — как ускорить вставку данных. Покажу, какие настройки стоит применить для Spring и Hibernate, для чего они нужны и какой буст по производительности дают. Здесь же разберем, как можно создать свою собственную прослойку для вставки данных в PostgreSQL. Эта прослойка позволит нам использовать разные подходы к вставке данных, в том числе кастомные методы PostgreSQL, а также распараллелить процесс вставки. Посмотрим, как ее можно подружить со Spring, а также какой профит нам даст каждый из рассмотренных подходов. 

Я наблюдал, как мой опытный коллега-финансист целый час колупался в Excel. Он гуру экселя, работает с ним 20 лет. Но увидев, как он печатает формулы, я не выдержал и показал пару простых трюков, от которых он пришёл в восторг.

Это была проблема незнания — незнания о функциях, которые лежат в Excel годами, экономят часы работы, но о которых просто никто не рассказывает.

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

Debezium — популярный фреймворк для Change Data Capture (CDC), позволяющий отслеживать изменения в источниках данных (таких как базы данных) и передавать их в потоковые платформы вроде Apache Kafka. Одним из компонентов Debezium является JDBC Sink Connector, предназначенный для записи данных из Kafka в реляционные базы данных посредством интерфейса Java Database Connectivity (JDBC). 

Debezium JDBC Sink Connector может решать множество задач: от репликации данных между БД и синхронизации обновлений между микросервисами до создания резервных копий данных для целей тестирования или разработки. Мы в VK Tech используем Debezium JDBC sink connector, чтобы строить перформанс-интеграции. Но в нагрузочных тестах столкнулись с проблемой производительности, которая не решалась никакими обходными путями. Поэтому нам пришлось детально погрузиться в нюансы обработки событий в Debezium JDBC connector.

Привет, Хабр. Меня зовут Артём Дубинин. Я старший разработчик Backend в команде Tarantool CDC — решения для репликации данных в реальном времени между системами управления базами данных (СУБД). В этой статье я изложу свою интерпретацию создания Debezium, расскажу о том, как работает Debezium JDBC connector, а также о нашем варианте оптимизации перформанса, который попал в Open-source версию.

История началась в далеком 2016 году, когда у меня был небольшой свечной заводик. Не свечной, конечно, но все же производство — и нужно мне было на нем сделать автоматизацию. Чтобы компоненты закупались вовремя, списывались со склада в правильном количестве и автоматически планировалось, какие операции делать в рамках рабочего дня. Тогда я впервые подумал, что неплохо бы иметь программируемый конструктор — что-то типа MS Access, но только в web и чтобы логика и запросы программировались одинаково и понятно.

В статье рассказываем о подходе к построению DWH на базе единой инфраструктуры данных (Unified Data Infrastructure), разработанной Andreessen Horowitz. 

Разбираемся, почему модель a16z полезна в быстрорастущих компаниях или тех, кто переходит к data-driven управлению.

Привет, Хабр! Меня зовут Валерий Пташкин, я руководитель направления в трайбе «Потребительское Кредитование» в Сбере. Статью я подготовил вместе с моими коллегами — Кириллом Макаровым и Евгением Беляевым.

Наш продукт отвечает за хранение клиентских заявок на потребительские кредиты, заявок кредитного потенциала, автокредитов, ипотечного кредитования и так далее. И в этом году мы перевели работу нашего модуля хранения с Oracle на СУБД Pangolin (сборка PostgreSQL с доработками от СберТеха).

При переезде у нас было несколько критичных требований к СУБД: способность держать достаточно высокую нагрузку (4 тысячи запросов в секунду), при этом иметь время отклика не более 100 мс для 99 % запросов, и обеспечивать максимально высокую доступность нашего сервиса как системы уровня mission critical.

В этой статье мы расскажем про состояние нашей инфраструктуры, этапы миграции, и коснёмся возможных нюансов и потенциальных рисков. Это будет полезно тем, кто тоже планирует переезд на СУБД Pangolin или другой форк PostgreSQL. Уверен, многие рекомендации будут полезны и пользователям стандартного PostgreSQL. Итак, начнём.

Привет, Хабр! Меня зовут Александр Гришин, я руководитель по развитию продуктов хранения данных в Selectel. Сегодня я предлагаю продолжить разбираться с PostgreSQL и заглянуть еще глубже в эту кроличью нору. Посмотрим, что происходит под капотом СУБД во время записи строк, поверхностно разберем, как устроены страницы памяти, что такое tuple, tuple chain, fillfactor, VM и FSM. Эти знания помогут разработчикам не только понимать, как работает база данных, но и эффективно управлять ее производительностью в продакшене.

Если вы начинающий DBA, разработчик, инженер или архитектор облачной инфраструктуры, эта статья для вас. Погнали?

В порыве ностальгии листая письма с далёкой родины я нашёл в почтовом ящике письмо о розыгрыше. Обычно такие письма лежат в папке Спам, но оно почему-то пробилось сквозь фильтры.

NB! Данный пост является информационным, опубликован с целью показать IT-сообществу как несогласованные действия SMM-специалистов могут отразиться на безопасности проектов в целом. Помните, что незаконный сбор персональных данных карается в большинстве стран мира.

Всем привет!

Меня зовут Александр Борисов, я главный эксперт по технологиям в СберТехе. В статье расскажу про свой алгоритм, который позволил повысить скорость Unicode в PostgreSQL 18. На эту тему уже выпущен патч Optimization for lower(), upper(), casefold() functions, принятый сообществом PostgreSQL.

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

Начнём с краткого обзора: что же удалось ускорить в PostgreSQL?

Всем привет! В первой части https://habr.com/ru/articles/958356/ мы познакомились с форматом XBRL-CSV2, который позволяет упаковать сложность XBRL-отчетности в простые и удобные для обработки CSV-таблицы. Мы обсудили, как данные и их метаописания (маппинг) преобразуются из XML-представления в реляционное.

Но сбор данных — это только половина дела. Вторая, не менее важная часть — это их проверка на целостность, непротиворечивость и соответствие бизнес-правилам. В классическом XBRL за это отвечает формульный слой (Formula Layer). Сегодня мы поговорим о том, как мы превратили эти формулы в исполняемые SQL-скрипты, создав так называемый «слой отделяемых формул».

YDB — отказоустойчивая геораспределённая СУБД класса Distributed SQL. Она появилась в недрах Яндекса более десяти лет назад и прошла длительный путь от узкоспециализированного хранилища, применявшегося в поисковом движке, до полновесной СУБД общего назначения. Открытие исходного кода YDB в 2022 году стало одной из наиболее ярких опенсорс-инициатив Яндекса.

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

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

Команда Go for Devs подготовила перевод статьи о том, почему большинству проектов не нужна Kafka, «веб-масштабные» очереди и зоопарк из пяти баз данных. Автор на бенчмарках показывает, как далеко можно уехать на одном Postgres — и заодно разбирает, почему карго-культ масштабирования и «инфраструктура ради резюме» только мешают делать работу.

Техподдержка бывает разная. Где-то это «попробуйте перезагрузить» или «проверьте провод», а где-то — сложные инженерные задачи, которым не жалко посвятить хоть всю жизнь. Какой вариант в поддержке Postgres Professional и кого/чего больше в этой сфере — людей или технологий, — разбираемся со старшим инженером технической поддержки Postgres Professional Камилем Каримовым.

В статье Архитектура высоконагруженной платформы Magnit F&R было рассказано о ключевых архитектурных принципах и решениях.

Сегодня хочу поделиться практическим опытом: как в Magnit Tech изменилась концепция Data Lakehouse, где она блестяще сработала — и где подвела.

Я, Алексей Соболеков, лид архитектуры F&R.

И это история о том, как красивая теория сталкивается с физикой доступа к данным.

VaryPack — новый, простой, гибкий, шустрый и компактный формат бинарной сериализации произвольных данных.

Многие задаются вопросом: «Зачем мне семантический слой? Что это вообще такое?» В этом практическом руководстве мы соберём самый простой семантический слой — всего лишь из файла YAML и Python-скрипта. Цель не в том, чтобы построить слой ради самого слоя, а в том, чтобы понять его ценность. Затем мы выполним запросы к данным о 20 миллионах поездок нью-йоркских такси, используя согласованные бизнес-метрики, при этом запросы выполняются через DuckDB и Ibis. К концу вы точно будете понимать, когда семантический слой действительно решает проблемы, а когда это избыточно.

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

Это универсальная платформа, где данные под полным контролем, а точность запросов на порядок выше. Text-to-SQL — лишь первое применение. Архитектура позволяет решать любые AI-задачи, где критична надежность.