Какой будет соответствующий ключ раздела для документа профиля пользователя в базе данных Cosmos - PullRequest
Новая
       8

Какой будет соответствующий ключ раздела для документа профиля пользователя в базе данных Cosmos

0 голосов
/ 14 января 2019

Я пытаюсь разработать службу профилей пользователей ( Базовый веб-API Asp.Net ), которая имеет постоянное хранилище как Azure Cosmos DB . Даже прочитав различные статьи, я не смог найти подходящий ключ раздела для этого сервиса. По разным статьям

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

Ниже приведен пример документа, который хранится в Azure Cosmos DB (SQL API). 

{
    "id": <<Id>>,   
    "uniqueBusinessId": <<uniqueBusinessId>>,               
    "userName": <<userName>>,                                   
    "isActive": <<isActive>>,                       
    "email" : <<email>>
    "salutation": <<"salutation>>
    "firstName": <<firstName>>,                 
    "middleName": <<middleName>>,                       
    "lastName": <<lastName>>,                                           
    "companyName": <<companyName>>,         
    "jobTitle": <<jobTitle>>        
    "address": [                
        {                                   
            "countryCode": <<Country Code>>,        
            "stateProvinceCode": <<StateProvinceCode>>,     
            "address1": <<addressLine1>>,   
            "address2": null,               
            "city": <<city>>,               
            "postalCode": <<postalCode>>,           
        }
    ]
    "phone": [              
         {          
            "countryCode":  <<Country Code>>,           
            "areaCode": <<area Code>>,          
            "number": <<number>>,       
            "extension": <<extension>>          
        }
    ]
  }

Для каждого пользователя в коллекции будет один документ, и 99% запросов будут извлекать данные на основе uniqueBusinessId, который является уникальным идентификатором для каждого пользователя (в системе будет около 1 миллиона пользователей).

Если я выберу uniqueBusinessId для вышеуказанной коллекции в качестве ключа раздела, это означает, что он создаст 1 миллион логических разделов (и у него не будет кардинального числа). uniqueBusinessId правильный кандидат на ключ раздела? Я могу выбрать ключ раздела как /address/city или любой другой ключ в документе, чтобы иметь хорошую мощность; но проблема, которую это создаст с запросами, так как они будут перекрестным сканированием для фильтрации документов на основе uniqueBusinessId.

Есть ли какие-либо предложения относительно того, каким должен быть соответствующий ключ раздела для вышеуказанного документа?

1 Ответ

0 голосов
/ 14 января 2019

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

Вы НЕ хотите, чтобы какие-либо перекрестные запросы были частью вашего повседневного рабочего процесса в вашем приложении.

Выбор uniqueBusinessId будет хорошим выбором, если вы сможете получить доступ к нему в 99% случаев. Это обеспечит хорошую производительность и низкую стоимость операций.

Имейте в виду, что максимальный размер каждого логического раздела составляет 10 ГБ. Если при использовании uniqueBusinessId есть какой-либо шанс встретить это ограничение, вы не можете его использовать.

...