Когда создаются физические разделы? - PullRequest
0 голосов
/ 14 мая 2018

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

Я поместил в него около 32 тыс. Документов. Используя Partition Stats образец:

Summary:
        partitions: 1
        documentsCount: 32,190
        documentsSize: 0.045 GB

Но есть только один физический раздел! Если я использую метрики портала, я вижу похожую вещь:

enter image description here

Не означает ли это, что все мои запросы относятся к одному физическому разделу? Когда Космос добавляет больше физических разделов?

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

    private async Task<int> RetrieveDigitalMembershipRefreshItemsCount(string code, string correlationId)
    {
        var error = "";
        double cost = 0;
        var handler = HandlersFactory.GetProfilerHandler(_loggerService, _settingService);
        handler.Start(LOG_TAG, "RetrieveDigitalMembershipRefreshItemsCount", correlationId);

        try
        {
            if (this._docDbClient == null)
                throw new Exception("No singleton DocDb client!");

            // Check to see if there is a URL
            if (string.IsNullOrEmpty(_docDbDigitalMembershipsCollectionName))
                throw new Exception("No Digital Memberships collection defined!");

            FeedOptions queryOptions = new FeedOptions { MaxItemCount = 1, PartitionKey = new Microsoft.Azure.Documents.PartitionKey(code.ToUpper()) };

            return await _docDbClient.CreateDocumentQuery<DigitalMembershipDeviceRegistrationItem>(
                        UriFactory.CreateDocumentCollectionUri(_docDbDatabaseName, _docDbDigitalMembershipsCollectionName), queryOptions)
                        .Where(e => e.CollectionType == DigitalMembershipCollectionTypes.RefreshItem && e.Code.ToUpper() == code.ToUpper())
                        .CountAsync();
        }
        catch (Exception ex)
        {
            error = ex.Message;
            throw new Exception(error);
        }
        finally
        {
            handler.Stop(error, cost, new
            {
                Code = code
            });
        }
    }

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

enter image description here

Я попробовал большинство советов по производительности, то есть прямой режим, тот же регион, синглтон. Любая помощь могла бы быть полезна.

Спасибо.

1 Ответ

0 голосов
/ 15 мая 2018

Ключ раздела используется для логического раздела, распределяя данные по физическим разделам. Управление физическими разделами управляется Azure Cosmos DB.

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

Два сценария физического разделения:

  • Обеспечивая пропускную способность выше значения настроек, Azure Cosmos DB разделяет один или несколько физических разделов для поддержки более высокой пропускной способности.
  • Физический раздел p достигает своего предела хранения, Azure Cosmos DB плавно разделяет p на два новых физических раздела. Если p содержит только один логический раздел, разделение не произойдет.

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

Подробнее см. Раздел Azure Cosmos DB .

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