، "دنیا کا بہترین اوپن سورس رشتہ دار ڈیٹا بیس" کا تازہ ترین ورژن چند ہفتوں میں سامنے آ رہا ہے (اگر سب کچھ منصوبہ بندی کے مطابق ہو)۔ یہ سال میں ایک بار ایک ٹن نئی خصوصیات کے ساتھ نیا ورژن جاری کرنے کے معمول کے شیڈول کی پیروی کرتا ہے، اور واضح طور پر، یہ متاثر کن ہے۔ اسی لیے میں PostgreSQL کمیونٹی کا ایک فعال رکن بن گیا۔
میری رائے میں، پچھلی ریلیز کے برعکس، 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% کم جگہ استعمال ہوتی ہے۔ اب ہم نہ صرف بی ٹری اشاریہ جات کو برقرار رکھنے (یعنی تحریری کارروائیوں پر) بلکہ ڈیٹا کی بازیافت پر بھی کم وقت صرف کرتے ہیں، کیونکہ اشاریہ جات بہت چھوٹے ہیں۔
ایپلی کیشنز جو فعال طور پر اپنے ٹیبلز کو اپ ڈیٹ کرتی ہیں - عام طور پر OLTP ایپلی کیشنز () - ڈسک کا استعمال کرے گا اور درخواستوں کو زیادہ مؤثر طریقے سے پروسیس کرے گا۔ جتنی زیادہ ڈسک اسپیس ہوگی، ڈیٹا بیس کو انفراسٹرکچر کو اپ گریڈ کیے بغیر اتنی ہی زیادہ جگہ بڑھنی ہوگی۔
کچھ اپ گریڈ کی حکمت عملیوں کے لیے ان فوائد سے فائدہ اٹھانے کے لیے بی ٹری انڈیکس کو دوبارہ بنانے کی ضرورت ہوتی ہے (جیسے خود بخود اشاریہ جات کو دوبارہ نہیں بنائے گا)۔ PostgreSQL کے پچھلے ورژنز میں، ٹیبلز پر بڑے اشاریہ جات کو دوبارہ بنانے کے نتیجے میں اہم ڈاؤن ٹائم ہوا کیونکہ اس دوران تبدیلیاں نہیں کی جا سکتی تھیں۔ لیکن پوسٹگری ایس کیو ایل 12 میں ایک اور عمدہ خصوصیت ہے: اب آپ کمانڈ کے متوازی طور پر اشاریہ جات کو دوبارہ بنا سکتے ہیں۔ مکمل طور پر ڈاؤن ٹائم سے بچنے کے لئے.
PostgreSQL 12 میں اشاریہ سازی کے بنیادی ڈھانچے میں دیگر بہتری بھی ہیں۔ ایک اور چیز جہاں کچھ جادو تھا - , aka WAL (لکھنے سے آگے لاگ)۔ ایک تحریری لاگ ان ناکامی اور نقل کی صورت میں PostgreSQL میں ہر لین دین کو ریکارڈ کرتا ہے۔ ایپلی کیشنز اسے آرکائیو کرنے کے لیے استعمال کرتی ہیں۔ . بلاشبہ، لکھنے سے آگے کا لاگ ڈسک پر لکھا جاتا ہے، جو کارکردگی کو متاثر کر سکتا ہے۔
PostgreSQL 12 نے WAL ریکارڈز کے اوور ہیڈ کو کم کر دیا ہے جو انڈیکس کی تعمیر کے دوران GiST، GIN، اور SP-GiST اشاریہ جات کے ذریعے بنائے جاتے ہیں۔ یہ کئی ٹھوس فوائد فراہم کرتا ہے: WAL ریکارڈز ڈسک کی کم جگہ لیتا ہے، اور ڈیٹا کو تیزی سے ری پلے کیا جاتا ہے، جیسے ڈیزاسٹر ریکوری یا پوائنٹ ان ٹائم ریکوری کے دوران۔ اگر آپ اپنی ایپلی کیشنز میں اس طرح کے اشاریہ جات استعمال کرتے ہیں (مثال کے طور پر، پوسٹ جی آئی ایس پر مبنی جغرافیائی ایپلی کیشنز جی ایس ٹی انڈیکس کا بہت زیادہ استعمال کرتے ہیں)، تو یہ ایک اور خصوصیت ہے جو آپ کی طرف سے بغیر کسی کوشش کے تجربے کو نمایاں طور پر بہتر بنائے گی۔
تقسیم کرنا - بڑا، بہتر، تیز
PostgreSQL 10 متعارف کرایا گیا۔ . PostgreSQL 11 میں اسے استعمال کرنا بہت آسان ہو گیا ہے۔ PostgreSQL 12 میں آپ سیکشنز کے پیمانے کو تبدیل کر سکتے ہیں۔
PostgreSQL 12 میں، پارٹیشننگ سسٹم کی کارکردگی نمایاں طور پر بہتر ہو گئی ہے، خاص طور پر اگر ٹیبل میں ہزاروں پارٹیشنز ہوں۔ مثال کے طور پر، اگر کوئی سوال ٹیبل میں صرف چند پارٹیشنز کو متاثر کرتا ہے جس میں ان میں سے ہزاروں ہیں، تو یہ بہت تیزی سے کام کرے گا۔ کارکردگی صرف اس قسم کے سوالات کے لیے بہتر نہیں ہوتی ہے۔ آپ یہ بھی دیکھیں گے کہ متعدد پارٹیشنز والی ٹیبلز پر INSERT آپریشنز کتنی تیز ہیں۔
استعمال کرتے ہوئے ڈیٹا ریکارڈ کرنا - ویسے، یہ ایک بہت اچھا طریقہ ہے اور یہاں ایک مثال ہے — PostgreSQL 12 میں تقسیم شدہ میزیں بھی زیادہ موثر ہو گئی ہیں۔ کاپی کے ساتھ سب کچھ پہلے ہی تیز تھا، لیکن PostgreSQL 12 میں یہ بالکل اڑ جاتا ہے۔
ان فوائد کی بدولت، PostgreSQL آپ کو اور بھی بڑے ڈیٹا سیٹس کو ذخیرہ کرنے اور انہیں بازیافت کرنے میں آسانی فراہم کرتا ہے۔ اور آپ کی طرف سے کوئی کوشش نہیں. اگر ایپلیکیشن میں بہت سے پارٹیشنز ہیں، جیسے کہ ٹائم سیریز کے ڈیٹا کو ریکارڈ کرنا، تو ایک سادہ اپ گریڈ اس کی کارکردگی کو نمایاں طور پر بہتر کرے گا۔
اگرچہ یہ بالکل "اپ گریڈ اور لطف اٹھائیں" کی بہتری نہیں ہے، پوسٹگری ایس کیو ایل 12 آپ کو غیر ملکی کلیدیں بنانے کی اجازت دیتا ہے جو تقسیم شدہ جدولوں کا حوالہ دیتے ہیں، جس سے تقسیم کاری کو کام کرنے میں خوشی ہوتی ہے۔
سوالات کے ساتھ ابھی بہت بہتر ہو گیا ہے۔
جب (عرف CTE، عرف سوالات کے ساتھ)، میں اس کے بارے میں مضمون لکھنے کا انتظار نہیں کر سکتا تھا۔ . یہ ان خصوصیات میں سے ایک ہے جو ایپلی کیشن کو تیز کرے گی۔ جب تک کہ، یقیناً، آپ CTE استعمال کرتے ہیں۔
مجھے اکثر معلوم ہوتا ہے کہ SQL میں نئے آنے والے CTEs استعمال کرنا پسند کرتے ہیں؛ اگر آپ انہیں کسی خاص طریقے سے لکھتے ہیں، تو واقعی ایسا محسوس ہوتا ہے کہ آپ ایک لازمی پروگرام لکھ رہے ہیں۔ ذاتی طور پر، میں نے ارد گرد حاصل کرنے کے لئے ان سوالات کو دوبارہ لکھنا پسند کیا بغیر CTE اور پیداواری صلاحیت میں اضافہ۔ اب سب کچھ مختلف ہے۔
PostgreSQL 12 آپ کو بغیر کسی ضمنی اثرات کے مخصوص قسم کے CTE کو ان لائن کرنے کی اجازت دیتا ہے (SELECT)، جو درخواست کے اختتام کے قریب صرف ایک بار استعمال ہوتا ہے۔ اگر میں نے دوبارہ لکھے ہوئے CTE سوالات پر نظر رکھی تو ان میں سے اکثر اس زمرے میں آئیں گے۔ اس سے ڈویلپرز کو واضح کوڈ لکھنے میں مدد ملتی ہے جو اب تیزی سے چلتا ہے۔
مزید برآں، PostgreSQL 12 آپ کو کچھ کرنے کی ضرورت کے بغیر، ایس کیو ایل کے عمل کو خود بہتر بناتا ہے۔ اور اگرچہ مجھے اب شاید اس طرح کے سوالات کو بہتر بنانے کی ضرورت نہیں ہوگی، یہ بہت اچھا ہے کہ PostgreSQL استفسار کی اصلاح پر کام جاری رکھے ہوئے ہے۔
Just-in-Time (JIT) - اب پہلے سے طے شدہ
سپورٹ کے ساتھ PostgreSQL 12 سسٹمز پر جے آئی ٹی کی تالیف بطور ڈیفالٹ فعال ہے۔ سب سے پہلے، آپ کو حمایت حاصل ہے کچھ اندرونی کارروائیوں کے لیے، اور دوسری بات، منتخب فہرستوں میں اظہارات کے ساتھ سوالات (سب سے آسان مثال x + y ہے) (جو آپ کے پاس SELECT کے بعد ہے)، مجموعی، WHERE شقوں کے ساتھ اظہار اور دیگر کارکردگی کو بہتر بنانے کے لیے JIT کا استعمال کر سکتے ہیں۔
چونکہ JIT بطور ڈیفالٹ PostgreSQL 12 میں فعال ہے، اس لیے کارکردگی خود بہتر ہو جائے گی، لیکن میں تجویز کرتا ہوں کہ پوسٹگری ایس کیو ایل 11 میں ایپلیکیشن کی جانچ کریں، جس نے JIT متعارف کرایا، استفسار کی کارکردگی کی پیمائش کرنے اور یہ دیکھنے کے لیے کہ کیا آپ کو کچھ ٹیون کرنے کی ضرورت ہے۔
PostgreSQL 12 میں باقی نئی خصوصیات کے بارے میں کیا خیال ہے؟
PostgreSQL 12 میں معیاری SQL/JSON روٹ ایکسپریشنز کا استعمال کرتے ہوئے JSON ڈیٹا کی جانچ کرنے کی صلاحیت سے لے کر پیرامیٹر کے ساتھ ملٹی فیکٹر تصدیق تک بہت ساری نئی خصوصیات ہیں۔ clientcert=verify-full، کالم بنائے اور بہت کچھ۔ الگ پوسٹ کے لیے کافی ہے۔
PostgreSQL 10 کی طرح، PostgreSQL 12 اپ گریڈ کے فوراً بعد مجموعی کارکردگی کو بہتر بنائے گا۔ یقیناً، آپ کا اپنا راستہ ہوسکتا ہے - بہتری کو فعال کرنے سے پہلے پروڈکشن سسٹم پر اسی طرح کے حالات میں ایپلیکیشن کی جانچ کریں، جیسا کہ میں نے PostgreSQL 10 کے ساتھ کیا تھا۔ یہاں تک کہ اگر PostgreSQL 12 میری توقع سے زیادہ مستحکم ہے، جانچ میں سستی نہ کریں۔ ایپلی کیشنز کو پیداوار میں جاری کرنے سے پہلے اچھی طرح سے۔
ماخذ: www.habr.com