Это эффективная структура / запрос в Azure CosmosDB?

Question

Я добавляю простые функции поиска для своих пользователей в свое приложение и настоятельно рекомендую использовать Azure CosmosDB. Документы в моей базе данных Cosmos (Azure) представляют телефонные звонки и выглядят следующим образом:

{
    "id": "JKEeW3aebSEAzUA",
    "partitionKey": "191625028",
    "ownerId": "191625028",
    "callTime": "2020-06-12T22:13:18.271+00:00",
    "direction": "Inbound",
    "action": "Phone Call",
    "result": "Accepted",
    "callers": [
        {
            "phoneNum": "9182914018",
            "name": "JENKS        OK",
            "location": "Jenks, OK"
        },
        {
            "phoneNum": "9189406524",
            "name": "Main IVR",
            "location": null
        },
        {
            "phoneNum": null,
            "name": "Main IVR",
            "location": null,
        }
    ]
}

Я собираюсь предоставить возможность поиска на основе вложенных свойств phoneNum, name и location в каждом элементе callers. Я рассматриваю возможность использования этого запроса:

SELECT c.id,a.phoneNum,c.callers 
FROM c join a in c.callers 
where CONTAINS(a.phoneNum, '4018')

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

1. Это мультитенантная система, и мы используем схему «раздел на каждого арендатора» в этой конкретной базе данных.
2. Некоторые разделы / арендаторы будут иметь более 1 000 000 записей вызовов и 3 000 000 - 4 000 000 вложенных записей вызывающих абонентов после завершения импорта данных.

Я новичок в Azure CosmosDB. В настоящее время мы предоставляем ограниченные возможности поиска, аналогичные этой, через сервер SQL. Эта структура идентична нашей структуре на SQL сервере (записи родительских вызовов, записи дочерних вызывающих).

Answer 1

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

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

Answer 2

Это мультитенантная система, и мы используем «разделение на каждого арендатора» ... Это самый эффективный способ выполнения такого поиска?

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

Физический раздел Cosmos DB больше похож на отдельный сервер SQL, чем на раздел таблицы SQL Server.

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

https://docs.microsoft.com/en-us/azure/cosmos-db/how-to-query-container#in -partition-query

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

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