O que é o arquivo analítico do Azure Cosmos DB?

APLICA A: SQL API Azure Cosmos DB API para MongoDB

A loja analítica Azure Cosmos DB é uma loja de colunas totalmente isolada para permitir análises em larga escala contra dados operacionais no seu Azure Cosmos DB, sem qualquer impacto nas suas cargas de trabalho transacionais.

A loja de transações Azure Cosmos DB é schema-agnóstica, e permite-lhe iterar nas suas aplicações transacionais sem ter de lidar com schema ou gestão de índices. Em contraste com isso, a loja analítica Azure Cosmos DB é schematizada para otimizar para o desempenho da consulta analítica. Este artigo descreve detalhadamente sobre o armazenamento analítico.

Desafios com análises em larga escala em dados operacionais

Os dados operacionais multi-modelo num contentor DB Azure Cosmos são armazenados internamente numa "loja transacional" indexada à base de linha. O formato da loja row foi projetado para permitir leituras e escritos transacionais rápidos nos tempos de resposta de ordem de milissegundos e consultas operacionais. Se o seu conjunto de dados crescer grandes e complexas consultas analíticas podem ser dispendiosas em termos de produção a forerada nos dados armazenados neste formato. O elevado consumo de produção aprovisionada, por sua vez, tem impacto no desempenho de cargas de trabalho transacionais que são utilizadas pelas suas aplicações e serviços em tempo real.

Tradicionalmente, para analisar grandes quantidades de dados, os dados operacionais são extraídos da loja transacional da Azure Cosmos DB e armazenados numa camada de dados separada. Por exemplo, os dados são armazenados num armazém de dados ou num lago de dados num formato adequado. Estes dados são mais tarde utilizados para análises em larga escala e analisados utilizando o motor computacional, como os clusters Apache Spark. Esta separação das camadas de armazenamento e cálculo analíticos dos dados operacionais resulta numa latência adicional, porque os gasodutos ETL (Extract, Transform, Load) são executados com menos frequência para minimizar o impacto potencial nas suas cargas de trabalho transacionais.

Os gasodutos ETL tornam-se também complexos ao lidar com atualizações aos dados operacionais quando comparados com o manuseamento de apenas dados operacionais recém-ingeridos.

Loja analítica orientada para colunas

A loja analítica Azure Cosmos DB aborda os desafios de complexidade e latência que ocorrem com os oleodutos tradicionais da ETL. A loja analítica Azure Cosmos DB pode sincronizar automaticamente os seus dados operacionais numa loja de colunas separada. O formato da loja de colunas é adequado para consultas analíticas em larga escala a serem realizadas de forma otimizada, resultando em melhorar a latência de tais consultas.

Utilizando Azure Synapse Link, pode agora construir soluções HTAP sem ETL ligando-se diretamente à loja analítica Azure Cosmos DB da Azure Synapse Analytics. Permite-lhe executar análises em larga escala em tempo real nos seus dados operacionais.

Características da loja analítica

Quando ativa a loja analítica num recipiente DB Azure Cosmos, uma nova loja de colunas é criada internamente com base nos dados operacionais do seu recipiente. Esta loja de colunas é persistido separadamente da loja transacional orientada para a linha para aquele recipiente. As inserções, atualizações e eliminações dos seus dados operacionais são automaticamente sincronizadas na loja analítica. Não precisa do Feed de Alteração ou ETL para sincronizar os dados.

Loja de colunas para cargas de trabalho analíticas em dados operacionais

Cargas de trabalho analíticas normalmente envolvem agregações e digitalizações sequenciais de campos selecionados. Ao armazenar os dados numa ordem de coluna-grande, a loja analítica permite que um grupo de valores para cada campo seja serializado em conjunto. Este formato reduz o IOPS necessário para digitalizar ou calcular estatísticas sobre campos específicos. Melhora drasticamente os tempos de resposta da consulta para digitalizações em grandes conjuntos de dados.

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

Example operational table

A loja de linha persiste os dados acima num formato serializado, por linha, no disco. Este formato permite leituras, escritas e consultas operacionais mais rápidas, tais como" Devolução de informações sobre o Produto1". No entanto, à medida que o conjunto de dados cresce grande e se quiser executar consultas analíticas complexas sobre os dados, pode ser caro. Por exemplo, se quiser obter "as tendências de venda de um produto na categoria denominada 'Equipamento' em diferentes unidades de negócio e meses", é necessário fazer uma consulta complexa. As grandes análises neste conjunto de dados podem ser dispendiosas em termos de produção aprovisionada e também podem ter impacto no desempenho das cargas de trabalho transacionais que alimentam as suas aplicações e serviços em tempo real.

A loja analítica, que é uma loja de colunas, é mais adequada para tais consultas porque serializa campos de dados semelhantes em conjunto e reduz o disco IOPS.

A imagem a seguir mostra loja de linha transacional vs. loja de colunas analíticas em Azure Cosmos DB:

Transactional row store Vs analytical column store in Azure Cosmos DB

Desempenho dissociado para cargas de trabalho analíticas

Não há impacto no desempenho das suas cargas de trabalho transacionais devido a consultas analíticas, uma vez que a loja analítica está separada da loja transacional. A loja analítica não precisa de unidades de pedido separadas (RUs) para ser atribuída.

Auto-Sincronização

Auto-Sync refere-se à capacidade totalmente gerida do Azure Cosmos DB onde os inserções, atualizações, eliminações para dados operacionais são automaticamente sincronizados da loja transacional para a loja analítica em tempo real. A latência de sincronização automática é geralmente dentro de 2 minutos. Em casos de base de dados de produção partilhada com um grande número de contentores, a latência auto-sincronizada de contentores individuais pode ser maior e demorar até 5 minutos. Gostaríamos de saber mais como esta latência se encaixa nos seus cenários. Para isso, por favor contacte a Equipa DB da Azure Cosmos.

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

  • Azure Synapse a Analytics Spark pode ler todos os dados, incluindo as mais recentes atualizações, através das tabelas Spark, que são atualizadas automaticamente, ou através do spark.read comando, que lê sempre o último estado dos dados.

  • Azure Synapse Analytics SQL os pools Serverless podem ler todos os dados, incluindo as atualizações mais recentes, através de vistas, que são atualizadas automaticamente, ou através SELECT dos OPENROWSET comandos, que lê sempre o estado mais recente dos dados.

Nota

Os seus dados transacionais serão sincronizados na loja analítica, mesmo que o seu tempo de vida transacional (TTL) seja inferior a 2 minutos.

Nota

Por favor, note que se eliminar o seu recipiente, a loja analítica também é eliminada.

Elasticidade da & escalabilidade

Ao utilizar divisórias horizontais, a loja transacional Azure Cosmos DB pode escalar elasticamente o armazenamento e a produção sem qualquer tempo de inatividade. A divisória horizontal na loja transacional proporciona elasticidade de escalabilidade & em auto-sincronização para garantir que os dados são sincronizados na loja analítica em tempo real. A sincronização de dados acontece independentemente da produção transacional de tráfego, quer sejam 1000 operações/seg ou 1 milhão de operações/seg, e não afeta o rendimento previsto na loja transacional.

Lidar automaticamente com atualizações de esquemas

A loja de transações Azure Cosmos DB é schema-agnóstica, e permite-lhe iterar nas suas aplicações transacionais sem ter de lidar com schema ou gestão de índices. Em contraste com isso, a loja analítica Azure Cosmos DB é schematizada para otimizar para o desempenho da consulta analítica. Com a capacidade de sincronização automática, a Azure Cosmos DB gere a inferência de esquema sobre as últimas atualizações da loja transacional. Também gere a representação de esquemas na loja analítica fora da caixa, o que inclui o manuseamento de tipos de dados aninhados.

À medida que o seu esquema evolui, e novas propriedades são adicionadas ao longo do tempo, a loja analítica apresenta automaticamente um esquema sindicalizado em todos os esquemas históricos na loja transacional.

Nota

No contexto da loja analítica, consideramos as seguintes estruturas como propriedade:

  • JSON "elementos" ou "pares de valores de corda separados por um : ".
  • Objetos JSON, delimitados por { e }.
  • Matrizes JSON, delimitadas por [ e ].

Restrições de esquema

Os seguintes constrangimentos são aplicáveis nos dados operacionais da Azure Cosmos DB quando permite que a loja analítica infera e represente corretamente o esquema:

  • Você pode ter um máximo de 1000 propriedades em todos os níveis aninhados no esquema do documento e uma profundidade máxima de nidificação de 127.

    • Apenas as primeiras 1000 propriedades estão representadas na loja analítica.
    • Apenas os primeiros 127 níveis aninhados estão representados na loja analítica.
    • O primeiro nível de um documento JSON é o seu / nível de raiz.
    • As propriedades no primeiro nível do documento serão representadas como colunas.
  • Cenários de amostragem:

    • Se o primeiro nível do seu documento tiver 2000 propriedades, apenas os primeiros 1000 serão representados.
    • Se os seus documentos tiverem cinco níveis com 200 propriedades em cada um, todas as propriedades estarão representadas.
    • Se os seus documentos tiverem 10 níveis com 400 propriedades em cada um, apenas os dois primeiros níveis estarão totalmente representados na loja analítica. Metade do terceiro nível também estará representado.
  • O documento hipotético abaixo contém quatro propriedades e três níveis.

    • Os níveis são root, myArraye a estrutura aninhada dentro do myArray.
    • As propriedades sãoid, myArrayemyArray.nested1myArray.nested2.
    • A representação da loja analítica terá duas colunas, ide myArray. Pode utilizar funções Spark ou T-SQL para também expor as estruturas aninhadas como colunas.
{
  "id": "1",
  "myArray": [
    "string1",
    "string2",
    {
      "nested1": "abc",
      "nested2": "cde"
    }
  ]
}
  • Enquanto os documentos json (e coletas/contentores Cosmos DB) são sensíveis a casos do ponto de vista da singularidade, a loja analítica não é.

    • No mesmo documento: Os nomes das propriedades no mesmo nível devem ser únicos quando comparados caso-insensívelmente. Por exemplo, o seguinte documento JSON tem "Nome" e "nome" no mesmo nível. Embora seja um documento JSON válido, não satisfaz a limitação de singularidade e, portanto, não estará totalmente representado na loja analítica. Neste exemplo, "Nome" e "nome" são os mesmos quando comparados de forma insensível a caso. Só "Name": "fred" estará representado na loja de análise, porque é a primeira ocorrência. E "name": "john" não será representado.
    {"id": 1, "Name": "fred", "name": "john"}
    
    • Em diferentes documentos: As propriedades no mesmo nível e com o mesmo nome, mas em casos diferentes, serão representadas dentro da mesma coluna, utilizando o formato de nome da primeira ocorrência. Por exemplo, os seguintes documentos JSON têm "Name" e "name" no mesmo nível. Uma vez que o primeiro formato documental é "Name", isto é o que será usado para representar o nome da propriedade na loja analítica. Por outras palavras, o nome da coluna na loja analítica será "Name". Ambos "fred" e "john" serão representados, na "Name" coluna.
    {"id": 1, "Name": "fred"}
    {"id": 2, "name": "john"}
    
  • O primeiro documento da coleção define o esquema inicial da loja analítica.

    • Documentos com mais propriedades do que o esquema inicial gerarão novas colunas na loja analítica.
    • As colunas não podem ser removidas.
    • A eliminação de todos os documentos de uma coleção não repõe o esquema da loja analítica.
    • Não há versões de esquema. A última versão deduzida da loja transacional é o que você verá na loja analítica.
  • Atualmente Azure Synapse Spark não consegue ler propriedades que contenham alguns caracteres especiais nos seus nomes, listados abaixo. Azure Synapse SQL sem servidor não é afetado.

    • :
    • `
    • ,
    • ;
    • {}
    • ()
    • \n
    • \t
    • =
    • "

Nota

Os espaços brancos também estão listados na mensagem de erro Spark devolvida quando se chega a esta limitação. Mas adicionámos um tratamento especial para espaços brancos, por favor confira mais detalhes nos itens abaixo.

  • Se tiver nomes de propriedades usando os caracteres acima indicados, as alternativas são:
    • Altere o seu modelo de dados com antecedência para evitar estes caracteres.
    • Uma vez que atualmente não suportamos o reset de esquema, você pode alterar a sua aplicação para adicionar uma propriedade redundante com um nome semelhante, evitando estes caracteres.
    • Utilize o Change Feed para criar uma visão materializada do seu recipiente sem estes caracteres em nomes de propriedades.
    • Utilize a opção dropColumn Spark para ignorar as colunas afetadas e carregue todas as outras colunas num DataFrame. A sintaxe é:
# Removing one column:
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()
     
# Removing multiple columns:
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;StreetName,StreetNumber")\
     .option("spark.cosmos.dropMultiColumnSeparator", ";")\
     .load()  
  • Azure Synapse Spark agora suporta propriedades com espaços brancos em seus nomes. Para isso, é necessário utilizar a opção allowWhiteSpaceInFieldNames Spark para carregar as colunas afetadas num DataFrame, mantendo o nome original. A sintaxe é:
df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.cosmos.allowWhiteSpaceInFieldNames", "true")\
    .load()
  • Os seguintes tipos de dados BSON não são suportados e não serão representados na loja analítica:

    • Decimal128
    • Expressão Regular
    • Ponteiro DB
    • JavaScript
    • Símbolo
    • MinKey/MaxKey
  • Ao utilizar as cordas DateTime que seguem a norma ISO 8601 UTC, espere o seguinte comportamento:

    • As piscinas de faíscas em Azure Synapse representarão estas colunas como string.
    • SQL piscinas sem servidor em Azure Synapse representarão estas colunas como varchar(8000).
  • SQL piscinas sem servidor em conjuntos de resultados de suporte Azure Synapse com até 1000 colunas, e expor colunas aninhadas também conta para esse limite. Por favor, considere estas informações ao conceber a sua arquitetura de dados e modelar os seus dados transacionais.

  • Se mudar o nome de um imóvel, em um ou muitos documentos, será considerado uma nova coluna. Se executar o mesmo rebatizador em todos os documentos da recolha, todos os dados serão migrados para a nova coluna e a coluna antiga será representada com NULL valores.

Representação de Schema

Existem dois tipos de representação de esquemas na loja analítica. Estes tipos definem o método de representação do esquema para todos os contentores na conta de base de dados e têm trocas entre a simplicidade da experiência de consulta versus a conveniência de uma representação colunar mais inclusiva para esquemas polimórficos.

  • Representação de esquema bem definida, opção por defeito para contas API de SQL (CORE).
  • Representação total do esquema de fidelidade, opção padrão para Azure Cosmos DB API para contas MongoDB.

Esquema de fidelidade total para contas SQL API

É possível utilizar o Esquema de fidelidade total para contas API de SQL (Core), em vez da opção padrão, definindo o tipo de esquema ao permitir Synapse Link numa conta Cosmos DB pela primeira vez. Aqui estão as considerações sobre a alteração do tipo de representação de esquema padrão:

  • Esta opção é válida apenas para contas que não tenham Synapse Link já ativadas.
  • Não é possível redefinir o tipo de representação de esquema, de bem definido a fidelidade total ou vice-versa.
  • Atualmente, a Azure Cosmos DB API para a MongoDB não é compatível com esta possibilidade de alterar a representação do esquema. Todas as contas mongoDB terão sempre o tipo de representação de esquema de fidelidade completo.
  • Atualmente esta mudança não pode ser feita através do portal do Azure. Todas as contas de base de dados que tenham Synapse Link ativadas 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 tomada ao mesmo tempo que Synapse Link está ativada na conta, utilizando a Azure CLI ou a PowerShell.

Com o Azure CLI:

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

Nota

No comando acima, substitua-o createupdate por contas existentes.

Com o PowerShell:

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

Nota

No comando acima, substitua-o New-AzCosmosDBAccountUpdate-AzCosmosDBAccount por contas existentes.

Representação de esquemas bem definidos

A representação de esquema bem definida cria uma simples representação tabular dos dados schema-agnósticos na loja transacional. A representação de esquemas bem definidas tem as seguintes considerações:

  • O primeiro documento define o esquema base e a propriedade deve ter sempre o mesmo tipo em todos os documentos. As únicas exceções são:
    • De NULL qualquer outro tipo de dados. A primeira ocorrência não nulo define o tipo de dados da coluna. Qualquer documento que não segui-lo seja o primeiro tipo de dados não nulo não será representado na loja analítica.
    • De float . para integer. Todos os documentos serão representados na loja de análise.
    • De integer . para float. Todos os documentos serão representados na loja de análise. No entanto, para ler estes dados com Azure Synapse SQL piscinas sem servidor, tem de utilizar uma cláusula COM para converter a coluna para varchar. E depois desta conversão inicial, é possível convertê-lo novamente para um número. Por favor, verifique o exemplo abaixo, onde um valor inicial era um número inteiro e o segundo era um flutuador.
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 de esquema base não serão representadas na loja analítica. Por exemplo, considere os documentos abaixo: o primeiro definiu o esquema base da loja analítica. O segundo documento, onde id está "2", não tem um esquema bem definido, uma vez que a propriedade "code" é uma cadeia e o primeiro documento tem "code" como número. Neste caso, a loja analítica regista o tipo de dados de "code" como integer para o tempo de vida do recipiente. O segundo documento ainda será incluído na loja de análise, mas a sua "code" propriedade não.

    • {"id": "1", "code":123}
    • {"id": "2", "code": "123"}

Nota

A condição acima não se aplica a NULL propriedades. Por exemplo, {"a":123} and {"a":NULL} ainda está bem definido.

Nota

A condição acima não muda se atualizar "code" o documento "1" para uma cadeia na sua loja transacional. Na loja analítica, "code" será mantido como integer atualmente não suportamos o reset de esquema.

  • Os tipos de matriz devem conter um único tipo repetido. Por exemplo, {"a": ["str",12]} não é um esquema bem definido porque a matriz contém uma mistura de inteiros e tipos de cordas.

Nota

Se a loja analítica Azure Cosmos DB seguir a representação de esquemas bem definida e a especificação acima for violada por certos itens, esses itens não serão incluídos na loja analítica.

  • Espere um comportamento diferente no que diz respeito a diferentes tipos em esquemas bem definidos:

    • As piscinas de faíscas em Azure Synapse representarão estes valores como undefined.
    • SQL piscinas sem servidor em Azure Synapse representarão estes valores como NULL.
  • Espere um comportamento diferente no que diz respeito a valores explícitos NULL :

    • As piscinas de faíscas em Azure Synapse lerão estes valores como 0 (zero). E mudará para undefined assim que a coluna tiver um valor não nulo.
    • SQL piscinas sem servidor em Azure Synapse lerão estes valores como NULL.
  • Espere um comportamento diferente no que diz respeito às colunas em falta:

    • As piscinas de faíscas em Azure Synapse representarão estas colunas como undefined.
    • SQL piscinas sem servidor em Azure Synapse representarão estas colunas como NULL.

Representação total do esquema de fidelidade

A representação total do esquema de fidelidade foi concebida para lidar com toda a amplitude de esquemas polimórficos nos dados operacionais schema-agnósticos. Nesta representação de esquema, nenhum itens é retirado da loja analítica, mesmo que as restrições de esquema bem definidas (que não são campos de tipo de dados mistos nem matrizes de tipo de dados mistos) sejam violadas.

Isto é conseguido traduzindo as propriedades da folha dos dados operacionais para a loja analítica com colunas distintas com base no tipo de dados de valores na propriedade. Os nomes da propriedade da folha são estendidos com tipos de dados como um sufixo no esquema de loja analítica de modo que podem ser consultas sem ambiguidade.

Na representação total do esquema de fidelidade, cada tipo de dados de cada propriedade gerará uma coluna para esse tipo de dados. Cada um deles conta como uma das 1000 propriedades máximas.

Por exemplo, vamos recolher o seguinte documento de amostra na loja transacional:

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

A propriedade streetNo da folha dentro do objeto address aninhado será representada no esquema de loja analítica como uma coluna address.object.streetNo.int32. O tipo de dados é adicionado como um sufixo à coluna. Desta forma, se outro documento for adicionado à loja transacional onde o valor da propriedade streetNo da folha é "123" (note que é uma corda), o esquema da loja analítica evolui automaticamente sem alterar o tipo de coluna previamente escrita. Uma nova coluna adicionada à loja analítica como address.object.streetNo.string onde este valor de "123" é armazenado.

Tipo de dados para mapa de sufixo

Aqui está um mapa de todos os tipos de dados da propriedade e suas representações de sufixo na loja analítica:

Tipo de dados original Sufixo Exemplo
Double (Duplo) ".float64" 24.99
Matriz ".array" ["a", "b"]
Binário ".binário" 0
Booleano ".bool" Verdadeiro
Int32 ".int32" 123
Int64 ".int64" 255486129307
NULL ". NULO" NULL
String ".string" "ABC"
CarimboDeDataEHora ".timetamp" Tempo de tempo (0,0)
DateTime ".data" ISODate ("2020-08-21T07:43:07.375Z")
ObjectId ".objectId" ObjectId ("5f3f7b59330ec25c132623a2")
Documento ".objeto" {"a": "a"}
  • Espere um comportamento diferente no que diz respeito a valores explícitos NULL :

    • As piscinas de faíscas em Azure Synapse lerão estes valores como 0 (zero).
    • SQL piscinas sem servidor em Azure Synapse lerão estes valores como NULL.
  • Espere um comportamento diferente no que diz respeito às colunas em falta:

    • As piscinas de faíscas em Azure Synapse representarão estas colunas como undefined.
    • SQL piscinas sem servidor em Azure Synapse representarão estas colunas como NULL.

Tempo analítico para viver (TTL)

TTL Analítico (ATTL) indica quanto tempo os dados devem ser retidos na sua loja analítica, para um recipiente.

A loja analítica é ativada quando a ATTL é definida com um valor diferente NULL e 0. Quando ativados, inserções, atualizações, eliminações para dados operacionais são automaticamente sincronizados da loja transacional para a loja analítica, independentemente da configuração transacional TTL (TTTL). A retenção destes dados transacionais na loja analítica pode ser controlada ao nível do AnalyticalStoreTimeToLiveInSeconds contentor pela propriedade.

As possíveis configurações ATTL são:

  • Se o valor for definido 0 ou definido para NULL: a loja analítica é desativada e nenhum dado é replicado da loja transacional para a loja analítica

  • Se o valor for definido para -1: a loja analítica retém todos os dados históricos, independentemente da conservação dos dados na loja transacional. Esta definição indica que a loja analítica tem uma retenção infinita dos seus dados operacionais

  • Se o valor for definido para um número inteiro n positivo: os itens expirarão a partir da loja n analítica segundos após o seu último tempo modificado na loja transacional. Esta definição pode ser alavancada se pretender reter os seus dados operacionais por um período limitado de tempo na loja analítica, independentemente da conservação dos dados na loja transacional

Alguns pontos a considerar:

  • Depois de a loja analítica estar ativada com um valor ATTL, pode ser atualizada para um valor válido diferente mais tarde.
  • Enquanto o TTTL pode ser definido ao nível do recipiente ou do item, o ATTL só pode ser definido ao nível do recipiente atualmente.
  • Pode obter uma maior retenção dos seus dados operacionais na loja analítica, definindo ATTL >= TTTL ao nível do recipiente.
  • A loja analítica pode ser feita para espelhar a loja transacional definindo ATTL = TTTL.
  • Se tiver ATTL maior que tTTL, em algum momento terá dados que só existem na loja analítica. Estes dados são lidos apenas.

Como permitir a loja analítica num recipiente:

  • A partir do portal do Azure, a opção ATTL, quando ligada, é definida para o valor padrão de -1. Pode alterar este valor para 'n' segundos, navegando para as definições do recipiente sob Data Explorer.

  • A partir da Azure Management SDK, Azure Cosmos DB SDKs, PowerShell ou Azure CLI, a opção ATTL pode ser ativada definindo-a para -1 ou 'n' segundos.

Para saber mais, consulte como configurar a TTL analítica num recipiente.

Arquivo rentável de dados históricos

O tiering de dados refere-se à separação de dados entre infraestruturas de armazenamento otimizadas para diferentes cenários. Assim, melhorar o desempenho global e a eficácia de custos da pilha de dados de ponta a ponta. Com a loja analítica, a Azure Cosmos DB suporta agora o tiering automático de dados da loja transacional para a loja analítica com diferentes layouts de dados. Com a loja analítica otimizada em termos de custo de armazenamento em comparação com a loja transacional, permite-lhe reter horizontes muito mais longos de dados operacionais para análise histórica.

Após a ativação da loja analítica, com base nas necessidades de retenção de dados das cargas de trabalho transacionais, pode configurar a propriedade time-to-live (TTTL) da loja transacional para ter registos automaticamente apagados da loja transacional após um determinado período de tempo. Da mesma forma, a loja analítica Time-to-Live (ATTL)' permite-lhe gerir o ciclo de vida dos dados retidos na loja analítica independente da loja transacional. Ao permitir a loja analítica e configurar propriedades TTL, pode nivelar perfeitamente e definir o período de retenção de dados para as duas lojas.

Backup

Atualmente, a loja analítica não suporta backup e restauro, e a sua política de backup não pode ser planeada confiando nisso. Para mais informações, consulte a secção de limitações deste documento. Embora o modo de backup contínuo não seja suportado em contas de base de dados com Synapse Link ativado, o modo de cópia de segurança periódica é.

Com o modo de backup periódico e os recipientes existentes, pode:

Reconstruir totalmente a loja analítica quando TTTL >= ATTL

O recipiente original é restaurado sem loja analítica. Mas pode ative-lo e será reconstruído com todos os dados que existem no recipiente.

Reconstruir parcialmente a loja analítica quando tTTL < ATTL

Os dados que estavam apenas na loja analítica não são restaurados, mas serão mantidos disponíveis para consultas desde que mantenha o recipiente original. A loja analítica só é eliminada quando apagar o recipiente. As suas consultas analíticas em Azure Synapse Analytics podem ler dados de lojas analíticas originais e restauradas do contentor. Exemplo:

  • O contentor OnlineOrders tem TTTL definido para um mês e ATTL definido para um ano.
  • Quando o restaurar e ligar a OnlineOrdersNew loja analítica para reconstruí-la, haverá apenas um mês de dados na loja transacional e analítica.
  • O recipiente OnlineOrders original não é apagado e a sua loja analítica ainda está disponível.
  • Os novos dados só são ingeridos em OnlineOrdersNew.
  • As consultas analíticas farão uma UNION ALL a partir de lojas analíticas enquanto os dados originais ainda são relevantes.

Se pretender eliminar o recipiente original mas não quiser perder os seus dados de loja analítica, pode persistir na loja analítica do recipiente original noutro serviço de dados Azure. A Synapse Analytics tem a capacidade de realizar junções entre dados armazenados em diferentes locais. Um exemplo: Uma consulta synapse Analytics junta dados de loja analítica com tabelas externas localizadas em Armazenamento de Blobs do Azure, Azure Data Lake Store, etc.

É importante notar que os dados na loja analítica têm um esquema diferente do que existe na loja transacional. Embora possa gerar instantâneos dos seus dados de loja analíticos e exportá-lo para qualquer serviço Azure Data, sem custos de RUs, não podemos garantir o uso deste instantâneo para voltar a alimentar a loja transacional. Este processo não é apoiado.

Distribuição Global

Se tiver uma conta DB Azure Cosmos distribuída globalmente, depois de ativar uma loja analítica para um recipiente, estará disponível em todas as regiões dessa conta. Quaisquer alterações aos dados operacionais são globalmente replicadas em todas as regiões. Pode executar consultas analíticas eficazmente contra a cópia regional mais próxima dos seus dados em Azure Cosmos DB.

Criação de partições

A partição de lojas analíticas é completamente independente da divisão na loja transacional. Por padrão, os dados na loja analítica não são divididos. Se as suas consultas analíticas tiverem usado filtros frequentemente, tem a opção de dividir com base nestes campos para um melhor desempenho de consulta. Para saber mais, consulte a introdução à partição personalizada e como configurar a partição personalizada.

Segurança

  • A autenticação na loja analítica é a mesma que a loja transacional para uma determinada base de dados. Pode utilizar as chaves primárias, secundárias ou apenas de leitura para a autenticação. Pode aproveitar o serviço ligado em Synapse Studio para evitar a colagem das chaves DB do Azure Cosmos nos cadernos Spark. Para Azure Synapse SQL sem servidor, pode utilizar credenciais SQL para evitar a colagem das teclas DB do Azure Cosmos nos cadernos SQL. O Acesso a estes Serviços Ligados ou a estas credenciais SQL estão disponíveis para qualquer pessoa que tenha acesso ao espaço de trabalho. Por favor, note que a chave de leitura cosmos também pode ser usada.

  • Isolamento de rede utilizando pontos finais privados - Pode controlar o acesso à rede aos dados nas lojas transacionais e analíticas de forma independente. O isolamento da rede é feito utilizando pontos finais privados geridos separados para cada loja, dentro de redes virtuais geridas em espaços de trabalho Azure Synapse. Para saber mais, veja como configurar pontos finais privados para artigos de loja analítica .

  • Encriptação de dados com teclas geridas pelo cliente - Pode encriptar os dados de forma perfeita através de lojas transacionais e analíticas utilizando as mesmas chaves geridas pelo cliente de forma automática e transparente. Azure Synapse Link só suporta configurar chaves geridas pelo cliente usando a identidade gerida da sua conta Azure Cosmos DB. Tem de configurar a identidade gerida da sua conta na sua política de acesso Key Vault Azure antes de permitir Azure Synapse Link na sua conta. Para saber mais, veja como configurar as chaves geridas pelo cliente usando o artigo de identidades geridas pela Azure Cosmos DB .

Suporte para vários tempos de Azure Synapse Analytics

A loja analítica está otimizada para proporcionar escalabilidade, elasticidade e desempenho para cargas de trabalho analíticas sem qualquer dependência dos tempos de execução do cálculo. A tecnologia de armazenamento é auto-gerida para otimizar as suas cargas de trabalho de análise sem esforços manuais.

Ao dissociar o sistema de armazenamento analítico do sistema de computação analítica, os dados na loja analítica Azure Cosmos DB podem ser consultados simultaneamente a partir dos diferentes tempos de execução analíticos suportados pelo Azure Synapse Analytics. A partir de hoje, a Azure Synapse Analytics suporta o Apache Spark e a piscina de SQL sem servidor com a loja analítica Azure Cosmos DB.

Nota

Só é possível ler na loja de análise utilizando Azure Synapse tempos de funcionação do Analytics. E o oposto também é verdade, Azure Synapse os tempos de execução da Analytics só podem ser lidos a partir de lojas analíticas. Apenas o processo de auto-sincronização pode alterar dados na loja analítica. Você pode escrever dados de volta para a loja transacional Cosmos DB usando Azure Synapse Piscina De Spark Analytics, usando o Azure Cosmos DB OLTP SDK incorporado.

Preços

A loja analítica segue um modelo de preços baseado no consumo onde é cobrado:

  • Armazenamento: o volume dos dados retidos na loja analítica todos os meses, incluindo dados históricos definidos pela TTL analítica.

  • Operações de escrita analítica: a sincronização totalmente gerida das atualizações de dados operacionais para a loja analítica a partir da loja transacional (auto-sincronização)

  • Operações de leitura analítica: as operações de leitura realizadas contra a loja analítica a partir da piscina Azure Synapse Analytics Spark e tempos de execução SQL sem servidor.

O preço da loja analítica é separado do modelo de preços da loja de transações. Não há nenhum conceito de RUs a provisionados na loja analítica. Consulte a página de preços da Azure Cosmos DB para obter detalhes completos sobre o modelo de preços para a loja analítica.

Os dados na loja de análise só podem ser acedidos através do Link Azure Synapse, que é feito nos tempos de execução Azure Synapse Analytics: Azure Synapse piscinas Apache Spark e Azure Synapse piscinas SQL sem servidor. Consulte Azure Synapse página de preços do Analytics para obter todos os detalhes sobre o modelo de preços para aceder aos dados na loja analítica.

Para obter uma estimativa de custos de alto nível para permitir uma loja analítica num recipiente Azure Cosmos DB, do ponto de vista da loja analítica, você pode usar o planejador DB capacidade Azure Cosmos e obter uma estimativa dos seus custos de armazenamento analítico e escrever operações. Os custos das operações de leitura analítica dependem das características da carga de trabalho analítica, mas como estimativa de alto nível, a análise de 1 TB de dados na loja analítica resulta tipicamente em 130.000 operações de leitura analítica, e resulta num custo de $0,065.

Nota

As estimativas de operações de leitura de lojas analíticas não estão incluídas na calculadora de custos da Cosmos DB, uma vez que são uma função da sua carga de trabalho analítica. Embora a estimativa acima seja para digitalizar 1TB de dados na loja analítica, a aplicação de filtros reduz o volume de dados digitalizados e isso determina o número exato de operações de leitura analítica dado o modelo de preços de consumo. Uma prova de conceito em torno da carga de trabalho analítica proporcionaria uma estimativa mais fina das operações de leitura analítica. Esta estimativa não inclui o custo da Azure Synapse Analytics.

Passos seguintes

Para saber mais, consulte os seguintes documentos: