Поделиться через

Данные для рабочих нагрузок SaaS в Azure

  • Статья

Рассматривайте данные как наиболее ценный ресурс вашего решения. Как независимый поставщик программного обеспечения (ISV), вы отвечаете за управление данными клиентов. Стратегия проектирования данных и выбор хранилища данных могут существенно повлиять на клиентов.

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

Выберите хранилище данных

Хранилище данных в решении SaaS влияет на архитектуру, производительность, надежность и сложность транзакций. Сравните возможности управляемых служб Azure с аналогичными предложениями, отличными от Майкрософт. В некоторых ситуациях можно также рассмотреть возможность запуска продуктов с открытым исходным кодом на виртуальных машинах.

Рекомендации по проектированию

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

    В этом руководстве основное внимание уделяется хранилищам транзакций.

  • Общие сведения о потребностях в данных. Оцените объем, частоту изменения и тип данных, необходимых для хранения.

    Ожидается, что данные будут значительно увеличиваться с течением времени. Для решений SaaS рост происходит в нескольких измерениях. Ожидается увеличение объема и типов данных по мере увеличения числа клиентов. Убедитесь, что вы планируете этот рост и инвестируете в технологии, которые могут поддерживать его.

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

    Дополнительные сведения см. на платформах данных SQL и NoSQL.

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

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

  • Используйте то, что вы знаете, и инвестируйте в него. Если у вашей команды уже есть опыт работы с определенным хранилищем данных, часто лучше использовать это хранилище данных, а не инвестировать в обучение новых навыков. Хранилища данных и платформы являются сложными, а решения по проектированию могут быть сложными.

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

Рекомендации по проектированию

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

Приоритет управляемых хранилищ данных. Распространенные варианты: Azure Cosmos DB, Sql Azure, MySQL, MongoDB и PostgreSQL.		 Этот подход помогает свести к минимуму сложность и гарантировать, что вы используете правильный продукт для повышения эффективности. Управляемые хранилища данных обеспечивают гибкость в управлении ресурсами и затратами эластично и масштабируемом с учетом ваших потребностей. Использование управляемых хранилищ данных создает меньше бремени управления, чем развертывание собственного хранилища данных в собственной инфраструктуре.
Инвестируйте в обучение выбранной технологии. Обустраивайте свою команду для управления высокими требованиями к масштабированию и другими сложными решениями SaaS. Узнайте о используемых средствах и их более широкой экосистеме, чтобы эффективно использовать платформу данных при масштабировании.
Гибкость в проектировании данных. По мере роста или изменения требований решения SaaS можно адаптировать, добавив или изменив хранилища данных. Эта гибкость позволяет начать с одного хранилища данных и развиваться с течением времени в соответствии с вашими потребностями.

Модель аренды и стратегия базы данных

Ключевым аспектом проектирования данных является решение размещать ресурсы от имени клиентов или размещать ресурсы в своей среде. Большинство поставщиков SaaS размещают ресурсы для всех клиентов, что обеспечивает гибкость в управлении базами данных. Если вы размещаете ресурсы в среде клиента, рассмотрите способ доступа к этим ресурсам и управление ими.

Рекомендации по проектированию

  • Планирование сегментации базы данных. В решениях SaaS для бизнеса (B2B) рекомендуется создавать выделенные базы данных для каждого клиента. Этот подход повышает безопасность данных, сохраняя строгую изоляцию между клиентами, что снижает риск смешивания данных и поддерживает ключи шифрования, управляемые клиентом. Он также помогает соответствовать нормативным требованиям для некоторых клиентов.

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

    В некоторых случаях необходимо хранить данные нескольких клиентов в одном хранилище данных. Например, в решениях "бизнес—потребитель" (B2C) можно сохранять данные в одном хранилище с логическим секционированием на основе идентификатора клиента. В решениях B2B, которые совместно используют компоненты, можно использовать одно хранилище данных для определенных частей, таких как хранилище событий, обеспечивая включение идентификаторов клиентов в каждое событие.

  • Объединение хранилищ данных с компонентами приложения. Если вы размещаете ресурсы от имени клиента, развернитесь в том же регионе Azure, чтобы избежать расходов на пропускную способность исходящего трафика и задержки. При размещении приложений и хранилищ данных в среде клиента разверните их вместе в одной среде, чтобы избежать сложности между средами.

  • Стандартизируйте управление хранилищем данных так же, как и практически. Единообразие — это ключ к управлению данными между клиентами. По мере роста бизнеса различия между клиентами повышают риск и сложность. Эти различия также могут сделать производственные сбои более вероятными и более сложными.

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

Дополнительные сведения о том, как модель аренды влияет на стратегию обработки данных, см. в статье.

Рекомендации по проектированию

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

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

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

Планирование ресурсов

Планирование емкости относится к управлению использованием ресурсов, с фокусом на ЦП, памяти, хранилища и дисковых операциях, таких как входные и выходные операции в секунду (IOPS). Некоторые хранилища данных объединяют эти ресурсы в простую метрику потребления синтетических ресурсов, например единицу пропускной способности базы данных (DTU) в AZURE SQL или единицу запроса (ЕЗ) в Azure Cosmos DB. Управляемые хранилища данных обеспечивают гибкость в управлении ресурсами, что позволяет изменяться с течением времени. Важно установить первоначальный план и выполнить итерацию по мере развития ваших потребностей.

Рекомендации по проектированию

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

  • Ознакомьтесь с различными моделями емкости, которые предлагают платформы данных. Облачные платформы данных часто предоставляют несколько моделей ресурсов. Например, некоторые службы Azure, такие как Azure Cosmos DB, предоставляют подготовленные модели на основе пропускной способности и бессерверные модели. База данных SQL Azure также предоставляет эластичные пулы.

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

    Несмотря на то, что подготовленная пропускная способность требует, чтобы ресурсы были выделены заранее, службы, такие как Azure Cosmos DB, обеспечивают пропускную способность автомасштабирования. Правила динамического добавления или удаления ресурсов можно задать на основе указанных триггеров.

    Модели бессерверных ресурсов автоматически масштабируются по требованию. Эта возможность делает их хорошей отправной точкой, если вы не можете прогнозировать требования к емкости заранее. Однако они могут поддерживать меньше функций и стать экономически неэффективными по мере роста. Бессерверные модели доступны в База данных SQL Azure и Azure Cosmos DB.

Рекомендации по проектированию

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

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

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

Высокий уровень доступности и аварийное восстановление

Клиенты решений SaaS часто ожидают высокого уровня доступности (ВЫСОКОЙ доступности) и аварийного восстановления (аварийного восстановления). Если клиенты работают в регулируемых отраслях или полагаются на решение для ежедневных операций, их требования могут быть еще более строгими.

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

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

Рекомендации по проектированию

  • Квалифицируйте устойчивость. Измеряйте требования к устойчивости с помощью целей уровня обслуживания (SLOS), которые включают такие метрики, как время простоя, время восстановления и точка восстановления. Эти метрики определяются как вашими бизнес-требованиями, так и вашими клиентами, которые могут иметь различные потребности. Если вы храните большие объемы данных от имени ваших клиентов, решение высокой доступности и аварийного восстановления может оказаться более сложным в соответствии с строгими требованиями.

    Дополнительные сведения о метриках устойчивости см . в рекомендациях RE:04 по определению целевых показателей надежности.

  • Используйте функции платформы. Azure предоставляет возможности обеспечения устойчивости в центре обработки данных в пределах региона с помощью зон доступности и в более широкой географической области с помощью нескольких регионов. Объедините такие стратегии, как зоны доступности, резервное копирование между регионами и многорегионные развертывания, чтобы обеспечить правильный уровень устойчивости решения. Для обеспечения высокой устойчивости рассмотрите многорегионную архитектуру с асинхронной репликацией данных между регионами. Такой подход может привести к потере данных во время катастрофического сбоя.

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

    Ознакомьтесь с рекомендациями RE:05 по использованию зон доступности и регионов.

  • Используйте метки развертывания для изоляции радиуса взрыва компонентов. Шаблон меток развертывания широко используется в решениях SaaS, так как он обеспечивает преимущества развертывания, управления, производительности и устойчивости. Например, развертывание одной метки в США и другой метки в Европе гарантирует, что клиенты в одном регионе изолированы от сбоев в другом регионе и могут работать независимо.

Рекомендации по проектированию

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

Задайте ожидания для клиентов. Ноль потери данных во время катастрофических сбоев или 100% времени простоя могут быть нереалистичными.		 Модели выставления счетов могут помочь клиентам понять, насколько гарантированная устойчивость они подписываются. Например, с более низким уровнем клиенты получают минимальные гарантии. На более высоком уровне клиенты получают большую устойчивость, так как вы можете позволить себе реплицировать свои ресурсы в нескольких регионах.
Используйте зоны доступности Azure для рабочих решений. По возможности используйте избыточные между зонами хранилища данных. Зоны доступности обеспечивают устойчивость к сбоям центра обработки данных, не увеличивая затраты, задержку или сложность решения.
Сохраняйте резервные копии хранилищ данных в глобальном избыточном формате с помощью репликации между регионами, где они доступны. Резервные копии данных между регионами добавляют дополнительный уровень устойчивости.
Используйте метки развертывания для создания отдельных экземпляров решения в географически распределенных расположениях. С помощью меток развертывания для создания отдельных экземпляров решения в географически распределенных расположениях можно повысить устойчивость и обеспечить дополнительные преимущества, такие как упрощенное управление операциями.
Оцените, требуется ли многорегионное развертывание, и если вам нужен активный проект для удовлетворения требований.

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

Безопасность и соответствие требованиям

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

Рекомендации по проектированию

  • Сеть. Рассмотрите возможность доступа к хранилищу данных. Как правило, только вашему приложению требуется прямая связь, поэтому настройте его для сети только для частных пользователей.

  • Удостоверение. Рассмотрим способ доступа к хранилищам данных. Многие решения SaaS используют одно удостоверение приложения для всех хранилищ данных, при этом уровень приложений обеспечивает изоляцию и авторизацию. Для безопасности на уровне строк или авторизации на уровне базы данных может потребоваться распространить удостоверение пользователя в хранилище данных, которое является сложным в мультитенантной среде.

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

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

Рекомендации по проектированию

Рекомендация Преимущества
Настройте хранилища данных для использования частных конечных точек и отключите общедоступные конечные точки. Этот подход повышает безопасность путем ограничения доступа к внутренней сети. Ограничение доступа позволяет снизить риск несанкционированного доступа и потенциальных нарушений данных.
Используйте управляемые удостоверения и идентификатор Microsoft Entra для проверки подлинности. Избегайте использования ключей или учетных данных базы данных. Управляемые удостоверения устраняют потребность в ключах или учетных данных базы данных, что снижает риск кражи учетных данных и упрощает управление доступом.
При работе с общими хранилищами данных убедитесь, что приложение ограничивает все запросы к одному клиенту, включая идентификатор клиента в WHERE предложениях. Этот процесс помогает снизить риск утечки данных между клиентами или олицетворения.
Спланируйте стратегию хранения данных на основе соответствия требованиям и бизнес-потребностям. Избегайте хранения ненужных исторических данных. Для долгосрочного хранения перемещайте данные из основных хранилищ в архивное хранилище. Избегая ненужного хранения, вы сохраняете меньшую область поверхности.
Используйте функции хранилища данных для поддержки потребностей жизненного цикла данных.

В Azure Cosmos DB задайте время для жизни в документах. В SQL Azure реализуйте стратегию скользящего окна с помощью секционирования таблиц, чтобы свести к минимуму влияние архивного процесса на базу данных.		 Эти подходы обеспечивают эффективное управление жизненным циклом данных, оптимизируйте хранилище путем архивации или удаления устаревших данных и сокращайте вмешательство вручную, когда это возможно.

Операции

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

Рекомендации по проектированию

  • Узнайте о возможностях вашей команды. Если у вас нет больших групп администраторов баз данных, которые могут выполнять подробный анализ баз данных отдельных клиентов, у вас есть план выполнения операций в масштабе и использование инструментов платформы всякий раз, когда это возможно.

  • Планирование регулярных процедур обслуживания. Перечислить необходимые операции регулярного обслуживания и их частоту. Определенные операции зависят от типа используемого хранилища данных. Например:

    • Отслеживайте общий объем данных и данных, расположенных в определенных сущностях, таких как важные таблицы.
    • Перестройте индексы.
    • Создание или удаление индексов на основе изменения шаблонов запросов.
    • Перебалансирование секций.

    Изучите функции платформы, которые помогут вам выполнять регулярное обслуживание и заранее искать новые проблемы. Например, помощник по База данных SQL в База данных SQL Azure отслеживает проблемы.

  • Проектирование для автоматизации. Автоматизированные операции необходимы для эффективного масштабирования решения SaaS. Определите регулярные и случайные задачи и создайте сборники схем или скрипты автоматизации для них. Для задач, которые нельзя автоматизировать немедленно, тщательно документируйте процессы, чтобы обеспечить согласованность и ясность.

Рекомендации по проектированию

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

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

Ознакомьтесь с параметрами, предоставляемыми платформой и поставщиками, не являющихся корпорацией Майкрософт.		 Инвестируя в автоматизацию качества, вы можете многократно использовать эти ресурсы и сократить количество ручных задач, которые часто подвержены ошибкам. Автоматизированные инструменты ценны, если вы не являетесь экспертом в хранилище данных, которое вы используете, или если вы не уверены в необходимых задачах обслуживания.
Тщательно разверните емкость администрирования базы данных вашей команды. Зарезервируйте администраторов человеческих баз данных для наиболее эффективной деятельности, например для работы с крупными клиентами или автоматизацией здания, которые могут масштабироваться для многих клиентов. При приоритете ценных функций вы можете максимально повысить эффективность.

Доступ клиента к данным

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

Рекомендации по проектированию

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

    Найдите альтернативные способы удовлетворения требований, а не предоставление прямого доступа. Если для создания отчетов требуется доступ, подходы уровня приложений предпочтительнее. Например, можно создавать отчеты для них с помощью Microsoft Power BI или экспортировать подмножество данных в файл, предоставленный им. Вы также можете создавать API, которые они могут использовать для доступа к данным.

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

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

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

Рекомендации по проектированию

Рекомендация Преимущества
Избегайте прямого доступа к хранилищам данных.

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

Дополнительные ресурсы

Мультитенантность — это основная бизнес-методология разработки рабочих нагрузок SaaS. В этих статьях содержатся дополнительные сведения о рекомендациях по проектированию данных:

Следующий шаг

Узнайте о рекомендациях DevOps для рабочих нагрузок SaaS, включая эффективное управление жизненным циклом клиентов и безопасные методики развертывания.

Область разработки: методики DevOps для рабочих нагрузок SaaS в Azure