Apabila bekerja dengan jumlah data yang besar, masalah kekurangan ruang cakera kadangkala boleh timbul. Salah satu cara untuk menyelesaikan masalah ini ialah pemampatan, berkat yang, pada peralatan yang sama, anda mampu untuk meningkatkan jumlah storan. Dalam artikel ini, kita akan melihat cara pemampatan data berfungsi dalam Apache Ignite. Artikel ini akan menerangkan hanya kaedah pemampatan cakera yang dilaksanakan dalam produk. Kaedah pemampatan data lain (melalui rangkaian, dalam ingatan), sama ada dilaksanakan atau tidak, akan kekal di luar skop.
Jadi, dengan mod kegigihan didayakan, akibat daripada perubahan dalam data dalam cache, Ignite mula menulis ke cakera:
- Kandungan cache
- Tulis Log Hadapan (selepas ini hanya WAL)
Terdapat mekanisme untuk pemampatan WAL untuk sekian lama, dipanggil pemadatan WAL. Apache Ignite 2.8 yang dikeluarkan baru-baru ini memperkenalkan dua lagi mekanisme yang membolehkan anda memampatkan data pada cakera: pemampatan halaman cakera untuk memampatkan kandungan cache dan pemampatan petikan halaman WAL untuk memampatkan beberapa entri WAL. Butiran lanjut tentang ketiga-tiga mekanisme ini di bawah.
Pemampatan halaman cakera
ΠΠ°ΠΊ ΡΡΠΎ ΡΠ°Π±ΠΎΡΠ°Π΅Ρ
Mula-mula, mari kita lihat secara ringkas cara Ignite menyimpan data. Memori halaman digunakan untuk penyimpanan. Saiz halaman ditetapkan pada permulaan nod dan tidak boleh diubah pada peringkat kemudian; juga, saiz halaman mestilah kuasa dua dan gandaan saiz blok sistem fail. Halaman dimuatkan ke dalam RAM dari cakera mengikut keperluan; saiz data pada cakera mungkin melebihi jumlah RAM yang diperuntukkan. Jika tidak ada ruang yang mencukupi dalam RAM untuk memuatkan halaman dari cakera, halaman lama yang tidak digunakan lagi akan diusir daripada RAM.
Data disimpan pada cakera dalam bentuk berikut: fail berasingan dicipta untuk setiap partition bagi setiap kumpulan cache; dalam fail ini, halaman muncul satu demi satu dalam susunan indeks menaik. Pengecam halaman penuh mengandungi pengecam kumpulan cache, nombor partition dan indeks halaman dalam fail. Oleh itu, menggunakan pengecam halaman penuh, kami boleh menentukan secara unik fail dan offset dalam fail untuk setiap halaman. Anda boleh membaca lebih lanjut mengenai memori paging dalam artikel Apache Ignite Wiki: .
Mekanisme pemampatan halaman cakera, seperti yang anda mungkin meneka dari namanya, berfungsi pada peringkat halaman. Apabila mekanisme ini didayakan, data dalam RAM diproses seperti sedia ada, tanpa sebarang pemampatan, tetapi apabila halaman disimpan dari RAM ke cakera, ia dimampatkan.
Tetapi memampatkan setiap halaman secara individu bukanlah penyelesaian kepada masalah; anda perlu entah bagaimana mengurangkan saiz fail data yang terhasil. Jika saiz halaman tidak lagi ditetapkan, kami tidak lagi boleh menulis halaman ke fail satu demi satu, kerana ini boleh menimbulkan beberapa masalah:
- Menggunakan indeks halaman, kami tidak akan dapat mengira offset yang mana ia terletak dalam fail.
- Tidak jelas apa yang perlu dilakukan dengan halaman yang tidak berada di penghujung fail dan menukar saiznya. Jika saiz halaman berkurangan, ruang yang dikosongkan akan hilang. Jika saiz halaman bertambah, anda perlu mencari tempat baharu dalam fail untuknya.
- Jika halaman bergerak dengan beberapa bait yang bukan gandaan saiz blok sistem fail, maka membaca atau menulisnya akan memerlukan sentuhan satu lagi blok sistem fail, yang boleh menyebabkan kemerosotan prestasi.
Untuk mengelak daripada menyelesaikan masalah ini pada tahapnya sendiri, pemampatan halaman cakera dalam Apache Ignite menggunakan mekanisme sistem fail yang dipanggil fail jarang. Fail jarang ialah fail yang beberapa kawasan yang diisi sifar boleh ditandakan sebagai "lubang". Dalam kes ini, tiada blok sistem fail akan diperuntukkan untuk menyimpan lubang ini, mengakibatkan penjimatan ruang cakera.
Adalah logik bahawa untuk membebaskan blok sistem fail, saiz lubang mestilah lebih besar daripada atau sama dengan blok sistem fail, yang mengenakan had tambahan pada saiz halaman dan Apache Ignite: untuk pemampatan mempunyai sebarang kesan, saiz halaman mestilah lebih besar daripada saiz blok sistem fail. Jika saiz halaman adalah sama dengan saiz blok, maka kami tidak akan dapat membebaskan satu blok, kerana untuk membebaskan satu blok, halaman yang dimampatkan mesti menduduki 0 bait. Jika saiz halaman sama dengan saiz 2 atau 4 blok, kami sudah boleh mengosongkan sekurang-kurangnya satu blok jika halaman kami dimampatkan kepada sekurang-kurangnya 50% atau 75%, masing-masing.
Oleh itu, penerangan akhir tentang cara mekanisme berfungsi: Apabila menulis halaman ke cakera, percubaan dibuat untuk memampatkan halaman. Jika saiz halaman yang dimampatkan membenarkan satu atau lebih blok sistem fail dibebaskan, maka halaman itu ditulis dalam bentuk termampat, dan "lubang" dibuat sebagai ganti blok yang dibebaskan (panggilan sistem dilaksanakan fallocate() dengan bendera punch hole). Jika saiz halaman yang dimampatkan tidak membenarkan blok dibebaskan, halaman tersebut disimpan seperti sedia ada, tidak dimampatkan. Semua pengimbangan halaman dikira dengan cara yang sama seperti tanpa pemampatan, dengan mendarabkan indeks halaman dengan saiz halaman. Tiada penempatan semula halaman diperlukan sendiri. Offset halaman, sama seperti tanpa pemampatan, jatuh pada sempadan blok sistem fail.
Dalam pelaksanaan semasa, Ignite hanya boleh berfungsi dengan fail jarang di bawah OS Linux; oleh itu, pemampatan halaman cakera hanya boleh didayakan apabila menggunakan Ignite pada sistem pengendalian ini.
Algoritma pemampatan yang boleh digunakan untuk pemampatan halaman cakera: ZSTD, LZ4, Snappy. Di samping itu, terdapat mod pengendalian (SKIP_GARBAGE), di mana hanya ruang yang tidak digunakan dalam halaman dibuang tanpa menggunakan pemampatan pada data yang tinggal, yang mengurangkan beban pada CPU berbanding dengan algoritma yang disenaraikan sebelum ini.
Kesan Prestasi
Malangnya, saya tidak melakukan pengukuran prestasi sebenar pada pendirian sebenar, kerana kami tidak merancang untuk menggunakan mekanisme ini dalam pengeluaran, tetapi kami secara teorinya boleh membuat spekulasi di mana kami akan kalah dan di mana kami akan menang.
Untuk melakukan ini, kita perlu ingat bagaimana halaman dibaca dan ditulis apabila diakses:
- Apabila melakukan operasi baca, ia pertama kali dicari dalam RAM; jika carian tidak berjaya, halaman dimuatkan ke dalam RAM dari cakera oleh benang yang sama yang melakukan bacaan.
- Apabila operasi tulis dilakukan, halaman dalam RAM ditandakan sebagai kotor, tetapi halaman itu tidak disimpan secara fizikal ke cakera dengan serta-merta oleh benang yang melakukan penulisan. Semua halaman kotor disimpan ke cakera kemudian dalam proses pusat pemeriksaan dalam benang berasingan.
Jadi kesan ke atas operasi baca ialah:
- Positif (IO cakera), disebabkan oleh penurunan bilangan blok sistem fail yang dibaca.
- Negatif (CPU), disebabkan oleh beban tambahan yang diperlukan oleh sistem pengendalian untuk berfungsi dengan fail yang jarang. Ada juga kemungkinan bahawa operasi IO tambahan secara tersirat akan muncul di sini untuk menyimpan struktur fail jarang yang lebih kompleks (malangnya, saya tidak biasa dengan semua butiran tentang cara fail jarang berfungsi).
- Negatif (CPU), kerana keperluan untuk menyahmampat halaman.
- Tiada kesan pada operasi tulis.
- Kesan pada proses pusat pemeriksaan (semuanya di sini serupa dengan operasi baca):
- Positif (cakera IO), disebabkan oleh penurunan bilangan blok sistem fail bertulis.
- Negatif (CPU, mungkin cakera IO), kerana bekerja dengan fail yang jarang.
- Negatif (CPU), kerana keperluan untuk pemampatan halaman.
Sisi penimbang yang manakah akan menghujung penimbang? Ini semua sangat bergantung pada persekitaran, tetapi saya cenderung untuk percaya bahawa pemampatan halaman cakera berkemungkinan besar akan membawa kepada kemerosotan prestasi pada kebanyakan sistem. Selain itu, ujian pada DBMS lain yang menggunakan pendekatan serupa dengan fail yang jarang menunjukkan penurunan prestasi apabila pemampatan didayakan.
Bagaimana untuk mendayakan dan mengkonfigurasi
Seperti yang dinyatakan di atas, versi minimum Apache Ignite yang menyokong pemampatan halaman cakera ialah 2.8 dan hanya sistem pengendalian Linux yang disokong. Dayakan dan konfigurasikan seperti berikut:
- Mesti ada modul mampatan nyala dalam laluan kelas. Secara lalai, ia terletak dalam pengedaran Apache Ignite dalam direktori lib/pilihan dan tidak termasuk dalam laluan kelas. Anda hanya boleh mengalihkan direktori ke atas satu tahap ke lib dan kemudian apabila anda menjalankannya melalui ignite.sh ia akan didayakan secara automatik.
- Kegigihan mesti didayakan (Didayakan melalui
DataRegionConfiguration.setPersistenceEnabled(true)). - Saiz halaman mestilah lebih besar daripada saiz blok sistem fail (anda boleh menetapkannya menggunakan
DataStorageConfiguration.setPageSize()). - Untuk setiap cache yang datanya perlu dimampatkan, anda mesti mengkonfigurasi kaedah mampatan dan (sebagai pilihan) tahap mampatan (kaedah
CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).
Pemadatan WAL
ΠΠ°ΠΊ ΡΡΠΎ ΡΠ°Π±ΠΎΡΠ°Π΅Ρ
Apakah WAL dan mengapa ia diperlukan? Secara ringkas: ini ialah log yang mengandungi semua peristiwa yang akhirnya mengubah storan halaman. Ia diperlukan terutamanya untuk dapat pulih sekiranya terjatuh. Sebarang operasi, sebelum memberikan kawalan kepada pengguna, mesti merekodkan peristiwa dalam WAL terlebih dahulu, supaya sekiranya berlaku kegagalan, ia boleh dimainkan semula dalam log dan memulihkan semua operasi yang pengguna menerima respons yang berjaya, walaupun operasi ini. tidak mempunyai masa untuk dicerminkan dalam storan halaman pada cakera (sudah di atas Telah diterangkan bahawa penulisan sebenar ke stor halaman dilakukan dalam proses yang dipanggil "pemeriksaan" dengan beberapa kelewatan oleh benang berasingan).
Entri dalam WAL terbahagi kepada logik dan fizikal. Boolean adalah kunci dan nilai itu sendiri. Fizikal - mencerminkan perubahan pada halaman dalam stor halaman. Walaupun rekod logik boleh berguna untuk beberapa kes lain, rekod fizikal hanya diperlukan untuk pemulihan sekiranya berlaku ranap dan rekod hanya diperlukan sejak pusat pemeriksaan terakhir yang berjaya. Di sini kami tidak akan menerangkan secara terperinci dan menjelaskan mengapa ia berfungsi dengan cara ini, tetapi mereka yang berminat boleh merujuk kepada artikel yang telah disebutkan di Apache Ignite Wiki: .
Selalunya terdapat beberapa rekod fizikal bagi setiap rekod logik. Iaitu, sebagai contoh, satu operasi meletakkan ke dalam cache menjejaskan beberapa halaman dalam memori halaman (halaman dengan data itu sendiri, halaman dengan indeks, halaman dengan senarai percuma). Dalam beberapa ujian sintetik, saya mendapati bahawa rekod fizikal menduduki sehingga 90% daripada fail WAL. Walau bagaimanapun, ia diperlukan untuk masa yang sangat singkat (secara lalai, selang antara pusat pemeriksaan ialah 3 minit). Adalah logik untuk menyingkirkan data ini selepas kehilangan kaitannya. Inilah yang dilakukan oleh mekanisme pemadatan WAL: ia menyingkirkan rekod fizikal dan memampatkan rekod logik yang tinggal menggunakan zip, manakala saiz fail dikurangkan dengan sangat ketara (kadang-kadang berpuluh kali ganda).
Secara fizikal, WAL terdiri daripada beberapa segmen (10 secara lalai) dengan saiz tetap (64MB secara lalai), yang ditimpa secara bulat. Sebaik sahaja segmen semasa diisi, segmen seterusnya ditetapkan sebagai semasa dan segmen yang diisi disalin ke arkib oleh benang berasingan. Pemadatan WAL sudah berfungsi dengan segmen arkib. Selain itu, sebagai utas yang berasingan, ia memantau pelaksanaan pusat pemeriksaan dan memulakan pemampatan dalam segmen arkib yang rekod fizikalnya tidak diperlukan lagi.
Kesan Prestasi
Memandangkan pemadatan WAL berjalan sebagai benang yang berasingan, seharusnya tiada kesan langsung ke atas operasi yang dijalankan. Tetapi ia masih meletakkan beban latar belakang tambahan pada CPU (mampatan) dan cakera (membaca setiap segmen WAL dari arkib dan menulis segmen termampat), jadi jika sistem berjalan pada kapasiti maksimumnya, ia juga akan membawa kepada kemerosotan prestasi.
Bagaimana untuk mendayakan dan mengkonfigurasi
Anda boleh mendayakan pemadatan WAL menggunakan harta tersebut WalCompactionEnabled Π² DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). Selain itu, menggunakan kaedah DataStorageConfiguration.setWalCompactionLevel(), anda boleh menetapkan tahap mampatan jika anda tidak berpuas hati dengan nilai lalai (BEST_SPEED).
Pemampatan petikan halaman WAL
ΠΠ°ΠΊ ΡΡΠΎ ΡΠ°Π±ΠΎΡΠ°Π΅Ρ
Kami telah mengetahui bahawa dalam rekod WAL dibahagikan kepada logik dan fizikal. Untuk setiap perubahan pada setiap halaman, rekod WAL fizikal dijana dalam memori halaman. Rekod fizikal, seterusnya, juga dibahagikan kepada 2 subjenis: rekod petikan halaman dan rekod delta. Setiap kali kami menukar sesuatu pada halaman dan memindahkannya daripada keadaan bersih kepada keadaan kotor, salinan lengkap halaman ini disimpan dalam WAL (rekod petikan halaman). Walaupun kami menukar hanya satu bait dalam WAL, rekod akan lebih besar sedikit daripada saiz halaman. Jika kita menukar sesuatu pada halaman yang sudah kotor, maka rekod delta terbentuk dalam WAL, yang hanya mencerminkan perubahan berbanding keadaan halaman sebelumnya, tetapi bukan keseluruhan halaman. Memandangkan penetapan semula keadaan halaman daripada kotor kepada bersih dilakukan semasa proses pusat pemeriksaan, sejurus selepas permulaan pusat pemeriksaan, hampir semua rekod fizikal hanya akan terdiri daripada petikan halaman (kerana semua halaman sebaik sahaja permulaan pusat pemeriksaan adalah bersih) , kemudian apabila kita menghampiri pusat pemeriksaan seterusnya, pecahan rekod delta mula berkembang dan ditetapkan semula pada permulaan pusat pemeriksaan seterusnya. Pengukuran dalam beberapa ujian sintetik menunjukkan bahawa bahagian syot kilat halaman dalam jumlah volum rekod fizikal mencapai 90%.
Idea pemampatan petikan halaman WAL adalah untuk memampatkan petikan halaman menggunakan alat pemampatan halaman siap sedia (lihat pemampatan halaman cakera). Pada masa yang sama, dalam WAL, rekod disimpan secara berurutan dalam mod tambahan sahaja dan tidak perlu mengikat rekod ke sempadan blok sistem fail, jadi di sini, tidak seperti mekanisme pemampatan halaman cakera, kami tidak memerlukan fail jarang di semua; oleh itu, mekanisme ini akan berfungsi bukan sahaja pada OS Linux. Di samping itu, ia tidak lagi penting kepada kami sejauh mana kami dapat memampatkan halaman. Walaupun kami membebaskan 1 bait, ini sudah menjadi hasil yang positif dan kami boleh menyimpan data mampat dalam WAL, tidak seperti pemampatan halaman cakera, di mana kami menyimpan halaman dimampatkan hanya jika kami membebaskan lebih daripada 1 blok sistem fail.
Halaman adalah data yang sangat boleh dimampatkan, bahagian mereka dalam jumlah volum WAL adalah sangat tinggi, jadi tanpa mengubah format fail WAL kita boleh mendapat pengurangan ketara dalam saiznya. Pemampatan, termasuk rekod logik, memerlukan perubahan dalam format dan kehilangan keserasian, contohnya, untuk pengguna luar yang mungkin berminat dengan rekod logik, tetapi tidak akan membawa kepada pengurangan ketara dalam saiz fail.
Seperti pemampatan halaman cakera, pemampatan petikan halaman WAL boleh menggunakan algoritma pemampatan ZSTD, LZ4, Snappy, serta mod SKIP_GARBAGE.
Kesan Prestasi
Tidak sukar untuk menyedari bahawa mendayakan secara langsung pemampatan petikan halaman WAL hanya mempengaruhi utas yang menulis data ke memori halaman, iaitu, utas yang menukar data dalam cache. Membaca rekod fizikal daripada WAL berlaku sekali sahaja, pada masa ini nod dinaikkan selepas jatuh (dan hanya jika ia jatuh semasa pusat pemeriksaan).
Ini mempengaruhi urutan yang menukar data dengan cara berikut: kami mendapat kesan negatif (CPU) kerana keperluan untuk memampatkan halaman setiap kali sebelum menulis ke cakera, dan kesan positif (cakera IO) disebabkan oleh pengurangan jumlah data yang ditulis. Oleh itu, segala-galanya adalah mudah di sini: jika prestasi sistem dihadkan oleh CPU, kita mendapat sedikit kemerosotan, jika ia dihadkan oleh cakera I/O, kita mendapat peningkatan.
Secara tidak langsung, mengurangkan saiz WAL juga mempengaruhi (secara positif) aliran yang membuang segmen WAL ke dalam arkib dan aliran pemadatan WAL.
Ujian prestasi sebenar dalam persekitaran kami menggunakan data sintetik menunjukkan sedikit peningkatan (throughput meningkat sebanyak 10%-15%, kependaman menurun sebanyak 10%-15%).
Bagaimana untuk mendayakan dan mengkonfigurasi
Versi Apache Ignite minimum: 2.8. Dayakan dan konfigurasikan seperti berikut:
- Mesti ada modul mampatan nyala dalam laluan kelas. Secara lalai, ia terletak dalam pengedaran Apache Ignite dalam direktori lib/pilihan dan tidak termasuk dalam laluan kelas. Anda hanya boleh mengalihkan direktori ke atas satu tahap ke lib dan kemudian apabila anda menjalankannya melalui ignite.sh ia akan didayakan secara automatik.
- Kegigihan mesti didayakan (Didayakan melalui
DataRegionConfiguration.setPersistenceEnabled(true)). - Mod mampatan mesti ditetapkan menggunakan kaedah tersebut
DataStorageConfiguration.setWalPageCompression(), mampatan dinyahdayakan secara lalai (mod DISABLED). - Secara pilihan, anda boleh menetapkan tahap mampatan menggunakan kaedah tersebut
DataStorageConfiguration.setWalPageCompression(), lihat javadoc untuk kaedah untuk nilai yang sah untuk setiap mod.
Kesimpulan
Mekanisme pemampatan data yang dipertimbangkan dalam Apache Ignite boleh digunakan secara berasingan antara satu sama lain, tetapi sebarang kombinasi daripadanya juga boleh diterima. Memahami cara ia berfungsi akan membolehkan anda menentukan sejauh mana ia sesuai untuk tugas anda dalam persekitaran anda dan perkara yang anda perlu korbankan apabila menggunakannya. Pemampatan halaman cakera direka untuk memampatkan storan utama dan boleh memberikan nisbah mampatan sederhana. Pemampatan petikan halaman WAL akan memberikan tahap pemampatan purata untuk fail WAL, dan kemungkinan besar akan meningkatkan prestasi. Pemadatan WAL tidak akan memberi kesan positif ke atas prestasi, tetapi akan mengurangkan saiz fail WAL sebanyak mungkin dengan mengalih keluar rekod fizikal.
Sumber: www.habr.com