کله چې د ډیټا لوی مقدار سره کار کول ، د ډیسک ځای نشتوالي ستونزه ځینې وختونه رامینځته کیدی شي. د دې ستونزې د حل کولو یوه لاره کمپریشن دی، له دې څخه مننه، په ورته تجهیزاتو کې، تاسو کولی شئ د ذخیره کولو حجم زیات کړئ. پدې مقاله کې، موږ به وګورو چې څنګه د ډیټا کمپریشن په اپاچي ایګنیټ کې کار کوي. دا مقاله به یوازې د ډیسک کمپریشن میتودونه تشریح کړي چې په محصول کې پلي شوي. د ډیټا کمپریشن نور میتودونه (په شبکه کې، په حافظه کې)، که پلي شوي وي یا نه، د ساحې څخه بهر پاتې کیږي.
نو، د دوام حالت فعالولو سره، په کیچونو کې د معلوماتو بدلونونو په پایله کې، Ignite ډیسک ته لیکل پیل کوي:
- د زیرمو منځپانګې
- مخکینۍ لاګ ولیکئ (له دې وروسته په ساده ډول WAL)
د اوږدې مودې لپاره د WAL کمپریشن لپاره میکانیزم شتون لري، چې د WAL کمپریشن په نوم یادیږي. په دې وروستیو کې خپور شوي اپاچي ایګنیټ 2.8 دوه نور میکانیزمونه معرفي کړل چې تاسو ته اجازه درکوي په ډیسک کې ډیټا کمپریس کړئ: د کیچ مینځپانګې کمپریشن کولو لپاره د ډیسک پا pageې کمپریشن او د ځینې WAL ننوتلو کمپریس کولو لپاره د WAL پا pageې سنیپ شاټ کمپریشن. لاندې د دې ټولو دریو میکانیزمونو په اړه نور توضیحات.
د ډیسک پاڼې کمپریشن
دا څنګه کار کوي؟
لومړی، راځئ چې یو ډیر لنډ نظر وکړو چې څنګه Ignite ډاټا ذخیره کوي. د پاڼې حافظه د ذخیره کولو لپاره کارول کیږي. د پاڼې اندازه د نوډ په پیل کې ټاکل شوې او په وروستیو مرحلو کې نشي بدلیدلی؛ همدارنګه، د پاڼې اندازه باید د دوه ځواک او د فایل سیسټم بلاک اندازې څو څو وي. پاڼې د اړتیا په صورت کې له ډیسک څخه رام ته پورته کیږي؛ په ډیسک کې د ډیټا اندازه ممکن د تخصیص شوي رام مقدار څخه ډیر وي. که چیرې په RAM کې د ډیسک څخه د پاڼې پورته کولو لپاره کافي ځای شتون ونلري، زاړه، نور نه کارول شوي پاڼې به له رام څخه ویستل شي.
ډیټا په ډیسک کې په لاندې شکل کې زیرمه کیږي: د هرې کیش ګروپ هرې برخې لپاره جلا فایل رامینځته کیږي؛ پدې فایل کې ، پا pagesې یو له بل څخه وروسته د شاخص په ترتیب سره څرګندیږي. د بشپړ پاڼې پیژندونکی په فایل کې د کیچ ګروپ پیژندونکی، د برخې شمیره، او د پاڼې شاخص لري. په دې توګه، د بشپړ پاڼې پیژندونکي په کارولو سره، موږ کولی شو د هرې پاڼې لپاره په فایل کې فایل او آفسیټ په ځانګړي ډول وټاکو. تاسو کولی شئ د اپاچي ایګنیټ ویکي مقاله کې د مخ کولو حافظې په اړه نور ولولئ: .
د ډیسک پاڼې کمپریشن میکانیزم، لکه څنګه چې تاسو د نوم څخه اټکل کولی شئ، د پاڼې په کچه کار کوي. کله چې دا میکانیزم فعال شي، په RAM کې ډاټا پرته له کوم فشار پرته پروسس کیږي، مګر کله چې پاڼې له RAM څخه ډیسک ته خوندي شي، دوی کمپریس کیږي.
مګر په انفرادي ډول د هرې پاڼې فشارول د ستونزې حل نه دی؛ تاسو اړتیا لرئ چې په یو ډول د پایلو ډاټا فایلونو اندازه کمه کړئ. که د پاڼې اندازه نوره ثابته نه شي، موږ نور نشو کولی چې یو له بل وروسته فایل ته پاڼې ولیکو، ځکه چې دا یو شمیر ستونزې رامینځته کولی شي:
- د پاڼې شاخص په کارولو سره، موږ به ونه توانیږو چې د آفسیټ محاسبه وکړو چې دا په فایل کې موقعیت لري.
- دا روښانه نده چې د هغو پاڼو سره څه وکړي چې د فایل په پای کې ندي او د دوی اندازه بدلوي. که د پاڼې اندازه کمه شي، هغه ځای چې دا یې خلاص کړی له منځه ځي. که د پاڼې اندازه زیاته شي، تاسو اړتیا لرئ چې د دې لپاره په فایل کې یو نوی ځای وګورئ.
- که یوه پاڼه د یو شمیر بایټونو په واسطه حرکت وکړي چې د فایل سیسټم بلاک اندازې ډیری نه وي، نو بیا لوستل یا لیکل به د یو بل فایل سیسټم بلاک لمس کولو ته اړتیا ولري، کوم چې د فعالیت د خرابیدو لامل کیدی شي.
د دې ستونزې په خپله کچه د حل کولو مخنیوي لپاره، په اپاچي ایګنیټ کې د ډیسک پاڼې کمپریشن د سپیر فایلونو په نوم د فایل سیسټم میکانیزم کاروي. سپیر فایل هغه دی چې په کې ځینې صفر ډکې سیمې د "سوري" په توګه نښه کیدی شي. په دې حالت کې، د فایل سیسټم بلاکونه به د دې سوراخونو ذخیره کولو لپاره تخصیص نشي، په پایله کې د ډیسک ځای خوندي کول.
دا منطقي ده چې د فایل سیسټم بلاک آزادولو لپاره، د سوري اندازه باید د فایل سیسټم بلاک څخه لوی یا مساوي وي، کوم چې د پاڼې په اندازې او اپاچی ایګنیټ باندې اضافي محدودیت وضع کوي: د فشار لپاره د کوم اغیز لپاره، د پاڼې اندازه باید د فایل سیسټم بلاک اندازې څخه په کلکه لویه وي. که د پاڼې اندازه د بلاک اندازې سره مساوي وي، نو موږ به هیڅکله د دې توان ونلرو چې یو بلاک آزاد کړو، ځکه چې د یو بلاک د خلاصولو لپاره، کمپریس شوی پاڼه باید 0 بایټس ونیسي. که د پاڼې اندازه د 2 یا 4 بلاکونو اندازه سره مساوي وي، موږ به لا دمخه د دې وړتیا ولرو چې لږترلږه یو بلاک خلاص کړو که چیرې زموږ پاڼه په ترتیب سره لږترلږه 50٪ یا 75٪ ته فشار ورکړي.
په دې توګه، د میکانیزم د کار کولو وروستی توضیحات: کله چې ډیسک ته پاڼه لیکل کیږي، د پاڼې د کمپرس کولو هڅه کیږي. که د کمپرس شوي پا pageې اندازه د یو یا ډیرو فایل سیسټم بلاکونو خوشې کولو ته اجازه ورکوي ، نو پاڼه په کمپریس شوي شکل کې لیکل کیږي ، او د آزاد شوي بلاکونو په ځای کې "سوري" رامینځته کیږي (د سیسټم کال اجرا کیږي. fallocate() د پنچ سوراخ بیرغ سره). که د کمپریس شوي پاڼې اندازه د بلاکونو خوشې کولو ته اجازه ورنکړي، پاڼه خوندي کیږي لکه څنګه چې وي، غیر کمپریس شوی. د پاڼې ټول آفسیټونه په ورته ډول محاسبه کیږي لکه د کمپریشن پرته، د پاڼې شاخص د پاڼې د اندازې په واسطه ضرب کولو سره. په خپله د مخونو ځای په ځای کولو ته اړتیا نشته. د پاڼې آفسیټونه، لکه د کمپریشن پرته، د فایل سیسټم بلاکونو په سرحدونو کې راځي.
په اوسني تطبیق کې، Ignite یوازې د لینوکس OS لاندې د سپینو فایلونو سره کار کولی شي؛ په وینا، د ډیسک پاڼې کمپریشن یوازې هغه وخت فعال کیدی شي کله چې په دې عملیاتي سیسټم کې Ignite کاروي.
د کمپریشن الګوریتمونه چې د ډیسک پاڼې کمپریشن لپاره کارول کیدی شي: ZSTD، LZ4، Snappy. برسېره پردې، یو عملیاتي حالت (SKIP_GARBAGE) شتون لري، په کوم کې چې په پاڼه کې یوازې غیر کارول شوي ځای په پاتې معلوماتو کې د کمپریشن پلي کولو پرته غورځول کیږي، کوم چې د مخکینۍ لیست شوي الګوریتمونو په پرتله په CPU کې بار کموي.
د فعالیت اغیزه
له بده مرغه، ما په ریښتیني موقفونو کې د حقیقي فعالیت اندازه نه ده ترسره کړې، ځکه چې موږ پالن نه لرو چې دا میکانیزم په تولید کې وکاروو، مګر موږ کولی شو په تیوریکي توګه اټکل وکړو چې موږ به چیرته له لاسه ورکړو او چیرته به وګټو.
د دې کولو لپاره، موږ باید په یاد ولرو چې څنګه پاڼې لوستل او لیکل کیږي کله چې لاسرسی ومومي:
- کله چې د لوستلو عملیات ترسره کیږي، دا لومړی په RAM کې پلټنه کیږي؛ که چیرې لټون ناکامه وي، پاڼه د ډیسک څخه رام ته د ورته تار په واسطه پورته کیږي چې لوستل ترسره کوي.
- کله چې د لیکلو عملیات ترسره کیږي، په RAM کې پاڼه د خندا په توګه نښه کیږي، مګر پاڼه په فزیکي توګه د لیکلو ترسره کولو د تار لخوا سمدلاسه ډیسک ته نه خوندي کیږي. ټولې ناپاکې پاڼې په جلا تارونو کې د پوستې پروسې کې وروسته ډیسک ته خوندي کیږي.
نو د لوستلو په عملیاتو اغیزه دا ده:
- مثبت (ډیسک IO) ، د لوستلو فایل سیسټم بلاکونو شمیر کې کمښت له امله.
- منفي (CPU)، د اضافي بار له امله چې د عملیاتي سیسټم لخوا د سپارس فایلونو سره کار کولو لپاره اړین دی. دا هم ممکنه ده چې اضافي IO عملیات به په ښکاره ډول دلته د یو ډیر پیچلي سپارس فایل جوړښت خوندي کولو لپاره ښکاره شي (له بده مرغه، زه د سپارس فایلونو د کار کولو ټولو جزیاتو سره بلد نه یم).
- منفي (CPU)، د مخونو د کمولو اړتیا له امله.
- د لیکلو په عملیاتو هیڅ اغیزه نلري.
- د پوستې په پروسه اغیزه (دلته هرڅه د لوستلو عملیاتو سره ورته دي):
- مثبت (ډیسک IO)، د لیکل شوي فایل سیسټم بلاکونو شمیر کې کمښت له امله.
- منفي (CPU، احتمالا ډیسک IO)، د سپیر فایلونو سره کار کولو له امله.
- منفي (CPU)، د پاڼې کمپریشن ته اړتیا له امله.
د پیمان کوم اړخ به پیمانه ټیټ کړي؟ دا ټول په چاپیریال پورې اړه لري، مګر زه په دې باور یم چې د ډیسک پاڼې کمپریشن به په ډیری سیسټمونو کې د فعالیت د خرابیدو لامل شي. سربیره پردې ، د نورو DBMSs ازموینې چې د سپک فایلونو سره ورته چلند کاروي کله چې کمپریشن فعال شي په فعالیت کې کمښت ښیې.
څنګه فعال او تنظیم کړئ
لکه څنګه چې پورته یادونه وشوه، د اپاچي ایګنیټ لږترلږه نسخه چې د ډیسک پاڼې کمپریشن ملاتړ کوي 2.8 دی او یوازې د لینکس عملیاتي سیسټم ملاتړ کیږي. په لاندې ډول فعال او تنظیم کړئ:
- د ټولګي په لاره کې باید د ignite-compression ماډل شتون ولري. په ډیفالټ کې، دا د اپاچي Ignite ویش کې د libs/اختیاري لارښود کې موقعیت لري او د ټولګي لارې کې شامل ندي. تاسو کولی شئ په ساده ډول ډایرکټر یو لیول پورته libs ته واړوئ او بیا کله چې تاسو یې د ignite.sh له لارې پرمخ وړئ دا به په اوتومات ډول فعال شي.
- دوام باید فعال شي (له لارې فعال شوی
DataRegionConfiguration.setPersistenceEnabled(true)). - د پاڼې اندازه باید د فایل سیسټم بلاک اندازې څخه لوی وي (تاسو کولی شئ دا په کارولو سره تنظیم کړئ
DataStorageConfiguration.setPageSize()). - د هرې زیرمې لپاره چې ډیټا باید فشار ته اړتیا ولري ، تاسو باید د کمپریشن میتود تنظیم کړئ او (اختیاري) د کمپریشن کچه (میتودونه)
CacheConfiguration.setDiskPageCompression() , CacheConfiguration.setDiskPageCompressionLevel()).
د وال کمپکشن
دا څنګه کار کوي؟
WAL څه شی دی او ولې ورته اړتیا ده؟ په لنډه توګه: دا یو لاګ دی چې ټول هغه پیښې لري چې په پای کې د پاڼې ذخیره بدلوي. دا په لومړي سر کې اړینه ده چې د سقوط په صورت کې د بیا رغونې وړ وي. هر عملیات، مخکې له دې چې کاروونکي ته کنټرول ورکړي، باید لومړی په WAL کې یوه پیښه ثبت کړي، ترڅو د ناکامۍ په صورت کې، دا بیرته په لاګ کې پلی شي او ټول هغه عملیات بیرته راولي چې کارونکي یې بریالي ځواب ترلاسه کړی، حتی که دا عملیات په ډیسک کې د پاڼې ذخیره کولو کې د منعکس کولو لپاره وخت نه درلود (مخکې له دې چې پورته تشریح شوي چې د پاڼې پلورنځي ته حقیقي لیکنه په داسې پروسه کې ترسره کیږي چې د "چیک پواینټ" په نوم یادیږي د جلا تارونو لخوا یو څه ځنډ سره).
په WAL کې ننوتل په منطقي او فزیکي ویشل شوي دي. بولین هغه کلیدي دي او پخپله ارزښت لري. فزیکي - د پاڼې ذخیره کې د پاڼو بدلون منعکس کوي. پداسې حال کې چې منطقي ریکارډونه د ځینو نورو قضیو لپاره ګټور کیدی شي، فزیکي ریکارډونه یوازې د حادثې په صورت کې د بیا رغونې لپاره اړین دي او ریکارډونه یوازې د وروستي بریالي پوستې راهیسې اړین دي. دلته به موږ په تفصیل کې نه ځو او تشریح کوو چې ولې دا دا کار کوي، مګر علاقمندان کولی شي د اپاچي ایګنیټ ویکي کې دمخه ذکر شوي مقالې ته مراجعه وکړي: .
په هر منطقي ریکارډ کې ډیری فزیکي ریکارډونه شتون لري. دا، د مثال په توګه، په کیچ کې یو ځای پرځای کول د پاڼې په حافظه کې څو پاڼې اغیزه کوي (یو پاڼه پخپله د ډاټا سره، پاڼې د شاخصونو سره، پاڼې د وړیا لیستونو سره). په ځینو مصنوعي ازموینو کې، ما وموندله چې فزیکي ریکارډونه د WAL فایل 90٪ پورې نیول شوي. په هرصورت، دوی د خورا لنډ وخت لپاره اړین دي (د ډیفالټ په واسطه، د پوستې ترمنځ وقفه 3 دقیقې ده). دا به منطقي وي چې د دې معلوماتو له لاسه ورکولو وروسته له دې څخه ځان خلاص کړئ. دا په حقیقت کې هغه څه دي چې د WAL کمپیکشن میکانیزم کوي: دا د فزیکي ریکارډونو څخه خلاصیږي او د زپ په کارولو سره پاتې منطقي ریکارډونه فشاروي، پداسې حال کې چې د فایل اندازه خورا د پام وړ کمه شوې (کله ناکله په لسګونو ځله).
په فزیکي توګه، WAL د ټاکل شوي اندازې (10MB لخوا په ډیفالټ) کې څو برخې لري (64 په ډیفالټ ډول) چې په سرکلر ډول لیکل کیږي. هرڅومره ژر چې اوسنۍ برخه ډکه شي ، بله برخه د اوسني په توګه ټاکل کیږي ، او ډکه شوې برخه د جلا تار په واسطه آرشیف ته کاپي کیږي. د WAL کمپیکشن دمخه د آرشیف برخو سره کار کوي. همچنان ، د جلا تار په توګه ، دا د پوستې اجرا کول څاري او د آرشیف برخو کې فشار پیل کوي د کوم لپاره چې فزیکي ریکارډونو ته نور اړتیا نشته.
د فعالیت اغیزه
څرنګه چې د WAL ترکیب د جلا تار په توګه تیریږي، نو باید په ترسره شوي عملیاتو مستقیم اغیزه ونلري. مګر دا لاهم په CPU (کمپریشن) او ډیسک کې اضافي شالید بار اچوي (د آرشیف څخه د WAL هرې برخې لوستل او کمپریس شوي برخې لیکل) ، نو که سیسټم په خپل اعظمي ظرفیت کې روان وي ، نو دا به د فعالیت تخریب لامل هم شي.
څنګه فعال او تنظیم کړئ
تاسو کولی شئ د ملکیت په کارولو سره د WAL کمپیکشن فعال کړئ WalCompactionEnabled в DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)). همدارنګه، د DataStorageConfiguration.setWalCompactionLevel() میتود په کارولو سره، تاسو کولی شئ د کمپریشن کچه وټاکئ که تاسو د ډیفالټ ارزښت (BEST_SPEED) څخه راضي نه یاست.
د WAL پاڼې سنیپ شاټ کمپریشن
دا څنګه کار کوي؟
موږ دمخه موندلي چې د WAL ریکارډونه په منطقي او فزیکي ویشل شوي دي. په هره پاڼه کې د هر بدلون لپاره، د پاڼې په حافظه کې د فزیکي WAL ریکارډ رامینځته کیږي. فزیکي ریکارډونه، په بدل کې، هم په 2 فرعي ډولونو ویشل شوي دي: د پاڼې سنیپ شاټ ریکارډ او ډیلټا ریکارډ. هرکله چې موږ په یوه پاڼه کې یو څه بدلوو او له پاک حالت څخه خندا حالت ته لیږدوو، د دې پاڼې بشپړ کاپي په WAL (د پاڼې سنیپ شاټ ریکارډ) کې زیرمه کیږي. حتی که موږ په WAL کې یوازې یو بایټ بدل کړو، ریکارډ به د پاڼې د اندازې څخه یو څه لوی وي. که موږ په یوه ناپاکه پاڼه کې یو څه بدل کړو، په WAL کې د ډیلټا ریکارډ رامینځته کیږي، کوم چې یوازې د مخ د مخکینۍ حالت په پرتله بدلون منعکس کوي، مګر ټوله پاڼه نه. څرنګه چې د پوستې له پیل څخه سمدستي وروسته د پوستې له پیل څخه سمدستي وروسته د پاڼو حالت له ناپاکو څخه پاکولو ته بیا تنظیم کول ترسره کیږي، نږدې ټول فزیکي ریکارډونه به یوازې د پاڼو عکسونه ولري (ځکه چې د پوستې له پیل څخه سمدستي وروسته ټولې پاڼې پاکې وي) ، بیا لکه څنګه چې موږ بلې پوستې ته نږدې کیږو ، د ډیلټا ریکارډ برخه وده پیل کوي او د بلې پوستې په پیل کې بیا تنظیم کیږي. په ځینو مصنوعي ازموینو کې اندازه کول وښودله چې د فزیکي ریکارډونو ټول حجم کې د پاڼې سنیپ شاټونو ونډه 90٪ ته رسیږي.
د WAL پاڼې سنیپ شاټ کمپریشن مفکوره دا ده چې د چمتو شوي پاڼې کمپریشن وسیلې په کارولو سره د پاڼې سنیپ شاټ کمپریس کړئ (د ډیسک پاڼې کمپریشن وګورئ). په ورته وخت کې، په WAL کې، ریکارډونه په ترتیب سره یوازې د ضمیمه کولو حالت کې خوندي شوي او د فایل سیسټم بلاکسونو حدودو ته د ریکارډونو تړلو ته اړتیا نشته، نو دلته، د ډیسک پاڼې کمپریشن میکانیزم برعکس، موږ د سپیر فایلونو ته اړتیا نلرو. ټول؛ په دې اساس، دا میکانیزم به نه یوازې په OS لینکس کې کار وکړي. برسېره پر دې، دا نور موږ ته مهمه نه ده چې موږ څومره د پاڼې کمپرس کولو توان درلود. حتی که موږ 1 بایټ خلاص کړو ، دا دمخه یوه مثبته پایله ده او موږ کولی شو په WAL کې کمپریس شوي ډیټا خوندي کړو ، د ډیسک پاڼې کمپریشن برعکس ، چیرې چې موږ کمپریس شوی پاڼه یوازې هغه وخت خوندي کوو که چیرې موږ له 1 څخه ډیر فایل سیسټم بلاک خلاص کړو.
پاڼې خورا د فشار وړ ډیټا دي، د WAL ټول حجم کې د دوی ونډه خورا لوړه ده، نو د WAL فایل فارمیټ بدلولو پرته موږ کولی شو د هغې په اندازې کې د پام وړ کمښت ترلاسه کړو. کمپریشن، د منطقي ریکارډونو په شمول، به په بڼه کې بدلون او د مطابقت له لاسه ورکولو ته اړتیا ولري، د بیلګې په توګه، د بهرني مصرف کونکو لپاره چې ممکن د منطقي ریکارډونو سره علاقه ولري، مګر د فایل اندازه کې د پام وړ کمښت المل نشي.
لکه څنګه چې د ډیسک پاڼې کمپریشن سره، د WAL پاڼې سنیپ شاټ کمپریشن کولی شي ZSTD، LZ4، Snappy کمپریشن الګوریتمونه، او همدارنګه د SKIP_GARBAGE حالت وکاروي.
د فعالیت اغیزه
دا ستونزمنه نه ده چې په مستقیم ډول د WAL پاڼې سنیپ شاټ کمپریشن فعالول یوازې هغه تارونه اغیزه کوي چې د پاڼې حافظې ته ډاټا لیکي، دا هغه تارونه دي چې په کیچونو کې ډاټا بدلوي. د WAL څخه د فزیکي ریکارډونو لوستل یوازې یو ځل پیښیږي، په دې وخت کې نوډ د سقوط وروسته پورته کیږي (او یوازې که چیرې دا د پوستې په جریان کې راښکته شي).
دا په هغو تارونو اغیزه کوي چې په لاندې ډول ډاټا بدلوي: موږ منفي اغیزه (CPU) ترلاسه کوو ځکه چې هر ځل ډیسک ته د لیکلو دمخه د پاڼې کمپریس کولو اړتیا، او مثبت اغیزه (ډیسک IO) د مقدار کمولو له امله. لیکل شوي ډاټا په دې اساس، دلته هرڅه ساده دي: که د سیسټم فعالیت د CPU لخوا محدود وي، موږ یو څه تخریب ترلاسه کوو، که دا د ډیسک I/O لخوا محدود وي، موږ زیاتوالی ترلاسه کوو.
په غیر مستقیم ډول، د WAL اندازه کمول هم په (مثبت ډول) جریان اغیزه کوي کوم چې د WAL برخې په آرشیف او د WAL کمپیکشن جریانونو کې ډوبوي.
زموږ په چاپیریال کې د مصنوعي ډیټا په کارولو سره د ریښتیني فعالیت ازموینې یو څه زیاتوالی ښیې (د 10٪ -15٪ لخوا له مینځه وړل ډیر شوي ، ځنډ د 10٪ -15٪ لخوا کم شوی).
څنګه فعال او تنظیم کړئ
لږترلږه اپاچی ایګنیټ نسخه: 2.8. په لاندې ډول فعال او تنظیم کړئ:
- د ټولګي په لاره کې باید د ignite-compression ماډل شتون ولري. په ډیفالټ کې، دا د اپاچي Ignite ویش کې د libs/اختیاري لارښود کې موقعیت لري او د ټولګي لارې کې شامل ندي. تاسو کولی شئ په ساده ډول ډایرکټر یو لیول پورته libs ته واړوئ او بیا کله چې تاسو یې د ignite.sh له لارې پرمخ وړئ دا به په اوتومات ډول فعال شي.
- دوام باید فعال شي (له لارې فعال شوی
DataRegionConfiguration.setPersistenceEnabled(true)). - د کمپریشن حالت باید د میتود په کارولو سره تنظیم شي
DataStorageConfiguration.setWalPageCompression()، کمپریشن د ډیفالټ لخوا غیر فعال شوی (غیر فعال حالت). - په اختیاري توګه، تاسو کولی شئ د میتود په کارولو سره د کمپریشن کچه تنظیم کړئ
DataStorageConfiguration.setWalPageCompression()، د هر حالت لپاره د اعتبار وړ ارزښتونو لپاره میتود لپاره جاواډاک وګورئ.
پایلې
په Apache Ignite کې د پام وړ ډیټا کمپریشن میکانیزمونه د یو بل څخه په خپلواکه توګه کارول کیدی شي، مګر د دوی هر ډول ترکیب هم د منلو وړ دی. پدې پوهیدل چې دوی څنګه کار کوي تاسو ته اجازه درکوي دا معلومه کړئ چې دوی ستاسو په چاپیریال کې ستاسو د دندو لپاره څومره مناسب دي او تاسو به د دوی کارولو پرمهال څه قرباني کړئ. د ډیسک پاڼې کمپریشن د اصلي ذخیره کولو لپاره ډیزاین شوی او کولی شي د منځني کمپریشن تناسب ورکړي. د WAL پاڼې سنیپ شاټ کمپریشن به د WAL فایلونو لپاره اوسط درجې کمپریشن ورکړي، او ډیری احتمال به حتی فعالیت ته وده ورکړي. د WAL کمپکشن به په فعالیت باندې مثبت اغیزه ونلري، مګر د فزیکي ریکارډونو په لرې کولو سره به د WAL فایلونو اندازه کمه کړي.
سرچینه: www.habr.com