’’یہ ضروری ہے۔‘‘ اس نے کسی سے مخاطب نہ ہوتے ہوئے اونچی آواز میں کہا۔ - یہ ضروری ہے! یہ بالکل وہی ہے جو یہ کہتا ہے: کمپنی کا بنیادی کام حصص یافتگان کے مفادات میں منافع کمانا ہے۔ ٹھیک ہے، اس کے بارے میں سوچو! وہ کسی چیز سے نہیں ڈرتے!
یولی ڈوبوف، "کم برائی"
ایسی سرخی دیکھ کر، آپ شاید پہلے ہی فیصلہ کر چکے ہوں گے کہ مضمون یا تو حماقت ہے یا اشتعال انگیزی۔ لیکن نتیجہ اخذ کرنے میں جلدی نہ کریں: بڑی کارپوریشنوں کے ملازمین، خاص طور پر ریاستی شرکت والی کارپوریشنوں کو اکثر مختلف پلیٹ فارمز کا موازنہ کرنا پڑتا ہے، بشمول مکمل طور پر مختلف پلیٹ فارمز - مثال کے طور پر، عنوان والے۔
یقیناً، کوئی بھی اس طرح سے ڈی بی ایم ایس کا موازنہ نہیں کرتا، کیونکہ ان کی خوبیاں اور کمزوریاں اچھی طرح سے معلوم ہیں۔ ایک اصول کے طور پر، پلیٹ فارمز جو کچھ ایپلیکیشن کے مسئلے کو حل کرتے ہیں وہ موازنہ کے تابع ہیں۔ مضمون میں میں وہ طریقہ کار دکھاؤں گا جو اس معاملے میں استعمال ہوتا ہے، ڈیٹا بیس کی مثال کو ایک ایسے مضمون کے طور پر استعمال کرتے ہوئے جو حبر کے قارئین کے لیے خود ہی واقف ہے۔ تو،
پریرتا
جب آپ کوئی تعلیمی پروجیکٹ یا شوق کا پروجیکٹ شروع کرتے ہیں، تو پلیٹ فارم کو منتخب کرنے کی ترغیب بہت متنوع ہو سکتی ہے: "یہ وہ پلیٹ فارم ہے جسے میں سب سے بہتر جانتا ہوں"، "میں اس کو سمجھنے میں دلچسپی رکھتا ہوں"، "یہ بہترین دستاویزات ہیں" ... ایک تجارتی کمپنی کے معاملے میں، انتخاب کا معیار ایک ہی ہے: مجھے کتنی رقم ادا کرنی ہوگی اور اس رقم کے لیے مجھے کیا ملے گا۔
قدرتی طور پر، آپ کم ادا کرنا چاہتے ہیں اور زیادہ حاصل کرنا چاہتے ہیں۔ تاہم، آپ کو یہ فیصلہ کرنے کی ضرورت ہے کہ کیا زیادہ اہم ہے - کم ادائیگی کرنا یا زیادہ لینا، اور ہر نوڈ کو ایک وزن تفویض کرنا۔ آئیے مان لیں کہ ایک اعلیٰ معیار کا حل ہمارے لیے سستے حل سے زیادہ اہم ہے، اور ہم "لاگت" نوڈ کو 40% اور "موقع" نوڈ کو 60% وزن تفویض کرتے ہیں۔
بڑی کارپوریشنوں میں، عام طور پر اس کے برعکس ہوتا ہے - لاگت کا وزن 50% سے کم نہیں ہوتا، اور شاید 60% سے زیادہ۔ ماڈل مثال میں، صرف اتنا اہم ہے کہ کسی بھی پیرنٹ نوڈ کے چائلڈ نوڈس کا کل وزن 100% ہونا چاہیے۔
کٹوتی کی شرائط
ویب سائٹ تقریباً 500 ڈیٹا بیس مینجمنٹ سسٹم معلوم ہیں۔ قدرتی طور پر، اگر آپ بہت سارے اختیارات میں سے ایک ٹارگٹ پلیٹ فارم کا انتخاب کرتے ہیں، تو آپ کو ایک جائزہ مضمون مل سکتا ہے، لیکن تجارتی پروجیکٹ نہیں۔ انتخاب کی جگہ کو کم کرنے کے لیے، کٹ آف کے معیارات مرتب کیے جاتے ہیں، اور اگر پلیٹ فارم ان معیارات کو پورا نہیں کرتا ہے، تو اس پر غور نہیں کیا جاتا ہے۔
کٹ آف کا معیار تکنیکی خصوصیات سے متعلق ہو سکتا ہے، مثال کے طور پر:
- ACID ضمانت دیتا ہے؛
- رشتہ دار ڈیٹا ماڈل؛
- ایس کیو ایل لینگویج سپورٹ (نوٹ، یہ "ریلیشنل ماڈل" جیسا نہیں ہے)؛
- افقی اسکیلنگ کا امکان۔
عام معیارات ہوسکتے ہیں:
- روس میں تجارتی مدد کی دستیابی؛
- آزاد مصدر؛
- وزارت ٹیلی کام اور ماس کمیونیکیشن کے رجسٹر میں پلیٹ فارم کی دستیابی؛
- کچھ درجہ بندی میں پلیٹ فارم کی موجودگی (مثال کے طور پر، db-engines.com کی درجہ بندی کے پہلے سو میں)؛
- مارکیٹ میں ماہرین کی موجودگی (مثال کے طور پر، ویب سائٹ hh.ru پر ریزیومے میں پلیٹ فارم کا نام تلاش کرنے کے نتائج کی بنیاد پر)۔
سب کے بعد، انٹرپرائز کے مخصوص معیار ہو سکتے ہیں:
- عملے پر ماہرین کی دستیابی؛
- مانیٹرنگ سسٹم X یا بیک اپ سسٹم Y کے ساتھ مطابقت، جس پر تمام سپورٹ مبنی ہے...
سب سے اہم بات یہ ہے کہ کٹ آف کے معیار کی ایک فہرست ہے۔ بصورت دیگر، یقینی طور پر کوئی ماہر (یا "ماہر") ہوگا جو انتظامیہ سے خصوصی اعتماد حاصل کرتا ہے جو کہے گا کہ "آپ نے پلیٹ فارم Z کا انتخاب کیوں نہیں کیا، میں جانتا ہوں کہ یہ بہترین ہے۔"
لاگت کا تخمینہ
حل کی لاگت ظاہر ہے کہ لائسنس کی قیمت، معاونت کی قیمت اور سامان کی قیمت پر مشتمل ہے۔
اگر سسٹمز تقریباً ایک ہی طبقے کے ہیں (مثال کے طور پر، Microsoft SQL Server اور PostgreSQL)، تو پھر سادگی کے لیے ہم یہ فرض کر سکتے ہیں کہ دونوں حلوں کے لیے آلات کی مقدار تقریباً ایک جیسی ہو گی۔ یہ آپ کو سامان کی جانچ نہیں کرنے کی اجازت دے گا، اس طرح بہت وقت اور کوشش کی بچت ہوگی۔ اگر آپ کو بالکل مختلف سسٹمز کا موازنہ کرنا ہے (کہیں کہ، اوریکل بمقابلہ ریڈیس)، تو یہ ظاہر ہے کہ درست تشخیص کے لیے سائزنگ (سامان کی مقدار کا حساب) کرنا ضروری ہے۔ ایک غیر موجود نظام کو سائز دینا ایک بہت ہی نا شکری کا کام ہے، اس لیے وہ پھر بھی اس طرح کے موازنہ سے بچنے کی کوشش کرتے ہیں۔ یہ کرنا آسان ہے: کٹ آف کنڈیشنز میں، ڈیٹا کا صفر نقصان اور ایک رشتہ دار ماڈل لکھا جاتا ہے، یا اس کے برعکس - فی سیکنڈ 50 ہزار ٹرانزیکشنز کا بوجھ۔
لائسنسوں کا جائزہ لینے کے لیے، یہ کافی ہے کہ وینڈر یا اس کے شراکت داروں سے ایک مقررہ تعداد کے لیے لائسنس کی قیمت اور ایک مقررہ مدت کے لیے سپورٹ کے لیے پوچھیں۔ ایک اصول کے طور پر، کمپنیاں پہلے سے ہی سافٹ ویئر فروشوں کے ساتھ مضبوط تعلقات رکھتی ہیں، اور اگر ڈیٹا بیس آپریشنز ڈیپارٹمنٹ لاگت کے سوال کا خود جواب نہیں دے سکتا، تو اس معلومات کو حاصل کرنے کے لیے ایک خط کافی ہے۔
مختلف دکانداروں کے پاس مختلف لائسنسنگ میٹرکس ہو سکتے ہیں: کور کی تعداد، ڈیٹا والیوم یا نوڈس کی تعداد کے لحاظ سے۔ اسٹینڈ بائی بیس مفت ہو سکتا ہے، یا اسے اسی طرح لائسنس دیا جا سکتا ہے جیسا کہ مرکزی ہے۔ اگر میٹرکس میں کوئی فرق پایا جاتا ہے، تو آپ کو ماڈل اسٹینڈ کو تفصیل سے بیان کرنا ہوگا اور اسٹینڈ کے لیے لائسنس کی قیمت کا حساب لگانا ہوگا۔
درست موازنے کے لیے ایک اہم نکتہ وہی سپورٹ شرائط ہے۔ مثال کے طور پر، Oracle سپورٹ پر لائسنس کی قیمت کا 22% فی سال خرچ ہوتا ہے، لیکن آپ کو PostgreSQL سپورٹ کے لیے ادائیگی کرنے کی ضرورت نہیں ہے۔ کیا اس طرح موازنہ کرنا درست ہے؟ نہیں، کیونکہ ایک غلطی جو آپ خود ٹھیک نہیں کی جا سکتی اس کے مکمل طور پر مختلف نتائج ہوتے ہیں: پہلی صورت میں، معاون ماہرین جلد ہی اسے ٹھیک کرنے میں آپ کی مدد کریں گے، لیکن دوسری صورت میں، منصوبے میں تاخیر یا مکمل ہونے کا وقت ختم ہونے کا خطرہ ہے۔ غیر معینہ مدت کے لیے نظام۔
آپ حساب کی شرائط کو تین طریقوں سے برابر کر سکتے ہیں:
- حمایت کے بغیر اوریکل کا استعمال کریں (حقیقت میں ایسا نہیں ہوتا ہے)۔
- PostgreSQL کے لیے سپورٹ خریدیں - مثال کے طور پر، Postgres Professional سے۔
- تعاون کی کمی سے وابستہ خطرات کو مدنظر رکھیں۔
مثال کے طور پر، خطرے کا حساب کتاب اس طرح نظر آسکتا ہے: ڈیٹا بیس کی مہلک ناکامی کی صورت میں، سسٹم کا ڈاؤن ٹائم 1 کاروباری دن ہوگا۔ سسٹم کے استعمال سے متوقع منافع 40 بلین MNT سالانہ ہے، حادثے کی شرح کا تخمینہ 1/400 ہے، اس طرح سپورٹ کی کمی کے خطرے کا تخمینہ تقریباً 100 ملین MNT سالانہ ہے۔ ظاہر ہے، "منصوبہ بند منافع" اور "تخمینی حادثات کی فریکوئنسی" مجازی قدریں ہیں، لیکن ایسا ماڈل نہ رکھنے سے کہیں بہتر ہے۔
حقیقت میں، طویل مدتی ڈاؤن ٹائم کی ساکھ کی قیمت ناقابل قبول ہونے کے لیے یہ نظام بہت اہم ہو سکتا ہے، اس لیے مدد کی ضرورت ہوگی۔ اگر ڈاون ٹائم کی اجازت ہے، تو کبھی کبھی سپورٹ سے انکار کرنا پیسے بچانے کا ایک اچھا طریقہ ہو سکتا ہے۔
آئیے ہم فرض کرتے ہیں کہ تمام حسابات کے بعد، 5 سالوں کے لیے آپریٹنگ پلیٹ فارم A کی لاگت 800 ملین MNT، آپریٹنگ پلیٹ فارم B کی لاگت 650 ملین MNT، اور آپریٹنگ پلیٹ فارم C کی لاگت 600 ملین MNT ہے۔ پلیٹ فارم C، فاتح کے طور پر، قیمت کے لیے ایک مکمل پوائنٹ حاصل کرتا ہے، جبکہ پلیٹ فارم A اور B کو تھوڑا کم ملتا ہے، اس تناسب سے کہ وہ کتنی بار زیادہ مہنگے ہیں۔ اس صورت میں - بالترتیب 0.75 اور 0.92 پوائنٹس۔
مواقع کی تشخیص
مواقع کی تشخیص کو کئی گروہوں میں تقسیم کیا گیا ہے، جن کی تعداد صرف تشخیص کرنے والے شخص کے تصور سے ہی محدود ہے۔ ایسا لگتا ہے کہ بہترین آپشن صلاحیتوں کو ٹیموں میں تقسیم کرنا ہے جو ان صلاحیتوں کو استعمال کریں گی۔ ہماری مثال میں، یہ ڈویلپرز، ایڈمنسٹریٹر اور انفارمیشن سیکیورٹی آفیسرز ہیں۔ آئیے فرض کریں کہ ان افعال کے وزن کو 40:40:20 کے طور پر تقسیم کیا گیا ہے۔
ترقیاتی افعال میں شامل ہیں:
- ڈیٹا ہیرا پھیری میں آسانی؛
- پیمانہ کاری
- ثانوی اشاریہ جات کی موجودگی۔
معیارات کی فہرست، نیز ان کے وزن، بہت ساپیکش ہیں۔ ایک ہی مسئلہ کو حل کرتے وقت بھی، یہ فہرستیں، آئٹم کے وزن اور جوابات آپ کی ٹیم کی ساخت کے لحاظ سے نمایاں طور پر مختلف ہوں گے۔ مثال کے طور پر، فیس بک ڈیٹا کو ذخیرہ کرنے کے لیے MySQL کا استعمال کرتا ہے، اور Instagram Cassandra پر بنایا گیا ہے۔ یہ امکان نہیں ہے کہ ان ایپلی کیشنز کے ڈویلپرز نے اس طرح کی میزیں بھریں۔ کوئی صرف اس بات کا اندازہ لگا سکتا ہے کہ مارک زکربرگ نے ایک مکمل رشتہ دار ماڈل کا انتخاب کیا، اس کے لیے لاگو شارڈنگ کی ضرورت کے ساتھ ادائیگی کی، جبکہ کیون سسٹروم نے ڈیٹا تک رسائی کی آسانی کو قربان کرتے ہوئے پلیٹ فارم کا استعمال کرتے ہوئے اسکیلنگ بنائی۔
انتظامیہ کے افعال میں شامل ہیں:
- بیک اپ سسٹم کی صلاحیتیں؛
- نگرانی میں آسانی؛
- صلاحیت کے انتظام میں آسانی - ڈسک اور نوڈس؛
- ڈیٹا نقل کی صلاحیتیں
براہ کرم نوٹ کریں کہ سوالات کو مقداری انداز میں بیان کیا جانا چاہیے۔ یہاں تک کہ آپ کسی خاص فنکشن کا اندازہ لگانے کے طریقہ پر بھی اتفاق کر سکتے ہیں۔ آئیے، مثال کے طور پر، اوریکل DBMS کے ساتھ فراہم کردہ ٹولز کی مثال کا استعمال کرتے ہوئے بیک اپ ٹولز کی درجہ بندی کرنے کی کوشش کریں:
آلہ۔
تبصرہ
تشخیص
imp/exp
ڈیٹا اپ لوڈ اور لوڈ کرنا
0.1
شروع/آخر بیک اپ
فائلوں کو کاپی کرنا
0.3
RMAN
بڑھتی ہوئی کاپی کی صلاحیت
0.7
ZDLRA
صرف انکریمنٹل کاپینگ، پوائنٹ پر تیز ترین ریکوری
1.0
اگر تشخیص کا کوئی واضح معیار نہیں ہے، تو یہ سمجھ میں آتا ہے کہ کئی ماہرین سے درجہ بندی کرنے کے لیے کہیں اور پھر ان کی اوسط لگائیں۔
آخر میں، ہم صرف معلومات کی حفاظت کے افعال کی فہرست دیتے ہیں:
- پاس ورڈ کے انتظام کی پالیسیوں کی دستیابی؛
- بیرونی تصدیقی ٹولز (LDAP، Kerberos) کو جوڑنے کی صلاحیت؛
- رسائی کا رول ماڈل؛
- آڈٹ کی صلاحیتیں؛
- ڈسک پر ڈیٹا کی خفیہ کاری؛
- نیٹ ورک پر ٹرانسمیشن کے دوران خفیہ کاری (TLS)؛
- ایڈمنسٹریٹر سے ڈیٹا کا تحفظ۔
کارکردگی کی جانچ
الگ سے، میں کسی بھی لوڈ ٹیسٹ کے نتائج کو استعمال کرنے کے خلاف انتباہ کرنا چاہوں گا جو آپ نے بطور دلیل نہیں بنائے تھے۔
سب سے پہلے، جانچ کی جا رہی ایپلیکیشنز کا ڈیٹا ڈھانچہ اور لوڈ پروفائل اس مسئلے سے کافی مختلف ہو سکتا ہے جسے آپ حل کرنے جا رہے ہیں۔ تقریباً 10-15 سال پہلے، ڈیٹا بیس وینڈرز TPC ٹیسٹوں میں حاصل ہونے والے نتائج کو ظاہر کرنا پسند کرتے تھے، لیکن اب، ایسا لگتا ہے، کوئی بھی ان نتائج کو سنجیدگی سے نہیں لیتا۔
دوم، سسٹم کی کارکردگی کافی حد تک اس بات پر منحصر ہے کہ کوڈ اصل میں کس پلیٹ فارم کے لیے لکھا گیا تھا اور ٹیسٹ کس سامان پر کیا گیا تھا۔ میں نے بہت سے ٹیسٹ دیکھے ہیں جہاں اوریکل کا موازنہ PostgreSQL سے کیا گیا تھا۔ نتائج ایک نظام کی غیر مشروط برتری سے دوسرے نظام کی مساوی غیر مشروط برتری تک ہیں۔
اور آخر میں، تیسرا، آپ اس بارے میں کچھ نہیں جانتے کہ ٹیسٹ کس نے کیا۔ دونوں قابلیتیں اہم ہیں، جو OS اور پلیٹ فارم کو ترتیب دینے کے معیار کو متاثر کرتی ہیں، نیز حوصلہ افزائی، جو ٹیسٹ کے نتائج کو دیگر تمام عوامل سے زیادہ متاثر کرتی ہے۔
اگر کارکردگی ایک اہم عنصر ہے، تو خود ٹیسٹ کروائیں، ترجیحاً ان لوگوں کی مدد سے جو پیداواری نظام کو ترتیب دیں گے اور اسے برقرار رکھیں گے۔
نتیجہ
آخر میں، کیے گئے تمام کام کا نتیجہ ایک اسپریڈ شیٹ ہونا چاہیے جہاں تمام تخمینوں کو ملا کر، ضرب اور خلاصہ کیا جائے:
جیسا کہ آپ سمجھتے ہیں، ترازو کو تبدیل کرکے اور درجہ بندی کو ایڈجسٹ کرکے آپ کوئی بھی مطلوبہ نتیجہ حاصل کرسکتے ہیں، لیکن یہ بالکل مختلف کہانی ہے...
ماخذ: www.habr.com