مجھے حال ہی میں اس کا پتہ چلا (وہ لائسنس کی تبدیلیوں کی وجہ سے کہتے ہیں)۔ اس نے مجھے سوچنے پر مجبور کیا کیونکہ پچھلے کچھ سالوں میں میں نے بہت سارے مضامین دیکھے ہیں کہ MongoDB کتنا خوفناک ہے اور کس طرح کسی کو اسے استعمال نہیں کرنا چاہئے۔ لیکن اس وقت کے دوران، MongoDB ایک بہت زیادہ پختہ مصنوعات بن گیا ہے۔ کیا ہوا؟ کیا تمام نفرت واقعی ایک نئے DBMS کی ابتدائی مارکیٹنگ میں غلطیوں کی وجہ سے ہے؟ یا لوگ صرف غلط جگہوں پر MongoDB استعمال کر رہے ہیں؟
اگر آپ کو لگتا ہے کہ میں MongoDB کا دفاع کر رہا ہوں، تو براہ کرم پڑھیں مضمون کے آخر میں.
نیا رجحان
میں سافٹ ویئر انڈسٹری میں اس سے زیادہ سالوں سے کام کر رہا ہوں جتنا کہ میں کہہ سکتا ہوں، لیکن مجھے ابھی تک ان رجحانات کے صرف ایک چھوٹے سے حصے کا سامنا کرنا پڑا ہے جنہوں نے ہماری صنعت کو متاثر کیا ہے۔ میں نے 4GL، AOP، Agile، SOA، Web 2.0، AJAX، Blockchain کے عروج کا مشاہدہ کیا ہے... فہرست لامتناہی ہے۔ ہر سال نئے رجحانات ظاہر ہوتے ہیں۔ کچھ تیزی سے ختم ہو جاتے ہیں، جبکہ دیگر بنیادی طور پر سافٹ ویئر تیار کرنے کے طریقے کو بدل دیتے ہیں۔
ہر نیا رجحان ایک عمومی جوش و خروش پیدا کرتا ہے: لوگ یا تو بورڈ پر کودتے ہیں، یا دوسروں کی طرف سے پیدا ہونے والے شور کو دیکھتے ہیں اور ہجوم کی پیروی کرتے ہیں۔ اس عمل کو گارٹنر ان کے ذریعہ کوڈفائیڈ کیا گیا ہے۔ . اگرچہ متنازعہ ہے، یہ ٹائم لائن تقریباً بیان کرتی ہے کہ ٹیکنالوجیز کے آخر کار کارآمد ہونے سے پہلے ان کا کیا ہوتا ہے۔
لیکن وقتاً فوقتاً ایک نئی اختراع ظاہر ہوتی ہے (یا اس کی دوسری آمد ہوتی ہے، جیسا کہ اس معاملے میں) صرف ایک مخصوص نفاذ کے ذریعے چلایا جاتا ہے۔ NoSQL کے معاملے میں، hype بہت زیادہ منگو ڈی بی کے ابھرنے اور موسمیاتی اضافے کے ذریعہ کارفرما تھا۔ MongoDB نے یہ رجحان شروع نہیں کیا: درحقیقت، بڑی انٹرنیٹ کمپنیوں کو ڈیٹا کی بڑی مقدار پر کارروائی کرنے میں دشواری کا سامنا کرنا پڑا، جس کی وجہ سے غیر متعلقہ ڈیٹا بیسز کی واپسی ہوئی۔ مجموعی طور پر تحریک کا آغاز گوگل کے بگ ٹیبل اور فیس بک کی کیسینڈرا جیسے منصوبوں سے ہوا، لیکن یہ MongoDB تھا جو سب سے زیادہ معروف اور قابل رسائی NoSQL ڈیٹا بیس کا نفاذ بن گیا جس تک زیادہ تر ڈویلپرز کو رسائی حاصل تھی۔
نوٹ: آپ یہ سوچ سکتے ہیں کہ میں کالمر ڈیٹا بیس، کلیدی/ویلیو اسٹورز، یا ڈیٹا اسٹورز کی متعدد دیگر اقسام میں سے کسی بھی دستاویز کے ڈیٹا بیس کو الجھا رہا ہوں جو عام NoSQL تعریف کے تحت آتے ہیں۔ اور تم ٹھیک کہتے ہو۔ لیکن اس وقت افراتفری کا راج تھا۔ ہر کوئی NoSQL کا جنون ہے، یہ سب بن گیا ہے۔ بالکل ضروری ہے، اگرچہ بہت سے لوگوں نے مختلف ٹیکنالوجیز میں فرق نہیں دیکھا۔ بہت سے لوگوں کے لیے، MongoDB بن گیا ہے۔ مترادف NoSQL۔
اور ڈویلپرز نے اس پر زور دیا۔ کسی بھی مسئلے کو حل کرنے کے لیے جادوئی طریقے سے اسکیم لیس ڈیٹا بیس کا خیال کافی پرکشش تھا۔ 2014 کے آس پاس، ایسا لگتا تھا کہ ہر جگہ جہاں ایک سال پہلے ایک رشتہ دار ڈیٹا بیس استعمال کیا جاتا تھا جیسے MySQL، Postgres یا SQL Server نے MongoDB ڈیٹا بیس کو تعینات کرنا شروع کر دیا تھا۔ جب آپ سے پوچھا گیا کہ کیوں، آپ کو "یہ ویب کا پیمانہ ہے" سے زیادہ سوچ سمجھ کر جواب مل سکتا ہے "میرا ڈیٹا بہت ڈھیلا ڈھانچہ ہے اور بغیر کسی اسکیما کے ڈیٹا بیس میں فٹ بیٹھتا ہے۔"
یہ یاد رکھنا ضروری ہے کہ MongoDB، اور عام طور پر دستاویزی ڈیٹا بیس، روایتی رشتہ دار ڈیٹا بیس کے ساتھ کئی مسائل حل کرتے ہیں:
- سخت اسکیم: ایک متعلقہ ڈیٹا بیس کے ساتھ، اگر آپ نے متحرک طور پر ڈیٹا تیار کیا ہے، تو آپ کو یا تو ڈیٹا کے بے ترتیب "متفرق" کالموں کا ایک گروپ بنانے، ڈیٹا کے بلابس کو وہاں سے ہٹانے، یا کنفیگریشن استعمال کرنے پر مجبور کیا جاتا ہے۔ ...اس سب میں نمایاں خرابیاں ہیں۔
- پیمائش کرنے میں دشواری: اگر اتنا زیادہ ڈیٹا ہے کہ یہ ایک سرور پر فٹ نہیں بیٹھتا ہے، تو MongoDB نے اسے متعدد مشینوں میں پیمانے کی اجازت دینے کے لیے میکانزم پیش کیے ہیں۔
- پیچیدہ سرکٹ ترمیم: کوئی ہجرت نہیں! متعلقہ ڈیٹا بیس میں، ڈیٹا بیس کی ساخت کو تبدیل کرنا ایک بہت بڑا مسئلہ ہوسکتا ہے (خاص طور پر جب بہت زیادہ ڈیٹا موجود ہو)۔ MongoDB اس عمل کو بہت آسان بنانے کے قابل تھا۔ اور اس نے اسے اتنا آسان بنا دیا ہے کہ آپ جاتے جاتے سرکٹ کو اپ ڈیٹ کر سکتے ہیں اور بہت تیزی سے آگے بڑھ سکتے ہیں۔
- ریکارڈنگ کی کارکردگی: MongoDB کی کارکردگی اچھی تھی، خاص طور پر جب مناسب طریقے سے ترتیب دی گئی ہو۔ یہاں تک کہ MongoDB کی آؤٹ آف دی باکس کنفیگریشن، جس کے لیے اسے اکثر تنقید کا نشانہ بنایا جاتا تھا، نے کچھ متاثر کن کارکردگی کے نمبر دکھائے۔
تمام خطرات آپ پر ہیں۔
MongoDB کے ممکنہ فوائد بہت زیادہ تھے، خاص طور پر مسائل کے بعض طبقات کے لیے۔ اگر آپ سیاق و سباق کو سمجھے بغیر اور تجربے کے بغیر مذکورہ فہرست کو پڑھتے ہیں، تو آپ کو یہ تاثر مل سکتا ہے کہ MongoDB واقعی ایک انقلابی DBMS ہے۔ صرف ایک مسئلہ یہ تھا کہ اوپر درج فوائد متعدد انتباہات کے ساتھ آئے تھے، جن میں سے کچھ ذیل میں درج ہیں۔
منصفانہ طور پر، 10gen/MongoDB Inc پر کوئی بھی نہیں۔ یہ نہیں کہیں گے کہ مندرجہ ذیل سچ نہیں ہے، یہ صرف سمجھوتہ ہیں۔
- کھوئے ہوئے لین دین: لین دین بہت سے متعلقہ ڈیٹا بیسز کی بنیادی خصوصیت ہیں (سب نہیں، لیکن زیادہ تر)۔ لین دین کا مطلب یہ ہے کہ آپ ایٹمی طور پر ایک سے زیادہ آپریشن انجام دے سکتے ہیں اور اس بات کو یقینی بنا سکتے ہیں کہ ڈیٹا مستقل رہے۔ بلاشبہ، NoSQL ڈیٹا بیس کے ساتھ، لین دین ایک دستاویز کے اندر ہو سکتا ہے، یا آپ ٹرانزیکشنل سیمنٹکس حاصل کرنے کے لیے دو فیز کمٹ کا استعمال کر سکتے ہیں۔ لیکن آپ کو اس فعالیت کو خود نافذ کرنا پڑے گا... جو ایک مشکل اور وقت طلب کام ہوسکتا ہے۔ اکثر آپ کو یہ احساس نہیں ہوتا کہ کوئی مسئلہ ہے جب تک کہ آپ ڈیٹا بیس میں موجود ڈیٹا کو غلط حالتوں میں نہیں دیکھتے کیونکہ آپریشنز کے جوہری ہونے کی ضمانت نہیں دی جا سکتی۔ نوٹ: بہت سے لوگوں نے مجھے بتایا کہ MongoDB 4.0 نے پچھلے سال لین دین متعارف کرایا تھا، لیکن کچھ حدود کے ساتھ۔ مضمون سے ٹیک وے وہی رہتا ہے: اندازہ کریں کہ ٹیکنالوجی آپ کی ضروریات کو کتنی اچھی طرح سے پورا کرتی ہے۔
- رشتہ داری کی سالمیت کا نقصان (غیر ملکی چابیاں): اگر آپ کے ڈیٹا میں رشتے ہیں تو آپ کو درخواست میں ان کا اطلاق کرنا ہوگا۔ ان رشتوں کا احترام کرنے والا ڈیٹا بیس ہونا درخواست سے بہت زیادہ کام لے گا اور اس وجہ سے آپ کے پروگرامرز۔
- ڈیٹا سٹرکچر کو لاگو کرنے کی صلاحیت کا فقدان: سخت اسکیمے بعض اوقات ایک بڑا مسئلہ ہو سکتے ہیں، لیکن اگر یہ دانشمندی سے استعمال کیے جائیں تو ڈیٹا کی اچھی ساخت کے لیے یہ ایک طاقتور طریقہ کار بھی ہیں۔ MongoDB جیسے دستاویزی ڈیٹا بیس ناقابل یقین سکیما لچک فراہم کرتے ہیں، لیکن یہ لچک ڈیٹا کو صاف رکھنے کی ذمہ داری کو ہٹا دیتی ہے۔ اگر آپ ان کا خیال نہیں رکھتے ہیں، تو آپ اپنی ایپلیکیشن میں بہت سارے کوڈ لکھیں گے تاکہ ڈیٹا کا حساب کتاب کیا جا سکے جو آپ کی توقع کے مطابق محفوظ نہیں ہے۔ جیسا کہ ہم اپنی کمپنی میں اکثر کہتے ہیں Simple Thread... ایپلی کیشن کسی دن دوبارہ لکھی جائے گی، لیکن ڈیٹا ہمیشہ زندہ رہے گا۔ نوٹ: MongoDB سکیما چیکنگ کو سپورٹ کرتا ہے: یہ مفید ہے، لیکن وہی گارنٹی فراہم نہیں کرتا جیسا کہ متعلقہ ڈیٹا بیس میں ہے۔ سب سے پہلے، سکیما چیک کو شامل کرنے یا تبدیل کرنے سے کلیکشن میں موجود ڈیٹا پر کوئی اثر نہیں پڑتا ہے۔ یہ یقینی بنانا آپ پر منحصر ہے کہ آپ نئے اسکیما کے مطابق ڈیٹا کو اپ ڈیٹ کرتے ہیں۔ خود فیصلہ کریں کہ آیا یہ آپ کی ضروریات کے لیے کافی ہے۔
- مقامی استفسار کی زبان / ٹول ایکو سسٹم کا نقصان: SQL کی آمد ایک مطلق انقلاب تھی اور اس کے بعد سے کچھ بھی نہیں بدلا۔ یہ ایک ناقابل یقین حد تک طاقتور زبان ہے، لیکن یہ کافی پیچیدہ بھی ہے۔ JSON ٹکڑوں پر مشتمل ایک نئی زبان میں ڈیٹا بیس کے سوالات بنانے کی ضرورت کو SQL کے ساتھ کام کرنے کا تجربہ رکھنے والے لوگوں کے لیے پیچھے کی طرف ایک بڑا قدم سمجھا جاتا ہے۔ ٹولز کی ایک پوری کائنات ہے جو آئی ڈی ای سے لے کر رپورٹنگ ٹولز تک ایس کیو ایل ڈیٹا بیس کے ساتھ تعامل کرتی ہے۔ ایس کیو ایل کو سپورٹ نہ کرنے والے ڈیٹا بیس میں منتقل ہونے کا مطلب ہے کہ آپ ان میں سے زیادہ تر ٹولز استعمال نہیں کر سکتے یا آپ کو ڈیٹا کو استعمال کرنے کے لیے SQL میں ترجمہ کرنا پڑتا ہے، جو آپ کے خیال سے کہیں زیادہ مشکل ہو سکتا ہے۔
بہت سے ڈویلپرز جنہوں نے MongoDB کا رخ کیا وہ واقعی تجارتی معاملات کو نہیں سمجھتے تھے، اور اکثر اس کو اپنے بنیادی ڈیٹا اسٹور کے طور پر انسٹال کرنے میں سرفہرست تھے۔ اس کے بعد واپس آنا اکثر ناقابل یقین حد تک مشکل تھا۔
مختلف طریقے سے کیا کیا جا سکتا تھا؟
ہر کوئی سر سے پہلے چھلانگ نہیں لگاتا اور نیچے سے نہیں مارتا تھا۔ لیکن بہت سے پروجیکٹس نے MongoDB کو ان جگہوں پر انسٹال کیا ہے جہاں یہ بالکل فٹ نہیں ہے - اور انہیں آنے والے کئی سالوں تک اس کے ساتھ رہنا پڑے گا۔ اگر ان تنظیموں نے کچھ وقت گزارا ہوتا اور اپنی ٹکنالوجی کے انتخاب کے بارے میں طریقہ کار کے ساتھ سوچا ہوتا تو بہت سے لوگ مختلف انتخاب کرتے۔
صحیح ٹیکنالوجی کا انتخاب کیسے کریں؟ ٹیکنالوجی کی تشخیص کے لیے ایک منظم فریم ورک بنانے کی کئی کوششیں کی گئی ہیں، جیسے и ، لیکن مجھے لگتا ہے کہ یہ غیر ضروری پیچیدگی ہے۔
صرف دو بنیادی سوالات پوچھ کر بہت سی ٹیکنالوجیز کا ذہانت سے اندازہ لگایا جا سکتا ہے۔ مسئلہ ایسے لوگوں کو تلاش کرنا ہے جو انہیں ذمہ داری سے جواب دے سکیں، جوابات تلاش کرنے کے لیے وقت نکالیں اور تعصب کے بغیر۔
اگر آپ کو کوئی مسئلہ درپیش نہیں ہے تو آپ کو کسی نئے ٹول کی ضرورت نہیں ہے۔ ڈاٹ
سوال 1: میں کن مسائل کو حل کرنے کی کوشش کر رہا ہوں؟
اگر آپ کو کوئی مسئلہ درپیش نہیں ہے تو آپ کو کسی نئے ٹول کی ضرورت نہیں ہے۔ ڈاٹ حل تلاش کرنے اور پھر مسئلہ ایجاد کرنے کی ضرورت نہیں۔ جب تک آپ کو کوئی مسئلہ درپیش نہ ہو جسے نئی ٹیکنالوجی آپ کی موجودہ ٹکنالوجی سے نمایاں طور پر بہتر طریقے سے حل کرتی ہے، یہاں بات کرنے کے لیے کچھ نہیں ہے۔ اگر آپ اس ٹیکنالوجی کو استعمال کرنے پر غور کر رہے ہیں کیونکہ آپ نے دوسروں کو اسے استعمال کرتے ہوئے دیکھا ہے، تو غور کریں کہ انہیں کن مسائل کا سامنا ہے اور پوچھیں کہ کیا آپ کو یہ مسائل درپیش ہیں۔ کسی ٹیکنالوجی کو قبول کرنا آسان ہے کیونکہ دوسرے اسے استعمال کر رہے ہیں، چیلنج یہ سمجھنا ہے کہ آیا آپ کو بھی وہی مسائل درپیش ہیں۔
سوال 2: میں کیا کھو رہا ہوں؟
یہ یقینی طور پر زیادہ مشکل سوال ہے کیونکہ آپ کو پرانی اور نئی ٹیکنالوجی دونوں کے بارے میں اچھی طرح سمجھنا پڑے گا۔ کبھی کبھی آپ واقعی کسی نئے کو اس وقت تک نہیں سمجھ سکتے جب تک کہ آپ اس کے ساتھ کچھ نہ بنائیں یا اس کے ساتھ کسی کو تجربہ نہ ہو۔
اگر آپ کے پاس کوئی بھی نہیں ہے، تو اس آلے کی قدر کا تعین کرنے کے لیے کم از کم ممکنہ سرمایہ کاری کے بارے میں سوچنا سمجھ میں آتا ہے۔ اور ایک بار جب آپ سرمایہ کاری کر لیتے ہیں، تو فیصلہ واپس لینا کتنا مشکل ہو گا؟
لوگ ہمیشہ سب کچھ برباد کر دیتے ہیں۔
جب آپ ان سوالوں کے جوابات غیر جانبداری سے دینے کی کوشش کرتے ہیں تو ایک بات یاد رکھیں: آپ کو انسانی فطرت سے لڑنا پڑے گا۔ ٹیکنالوجی کے مؤثر طریقے سے جائزہ لینے کے لیے بہت سے علمی تعصبات ہیں جن پر قابو پانا ضروری ہے۔ یہاں صرف چند ایک ہیں:
- - ہر کوئی اس کے بارے میں جانتا ہے، لیکن پھر بھی اس سے لڑنا مشکل ہے۔ بس اس بات کو یقینی بنائیں کہ ٹیکنالوجی آپ کی اصل ضروریات سے میل کھاتی ہے۔
- — بہت سے ڈویلپرز ان ٹیکنالوجیز کو کم سمجھتے ہیں جن کے ساتھ انہوں نے طویل عرصے سے کام کیا ہے اور نئی ٹیکنالوجی کے فوائد کو زیادہ اہمیت دیتے ہیں۔ یہ صرف پروگرامرز ہی نہیں، ہر کوئی اس علمی تعصب کا شکار ہے۔
- - ہم یہ دیکھتے ہیں کہ وہاں کیا ہے اور جو غائب ہے اس کی نظر کھو دیتے ہیں۔ یہ نت نئے اثرات کے ساتھ مل کر افراتفری کا باعث بن سکتا ہے، کیونکہ آپ نہ صرف فطری طور پر نئی ٹیکنالوجی کو زیادہ اہمیت دیتے ہیں، بلکہ اس کی خامیوں کو بھی نظر انداز کرتے ہیں۔.
معروضی تشخیص آسان نہیں ہے، لیکن بنیادی علمی تعصبات کو سمجھنے سے آپ کو زیادہ عقلی فیصلے کرنے میں مدد ملے گی۔
خلاصہ
جب بھی کوئی اختراع ظاہر ہوتی ہے تو دو سوالوں کا نہایت احتیاط سے جواب دینا ضروری ہے:
- کیا یہ ٹول ایک حقیقی مسئلہ حل کرتا ہے؟
- کیا ہم تجارت کو اچھی طرح سمجھتے ہیں؟
اگر آپ اعتماد کے ساتھ ان دو سوالوں کا جواب نہیں دے سکتے تو چند قدم پیچھے ہٹ کر سوچیں۔
تو کیا MongoDB بھی صحیح انتخاب تھا؟ جی ہاں بالکل؛ جیسا کہ زیادہ تر انجینئرنگ ٹیکنالوجیز کے ساتھ، یہ بہت سے عوامل پر منحصر ہے۔ ان دو سوالوں کے جواب دینے والوں میں سے، بہت سے لوگوں نے MongoDB سے فائدہ اٹھایا ہے اور وہ کرتے رہتے ہیں۔ ان لوگوں کے لیے جنہوں نے ایسا نہیں کیا، مجھے امید ہے کہ آپ نے ہائپ سائیکل سے گزرنے کے بارے میں ایک قیمتی اور زیادہ تکلیف دہ سبق سیکھا ہوگا۔
دستبرداری
میں واضح کرنا چاہتا ہوں کہ میرا MongoDB کے ساتھ نہ تو محبت ہے اور نہ ہی نفرت کا رشتہ۔ ہمارے پاس ابھی اس قسم کے مسائل نہیں ہیں جن کو حل کرنے کے لیے MongoDB بہترین موزوں ہے۔ میں جانتا ہوں کہ 10gen/MongoDB Inc. پہلے تو بہت بولڈ تھا، کسی بھی ڈیٹا کے ساتھ کام کرنے کے لیے ایک آفاقی حل کے طور پر غیر محفوظ ڈیفالٹس کو ترتیب دینا اور ہر جگہ (خاص طور پر ہیکاتھنز میں) MongoDB کو فروغ دینا۔ یہ شاید ایک برا فیصلہ تھا۔ لیکن یہ یہاں بیان کردہ نقطہ نظر کی تصدیق کرتا ہے: ٹیکنالوجی کی سطحی تشخیص کے ساتھ بھی ان مسائل کا بہت جلد پتہ لگایا جا سکتا ہے۔
ماخذ: www.habr.com