جڏهن ڊيٽا جي وڏي مقدار سان ڪم ڪري، ڊسڪ اسپيس جي کوٽ جو مسئلو ڪڏهن ڪڏهن پيدا ٿي سگهي ٿو. هن مسئلي کي حل ڪرڻ جو هڪ طريقو آهي کمپريشن، جنهن جي مهرباني، ساڳئي سامان تي، توهان اسٽوريج جي مقدار کي وڌائڻ جي برداشت ڪري سگهو ٿا. هن آرٽيڪل ۾، اسان ڏسنداسين ته ڊيٽا ڪمپريشن ڪيئن ڪم ڪري ٿي Apache Ignite ۾. هي آرٽيڪل صرف بيان ڪندو ڊسڪ ڪمپريشن طريقن جي پيداوار اندر لاڳو ٿيل. ڊيٽا ڪمپريشن جا ٻيا طريقا (نيٽ ورڪ تي، ياداشت ۾)، ڇا لاڳو ٿئي ٿو يا نه، دائري کان ٻاهر رهندو.
تنهن ڪري، استقامت واري موڊ کي فعال ڪرڻ سان، ڪيش ۾ ڊيٽا ۾ تبديلين جي نتيجي ۾، Ignite ڊسڪ ڏانهن لکڻ شروع ڪري ٿو:
- ڪيش جو مواد
- اڳيان لاگ لکو (هتي صرف WAL)
ھاڻي ڪافي عرصي کان WAL ڪمپريشن لاءِ ھڪ ميکانيزم موجود آھي، جنھن کي WAL compaction چئبو آھي. تازو جاري ڪيل Apache Ignite 2.8 ٻه وڌيڪ ميڪانيزم متعارف ڪرايا جيڪي توهان کي ڊسڪ تي ڊيٽا کي دٻائڻ جي اجازت ڏين ٿا: ڪيش جي مواد کي ڪمپريس ڪرڻ لاءِ ڊسڪ پيج ڪمپريشن ۽ WAL پيج سنيپ شاٽ ڪمپريشن ڪجھ WAL داخلائن کي دٻائڻ لاءِ. انهن ٽنهي ميڪانيزم بابت وڌيڪ تفصيل هيٺ ڏنل آهن.
ڊسڪ پيج ڪمپريشن
ڪيئن هن ڪم ڪندو
پهرين، اچو ته هڪ تمام مختصر نظر رکون ته ڪيئن Ignite ڊيٽا کي ذخيرو ڪري ٿو. صفحي جي ياداشت کي اسٽوريج لاءِ استعمال ڪيو ويندو آهي. صفحي جي سائيز نوڊ جي شروعات ۾ مقرر ڪئي وئي آھي ۽ بعد ۾ مرحلن تي تبديل نه ٿي ڪري سگھجي؛ پڻ، صفحي جي سائيز ٻن جي طاقت ۽ فائل سسٽم جي بلاڪ جي سائيز جي گھڻائي آھي. صفحا گهربل طور تي ڊسڪ مان رام ۾ لوڊ ڪيا ويا آهن؛ ڊسڪ تي ڊيٽا جي ماپ مختص ڪيل رام جي مقدار کان وڌيڪ ٿي سگھي ٿي. جيڪڏهن RAM ۾ ڪافي جاء نه آهي ته ڊسڪ مان هڪ صفحي کي لوڊ ڪرڻ لاء، پراڻي، وڌيڪ استعمال ٿيل صفحا RAM مان ڪڍيا ويندا.
ڊيٽا ڊسڪ تي هيٺ ڏنل شڪل ۾ محفوظ ڪئي وئي آهي: هر ڪيش گروپ جي هر ورهاڱي لاء هڪ الڳ فائل ٺاهي وئي آهي؛ هن فائل ۾، صفحا هڪ ٻئي کان پوء انڊيڪس جي ترتيب ۾ ظاهر ٿيندا آهن. مڪمل صفحي جي سڃاڻپ ڪندڙ فائل ۾ ڪيش گروپ جي سڃاڻپ ڪندڙ، ورهاڱي نمبر، ۽ صفحي جي انڊيڪس تي مشتمل آھي. اهڙيء طرح، مڪمل صفحي جي سڃاڻپ ڪندڙ کي استعمال ڪندي، اسان منفرد طور تي هر صفحي جي فائل ۾ فائل ۽ آفسيٽ جو اندازو لڳائي سگهون ٿا. توهان Apache Ignite Wiki آرٽيڪل ۾ پيجنگ ميموري بابت وڌيڪ پڙهي سگهو ٿا: .
ڊسڪ پيج ڪمپريشن ميڪانيزم، جيئن توھان نالو مان اندازو لڳائي سگھو ٿا، صفحي جي سطح تي ڪم ڪري ٿو. جڏهن هن ميڪانيزم کي فعال ڪيو ويندو آهي، RAM ۾ ڊيٽا کي پروسيس ڪيو ويندو آهي، بغير ڪنهن ڪمپريشن، پر جڏهن صفحا محفوظ ڪيا ويندا آهن RAM کان ڊسڪ تائين، انهن کي دٻايو ويندو آهي.
پر هر صفحي کي انفرادي طور تي دٻائڻ مسئلي جو حل ناهي؛ توهان کي ڪنهن به طريقي سان نتيجن جي ڊيٽا فائلن جي سائيز کي گهٽائڻ جي ضرورت آهي. جيڪڏهن صفحي جي سائيز هاڻي مقرر نه ڪئي وئي آهي، اسان هاڻي هڪ ٻئي کان پوء فائل ۾ صفحا نه ٿا لکي سگهون، ڇو ته اهو ڪيترائي مسئلا پيدا ڪري سگهي ٿو:
- صفحي جي انڊيڪس کي استعمال ڪندي، اسان آفسيٽ کي ڳڻڻ جي قابل نه ھونداسين جنھن جي ذريعي اھو فائل ۾ واقع آھي.
- اهو واضح ناهي ته انهن صفحن سان ڇا ڪجي جيڪي فائل جي آخر ۾ نه آهن ۽ انهن جي سائيز کي تبديل ڪن. جيڪڏهن صفحي جي سائيز گھٽجي ٿي، ان جي خالي ڪيل جاء غائب ٿي ويندي. جيڪڏھن صفحي جي سائيز وڌي ٿي، توھان کي ان لاءِ فائل ۾ نئين جڳھ ڳولڻ جي ضرورت آھي.
- جيڪڏهن هڪ صفحو ڪيترن ئي بائيٽن سان هلي ٿو جيڪو فائل سسٽم بلاڪ جي سائيز جو هڪ کان وڌيڪ نه آهي، پوء ان کي پڙهڻ يا لکڻ لاء هڪ وڌيڪ فائل سسٽم بلاڪ کي ڇڪڻ جي ضرورت پوندي، جيڪو ڪارڪردگي جي خراب ٿيڻ جي ڪري سگھي ٿو.
انهن مسئلن کي پنهنجي سطح تي حل ڪرڻ کان بچڻ لاءِ، Apache Ignite ۾ ڊسڪ پيج ڪمپريشن هڪ فائيل سسٽم ميکانيزم استعمال ڪري ٿو جنهن کي اسپارس فائلون سڏيو ويندو آهي. هڪ اسپارس فائل هڪ آهي جنهن ۾ ڪجهه صفر ڀريل علائقن کي "سوراخ" طور نشان لڳايو وڃي ٿو. انهي صورت ۾، انهن سوراخن کي ذخيرو ڪرڻ لاء ڪو به فائيل سسٽم بلاڪ مختص نه ڪيو ويندو، نتيجي ۾ ڊسڪ اسپيس تي بچت.
اهو منطقي آهي ته فائيل سسٽم بلاڪ کي آزاد ڪرڻ لاء، سوراخ جي سائيز فائل سسٽم بلاڪ کان وڌيڪ يا برابر هجڻ گهرجي، جيڪو صفحي جي سائيز تي اضافي حد لاڳو ڪري ٿو ۽ Apache Ignite: ڪمپريشن لاء ڪو به اثر، صفحي جي سائيز فائل سسٽم بلاڪ جي سائيز کان سختي سان وڏي هجڻ گهرجي. جيڪڏهن صفحي جي سائيز بلاڪ جي سائيز جي برابر آهي، ته پوء اسين ڪڏهن به هڪ بلاڪ کي آزاد ڪرڻ جي قابل نه هوندا، ڇاڪاڻ ته هڪ بلاڪ کي آزاد ڪرڻ لاء، کمپريس ٿيل صفحي کي 0 بائيٽ تي قبضو ڪرڻ گهرجي. جيڪڏهن صفحي جي سائيز 2 يا 4 بلاڪ جي سائيز جي برابر آهي، اسان اڳ ۾ ئي گهٽ ۾ گهٽ هڪ بلاڪ کي آزاد ڪرڻ جي قابل ٿي سگهنداسين، جيڪڏهن اسان جو صفحو گهٽ ۾ گهٽ 50٪ يا 75٪ تائين دٻايو وڃي ٿو.
اهڙيء طرح، آخري وضاحت ڪيئن ميڪانيزم ڪم ڪري ٿو: جڏهن هڪ صفحي کي ڊسڪ ۾ لکندو آهي، هڪ ڪوشش ڪئي وئي آهي صفحي کي دٻائڻ جي. جيڪڏهن ڪمپريس ٿيل پيج جي سائيز هڪ يا وڌيڪ فائل سسٽم بلاڪ کي آزاد ڪرڻ جي اجازت ڏئي ٿي، ته پوءِ صفحو کمپريس ٿيل فارم ۾ لکيو ويندو آهي، ۽ آزاد ٿيل بلاڪ جي جاءِ تي هڪ ”سوراخ“ ڪيو ويندو آهي (هڪ سسٽم ڪال تي عمل ڪيو ويندو آهي. fallocate() پنچ سوراخ جي پرچم سان). جيڪڏهن ڪمپريس ٿيل پيج جي سائيز بلاڪ کي آزاد ٿيڻ جي اجازت نه ڏئي، صفحو محفوظ ڪيو ويندو آهي جيئن آهي، غير ٺهيل. سڀ پيج آف سيٽ حساب ڪيا ويندا آهن ساڳيءَ طرح جيئن بغير ڪمپريشن جي، صفحي جي انڊيڪس کي صفحي جي سائيز سان ضرب ڪندي. توهان جي طرفان صفحن جي ڪنهن به منتقلي جي ضرورت ناهي. صفحو آفسيٽس، جھڙوڪ بغير بغير، فائل سسٽم بلاڪ جي حدن تي گر.
موجوده عمل ۾، Ignite صرف لينڪس OS تحت اسپارس فائلن سان ڪم ڪري سگھي ٿو؛ ان جي مطابق، ڊسڪ پيج ڪمپريشن صرف ان وقت فعال ٿي سگھي ٿو جڏھن ھن آپريٽنگ سسٽم تي Ignite استعمال ڪيو وڃي.
ڪمپريشن الگورتھم جيڪي استعمال ڪري سگھجن ٿيون ڊسڪ پيج ڪمپريشن لاءِ: ZSTD، LZ4، Snappy. ان کان علاوه، اتي ھڪڙو آپريٽنگ موڊ (SKIP_GARBAGE) آھي، جنھن ۾ صفحي ۾ صرف غير استعمال ٿيل جڳھ کي ٻاھر ڪڍيو ويندو آھي باقي ڊيٽا تي ڪمپريشن لاڳو ڪرڻ کان سواء، جيڪو اڳئين درج ٿيل الگورتھم جي مقابلي ۾ سي پي يو تي لوڊ گھٽائي ٿو.
ڪارڪردگي جو اثر
بدقسمتي سان، مون حقيقي اسٽينڊن تي حقيقي ڪارڪردگي جي ماپ تي عمل نه ڪيو، ڇو ته اسان هن ميڪانيزم کي پيداوار ۾ استعمال ڪرڻ جو منصوبو نه ٿا ڪريون، پر اسان نظرياتي طور تي اندازو لڳائي سگهون ٿا ته اسان ڪٿي وڃائينداسين ۽ ڪٿي کٽينداسين.
هن کي ڪرڻ لاء، اسان کي ياد رکڻ جي ضرورت آهي ته ڪئين صفحا پڙهي ۽ لکيا ويندا آهن جڏهن رسائي حاصل ڪئي ويندي آهي:
- جڏهن پڙهڻ واري عمل کي انجام ڏيو، اهو پهريون ڀيرو RAM ۾ ڳولهيو ويندو آهي؛ جيڪڏهن ڳولا ناڪام ٿئي ٿي، صفحي کي ڊسڪ مان RAM ۾ لوڊ ڪيو ويندو آهي ساڳئي ٿلهي ذريعي جيڪو پڙهڻ کي انجام ڏئي ٿو.
- جڏهن لکڻ جي عمل کي انجام ڏنو ويندو آهي، RAM ۾ صفحو گندي طور تي نشان لڳل آهي، پر اهو صفحو جسماني طور تي ڊسڪ ۾ محفوظ نه ڪيو ويو آهي فوري طور تي لکڻ جي سلسلي ذريعي. سڀئي گندا صفحا ڊسڪ ۾ محفوظ ڪيا ويا آهن بعد ۾ چيڪ پوائنٽ جي عمل ۾ الڳ الڳ موضوعن ۾.
تنهن ڪري پڙهڻ جي عملن تي اثر آهي:
- مثبت (ڊسڪ IO)، پڙهڻ واري فائل سسٽم بلاڪ جي تعداد ۾ گهٽتائي جي ڪري.
- ناڪاري (سي پي يو)، اسپارس فائلن سان ڪم ڪرڻ لاءِ آپريٽنگ سسٽم طرفان گهربل اضافي لوڊ جي ڪري. اهو پڻ ممڪن آهي ته اضافي IO آپريشن واضح طور تي هتي ظاهر ٿيندا هڪ وڌيڪ پيچيده اسپارس فائل جي ڍانچي کي بچائڻ لاءِ (بدقسمتي سان، مان سڀني تفصيلن کان واقف نه آهيان ته اسپارس فائلون ڪيئن ڪم ڪن ٿيون).
- ناڪاري (سي پي يو)، صفحن کي ختم ڪرڻ جي ضرورت جي ڪري.
- لکڻ جي عملن تي ڪو به اثر نه آهي.
- چيڪ پوائنٽ جي عمل تي اثر (هتي هر شي پڙهڻ جي عملن وانگر آهي):
- مثبت (ڊسڪ IO)، لکت واري فائيل سسٽم بلاڪ جي تعداد ۾ گهٽتائي جي ڪري.
- ناڪاري (سي پي يو، ممڪن طور تي ڊسڪ IO)، اسپارس فائلن سان ڪم ڪرڻ جي ڪري.
- ناڪاري (سي پي يو)، صفحي جي ڪمپريشن جي ضرورت جي ڪري.
ماپ جو ڪهڙو پاسو ماپ کي ٽپ ڏيندو؟ اهو سڀ ڪجهه ماحول تي منحصر آهي، پر مان سمجهان ٿو ته ڊسڪ پيج ڪمپريشن گهڻو ڪري اڪثر سسٽم تي ڪارڪردگي جي خراب ٿيڻ جو سبب بڻجندو. ان کان علاوه، ٻين DBMSs تي ٽيسٽ جيڪي اسپارس فائلن سان ساڳي طريقي سان استعمال ڪندا آھن ڪارڪردگي ۾ گھٽتائي ڏيکاريندي آھي جڏھن ڪمپريشن فعال آھي.
ڪيئن فعال ۽ ترتيب ڏيڻ
جيئن مٿي ذڪر ڪيو ويو آهي، Apache Ignite جو گهٽ ۾ گهٽ نسخو جيڪو سپورٽ ڪري ٿو ڊسڪ پيج ڪمپريشن 2.8 آهي ۽ صرف لينڪس آپريٽنگ سسٽم سپورٽ آهي. ھيٺ ڏنل طور تي فعال ۽ ترتيب ڏيو:
- ڪلاس واٽ ۾ هڪ ignite-compression module هجڻ ضروري آهي. ڊفالٽ طور، اهو Libs/اختياري ڊاريڪٽري ۾ Apache Ignite distribution ۾ واقع آهي ۽ ڪلاس-پاٿ ۾ شامل نه آهي. توھان آساني سان ڊاريڪٽري کي ھڪڙي سطح تي libs ڏانھن منتقل ڪري سگھو ٿا ۽ پوءِ جڏھن توھان ان کي ignite.sh ذريعي هلائيندا ته اھو پاڻمرادو فعال ٿي ويندو.
- استقامت کي فعال ڪيو وڃي (فعال ذريعي
DataRegionConfiguration.setPersistenceEnabled(true)). - صفحي جي سائيز فائل سسٽم بلاڪ جي سائيز کان وڏي هجڻ گهرجي (توهان ان کي استعمال ڪندي سيٽ ڪري سگهو ٿا
DataStorageConfiguration.setPageSize()). - هر ڪيش لاءِ جنهن جي ڊيٽا کي دٻائڻ جي ضرورت آهي، توهان کي ڪمپريشن جو طريقو ترتيب ڏيڻ گهرجي ۽ (اختياري طور تي) ڪمپريشن ليول (طريقن)
CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).
WAL compaction
ڪيئن هن ڪم ڪندو
WAL ڇا آهي ۽ ان جي ضرورت ڇو آهي؟ تمام مختصر طور: هي هڪ لاگ آهي جنهن ۾ سڀئي واقعا شامل آهن جيڪي آخرڪار صفحي جي اسٽوريج کي تبديل ڪن ٿا. اهو بنيادي طور تي ضروري آهي ته زوال جي صورت ۾ بحال ڪرڻ جي قابل ٿي. ڪنهن به آپريشن، صارف کي ڪنٽرول ڏيڻ کان اڳ، پهريان WAL ۾ واقعا رڪارڊ ڪرڻ ضروري آهي، ته جيئن ناڪامي جي صورت ۾، ان کي واپس لاگ ۾ ادا ڪري سگهجي ۽ سڀني عملن کي بحال ڪري سگهجي، جنهن لاءِ صارف کي ڪامياب جواب ملي، جيتوڻيڪ اهي آپريشنز ڊسڪ تي صفحي جي اسٽوريج ۾ ظاهر ٿيڻ جو وقت نه هو (اڳ ۾ ئي مٿي بيان ڪيو ويو آهي ته صفحي جي دڪان تي اصل لکڻ هڪ عمل ۾ ڪيو ويندو آهي "چيڪ پوائنٽنگ" نالي سان الڳ موضوعن سان ڪجهه دير سان).
WAL ۾ داخلائون منطقي ۽ جسماني ۾ ورهايل آھن. Boolean آهن ڪنجيون ۽ قدر پاڻ کي. جسماني - صفحي جي دڪان ۾ صفحن ۾ تبديلين کي ظاهر ڪري ٿو. جڏهن ته منطقي رڪارڊ ڪجهه ٻين ڪيسن لاءِ ڪارآمد ٿي سگهن ٿا، جسماني رڪارڊ صرف حادثي جي صورت ۾ بحاليءَ لاءِ گهربل هوندا آهن ۽ رڪارڊ صرف آخري ڪامياب چيڪ پوائنٽ کان ئي گهربل هوندا آهن. هتي اسان تفصيل ۾ نه وينداسين ۽ وضاحت ڪنداسين ته اهو هن طريقي سان ڇو ڪم ڪري ٿو، پر جيڪي دلچسپي وٺن ٿا انهن کي Apache Ignite Wiki تي اڳ ۾ ذڪر ڪيل مضمون جو حوالو ڏئي سگهي ٿو: .
اتي اڪثر ڪيترائي جسماني رڪارڊ في منطقي رڪارڊ آهن. اهو آهي، مثال طور، ڪيش ۾ هڪ لڳائڻ وارو عمل ڪيترن ئي صفحن کي متاثر ڪري ٿو صفحي جي ميموري ۾ (هڪ صفحو پاڻ سان گڏ ڊيٽا، صفحا انڊيڪس سان، صفحا مفت فهرستن سان). ڪجھ مصنوعي تجربن ۾، مون ڏٺو ته جسماني رڪارڊ WAL فائل جي 90٪ تائين قبضو ڪيو. بهرحال، انهن کي تمام مختصر وقت جي ضرورت آهي (ڊفالٽ طور، چيڪ پوسٽن جي وچ ۾ وقفو 3 منٽ آهي). اهو منطقي هوندو ته هن ڊيٽا مان نجات حاصل ڪرڻ کان پوء ان جي لاڳاپي کي وڃائڻ کان پوء. اهو ئي آهي جيڪو WAL ڪمپيشن ميڪانيزم ڪندو آهي: اهو جسماني رڪارڊ مان نجات حاصل ڪري ٿو ۽ زپ استعمال ڪندي باقي منطقي رڪارڊ کي دٻائي ٿو، جڏهن ته فائل جي سائيز تمام گهڻو گهٽجي ويندي آهي (ڪڏهن ڪڏهن ڏهن ڀيرا).
جسماني طور تي، WAL ڪيترن ئي حصن تي مشتمل آهي (10 ڊفالٽ طور تي) هڪ مقرر ڪيل سائيز (64 ايم بي ڊفالٽ) جي، جن کي سرڪيولر انداز ۾ اوور رائٽ ڪيو ويو آهي. جيئن ئي موجوده ڀاڱو ڀريو ويندو آهي، ايندڙ ڀاڱو موجوده طور تي لڳايو ويندو آهي، ۽ ڀريل ڀاڱو هڪ الڳ سلسلي ذريعي آرڪائيو ڏانهن نقل ڪيو ويندو آهي. WAL compaction اڳ ۾ ئي آرڪائيو حصن سان ڪم ڪري ٿو. انهي سان گڏ، هڪ الڳ موضوع جي طور تي، اهو چيڪ پوائنٽ جي عمل جي نگراني ڪري ٿو ۽ آرڪائيو حصن ۾ کمپريشن شروع ٿئي ٿو جنهن لاء جسماني رڪارڊ جي ضرورت ناهي.
ڪارڪردگي جو اثر
جيئن ته WAL ڪمپيڪشن هڪ الڳ ٿريڊ طور هلندي آهي، ان ڪري عملن تي ڪو به سڌو اثر نه پوندو. پر اهو اڃا تائين سي پي يو (ڪمپريشن) ۽ ڊسڪ تي اضافي پس منظر وارو لوڊ رکي ٿو (آرڪائيو مان هر WAL سيگمينٽ کي پڙهڻ ۽ ڪمپريس ٿيل حصن کي لکڻ)، تنهن ڪري جيڪڏهن سسٽم پنهنجي وڌ ۾ وڌ گنجائش تي هلندو آهي، اهو پڻ ڪارڪردگي جي خراب ٿيڻ جو سبب بڻجندو.
ڪيئن فعال ۽ ترتيب ڏيڻ
توھان ملڪيت کي استعمال ڪندي WAL compaction کي فعال ڪري سگھو ٿا WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). انهي سان گڏ، DataStorageConfiguration.setWalCompactionLevel() طريقو استعمال ڪندي، توهان ڪمپريشن ليول سيٽ ڪري سگهو ٿا جيڪڏهن توهان ڊفالٽ قيمت (BEST_SPEED) سان مطمئن نه آهيو.
WAL صفحو سنيپ شاٽ ڪمپريشن
ڪيئن هن ڪم ڪندو
اسان اڳ ۾ ئي معلوم ڪيو آهي ته WAL ۾ رڪارڊ منطقي ۽ جسماني ۾ ورهايل آهن. هر صفحي تي هر تبديلي لاء، هڪ جسماني WAL رڪارڊ ٺاهي وئي آهي صفحي جي ياداشت ۾. جسماني رڪارڊ، موڙ ۾، پڻ ورهايل آهن 2 ذيلي قسمون: صفحو سنيپ شاٽ رڪارڊ ۽ ڊيلٽا رڪارڊ. هر دفعي جڏهن اسان ڪنهن صفحي تي ڪا شيءِ تبديل ڪندا آهيون ۽ ان کي صاف حالت مان گندي حالت ۾ منتقل ڪندا آهيون، ته هن صفحي جي مڪمل ڪاپي WAL (صفحو سنيپ شاٽ رڪارڊ) ۾ محفوظ ڪئي ويندي آهي. جيتوڻيڪ اسان WAL ۾ صرف هڪ بائيٽ تبديل ڪيو، رڪارڊ صفحي جي سائيز کان ٿورو وڏو ٿيندو. جيڪڏهن اسان اڳ ۾ ئي گندي صفحي تي ڪا شيءِ تبديل ڪريون ٿا، ته WAL ۾ ڊيلٽا رڪارڊ ٺهي ٿو، جيڪو صفحي جي پوئين حالت جي مقابلي ۾ رڳو تبديلين کي ظاهر ڪري ٿو، پر پوري صفحي جي نه. جيئن ته صفحن جي حالت کي گندي کان صاف ڪرڻ لاءِ ري سيٽ ڪرڻ چيڪ پوائنٽ جي عمل دوران ڪيو ويندو آهي، چيڪ پوائنٽ جي شروعات کان فوري طور تي، تقريبن سڀئي جسماني رڪارڊ صرف صفحن جي تصويرن تي مشتمل هوندا (جيئن ته چيڪ پوائنٽ جي شروعات کان فوري طور تي سڀئي صفحا صاف آهن) ، پوءِ جيئن اسان ايندڙ چيڪ پوائنٽ تي پهچون ٿا، ڊيلٽا رڪارڊ جو حصو وڌڻ شروع ٿئي ٿو ۽ ايندڙ چيڪ پوائنٽ جي شروعات ۾ ٻيهر سيٽ ڪيو وڃي. ڪجھ مصنوعي تجربن ۾ ماپون ڏيکاريا ويا آھن ته صفحي جي سنيپ شاٽ جو حصو جسماني رڪارڊ جي ڪل مقدار ۾ 90٪ تائين پھچندو آھي.
WAL پيج سنيپ شاٽ ڪمپريشن جو خيال آهي صفحو سنيپ شاٽ کي ڪمپريشن ڪرڻ لاءِ تيار ٿيل پيج ڪمپريشن ٽول استعمال ڪندي (ڏسو ڊسڪ پيج ڪمپريشن). ساڳئي وقت، WAL ۾، رڪارڊ ترتيبوار طور تي صرف اپينڊ موڊ ۾ محفوظ ڪيا ويندا آهن ۽ فائل سسٽم بلاڪ جي حدن سان رڪارڊ کي پابند ڪرڻ جي ڪا ضرورت ناهي، تنهنڪري هتي، ڊسڪ پيج ڪمپريشن ميڪانيزم جي برعڪس، اسان کي اسپارس فائلن جي ضرورت ناهي. سڀ؛ مطابق، هي ميکانيزم نه رڳو او ايس لينڪس تي ڪم ڪندو. ان کان علاوه، اهو هاڻي اسان لاء اهم ناهي ته اسان صفحي کي ڪيئن دٻائڻ جي قابل هئاسين. جيتوڻيڪ اسان 1 بائيٽ کي آزاد ڪيو، اهو اڳ ۾ ئي هڪ مثبت نتيجو آهي ۽ اسان ڊسڪ پيج جي ڪمپريشن جي برعڪس، WAL ۾ ڪمپريس ٿيل ڊيٽا محفوظ ڪري سگهون ٿا، جتي اسان ڪمپريس ٿيل پيج کي صرف ان صورت ۾ محفوظ ڪريون ٿا جڏهن اسان 1 کان وڌيڪ فائل سسٽم بلاڪ کي آزاد ڪيو.
صفحا ڏاڍا دٻائڻ وارا ڊيٽا آهن، انهن جو ڪل WAL حجم ۾ حصو تمام گهڻو آهي، تنهنڪري WAL فائل فارميٽ کي تبديل ڪرڻ کان سواءِ اسان ان جي سائيز ۾ وڏي گهٽتائي حاصل ڪري سگهون ٿا. کمپريشن، بشمول منطقي رڪارڊ، فارميٽ ۾ تبديلي ۽ مطابقت جي نقصان جي ضرورت پوندي، مثال طور، ٻاهرين صارفين لاءِ جيڪي شايد منطقي رڪارڊن ۾ دلچسپي رکن ٿا، پر فائل جي سائيز ۾ وڏي گھٽتائي جو سبب نه بڻجندا.
جيئن ڊسڪ پيج ڪمپريشن سان، WAL پيج سنيپ شاٽ ڪمپريشن ZSTD، LZ4، سنيپي ڪمپريشن الگورتھم، ۽ گڏوگڏ SKIP_GARBAGE موڊ استعمال ڪري سگھن ٿا.
ڪارڪردگي جو اثر
اهو نوٽ ڪرڻ ڏکيو ناهي ته WAL پيج سنيپ شاٽ ڪمپريشن کي سڌو سنئون فعال ڪرڻ صرف انهن ٿريڊن کي متاثر ڪري ٿو جيڪي ڊيٽا کي صفحي جي ميموري ۾ لکن ٿا، يعني اهي ٿريڊ جيڪي ڪيش ۾ ڊيٽا تبديل ڪن ٿا. WAL کان جسماني رڪارڊ پڙهڻ صرف هڪ ڀيرو ٿئي ٿو، هن وقت نوڊ زوال کان پوء بلند ڪيو ويو آهي (۽ صرف جيڪڏهن اهو هڪ چيڪ پوائنٽ دوران پوي ٿو).
اهو انهن سلسلين تي اثر انداز ٿئي ٿو جيڪي ڊيٽا کي هيٺين طريقي سان تبديل ڪن ٿا: اسان کي منفي اثر (سي پي يو) حاصل ٿئي ٿو ڇاڪاڻ ته هر دفعي ڊسڪ تي لکڻ کان اڳ صفحي کي دٻائڻ جي ضرورت آهي، ۽ هڪ مثبت اثر (ڊسڪ IO) جي مقدار ۾ گهٽتائي سبب. ڊيٽا لکيو ويو آهي. ان جي مطابق، هتي سڀ ڪجهه سادو آهي: جيڪڏهن سسٽم جي ڪارڪردگي سي پي يو طرفان محدود آهي، اسان کي ٿوري خرابي ملي ٿي، جيڪڏهن اهو ڊسڪ I/O تائين محدود آهي، اسان کي وڌايو وڃي ٿو.
اڻ سڌي طرح، WAL سائيز کي گھٽائڻ پڻ (مثبت طور تي) اسٽريمز کي متاثر ڪري ٿو جيڪي WAL حصن کي آرڪائيو ۽ WAL ڪمپيشن اسٽريمز ۾ ڊمپ ڪن ٿا.
مصنوعي ڊيٽا استعمال ڪندي اسان جي ماحول ۾ حقيقي ڪارڪردگي جا تجربا ٿورڙي واڌ ڏيکاريا (ذريعو وڌايو ويو 10٪ -15٪، دير جي گھٽتائي 10٪ -15٪).
ڪيئن فعال ۽ ترتيب ڏيڻ
گھٽ ۾ گھٽ Apache Ignite ورجن: 2.8. ھيٺ ڏنل طور تي فعال ۽ ترتيب ڏيو:
- ڪلاس واٽ ۾ هڪ ignite-compression module هجڻ ضروري آهي. ڊفالٽ طور، اهو Libs/اختياري ڊاريڪٽري ۾ Apache Ignite distribution ۾ واقع آهي ۽ ڪلاس-پاٿ ۾ شامل نه آهي. توھان آساني سان ڊاريڪٽري کي ھڪڙي سطح تي libs ڏانھن منتقل ڪري سگھو ٿا ۽ پوءِ جڏھن توھان ان کي ignite.sh ذريعي هلائيندا ته اھو پاڻمرادو فعال ٿي ويندو.
- استقامت کي فعال ڪيو وڃي (فعال ذريعي
DataRegionConfiguration.setPersistenceEnabled(true)). - ڪمپريشن موڊ جو طريقو استعمال ڪندي سيٽ ڪيو وڃي
DataStorageConfiguration.setWalPageCompression()، ڪمپريشن ڊفالٽ طور بند ٿيل آھي (DISABLED mode). - اختياري طور تي، توهان طريقي سان استعمال ڪندي ڪمپريشن سطح سيٽ ڪري سگهو ٿا
DataStorageConfiguration.setWalPageCompression()، هر موڊ لاءِ صحيح قدرن لاءِ طريقي لاءِ جاواڊڪ ڏسو.
ٿڪل
Apache Ignite ۾ سمجهيل ڊيٽا ڪمپريشن ميڪانيزم هڪ ٻئي کان آزاد طور تي استعمال ڪري سگھجن ٿا، پر انهن جو ڪو ميلاپ پڻ قابل قبول آهي. سمجھڻ سان اهي ڪيئن ڪم ڪن ٿا توهان کي اهو طئي ڪرڻ جي اجازت ڏيندو ته اهي توهان جي ماحول ۾ توهان جي ڪمن لاءِ ڪيترا مناسب آهن ۽ انهن کي استعمال ڪرڻ وقت توهان کي ڪهڙي قرباني ڏيڻي پوندي. ڊسڪ پيج ڪمپريشن ٺهيل آهي مکيه اسٽوريج کي دٻائڻ لاءِ ۽ هڪ وچولي ڪمپريشن تناسب ڏئي سگهي ٿو. WAL پيج سنيپ شاٽ ڪمپريشن WAL فائلن لاءِ اوسط درجو ڪمپريشن ڏيندو، ۽ غالباً ڪارڪردگي بھتر ڪندو. WAL compaction ڪارڪردگي تي مثبت اثر نه ڏيندو، پر جسماني رڪارڊ کي هٽائڻ سان WAL فائلن جي سائيز کي گھٽائي ڇڏيندو.
جو ذريعو: www.habr.com