Böyük həcmli məlumatlarla işləyərkən bəzən diskdə yer çatışmazlığı problemi yarana bilər. Bu problemi həll etməyin bir yolu sıxılmadır, bunun sayəsində eyni avadanlıqda saxlama həcmini artıra bilərsiniz. Bu yazıda Apache Ignite-də məlumatların sıxılmasının necə işlədiyinə baxacağıq. Bu məqalə yalnız məhsul daxilində tətbiq olunan disk sıxılma üsullarını təsvir edəcəkdir. Verilənlərin sıxılmasının digər üsulları (şəbəkə üzərindən, yaddaşda), tətbiq edilib-edilməməsindən asılı olmayaraq, əhatə dairəsindən kənarda qalacaq.
Beləliklə, əzmkarlıq rejimi aktiv olduqda, keşlərdəki məlumatların dəyişməsi nəticəsində Ignite diskə yazmağa başlayır:
- Keşlərin məzmunu
- İrəlidə qeydini yazın (bundan sonra sadəcə WAL)
Artıq bir müddətdir ki, WAL sıxılması üçün WAL sıxılması adlı mexanizm mövcuddur. Bu yaxınlarda buraxılmış Apache Ignite 2.8 diskdə məlumatları sıxmağa imkan verən daha iki mexanizm təqdim etdi: keşlərin məzmununu sıxmaq üçün disk səhifəsinin sıxılması və bəzi WAL girişlərinin sıxılması üçün WAL səhifəsinin snapshot sıxılması. Aşağıda bu mexanizmlərin hər üçü haqqında daha ətraflı məlumat.
Disk səhifəsinin sıxılması
Bu necə işləyir
Əvvəlcə Ignite-in məlumatları necə saxladığına qısa nəzər salaq. Səhifə yaddaşı yaddaş üçün istifadə olunur. Səhifə ölçüsü qovşağın başlanğıcında təyin edilir və sonrakı mərhələlərdə dəyişdirilə bilməz; həmçinin, səhifə ölçüsü fayl sistemi blokunun ölçüsündən iki və çox olmalıdır. Səhifələr lazım olduqda diskdən RAM-a yüklənir; diskdəki məlumatların ölçüsü ayrılmış RAM miqdarından çox ola bilər. Əgər diskdən səhifə yükləmək üçün RAM-da kifayət qədər yer yoxdursa, köhnə, artıq istifadə olunmayan səhifələr RAM-dan çıxarılacaq.
Məlumat diskdə aşağıdakı formada saxlanılır: hər bir keş qrupunun hər bölməsi üçün ayrıca fayl yaradılır, bu faylda səhifələr artan indeks sırası ilə bir-birinin ardınca görünür. Tam səhifə identifikatoru faylda keş qrupu identifikatorunu, bölmə nömrəsini və səhifə indeksini ehtiva edir. Beləliklə, tam səhifə identifikatorundan istifadə edərək, hər bir səhifə üçün faylı və fayldakı ofseti unikal şəkildə müəyyən edə bilərik. Apache Ignite Wiki məqaləsində yaddaş yaddaşı haqqında ətraflı oxuya bilərsiniz: .
Disk səhifəsinin sıxılma mexanizmi, adından da təxmin etdiyiniz kimi, səhifə səviyyəsində işləyir. Bu mexanizm işə salındıqda, RAM-dakı məlumatlar heç bir sıxılma olmadan olduğu kimi işlənir, lakin səhifələr RAM-dan diskə saxlandıqda onlar sıxılır.
Ancaq hər bir səhifəni ayrı-ayrılıqda sıxışdırmaq problemin həlli deyil, nəticədə yaranan məlumat fayllarının ölçüsünü birtəhər azaltmaq lazımdır. Səhifənin ölçüsü artıq sabit deyilsə, biz artıq fayla səhifələri bir-birinin ardınca yaza bilmərik, çünki bu, bir sıra problemlər yarada bilər:
- Səhifə indeksindən istifadə edərək, onun faylda yerləşdiyi ofseti hesablaya bilməyəcəyik.
- Faylın sonunda olmayan və ölçüsünü dəyişən səhifələrlə nə etmək aydın deyil. Səhifə ölçüsü azalarsa, onun boşaldığı yer yox olur. Səhifə ölçüsü artırsa, bunun üçün faylda yeni yer axtarmalısınız.
- Əgər səhifə fayl sistemi blokunun ölçüsündən çox olmayan bir neçə baytla hərəkət edərsə, onu oxumaq və ya yazmaq üçün daha bir fayl sistemi blokuna toxunmaq tələb olunacaq və bu, performansın aşağı düşməsinə səbəb ola bilər.
Bu problemləri öz səviyyəsində həll etməmək üçün Apache Ignite-də disk səhifələrinin sıxılması seyrək fayllar adlı fayl sistemi mexanizmindən istifadə edir. Seyrək fayl bəzi sıfır doldurulmuş bölgələrin "deşiklər" kimi qeyd oluna biləcəyi bir fayldır. Bu halda, bu boşluqları saxlamaq üçün heç bir fayl sistemi bloku ayrılmayacaq, nəticədə disk sahəsinə qənaət edilir.
Məntiqlidir ki, fayl sistemi blokunu azad etmək üçün çuxurun ölçüsü fayl sistemi blokundan böyük və ya ona bərabər olmalıdır ki, bu da səhifə ölçüsünə və Apache Ignite-ə əlavə məhdudiyyət qoyur: sıxılmanın hər hansı bir təsir göstərməsi üçün, səhifənin ölçüsü fayl sistemi blokunun ölçüsündən ciddi şəkildə böyük olmalıdır. Əgər səhifənin ölçüsü blokun ölçüsünə bərabərdirsə, onda biz heç vaxt bir bloku azad edə bilməyəcəyik, çünki bir bloku azad etmək üçün sıxılmış səhifə 0 bayt tutmalıdır. Əgər səhifənin ölçüsü 2 və ya 4 blokun ölçüsünə bərabərdirsə, səhifəmiz müvafiq olaraq ən azı 50% və ya 75%-ə qədər sıxılırsa, biz artıq ən azı bir bloku azad edə biləcəyik.
Beləliklə, mexanizmin necə işlədiyinin yekun təsviri: Diskə səhifə yazarkən səhifəni sıxmağa cəhd edilir. Sıxılmış səhifənin ölçüsü bir və ya bir neçə fayl sistemi blokunu azad etməyə imkan verirsə, səhifə sıxılmış formada yazılır və azad edilmiş blokların yerində "deşik" açılır (sistem çağırışı yerinə yetirilir). fallocate() deşik bayrağı ilə). Sıxılmış səhifənin ölçüsü blokları azad etməyə imkan vermirsə, səhifə sıxılmadan olduğu kimi saxlanılır. Bütün səhifə ofsetləri, səhifə indeksini səhifə ölçüsünə vurmaqla, sıxılmadan olduğu kimi hesablanır. Səhifələrin özbaşına yerdəyişməsi tələb olunmur. Səhifə ofsetləri, sıxılmadan olduğu kimi, fayl sistemi bloklarının hüdudlarına düşür.
Cari tətbiqdə Ignite yalnız Linux OS altında seyrək fayllarla işləyə bilər; müvafiq olaraq, disk səhifəsinin sıxılması yalnız bu əməliyyat sistemində Ignite istifadə edildikdə aktivləşdirilə bilər.
Disk səhifələrinin sıxılması üçün istifadə edilə bilən sıxılma alqoritmləri: ZSTD, LZ4, Snappy. Bundan əlavə, əvvəllər sadalanan alqoritmlərlə müqayisədə CPU-ya yükü azaldan, qalan məlumatlara sıxılma tətbiq edilmədən səhifədə yalnız istifadə olunmamış yerin atıldığı bir iş rejimi (SKIP_GARBAGE) mövcuddur.
Performans Təsiri
Təəssüf ki, real stendlərdə real performans ölçmələri aparmadım, çünki biz bu mexanizmdən istehsalda istifadə etməyi planlaşdırmırıq, lakin nəzəri olaraq harda uduzacağımızı və harda qalib gələcəyimizi təxmin edə bilərik.
Bunu etmək üçün səhifələrin daxil olduqda necə oxunduğunu və yazıldığını xatırlamalıyıq:
- Oxuma əməliyyatını yerinə yetirərkən əvvəlcə RAM-da axtarılır, axtarış uğursuz olarsa, səhifə oxunuşu yerinə yetirən eyni iplə diskdən RAM-a yüklənir.
- Yazma əməliyyatı yerinə yetirildikdə, RAM-dakı səhifə çirkli olaraq qeyd olunur, lakin yazmanı həyata keçirən ip tərəfindən səhifə dərhal diskdə fiziki olaraq saxlanmır. Bütün çirkli səhifələr daha sonra ayrı-ayrı mövzularda yoxlama nöqtəsi prosesində diskdə saxlanılır.
Beləliklə, oxu əməliyyatlarına təsir:
- Müsbət (disk IO), oxunan fayl sistemi bloklarının sayının azalması səbəbindən.
- Mənfi (CPU), seyrək fayllarla işləmək üçün əməliyyat sisteminin tələb etdiyi əlavə yükə görə. Daha mürəkkəb seyrək fayl strukturunu saxlamaq üçün əlavə IO əməliyyatlarının burada görünməsi də mümkündür (təəssüf ki, mən seyrək faylların necə işlədiyinin bütün detalları ilə tanış deyiləm).
- Səhifələri açmaq zərurəti ilə əlaqədar mənfi (CPU).
- Yazma əməliyyatlarına heç bir təsiri yoxdur.
- Yoxlama məntəqəsi prosesinə təsir (burada hər şey oxu əməliyyatlarına bənzəyir):
- Yazılı fayl sistemi bloklarının sayının azalması səbəbindən müsbət (disk IO).
- Seyrək fayllarla işləmək səbəbindən mənfi (CPU, bəlkə də disk IO).
- Səhifə sıxılma ehtiyacına görə mənfi (CPU).
Tərəzinin hansı tərəfi tərəziyə çevriləcək? Bütün bunlar ətraf mühitdən çox asılıdır, lakin mən inanıram ki, disk səhifələrinin sıxılması çox güman ki, əksər sistemlərdə performansın aşağı düşməsinə səbəb olacaq. Bundan əlavə, seyrək fayllarla oxşar yanaşmadan istifadə edən digər DBMS-lərdəki testlər sıxılma aktivləşdirildikdə performansın aşağı düşdüyünü göstərir.
Necə aktivləşdirmək və konfiqurasiya etmək olar
Yuxarıda qeyd edildiyi kimi, disk səhifələrinin sıxılmasını dəstəkləyən minimum Apache Ignite versiyası 2.8-dir və yalnız Linux əməliyyat sistemi dəstəklənir. Aşağıdakı kimi aktivləşdirin və konfiqurasiya edin:
- Sinif yolunda alovlanma-sıxılma modulu olmalıdır. Varsayılan olaraq, o, libs/optional kataloqda Apache Ignite paylanmasında yerləşir və sinif yoluna daxil edilmir. Siz sadəcə olaraq qovluğu bir pillə yuxarıya daşıya bilərsiniz və sonra onu ignite.sh vasitəsilə işə saldığınız zaman o, avtomatik işə salınacaq.
- Davamlılıq aktivləşdirilməlidir (Vasitəsi ilə aktivləşdirilib
DataRegionConfiguration.setPersistenceEnabled(true)). - Səhifə ölçüsü fayl sistemi blokunun ölçüsündən böyük olmalıdır (onu istifadə edərək təyin edə bilərsiniz
DataStorageConfiguration.setPageSize()). - Məlumatı sıxılmalı olan hər bir keş üçün siz sıxılma metodunu və (istəyə görə) sıxılma səviyyəsini (metodlar) konfiqurasiya etməlisiniz.
CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).
WAL sıxılması
Bu necə işləyir
WAL nədir və nə üçün lazımdır? Çox qısaca: bu, nəticədə səhifə yaddaşını dəyişdirən bütün hadisələri ehtiva edən bir jurnaldır. Bu, ilk növbədə, yıxılma halında bərpa oluna bilmək üçün lazımdır. İstənilən əməliyyat istifadəçiyə nəzarət etməzdən əvvəl əvvəlcə hadisəni WAL-da qeyd etməlidir ki, uğursuzluq halında o, jurnalda oxuna bilsin və istifadəçinin uğurlu cavab aldığı bütün əməliyyatlar bərpa olunsun. diskdəki səhifə yaddaşında əks olunmağa vaxtı yox idi (artıq yuxarıda təsvir edilmişdir ki, səhifə anbarına faktiki yazı ayrı-ayrı mövzular tərəfindən bir qədər gecikmə ilə "yoxlama nöqtəsi" adlanan prosesdə aparılır).
WAL-da qeydlər məntiqi və fiziki olaraq bölünür. Booleanlar açarlar və dəyərlərdir. Fiziki - səhifə mağazasında səhifələrə edilən dəyişiklikləri əks etdirir. Məntiqi qeydlər bəzi digər hallar üçün faydalı ola bilsə də, fiziki qeydlər yalnız qəza zamanı bərpa üçün lazımdır və qeydlər yalnız sonuncu uğurlu yoxlama məntəqəsindən sonra lazımdır. Burada təfərrüatlara girməyəcəyik və bunun niyə belə işlədiyini izah etməyəcəyik, lakin maraqlananlar Apache Ignite Wiki-də artıq qeyd olunan məqaləyə müraciət edə bilərlər: .
Məntiqi qeyddə çox vaxt bir neçə fiziki qeyd olur. Yəni, məsələn, keş yaddaşa bir yerləşdirmə əməliyyatı səhifə yaddaşındakı bir neçə səhifəyə təsir göstərir (məlumatların özü olan səhifə, indeksləri olan səhifələr, sərbəst siyahıları olan səhifələr). Bəzi sintetik testlərdə fiziki qeydlərin WAL faylının 90%-ni tutduğunu aşkar etdim. Bununla belə, onlar çox qısa müddətə lazımdır (standart olaraq, yoxlama məntəqələri arasındakı interval 3 dəqiqədir). Öz aktuallığını itirdikdən sonra bu məlumatlardan qurtulmaq məntiqli olardı. WAL sıxlaşdırma mexanizmi məhz bunu edir: o, fiziki qeydlərdən xilas olur və qalan məntiqi qeydləri zip-dən istifadə edərək sıxışdırır, eyni zamanda faylın ölçüsü çox əhəmiyyətli dərəcədə azalır (bəzən onlarla dəfə).
Fiziki olaraq, WAL dairəvi şəkildə üzərinə yazılmış sabit ölçülü (defolt olaraq 10MB) bir neçə seqmentdən (standart olaraq 64) ibarətdir. Cari seqment doldurulan kimi, növbəti seqment cari olaraq təyin edilir və doldurulmuş seqment ayrıca bir iplə arxivə kopyalanır. WAL sıxlaşdırma artıq arxiv seqmentləri ilə işləyir. Ayrıca, ayrı bir mövzu olaraq, yoxlama məntəqəsinin icrasına nəzarət edir və fiziki qeydlərə ehtiyac olmayan arxiv seqmentlərində sıxılmaya başlayır.
Performans Təsiri
WAL-ın sıxılması ayrı bir ip kimi işlədiyindən, həyata keçirilən əməliyyatlara birbaşa təsir olmamalıdır. Lakin o, yenə də CPU (sıxılma) və diskə əlavə fon yükü qoyur (arxivdən hər bir WAL seqmentinin oxunması və sıxılmış seqmentlərin yazılması), buna görə də sistem maksimum gücü ilə işləyirsə, bu, həm də performansın aşağı düşməsinə gətirib çıxaracaq.
Necə aktivləşdirmək və konfiqurasiya etmək olar
Mülkdən istifadə edərək WAL sıxılmasını aktivləşdirə bilərsiniz WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Həmçinin, DataStorageConfiguration.setWalCompactionLevel() metodundan istifadə edərək defolt dəyərdən (BEST_SPEED) razı deyilsinizsə, sıxılma səviyyəsini təyin edə bilərsiniz.
WAL səhifə snapshot sıxılma
Bu necə işləyir
WAL-da qeydlərin məntiqi və fiziki olaraq bölündüyünü artıq öyrəndik. Hər səhifəyə edilən hər dəyişiklik üçün səhifə yaddaşında fiziki WAL qeydi yaradılır. Fiziki qeydlər də öz növbəsində 2 alt növə bölünür: səhifə snapshot qeydi və delta qeydi. Biz hər dəfə bir səhifədə nəyisə dəyişdikdə və onu təmiz vəziyyətdən çirkli vəziyyətə köçürdükdə, bu səhifənin tam surəti WAL-da (səhifə snapshot qeydi) saxlanılır. WAL-da yalnız bir baytı dəyişdirsək belə, qeyd səhifə ölçüsündən bir qədər böyük olacaq. Artıq çirklənmiş səhifədə nəyisə dəyişdirsək, WAL-da delta qeydi formalaşır ki, bu da səhifənin əvvəlki vəziyyəti ilə müqayisədə yalnız dəyişiklikləri əks etdirir, lakin bütün səhifəni deyil. Səhifələrin vəziyyətinin çirklidən təmizə sıfırlanması yoxlama məntəqəsi prosesi zamanı həyata keçirildiyindən, yoxlama məntəqəsi işə salındıqdan dərhal sonra, demək olar ki, bütün fiziki qeydlər yalnız səhifələrin snapshotlarından ibarət olacaq (çünki yoxlama məntəqəsinin başlamasından dərhal sonra bütün səhifələr təmizdir) , sonra biz növbəti yoxlama məntəqəsinə yaxınlaşdıqca, delta rekord hissəsi böyüməyə başlayır və növbəti yoxlama məntəqəsinin əvvəlində yenidən sıfırlanır. Bəzi sintetik testlərdə ölçmələr göstərdi ki, fiziki qeydlərin ümumi həcmində səhifə snapshotlarının payı 90%-ə çatır.
WAL səhifə snapshot sıxılma ideyası hazır səhifə sıxılma alət (disk səhifə sıxılma baxın) istifadə edərək, səhifə snapshots sıxmaq üçün. Eyni zamanda, WAL-da qeydlər ardıcıl olaraq yalnız əlavə rejimində saxlanılır və qeydləri fayl sistemi bloklarının sərhədlərinə bağlamağa ehtiyac yoxdur, buna görə də burada, disk səhifələrinin sıxılma mexanizmindən fərqli olaraq, burada seyrək fayllara ehtiyacımız yoxdur. bütün; müvafiq olaraq, bu mexanizm yalnız OS Linux-da işləməyəcəkdir. Bundan əlavə, səhifəni nə qədər sıxışdıra bildiyimiz bizim üçün artıq əhəmiyyət kəsb etmir. 1 baytı azad etsək belə, bu artıq müsbət nəticədir və disk səhifəsinin sıxılmasından fərqli olaraq sıxılmış məlumatları WAL-da saxlaya bilərik, burada sıxılmış səhifəni yalnız 1-dən çox fayl sistemi blokunu azad etdiyimiz halda saxlayırıq.
Səhifələr yüksək sıxılan məlumatlardır, onların ümumi WAL həcmində payı çox yüksəkdir, buna görə də WAL fayl formatını dəyişdirmədən onun ölçüsündə əhəmiyyətli dərəcədə azalma əldə edə bilərik. Məntiqi qeydlər də daxil olmaqla sıxılma formatın dəyişdirilməsini və uyğunluğun itirilməsini tələb edəcək, məsələn, məntiqi qeydlərlə maraqlana bilən xarici istehlakçılar üçün, lakin fayl ölçüsünün əhəmiyyətli dərəcədə azalmasına səbəb olmayacaq.
Disk səhifələrinin sıxılmasında olduğu kimi, WAL səhifəsinin snapshot sıxılması ZSTD, LZ4, Snappy sıxılma alqoritmlərindən, həmçinin SKIP_GARBAGE rejimindən istifadə edə bilər.
Performans Təsiri
Birbaşa WAL səhifənin snapshot sıxılmasını aktivləşdirmək yalnız səhifə yaddaşına məlumat yazan mövzulara, yəni keşlərdəki məlumatları dəyişən mövzulara təsir etdiyini görmək çətin deyil. WAL-dan fiziki qeydlərin oxunması yalnız bir dəfə baş verir, bu anda düyün düşmədən sonra qaldırılır (və yalnız nəzarət nöqtəsi zamanı düşərsə).
Bu, məlumatları dəyişən mövzulara aşağıdakı şəkildə təsir göstərir: biz diskə yazmadan əvvəl səhifəni hər dəfə sıxışdırmaq ehtiyacı səbəbindən mənfi təsir (CPU) və miqdarın azalması səbəbindən müsbət təsir (disk IO) alırıq. məlumatlar yazılmışdır. Müvafiq olaraq, burada hər şey sadədir: əgər sistemin performansı CPU tərəfindən məhdudlaşdırılırsa, biz bir az deqradasiya alırıq, əgər disk I/O ilə məhdudlaşırsa, artım əldə edirik.
Dolayı olaraq, WAL ölçüsünün azaldılması WAL seqmentlərini arxivə və WAL sıxılma axınlarına tökən axınlara da (müsbət) təsir göstərir.
Sintetik məlumatlardan istifadə edərək mühitimizdə real performans testləri cüzi artım göstərdi (keçirmə qabiliyyəti 10%-15% artdı, gecikmə 10%-15% azaldı).
Necə aktivləşdirmək və konfiqurasiya etmək olar
Minimum Apache Ignite versiyası: 2.8. Aşağıdakı kimi aktivləşdirin və konfiqurasiya edin:
- Sinif yolunda alovlanma-sıxılma modulu olmalıdır. Varsayılan olaraq, o, libs/optional kataloqda Apache Ignite paylanmasında yerləşir və sinif yoluna daxil edilmir. Siz sadəcə olaraq qovluğu bir pillə yuxarıya daşıya bilərsiniz və sonra onu ignite.sh vasitəsilə işə saldığınız zaman o, avtomatik işə salınacaq.
- Davamlılıq aktivləşdirilməlidir (Vasitəsi ilə aktivləşdirilib
DataRegionConfiguration.setPersistenceEnabled(true)). - Metoddan istifadə edərək sıxılma rejimi təyin edilməlidir
DataStorageConfiguration.setWalPageCompression(), sıxılma defolt olaraq qeyri-aktivdir (DISABLED rejimi). - İsteğe bağlı olaraq, metoddan istifadə edərək sıxılma səviyyəsini təyin edə bilərsiniz
DataStorageConfiguration.setWalPageCompression(), hər rejim üçün etibarlı dəyərlər üçün metod üçün javadoc-a baxın.
Nəticə
Apache Ignite-də nəzərdən keçirilən məlumatların sıxılma mexanizmləri bir-birindən asılı olmayaraq istifadə edilə bilər, lakin onların istənilən kombinasiyası da məqbuldur. Onların necə işlədiyini başa düşmək sizə onların mühitinizdəki tapşırıqlarınız üçün nə dərəcədə uyğun olduğunu və onlardan istifadə edərkən nələri qurban verməli olduğunuzu müəyyən etməyə imkan verəcək. Disk səhifəsinin sıxılması əsas yaddaşı sıxmaq üçün nəzərdə tutulmuşdur və orta sıxılma nisbəti verə bilər. WAL səhifəsinin snapshot sıxılması WAL faylları üçün orta sıxılma dərəcəsi verəcək və çox güman ki, performansı artıracaq. WAL sıxlaşdırılması performansa müsbət təsir etməyəcək, lakin fiziki qeydləri silməklə WAL fayllarının ölçüsünü mümkün qədər azaldacaq.
Mənbə: www.habr.com