Nalika nggarap volume data sing akeh, masalah kekurangan ruang disk kadhangkala bisa muncul. Salah sawijining cara kanggo ngatasi masalah iki yaiku kompresi, amarga ing peralatan sing padha, sampeyan bisa nambah volume panyimpenan. Ing artikel iki, kita bakal ndeleng cara kerja kompresi data ing Apache Ignite. Artikel iki mung bakal njlèntrèhaké cara komprèsi disk sing diterapake ing produk. Cara liya kanggo komprèsi data (liwat jaringan, ing memori), dileksanakake utawa ora, bakal tetep ing njaba ruang lingkup.
Dadi, kanthi mode kegigihan diaktifake, minangka akibat saka owah-owahan data ing cache, Ignite wiwit nulis menyang disk:
- Isi saka caches
- Tulis Ahead Log (sabanjuré mung WAL)
Ana mekanisme kanggo kompresi WAL kanggo sawetara wektu saiki, disebut compaction WAL. Apache Ignite 2.8 sing bubar dirilis ngenalake rong mekanisme liyane sing ngidini sampeyan ngompres data ing disk: kompresi kaca disk kanggo ngompres isi cache lan kompresi snapshot kaca WAL kanggo ngompres sawetara entri WAL. Rincian liyane babagan kabeh telung mekanisme kasebut ing ngisor iki.
Kompresi kaca disk
Carane ora karya iki
Pisanan, ayo goleki kanthi ringkes babagan cara Ignite nyimpen data. Memori kaca digunakake kanggo panyimpenan. Ukuran kaca disetel ing wiwitan simpul lan ora bisa diganti ing tahap sabanjure; uga, ukuran kaca kudu dadi kekuwatan loro lan kaping pirang-pirang ukuran blok sistem file. Kaca-kaca dimuat menyang RAM saka disk yen perlu; ukuran data ing disk bisa ngluwihi jumlah RAM sing diparengake. Yen ana ora cukup papan ing RAM kanggo mbukak kaca saka disk, lawas, ora digunakake maneh kaca bakal digusur saka RAM.
Data disimpen ing disk ing wangun ing ngisor iki: file kapisah digawe kanggo saben partisi saben grup cache; ing berkas iki, kaca katon siji-sijine ing urutan indeks munggah. Pengenal kaca lengkap ngemot pengenal grup cache, nomer partisi, lan indeks kaca ing file kasebut. Mangkono, kanthi nggunakake pengenal kaca lengkap, kita bisa nemtokake kanthi unik file lan offset ing file kanggo saben kaca. Sampeyan bisa maca liyane babagan memori paging ing artikel Apache Ignite Wiki: .
Mekanisme kompresi kaca disk, kaya sing bisa ditebak saka jeneng kasebut, bisa digunakake ing tingkat kaca. Nalika mekanisme iki diaktifake, data ing RAM diproses minangka, tanpa komprèsi, nanging nalika kaca disimpen saka RAM kanggo disk, lagi teken.
Nanging ngompres saben kaca kanthi individu dudu solusi kanggo masalah kasebut; sampeyan kudu nyuda ukuran file data sing diasilake. Yen ukuran kaca ora tetep, kita ora bisa nulis kaca siji-sijine menyang file, amarga iki bisa nyebabake sawetara masalah:
- Nggunakake indeks kaca, kita ora bakal bisa ngetung offset sing ana ing file kasebut.
- Ora jelas apa sing kudu ditindakake karo kaca sing ora ana ing mburi file lan ngganti ukurane. Yen ukuran kaca suda, spasi sing dibebasake bakal ilang. Yen ukuran kaca mundhak, sampeyan kudu nggoleki panggonan anyar ing file kasebut.
- Yen kaca obah kanthi pirang-pirang bita sing ora dadi pirang-pirang ukuran blok sistem file, banjur maca utawa nulis bakal mbutuhake ndemek blok sistem file liyane, sing bisa nyebabake degradasi kinerja.
Kanggo ngindhari masalah kasebut ing tingkat dhewe, kompresi kaca disk ing Apache Ignite nggunakake mekanisme sistem file sing disebut file jarang. File sing jarang yaiku salah sawijining wilayah sing diisi nol bisa ditandhani minangka "bolongan". Ing kasus iki, ora ana pamblokiran sistem file sing bakal dialokasikan kanggo nyimpen bolongan kasebut, sing bakal ngirit ruang disk.
Logis yen kanggo mbebasake blok sistem file, ukuran bolongan kudu luwih gedhe utawa padha karo blok sistem file, sing nggawe watesan tambahan ing ukuran kaca lan Apache Ignite: supaya kompresi duwe efek apa wae, ukuran kaca kudu luwih gedhe tinimbang ukuran blok sistem berkas. Yen ukuran kaca padha karo ukuran blok, mula kita ora bakal bisa mbebasake blok siji, amarga kanggo mbebasake blok siji, kaca sing dikompres kudu ngenggoni 0 bita. Yen ukuran kaca padha karo ukuran 2 utawa 4 blok, kita bakal bisa mbebasake paling ora siji blok yen kaca kita dikompress nganti paling sethithik 50% utawa 75%.
Mangkono, katrangan pungkasan babagan cara mekanisme kasebut: Nalika nulis kaca menyang disk, ana upaya kanggo ngompres kaca kasebut. Yen ukuran kaca sing dikompres ngidini siji utawa luwih blok sistem file dibebasake, mula kaca kasebut ditulis ing bentuk sing dikompres, lan "bolongan" digawe kanggo ngganti blok sing dibebasake (panggilan sistem dieksekusi. fallocate() kanthi gendera punch hole). Yen ukuran kaca sing dikompres ora ngidini pamblokiran dibebasake, kaca kasebut disimpen kaya saiki, ora dikompres. Kabeh offset kaca diwilang kanthi cara sing padha karo tanpa kompresi, kanthi nikelake indeks kaca kanthi ukuran kaca. Ora ana relokasi kaca sing dibutuhake dhewe. Offset kaca, kaya tanpa kompresi, tiba ing wates blok sistem file.
Ing implementasine saiki, Ignite mung bisa nggarap file sing jarang ing Linux OS; mula, kompresi kaca disk mung bisa diaktifake nalika nggunakake Ignite ing sistem operasi iki.
Algoritma kompresi sing bisa digunakake kanggo kompresi kaca disk: ZSTD, LZ4, Snappy. Kajaba iku, ana mode operasi (SKIP_GARBAGE), ing ngendi mung papan sing ora digunakake ing kaca sing dibuwang tanpa komprèsi ing data sing isih ana, sing nyuda beban CPU dibandhingake karo algoritma sing wis kadhaptar sadurunge.
Dampak Kinerja
Sayange, aku ora nindakake pangukuran kinerja nyata ing stands nyata, amarga kita ora rencana nggunakake mekanisme iki ing produksi, nanging teori bisa speculate ngendi kita bakal kalah lan ngendi kita bakal menang.
Kanggo nindakake iki, kita kudu ngelingi carane kaca diwaca lan ditulis nalika diakses:
- Nalika nindakake operasi maca, pisanan ditelusuri ing RAM; yen telusuran ora kasil, kaca kasebut dimuat menyang RAM saka disk kanthi benang sing padha sing maca.
- Nalika operasi nulis dileksanakake, kaca ing RAM ditandhani minangka reged, nanging kaca ora fisik disimpen langsung menyang disk dening thread nindakake nulis. Kabeh kaca reged disimpen menyang disk mengko ing proses checkpoint ing thread kapisah.
Dadi pengaruh ing operasi maca yaiku:
- Positif (disk IO), amarga nyuda jumlah blok sistem file sing diwaca.
- Negatif (CPU), amarga beban tambahan sing dibutuhake dening sistem operasi kanggo nggarap file sing jarang. Bisa uga operasi IO tambahan bakal katon ing kene kanggo nyimpen struktur file sing luwih rumit (sayange, aku ora ngerti kabeh rincian babagan cara kerja file sing jarang).
- Negatif (CPU), amarga perlu kanggo decompress kaca.
- Ora ana pengaruh ing operasi nulis.
- Dampak ing proses checkpoint (kabeh ing kene padha karo operasi maca):
- Positif (disk IO), amarga nyuda jumlah blok sistem file sing ditulis.
- Negatif (CPU, bisa uga IO disk), amarga nggarap file sing jarang.
- Negatif (CPU), amarga perlu kanggo kompresi kaca.
Sisih endi skala sing bakal menehi tip skala? Iki kabeh gumantung banget marang lingkungan, nanging aku yakin manawa kompresi kaca disk bakal nyebabake degradasi kinerja ing umume sistem. Kajaba iku, tes ing DBMS liyane sing nggunakake pendekatan sing padha karo file sing jarang nuduhake penurunan kinerja nalika kompresi diaktifake.
Carane ngaktifake lan ngatur
Kaya sing kasebut ing ndhuwur, versi minimal Apache Ignite sing ndhukung kompresi kaca disk yaiku 2.8 lan mung sistem operasi Linux sing didhukung. Aktifake lan konfigurasi kaya ing ngisor iki:
- Mesthi ana modul kompresi ignite ing jalur kelas. Kanthi gawan, dumunung ing distribusi Apache Ignite ing direktori libs / opsional lan ora kalebu ing path-kelas. Sampeyan mung bisa mindhah direktori munggah siji tingkat kanggo libs banjur nalika mbukak liwat ignite.sh bakal otomatis aktif.
- Ketekunan kudu diaktifake (Aktifake liwat
DataRegionConfiguration.setPersistenceEnabled(true)). - Ukuran kaca kudu luwih gedhe tinimbang ukuran blok sistem file (sampeyan bisa nyetel nggunakake
DataStorageConfiguration.setPageSize()). - Kanggo saben cache sing data kudu dikompres, sampeyan kudu ngatur cara kompresi lan (opsional) tingkat kompresi (metode).
CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).
kompaksi WAL
Carane ora karya iki
Apa WAL lan kenapa perlu? Sedhela banget: iki minangka log sing ngemot kabeh acara sing pungkasane ngganti panyimpenan kaca. Perlu utamane supaya bisa pulih yen tiba. Operasi apa wae, sadurunge menehi kontrol marang pangguna, kudu ngrekam acara ing WAL dhisik, supaya yen gagal, bisa dimainake maneh ing log lan mulihake kabeh operasi sing pangguna nampa respon sing sukses, sanajan operasi kasebut. ora duwe wektu kanggo dibayangke ing panyimpenan kaca ing disk (wis ing ndhuwur wis diterangake yen nulis nyata kanggo nyimpen kaca wis rampung ing proses disebut "checkpointing" karo sawetara wektu tundha dening Utas kapisah).
Entri ing WAL dipérang dadi logis lan fisik. Boolean minangka kunci lan nilai dhewe. Fisik - nggambarake owah-owahan ing kaca ing toko kaca. Nalika cathetan logis bisa migunani kanggo sawetara kasus liyane, cathetan fisik mung dibutuhake kanggo pemulihan yen ana kacilakan lan cathetan mung dibutuhake wiwit titik papriksan sukses pungkasan. Ing kene, kita ora bakal njlèntrèhaké rinci lan njlèntrèhaké sebabé cara iki, nanging sing kasengsem bisa ngrujuk menyang artikel sing wis kasebut ing Apache Ignite Wiki: .
Asring ana sawetara rekaman fisik saben rekaman logis. Sing, contone, siji sijine operasi menyang cache mengaruhi sawetara kaca ing memori kaca (kaca karo data dhewe, kaca karo indeks, kaca karo free-dhaptar). Ing sawetara tes sintetik, aku nemokake manawa rekaman fisik dikuwasani nganti 90% file WAL. Nanging, padha dibutuhake kanggo wektu cendhak banget (kanthi standar, interval antarane checkpoints 3 menit). Iku bakal logis kanggo nyisihake data iki sawise ilang relevansi. Iki minangka mekanisme pemadatan WAL: nyisihake rekaman fisik lan ngompres cathetan logis sing isih ana nggunakake zip, dene ukuran file dikurangi kanthi signifikan (kadhangkala kaping puluhan).
Secara fisik, WAL dumadi saka sawetara segmen (10 minangka standar) kanthi ukuran tetep (64MB minangka standar), sing ditimpa kanthi cara bunder. Sanalika bagean saiki diisi, bagean sabanjure ditugasake minangka saiki, lan bagean sing diisi disalin menyang arsip kanthi benang sing kapisah. Pemadatan WAL wis bisa digunakake karo segmen arsip. Uga, minangka utas sing kapisah, ngawasi eksekusi papan papriksan lan miwiti kompresi ing bagean arsip sing cathetan fisik ora dibutuhake maneh.
Dampak Kinerja
Wiwit pemadatan WAL mlaku minangka utas sing kapisah, mula ora ana pengaruh langsung marang operasi sing ditindakake. Nanging isih nempatno beban latar mburi tambahan ing CPU (komprèsi) lan disk (maca saben bagean WAL saka arsip lan nulis bagean teken), supaya yen sistem mlaku ing kapasitas maksimum, iku uga bakal mimpin kanggo degradasi kinerja.
Carane ngaktifake lan ngatur
Sampeyan bisa ngaktifake pemadatan WAL nggunakake properti kasebut WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Uga, nggunakake cara DataStorageConfiguration.setWalCompactionLevel (), sampeyan bisa nyetel tingkat komprèsi yen sampeyan ora wareg karo nilai gawan (BEST_SPEED).
Kompresi snapshot kaca WAL
Carane ora karya iki
Kita wis nemokake manawa ing cathetan WAL dipérang dadi logis lan fisik. Kanggo saben owah-owahan ing saben kaca, rekaman WAL fisik digawe ing memori kaca. Cathetan fisik, uga dipérang dadi 2 subtipe: rekaman snapshot kaca lan rekaman delta. Saben-saben kita ngganti soko ing kaca lan nransfer saka negara resik menyang negara reged, salinan lengkap kaca iki disimpen ing WAL (kaca rekaman gambar asli). Sanajan kita mung ngganti siji bait ing WAL, rekaman bakal luwih gedhe tinimbang ukuran kaca. Yen kita ngganti soko ing kaca sing wis reged, rekaman delta dibentuk ing WAL, sing mung nuduhake owah-owahan dibandhingake karo kahanan kaca sadurunge, nanging ora kabeh kaca. Wiwit ngreset kahanan kaca saka reged dadi resik ditindakake sajrone proses checkpoint, sanalika sawise wiwitan checkpoint, meh kabeh cathetan fisik mung kalebu jepretan kaca (amarga kabeh kaca langsung sawise wiwitan checkpoint wis resik) , banjur nalika kita nyedhaki checkpoint sabanjuré, pecahan rekaman delta wiwit tuwuh lan ngreset maneh ing awal checkpoint sabanjuré. Pangukuran ing sawetara tes sintetik nuduhake yen bagean saka jepretan kaca ing volume total rekaman fisik tekan 90%.
Gagasan kompresi gambar kaca WAL yaiku ngompres gambar kaca kanthi nggunakake alat kompresi kaca sing wis siap (deleng kompresi kaca disk). Ing wektu sing padha, ing WAL, cathetan disimpen sacara berurutan ing mode append-only lan ora perlu ngiket cathetan menyang wates blok sistem file, mula ing kene, ora kaya mekanisme kompresi kaca disk, kita ora butuh file sing jarang. kabeh; patut, mekanisme iki ora mung bisa digunakake ing OS Linux. Kajaba iku, ora penting maneh kanggo kita sepira kita bisa ngompres kaca kasebut. Sanajan kita mbebasake 1 bait, iki wis dadi asil positif lan kita bisa nyimpen data sing dikompres ing WAL, ora kaya kompresi kaca disk, ing ngendi kita nyimpen kaca sing dikompres mung yen kita mbebasake luwih saka 1 blok sistem file.
Kaca-kaca minangka data sing bisa dikompres, panggabungane ing volume total WAL dhuwur banget, saengga tanpa ngganti format file WAL, kita bisa nyuda ukurane sing signifikan. Kompresi, kalebu cathetan logis, bakal mbutuhake owah-owahan ing format lan mundhut saka kompatibilitas, contone, kanggo konsumen external sing uga kasengsem ing cathetan logis, nanging ora bakal mimpin kanggo nyuda pinunjul ing ukuran file.
Kaya kompresi kaca disk, kompresi snapshot kaca WAL bisa nggunakake algoritma kompresi ZSTD, LZ4, Snappy, uga mode SKIP_GARBAGE.
Dampak Kinerja
Ora angel digatekake manawa langsung ngaktifake kompresi snapshot kaca WAL mung mengaruhi benang sing nulis data menyang memori kaca, yaiku, benang sing ngganti data ing cache. Maca cathetan fisik saka WAL mung kedadeyan sapisan, ing wayahe simpul kasebut diunggahake sawise tiba (lan mung yen tiba nalika titik mriksa).
Iki mengaruhi utas sing ngganti data kanthi cara ing ngisor iki: kita entuk efek negatif (CPU) amarga kudu ngompres kaca saben sadurunge nulis menyang disk, lan efek positif (disk IO) amarga nyuda jumlah data ditulis. Patut, kabeh iku prasaja ing kene: yen kinerja sistem diwatesi dening CPU, kita njaluk degradasi tipis, yen diwatesi dening disk I / O, kita njaluk Tambah.
Kanthi ora langsung, nyuda ukuran WAL uga mengaruhi (positif) stream sing mbucal segmen WAL menyang arsip lan stream pemadatan WAL.
Tes kinerja nyata ing lingkungan kita nggunakake data sintetik nuduhake paningkatan tipis (throughput tambah 10% -15%, latensi mudhun 10% -15%).
Carane ngaktifake lan ngatur
Versi Apache Ignite minimal: 2.8. Aktifake lan konfigurasi kaya ing ngisor iki:
- Mesthi ana modul kompresi ignite ing jalur kelas. Kanthi gawan, dumunung ing distribusi Apache Ignite ing direktori libs / opsional lan ora kalebu ing path-kelas. Sampeyan mung bisa mindhah direktori munggah siji tingkat kanggo libs banjur nalika mbukak liwat ignite.sh bakal otomatis aktif.
- Ketekunan kudu diaktifake (Aktifake liwat
DataRegionConfiguration.setPersistenceEnabled(true)). - Mode kompresi kudu disetel nggunakake metode kasebut
DataStorageConfiguration.setWalPageCompression(), komprèsi dipatèni kanthi gawan (mode DISABLED). - Opsional, sampeyan bisa nyetel tingkat kompresi nggunakake metode kasebut
DataStorageConfiguration.setWalPageCompression(), deleng javadoc kanggo metode kanggo nilai sing bener kanggo saben mode.
kesimpulan
Mekanisme kompresi data sing dianggep ing Apache Ignite bisa digunakake kanthi mandiri, nanging kombinasi apa wae uga bisa ditampa. Ngerteni cara kerjane bakal ngidini sampeyan nemtokake manawa cocog kanggo tugas ing lingkungan sampeyan lan apa sing kudu sampeyan korbanake nalika nggunakake. Kompresi kaca disk dirancang kanggo ngompres panyimpenan utama lan bisa menehi rasio kompresi medium. Kompresi snapshot kaca WAL bakal menehi tingkat kompresi rata-rata kanggo file WAL, lan kemungkinan bakal nambah kinerja. WAL compaction ora bakal duwe efek positif ing kinerja, nanging bakal nyuda ukuran file WAL sabisa kanthi mbusak cathetan fisik.
Source: www.habr.com