زه تاسو ته وړاندیز کوم چې تاسو د 2016 له پیل څخه د انډری سالنیکوف لخوا د راپور لیږد ولولئ "په غوښتنلیکونو کې عادي غلطۍ چې په پوسټګریسکیل کې د غوړیدو لامل کیږي"
پدې راپور کې ، زه به په غوښتنلیکونو کې اصلي غلطۍ تحلیل کړم چې د غوښتنلیک کوډ ډیزاین کولو او لیکلو مرحله کې رامینځته کیږي. او زه به یوازې هغه تېروتنې واخلم چې په Postgresql کې د غوړیدو لامل کیږي. د یوې قاعدې په توګه، دا په ټولیزه توګه ستاسو د سیسټم د فعالیت پای پیل دی، که څه هم په پیل کې د دې لپاره هیڅ شرط نه و.
ټولو ته ښه راغلاست وایم! دا راپور زما د همکار څخه د تیر راپور په څیر تخنیکي ندی. دا راپور اساسا د بیک اینڈ سیسټم پراختیا کونکو لپاره دی ځکه چې موږ په کافي اندازه پیرودونکي لرو. او دوی ټول ورته غلطي کوي. زه به تاسو ته د دوی په اړه ووایم. زه به تشریح کړم چې دا تیروتنې کوم وژونکي او بد شیان رامینځته کوي.
ولې تېروتنې کېږي؟ دا د دوو دلیلونو لپاره ترسره کیږي: په تصادفي، شاید دا به کار وکړي او د ځینو میکانیزمونو د ناپوهۍ له امله چې د ډیټابیس او غوښتنلیک تر منځ په کچه واقع کیږي، او همدارنګه پخپله ډیټابیس کې.
زه به تاسو ته د ناوړه عکسونو سره درې مثالونه درکړم چې څنګه خراب شیان پیښ شوي. زه به تاسو ته په لنډ ډول د هغه میکانیزم په اړه ووایم چې هلته پیښیږي. او د دوی سره څنګه معامله وکړئ، کله چې دوی پیښ شوي، او د غلطیو مخنیوي لپاره کوم مخنیوي میتودونه کارول کیږي. زه به تاسو ته د مرستندویه وسیلو په اړه ووایم او ګټور لینکونه چمتو کړم.
ما د ازموینې ډیټابیس کارولی چیرې چې ما دوه میزونه درلودل. یو پلیټ د پیرودونکو حسابونو سره، بل په دې حسابونو کې د معاملو سره. او د یو څه فریکونسۍ سره موږ په دې حسابونو کې بیلانس تازه کوو.
د پلیټ لومړني معلومات: دا خورا کوچنی دی، 2 MB. د ډیټابیس لپاره د غبرګون وخت او په ځانګړې توګه د نښې لپاره هم خورا ښه دی. او په کافي اندازه ښه بار - د پلیټ مطابق په هره ثانیه کې 2 عملیات.
او د دې راپور له لارې به زه تاسو ته ګرافونه وښیم ترڅو تاسو په روښانه توګه پوه شئ چې څه پیښیږي. تل به د ګرافونو سره 2 سلایډونه وي. لومړی سلایډ هغه څه دي چې په سرور کې په عمومي ډول پیښیږي.
او په دې حالت کې، موږ ګورو چې موږ واقعا یو کوچنی نښه لرو. شاخص په 2 MB کې کوچنی دی. دا په کیڼ اړخ کې لومړی ګراف دی.
په سرور کې د اوسط غبرګون وخت هم باثباته او لنډ دی. دا د پورتنۍ ښیې ګراف دی.
لاندې کیڼ ګراف تر ټولو اوږد لیږد ښیي. موږ ګورو چې لیږدونه په چټکۍ سره بشپړ شوي. او آٹوواکوم لاهم دلته کار نه کوي ، ځکه چې دا د پیل ازموینه وه. دا به کار ته دوام ورکړي او زموږ لپاره به ګټور وي.
دوهم سلایډ به تل هغه پلیټ ته وقف شي چې ازمول کیږي. پدې حالت کې، موږ په دوامداره توګه د پیرودونکي حساب بیلانس تازه کوو. او موږ ګورو چې د تازه عملیاتو لپاره د اوسط غبرګون وخت خورا ښه دی ، له ملی ثانوي څخه لږ. موږ ګورو چې د پروسیسر سرچینې (دا پورتنۍ ښیې ګراف دی) هم په مساوي او خورا کوچني مصرف کیږي.
ښکته ښیې ګراف ښیې چې موږ د دې تازه کولو دمخه د خپلې مطلوب کرښې په لټون کې څومره عملیاتي او ډیسک حافظې ته ځو. او د نښې له مخې د عملیاتو شمیر په هره ثانیه کې 2 دی ، لکه څنګه چې ما په پیل کې وویل.
او اوس موږ یوه تراژیدي لرو. د ځینو دلیلونو لپاره یو اوږد هیر شوی معامله شتون لري. لاملونه معمولا ټول حرام دي:
- یو له خورا عام څخه دا دی چې موږ د غوښتنلیک کوډ کې بهرني خدمت ته لاسرسی پیل کړ. او دا خدمت موږ ته ځواب نه راکوي. دا دی، موږ یوه معامله پرانیستله، په ډیټابیس کې یې بدلون راوست او د غوښتنلیک څخه د بریښنالیک لوستلو یا زموږ په زیربنا کې بل خدمت ته لاړ، او د ځینو دلیلونو لپاره دا موږ ته ځواب نه ورکوي. او زموږ غونډه په داسې حالت کې بنده ده چې معلومه نه ده چې دا به کله حل شي.
- دوهم حالت هغه وخت دی کله چې زموږ په کوډ کې د کوم دلیل لپاره استثنا رامینځته شوه. او په استثنا کې موږ د راکړې ورکړې بندولو پروسه نه ده کړې. او موږ د خلاصې معاملې سره د ځړولو سیشن سره پای ته ورسیدو.
- او وروستنۍ قضیه هم خورا عام قضیه ده. دا د ټیټ کیفیت کوډ دی. ځینې چوکاټونه یوه معامله پرانیزي. دا ځړیږي، او تاسو ممکن په غوښتنلیک کې نه پوهیږئ چې تاسو یې ځړول یاست.
دا ډول شیان چیرته ځي؟
دې ټکي ته چې زموږ میزونه او شاخصونه په ډراماتیک ډول وده کوي. دا په حقیقت کې ورته د ګل کولو اغیز دی. د ډیټابیس لپاره ، دا به پدې معنی وي چې د ډیټابیس غبرګون وخت به خورا ګړندی وده وکړي او د ډیټابیس سرور باندې بار به ډیر شي. او د پایلې په توګه، زموږ غوښتنلیک به زیانمن شي. ځکه چې که تاسو ډیټابیس ته د غوښتنې په اړه په خپل کوډ کې 10 ملیسیکنډونه مصرف کړي ، 10 ملیسیکنډونه ستاسو په منطق کې ، نو ستاسو فعالیت بشپړولو لپاره 20 ملی ثانیه وخت نیولی. او اوس به ستا حالت ډېر غمجن وي.
او راځئ وګورو چې څه پیښیږي. لاندې کیڼ ګراف ښیې چې موږ اوږده اوږده معامله لرو. او که موږ پورتنۍ کیڼ ګراف ته وګورو، موږ ګورو چې زموږ د میز اندازه ناڅاپه له دوه میګابایټ څخه 300 میګابایټ ته پورته شوې. په ورته وخت کې، په جدول کې د معلوماتو اندازه نه ده بدله شوې، د بیلګې په توګه هلته د کثافاتو لوی مقدار شتون لري.
د اوسط سرور غبرګون وخت په اړه عمومي وضعیت هم د شدت د څو امرونو لخوا بدل شوی. دا دی، په سرور کې ټولې غوښتنې په بشپړه توګه راټیټ شوي. او په ورته وخت کې، داخلي Postgres پروسې د Autovacuum په بڼه پیل شوي، کوم چې هڅه کوي یو څه وکړي او سرچینې مصرف کړي.
زموږ د نښې سره څه تیریږي؟ ورته. د نښې سره سم زموږ د اوسط غبرګون وخت د شدت څو امرونه پورته شوي. په ځانګړي توګه د مصرف شوي سرچینو شرایطو کې ، موږ ګورو چې پروسیسر باندې بار خورا ډیر شوی. دا د پورتنۍ ښیې ګراف دی. او دا ډیر شوی ځکه چې پروسیسر باید د اړتیا وړ یو په لټه کې د بې کاره لینونو یوه ډله ترتیب کړي. دا لاندې ښیې ګراف دی. او د پایلې په توګه، په هره ثانیه کې زموږ د تلیفونونو شمیر خورا مهم کمیدل پیل کړل، ځکه چې ډیټابیس د ورته شمیر غوښتنو پروسس کولو لپاره وخت نه درلود.
موږ باید بیرته ژوند ته راشئ. موږ آنلاین ځو او ګورو چې اوږدې راکړې ورکړې ستونزې رامینځته کوي. موږ دا معامله پیدا کوو او وژنو. او زموږ لپاره هرڅه نورمال کیږي. هر څه کار کوي لکه څنګه چې باید وي.
موږ ارام شو ، مګر یو څه وروسته موږ پوهیږو چې غوښتنلیک د بیړني حالت دمخه په ورته ډول کار نه کوي. غوښتنې لاهم په ورو او د پام وړ ورو پروسس کیږي. یو نیم څخه تر دوه ځله ورو ورو په ځانګړي توګه زما په مثال کې. په سرور باندې بار هم د حادثې دمخه په پرتله لوړ دی.
او پوښتنه: "په دې وخت کې اډې ته څه پیښیږي؟" او لاندې حالت د اډې سره واقع کیږي. د راکړې ورکړې چارټ کې تاسو لیدلی شئ چې دا بند شوی او واقعیا د اوږدې مودې لیږد شتون نلري. مګر د حادثې په جریان کې د نښو اندازه په وژونکي توګه لوړه شوه. او له هغه وخت راهیسې دوی کم شوي ندي. په اډه کې اوسط وخت ثبات لري. او ځوابونه داسې بریښي چې په کافي اندازه زموږ لپاره د منلو وړ سرعت سره راځي. آټوواکوم ډیر فعال شو او د نښان سره یو څه ترسره کول پیل کړل، ځکه چې دا د ډیرو معلوماتو له لارې لیږدولو ته اړتیا لري.
په ځانګړې توګه، د حسابونو سره د ازموینې پلیټ سره سم، چیرې چې موږ بیلانس بدلوو: د غوښتنې لپاره د غبرګون وخت داسې بریښي چې عادي حالت ته راستون شوی. مګر په حقیقت کې دا یو نیم چنده لوړ دی.
او د پروسیسر د بار څخه، موږ ګورو چې د پروسیسر بار د حادثې دمخه اړین ارزښت ته نه دی راستانه شوی. او دلیلونه یې په ټیټ ښي ګراف کې دقیقا پراته دي. دا لیدل کیدی شي چې د حافظې یو ټاکلی مقدار هلته لټون کیږي. دا، د اړتیا وړ کرښه موندلو لپاره، موږ د ډیټابیس سرور سرچینې ضایع کوو پداسې حال کې چې د بې ګټې ډیټا له لارې ترتیب کوو. په هر ثانیه کې د معاملو شمیر ثبات لري.
په ټولیز ډول ښه، مګر وضعیت د پخوا په پرتله خراب دی. زموږ د غوښتنلیک په پایله کې چې د دې ډیټابیس سره کار کوي د ډیټابیس تخریب پاک کړئ.
او د دې پوهیدو لپاره چې هلته څه پیښیږي ، که تاسو په تیرو راپور کې نه یاست ، اوس راځئ چې یو کوچنی تیوري ترلاسه کړو. د داخلي پروسې په اړه نظریه. ولې د موټر خلا او دا څه کوي؟
په لنډه توګه د پوهیدو لپاره. په ځینو وختونو کې موږ یو میز لرو. موږ په میز کې قطارونه لرو. دا لینونه فعال، ژوندي، او هغه څه چې موږ یې اوس ورته اړتیا لرو. دوی په انځور کې په شنه نښه شوي دي. او دلته د مړو کرښو شتون لري چې دمخه کار شوی ، نوي شوي ، او نوي ننوتل په دوی کې څرګند شوي. او دوی په نښه شوي چې دوی نور ډیټابیس ته په زړه پوري ندي. مګر دوی د پوسټګریس ځانګړتیا له امله په میز کې دي.
تاسو ولې د موټر ویکیوم ته اړتیا لرئ؟ په یو وخت کې ، آټوواکوم راځي ، ډیټابیس ته لاسرسی لري او پوښتنه کوي: "مهرباني وکړئ ما ته د ترټولو زوړ لیږد ID راکړئ چې دا مهال په ډیټابیس کې خلاص دی." ډیټابیس دا ID بیرته راګرځوي. او اوټوواکوم ، په دې تکیه کوي ، په میز کې د لینونو له لارې ترتیب کوي. او که هغه وګوري چې ځینې لینونه د ډیرو پخوانیو معاملو لخوا بدل شوي، نو هغه حق لري چې دوی د لینونو په توګه په نښه کړي چې موږ کولی شو په راتلونکي کې د نوي معلوماتو په لیکلو سره بیا وکاروو. دا یو پس منظر پروسه ده.
په دې وخت کې، موږ د ډیټابیس سره کار ته دوام ورکوو او په میز کې ځینې بدلونونو ته دوام ورکوو. او په دې کرښو کې، کوم چې موږ کولی شو بیا وکاروو، موږ نوي معلومات لیکو. او په دې توګه موږ یو سایکل ترلاسه کوو، د بیلګې په توګه هر وخت یو څه زاړه زاړه کرښې راښکاره کیږي، د دوی پرځای موږ نوې کرښې لیکو چې موږ ورته اړتیا لرو. او دا د PostgreSQL کار کولو لپاره یو نورمال حالت دی.
د حادثې په جریان کې څه پیښ شوي؟ دا بهیر هلته څنګه شو؟
موږ په ځینو حالتونو کې نښه درلوده، ځینې ژوندي، ځینې مړې کرښې. د موټر خلا راورسیده. هغه د ډیټابیس څخه وپوښتل چې زموږ پخوانی معامله څه ده او د هغه ID څه دی. ما دا ID ترلاسه کړ، چې کیدای شي څو ساعته مخکې، شاید لس دقیقې مخکې وي. دا پدې پورې اړه لري چې تاسو په خپل ډیټابیس کې څومره دروند بار لرئ. او هغه د لینونو په لټه کې شو چې کولی شي د بیا کارولو په توګه نښه کړي. او ما زموږ په میز کې داسې کرښې ونه موندلې.
مګر پدې وخت کې موږ د میز سره کار ته دوام ورکوو. موږ پدې کې یو څه کوو، تازه یې کوو، ډاټا بدلوو. په دې وخت کې ډیټابیس باید څه وکړي؟ هغه د موجوده جدول په پای کې د نوي لینونو اضافه کولو پرته بله چاره نه لري. او پدې توګه زموږ د میز اندازه پړسوب پیل کیږي.
په واقعیت کې، موږ د کار کولو لپاره شنه کرښې ته اړتیا لرو. مګر د داسې یوې ستونزې په جریان کې، دا معلومه شوه چې د شنو لیکو سلنه په ټول میز کې خورا ټیټه ده.
او کله چې موږ یوه پوښتنه اجرا کوو، ډیټابیس باید د ټولو لینونو څخه تیریږي: سور او شنه دواړه، د مطلوب کرښه موندلو لپاره. او د بې ګټې معلوماتو سره د میز د غوړولو اغیز د "بلوټ" په نوم یادیږي، کوم چې زموږ د ډیسک ځای هم خوري. په یاد ولرئ، دا 2 MB و، دا 300 MB شو؟ اوس میګابایټ ګیګابایټ ته بدل کړئ او تاسو به ژر تر ژره خپل ټول ډیسک سرچینې له لاسه ورکړئ.
زموږ لپاره څه پایلې کیدی شي؟
- زما په مثال کې، میز او شاخص 150 ځله وده کړې. زموږ ځینې پیرودونکي ډیرې وژونکې پیښې لري کله چې دوی په ساده ډول د ډیسک ځای له لاسه ورکولو پیل وکړ.
- پخپله د میزونو اندازه به هیڅکله کمه نشي. په ځینو مواردو کې آټوواکوم کولی شي د میز لکۍ پرې کړي که چیرې یوازې مړې کرښې شتون ولري. مګر له هغه ځایه چې دوامداره گردش شتون لري ، یو شنه کرښه ممکن په پای کې کنګل شي او تازه نشي ، پداسې حال کې چې نور ټول به د پلیټ په پیل کې یو ځای لیکل شوي وي. مګر دا دومره احتمالي پیښه ده چې ستاسو میز به پخپله د اندازې سره راټیټ شي، نو تاسو باید د هغې تمه ونه کړئ.
- ډیټابیس اړتیا لري د بې کاره لینونو ټول ګروپ له لارې ترتیب کړي. او موږ د ډیسک سرچینې ضایع کوو، موږ د پروسیسر سرچینې او بریښنا ضایع کوو.
- او دا مستقیم زموږ په غوښتنلیک اغیزه کوي ، ځکه چې که په پیل کې موږ په غوښتنې کې 10 ملیسیکنډونه مصرف کړل ، زموږ په کوډ کې 10 ملیسیکنډونه ، نو د حادثې پرمهال موږ په غوښتنه یوه ثانیه او په کوډ کې 10 ملی ثانیه مصرف کول پیل کړل ، د بیلګې په توګه یو حکم. د غوښتنلیک فعالیت کې شدت کم شوی. او کله چې حادثه حل شوه، موږ په یوه غوښتنه کې 20 ملیسیکنډونه لګول پیل کړل، په کوډ کې 10 ملی ثانیه. دا پدې مانا ده چې موږ لاهم په تولید کې یو نیم ځله راټیټ شوي. او دا ټول د یوې معاملې له امله دي چې کنګل شوي ، شاید زموږ د خطا له لارې.
- او پوښتنه: "موږ څنګه کولی شو هرڅه بیرته ترلاسه کړو؟" نو دا چې هرڅه زموږ سره سم دي او غوښتنې د حادثې دمخه په چټکۍ سره راځي.
د دې هدف لپاره د کار یو ټاکلی دوره شتون لري چې ترسره کیږي.
لومړی موږ اړتیا لرو هغه ستونزې لرونکي میزونه ومومئ چې غوړ شوي دي. موږ پوهیږو چې په ځینو جدولونو کې ریکارډ ډیر فعال دی، په نورو کې لږ فعال. او د دې لپاره موږ توسیع کاروو . د دې توسیع په نصبولو سره، تاسو کولی شئ پوښتنې ولیکئ چې تاسو سره به د میزونو په موندلو کې مرسته وکړي کوم چې خورا غوړ شوي دي.
یوځل چې تاسو دا میزونه ومومئ، تاسو اړتیا لرئ چې دوی فشار کړئ. د دې لپاره لا دمخه وسایل شتون لري. زموږ په شرکت کې موږ درې وسیلې کاروو. لومړی جوړ شوی VACUUM FULL دی. هغه ظالم، سخت او بې رحمه دی، مګر کله ناکله هغه خورا ګټور وي. и - دا د میزونو د کمپرس کولو لپاره د دریمې ډلې اسانتیاوې دي. او دوی ډیټابیس په ډیر احتیاط سره چلند کوي.
دوی د دې پورې اړه لري چې ستاسو لپاره ډیر مناسب دی کارول کیږي. مګر زه به تاسو ته په پای کې پدې اړه ووایم. اصلي خبره دا ده چې درې وسیلې شتون لري. د انتخاب کولو لپاره ډیر څه شتون لري.
وروسته له دې چې موږ هرڅه سم کړل او ډاډ ترلاسه کړو چې هرڅه سم دي، موږ باید پوه شو چې څنګه په راتلونکي کې د دې وضعیت مخه ونیسو:
- دا په اسانۍ سره مخنیوی کیدی شي. تاسو اړتیا لرئ په ماسټر سرور کې د غونډو موده وڅارئ. په ځانګړې توګه خطرناکې ناستې د راکړې ورکړې په حالت کې بې کاره دي. دا هغه څوک دي چې یوازې یو معامله یې پرانیستله، یو څه یې وکړل او پریښودل، یا په ساده ډول ځړول، په کوډ کې ورک شوي.
- او ستاسو لپاره، د پراختیا کونکو په توګه، دا مهمه ده چې ستاسو کوډ ازموینه وکړئ کله چې دا حالتونه رامینځته کیږي. دا کار سخت نه دی. دا به یو ګټور چک وي. تاسو به د لوی شمیر "ماشومانو" ستونزو څخه مخنیوی وکړئ چې د اوږدې معاملو سره تړاو لري.
پدې ګرافونو کې ، ما غوښتل تاسو ته وښیم چې څنګه د ډیټابیس نښه او چلند بدل شو وروسته له دې چې زه پدې قضیه کې د VACUUM FULL سره لاسلیک ته لاړم. دا زما لپاره تولید نه دی.
د میز اندازه سمدلاسه د یو څو میګابایټ عادي عملیاتي حالت ته راستون شوه. دا د سرور لپاره د اوسط غبرګون وخت خورا اغیزه نده کړې.
مګر په ځانګړي توګه زموږ د ازموینې نښه لپاره ، چیرې چې موږ د حساب بیلانس تازه کړی ، موږ ګورو چې په نښه کې د معلوماتو تازه کولو غوښتنې لپاره د اوسط غبرګون وخت د بیړني حالت دمخه کچې ته راټیټ شوی. د دې غوښتنې بشپړولو لپاره د پروسیسر لخوا مصرف شوي سرچینې هم د حادثې دمخه کچې ته راټیټ شوي. او ښکته ښي ګراف ښیې چې اوس موږ دقیقا هغه کرښه ومومئ چې موږ ورته سمدلاسه اړتیا لرو، پرته له دې چې د مړو لینونو انبارونو ته لاړ شو چې مخکې له دې چې د میز له فشار سره مخ شو. او د اوسط غوښتنې وخت نږدې په ورته کچه پاتې شو. مګر دلته زه زما په هارډویر کې یوه تېروتنه لرم.
دا هغه ځای دی چې لومړۍ کیسه پای ته رسیږي. دا تر ټولو عام دی. او دا د هرچا سره پیښیږي ، پرته لدې چې د پیرودونکي تجربې ته په پام سره او برنامه کونکي څومره وړ دي. ډیر ژر یا وروسته دا پیښیږي.
دویمه کیسه، په کوم کې چې موږ بار توزیع کوو او د سرور سرچینې اصلاح کوو
- موږ لا دمخه لوی شوي او جدي هلکان شوي یو. او موږ پوهیږو چې موږ یو نقل لرو او دا به زموږ لپاره ښه وي چې بار توازن وکړو: ماسټر ته ولیکئ، او د نقل څخه ولولئ. او معمولا دا وضعیت رامینځته کیږي کله چې موږ غواړو ځینې راپورونه یا ETL چمتو کړو. او سوداګرۍ په دې اړه ډیر خوشحاله دی. هغه واقعیا د ډیری پیچلي تحلیلونو سره مختلف راپورونه غواړي.
- راپورونه ډیر ساعتونه وخت نیسي، ځکه چې پیچلې تحلیلونه په ملی ثانیو کې نشي محاسبه کیدی. موږ، د زړورو هلکانو په څیر، کوډ لیکو. د داخلولو غوښتنلیک کې موږ په ماسټر کې ریکارډ جوړوو، او په نقل کې راپورونه اجرا کوو.
- د بار ویشل.
- هرڅه سم کار کوي. موږ عالي یو.
او دا حالت څه ډول ښکاري؟ په ځانګړې توګه په دې ګرافونو کې، ما د لیږد د مودې لپاره د نقل څخه د معاملو موده هم اضافه کړه. نور ټول ګرافونه یوازې ماسټر سرور ته راجع کیږي.
په دې وخت کې، زما د راپور بورډ وده کړې وه. په دوی کې نور هم شتون لري. موږ ګورو چې د اوسط سرور ځواب وخت مستحکم دی. موږ ګورو چې په نقل کې موږ اوږدمهاله معامله لرو چې د 2 ساعتونو لپاره پرمخ ځي. موږ د اوټوواکوم خاموش عملیات ګورو، کوم چې د مړو کرښو پروسس کوي. او زموږ سره هرڅه سم دي.
په ځانګړې توګه، د ازمول شوي پلیټ مطابق، موږ هلته د حساب بیلانس تازه کولو ته دوام ورکوو. او موږ د غوښتنو لپاره باثباته ځواب وخت هم لرو ، د سرچینو مستحکم مصرف. زموږ سره هرڅه سم دي.
هرڅه سم دي تر هغه وخته چې دا راپورونه د نقل سره د شخړې له امله بیرته ډزې پیل کړي. او دوی په منظم وقفاتو کې بیرته ډزې کوي.
موږ آنلاین ځو او لوستل پیل کوو چې ولې دا پیښیږي. او موږ د حل لاره پیدا کوو.
لومړی حل د نقل کولو ځنډ زیاتول دي. موږ پوهیږو چې زموږ راپور د 3 ساعتونو لپاره تیریږي. موږ د تکرار ځنډ 3 ساعتونو ته ټاکلی. موږ هرڅه پیل کوو، مګر موږ لاهم د راپورونو سره ستونزې لرو چې ځینې وختونه لغوه کیږي.
موږ غواړو چې هرڅه سم وي. موږ نور پورته کوو. او موږ په انټرنیټ کې یو ښه ترتیب وموند - hot_standby_feedback. راځئ چې دا وګرځوو. Hot_standby_feedback موږ ته اجازه راکوي چې په ماسټر کې آٹوواکوم بیرته وساتو. په دې توګه، موږ په بشپړه توګه د نقل کولو شخړو څخه خلاص شو. او هرڅه زموږ لپاره د راپورونو سره ښه کار کوي.
او پدې وخت کې د ماسټر سرور سره څه پیښیږي؟ او موږ د ماسټر سرور سره په بشپړ ډول ستونزه کې یو. اوس موږ ګرافونه ګورو کله چې ما دا دواړه تنظیمات فعال کړل. او موږ ګورو چې زموږ په نقل کې ناسته یو څه د ماسټر سرور وضعیت باندې اغیزه پیل کړه. هغه اغیزه لري ځکه چې هغې د اوټوواکوم مخه ونیوله، کوم چې مړې کرښې پاکوي. زموږ د میز اندازه یو ځل بیا اسمان ته پورته شوه. په ټول ډیټابیس کې د اوسط پوښتنو اجرا کولو وخت هم آسمان ته رسیدلی. اوټوواکومونه یو څه سخت شول.
په ځانګړې توګه، زموږ د پلیټ څخه، موږ ګورو چې پدې کې د معلوماتو تازه کول هم اسمان ته پورته شوي. د CPU مصرف په ورته ډول خورا ډیر شوی. موږ یوځل بیا د لوی شمیر مړو ، بې ګټې لینونو څخه تیر یو. او د دې نښه لپاره د غبرګون وخت او د معاملو شمیر راټیټ شوی.
دا به څه ډول ښکاري که موږ نه پوهیږو چې ما مخکې د څه په اړه خبرې کولې؟
- موږ د ستونزو په لټه کې پیل کوو. که موږ په لومړۍ برخه کې له ستونزو سره مخ شو، موږ پوهیږو چې دا ممکن د اوږدې معاملو له امله وي او ماسټر ته لاړ شي. موږ په ماسټر کې ستونزه لرو. ساسج ورته کوي. دا تودوخه کوي، د هغې د بار اوسط شاوخوا سل دی.
- هلته غوښتنې ورو دي، مګر موږ هلته هیڅ اوږد مهاله لیږد نه وینو. او موږ نه پوهیږو چې څه شی دی. موږ نه پوهیږو چې چیرته وګورو.
- موږ د سرور تجهیزات چیک کوو. شاید زموږ برید له منځه تللی وي. شاید زموږ د حافظې لرګی سوځیدلی وي. هو، هر څه کیدی شي. مګر نه، سرورونه نوي دي، هرڅه سم کار کوي.
- هرڅوک روان دي: مدیران، پراختیا کونکي او رییس. هیڅ مرسته نه کوي.
- او په یو وخت کې هرڅه ناڅاپه خپل ځان سمول پیل کوي.
په دې وخت کې، زموږ په نقل کې غوښتنه پروسس شوه او پریښودل شوه. موږ راپور ترلاسه کړ. سوداګرۍ لاهم خوشحاله ده. لکه څنګه چې تاسو لیدلی شئ، زموږ نښه یو ځل بیا وده کړې او نه کمیږي. د غونډو سره په ګراف کې ، ما د دې اوږد لیږد یوه برخه د نقل څخه پریښوده ترڅو تاسو اټکل وکړئ چې وضعیت مستحکم کیدو پورې څومره وخت نیسي.
غونډه پای ته ورسیده. او یوازې د یو څه وخت وروسته سرور ډیر یا لږ په ترتیب کې راځي. او په ماسټر سرور کې د غوښتنو لپاره د اوسط ځواب وخت بیرته عادي حالت ته راځي. ځکه چې په نهایت کې ، اوټوواکوم فرصت لري چې دا مړې کرښې پاکې او په نښه کړي. او خپل کار یې پیل کړ. او څومره ژر چې هغه دا کوي، نو ژر به موږ په ترتیب سره ترلاسه کړو.
د ازمول شوي ټابلیټ په وینا ، چیرې چې موږ د حساب بیلانس تازه کوو ، موږ ورته ورته عکس ګورو. د اوسط حساب تازه کولو وخت هم ورو ورو نورمال کیږي. د پروسیسر لخوا مصرف شوي سرچینې هم کم شوي. او په هره ثانیه کې د معاملو شمیر نورمال ته راستنیږي. مګر بیا موږ بیرته عادي حالت ته راګرځو، لکه څنګه چې موږ د حادثې دمخه وو.
په هر حالت کې، موږ د فعالیت کمښت ترلاسه کوو، لکه په لومړي حالت کې، له یو نیم څخه تر دوه ځله، او ځینې وختونه نور.
داسې ښکاري چې موږ هرڅه سم کړي دي. بار وویشئ. تجهیزات بې کاره ندي. غوښتنې مو د خپل ذهن له مخې وېشلې، خو بیا هم هر څه خراب شول.
- hot_standby_feedback فعال نه کړئ؟ هو، دا سپارښتنه نه کیږي چې دا د ځانګړي قوي دلیلونو پرته فعال کړئ. ځکه چې دا موړ مستقیم په ماسټر سرور اغیزه کوي او هلته د اوټوواکوم عملیات وځنډوي. په یو څه نقل کې د دې فعالولو او د هغې په اړه هیرولو سره، تاسو کولی شئ ماسټر ووژنئ او د غوښتنلیک سره لوی ستونزې ترلاسه کړئ.
- max_standby_streaming_delay زیات کړئ؟ هو، د راپورونو لپاره دا ریښتیا ده. که تاسو درې ساعته راپور لرئ او تاسو نه غواړئ چې دا د نقل کولو شخړو له امله ټکر شي، نو بیا په ساده ډول ځنډ زیات کړئ. یو اوږد مهاله راپور هیڅکله هغه معلوماتو ته اړتیا نلري چې همدا اوس ډیټابیس ته رسیدلی وي. که تاسو دا د دریو ساعتونو لپاره لرئ ، نو تاسو دا د ځینې زاړه ډیټا دورې لپاره پرمخ وړئ. او ستاسو لپاره ، که درې ساعته ځنډ وي یا شپږ ساعته ځنډ به هیڅ توپیر ونلري ، مګر تاسو به په دوامداره توګه راپورونه ترلاسه کوئ او د دوی په ښکته کیدو کې به کومه ستونزه ونلري.
- په طبیعي ډول ، تاسو اړتیا لرئ په عکسونو کې اوږدې ناستې کنټرول کړئ ، په ځانګړي توګه که تاسو پریکړه وکړئ چې په عکس کې hot_standby_feedback فعال کړئ. ځکه چې هر څه کیدی شي. موږ دا نقل جوړونکي ته ورکړ ترڅو هغه غوښتنې معاینه کړي. هغه یوه لیونۍ غوښتنه لیکلې وه. هغه یې پیل کړ او د چای څښلو لپاره لاړ، او موږ تاسیس شوی ماسټر ترلاسه کړ. یا شاید موږ هلته غلط غوښتنلیک واچوو. حالات متفاوت دي. د نقلونو ناستې باید د ماسټر په څیر په احتیاط سره وڅارل شي.
- او که تاسو د نقلونو په اړه ګړندۍ او اوږدې پوښتنې لرئ ، نو پدې حالت کې دا غوره ده چې د بار توزیع کولو لپاره یې وویشئ. دا د streaming_delay لپاره لینک دی. د ګړندیو لپاره ، د کوچني تکرار ځنډ سره یو نقل ولرئ. د اوږدمهاله راپور ورکولو غوښتنو لپاره، یو نقل ولرئ چې د 6 ساعتونو یا یوه ورځ وروسته پاتې کیدی شي. دا په بشپړه توګه عادي حالت دی.
موږ پایلې په ورته ډول له منځه یوسو:
- موږ غوړ شوي میزونه پیدا کوو.
- او موږ دا د خورا مناسب وسیلې سره فشار کوو چې زموږ سره مناسب وي.
دویمه کیسه دلته پای ته رسیږي. راځئ چې دریمې کیسې ته لاړ شو.
زموږ لپاره هم خورا عام دی په کوم کې چې موږ مهاجرت کوو.
- د سافټویر هر محصول وده کوي. د دې لپاره اړتیاوې بدلیږي. په هر حالت کې، موږ غواړو پرمختګ وکړو. او داسې پیښیږي چې موږ اړتیا لرو په جدول کې ډیټا تازه کړو ، د بیلګې په توګه زموږ د مهاجرت په شرایطو کې د نوي فعالیت لپاره چې موږ یې زموږ د پراختیا برخې په توګه معرفي کوو.
- د پخوانیو معلوماتو بڼه د قناعت وړ نه ده. راځئ چې ووایو موږ اوس دوهم جدول ته مخه کوو ، چیرې چې زه پدې حسابونو کې لیږد لرم. او راځئ چې ووایو چې دوی په روبل کې وو، او موږ پریکړه وکړه چې دقت زیات کړو او په کوپیکونو کې یې وکړو. او د دې لپاره موږ اړتیا لرو یو تازه کړئ: ساحه د لیږد مقدار سره یو سل ضرب کړئ.
- په نننۍ نړۍ کې، موږ د اتوماتیک ډیټابیس نسخه کنټرول وسایل کاروو. راځی چې وایو . موږ هلته خپل مهاجرت ثبت کوو. موږ دا زموږ د ازموینې اساس کې ازمو. هر څه سم دي. تازه کول روان دي. دا د یو څه وخت لپاره کار بندوي، مګر موږ تازه معلومات ترلاسه کوو. او موږ کولی شو پدې اړه نوي فعالیت پیل کړو. هرڅه ازمول شوي او معاینه شوي. هرڅه تایید شول.
- موږ پلان شوي کارونه ترسره کړل او مهاجرت مو ترسره کړ.
دلته ستاسو په وړاندې وړاندې شوي تازه معلومات سره مهاجرت دی. څرنګه چې دا زما د حساب لیږدونه دي، پلیټ 15 GB و. او له هغه وخته چې موږ هره کرښه تازه کوو، موږ د تازه کولو سره د میز اندازه دوه برابره کړه، ځکه چې موږ هره کرښه بیا لیکلې.
د مهاجرت په جریان کې، موږ د دې پلیټ سره هیڅ شی نشو کولی، ځکه چې دې ته ټولې غوښتنې په قطار کې ولاړې وې او د دې تازه بشپړیدو پورې انتظار باسو. مګر دلته زه غواړم ستاسو پام هغو شمیرو ته واړوم چې په عمودی محور کې دي. دا دی، موږ د شاوخوا 5 ملیسیکنډونو مهاجرت دمخه د اوسط غوښتنې وخت لرو او د پروسیسر بار ، د ډیسک حافظې لوستلو لپاره د بلاک عملیاتو شمیر له 7,5 څخه کم دی.
موږ مهاجرت وکړ او بیا مو ستونزې پیدا کړې.
مهاجرت بریالی و، مګر:
- پخوانی فعالیت اوس بشپړیدو لپاره ډیر وخت نیسي.
- میز بیا په اندازه کې وده وکړه.
- په سرور باندې بار بیا د پخوا په پرتله ډیر شو.
- او البته، موږ لاهم د هغه فعالیت سره ټکر کوو چې ښه کار کړی، موږ دا یو څه ښه کړی دی.
او دا یو ځل بیا پړسوب دی، چې بیا زموږ ژوند تباه کوي.
دلته زه وښیم چې میز، د تیرو دوو قضیو په څیر، بیرته خپلو پخوانیو اندازو ته نه ځي. د اوسط سرور بار کافي ښکاري.
او که موږ د حسابونو سره میز ته وګرځو، موږ به وګورو چې د دې میز لپاره د اوسط غوښتنې وخت دوه چنده شوی. د پروسیسر بار او په حافظه کې د ترتیب شوي لینونو شمیر له 7,5 پورته پورته شو ، مګر ټیټ و. او دا د پروسیسرونو په قضیه کې 2 ځله کود شوی ، د بلاک عملیاتو په حالت کې 1,5 ځله ، د بیلګې په توګه موږ د سرور فعالیت کې تخریب ترلاسه کړ. او د پایلې په توګه - زموږ د غوښتنلیک د فعالیت تخریب. په ورته وخت کې، د تلیفونونو شمیر نږدې په ورته کچه پاتې دی.
او دلته اصلي شی دا دی چې پوه شي چې څنګه دا ډول مهاجرتونه په سمه توګه ترسره شي. او دوی باید ترسره شي. موږ دا مهاجرتونه په دوامداره توګه ترسره کوو.
- دا ډول لوی مهاجرتونه په اتوماتيک ډول نه کیږي. دوی باید تل تر کنټرول لاندې وي.
- د پوه شخص لخوا څارنه اړینه ده. که تاسو په خپل ټیم کې DBA لرئ، نو اجازه راکړئ چې DBA دا وکړي. دا د هغه دنده ده. که نه، نو بیا ترټولو تجربه لرونکي کس ته اجازه ورکړئ، څوک چې پوهیږي چې څنګه د ډیټابیس سره کار وکړي.
- د ډیټابیس نوې سکیما، حتی که موږ یو کالم تازه کړو، موږ تل په مرحلو کې چمتو کوو، د بیلګې په توګه مخکې له دې چې د غوښتنلیک نوې نسخه راوباسي:
- نوي ساحې اضافه شوي چیرې چې موږ به تازه معلومات ثبت کړو.
- موږ د زاړه ساحې څخه نوي ساحې ته په کوچنیو برخو کې ډاټا لیږدوو. موږ ولې دا کار کوو؟ لومړی، موږ تل د دې پروسې کنټرول کوو. موږ پوهیږو چې موږ دمخه ډیری بستونه لیږدولي او موږ ډیر پاتې یو.
- او دویمه مثبته اغیزه دا ده چې د هر داسې بستې په مینځ کې موږ لیږد بندوو، یو نوی پرانیزئ، او دا آټوواکوم ته اجازه ورکوي چې د پلیټ سره سم کار وکړي، د بیا کارونې لپاره مړې کرښې په نښه کړي.
- د هغه لینونو لپاره چې د غوښتنلیک د چلولو پرمهال به څرګند شي (موږ لاهم زاړه غوښتنلیک روان یو) ، موږ یو محرک اضافه کوو چې نوي برخو ته نوي ارزښتونه لیکي. زموږ په قضیه کې، دا د زوړ ارزښت سل په واسطه ضرب دی.
- که موږ په بشپړ ډول ضد یو او ورته ساحه غواړو، نو د ټولو مهاجرتونو په بشپړیدو او د غوښتنلیک نوې نسخه وړاندې کولو دمخه، موږ په ساده ډول د ساحو نوم بدلوو. زړو ته ځینې اختراع شوي نومونه ورکړل شوي، او نوي ساحې زاړه ته بدل شوي.
- او یوازې له هغې وروسته موږ د غوښتنلیک نوې نسخه پیل کوو.
او په ورته وخت کې به موږ پړسوب ترلاسه نه کړو او د فعالیت په شرایطو کې به زیان ونه وینو.
دا هغه ځای دی چې دریمه کیسه پای ته رسیږي.
او اوس د وسیلو په اړه یو څه نور توضیحات چې ما په لومړۍ کیسه کې یادونه کړې.
د بلوټ لټون کولو دمخه، تاسو باید توسیع نصب کړئ .
د دې لپاره چې تاسو د پوښتنو سره راشئ ، موږ دمخه دا پوښتنې زموږ په کار کې لیکلي دي. تاسو کولی شئ دوی وکاروئ. دلته دوه غوښتنې شتون لري.
- لومړی د کار کولو لپاره ډیر وخت نیسي، مګر دا به تاسو ته د میز څخه د بلوټ دقیق ارزښتونه وښيي.
- دوهم ګړندی کار کوي او خورا مؤثره دی کله چې تاسو اړتیا لرئ ژر تر ژره ارزونه وکړئ چې ایا د میز سره سم بلیټ شتون لري یا نه. او تاسو باید پدې هم پوه شئ چې بلوټ تل د پوسټګریس میز کې شتون لري. دا د دې MVCC ماډل ځانګړتیا ده.
- او په ډیری قضیو کې د میزونو لپاره 20٪ بلیټ نورمال دی. دا دی، تاسو باید اندیښنه ونلرئ او دا میز فشار کړئ.
موږ معلومه کړه چې څنګه میزونه وپیژنو چې د بې ګټې معلوماتو سره پړسیدلي دي.
اوس د پړسوب د حل کولو څرنګوالي په اړه:
- که موږ یو کوچنی ټابلیټ او ښه ډیسک ولرو، دا په یوه ټابلیټ کې تر یو ګیګابایټ پورې، د VACUUM FULL کارولو لپاره خورا ممکنه ده. هغه به ستاسو څخه د څو ثانیو لپاره په میز کې یو ځانګړی قفل واخلي او سمه ده، مګر هغه به هر څه په چټکۍ او سختۍ سره ترسره کړي. VACUUM FULL څه کوي؟ دا په میز کې یو ځانګړی قفل اخلي او د زاړه میزونو څخه ژوندي قطارونه نوي میز ته بیا لیکي. او په پای کې هغه د دوی ځای نیسي. دا زاړه فایلونه حذف کوي او زاړه د نوي سره بدلوي. مګر د خپل کار د مودې لپاره، دا په میز کې یو ځانګړی قفل اخلي. دا پدې مانا ده چې تاسو د دې میز سره هیڅ شی نشئ کولی: نه یې لیکئ، نه یې ولولئ، او نه یې ترمیم کړئ. او VACUUM FULL د ډیټا لیکلو لپاره اضافي ډیسک ځای ته اړتیا لري.
- بله وسیله . د دې په اصولو کې، دا د VACUUM FULL سره ورته دی، ځکه چې دا د پخوانیو فایلونو څخه نوي ته ډاټا بیا لیکي او په میز کې یې ځای نیسي. مګر په ورته وخت کې ، دا د خپل کار په پیل کې په میز کې ځانګړی قفل نه اخلي ، مګر دا یوازې هغه وخت اخلي کله چې دا دمخه د فایلونو ځای په ځای کولو لپاره چمتو ډیټا لري. د دې ډیسک سرچینې اړتیاوې د VACUUM FULL سره ورته دي. تاسو اضافي ډیسک ځای ته اړتیا لرئ، او دا ځینې وختونه مهم دي که تاسو د ټیرابایټ میزونه ولرئ. او دا خورا پروسیسر وږی دی ځکه چې دا په فعاله توګه د I/O سره کار کوي.
- دریمه ګټه ده . دا د سرچینو سره ډیر محتاط دی ځکه چې دا د یو څه مختلف اصولو سره سم کار کوي. د pgcompacttable اصلي نظر دا دی چې دا په جدول کې د تازه معلوماتو په کارولو سره ټول ژوندي قطارونه د میز پیل ته حرکت کوي. او بیا دا په دې میز کې خلا چلوي، ځکه چې موږ پوهیږو چې موږ په پیل کې ژوندي قطارونه او په پای کې مړه قطارونه لرو. او خلا پخپله دا لکۍ پرې کوي، د بیلګې په توګه دا د ډیسک ډیر اضافي ځای ته اړتیا نلري. او په ورته وخت کې، دا لاهم د سرچینو په شرایطو کې ځړول کیدی شي.
هر څه د وسیلو سره.
که تاسو د بلوټ موضوع په زړه پورې ومومئ چې دننه دننه یې ولیکئ، دلته ځینې ګټورې لینکونه دي:
- - دا زما د همکار راپور دی. دا د دې په اړه عمومي دی چې د پوسټګریس ځای د خپل کار او ژوند په جریان کې چیرته ځي. او د بلاټ په اړه د ډیټابیس مدیرانو لپاره خورا لوی او مفصل تخنیکي برخه شتون لري.
- - دا زموږ د ذخیره کولو لینک دی، چیرې چې موږ د ډیټابیس حالت چک کولو لپاره د ګټورو سکریپټونو یوه ډله ذخیره کوو. هلته تاسو کولی شئ د بلوټ لټون کولو لپاره سکریپټونه ومومئ.
- и د وسیلو لینکونه چې تاسو سره به د نښو کمولو کې مرسته وکړي.
- - دا زما د همکار څخه یو پوسټ دی. هلته هغه په جدي او تخنیکي ډول د مدیرانو سره نږدې په کچه په تفصیل سره بلیټ تحلیلوي.
ما ډیره هڅه وکړه چې د پراختیا کونکو لپاره د وحشت کیسه وښایه، ځکه چې دوی زموږ د ډیټابیس مستقیم پیرودونکي دي او باید پوه شي چې څه او کوم عملونه المل کیږي. زه هیله لرم چې بریالی شم. له پاملرنې څخه مو مننه!
پوښتنې
د راپور لپاره مننه! تاسو د دې په اړه خبرې وکړې چې تاسو څنګه کولی شئ ستونزې وپیژنئ. دوی څنګه خبرداری ورکول کیدی شي؟ دا دی، ما یو داسې وضعیت درلود چې غوښتنې یې نه یوازې ځکه چې دوی ځینې بهرني خدماتو ته لاسرسی درلود. دا یوازې ځینې وحشي یوځای کیدل وو. څو وړې وړې، بې ضرره غوښتنې وې، چې د ورځې په اوږدو کې ولاړې وې او بیا یې یو څه بې ځایه کارونه پیل کړل. دا د هغه څه سره ورته دی چې تاسو یې تشریح کوئ. دا څنګه تعقیب کړئ؟ ناست او په دوامداره توګه وګورئ چې کومه غوښتنه بنده ده؟ دا څنګه مخنیوی کیدی شي؟
پدې حالت کې، دا ستاسو د شرکت مدیرانو لپاره دنده ده، نه د DBA لپاره.
زه یو مدیر یم.
PostgreSQL د pg_stat_activity په نوم یو لید لري چې د زړه پورې پوښتنې ښیې. او تاسو کولی شئ وګورئ چې دا هلته څومره وخت ځړول کیږي.
ایا زه باید دننه راشم او په هر 5 دقیقو کې وګورم؟
کرون تنظیم کړئ او چیک کړئ. که تاسو اوږدمهاله غوښتنه لرئ، یو لیک ولیکئ او دا دی. دا دی، تاسو اړتیا نلرئ د خپلو سترګو سره وګورئ، دا اتوماتیک کیدی شي. تاسو به یو لیک ترلاسه کړئ، تاسو به یې غبرګون وښایئ. یا تاسو کولی شئ په اتوماتيک ډول ډزې وکړئ.
ایا کوم څرګند دلیلونه شتون لري چې ولې دا پیښیږي؟
ما ځینې لیست کړي دي. نور پیچلي مثالونه. او د اوږدې مودې لپاره خبرې اترې کیدی شي.
د راپور لپاره مننه! ما غوښتل د pg_repack یوټیلیټ په اړه روښانه کړم. که هغه یو ځانګړی لاک نه کوي، نو ...
هغه یو ځانګړی تالاش کوي.
... بیا زه ممکن معلومات له لاسه ورکړم. ایا زما غوښتنلیک باید پدې وخت کې هیڅ شی ثبت نه کړي؟
نه، دا د میز سره په اسانۍ سره کار کوي، د بیلګې په توګه pg_repack لومړی ټول ژوندي کرښې لیږدوي چې شتون لري. په طبیعي توګه، میز ته یو ډول ننوتل هلته واقع کیږي. هغه یوازې دا پوټکی بهر غورځوي.
دا دی، هغه واقعیا دا په پای کې کوي؟
په نهایت کې ، هغه د دې فایلونو بدلولو لپاره یو ځانګړی لاک اخلي.
ایا دا به د VACUUM FULL څخه ګړندی وي؟
VACUUM FULL، هرڅومره ژر چې دا پیل شو، سمدلاسه یو ځانګړي تالاشۍ ونیوله. او تر څو چې هغه هر څه وکړي، هغه به هغه پریږدي. او pg_repack یوازې د فایل بدلولو په وخت کې یو ځانګړی لاک اخلي. په دې وخت کې به تاسو هلته ونه لیکئ، مګر ډاټا به له لاسه ورنکړي، هرڅه به سم وي.
سلام! تاسو د موټر خلا د عملیاتو په اړه خبرې وکړې. د سور، ژیړ او شنه ثبت کولو حجرو سره یو ګراف و. دا دی، ژیړ - هغه دوی د حذف شوي په توګه په نښه کړل. او د پایلې په توګه، په دوی کې یو څه نوي لیکل کیدی شي؟
هو. پوسټګریس لاینونه نه حذفوي. هغه داسې ځانګړتیا لري. که موږ یوه کرښه تازه کړه، موږ زاړه یو د حذف شوي په توګه په نښه کړ. د راکړې ورکړې ID چې دا کرښه یې بدله کړې هلته ښکاري، او موږ نوې کرښه لیکو. او موږ ناستې لرو چې په احتمالي ډول یې لوستلی شي. په ځینو وختونو کې دوی ډیر زاړه کیږي. او د آټوواکوم کار کولو څرنګوالی دا دی چې دا د دې لینونو څخه تیریږي او د غیر ضروري په توګه نښه کوي. او تاسو کولی شئ هلته ډاټا له سره لیکئ.
زه پوهیږم. مګر دا هغه څه ندي چې پوښتنه یې په اړه ده. ما ختم نه کړ. راځئ فرض کړو چې موږ یو میز لرو. دا د متغیر اندازه ساحې لري. او که زه هڅه وکړم چې یو څه نوی داخل کړم، دا ممکن په ساده ډول په زاړه حجره کې مناسب نه وي.
نه، په هر حالت کې ټوله کرښه هلته تازه کیږي. پوسټګریس د ډیټا ذخیره کولو دوه ماډلونه لري. دا د ډیټا ډول څخه غوره کوي. دلته ډاټا شتون لري چې په مستقیم ډول په جدول کې زیرمه شوي، او د ټاس ډیټا هم شتون لري. دا د ډیټا لوی مقدار دي: متن، json. دوی په جلا تختو کې ساتل کیږي. او د دې ټابلیټونو له مخې ، د بلوټ سره ورته کیسه پیښیږي ، یعنی هرڅه یو شان دي. دوی یوازې په جلا توګه لیست شوي دي.
د راپور لپاره مننه! ایا دا د منلو وړ ده چې د مودې محدودولو لپاره د بیان وخت پای پوښتنو څخه کار واخلئ؟
ډیر د منلو وړ. موږ دا هر ځای کاروو. او له هغه ځایه چې موږ خپل خدمات نلرو، موږ لیرې ملاتړ چمتو کوو، موږ ډیری پیرودونکي لرو. او هرڅوک په بشپړ ډول له دې څخه راضي دي. دا دی، موږ د کرون دندې لرو چې چک کوي. د غونډو موده په ساده ډول د پیرودونکي سره موافقه کیږي، مخکې له دې چې موږ موافق نه یو. دا کیدای شي یوه دقیقه وي، دا کیدای شي 10 دقیقې وي. دا په بیس او د هغې هدف باندې بار پورې اړه لري. مګر موږ ټول pg_stat_activity کاروو.
د راپور لپاره مننه! زه هڅه کوم چې ستاسو راپور زما غوښتنلیکونو کې پلي کړم. او داسې ښکاري چې موږ هرچیرې یو لیږد پیل کوو، او په روښانه توګه یې هرچیرې بشپړ کړو. که چیرې یو څه استثنا وي، نو بیا هم رول بیک واقع کیږي. او بیا ما فکر پیل کړ. په هرصورت، معامله ممکن په ښکاره ډول پیل نشي. دا شاید نجلۍ ته اشاره وي. که زه یوازې یو ریکارډ تازه کړم، ایا لیږد به په PostgreSQL کې پیل شي او یوازې هغه وخت بشپړ شي کله چې اړیکه قطع شي؟
که تاسو اوس د غوښتنلیک کچې په اړه خبرې کوئ، نو دا په هغه چلوونکي پورې اړه لري چې تاسو یې کاروئ، په ORM کې چې کارول کیږي. هلته ډیری ترتیبات شتون لري. که تاسو په اوتومات ډول ژمنې فعاله کړې وي، نو بیا یو لیږد هلته پیل کیږي او سمدلاسه بندیږي.
دا دی، دا د تازه کولو وروسته سمدلاسه تړل کیږي؟
دا په ترتیباتو پورې اړه لري. ما یو ترتیب نوم کړ. دا په اتوماتيک ډول ژمن دی. دا خورا عام دی. که دا فعاله وي، نو بیا راکړه ورکړه پرانیستل شوې او تړل شوې. پرته لدې چې تاسو په واضح ډول وویل چې "معامله پیل کړئ" او "د لیږد پای" ، مګر په ساده ډول په ناسته کې غوښتنه پیل کړه.
سلام! د راپور لپاره مننه! راځئ تصور وکړو چې موږ یو ډیټابیس لرو چې پړسوب او پړسوب دی او بیا په سرور کې ځای تیریږي. ایا د دې وضعیت د حل لپاره کوم وسیلې شتون لري؟
په سرور کې ځای باید په سمه توګه وڅیړل شي.
د مثال په توګه، DBA د چای لپاره لاړ، په یوه ریزورټ کې و، او داسې نور.
کله چې د فایل سیسټم رامینځته شي ، لږترلږه یو ډول بیک اپ ځای رامینځته کیږي چیرې چې ډاټا نه لیکل کیږي.
څه که دا په بشپړه توګه له صفر څخه ښکته وي؟
هلته ورته خوندي ځای ویل کیږي، د بیلګې په توګه دا آزاد کیدی شي او په دې پورې اړه لري چې دا څومره لوی جوړ شوی، تاسو وړیا ځای ترلاسه کوئ. په ډیفالټ زه نه پوهیږم چې څومره شتون لري. او په بل حالت کې، ډیسکونه وړاندې کړئ ترڅو تاسو د بیا رغونې عملیات ترسره کولو لپاره خونه ولرئ. تاسو کولی شئ ځینې میزونه حذف کړئ چې تاسو یې تضمین یاست چې اړتیا نلري.
ایا کوم بل وسایل شته؟
دا تل په لاس جوړ شوی دی. او په محلي توګه دا روښانه کیږي چې هلته څه کول غوره دي، ځکه چې ځینې معلومات مهم دي او ځینې یې غیر مهم دي. او د هر ډیټابیس او غوښتنلیک لپاره چې ورسره کار کوي ، دا په سوداګرۍ پورې اړه لري. دا تل په محلي توګه پریکړه کیږي.
د راپور لپاره مننه! زه دوه پوښتنې لرم. لومړی، تاسو سلایډونه وښودل چې وښودله چې کله لیږدونه ودریږي، د میز ځای اندازه او د شاخص اندازه دواړه وده کوي. او نور په راپور کې د اسانتیاو یوه ډله وه چې ټابلیټ بسته کوي. د شاخص په اړه څه؟
دوی هم بسته بندي کوي.
مګر خلا په شاخص اغیزه نه کوي؟
ځینې یې د شاخص سره کار کوي. د مثال په توګه، pg_rapack، pgcompacttable. خلا شاخصونه بیا جوړوي او اغیزه کوي. د VACUUM FULL سره مفکوره دا ده چې هرڅه له سره لیکي، د بیلګې په توګه دا د هرچا سره کار کوي.
او دویمه پوښتنه. زه نه پوهیږم چې ولې د نقلونو راپورونه پخپله په نقل باندې دومره تکیه کوي. ماته داسې بریښي چې راپورونه لوستل کیږي، او نقل لیکل کیږي.
د تکراري شخړې لامل څه شی دی؟ موږ یو ماسټر لرو چې پروسې ترسره کیږي. موږ د موټر ویکیوم روان یو. اوټوواکوم په حقیقت کې څه کوي؟ هغه ځینې زړې کرښې پرې کوي. که په دې وخت کې موږ په ریپلیکا کې غوښتنه ولرو چې دا زاړه لینونه ولولي، او په ماسټر کې داسې وضعیت رامینځته شوی چې آټوواکوم دا کرښې د بیا لیکلو لپاره د امکان په توګه په نښه کړي، نو موږ یې له منځه یوسو. او موږ د ډیټا کڅوړه ترلاسه کړه ، کله چې موږ اړتیا لرو هغه کرښې بیا لیکلو ته اړتیا ولرو چې غوښتنه یې په نقل کې اړتیا لري ، د نقل کولو پروسه به هغه وخت ته انتظار وباسي چې تاسو تنظیم کړی. او بیا PostgreSQL به پریکړه وکړي چې د دې لپاره ډیر مهم دی. او نقل کول ورته د غوښتنې په پرتله خورا مهم دي ، او هغه به غوښتنه ډزې وکړي ترڅو په نقل کې دا بدلونونه رامینځته کړي.
اندری، زه یوه پوښتنه لرم. دا په زړه پورې ګرافونه چې تاسو د پریزنټشن په جریان کې ښودلي، ایا دا ستاسو د یو ډول کارونې کار پایله ده؟ ګرافونه څنګه جوړ شوي؟
دا یو خدمت دی .
ایا دا سوداګریز محصول دی؟
هو. دا یو سوداګریز محصول دی.
سرچینه: www.habr.com