Моя компания пыталась разделить нашу текущую базу данных SQL географически из-за того, что наши пользователи требовали хранить свои конфиденциальные данные в их собственном географическом регионе. Только часть данных БД пользователя должна быть расположена в определенном географическом месте.
Например: Допустим, БД хранит информацию о книгах по нескольким таблицам БД. Данные книг, относящихся к пользователям из Европы, должны существовать только на серверах ЕС. Другие данные в БД не нужно распределять особым образом, например, учетные записи пользователей и т. Д., Только данные книг.
Я хотел бы прочитать некоторые мысли и идеи о лучших подходах к решению этой проблемы. Первоначально я думал о том, чтобы иметь 1 основную БД, указывающую, где географически хранятся данные для каждой «книги», и, в соответствии с этим, продолжайте запрашивать БД правильного региона.
Вы не указали много ограничений, от которых можно было бы исходить, поэтому мы, возможно, просто крутим колеса, предлагая недопустимые решения. Но я предлагаю один подход для мира MS SQL Server ...
Предположим, ваша компания должна поддерживать 3 отдельных географических региона для размещения конфиденциальных данных. Затем также предположим, что пользователи в любом из этих регионов должны иметь возможность запрашивать данные во всех других регионах (конечно, в соответствии с политикой контроля доступа). Я предполагаю, что схема информации одинакова для всех регионов.
Поэтому в каждом регионе я бы создал «связанный» сервер SQL Server для двух других регионов. Это позволяет запросу, выполняющемуся в любом регионе, получать доступ к данным, хранящимся локально, а также в любом из других регионов. Запросы, которые ищут информацию, можно изменить так, чтобы они выполняли UNION по всем регионам, но по-прежнему возвращали ту же схему. Это неэффективно, поэтому вы, вероятно, придумали бы какую-то стратегию для репликации неконфиденциальных данных во все регионы, а затем рефакторинг ваших запросов для доступа к единственной локальной реплике для неконфиденциальных данных и нескольким регионам, только UNION, только для чувствительной схемы.