یوه ورځ په لرې راتلونکي کې، د غیر ضروري معلوماتو اتوماتیک لیرې کول به د DBMS یو له مهمو کارونو څخه وي [1]. په ورته وخت کې ، موږ پخپله اړتیا لرو چې د غیر ضروري ډیټا حذف کولو یا لږ قیمتي ذخیره کولو سیسټمونو ته لیږدولو ته پاملرنه وکړو. راځئ چې ووایو تاسو پریکړه وکړئ چې څو ملیون قطارونه حذف کړئ. یو خورا ساده کار، په ځانګړې توګه که چیرې حالت معلوم وي او یو مناسب شاخص شتون ولري. "د جدول 1 څخه ړنګ کړئ چیرته col1 = :value" - څه ساده کیدی شي، سمه ده؟
ویډیو:
-
زه د لومړي کال راهیسې د هایلوډ برنامې کمیټې کې یم ، یعنی له 2007 راهیسې.
-
او زه د 2005 راهیسې د پوسټګریس سره یم. دا په ډیرو پروژو کې کارول کیږي.
-
دا ډله د 2007 راهیسې د RuPostges سره هم ده.
-
موږ په Meetup کې 2100+ ګډون کونکو ته وده ورکړه. دا له نیویارک وروسته په نړۍ کې دوهم ځای دی چې څه موده وړاندې یې سان فرانسیسکو ته ماته ورکړه.
-
زه د څو کلونو راهیسې په کالیفورنیا کې ژوند کوم. زه ډیری د امریکایی شرکتونو سره کار کوم، په شمول لوی شرکتونه. دوی د پوسټګریس فعال کارونکي دي. او هر ډول په زړه پوري شیان هلته راپورته کیږي.
- دا زما شرکت دی. موږ د اتوماتیک کارونو په سوداګرۍ کې یو چې د پرمختیا سستۍ له مینځه وړي.
که تاسو یو څه کوئ، ځینې وختونه د پوسټګریس په شاوخوا کې ځینې خنډونه شتون لري. راځئ چې ووایو تاسو اړتیا لرئ تر هغه پورې انتظار وکړئ تر څو چې مدیر تاسو ته د ازموینې بینچ ترلاسه کړي، یا تاسو اړتیا لرئ تر هغه چې DBA تاسو ته ځواب درکړي. او موږ د پراختیا، ازموینې او ادارې پروسې کې دا ډول خنډونه ګورو او هڅه کوو چې د اتوماتیک او نوي طریقې په کارولو سره له منځه یوسو.
زه پدې وروستیو کې په لاس انجلس کې په VLDB کې وم. دا د ډیټابیس ترټولو لوی کنفرانس دی. او یو راپور شتون درلود چې په راتلونکي کې به DBMSs نه یوازې ذخیره کړي ، بلکه په اتوماتيک ډول به ډیټا حذف کړي. دا یوه نوې موضوع ده.
په نړۍ کې ډیر او ډیر ډیټا شتون لري زیټابایټ 1 پیټابایټ دی. او اوس دا دمخه اټکل شوی چې موږ په نړۍ کې له 000 زیټابایټ څخه ډیر ډیټا لرو. او د دوی څخه ډیر نور هم شتون لري.
او څه ورسره وکړو؟ دا روښانه ده چې دا باید حذف شي. دلته د دې جالب راپور لینک دی. مګر تر اوسه پورې دا په DBMS کې نه دی پلي شوی.
هغه څوک چې د پیسو په شمیرلو پوهیږي دوه شیان غواړي. دوی غواړي چې موږ ړنګ کړو، نو له تخنیکي پلوه موږ باید د دې وړتیا ولرو.
هغه څه چې زه به یې وروسته ووایم یو لنډیز وضعیت دی چې د ریښتیني حالتونو یوه ډله پکې شامله ده ، دا د هغه څه ځانګړي تالیف چې واقعیا زما او شاوخوا ډیټابیسونو سره ډیری وختونه پیښ شوي ، ډیری کلونه. ریکونه هرچیرې دي او هرڅوک هر وخت په دوی باندې ګام اخلي.
راځئ چې ووایو موږ یو بیس یا څو اډې لرو چې وده کوي. او ځینې ریکارډونه ښکاره کثافات دي. د مثال په توګه، کاروونکي هلته یو څه کول پیل کړل، مګر پای ته ونه رسیدل. او یو څه وخت وروسته موږ پوهیږو چې دا نیمګړی کار نور نشي ساتل کیدی. دا دی، موږ غواړو د ځای خوندي کولو، فعالیت ښه کولو، او نور لپاره ځینې فضول شیان پاک کړو.
په عموم کې، دنده دا ده چې په میز کې د ځانګړو شیانو، ځانګړو لینونو حذف کول اتومات کړي.
او موږ یوه غوښتنه لرو چې نن به یې په اړه خبرې وکړو، دا د کثافاتو د لرې کولو په اړه.
موږ د تجربه لرونکي پراختیا کونکي څخه وغوښتل چې دا کار وکړي. هغه دا غوښتنه واخیستله، دا یې پخپله چک کړه - هرڅه کار کوي. ما دا په سټیج کولو کې ازموینه وکړه - هرڅه سم دي. دا راوباسي - هرڅه کار کوي. په ورځ کې یو ځل موږ دا چلوو - هرڅه سم دي.
ډیټابیس وده کوي او وده کوي. ورځنی DELETE یو څه ورو کار پیل کوي.
بیا موږ پوهیږو چې موږ اوس د بازار موندنې شرکت یو او ټرافیک به څو ځله ډیر وي، نو موږ پریکړه کوو چې په لنډمهاله توګه غیر ضروري شیان ودروو. او موږ یې بیرته راګرځول هیر کړل.
څو میاشتې وروسته دوی په یاد ول. او دا پراختیا کونکی پریښود یا په بل څه بوخت و ، دوی بل ته دنده وسپارله چې بیرته یې ورکړي.
هغه په سټینګ کې دیو چیک کړ - هرڅه سم دي. په طبیعي ډول ، تاسو لاهم اړتیا لرئ هغه څه پاک کړئ چې راټول شوي. هغه چک کړه، هرڅه کار کوي.
بیا به څه کیږي؟ بیا هرڅه زموږ لپاره جلا کیږي. دا دومره ټیټیږي چې په یو وخت کې هرڅه ښکته کیږي. هرڅوک په حیرانتیا کې دي، هیڅوک نه پوهیږي چې څه پیښیږي. او بیا دا معلومه شوه چې دا DELETE مسله وه.
کومه تیروتنه وشوه؟ دلته د شیانو لیست دی چې ممکن غلط شي. له دې څخه کوم یو خورا مهم دی؟
-
د مثال په توګه، هیڅ بیاکتنه نه وه، د بیلګې په توګه د DBA متخصص نه لیدل کیده. د تجربه لرونکي سترګو سره، هغه به سمدستي ستونزه ومومي، او سربیره پردې، هغه پروډ ته لاسرسی لري، چیرې چې څو ملیون لینونه راټول شوي.
-
شاید دوی یو څه غلط چک کړي.
-
شاید هارډویر زوړ شوی وي او تاسو اړتیا لرئ دا ډیټابیس نوي کړئ.
-
یا پخپله د ډیټابیس سره یو څه غلط دی، او موږ اړتیا لرو چې له Postgres څخه MySQL ته لاړ شو.
-
یا شاید په عملیاتو کې یو څه غلط وي.
-
شاید د کار په تنظیم کې ځینې غلطی وي او تاسو اړتیا لرئ یو څوک له دندې ګوښه کړئ او غوره خلک وګمارئ؟
د DBA هیڅ چک نه و. که چیرې DBA شتون ولري ، نو هغه به دا څو ملیونه لینونه وګوري او حتی پرته له کومې تجربې به ووایی: "دوی دا نه کوي." راځئ چې ووایو که دا کوډ په GitLab، GitHub کې وي او د کوډ بیاکتنې پروسه شتون ولري او داسې هیڅ شی شتون نلري چې د DBA تصویب پرته به دا عملیات په تولید کې ترسره شي، نو په ښکاره ډول DBA به ووایي: "تاسو دا نشئ کولی. »
او هغه به ووایی چې تاسو به د ډیسک IO سره ستونزې ولرئ او ټولې پروسې به لیونۍ شي ، ممکن لاکونه شتون ولري ، او تاسو به د څو دقیقو لپاره آټوواکوم هم بند کړئ ، نو دا ښه نده.
دویمه غلطي دا ده چې دوی په غلط ځای کې چک کړي. موږ له دې حقیقت وروسته ولیدل چې د کثافاتو ډیری ډیټا په پروډ کې راټولې شوې وې ، مګر پراختیا کونکي پدې ډیټابیس کې ډیټا نه وه جمع کړې ، او هیچا واقعیا دا کثافات په سټیج کې ندي رامینځته کړي. په دې اساس، 1 لینونه وو، چې په چټکۍ سره بشپړ شوي.
موږ پوهیږو چې زموږ ازموینې کمزورې دي، د بیلګې په توګه هغه پروسه چې جوړه شوې ده ستونزې نه لري. د DB کافي تجربه نه وه ترسره شوې.
یو مثالی تجربه باید په غوره توګه په ورته تجهیزاتو ترسره شي. دا تل ممکنه نه ده چې دا په ورته هارډویر کې ترسره کړئ، مګر دا خورا مهمه ده چې دا د ډیټابیس بشپړ اندازې کاپي وي. دا هغه څه دي چې زه یې له څو کلونو راهیسې تبلیغ کوم. او یو کال دمخه ما پدې اړه خبرې وکړې، تاسو کولی شئ دا ټول په یوټیوب کې وګورئ.
شاید زموږ تجهیزات خراب وي؟ که تاسو وګورئ، ځنډ کود شوی دی. موږ ولیدل چې ریسایکل 100٪ و. البته، که دا عصري NVMe ډرایو وي، نو دا به زموږ لپاره خورا اسانه وي. او شاید موږ به د دې له امله پروت نه شو.
که تاسو بادل لرئ، نو بیا پورته کول اسانه دي. موږ په نوي هارډویر کې نوي نقلونه پیل کړل. سویچور. او ټول ښه دي. ډیر اسانه.
ایا دا ممکنه ده چې په یو ډول کوچني ډیسکونه لمس کړئ؟ او دلته، د DBA په مرسته، موږ یوې ځانګړې موضوع ته ډوبه کوو چې د پوستې ټونینګ نومیږي. دا معلومه شوه چې موږ د پوستې ټوننګ نه دی ترسره کړی.
پوسته څه ده؟ دا په هر DBMS کې شتون لري. کله چې ستاسو په حافظه کې ډاټا بدلیږي، دا سمدلاسه ډیسکونو ته نه لیکل کیږي. هغه معلومات چې ډاټا بدله شوې ده لومړی په فارورډ لاګ کې لیکل کیږي، د لیکلو مخکې لاګ کې. او په ځینو وختونو کې، DBMS پریکړه کوي چې دا وخت دی چې اصلي پاڼې په ډیسک کې وغورځوئ، نو که چیرې موږ ناکام شو، موږ کولی شو لږ REDO ترسره کړو. دا د لوبو په څیر دی. که موږ ووژل شو، موږ به د وروستۍ پوستې څخه لوبه پیل کړو. او ټول DBMS دا پلي کوي.
په پوسټګریس کې تنظیمات وروسته پاتې دي. دوی د 10-15 کلنو معلوماتو او عملیاتو لپاره ډیزاین شوي. او پوسته هیڅ استثنا نه ده.
دا معلومات د پوسټګریس چیک اپ سره زموږ د راپور څخه دي، د بیلګې په توګه د اتوماتیک روغتیا معاینه. او دلته د څو ټیرابایټ ډیټابیس دی. او دا روښانه ده چې پوستې نږدې 90٪ قضیو کې جبري دي.
دا څه معنی ورکوي؟ هلته دوه ترتیبات شتون لري. د چک پوسته کیدای شي د وخت په پای کې واقع شي، د بیلګې په توګه، په 10 دقیقو کې. یا دا ممکن واقع شي کله چې ډیری معلومات ډک شوي وي.
او د ډیفالټ په واسطه، max_wal_saze 1 ګیګابایټ ته ټاکل شوی. په حقیقت کې، دا واقعا په Postgres کې د 300-400 میګابایټ وروسته واقع کیږي. تاسو ډیر ډیټا بدل کړی او تاسو پوسته لرئ.
او که چا دا نه وي کړی، مګر خدمت وده کړې، او شرکت ډیرې پیسې ګټي، ډیرې راکړې ورکړې لري، نو بیا پوسته په دقیقو کې یو ځل واقع کیږي، ځینې وختونه په هر 30 ثانیو کې یو ځل، او ځینې وختونه دوی حتی یو بل ته ځي. . دا واقعا بد دی.
او موږ اړتیا لرو ډاډ ترلاسه کړو چې دا لږ ځله راځي. دا دی، موږ کولی شو max_wal_size لوړ کړو. او هغه به لږ ځله برید وکړي.
مګر موږ یو بشپړ میتودولوژي رامینځته کړې چې دا څنګه په سمه توګه ترسره کړو ، دا دا دی چې څنګه د تنظیماتو غوره کولو په اړه پریکړې وکړو ، په واضح ډول د ځانګړو معلوماتو پراساس.
په دې اساس، موږ د ډیټابیس تجربو دوه لړۍ ترسره کوو.
لومړی لړۍ - موږ max_wal_size بدلوو. او موږ پراخ عملیات ترسره کوو. لومړی موږ دا د 1 ګیګابایټ په ډیفالټ ترتیب کې کوو. او موږ د ډیری ملیونونو لینونو پراخه DELETE کوو.
تاسو کولی شئ وګورئ چې دا زموږ لپاره څومره سخت دی. موږ ګورو چې ډیسک IO خورا خراب دی. راځئ وګورو چې موږ څومره وال تولید کړی، ځکه چې دا خورا مهم دی. وبه ګورو چې څو ځله پوستې ته ننوتل. او موږ ګورو چې دا ښه نه دی.
بیا موږ max_wal_size زیاتوو. موږ تکرار کوو. زیات کړئ، تکرار کړئ. او داسې څو ځله. په اصولو کې، 10 ټکي ښه دي، چیرته چې 1، 2، 4، 8 ګیګابایټ. او موږ د یو ځانګړي سیسټم چلند ته ګورو. دا روښانه ده چې دلته تجهیزات باید د محصول په څیر وي. تاسو باید ورته ډیسکونه، د حافظې ورته مقدار، او ورته پوسټګریس ترتیبات ولرئ.
او پدې توګه به موږ خپل سیسټم تبادله کړو، او موږ پوهیږو چې DBMS به د خراب ډله ایز DELETE په صورت کې څنګه چلند وکړي، دا به څنګه پوسته وي.
په روسیه کې پوسته د کنټرول نقطې معنی لري.
بېلګه: څو ملیونه قطارونه د شاخص په واسطه ړنګ کړئ، قطارونه په پاڼو کې "پرېشې" دي.
دلته یو مثال دی. دا یو څه اساس دی. او د max_wal_size لپاره د 1 ګیګابایټ ډیفالټ ترتیب سره ، دا خورا روښانه ده چې زموږ ډیسک د ثبت کولو لپاره شیلف ته ځي. دا انځور د یو ډیر ناروغ ناروغ یوه عادي علامه ده، دا دی، هغه واقعیا بد احساس کړی. او دلته یوازې یو عملیات و، دلته یوازې د څو ملیون لینونو حذف و.
که چیرې دا ډول عملیات په پروډ کې اجازه ورکړل شي، نو موږ به یوازې ښکته شو، ځکه چې دا روښانه ده چې یو DELETE موږ په المارۍ کې وژني.
سربیره پردې ، چیرې چې 16 ګیګابایټ شتون لري ، تاسو کولی شئ وګورئ چې غاښونه لا دمخه څرګندیدل پیل شوي. غاښونه لا دمخه ښه دي، د بیلګې په توګه موږ چت ټکوي، مګر دومره بد نه دي. هلته لږ آزادي ښکاره شوه. په ښي خوا کې ریکارډ دی. او د عملیاتو شمیر دوهم ګراف دی. او دا روښانه ده چې موږ دمخه د 16 ګیګابایټ سره یو څه اسانه تنفس کوو.
او چیرته چې 64 ګیګابایټ لیدل کیږي، دا په بشپړه توګه ښه شوی. دمخه غاښونه په ښکاره ډول لیدل کیږي، د نورو عملیاتو ژوندي پاتې کیدو لپاره ډیر فرصتونه شتون لري او د ډیسک سره یو څه ترسره کوي.
ولې داسې
زه به په تفصیل کې لږ څه ډوب کړم، مګر دا موضوع چې څنګه د پوستې ټینګ کولو ترسره کول د بشپړ راپور پایله کیدی شي، نو زه به ډیر تفصیل ته لاړ نه شم، مګر زه به لږ څه تشریح کړم چې کوم مشکلات شتون لري.
که چیرې پوسته ډیر ځله پیښیږي ، او موږ خپل قطارونه په ترتیب سره نوي نه کوو ، مګر د شاخص له مخې یې ومومئ ، کوم چې ښه دی ، ځکه چې موږ ټول جدول نه حذف کوو ، نو داسې پیښ کیدی شي چې لومړی موږ لومړی مخ لمس کړو ، بیا په زرګونو ، او بیا لومړی ته راستون شو. او که د دې لیدنو په مینځ کې لومړي مخ ته د پوستې پوستې دمخه دا په ډیسک کې خوندي کړی وي ، نو دا به یې بیا خوندي کړي ، ځکه چې موږ دا دوهم ځل ناپاک کړی دی.
او موږ به څو ځله پوستې ته د ژغورلو لپاره مجبور کړو. لکه څنګه چې د دې لپاره بې ځایه عملیات شتون لري.
مګر دا ټول نه دي. په Postgres کې، پاڼې 8 کیلوبایټ وزن لري، او په لینکس کې 4 کیلوبایټ. او هلته د بشپړ_صفحې_لیکلو ترتیب شتون لري. دا د ډیفالټ لخوا فعال شوی. او دا سمه ده، ځکه چې که موږ یې بند کړو، نو دا خطر شتون لري چې که ناکامه وي، یوازې نیمایي پاڼه به خوندي شي.
د فارورډ لاګ په WAL کې د ننوتلو چلند داسې دی چې کله موږ پوسته لرو او موږ د لومړي ځل لپاره یوه پاڼه بدلوو، ټوله پاڼه، یعني ټول 8 کیلوبایټ، په فارورډ لاګ کې پای ته رسیږي، که څه هم موږ یوازې یوه کرښه بدله کړه چې 100 بایټ وزن لري. او موږ مجبور یو چې ټوله پاڼه ولیکو.
په راتلونکو بدلونونو کې به یوازې یو ځانګړی ټپل وي، مګر د لومړي ځل لپاره موږ هر څه لیکو.
او، په وینا، که چیرې پوسته بیا پیښ شي، نو موږ باید هر څه له پیل څخه بیا پیل کړو او ټوله پاڼه وخورئ. د پرله پسې پوستو سره، کله چې موږ د ورته مخونو څخه تیریږو، full_page_writes = on به د دې څخه ډیر وي، د بیلګې په توګه موږ ډیر WAL تولید کوو. نور عکسونو ته ، آرشیف ته ، ډیسک ته لیږل کیږي.
او، په وینا، موږ دوه بې ځایه کیدنه لرو.
که موږ max_wal_size زیات کړو، نو دا معلومه شوه چې موږ د پوستې او وال لیکونکي دواړه کار اسانه کوو. او دا ډیر ښه دی.
راځئ چې یو ټیرابایټ نصب کړو او د هغې سره ژوند وکړو. په دې کې څه بد دي؟ دا بد دی، ځکه چې د ناکامۍ په صورت کې به موږ د ساعتونو لپاره پاڅیږو، ځکه چې پوسته ډیر وخت مخکې وه او ډیر څه بدل شوي دي. او موږ باید د دې ټولو لپاره REDO ترسره کړو. او له همدې امله موږ د تجربو دوهم لړۍ ترسره کوو.
موږ عملیات ترسره کوو او وګورو کله چې د پوستې بشپړیدو ته نږدې وي، موږ په هدف سره -9 پوستې وژنو.
او له هغې وروسته، موږ دا بیا پیل کوو، او وګورو چې دا به څومره وخت ونیسي چې دا تجهیزات لوړ شي، د بیلګې په توګه، دا به په دې بد حالت کې څومره REDO وکړي.
زه به دوه ځله یادونه وکړم چې وضعیت خراب دی. لومړی، موږ د پوستې پای ته رسیدو دمخه سم راښکته شو، نو موږ د لاسه ورکولو لپاره ډیر څه لرو. او دوهم، موږ پراخ عملیات درلودل. او که چیرې د پوستې وخت پای ته رسیدلی وي، نو ډیری احتمال به د وروستي پوستې څخه لږ WAL تولید شوي وي. یعني دا دوه ځله بایلونکی دی.
موږ دا حالت د مختلف max_wal_size لپاره اندازه کوو او پوهیږو چې که max_wal_size 64 ګیګابایټ وي، نو په دوه ځله بد حالت کې به موږ د 10 دقیقو لپاره پورته کړو. او موږ فکر کوو چې ایا دا زموږ سره مناسب دی یا نه. دا د سوداګرۍ مسله ده. موږ اړتیا لرو چې دا عکس د سوداګرۍ پریکړو مسؤلینو ته وښیو او پوښتنه یې وکړو: "د ستونزې په صورت کې تر ټولو ډیر وخت څومره دی چې موږ انتظار کولی شو؟ ایا موږ کولی شو په بد حالت کې د 3-5 دقیقو لپاره ودریږو؟" او تاسو پریکړه وکړئ.
او دلته یو په زړه پوری ټکی دی. په کنفرانس کې د پټروني په اړه یو څو راپورونه لرو. او شاید تاسو یې کاروئ. دا د Postgres لپاره autofailover دی. GitLab او Data Egret پدې اړه خبرې وکړې.
او که تاسو یو آټوفیلور ولرئ چې په 30 ثانیو کې به پیښ شي ، نو شاید موږ د 10 دقیقو لپاره ویده شو؟ ځکه چې پدې وخت کې به موږ نقل ته لاړ شو، او هرڅه به سم وي. دا یوه جنجالي مسله ده. زه روښانه ځواب نه پوهیږم. زه یوازې احساس کوم چې دا موضوع یوازې د ناورین د بیا رغونې شاوخوا نه ده.
که موږ د ناکامۍ څخه اوږده رغونه ولرو، نو موږ به په ډیرو نورو حالتونو کې ناامنه یو. د مثال په توګه، په ورته تجربو کې، کله چې موږ یو څه کوو او ځینې وختونه باید د 10 دقیقو انتظار وکړو.
زه به لاهم ډیر لرې نه ځم ، حتی که موږ پخپله ناکامه هم ولرو. د یوې قاعدې په توګه، ارزښتونه لکه 64، 100 ګیګابایټ ښه ارزښتونه دي. ځینې وختونه دا حتی د لږ غوره کولو ارزښت لري. په عموم کې، دا یو فرعي ساینس دی.
د تکرار کولو لپاره، د مثال په توګه، max_wal_size = 1، 8، تاسو اړتیا لرئ څو څو ځله ډله ایز عملیات تکرار کړئ. تاسو دا وکړل. او تاسو غواړئ دا بیا په ورته اډه کې ترسره کړئ، مګر تاسو دمخه هرڅه حذف کړي دي. چې څه کول پکار دي؟
زه به تاسو ته وروسته زموږ د حل په اړه ووایم او په داسې شرایطو کې د تکرار لپاره موږ څه کوو. او دا ترټولو سمه لاره ده.
مګر پدې حالت کې موږ خوشحاله یو. که، لکه څنګه چې دلته وايي "پیل، حذف، رول بیک"، نو بیا موږ کولی شو DELETE تکرار کړو. دا، که موږ دا پخپله فسخ کړو، نو موږ یې تکرارولی شو. او په فزیکي توګه ستاسو ډاټا به هلته وي. تاسو حتی هیڅ پړسوب نه ترلاسه کوئ. تاسو کولی شئ په دې ډول DELETE تکرار کړئ.
دا د ROLLBACK سره DELETE د پوستې ټونینګ لپاره مثالی دی، حتی که تاسو په سمه توګه ځای پرځای شوي ډیټابیس لابراتوار نلرئ.
موږ د یو کالم "i" سره نښه جوړه کړه. پوسټګریس د کارونې کالمونه لري. دوی نه لیدل کیږي پرته لدې چې په ځانګړي ډول غوښتنه وشي. دا دي: ctid، xmid، xmax.
Ctid فزیکي پته ده. مخ صفر، په پاڼه کې لومړی ټوک.
دا لیدل کیدی شي چې د ROOLBACK وروسته ټیپل په ورته ځای کې پاتې شو. دا دی، موږ کولی شو بیا هڅه وکړو، دا به ورته چلند وکړي. دا اصلي خبره ده.
Xmax د ټپل د مړینې وخت دی. دا داخل شوی، مګر پوسټګریس پوهیږي چې دا معامله بیرته راګرځول شوې، نو دا مهمه نده چې ایا دا 0 دی یا بیرته راګرځیدلی معامله. دا وړاندیز کوي چې DELETE د سیسټم چلند لوی عملیات تکرار او ازموینې لپاره کارول کیدی شي. تاسو کولی شئ د بې وزلو لپاره ډیټابیس لابراتوار جوړ کړئ.
دا د پروګرام کونکو په اړه دی. د DBA په اړه هم، دوی تل د دې لپاره پروګرامرانو ته ګوته نیسي: "تاسو ولې دومره اوږد او ستونزمن عملیات کوئ؟" دا په بشپړه توګه جلا جلا موضوع ده. پخوا به اداره وه، خو اوس به پرمختګ وي.
په ښکاره ډول موږ دا په برخو کې نه دي ویشلي. دا صفا ده. دا ناشونې ده چې دا ډول DELETE د ملیونونو لینونو لپاره په برخو کې مات کړئ. دا به 20 دقیقې وخت ونیسي، او هرڅه به پریوځي. مګر، له بده مرغه، حتی تجربه لرونکي پراختیا کونکي غلطي کوي، حتی په لویو شرکتونو کې.
ولې ماتول مهم دي؟
-
که موږ وګورو چې ډیسک سخت دی، نو راځئ چې دا ورو کړو. او که موږ مات شوي یو، نو موږ کولی شو وقفې اضافه کړو، موږ کولی شو د تخته کول سست کړو.
-
او موږ به نور د اوږدې مودې لپاره بند نه کړو. په ځینو مواردو کې دا مهمه نده ، که تاسو ریښتیني کثافات لرې کوئ چې هیڅوک پرې کار نه کوي ، نو تاسو به ډیری احتمال د آټوواکوم کار پرته بل څوک بند نه کړئ ځکه چې دا به د لیږد بشپړیدو ته انتظار باسي. مګر که تاسو یو څه حذف کړئ چې بل څوک یې غوښتنه کولی شي ، نو دوی به بلاک شي ، یو ډول سلسله عکس العمل به وي. په ویب سایټونو او ګرځنده غوښتنلیکونو کې باید د اوږدې معاملو څخه ډډه وشي.
دا په زړه پورې ده. زه ډیری وختونه پرمخ وړونکي ګورم چې پوښتنه کوي ، "د کوم بسته اندازه باید غوره کړم؟"
دا روښانه ده چې د بیچ اندازه لویه وي، د لیږد سر ټیټ وي، د بیلګې په توګه د اضافي لیږد سر. مګر په ورته وخت کې، د دې لیږد وخت ډیریږي.
زه یو ډیر ساده قاعده لرم: څومره چې ممکنه وي واخلئ، مګر په هره ثانیه کې د اعدام څخه ډیر مه کوئ.
ولې یوه ثانیه؟ تشریح خورا ساده او د هرچا لپاره د پوهیدو وړ دی، حتی غیر تخنیکي خلک. موږ غبرګون ګورو. راځئ چې 50 ملی ثانيې واخلو. که یو څه بدل شوی وي، زموږ سترګې به غبرګون وکړي. که دا کم وي، دا ډیر ستونزمن دی. که یو څه د 100 ملی ثانیو وروسته ځواب ووایی، د بیلګې په توګه، تاسو د موږک سره کلیک وکړ او دا تاسو ته د 100 ملی ثانیو وروسته ځواب ورکړ، تاسو دمخه د دې لږ ځنډ احساس کوئ. یوه ثانیه لا دمخه د بریک په توګه پیژندل کیږي.
په دې اساس، که موږ خپل ډله ایز عملیات په 10 ثانیو کې وویشو، نو موږ خطر لرو چې موږ به یو څوک بند کړو. او دا به د څو ثانیو لپاره کار وکړي، او خلک به یې دمخه خبر کړي. له همدې امله زه غوره نه ګڼم چې دا د یوې ثانیې څخه ډیر نه وکړم. مګر په ورته وخت کې، دا خورا کوچنی مه ماتوئ، ځکه چې د لیږد سر به د پام وړ وي. دا به د اډې لپاره دروند وي، او ممکن نورې ستونزې رامنځته شي.
موږ د کڅوړې اندازه غوره کوو. په هر حالت کې موږ کولی شو دا په مختلف ډول ترسره کړو. اتومات کیدی شي. او موږ د یوې کڅوړې پروسس کولو موثریت باندې قانع یو. دا دی، موږ د یوې کڅوړې حذف یا تازه کوو.
په لاره کې، هرڅه چې زه تاسو ته وایم یوازې د حذف کولو په اړه ندي. لکه څنګه چې تاسو اټکل کړی، دا په ډیټا کې لوی عملیات دي.
او موږ ګورو چې پلان خورا ښه دی. تاسو کولی شئ د شاخص سکین وګورئ، حتی غوره شاخص یوازې سکین. او موږ لږ مقدار معلومات لرو. او هرڅه د یوې ثانیې څخه لږ وخت کې کار کوي. سوپر
او موږ لاهم اړتیا لرو چې ډاډ ترلاسه کړو چې هیڅ تخریب شتون نلري. دا پیښیږي چې لومړی بستونه په چټکۍ سره کار کوي، او بیا هرڅه خراب او بدتر کیږي. پروسه داسې ده چې تاسو اړتیا لرئ ډیری ازموینې ته اړتیا ولرئ. دا هغه څه دي چې د ډیټابیس لابراتوارونو لپاره اړین دي.
او موږ لاهم اړتیا لرو یو څه چمتو کړو نو دا به موږ ته اجازه راکړي چې دا په تولید کې په سمه توګه وڅیړو. د مثال په توګه، موږ کولی شو په لاګ کې وخت ولیکئ، موږ کولی شو ولیکئ چې موږ اوس چیرته یو او څوک چې موږ اوس حذف کړی دی. او دا به موږ ته اجازه درکړو چې وروسته پوه شو چې څه پیښیږي. او که یو څه غلط شي، ژر تر ژره ستونزه ومومئ.
که موږ د پوښتنو موثریت چیک کولو ته اړتیا ولرو او موږ اړتیا لرو څو څو ځله تکرار کړو ، نو د ملګري بوټ په څیر یو شی شتون لري. هغه لا دمخه چمتو دی. دا هره ورځ د لسګونو پراختیا کونکو لخوا کارول کیږي. او هغه کولی شي د غوښتنې سره سم په 30 ثانیو کې یو لوی ټیرابایټ ډیټابیس چمتو کړي ، ستاسو خپله کاپي. او تاسو کولی شئ هلته یو څه حذف کړئ او RESET ووایاست ، او بیا یې حذف کړئ. تاسو کولی شئ دا په دې طریقه تجربه کړئ. زه پدې شی کې راتلونکی ګورم. او موږ لا دمخه دا کار کوو.
د ویشلو تګلارې څه دي؟ زه د 3 مختلف ویشلو ستراتیژیو ګورم چې پراختیا کونکي یې په پیک کې کاروي.
لومړی خورا ساده دی. موږ یو شمیري ID لرو. او راځئ چې دا په مختلفو وقفو کې مات کړو او د هغې سره کار وکړو. نیمګړتیا روښانه ده. په لومړۍ برخه کې، موږ ممکن د اصلي کثافاتو 100 لینونه ولرو، په دویمه 5 لینونو کې یا په بشپړه توګه نه، یا ټولې 1 کرښې به د کثافاتو په توګه وګرځي. ډیر غیر مساوي کار، مګر ماتول اسانه دي. دوی اعظمي ID واخیست او مات یې کړ. دا یو ساده طریقه ده.
دویمه ستراتیژي یو متوازن چلند دی. دا په Gitlab کې کارول کیږي. موږ میز واخیست او سکین یې کړ. موږ د ID پیکونو سرحدونه وموندل ترڅو هر کڅوړه دقیقا 10 ریکارډونه ولري. او دوی ما په یو ډول کتار کې ودرول. او موږ نور پروسس کوو. تاسو کولی شئ دا په څو تارونو کې ترسره کړئ.
په لومړۍ ستراتیژۍ کې، تاسو کولی شئ دا په څو تارونو کې هم ترسره کړئ. دا ستونزمنه نه ده.
مګر یو یخ او ډیر غوره لاره شتون لري. دا دریمه ستراتیژي ده. او کله چې امکان ولري، دا غوره ده چې دا غوره کړئ. موږ دا د ځانګړي شاخص پراساس کوو. په دې حالت کې، دا به ډیری احتمال زموږ د کثافاتو حالت او ID پراساس یو شاخص وي. موږ به ID شامل کړو ترڅو دا یوازې یو شاخص سکین وي ترڅو موږ ډنډ ته نه ځو.
عموما، یوازې د شاخص سکین د شاخص سکین څخه ګړندی دی.
او موږ ژر تر ژره خپل IDونه ومومئ چې موږ یې حذف کول غواړو. موږ مخکې له مخکې BATCH_SIZE غوره کوو. او موږ نه یوازې دوی ترلاسه کوو ، موږ یې په ځانګړي ډول ترلاسه کوو او سمدلاسه یې تنظیم کوو. مګر موږ یې په دې ډول بندوو که چیرې دوی دمخه بند شوي وي ، نو موږ یې نه بندوو ، مګر حرکت کوو او راتلونکي یې ونیسو. دا د تازه کولو لپاره دی چې سکیپ لاک شوی دی. دا د پوسټګریس سوپر فیچر موږ ته اجازه راکوي چې په څو تارونو کې کار وکړو که موږ وغواړو. احتمالا په یوه تار کې. او بیا CTE شتون لري - دا یوه غوښتنه ده. او موږ د دې CTE په دوهم پوړ کې ریښتیني لرې کول لرو - returning *. تاسو کولی شئ ID بیرته ورکړئ، مګر دا غوره ده *که تاسو په هره کرښه کې لږ معلومات لرئ.
ولې موږ دې ته اړتیا لرو؟ موږ د راپور ورکولو لپاره دې ته اړتیا لرو. موږ اوس په حقیقت کې ډیری کرښې حذف کړې. او زموږ حدود د ID یا create_at لخوا داسې دي. تاسو کولی شئ لږترلږه، اعظمي. بل څه کولی شي. دلته ډیر څه شتون لري چې تاسو یې کولی شئ. او دا د څارنې لپاره خورا اسانه دی.
د شاخص په اړه یو بل یادونه شتون لري. که موږ پریکړه وکړو چې موږ د دې ځانګړي کار لپاره ځانګړي شاخص ته اړتیا لرو، نو موږ باید ډاډ ترلاسه کړو چې دا یوازې د ټپل تازه معلومات خراب نه کوي. دا دی، پوسټګریس داسې احصایې لري. دا ستاسو د میز لپاره pg_stat_user_tables کې لیدل کیدی شي. تاسو کولی شئ وګورئ چې ګرم تازه معلومات کارول کیږي یا نه.
داسې شرایط شتون لري کله چې ستاسو نوی شاخص ممکن په ساده ډول دوی پرې کړي. او نور ټول تازه معلومات چې دمخه روان دي ورو به ورو شي. نه یوازې د دې لپاره چې شاخص څرګند شو (هر شاخص یو څه تازه کوي ، مګر یوازې یو څه) ، مګر دلته به لاهم شیان ګډوډ کړي. او د دې میز لپاره ځانګړي اصلاح کول ناممکن دي. دا کله کله پیښیږي. دا یو لنډیز دی چې لږ خلک یې په یاد لري. او په دې ریک باندې ګام اخیستل اسانه دي. ځینې وختونه داسې پیښیږي چې تاسو اړتیا لرئ د بل اړخ څخه یوه لاره ومومئ او بیا هم د دې نوي شاخص پرته ترسره کړئ، یا بل شاخص جوړ کړئ، یا بل څه وکړئ، د بیلګې په توګه، تاسو کولی شئ دویمه طریقه وکاروئ.
مګر دا ترټولو غوره تګلاره ده، دا څنګه په بیچونو ویشئ او د یوې غوښتنې سره په بیچونو کې ډزې وکړئ، په یو وخت کې یو څه حذف کړئ، او داسې نور.
اوږده راکړه ورکړه -
بند شوی autovacuum
د بلاک کولو مسله
تېروتنه #5 لویه ده. د Okmeter څخه نیکولای د Postgres څارنې په اړه خبرې وکړې. له بده مرغه، د پوستګریس کامل څارنه شتون نلري. ځینې نږدې دي، ځینې نور. Okmeter د کامل کیدو لپاره کافي نږدې دی ، مګر ډیر څه ورک دي او اضافه کولو ته اړتیا لري. تاسو باید د دې لپاره چمتو اوسئ.
د مثال په توګه، دا غوره ده چې د مړو ټوپلونو څارنه وکړئ. که تاسو په خپل میز کې ډیری مړه توکي لرئ، نو یو څه غلط دی. دا غوره ده چې همدا اوس عکس العمل وښایئ ، که نه نو دلته تخریب شتون لري ، او موږ کولی شو پریوځو. دا پیښیږي.
که چیرې یو لوی IO وي، نو دا روښانه ده چې دا ښه نه ده.
اوږده راکړه ورکړه هم. په OLTP کې د اوږدې راکړې ورکړې اجازه نه ورکول کیږي. او دلته د ټوټې لپاره لینک دی، کوم چې تاسو ته اجازه درکوي چې دا ټوټه واخلئ او دمخه د اوږدې معاملو ځینې تعقیب ترسره کړئ.
ولې اوږدې راکړې ورکړې خرابې دي؟ ځکه چې ټول قفل به یوازې په پای کې خوشې شي. او موږ ټول بند کړو. پلس موږ د ټولو میزونو لپاره آټوواکوم بلاک کوو. دا هر څه ښه نه دي. حتی که تاسو په عکس کې ګرم سټینډ بای فعال کړی وي ، دا لاهم خراب دی. په عموم کې، دا غوره ده چې په هر ځای کې د اوږدې معاملو څخه ډډه وکړئ.
که موږ ډیری میزونه لرو چې خالي نه وي، نو موږ باید خبرتیا ولرو. دا ډول حالت دلته ممکن دی. موږ کولی شو په غیر مستقیم ډول د آټوواکوم عملیات اغیزمن کړو. دا د Avito څخه یوه ټوټه ده، کوم چې ما یو څه ښه کړی. او دا یو په زړه پوری وسیله وګرځیده ترڅو وګورو چې موږ د اوټوواکوم سره څه لرو. د مثال په توګه، دلته ځینې میزونه شتون لري او دوی به د خپل وار انتظار ونه کړي. تاسو هم اړتیا لرئ چې دا په څارنه کې واچوئ او خبرتیا ولرئ.
او د بلاکونو مسله. د بلاکونو ځنګل. زه خوښوم چې له یو چا څخه یو څه واخلم او ښه کړم. دلته ما د ډیټا ایګریټ څخه یو ښه تکراري CTE واخیست ، کوم چې د تالاشۍ ونو ځنګل ښیې. دا د تشخیص لپاره یو ښه شی دی. او د هغې په بنیاد څارنه هم کولی شي. مګر دا باید په دقت سره ترسره شي. تاسو اړتیا لرئ د خپل ځان لپاره یو کوچنی بیان_ وخت ختم کړئ. او lock_timeout مطلوب دی.
ځینې وختونه دا ټولې تېروتنې یوځای کیږي.
زما په اند، دلته ترټولو مهمه تېروتنه تنظیمي ده. دا تنظیمي ده، ځکه چې ټیکنالوژي کار نه کوي. دا نمبر 2 دی - دوی په غلط ځای کې چک شوي.
موږ هلته چیک نه کړ ځکه چې موږ د تولید کلون نه درلود چې چیک کول یې اسانه وو. پراختیا کونکی ممکن تولید ته لاسرسی ونلري.
او موږ په غلط ځای کې چک کړل. که دوی هلته کتلي وای، نو موږ به یې پخپله لیدلي وای. پراختیا کونکی کولی شي دا ټول حتی د DBA پرته وګوري ، که چیرې هغه دا په ښه چاپیریال کې چیک کړي ، چیرې چې د معلوماتو ورته مقدار او ورته ترتیب شتون لري. هغه به دا ټول ذلت لیدلی وی او شرمیدلی وی.
د موټر خلا په اړه نور. وروسته له هغه چې موږ د څو ملیون لینونو پراخه پاکول ترسره کړل، موږ لاهم اړتیا لرو چې REPACK ترسره کړو. دا په ځانګړې توګه د شاخصونو لپاره مهم دی. دوی به بد احساس کړي کله چې موږ هلته هرڅه پاک کړو.
او که تاسو غواړئ د لرې کولو ورځنی کار بیرته راوباسئ ، نو زه به وړاندیز وکړم چې دا ډیر ځله ترسره کړئ ، مګر کوچنی. دا په هره دقیقه کې یو ځل یا حتی ډیر ځله لږ څه کیدی شي. او موږ باید دوه شیان وڅیړو: دا چې دا شی هیڅ غلطی نلري او دا چې وروسته پاتې نشي. هغه چال چې ما ښودلی تاسو ته به اجازه درکړي چې دا حل کړي.
هغه څه چې موږ یې کوو خلاص سرچینه ده. دا په GitLab کې پوسټ شوی. او موږ دا جوړوو ترڅو خلک حتی د DBA پرته چیک کړي. موږ د ډیټابیس لابراتوار جوړوو، دا دی، موږ د بیس برخې ته زنګ ووهو په کوم کې چې اوس کار کوي. او تاسو کولی شئ د تولید یوه کاپي واخلئ. اوس د سست لپاره د جو پلي کول شتون لري ، تاسو کولی شئ هلته ووایاست: "داسې او داسې غوښتنه تشریح کړئ" او سمدلاسه ستاسو د ډیټابیس کاپي لپاره پایله ترلاسه کړئ. تاسو حتی کولی شئ هلته DELETE وکړئ، او هیڅوک به یې پام ونه کړي.
راځئ چې ووایو تاسو 10 ټیرابایټ لرئ، موږ د ډیټابیس لابراتوار هم 10 ټیرابایټ جوړوو. او 10 پراختیا کونکي کولی شي په ورته وخت کې د 10 ټیرابایټ ډیټابیسونو سره په ورته وخت کې کار وکړي. هرڅوک کولی شي هغه څه وکړي چې دوی یې غواړي. حذف کول، پرې کول، او نور کولی شي دا په زړه پورې دی. موږ به سبا په دې اړه خبرې وکړو.
دې ته پتلی چمتو کول ویل کیږي. دا فرعي چمتو کول دي. دا یو ډول تصور دی چې د پراختیا او ازموینې ځنډ خورا له مینځه وړي او نړۍ پدې برخه کې غوره ځای جوړوي. دا دی، دا یوازې تاسو ته اجازه درکوي د ډله ایزو عملیاتو سره د ستونزو څخه مخنیوی وکړئ.
بېلګه: د 5 ټیرابایټ ډیټابیس، د 30 ثانیو څخه لږ وخت کې کاپي ترلاسه کول. او دا حتی په اندازې پورې اړه نلري، د بیلګې په توګه دا مهمه نده چې څومره ټیرابایټ.
نن ورځ تاسو کولی شئ لاړ شئ او زموږ وسیلو ته کیندل. تاسو کولی شئ راجستر کړئ او وګورئ چې هلته څه دي. تاسو کولی شئ دا بوټ د ځان لپاره نصب کړئ. دغه وړیا دی. ولیکئ.
پوښتنې
ډیری وختونه په ریښتیني حاالتو کې دا په ګوته کیږي چې هغه معلومات چې باید په جدول کې پاتې شي د هغه څه په پرتله خورا لږ دي چې حذف کولو ته اړتیا لري. دا دی، په داسې حالت کې د دې طریقې پلي کول اکثرا اسانه وي، کله چې د نوي څیز رامینځته کول اسانه وي، یوازې اړین معلومات هلته کاپي کړئ او زاړه جدول لیږد کړئ. دا روښانه ده چې تاسو د دې شیبې لپاره د سافټویر چلند ته اړتیا لرئ پداسې حال کې چې تاسو بدل کوئ. دا طریقه څنګه ده؟
دا یو ډیر ښه چلند او ډیر ښه کار دی. دا د هغه څه سره ورته دی چې pg_repack کوي، دا د هغه څه سره ورته دی چې تاسو یې باید ترسره کړئ کله چې تاسو د خلکو ID 4 بایټ جوړ کړئ. ډیری چوکاټونو څو کاله دمخه دا کار کړی و، او پلیټونه یوازې لوی شوي، او دوی باید 8 بایټ ته بدل شي.
دا کار خورا ستونزمن دی. موږ دا وکړل. او تاسو باید ډیر محتاط اوسئ. قلفونه او داسې نور شته خو دا کار شوی دی. دا دی، معیاري طریقه د pg_repack کارول دي. تاسو داسې یوه نښه اعلان کړئ. او مخکې لدې چې تاسو دا د سنیپ شاټ ډیټا سره ډک کړئ ، تاسو یو جدول هم اعلان کړئ چې ټول بدلونونه تعقیبوي. دلته یو چال شتون لري چې تاسو ممکن حتی ځینې بدلونونه هم تعقیب نه کړئ. فرعي ټکي شتون لري. او بیا تاسو بدل کړئ، بدلونونه راولئ. یو لنډ وقف به وي کله چې موږ هرڅوک بند کړو، مګر په ټولیز ډول دا ترسره کیږي.
که تاسو په GitHub کې pg_repack ته ګورئ ، نو کله چې د ID int 4 څخه int 8 ته د بدلولو دنده شتون درلود ، نو پخپله د pg_repack کارولو لپاره نظر شتون درلود. دا هم ممکنه ده، مګر دا یو څه د هیکر طریقه ده، مګر دا به د دې لپاره هم کار وکړي. تاسو کولی شئ په هغه محرک کې مداخله وکړئ چې pg_repack کاروي او هلته ووایی: "موږ دې ډیټا ته اړتیا نلرو ،" یعنی موږ یوازې هغه څه لیږدوو چې موږ ورته اړتیا لرو. او بیا هغه یوازې بدلوي او بس.
د دې طریقې سره، موږ د جدول دویمه کاپي هم ترلاسه کوو، په کوم کې چې ډاټا لا دمخه ترتیب شوي او د ښکلي شاخصونو سره خورا په اسانۍ سره ایښودل شوي.
بلیټ نه، دا یو ښه طریقه ده. مګر زه پوهیږم چې د دې لپاره د اتوماتیک رامینځته کولو هڅې شتون لري ، د بیلګې په توګه د نړیوال حل رامینځته کول. زه کولی شم تاسو دې اتومات ته معرفي کړم. دا په Python کې لیکل شوی، ښه توکي.
زه د MySQL نړۍ څخه لږ څه یم، نو زه د اوریدلو لپاره راغلی یم. او موږ دا طریقه کاروو.
مګر دا یوازې هغه وخت دی چې موږ 90٪ لرو. که موږ 5٪ ولرو، نو دا د کارولو لپاره خورا ښه نه ده.
د راپور لپاره مننه! که چیرې د پروډ بشپړ کاپي کولو لپاره سرچینې شتون نلري، ایا د بار یا اندازې محاسبه کولو لپاره کوم الګوریتم یا فورمول شتون لري؟
ښه پوښتنه. تر دې دمه موږ د څو ټرابایټ ډیټابیس موندلو توان لرو. حتی که چیرې هارډویر یو شان نه وي، د بیلګې په توګه، لږ حافظه، لږ پروسیسر او ډیسکونه په سمه توګه ورته ندي، موږ بیا هم دا کوو. که چیرې هیڅ ځای شتون نلري، نو تاسو باید د هغې په اړه فکر وکړئ. اجازه راکړئ تر سبا پورې د هغې په اړه فکر وکړم، تاسو راغلی، موږ به خبرې وکړو، دا یوه ښه پوښتنه ده.
د راپور لپاره مننه! تاسو لومړی د دې حقیقت په اړه خبرې پیل کړې چې یو ښه پوسټګریس شتون لري، کوم چې دا ډول محدودیتونه لري، مګر دا وده کوي. او دا ټول په پراخه کچه یو کرچ دی. ایا دا ټول پخپله د پوسټګریس پراختیا سره مخالفت نه کوي ، په کوم کې چې یو ډول DELETE ډیفینټ به څرګند شي یا کوم بل څه چې باید په ټیټه کچه وساتي هغه څه چې موږ یې دلته د خپلو ځینې عجیب وسیلو سره پوښلو هڅه کوو؟
که په SQL کې موږ وویل چې په یوه لیږد کې ډیری ریکارډونه حذف یا تازه کړئ، نو پوسټګریس څنګه دا توزیع کولی شي؟ موږ په فزیکي توګه په عملیاتو کې محدود یو. موږ به لاهم دا د اوږدې مودې لپاره کوو. او موږ به پدې وخت کې لاک کړو ، وغيره.
دوی د شاخصونو سره ورته وکړل.
زه فرض کولی شم چې د ورته پوستې ټوننګ اتومات کیدی شي. یوه ورځ ممکن دا پیښ شي. مګر بیا زه واقعیا په پوښتنه نه پوهیږم.
پوښتنه دا ده: ایا د پراختیا ویکتور شتون لري چې سم هلته ځي، او دلته ستاسو سره موازي ځي؟ هغوی. ایا دوی تر اوسه په دې اړه فکر نه کوي؟
ما د هغو اصولو په اړه خبرې وکړې چې اوس کارول کیدی شي. یو بل بوټ شتون لري ، د دې سره تاسو کولی شئ د چک پوستې اتومات کول ترسره کړئ. ایا دا به کله په Postgres کې پیښ شي؟ زه نه پوهیږم، دا حتی تر اوسه بحث نه دی شوی. موږ لاهم له دې څخه لرې یو. مګر داسې ساینس پوهان شتون لري چې نوي سیسټمونه جوړوي. او دوی موږ په اتوماتیک شاخصونو کې غورځوي. پرمختګونه شتون لري. د مثال په توګه، تاسو کولی شئ د اتوماتیک ټوننګ وګورئ. دا په اتوماتيک ډول پیرامیټونه غوره کوي. مګر هغه به لاهم ستاسو لپاره د پوستې ټوننګ نه کوي. دا دی، دا به د فعالیت، شیل بفر، او نور لپاره غوره کړي.
او د پوستې ټینګ کولو لپاره تاسو لاندې شیان ترسره کولی شئ: که تاسو زر کلسترونه او د هارډویر مختلف ټوټې لرئ ، په بادل کې مختلف مجازی ماشینونه ، تاسو کولی شئ زموږ بوټ وکاروئ اتومات کول. او max_wal_size به ستاسو د هدف تنظیماتو سره سم په اوتومات ډول وټاکل شي. مګر تر دې دمه دا حتی په کرنل کې کیدو ته نږدې ندی ، له بده مرغه.
بعد له غرمه مو پخیر تاسو د اوږدې معاملو د خطرونو په اړه خبرې وکړې. تاسو وویل چې د حذف کولو په صورت کې آٹوواکوم بلاک شوی دی. دا نور څنګه موږ ته زیان رسوي؟ ځکه چې موږ د ځای خالي کولو او د دې کارولو وړتیا په اړه نور خبرې کوو. موږ نور څه له لاسه ورکوو؟
Autovacuum ممکن دلته ترټولو لویه ستونزه نه وي. او دا حقیقت چې اوږده معامله کولی شي نور لیږدونه بند کړي یو ډیر خطرناک امکان دی. هغه ممکن ملاقات وکړي یا نه. که هغه ولیدل، نو شیان خورا خراب کیدی شي. او د Autovacuum سره دا هم یوه ستونزه ده. په OLTP کې د اوږدې معاملو سره دوه ستونزې شتون لري: تالاشۍ او آٹوواکوم. او که تاسو په ریپلیکا کې ګرم سټینډ بای فیډبیک فعال کړی وي ، نو د آټوواکوم بلاک کول به ماسټر ته راشي ، دا به له نقل څخه راشي. مګر لږ تر لږه به هلته تالاشي نه وي. او دلته به تالاشي وي. موږ د معلوماتو د بدلونونو په اړه خبرې کوو، نو قلفونه دلته یو مهم ټکی دی. او که دا د اوږدې مودې لپاره دوام وکړي، نو بیا نور ډیر لیږدونه بندیږي. دوی کولی شي نور وخوري. او تالاشي ونې ښکاري. ما د ټوټې لپاره لینک چمتو کړ. او دا ستونزه په چټکۍ سره د آټوواکوم ستونزې په پرتله خورا د پام وړ کیږي، کوم چې یوازې راټولیږي.
د راپور لپاره مننه! تاسو خپل راپور په دې ویلو پیل کړ چې تاسو په غلطه توګه ازموینه کړې. موږ خپل نظر ته دوام ورکړ چې موږ ورته تجهیزاتو ته اړتیا لرو، د اډې سره ورته ورته. راځئ چې ووایو موږ پراختیا کونکي ته اساس ورکړ. او هغه غوښتنه یې ومنله. او داسې بریښي چې ښه کار کوي. مګر دا په ژوندۍ کې نه ګوري، مګر په ژوندۍ کې، د بیلګې په توګه، زموږ بار 60-70٪ دی. او حتی که موږ دا ټونینګ وکاروو، دا خورا ښه نه کیږي
ستاسو په ټیم کې د متخصص درلودل او د DBA متخصصینو کارول چې کولی شي وړاندوینه وکړي چې د ریښتیني شالید بار لاندې به څه پیښ شي مهم دي. کله چې موږ په ساده ډول زموږ د خالص بدلونونو له لارې تیر شو، موږ انځور ګورو. مګر یو ډیر پرمختللی کړنلاره وه کله چې موږ ورته کار بیا وکړ، مګر د تولید شوي تولید بار سره. دا په بشپړه توګه خوندور دی. موږ لاهم دې ټکي ته وده ورکولو ته اړتیا لرو. دا بالغ دی. موږ په خالص ډول هغه څه ته ګورو چې موږ یې لرو او دا هم ګورو چې ایا موږ کافي سرچینې لرو. دا ښه پوښتنه ده.
کله چې موږ دمخه د کثافاتو انتخاب کوو او موږ لرو ، د مثال په توګه ، حذف شوی بیرغ
دا هغه څه دي چې Autovacuum په اتوماتيک ډول په Postgres کې کوي.
او هغه دا کوي؟
Autovacuum د کثافاتو راټولونکی دی.
ساپی!
د راپور لپاره مننه! ایا د ویشلو سره سمدستي ډیټابیس ډیزاین کولو لپاره اختیار شتون لري ترڅو ټول کثافات له اصلي میز څخه بل ځای ته واړول شي؟
البته لري.
ایا موږ کولی شو خپل ځان خوندي کړو که چیرې موږ یو میز بند کړی وي چې باید ونه کارول شي؟
البته لري. مګر دا د چرګ او هګۍ پوښتنه ده. که موږ ټول پوهیږو چې په راتلونکي کې به څه پیښ شي ، نو یقینا موږ به هرڅه عالي ترسره کړو. مګر سوداګرۍ بدلیږي، نوي کالمونه او نوې غوښتنې ښکاري. او بیا - هو، موږ غواړو دا حذف کړو. مګر دا یو مثالی حالت دی؛ دا په ژوند کې پیښیږي، مګر تل نه. مګر په ټولیزه توګه دا یو ښه نظر دی. یوازې ټوټه کړئ او بس.
سرچینه: www.habr.com