Архитектура персистентности SQL рабочего процесса Windows

Question

Мне нравится идея WF, и я хотел бы сохранить длительные рабочие процессы в базе данных SQL. В связи с этим, какова подходящая архитектура на уровне SQL для постоянной базы данных? Если персистентные таблицы существуют внутри базы данных проекта, или же это является проектом Project of datatables agnositc, и будет создана только одна база данных персистентности, как база данных SSRS. Могут ли несколько приложений использовать одну постоянную базу данных?

Answer 1

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

Я никогда не объединяю разные постоянные базы данных в одну. На практике WorkflowRuntime каждого приложения будет настраиваться по-разному, поэтому ваш рабочий процесс не может просто выбрать какой-либо хост для запуска, а привязан к специально настроенному, который знает все о типе рабочего процесса. И как только вы начнете использовать DelayActivities, и срок их действия истечет, вы не сможете контролировать, какая среда выполнения попытается загрузить рабочий процесс обратно в память. Использование одной базы данных постоянства с несколькими экземплярами одного и того же типа рабочего процесса для целей балансировки нагрузки возможно, но представляет собой небольшую проблему. На самом деле более распространено иметь несколько постоянных баз данных для по-разному настроенных WorkflowRuntimes в одном приложении, чем наоборот.

Answer 2

База данных SQL Persistence не связана с вашим приложением или проектом. Каждый рабочий процесс полностью атомарен и уникально идентифицируется по GUID. Следовательно, должна быть возможность совместного использования общей базы данных персистентности рабочего процесса для нескольких приложений.

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

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