{"id":81936,"date":"2020-05-18T01:42:37","date_gmt":"2020-05-17T23:42:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera"},"modified":"2020-05-18T01:42:37","modified_gmt":"2020-05-17T23:42:37","slug":"szhatie-dannyh-v-apache-ignite-opyt-sbera","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","title":{"rendered":"Compressione dei dati in Apache Ignite. Esperienza di Sber.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Compressione dei dati in Apache Ignite. Esperienza di Sber.\" src=\"\/wp-content\/uploads\/2020\/05\/0e26c686b1f29e88e6be4b8df81ab668.jpg\" style=\"display:block;margin: 0 auto;\" \/>Quando si lavora con grandi volumi di dati, pu\u00f2 sorgere acutamente il problema della mancanza di spazio sui dischi. Uno dei modi per risolvere questo problema \u00e8 la compressione, grazie alla quale, con la stessa attrezzatura, \u00e8 possibile aumentare i volumi di archiviazione. In questo articolo esamineremo come funziona la compressione dei dati in Apache Ignite. L'articolo descriver\u00e0 solo i metodi di compressione implementati all'interno del prodotto. Altri metodi di compressione dei dati (su rete, in memoria), sia implementati che non, rimarranno fuori dal campo d'azione.<\/p>\n<p>Quindi, con la modalit\u00e0 di persistenza attivata, a seguito delle modifiche ai dati nelle cache, Ignite inizia a scrivere su disco:<\/p>\n<ol>\n<li>Il contenuto delle cache<\/li>\n<li>Il registro di scrittura anticipata (Write Ahead Log, di seguito semplicemente WAL)<\/li>\n<\/ol>\n<p>\nDa tempo esiste un meccanismo per la compressione del WAL, chiamato WAL compaction. Nella recente versione di Apache Ignite 2.8 sono stati introdotti altri due meccanismi che consentono di comprimere i dati su disco, ovvero la compressione delle pagine disco per comprimere il contenuto delle cache e la compressione delle snapshot delle pagine WAL per comprimere alcune voci del WAL. Maggiori dettagli su questi tre meccanismi di seguito.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Compressione delle pagine disco<\/h3>\n<p><\/p>\n<h4>Come funziona<\/h4>\n<p>\nIniziamo brevemente a esaminare come Ignite memorizza i dati. Viene utilizzata la memoria a pagine. La dimensione della pagina \u00e8 impostata all'avvio del nodo e non pu\u00f2 essere modificata in fasi successive; inoltre, la dimensione della pagina deve essere una potenza di due e multipla della dimensione del blocco del file system. Le pagine vengono caricate in RAM dal disco secondo le necessit\u00e0; la dimensione dei dati su disco pu\u00f2 superare l'ammontare di RAM dedicata. In caso di mancanza di spazio in RAM per caricare una pagina dal disco, le vecchie pagine gi\u00e0 non utilizzate verranno espulse dalla RAM.<\/p>\n<p>Su disco, i dati sono memorizzati nel seguente modo: per ogni partizione di ciascun gruppo di cache viene creato un file separato, in questo file, in ordine crescente di indice, si trovano una dopo l'altra le pagine. L'identificatore completo della pagina contiene l'identificatore del gruppo di cache, il numero di partizione e l'indice della pagina nel file. In questo modo, attraverso l'identificatore completo della pagina, possiamo determinare in modo univoco il file e l'offset nel file per ogni pagina. Maggiori dettagli sulla struttura della memoria a pagine possono essere trovati nell'articolo sulla Wiki di Apache Ignite: <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/IGNITE\/Ignite+Persistent+Store+-+under+the+hood\">Ignite Persistent Store - sotto il cofano<\/a><\/noindex>.<\/p>\n<p>Il meccanismo di compressione delle pagine disk, come suggerisce il nome, funziona a livello di pagina. Quando questo meccanismo \u00e8 attivato, il lavoro con i dati nella RAM avviene senza alcuna compressione, ma al momento del salvataggio delle pagine dalla RAM su disco, viene eseguita la loro compressione.<\/p>\n<p>Tuttavia, comprimere ogni pagina singolarmente non risolve il problema, \u00e8 necessario in qualche modo ridurre le dimensioni dei file finali con i dati. Se la dimensione della pagina smette di essere fissa, non possiamo pi\u00f9 scrivere pagine nel file una dopo l'altra, poich\u00e9 questo potrebbe generare una serie di problemi:<\/p>\n<ul>\n<li>Non saremo in grado di calcolare l'offset della pagina utilizzando l'indice della pagina stessa.<\/li>\n<li>Non \u00e8 chiaro come gestire le pagine che non si trovano alla fine del file e che cambiano le loro dimensioni. Se la dimensione della pagina diminuisce, lo spazio liberato si perde. Se la dimensione della pagina aumenta, \u00e8 necessario cercare un nuovo spazio nel file per essa.<\/li>\n<li>Se la pagina si sposta di un numero di byte che non \u00e8 un multiplo della dimensione del blocco del file system, la lettura o la scrittura richieder\u00e0 di toccare un blocco del file system in pi\u00f9, il che potrebbe portare a una degradazione delle prestazioni.<\/li>\n<\/ul>\n<p>\nPer evitare di affrontare questi problemi a livello locale, la compressione delle pagine disk in Apache Ignite utilizza un meccanismo del file system chiamato file sparse. Un file sparse \u00e8 un file in cui alcune aree riempite di zeri possono essere contrassegnate come \"buchi\". A tal fine, non verranno allocati blocchi del file system per memorizzare questi buchi, il che comporta un risparmio di spazio su disco.<\/p>\n<p>\u00c8 logico che, per liberare un blocco del file system, la dimensione del buco deve essere maggiore o uguale a quella del blocco del file system, il che impone un ulteriore vincolo sulla dimensione della pagina in Apache Ignite: affinch\u00e9 la compressione abbia un effetto, la dimensione della pagina deve essere strettamente maggiore della dimensione del blocco del file system. Se la dimensione della pagina \u00e8 uguale a quella del blocco, non saremo mai in grado di liberare un blocco, poich\u00e9 per liberare un singolo blocco \u00e8 necessario che la pagina compressa occupi 0 byte. Se la dimensione della pagina \u00e8 uguale a quella di 2 o 4 blocchi, potremo liberare almeno un blocco se la nostra pagina si comprime di almeno il 50% o il 75% rispettivamente.<\/p>\n<p>Pertanto, la descrizione finale del funzionamento del meccanismo \u00e8 la seguente: quando una pagina viene scritta su disco, si tenta di comprimere la pagina. Se la dimensione della pagina compressa consente di liberare uno o pi\u00f9 blocchi del file system, la pagina viene scritta in formato compresso, lasciando un \"buco\" (viene effettuata una chiamata di sistema con flag \"punch hole\"). Se la dimensione della pagina compressa non consente di liberare blocchi, la pagina viene salvata cos\u00ec com'\u00e8, in formato non compresso. Tutti gli offset delle pagine vengono calcolati come senza compressione, moltiplicando l'indice della pagina per la dimensione della pagina. Non \u00e8 necessaria alcuna rilocazione manuale delle pagine. Gli offset delle pagine, come senza compressione, si trovano sui confini dei blocchi del file system. <code>fallocate()<\/code> con il flag \"punch hole\"). Se la dimensione della pagina compressa non consente di liberare blocchi, la pagina viene salvata cos\u00ec com'\u00e8, in formato non compresso. Tutti gli offset delle pagine vengono calcolati come senza compressione, moltiplicando l'indice della pagina per la dimensione della pagina. Non \u00e8 necessaria alcuna rilocazione manuale delle pagine. Gli offset delle pagine, come senza compressione, si trovano sui confini dei blocchi del file system.<\/p>\n<p><img decoding=\"async\" alt=\"Compressione dei dati in Apache Ignite. Esperienza di Sber.\" src=\"\/wp-content\/uploads\/2020\/05\/6a6c6ad83d3b8591f76b9343ff067746.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <br \/>\nNell'attuale implementazione, Ignite \u00e8 in grado di lavorare con file sparsi solo su sistemi operativi Linux; di conseguenza, la compressione delle pagine su disco pu\u00f2 essere attivata solo utilizzando Ignite su questo sistema operativo.<\/p>\n<p>Gli algoritmi di compressione che possono essere utilizzati per la compressione delle pagine su disco sono: ZSTD, LZ4, Snappy. Inoltre, esiste una modalit\u00e0 operativa (SKIP_GARBAGE), in cui viene semplicemente scartato lo spazio non utilizzato nella pagina senza applicare compressione ai dati rimanenti, il che consente di ridurre il carico sulla CPU rispetto agli algoritmi elencati in precedenza.<\/p>\n<h4>Impatto sulle prestazioni <\/h4>\n<p>\nSfortunatamente, non ho effettuato una misurazione reale delle prestazioni su stand reali, poich\u00e9 non abbiamo intenzione di utilizzare questo meccanismo in produzione, ma possiamo riflettere teoricamente su dove perderemo e dove guadagneremo.<\/p>\n<p>Per questo, dobbiamo ricordare come avviene la lettura e la scrittura delle pagine quando vi accediamo:<\/p>\n<ul>\n<li>Durante l'operazione di lettura, prima viene cercata nella RAM; se la ricerca ha esito negativo, la pagina viene caricata in RAM dal disco dallo stesso thread che esegue la lettura.<\/li>\n<li>Durante l'operazione di scrittura, la pagina nella RAM viene contrassegnata come sporca, ma il salvataggio fisico della pagina su disco non avviene immediatamente nel thread che esegue la scrittura. Tutte le pagine sporche vengono salvate su disco successivamente nel processo di checkpoint da thread separati.<\/li>\n<\/ul>\n<p>\nPertanto, l'impatto sulle operazioni di lettura \u00e8:<\/p>\n<ul>\n<li>Positivo (disk IO), grazie alla riduzione del numero di blocchi letti dal file system.<\/li>\n<li>Negativo (CPU), a causa del carico aggiuntivo necessario al sistema operativo per lavorare con i file sparsi. \u00c8 anche possibile che qui appaiano implicitamente ulteriori operazioni di IO per salvare una struttura di file sparso pi\u00f9 complessa (purtroppo non sono esperto di tutti i dettagli relativi ai file sparsi).<\/li>\n<li>Negativo (CPU), a causa della necessit\u00e0 di decomprimere le pagine.<\/li>\n<li>Non ci sono influenze sulle operazioni di scrittura.<\/li>\n<li>Influenza sul processo di checkpoint (\u00e8 tutto analogo alle operazioni di lettura):<\/li>\n<li>Positivo (disk IO), grazie alla riduzione del numero di blocchi scritti nel file system.<\/li>\n<li>Negativo (CPU, possibile disk IO), a causa del lavoro con file sparsi.<\/li>\n<li>Negativo (CPU), a causa della necessit\u00e0 di comprimere le pagine.<\/li>\n<\/ul>\n<p>\nQuale piatto della bilancia prevarr\u00e0? Questo dipende molto dall'ambiente, ma sono propenso a pensare che la compressione delle pagine su disco porter\u00e0 piuttosto a una degradazione delle prestazioni nella maggior parte dei sistemi. Inoltre, i test su altri DBMS che utilizzano un approccio simile con i file sparsi mostrano un calo delle prestazioni quando la compressione \u00e8 attivata.<\/p>\n<h4>Come abilitare e configurare<\/h4>\n<p>\nCome gi\u00e0 detto sopra, la versione minima di Apache Ignite che supporta la compressione delle pagine su disco \u00e8 2.8 e supporta solo il sistema operativo Linux. L'abilitazione e la configurazione vengono effettuate nel seguente modo:<\/p>\n<ul>\n<li>Nel class-path deve esserci il modulo ignite-compression. Di default si trova nella distribuzione di Apache Ignite nella directory libs\/optional e non \u00e8 incluso nel class-path. Puoi semplicemente spostare la directory di un livello verso l'alto in libs e allora, all'avvio tramite ignite.sh, sar\u00e0 automaticamente incluso.<\/li>\n<li>La persistenza deve essere abilitata (si abilita tramite <code>DataRegionConfiguration.setPersistenceEnabled(true))<\/code>.<\/li>\n<li>La dimensione della pagina deve essere maggiore della dimensione del blocco del file system (pu\u00f2 essere impostata tramite <code>DataStorageConfiguration.setPageSize()<\/code> ).<\/li>\n<li>Per ogni cache i cui dati devono essere compressi, \u00e8 necessario configurare il metodo di compressione nella configurazione e (opzionalmente) il livello di compressione (metodi <code>CacheConfiguration.setDiskPageCompression(), CacheConfiguration.setDiskPageCompressionLevel()<\/code>).<\/li>\n<\/ul>\n<p><\/p>\n<h3>Compattazione WAL<\/h3>\n<p><\/p>\n<h4>Come funziona<\/h4>\n<p>\nChe cos'\u00e8 il WAL e a cosa serve? In breve: \u00e8 un registro in cui vengono registrati tutti gli eventi che alla fine modificano lo storage delle pagine. Serve principalmente per il ripristino in caso di crash. Qualsiasi operazione, prima di restituire il controllo all'utente, deve prima registrare un evento nel WAL, affinch\u00e9 in caso di crash possa ripristinare tutti le operazioni che hanno ricevuto una risposta positiva, anche se queste operazioni non sono state ancora riflettute nello storage delle pagine su disco (come gi\u00e0 descritto, la registrazione effettiva nello storage delle pagine avviene attraverso un processo chiamato 'checkpoint', con un certo ritardo da parte di thread separati).<\/p>\n<p>Le registrazioni nel WAL si dividono in logiche e fisiche. Le logiche sono le chiavi e i valori stessi. Le fisiche riflettono le modifiche delle pagine nello storage delle pagine. Se le registrazioni logiche possono essere utili in altre circostanze, le registrazioni fisiche sono necessarie solo per il ripristino in caso di crash e sono necessarie solo le registrazioni dall'ultimo checkpoint riuscito. Qui non entreremo nei dettagli per spiegare perch\u00e9 funziona in questo modo, ma chi \u00e8 interessato pu\u00f2 fare riferimento all'articolo gi\u00e0 menzionato su Apache Ignite Wiki: <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/IGNITE\/Ignite+Persistent+Store+-+under+the+hood\">Ignite Persistent Store - sotto il cofano<\/a><\/noindex>.<\/p>\n<p>Spesso a una registrazione logica corrispondono pi\u00f9 registrazioni fisiche. Ad esempio, un'operazione di inserimento nella cache tocca pi\u00f9 pagine nella memoria delle pagine (pagina con i dati, pagine con gli indici, pagine con le liste free). In alcuni test sintetici, ho scoperto che le registrazioni fisiche occupavano fino al 90% del volume del file WAL. Inoltre, sono necessarie solo per un breve periodo (l'intervallo predefinito tra i checkpoint \u00e8 di 3 minuti). Sarebbe logico eliminare questi dati dopo che hanno perso la loro attualit\u00e0. Questo \u00e8 precisamente ci\u00f2 che fa il meccanismo di compattazione del WAL, liberandosi delle registrazioni fisiche e comprimendo le registrazioni logiche rimanenti con zip, riducendo cos\u00ec notevolmente la dimensione del file (a volte di decine di volte).<\/p>\n<p>FISICAMENTE, WAL \u00e8 composto da diversi segmenti (di default 10) di dimensioni fisse (di default 64MB), che vengono sovrascritti in modo circolare. Una volta che il segmento corrente \u00e8 pieno, il segmento successivo viene assegnato come corrente e il segmento pieno viene copiato in archivio tramite un flusso separato. La compattazione WAL lavora gi\u00e0 con i segmenti archiviati. Inoltre, tramite un flusso separato, monitora l'esecuzione del checkpoint e inizia la compressione dei segmenti archiviati, per cui le registrazioni fisiche non sono pi\u00f9 necessarie.<\/p>\n<p><img decoding=\"async\" alt=\"Compressione dei dati in Apache Ignite. Esperienza di Sber.\" src=\"\/wp-content\/uploads\/2020\/05\/ca8690ba7a350df9530f2ccf01c90975.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h4>Impatto sulle prestazioni<\/h4>\n<p>\nPoich\u00e9 la compattazione WAL funziona tramite un flusso separato, non dovrebbe avere un impatto diretto sulle operazioni in corso. Tuttavia, genera un carico di lavoro in background aggiuntivo sulla CPU (compressione) e sul disco (lettura di ogni segmento WAL dall'archivio e scrittura dei segmenti compressi), quindi se il sistema \u00e8 gi\u00e0 al limite delle sue capacit\u00e0, ci\u00f2 porter\u00e0 anche a una degradazione delle prestazioni.<\/p>\n<h4>Come abilitare e configurare<\/h4>\n<p>\n\u00c8 possibile attivare la compattazione WAL tramite la propriet\u00e0 <code>WalCompactionEnabled<\/code> in <code>DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)<\/code>). Inoltre, con il metodo DataStorageConfiguration.setWalCompactionLevel() \u00e8 possibile impostare il livello di compressione, se il valore di default (BEST_SPEED) non soddisfa le esigenze.<\/p>\n<h3>Compressione dello snapshot della pagina WAL<\/h3>\n<p><\/p>\n<h4>Come funziona<\/h4>\n<p>\nAbbiamo gi\u00e0 chiarito in precedenza che le registrazioni WAL si dividono in logiche e fisiche. Ogni modifica di ogni pagina nella memoria pagina genera una registrazione fisica WAL. Le registrazioni fisiche si suddividono a loro volta in due sottocategorie: registrazione dello snapshot della pagina e registrazione delta. Ogni volta che apportiamo una modifica a una pagina e la convertiamo da uno stato pulito a uno sporco, viene salvata una copia completa di quella pagina nel WAL (registrazione dello snapshot della pagina). Anche se abbiamo cambiato solo un byte, nel WAL verr\u00e0 salvata una registrazione di dimensioni leggermente superiori a quelle della pagina. Se invece apportiamo modifiche a una pagina gi\u00e0 sporca, nel WAL si genera una registrazione delta, che riflette solo le modifiche rispetto allo stato precedente della pagina, ma non tutta la pagina nella sua interezza. Poich\u00e9 il ripristino dello stato delle pagine da sporco a pulito avviene durante il checkpoint, subito dopo l'inizio del checkpoint, praticamente tutte le registrazioni fisiche consisteranno solo in snapshot delle pagine (poich\u00e9 tutte le pagine subito dopo l'inizio del checkpoint sono pulite), poi, man mano che ci si avvicina al successivo checkpoint, la quota delle registrazioni delta inizia a crescere e di nuovo viene azzerata all'inizio del prossimo checkpoint. Misurazioni in alcuni test sintetici hanno mostrato che la quota degli snapshot delle pagine nel volume totale delle registrazioni fisiche raggiunge il 90%.<\/p>\n<p>L'idea della compressione degli snapshot delle pagine WAL consiste nel comprimere gli snapshot delle pagine utilizzando uno strumento gi\u00e0 pronto per la compressione delle pagine (vedi compressione delle pagine su disco). In questo caso, le registrazioni WAL vengono salvate in modo sequenziale in modalit\u00e0 append-only e non \u00e8 necessaria l'associazione delle registrazioni ai limiti dei blocchi del file system; pertanto, qui, a differenza del meccanismo di compressione delle pagine su disco, non abbiamo affatto bisogno di file sparsi, quindi questo meccanismo funzioner\u00e0 non solo su sistemi operativi Linux. Inoltre, non ci importa pi\u00f9 quanto siamo riusciti a comprimere la pagina. Anche se abbiamo liberato solo 1 byte, questo \u00e8 gi\u00e0 un risultato positivo e possiamo salvare dati compressi nel WAL, a differenza della compressione delle pagine su disco, dove salviamo la pagina compressa solo se abbiamo liberato pi\u00f9 di 1 blocco del file system.<\/p>\n<p>Le pagine sono dati ben comprimibili, la loro percentuale rispetto al volume totale del WAL \u00e8 molto alta, quindi, mantenendo il formato del file WAL, possiamo ottenere una significativa riduzione delle sue dimensioni. La compressione, inclusa quella delle registrazioni logiche, richiederebbe una modifica del formato e la perdita di compatibilit\u00e0, ad esempio, per i consumatori esterni che potrebbero essere interessati alle registrazioni logiche, senza portare a una riduzione significativa del volume del file.<\/p>\n<p>Come per la compressione delle pagine su disco, anche per la compressione degli snapshot delle pagine WAL possono essere utilizzati algoritmi di compressione come ZSTD, LZ4, Snappy, oltre alla modalit\u00e0 SKIP_GARBAGE.<\/p>\n<h4>Impatto sulle prestazioni<\/h4>\n<p>\nCome non \u00e8 difficile notare, l'attivazione diretta della compressione degli snapshot delle pagine WAL influisce solo sui thread che scrivono dati nella memoria delle pagine, ovvero su quelli che modificano i dati nella cache. La lettura delle registrazioni fisiche WAL avviene solo una volta, al momento dell'avvio del nodo dopo un crash (e solo in caso di crash durante il checkpoint).<\/p>\n<p>L'impatto sui thread che modificano i dati \u00e8 il seguente: otteniamo un effetto negativo (CPU) dovuto alla necessit\u00e0 di comprimere ogni volta la pagina prima di scriverla su disco e un effetto positivo (disk IO) grazie alla riduzione della quantit\u00e0 di dati scritti. Pertanto, \u00e8 semplice: se le prestazioni del sistema sono limitate dalla CPU, otteniamo una leggera degradazione; se dal disco in input\/output, otteniamo un guadagno.<\/p>\n<p>Indirettamente, la riduzione delle dimensioni del WAL influisce anche (positivamente) sui thread che archiviano i segmenti WAL e sui thread di compattazione del WAL.<\/p>\n<p>Test di performance reali nel nostro ambiente con dati sintetici hanno mostrato un leggero guadagno (il throughput \u00e8 aumentato del 10%-15%, la latenza \u00e8 diminuita del 10%-15%).<\/p>\n<h4>Come abilitare e configurare<\/h4>\n<p>\nVersione minima di Apache Ignite: 2.8. L'abilitazione e la configurazione avvengono nel seguente modo:<\/p>\n<ul>\n<li>Nel class-path deve esserci il modulo ignite-compression. Di default si trova nella distribuzione di Apache Ignite nella directory libs\/optional e non \u00e8 incluso nel class-path. Puoi semplicemente spostare la directory di un livello verso l'alto in libs e allora, all'avvio tramite ignite.sh, sar\u00e0 automaticamente incluso.<\/li>\n<li>La persistenza deve essere abilitata (si abilita tramite <code>DataRegionConfiguration.setPersistenceEnabled(true)<\/code>).<\/li>\n<li>Deve essere impostata la modalit\u00e0 di compressione tramite il metodo <code>DataStorageConfiguration.setWalPageCompression()<\/code>, per impostazione predefinita la compressione \u00e8 disabilitata (modalit\u00e0 DISABLED).<\/li>\n<li>Facoltativamente, \u00e8 possibile impostare il grado di compressione tramite il metodo <code>DataStorageConfiguration.setWalPageCompression()<\/code>, valori ammissibili per ciascuna delle modalit\u00e0 sono disponibili nella javadoc del metodo.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Conclusione<\/h3>\n<p>\nI meccanismi di compressione dei dati esaminati in Apache Ignite possono essere utilizzati indipendentemente l'uno dall'altro, ma \u00e8 anche possibile combinare le loro funzionalit\u00e0. Comprendere i principi del loro funzionamento permetter\u00e0 di definire quanto siano adatti alle vostre esigenze nel vostro ambiente e quali compromessi saranno necessari nel loro utilizzo. La compressione delle pagine del disco \u00e8 destinata a comprimere lo storage principale e pu\u00f2 fornire un livello medio di compressione. La compressione degli snapshot delle pagine WAL offrir\u00e0 un livello medio di compressione dei file WAL, e molto probabilmente aumenter\u00e0 anche le prestazioni. La compattazione WAL non avr\u00e0 un impatto positivo sulle prestazioni, ma ridurr\u00e0 al minimo le dimensioni dei file WAL grazie all'eliminazione delle registrazioni fisiche.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/sberbank\/blog\/502136\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438 \u0440\u0430\u0431\u043e\u0442\u0435 \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c\u0438 \u043e\u0431\u044a\u0435\u043c\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0438\u043d\u043e\u0433\u0434\u0430 \u043c\u043e\u0436\u0435\u0442 \u043e\u0441\u0442\u0440\u043e \u0432\u0441\u0442\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u043d\u0435\u0445\u0432\u0430\u0442\u043a\u0438 \u043c\u0435\u0441\u0442\u0430 \u043d\u0430 \u0434\u0438\u0441\u043a\u0430\u0445. \u041e\u0434\u043d\u0438\u043c \u0438\u0437 \u0441\u043f\u043e\u0441\u043e\u0431\u043e\u0432 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0434\u0430\u043d\u043d\u043e\u0439 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0436\u0430\u0442\u0438\u0435, \u0431\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f \u043a\u043e\u0442\u043e\u0440\u043e\u043c\u0443, \u043d\u0430 \u0442\u043e\u043c \u0436\u0435 \u043e\u0431\u043e\u0440\u0443\u0434\u043e\u0432\u0430\u043d\u0438\u0438, \u043c\u043e\u0436\u043d\u043e \u0441\u0435\u0431\u0435 \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442\u044c \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u044c \u043e\u0431\u044a\u0435\u043c\u044b \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f. \u0412 \u0434\u0430\u043d\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u0441\u0436\u0430\u0442\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Apache Ignite. \u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u0431\u0443\u0434\u0443\u0442 \u043e\u043f\u0438\u0441\u0430\u043d\u044b \u0442\u043e\u043b\u044c\u043a\u043e \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0432\u043d\u0443\u0442\u0440\u0438 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":81937,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-81936","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u0436\u0430\u0442\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Apache Ignite. \u041e\u043f\u044b\u0442 \u0421\u0431\u0435\u0440\u0430 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-17T23:42:37+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-17T23:42:37+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Compressione dei dati in Apache Ignite. Esperienza di Sber | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u0436\u0430\u0442\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Apache Ignite. \u041e\u043f\u044b\u0442 \u0421\u0431\u0435\u0440\u0430 | ProHoster","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-17T23:42:37+00:00","article:modified_time":"2020-05-17T23:42:37+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"81936","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:47:30","updated":"2022-10-02 17:21:32","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/81936","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=81936"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/81936\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/81937"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=81936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=81936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=81936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}