هغې په لوړ غږ وویل: "دا اړینه ده." چا ته یې خطاب نه کړ. - دا اړینه ده! دا په حقیقت کې هغه څه دي چې وايي: د شرکت اصلي دنده د ونډې اخیستونکو په ګټو کې ګټه ترلاسه کول دي. ښه، فکر وکړئ! دوی له هیڅ شی نه ډاریږي!
یولي دوبوف، "لږ بد"
د داسې سرلیک په لیدلو سره، تاسو شاید دمخه پریکړه کړې وي چې دا مقاله یا حماقت یا اشتباه ده. مګر پایلې ته ګړندۍ مه کوئ: د لوی شرکتونو کارمندان ، په ځانګړي توګه هغه شرکتونه چې دولتي برخه لري ، ډیری وختونه باید مختلف پلیټ فارمونه پرتله کړي ، پشمول په بشپړ ډول مختلف - د مثال په توګه ، هغه چې په سرلیک کې دي.
البته، هیڅوک په دې طریقه د DBMSs پرتله نه کوي، ځکه چې د دوی ځواک او ضعف ښه پوهیږي. د یوې قاعدې په توګه، هغه پلیټ فارمونه چې د غوښتنلیک ځینې ستونزې حل کوي د پرتله کولو تابع دي. په مقاله کې به زه هغه میتودولوژي وښیم چې پدې قضیه کې کارول کیږي ، د ډیټابیس مثال په توګه د یوې موضوع په توګه کارول چې د هابر لوستونکو ته په لومړي سر کې پیژندل کیږي. نو،
انګیزه
کله چې تاسو یوه تعلیمي پروژه یا د شوق پروژه پیل کړئ ، د پلیټ فارم غوره کولو هڅونه خورا متنوع کیدی شي: "دا هغه پلیټ فارم دی چې زه یې ښه پوهیږم" ، "زه د دې په پوهیدو کې علاقه لرم" ، "دلته غوره اسناد دي" ... د سوداګریز شرکت په قضیه کې، د انتخاب معیار یو شان دی: زه به څومره پیسې ورکړم او د دې پیسو لپاره به څه ترلاسه کړم.
په طبیعي توګه، تاسو غواړئ لږ پیسې ورکړئ او ډیر ترلاسه کړئ. په هرصورت، تاسو اړتیا لرئ پریکړه وکړئ چې څه مهم دي - لږ پیسې ورکول یا ډیر ترلاسه کول، او هر نوډ ته وزن ورکړئ. راځئ فرض کړو چې د لوړ کیفیت حل زموږ لپاره د ارزانه حل په پرتله خورا مهم دی، او موږ 40٪ وزن د "لګښت" نوډ ته، او 60٪ د "فرصتونو" نوډ ته ورکوو.
په لویو شرکتونو کې، برعکس معمولا ریښتیا وي - د لګښت وزن د 50٪ څخه کم نه وي، او ممکن د 60٪ څخه ډیر وي. د ماډل مثال کې، ټول هغه څه چې مهم دي دا دي چې د هر والدین نوډ د ماشوم نوډونو ټول وزن باید 100٪ وي.
د قطع کیدو شرایط
ویب پاڼه د ډیټابیس مدیریت شاوخوا 500 سیسټمونه پیژندل شوي. په طبیعي توګه، که تاسو د ډیری انتخابونو څخه د هدف پلیټ فارم غوره کړئ، تاسو ممکن د بیاکتنې مقالې سره پای ته ورسیږئ، مګر سوداګریزه پروژه نه. د انتخاب ځای کمولو لپاره، د کټ آف معیارونه جوړ شوي، او که پلیټ فارم دا معیارونه پوره نکړي، نو دا په پام کې نه نیول کیږي.
د قطع کولو معیارونه ممکن د تخنیکي ځانګړتیاو سره تړاو ولري، د بیلګې په توګه:
- د ACID تضمین؛
- د اړونده معلوماتو ماډل؛
- د SQL ژبې ملاتړ (یادونه، دا د "اړیکو ماډل" په څیر ندي)؛
- د افقی اندازه کولو امکان.
کېدای شي عمومي معیارونه وي:
- په روسیه کې د سوداګریزو مرستو شتون؛
- خلاص سرچینه؛
- د مخابراتو او ډله ایزو مخابراتو وزارت په راجستر کې د پلیټ فارم شتون؛
- په ځینو درجه بندي کې د پلیټ فارم شتون (د مثال په توګه، د db-engines.com درجه بندي په لومړي سو کې)؛
- په بازار کې د متخصصینو شتون (د بیلګې په توګه، د ویب پاڼې په بیا پیل کې د پلیټ فارم نوم لټون کولو پایلو پر بنسټ hh.ru).
په هرصورت، ممکن د تصدۍ ځانګړي معیارونه وي:
- په کارکوونکو کې د متخصصینو شتون؛
- د نظارت سیسټم X یا بیک اپ سیسټم Y سره مطابقت ، په کوم کې چې ټول ملاتړ پراساس دی ...
ترټولو مهمه خبره دا ده چې د کټ آف معیارونو لیست شتون لري. که نه نو، یقینا یو متخصص (یا "ماهر") به وي چې د مدیریت څخه ځانګړي باور څخه خوند اخلي څوک به ووایي "ولې تاسو پلیټ فارم Z نه غوره کړی، زه پوهیږم چې دا غوره دی."
د لګښت اټکل
د حل لګښت په ښکاره ډول د جوازونو لګښت، د ملاتړ لګښت او د تجهیزاتو لګښت لري.
که سیسټمونه نږدې ورته ټولګي وي (د مثال په توګه ، د مایکروسافټ SQL سرور او PostgreSQL) ، نو د سادگي لپاره موږ فرض کولی شو چې د دواړو حلونو لپاره د تجهیزاتو مقدار به نږدې ورته وي. دا به تاسو ته اجازه درکړي چې د تجهیزاتو ارزونه ونه کړي، په دې توګه ډیر وخت او هڅې خوندي کوي. که تاسو په بشپړ ډول مختلف سیسټمونه پرتله کړئ (ووایه ، اوریکل vs. ریډیس) ، نو دا څرګنده ده چې د سمې ارزونې لپاره دا اړینه ده چې اندازه کول (د تجهیزاتو مقدار محاسبه کول). د غیر موجود سیسټم اندازه کول خورا بې شکره کار دی ، نو دوی لاهم هڅه کوي د ورته پرتله کولو مخه ونیسي. دا کول اسانه دي: د کټ آف شرایطو کې ، د صفر ډیټا ضایع کول او یو اړونده ماډل لیکل کیږي ، یا برعکس - په هره ثانیه کې د 50 زره لیږدونو بار.
د جوازونو ارزولو لپاره، دا کافي ده چې د پلورونکي یا د هغې شریکانو څخه د یو ثابت شمیر کورونو او د یوې ټاکلې مودې لپاره د ملاتړ لپاره د جواز لګښت غوښتنه وکړئ. د یوې قاعدې په توګه ، شرکتونه دمخه د سافټویر پلورونکو سره قوي اړیکې لري ، او که چیرې د ډیټابیس عملیاتي څانګه نشي کولی پخپله د لګښت پوښتنې ځواب کړي ، نو د دې معلوماتو ترلاسه کولو لپاره یو لیک کافي دی.
مختلف پلورونکي ممکن د جواز ورکولو مختلف میټریکونه ولري: د کور شمیره ، د معلوماتو حجم یا د نوډونو شمیر. د سټینډ بای اډه وړیا کیدی شي ، یا دا د اصلي په څیر ورته جواز ترلاسه کیدی شي. که چیرې په میټریکونو کې کوم توپیر وموندل شي، تاسو باید د ماډل موقف په تفصیل سره تشریح کړئ او د سټینډ لپاره د جوازونو لګښت محاسبه کړئ.
د سم پرتله کولو لپاره یو مهم ټکی د ورته ملاتړ شرایط دي. د مثال په توګه ، د اوریکل ملاتړ په کال کې د جواز قیمت 22٪ لګښت کوي ، مګر تاسو اړتیا نلرئ د PostgreSQL ملاتړ لپاره پیسې ورکړئ. ایا د دې ډول پرتله کول سمه ده؟ نه، ځکه چې یوه تېروتنه چې ستاسو په خپله نشي حل کیدی په بشپړه توګه مختلفې پایلې لري: په لومړي حالت کې، د مالتړ متخصصین به تاسو سره په چټکۍ سره د هغې په حل کولو کې مرسته وکړي، مګر په دویمه قضیه کې، د پروژې د ځنډولو یا پای ته رسیدو وخت کې د ځنډ خطر شتون لري. سیسټم د نامعلومې مودې لپاره.
تاسو کولی شئ د محاسبې شرایط په دریو لارو مساوي کړئ:
- د ملاتړ پرته اوریکل وکاروئ (په حقیقت کې دا نه پیښیږي).
- د PostgreSQL لپاره ملاتړ واخلئ - د بیلګې په توګه، د پوسټګریس مسلکي څخه.
- د ملاتړ نشتوالي سره تړلي خطرونه په پام کې ونیسئ.
د مثال په توګه، د خطر محاسبه کیدای شي داسې ښکاري: د وژونکي ډیټابیس ناکامۍ په صورت کې، د سیسټم وخت به 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 کاروي، او انسټاګرم په کاسیندرا کې جوړ شوی. دا امکان نلري چې د دې غوښتنلیکونو پراختیا کونکي دا ډول میزونه ډک کړي. یو څوک یوازې اټکل کولی شي چې مارک زوکربرګ یو بشپړ تړاو لرونکی ماډل غوره کړی ، د پلي شوي شارډینګ اړتیا سره یې تادیه کړې ، پداسې حال کې چې کیون سیسټروم د پلیټ فارم په کارولو سره سکیلینګ رامینځته کړی ، ډیټا ته د لاسرسي اسانتیا قرباني کوي.
د ادارې دندې عبارت دي له:
- د بیک اپ سیسټم وړتیاوې؛
- د څارنې اسانتیا؛
- د ظرفیت مدیریت اسانه کول - ډیسکونه او نوډونه؛
- د معلوماتو د نقل کولو وړتیاوې.
مهرباني وکړئ په یاد ولرئ چې پوښتنې باید په کمیتي ډول بیان شي. تاسو حتی کولی شئ موافقه وکړئ چې څنګه د یو ځانګړي فعالیت ارزونه وکړئ. راځئ چې د مثال په توګه د اوریکل DBMS سره چمتو شوي وسیلو مثال په کارولو سره د بیک اپ وسیلو درجه بندي کولو هڅه وکړو:
اوزار
تبصره
ارزونې
imp/exp
د معلوماتو پورته کول او پورته کول
0.1
بیک اپ پیل / پای
د فایلونو کاپي کول
0.3
RMAN
د زیاتیدونکي کاپي وړتیا
0.7
ZDLRA
یوازې زیاتیدونکي کاپي کول، په نښه کولو کې ګړندۍ رغونه
1.0
که چیرې د ارزونې روښانه معیارونه شتون ونلري، نو دا معنی لري چې د څو متخصصینو څخه وغواړئ چې درجه بندي ورکړي او بیا یې اوسط کړي.
په نهایت کې ، موږ په ساده ډول د معلوماتو امنیت دندې لیست کوو:
- د پټنوم مدیریت پالیسیو شتون؛
- د بهرني تصدیق کولو وسیلو سره د نښلولو وړتیا (LDAP، Kerberos)؛
- د لاسرسي رول ماډل؛
- د پلټنې وړتیاوې؛
- په ډیسک کې د معلوماتو کوډ کول؛
- په شبکه کې د لیږد پرمهال کوډ کول (TLS)؛
- د مدیر څخه د معلوماتو ساتنه.
ټیسټروواونی производительности
په جلا توګه ، زه غواړم د هر ډول بار ازموینې پایلو کارولو پروړاندې خبرداری ورکړم چې ستاسو لخوا د دلیل په توګه ندي رامینځته شوي.
لومړی ، د ازمول شوي غوښتنلیکونو ډیټا جوړښت او بار پروفایل ممکن د هغه ستونزې څخه د پام وړ توپیر ولري چې تاسو یې حل کوئ. شاوخوا 10-15 کاله دمخه، د ډیټابیس پلورونکي د TPC ازموینو کې لاسته راوړنې پایلې خوښوي، مګر اوس داسې ښکاري چې هیڅوک دا پایلې په جدي توګه نه اخلي.
دوهم، د سیسټم فعالیت خورا په کلکه پورې اړه لري چې کوډ په اصل کې د کوم پلیټ فارم لپاره لیکل شوی و او په کوم تجهیزاتو کې ازموینه ترسره شوې. ما ډیری ازموینې لیدلي چیرې چې اوریکل د PostgreSQL سره پرتله شوی. پایلې د یو سیسټم د غیر مشروط برتری څخه د بل غیر مشروط برتری تر مساوي حد پورې اړه لري.
او په نهایت کې ، دریم ، تاسو پدې اړه هیڅ نه پوهیږئ چې چا ازموینه کړې. دواړه وړتیاوې مهمې دي، د OS او پلیټ فارم ترتیب کولو کیفیت اغیزه کوي، او همدارنګه هڅونه، کوم چې د نورو ټولو فکتورونو په پرتله د ازموینې پایلې اغیزمنوي.
که فعالیت یو مهم فاکتور وي ، ازموینه پخپله ترسره کړئ ، په غوره توګه د خلکو په مرسته چې د تولید سیسټم تنظیم او ساتي.
نتيجه
په نهایت کې، د ټولو ترسره شویو کارونو پایله باید یو سپریڈ شیټ وي چیرې چې ټول اټکلونه یوځای شوي، ضرب شوي او لنډیز شوي دي:
لکه څنګه چې تاسو پوهیږئ، د ترازو بدلولو او د درجه بندي تنظیم کولو سره تاسو کولی شئ هره مطلوبه پایله ترلاسه کړئ، مګر دا یو بشپړ مختلف کیسه ده ...
سرچینه: www.habr.com