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