что такое двухфазный коммит

Двухфазный коммит и будущее распределённых систем

В этой статье мы смоделируем и исследуем протокол двухфазного коммита с помощью TLA+.

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

Проблема двухфазного коммита

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

Менеджер транзакций (TM) принимает окончательное решение: коммит или отмена. Условием для коммита является готовность к коммиту всех RM. В противном случае транзакцию следует отменить.

Некоторые замечания о моделировании

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

RM может только читать состояние TM и читать/обновлять собственное состояние. Он не может прочитать состояние другого диспетчера ресурсов. ТМ может читать состояние всех узлов RM и читать/обновлять собственное состояние.

Определения

Существует возможность, что TM не сможет сделать tmState «недоступным», но только если константа TMMAYFAIL установлена в значение true до начала проверки модели. В TLA+ метки определяют степень атомарности, то есть её гранулярность. Метками F1 и F2 мы обозначаем, что соответствующие операторы выполняются неатомарно (после некоторого неопределённого времени) по отношению к предыдущим операторам.

Модель RM

Модель RM тоже простая. Поскольку «рабочие» и «подготовленные» состояния неконечные, RM недетерминированно выбирает среди действий, пока не достигнет конечного состояния. «Рабочий» RM может перейти в «прерванное» или «подготовленное» состояние. «Подготовленный» RM ожидает от TM решения коммит/отмена — и действует соответственно. На рисунке ниже показаны возможные переходы состояний для одного RM. Но обратите внимание, что у нас несколько RM, каждый из которых проходит через свои состояния в своём темпе без знания состояния других RM.

Модель двухфазного коммита

Нам нужно проверить согласованность нашего двухфазного коммита: чтобы не было разных RM, один из которых говорит «коммит», а другой «аборт».

Теперь установим TMMAYFAIL=TRUE и перезапустим проверку. Программа быстро выдаёт противоположный результат, где RM застряли в ожидании ответа от недоступной TM.

Моделирование BTM

Чтобы избежать зависания транзакций, добавляем резервный ТМ (BTM), который быстро берёт на себя управление, если основной ТМ недоступен. Для принятия решений BTM использует ту же логику, что и TM. И для простоты мы предполагаем, что BTM никогда не падает.

Когда мы проверяем модель с добавленным процессом BTM, то получаем новое сообщение об ошибке.

BTM не может принять коммит, поскольку наше оригинальное условие canCommit утверждает, что все RMstates должны быть «подготовлены» и не учитывает условие, когда одни RM уже получили решение о коммите от оригинального ТМ до того, как BТМ взял на себя управление. Нужно переписать условия canCommit с учётом такой ситуации.

Успех! Когда мы проверяем модель, то достигаем и согласованности, и завершённости, поскольку BTM берёт на себя управление и завершает транзакцию, если TM падает. Вот модель 2PCwithBTM в TLA+ (BTM и вторая строка canCommit изначально раскомменчены) и соответствующий pdf.

Что если RM тоже потерпят неудачу?

Мы предположили, что RM надёжны. Теперь отменим это условие и посмотрим, как ведёт себя протокол при сбое RM. Добавляем «недоступное» состояние в модель сбоя. Чтобы исследовать поведение и смоделировать прерывистую потерю доступности, позволяем аварийному RM восстановиться и продолжить работу, прочитав своё состояние из лога. Вот ещё одна диаграмма перехода состояния RM с добавленным «недоступным» состоянием и переходами, отмеченными красным цветом. А ниже — пересмотренная модель для RM.

Необходимо также доработать canAbort с учётом состояния недоступности. ТМ может принять решение «отбой», если какая-то из служб находится в прерванном или недоступном состоянии. Если опустить это условие, то упавший и не восстановленный RM прервёт ход выполнения транзакции. Конечно, опять следует учесть RM, которые узнали решение о завершении транзакции от исходного TM.

Проверка модели

Когда мы проверяем модель, то возникает проблема несоответствия! Как это могло произойти? Проследим за трассировкой.

В этом случае BTM принял решение, которое нарушило согласованность. С другой стороны, если заставить BTM ждать выхода RM из недоступного состояния, он может навечно зависнуть в случае аварии на узле, и это нарушит условие выполнения (прогресса).

Невозможность FLP

Итак, что же произошло? Мы уткнулись в теорему Фишера, Линча, Патерсона (FLP) о невозможности консенсуса в асинхронной системе со сбоями.

В нашем примере BTM не может правильно решить, находится RM2 в состоянии сбоя или нет — и некорректно принимает решение прервать транзакцию. Если бы решение принимал только исходный TM, такая неточность в распознавании сбоя не стала бы проблемой. RM подчинятся любому решению ТМ, так что сохранятся и согласованность, и прогресс выполнения.

Проблема в том, что у нас два объекта принимают решения: TM и BTM, они смотрят на состояние RM в разное время и принимают разные решения. Такая асимметричность информации — корень всего зла в распределённых системах.

Проблема не исчезает даже с расширением до трёхфазного коммита. Вот трёхфазный коммит, смоделированный в TLA+ (версия pdf), а ниже трассировка ошибки, которая показывает, что на этот раз нарушен прогресс (на странице Википедии о трёхфазном коммите описывается ситуация, когда RM1 подвисает после получения решения перед коммитом, а RM2 и RM3 совершают коммит, что нарушает согласованность).

Paxos старается сделать мир лучше

Но не всё потеряно, надежда не умерла. У нас есть Paxos. Он аккуратно действует в пределах теоремы FLP. Инновация Paxos заключается в том, что он всегда безопасен (даже при наличии неточных детекторов, асинхронного выполнения и сбоев), и в конечном итоге завершает транзакцию, когда консенсус становится возможным.

Можно эмулировать TM на кластере с тремя узлами Paxos, и это решит проблему несогласованности TM/BTM. Или, как показали Грей и Лэмпорт в научной статье по консенсусу в коммите транзакций, если RM используют контейнер Paxos для хранения своих решений одновременно с ответом TM, это избавляет от одного лишнего шага в алгоритме стандартного протокола.

Источник

Однофазная и многофазная фиксация транзакции

Каждым используемым в транзакции ресурсом управляет диспетчер ресурсов, действия которого координируются диспетчером транзакций. Прикрепление ресурсов как участников в разделе транзакции описывает, как ресурс (или несколько ресурсов) можно прикрепить к транзакции. В этом разделе также описывается порядок координации процесса фиксации транзакции между зачисленными ресурсами.

Если транзакция включает несколько ресурсов, необходимо выполнить двухфазную фиксацию (2PC). Протокол двухфазной фиксации (фаза подготовки и фаза фиксации) гарантирует, что при завершении транзакции все изменения, произведенные над всеми ресурсами, либо полностью фиксируются, либо полностью откатываются. После завершения транзакции результат сообщается всем участникам. Подробное описание протокола двухфазной фиксации см. в книге «обработка транзакций: основные понятия и методики (Morgan Кауфманн Series в управление данными Systems) ISBN: 1558601902«, Джим серый.

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

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

Двухфазная фиксация (2PC)

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

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

Фаза подготовки (фаза 1)

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

Диспетчеру ресурсов, реализующему интерфейс IEnlistmentNotification, сначала необходимо реализовать метод Prepare(PreparingEnlistment), как показано в следующем простом примере.

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

После того, как диспетчер ресурсов завершил свои операции подготовки, ему необходимо проголосовать за фиксацию или откат путем вызова метода Prepared или ForceRollback. Обратите внимание, что класс PreparingEnlistment наследует метод Done от класса Enlistment. Если вызвать этот метод для обратного вызова PreparingEnlistment в фазе подготовки, он сообщает диспетчеру транзакций, что зачисленный ресурс доступен в режиме «только чтение» (т. е. диспетчеры ресурсов могут читать, но не могут изменять защищенные транзакцией данные), и диспетчер ресурсов не получает дальнейших уведомлений от диспетчера транзакций относительно результата транзакции в фазе 2.

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

Фаза фиксации (фаза 2)

Если во второй фазе транзакции диспетчер транзакций получает сведения об успешной подготовке от всех диспетчеров ресурсов (все диспетчеры ресурсов вызвали метод Prepared в конце фазы 1), он вызывает метод Commit для каждого диспетчера ресурсов. После этого диспетчеры ресурсов могут зафиксировать изменения.

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

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

Диспетчер ресурсов должен выполнить любые действия, необходимые для завершения транзакции в соответствии с типом уведомления, и затем информировать диспетчер транзакций о завершении транзакции, вызвав метод Done для параметра Enlistment. Это может быть выполнено в рабочем потоке. Заметьте, что уведомления второго этапа могут быть встроены в тот же поток, который вызвал метод Prepared на первой фазе. Таким образом, после вызова метода Prepared не нужно выполнять никаких действий (например, снимать блокировки), которые должны были быть выполнены перед получением уведомлений второго этапа.

Реализация метода InDoubt

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

Оптимизация однофазной фиксации

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

Источник

Двухфазный коммит и будущее распределённых систем

В этой статье мы смоделируем и исследуем протокол двухфазного коммита с помощью TLA+.

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

Проблема двухфазного коммита

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

Менеджер транзакций (TM) принимает окончательное решение: коммит или отмена. Условием для коммита является готовность к коммиту всех RM. В противном случае транзакцию следует отменить.

Некоторые замечания о моделировании

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

RM может только читать состояние TM и читать/обновлять собственное состояние. Он не может прочитать состояние другого диспетчера ресурсов. ТМ может читать состояние всех узлов RM и читать/обновлять собственное состояние.

Определения

Существует возможность, что TM не сможет сделать tmState «недоступным», но только если константа TMMAYFAIL установлена в значение true до начала проверки модели. В TLA+ метки определяют степень атомарности, то есть её гранулярность. Метками F1 и F2 мы обозначаем, что соответствующие операторы выполняются неатомарно (после некоторого неопределённого времени) по отношению к предыдущим операторам.

Модель RM

Модель RM тоже простая. Поскольку «рабочие» и «подготовленные» состояния неконечные, RM недетерминированно выбирает среди действий, пока не достигнет конечного состояния. «Рабочий» RM может перейти в «прерванное» или «подготовленное» состояние. «Подготовленный» RM ожидает от TM решения коммит/отмена — и действует соответственно. На рисунке ниже показаны возможные переходы состояний для одного RM. Но обратите внимание, что у нас несколько RM, каждый из которых проходит через свои состояния в своём темпе без знания состояния других RM.

Модель двухфазного коммита

Нам нужно проверить согласованность нашего двухфазного коммита: чтобы не было разных RM, один из которых говорит «коммит», а другой «аборт».

Теперь установим TMMAYFAIL=TRUE и перезапустим проверку. Программа быстро выдаёт противоположный результат, где RM застряли в ожидании ответа от недоступной TM.

Моделирование BTM

Чтобы избежать зависания транзакций, добавляем резервный ТМ (BTM), который быстро берёт на себя управление, если основной ТМ недоступен. Для принятия решений BTM использует ту же логику, что и TM. И для простоты мы предполагаем, что BTM никогда не падает.

Когда мы проверяем модель с добавленным процессом BTM, то получаем новое сообщение об ошибке.

BTM не может принять коммит, поскольку наше оригинальное условие canCommit утверждает, что все RMstates должны быть «подготовлены» и не учитывает условие, когда одни RM уже получили решение о коммите от оригинального ТМ до того, как BТМ взял на себя управление. Нужно переписать условия canCommit с учётом такой ситуации.

Успех! Когда мы проверяем модель, то достигаем и согласованности, и завершённости, поскольку BTM берёт на себя управление и завершает транзакцию, если TM падает. Вот модель 2PCwithBTM в TLA+ (BTM и вторая строка canCommit изначально раскомменчены) и соответствующий pdf.

Что если RM тоже потерпят неудачу?

Мы предположили, что RM надёжны. Теперь отменим это условие и посмотрим, как ведёт себя протокол при сбое RM. Добавляем «недоступное» состояние в модель сбоя. Чтобы исследовать поведение и смоделировать прерывистую потерю доступности, позволяем аварийному RM восстановиться и продолжить работу, прочитав своё состояние из лога. Вот ещё одна диаграмма перехода состояния RM с добавленным «недоступным» состоянием и переходами, отмеченными красным цветом. А ниже — пересмотренная модель для RM.

Необходимо также доработать canAbort с учётом состояния недоступности. ТМ может принять решение «отбой», если какая-то из служб находится в прерванном или недоступном состоянии. Если опустить это условие, то упавший и не восстановленный RM прервёт ход выполнения транзакции. Конечно, опять следует учесть RM, которые узнали решение о завершении транзакции от исходного TM.

Проверка модели

Когда мы проверяем модель, то возникает проблема несоответствия! Как это могло произойти? Проследим за трассировкой.

В этом случае BTM принял решение, которое нарушило согласованность. С другой стороны, если заставить BTM ждать выхода RM из недоступного состояния, он может навечно зависнуть в случае аварии на узле, и это нарушит условие выполнения (прогресса).

Невозможность FLP

Итак, что же произошло? Мы уткнулись в теорему Фишера, Линча, Патерсона (FLP) о невозможности консенсуса в асинхронной системе со сбоями.

В нашем примере BTM не может правильно решить, находится RM2 в состоянии сбоя или нет — и некорректно принимает решение прервать транзакцию. Если бы решение принимал только исходный TM, такая неточность в распознавании сбоя не стала бы проблемой. RM подчинятся любому решению ТМ, так что сохранятся и согласованность, и прогресс выполнения.

Проблема в том, что у нас два объекта принимают решения: TM и BTM, они смотрят на состояние RM в разное время и принимают разные решения. Такая асимметричность информации — корень всего зла в распределённых системах.

Проблема не исчезает даже с расширением до трёхфазного коммита. Вот трёхфазный коммит, смоделированный в TLA+ (версия pdf), а ниже трассировка ошибки, которая показывает, что на этот раз нарушен прогресс (на странице Википедии о трёхфазном коммите описывается ситуация, когда RM1 подвисает после получения решения перед коммитом, а RM2 и RM3 совершают коммит, что нарушает согласованность).

Paxos старается сделать мир лучше

Но не всё потеряно, надежда не умерла. У нас есть Paxos. Он аккуратно действует в пределах теоремы FLP. Инновация Paxos заключается в том, что он всегда безопасен (даже при наличии неточных детекторов, асинхронного выполнения и сбоев), и в конечном итоге завершает транзакцию, когда консенсус становится возможным.

Можно эмулировать TM на кластере с тремя узлами Paxos, и это решит проблему несогласованности TM/BTM. Или, как показали Грей и Лэмпорт в научной статье по консенсусу в коммите транзакций, если RM используют контейнер Paxos для хранения своих решений одновременно с ответом TM, это избавляет от одного лишнего шага в алгоритме стандартного протокола.

Источник

Согласованность данных в высоконагруженных системах

Проблематика

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

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

Что касается крупномасштабных систем, то в них далеко не всегда возможно использовать единую базу данных из-за слишком большой нагрузки. В таких случаях каждому модулю системы (сервису) предоставляется своя отдельная база данных. В этом случает встаёт вопрос как для такой кластерной архитектуры обеспечить согласованность данных.

Решение проблемы согласованности данных

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

Простой протокол для фиксации глобальных транзакций — двухфазный коммит (2PC). Узел, выполняющий транзакцию, считается координатором. На подготовительной фазе (prepare) координатор сообщает остальным узлам о фиксации транзакции и дожидается от них подтверждения, что они готовы выполнить фиксацию. Если хотя бы один узел не готов — транзакция обрывается. На фазе фиксации (commit) координатор сообщает всем узлам о решении зафиксировать транзакцию. При получении от всех подтверждения, что все ок, координатор тоже фиксирует транзакцию.

Рисунок 1 – Общая схема двухфазного коммита

Этот протокол позволяет обойтись минимумом сообщений, но не устойчив к сбоям. Например, при отказе координатора после фазы prepare, остальные узлы не имеют информации о том, должна ли транзакция быть зафиксирована или отменена (им придется ждать устранения сбоя). Ещё один серьёзный недостаток 2PC (и других протоколов распределённых транзакций, например 3PC) – при росте количества узлов кластера производительность двухфазных коммитов падает.

Рисунок 2 – Зависимость скорости выполнения двухвазного коммита от количества серверов в кластере СУБД

Кроме того, подход распределённых транзакций накладывает ограничение: все модули системы должны использовать одну и туже СУБД, что не всегда удобно.

Другой вариант – обеспечить некий механизм, позволяющий работать с различными базами данных (для сервисов) как с единой базой данных (решить проблему с целостностью данных в распределённой базе). При этом требуется некий аналог транзакции для распределённой системы («бизнес-транзакция»).

В обычных транзакциях, а также в двухфазных коммитах, все операции контролируются механизмом транзакций (с использованием блокировок), и это делается с целью обеспечить возможность откатить любую операцию (пессимистический подход – любую операцию считаем потенциально вызывающей сбой). Это является узким местом системы. Альтернативный вариант – так называемый оптимистический подход: считаем, что большинство операций завершаются успешно. Дополнительные же действия производим уже по факту произошедшего сбоя. Т.е. уменьшаем издержки для большинства операций, что приводит к повышению производительности.

Что такое Saga (Сага) и как она работает

Альтернативой транзакциям для микросервисной архитектуры является Saga. Saga (сага) представляет собой набор шагов, выполняемых различными модулями системы (сервисами); так же требуется сервис саги, отвечающий за операцию (бизнес-транзакцию) в целом. Шаги связаны через граф событий. После выполнения саги система должна перейти из одного согласованного состояния в другое (в случае успешного выполнения), или вернутся к предыдущему согласованному состоянию (в случае отмены).

Как реализовать такой возврат или откат бизнес-транзакции? Для этого в сагах используется механизм отменяемости шагов (компенсирующие действия). Например, один из шагов был выполнен успешно (допустим в таблицу базы данных пользователей была добавлена запись), но на одном из следующих шагов произошёл сбой, и всю сагу следует отменить. Тогда этому же сервису поступает команда – отменить действие. Но в СУБД сервиса локальная транзакция уже завершена, запись пользователя добавлена. Тогда для возврата к предыдущему состоянию сервис должен выполнить компенсирующее действие (в нашем примере – удалить запись). Отменяемость шагов позволяет реализовать в рамках саги атомарность (Atomicity) – «всё или ничего» — все шаги выполняются или компенсируются.

Рисунок 3 – Механизм работы Saga и природа компенсирующего действия

На рисунке 3 шаги саги обозначены как T1. T4, компенсирующие действия: C1. C4.
Саги поддерживают идемпотентность шагов (действие, многократное повторение которого эквивалентно однократному). Подход саг обеспечивает возможность повторить любой шаг (например, если не получили отклик об успешном завершении). Так же идемпотентность позволяет восстановить состояние при потере данных на каком-либо узле (сбой и восстановление). При выполнении шага каждый сервис должен определять (по ключу идемпотентности) выполнял он уже этот шаг, или нет (если нет – выполнить, иначе — пропустить). Для компенсирующих действий тоже возможно добавление ключей идемпотентности и повторы операций (обеспечение персистентности/устойчивости).

Резюме

Из четырёх требований к транзакционной системе ACID (атомарность, согласованность, изолированность, устойчивость) механизм саг позволяет реализовать три – все, кроме изолированности. Отсутствие изолированности может приводить к аномалиям («грязные чтения», «неповторяющиеся чтения», перезапись изменений между различными бизнес-транзакциями и т.д.). Для преодоления подобных ситуаций требуется использовать дополнительные механизмы, например версионность изменяемых объектов.

Саги позволяют решить следующие задачи:

Область применения и примеры применения

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

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

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

Источник