O que é o repositório analítico do Azure Cosmos DB?

APLICA-SE A: API do SQL API do Azure Cosmos DB para MongoDB

O repositório analítico do Azure Cosmos DB é um repositório de coluna totalmente isolado para habilitar a análise em grande escala de dados operacionais em seu Azure Cosmos DB, sem nenhum impacto as cargas de trabalho transacionais.

O repositório transacional do Azure Cosmos DB é independente de esquema e permite que você faça uma iteração nos seus aplicativos transacionais sem a necessidade de lidar com gerenciamento de índices ou de esquemas. De modo contrastante, o repositório analítico do Azure Cosmos DB é esquematizado para otimizar o desempenho de consultas analíticas. Este artigo descreve em detalhes o repositório analítico.

Desafios com análise em larga escala sobre dados operacionais

Os dados operacionais multimodelo em um contêiner do Azure Cosmos DB são armazenados internamente em um "repositório transacional" baseado em linha e indexado. O formato de repositório de linha foi projetado para permitir leituras e gravações transacionais rápidas nos tempos de resposta na casa de milissegundos e consultas operacionais. Se o conjunto de dados aumentar, as consultas analíticas complexas poderão ser caras em termos de taxa de transferência provisionada nos dados armazenados nesse formato. O alto consumo de taxa de transferência provisionada, por sua vez, impacta o desempenho de cargas de trabalho transacionais que são usadas pelos aplicativos e serviços em tempo real.

Tradicionalmente, para analisar grandes quantidades de dados, os dados operacionais são extraídos do repositório transacional do Azure Cosmos DB e armazenados em uma camada de dados separada. Por exemplo, os dados são armazenados em um data warehouse ou em um data lake em um formato adequado. Esses dados são usados posteriormente para a análise em larga escala e são analisados usando o um mecanismo de computação, como os clusters do Apache Spark. Essa separação do armazenamento analítico e das camadas de computação dos dados operacionais resulta em latência adicional, pois os pipelines de ETL (extração, transformação e carregamento) são executados com menos frequência para minimizar o impacto potencial em suas cargas de trabalho transacionais.

Os pipelines de ETL também se tornam complexos ao lidar com atualizações dos dados operacionais quando comparados ao tratamento apenas de dados operacionais recentemente ingeridos.

Repositório analítico orientado por coluna

O repositório analítico do Azure Cosmos DB aborda os desafios de complexidade e latência que ocorrem com os pipelines de ETL tradicionais. O repositório analítico do Azure Cosmos DB pode sincronizar automaticamente seus dados operacionais em um repositório de coluna separado. O formato de repositório de coluna é adequado para consultas analíticas de larga escala a serem executadas de maneira otimizada, resultando na melhoria da latência dessas consultas.

Agora, ao usar o Link do Azure Synapse, você pode criar soluções de HTAP sem ETL ao vincular diretamente ao repositório analítico do Azure Cosmos DB a partir do Azure Synapse Analytics. Isso permite que você execute análises de larga escala quase em tempo real em seus dados operacionais.

Recursos de repositório analítico

Quando você habilitar o repositório analítico em um contêiner do Azure Cosmos DB, um novo repositório de coluna será criado internamente com base nos dados operacionais em seu contêiner. Esse repositório de coluna é persistido separadamente do repositório transacional orientado por linha desse contêiner. As inserções, atualizações e exclusões dos seus dados operacionais são sincronizadas automaticamente ao repositório analítico. Você não precisa do feed de alterações ou da ETL para sincronizar os dados.

Repositório de coluna para cargas de trabalho analíticas em dados operacionais

As cargas de trabalho analíticas normalmente envolvem agregações e exames sequenciais dos campos selecionados. Ao armazenar os dados em uma ordem de coluna principal, o repositório analítico permite que um grupo de valores de cada campo seja serializado em conjunto. Esse formato reduz as IOPS necessárias para verificar ou computar estatísticas em campos específicos. Ele melhora significativamente os tempos de resposta de consulta para verificações em grandes conjuntos de dados.

Por exemplo, se suas tabelas operacionais estiverem no seguinte formato:

Exemplo de tabela operacional

O repositório de linha persiste os dados acima em um formato serializado, por linha, no disco. Esse formato permite leituras, gravações e consultas operacionais transacionais mais rápidas, como “Retornar informações sobre Product1”. No entanto, como o conjunto de dados aumenta e se você quiser executar consultas analíticas complexas sobre eles, isso pode se tornar caro. Por exemplo, se você quiser saber “as tendências de vendas de um produto sob a categoria chamada ‘equipamentos’ entre diferentes unidades de negócios e meses”, você precisará executar uma consulta complexa. Grandes exames nesse conjunto de recursos podem ser caros em termos de taxa de transferência provisionada e também podem impactar o desempenho das cargas de trabalho transacionais, capacitando seus aplicativos e serviços em tempo real.

O repositório analítico, que é um repositório de coluna, é mais adequado para essas consultas porque ele serializa campos semelhantes de dados juntos e reduz as IOPS de disco.

A imagem a seguir mostra o repositório de linhas transacional em comparação ao repositório de colunas analíticas no Azure Cosmos DB:

Repositório de linhas transacional em comparação ao repositório de colunas analíticas no Azure Cosmos DB

Desempenho separado para cargas de trabalho analíticas

Não há nenhum impacto no desempenho de suas cargas de trabalho transacionais devido a consultas analíticas, pois o repositório analítico fica separado do repositório transacional. O repositório analítico não precisa de RUs (unidades de solicitação) separadas para ser alocado.

Sincronização automática

A sincronização automática refere-se à capacidade totalmente gerenciada do Azure Cosmos DB em que as inserções, atualizações e exclusões em relação a dados operacionais são sincronizadas automaticamente do repositório transacional para o repositório analítico em tempo quase real. A latência de sincronização automática geralmente é de 2 minutos. Em casos de banco de dados de taxa de transferência compartilhado com um grande número de contêineres, a latência de sincronização automática de contêineres individuais pode ser maior e levar até 5 minutos. Gostaríamos de saber mais sobre como essa latência se adapta aos seus cenários. Para isso, entre em contato com a equipe do Azure Cosmos DB.

No final de cada execução do processo de sincronização automática, seus dados transacionais estarão imediatamente disponíveis para os runtimes do Azure Synapse Analytics:

  • Os pools do Spark no Azure Synapse Analytics podem ler todos os dados, incluindo as atualizações mais recentes, por meio das tabelas do Spark, que são atualizadas automaticamente ou por meio do comando spark.read, que sempre lê o último estado dos dados.

  • Os pools Sem Servidor SQL no Azure Synapse Analytics podem ler todos os dados, incluindo as atualizações mais recentes, por meio das exibições, que são atualizadas automaticamente ou por meio do comando SELECT junto com o comando OPENROWSET, que sempre leem o último estado dos dados.

Observação

Seus dados transacionais serão sincronizados com o armazenamento analítico mesmo que o TTL transacional seja menor que 2 minutos.

Escalabilidade e elasticidade

Ao usar o particionamento horizontal, o repositório transacional do Azure Cosmos DB pode escalar elasticamente o armazenamento e a taxa de transferência sem nenhum tempo de inatividade. O particionamento horizontal no repositório transacional fornece escalabilidade e elasticidade na sincronização automática para garantir que os dados sejam sincronizados com o repositório analítico quase em tempo real. A sincronização de dados ocorre independentemente da taxa de transferência do tráfego transacional, sejam 1.000 ou 1 milhão de operações/s, e não impacta a taxa de transferência provisionada no repositório transacional.

Lidar automaticamente com atualizações de esquema

O repositório transacional do Azure Cosmos DB é independente de esquema e permite que você faça uma iteração nos seus aplicativos transacionais sem a necessidade de lidar com gerenciamento de índices ou de esquemas. De modo contrastante, o repositório analítico do Azure Cosmos DB é esquematizado para otimizar o desempenho de consultas analíticas. Com o recurso de sincronização automática, o Azure Cosmos DB gerencia a inferência de esquema sobre as atualizações mais recentes do repositório transacional. Ele também gerencia a representação do esquema no repositório analítico pronto para uso, que inclui o tratamento de tipos de dados aninhados.

Conforme seu esquema evolui e novas propriedades são adicionadas ao longo do tempo, o repositório analítico apresenta automaticamente um esquema unido entre todos os esquemas históricos no repositório transacional.

Observação

No contexto do armazenamento analítico, consideramos as seguintes estruturas como propriedade:

  • Os "elements" do JSON ou o "string-value pairs separated by a : ".
  • Objetos JSON, delimitados por { e }.
  • Matrizes JSON, delimitadas por [ e ].

Restrições de esquema

As seguintes restrições são aplicáveis aos dados operacionais em Azure Cosmos DB quando você habilita o repositório analítico para inferir e representar automaticamente o esquema corretamente:

  • Você pode ter, no máximo, 1000 propriedades em qualquer nível de aninhamento no esquema, além de uma profundidade máxima de aninhamento de 127.

    • Somente as primeiras 1000 propriedades são representadas no repositório analítico.
    • Somente os primeiros 127 níveis aninhados são representados no repositório analítico.
    • O primeiro nível de um documento JSON é seu nível raiz /.
    • As propriedades no primeiro nível do documento serão representadas como colunas.
  • Cenários de exemplo:

    • Se o primeiro nível do documento tiver 2.000 propriedades, somente as primeiras 1.000 serão representadas.
    • Se seus documentos têm 5 níveis com 200 propriedades em cada um, todas elas serão representadas.
    • Se seus documentos têm 10 níveis com 400 propriedades em cada um, somente os dois primeiros níveis serão totalmente representados no armazenamento analítico. Metade do terceiro nível também será representado.
  • O documento hipotético abaixo contém 4 propriedades e 3 níveis.

    • Os níveis são root, myArray, e a estrutura aninhada dentro do myArray.
    • As propriedades são id, myArray, myArray.nested1 e myArray.nested2.
    • A representação do armazenamento analítico terá duas colunas: id e myArray. Você pode usar funções do Spark ou do T-SQL para expor as estruturas aninhadas como colunas também.
{
  "id": "1",
  "myArray": [
    "string1",
    "string2",
    {
      "nested1": "abc",
      "nested2": "cde"
    }
  ]
}
  • Embora os documentos JSON (e coleções/contêineres Cosmos DB) diferenciem maiúsculas de minúsculas da perspectiva de exclusividade, o repositório analítico não faz isso.

    • No mesmo documento: os nomes de propriedades no mesmo nível devem ser exclusivos quando comparados sem distinção entre maiúsculas e minúsculas. Por exemplo, o documento JSON a seguir tem "Name" e "name" no mesmo nível. Embora seja um documento JSON válido, ele não satisfaz a restrição de exclusividade e, portanto, não será totalmente representado no repositório analítico. Neste exemplo, "Name" e "name" são os mesmos quando comparados de forma não sensível a maiúsculas e minúsculas. Somente "Name": "fred" será representado no repositório analítico, porque é a primeira ocorrência. E "name": "john" não será representado.
    {"id": 1, "Name": "fred", "name": "john"}
    
    • Em documentos diferentes: as propriedades no mesmo nível e com o mesmo nome, mas em casos diferentes, serão representadas na mesma coluna, usando o formato de nome da primeira ocorrência. Por exemplo, os documentos JSON a seguir têm "Name" e "name" no mesmo nível. Como o primeiro formato de documento é "Name", isso é o que será usado para representar o nome da propriedade no repositório analítico. Em outras palavras, o nome da coluna no repositório analítico será "Name". Ambos "fred" e "john" serão representados na coluna "Name".
    {"id": 1, "Name": "fred"}
    {"id": 2, "name": "john"}
    
  • O primeiro documento da coleção define o esquema inicial do repositório analítico.

    • Documentos com mais propriedades do que o esquema inicial gerarão novas colunas no repositório analítico.
    • Não é possível remover colunas.
    • A exclusão de todos os documentos em uma coleção não redefine o esquema de armazenamento analítico.
    • Não há controle de versão do esquema. A última versão inferida do armazenamento transacional é o que você verá no repositório analítico.
  • Atualmente, o Azure Synapse Spark não pode ler propriedades que contêm alguns caracteres especiais em seus nomes, listados abaixo. O SQL do Azure Synapse sem servidor não é afetado.

    • : (Dois-pontos)
    • ` (Acento grave)
    • , (Vírgula)
    • ; (Ponto e vírgula)
    • {}
    • ()
    • \n
    • \t
    • = (Sinal de igual)
    • " (Aspas)
  • Se você tiver nomes de propriedades que usam os caracteres listados acima, as alternativas são as seguintes:

    • Altere o modelo de dados com antecedência para evitar esses caracteres.
    • Como não há suporte para redefinição de esquema no momento, você pode alterar o aplicativo para adicionar uma propriedade redundante com um nome semelhante, evitando esses caracteres.
    • Use o Feed de Alterações para criar uma exibição materializada do contêiner, sem esses caracteres nos nomes de propriedades.
    • Use a novíssima opção do Spark dropColumn para ignorar as colunas afetadas ao carregar dados em um DataFrame. A sintaxe para soltar uma coluna hipotética chamada "FirstName,LastNAme" que contém uma vírgula é a seguinte:
df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.synapse.dropColumn","FirstName,LastName")\
     .load()
  • O Azure Synapse Spark agora dá suporte a propriedades com espaços em branco em seus nomes.

Representação do esquema

Há dois tipos de representação de esquema no repositório analítico. Esses tipos definem o método de representação de esquema para todos os contêineres na conta do banco de dados e têm compensações entre a simplicidade da experiência de consulta em comparação com a conveniência de uma representação colunar mais inclusiva para esquemas polimórficos.

  • A representação de esquema bem definida, opção padrão para contas de API de SQL (núcleo).
  • Representação de esquema de fidelidade total, opção padrão da API do Azure Cosmos DB para contas do MongoDB.

Esquema de fidelidade total para contas de API de SQL

É possível usar o esquema de fidelidade total para contas de API de SQL (Núcleo), em vez da opção padrão, definindo o tipo de esquema ao habilitar o Link do Synapse em uma conta do Cosmos DB pela primeira vez. Estas são as considerações sobre como alterar o tipo de representação do esquema padrão:

  • Esta opção só é válida para contas que já não tenham o Link do Synapse habilitado.
  • Não é possível redefinir o tipo de representação do esquema, de bem definido para a fidelidade completa ou vice-versa.
  • Atualmente, a API do Azure Cosmos DB para as contas do MongoDB não são compatíveis com essa possibilidade de alterar a representação do esquema. Todas as contas do MongoDB sempre terão o tipo de representação de esquema de fidelidade total.
  • Atualmente, essa alteração não pode ser feita por meio do portal do Azure. Todas as contas de banco de dados que têm o LinK do Synapse habilitado pelo portal do Azure terão o tipo de representação de esquema padrão: esquema bem definido.

A decisão do tipo de representação do esquema deve ser feita ao mesmo tempo em que o Link do Synapse é habilitado na conta, usando a CLI do Azure ou o PowerShell.

Com a CLI do Azure:

az cosmosdb create --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup --subscription MySubscription --analytical-storage-schema-type "FullFidelity" --enable-analytical-storage true

Observação

No comando acima, substitua create por update para as contas existentes.

Com o PowerShell:

 New-AzCosmosDBAccount -ResourceGroupName MyResourceGroup -Name MyCosmosDBDatabaseAccount  -EnableAnalyticalStorage true -AnalyticalStorageSchemaType "FullFidelity"

Observação

No comando acima, substitua New-AzCosmosDBAccount por Update-AzCosmosDBAccount para as contas existentes.

Representação de esquema bem definido

A representação de esquema bem definido cria uma representação de tabela simples dos dados independentes de esquema no repositório transacional. A representação de esquema bem definida tem as seguintes considerações:

  • O primeiro documento define o esquema base e a propriedade sempre deve ter o mesmo tipo em todos os documentos. As únicas exceções são:
    • De nulo para qualquer outro tipo de dados. A primeira ocorrência não nula define o tipo de dados da coluna. Qualquer documento que não esteja seguindo o primeiro tipo de dados não nulo não será representado no repositório analítico.
    • De float a integer. Todos os documentos serão representados no repositório analítico.
    • De integer a float. Todos os documentos serão representados no repositório analítico. No entanto, para ler esses dados com os pools sem servidor SQL do Azure Synapse, você deverá usar uma cláusula WITH para converter a coluna em varchar. E, após essa conversão inicial, é possível convertê-lo novamente em um número. Verifique o exemplo abaixo, em que o valor inicial num era um inteiro e o segundo era um float.
SELECT CAST (num as float) as num
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = '<your-connection',
                OBJECT = 'IntToFloat',
                SERVER_CREDENTIAL = 'your-credential'
) 
WITH (num varchar(100)) AS [IntToFloat]
  • As propriedades que não seguem o tipo de dados do esquema base não serão representadas no repositório analítico. Por exemplo, considere os 2 documentos abaixo e veja que o primeiro definiu o esquema base do repositório analítico. O segundo documento, em que id é 2, não tem um esquema bem definido, pois a propriedade "a" é uma cadeia de caracteres e o primeiro documento tem "a" como um número. Nesse caso, o repositório analítico registra o tipo de dados de "a" como integer no tempo de vida do contêiner. O segundo documento ainda será incluído no repositório analítico, mas sua propriedade "a" não será.

    • {"id": "1", "a":123}
    • {"id": "2", "a": "str"}

Observação

Essa condição acima não se aplica a propriedades nulas. Por exemplo, {"a":123} and {"a":null} ainda é bem definido.

  • Tipos de matriz devem conter um só tipo repetido. Por exemplo, {"a": ["str",12]} não é um esquema bem-definido porque a matriz contém uma combinação de tipos inteiros e cadeias de caracteres.

Observação

Se o repositório analítico do Azure Cosmos DB seguir a representação de esquema bem definida e a especificação acima for violada por determinados itens, esses itens não serão incluídos no repositório analítico.

  • Espere um comportamento diferente em relação a tipos diferentes no esquema bem-definido:

    • Os pools do Spark no Azure Synapse representarão esses valores como undefined.
    • Os pools sem servidor SQL no Azure Synapse representarão esses valores como NULL.
  • Espere um comportamento diferente em relação aos null valores explícitos:

    • Os pools do Spark no Azure Synapse lerá esses valores como 0 (zero). E será alterado para undefined assim que a coluna tiver um valor não nulo.
    • Os pools sem servidor SQL no Azure Synapse lerão esses valores como NULL.
  • Espere um comportamento diferente em relação às colunas ausentes:

    • Os pools do Spark no Azure Synapse representarão essas colunas como undefined.
    • Os pools sem servidor SQL no Azure Synapse representarão essas colunas como NULL.

Representação de esquema com fidelidade total

A representação de esquema de fidelidade total foi projetada para lidar com toda a amplitude de esquemas polimórficos nos dados operacionais independentes de esquema. Nessa representação de esquema, nenhum item é removido do repositório analítico, mesmo que as restrições de esquema bem-definido (que não sejam campos de tipo de dados mistos nem matrizes de tipos de dados mistos) sejam violadas.

Isso é obtido pela tradução das propriedades de folha dos dados operacionais para o repositório analítico com colunas distintas com base no tipo de dados dos valores na propriedade. Os nomes de propriedade de folha são estendidos com tipos de dados como um sufixo no esquema de armazenamento analítico, de forma que eles possam ser consultas sem ambiguidade.

Na representação de esquema com fidelidade total, cada tipo de dados de cada propriedade irá gerar uma coluna para esse tipo de dados. Cada uma delas conta como uma das 1.000 propriedades máximas.

Por exemplo, vejamos o seguinte documento de exemplo no repositório transacional:

{
name: "John Doe",
age: 32,
profession: "Doctor",
address: {
  streetNo: 15850,
  streetName: "NE 40th St.",
  zip: 98052
},
salary: 1000000
}

A propriedade folha streetNo dentro do objeto aninhado address será representada no esquema de repositório analítico como uma coluna address.object.streetNo.int32. O tipo de dados é adicionado como um sufixo à coluna. Dessa forma, se for adicionado ao repositório transacional outro documento em que o valor da propriedade folha streetNo for "123" (observe que é uma cadeia de caracteres), o esquema do repositório analítico evoluirá automaticamente sem a necessidade de estar de acordo com os tipos de propriedade gravados anteriormente. Uma nova coluna adicionada ao repositório analítico como address.object.streetNo.string onde esse valor de "123" é armazenado.

Tipo de dados para mapa de sufixo

Aqui está um mapa de todos os tipos de dados de propriedade e suas representações de sufixo no repositório analítico:

Tipo de dados original Sufixo Exemplo
Double ".float64" 24.99
Array ".array" ["a", "b"]
Binário ".binary" 0
Boolean ".bool" True
Int32 ".int32" 123
Int64 ".int64" 255486129307
Nulo ".null" nulo
String ".string" "ABC"
Timestamp ".timestamp" Timestamp(0, 0)
Datetime ".date" ISODate("2020-08-21T07:43:07.375Z")
ObjectId ".objectId" ObjectId("5f3f7b59330ec25c132623a2")
Documento ".object" {"a": "a"}
  • Espere um comportamento diferente em relação aos null valores explícitos:

    • Os pools do Spark no Azure Synapse lerá esses valores como 0 (zero).
    • Os pools sem servidor SQL no Azure Synapse lerão esses valores como NULL.
  • Espere um comportamento diferente em relação às colunas ausentes:

    • Os pools do Spark no Azure Synapse representarão essas colunas como undefined.
    • Os pools sem servidor SQL no Azure Synapse representarão essas colunas como NULL.

Arquivamento econômico de dados históricos

Uma camada de dados se refere à separação de dados entre as infraestruturas de armazenamento otimizadas para cenários diferentes. Dessa forma, melhora o desempenho geral e a economia da pilha de dados de ponta a ponta. Com o repositório analítico, agora o Azure Cosmos DB tem suporte para camadas automáticas de dados do repositório transacional para o repositório analítico com diferentes layouts de dados. Com o repositório analítico otimizado em termos de custo de armazenamento em comparação ao repositório transacional, você pode reter horizontes muito maiores de dados operacionais para análise histórica.

Depois que o repositório analítico estiver habilitado, com base nas necessidades de retenção de dados das cargas de trabalho transacionais, você poderá configurar a propriedade “vida útil do repositório transacional (TTL transacional)” para que os registros sejam excluídos automaticamente do repositório transacional após um determinado período de tempo. De modo semelhante, a “vida útil do repositório analítico (TTL analítica)” permite que você gerencie o ciclo de vida dos dados retidos no repositório analítico independentemente do repositório transacional. Ao habilitar o repositório analítico e configurar as propriedades de TTL, você pode criar camadas e definir o período de retenção de dados para os dois repositórios perfeitamente.

Observação

No momento, o repositório analítico não dá suporte a backup e restauração. Sua política de backup não pode ser planejada com base no repositório analítico. Para saber mais, consulte a seção de limitações deste documento. É importante observar que os dados no repositório analítico têm um esquema diferente do que existe no armazenamento transacional. Embora você possa gerar instantâneos de seus dados de armazenamento analítico sem nenhum custo de RUs, não podemos garantir o uso desse instantâneo para fazer a retroalimentação do armazenamento transacional. Não há suporte para esse processo.

Distribuição Global

Se você tiver uma conta do Azure Cosmos DB distribuída globalmente, depois de habilitar o repositório analítico para um contêiner, ele ficará disponível em todas as regiões dessa conta. Quaisquer alterações nos dados operacionais são replicadas globalmente em todas as regiões. Você pode executar consultas analíticas efetivamente na cópia regional mais próxima dos seus dados no Azure Cosmos DB.

Segurança

  • A autenticação com o repositório analítico é igual a de um repositório transacional para um determinado banco de dados. Você pode usar chaves primárias ou somente leitura para a autenticação. Você pode usar o serviço vinculado no Synapse Studio para evitar colar as chaves do Azure Cosmos DB nos notebooks do Spark. No SQL do Azure Synapse sem servidor, você pode usar as credenciais de SQL para também evitar colar as chaves do Azure Cosmos DB nos notebooks SQL. O Acesso a estes Serviços Vinculados ou a essas credenciais está disponível para qualquer pessoa que tenha acesso ao workspace.

  • Isolamento de rede usando pontos de extremidade privados: você pode controlar o acesso à rede para os dados nos armazenamentos transacionais e analíticos de forma independente. O isolamento de rede é feito usando pontos de extremidade privados gerenciados separados para cada armazenamento, em redes virtuais gerenciadas nos espaços de trabalho do Azure Synapse. Para saber mais, consulte o artigo sobre como Configurar pontos de extremidade privados para o armazenamento analítico.

  • Criptografia de dados com chaves gerenciadas pelo cliente: você pode criptografar diretamente os dados entre os armazenamentos transacional e analítico usando as mesmas chaves gerenciadas pelo cliente de maneira automática e transparente. O Link do Azure Synapse só dá suporte à configuração de chaves gerenciadas pelo cliente usando a identidade gerenciada da sua conta do Azure Cosmos DB. Você deve configurar a identidade gerenciada da sua conta em sua política de acesso do Azure Key Vault antes de habilitar o Link do Azure Synapse em sua conta. Para saber mais, confira o artigo como Configurar as chaves gerenciadas pelo cliente usando identidades gerenciadas das contas do Azure Cosmos DB.

Suporte para vários runtimes do Azure Synapse Analytics

O repositório analítico é otimizado para fornecer escalabilidade, elasticidade e desempenho para cargas de trabalho analíticas sem qualquer dependência dos tempos de execução de computação. A tecnologia de armazenamento é autogerenciada para otimizar suas cargas de trabalho de análise se esforços manuais.

Ao desacoplar o sistema de repositório analítico do sistema de computação analítica, os dados no repositório analítico do Azure Cosmos DB podem ser consultados simultaneamente em diferentes runtimes de análise com suporte do Azure Synapse Analytics. A partir de hoje, o Azure Synapse Analytics tem suporte para o Apache Spark e o pool SQL sem servidor com o repositório analítico do Azure Cosmos DB.

Observação

Você só pode ler o repositório analítico usando os runtimes do Azure Synapse Analytics. E o oposto também é verdadeiro, os runtimes do Azure Synapse Analytics só podem ler do repositório analítico. Somente o processo de sincronização automática pode alterar os dados no repositório analítico. Você pode gravar dados de volta no armazenamento transacional do Cosmos DB usando o pool do Spark no Azure Synapse Analytics, usando o SDK Azure Cosmos DB OLTP interno.

Preços

O repositório analítico segue um modelo de preço baseado em consumo no qual você é cobrado por:

  • Armazenamento: o volume dos dados retidos no repositório analítico todos os meses, incluindo os dados históricos, conforme definido pela TTL analítica.

  • Operações de gravação analítica: a sincronização totalmente gerenciada de atualizações de dados operacionais para o repositório analítico a partir do repositório transacional (sincronização automática).

  • Operações de leitura analítica: as operações de leitura executadas no repositório analítico do pool do Azure Synapse Analytics Spark e os tempos de execução do pool SQL sem servidor.

O preço do repositório analítico é separado do modelo de preços do repositório transacional. Não há nenhum conceito de RUs provisionadas no repositório analítico. Confira a página de preços do Azure Cosmos DB para obter detalhes completos sobre o modelo de preços do repositório analítico.

Os dados no repositório de análise só podem ser acessados por meio do Link do Azure Synapse, o que é realizado nos runtimes do Azure Synapse Analytics: pools do Apache Spark do Azure Synapse e pools de SQL sem servidor do Azure Synapse. Confira a página de preços do Azure Synapse Analytics para obter detalhes completos sobre o modelo de preços para acessar dados no repositório analítico.

Para obter uma estimativa geral do custo para habilitar o armazenamento analítico em um contêiner do Azure Cosmos DB, da perspectiva do repositório analítico, você pode usar o Planejador de capacidade do Azure Cosmos DB e obter uma estimativa do armazenamento analítico e dos custos das operações de gravação. Os custos de operações de leitura analítica dependem das características da carga de trabalho analítica, mas como uma estimativa de alto nível, o exame de 1 TB de dados no repositório analítico geralmente resulta em 130.000 operações de leitura analítica e em um custo de US$ 0,065.

Observação

As estimativas de operações de leitura do repositório analítico não estão incluídas na calculadora de custos do Cosmos DB, pois são uma função de sua carga de trabalho analítica. Embora a estimativa acima seja para a verificação de 1 TB de dados no repositório analítico, a aplicação de filtros reduz o volume de dados verificados e determina o número exato de operações de leituras analíticas dado o modelo de preços de consumo. Uma prova de conceito em relação à carga de trabalho analítica forneceria uma estimativa mais refinada das operações de leitura analítica. Essa estimativa não inclui o custo do Azure Synapse Analytics.

TTL (vida útil) analítica

A TTL analítica indica por quanto tempo os dados devem ser retidos em seu repositório analítico, para um contêiner.

Se o repositório analítico estiver habilitado, as inserções, atualizações, exclusões em dados operacionais são sincronizadas automaticamente do repositório transacional para o repositório analítico, independentemente da configuração da TTL transacional. A retenção desses dados operacionais no repositório analítico pode ser controlada pelo valor da TTL Analítico no nível de contêiner, conforme especificado abaixo:

A TTL Analítico em um contêiner é definida usando a propriedade AnalyticalStoreTimeToLiveInSeconds:

  • Se o valor for definido como "0", ausente (ou definido como nulo): o repositório analítico será desabilitado, e nenhum dado será replicado do repositório transacional para o repositório analítico

  • Se presente e o valor for definido como "-1": o repositório analítico manterá todos os dados históricos, independentemente da retenção dos dados no repositório transacional. Essa configuração indica que o repositório analítico tem retenção infinita dos seus dados operacionais

  • Se presente e o valor for definido como algum número positivo “n”: os itens expirarão do repositório analítico “n” segundos após a hora da última modificação no repositório transacional. Essa configuração poderá ser usada se você quiser manter seus dados operacionais por um período de tempo limitado no repositório analítico, independentemente da retenção dos dados no repositório transacional.

Considere o seguinte:

  • Depois que o repositório analítico for habilitado com um determinado valor de TTL analítico, é possível atualizá-lo posteriormente com um valor válido diferente.
  • Embora a TTL transacional possa ser definida no nível de contêiner ou de item, atualmente, a TTL analítica só pode ser definida no nível de contêiner.
  • Você pode obter uma retenção mais longa de seus dados operacionais no repositório analítico ao definir a TTL analítica > = TTL transacional no nível de contêiner.
  • O repositório analítico pode ser feito para espelhar o armazenamento transacional ao definir a TTL analítica = TTL transacional.

Como habilitar o repositório analítico em um contêiner:

  • No portal do Azure, quando a opção TTL analítico está ligada, ela é definida com o valor padrão de -1. Você pode alterar esse valor para “n” segundos, navegando para configurações de contêiner em Data Explorer.

  • No SDK de Gerenciamento do Azure, do SDK do Azure Cosmos DB, do PowerShell ou da CLI, a opção de TTL analítico pode ser habilitada definindo-se como-1 ou ' n' segundos.

Para saber mais, confira Como configurar a TTL analítica em um contêiner.

Próximas etapas

Para saber mais, consulte a seguinte documentação: