CosmosDB - Опрос по всем разделам - PullRequest
Новая
       21

CosmosDB - Опрос по всем разделам

0 голосов
/ 04 декабря 2018

Я создаю систему журналирования для наблюдения за нашими (200 ish) основными установками приложений, и Cosmos db кажется подходящим из-за количества данных, которые мы собираем, и для того, чтобыизменяющаяся схема для данных журнала (в частности, массив Tags - см. схему документа ниже).

Но, никогда не использовав CosmosDb до того, как я немного сомневаюсь, что использовать для ключа раздела.

Если я разделю на CustomerId, вероятно, будет несколько Gb данных в каждом из 200 разделов, и данные будут обычно запрашиваться CustomerId, так что это был мой первый выбор для ключа раздела,

Однако я планировал иметь представление «поток журналов» в системе ведения журнала, показывающее журналы, поступающие для всех клиентов .

  • Приведет ли это к запуску ужасно медленного / дорогостоящего перекрестного запроса?

Если это так, есть ли очевидный способ избежать / ограничить влияние затрат и скорости на эти запросы кросс-разделов?(За исключением того, что вы получаете представление потока журнала для всех клиентов!) 

{
    "CustomerId": "be806507-7cc4-4db4-881b",
    "CustomerName": "Our Customer",
    "SystemArea": 1,
    "SystemAreaName": "ExchangeSync",
    "Message": "Updated OK",
    "Details": "",
    "LogLevel": 2,
    "Timestamp": "2018-11-23T10:59:29.7548888+00:00",
    "Tags": {
        "appointmentId": "109654",
        "appointmentGroupId": "86675",
        "exchangeId": "AAMkA",
        "exchangeAlias": "customer.name@customer.com"        
    }    
}

(Примечание. Пока еще не определен список типов SystemArea, которые мы будем использовать, но этобыло бы намного меньше, чем 200 клиентов)

1 Ответ

0 голосов
/ 04 декабря 2018

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

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

...