Informazioni sull'archivio analitico di Azure Cosmos DB

SI APPLICA A: Nosql Mongodb Gremlin

L'archivio analitico di Azure Cosmos DB è un archivio colonne completamente isolato per consentire l'analisi su larga scala dei dati operativi in Azure Cosmos DB, senza alcun impatto sui carichi di lavoro transazionali.

L'archivio transazionale di Azure Cosmos DB è senza schema e consente di eseguire l'iterazione sulle applicazioni transazionali senza dover gestire schemi o indici. Al contrario, l'archivio analitico di Azure Cosmos DB è schematizzato per ottimizzare le prestazioni delle query analitiche. Questo articolo descrive in dettaglio l'archiviazione analitica.

Problemi con l'analisi su larga scala dei dati operativi

I dati operativi multimodello in un contenitore Azure Cosmos DB vengono archiviati internamente in un "archivio transazionale" indicizzato basato su righe. Il formato dell'archivio righe è progettato per consentire letture e scritture transazionali rapide nei tempi di risposta dell'ordine dei millisecondi e query operative. Se il set di dati aumenta di dimensioni elevate, le query analitiche complesse possono essere costose in termini di velocità effettiva con provisioning sui dati archiviati in questo formato. Un utilizzo elevato della velocità effettiva con provisioning influisce a sua volta sulle prestazioni dei carichi di lavoro transazionali usati dalle applicazioni e dai servizi in tempo reale.

Tradizionalmente, per analizzare grandi quantità di dati, i dati operativi vengono estratti dall'archivio transazionale di Azure Cosmos DB e archiviati in un livello dati separato. Ad esempio, i dati vengono archiviati in un data warehouse o data lake in un formato appropriato. Questi dati vengono usati in seguito per l'analisi su larga scala e analizzati usando motori di calcolo come i cluster Apache Spark. La separazione dei dati analitici dai dati operativi comporta ritardi per gli analisti che vogliono usare i dati più recenti.

Anche le pipeline ETL diventano complesse quando si gestiscono gli aggiornamenti ai dati operativi rispetto alla gestione dei soli dati operativi appena inseriti.

Archivio analitico orientato alle colonne

L'archivio analitico di Azure Cosmos DB risolve i problemi di complessità e latenza che si verificano con le pipeline ETL tradizionali. L'archivio analitico di Azure Cosmos DB può sincronizzare automaticamente i dati operativi in un archivio colonne separato. Il formato dell'archivio colonne è adatto per l'esecuzione di query analitiche su larga scala in modo ottimizzato, con conseguente miglioramento della latenza di tali query.

Usando Azure Synapse Collegamento, è ora possibile creare soluzioni HTAP senza ETL collegandosi direttamente all'archivio analitico di Azure Cosmos DB da Azure Synapse Analytics. Consente di eseguire analisi su larga scala in near real-time sui dati operativi.

Funzionalità dell'archivio analitico

Quando si abilita l'archivio analitico in un contenitore Azure Cosmos DB, viene creato internamente un nuovo archivio colonne in base ai dati operativi presenti nel contenitore. Questo archivio colonne viene mantenuto separatamente dall'archivio transazionale orientato alle righe per tale contenitore, in un account di archiviazione completamente gestito da Azure Cosmos DB, in una sottoscrizione interna. I clienti non devono trascorrere tempo con l'amministrazione dell'archiviazione. Gli inserimenti, gli aggiornamenti e le eliminazioni dei dati operativi vengono sincronizzati automaticamente con l'archivio analitico. Non è necessario il feed di modifiche o ETL per sincronizzare i dati.

Archivio colonne per carichi di lavoro analitici su dati operativi

I carichi di lavoro analitici in genere comportano aggregazioni e analisi sequenziali dei campi selezionati. Archiviando i dati in ordine column-major, l'archivio analitico consente di serializzare insieme un gruppo di valori per ogni campo. Questo formato riduce le operazioni di I/O al secondo necessarie per l'analisi o il calcolo delle statistiche su campi specifici. Migliora notevolmente i tempi di risposta delle query per le analisi su set di dati di grandi dimensioni.

Ad esempio, se le tabelle operative hanno il formato seguente:

L'archivio righe salva in modo permanente i dati sopra riportati in un formato serializzato, per ogni riga, sul disco. Questo formato consente letture e scritture transazionali più veloci e query operative, ad esempio "restituire informazioni su Product1". Tuttavia, man mano che le dimensioni del set di dati aumentano e se si vogliono eseguire query analitiche complesse sui dati, può essere costoso. Ad esempio, se si desidera ottenere "le tendenze di vendita per un prodotto nella categoria denominata "Equipment" in diverse business unit e mesi, è necessario eseguire una query complessa. Le analisi di grandi dimensioni in questo set di dati possono risultare costose in termini di velocità effettiva con provisioning e possono anche influire sulle prestazioni dei carichi di lavoro transazionali che alimentano le applicazioni e i servizi in tempo reale.

L'archivio analitico, che è un archivio colonne, è più adatto per tali query perché serializza insieme i campi di dati simili e riduce le operazioni di I/O al secondo del disco.

Nell'immagine seguente viene illustrato l'archivio righe transazionale rispetto all'archivio colonne analitico in Azure Cosmos DB:

Prestazioni separate per carichi di lavoro analitici

Non vi è alcun impatto sulle prestazioni dei carichi di lavoro transazionali a causa di query analitiche, poiché l'archivio analitico è separato dall'archivio transazionale. L'archivio analitico non necessita di unità richiesta separate da allocare.

Sincronizzazione automatica

Sincronizzazione automatica fa riferimento alla funzionalità completamente gestita di Azure Cosmos DB in cui gli inserimenti, gli aggiornamenti, le eliminazioni ai dati operativi vengono sincronizzati automaticamente dall'archivio transazionale all'archivio analitico in tempo quasi reale. La latenza di sincronizzazione automatica è in genere entro 2 minuti. Nei casi di database con velocità effettiva condivisa con un numero elevato di contenitori, la latenza di sincronizzazione automatica dei singoli contenitori potrebbe essere superiore e richiedere fino a 5 minuti.

Alla fine di ogni esecuzione del processo di sincronizzazione automatica, i dati transazionali saranno immediatamente disponibili per i runtime di analisi di Azure Synapse:

• Azure Synapse pool spark di Analisi possono leggere tutti i dati, inclusi gli aggiornamenti più recenti, tramite tabelle Spark, che vengono aggiornate automaticamente o tramite il spark.read comando, che legge sempre l'ultimo stato dei dati.

• Azure Synapse pool SQL Serverless di Analisi possono leggere tutti i dati, inclusi gli aggiornamenti più recenti, tramite visualizzazioni, che vengono aggiornati automaticamente o tramite SELECT i OPENROWSET comandi, che legge sempre lo stato più recente dei dati.

Nota

I dati transazionali verranno sincronizzati con l'archivio analitico anche se il time-to-live (TTL) transazionale è inferiore a 2 minuti.

Nota

Si noti che se si elimina il contenitore, l'archivio analitico viene eliminato anche.

& Elasticità della scalabilità

Grazie al partizionamento orizzontale, l'archivio transazionale di Azure Cosmos DB può dimensionare in modo elastico l'archiviazione e la velocità effettiva senza tempi di inattività. Il partizionamento orizzontale nell'archivio transazionale offre elasticità di scalabilità & nella sincronizzazione automatica per garantire che i dati vengano sincronizzati nell'archivio analitico in tempo quasi reale. La sincronizzazione dei dati avviene indipendentemente dalla velocità effettiva del traffico transazionale, indipendentemente dal fatto che si tratti di 1000 operazioni/sec o di 1 milione di operazioni/sec e non influisca sulla velocità effettiva di provisioning nell'archivio transazionale.

Gestione automatica degli aggiornamenti dello schema

L'archivio transazionale di Azure Cosmos DB è senza schema e consente di eseguire l'iterazione sulle applicazioni transazionali senza dover gestire schemi o indici. Al contrario, l'archivio analitico di Azure Cosmos DB è schematizzato per ottimizzare le prestazioni delle query analitiche. Con la funzionalità di sincronizzazione automatica, Azure Cosmos DB gestisce l'inferenza dello schema sugli aggiornamenti più recenti dall'archivio transazionale. Gestisce inoltre per impostazione predefinita la rappresentazione dello schema nell'archivio analitico, che include la gestione dei tipi di dati annidati.

Man mano che lo schema si evolve e le nuove proprietà vengono aggiunte nel tempo, l'archivio analitico presenta automaticamente uno schema unioneto in tutti gli schemi cronologici nell'archivio transazionale.

Nota

Nel contesto dell'archivio analitico si considerano le strutture seguenti come proprietà:

• JSON "elements" o "string-value coppie separate da un : ".
• Oggetti JSON, delimitati da { e }.
• Matrici JSON, delimitate da [ e ].

Vincoli dello schema

I vincoli seguenti sono applicabili ai dati operativi in Azure Cosmos DB quando si abilita l'archivio analitico per dedurre automaticamente e rappresentare correttamente lo schema:

• È possibile avere un massimo di 1000 proprietà in tutti i livelli nidificati nello schema del documento e una profondità massima di annidamento pari a 127.

  • Solo le prime 1000 proprietà sono rappresentate nell'archivio analitico.
  • Solo i primi 127 livelli annidati sono rappresentati nell'archivio analitico.
  • Il primo livello di un documento JSON è il / relativo livello radice.
  • Le proprietà nel primo livello del documento verranno rappresentate come colonne.

• Scenari di esempio:

  • Se il primo livello del documento ha 2000 proprietà, il processo di sincronizzazione rappresenterà i primi 1000 di essi.
  • Se i documenti hanno cinque livelli con 200 proprietà in ognuna, il processo di sincronizzazione rappresenta tutte le proprietà.
  • Se i documenti hanno 10 livelli con 400 proprietà in ognuna, il processo di sincronizzazione rappresenta completamente i due primi livelli e solo la metà del terzo livello.

• Il documento ipotetico seguente contiene quattro proprietà e tre livelli.

  • I livelli sono root, myArraye la struttura annidata all'interno di myArray.
  • Le proprietà sono id, , myArraymyArray.nested1e myArray.nested2.
  • La rappresentazione dell'archivio analitico avrà due colonne, ide myArray. È possibile usare funzioni Spark o T-SQL per esporre anche le strutture annidate come colonne.

{
  "id": "1",
  "myArray": [
    "string1",
    "string2",
    {
      "nested1": "abc",
      "nested2": "cde"
    }
  ]
}

• Mentre i documenti JSON (e le raccolte/contenitori di Azure Cosmos DB) sono distinzione tra maiuscole e minuscole dal punto di vista dell'univocità, l'archivio analitico non è.

  • Nello stesso documento: I nomi delle proprietà nello stesso livello devono essere univoci quando confrontati in modo senza distinzione tra maiuscole e minuscole. Ad esempio, il documento JSON seguente ha "Name" e "name" nello stesso livello. Sebbene sia un documento JSON valido, non soddisfa il vincolo di univocità e quindi non sarà completamente rappresentato nell'archivio analitico. In questo esempio "Name" e "name" sono uguali quando confrontati in modo senza distinzione tra maiuscole e minuscole. Verrà rappresentato solo "Name": "fred" nell'archivio analitico, perché è la prima occorrenza. E "name": "john" non sarà affatto rappresentato.

  {"id": 1, "Name": "fred", "name": "john"}
  

  • In documenti diversi: Le proprietà nello stesso livello e con lo stesso nome, ma in casi diversi, verranno rappresentate all'interno della stessa colonna, usando il formato del nome della prima occorrenza. Ad esempio, i documenti JSON seguenti hanno "Name" e "name" nello stesso livello. Poiché il primo formato del documento è "Name", si tratta di ciò che verrà usato per rappresentare il nome della proprietà nell'archivio analitico. In altre parole, il nome della colonna nell'archivio analitico sarà "Name". Entrambi "fred" e "john" verranno rappresentati nella "Name" colonna.

  {"id": 1, "Name": "fred"}
  {"id": 2, "name": "john"}
  

• Il primo documento della raccolta definisce lo schema dell'archivio analitico iniziale.

  • I documenti con più proprietà dello schema iniziale genereranno nuove colonne nell'archivio analitico.
  • Le colonne non possono essere rimosse.
  • L'eliminazione di tutti i documenti in una raccolta non reimposta lo schema dell'archivio analitico.
  • Non è disponibile il controllo delle versioni dello schema. L'ultima versione derivata dall'archivio transazionale è ciò che verrà visualizzato nell'archivio analitico.

• Attualmente Azure Synapse Spark non può leggere le proprietà che contengono alcuni caratteri speciali nei loro nomi, elencati di seguito. Azure Synapse SQL Serverless non è interessato.

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

Nota

Gli spazi vuoti sono elencati anche nel messaggio di errore Spark restituito quando si raggiunge questa limitazione. Ma abbiamo aggiunto un trattamento speciale per spazi vuoti, vedere altri dettagli negli elementi seguenti.

• Se sono presenti nomi di proprietà usando i caratteri elencati in precedenza, le alternative sono:
  • Modificare il modello di dati in anticipo per evitare questi caratteri.
  • Poiché attualmente non è supportata la reimpostazione dello schema, è possibile modificare l'applicazione per aggiungere una proprietà ridondante con un nome simile, evitando questi caratteri.
  • Usare Il feed di modifiche per creare una visualizzazione materializzata del contenitore senza questi caratteri nei nomi delle proprietà.
  • Usare l'opzione dropColumn Spark per ignorare le colonne interessate e caricare tutte le altre colonne in un dataframe. La sintassi è:

# 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 supporta ora le proprietà con spazi vuoti nei nomi. A tale scopo, è necessario usare l'opzione allowWhiteSpaceInFieldNames Spark per caricare le colonne interessate in un dataframe, mantenendo il nome originale. La sintassi è:

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()

• I tipi di dati BSON seguenti non sono supportati e non saranno rappresentati nell'archivio analitico:

  • Decimal128
  • Espressione regolare
  • Puntatore db
  • JavaScript
  • Simbolo
  • MinKey/MaxKey

• Quando si usano stringhe DateTime che seguono lo standard UTC ISO 8601, si prevede il comportamento seguente:

  • I pool spark in Azure Synapse rappresentano queste colonne come string.
  • I pool serverless di SQL in Azure Synapse rappresentano queste colonne come varchar(8000).

• Le proprietà con UNIQUEIDENTIFIER (guid) tipi sono rappresentate come string nell'archivio analitico e devono essere convertite VARCHAR in SQL o string in In Spark per la visualizzazione corretta.

• I pool serverless SQL in Azure Synapse supportano i set di risultati con un massimo di 1000 colonne e l'esposizione di colonne annidate conta anche verso tale limite. È consigliabile considerare queste informazioni nell'architettura e nella modellazione dei dati transazionali.

• Se si rinomina una proprietà, in uno o più documenti, verrà considerata una nuova colonna. Se si esegue la stessa ridenominazione in tutti i documenti della raccolta, tutti i dati verranno migrati alla nuova colonna e la colonna precedente verrà rappresentata con NULL valori.

Rappresentazione dello schema

Esistono due metodi di rappresentazione dello schema nell'archivio analitico, validi per tutti i contenitori nell'account del database. Hanno compromessi tra la semplicità dell'esperienza di query e la praticità di una rappresentazione colonnare più inclusiva per gli schemi polimorfi.

• Rappresentazione dello schema ben definita, opzione predefinita per l'API per gli account NoSQL e Gremlin.
• Rappresentazione completa dello schema fedeltà, opzione predefinita per gli account API per MongoDB.

Rappresentazione dello schema ben definita

La rappresentazione dello schema ben definita crea una rappresentazione tabulare semplice dei dati agnostici dello schema nell'archivio transazionale. La rappresentazione dello schema ben definita presenta le considerazioni seguenti:

• Il primo documento definisce lo schema di base e le proprietà devono sempre avere lo stesso tipo in tutti i documenti. Le uniche eccezioni sono:
  • Da NULL a qualsiasi altro tipo di dati. La prima occorrenza non Null definisce il tipo di dati della colonna. Qualsiasi documento che non segue il primo tipo di dati non Null non sarà rappresentato nell'archivio analitico.
  • Da float a integer. Tutti i documenti sono rappresentati nell'archivio analitico.
  • Da integer a float. Tutti i documenti sono rappresentati nell'archivio analitico. Tuttavia, per leggere questi dati con Azure Synapse pool serverless SQL, è necessario usare una clausola WITH per convertire la colonna in varchar. E dopo questa conversione iniziale, è possibile convertirla di nuovo in un numero. Controllare l'esempio seguente, dove il valore iniziale num era un intero e il secondo era un 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]

• Le proprietà che non seguono il tipo di dati dello schema di base non verranno rappresentate nell'archivio analitico. Si considerino ad esempio i documenti seguenti: il primo definito lo schema di base dell'archivio analitico. Il secondo documento, dove id è , non ha uno schema ben definito poiché la proprietà "code" è "2"una stringa e il primo documento ha "code" come numero. In questo caso, l'archivio analitico registra il tipo di dati di "code" come integer per la durata del contenitore. Il secondo documento verrà comunque incluso nell'archivio analitico, ma la relativa "code" proprietà non verrà inclusa.

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

Nota

La condizione precedente non si applica alle NULL proprietà. Ad esempio, {"a":123} and {"a":NULL} è ancora ben definito.

Nota

La condizione precedente non cambia se si aggiorna "code" il documento "1" a una stringa nell'archivio transazionale. Nell'archivio "code" analitico verrà mantenuto come integer dal momento che attualmente non è supportata la reimpostazione dello schema.

• I tipi di matrice devono contenere un solo tipo ripetuto. Ad esempio, {"a": ["str",12]} non è uno schema ben definito perché la matrice contiene una combinazione di tipi integer e stringa.

Nota

Se l'archivio analitico di Azure Cosmos DB segue la rappresentazione dello schema ben definita e la specifica precedente viene violata da determinati elementi, tali elementi non verranno inclusi nell'archivio analitico.

• Si prevede un comportamento diverso rispetto ai diversi tipi nello schema ben definito:

  • I pool spark in Azure Synapse rappresentano questi valori come undefined.
  • I pool serverless SQL in Azure Synapse rappresentano questi valori come NULL.

• Si prevede un comportamento diverso per quanto riguarda i valori espliciti NULL :

  • I pool spark in Azure Synapse leggere questi valori come 0 (zero) e non undefined appena la colonna ha un valore non null.
  • I pool sql serverless in Azure Synapse leggere questi valori come NULL.

• Si prevede un comportamento diverso rispetto alle colonne mancanti:

  • I pool spark in Azure Synapse rappresentano queste colonne come undefined.
  • I pool serverless di SQL in Azure Synapse rappresentano queste colonne come NULL.

Soluzioni alternative per le sfide di rappresentazione

È possibile che un documento precedente, con uno schema non corretto, sia stato usato per creare lo schema di base dell'archivio analitico del contenitore. In base a tutte le regole presentate in precedenza, è possibile ricevere NULL per determinate proprietà quando si esegue una query sull'archivio analitico usando Azure Synapse Collegamento. Per eliminare o aggiornare i documenti problematici non sarà utile perché la reimpostazione dello schema di base non è attualmente supportata. Le possibili soluzioni sono:

• Per eseguire la migrazione dei dati a un nuovo contenitore, assicurarsi che tutti i documenti abbiano lo schema corretto.
• Per abbandonare la proprietà con lo schema errato e aggiungerne uno nuovo con un altro nome con lo schema corretto in tutti i documenti. Esempio: nel contenitore Orders sono presenti miliardi di documenti in cui la proprietà status è una stringa. Ma il primo documento in tale contenitore ha lo stato definito con integer. Quindi, un documento avrà stato correttamente rappresentato e tutti gli altri documenti avranno NULL. È possibile aggiungere la proprietà status2 a tutti i documenti e iniziare a usarla anziché alla proprietà originale.

Rappresentazione dello schema con massima fedeltà

La rappresentazione completa dello schema di fedeltà è progettata per gestire l'intera gamma di schemi polimorfici nei dati operativi agnostici dello schema. In questa rappresentazione dello schema non vengono eliminati elementi dall'archivio analitico anche se i vincoli di schema ben definiti (che non sono campi di tipo di dati misti né matrici di tipi di dati misti) vengono violati.

Ciò viene ottenuto traducendo le proprietà foglia dei dati operativi nell'archivio analitico come coppie JSONkey-value, dove il tipo di dati è il key e il contenuto della proprietà è .value Questa rappresentazione dell'oggetto JSON consente query senza ambiguità e è possibile analizzare singolarmente ogni tipo di dati.

In altre parole, nella rappresentazione completa dello schema fedeltà ogni tipo di dati di ogni proprietà di ogni documento genererà una key-valuecoppia in un oggetto JSON per tale proprietà. Ognuno di essi conta come uno dei 1000 limiti massimi di proprietà.

Ad esempio, si esaminerà il documento di esempio seguente nell'archivio transazionale:

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

L'oggetto address annidato è una proprietà nel livello radice del documento e verrà rappresentata come colonna. Ogni proprietà foglia nell'oggetto address verrà rappresentata come oggetto JSON: {"object":{"streetNo":{"int32":15850},"streetName":{"string":"NE 40th St."},"zip":{"int32":98052}}}.

A differenza della rappresentazione dello schema ben definita, il metodo di fedeltà completo consente la variazione nei tipi di dati. Se il documento successivo in questa raccolta dell'esempio precedente ha streetNo come stringa, verrà rappresentato nell'archivio analitico come "streetNo":{"string":15850}. Nel metodo dello schema ben definito non sarebbe rappresentato.

Mappa dei tipi di dati per lo schema di fedeltà completa

Ecco una mappa di tutti i tipi di dati delle proprietà e delle relative rappresentazioni nell'archivio analitico in rappresentazione dello schema fedeltà completa:

Tipo dati originale	Suffisso	Esempio
Double	".float64"	24.99
Array	".array"	["a", "b"]
Binary	".binary"	0
Boolean	".bool"	True
Int32	".int32"	123
Int64	".int64"	255486129307
NULL	". NULL"	NULL
string	".string"	"ABC"
Timestamp	".timestamp"	Timestamp(0, 0)
ObjectId	".objectId"	ObjectId("5f3f7b59330ec25c132623a2")
Documento	".object"	{"a": "a"}

• Si prevede un comportamento diverso per quanto riguarda i valori espliciti NULL :

  • I pool spark in Azure Synapse leggeranno questi valori come 0 (zero).
  • I pool serverless SQL in Azure Synapse leggeranno questi valori come NULL.

• Si prevede un comportamento diverso rispetto alle colonne mancanti:

  • I pool spark in Azure Synapse rappresentano queste colonne come undefined.
  • I pool serverless sql in Azure Synapse rappresentano queste colonne come NULL.

Uso dello schema di fedeltà completo con Spark

Spark gestirà ogni tipo di dati come colonna durante il caricamento in un DataFrameoggetto . Si supponga che una raccolta con i documenti seguenti.

{
	"_id" : "1" ,
	"item" : "Pizza",
	"price" : 3.49,
	"rating" : 3,
	"timestamp" : 1604021952.6790195
},
{
	"_id" : "2" ,
	"item" : "Ice Cream",
	"price" : 1.59,
	"rating" : "4" ,
	"timestamp" : "2022-11-11 10:00 AM"
}

Mentre il primo documento ha come numero e timestamp in formato utc, il secondo documento ha ratingrating e timestamp come stringhe. Supponendo che questa raccolta sia stata caricata in DataFrame senza alcuna trasformazione dei dati, l'output dell'oggetto df.printSchema() è:

root
 |-- _rid: string (nullable = true)
 |-- _ts: long (nullable = true)
 |-- id: string (nullable = true)
 |-- _etag: string (nullable = true)
 |-- _id: struct (nullable = true)
 |    |-- objectId: string (nullable = true)
 |-- item: struct (nullable = true)
 |    |-- string: string (nullable = true)
 |-- price: struct (nullable = true)
 |    |-- float64: double (nullable = true)
 |-- rating: struct (nullable = true)
 |    |-- int32: integer (nullable = true)
 |    |-- string: string (nullable = true)
 |-- timestamp: struct (nullable = true)
 |    |-- float64: double (nullable = true)
 |    |-- string: string (nullable = true)
 |-- _partitionKey: struct (nullable = true)
 |    |-- string: string (nullable = true)

Nella rappresentazione dello schema ben definita, entrambi rating e timestamp del secondo documento non sarebbero rappresentati. Nello schema di fedeltà completo è possibile usare gli esempi seguenti per accedere singolarmente a ogni valore di ogni tipo di dati.

Nell'esempio seguente è possibile usare PySpark per eseguire un'aggregazione:

df.groupBy(df.item.string).sum().show()

Nell'esempio seguente è possibile usare PySQL per eseguire un'altra aggregazione:

df.createOrReplaceTempView("Pizza")
sql_results = spark.sql("SELECT sum(price.float64),count(*) FROM Pizza where timestamp.string is not null and item.string = 'Pizza'")
sql_results.show()

Uso dello schema di fedeltà completo con SQL

Considerando gli stessi documenti dell'esempio spark precedente, i clienti possono usare l'esempio di sintassi seguente:

SELECT rating,timestamp_string,timestamp_utc
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = 'Account=<your-database-account-name';Database=<your-database-name>',
                OBJECT = '<your-collection-name>',
                SERVER_CREDENTIAL = '<your-synapse-sql-server-credential-name>')
WITH ( 
rating integer '$.rating.int32',    
timestamp varchar(50) '$.timestamp.string',
timestamp_utc float '$.timestamp.float64' 
) as HTAP 
WHERE timestamp is not null or timestamp_utc is not null

A partire dalla query precedente, i clienti possono implementare trasformazioni usando casto convert qualsiasi altra funzione T-SQL per modificare i dati. I clienti possono anche nascondere strutture di tipo di dati complesse usando le viste.

create view MyView as
SELECT MyRating=rating,MyTimestamp = convert(varchar(50),timestamp_utc)
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = 'Account=<your-database-account-name';Database=<your-database-name>',
                OBJECT = '<your-collection-name>',
                SERVER_CREDENTIAL = '<your-synapse-sql-server-credential-name>')
WITH ( 
rating integer '$.rating.int32',    
timestamp_utc float '$.timestamp.float64' 
) as HTAP 
WHERE  timestamp_utc is not null
union all 
SELECT MyRating=convert(integer,rating_string),MyTimestamp = timestamp_string
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = 'Account=<your-database-account-name';Database=<your-database-name>',
                OBJECT = '<your-collection-name>',
                SERVER_CREDENTIAL = '<your-synapse-sql-server-credential-name>')
WITH ( 
rating_string varchar(50) '$.rating.string',    
timestamp_string varchar(50) '$.timestamp.string' 
) as HTAP 
WHERE  timestamp_string is not null

Uso del campo MongoDB _id

il campo MongoDB è fondamentale per ogni raccolta in MongoDB _id e originariamente ha una rappresentazione esadecimale. Come si può vedere nella tabella precedente, lo schema di fedeltà completa manterrà le sue caratteristiche, creando una sfida per la sua visualizzazione in Azure Synapse Analytics. Per la visualizzazione corretta, è necessario convertire il _id tipo di dati come indicato di seguito:

Uso del campo MongoDB _id in Spark

L'esempio seguente funziona nelle versioni di Spark 2.x e 3.x:

val df = spark.read.format("cosmos.olap").option("spark.synapse.linkedService", "xxxx").option("spark.cosmos.container", "xxxx").load()

val convertObjectId = udf((bytes: Array[Byte]) => {
    val builder = new StringBuilder

    for (b <- bytes) {
        builder.append(String.format("%02x", Byte.box(b)))
    }
    builder.toString
}
 )

val dfConverted = df.withColumn("objectId", col("_id.objectId")).withColumn("convertedObjectId", convertObjectId(col("_id.objectId"))).select("id", "objectId", "convertedObjectId")
display(dfConverted)

Uso del campo MongoDB _id in SQL

SELECT TOP 100 id=CAST(_id as VARBINARY(1000))
FROM OPENROWSET('CosmosDB',
                'Your-account;Database=your-database;Key=your-key',
                HTAP) WITH (_id VARCHAR(1000)) as HTAP

Schema di fedeltà completo per gli account API per NoSQL o Gremlin

È possibile usare lo schema di fedeltà completo per gli account NoSQL anziché l'opzione predefinita impostando il tipo di schema quando si abilita Collegamento a Synapse in un account Azure Cosmos DB per la prima volta. Ecco le considerazioni sulla modifica del tipo di rappresentazione dello schema predefinito:

• Attualmente, se si abilita Collegamento a Synapse nell'account API NoSQL usando il portale di Azure, sarà abilitato come schema ben definito.
• Attualmente, se si vuole usare lo schema di fedeltà completo con account API NoSQL o Gremlin, è necessario impostarlo a livello di account nella stessa interfaccia della riga di comando o di PowerShell che consentirà Collegamento a Synapse a livello di account.
• Attualmente Azure Cosmos DB per MongoDB non è compatibile con questa possibilità di modificare la rappresentazione dello schema. Tutti gli account MongoDB hanno un tipo di rappresentazione dello schema fedeltà completo.
• Non è possibile reimpostare il tipo di rappresentazione dello schema, da ben definito a fedeltà completa o viceversa.
• Attualmente, gli schemi dei contenitori nell'archivio analitico vengono definiti quando il contenitore viene creato, anche se Collegamento a Synapse non è stato abilitato nell'account del database.
  • I contenitori o i grafici creati prima che Collegamento a Synapse sia stato abilitato con lo schema di fedeltà completo a livello di account avranno uno schema ben definito.
  • I contenitori o i grafici creati dopo che Collegamento a Synapse è stato abilitato con lo schema di fedeltà completo a livello di account avranno uno schema di fedeltà completo.

La decisione del tipo di rappresentazione dello schema deve essere presa contemporaneamente che Collegamento a Synapse è abilitata nell'account usando l'interfaccia della riga di comando di Azure o PowerShell.

Con l'interfaccia della riga di comando di Azure:

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

Nota

Nel comando precedente sostituire create con update per gli account esistenti.

Con PowerShell:

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

Nota

Nel comando precedente sostituire New-AzCosmosDBAccount con Update-AzCosmosDBAccount per gli account esistenti.

Durata (TTL) dei dati analitici

Il TTL analitico (ATTL) indica la durata di conservazione dei dati nell'archivio analitico per un contenitore.

L'archivio analitico è abilitato quando ATTL è impostato con un valore diverso da NULL e 0. Se abilitata, inserisce, aggiornamenti, eliminazioni ai dati operativi vengono sincronizzate automaticamente dall'archivio transazionale all'archivio analitico, indipendentemente dalla configurazione TTL transazionale (TTTL). La conservazione di questi dati transazionali nell'archivio analitico può essere controllata a livello di AnalyticalStoreTimeToLiveInSeconds contenitore dalla proprietà .

Le possibili configurazioni ATTL sono:

• Se il valore è impostato su o impostato su 0NULL: l'archivio analitico è disabilitato e non vengono replicati dati dall'archivio transazionale all'archivio analitico

• Se il valore è impostato su -1: l'archivio analitico conserva tutti i dati cronologici, indipendentemente dalla conservazione dei dati nell'archivio transazionale. Questa impostazione indica che l'archivio analitico ha una conservazione infinita dei dati operativi

• Se il valore è impostato su qualsiasi numero intero n positivo: gli elementi scadono dall'archivio n analitico secondi dopo l'ultima volta modificata nell'archivio transazionale. Questa impostazione può essere sfruttata se si desidera conservare i dati operativi per un periodo di tempo limitato nell'archivio analitico, indipendentemente dalla conservazione dei dati nell'archivio transazionale

Alcune informazioni da considerare:

• Dopo aver abilitato l'archivio analitico con un valore ATTL, può essere aggiornato a un valore valido diverso in un secondo momento.
• Sebbene sia possibile impostare TTTL a livello di contenitore o elemento, ATTL può essere impostato solo a livello di contenitore attualmente.
• È possibile ottenere una conservazione più lunga dei dati operativi nell'archivio analitico impostando ATTL = TTTL >a livello di contenitore.
• L'archivio analitico può essere eseguito per eseguire il mirroring dell'archivio transazionale impostando ATTL = TTTL.
• Se si dispone di ATTL più grande di TTTL, in qualche momento si avranno dati che esistono solo nell'archivio analitico. Questi dati vengono letti solo.
• Attualmente non vengono eliminati dati dall'archivio analitico. Se si imposta ATTL su qualsiasi intero positivo, i dati non verranno inclusi nelle query e non verranno fatturati. Tuttavia, se si modifica ATTL di nuovo in -1, tutti i dati verranno visualizzati di nuovo, si inizierà a essere fatturati per tutto il volume di dati.

Come abilitare l'archivio analitico in un contenitore:

• Dall'portale di Azure, l'opzione ATTL, quando attivata, è impostata sul valore predefinito di -1. È possibile modificare questo valore in secondi 'n', passando alle impostazioni del contenitore in Esplora dati.

• Dall'SDK di Gestione di Azure, gli SDK di Azure Cosmos DB, PowerShell o l'interfaccia della riga di comando di Azure, l'opzione ATTL può essere abilitata impostandola su -1 o 'n' secondi.

Per altre informazioni, vedere come configurare la durata (TTL) dei dati analitici in un contenitore.

Analisi conveniente sui dati cronologici

La suddivisione in livelli dei dati si riferisce alla separazione dei dati tra le infrastrutture di archiviazione ottimizzate per diversi scenari. Migliorando in tal modo le prestazioni complessive e la convenienza dello stack di dati end-to-end. Con l'archivio analitico, Azure Cosmos DB supporta ora la suddivisione in livelli automatica dei dati dall'archivio transazionale all'archivio analitico con layout di dati diversi. Con l'archivio analitico ottimizzato in termini di costi di archiviazione rispetto all'archivio transazionale, consente di mantenere orizzonti molto più lunghi dei dati operativi per l'analisi cronologica.

Dopo aver abilitato l'archivio analitico, in base alle esigenze di conservazione dei dati dei carichi di lavoro transazionali, è possibile configurare transactional TTL la proprietà per avere i record eliminati automaticamente dall'archivio transazionale dopo un determinato periodo di tempo. Analogamente, consente analytical TTL di gestire il ciclo di vita dei dati conservati nell'archivio analitico, indipendentemente dall'archivio transazionale. Abilitando l'archivio analitico e la configurazione delle proprietà transazionali e analitiche TTL , è possibile eseguire facilmente il livello e definire il periodo di conservazione dei dati per i due archivi.

Nota

Quando analytical TTL è maggiore di transactional TTL, il contenitore avrà dati esistenti solo nell'archivio analitico. Questi dati vengono letti solo e attualmente non supportano il livello TTL di documento nell'archivio analitico. Se i dati del contenitore potrebbero richiedere un aggiornamento o un'eliminazione in un certo momento in futuro, non usare analytical TTL più grandi di transactional TTL. Questa funzionalità è consigliata per i dati che non necessitano di aggiornamenti o eliminazioni in futuro.

Nota

Se lo scenario non richiede eliminazioni fisiche, è possibile adottare un approccio logico di eliminazione/aggiornamento. Inserire nell'archivio transazionale un'altra versione dello stesso documento presente solo nell'archivio analitico, ma richiede un'eliminazione/aggiornamento logico. Forse con un flag che indica che è un'eliminazione o un aggiornamento di un documento scaduto. Entrambe le versioni dello stesso documento coesistono nell'archivio analitico e l'applicazione deve considerare solo l'ultima.

Resilienza

L'archivio analitico si basa su Archiviazione di Azure e offre la protezione seguente da errori fisici:

• Per impostazione predefinita, gli account di database di Azure Cosmos DB allocano l'archivio analitico negli account di archiviazione con ridondanza locale. L'archiviazione con ridondanza locale garantisce almeno il 99,999999999% (11 nove) di durabilità degli oggetti nell'arco di un anno specifico.
• Se un'area geografica dell'account di database è configurata per la ridondanza della zona, viene allocata negli account di archiviazione con ridondanza della zona. I clienti devono abilitare zone di disponibilità in un'area dell'account di database di Azure Cosmos DB per avere dati analitici di tale area archiviati nell'archiviazione con ridondanza della zona. ZRS offre durabilità per le risorse di archiviazione di almeno il 99,999999999999% (12 9) in un determinato anno.

Per altre informazioni sulla durabilità di Archiviazione di Azure, fare clic qui.

Backup

Anche se l'archivio analitico ha una protezione predefinita contro gli errori fisici, il backup può essere necessario per le eliminazioni accidentali o gli aggiornamenti nell'archivio transazionale. In questi casi, è possibile ripristinare un contenitore e usare il contenitore ripristinato per riempire i dati nel contenitore originale o ricompilare completamente l'archivio analitico, se necessario.

Nota

Attualmente l'archivio analitico non viene eseguito il backup, pertanto non può essere ripristinato. I criteri di backup non possono essere pianificati in base a questo.

Collegamento a Synapse e archiviazione analitica per conseguenza, presenta diversi livelli di compatibilità con le modalità di backup di Azure Cosmos DB:

• La modalità di backup periodica è completamente compatibile con Collegamento a Synapse e queste 2 funzionalità possono essere usate nello stesso account di database.
• Attualmente la modalità di backup continua e Collegamento a Synapse non sono supportate nello stesso account di database. I clienti devono scegliere una di queste due funzionalità e questa decisione non può essere modificata.

Criteri di backup

Esistono due possibili criteri di backup e per comprendere come usarli, i dettagli seguenti sui backup di Azure Cosmos DB sono molto importanti:

• Il contenitore originale viene ripristinato senza archivio analitico in entrambe le modalità di backup.
• Azure Cosmos DB non supporta la sovrascrittura dei contenitori da un ripristino.

Vediamo ora come usare backup e ripristino dal punto di vista dell'archivio analitico.

Ripristino di un contenitore con TTTL = ATTL >

Quando transactional TTL è uguale o maggiore di analytical TTL, tutti i dati nell'archivio analitico esistono ancora nell'archivio transazionale. In caso di ripristino, sono disponibili due possibili situazioni:

• Per usare il contenitore ripristinato come sostituzione del contenitore originale. Per ricompilare l'archivio analitico, abilitare Collegamento a Synapse a livello di account e contenitore.
• Per usare il contenitore ripristinato come origine dati per compilare o aggiornare i dati nel contenitore originale. In questo caso, l'archivio analitico riflette automaticamente le operazioni sui dati.

Ripristino di un contenitore con TTTL ATTL <

Quando transactional TTL è minore di analytical TTL, alcuni dati esistono solo nell'archivio analitico e non saranno presenti nel contenitore ripristinato. Di nuovo, si hanno due possibili situazioni:

• Per usare il contenitore ripristinato come sostituzione del contenitore originale. In questo caso, quando si abilita Collegamento a Synapse a livello di contenitore, solo i dati presenti nell'archivio transazionale verranno inclusi nel nuovo archivio analitico. Si noti tuttavia che l'archivio analitico del contenitore originale rimane disponibile per le query purché esista il contenitore originale. È possibile modificare l'applicazione in entrambe le query.
• Per usare il contenitore ripristinato come origine dati per compilare o aggiornare i dati nel contenitore originale:
• L'archivio analitico riflette automaticamente le operazioni di dati per i dati presenti nell'archivio transazionale.
• Se si inseriscono nuovamente i dati rimossi in precedenza dall'archivio transazionale a causa transactional TTLdi , questi dati verranno duplicati nell'archivio analitico.

Esempio:

• Il contenitore OnlineOrders dispone di TTTL impostato su un mese e su ATTL impostato per un anno.
• Quando lo si ripristina e OnlineOrdersNew si attiva l'archivio analitico per ricompilarlo, ci sarà solo un mese di dati in archivio transazionale e analitico.
• Il contenitore OnlineOrders originale non viene eliminato e l'archivio analitico è ancora disponibile.
• I nuovi dati vengono inseriti solo in OnlineOrdersNew.
• Le query analitiche eseguiranno un'operazione UNION ALL da archivi analitici mentre i dati originali sono ancora rilevanti.

Se si vuole eliminare il contenitore originale, ma non si vuole perdere i dati dell'archivio analitico, è possibile mantenere l'archivio analitico del contenitore originale in un altro servizio dati di Azure. Synapse Analytics offre la possibilità di eseguire join tra i dati archiviati in posizioni diverse. Esempio: una query synapse Analytics aggiunge i dati analitici all'archivio analitico con tabelle esterne disponibili in Archiviazione BLOB di Azure, Azure Data Lake Store e così via.

È importante notare che i dati nell'archivio analitico hanno uno schema diverso da quello che esiste nell'archivio transazionale. Anche se è possibile generare snapshot dei dati dell'archivio analitico ed esportarlo in qualsiasi servizio dati di Azure, senza costi delle UR, non è possibile garantire l'uso di questo snapshot per eseguire il feed dell'archivio transazionale. Questo processo non è supportato.

Distribuzione globale

Se si ha un account Azure Cosmos DB distribuito a livello globale, un archivio analitico abilitato per un contenitore sarà disponibile in tutte le aree di tale account. Tutte le modifiche apportate ai dati operativi vengono replicate a livello globale in tutte le aree. È possibile eseguire efficacemente query analitiche sulla copia locale più vicina dei dati in Azure Cosmos DB.

Partizionamento

Il partizionamento dell'archivio analitico è completamente indipendente dal partizionamento nell'archivio transazionale. Per impostazione predefinita, i dati nell'archivio analitico non vengono partizionati. Se le query analitiche hanno spesso usato filtri, è possibile partizionare in base a questi campi per migliorare le prestazioni delle query. Per altre informazioni, vedere Introduzione al partizionamento personalizzato e come configurare il partizionamento personalizzato.

Sicurezza

• L'autenticazione con l'archivio analitico è uguale all'archivio transazionale per un determinato database. È possibile usare chiavi primarie, secondarie o di sola lettura per l'autenticazione. È possibile sfruttare il servizio collegato in Synapse Studio per evitare di incollare le chiavi di Azure Cosmos DB nei notebook di Spark. Per Azure Synapse SQL serverless, è possibile usare le credenziali SQL per evitare anche di incollare le chiavi di Azure Cosmos DB nei notebook SQL. L'accesso a questi servizi collegati o a queste credenziali SQL è disponibile per chiunque abbia accesso all'area di lavoro. Si noti che è anche possibile usare la chiave di sola lettura di Azure Cosmos DB.

• Isolamento di rete tramite endpoint privati : è possibile controllare l'accesso di rete ai dati negli archivi transazionali e analitici in modo indipendente. L'isolamento della rete viene eseguito usando endpoint privati gestiti separati per ogni archivio, all'interno di reti virtuali gestite in Azure Synapse aree di lavoro. Per altre informazioni, vedere l'articolo Configurare endpoint privati per l'archivio analitico .

• Crittografia dei dati inattivi : la crittografia dell'archivio analitico è abilitata per impostazione predefinita.

• Crittografia dei dati con chiavi gestite dal cliente : è possibile crittografare facilmente i dati tra archivi transazionali e analitici usando le stesse chiavi gestite dal cliente in modo automatico e trasparente. Azure Synapse Collegamento supporta solo la configurazione delle chiavi gestite dal cliente usando l'identità gestita dell'account Azure Cosmos DB. È necessario configurare l'identità gestita dell'account nei criteri di accesso di Azure Key Vault prima di abilitare Azure Synapse Collegamento all'account. Per altre informazioni, vedere l'articolo Configurare le chiavi gestite dal cliente usando le identità gestite degli account Azure Cosmos DB .

Nota

Se si modifica l'account del database da First Party a System o User Assigned Identy e si abilita Azure Synapse Collegamento nell'account del database, non sarà possibile tornare all'identità first party perché non è possibile disabilitare Collegamento a Synapse dall'account del database.

Supporto di più runtime di Azure Synapse Analytics

L'archivio analitico è ottimizzato per offrire scalabilità, elasticità e prestazioni per carichi di lavoro analitici senza alcuna dipendenza dai runtime di calcolo. La tecnologia di archiviazione è gestita automaticamente per ottimizzare i carichi di lavoro analitici senza interventi manuali.

Separando il sistema di archiviazione analitico dal sistema di calcolo analitico, è possibile eseguire simultaneamente query sui dati nell'archivio analitico di Azure Cosmos DB da diversi runtime di analisi supportati da Azure Synapse Analytics. A partire da oggi, Azure Synapse Analytics supporta apache Spark e il pool SQL serverless con l'archivio analitico di Azure Cosmos DB.

Nota

È possibile leggere solo dall'archivio analitico usando i runtime di Azure Synapse Analytics. L'opposto è anche vero, Azure Synapse runtime di Analytics può leggere solo dall'archivio analitico. Solo il processo di sincronizzazione automatica può modificare i dati nell'archivio analitico. È possibile scrivere di nuovo i dati nell'archivio transazionale di Azure Cosmos DB usando Azure Synapse pool di Spark di Analisi, usando l'SDK OLTP di Azure Cosmos DB predefinito.

Prezzi

L'archivio analitico segue un modello tariffario basato sul consumo per cui vengono addebitati i costi:

• Archiviazione: il volume dei dati conservati nell'archivio analitico ogni mese, inclusi i dati cronologici definiti dal TTL analitico.

• Operazioni di scrittura analitica: sincronizzazione completamente gestita degli aggiornamenti dei dati operativi nell'archivio analitico dall'archivio transazionale (sincronizzazione automatica)

• Operazioni di lettura analitica: le operazioni di lettura eseguite sull'archivio analitico da Azure Synapse pool Spark di Analisi e tempi di esecuzione del pool SQL serverless.

Il prezzo dell'archivio analitico è separato dal modello di prezzi dell'archivio transazioni. Non esiste alcun concetto di UR di cui è stato effettuato il provisioning nell'archivio analitico. Per informazioni dettagliate sul modello di prezzi per l'archivio analitico, vedere la pagina dei prezzi di Azure Cosmos DB .

È possibile accedere ai dati nell'archivio di analisi solo tramite Azure Synapse Collegamento, eseguito nei runtime di Azure Synapse Analytics: Azure Synapse pool Apache Spark e Azure Synapse pool SQL serverless. Per informazioni dettagliate sul modello tariffario per accedere ai dati nell'archivio analitico, vedere la pagina dei prezzi di Azure Synapse Analytics.

Per ottenere una stima dei costi di alto livello per abilitare l'archivio analitico in un contenitore di Azure Cosmos DB, dal punto di vista dell'archivio analitico, è possibile usare Capacity Planner di Azure Cosmos DB e ottenere una stima dei costi di archiviazione analitica e scrittura delle operazioni.

Le stime delle operazioni di lettura dell'archivio analitico non sono incluse nel calcolatore dei costi di Azure Cosmos DB perché sono una funzione del carico di lavoro analitico. Tuttavia, come stima generale, l'analisi di 1 TB di dati nell'archivio analitico genera in genere 130.000 operazioni di lettura analitica e comporta un costo di $ 0,065. Ad esempio, se si usa Azure Synapse pool SQL serverless per eseguire questa analisi di 1 TB, il costo sarà di $ 5,00 in base alla pagina dei prezzi di Azure Synapse Analytics. Il costo totale finale per questa analisi da 1 TB sarebbe di $5,065.

Mentre la stima precedente è per l'analisi di 1 TB di dati nell'archivio analitico, l'applicazione di filtri riduce il volume di dati analizzati e questo determina il numero esatto di operazioni di lettura analitica in base al modello di determinazione dei prezzi del consumo. Un modello di verifica relativo al carico di lavoro analitico fornisce una stima più dettagliata delle operazioni di lettura analitica. Questa stima non include il costo di Azure Synapse Analytics.

Passaggi successivi

Per altre informazioni, vedere la documentazione seguente:

• Collegamento ad Azure Synapse per Azure Cosmos DB

• Vedere il modulo di training su come progettare l'elaborazione transazionale e analitica ibrida usando Azure Synapse Analytics

• Introduzione a Collegamento ad Azure Synapse per Azure Cosmos DB

• Domande frequenti su Collegamento ad Azure Synapse per Azure Cosmos DB

• Casi d'uso di Collegamento ad Azure Synapse per Azure Cosmos DB