ارے حبر! مضمون کا ترجمہ آپ کی توجہ میں پیش کرتا ہوں۔
"ریلیشنل ڈیٹا بیس کیسے کام کرتا ہے".

جب رشتہ دار ڈیٹا بیس کی بات آتی ہے تو میں مدد نہیں کرسکتا لیکن سوچتا ہوں کہ کچھ غائب ہے۔ وہ ہر جگہ استعمال ہوتے ہیں۔ چھوٹے اور مفید SQLite سے لے کر طاقتور Teradata تک بہت سے مختلف ڈیٹا بیس دستیاب ہیں۔ لیکن صرف چند مضامین ہیں جو بتاتے ہیں کہ ڈیٹا بیس کیسے کام کرتا ہے۔ آپ "howdoesarelationaldatabasework" کا استعمال کرتے ہوئے اپنے آپ کو تلاش کر سکتے ہیں تاکہ یہ معلوم ہو سکے کہ وہاں کتنے کم نتائج ہیں۔ مزید یہ کہ یہ مضامین مختصر ہیں۔ اگر آپ جدید ترین بزی ٹیکنالوجیز (BigData, NoSQL یا JavaScript) تلاش کر رہے ہیں، تو آپ کو مزید گہرائی والے مضامین ملیں گے جن میں بتایا گیا ہے کہ وہ کیسے کام کرتی ہیں۔

کیا متعلقہ ڈیٹا بیس بہت پرانے اور بہت بورنگ ہیں جنہیں یونیورسٹی کے کورسز، تحقیقی مقالات اور کتابوں کے باہر بیان کیا جا سکتا ہے؟

ایک ڈویلپر کے طور پر، مجھے ایسی چیز کا استعمال کرنے سے نفرت ہے جسے میں نہیں سمجھتا ہوں۔ اور اگر ڈیٹا بیس 40 سال سے زیادہ عرصے سے استعمال ہو رہے ہیں تو اس کی کوئی وجہ ہونی چاہیے۔ سالوں کے دوران، میں نے ان عجیب و غریب بلیک باکسز کو صحیح معنوں میں سمجھنے کے لیے سینکڑوں گھنٹے صرف کیے ہیں جو میں ہر روز استعمال کرتا ہوں۔ رشتہ دار ڈیٹا بیس بہت دلچسپ کیونکہ وہ مفید اور دوبارہ قابل استعمال تصورات پر مبنی. اگر آپ ڈیٹا بیس کو سمجھنے میں دلچسپی رکھتے ہیں، لیکن آپ کو اس وسیع موضوع پر غور کرنے کے لیے کبھی وقت یا جھکاؤ نہیں ملا، تو آپ کو اس مضمون سے لطف اندوز ہونا چاہیے۔

اگرچہ اس مضمون کا عنوان واضح ہے، اس مضمون کا مقصد یہ نہیں سمجھنا ہے کہ ڈیٹا بیس کو کیسے استعمال کیا جائے۔. لہذا، آپ کو پہلے ہی معلوم ہونا چاہئے کہ کنکشن کی ایک سادہ درخواست اور بنیادی سوالات کیسے لکھتے ہیں۔ را; بصورت دیگر آپ اس مضمون کو نہیں سمجھ سکتے۔ آپ کو صرف یہ جاننے کی ضرورت ہے، باقی میں وضاحت کروں گا۔

میں کمپیوٹر سائنس کی کچھ بنیادی باتوں سے شروع کروں گا، جیسے کہ الگورتھم کی ٹائم پیچیدگی (BigO)۔ میں جانتا ہوں کہ آپ میں سے کچھ اس تصور سے نفرت کرتے ہیں، لیکن اس کے بغیر آپ ڈیٹا بیس کے اندر کی پیچیدگیوں کو نہیں سمجھ پائیں گے۔ چونکہ یہ ایک بہت بڑا موضوع ہے، میں توجہ مرکوز کروں گا میں جو سوچتا ہوں وہ اہم ہے۔: ڈیٹا بیس کا عمل کیسے ہوتا ہے۔ SQL درخواست. میں صرف تعارف کرواتا ہوں۔ بنیادی ڈیٹا بیس تصوراتتاکہ مضمون کے آخر میں آپ کو اندازہ ہو جائے کہ ہڈ کے نیچے کیا ہو رہا ہے۔

چونکہ یہ ایک طویل اور تکنیکی مضمون ہے جس میں بہت سارے الگورتھم اور ڈیٹا ڈھانچے شامل ہیں، اس لیے اسے پڑھنے کے لیے اپنا وقت نکالیں۔ کچھ تصورات کو سمجھنا مشکل ہو سکتا ہے۔ آپ انہیں چھوڑ سکتے ہیں اور پھر بھی عمومی خیال حاصل کر سکتے ہیں۔

آپ میں سے زیادہ جاننے والوں کے لیے، اس مضمون کو 3 حصوں میں تقسیم کیا گیا ہے:

نچلی سطح اور اعلی سطحی ڈیٹا بیس کے اجزاء کا جائزہ
استفسار کی اصلاح کے عمل کا جائزہ
لین دین اور بفر پول مینجمنٹ کا جائزہ

واپس بنیادی باتوں کی طرف

برسوں پہلے (ایک کہکشاں میں بہت دور، بہت دور...)، ڈویلپرز کو ان کارروائیوں کی صحیح تعداد جاننا ہوتی تھی جو وہ کوڈنگ کر رہے تھے۔ وہ اپنے الگورتھم اور ڈیٹا ڈھانچے کو دل سے جانتے تھے کیونکہ وہ اپنے سست کمپیوٹرز کے CPU اور میموری کو ضائع کرنے کے متحمل نہیں تھے۔

اس حصے میں، میں آپ کو ان میں سے کچھ تصورات کی یاد دلاؤں گا کیونکہ وہ ڈیٹا بیس کو سمجھنے کے لیے ضروری ہیں۔ میں تصور بھی پیش کروں گا۔ ڈیٹا بیس انڈیکس.

O(1) بمقابلہ O(n2)

آج کل، بہت سے ڈویلپرز الگورتھم کی وقتی پیچیدگی کی پرواہ نہیں کرتے... اور وہ ٹھیک کہتے ہیں!

لیکن جب آپ بہت سارے ڈیٹا کے ساتھ کام کر رہے ہیں (میں ہزاروں کی بات نہیں کر رہا ہوں) یا اگر آپ ملی سیکنڈ میں جدوجہد کر رہے ہیں، تو اس تصور کو سمجھنا ضروری ہو جاتا ہے۔ اور جیسا کہ آپ تصور کر سکتے ہیں، ڈیٹا بیس کو دونوں صورتوں سے نمٹنا پڑتا ہے! میں آپ کو پوائنٹ حاصل کرنے کے لیے ضرورت سے زیادہ وقت نہیں گزاروں گا۔ اس سے ہمیں بعد میں لاگت پر مبنی اصلاح کے تصور کو سمجھنے میں مدد ملے گی (لاگت آئے کی بنیاد پر اصلاح کے).

تصور

الگورتھم کی وقت کی پیچیدگی یہ دیکھنے کے لیے استعمال کیا جاتا ہے کہ ڈیٹا کی دی گئی مقدار کے لیے الگورتھم کو مکمل ہونے میں کتنا وقت لگے گا۔. اس پیچیدگی کو بیان کرنے کے لیے، ہم بڑے O ریاضیاتی اشارے کا استعمال کرتے ہیں۔ یہ اشارے ایک فنکشن کے ساتھ استعمال ہوتا ہے جو یہ بتاتا ہے کہ ایک الگورتھم کو دی گئی تعداد کے ان پٹ کے لیے کتنے آپریشنز کی ضرورت ہے۔

مثال کے طور پر، جب میں کہتا ہوں کہ "اس الگورتھم میں پیچیدگی O(some_function()) ہے، تو اس کا مطلب ہے کہ الگورتھم کو ڈیٹا کی ایک خاص مقدار پر کارروائی کرنے کے لیے some_function(a_certain_amount_of_data) آپریشنز کی ضرورت ہوتی ہے۔

اس صورت میں، یہ ڈیٹا کی مقدار نہیں ہے جو اہم ہے**دوسری صورت میں ** ڈیٹا کے حجم میں اضافے کے ساتھ آپریشنز کی تعداد کیسے بڑھتی ہے۔. وقت کی پیچیدگی کارروائیوں کی صحیح تعداد فراہم نہیں کرتی ہے، لیکن عمل درآمد کے وقت کا اندازہ لگانے کا ایک اچھا طریقہ ہے۔

اس گراف میں آپ مختلف قسم کے الگورتھم وقت کی پیچیدگیوں کے لیے ان پٹ ڈیٹا کی مقدار کے مقابلے آپریشنز کی تعداد دیکھ سکتے ہیں۔ میں نے ان کو ظاہر کرنے کے لیے لوگارتھمک پیمانہ استعمال کیا۔ دوسرے الفاظ میں، ڈیٹا کی مقدار تیزی سے 1 سے 1 بلین تک بڑھ جاتی ہے۔ ہم دیکھ سکتے ہیں کہ:

O(1) یا مستقل پیچیدگی مستقل رہتی ہے (ورنہ اسے مستقل پیچیدگی نہیں کہا جائے گا)۔
O(لاگ ان کریں(n)) اربوں ڈیٹا کے باوجود کم رہتا ہے۔.
بدترین مشکل - O(n2)، جہاں آپریشنز کی تعداد تیزی سے بڑھتی ہے۔.
دوسری دو پیچیدگیاں اتنی ہی تیزی سے بڑھتی ہیں۔

مثالیں

ڈیٹا کی تھوڑی مقدار کے ساتھ، O(1) اور O(n2) کے درمیان فرق نہ ہونے کے برابر ہے۔ مثال کے طور پر، ہم کہتے ہیں کہ آپ کے پاس ایک الگورتھم ہے جسے 2000 عناصر پر کارروائی کرنے کی ضرورت ہے۔

O(1) الگورتھم کے لیے آپ کو 1 آپریشن لاگت آئے گی۔
O(log(n)) الگورتھم آپ کو 7 آپریشنز پر خرچ کرے گا۔
O(n) الگورتھم آپ کو 2 آپریشنز پر خرچ کرے گا۔
O(n*log(n)) الگورتھم آپ کو 14 آپریشنز پر خرچ کرے گا۔
O(n2) الگورتھم آپ کے لیے 4 آپریشنز کی لاگت آئے گی۔

O(1) اور O(n2) کے درمیان فرق بڑا لگتا ہے (4 ملین آپریشن) لیکن آپ زیادہ سے زیادہ 2 ms کھو دیں گے، بس اپنی آنکھیں جھپکنے کا وقت ہے۔ درحقیقت، جدید پروسیسر پروسیس کر سکتے ہیں۔ فی سیکنڈ لاکھوں آپریشنز. یہی وجہ ہے کہ بہت سے IT پروجیکٹس میں کارکردگی اور اصلاح کوئی مسئلہ نہیں ہے۔

جیسا کہ میں نے کہا، ڈیٹا کی بڑی مقدار کے ساتھ کام کرتے وقت اس تصور کو جاننا اب بھی ضروری ہے۔ اگر اس بار الگورتھم کو 1 عناصر پر کارروائی کرنی ہے (جو ڈیٹا بیس کے لیے اتنا زیادہ نہیں ہے):

O(1) الگورتھم کے لیے آپ کو 1 آپریشن لاگت آئے گی۔
O(log(n)) الگورتھم آپ کو 14 آپریشنز پر خرچ کرے گا۔
O(n) الگورتھم کے لیے آپ کو 1 آپریشنز کی لاگت آئے گی۔
O(n*log(n)) الگورتھم آپ کو 14 آپریشنز پر خرچ کرے گا
O(n2) الگورتھم آپ کو 1 آپریشنز کی لاگت آئے گی

میں نے ریاضی نہیں کی ہے، لیکن میں کہوں گا کہ O(n2) الگورتھم کے ساتھ آپ کے پاس کافی پینے کا وقت ہے (دو بھی!) اگر آپ ڈیٹا والیوم میں ایک اور 0 کا اضافہ کرتے ہیں، تو آپ کے پاس جھپکی لینے کا وقت ہوگا۔

آئیے مزید گہرائی میں جائیں۔

آپ کی معلومات کے لئے:

ایک اچھی ہیش ٹیبل تلاش O(1) میں ایک عنصر تلاش کرتی ہے۔
اچھی طرح سے متوازن درخت کی تلاش O(log(n)) میں نتائج پیدا کرتی ہے۔
صف کی تلاش O(n) میں نتائج پیدا کرتی ہے۔
بہترین ترتیب دینے والے الگورتھم میں پیچیدگی O(n*log(n)) ہوتی ہے۔
خراب ترتیب دینے والے الگورتھم میں پیچیدگی O(n2) ہوتی ہے۔

نوٹ: درج ذیل حصوں میں ہم یہ الگورتھم اور ڈیٹا سٹرکچر دیکھیں گے۔

الگورتھم وقت کی پیچیدگی کی کئی قسمیں ہیں:

اوسط کیس کا منظر
بہترین صورت حال
اور بدترین صورت حال

وقت کی پیچیدگی اکثر بدترین صورت حال ہوتی ہے۔

میں صرف الگورتھم کی وقتی پیچیدگی کے بارے میں بات کر رہا تھا، لیکن پیچیدگی اس پر بھی لاگو ہوتی ہے:

الگورتھم کی میموری کی کھپت
ڈسک I/O کھپت الگورتھم

یقیناً، n2 سے بھی بدتر پیچیدگیاں ہیں، مثال کے طور پر:

n4: یہ خوفناک ہے! ذکر کردہ الگورتھم میں سے کچھ میں یہ پیچیدگی ہے۔
3n: یہ اور بھی بدتر ہے! اس مضمون کے وسط میں ہم جو الگورتھم دیکھیں گے ان میں سے ایک یہ پیچیدگی ہے (اور یہ دراصل بہت سے ڈیٹا بیس میں استعمال ہوتا ہے)۔
factorial n: آپ کو کبھی بھی اپنے نتائج حاصل نہیں ہوں گے یہاں تک کہ بہت کم ڈیٹا کے ساتھ۔
nn: اگر آپ کو اس پیچیدگی کا سامنا ہے، تو آپ کو اپنے آپ سے پوچھنا چاہیے کہ کیا یہ واقعی آپ کی سرگرمی کا میدان ہے...

نوٹ: میں نے آپ کو بڑے O عہدہ کی اصل تعریف نہیں دی، صرف ایک خیال۔ آپ یہ مضمون پڑھ سکتے ہیں۔ وکیپیڈیا حقیقی (asymptotic) تعریف کے لیے۔

ضم کریں

جب آپ کو مجموعہ ترتیب دینے کی ضرورت ہو تو آپ کیا کرتے ہیں؟ کیا؟ آپ sort() فنکشن کو کہتے ہیں... ٹھیک ہے، اچھا جواب... لیکن ڈیٹا بیس کے لیے، آپ کو سمجھنا چاہیے کہ یہ sort() فنکشن کیسے کام کرتا ہے۔

چھانٹنے کے کئی اچھے الگورتھم ہیں، اس لیے میں سب سے اہم پر توجہ دوں گا: ضم ترتیب. ہو سکتا ہے آپ کو سمجھ نہ آئے کہ ڈیٹا کو چھانٹنا ابھی کیوں مفید ہے، لیکن آپ کو استفسار کے اصلاحی حصے کے بعد کرنا چاہیے۔ مزید برآں، انضمام کی ترتیب کو سمجھنے سے ہمیں بعد میں مشترکہ ڈیٹا بیس جوائن آپریشن کو سمجھنے میں مدد ملے گی۔ ضم میں شامل (انضمام ایسوسی ایشن).

ضم

بہت سے کارآمد الگورتھم کی طرح، ضم ترتیب ایک چال پر انحصار کرتا ہے: N/2 سائز کی 2 ترتیب شدہ صفوں کو N-عنصر کی ترتیب والی صف میں جوڑنے سے صرف N آپریشنز کی لاگت آتی ہے۔ اس آپریشن کو انضمام کہا جاتا ہے۔

آئیے ایک سادہ سی مثال سے دیکھتے ہیں کہ اس کا کیا مطلب ہے:

یہ اعداد و شمار ظاہر کرتا ہے کہ حتمی ترتیب شدہ 8-عنصری صفوں کو بنانے کے لیے، آپ کو 2 4-عنصری صفوں پر صرف ایک بار اعادہ کرنے کی ضرورت ہے۔ چونکہ دونوں 4 عنصری صفوں کو پہلے ہی ترتیب دیا گیا ہے:

1) آپ دونوں موجودہ عناصر کا دو صفوں میں موازنہ کرتے ہیں (شروع میں موجودہ = پہلے)
2) پھر اسے 8 عنصر کی صف میں ڈالنے کے لیے سب سے چھوٹی کو لیں۔
3) اور صف میں اگلے عنصر پر جائیں جہاں آپ نے سب سے چھوٹا عنصر لیا تھا۔
اور 1,2,3،XNUMX،XNUMX کو دہرائیں جب تک کہ آپ صفوں میں سے کسی ایک کے آخری عنصر تک نہ پہنچ جائیں۔
پھر آپ دوسری صف کے باقی عناصر کو 8 عنصر کی صف میں ڈالنے کے لیے لیتے ہیں۔

یہ کام کرتا ہے کیونکہ دونوں 4 عنصری صفوں کو ترتیب دیا گیا ہے اور اس لیے آپ کو ان صفوں میں "واپس جانے" کی ضرورت نہیں ہے۔

اب جب کہ ہم اس چال کو سمجھ گئے ہیں، انضمام کے لیے میرا سیوڈوکوڈ یہ ہے:

array mergeSort(array a)
   if(length(a)==1)
      return a[0];
   end if

   //recursive calls
   [left_array right_array] := split_into_2_equally_sized_arrays(a);
   array new_left_array := mergeSort(left_array);
   array new_right_array := mergeSort(right_array);

   //merging the 2 small ordered arrays into a big one
   array result := merge(new_left_array,new_right_array);
   return result;

مرج سورٹ کسی مسئلے کو چھوٹے مسائل میں توڑ دیتا ہے اور پھر اصل مسئلے کا نتیجہ حاصل کرنے کے لیے چھوٹے مسائل کے نتائج تلاش کرتا ہے (نوٹ: اس قسم کے الگورتھم کو تقسیم اور فتح کہا جاتا ہے)۔ اگر آپ اس الگورتھم کو نہیں سمجھتے تو پریشان نہ ہوں؛ میں نے اسے پہلی بار دیکھا تو سمجھ نہیں آیا۔ اگر یہ آپ کی مدد کر سکتا ہے، تو میں اس الگورتھم کو دو فیز الگورتھم کے طور پر دیکھتا ہوں:

تقسیم کا مرحلہ، جہاں صف کو چھوٹی صفوں میں تقسیم کیا گیا ہے۔
چھانٹنے کا مرحلہ وہ ہے جہاں چھوٹی صفوں کو ملا کر (یونین کا استعمال کرتے ہوئے) ایک بڑی صف کی تشکیل کی جاتی ہے۔

تقسیم کا مرحلہ

تقسیم کے مرحلے میں، صف کو 3 مراحل میں وحدانی صفوں میں تقسیم کیا جاتا ہے۔ مراحل کی رسمی تعداد log(N) ہے (چونکہ N=8، log(N) = 3)۔

میں یہ کیسے جان سکتا ہوں؟

میں باصلاحیت ہوں! ایک لفظ میں - ریاضی. خیال یہ ہے کہ ہر قدم اصل صف کے سائز کو 2 سے تقسیم کرتا ہے۔ قدموں کی تعداد وہ تعداد ہے جتنی بار آپ اصل صف کو دو حصوں میں تقسیم کر سکتے ہیں۔ یہ لوگارتھم (بیس 2) کی صحیح تعریف ہے۔

چھانٹنے کا مرحلہ

چھانٹنے کے مرحلے میں، آپ وحدانی (واحد عنصر) صفوں سے شروع کرتے ہیں۔ ہر قدم کے دوران آپ متعدد ضم آپریشنز لاگو کرتے ہیں اور کل لاگت N = 8 آپریشنز ہے:

پہلے مرحلے میں آپ کے پاس 4 انضمام ہیں جن میں سے ہر ایک میں 2 آپریشن لاگت آتی ہے۔
دوسرے مرحلے میں آپ کے پاس 2 انضمام ہیں جن میں سے ہر ایک میں 4 آپریشن لاگت آتی ہے۔
تیسرے مرحلے میں آپ کے پاس 1 انضمام ہے جس کی قیمت 8 آپریشنز ہے۔

چونکہ log(N) مراحل ہیں، کل لاگت N * log(N) آپریشنز.

انضمام کی ترتیب کے فوائد

یہ الگورتھم اتنا طاقتور کیوں ہے؟

کیونکہ:

آپ میموری فوٹ پرنٹ کو کم کرنے کے لیے اسے تبدیل کر سکتے ہیں تاکہ آپ نئی صفیں نہ بنائیں بلکہ براہ راست ان پٹ ارے میں ترمیم کریں۔

نوٹ: اس قسم کا الگورتھم کہا جاتا ہے۔ in-جگہ (اضافی میموری کے بغیر چھانٹنا)۔

آپ اسے ایک ہی وقت میں ڈسک کی جگہ اور تھوڑی مقدار میں میموری استعمال کرنے کے لیے تبدیل کر سکتے ہیں بغیر اہم ڈسک I/O اوور ہیڈ کو خرچ کیے بغیر۔ خیال یہ ہے کہ میموری میں صرف ان حصوں کو لوڈ کیا جائے جن پر اس وقت کارروائی ہو رہی ہے۔ یہ ضروری ہے جب آپ کو ملٹی گیگا بائٹ ٹیبل کو صرف 100 میگا بائٹ میموری بفر کے ساتھ ترتیب دینے کی ضرورت ہو۔

نوٹ: اس قسم کا الگورتھم کہا جاتا ہے۔ بیرونی ترتیب.

آپ اسے متعدد پروسیس/تھریڈز/سرور پر چلانے کے لیے تبدیل کر سکتے ہیں۔

مثال کے طور پر، تقسیم شدہ انضمام کی ترتیب کلیدی اجزاء میں سے ایک ہے۔ حدووپ (جو بڑے ڈیٹا میں ایک ڈھانچہ ہے)۔

یہ الگورتھم لیڈ کو سونے میں بدل سکتا ہے (واقعی!)

یہ ترتیب دینے والا الگورتھم زیادہ تر (اگر سبھی نہیں) ڈیٹا بیس میں استعمال ہوتا ہے، لیکن یہ واحد نہیں ہے۔ اگر آپ مزید جاننا چاہتے ہیں تو آپ اسے پڑھ سکتے ہیں۔ تحقیقی کام، جو عام ڈیٹا بیس چھانٹنے والے الگورتھم کے فوائد اور نقصانات پر بحث کرتا ہے۔

صف، درخت اور ہیش ٹیبل

اب جب کہ ہم وقت کی پیچیدگی اور چھانٹی کے خیال کو سمجھتے ہیں، مجھے آپ کو 3 ڈیٹا ڈھانچے کے بارے میں بتانا چاہیے۔ یہ اہم ہے کیونکہ وہ جدید ڈیٹا بیس کی بنیاد ہیں۔. میں تصور بھی پیش کروں گا۔ ڈیٹا بیس انڈیکس.

صف

ایک دو جہتی سرنی سب سے آسان ڈیٹا ڈھانچہ ہے۔ ایک ٹیبل کو ایک صف کے طور پر سوچا جا سکتا ہے۔ مثال کے طور پر:

یہ 2-جہتی صف قطاروں اور کالموں کے ساتھ ایک میز ہے:

ہر لائن ایک ہستی کی نمائندگی کرتی ہے۔
کالم ایسی خصوصیات کو اسٹور کرتے ہیں جو ہستی کی وضاحت کرتے ہیں۔
ہر کالم ایک مخصوص قسم کا ڈیٹا اسٹور کرتا ہے (انٹیجر، سٹرنگ، تاریخ...)۔

یہ ڈیٹا کو ذخیرہ کرنے اور دیکھنے کے لیے آسان ہے، تاہم، جب آپ کو کوئی خاص قدر تلاش کرنے کی ضرورت ہو، تو یہ مناسب نہیں ہے۔

مثال کے طور پر، اگر آپ ان تمام لڑکوں کو تلاش کرنا چاہتے ہیں جو یو کے میں کام کرتے ہیں، تو آپ کو یہ تعین کرنے کے لیے ہر قطار کو دیکھنا ہوگا کہ آیا وہ قطار یو کے سے تعلق رکھتی ہے۔ اس سے آپ کو N لین دین کی لاگت آئے گی۔جہاں N - لائنوں کی تعداد، جو برا نہیں ہے، لیکن کیا کوئی تیز تر طریقہ ہو سکتا ہے؟ اب وقت آگیا ہے کہ ہم درختوں سے واقف ہوں۔

نوٹ: زیادہ تر جدید ڈیٹا بیس میزوں کو مؤثر طریقے سے ذخیرہ کرنے کے لیے توسیعی صفیں فراہم کرتے ہیں: ہیپ آرگنائزڈ ٹیبلز اور انڈیکس آرگنائزڈ ٹیبل۔ لیکن اس سے کالموں کے گروپ میں کسی خاص حالت کو جلدی تلاش کرنے کا مسئلہ نہیں بدلتا۔

ڈیٹا بیس ٹری اور انڈیکس

بائنری سرچ ٹری ایک بائنری ٹری ہے جس میں ایک خاص خاصیت ہے، ہر نوڈ کی کلید ہونی چاہیے:

بائیں ذیلی درخت میں محفوظ کردہ تمام چابیاں سے زیادہ
دائیں سب ٹری میں محفوظ تمام چابیاں سے کم

آئیے دیکھتے ہیں کہ بصری طور پر اس کا کیا مطلب ہے۔

خیال

اس درخت میں N = 15 عناصر ہیں۔ آئیے کہتے ہیں کہ میں 208 کی تلاش کر رہا ہوں:

میں جڑ سے شروع کرتا ہوں جس کی کلید 136 ہے۔ 136<208 سے، میں نوڈ 136 کے دائیں ذیلی درخت کو دیکھتا ہوں۔
398>208 لہذا میں نوڈ 398 کے بائیں ذیلی درخت کو دیکھ رہا ہوں۔
250>208 لہذا میں نوڈ 250 کے بائیں ذیلی درخت کو دیکھ رہا ہوں۔
200<208، اس لیے میں نوڈ 200 کے دائیں ذیلی درخت کو دیکھ رہا ہوں۔ لیکن 200 کا کوئی صحیح ذیلی درخت نہیں ہے، قدر موجود نہیں ہے (کیونکہ اگر یہ موجود ہے تو یہ صحیح ذیلی درخت 200 میں ہوگا)۔

اب ہم کہتے ہیں کہ میں 40 کی تلاش کر رہا ہوں۔

میں جڑ سے شروع کرتا ہوں جس کی کلید 136 ہے۔ 136 > 40 کے بعد سے، میں نوڈ 136 کے بائیں ذیلی درخت کو دیکھتا ہوں۔
80> 40، لہذا میں نوڈ 80 کے بائیں ذیلی درخت کو دیکھ رہا ہوں۔
40 = 40، نوڈ موجود ہے. میں نوڈ کے اندر قطار کی ID بازیافت کرتا ہوں (تصویر میں نہیں) اور دی گئی قطار ID کے لئے ٹیبل میں دیکھتا ہوں۔
قطار کی ID کو جاننے سے مجھے یہ جاننے کی اجازت ملتی ہے کہ ٹیبل میں ڈیٹا کہاں ہے، لہذا میں اسے فوری طور پر بازیافت کر سکتا ہوں۔

آخر میں، دونوں تلاشوں سے مجھے درخت کے اندر کی سطحوں کی تعداد لاگت آئے گی۔ اگر آپ انضمام کی ترتیب کے بارے میں حصہ بغور پڑھتے ہیں، تو آپ کو نظر آنا چاہیے کہ لاگ(N) کی سطحیں ہیں۔ یہ ثابت ہوتا ہے، تلاش لاگت لاگ (N)، برا نہیں ہے!

آئیے اپنے مسئلے کی طرف لوٹتے ہیں۔

لیکن یہ بہت خلاصہ ہے، تو آئیے اپنے مسئلے کی طرف واپس آتے ہیں۔ سادہ عدد کے بجائے، ایک سٹرنگ کا تصور کریں جو پچھلے جدول میں کسی کے ملک کی نمائندگی کرتی ہے۔ فرض کریں کہ آپ کے پاس ایک درخت ہے جس میں ٹیبل کا "ملک" فیلڈ (کالم 3) ہے:

اگر آپ جاننا چاہتے ہیں کہ برطانیہ میں کون کام کرتا ہے۔
آپ نوڈ حاصل کرنے کے لیے درخت کو دیکھتے ہیں جو برطانیہ کی نمائندگی کرتا ہے۔
"UKnode" کے اندر آپ کو UK ورکرز کے ریکارڈ کا مقام مل جائے گا۔

اگر آپ براہ راست صف کا استعمال کرتے ہیں تو اس تلاش میں N آپریشنز کے بجائے لاگ(N) آپریشن لاگت آئے گی۔ جو آپ نے ابھی پیش کیا تھا۔ ڈیٹا بیس انڈیکس.

آپ فیلڈز کے کسی بھی گروپ (سٹرنگ، نمبر، 2 لائنز، نمبر اور سٹرنگ، ڈیٹ...) کے لیے ایک انڈیکس ٹری بنا سکتے ہیں جب تک کہ آپ کے پاس چابیاں (یعنی فیلڈ گروپس) کا موازنہ کرنے کا فنکشن موجود ہو تاکہ آپ سیٹ کر سکیں چابیاں کے درمیان آرڈر کریں (جو ڈیٹا بیس میں کسی بھی بنیادی قسم کا معاملہ ہے)۔

B+TreeIndex

اگرچہ یہ درخت مخصوص قیمت حاصل کرنے کے لیے اچھا کام کرتا ہے، لیکن جب آپ کو ضرورت ہو تو ایک بڑا مسئلہ ہوتا ہے۔ دو اقدار کے درمیان متعدد عناصر حاصل کریں۔. اس کی لاگت O(N) ہوگی کیونکہ آپ کو درخت کے ہر نوڈ کو دیکھنا ہوگا اور یہ چیک کرنا ہوگا کہ آیا یہ ان دو قدروں کے درمیان ہے (مثال کے طور پر درخت کے ترتیب شدہ ٹراورسل کے ساتھ)۔ مزید یہ کہ یہ آپریشن ڈسک I/O دوستانہ نہیں ہے کیونکہ آپ کو پورا درخت پڑھنا پڑتا ہے۔ ہمیں مؤثر طریقے سے عمل کرنے کا راستہ تلاش کرنے کی ضرورت ہے۔ رینج کی درخواست. اس مسئلے کو حل کرنے کے لیے، جدید ڈیٹا بیس پچھلے درخت کا ایک ترمیم شدہ ورژن استعمال کرتے ہیں جسے B+Tree کہتے ہیں۔ B+Tree درخت میں:

صرف سب سے کم نوڈس (پتے) ذخیرہ معلومات (متعلقہ جدول میں قطاروں کا مقام)
باقی نوڈس یہاں ہیں روٹنگ کے لیے صحیح نوڈ پر تلاش کے دوران.

جیسا کہ آپ دیکھ سکتے ہیں، یہاں مزید نوڈس ہیں (دو بار)۔ درحقیقت، آپ کے پاس اضافی نوڈس ہیں، "فیصلہ نوڈس"، جو آپ کو صحیح نوڈ (جو متعلقہ ٹیبل میں قطاروں کا مقام محفوظ کرتا ہے) تلاش کرنے میں مدد کرے گا۔ لیکن تلاش کی پیچیدگی ابھی بھی O(log(N)) ہے (صرف ایک اور سطح ہے)۔ بڑا فرق یہ ہے۔ نچلی سطح پر نوڈس ان کے جانشینوں سے جڑے ہوئے ہیں۔.

اس B+Tree کے ساتھ، اگر آپ 40 اور 100 کے درمیان قدریں تلاش کر رہے ہیں:

آپ کو صرف 40 تلاش کرنے کی ضرورت ہے (یا 40 کے بعد قریب ترین قدر اگر 40 موجود نہیں ہے) جیسا کہ آپ نے پچھلے درخت کے ساتھ کیا تھا۔
پھر براہ راست وارث کے لنکس کا استعمال کرتے ہوئے 40 ورثاء کو جمع کریں جب تک کہ آپ 100 تک نہ پہنچ جائیں۔

فرض کریں کہ آپ کو M جانشین ملتے ہیں اور درخت میں N نوڈس ہیں۔ کسی مخصوص نوڈ کو تلاش کرنے میں لاگ (N) لاگت آتی ہے جیسے پچھلے درخت کی طرح۔ لیکن ایک بار جب آپ یہ نوڈ حاصل کر لیتے ہیں، تو آپ کو M آپریشنز میں ان کے جانشینوں کے حوالے سے M جانشین مل جائیں گے۔ اس تلاش کی قیمت صرف M+log(N) ہے پچھلے درخت پر N آپریشنز کے مقابلے میں آپریشنز۔ مزید یہ کہ، آپ کو مکمل درخت (صرف M+log(N) نوڈس) کو پڑھنے کی ضرورت نہیں ہے، جس کا مطلب ہے کہ ڈسک کا کم استعمال۔ اگر M چھوٹی ہے (مثلاً 200 قطاریں) اور N بڑی ہے (1 قطاریں)، تو ایک بڑا فرق ہوگا۔

لیکن یہاں نئے مسائل ہیں (دوبارہ!) اگر آپ ڈیٹا بیس میں ایک قطار کو شامل یا حذف کرتے ہیں (اور اس وجہ سے متعلقہ B+Tree انڈیکس میں):

آپ کو B+Tree کے اندر نوڈس کے درمیان ترتیب کو برقرار رکھنا چاہیے، بصورت دیگر آپ غیر ترتیب شدہ درخت کے اندر نوڈس تلاش نہیں کر پائیں گے۔
آپ کو B+Tree میں سطحوں کی کم از کم ممکنہ تعداد کو برقرار رکھنا چاہیے، ورنہ O(log(N)) وقت کی پیچیدگی O(N) بن جائے گی۔

دوسرے الفاظ میں، B+Tree خود ترتیب دینے والا اور متوازن ہونا چاہیے۔ خوش قسمتی سے، یہ سمارٹ ڈیلیٹ اور انسرٹ آپریشنز سے ممکن ہے۔ لیکن یہ ایک قیمت پر آتا ہے: B+ درخت کی لاگت O(log(N)) میں اندراج اور حذف کرنا۔ اس لیے آپ میں سے کچھ لوگوں نے یہ سنا ہے۔ بہت زیادہ اشاریہ جات کا استعمال اچھا خیال نہیں ہے۔. واقعی، آپ ٹیبل میں ایک قطار کے تیزی سے داخل/اپ ڈیٹ/ڈیلیٹ کو سست کر رہے ہیں۔کیونکہ ڈیٹا بیس کو ہر انڈیکس کے لیے ایک مہنگے O(log(N)) آپریشن کا استعمال کرتے ہوئے ٹیبل کے اشاریہ جات کو اپ ڈیٹ کرنے کی ضرورت ہوتی ہے۔ مزید برآں، اشاریہ جات کو شامل کرنے کا مطلب ہے زیادہ کام کا بوجھ ٹرانزیکشن مینیجر (مضمون کے آخر میں بیان کیا جائے گا)۔

مزید تفصیلات کے لیے، آپ ویکیپیڈیا پر مضمون دیکھ سکتے ہیں۔ B+درخت. اگر آپ ڈیٹا بیس میں B+Tree کو لاگو کرنے کی مثال چاہتے ہیں تو ایک نظر ڈالیں۔ اس مضمون и اس مضمون ایک سرکردہ MySQL ڈویلپر سے۔ وہ دونوں اس بات پر توجہ مرکوز کرتے ہیں کہ InnoDB (MySQL انجن) اشاریہ جات کو کیسے ہینڈل کرتا ہے۔

نوٹ: ایک قاری نے مجھے بتایا کہ، کم سطح کی اصلاح کی وجہ سے، B+ درخت کو مکمل طور پر متوازن ہونا چاہیے۔

ہیش ٹیبل

ہمارا آخری اہم ڈیٹا ڈھانچہ ہیش ٹیبل ہے۔ جب آپ قدروں کو تیزی سے تلاش کرنا چاہتے ہیں تو یہ بہت مفید ہے۔ مزید برآں، ہیش ٹیبل کو سمجھنے سے ہمیں بعد میں ایک عام ڈیٹا بیس جوائن آپریشن کو سمجھنے میں مدد ملے گی جسے ہیش جوائن کہتے ہیں ( ہیش شمولیت)۔ اس ڈیٹا ڈھانچے کو ڈیٹا بیس کے ذریعے کچھ اندرونی چیزوں کو ذخیرہ کرنے کے لیے بھی استعمال کیا جاتا ہے (جیسے تالا میز یا بفر پول، ہم ان دونوں تصورات کو بعد میں دیکھیں گے)۔

ہیش ٹیبل ایک ڈیٹا ڈھانچہ ہے جو اپنی کلید کی بنیاد پر ایک عنصر کو تیزی سے تلاش کرتا ہے۔ ہیش ٹیبل بنانے کے لیے آپ کو وضاحت کرنے کی ضرورت ہے:

اشارہ آپ کے عناصر کے لئے
ہیش فنکشن چابیاں کے لیے کمپیوٹیڈ کلیدی ہیش عناصر کا مقام بتاتی ہیں (جسے کہا جاتا ہے۔ طبقات ).
چابیاں کا موازنہ کرنے کا فنکشن. ایک بار جب آپ کو صحیح سیگمنٹ مل جاتا ہے، تو آپ کو اس موازنے کا استعمال کرتے ہوئے سیگمنٹ کے اندر وہ عنصر تلاش کرنا چاہیے جو آپ تلاش کر رہے ہیں۔

سادہ مثال

آئیے ایک واضح مثال لیتے ہیں:

اس ہیش ٹیبل میں 10 سیگمنٹ ہیں۔ چونکہ میں سست ہوں، میں نے صرف 5 حصوں کی تصویر کشی کی ہے، لیکن میں جانتا ہوں کہ آپ ہوشیار ہیں، اس لیے میں آپ کو باقی 5 کی تصویر خود بنانے دوں گا۔ میں نے کلید کا ایک ہیش فنکشن ماڈیولو 10 استعمال کیا۔ دوسرے لفظوں میں، میں اس کے حصے کو تلاش کرنے کے لیے عنصر کی کلید کا صرف آخری ہندسہ ذخیرہ کرتا ہوں:

اگر آخری ہندسہ 0 ہے تو عنصر سیگمنٹ 0 میں آتا ہے،
اگر آخری ہندسہ 1 ہے تو عنصر سیگمنٹ 1 میں آتا ہے،
اگر آخری ہندسہ 2 ہے تو عنصر رقبہ 2 میں آتا ہے،
...

میں نے جو موازنہ فنکشن استعمال کیا ہے وہ صرف دو عدد کے درمیان مساوات ہے۔

ہم کہتے ہیں کہ آپ عنصر 78 حاصل کرنا چاہتے ہیں:

ہیش ٹیبل 78 کے لیے ہیش کوڈ کا حساب لگاتا ہے، جو 8 ہے۔
ہیش ٹیبل سیگمنٹ 8 کو دیکھتا ہے، اور اسے ملنے والا پہلا عنصر 78 ہے۔
وہ آپ کو آئٹم 78 واپس کرتی ہے۔
تلاش کی لاگت صرف 2 آپریشن ہے۔ (ایک ہیش ویلیو کا حساب لگانے کے لیے اور دوسرا سیگمنٹ کے اندر موجود عنصر کو تلاش کرنے کے لیے)۔

اب ہم کہتے ہیں کہ آپ عنصر 59 حاصل کرنا چاہتے ہیں:

ہیش ٹیبل 59 کے لیے ہیش کوڈ کا حساب لگاتا ہے، جو 9 ہے۔
ہیش ٹیبل سیگمنٹ 9 میں تلاش کرتا ہے، پہلا عنصر جو ملا ہے وہ 99 ہے۔ 99!=59 کے بعد سے، عنصر 99 ایک درست عنصر نہیں ہے۔
اسی منطق کا استعمال کرتے ہوئے، دوسرا عنصر (9)، تیسرا (79)، ...، آخری (29) لیا جاتا ہے۔
عنصر نہیں ملا۔
تلاشی پر 7 آپریشن لاگت آئے.

اچھا ہیش فنکشن

جیسا کہ آپ دیکھ سکتے ہیں، اس قدر پر منحصر ہے جس کی آپ تلاش کر رہے ہیں، قیمت ایک جیسی نہیں ہے!

اگر میں اب کلید کے ہیش فنکشن ماڈیولو 1 کو تبدیل کرتا ہوں (یعنی آخری 000 ہندسوں کو لے کر)، تو دوسری تلاش میں صرف 000 آپریشن لاگت آئے گی کیونکہ سیگمنٹ 6 میں کوئی عنصر نہیں ہے۔ اصل چیلنج ایک اچھا ہیش فنکشن تلاش کرنا ہے جو بہت کم عناصر پر مشتمل بالٹی بنائے گا۔.

میری مثال میں، ایک اچھا ہیش فنکشن تلاش کرنا آسان ہے۔ لیکن یہ ایک سادہ سی مثال ہے، ایک اچھا ہیش فنکشن تلاش کرنا زیادہ مشکل ہے جب کلید یہ ہے:

تار (مثال کے طور پر - آخری نام)
2 لائنیں (مثال کے طور پر - آخری نام اور پہلا نام)
2 لائنیں اور تاریخ (مثال کے طور پر - آخری نام، پہلا نام اور تاریخ پیدائش)
...

ایک اچھے ہیش فنکشن کے ساتھ، ہیش ٹیبل تلاش کرنے کی لاگت O(1).

سرنی بمقابلہ ہیش ٹیبل

ایک صف کا استعمال کیوں نہیں کرتے؟

ہمم، اچھا سوال۔

ہیش ٹیبل ہو سکتا ہے جزوی طور پر میموری میں بھری ہوئی ہے۔، اور بقیہ حصے ڈسک پر رہ سکتے ہیں۔
ایک صف کے ساتھ آپ کو میموری میں متصل جگہ استعمال کرنا ہوگی۔ اگر آپ ایک بڑی میز لوڈ کر رہے ہیں۔ کافی مسلسل جگہ تلاش کرنا بہت مشکل ہے۔.
ہیش ٹیبل کے لیے، آپ اپنی مطلوبہ کلید منتخب کر سکتے ہیں (مثال کے طور پر، ملک اور شخص کا آخری نام)۔

مزید معلومات کے لیے، آپ کے بارے میں مضمون پڑھ سکتے ہیں۔ اعلی درجے کا Javaہش میپجو کہ ایک ہیش ٹیبل کا موثر نفاذ ہے۔ اس مضمون میں شامل تصورات کو سمجھنے کے لیے آپ کو جاوا کو سمجھنے کی ضرورت نہیں ہے۔

ماخذ: www.habr.com

متعلقہ ڈیٹا بیس کیسے کام کرتے ہیں (حصہ 1)