Базы данных с несколькими ранами с различными стратегиями репликации

Question

Raven DB создает несколько баз данных для поддержки различных стратегий репликации.

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

Сначала я хотел бы узнать, создал ли кто-нибудь приложение с двумя базами данных raven?

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

Спасибо заранее,

Answer 1

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

Если каждая база данных потенциально может находиться на другом сервере (как можно предположить, поскольку вы говорите о репликации по-разному), каждый из них должен иметь свой собственный DocumentStore, который довольно дорого настроить, но это должно произойти только один раз при запуске приложения в любом случае, и вы говорите о 2, а не о 50.

Как упоминает Мэтт в комментариях, если у вас есть две базы данных на одном сервере, вы можете использовать тот же DocumentStore и указать имя базы данных, когда вы открываете сеанс.

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

Доступ к обеим базам данных потребует разворота IDocumentSession для каждого из них, и обоим из них нужно будет управлять отдельно. Если вы управляете своими сеансами документов на уровне инфраструктуры (то есть один сеанс на HTTP-запрос), то два из них усложняют ситуацию.

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

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