Блог

Я разрабатываю многопользовательское веб-приложение SaaS, которое будет размещено в Windows Azure и использовать хранилище таблиц.

Единственными ограничениями, которые я обнаружил на данный момент, являются:

• 5 учетных записей хранения на подписку
• максимум 100 ТБ на учетную запись хранения
• 1 МБ на объект

Я решаю, как наилучшим образом разделить мое хранилище для нескольких клиентов:

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

Вариант 2: предоставьте каждому клиенту свой собственный набор таблиц. Добавляйте к именам таблиц идентификаторы клиентов, такие как разделение таблицы Books на «CustA_Books», «CustB_Books» и т.д.

Вариант 3: Используйте один набор таблиц, но добавляйте префиксы к ключам разделов, чтобы разделить клиентов. Таким образом, одна таблица «записывает» ключи разделов «CustA_Fiction», «CustA_NonFiction», «CustB_Fiction», «CustB_NonFiction» и т.д.

Каковы плюсы и минусы вариантов 2 и 3? Существует ли ограничение на количество таблиц в одной учетной записи, которое может повлиять на вариант 2?

Количество таблиц, которые вы можете создать в Windows Azure, не ограничено. Ваши единственные ограничения — это те, которые вы уже перечислили. Что ж… Я предполагаю, что существуют другие ограничения, если вы считаете, что размер атрибута entity всегда равен 64 КБ или меньше, или если вы рассматриваете пакетные варианты (100 объектов или 4 МБ, независимо от того, что меньше).

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

Что я хотел бы рассмотреть здесь, так это то, потребуется ли вам когда-либо удалять данные массово или если вам когда-либо понадобится запросить данные у клиентов (арендаторов). В первом случае имеет смысл использовать отдельные таблицы для каждого клиента, поэтому удаление — это одна операция против в лучшем случае 1 на 100 объектов. Однако, если вам нужно запрашивать у разных клиентов, объединить эти данные при наличии нескольких таблиц сложнее (для этого потребуется несколько запросов).

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

HTH

Я настоятельно рекомендую вариант 2

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

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

Другой вариант: представьте, что у вас N учетных записей хранения, ограничение составляет 100 учетных записей хранения на подписку. У каждой учетной записи хранения есть таблица для каждого клиента.

1. Для операций запроса таблицы с ключом раздела, таких как Вставка, обновление, удаление или точечный запрос, вы вычисляете хэш-значение имени клиента ключ раздела, вычисляете его модульное значение по базовому N (общее количество учетных записей хранения), находите индекс точной учетной записи хранения и пересылаете запрос правильной учетной записи хранения / таблице.

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

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