اشاریہ جات اور بی درخت

ایک ڈیٹا بیس ایک سیکنڈ کے مختلف حصوں میں لاکھوں قطاروں کے درمیان ایک ریکارڈ کیسے تلاش کرسکتا ہے؟

پہلے سے طے شدہ طور پر، جب ہم SELECT * FROM customers WHERE city = 'Milano' سے پوچھتے ہیں، تو Postgres کو ایک Sequential Scan انجام دینا ہوتا ہے: یہ جسمانی طور پر ہر شہر کا "Milano" سے موازنہ کرتے ہوئے ڈسک کی قطار سے پوری میز کو پڑھتا ہے۔ جب ایک ٹیبل لاکھوں ریکارڈ رکھتا ہے، تو یہ عمل کارکردگی کو خراب کر دیتا ہے۔

ان رکاوٹوں کا بنیادی ساختی جواب انڈیکس ہیں۔

اشاریہ جات (B-Trees)

اشاریہ جات بالکل اسی طرح کام کرتے ہیں جیسے کسی بڑی کتاب کے پیچھے تجزیاتی اشاریہ ہوتا ہے۔ یہ تلاش کرنے کے لیے پوری کتاب پڑھنے کے بجائے کہ یہ "Milano" کے بارے میں کہاں بات کرتی ہے، ہم پچھلے صفحات کو دیکھتے ہیں جہاں لفظ "Milano" ہمیں [p. 45, 114, 230] پر بھیجتا ہے۔ ڈیٹا بیس، پردے کے پیچھے، یہ الگ، بہت کمپیکٹ ڈیٹا ڈھانچہ (اکثر "B-Tree") بناتے ہیں جو کالم یا کالم کے ذریعے ترتیب دیا جاتا ہے، جس میں مماثل قطاروں کے فزیکل اسٹوریج کی طرف براہ راست پوائنٹر ہوتے ہیں۔

-- Creare un indice semplice
CREATE INDEX idx_customers_city ON customers(city);

یہ واحد آپریشن پوسٹگریس انجن کو متحرک کرتا ہے، جو پس منظر میں تمام city اقدار کو نکالے گا اور انڈیکس کرے گا۔ ایک بار مکمل ہونے کے بعد، ہر آنے والا SELECT ... WHERE city = '...' اڑ جائے گا!

بنیادی چابیاں اور انفرادیت

کیا آپ جانتے ہیں کہ بنیادی کلید (PRIMARY KEY) اور UNIQUE کلیدی اصول خفیہ طور پر ہڈ کے نیچے اشاریہ جات کا استعمال کرتے ہیں؟ چونکہ ڈی بی کو یہ یقینی بنانا چاہیے کہ قطاریں ڈالتے یا تبدیل کرتے وقت ای میل یا ID کبھی بھی نقل نہیں کی جاتی ہے، اس لیے PostgreSQL خود بخود ان کے اوپر ایک مضمر B-Tree انڈیکس بناتا ہے: اس طرح انفرادیت کی جانچ میں مائیکرو سیکنڈ لگتے ہیں۔

اسی لیے ID فیلڈ میں شمولیت ناقابل یقین حد تک پرفارم کرتی ہے۔

انڈیکس گرانا

اگر آپ کو احساس ہے کہ بھاری سوالات بدل گئے ہیں اور انڈیکس سے کبھی مشورہ نہیں کیا جاتا ہے، تو اسے تباہ کرنا اور اہم جگہ پر دوبارہ دعوی کرنا دانشمندی ہے:

DROP INDEX idx_customers_city;

آپ کی باری

ثانوی منفرد اشاریہ جات کی تلاش