، د "د نړۍ ترټولو غوره خلاصې سرچینې اړوند ډیټابیس" وروستۍ نسخه په څو اونیو کې راځي (که هرڅه د پلان سره سم وي). دا په کال کې یو ځل د ټن نوي ب featuresو سره د نوي نسخې خوشې کولو معمول مهالویش تعقیبوي ، او په ریښتیا سره ، دا اغیزمن دی. له همدې امله زه د PostgreSQL ټولنې فعال غړی شوم.
زما په نظر، د پخوانیو ریلیزونو برعکس، PostgreSQL 12 یو یا دوه انقلابي ځانګړتیاوې نلري (لکه ویش یا د پوښتنې موازي). ما یو ځل ټوکه وکړه چې د PostgreSQL 12 اصلي ځانګړتیا لوی ثبات دی. ایا دا هغه څه ندي چې تاسو ورته اړتیا لرئ کله چې تاسو د خپلې سوداګرۍ مهمې ډاټا اداره کوئ؟
مګر PostgreSQL 12 دلته نه دریږي: د نوي ب featuresو او پرمختګونو سره ، غوښتنلیکونه به غوره ترسره کړي ، او ټول هغه څه چې تاسو یې کولو ته اړتیا لرئ نوي کول دي!
(ښه، شاید شاخصونه بیا جوړ کړئ، مګر پدې خپرونه کې دا هغومره ویره نه ده لکه څنګه چې موږ عادت شوي یو.)
دا به عالي وي چې د PostgreSQL لوړ کړئ او سمدلاسه د غیر ضروري ګډوډي پرته د پام وړ پرمختګونو څخه خوند واخلئ. څو کاله دمخه، ما د PostgreSQL 9.4 څخه PostgreSQL 10 ته یو اپ گریڈ بیاکتنه وکړه او ولیدل چې څنګه غوښتنلیک په PostgreSQL 10 کې د ښه شوي پوښتنو موازيتوب څخه مننه وکړه. max_parallel_workers).
موافقه وکړئ، دا مناسبه ده کله چې غوښتنلیکونه د نوي کولو وروسته سمدلاسه ښه کار کوي. او موږ د کاروونکو خوښولو لپاره ډیره هڅه کوو، ځکه چې PostgreSQL د دوی څخه ډیر څه لري.
نو څنګه کولی شي PostgreSQL 12 ته یو ساده اپ گریڈ تاسو خوشحاله کړي؟ زه به اوس درته ووایم.
د شاخص کولو لوی پرمختګونه
د لیست کولو پرته، ډیټابیس به لرې نه ځي. نور څنګه کولی شئ ژر تر ژره معلومات ومومئ؟ د PostgreSQL بنسټیز لیست کولو سیسټم ویل کیږي . دا ډول شاخص د ذخیره کولو سیسټمونو لپاره مطلوب دی.
موږ په ساده ډول آپریټر کاروو CREATE INDEX ON some_table (some_column)، او PostgreSQL د شاخص تازه ساتلو لپاره ډیر کار کوي پداسې حال کې چې موږ په دوامداره توګه ارزښتونه دننه کوو ، تازه کوو او حذف کوو. هر څه په خپله کار کوي، لکه د جادو په واسطه.
مګر د PostgreSQL شاخصونه یوه ستونزه لري - دوی او د ډیسک اضافي ځای واخلئ او د معلوماتو ترلاسه کولو او تازه کولو فعالیت کم کړئ. د "بلوټ" په واسطه زما مطلب دا دی چې په غیر مؤثره توګه د شاخص جوړښت ساتل. دا ممکن - یا ممکن نه وي - د کثافاتو ټپلونو پورې اړه ولري چې دا لیرې کوي (د معلوماتو لپاره د پیټر ګغان څخه مننه))). د Index bloat په ځانګړي ډول د کاري بارونو کې د پام وړ دی چیرې چې شاخص په فعاله توګه بدلیږي.
PostgreSQL 12 د B-tree indexes فعالیت خورا ښه کوي، او د بنچمارکونو لکه TPC-C تجربو ښودلې چې اوس په اوسط ډول 40٪ لږ ځای کارول کیږي. اوس موږ لږ وخت نه یوازې د B-tree شاخصونو په ساتلو (یعنې د لیکلو عملیاتو) کې مصرف کوو ، بلکه د معلوماتو بیرته ترلاسه کولو کې هم مصرف کوو ، ځکه چې شاخصونه خورا کوچني دي.
هغه غوښتنلیکونه چې په فعاله توګه خپل میزونه تازه کوي - په ځانګړې توګه د OLTP غوښتنلیکونه () - به ډیسک وکاروي او غوښتنې به خورا مؤثره پروسس کړي. څومره چې د ډیسک ځای ډیر وي، د ډیټابیس ډیر ځای باید د زیربنا له لوړولو پرته وده وکړي.
ځینې د لوړولو ستراتیژۍ د دې ګټو څخه ګټه پورته کولو لپاره د B-tree شاخصونو بیا رغولو ته اړتیا لري (د مثال په توګه شاخصونه به په اوتومات ډول بیا نه جوړیږي). د PostgreSQL په پخوانیو نسخو کې، په میزونو کې د لوی شاخصونو بیا رغول د پام وړ کم وخت پایله درلوده ځکه چې په دې وخت کې بدلونونه نشي کیدی. مګر PostgreSQL 12 یو بل ښه ځانګړتیا لري: اوس تاسو کولی شئ د کمانډ سره موازي شاخصونه بیا جوړ کړئ تر څو په بشپړه توګه د وخت څخه مخنیوی وشي.
په PostgreSQL 12 کې د لیست کولو زیربنا ته نور پرمختګونه شتون لري. یو بل شی چې هلته یو څه جادو و - , aka WAL (د لیکلو دمخه لاګ). د لیکلو دمخه لاګ د ناکامۍ او نقل کیدو په صورت کې په PostgreSQL کې هره معامله ثبتوي. غوښتنلیکونه دا د آرشیف کولو لپاره کاروي او . البته، د لیکلو مخکې لاګ ډیسک ته لیکل شوی، کوم چې کولی شي په فعالیت اغیزه وکړي.
PostgreSQL 12 د WAL ریکارډونو سر ټیټ کړی چې د شاخص جوړولو پرمهال د GiST، GIN، او SP-GiST شاخصونو لخوا رامینځته شوي. دا څو د پام وړ ګټې وړاندې کوي: د WAL ریکارډونه لږ ډیسک ځای نیسي، او ډاټا په چټکۍ سره بیاځل کیږي، لکه د ناورین بیا رغونه یا د وخت په وخت کې بیا رغونه. که تاسو په خپلو غوښتنلیکونو کې دا ډول شاخصونه وکاروئ (د مثال په توګه ، د پوسټ جی آی ایس میشته جیوسپیټل غوښتنلیکونه د GiST شاخص ډیر کاروي) ، دا یو بل خصوصیت دی چې ستاسو په برخه کې به پرته له کومې هڅې تجربې ته د پام وړ وده ورکړي.
تقسیم کول - لوی، غوره، چټک
PostgreSQL 10 معرفي شو . په PostgreSQL 11 کې دا کارول خورا اسانه شوي. په PostgreSQL 12 کې تاسو کولی شئ د برخو پیمانه بدل کړئ.
په PostgreSQL 12 کې، د ویشلو سیسټم فعالیت د پام وړ ښه شوی، په ځانګړې توګه که چیرې په میز کې زرګونه برخې شتون ولري. د مثال په توګه، که چیرې یوه پوښتنه په میز کې یوازې څو برخې اغیزه وکړي د زرګونو سره، دا به ډیر چټک اجرا کړي. فعالیت یوازې د دې ډول پوښتنو لپاره ښه شوی نه دی. تاسو به دا هم وګورئ چې د INSERT عملیات څومره ګړندي په میزونو کې د ډیری برخو سره دي.
په کارولو سره د معلوماتو ثبت کول - په لاره کې، دا یوه ښه لاره ده او دلته یو مثال دی - په PostgreSQL 12 کې ویشل شوي میزونه هم ډیر اغیزمن شوي. د کاپي سره هرڅه دمخه ګړندي وو ، مګر په PostgreSQL 12 کې دا په بشپړ ډول الوتنه کوي.
د دې ګټو څخه مننه، PostgreSQL تاسو ته اجازه درکوي حتی لوی ډیټا سیټونه ذخیره کړئ او د دوی بیرته ترلاسه کول اسانه کړئ. او ستاسو په برخه کې هیڅ هڅه نشته. که غوښتنلیک ډیری برخې ولري، لکه د وخت لړۍ ډاټا ثبت کول، یو ساده اپ گریڈ به د پام وړ فعالیت ته وده ورکړي.
پداسې حال کې چې دا په ریښتیا د "تعلیم او خوند اخیستلو" پرمختګ ندی، PostgreSQL 12 تاسو ته اجازه درکوي بهرنۍ کیلي رامینځته کړئ چې د ویشل شوي جدولونو حواله کوي، د ویشلو سره کار کولو کې خوښۍ رامینځته کوي.
د پوښتنو سره یوازې ډیر ښه شوی
کله چې (aka CTE، aka WITH queries)، زه نشم کولی په اړه د یوې مقالې لیکلو انتظار وکړم . دا یو له هغو ځانګړتیاو څخه دی چې د غوښتنلیک ګړندی کوي. پرته لدې چې، البته، تاسو CTE کاروئ.
زه ډیری وختونه ګورم چې SQL ته نوي زده کونکي د CTEs کارولو سره مینه لري؛ که تاسو دوی په یو ځانګړي ډول ولیکئ ، نو واقعیا داسې احساس کوي چې تاسو یو لازمي برنامه لیکئ. په شخصي توګه، ما د شاوخوا ترلاسه کولو لپاره دا پوښتنې بیا لیکل خوښ کړل پرته CTE او د تولید زیاتوالی. اوس هر څه توپیر لري.
PostgreSQL 12 تاسو ته اجازه درکوي د یو ځانګړي ډول CTE انلاین کړئ پرته له کوم اړخیزو اغیزو (SELECT)، کوم چې یوازې یو ځل د غوښتنې پای ته نږدې کارول کیږي. که زه د CTE پوښتنو تعقیب کړم چې ما بیا لیکلی، ډیری یې به پدې کټګورۍ کې راشي. دا د پراختیا کونکو سره مرسته کوي روښانه کوډ ولیکي چې اوس هم په چټکۍ سره پرمخ ځي.
سربیره پردې ، PostgreSQL 12 پخپله د SQL اجرا کول غوره کوي ، پرته لدې چې تاسو څه وکړئ. او که څه هم زه شاید اوس اړتیا نلرم چې دا ډول پوښتنې اصلاح کړم ، دا خورا ښه دی چې PostgreSQL د پوښتنو اصلاح کولو کار ته دوام ورکوي.
یوازې په وخت کې (JIT) - اوس ډیفالټ
د ملاتړ سره د PostgreSQL 12 سیسټمونو کې د JIT تالیف په ډیفالټ فعال شوی. لومړی، تاسو ملاتړ ترلاسه کوئ د ځینو داخلي عملیاتو لپاره، او دوهم، د بیانونو سره پوښتنې (تر ټولو ساده مثال یې x + y دی) په انتخاب لیستونو کې (کوم چې تاسو د SELECT وروسته لرئ)، مجموعه، د WHERE بندونو سره څرګندونې او نور کولی شي د فعالیت ښه کولو لپاره JIT وکاروي.
څرنګه چې JIT په PostgreSQL 12 کې د ډیفالټ لخوا فعال شوی ، فعالیت به پخپله وده وکړي ، مګر زه وړاندیز کوم چې په PostgreSQL 11 کې د غوښتنلیک ازموینه وکړئ ، کوم چې JIT معرفي کړی ، ترڅو د پوښتنې فعالیت اندازه کړي او وګورئ چې ایا تاسو اړتیا لرئ کوم شی ټون کړئ.
په PostgreSQL 12 کې د پاتې نورو ب featuresو په اړه څه؟
PostgreSQL 12 یو ټن ښه نوي ځانګړتیاوې لري، د معیاري SQL/JSON روټ بیاناتو په کارولو سره د JSON ډیټا معاینه کولو وړتیا څخه د پیرامیټر سره څو فکتور تصدیق کولو پورې clientcert=verify-full، کالمونه او نور ډیر څه جوړ کړل. د جلا پوست لپاره کافي.
د PostgreSQL 10 په څیر، PostgreSQL 12 به د نوي کولو وروسته سمدلاسه ټول فعالیت ښه کړي. تاسو، البته، کولی شئ خپله لاره ولرئ - د پرمختګونو فعالولو دمخه د تولید سیسټم کې د ورته شرایطو لاندې غوښتنلیک ازموینه وکړئ، لکه څنګه چې ما د PostgreSQL 10 سره کړی و. حتی که PostgreSQL 12 زما د توقع څخه ډیر مستحکم وي، په ازموینه کې سست مه کوئ. غوښتنلیکونه په بشپړه توګه، مخکې له دې چې تولید ته یې خوشې کړي.
سرچینه: www.habr.com