Dimensionamento del cluster DAX

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

La capacità e la disponibilità totali di un cluster DAX dipendono dal tipo e dal numero di nodi. Un numero maggiore di nodi nel cluster ne aumenta la capacità di lettura, ma non la capacità di scrittura. I tipi di nodi più grandi (fino a r5.8xlarge) possono gestire più scritture, ma un numero troppo basso di nodi può influire sulla disponibilità in caso di errore del nodo. Per ulteriori informazioni sul dimensionamento del cluster DAX, vedere. Guida alle dimensioni del cluster DAX

Nelle sezioni seguenti vengono descritti i diversi aspetti di dimensionamento da prendere in considerazione per bilanciare il tipo di nodo e il numero di nodi per la creazione di un cluster scalabile ed economico.

Pianificazione della disponibilità

Quando si dimensiona un cluster DAX, è necessario innanzitutto concentrarsi sulla sua disponibilità mirata. La disponibilità di un servizio in cluster, ad esempio DAX, è una dimensione del numero totale di nodi del cluster. Poiché un cluster a nodo singolo non ha alcuna tolleranza agli errori, la sua disponibilità è pari a un nodo. In un cluster a 10 nodi, la perdita di un singolo nodo ha un impatto minimo sulla capacità complessiva del cluster. Questa perdita non ha un impatto diretto sulla disponibilità perché i nodi rimanenti possono ancora soddisfare le richieste di lettura. Per riprendere le scritture, DAX nomina rapidamente un nuovo nodo primario.

DAX è basato su VPC. Utilizza un gruppo di sottoreti per determinare in quali zone di disponibilità può eseguire i nodi e quali indirizzi IP utilizzare dalle sottoreti. Per i carichi di lavoro di produzione, consigliamo vivamente di utilizzare DAX con almeno tre nodi in zone di disponibilità diverse. Ciò garantisce che al cluster rimanga più di un nodo per gestire le richieste anche in caso di guasto di un singolo nodo o di una zona di disponibilità. Un cluster può avere fino a 11 nodi, di cui uno è un nodo primario e 10 sono repliche di lettura.

Pianificazione del throughput di scrittura

Tutti i cluster DAX dispongono di un nodo primario per le richieste di scrittura. La dimensione del tipo di nodo per il cluster determina la sua capacità di scrittura. L'aggiunta di repliche di lettura aggiuntive non aumenta la capacità di scrittura del cluster. Pertanto, è necessario considerare la capacità di scrittura durante la creazione del cluster perché non è possibile modificare il tipo di nodo in un secondo momento.

Se l'applicazione deve eseguire la scrittura tramite DAX per aggiornare la cache degli elementi, prendete in considerazione un maggiore utilizzo delle risorse del cluster per facilitare la scrittura. Le scritture su DAX consumano circa 25 volte più risorse rispetto alle letture generate dalla cache. Ciò potrebbe richiedere un tipo di nodo più grande rispetto ai cluster di sola lettura.

Per ulteriori indicazioni su come determinare se la scrittura tramite scrittura o scrittura sia la soluzione migliore per l'applicazione in uso, consulta. Strategie di scrittura

Pianificazione, velocità di lettura

La capacità di lettura di un cluster DAX dipende dal rapporto di accesso alla cache del carico di lavoro. Poiché DAX legge i dati da DynamoDB quando si verifica un errore nella cache, consuma circa 10 volte più risorse del cluster rispetto a un problema di cache. Per aumentare gli accessi alla cache, aumenta l'impostazione TTL della cache per definire il periodo per il quale un elemento viene archiviato nella cache. Una durata TTL più elevata, tuttavia, aumenta la possibilità di leggere versioni precedenti degli elementi, a meno che gli aggiornamenti non vengano scritti tramite DAX.

Per assicurarti che il cluster abbia una capacità di lettura sufficiente, ridimensiona il cluster orizzontalmente come indicato in. Ridimensionamento orizzontale di un cluster L'aggiunta di altri nodi aggiunge repliche di lettura al pool di risorse, mentre la rimozione dei nodi riduce la capacità di lettura. Quando selezioni il numero di nodi e le relative dimensioni per un cluster, considera sia la quantità minima che quella massima di capacità di lettura necessaria. Se non riesci a scalare orizzontalmente un cluster con tipi di nodi più piccoli per soddisfare i requisiti di lettura, utilizza un tipo di nodo più grande.

Pianificazione delle dimensioni del set di dati

Ogni tipo di nodo disponibile ha una dimensione di memoria impostata per consentire a DAX di memorizzare i dati nella cache. Se un tipo di nodo è troppo piccolo, il set di dati di lavoro richiesto da un'applicazione non entrerà in memoria e si verificheranno errori nella cache. Poiché i nodi più grandi supportano cache più grandi, utilizzate un tipo di nodo più grande del set di dati stimato da inserire nella cache. Una cache più grande migliora anche il rapporto di accessi alla cache.

Potresti ottenere rendimenti decrescenti per gli elementi memorizzati nella cache con poche letture ripetute. Calcola la dimensione della memoria per gli elementi a cui si accede di frequente e assicurati che la cache sia sufficientemente grande da memorizzare quel set di dati.

Calcolo dei requisiti approssimativi di capacità del cluster

Puoi stimare le esigenze di capacità totale del tuo carico di lavoro per aiutarti a selezionare la dimensione e la quantità appropriate di nodi del cluster. Per eseguire questa stima, calcola la variabile normalizzata richiesta al secondo (RPS normalizzato). Questa variabile rappresenta le unità di lavoro totali che l'applicazione richiede al cluster DAX per supportare, inclusi accessi alla cache, errori di cache e scritture. Per calcolare l'RPS normalizzato, utilizzate i seguenti input:

Utilizzando la formula seguente, è possibile calcolare l'RPS normalizzato.

Normalized RPS = (ReadRPS_CacheHit * Size) + (ReadRPS_CacheMiss * Size * 10x_ReadMissFactor) + (WriteRequestRate * 25x_WriteFactor * Size * DaxNodeCount)

Ad esempio, considera i seguenti valori di input:

Sostituendo questi valori nella formula, è possibile calcolare l'RPS normalizzato come segue.

Normalized RPS = (50,000 Cache Hits/Sec * 2KB) + (1,000 Cache Misses/Sec * 2KB * 10) + (100 Writes/Sec * 25 * 2KB * 3)

In questo esempio, il valore calcolato di RPS normalizzato è 135.000. Tuttavia, questo valore RPS normalizzato non tiene conto del mantenimento dell'utilizzo del cluster al di sotto del 100% o della perdita di nodi. Si consiglia di tenere conto della capacità aggiuntiva. A tale scopo, determina il maggiore dei due fattori di moltiplicazione: l'utilizzo del target o la tolleranza alla perdita dei nodi. Quindi, moltiplica l'RPS normalizzato per il fattore maggiore per ottenere una richiesta target al secondo (Target RPS).

Utilizzando la formula seguente, è possibile calcolare l'RPS di destinazione.

Target RPS = Normalized RPS * CEILING(TargetUtilization, NodeLossTolerance)

Ad esempio, per calcolare Target RPS, considera i seguenti valori:

Sostituendo questi valori nella formula, puoi calcolare il Target RPS come segue.

Target RPS = 135,000 * CEILING(1.43, 1.5)

In questo esempio, poiché il valore di NodeLossTolerance è maggiore diTargetUtilization, calcoliamo il valore di Target RPS con. NodeLossTolerance Questo ci dà un Target RPS di 202.500, che è la quantità totale di capacità che il cluster DAX deve supportare. Per determinare il numero di nodi necessari in un cluster, mappa Target RPS su una colonna appropriata nella tabella seguente. Per questo esempio di Target RPS di 202.500, è necessario il tipo di nodo dax.r5.large con tre nodi.

Approssimazione della capacità di throughput del cluster per tipo di nodo

UtilizzandoTarget RPS formula, è possibile stimare la capacità del cluster per diversi tipi di nodi. La tabella seguente mostra le capacità approssimative per i cluster con 1, 3, 5 e 11 tipi di nodi. Queste capacità non sostituiscono la necessità di eseguire test di carico di DAX con modelli di dati e richieste personalizzati. Inoltre, queste capacità non includono le istanze di tipo t a causa della mancanza di capacità fissa della CPU. L'unità per tutti i valori nella tabella seguente è l'RPS normalizzato.

A causa del limite massimo di 1 milione di NPS (operazioni di rete al secondo) per ogni nodo, i nodi di tipo dax.r5.8xlarge o superiore non forniscono capacità aggiuntiva del cluster. I tipi di nodi più grandi di 8xlarge potrebbero non contribuire alla capacità di throughput totale del cluster. Tuttavia, questi tipi di nodi possono essere utili per archiviare in memoria un set di dati di lavoro più ampio.

Scalabilità della capacità di scrittura nei cluster DAX

Ogni scrittura su DAX consuma 25 richieste normalizzate su ogni nodo. Poiché esiste un limite di 1 milione di RPS per ogni nodo, un cluster DAX è limitato a 40.000 scritture al secondo, senza contare l'utilizzo di lettura.

Se il tuo caso d'uso richiede più di 40.000 scritture al secondo nella cache, devi utilizzare cluster DAX separati e suddividere le scritture tra di essi. Analogamente a DynamoDB, puoi eseguire l'hash della chiave di partizione per i dati che stai scrivendo nella cache. Quindi, usa modulus per determinare su quale shard scrivere i dati.

L'esempio seguente calcola l'hash di una stringa di input. Quindi calcola il modulo del valore hash con 10.

def hash_modulo(input_string):
    # Compute the hash of the input string
    hash_value = hash(input_string)

    # Compute the modulus of the hash value with 10
    bucket_number = hash_value % 10

    return bucket_number

#Example usage
if _name_ == "_main_":
    input_string = input("Enter a string: ")
    result = hash_modulo(input_string)
    print(f"The hash modulo 10 of '{input_string}' is: {result}.")