Apache Cassandra: Writing Performance

Come accennato nel paragrafo precedente, le API dei driver utilizzati mettono a dispo- sizione una serie di opzioni, parametri per poter personalizzare le performance di scrittura per poter sfruttare al meglio l’architettura installata. Studiando meglio questi parametri,si è visto che 3 sono associati alle performance delle operazioni di scrittura, per cui sono stati fatti una serie di test per valutare quale fosse la combinazione migliore; per combinazione migliore, si intende la combinazione dei due parametri che garantisce stabilità nel cluster e il miglior rapporto di operazioni al secondo. Queste sono state calcolate mettendo in rapporto il numero di elementi da scrivere nel database con il tempo impegato dal metodo per effettuare queste operazioni; in generale, la dimensione dei singoli

I tre parametri in questione sono:

• spark.cassandra.output.batch.size.bytes: Maximum total size of the batch in bytes; default 1024 bytes

• spark.cassandra.output.concurrent.writes: Maximum number of batches executed in parallel by a single Spark task; default 5

Nei prossimi 2 paragrafi verranno presentati i test effettuati, prima in locale, poi sul cluster di test, sui tre parametri. L’obiettivo è trovare la combinazione che garantisce le performance migliori, mantenendo il sistema stabile e vedere come queste cambiano a seconda dell’architettura utilizzata.

Batch Size

Il parametro spark.cassandra.output.batch.size.bytes va a definire la grandezza in bytes del blocco da scrivere su cassandra. Come valore di default ha 1024 bytes, per cui l’obiettivo di questo test è vedere se all’aumentare della dimensione del blocco, il numero di operazioni di scrittura al secondo (OpW/s) aumentano o diminuiscono.

Il test è stato eseguito prima in locale e poi sul cluster, testando le operazioni di caricamento di un certo numero di file, con dimensioni differenti, per tutti e tre le tipologie di flusso. Ad ogni iterazione il parametro è stato incrementato di una potenza di 2, in modo da poter analizzare anche blocchi di dimensione molto più grande con poche iterazioni. Per quanto riguarda gli altri due parametri, invece, sono stati mantenuti i valori di default.

Fig. 4.1 Rate di operazioni di scrittura al secondo all’aumentare della grandezza del batch; ogni serie colorata corrisponde ad un file

Il grafico in 4.1 mostra l’andamento del numero di operazioni di scrittura in relazione alla dimensione del blocco, in locale considerando una decina di file di dimensioni differenti. La dimensione del blocco è stata incrementata di una potenza di due a partire 20 fino a 214;il valore di default coincide con 210. Dal grafico si evince la relazione tra OpW/s e la dimensione del batch: all’aumentare della grandezza del batch aumentano velocemente, fino ad iniziare a stabilizzarsi. Il rate di OpW/s raggiunto dal parametro di default varia tra 4mila e 30mila operazioni, mentre quello raggiunto con il valore scelto come ottimale (213) varia tre 6mila e 42mila OpW/s. Per cui, aumentare questo parametro porta ad effettuare un numero più elevato di OpW/s, fino ad un limite che è dato dall’architettura del sistema. Un’osservazione interessante è l’andamento con cui migliorano le performance per ogni file è lo stesso; quindi le performance di scrittura sono migliori per i file più grandi, ma all’aumentare del batch size migliorano tutte allo stesso modo.

Fig. 4.2 Tempo di processamento all’aumentare della grandezza del batch

Ad ulteriore conferma di quanto appena detto, il grafico sottostante 4.2 mostra l’andamento dei tempi di scrittura in relazione alla grandezza del batch; all’aumentare di quest’ultimo i tempi di scrittura diminuiscono molto velocemente fino a stabilizzarsi. I tempi, da un range iniziale di 0-180 secondi, arrivano ad un range di 0-100 secondi con il valore di default 1024. Progredendo lungo il grafico i tempi continuano a migliorare, fino a raggiungere il valore ottimale a 213, nel range di 0-45 secondi.

Dati questi due test, il valore ottimale della grandezza del batch per le esecuzioni in locale è 213bytes, cioè 8192 bytes.

Questo test è stato effettuato anche sul cluster di test per trovare quale parametro sia ottimale per quell’ambiente, ma soprattutto per valutare quanto l’esecuzione su un cluster sia più performante di una in locale. Il test è stato fatto solamente su due file, quello più pesante e uno medie dimensioni, poichè si è già visto come il miglioramento delle performance sia simile per tutti i file.

Fig. 4.3 Rate di operazioni di scrittura al secondo all’aumentare della grandezza del batch nel cluster di test

Dal grafico 4.3 si vede subito come il numero delle OpW/s sia nettamente superiore all’esecuzione in locale; prima si era raggiunto un limite massimo di 42-43 mila OpW/s, mentre qua si superano leggermente le 90mila OpW/s. Rispetto al valore di default 1024 bytes, con cui si raggiungono circa le 40mila OpW/s, con il valore massimo queste raddoppiano. Inoltre, il grafico sottostante mostra i tempi di scrittura in relazione alla grandezza del batch.

Fig. 4.4 Tempo di processamento all’aumentare della grandezza del batch nel cluster di test Come per quanto è accaduto in locale, all’aumentare del batch i tempi diminuiscono molto velocemente fino a stabilizzarsi, a partire da un range di 0-150 secondi, fino a raggiungere 0-50 secondi con il valore di default e 0-25 con 214.

Quindi, le performance migliori sull’ambiente di test sono state ottenute con 214 come dimensione del batch, ma è stato scelto come parametro ottimale 213, cioè 8142 per evitare di spingere al limite il cluster.

Concurrent Writes

Un altro parametro che va ad incidere sulle performance di scrittura è il spark.cassandra.output.concurrent.writes che indica il numero massimo di blocchi scritti in parallelo da un task Spark; di default

questo valore è 5.

Anche per questo parametro sono stati fatti dei test per valutare quanto le performance miglio- rano o peggiorano all’aumentare di questo valore. Come per il test precedente, le prime prove sono state fatte in locale, incrementando tale valore di una potenza di 2 e mantenendo per gli altri due parametri quelli di default.

Il grafico 4.5 sottostante mostra l’andamento delle OpW/s all’aumentare del parametro. A differenza di prima, le curve associate ai diversi file si stabilizzano molto velocemente tutte attorno al valore 23 =8; il limite massimo raggiunto è di circa 33mila OpW/s, contro le 29mila OpW/s ottenute con il valore di default.

Fig. 4.5 Rate di operazioni di scrittura al secondo all’aumentare della grandezza delle concurrent writes

Osservando anche il grafico 4.6 che mette in relazione i tempi con i valori del parametro in questione, vediamo come i tempi diminuiscono in maniera esponenziale e si stabilizzano anche qua attorno a 8 come valore del parametro.

Fig. 4.6 Tempo di processamento all’aumentare delle concurrent writes nel cluster di test Il range iniziale dei tempi, oscilla tra i 0-280 secondi, con il valore di default tra 0-90 secondi, fino a stabilizzarsi attorno al 0-70 secondi. Per cui il valore ottimale è 23, cioè 8.

Analogamente è stato testato anche sul cluster, e i due grafici sottostanti mostrano gli an- damenti in relazione, il primo 4.7, alle OpW/s, mentre il secondo 4.8 al tempo di esecuzione.

Fig. 4.7 Rate di operazioni di scrittura al secondo all’aumentare della grandezza delle concurrent writes nel cluster di test

Fig. 4.8 Tempo di processamento all’aumentare delle concurrent writes nel cluster di test Come ci si aspettava, anche in questo caso le curve tendono a stabilizzarsi molto in fretta, nel range tra 16 e 32 come valore per il numero di concurrent write. Rispetto all’esecuzione in locale, si può notare come il numero di OpW/s è raddoppiato e, di conseguenza, i tempi di esecuzione si sono dimezzati.

Uploading Data Performance

Una volta finiti i test descritti, e definiti quali fossero i parametri ottimali per l’ambiente di cluster, si è eseguito lo script per effettuare l’ingestion dei dati su cassandra considerando circa 400 file salvati in una opportuna cartella su HDFS.

Prima di procedere con l’upload dei 400 file, si è testato quanto la combinazione dei due parametri ottimali fosse più performante sull’ambiente di test; per questa verifica sono stati utilizzati solamente 5 file, facendo più iterazioni.

Fig. 4.9 Confronto tra le performance di scrittura coi parametri ottimali e quelli di default Il grafico 4.9 mostra, quanto effettivamente le performance con i parametri trovati siano nettamente migliori rispetto a quelli di default. Per cui, per l’ingestion dei dati contenuti nei 400 file verranno utilizzati i parametri con i valori ottimali.

Durante l’inserimento sono state monitorate le performance dell’algoritmo, e adesso verranno descritti una serie di grafici legati alle performance delle operazioni di scrittura.

Fig. 4.10 Range delle performance di scrittura

Il grafico 4.10, mostra il range delle OpW/s ottenute impostando i parametri ottimali trovati coi test. Si può vedere come il range oscilli tra le 70mila e le 120mila OpW/s, con la maggior parte dei file caricati con una velocità di 90-105mila OpW/s.

Tuttavia, la velocità di elaborazione dello script non dipende solo dalle OpW/s, ma anche dalla grandezza dei file da processare. Il grafico 4.11 mostra la velocità con cui i dati vengono processati, mettendo in relazione la dimensione del file e il tempo di esecuzione del job spark.

Fig. 4.12 Velocità di scrittura dei file

Come si può vedere, la velocità è pressoché costante. Il grafico 4.12, descrive ancora meglio questa considerazione: tutti i file, a prescindere dalla loro dimensione, vengono processati con una velocità che nel caso peggiore è attorno a 0,3 Gb/min, mentre nel caso migliore di poco superiore a 0,7 Gb/min.