Базы данных *

Как разрешить пользователю реплики удаленно подключаться к Master-серверу PostgreSQL?

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

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

Чтобы решить эту проблему, необходимо отредактировать конфигурационный файл клиентской аутентификации pg_hba.conf на стороне Master-сервера и явно разрешить репликацию для IP-адреса вашей реплики.

Откройте конфигурационный файл клиентской аутентификации:

nano /etc/postgresql/17/main/pg_hba.conf

Обратите внимание, что тут рассматривается настройка репликации на примере PostgreSQL 17.

Найти точное расположение файла можно в командной строке PostgreSQL с помощью команды SHOW:

sudo -u postgres psql -c "SHOW hba_file;"

Добавьте в pg_hba.conf следующую строку, указав вместо REPLICA_ВНУТРЕННИЙ_IP сетевой адрес вашего ведомого сервера:

host    replication    replicator    REPLICA_ВНУТРЕННИЙ_IP/32    scram-sha-256

Для доступа к реплицируемым данным у пользователя replicator должна быть привилегия replication:

ALTER ROLE replicator WITH REPLICATION;

Предварительно ознакомьтесь с порядком применения правил в pg_hba.conf в официальной документации.

Чтобы PostgreSQL применил изменения в конфигурации авторизации, выполните reload службы в терминале:

systemctl reload postgresql

В качестве альтернативы можно отправить сигнал процессу postmaster с помощью pg_ctl reload, вызовом SQL-функции pg_reload_conf() или используя kill -HUP.

После применения изменений Master-сервер начнет принимать входящие пакеты от указанного IP-адреса, и процесс репликации сможет успешно инициализироваться.

На первый взгляд, настройка репликации в PostgreSQL кажется простой задачей: достаточно открыть доступ в pg_hba.conf и подключить standby-сервер.

Но в production-инфраструктуре за этой «простой настройкой» скрывается целый стек инженерных задач: необходимо следить за консистентностью WAL-журнала, контролировать лаг между репликами, обеспечивать безопасную сетевую доступность между узлами, настраивать резервное копирование, регулярно тестировать сценарии аварийного переключения и быть готовым вручную восстанавливать кластер в случае деградации одного из серверов.

Поэтому в ряде сценариев современные команды переходят от self-managed PostgreSQL к PaaS-решениям вроде Managed Databases, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.

Это позволяет сократить операционные расходы на сопровождение инфраструктуры и снизить риск простоев критичных сервисов.

Где бэкенд начинает тормозить: 18 открытых уроков по языкам, данным и архитектуре

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

В августе и сентябре преподаватели OTUS проведут бесплатные уроки для бэкенд‑разработчиков. В программе — Python, Go, C# и JVM, микросервисная архитектура, PostgreSQL, брокеры сообщений, наблюдаемость и контейнеризация. Выбирайте свою тему и присоединяйтесь к практическим разборам.

Архитектура и взаимодействие сервисов

• 3 августа, 20:00. «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться

• 4 августа, 20:00. «Секреты межсервисных запросов: как сделать приложение быстрым и надёжным». Записаться

• 12 августа, 20:00. «Паттерны отказоустойчивости и масштабируемости микросервисной архитектуры». Записаться

• 13 августа, 20:00. «Управление данными в MSA — дыра в бюджете или актив для ИИ-трансформации?». Записаться

• 19 августа, 20:00. «Монолит или микросервисы? Руководство для архитекторов, которые ценят свои нервы». Записаться

• 24 августа, 20:00. «Основные шаблоны проектирования в системном дизайне». Записаться

Языки, память и конкурентность

• 3 августа, 20:00. «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться

• 4 августа, 20:00. «Многозадачность в Python. Асинхронность, процессы, потоки». Записаться

• 5 августа, 20:00. «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust». Записаться

• 18 августа, 20:00. «Python asyncio: gather, wait, TaskGroup на практике». Записаться

• 18 августа, 20:00. «Горутины и каналы: базовые принципы параллелизма в Go». Записаться

• 18 августа, 20:00. «Архитектурные ошибки, которые совершают даже опытные C#-разработчики». Записаться

Базы данных и работа с состоянием

• 11 августа, 20:00. «Работа с SQLAlchemy и Alembic в FastAPI». Записаться

• 19 августа, 20:00. «PostgreSQL на стероидах: большие данные, высокие нагрузки и масштабирование без боли». Записаться

• 1 сентября, 20:00. «PostgreSQL 18: асинхронный I/O и io_uring на практике». Записаться

• 16 сентября, 20:00. «Темпоральные данные в PostgreSQL 18: история и версии без триггеров». Записаться

Наблюдаемость и контейнеризация

• 4 августа, 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

• 20 августа, 20:00. «Docker для Python-разработчика». Записаться

Что почитать перед практикой

1. Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт
   _{Путь от чтения RFC и реализации обработчика запросов до запуска сервера в контейнере. Внутри — защита исполняемого файла, ограничения для HTTP/2, работа с облачными площадками и поиск утечки памяти в OpenSSL.}

2. std::expected в C++23: гайд по миграции с исключений на функциональный error handling
   _{Как сделать ошибку явной частью сигнатуры функции, выстраивать цепочки операций и постепенно внедрять std::expected в существующий проект.}

3. Move-семантика в C++: пять задач, в которых легко ошибиться
   _{Разбор ловушек, которые успешно компилируются, но приводят к лишним копированиям, замедлению программы или неопределённому поведению.}

4. Миграция на Spring Boot 4 и Java 25: пошаговый план, чтобы обновиться и не уронить прод
   _{План обновления рабочего сервиса с промежуточными этапами, автоматизированными проверками, канареечным развёртыванием и заранее подготовленным сценарием отката.}

JSON или XML: сравнение популярных форматов обмена данными

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

В статье разобрали оба формата на одинаковых примерах, прошлись по истории и причинам, по которым JSON вытеснил XML в вебе. Сравнили по ключевым параметрам: синтаксис, объем, скорость обработки, поддержка типов данных, комментарии, пространства имен, валидация через JSON Schema и XSD. И отдельно написали про области применения.

Подробности — в блоге Рег.облака.

Программирование с явно выделенным состоянием

Одна из моих любимых тем, про которую не устаю говорить. В модели данных часто бывает ситуация, когда состояние выражено не прямым образом, а косвенно. Буквально вчера я реализовывал кастомные тарифы под конкретных пользователей. Отличие такого тарифа от обычного сводится к тому, заполнено ли поле user_id в тарифе или нет. Если не заполнено, то значит это общий тариф, если заполнено, значит под конкретного пользователя и другие его не могут видеть.

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

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

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

Приглашаем на пятилетие «Тантор Лабс». 10 сентября - Tantor JAM 2026

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

Программу скоро представим. Среди главных премьер:

• Новое поколение Платформы Tantor, основанное на AI-first подходе. Представим ИИ-администратора БД с целым роем специализированных ИИ-агентов, которые возьмут на себя рутинные операции по работе с СУБД.

• Результаты испытаний МБД Tantor XData Gen3 на различных профилях нагрузки. Покажем, как enterprise-технологии, ранее доступные только в зарубежных решениях, — независимое масштабирование Compute и Storage, RDMA, распределенная файловая система и полноценный HTAP — становятся доступны в российском ПАКе.

• Подробнее расскажем о Tantor Polar — новой распределенной СУБД, открывающей следующий этап развития российских PostgreSQL-технологий с полным сохранением совместимости с экосистемой Postgres.

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

10 сентября 2026 года, Москва

Регистрация уже открыта.

Участие бесплатное (требуется подтверждение от организатора).

Вышла бесплатная книга к курсу «SQL Введение»

Всем привет!

Недавно я публиковал здесь бесплатный курс «SQL Введение» на платформе Stepik. За это время курс уже начали проходить более 400 студентов.

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

Бесплатный курс: https://stepik.org/a/290855

Зачем появилась книга

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

Поэтому я решил подготовить книгу, полностью основанную на материалах курса. Она повторяет структуру уроков и позволяет легко закреплять пройденный материал.

Что представляет собой книга

Книга полностью соответствует программе курса и может использоваться параллельно с его прохождением.

Её можно использовать как:

• офлайн-версию курса для повторения материала;

• удобный конспект при выполнении практических заданий;

• справочник для быстрого повторения основных конструкций SQL.

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

Для кого она будет полезна

Так же, как и сам курс, книга ориентирована на тех, кто только начинает знакомство с SQL:

• студентов IT-специальностей;

• начинающих разработчиков;

• будущих аналитиков данных;

• тестировщиков;

• всех, кто хочет разобраться в основах работы с реляционными базами данных.

Бесплатный доступ

Книга распространяется бесплатно.

Если вы проходите курс «SQL Введение», она уже доступна внутри курса в качестве дополнительного учебного материала.

Кроме того, книга опубликована на GitHub, где всегда можно скачать последнюю актуальную версию.

https://github.com/Awilum/sql-introduction

Чтобы скачать последнюю актуальную версию, перейдите в раздел Releases, где всегда доступен самый свежий выпуск книги. 

https://github.com/Awilum/sql-introduction/releases

Буду рад вашим отзывам, предложениям и замечаниям как по курсу, так и по книге. Надеюсь, этот дополнительный материал сделает изучение SQL ещё более удобным и понятным.

В предыдущих видео я рассказывал о том, как Digital Q.DataBase воспроизводит функциональность Microsoft SQL Server, позволяя переносить приложения без переписывания прикладной бизнес-логики. Мой коллега Илья Лебедев также подробно рассказал о возможностях воспроизведения функциональности Oracle и подходах к миграции Oracle-приложений.

В этом докладе Илья Виссарионов рассказывает о практическом опыте компании «Диасофт» по импортозамещению крупной автоматизированной банковской системы, которая десятилетиями работала на Microsoft SQL Server.

Главной особенностью проекта стало то, что значительная часть бизнес-логики была реализована в виде хранимых процедур. Полное переписывание миллионов строк SQL-кода оказалось бы слишком дорогим и длительным, поэтому был выбран другой путь — развитие Digital Q.DataBase с максимальной совместимостью с Microsoft SQL Server и сохранением существующих приложений.

В докладе подробно рассматриваются реальные технические проблемы, с которыми столкнулась команда при переносе банковской системы на PostgreSQL-совместимую платформу: различия в типах данных, работе процедур, оптимизаторе запросов, производительности, временных таблицах, пользовательских типах данных и других механизмах СУБД.

Отдельное внимание уделено нагрузочному тестированию. Автор показывает, как поэтапная оптимизация Digital Q.DataBase позволила добиться производительности, сравнимой с Microsoft SQL Server, а по ряду операций — превзойти её, при этом сохранив существующую бизнес-логику без масштабного переписывания.

В этом видео вы узнаете:

🔹 почему импортозамещение крупных банковских систем требует особого подхода;
🔹 с какими проблемами столкнулась команда при переносе АБС с Microsoft SQL Server;
🔹 почему стандартного PostgreSQL оказалось недостаточно;
🔹 какие механизмы совместимости были реализованы в Digital Q.DataBase;
🔹 как удалось сохранить существующий T-SQL-код без его переписывания;
🔹 какие доработки были выполнены для повышения производительности;
🔹 как проводилось нагрузочное тестирование на реальных банковских сценариях;
🔹 каких результатов удалось добиться по сравнению с Microsoft SQL Server.

Если вас интересуют вопросы импортозамещения СУБД, миграции корпоративных систем или построения PostgreSQL-совместимых платформ корпоративного уровня — этот доклад будет полезен разработчикам, архитекторам, администраторам баз данных и техническим руководителям.

Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений.
Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.

🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива  
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase   
🔹 MAX: https://max.ru/join/orlthIssLJbjj37mjlEEYARWFyuJk5yMixLlGPISIzc

Как мы воспроизводим функциональность Oracle и создаем аналоги DBMS-пакетов.

В предыдущем посте я рассказывал о технологии «Полиглот» в Digital Q.DataBase — возможности исполнять T-SQL "на лету" наряду с родным PL/pgSQL, что позволяет мигрировать приложения с Microsoft SQL Server.

Но полиглотность Digital Q.DataBase этим не ограничивается.

Сегодня хочу поделиться выступлением моего коллеги Ильи Лебедева, посвящённым Oracle-направлению. В докладе он подробно рассказывает о поддержке PL/SQL и о том, как Digital Q.DataBase помогает переносить системы с Oracle, сохраняя серверную бизнес-логику и клиентские приложения без дорогостоящей переработки.

В этом выступлении обсуждаются:

🔹 Как Digital Q.DataBase реализует полноценную поддержку Oracle-диалекта, включая пакеты, DBMS-пакеты и PL/SQL-код.
🔹 Почему SQL- и PL/SQL-код может выполняться без изменений.
🔹 Как работает мастер переноса баз данных и какие скорости миграции можно получить на практике.
🔹 Каким образом обеспечивается бесшовное подключение существующих приложений через OCI и JDBC.
🔹 Почему переход с Oracle на Digital Q.DataBase может занять месяцы вместо лет.
🔹 Как накопленный опыт миграций позволяет ускорять последующие проекты и снижать объем доработок.

В докладе также показаны реальные сценарии переноса корпоративных систем, демонстрация работы клиентских приложений после замены СУБД и подход компании к развитию совместимости с Oracle на основе запросов заказчиков.

Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений.
Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.

🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива  
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase   
🔹 MAX: https://max.ru/join/orlthIssLJbjj37mjlEEYARWFyuJk5yMixLlGPISIzc

Новости мира Datalakehouse - DWH: на 26.06.26

"гонка сместилась к ИИ-агентам"

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

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

Databricks (их большая конференция прошла 16 июня). Показали новый движок Lakehouse//RT - он обещает выдавать аналитику почти мгновенно прямо из общего хранилища, без отдельной быстрой базы под витрины. Пока это ранняя версия и работает только на чтение, то есть данные через него можно читать, но не записывать. Второй анонс - способ держать «живые» рабочие данные и аналитику в одном месте, без постоянной перекачки между системами (обычно компании гоняют данные туда-сюда ночными выгрузками). Третий, и самый показательный - набор инструментов, чтобы пускать к данным ИИ-агентов: объяснять программе смысл данных и контролировать, куда ей можно лезть, а куда нет.

ClickHouse (своя конференция 27 мая). Это очень быстрая база для аналитики. Они запустили собственную управляемую версию Postgres - популярной базы, на которой работают тысячи приложений, - и научили её мгновенно отдавать все изменения в аналитику, без задержек. Плюс добавили ИИ-агентов поверх данных, построенных на Claude. По деньгам у них всё хорошо: годовая выручка за год утроилась и перевалила за 250 миллионов долларов.

Snowflake. Открыли свой каталог данных Polaris - это, грубо говоря, общее оглавление всех таблиц, по которому разные программы понимают, где что лежит. Раньше он был только их, теперь его передали в открытый фонд Apache, чтобы пользоваться им могли любые инструменты. А популярный открытый формат таблиц Iceberg дорос до новой версии и научился хранить более сложные данные.

SAP покупает компанию Dremio (сделка ещё не закрыта). Крупный вендор корпоративного софта докупает технологию, чтобы собрать собственное хранилище нового типа под ИИ. Это часть общего движения: рынок сходится вокруг одного открытого формата данных - того самого Iceberg.

DuckLake дорос до версии 1.0. Маленький и нарочно простой проект: он хранит оглавление данных в обычной знакомой базе (Postgres), а не в куче разрозненных служебных файлов, как делают старшие конкуренты. Меньше магии - проще обслуживать.

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

Дальше разберу каждый анонс по отдельности. Ждите продолжения.

Подъехало продолжение:

Databricks (их большая конференция прошла 16 июня) - ссылка на подробный разбор

ClickHouse (своя конференция 27 мая) - ссылка на подробный разбор

В этом докладе я (Жуйков Андрей, амбассадор компании «Диасофт») рассказываю о подходе Digital Q.DataBase к импортозамещению зарубежных СУБД и миграции корпоративных систем без переписывания прикладного кода.  

В видео рассмотрены: 

🔹 архитектура и возможности Digital Q.DataBase; 
🔹 технология Polyglot и поддержка нескольких SQL-диалектов в одной СУБД; 
🔹 совместимость с Microsoft SQL Server и Oracle; 
🔹 исполнение T-SQL и PL/SQL без изменения бизнес-логики приложений; 
🔹 поддержка протокола TDS и работа со стандартными драйверами Microsoft; 
🔹 миграция 1С с Microsoft SQL Server на Digital Q.DataBase; 
🔹 демонстрация работы через DBeaver, SQL Server Management Studio и Python; 
🔹 поддержка Service Broker, Reporting Services и CLR-сборок; 
🔹 примеры реальных проектов и опыт внедрения у заказчиков.  

Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений.

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

🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива  
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase   

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

#digitalqdatabase  #Diasoft #PostgreSQL #MicrosoftSQLServer #Oracle #Импортозамещение #СУБД #Database #TSQL #PLSQL #1С #DataBaseMigration #жуйковандрей

Бесплатный курс «SQL Введение» для тех, кто начинает изучать базы данных

Всем Привет!

Недавно я опубликовал новый бесплатный курс «SQL Введение» на платформе Stepik и хочу рассказать о нём сообществу.

https://stepik.org/course/290855

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

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

Курс ориентирован на тех, кто:

• никогда раньше не работал с базами данных;

• не писал SQL-запросы;

• хочет понять основы SQL перед дальнейшим обучением;

• учится на IT-специальности;

• рассматривает карьеру разработчика, аналитика данных, тестировщика или бизнес-аналитика.

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

Что изучается в курсе

В рамках курса рассматриваются базовые принципы работы реляционных баз данных и основные конструкции SQL.

В процессе обучения вы разберётесь с основами SQL и научитесь:

• понимать, как устроены таблицы и данные

• писать первые SQL-запросы

• выбирать столбцы из таблицы

• фильтровать данные

• использовать операторы сравнения

• формировать простые выборки

Материал построен по принципу «от простого к сложному». Каждый новый урок опирается на предыдущий, поэтому курс подходит даже тем, кто начинает изучение SQL с нуля.

Курс включает:

• теоретические уроки;

• тестовые задания для проверки понимания материала;

• практические упражнения с SQL-запросами.

Главная цель курса — помочь новичку разобраться в фундаментальных принципах работы с данными и научиться уверенно писать свои первые SQL-запросы.

Почему курс бесплатный

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

Буду рад обратной связи, замечаниям и предложениям по улучшению курса.

Начать обучение можно здесь:

https://stepik.org/course/290855

30 июня эксперты «Тантор Лабс» представят разбор Tantor XData Gen3 — третьего поколения машины баз данных для высоконагруженных корпоративных систем, реализующей ряд технологий, ранее доступных в таких западных продуктах как Oracle Exadata, SAP HANA и IBM Netezza.

В программе:

• эволюция архитектуры Tantor XData и ключевые изменения в Gen3: независимое масштабирование подсистем вычислений и хранения, полноценная обработка смешанной нагрузки (HTAP) на едином наборе данных;

• новые возможности платформы и сценарии их применения;

• устройство и особенности распределенной СУБД Tantor Polar;

• организация вычислительных ресурсов и ресурсов хранения;

• инструменты управления и мониторинга.

Отдельный блок будет посвящён практической работе с машиной баз данных. Пройдем интерактив с реальным ситуациями, демонстрирующими преимущества новой машины баз данных перед классическими СУБД.

Эксперты мероприятия:

• Вадим Яценко, генеральный директор «Тантор Лабс»

• Сергей Серегин, руководитель технического пресейл «Тантор Лабс».

Когда: 30 июня, начало в 11:00 (онлайн)

Зарегистрироваться

TXORDER-01: 7 тестов прошли, 8-й нашёл баг

Как domain state в одном тесте сделал видимым баг в порядке операций внутри транзакции — и что это говорит о том, что на самом деле проверяют “зелёные тесты”

7 тестов прошли.

8-й нашёл баг в production flow.

Не потому что был написан лучше. Потому что запустился с другим начальным состоянием системы.

Операция и транзакция

PATCH /reschedule — перенос appointment пациента на другой слот. Атомарная транзакция: освободить старый слот, занять новый, переместить запись. Плюс promoteFromWaitlist: если на освобождённом слоте есть очередь, первый из неё автоматически получает appointment.

Порядок операций в транзакции:

1. free_old_slot(slot1)

2. promoteFromWaitlist(slot1)

3. book_new_slot(slot2)

4. move_appointment(appointment → slot2)

Почему 7 тестов ничего не нашли

Тесты 1–7 проверяли стандартные сценарии: перенести pending, перенести confirmed, попытаться перенести на занятый слот. Ни в одном из них не было пациента в вейтлисте.promoteFromWaitlist в каждом тесте — no-op. Очередь пуста, функция вызывалась, ничего не делала, возвращала успех. Это важная деталь: функция не падала. Она просто не активировалась. Порядок операций вокруг неё не имел значения — потому что одна из операций ничего не делала.

7 зелёных тестов говорили: reschedule работает корректно. На самом деле они говорили: reschedule работает корректно когда вейтлист пуст.

Что нашёл 8-й тест

Пациент 2 встал в очередь на slot1. Пациент 1 запустил reschedule на slot2.

Ответ: 409 SLOT_IN_USE.

Слот был свободен. Пациент имел право переноса. Транзакция откатилась.

Механизм

1. free_old_slot(slot1) ← слот доступен

2. promoteFromWaitlist(slot1) ← пациент 2 получил pending на slot1

3. book_new_slot(slot2)

4. move_appointment → slot2 ← appointment пациента 1 ещё на slot1

После шага 2 на slot1 два active appointment одновременно: пациента 1 (ещё не переехал) и пациента 2 (только что из промоушна). UNIQUE constraint one_active_per_slot. Откат. 409.

Транзакция дисциплинированно выполняла логически неверную последовательность — и откатывалась на constraint.

Фикс

Appointment должен покинуть slot1 до того как promote вставляет нового пациента:

1. book_new_slot(slot2)

2. move_appointment → slot2

3. free_old_slot(slot1)

4. promoteFromWaitlist(slot1)

8-й тест прошёл

Что означают 7 зелёных тестов

Тест проверяет поведение системы при конкретном начальном состоянии. Если в наборе тестов нет нужного domain state — класс ошибок невидим, сколько бы тестов ни прошло.

В данном случае критическое условие — пациент в вейтлисте — отсутствовало во всех семи тестах. promoteFromWaitlist` был no-op в каждом из них. Баг в порядке операций существовал с момента написания — просто не было состояния которое его активировало.

Атомарность транзакции гарантирует: либо все операции выполнятся, либо ни одна. Она не гарантирует что операции написаны в правильном порядке. Это разные гарантии — и мы путали их семь тестов подряд.

Скрытое предположение “Я решилf что если транзакция атомарна — порядок операций внутри неё можно не тестировать. На самом деле транзакция защищает от частичных обновлений, но не от логически неверного порядка внутри.”

Код проекта: GitHub

Из серии “Тихие отказы в тест-автоматизации” Разборы таких кейсов — в Telegram-канале Тесты как система

Всем привет, нужны рекомендации и советы по следующим вопросам:

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

2. Если найдётся кто-то, кто работал над галлюцинациями и достоверностm. информации, сгенерированной LLM, поделитесь опытом.

В предыдущих сериях был реализован простейший движок на основе HashMap, в которой сохраняются данные key -> value, и в принципе была открыта дорога для написания сервера и клиента для тестов. Но я решил добавить в Space работу с распределенными (XA) транзакциями.

Наличие такого механизма обязательно приведет к деградации производительности. Закономерно возникает вопрос: для чего это было сделано? Memifydb - это распределенная БД и она должна обеспечивать конкурентный доступ к данным обеспечивая их целостность. Что проку если она будет работать быстро, но её содержимое будет - хаос? Ведь деже при создании простого приложения для обработки данных в нескольких потоках используется synchronized в java (и пр. механизмы синхронизации).

Второй момент состоит в том что я всегда работал с транзакциями на стороне клиента, т.е. работал с менеджером транзакции (TransactionManager). Теперь же я писал сервис и пришлось иметь место с менеджером ресурсов (XAResource), что тоже интересно (не забываем что проект модельный и исследовательский).

Итак, транзакционность добавил, пока что на уровне RAM без сохранения данных в долговременную помять для отката/восстановления. Следующий шаг это написание самого сервера, который будет управлять Space’ами и обработкой клиентских запросов.

👉 Telegram: https://t.me/memifydb 👉 GitHub: https://github.com/yourname/memifydb

Демонстрация low-code коннектора к «1С:Шине» от «Денвик»

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Пока «Фирма 1С» не выпустила поддержку «1С:Шины» в БСП, мы тестируем партнерские решения. Недавно в статье на Хабре я пригласил к сотрудничеству компании, у которых уже есть готовый коннектор, и первым откликнулся «Денвик».

«Денвик» — российский продукт для автоматизированной выгрузки данных из 1С во внешние аналитические базы и BI-системы. Кроме экстрактора есть инжектор — инструмент обратной загрузки данных в 1С. Оба инструмента имеют low-code интерфейсы. За счет этого типовые сценарии выгрузки из 1С и загрузки в 1С можно настраивать через интерфейс, без привлечения разработчика.

Можно ли экстрактор и инжектор использовать в качестве коннектора к «1С:Шине»? Да, можно. На вебинаре в этот четверг вместе с product owner «Денвик» Степаном Пыстиным покажем, какие задачи решаются с помощью инструментов «Денвика».

Спикеры:
— Сергей Скирдин, технический директор «Белого кода»
— Степан Пыстин, product owner «Денвик»

📅 Дата: 14 мая
🕛 Время: 12:00 МСК
📍 Формат: онлайн

➕ Для участников вебинара команда «Денвика» предоставит бесплатный тестовый доступ.

Регистрируйтесь на вебинар и приходите!

На сайте Hacker News завязалось любопытное обсуждение. Пользователь поделился опытом: в крошечной базе данных на 15 тысяч записей случилась коллизия UUIDv4. Приложение генерировало идентификаторы через uuid, популярный пакет npm, база имела ограничение UNIQUE, и однажды новая запись пришла с тем же UUID b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, что уже лежал в таблице с прошлого года.

Если что, то в этом плане у UUID должен быть полный иммолейт импрувед: вероятность такого события крайне мала. У 128-битного UUIDv4 122 случайных бита, то есть шанс попадания нового UUID в один из уже 15 000 существующих равен примерно один к 3,5 × 10³². Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.

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

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

Логика работы микросервиса была простой: в ответ на запрос генерировался UUID, выполнялась чрезвычайно важная проверка на уникальность в этой базе данных, а затем идентификатор возвращался клиенту. Работу микросервиса поддерживала отдельная команда из трёх инженеров с собственными спринтами и канбан-доской.

В предыдущих постах Разбираемся в in-memory базах и Выбираем базу и думаем о данных.

Взлетаем, создал репозиторий под проект https://github.com/mathter/memifydb.git

План

План общий такой:

• Изначально строю некоторый каркас, который буду достраивать и наполнять содержанием. Это будет удобно для прототипирования.

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

Сделано

• Данные клиента будут храниться в space’ах - это будет аналог таблиц в БД. Для начала будет только key-value space что бы можно было подумать уже сейчас о WAL клиенской библиотеке для java и сетевом уровне в целом и конечно же о транзакциях.

• Тестовая реализация WAL, которая в проекте будет называться Log.

Run.

Как я запускал российское зеркало для SQL-песочниц: гибридное облако и блокировки Composer

Привет, Хабр! Меня зовут Слава, я развиваю SQL-платформы sqltest.online и sqlize.online для бесплатной тренировки запросов на реальных СУБД (PostgreSQL, Oracle, MariaDB 12.3, MS SQL 2025).

Зачем понадобилось зеркало?

От 30% моей аудитории из РФ стали приходить сообщения: «Сайт открывается только через VPN».

Переносить бэкенд целиком - дорого, сервер завязан на тяжелые СУБД в Docker. Поэтому я выбрал гибридную модель: поднять фронтенд в зоне .ru, оставив бэкенд в Германии.

Архитектура: Фронт в РФ, мозг в Германии

Фронтенд: PHP без фреймворков

Нативный PHP, HTML и JS. Меньше зависимостей - проще деплой. Для RU-зеркала я выбрал SpaceWeb*, где есть отличные бюджетные тарифы и классная поддержка.

sqltest-online.ru (SpaceWeb, РФ)
├── PHP (без фреймворков) + HTML/JS
└── Минимум зависимостей

Бэкенд: Docker Compose

Мощный сервер в Германии у Contabo*, где в контейнерах крутятся MySQL, PostgreSQL, ClickHouse и другие базы. Серьезные СУБД требуют ресурсов, так что всё живет на одной полноценной машине.

Как они общаются?

Пользователь отправляет запрос -> браузер делает AJAX-вызов к .ru серверу -> фронт делает HTTP-запрос к бэкенду в Германии (server-to-server) -> бэкенд выполняет SQL и возвращает результат.

Плюсы схемы:

• CORS не нужен: браузер общается только со своим доменом.

• Бэкенд закрыт: принимает запросы только от white-list IP.

• Задержка минимальна: интерфейс грузится из РФ, тяжелые запросы идут по быстрому каналу серверов.

Резервного бэкенда нет - проект бесплатный, на второй сервер пока нет бюджета. Если падает Германия, ложится всё.

Проблемы деплоя: Composer «ушел в отказ»

С git pull всё прошло гладко, но установка зависимостей зависла намертво.

Проблема: Composer не мог достучаться до packagist.org. Просто бесконечный таймаут, вызванный нестабильностью сетевых маршрутов.

Решение: Поддержка SpaceWeb не стала отписываться «проблема на вашей стороне», а сразу дала адрес HTTP-прокси.

Дело одной команды:

export HTTPS_PROXY=http://proxy.host:port
composer install

(Для Windows: set HTTPS_PROXY=...)

Мораль: При деплое на российские площадки проверяйте доступность packagist.org (curl -v https://packagist.org). Если висит - просите прокси у хостера, не тратьте время на Composer.

Итоги

Зеркало sqltest-online.ru работает. Гибридная схема спасает: пользователи получают быстрый интерфейс без VPN, а запросы улетают на проверенный бэкенд.

Я верю, что образование должно быть доступным. Если для практики SQL нужно включать VPN и ждать по 10 секунд - человек не будет учиться. Зеркало .ru - мой способ сказать: «Продолжайте практиковаться».

А как вы деплоите зависимости на RU-площадки? Используете прокси, зеркала или есть решения изящнее?

* P.S. Ссылки на SpaceWeb и Contabo в статье - реферальные. Сервисами пользуюсь сам и смело рекомендую, а бонусы пойдут на оплату серверов проекта.

Вебинар о том, как обеспечить стабильность баз данных при росте проекта и нагрузок

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

Это третий вебинар из большого трека про эволюцию приложения в облаке. На этот раз разберем, как передать обслуживание PostgreSQL управляемому сервису в облаке и настроить архитектуру Master/Replica для стабильной работы при высоких нагрузках.

О чем будем говорить:

• сравним управляемую и self-hosted СУБД PostgreSQL: выясним, когда пора задуматься о переезде;

• разберем ключевые метрики БД: на что обращать внимание в мониторинге, чтобы не доводить до инцидента;

• обсудим, как архитектура Master/Replica повышает отказоустойчивость приложения.

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

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

📅 Встречаемся во вторник, 28 апреля, в 11:00 мск

Зарегистрироваться на вебинар