{"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\/de\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","title":{"rendered":"Datenkompression in Apache Ignite. Erfahrung von Sber","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Datenkompression in Apache Ignite. Erfahrung von Sber\" src=\"\/wp-content\/uploads\/2020\/05\/0e26c686b1f29e88e6be4b8df81ab668.jpg\" style=\"display:block;margin: 0 auto;\" \/>Bei der Arbeit mit gro\u00dfen Datenmengen kann manchmal das Problem des fehlenden Speicherplatzes auf den Festplatten akut werden. Eine der M\u00f6glichkeiten zur L\u00f6sung dieses Problems ist die Kompression, durch die man auf derselben Hardware eine Erh\u00f6hung des Speicherplatzes erreichen kann. In diesem Artikel werden wir untersuchen, wie die Datenkompression in Apache Ignite funktioniert. Es werden nur die im Produkt implementierten Methoden zur Kompression auf der Festplatte beschrieben. Andere Methoden der Datenkompression (\u00fcber das Netzwerk, im Speicher), ob implementiert oder nicht, bleiben unber\u00fccksichtigt.<\/p>\n<p>Also, im eingeschalteten Persistenzmodus beginnt Ignite infolge von Daten\u00e4nderungen in den Caches, auf die Festplatte zu schreiben:<\/p>\n<ol>\n<li>Inhalt der Caches<\/li>\n<li>Write Ahead Log (WAL)<\/li>\n<\/ol>\n<p>\nF\u00fcr die Kompression von WAL existiert schon seit einiger Zeit ein Mechanismus, der als WAL-Kompression bezeichnet wird. In der k\u00fcrzlich ver\u00f6ffentlichten Version Apache Ignite 2.8 wurden zwei weitere Mechanismen eingef\u00fchrt, die es erm\u00f6glichen, Daten auf der Festplatte zu komprimieren: die Disk Page Compression zur Kompression des Cache-Inhalts und die WAL Page Snapshot Compression zur Kompression bestimmter WAL-Eintr\u00e4ge. Weitere Details zu allen drei Mechanismen finden Sie weiter unten.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Disk Page Compression<\/h3>\n<p><\/p>\n<h4>Die DANE-Spezifikation ist in<\/h4>\n<p>\nZun\u00e4chst eine kurze Erkl\u00e4rung, wie Ignite Daten speichert. Zur Speicherung wird eine seitenbasierte Speicherverwaltung verwendet. Die Seitengr\u00f6\u00dfe wird beim Start des Knotens festgelegt und kann in sp\u00e4teren Phasen nicht mehr ge\u00e4ndert werden; zudem muss die Seitengr\u00f6\u00dfe eine Potenz von zwei sein und ein Vielfaches der Blockgr\u00f6\u00dfe des Dateisystems darstellen. Seiten werden bei Bedarf von der Festplatte in den RAM geladen, die Datenmenge auf der Festplatte kann den bereitgestellten RAM \u00fcbersteigen. Im Falle eines Speicherplatzmangels im RAM zum Laden von Seiten von der Festplatte werden alte, nicht mehr verwendete Seiten aus dem RAM verdr\u00e4ngt.<\/p>\n<p>Auf der Festplatte werden die Daten folgenderma\u00dfen gespeichert: F\u00fcr jede Partition jeder Cache-Gruppe wird eine separate Datei erstellt, in dieser Datei folgen die Seiten der Reihe nach in aufsteigender Indexp Reihenfolge. Die vollst\u00e4ndige Seiten-ID enth\u00e4lt die ID der Cache-Gruppe, die Partitionsnummer und den Seitenindex in der Datei. Damit k\u00f6nnen wir anhand der vollst\u00e4ndigen Seiten-ID eindeutig die Datei und den Offset in der Datei f\u00fcr jede Seite bestimmen. \u00dcber die Struktur der seitenbasierten Speicherverwaltung kann man in einem Artikel im Apache Ignite Wiki mehr erfahren: <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/IGNITE\/Ignite+Persistent+Store+-+under+the+hood\">Ignite Persistent Store \u2014 unter der Haube<\/a><\/noindex>.<\/p>\n<p>Der Mechanismus der Seitenkompression, wie aus dem Namen ersichtlich, funktioniert auf Seitenebene. Bei Aktivierung dieses Mechanismus erfolgt der Umgang mit Daten im RAM so, wie sie sind, ohne jegliche Kompression. Doch beim Speichern der Seiten aus dem RAM auf die Festplatte wird eine Kompression durchgef\u00fchrt.<\/p>\n<p>Es ist jedoch nicht ausreichend, jede Seite einzeln zu komprimieren; es muss auch eine M\u00f6glichkeit gefunden werden, die Gr\u00f6\u00dfe der endg\u00fcltigen Datendateien zu reduzieren. Wenn die Seitengr\u00f6\u00dfe nicht mehr fix ist, k\u00f6nnen wir die Seiten nicht mehr nacheinander in eine Datei schreiben, da dies zu einer Reihe von Problemen f\u00fchren kann:<\/p>\n<ul>\n<li>Wir k\u00f6nnen mit Hilfe des Seitenindex den Offset, an dem sie in der Datei liegt, nicht berechnen.<\/li>\n<li>Unklar ist, was mit Seiten zu tun ist, die sich nicht am Ende der Datei befinden und deren Gr\u00f6\u00dfe sich \u00e4ndert. Wenn die Seitengr\u00f6\u00dfe verringert wird, geht der Platz, den sie freisetzt, verloren. Wenn die Seitengr\u00f6\u00dfe zunimmt, muss ein neuer Platz in der Datei f\u00fcr sie gefunden werden.<\/li>\n<li>Wenn sich eine Seite um eine Anzahl von Bytes verschiebt, die nicht mit der Blockgr\u00f6\u00dfe des Dateisystems \u00fcbereinstimmt, ist es notwendig, beim Lesen oder Schreiben einen zus\u00e4tzlichen Block des Dateisystems anzusprechen, was zu einer Verschlechterung der Leistung f\u00fchren kann.<\/li>\n<\/ul>\n<p>\nUm diese Probleme nicht selbst auf ihrem Niveau zu l\u00f6sen, nutzt die Seitenkompression in Apache Ignite einen Mechanismus des Dateisystems namens Sparse Dateien. Eine Sparse Datei ist eine Datei, in der einige mit Nullen gef\u00fcllte Bereiche als \u201eL\u00f6cher\u201c gekennzeichnet werden k\u00f6nnen. In diesem Fall werden keine Bl\u00f6cke des Dateisystems zur Speicherung dieser L\u00f6cher zugewiesen, was zu einer Platzersparnis auf der Festplatte f\u00fchrt.<\/p>\n<p>Es ist logisch, dass zur Freigabe eines Blocks des Dateisystems die Gr\u00f6\u00dfe des Lochs gr\u00f6\u00dfer oder gleich der Blockgr\u00f6\u00dfe des Dateisystems sein muss, was eine zus\u00e4tzliche Einschr\u00e4nkung f\u00fcr die Seitengr\u00f6\u00dfe in Apache Ignite bedeutet: Damit die Kompression einen gewissen Effekt hat, muss die Seitengr\u00f6\u00dfe unbedingt gr\u00f6\u00dfer als die Blockgr\u00f6\u00dfe des Dateisystems sein. Wenn die Seitengr\u00f6\u00dfe der Blockgr\u00f6\u00dfe entspricht, k\u00f6nnen wir nie einen Block freigeben, da zur Freigabe eines einzelnen Blocks die komprimierte Seite 0 Byte einnehmen m\u00fcsste. Wenn jedoch die Seitengr\u00f6\u00dfe der Gr\u00f6\u00dfe von zwei oder vier Bl\u00f6cken entspricht, k\u00f6nnen wir mindestens einen Block freigeben, wenn unsere Seite sich mindestens auf 50 % oder 75 % ihrer urspr\u00fcnglichen Gr\u00f6\u00dfe komprimiert.<\/p>\n<p>Somit lautet die endg\u00fcltige Beschreibung der Funktionsweise des Mechanismus: Beim Speichern einer Seite auf der Festplatte wird versucht, die Seite zu komprimieren. Wenn die Gr\u00f6\u00dfe der komprimierten Seite es erlaubt, einen oder mehrere Bl\u00f6cke im Dateisystem freizugeben, wird die Seite komprimiert gespeichert, und an der Stelle der freigegebenen Bl\u00f6cke wird ein \u201eLoch\u201c gebohrt (Systemaufruf mit dem Flag \u201epunch hole\u201c). Wenn die Gr\u00f6\u00dfe der komprimierten Seite das Freigeben von Bl\u00f6cken nicht zul\u00e4sst, wird die Seite unver\u00e4ndert im unkomprimierten Format gespeichert. Alle Seitenoffsets werden wie ohne Kompression behandelt, indem der Seitenindex mit der Seitengr\u00f6\u00dfe multipliziert wird. Es ist keine Neupositionierung der Seiten erforderlich. Seitenoffsets ohne Kompression fallen ebenfalls an die Grenzen der Dateisystembl\u00f6cke. <code>fallocate()<\/code> mit dem Flag \u201epunch hole\u201c). Wenn die Gr\u00f6\u00dfe der komprimierten Seite das Freigeben von Bl\u00f6cken nicht zul\u00e4sst, wird die Seite unver\u00e4ndert im unkomprimierten Format gespeichert. Alle Seitenoffsets werden wie ohne Kompression behandelt, indem der Seitenindex mit der Seitengr\u00f6\u00dfe multipliziert wird. Es ist keine Neupositionierung der Seiten erforderlich. Seitenoffsets ohne Kompression fallen ebenfalls an die Grenzen der Dateisystembl\u00f6cke.<\/p>\n<p><img decoding=\"async\" alt=\"Datenkompression in Apache Ignite. Erfahrung von Sber\" src=\"\/wp-content\/uploads\/2020\/05\/6a6c6ad83d3b8591f76b9343ff067746.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <br \/>\nIn der aktuellen Implementierung kann Ignite nur unter Linux mit Sparse-Dateien arbeiten, weshalb die Disk Page Compression nur bei der Verwendung von Ignite auf diesem Betriebssystem aktiviert werden kann.<\/p>\n<p>Die f\u00fcr die Disk Page Compression verwendbaren Kompressionsalgorithmen sind: ZSTD, LZ4, Snappy. Au\u00dferdem gibt es einen Betriebsmodus (SKIP_GARBAGE), bei dem nur der in der Seite nicht genutzte Platz ohne Anwendung von Kompression auf den verbleibenden Daten herausgeworfen wird, was die CPU-Belastung im Vergleich zu den zuvor genannten Algorithmen verringert.<\/p>\n<h4>Einfluss auf die Leistung <\/h4>\n<p>\nLeider habe ich keine tats\u00e4chlichen Leistungsmesungen auf realen Testst\u00e4nden durchgef\u00fchrt, da wir nicht vorhaben, diesen Mechanismus in der Produktion zu verwenden, aber wir k\u00f6nnen theoretisch dar\u00fcber nachdenken, wo wir verlieren und wo wir gewinnen werden.<\/p>\n<p>Daf\u00fcr m\u00fcssen wir uns daran erinnern, wie das Lesen und Schreiben von Seiten abl\u00e4uft:<\/p>\n<ul>\n<li>Bei der Leseoperation wird zun\u00e4chst in RAM nach ihr gesucht. Wenn die Suche erfolglos ist, wird die Seite von der Festplatte vom gleichen Thread, der das Lesen durchf\u00fchrt, in den RAM geladen.<\/li>\n<li>Bei der Schreiboperation wird die Seite im RAM als schmutzig markiert, wobei die physische Speicherung der Seite auf der Festplatte im selben Thread, der das Schreiben durchf\u00fchrt, nicht sofort erfolgt. Alle schmutzigen Seiten werden sp\u00e4ter in einem Prozess beim Checkpointing von separaten Threads auf die Festplatte gespeichert.<\/li>\n<\/ul>\n<p>\nSomit hat der Einfluss auf Leseoperationen:<\/p>\n<ul>\n<li>Positiv (Disk IO), da die Anzahl der gelesenen Dateisystembl\u00f6cke reduziert wird.<\/li>\n<li>Negativ (CPU) aufgrund der zus\u00e4tzlichen Belastung, die das Betriebssystem f\u00fcr die Arbeit mit Sparse-Dateien ben\u00f6tigt. Es ist auch m\u00f6glich, dass hier implizit zus\u00e4tzliche IO-Operationen auftreten, um eine komplexere Struktur einer Sparse-Datei zu speichern (mit den Details zur Funktionsweise von Sparse-Dateien kenne ich mich leider nicht aus).<\/li>\n<li>Negativ (CPU) aufgrund der Notwendigkeit der Dekompression von Seiten.<\/li>\n<li>Es gibt keinen Einfluss auf Schreiboperationen.<\/li>\n<li>Einfluss auf den Checkpoint-Prozess (hier ist alles wie bei Lesevorg\u00e4ngen):<\/li>\n<li>Positiv (Disk-IO) aufgrund der Verringerung der Anzahl der geschriebenen Bl\u00f6cke im Dateisystem.<\/li>\n<li>Negativ (CPU, m\u00f6glicherweise Disk-IO) aufgrund der Arbeit mit Sparse-Dateien.<\/li>\n<li>Negativ (CPU) aufgrund der Notwendigkeit, Seiten zu komprimieren.<\/li>\n<\/ul>\n<p>\nWelcher Waagschale wird \u00fcberwiegen? Das h\u00e4ngt stark von der Umgebung ab, aber ich tendiere dazu zu glauben, dass die Disk-Seitenkompression in den meisten Systemen eher zu einer Leistungsminderung f\u00fchren wird. Zumal Tests mit anderen DBMS, die einen \u00e4hnlichen Ansatz mit Sparse-Dateien verwenden, zeigen, dass die Leistung bei aktivierter Kompression abnimmt.<\/p>\n<h4>Wie man es aktiviert und konfiguriert<\/h4>\n<p>\nWie bereits erw\u00e4hnt, die minimale Version von Apache Ignite, die die Disk-Seitenkompression unterst\u00fctzt: 2.8, und sie wird nur auf dem Betriebssystem Linux unterst\u00fctzt. Die Aktivierung und Konfiguration erfolgt wie folgt:<\/p>\n<ul>\n<li>Im Class-Path muss das Modul ignite-compression vorhanden sein. Standardm\u00e4\u00dfig befindet es sich im Apache Ignite-Verzeichnis libs\/optional und wird nicht in den Class-Path aufgenommen. Man kann das Verzeichnis einfach in das libs-Verzeichnis auf einer Ebene h\u00f6her verschieben, und beim Start \u00fcber ignite.sh wird es automatisch ber\u00fccksichtigt.<\/li>\n<li>Persistence muss aktiviert sein (wird \u00fcber <code>DataRegionConfiguration.setPersistenceEnabled(true)) aktiviert.<\/code>.<\/li>\n<li>Die Seitengr\u00f6\u00dfe muss gr\u00f6\u00dfer als die Blockgr\u00f6\u00dfe des Dateisystems sein (kann \u00fcber <code>DataStorageConfiguration.setPageSize() festgelegt werden.<\/code> ).<\/li>\n<li>F\u00fcr jeden Cache, dessen Daten komprimiert werden sollen, muss in der Konfiguration die Komprimierungsmethode und (optional) der Komprimierungsgrad konfiguriert werden (Methoden <code>CacheConfiguration.setDiskPageCompression(), CacheConfiguration.setDiskPageCompressionLevel()<\/code>).<\/li>\n<\/ul>\n<p><\/p>\n<h3>WAL-Kompaktierung<\/h3>\n<p><\/p>\n<h4>Die DANE-Spezifikation ist in<\/h4>\n<p>\nWas ist WAL und warum wird es ben\u00f6tigt? Kurz gesagt: es ist ein Protokoll, in das alle Ereignisse eingehen, die letztendlich den Seiten-Speicher ver\u00e4ndern. Es wird in erster Linie ben\u00f6tigt, um eine Wiederherstellung im Falle eines Ausfalls zu erm\u00f6glichen. Jede Operation muss, bevor sie die Kontrolle an den Benutzer zur\u00fcckgibt, zun\u00e4chst ein Ereignis in WAL protokollieren, um im Falle eines Ausfalls die M\u00f6glichkeit zu haben, das Protokoll wieder abzuspielen und alle Operationen wiederherzustellen, f\u00fcr die der Benutzer eine positive R\u00fcckmeldung erhalten hat, selbst wenn diese Operationen noch nicht im Seiten-Speicher auf der Festplatte reflektiert wurden (bereits erw\u00e4hnt, dass die tats\u00e4chliche Aufzeichnung im Seiten-Speicher im Prozess erfolgt, der als \u201eCheckpoint\u201c bezeichnet wird, mit einer gewissen Verz\u00f6gerung durch separate Threads).<\/p>\n<p>Die Eintr\u00e4ge im WAL werden in logische und physische unterteilt. Logische sind die eigentlichen Schl\u00fcssel und Werte. Physische spiegeln die \u00c4nderungen der Seiten im Seiten-Speicher wider. Wenn logische Eintr\u00e4ge auch f\u00fcr andere F\u00e4lle n\u00fctzlich sein k\u00f6nnen, sind physische Eintr\u00e4ge nur zur Wiederherstellung im Falle eines Ausfalls erforderlich und es werden nur Eintr\u00e4ge ab dem letzten erfolgreichen Checkpoint ben\u00f6tigt. Wir werden hier nicht ins Detail gehen und erkl\u00e4ren, warum das genau so funktioniert, aber Interessierte k\u00f6nnen auf den bereits erw\u00e4hnten Artikel im Apache Ignite Wiki zur\u00fcckgreifen: <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/IGNITE\/Ignite+Persistent+Store+-+under+the+hood\">Ignite Persistent Store \u2014 unter der Haube<\/a><\/noindex>.<\/p>\n<p>Auf einen logischen Datensatz entfallen h\u00e4ufig mehrere physische Datens\u00e4tze. Zum Beispiel betrifft eine put-Operation im Cache mehrere Seiten im Seiten-Speicher (die Seite mit den tats\u00e4chlichen Daten, Seiten mit Indizes, Seiten mit Free-Listen). Bei einigen synthetischen Tests konnte ich feststellen, dass physische Datens\u00e4tze bis zu 90 % des Volumens der WAL-Datei ausmachten. Diese Daten sind jedoch nur f\u00fcr sehr kurze Zeit erforderlich (der Standardintervall zwischen Checkpoints betr\u00e4gt 3 Minuten). Es w\u00e4re logisch, diese Daten nach dem Verlust ihrer Relevanz loszuwerden. Genau das erledigt der Mechanismus der WAL-Kompression, der physische Datens\u00e4tze entfernt und die verbleibenden logischen Datens\u00e4tze mithilfe von Zip komprimiert, wodurch die Dateigr\u00f6\u00dfe erheblich verringert wird (manchmal um das Zehnfache).<\/p>\n<p>Physisch besteht WAL aus mehreren Segmenten (standardm\u00e4\u00dfig 10) fester Gr\u00f6\u00dfe (standardm\u00e4\u00dfig 64MB), die im Kreis \u00fcberschrieben werden. Sobald das aktuelle Segment voll ist, wird ihm das n\u00e4chste Segment zugewiesen, und das gef\u00fcllte Segment wird in einem separaten Thread archiviert. Die WAL-Kompaktion arbeitet bereits mit archivierten Segmenten. Auch in einem separaten Thread verfolgt sie die Durchf\u00fchrung von Checkpoints und beginnt mit der Komprimierung von archivierten Segmenten, deren physische Aufzeichnungen nicht mehr ben\u00f6tigt werden.<\/p>\n<p><img decoding=\"async\" alt=\"Datenkompression in Apache Ignite. Erfahrung von Sber\" src=\"\/wp-content\/uploads\/2020\/05\/ca8690ba7a350df9530f2ccf01c90975.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h4>Einfluss auf die Leistung<\/h4>\n<p>\nDa die WAL-Kompaktion in einem separaten Thread arbeitet, sollte sie keine direkten Auswirkungen auf die ausgef\u00fchrten Operationen haben. Sie erzeugt jedoch zus\u00e4tzliche Hintergrundlast auf der CPU (Komprimierung) und der Festplatte (Lesen jedes WAL-Segments aus dem Archiv und Schreiben der komprimierten Segmente). Wenn das System also am Limit arbeitet, f\u00fchrt dies auch zu einer Leistungsverschlechterung.<\/p>\n<h4>Wie man es aktiviert und konfiguriert<\/h4>\n<p>\nDie WAL-Kompaktion kann durch die Eigenschaft <code>WalCompactionEnabled<\/code> in <code>DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)<\/code>). Dar\u00fcber hinaus kann mit der Methode DataStorageConfiguration.setWalCompactionLevel() der Komprimierungsgrad festgelegt werden, wenn der Standardwert (BEST_SPEED) nicht ausreicht.<\/p>\n<h3>WAL-Seiten-Snapshot-Komprimierung<\/h3>\n<p><\/p>\n<h4>Die DANE-Spezifikation ist in<\/h4>\n<p>\nFr\u00fcher wurde bereits festgestellt, dass WAL-Datens\u00e4tze in logische und physische unterteilt sind. Bei jeder \u00c4nderung jeder Seite im Seiten-Speicher wird ein physischer WAL-Datensatz erstellt. Physische Datens\u00e4tze teilen sich wiederum in zwei Unterarten: Page Snapshot Record und Delta Record. Jedes Mal, wenn wir etwas auf einer Seite \u00e4ndern und sie von einem sauberen in einen schmutzigen Zustand versetzen, wird eine vollst\u00e4ndige Kopie dieser Seite im WAL gespeichert (Page Snapshot Record \u2014 Snapshot der Seite). Selbst wenn wir nur ein Byte \u00e4ndern, wird im WAL ein Datensatz gespeichert, der etwas gr\u00f6\u00dfer als die Seitengr\u00f6\u00dfe ist. Wenn wir hingegen etwas auf einer bereits schmutzigen Seite \u00e4ndern, wird im WAL ein Delta Record erstellt, der nur die \u00c4nderungen im Vergleich zum vorherigen Zustand der Seite widerspiegelt, jedoch nicht die gesamte Seite. Da der Zustand von Seiten von schmutzig nach sauber im Verlauf eines Checkpoints zur\u00fcckgesetzt wird, werden unmittelbar nach Beginn des Checkpoints fast alle physischen Datens\u00e4tze ausschlie\u00dflich aus Snapshots der Seiten bestehen (da alle Seiten unmittelbar nach Beginn des Checkpoints sauber sind). Mit der Ann\u00e4herung an den n\u00e4chsten Checkpoint beginnt der Anteil der Delta Records zu wachsen und wird zu Beginn des n\u00e4chsten Checkpoints wieder zur\u00fcckgesetzt. Messungen in einigen synthetischen Tests zeigten, dass der Anteil der Snapshots der Seiten im Gesamtvolumen der physischen Datens\u00e4tze bis zu 90 % erreicht.<\/p>\n<p>Die Idee der WAL Page Snapshot-Kompression besteht darin, Snapshots der Seiten mithilfe eines bereits vorhandenen Werkzeugs zur Seitenkompression zu komprimieren (siehe Disk Page Compression). Dabei werden die WAL-Datens\u00e4tze sequenziell im Append-Only-Modus gespeichert, und es besteht keine Notwendigkeit, die Datens\u00e4tze an die Grenzen von Dateisystembl\u00f6cken zu binden. Daher ben\u00f6tigen wir hier, im Gegensatz zum Mechanismus der Disk Page Compression, keinerlei Sparse-Dateien, weshalb dieser Mechanismus nicht nur auf Linux-Betriebssystemen funktioniert. Dar\u00fcber hinaus ist es uns egal, wie stark wir die Seite komprimieren konnten. Selbst wenn wir 1 Byte freigemacht haben, ist das bereits ein positives Ergebnis und wir k\u00f6nnen komprimierte Daten im WAL speichern, anders als bei der Disk Page Compression, bei der wir eine komprimierte Seite nur speichern, wenn wir mehr als 1 Block des Dateisystems freigemacht haben.<\/p>\n<p>Seiten sind gut komprimierbare Daten, und ihr Anteil am gesamten WAL-Volumen ist sehr hoch. So k\u00f6nnen wir durch Beibehaltung des WAL-Dateiformats eine signifikante Reduzierung seiner Gr\u00f6\u00dfe erreichen. Die Komprimierung von logischen Eintr\u00e4gen w\u00fcrde eine \u00c4nderung des Formats und den Verlust der Kompatibilit\u00e4t erfordern, z. B. f\u00fcr externe Verbraucher, die an logischen Eintr\u00e4gen interessiert sein k\u00f6nnten, ohne eine wesentliche Verringerung der Dateigr\u00f6\u00dfe zu bringen.<\/p>\n<p>Wie bei der Kompression von Disk-Seiten k\u00f6nnen auch f\u00fcr die Kompression von WAL-Seiten-Snapshots die Kompressionsalgorithmen ZSTD, LZ4, Snappy sowie der SKIP_GARBAGE-Modus verwendet werden.<\/p>\n<h4>Einfluss auf die Leistung<\/h4>\n<p>\nWie leicht zu erkennen ist, wirkt sich die direkte Aktivierung der Kompression von WAL-Seiten-Snapshots nur auf die Threads aus, die Daten in den Seiten-Speicher schreiben, das hei\u00dft auf jene Threads, die Daten in den Caches \u00e4ndern. Das Lesen aus den WAL-physikalischen Eintr\u00e4gen erfolgt nur einmalig, wenn der Knoten nach einem Absturz hochgefahren wird (und nur im Fall eines Absturzes w\u00e4hrend des Checkpoints).<\/p>\n<p>Auf die Threads, die Daten \u00e4ndern, wirkt sich dies folgenderma\u00dfen aus: Wir haben einen negativen Effekt (CPU) aufgrund der Notwendigkeit, jede Seite vor dem Schreiben auf die Festplatte zu komprimieren, und einen positiven Effekt (Disk IO) durch die Verringerung der geschriebenen Datenmenge. Dementsprechend ist es hier einfach: wenn die Systemleistung vom CPU begrenzt wird, erfahren wir einen leichten R\u00fcckgang, wenn es vom Festplattenein-\/-ausgabe abh\u00e4ngt \u2013 einen Anstieg.<\/p>\n<p>Indirekt wirkt sich die Verringerung der WAL-Gr\u00f6\u00dfe auch positiv auf die Threads aus, die WAL-Segmente in Archive ablegen, sowie auf die WAL-Komprimierungsthreads.<\/p>\n<p>Reale Leistungstests in unserer Umgebung mit synthetischen Daten zeigten einen geringen Anstieg (der Durchsatz stieg um 10%-15%, die Latenz verringerte sich um 10%-15%).<\/p>\n<h4>Wie man es aktiviert und konfiguriert<\/h4>\n<p>\nMinimale Version von Apache Ignite: 2.8. Die Aktivierung und Konfiguration erfolgt wie folgt:<\/p>\n<ul>\n<li>Im Class-Path muss das Modul ignite-compression vorhanden sein. Standardm\u00e4\u00dfig befindet es sich im Apache Ignite-Verzeichnis libs\/optional und wird nicht in den Class-Path aufgenommen. Man kann das Verzeichnis einfach in das libs-Verzeichnis auf einer Ebene h\u00f6her verschieben, und beim Start \u00fcber ignite.sh wird es automatisch ber\u00fccksichtigt.<\/li>\n<li>Persistence muss aktiviert sein (wird \u00fcber <code>DataRegionConfiguration.setPersistenceEnabled(true)<\/code>).<\/li>\n<li>Der Komprimierungsmodus muss mit der Methode festgelegt werden <code>DataStorageConfiguration.setWalPageCompression()<\/code>, standardm\u00e4\u00dfig ist die Komprimierung deaktiviert (Modus DISABLED).<\/li>\n<li>Optional kann der Komprimierungsgrad mit der Methode festgelegt werden <code>DataStorageConfiguration.setWalPageCompression()<\/code>, zul\u00e4ssige Werte f\u00fcr jede der Modi finden Sie in der Javadoc zur Methode.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Fazit<\/h3>\n<p>\nDie betrachteten Datenkomprimierungsmechanismen in Apache Ignite k\u00f6nnen unabh\u00e4ngig voneinander verwendet werden, aber auch beliebige Kombinationen sind zul\u00e4ssig. Das Verst\u00e4ndnis der Funktionsprinzipien erm\u00f6glicht es, zu bestimmen, wie gut sie f\u00fcr Ihre Anforderungen in Ihrer Umgebung geeignet sind und auf was verzichtet werden muss, wenn sie eingesetzt werden. Die Disk-Seitenkompression ist f\u00fcr die Komprimierung des Hauptspeichers vorgesehen und kann eine mittlere Komprimierungsrate liefern. Die WAL-Seiten-Snapshot-Kompression erzielt eine mittlere Komprimierungsrate der WAL-Dateien und k\u00f6nnte wahrscheinlich sogar die Leistung steigern. Die WAL-Kompression hat keinen positiven Einfluss auf die Leistung, reduziert jedoch die Gr\u00f6\u00dfe der WAL-Dateien erheblich, indem physische Eintr\u00e4ge gel\u00f6scht werden.<br \/>\n<br \/>Quelle: <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\/de\/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=\"de_DE\" \/>\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\/de\/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\udd47Datenkomprimierung in Apache Ignite. Erfahrung von Sber | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/81936","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=81936"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/81936\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/81937"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=81936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=81936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=81936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}