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à.

Dimensionamento del cluster DAX

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, consulta 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 necessari per la creazione di un cluster scalabile e conveniente.

Disponibilità di pianificazione

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, si consiglia vivamente di utilizzare DAX con almeno tre nodi in diverse zone di disponibilità. Ciò garantisce che al cluster rimanga più di un nodo per gestire le richieste anche in caso di errore 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 write-through. 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 una scrittura di tipo write-though tramite DAX per aggiornare la cache degli elementi, prendi 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 con riscontro nella 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 di tipo write-thorugh o quella di tipo write-around sia la soluzione migliore per l’applicazione in uso, consulta Strategie di scrittura.

Pianificazione del throughput di lettura

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

Per assicurarti che il cluster abbia una capacità di lettura sufficiente, dimensiona il cluster orizzontalmente come indicato in Dimensionamento 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. Nella selezione del numero di nodi e delle relative dimensioni per un cluster, considera sia la quantità minima che quella massima di capacità di lettura necessaria. Se non riesci a dimensionare 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 archiviare 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 mancati riscontri nella cache. Poiché i nodi più grandi supportano cache più grandi, utilizza un tipo di nodo più grande del set di dati stimato da inserire nella cache. Una cache più grande migliora anche il tasso di riscontri nella cache.

Potrebbe essere possibile ottenere rendimenti decrescenti per il caching di elementi con poche letture ripetute. Calcola la dimensione della memoria per gli elementi con accesso frequente e assicurati che la cache sia sufficientemente grande per l’archiviazione di quel set di dati.

Calcolo dei requisiti approssimativi di capacità del cluster

È possibile stimare le esigenze di capacità totale di un carico di lavoro per aiutare a selezionare la dimensione e la quantità appropriate di nodi del cluster. Per eseguire questa stima, calcola la variabile richiesta al secondo normalizzata (RPS normalizzata). Questa variabile rappresenta le unità di lavoro totali che l’applicazione richiede al cluster DAX per supportare, inclusi riscontri nella cache, mancati riscontri nella cache e scritture. Per calcolare l’RPS normalizzata, utilizza i seguenti input:

Con la seguente formula è possibile calcolare l’RPS normalizzata.

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

Si considerino, ad esempio, i seguenti valori di input:

Sostituendo questi valori nella formula, è possibile calcolare l’RPS normalizzata 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 dell’RPS normalizzata è 135.000. Tuttavia, questo valore dell’RPS normalizzata non tiene conto del mantenimento dell’utilizzo del cluster al di sotto del 100% o della perdita di nodi. È consigliabile considerare la capacità aggiuntiva. A tale scopo, determina il maggiore dei due fattori di moltiplicazione: l’utilizzo di destinazione o la tolleranza alla perdita dei nodi. Quindi, moltiplica l’RPS normalizzata per il fattore maggiore per ottenere una richiesta di destinazione al secondo (RPS di destinazione).

Con la seguente formula è possibile calcolare l’RPS di destinazione.

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

Ad esempio, per calcolare l’RPS di destinazione, si considerino i seguenti valori:

Sostituendo questi valori nella formula, è possibile calcolare l’RPS di destinazione come segue.

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

In questo esempio, poiché il valore di NodeLossTolerance è maggiore di TargetUtilization, il valore di RPS di destinazione viene calcolato con NodeLossTolerance. Questo restituisce una RPS di destinazione 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 l’RPS di destinazione su una colonna appropriata nella tabella seguente. Per questo esempio di RPS di destinazione di 202.500, è necessario il tipo di nodo dax.r5.large con tre nodi.

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

Utilizzando Target 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à della CPU fissa. L’unità per tutti i valori nella tabella seguente è RPS normalizzata.

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 al 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.

Dimensionamento 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 caso d’uso richiede più di 40.000 scritture al secondo nella cache, è necessario utilizzare cluster DAX separati e sottoporre a sharding le scritture tra di essi. Analogamente a DynamoDB, è possibile eseguire l’hash della chiave di partizione per i dati che si stanno scrivendo nella cache. Quindi, viene utilizzato il modulo 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}.")