تعارف
"آپ کو اپنی جگہ پر رہنے کے لیے جتنی تیزی سے دوڑنا ہو گا،
اور کہیں جانے کے لیے، آپ کو کم از کم دوگنا تیز دوڑنا پڑے گا!"
(c) ایلس ان ونڈر لینڈ
کچھ عرصہ پہلے مجھے ایک لیکچر دینے کو کہا گیا۔ تجزیہ کار ڈیٹا ماڈلز کو ڈیزائن کرنے کے موضوع پر ہماری کمپنی، کیونکہ طویل عرصے تک پروجیکٹس پر بیٹھے رہنے سے (بعض اوقات کئی سالوں تک) ہم آئی ٹی ٹیکنالوجیز کی دنیا میں ہمارے ارد گرد کیا ہو رہا ہے اس سے محروم ہو جاتے ہیں۔ ہماری کمپنی میں (ایسا ہی ہوتا ہے) بہت سے پروجیکٹس NoSQL ڈیٹا بیس استعمال نہیں کرتے ہیں (کم از کم ابھی کے لیے)، اس لیے میں نے اپنے لیکچر میں الگ سے HBase کی مثال استعمال کرتے ہوئے ان پر کچھ توجہ دی اور کوشش کی کہ مواد کی پیشکش کو ان لوگوں تک پہنچایا جائے۔ جنہوں نے کبھی استعمال نہیں کیا انہوں نے کام کیا ہے۔ خاص طور پر، میں نے کئی سال پہلے پڑھی ہوئی مثال کا استعمال کرتے ہوئے ڈیٹا ماڈل ڈیزائن کی کچھ خصوصیات کی وضاحت کی۔ . مثالوں کا تجزیہ کرتے وقت، میں نے ایک ہی مسئلے کو حل کرنے کے لیے کئی آپشنز کا موازنہ کیا تاکہ مرکزی خیالات کو سامعین تک بہتر طریقے سے پہنچایا جا سکے۔
حال ہی میں، "کچھ نہیں کرنے کے لیے"، میں نے اپنے آپ سے سوال پوچھا (قرنطینہ میں مئی کا طویل ویک اینڈ خاص طور پر اس کے لیے سازگار ہے)، نظریاتی حسابات پریکٹس کے کتنے موافق ہوں گے؟ دراصل، اس مضمون کا خیال اسی طرح پیدا ہوا۔ ایک ڈویلپر جو NoSQL کے ساتھ کئی دنوں سے کام کر رہا ہے ہو سکتا ہے کہ اس سے کوئی نئی چیز نہ سیکھ سکے (اور اس لیے فوراً آدھا مضمون چھوڑ سکتا ہے)۔ لیکن اس کے لئے تجزیہ کاران لوگوں کے لیے جنہوں نے ابھی تک NoSQL کے ساتھ قریب سے کام نہیں کیا ہے، میرے خیال میں یہ HBase کے لیے ڈیٹا ماڈل ڈیزائن کرنے کی خصوصیات کی بنیادی سمجھ حاصل کرنے کے لیے مفید ہوگا۔
مثال کا تجزیہ
میری رائے میں، اس سے پہلے کہ آپ NoSQL ڈیٹا بیسز کا استعمال شروع کریں، آپ کو احتیاط سے سوچنے اور فوائد اور نقصانات کا وزن کرنے کی ضرورت ہے۔ اکثر مسئلہ روایتی رشتہ دار DBMSs کا استعمال کرتے ہوئے حل کیا جا سکتا ہے۔ اس لیے بہتر ہے کہ NoSQL کو اہم وجوہات کے بغیر استعمال نہ کیا جائے۔ اگر اس کے باوجود آپ نے NoSQL ڈیٹا بیس استعمال کرنے کا فیصلہ کیا ہے، تو آپ کو اس بات کو ذہن میں رکھنا چاہیے کہ یہاں ڈیزائن کے نقطہ نظر کچھ مختلف ہیں۔ خاص طور پر ان میں سے کچھ ان لوگوں کے لئے غیر معمولی ہوسکتے ہیں جنہوں نے پہلے صرف رشتہ دار DBMSs (میرے مشاہدات کے مطابق) سے نمٹا ہے۔ لہذا، "رشتہ دار" دنیا میں، ہم عام طور پر مسئلے کے ڈومین کو ماڈلنگ کے ذریعے شروع کرتے ہیں، اور صرف اس کے بعد، اگر ضروری ہو تو، ماڈل کو غیر معمولی بنائیں۔ NoSQL میں ہم ڈیٹا کے ساتھ کام کرنے کے لیے متوقع منظرناموں کو فوری طور پر مدنظر رکھنا چاہیے۔ اور ابتدائی طور پر ڈیٹا کو غیر معمولی بنائیں۔ اس کے علاوہ، بہت سے دوسرے اختلافات ہیں، جن پر ذیل میں تبادلہ خیال کیا جائے گا.
آئیے درج ذیل "مصنوعی" مسئلے پر غور کریں، جس کے ساتھ ہم کام جاری رکھیں گے:
کچھ تجریدی سوشل نیٹ ورک کے صارفین کے دوستوں کی فہرست کے لیے اسٹوریج کا ڈھانچہ تیار کرنا ضروری ہے۔ آسان بنانے کے لیے، ہم فرض کریں گے کہ ہمارے تمام کنکشنز ڈائریکٹ کیے گئے ہیں (جیسا کہ Instagram پر، Linkedin نہیں)۔ ڈھانچہ آپ کو مؤثر طریقے سے کرنے کی اجازت دیتا ہے:
- اس سوال کا جواب دیں کہ آیا صارف A صارف B کو پڑھتا ہے (پڑھنے کا نمونہ)
- صارف B سے صارف A کی سبسکرپشن/ان سبسکرپشن کی صورت میں کنکشنز کو شامل کرنے/ ہٹانے کی اجازت دیں (ڈیٹا تبدیلی ٹیمپلیٹ)
یقینا، مسئلہ کو حل کرنے کے لئے بہت سے اختیارات ہیں. ایک باقاعدہ رشتہ دار ڈیٹا بیس میں، ہم زیادہ تر ممکنہ طور پر تعلقات کا ایک جدول بنائیں گے (ممکنہ طور پر ٹائپ کیا جائے گا اگر، مثال کے طور پر، ہمیں صارف گروپ کو ذخیرہ کرنے کی ضرورت ہے: خاندان، کام، وغیرہ، جس میں یہ "دوست" شامل ہے)، اور بہتر بنانے کے لیے رسائی کی رفتار اشاریہ جات/تقسیم کا اضافہ کرے گی۔ زیادہ تر امکان ہے کہ فائنل ٹیبل کچھ اس طرح نظر آئے گا:
USER_ID
دوست_آئی ڈی
سے vasya
پیٹر
سے vasya
Оля
اس کے بعد، وضاحت اور بہتر تفہیم کے لیے، میں IDs کے بجائے نام بتاؤں گا۔
HBase کے معاملے میں، ہم جانتے ہیں کہ:
- موثر تلاش جس کے نتیجے میں مکمل ٹیبل اسکین نہیں ہوتا ہے ممکن ہے۔ خصوصی طور پر کلید کے ذریعے
- درحقیقت، یہی وجہ ہے کہ ایس کیو ایل کے سوالات لکھنا بہت سے لوگوں کو ایسے ڈیٹا بیس سے واقف کرنا ایک برا خیال ہے۔ تکنیکی طور پر، یقیناً، آپ اسی امپالا سے HBase کو Joins اور دیگر منطق کے ساتھ ایک SQL استفسار بھیج سکتے ہیں، لیکن یہ کتنا موثر ہوگا...
لہذا، ہم صارف کی شناخت کو کلید کے طور پر استعمال کرنے پر مجبور ہیں۔ اور "دوستوں کی شناخت کہاں اور کیسے اسٹور کریں؟" کے موضوع پر میرا پہلا خیال۔ شاید انہیں کالموں میں ذخیرہ کرنے کا خیال ہو۔ یہ سب سے واضح اور "بولی" آپشن کچھ اس طرح نظر آئے گا (آئیے اسے کہتے ہیں۔ آپشن 1 (پہلے سے طے شدہ)مزید حوالہ کے لیے):
RowKey
مقررین
سے vasya
1: پیٹیا
2: اولیا
3: دشا
پیٹر
1: ماشہ
2: واسعہ
یہاں، ہر لائن ایک نیٹ ورک صارف سے مطابقت رکھتی ہے۔ کالموں کے نام ہیں: 1، 2، ... - دوستوں کی تعداد کے مطابق، اور دوستوں کی آئی ڈیز کالم میں محفوظ ہیں۔ یہ نوٹ کرنا ضروری ہے کہ ہر قطار میں کالموں کی تعداد مختلف ہوگی۔ اوپر دی گئی تصویر میں مثال کے طور پر، ایک قطار میں تین کالم ہیں (1، 2 اور 3)، اور دوسری میں صرف دو (1 اور 2) ہیں - یہاں ہم نے خود HBase کی دو خصوصیات استعمال کی ہیں جو متعلقہ ڈیٹا بیس کے پاس نہیں ہیں:
- کالموں کی ساخت کو متحرک طور پر تبدیل کرنے کی صلاحیت (ایک دوست شامل کریں -> ایک کالم شامل کریں، ایک دوست کو ہٹا دیں -> کالم کو حذف کریں)
- مختلف قطاروں میں مختلف کالم کمپوزیشن ہو سکتے ہیں۔
آئیے کام کے تقاضوں کی تعمیل کے لیے اپنے ڈھانچے کو چیک کریں:
- ڈیٹا پڑھنا: یہ سمجھنے کے لیے کہ آیا واسیا اولیا کے لیے سبسکرائب ہے، ہمیں گھٹانے کی ضرورت ہوگی۔ پوری لائن کلید RowKey = "Vasya" کے ذریعے اور کالم کی اقدار کے ذریعے ترتیب دیں جب تک کہ ہم ان میں اولیا سے "ملیں"۔ یا تمام کالموں کی قدروں کے ذریعے اعادہ کریں، اولیا کو "نہ ملیں" اور جواب غلط دیں؛
- ڈیٹا میں ترمیم کرنا: دوست کو شامل کرنا: اسی طرح کے کام کے لیے ہمیں گھٹانے کی بھی ضرورت ہے۔ پوری لائن کلید RowKey = "Vasya" کا استعمال کرتے ہوئے اپنے دوستوں کی کل تعداد گننا۔ ہمیں اس کالم کی تعداد کا تعین کرنے کے لیے دوستوں کی اس کل تعداد کی ضرورت ہے جس میں ہمیں نئے دوست کی شناخت لکھنے کی ضرورت ہے۔
- ڈیٹا تبدیل کرنا: دوست کو حذف کرنا:
- گھٹانے کی ضرورت ہے۔ پوری لائن کلید RowKey = "Vasya" کے ذریعے اور کالموں کو چھانٹیں تاکہ جس دوست کو حذف کیا جانا ہے اسے تلاش کیا جا سکے۔
- اس کے بعد، کسی دوست کو ڈیلیٹ کرنے کے بعد، ہمیں تمام ڈیٹا کو ایک کالم میں "شفٹ" کرنے کی ضرورت ہے تاکہ ان کی نمبرنگ میں "خرابی" نہ ہو۔
آئیے اب جائزہ لیتے ہیں کہ یہ الگورتھم، جن کو ہمیں "مشروط درخواست" کی طرف لاگو کرنے کی ضرورت ہوگی، استعمال کرتے ہوئے کتنے نتیجہ خیز ثابت ہوں گے۔ . آئیے اپنے فرضی سوشل نیٹ ورک کے سائز کو n کے طور پر بیان کرتے ہیں۔ پھر ایک صارف کے دوستوں کی زیادہ سے زیادہ تعداد (n-1) ہے۔ ہم اپنے مقاصد کے لیے اس (-1) کو مزید نظر انداز کر سکتے ہیں، کیونکہ O-علامتوں کے استعمال کے فریم ورک کے اندر یہ غیر اہم ہے۔
- ڈیٹا پڑھنا: پوری لائن کو گھٹانا اور اس کے تمام کالموں کے ذریعے حد میں اعادہ کرنا ضروری ہے۔ اس کا مطلب ہے کہ اخراجات کا اوپری تخمینہ تقریباً O(n) ہوگا
- ڈیٹا میں ترمیم کرنا: دوست کو شامل کرنا: دوستوں کی تعداد کا تعین کرنے کے لیے، آپ کو قطار کے تمام کالموں میں اعادہ کرنا ہوگا، اور پھر ایک نیا کالم داخل کرنا ہوگا => O(n)
- ڈیٹا تبدیل کرنا: دوست کو حذف کرنا:
- شامل کرنے کی طرح - آپ کو حد => O(n) میں تمام کالموں سے گزرنا ہوگا۔
- کالموں کو ہٹانے کے بعد، ہمیں انہیں "منتقل" کرنے کی ضرورت ہے۔ اگر آپ اس "ہیڈ آن" کو لاگو کرتے ہیں، تو حد میں آپ کو (n-1) آپریشنز کی ضرورت ہوگی۔ لیکن یہاں اور آگے عملی حصے میں ہم ایک مختلف طریقہ استعمال کریں گے، جو ایک مقررہ تعداد کے آپریشنز کے لیے ایک "سیڈو شفٹ" نافذ کرے گا - یعنی اس پر مستقل وقت صرف کیا جائے گا، قطع نظر اس کے کہ n۔ اس مستقل وقت (O(2) کے عین مطابق ہونے کے لیے) کو O(n) کے مقابلے میں نظرانداز کیا جا سکتا ہے۔ نقطہ نظر کو نیچے دی گئی تصویر میں واضح کیا گیا ہے: ہم صرف "آخری" کالم سے ڈیٹا کو اس میں کاپی کرتے ہیں جس سے ہم ڈیٹا کو حذف کرنا چاہتے ہیں، اور پھر آخری کالم کو حذف کرتے ہیں:
مجموعی طور پر، تمام منظرناموں میں ہمیں O(n) کی ایک اسیمپٹوٹک کمپیوٹیشنل پیچیدگی موصول ہوئی۔
آپ نے شاید پہلے ہی محسوس کیا ہو گا کہ ہمیں تقریباً ہمیشہ ڈیٹا بیس سے پوری قطار پڑھنی پڑتی ہے، اور تین میں سے دو صورتوں میں، صرف تمام کالموں میں جا کر دوستوں کی کل تعداد کا حساب لگانا پڑتا ہے۔ لہذا، اصلاح کی کوشش کے طور پر، آپ ایک "کاؤنٹ" کالم شامل کر سکتے ہیں، جو ہر نیٹ ورک صارف کے دوستوں کی کل تعداد کو محفوظ کرتا ہے۔ اس صورت میں، ہم دوستوں کی کل تعداد کا حساب لگانے کے لیے پوری قطار کو نہیں پڑھ سکتے، لیکن صرف ایک "گنتی" کالم پڑھ سکتے ہیں۔ اہم بات یہ ہے کہ ڈیٹا میں ہیرا پھیری کرتے وقت "گنتی" کو اپ ڈیٹ کرنا نہ بھولیں۔ وہ. ہم بہتر ہو جاتے ہیں اختیار 2 (شمار):
RowKey
مقررین
سے vasya
1: پیٹیا
2: اولیا
3: دشا
شمار: 3
پیٹر
1: ماشہ
2: واسعہ
شمار: 2
پہلے آپشن کے مقابلے میں:
- ڈیٹا پڑھنا: سوال کا جواب حاصل کرنے کے لیے "کیا واسیا اولیا پڑھتا ہے؟" کچھ نہیں بدلا ہے => O(n)
- ڈیٹا میں ترمیم کرنا: دوست کو شامل کرنا: ہم نے ایک نئے دوست کے اندراج کو آسان کر دیا ہے، کیونکہ اب ہمیں پوری لائن کو پڑھنے اور اس کے کالموں پر تکرار کرنے کی ضرورت نہیں ہے، بلکہ صرف "کاؤنٹ" کالم وغیرہ کی قدر حاصل کر سکتے ہیں۔ نئے دوست کو داخل کرنے کے لیے فوری طور پر کالم نمبر کا تعین کریں۔ اس سے O(1) کی کمپیوٹیشنل پیچیدگی میں کمی واقع ہوتی ہے۔
- ڈیٹا تبدیل کرنا: دوست کو حذف کرنا: کسی دوست کو حذف کرتے وقت، ہم اس کالم کو I/O آپریشنز کی تعداد کو کم کرنے کے لیے بھی استعمال کر سکتے ہیں جب ڈیٹا ایک سیل کو بائیں طرف "شفٹ" کرتے ہیں۔ لیکن جس کو حذف کرنے کی ضرورت ہے اسے تلاش کرنے کے لیے کالموں کے ذریعے اعادہ کرنے کی ضرورت اب بھی باقی ہے، لہذا => O(n)
- دوسری طرف، اب ڈیٹا کو اپ ڈیٹ کرتے وقت ہمیں ہر بار "count" کالم کو اپ ڈیٹ کرنے کی ضرورت ہوتی ہے، لیکن اس میں مستقل وقت لگتا ہے، جسے O-symbols کے فریم ورک میں نظر انداز کیا جا سکتا ہے۔
عام طور پر، آپشن 2 تھوڑا زیادہ بہتر لگتا ہے، لیکن یہ "انقلاب کے بجائے ارتقا" جیسا ہے۔ "انقلاب" کرنے کے لیے ہمیں ضرورت ہو گی۔ آپشن 3 (col).
آئیے سب کچھ "الٹا" کر دیں: ہم تفویض کریں گے۔ کالم کا نام صارف ID! کالم میں جو کچھ لکھا جائے گا وہ اب ہمارے لیے اہم نہیں رہا، اسے نمبر 1 رہنے دیں (عموماً، مفید چیزیں وہاں محفوظ کی جا سکتی ہیں، مثال کے طور پر، گروپ "خاندان/دوست/وغیرہ")۔ یہ نقطہ نظر غیر تیار "عام آدمی" کو حیران کر سکتا ہے جسے NoSQL ڈیٹا بیس کے ساتھ کام کرنے کا کوئی سابقہ تجربہ نہیں ہے، لیکن یہ بالکل وہی طریقہ ہے جو آپ کو اس کام میں HBase کی صلاحیت کو زیادہ مؤثر طریقے سے استعمال کرنے کی اجازت دیتا ہے:
RowKey
مقررین
سے vasya
پیٹیا: 1
اولیا: 1
دشا: 1
پیٹر
ماشہ: 1
واسع: 1
یہاں ہمیں ایک ساتھ کئی فوائد ملتے ہیں۔ ان کو سمجھنے کے لیے، آئیے نئے ڈھانچے کا تجزیہ کرتے ہیں اور کمپیوٹیشنل پیچیدگی کا اندازہ لگاتے ہیں:
- ڈیٹا پڑھنا: اس سوال کا جواب دینے کے لیے کہ آیا واسع اولیا کے لیے سبسکرائب کیا گیا ہے، ایک کالم "اولیا" پڑھنا کافی ہے: اگر یہ موجود ہے تو جواب درست ہے، اگر نہیں - غلط => O(1)
- ڈیٹا میں ترمیم کرنا: دوست کو شامل کرنا: دوست کو شامل کرنا: صرف ایک نیا کالم شامل کریں “Friend ID” => O(1)
- ڈیٹا تبدیل کرنا: دوست کو حذف کرنا: صرف Friend ID کالم => O(1) کو ہٹا دیں۔
جیسا کہ آپ دیکھ سکتے ہیں، اس سٹوریج ماڈل کا ایک اہم فائدہ یہ ہے کہ ہمیں درکار تمام منظرناموں میں، ہم صرف ایک کالم کے ساتھ کام کرتے ہیں، ڈیٹا بیس سے پوری قطار کو پڑھنے سے گریز کرتے ہیں اور اس کے علاوہ، اس قطار کے تمام کالموں کی گنتی کرتے ہیں۔ ہم وہاں رک سکتے تھے، لیکن...
آپ حیران رہ سکتے ہیں اور ڈیٹا بیس تک رسائی حاصل کرتے وقت کارکردگی کو بہتر بنانے اور I/O آپریشنز کو کم کرنے کے راستے پر تھوڑا آگے جا سکتے ہیں۔ کیا ہوگا اگر ہم مکمل تعلقات کی معلومات کو براہ راست قطار کی کلید میں ہی محفوظ کریں؟ یعنی userID.friendID کی طرح کلیدی مرکب بنائیں؟ اس معاملے میں، ہمیں لائن کے کالم بالکل بھی نہیں پڑھنا ہوں گے (آپشن 4 (قطار)):
RowKey
مقررین
واسہ۔پیتیا
پیٹیا: 1
وسیا۔اولیا۔
اولیا: 1
وسیا.داشا
دشا: 1
پیٹیا۔ماشا
ماشہ: 1
پیٹیا۔واسیا
واسع: 1
ظاہر ہے، اس طرح کے ڈھانچے میں تمام ڈیٹا ہیرا پھیری کے منظرناموں کا اندازہ، جیسا کہ پچھلے ورژن میں، O(1) ہوگا۔ آپشن 3 کے ساتھ فرق صرف اور صرف ڈیٹا بیس میں I/O آپریشنز کی کارکردگی میں ہوگا۔
ٹھیک ہے، آخری "دخش". یہ دیکھنا آسان ہے کہ آپشن 4 میں، قطار کی کلید کی لمبائی متغیر ہوگی، جو ممکنہ طور پر کارکردگی کو متاثر کر سکتی ہے (یہاں ہمیں یاد ہے کہ HBase ڈیٹا کو بائٹس کے سیٹ کے طور پر اسٹور کرتا ہے اور ٹیبل میں قطاریں کلید کے حساب سے ترتیب دی جاتی ہیں)۔ اس کے علاوہ ہمارے پاس ایک الگ کرنے والا ہے جسے کچھ منظرناموں میں سنبھالنے کی ضرورت پڑ سکتی ہے۔ اس اثر کو ختم کرنے کے لیے، آپ یوزر آئی ڈی اور فرینڈ آئی ڈی سے ہیشز استعمال کر سکتے ہیں، اور چونکہ دونوں ہیشز کی لمبائی مستقل ہو گی، اس لیے آپ انہیں بغیر کسی الگ کرنے والے کے آسانی سے جوڑ سکتے ہیں۔ پھر ٹیبل میں ڈیٹا اس طرح نظر آئے گا (آپشن 5(ہیش)):
RowKey
مقررین
dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
پیٹیا: 1
dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
اولیا: 1
dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
دشا: 1
1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
ماشہ: 1
1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
واسع: 1
ظاہر ہے، ہم جن منظرناموں پر غور کر رہے ہیں اس طرح کے ڈھانچے کے ساتھ کام کرنے کی الگورتھمک پیچیدگی وہی ہوگی جو آپشن 4 کی ہوگی - یعنی O(1)۔
مجموعی طور پر، آئیے ایک جدول میں کمپیوٹیشنل پیچیدگی کے اپنے تمام تخمینوں کا خلاصہ کریں:
ایک دوست کو شامل کرنا
ایک دوست کی جانچ کر رہا ہے۔
دوست کو ہٹانا
آپشن 1 (پہلے سے طے شدہ)
اے (ن)
اے (ن)
اے (ن)
اختیار 2 (شمار)
O (1)
اے (ن)
اے (ن)
آپشن 3 (کالم)
O (1)
O (1)
O (1)
آپشن 4 (قطار)
O (1)
O (1)
O (1)
آپشن 5 (ہیش)
O (1)
O (1)
O (1)
جیسا کہ آپ دیکھ سکتے ہیں، آپشن 3-5 سب سے زیادہ ترجیحی معلوم ہوتے ہیں اور نظریاتی طور پر تمام ضروری ڈیٹا ہیرا پھیری کے منظرناموں پر مستقل وقت میں عملدرآمد کو یقینی بناتے ہیں۔ ہمارے کام کے حالات میں، صارف کے تمام دوستوں کی فہرست حاصل کرنے کی کوئی واضح ضرورت نہیں ہے، لیکن حقیقی پروجیکٹ کی سرگرمیوں میں، اچھے تجزیہ کاروں کے طور پر، یہ ہمارے لیے اچھا ہوگا کہ اس طرح کا کوئی کام سامنے آسکتا ہے اور "ایک تنکا پھیلاؤ۔" لہذا، میری ہمدردی آپشن 3 کی طرف ہے. لیکن یہ بہت ممکن ہے کہ ایک حقیقی منصوبے میں اس درخواست کو پہلے ہی دوسرے طریقوں سے حل کیا جا سکتا تھا، لہذا، پورے مسئلے کے عام نقطہ نظر کے بغیر، بہتر نہیں ہے کہ حتمی نتائج.
تجربے کی تیاری
میں مندرجہ بالا نظریاتی دلائل کو عملی طور پر جانچنا چاہوں گا - یہ اس خیال کا مقصد تھا جو طویل ویک اینڈ پر پیدا ہوا۔ ایسا کرنے کے لیے، ڈیٹا بیس کے استعمال کے لیے تمام بیان کردہ منظرناموں میں ہماری "مشروط ایپلی کیشن" کی آپریٹنگ رفتار کا جائزہ لینا ضروری ہے، اور ساتھ ہی سوشل نیٹ ورک (n) کے بڑھتے ہوئے سائز کے ساتھ اس وقت میں ہونے والے اضافے کا بھی جائزہ لینا ضروری ہے۔ ٹارگٹ پیرامیٹر جو ہماری دلچسپی رکھتا ہے اور جس کی ہم تجربے کے دوران پیمائش کریں گے وہ وقت ہے جو "مشروط ایپلی کیشن" نے ایک "کاروباری آپریشن" کو انجام دینے کے لیے صرف کیا ہے۔ "کاروباری لین دین" سے ہمارا مطلب درج ذیل میں سے ایک ہے:
- ایک نیا دوست شامل کرنا
- چیک کرنا کہ آیا صارف A صارف B کا دوست ہے۔
- ایک دوست کو ہٹانا
اس طرح، ابتدائی بیان میں بیان کردہ تقاضوں کو مدنظر رکھتے ہوئے، تصدیق کا منظر نامہ اس طرح ابھرتا ہے:
- ڈیٹا ریکارڈنگ. تصادفی طور پر سائز n کا ایک ابتدائی نیٹ ورک تیار کریں۔ "حقیقی دنیا" کے قریب جانے کے لیے، ہر صارف کے دوستوں کی تعداد بھی ایک بے ترتیب متغیر ہے۔ اس وقت کی پیمائش کریں جس کے دوران ہماری "مشروط درخواست" تمام تیار کردہ ڈیٹا کو HBase پر لکھتی ہے۔ پھر نتیجے میں آنے والے وقت کو شامل کردہ دوستوں کی کل تعداد سے تقسیم کریں - اس طرح ہمیں ایک "کاروباری آپریشن" کے لیے اوسط وقت ملتا ہے۔
- ڈیٹا پڑھنا. ہر صارف کے لیے، "شخصیات" کی ایک فہرست بنائیں جس کے لیے آپ کو جواب حاصل کرنے کی ضرورت ہے کہ آیا صارف نے ان کو سبسکرائب کیا ہے یا نہیں۔ فہرست کی لمبائی = صارف کے دوستوں کی تقریباً تعداد، اور چیک کیے گئے دوستوں میں سے نصف کے لیے جواب "ہاں"، اور باقی آدھے کے لیے - "نہیں" ہونا چاہیے۔ چیک اس ترتیب سے کیا جاتا ہے کہ جوابات "ہاں" اور "نہیں" متبادل ہوتے ہیں (یعنی ہر دوسری صورت میں ہمیں آپشن 1 اور 2 کے لیے لائن کے تمام کالموں سے گزرنا پڑے گا)۔ اس کے بعد اسکریننگ کے کل وقت کو ان دوستوں کی تعداد سے تقسیم کیا جاتا ہے جن کی جانچ کی گئی تاکہ فی مضمون کے اوسط اسکریننگ کا وقت حاصل کیا جا سکے۔
- ڈیٹا ڈیلیشن. صارف سے تمام دوستوں کو ہٹا دیں۔ مزید برآں، حذف کرنے کا حکم بے ترتیب ہے (یعنی، ہم ڈیٹا کو ریکارڈ کرنے کے لیے استعمال ہونے والی اصل فہرست کو "شفل" کرتے ہیں)۔ پھر چیک کے کل وقت کو ہٹائے گئے دوستوں کی تعداد سے تقسیم کیا جاتا ہے تاکہ فی چیک اوسط وقت حاصل کیا جا سکے۔
منظرناموں کو 5 ڈیٹا ماڈل کے اختیارات میں سے ہر ایک کے لیے اور سوشل نیٹ ورک کے مختلف سائز کے لیے چلانے کی ضرورت ہے تاکہ یہ دیکھا جا سکے کہ وقت بڑھنے کے ساتھ کیسے بدلتا ہے۔ ایک این کے اندر، نیٹ ورک میں کنکشن اور چیک کرنے کے لیے صارفین کی فہرست، یقیناً، تمام 5 اختیارات کے لیے یکساں ہونا چاہیے۔
بہتر تفہیم کے لیے، ذیل میں n= 5 کے لیے تیار کردہ ڈیٹا کی ایک مثال ہے۔ لکھا ہوا "جنریٹر" آؤٹ پٹ کے طور پر تین ID لغات تیار کرتا ہے:
- پہلا داخل کرنے کے لئے ہے
- دوسرا چیک کرنے کے لئے ہے
- تیسرا - حذف کرنے کے لیے
{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей
{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов
{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей
جیسا کہ آپ دیکھ سکتے ہیں، چیکنگ کے لیے ڈکشنری میں 10 سے زیادہ تمام IDs بالکل وہی ہیں جو یقیناً غلط جواب دیں گی۔ "دوستوں" کو داخل کرنا، چیک کرنا اور حذف کرنا بالکل اسی ترتیب میں کیا جاتا ہے جو لغت میں بیان کی گئی ہے۔
یہ تجربہ ونڈوز 10 پر چلنے والے لیپ ٹاپ پر کیا گیا، جہاں ایک ڈوکر کنٹینر میں HBase چل رہا تھا، اور دوسرے میں Jupyter Notebook کے ساتھ Python چل رہا تھا۔ ڈوکر کو 2 سی پی یو کور اور 2 جی بی ریم مختص کی گئی تھی۔ تمام منطق، جیسے کہ "مشروط ایپلی کیشن" اور "پائپنگ" کی نقالی ٹیسٹ ڈیٹا بنانے اور وقت کی پیمائش کے لیے، Python میں لکھی گئی تھی۔ لائبریری HBase کے ساتھ کام کرنے کے لیے استعمال ہوتی تھی۔ ، آپشن 5 کے لیے ہیشز (MD5) کا حساب لگانے کے لیے - hashlib
کسی خاص لیپ ٹاپ کی کمپیوٹنگ طاقت کو مدنظر رکھتے ہوئے، n = 10, 30, … کے لیے لانچ کو تجرباتی طور پر منتخب کیا گیا تھا۔ 170 - جب مکمل ٹیسٹنگ سائیکل کا کل آپریٹنگ وقت (تمام n کے لیے تمام اختیارات کے لیے تمام منظرنامے) ایک چائے پارٹی کے دوران کم و بیش معقول اور موزوں تھا (اوسطاً 15 منٹ)۔
یہاں یہ تبصرہ کرنا ضروری ہے کہ اس تجربے میں ہم بنیادی طور پر کارکردگی کے مطلق اعداد و شمار کا جائزہ نہیں لے رہے ہیں۔ یہاں تک کہ مختلف دو اختیارات کا نسبتاً موازنہ بھی مکمل طور پر درست نہیں ہو سکتا۔ اب ہم n پر منحصر وقت میں تبدیلی کی نوعیت میں دلچسپی رکھتے ہیں، چونکہ "ٹیسٹ اسٹینڈ" کی مذکورہ بالا ترتیب کو مدنظر رکھتے ہوئے، بے ترتیب اور دیگر عوامل کے اثر سے "صاف" وقت کا تخمینہ حاصل کرنا بہت مشکل ہے۔ اور ایسا کام طے نہیں کیا گیا تھا)۔
تجربہ کا نتیجہ
پہلا امتحان یہ ہے کہ فرینڈ لسٹ کو پُر کرنے میں صرف ہونے والا وقت کیسے بدلتا ہے۔ نتیجہ نیچے گراف میں ہے۔
آپشن 3-5، جیسا کہ توقع کی گئی ہے، تقریباً مستقل "کاروباری لین دین" کا وقت دکھاتے ہیں، جو نیٹ ورک کے سائز کی ترقی اور کارکردگی میں ناقابل فرق فرق پر منحصر نہیں ہے۔
آپشن 2 بھی مستقل، لیکن قدرے بدتر کارکردگی دکھاتا ہے، آپشن 2-3 کے مقابلے میں تقریباً 5 گنا۔ اور یہ خوشی کے سوا نہیں ہو سکتا، کیونکہ یہ تھیوری سے تعلق رکھتا ہے - اس ورژن میں HBase سے/سے I/O آپریشنز کی تعداد بالکل 2 گنا زیادہ ہے۔ یہ بالواسطہ ثبوت کے طور پر کام کر سکتا ہے کہ ہمارا ٹیسٹ بینچ، اصولی طور پر، اچھی درستگی فراہم کرتا ہے۔
آپشن 1 بھی، جیسا کہ توقع کی جاتی ہے، سب سے سست نکلتا ہے اور نیٹ ورک کے سائز میں ایک دوسرے کو شامل کرنے میں صرف کیے گئے وقت میں خطی اضافہ کو ظاہر کرتا ہے۔
آئیے اب دوسرے ٹیسٹ کے نتائج کو دیکھتے ہیں۔
اختیارات 3-5 دوبارہ توقع کے مطابق برتاؤ کرتے ہیں - مستقل وقت، نیٹ ورک کے سائز سے آزاد۔ اختیارات 1 اور 2 نیٹ ورک کے سائز میں اضافے اور اسی طرح کی کارکردگی کے ساتھ وقت میں خطی اضافہ کو ظاہر کرتے ہیں۔ مزید برآں، آپشن 2 تھوڑا سا سست نکلتا ہے - بظاہر اضافی "کاؤنٹ" کالم کو پروف ریڈ کرنے اور اس پر کارروائی کرنے کی ضرورت کی وجہ سے، جو کہ n کے بڑھنے کے ساتھ زیادہ نمایاں ہو جاتا ہے۔ لیکن میں پھر بھی کوئی نتیجہ اخذ کرنے سے گریز کروں گا، کیونکہ اس موازنہ کی درستگی نسبتاً کم ہے۔ اس کے علاوہ، یہ تناسب (جو آپشن، 1 یا 2، تیز تر ہے) رن سے رن میں تبدیل ہو گئے (انحصار کی نوعیت کو برقرار رکھتے ہوئے اور "گردن اور گردن کو جانا")۔
ٹھیک ہے، آخری گراف ہٹانے کی جانچ کا نتیجہ ہے۔
ایک بار پھر، یہاں کوئی تعجب نہیں. اختیارات 3-5 مستقل وقت میں ہٹانے کا کام انجام دیتے ہیں۔
مزید برآں، دلچسپ بات یہ ہے کہ اختیارات 4 اور 5، پچھلے منظرناموں کے برعکس، آپشن 3 کے مقابلے میں نمایاں طور پر قدرے خراب کارکردگی دکھاتے ہیں۔ بظاہر، قطار کو حذف کرنے کا عمل کالم حذف کرنے کے آپریشن سے زیادہ مہنگا ہے، جو عام طور پر منطقی ہوتا ہے۔
اختیارات 1 اور 2، جیسا کہ توقع کی جاتی ہے، وقت میں ایک خطی اضافہ کا مظاہرہ کرتے ہیں۔ ایک ہی وقت میں، آپشن 2 آپشن 1 کے مقابلے میں مسلسل سست ہے - گنتی کے کالم کو "برقرار رکھنے" کے لیے اضافی I/O آپریشن کی وجہ سے۔
تجربے کے عمومی نتائج:
- HBase کا فائدہ اٹھاتے ہوئے اختیارات 3-5 زیادہ کارکردگی کا مظاہرہ کرتے ہیں۔ مزید یہ کہ، ان کی کارکردگی ایک دوسرے سے مستقل طور پر مختلف ہوتی ہے اور نیٹ ورک کے سائز پر منحصر نہیں ہوتی ہے۔
- اختیارات 4 اور 5 کے درمیان فرق ریکارڈ نہیں کیا گیا تھا۔ لیکن اس کا مطلب یہ نہیں ہے کہ آپشن 5 استعمال نہیں کیا جانا چاہیے۔ یہ امکان ہے کہ استعمال شدہ تجرباتی منظر نامے نے، ٹیسٹ بینچ کی کارکردگی کی خصوصیات کو مدنظر رکھتے ہوئے، اس کا پتہ لگانے کی اجازت نہیں دی۔
- ڈیٹا کے ساتھ "کاروباری کارروائیوں" کو انجام دینے کے لیے درکار وقت میں اضافے کی نوعیت عام طور پر تمام اختیارات کے لیے پہلے سے حاصل کردہ نظریاتی حسابات کی تصدیق کرتی ہے۔
اپسنہار
کئے گئے کھردرے تجربات کو قطعی سچائی کے طور پر نہیں لینا چاہئے۔ بہت سے ایسے عوامل ہیں جن کو مدنظر نہیں رکھا گیا اور نتائج کو مسخ کر دیا (یہ اتار چڑھاو خاص طور پر چھوٹے نیٹ ورک سائز والے گراف میں نظر آتے ہیں)۔ مثال کے طور پر، کفایت شعاری کی رفتار، جسے ہیپی بیس کے ذریعے استعمال کیا جاتا ہے، اس منطق کو لاگو کرنے کا حجم اور طریقہ جو میں نے ازگر میں لکھا تھا (میں یہ دعویٰ نہیں کر سکتا کہ کوڈ بہترین اور مؤثر طریقے سے تمام اجزاء کی صلاحیتوں کو استعمال کیا گیا تھا)، شاید HBase کیشنگ کی خصوصیات، میرے لیپ ٹاپ پر ونڈوز 10 کی بیک گراؤنڈ سرگرمی وغیرہ۔ عام طور پر، ہم یہ فرض کر سکتے ہیں کہ تمام نظریاتی حسابات نے تجرباتی طور پر اپنی درستگی کا مظاہرہ کیا ہے۔ ٹھیک ہے، یا کم از کم یہ ممکن نہیں تھا کہ اس طرح کے "سر پر حملہ" سے ان کی تردید کی جائے۔
آخر میں، ہر ایک کے لیے سفارشات جو صرف HBase میں ڈیٹا ماڈلز ڈیزائن کرنا شروع کر رہا ہے: متعلقہ ڈیٹا بیس کے ساتھ کام کرنے والے پچھلے تجربے سے خلاصہ اور "حکمات" کو یاد رکھیں:
- ڈیزائن کرتے وقت، ہم ڈیٹا ہیرا پھیری کے کام اور نمونوں سے آگے بڑھتے ہیں، نہ کہ ڈومین ماڈل سے
- موثر رسائی (مکمل ٹیبل اسکین کے بغیر) - صرف کلید کے ذریعے
- ڈی نارملائزیشن
- مختلف قطاروں میں مختلف کالم ہو سکتے ہیں۔
- مقررین کی متحرک ساخت
ماخذ: www.habr.com