پدې وروستیو کې ما تاسو ته وویل چې څنګه، د معیاري ترکیبونو په کارولو سره د PostgreSQL ډیټابیس څخه. نن موږ به په دې اړه خبرې وکړو چې څنګه ثبت کول په ډیر اغیزمن ډول ترسره کیدی شي په ډیټابیس کې پرته له دې چې په ترتیب کې کوم "موټر" وکاروئ - په ساده ډول د ډیټا جریان په سمه توګه تنظیم کولو سره.
#1 برخه کول
د دې په اړه یوه مقاله چې څنګه او ولې د تنظیم کولو ارزښت لري لا دمخه شتون لري، دلته به موږ په خپل دننه کې د ځینو طریقو د پلي کولو په اړه خبرې وکړو .
"د تېرې ورځې شیان ..."
په پیل کې، د هر MVP په څیر، زموږ پروژه د کافي سپک بار لاندې پیل شوه - څارنه یوازې د لسو خورا مهم سرورونو لپاره ترسره شوې، ټول میزونه نسبتا کمپیکٹ وو ... مګر لکه څنګه چې وخت تیر شو، د څارل شوي کوربه شمیره نوره هم ډیره شوه. ، او یوځل بیا موږ هڅه وکړه چې د یو سره یو څه وکړو میزونه 1.5TB په اندازه کې، موږ پوهیږو چې که څه هم دا ممکنه وه چې داسې ژوند ته دوام ورکړو، دا خورا ستونزمن و.
وختونه تقریبا د عصري وختونو په څیر وو، د PostgreSQL 9.x مختلف نسخې اړونده وې، نو ټول ویش باید "په لاسي" ترسره شي - له لارې. د جدول میراث او محرکات د متحرک سره روټینګ EXECUTE.
پایله لرونکی حل دومره نړیوال وګرځید چې دا ټولو میزونو ته ژباړل کیدی شي:
- یو خالي "سرلیک" والدین جدول اعلان شو، کوم چې ټول یې تشریح کړل اړین شاخصونه او محرکات.
- د مراجعینو له نظره ریکارډ د "روټ" جدول کې جوړ شوی، او په داخلي توګه کارول کیږي روټینګ محرک
BEFORE INSERTریکارډ په "فزیکي ډول" اړین برخې ته داخل شوی و. که چیرې داسې څه نه وي، موږ یو استثنا نیولی او ... - … په کارولو د اصلي میز د ټیمپلیټ پراساس رامینځته شوی د مطلوب نیټې د محدودیت سره برخهنو کله چې ډاټا ترلاسه کیږي، لوستل یوازې په هغې کې ترسره کیږي.
PG10: لومړۍ هڅه
مګر د میراث له لارې ویشل په تاریخي توګه د فعال لیکلو جریان یا د ماشومانو ډیری برخې سره معامله کولو لپاره مناسب ندي. د مثال په توګه، تاسو کولی شئ په یاد ولرئ چې د اړتیا وړ برخې غوره کولو لپاره الګوریتم درلود څلور اړخیز پیچلتیا، چې دا د 100+ برخو سره کار کوي ، تاسو پخپله پوهیږئ چې څنګه ...
په PG10 کې دا وضعیت د ملاتړ پلي کولو له لارې خورا ښه شوی و . له همدې امله ، موږ سمدلاسه هڅه وکړه چې دا د ذخیره کولو مهاجرت وروسته سمدلاسه پلي کړو ، مګر ...
لکه څنګه چې دا د لارښود له کیندلو وروسته معلومه شوه، په دې نسخه کې په اصلي ډول ویشل شوی جدول دا دی:
- د شاخص توضیحاتو ملاتړ نه کوي
- په دې باندې د محرکاتو ملاتړ نه کوي
- د هیچا "نسل" نشي کیدی
- ملاتړ مه کوئ
INSERT ... ON CONFLICT - نشي کولی په اتوماتيک ډول یوه برخه تولید کړي
د ریک سره په تندي کې د دردناک ضربې ترلاسه کولو سره، موږ پوهیږو چې دا به د غوښتنلیک له تعدیل پرته ناممکن وي، او د شپږو میاشتو لپاره نورې څیړنې وځنډول شوې.
PG10: دوهم چانس
نو، موږ د ستونزو حل کولو پیل وکړ چې یو له بل سره راپورته کیږي:
- ځکه چې محرک او
ON CONFLICTموږ وموندله چې موږ لاهم دوی ته دلته او هلته اړتیا لرو، نو موږ د دوی د کار کولو لپاره منځمهاله مرحله جوړه کړه پراکسي میز. - له "روټینګ" څخه خلاص شو په محرکاتو کې - دا دی، څخه
EXECUTE. - دوی یې په جلا توګه واخیستل د ټولو شاخصونو سره د ټیمپلیټ میزنو دوی حتی په پراکسي میز کې شتون نلري.
په نهایت کې ، له دې ټولو وروسته ، موږ اصلي جدول په اصلي ډول تقسیم کړ. د نوې برخې رامینځته کول لاهم د غوښتنلیک ضمیر ته پاتې دي.
د "څرمن" لغتونه
لکه څنګه چې په هر تحلیلي سیسټم کې، موږ هم درلود "حقایق" او "کټونه" (لغتونه). زموږ په قضیه کې، په دې ظرفیت کې دوی عمل وکړ، د بیلګې په توګه، ورته ورو پوښتنې یا پخپله د پوښتنې متن.
"حقایق" د اوږدې مودې لپاره د ورځې لخوا قطع شوي و ، نو موږ په آرامۍ سره زاړه برخې حذف کړې ، او دوی موږ ته زیان نه دی رسولی (لاګ!). مګر د لغتونو سره ستونزه وه ...
دا مه وایئ چې ډیری یې شتون درلود، مګر نږدې د 100TB "حقایقو" په پایله کې د 2.5TB لغت جوړ شو. تاسو نشئ کولی په اسانۍ سره له داسې میز څخه هیڅ شی حذف کړئ ، تاسو نشئ کولی دا په کافي وخت کې کمپریس کړئ ، او دې ته لیکل ورو ورو ورو شو.
د یوه لغت په څیر ... په دې کې، هر ننوتل باید په سمه توګه یو ځل وړاندې شي ... او دا سمه ده، مګر! د هرې ورځې لپاره جلا لغت! هو، دا یو ځانګړی بې ځایه والی راوړي، مګر دا اجازه ورکوي:
- ګړندی لیکل / لوستل د کوچنۍ برخې اندازې له امله
- کم حافظه مصرفوي د نورو کمپیکٹ شاخصونو سره کار کولو سره
- لږ معلومات ذخیره کړئ د زوړ لرې کولو وړتیا له امله
د اقداماتو ټول پیچلتیا په پایله کې د CPU بار ~ 30٪ کم شوی، د ډیسک بار ~ 50٪ لخوا کم شوی:
په ورته وخت کې ، موږ په ډیټابیس کې دقیقا ورته شی لیکلو ته دوام ورکړ ، یوازې د لږ بار سره.
#2 د ډیټابیس ارتقاء او ریفاکتور کول
نو موږ په هغه څه بسیا شو چې موږ یې لرو هره ورځ خپله برخه لري د معلوماتو سره. په حقیقت کې، CHECK (dt = '2018-10-12'::date) - او د ویشلو کیلي شتون لري او د ریکارډ لپاره شرایط چې یوې ځانګړې برخې ته راځي.
څرنګه چې زموږ په خدمت کې ټول راپورونه د یوې ټاکلې نیټې په شرایطو کې جوړ شوي، نو د دوی لپاره شاخصونه د "غیر ویشل شوي وخت" راهیسې ټول ډولونه دي (سرور، نیټهد پلان کينډۍ), (سرور، نیټهد پلان نوډ), (نیټهد تېروتنې ټولګي، سرور)، ...
خو اوس دوی په هره برخه کې ژوند کوي ستاسو نقلونه هر یو داسې شاخص... او په هره برخه کې نیټه یو ثابت دی... دا معلومه شوه چې اوس موږ په هر ډول شاخص کې یو په ساده ډول یو ثابت داخل کړئ د یوې ساحې په توګه، کوم چې د هغې حجم او د لټون وخت دواړه زیاتوي، مګر هیڅ نتیجه نه راوړي. دوی ریک ځان ته پریښود، اوف ...
د اصلاح کولو لار روښانه ده - ساده د ټولو شاخصونو څخه د نیټې ساحه لرې کړئ په ویشل شوي میزونو کې. زموږ حجمونو ته په پام سره، لاسته راوړنه په اړه ده 1TB/هفته!
اوس راځئ چې یادونه وکړو چې دا ټیرابایټ لاهم باید په یو ډول ثبت شي. یعنی موږ هم ډیسک باید اوس لږ بار شي! دا انځور په واضح ډول د پاکولو څخه ترلاسه شوي اغیز ښیې، کوم چې موږ یوه اونۍ وقف کړې وه:
#3 د لوړ بار "خپرول"
د بار شوي سیسټمونو یو له لویو ستونزو څخه دی بې ځایه همغږي کول ځینې عملیات چې ورته اړتیا نلري. ځینې وختونه "ځکه چې دوی پام نه کوي"، ځینې وختونه "دا په دې لاره کې اسانه وه"، مګر ژر یا وروسته تاسو باید له دې څخه ځان خلاص کړئ.
راځئ چې په مخکیني انځور کې زوم وکړو او وګورو چې موږ یو ډیسک لرو "پمپونه" د بار لاندې د دوه ځله طول البلد سره د نږدې نمونو ترمنځ، کوم چې په واضح ډول "احصایوي" باید د داسې یو شمیر عملیاتو سره پیښ نشي:
دا د ترلاسه کولو لپاره خورا اسانه دی. موږ لا دمخه څارنه پیل کړې ده نږدې 1000 سرورونه، هر یو د جلا منطقي تار لخوا پروسس کیږي ، او هر تار راټول شوي معلومات بیا تنظیموي ترڅو ډیټابیس ته په ټاکلي فریکونسۍ کې لیږل کیږي ، یو څه داسې:
setInterval(sendToDB, interval)دلته ستونزه دقیقا په حقیقت کې ده ټول تارونه تقریبا په ورته وخت کې پیل کیږي، نو د دوی د لیږلو وختونه نږدې تل "مقام ته" سره سمون لري. اوف #2...
خوشبختانه، دا د حل کولو لپاره خورا اسانه دی، د "تصادفي" رن اپ اضافه کول وخت په وخت:
setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))#۴ موږ هغه څه ذخیره کوو چې موږ ورته اړتیا لرو
دریمه دودیزه لویه ستونزه ده هیڅ زیرمه نشته هغه چیرته دی کولای اوسیدل.
د مثال په توګه، موږ د پلان نوډونو په شرایطو کې تحلیل کول ممکن کړي (دا ټول Seq Scan on users)، مګر سمدلاسه فکر وکړئ چې دوی د ډیری برخې لپاره ورته دي - دوی هیر کړي.
نه، البته، بیا ډیټابیس ته هیڅ شی نه لیکل کیږي، دا د دې سره محرک قطع کوي INSERT ... ON CONFLICT DO NOTHING. مګر دا ډاټا لاهم ډیټابیس ته رسیږي، او دا غیر ضروري ده د شخړې د چک کولو لپاره لوستل باید وکړي. اوف #3...
د کیچنګ فعال کیدو دمخه / وروسته ډیټابیس ته لیږل شوي ریکارډونو شمیر کې توپیر څرګند دی:
او دا د ذخیره کولو بار کې د کمیدو سره دی:
ټول
"هره ورځ ټیرابایټ" یوازې ویرونکی ښکاري. که تاسو هرڅه سم کوئ، نو دا یوازې دی 2^40 بایټ / 86400 ثانیې = ~12.5MB/sچې حتی د ډیسټاپ IDE پیچونه ساتل کیږي. 🙂
مګر په جدي توګه، حتی د ورځې په اوږدو کې د لس چنده "سکیو" بار سره، تاسو کولی شئ په اسانۍ سره د عصري SSDs وړتیاوې پوره کړئ.
سرچینه: www.habr.com