، جو جديد نسخو ”دنيا جو بهترين اوپن سورس لاڳاپو ڊيٽابيس“ ، ڪجهه هفتن ۾ ٻاهر اچي رهيو آهي (جيڪڏهن سڀ ڪجهه رٿابندي مطابق ٿئي). هي سال ۾ هڪ ڀيرو نئين فيچرز سان گڏ نئين ورزن کي جاري ڪرڻ جي معمولي شيڊول جي پيروي ڪري ٿو، ۽ صاف طور تي، اهو شاندار آهي. ان ڪري مان پوسٽ گري ايس ايس ايل ڪميونٽي جو سرگرم ميمبر بڻجي ويو آهيان.
منهنجي خيال ۾، پوئين رليز جي برعڪس، PostgreSQL 12 ۾ هڪ يا ٻه انقلابي خاصيتون شامل نه آهن (جهڙوڪ ورهاڱي يا سوال متوازي). مون هڪ دفعو مذاق ڪيو ته PostgreSQL 12 جي بنيادي خصوصيت وڌيڪ استحڪام آهي. ڇا اهو نه آهي ته توهان کي ضرورت آهي جڏهن توهان پنهنجي ڪاروبار جي نازڪ ڊيٽا کي منظم ڪريو ٿا؟
پر PostgreSQL 12 اتي نه روڪيو: نئين خاصيتن ۽ سڌارن سان، ايپليڪيشنون بهتر ڪارڪردگي ڪنديون، ۽ توهان سڀني کي ڪرڻو آهي اپ گريڊ!
(خير، ٿي سگهي ٿو انڊيڪس کي ٻيهر ٺاهيو، پر هن رليز ۾ اهو ايترو خوفناڪ نه آهي جيترو اسان استعمال ڪندا آهيون.)
PostgreSQL کي اپڊيٽ ڪرڻ ۽ فوري طور تي غير ضروري ڀوڳ کان سواءِ اهم سڌارن مان لطف اندوز ٿيڻ تمام وڏو ٿيندو. ڪجھ سال اڳ، مون جائزو ورتو PostgreSQL 9.4 کان PostgreSQL 10 تائين اپ گريڊ ۽ ڏٺو ته ڪيئن اپليڪيشن تيز ٿي وئي آھي مھرباني ڪري پوسٽ گري ايس سي ايل 10 ۾ سوال جي برابري کي بهتر ڪرڻ جي ڪري. ۽، سڀ کان وڌيڪ، مون کان تقريبا ڪجھ به نه گھريو ويو (صرف ھڪڙي ترتيب جي ماپ مقرر ڪريو max_parallel_workers).
اتفاق ڪريو، اهو آسان آهي جڏهن ايپليڪيشنون بهتر ڪم ڪن ٿيون فوري طور تي اپ گريڊ کان پوء. ۽ اسان صارفين کي خوش ڪرڻ جي تمام گهڻي ڪوشش ڪندا آهيون، ڇاڪاڻ ته PostgreSQL انهن مان تمام گهڻو آهي.
پوء ڪيئن ٿي سگهي ٿو هڪ سادي اپ گريڊ PostgreSQL 12 ڏانهن توهان کي خوش ڪري؟ مان توهان کي هاڻي ٻڌايان ٿو.
اهم انڊيڪسنگ بهتري
انڊيڪسنگ جي بغير، ڊيٽابيس پري نه ويندي. ٻيو ڪيئن توهان جلدي معلومات ڳولي سگهو ٿا؟ PostgreSQL جو بنيادي انڊيڪسنگ سسٽم سڏيو ويندو آهي . هن قسم جي انڊيڪس اسٽوريج سسٽم لاءِ بهتر ڪئي وئي آهي.
اسان صرف آپريٽر استعمال ڪندا آهيون CREATE INDEX ON some_table (some_column)، ۽ PostgreSQL انڊيڪس کي تازه ترين رکڻ لاءِ تمام گھڻو ڪم ڪندو آھي جڏھن ته اسين مسلسل قدرن کي داخل ڪرڻ، تازه ڪاري ڪرڻ ۽ حذف ڪرڻ لاءِ. هر شي پنهنجو ڪم ڪري ٿي، ڄڻ ته جادوءَ سان.
پر PostgreSQL انڊيڪسس ۾ ھڪڙو مسئلو آھي - اھي ۽ اضافي ڊسڪ اسپيس وٺي ۽ ڊيٽا جي بحالي ۽ تازه ڪاري جي ڪارڪردگي کي گھٽايو. "بلوٽ" مان منهنجو مطلب آهي غير موثر طور تي انڊيڪس جي جوڙجڪ کي برقرار رکڻ. اهو ٿي سگهي ٿو - يا نه ٿي سگھي ٿو - ڪچري جي ٽوپل سان لاڳاپيل هجي جيڪو اهو هٽائي ٿو (معلومات لاءِ پيٽر گاگن جي مهرباني))). انڊيڪس بلوٽ خاص طور تي ڪم لوڊ ۾ قابل ذڪر آهي جتي انڊيڪس فعال طور تي تبديل ٿي رهي آهي.
PostgreSQL 12 B-tree indexes جي ڪارڪردگي کي تمام گهڻو بهتر بڻائي ٿو، ۽ TPC-C وانگر معيارن سان تجربن مان معلوم ٿيو آهي ته سراسري طور تي 40٪ گهٽ جڳهه هاڻي استعمال ڪئي وئي آهي. ھاڻي اسان گھٽ وقت خرچ ڪندا آھيون نه رڳو B-tree انڊيڪسس کي برقرار رکڻ (يعني لکڻ جي عملن تي)، پر ڊيٽا حاصل ڪرڻ تي پڻ، ڇاڪاڻ ته انڊيڪس تمام ننڍا آھن.
ايپليڪيشنون جيڪي فعال طور تي پنھنجي جدولن کي اپڊيٽ ڪن ٿيون - عام طور تي OLTP ايپليڪيشنون () - ڊسڪ استعمال ڪندو ۽ درخواستن کي وڌيڪ موثر طريقي سان پروسيس ڪندو. وڌيڪ ڊسڪ اسپيس، وڌيڪ اسپيس ڊيٽابيس کي بغير انفراسٽرڪچر کي اپ گريڊ ڪرڻ جي وڌندي آهي.
ڪجھ اپ گريڊ حڪمت عمليون انھن فائدن مان فائدو وٺڻ لاءِ B-tree indexes کي ٻيهر تعمير ڪرڻ جي ضرورت آھي (مثال طور. خودڪار طور تي انڊيڪس ٻيهر نه ٺاهيندا). PostgreSQL جي پوئين ورزن ۾، جدولن تي وڏي انڊيڪسس کي ٻيهر تعمير ڪرڻ جي نتيجي ۾ اهم وقت ختم ٿيو ڇاڪاڻ ته ان دوران تبديليون نه ٿي سگھيون. پر PostgreSQL 12 ۾ هڪ ٻي سٺي خصوصيت آهي: هاڻي توهان ڪمانڊ سان متوازي انڊيڪس ٻيهر ٺاهي سگهو ٿا مڪمل طور تي بند ٿيڻ کان بچڻ لاء.
PostgreSQL 12 ۾ انڊيڪسنگ انفراسٽرڪچر ۾ ٻيا بھتر آھن. ٻي شيءِ جتي ڪو جادو هو. , aka WAL (لکڻ-اڳتي لاگ). هڪ لکڻ-اڳتي لاگ هر ٽرانزيڪشن کي رڪارڊ ڪري ٿو PostgreSQL ۾ ناڪامي ۽ نقل جي صورت ۾. ايپليڪيشنون ان کي آرڪائيو ڪرڻ لاء استعمال ڪندا آهن ۽ . يقينا، لکڻ-اڳتي لاگ ڊسڪ ڏانهن لکيو ويو آهي، جيڪو ڪارڪردگي تي اثر انداز ڪري سگهي ٿو.
PostgreSQL 12 WAL رڪارڊز جي اوور هيڊ کي گھٽائي ڇڏيو آھي جيڪي انڊيڪس جي تعمير دوران GiST، GIN، ۽ SP-GiST انڊيڪسز پاران ٺاھيا ويا آھن. هي ڪيترن ئي قابل فائدن مهيا ڪري ٿو: WAL رڪارڊ گهٽ ڊسڪ اسپيس وٺن ٿا، ۽ ڊيٽا کي تيزيء سان ٻيهر هلايو ويندو آهي، جهڙوڪ آفت جي بحالي يا پوائنٽ ۾ وقت جي بحالي دوران. جيڪڏھن توھان پنھنجي ايپليڪيشنن ۾ اھڙيون انڊيڪس استعمال ڪندا آھيو (مثال طور، PostGIS-based geospatial ائپليڪيشنون GiST index تمام گھڻو استعمال ڪن ٿيون)، ھي ھڪ ٻي خصوصيت آھي جيڪا توھان جي طرف کان بغير ڪنھن ڪوشش جي تجربي کي بھتر بڻائيندي.
ورهاڱي - وڏو، بهتر، تيز
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 execution کي بهتر بڻائي ٿو، بغير توهان کي ڪجهه ڪرڻ جي. ۽ جيتوڻيڪ مون کي شايد هاڻي اهڙن سوالن کي بهتر ڪرڻ جي ضرورت نه پوندي، اهو تمام سٺو آهي ته PostgreSQL سوال جي اصلاح تي ڪم جاري رکي ٿو.
Just-in-Time (JIT) - ھاڻي ڊفالٽ
PostgreSQL 12 سسٽم تي سپورٽ سان JIT تاليف ڊفالٽ طور تي فعال آهي. سڀ کان پهريان، توهان کي حمايت حاصل آهي ڪجھ اندروني عملن لاءِ، ۽ ٻيو، سوالن سان گڏ ايڪسپريشنز (سڀ کان آسان مثال x + y آھي) چونڊ لسٽن ۾ (جنھن کي توھان وٽ SELECT کان پوءِ آھي)، مجموعي، ايڪسپريشنز سان WHERE شقون ۽ ٻيا استعمال ڪري سگھن ٿا JIT ڪارڪردگي کي بهتر ڪرڻ لاءِ.
جيئن ته JIT ڊفالٽ طور تي PostgreSQL 12 ۾ فعال آهي، ڪارڪردگي پنهنجي طور تي بهتر ٿي ويندي، پر مان سفارش ڪريان ٿو ايپليڪيشن کي جانچڻ جي PostgreSQL 11 ۾، جنهن JIT متعارف ڪرايو، سوال جي ڪارڪردگي کي ماپڻ لاءِ ۽ ڏسو ته ڇا توهان کي ڪنهن به شيءِ کي ترتيب ڏيڻ جي ضرورت آهي.
PostgreSQL 12 ۾ باقي نون خصوصيتن بابت ڇا؟
PostgreSQL 12 ۾ ڪافي نيون خاصيتون آهن، معياري SQL/JSON روٽ ايڪسپريشنز استعمال ڪندي JSON ڊيٽا کي ڳولڻ جي صلاحيت کان وٺي ملٽي فيڪٽر جي تصديق تائين پيراميٽر سان clientcert=verify-full، ڪالم ٺاهيا ۽ گهڻو ڪجهه. هڪ الڳ پوسٽ لاء ڪافي.
PostgreSQL 10 وانگر، PostgreSQL 12 اپ گريڊ ٿيڻ کان پوءِ فوري طور تي مجموعي ڪارڪردگي بهتر ڪندو. توهان، يقيناً، توهان جو پنهنجو طريقو اختيار ڪري سگهو ٿا - بهتر ڪرڻ کان اڳ پيداواري نظام تي ساڳين حالتن هيٺ ايپليڪيشن کي آزمايو، جيئن مون پوسٽ گري ايس ايس ايل 10 سان ڪيو هو. جيتوڻيڪ PostgreSQL 12 اڳ ۾ ئي منهنجي توقع کان وڌيڪ مستحڪم آهي، جاچ ۾ سست نه ٿيو. ايپليڪيشنن کي مڪمل طور تي، انهن کي پيداوار ۾ ڇڏڻ کان اڳ.
جو ذريعو: www.habr.com