Identificar uma estratégia de criação de partições para os dados do Azure Cosmos DB

Concluído

Lembre-se de que os dados num Azure Cosmos DB estão armazenados em coleções. As coleções são distribuídas por partições com base no valor da chave de partição de uma coleção.

A chave de partição é uma propriedade do documento. Os documentos com o mesmo valor de chave de partição estão sempre localizados na mesma partição lógica. Uma partição suporta uma quantidade máxima fixa de armazenamento e Unidades de Pedido (RUs). Quando a capacidade de uma partição lógica se aproximar do armazenamento máximo, o Azure Cosmos DB aloca outra partição física. O Azure Cosmos DB divide uniformemente as partições lógicas, os grupos de documentos com o mesmo valor de chave de partição, entre as partições físicas.

Evite divisórias quentes

O débito do Azure Cosmos DB configurado está dividido uniformemente entre as partições. Uma estrutura de chave de partição que não distribua uniformemente os pedidos de débito pode criar partições frequentes. Uma partição frequente é acedida mais vezes do que outras partições. Isto resulta numa utilização ineficiente do débito configurado total. Se a procura na partição quente for suficientemente elevada, a partição fica sobrecarregada e o tráfego para a base de dados é limitado.

Uma boa conceção de partições é evitar as partições frequentes.

Considerações sobre a conceção de partições

Para conceber uma estratégia de criação de partições, é necessário que compreenda os dados e as suas cargas de trabalho operacionais. Ao considerar o seu design, recomendamos que considere os seguintes requisitos.

Faça uma estimativa do dimensionamento das suas necessidades de dados

Considere estes requisitos:

  • Qual é o tamanho aproximado dos seus documentos, ou intervalo de tamanhos?
  • Qual é o débito necessário para o número de leituras e escritas por segundo?
  • Qual o volume dos documentos a consultar?

Compreenda a carga de trabalho

Considere estes requisitos:

  • Tem uma carga de trabalho de leitura ou escrita intensiva, ou ambas?
  • No caso de uma leitura intensiva, quais são as cinco principais consultas?
  • Se for escrita intensiva, precisa de transações?

Apresente algumas opções de chave de partição

Considere estas opções:

  • A escolha da chave tem um grande número de valores possíveis ou grande cardinalidade?
  • Os valores têm uma distribuição consistente em todos os dados?
  • O acesso a alguns valores é superior a outros?
  • Para cargas de trabalho de leitura intensiva, a consulta pode ser feita dentro de uma única partição?
  • Para cargas de trabalho transacionais de escrita intensiva, a transação pode ser feita dentro de uma única partição?

Cenário: identificar uma estratégia de partição

A coleção Encomendas tem muitas propriedades que pode utilizar como chave de partição. O seguinte exemplo mostra um documento de encomenda típico com 1 KB de dados. Este tamanho permite-lhe fazer estimativas de RUs facilmente.

{
    "OrderTime": "4:21 PM",
    "id": "c0292ca2-c932-4e7f-a159-330dfd7d18e9",
    "OrderStatus": "NEW",
    "Item": {
        "id": "07f11c55-6a17-3521-9c62-8ec4bf12d75b",
        "Title": "aqyq0ir54234qz3",
        "Category": "Books",
        "UPC": "85:8913:018",
        "Website": "https://asu.vvkgmfo.com",
        "ReleaseDate": "2019-01-10T16:21:41.15317-08:00",
        "Condition": "NEW",
        "Merchant": "Producer",
        "ListPricePerItem": 26.4,
        "PurchasePrice": 23.73,
        "Currency": "USD"
    },
    "Quantity": 80,
    "PaymentInstrumentType": 2,
    "PurchaseOrderNumber": "095-59132-06",
    "Customer": {
        "id": "b7903b01-2aec-e85e-42b0-4b9f342a8560",
        "FirstName": "Garland",
        "LastName": "Murazik",
        "Email": "Garland33@gmail.com",
        "StreetAddress": "605 Ritchie Ferry",
        "ZipCode": "15719",
        "State": "IA"
    },
    "ShippingDate": "2019-01-13T16:21:42.487967-08:00",
    "Data": "BG4eT0bLt+W5Uw=="
}

Compreender a carga de trabalho da coleção

Imagine que a coleção é utilizada para armazenar um registo de encomendas. Quando é encomendado um item específico, o sistema de inventário verifica as encomendas mais recentes para obter um valor preciso do inventário desse item.

Em períodos de pico, tais como nas vendas de Natal, prevê que mais de 100 milhões de encomendas sejam feitas num período de 24 horas.

Quando cada documento da encomenda é adicionado à coleção, a mesma é consultada em relação a outras encomendas do mesmo item. Como podem existir várias encomendas para cada item, há mais documentos de leitura do que de escrita.

As leituras mais frequentes e menos dispendiosas estão equilibradas com as escritas menos frequentes e mais dispendiosas. Portanto, a coleção Encomendas tem uma carga de trabalho de leitura/escrita intensiva equilibrada.

Apresentar valores de chave de partição para a coleção

Ao utilizar a informação das secções anteriores, vamos propor alguns valores diferentes para a chave de partição, e examinar se eles cumprem os seus critérios de design:

  • OrderTime como chave de partição:

    • Se incluir o tempo com uma resolução de segundos, OrderTime terá uma grande cardinalidade.
    • Partindo do princípio de que as encomendas são feitas a um ritmo consistente, os valores de OrderTime são distribuídos uniformemente pelo armazenamento da coleção.
    • No entanto, as encomendas não são distribuídas uniformemente ao longo do tempo. Estão a ser feitas muitas encomendas em simultâneo.
    • Além disso, a consulta do inventário provavelmente cruza partições, o que significa que a procura da consulta mais comum não é minimizada.

    OrderTimenão é a uma boa opção para a chave de partição.

  • Item/Category como chave de partição:

    • A base de dados Encomendas contém as seguintes categorias:

      public static string[] Categories =
      {
            "Books",
            "Electronics",
            "Cosmetics",
            "Tools",
            "Kitchenware",
            "Office Supplies",
            "Whiteware"
      };
      

      Se você usar a Item/Category propriedade como chave de partição, tem uma pequena cardinalidade. Mesmo que os documentos sejam distribuídos uniformemente pela coleção, para coleções grandes, qualquer categoria poderá ultrapassar uma única partição.

    • Se as categorias não forem distribuídas uniformemente pelos documentos da coleção, o problema é ainda pior. A categoria dominante restringe a capacidade de dimensionamento do Azure Cosmos DB.

    Item/Categorynão é a uma boa opção para a chave de partição.

  • Item/id como chave de partição:

    • Cada item tem um identificador exclusivo. Espera que os itens encomendados sejam distribuídos uniformemente pelas encomendas.
    • Existem muitos itens diferentes, por isso a cardinalidade é grande.
    • Quando consulta as encomendas, todas as encomendas do mesmo item estão na mesma partição.

    Item/id é uma solução viável para este cenário.

Na unidade seguinte, irá monitorizar as nossas coleções para ver como poderia confirmar a escolha desta conceção.

Verificação de conhecimento

1.

O que causa uma partição frequente numa coleção de base de dados NoSQL distribuída?

2.

Qual é a melhor forma de maximizar a eficiência de uma consulta individual à base de dados?