Condividi tramite

Suggerimenti sulle prestazioni per Azure Cosmos DB Sync Java SDK v2

  • Si applica a: ✅ NoSQL

Importante

Questa non corrisponde alla versione più recente di Java SDK per Azure Cosmos DB. È consigliabile aggiornare il progetto ad Azure Cosmos DB Java SDK v4 e quindi leggere la guida ai suggerimenti sulle prestazioni di Java SDK v4 di Azure Cosmos DB. Seguire le istruzioni nella guida Eseguire la migrazione ad Azure Cosmos DB Java SDK v4 e la guida Reactor vs RxJava per eseguire l'aggiornamento.

Questi suggerimenti sulle prestazioni sono solo per Azure Cosmos DB Sync Java SDK v2. Per altre informazioni, vedere il repository Maven .

Importante

Il 29 febbraio 2024 azure Cosmos DB Sync Java SDK v2.x verrà ritirato; l'SDK e tutte le applicazioni che usano l'SDK continueranno a funzionare; Azure Cosmos DB smetterà di fornire ulteriore manutenzione e supporto per questo SDK. È consigliabile seguire le istruzioni sopra riportate per eseguire la migrazione ad Azure Cosmos DB Java SDK v4.

Azure Cosmos DB è un database distribuito veloce e flessibile, facilmente scalabile e con latenza e velocità effettiva garantite. Non è necessario apportare modifiche significative all'architettura o scrivere codice complesso per ridimensionare il database con Azure Cosmos DB. Aumentare o ridurre le prestazioni è semplice come eseguire una singola chiamata API. Per altre informazioni, vedere come effettuare il provisioning della velocità effettiva del contenitore o come effettuare il provisioning della velocità effettiva del database. Tuttavia, poiché Azure Cosmos DB è accessibile tramite chiamate di rete, è possibile eseguire ottimizzazioni lato client per ottenere prestazioni ottimali quando si usa Azure Cosmos DB Sync Java SDK v2.

Se si vogliono migliorare le prestazioni del database, valutare le opzioni seguenti:

Rete

  1. Modalità di connessione: Usare DirectHttps

    Il modo in cui un client si connette ad Azure Cosmos DB ha implicazioni importanti sulle prestazioni, soprattutto in termini di latenza lato client osservata. È disponibile un'impostazione di configurazione chiave per la configurazione del client ConnectionPolicy , ovvero ConnectionMode. Le due modalità di connessione disponibili sono:

    1. Gateway (impostazione predefinita)

    2. DirectHttps

      La modalità gateway è supportata in tutte le piattaforme SDK ed è l'impostazione predefinita configurata. Se l'applicazione viene eseguita all'interno di una rete aziendale con restrizioni del firewall rigorose, il gateway è la scelta migliore perché usa la porta HTTPS standard e un singolo endpoint. Il compromesso delle prestazioni, tuttavia, è che la modalità gateway comporta un hop di rete aggiuntivo ogni volta che i dati vengono letti o scritti in Azure Cosmos DB. Per questo motivo, la modalità DirectHttps offre prestazioni migliori a causa di un minor numero di hop di rete.

      Azure Cosmos DB Sync Java SDK v2 usa HTTPS come protocollo di trasporto. HTTPS usa TLS per l'autenticazione iniziale e la crittografia del traffico. Quando si usa Azure Cosmos DB Sync Java SDK v2, è necessario aprire solo la porta HTTPS 443.

      ConnectionMode viene configurato durante la costruzione dell'istanza di DocumentClient con il parametro ConnectionPolicy.

    Sync Java SDK V2 (Maven com.microsoft.azure::azure-documentdb)

    public ConnectionPolicy getConnectionPolicy() {
  ConnectionPolicy policy = new ConnectionPolicy();
  policy.setConnectionMode(ConnectionMode.DirectHttps);
  policy.setMaxPoolSize(1000);
  return policy;
}

ConnectionPolicy connectionPolicy = new ConnectionPolicy();
DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);

    Diagramma che mostra i criteri di connessione di Azure Cosmos DB.

  2. Collocare i client nella stessa area di Azure per ottenere prestazioni migliori

    Quando possibile, posizionare eventuali applicazioni che chiamano Azure Cosmos DB nella stessa area del database Azure Cosmos DB. Per un confronto approssimativo, le chiamate ad Azure Cosmos DB eseguite nella stessa area vengono completate entro 1-2 millisecondi, mentre la latenza tra la costa occidentale e quella orientale degli Stati Uniti è >50 millisecondi. Questa latenza può variare da richiesta a richiesta, in base alla route seguita dalla richiesta durante il passaggio dal client al limite del data center di Azure. È possibile ottenere la latenza più bassa possibile assicurandosi che l'applicazione chiamante si trovi nella stessa area di Azure in cui si trova l'endpoint con provisioning di Azure Cosmos DB. Per un elenco delle aree disponibili, vedere Aree di Azure.

    Il diagramma mostra le richieste e le risposte in due aree, in cui i computer si connettono a un account Azure Cosmos DB tramite servizi di livello intermedio.

Utilizzo dell'SDK

  1. Installare l'SDK più recente

    Agli SDK di Azure Cosmos DB vengono apportati continui miglioramenti per offrire prestazioni ottimali. Per determinare i miglioramenti più recenti di SDK, visitare Azure Cosmos DB SDK.

  2. Utilizzare un client Azure Cosmos DB singleton per l'intero ciclo di vita dell'applicazione

    Ogni istanza di DocumentClient è thread-safe ed esegue una gestione efficiente della connessione e la memorizzazione nella cache degli indirizzi quando si opera in modalità diretta. Per consentire una gestione efficiente delle connessioni e prestazioni migliori di DocumentClient, è consigliabile usare una singola istanza di DocumentClient per AppDomain per la durata dell'applicazione.

  3. Aumentare MaxPoolSize per host quando si usa la modalità gateway

    Le richieste di Azure Cosmos DB vengono effettuate tramite HTTPS/REST quando si usa la modalità gateway e sono soggette al limite di connessione predefinito per ogni nome host o indirizzo IP. Potrebbe essere necessario impostare MaxPoolSize su un valore superiore (200-1000) in modo che la libreria client possa usare più connessioni simultanee ad Azure Cosmos DB. In Azure Cosmos DB Sync Java SDK v2 il valore predefinito per ConnectionPolicy.getMaxPoolSize è 100. Usare setMaxPoolSize per modificare il valore.

  4. Ottimizzazione delle query parallele per le raccolte partizionate

    Azure Cosmos DB Sync Java SDK versione 1.9.0 e successive supportano query parallele, che consentono di eseguire query su una raccolta partizionata in parallelo. Per altre informazioni, vedere esempi di codice relativi all'uso degli SDK. Le query parallele sono progettate per migliorare la latenza delle query e la velocità effettiva rispetto alla controparte seriale.

    (a) Tuning setMaxDegreeOfParallelism: Le query parallele funzionano eseguendo interrogazioni su più partizioni in parallelo. Tuttavia, i dati di una singola raccolta partizionata vengono recuperati in modo seriale rispetto alla query. Usare quindi setMaxDegreeOfParallelism per impostare il numero di partizioni con la massima probabilità di ottenere la query più efficiente, purché tutte le altre condizioni di sistema rimangano invariate. Se non si conosce il numero di partizioni, è possibile usare setMaxDegreeOfParallelism per impostare un numero elevato e il sistema sceglie il valore minimo (numero di partizioni, input fornito dall'utente) come grado massimo di parallelismo.

    È importante notare che le query parallele producono i migliori vantaggi se i dati vengono distribuiti uniformemente in tutte le partizioni rispetto alla query. Se la raccolta partizionata viene partizionata in modo che tutti i dati o la maggior parte di essi restituiti da una query venga concentrata in poche partizioni (una partizione nel peggiore dei casi), le prestazioni della query verrebbero limitate da tali partizioni.

    (b) Tuning setMaxBufferedItemCount: La query parallela è progettata per preletturare i risultati mentre il batch corrente di risultati viene elaborato dal client. Il prefetch aiuta a migliorare complessivamente la latenza di una query. setMaxBufferedItemCount limita il numero di risultati prefetched. Impostando setMaxBufferedItemCount sul numero previsto di risultati restituiti (o un numero superiore), questa operazione consente alla query di ricevere il massimo vantaggio dalla prelettura.

    La prelettura funziona allo stesso modo indipendentemente da MaxDegreeOfParallelism e esiste un singolo buffer per i dati di tutte le partizioni.

  5. Implementare il backoff a intervalli getRetryAfterInMilliseconds

    Durante i test delle prestazioni, è consigliabile aumentare il carico fino a quando non viene limitata una frequenza ridotta di richieste. Se limitata, l'applicazione client deve ridurre la frequenza delle richieste durante l'intervallo di ripetizione specificato dal server. Il rispetto del backoff garantisce che si spenda una quantità minima di tempo in attesa tra tentativi. Il supporto dei criteri di ripetizione dei tentativi è incluso nella versione 1.8.0 e successive di Azure Cosmos DB Sync Java SDK. Per altre informazioni, vedere getRetryAfterInMilliseconds.

  6. Aumentare il carico di lavoro client

    Se si esegue il test a livelli di velocità di trasmissione elevati (>50.000 RU/s), l'applicazione client potrebbe diventare il collo di bottiglia a causa del limite del sistema sull'utilizzo della CPU o della rete. Se si arriva a questo punto, è possibile continuare a spingere l'account Azure Cosmos DB espandendo le applicazioni client su più server.

  7. Usare l'indirizzamento basato su nomi

    Usare l'indirizzamento basato sui nomi, in cui i collegamenti hanno il formato dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentId, anziché SelfLinks (_self), che hanno il formato dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> per evitare di recuperare i ResourceId di tutte le risorse usate per costruire il collegamento. Inoltre, poiché queste risorse vengono ricreate (possibilmente con lo stesso nome), la memorizzazione nella cache potrebbe non essere utile.

  8. Ottimizzare le dimensioni della pagina per query/feed di lettura per ottenere prestazioni migliori

    Quando si esegue una lettura bulk di documenti usando la funzionalità di lettura del feed (ad esempio readDocuments) o quando si esegue una query SQL, i risultati vengono restituiti in modo segmentato se il set di risultati è troppo grande. Per impostazione predefinita, i risultati vengono restituiti in blocchi di 100 elementi o 1 MB, a qualsiasi limite raggiunto per primo.

    Per ridurre il numero di viaggi di andata e ritorno della rete necessari per recuperare tutti i risultati applicabili, è possibile aumentare la dimensione della pagina utilizzando l'intestazione della richiesta x-ms-max-item-count a un massimo di 1000. Nei casi in cui è necessario visualizzare solo alcuni risultati, ad esempio se l'interfaccia utente o l'API dell'applicazione restituisce solo 10 risultati alla volta, è anche possibile ridurre le dimensioni della pagina a 10 per ridurre la velocità effettiva utilizzata per le letture e le query.

    È anche possibile impostare le dimensioni della pagina usando il metodo setPageSize.

Criteri di indicizzazione

  1. Escludere i percorsi non usati dall'indicizzazione per scritture più veloci

    I criteri di indicizzazione di Azure Cosmos DB consentono di specificare i percorsi dei documenti da includere o escludere dall'indicizzazione usando i percorsi di indicizzazione (setIncludedPaths e setExcludedPaths). L'uso dei percorsi di indicizzazione può consentire di ottenere prestazioni migliori e di ridurre le risorse di archiviazione dell'indice per gli scenari in cui i modelli di query sono noti in anticipo, poiché i costi dell'indicizzazione sono correlati direttamente al numero di percorsi univoci indicizzati. Ad esempio, il codice seguente mostra come escludere dall'indicizzazione un'intera sezione (sottoalbero) dei documenti utilizzando il carattere speciale "*".

    Sync Java SDK V2 (Maven com.microsoft.azure::azure-documentdb)

    Index numberIndex = Index.Range(DataType.Number);
numberIndex.set("precision", -1);
indexes.add(numberIndex);
includedPath.setIndexes(indexes);
includedPaths.add(includedPath);
indexingPolicy.setIncludedPaths(includedPaths);
collectionDefinition.setIndexingPolicy(indexingPolicy);

    Per altre informazioni, vedere l'articolo relativo ai criteri di indicizzazione di Azure Cosmos DB.

Capacità di produzione

  1. Misurare e ottimizzare per ottenere un utilizzo minore di unità richiesta al secondo

    Azure Cosmos DB offre un'ampia gamma di operazioni di database, incluse query relazionali e gerarchiche USD, stored procedure e trigger, operative nei documenti all'interno di una raccolta di database. Il costo associato a ognuna di queste operazioni dipende da CPU, I/O e memoria necessari per il completamento dell'operazione. Invece di occuparsi della pianificazione e della gestione delle risorse hardware, sarà possibile usare un'unità di richiesta come misura singola per le risorse necessarie per eseguire diverse operazioni di database e rispondere a una richiesta dell'applicazione.

    Viene eseguito il provisioning della velocità effettiva in base al numero di unità richiesta impostato per ogni contenitore. Il consumo delle unità di richiesta è valutato in base alla frequenza al secondo. Le applicazioni che superano il tasso di unità di richiesta fornito per il contenitore vengono limitate fino a quando il tasso non scende al di sotto del livello previsto per il contenitore. Se l'applicazione necessita di un livello superiore di velocità effettiva, sarà possibile aumentare la velocità effettiva eseguendo il provisioning di unità di richiesta aggiuntive.

    La complessità di una query influisce sulla quantità di unità richiesta usate per un'operazione. Il numero di predicati, la natura dei predicati, il numero di funzioni definite dall'utente e le dimensioni del set di dati di origine sono tutti fattori che incidono sul costo delle operazioni di query.

    Per misurare il sovraccarico di qualsiasi operazione (creazione, aggiornamento o eliminazione), esaminare l'intestazione x-ms-request-charge (o la proprietà RequestCharge equivalente in ResourceResponse<T> o FeedResponse<T> per misurare il numero di unità richiesta utilizzate da queste operazioni.

    Sync Java SDK V2 (Maven com.microsoft.azure::azure-documentdb)

    ResourceResponse<Document> response = client.createDocument(collectionLink, documentDefinition, null, false);

response.getRequestCharge();

    L'addebito richiesta restituito in questa intestazione è una frazione della velocità effettiva con provisioning. Ad esempio, se è stato effettuato il provisioning di 2000 UR/sec e se la query precedente restituisce 1.000 documenti da 1 KB, il costo dell'operazione è 1000. Entro un secondo, il server rispetterà quindi solo due richieste di questo tipo prima di limitare la velocità delle richieste successive. Per altre informazioni, vedere Unità richiesta e il calcolatore di unità richiesta.

  2. Gestire la limitazione della frequenza o una frequenza di richieste troppo elevata

    Quando un client prova a superare la velocità effettiva riservata per un account, non si verifica alcun calo delle prestazioni del server e l'uso della capacità della velocità effettiva non supera il livello riservato. Il server termina preventivamente la richiesta con RequestRateTooLarge (codice di stato HTTP 429) e restituisce l'intestazione x-ms-retry-after-ms, che indica la quantità di tempo, in millisecondi, che l'utente deve attendere prima di eseguire di nuovo la richiesta.

        HTTP Status 429,
    Status Line: RequestRateTooLarge
    x-ms-retry-after-ms :100

    Tutti gli SDK intercettano implicitamente questa risposta, rispettano l'intestazione retry-after specificata dal server e ripetono la richiesta. A meno che all'account non accedano contemporaneamente più client, il tentativo successivo riuscirà.

    Se si dispone di più client che operano in modo cumulativo in modo coerente al di sopra della frequenza delle richieste, il numero di tentativi predefinito attualmente impostato su 9 internamente dal client potrebbe non essere sufficiente; in questo caso, il client genera un'eccezione DocumentClientException con codice di stato 429 all'applicazione. Il numero di tentativi predefinito può essere modificato usando setRetryOptions nell'istanza ConnectionPolicy . Per impostazione predefinita, l'eccezione DocumentClientException con codice di stato 429 viene restituita dopo un tempo di attesa cumulativo di 30 secondi se la richiesta continua a funzionare al di sopra della frequenza di richiesta. Ciò si verifica anche quando il numero di ripetizioni dei tentativi corrente è inferiore al numero massimo di tentativi, indipendentemente dal fatto che si tratti del valore predefinito 9 o di un valore definito dall'utente.

    Benché il comportamento automatizzato per la ripetizione dei tentativi consenta di migliorare la resilienza e l'usabilità per la maggior parte delle applicazioni, è possibile che provochi conflitti durante l'esecuzione dei benchmark delle prestazioni, in particolare durante la misurazione della latenza. La latenza osservata dal client presenterà dei picchi se l'esperimento raggiunge il limite del server e fa in modo che l'SDK client ripeta automaticamente i tentativi. Per evitare i picchi di latenza durante gli esperimenti relativi alle prestazioni, misurare l'addebito restituito da ogni operazione e assicurarsi che le richieste operino al di sotto della frequenza delle richieste riservata. Per altre informazioni, vedere Unità richiesta.

  3. Progettare documenti di dimensioni minori per ottenere una velocità effettiva maggiore

    L'addebito per le richieste, ovvero il costo di elaborazione delle richieste, per un'operazione specifica è correlato direttamente alle dimensioni del documento. Le operazioni sui documenti di grandi dimensioni sono più costose rispetto alle operazioni per i documenti di piccole dimensioni.

Passaggi successivi

Per altre informazioni sulla progettazione dell'applicazione per scalabilità e prestazioni elevate, vedere l'articolo relativo a partizionamento e ridimensionamento in Azure Cosmos DB.

  • Last updated on