د جاوا پراختیا کونکي د سترګو له لارې په PostgreSQL کې د شاخصونو روغتیا

سلام

زما نوم وانیا دی او زه د جاوا پراختیا کونکی یم. دا داسې پیښیږي چې زه د PostgreSQL سره ډیر کار کوم - ډیټابیس تنظیم کول ، جوړښت اصلاح کول ، فعالیت کول ، او د اونۍ په پای کې لږ DBA لوبول.

پدې وروستیو کې ما زموږ په مایکرو خدماتو کې ډیری ډیټابیسونه تنظیم کړي او د جاوا کتابتون یې لیکلی دی pg-index-health، کوم چې دا کار اسانه کوي ، زما وخت خوندي کوي او ما سره مرسته کوي چې د پراختیا کونکو لخوا رامینځته شوي ځینې عام غلطیو مخه ونیسي. دا هغه کتابتون دی چې نن به یې په اړه خبرې وکړو.

دادعا

د PostgreSQL اصلي نسخه چې زه ورسره کار کوم 10 دی. ټولې SQL پوښتنې چې زه یې کاروم هم په 11 نسخه کې ازمول شوي. لږترلږه ملاتړ شوی نسخه 9.6 ده.

له تاریخ څخه دمخه

دا ټول شاوخوا یو کال دمخه د داسې وضعیت سره پیل شو چې زما لپاره عجیب و: د نیلي څخه د شاخص سیالي رامینځته کول د غلطۍ سره پای ته ورسید. شاخص پخپله، د معمول په څیر، په ډیټابیس کې په ناسم حالت کې پاتې شو. د لاګ تحلیل کمښت ښودلی temp_file_limit. او موږ لاړ شو ... ژور کیندل، ما د ډیټابیس په ترتیب کې د ستونزو یوه ټوله ډله وموندله او زما آستین یې راټیټ کړ، زما په سترګو کې د چمک سره یې حل کول پیل کړل.

یوه ستونزه - د ډیفالټ ترتیب

شاید هرڅوک د پوسټګریس په اړه د استعار څخه ډیر ستړی وي ، کوم چې په کافي جوړونکي کې پرمخ وړل کیدی شي ، مګر ... د ډیفالټ ترتیب واقعیا یو شمیر پوښتنې راپورته کوي. لږترلږه، دا د پام وړ ارزښت لري د ساتنې_کار_میم, temp_file_limit, بیان_ وخت پای и lock_timeout.

زموږ په قضیه کې د ساتنې_کار_میم ډیفالټ 64 MB وه، او temp_file_limit د 2 GB شاوخوا یو څه - موږ په ساده ډول دومره حافظه نلرو چې په لوی میز کې شاخص رامینځته کړو.

له همدې امله، په pg-index-health ما یوه لړۍ راټوله کړه کلید، زما په نظر، هغه پیرامیټونه چې باید د هر ډیټابیس لپاره تنظیم شي.

دویمه ستونزه - نقل شوي شاخصونه

زموږ ډیټابیسونه په SSD ډرایو کې ژوند کوي، او موږ یې کاروو HA- د ډیری ډیټا مرکزونو سره تنظیم کول ، ماسټر کوربه او n- د نقلونو شمیر. د ډیسک ځای زموږ لپاره خورا ارزښتناکه سرچینه ده؛ دا د فعالیت او CPU مصرف څخه لږ مهم ندي. له همدې امله ، له یوې خوا ، موږ د ګړندي لوستلو لپاره شاخصونو ته اړتیا لرو ، او له بلې خوا ، موږ نه غواړو په ډیټابیس کې غیر ضروري شاخصونه وګورو ، ځکه چې دوی ځای خوري او د معلوماتو تازه کول ورو کوي.

او اوس، هرڅه بیرته راګرځول ناسم شاخصونه او کافي لیدل د اولیګ بارتونوف لخوا راپورونه، ما پریکړه وکړه چې یو "ستر" پاکول تنظیم کړم. دا معلومه شوه چې پراختیا کونکي د ډیټابیس اسنادو لوستل نه خوښوي. دوی دا ډیر نه خوښوي. د دې له امله، دوه معمولي تېروتنې رامنځته کیږي - په لومړني کیلي کې په لاسي ډول جوړ شوی شاخص او په یو ځانګړي کالم کې ورته "دستی" شاخص. حقیقت دا دی چې دوی ته اړتیا نشته - Postgres به هرڅه پخپله وکړي. دا ډول شاخصونه په خوندي ډول حذف کیدی شي ، او د دې هدف لپاره تشخیص څرګند شوي نقل شوي_انډیکسونه.

دریمه ستونزه - شاخصونه یو بل سره نښلوي

ډیری نوي پراختیا کونکي په یوه کالم کې شاخصونه رامینځته کوي. په تدریجي ډول، د دې سوداګرۍ په بشپړه توګه تجربه کولو سره، خلک د خپلو پوښتنو اصلاح کول پیل کوي او ډیر پیچلي شاخصونه اضافه کوي چې ډیری کالمونه پکې شامل دي. دا څنګه په کالمونو کې شاخصونه ښکاري A, A + B, A+B+C او همداسی پسی. د دې شاخصونو څخه لومړی دوه په خوندي ډول ایستل کیدی شي، ځکه چې دوی د دریم مخفف دي. دا د ډیسک ډیری ځای هم خوندي کوي او د دې لپاره تشخیص شتون لري قطع شوي_انډیکسونه.

څلورمه ستونزه - بهرنۍ کیلي پرته له شاخصونو

پوسټګریس تاسو ته اجازه درکوي د ملاتړ شاخص مشخص کولو پرته بهرني کلیدي خنډونه رامینځته کړئ. په ډیری حاالتو کې دا کومه ستونزه نده، او ممکن حتی پخپله ښکاره نشي ... د اوس لپاره ...

دا زموږ سره ورته و: دا یوازې هغه وخت دی چې په یو وخت کې یو دنده، د مهال ویش سره سم پرمخ وړل او د ازموینې امرونو ډیټابیس پاکول، د ماسټر کوربه لخوا موږ ته "اضافه" کول پیل شول. CPU او IO ضایع شول، غوښتنې ورو شوې او وخت پای ته ورسید، خدمت پنځه سوه و. چټک تحلیل pg_stat_activity هغه پوښتنې ښودلې لکه:

delete from <table> where id in (…)

په دې حالت کې، البته، په نښه شوي جدول کې د ID لخوا یو شاخص شتون درلود، او د شرایطو سره سم ډیر لږ ریکارډونه حذف شوي. داسې بریښي چې هرڅه باید کار وکړي، مګر، افسوس، دا نه و.

په زړه پورې یو د ژغورنې لپاره راغلی تحلیل تشریح کړئ او وویل چې په هدف جدول کې د ریکارډونو حذف کولو سربیره ، د حوالې بشپړتیا چیک هم شتون لري ، او په یو اړوند میز کې دا چیک ناکام کیږي ترتیب سکین د مناسب شاخص د نشتوالي له امله. په دې توګه تشخیص رامنځته شو بهرنۍ_کیزونه_بغیر_انډیکس.

پنځمه ستونزه - په شاخصونو کې بې ارزښته ارزښت

په ډیفالټ ، پوسټګریس کې د btree indexes کې null ارزښتونه شامل دي ، مګر دوی معمولا هلته اړتیا نلري. له همدې امله ، زه په کلکه هڅه کوم چې دا نولس لرې کړم (تشخیص indexes_with_null_values)، د ډول له مخې د نه منلو وړ کالمونو جزوي شاخصونه رامینځته کول where <A> is not null. پدې توګه زه وکولی شوم چې زموږ د یو شاخص اندازه له 1877 MB څخه 16 KB ته راټیټ کړم. او په یوه خدماتو کې، د ډیټابیس اندازه د شاخصونو څخه د ناپاک ارزښتونو د ایستلو له امله په ټولیزه توګه 16٪ (په مطلق شمیر کې د 4.3 GB لخوا) کمه شوې. د ډیسک په ځای کې د خورا ساده تعدیلاتو سره لوی سپما. 🙂

شپږمه ستونزه - د ابتدايي کیلي نشتوالی

د میکانیزم د طبیعت له امله MVCC په Postgres کې داسې حالت ممکن دی پړسوبکله چې ستاسو د میز اندازه د ډیری مړو ریکارډونو له امله په چټکۍ سره وده کوي. زه په ساده ډول باور لرم چې دا به موږ ته ګواښ ونکړي، او دا به زموږ اډې ته ونه رسیږي، ځکه چې موږ، واه!!!، عادي پراختیا کونکي یو ... زه څومره احمق او ناپوه وم ...

یوه ورځ، یو په زړه پورې مهاجرت په لوی او فعاله توګه کارول شوي میز کې ټول ریکارډونه واخیستل او تازه کړل. موږ له نیلي څخه د میز اندازې ته +100 GB ترلاسه کړل. دا د شرم خبره وه، مګر زموږ بدمرغۍ دلته پای ته نه رسیږي. وروسته له دې چې په دې میز کې آٹوواکوم 15 ساعته وروسته پای ته ورسېد، دا څرګنده شوه چې فزیکي موقعیت به بیرته راستانه نشي. موږ نشو کولی خدمت ودروو او VACUUM FULL جوړ کړو، نو موږ د کارولو پریکړه وکړه pg_repack. او بیا دا معلومه شوه چې pg_repack نه پوهیږي چې څنګه د ابتدايي کیلي یا بل انفراديت محدودیت پرته میزونه پروسس کړي، او زموږ جدول لومړنۍ کیلي نه درلوده. په دې توګه تشخیص رامنځته شو جدولونه_بغیر_لومړنۍ_کی.

د کتابتون نسخه کې 0.1.5 د میزونو او شاخصونو له بلیټ څخه د معلوماتو راټولولو او په وخت سره ورته ځواب ویلو وړتیا اضافه شوې.

اوه او اته ستونزې - ناکافي شاخصونه او نه کارول شوي شاخصونه

لاندې دوه تشخیصونه دي: جدولونه_سره_لري_لري и نه کارول شوي_انډیکسونه - په دې وروستیو کې په وروستي شکل کې راڅرګند شو. ټکی دا دی چې دوی نشي کولی یوازې ونیول شي او اضافه شي.

لکه څنګه چې ما مخکې لیکلي، موږ د ډیری نقلونو سره یو ترتیب کاروو، او په مختلفو میزبانونو کې د لوستلو بار اساسا توپیر لري. د پایلې په توګه، وضعیت په ګوته کوي چې په ځینو میزبانونو کې ځینې میزونه او شاخصونه په عملي توګه نه کارول کیږي، او د تحلیل لپاره تاسو اړتیا لرئ چې په کلستر کې د ټولو کوربه څخه احصایې راټول کړئ. احصایې بیا تنظیم کړئ دا په کلستر کې په هر کوربه کې هم اړین دی؛ تاسو دا یوازې په ماسټر کې نشئ کولی.

دې کړنلارې موږ ته اجازه راکړه چې د څو لسیزو ګیګابایټ شاخصونو په لرې کولو سره خوندي کړو چې هیڅکله نه کارول شوي ، او همدارنګه په نادره توګه کارول شوي جدولونو کې ورک شوي شاخصونه اضافه کول.

د پایلې په توګه

البته، د نږدې ټولو تشخیصونو لپاره تاسو کولی شئ تنظیم کړئ د ګوښه کولو لیست. په دې توګه، تاسو کولی شئ په چټکۍ سره په خپل غوښتنلیک کې چکونه پلي کړئ، د نوي غلطیو د څرګندیدو مخه ونیسئ، او بیا ورو ورو زاړه اصلاح کړئ.

ځینې ​​​​تشخیصونه د ډیټابیس مهاجرت څخه سمدلاسه وروسته په فعاله ازموینو کې ترسره کیدی شي. او دا شاید زما د کتابتون یو له خورا قوي ځانګړتیاو څخه وي. د کارولو مثال په کې موندل کیدی شي ډیمو.

دا معنی لري چې د نه کارول شوي یا ورک شوي شاخصونو لپاره چیکونه ترسره کړئ ، په بیله بیا د بلوټ لپاره ، یوازې په ریښتیني ډیټابیس کې. راټول شوي ارزښتونه په کې ثبت کیدی شي ټک هاوس یا د څارنې سیسټم ته لیږل کیږي.

زه واقعیا هیله لرم pg-index-health ګټور او په تقاضا کې به وي. تاسو کولی شئ د کتابتون په پراختیا کې د ستونزو په راپور ورکولو او د نوي تشخیص وړاندیز کولو له لارې هم مرسته وکړئ.

سرچینه: www.habr.com