کدام بهتر است - Oracle یا Redis یا نحوه توجیه انتخاب پلتفرم

او با صدای بلند گفت: "این لازم است." - این لازمه! این دقیقاً همان چیزی است که می گوید: وظیفه اصلی یک شرکت کسب سود به نفع سهامداران است. خوب، در مورد آن فکر کنید! آنها از هیچ چیز نمی ترسند!

یولی دوبوف، «شیطان کوچکتر»

با دیدن چنین تیتری، احتمالاً قبلاً به این نتیجه رسیده اید که مقاله یا حماقت است یا یک تحریک. اما در نتیجه گیری عجله نکنید: کارمندان شرکت های بزرگ، به ویژه شرکت های با مشارکت دولتی، اغلب مجبورند پلتفرم های مختلف، از جمله پلتفرم های کاملاً متفاوت را با هم مقایسه کنند - به عنوان مثال، آنها در عنوان.

البته هیچکس DBMS ها را به این شکل مقایسه نمی کند، زیرا نقاط قوت و ضعف آن ها به خوبی شناخته شده است. به عنوان یک قاعده، پلتفرم هایی که برخی از مشکلات برنامه را حل می کنند، قابل مقایسه هستند. در مقاله روشی را که در این مورد استفاده می‌شود، با استفاده از مثالی از پایگاه‌های داده به عنوان موضوعی که برای خوانندگان هابر آشنا است، نشان خواهم داد. بنابراین،

انگیزه

هنگامی که یک پروژه آموزشی یا یک پروژه سرگرمی را شروع می کنید، انگیزه برای انتخاب یک پلت فرم می تواند بسیار متنوع باشد: "این پلت فرمی است که من بهتر می دانم"، "من علاقه مند به درک این هستم"، "اینجا بهترین مستندات است" ... در مورد یک شرکت تجاری، معیار انتخاب یکسان است: چقدر باید پرداخت کنم و با این پول چه چیزی دریافت خواهم کرد.

طبیعتاً می خواهید هزینه کمتری بپردازید و بیشتر بگیرید. با این حال، باید تصمیم بگیرید که چه چیزی مهمتر است - پرداخت کمتر یا دریافت بیشتر، و یک وزن به هر گره اختصاص دهید. بیایید فرض کنیم که یک راه حل باکیفیت برای ما مهمتر از یک راه حل ارزان است، و وزنی معادل 40 درصد به گره «هزینه» و 60 درصد به گره «فرصت ها» اختصاص می دهیم.

در شرکت های بزرگ، معمولاً برعکس است - وزن هزینه کمتر از 50٪ و شاید بیش از 60٪ نمی شود. در مثال مدل، تنها چیزی که مهم است این است که وزن کل گره های فرزند هر گره والد باید 100٪ باشد.

شرایط قطع

سایت db-engines.com حدود 500 سیستم مدیریت پایگاه داده شناخته شده است. به طور طبیعی، اگر یک پلتفرم هدف را از بین گزینه های بسیار انتخاب کنید، ممکن است با یک مقاله مروری مواجه شوید، اما نه یک پروژه تجاری. به منظور کاهش فضای انتخاب، معیارهای برش تنظیم می شود و اگر پلت فرم این معیارها را برآورده نمی کند، در نظر گرفته نمی شود.

معیارهای برش ممکن است به ویژگی های تکنولوژیکی مربوط باشد، به عنوان مثال:

• تضمین اسید؛
• مدل داده های رابطه ای;
• پشتیبانی از زبان SQL (توجه داشته باشید، این همان مدل رابطه ای نیست).
• امکان مقیاس بندی افقی

ممکن است معیارهای کلی وجود داشته باشد:

• در دسترس بودن پشتیبانی تجاری در روسیه؛
• متن باز؛
• در دسترس بودن پلت فرم در ثبت وزارت مخابرات و ارتباطات جمعی؛
• حضور پلت فرم در برخی رتبه بندی ها (به عنوان مثال، در صد اول رتبه بندی db-engines.com)؛
• حضور کارشناسان در بازار (به عنوان مثال، بر اساس نتایج جستجوی نام پلت فرم در رزومه در وب سایت hh.ru).

پس از همه، ممکن است معیارهای خاص سازمانی وجود داشته باشد:

• در دسترس بودن متخصصان در کارکنان؛
• سازگاری با سیستم مانیتورینگ X یا سیستم پشتیبان Y که تمامی پشتیبانی ها بر اساس آن است...

مهمترین چیز این است که لیستی از معیارهای برش وجود دارد. در غیر این صورت، قطعاً یک متخصص (یا «متخصص») وجود خواهد داشت که از اعتماد ویژه مدیریت برخوردار است و می‌گوید «چرا پلتفرم Z را انتخاب نکردی، می‌دانم که این بهترین است».

برآورد هزینه

هزینه راه حل بدیهی است که شامل هزینه مجوزها، هزینه پشتیبانی و هزینه تجهیزات است.

اگر سیستم ها تقریباً یک کلاس باشند (مثلاً Microsoft SQL Server و PostgreSQL)، برای سادگی می توانیم فرض کنیم که مقدار تجهیزات برای هر دو راه حل تقریباً یکسان باشد. این به شما امکان می دهد تجهیزات را ارزیابی نکنید و در نتیجه در زمان و تلاش زیادی صرفه جویی کنید. اگر باید سیستم‌های کاملاً متفاوتی را با هم مقایسه کنید (مثلاً اوراکل در مقابل ردیس)، پس بدیهی است که برای ارزیابی صحیح، اندازه‌گیری (محاسبه مقدار تجهیزات) ضروری است. تعیین اندازه یک سیستم موجود کار بسیار ناسپاسی است، بنابراین آنها همچنان سعی می کنند از چنین مقایسه هایی اجتناب کنند. انجام این کار آسان است: در شرایط قطع، از دست دادن داده صفر و یک مدل رابطه ای نوشته می شود، یا برعکس - بار 50 هزار تراکنش در ثانیه.

برای ارزیابی مجوزها، کافی است از فروشنده یا شرکای آن هزینه مجوز برای تعداد هسته ثابت و پشتیبانی برای یک دوره ثابت را بپرسید. به عنوان یک قاعده، شرکت ها قبلاً روابط قوی با فروشندگان نرم افزار دارند و اگر بخش عملیات پایگاه داده نتواند به تنهایی به سؤال هزینه پاسخ دهد، یک حرف برای به دست آوردن این اطلاعات کافی است.

فروشندگان مختلف ممکن است معیارهای صدور مجوز متفاوتی داشته باشند: بر اساس تعداد هسته ها، حجم داده یا تعداد گره ها. پایه آماده به کار می تواند رایگان باشد یا می توان آن را به همان روش اصلی مجوز داد. اگر تفاوتی در معیارها کشف شد، باید مدل پایه را با جزئیات توصیف کنید و هزینه مجوز برای غرفه را محاسبه کنید.

نکته مهم برای مقایسه صحیح همین شرایط پشتیبانی است. به عنوان مثال، پشتیبانی Oracle 22٪ از قیمت مجوز در سال هزینه دارد، اما شما مجبور نیستید برای پشتیبانی PostgreSQL هزینه کنید. آیا مقایسه اینگونه درست است؟ خیر، زیرا خطایی که به تنهایی قابل رفع نیست عواقب کاملاً متفاوتی دارد: در مورد اول، متخصصان پشتیبانی به سرعت به شما کمک می کنند تا آن را برطرف کنید، اما در مورد دوم، خطر تاخیر در پروژه یا خرابی کار تمام شده وجود دارد. سیستم برای مدت نامحدود

شما می توانید شرایط محاسبه را به سه روش یکسان کنید:

1. از Oracle بدون پشتیبانی استفاده کنید (در واقعیت این اتفاق نمی افتد).
2. خرید پشتیبانی برای PostgreSQL - به عنوان مثال، از Postgres Professional.
3. خطرات مرتبط با عدم حمایت را در نظر بگیرید.

به عنوان مثال، یک محاسبه ریسک ممکن است به این صورت باشد: در صورت خرابی مرگبار پایگاه داده، خرابی سیستم 1 روز کاری خواهد بود. سود پیش بینی شده از استفاده از سیستم 40 میلیارد MNT در سال است، میزان تصادف 1/400 برآورد شده است، بنابراین خطر عدم پشتیبانی تقریباً 100 میلیون MNT در سال برآورد می شود. بدیهی است که "سود برنامه ریزی شده" و "تکرار تصادف تخمینی" مقادیر مجازی هستند، اما داشتن چنین مدلی بسیار بهتر از نداشتن آن است.

در واقعیت، سیستم ممکن است برای هزینه‌های اعتباری ناشی از خرابی طولانی‌مدت آنقدر مهم باشد که قابل قبول نباشد، بنابراین پشتیبانی لازم است. اگر زمان توقف مجاز باشد، گاهی اوقات امتناع از پشتیبانی می تواند راه خوبی برای صرفه جویی در هزینه باشد.

فرض کنید پس از تمام محاسبات، هزینه سکوی عملیاتی A برای 5 سال 800 میلیون MNT، هزینه سکوی عملیاتی B 650 میلیون MNT و هزینه سکوی عامل C 600 میلیون MNT باشد. پلتفرم C به عنوان برنده، یک امتیاز کامل به ازای قیمت دریافت می کند، در حالی که پلتفرم های A و B به نسبت چند برابر گرانی، اندکی کمتر دریافت می کنند. در این مورد - به ترتیب 0.75 و 0.92 امتیاز.

ارزیابی فرصت

ارزیابی فرصت‌ها به گروه‌های زیادی تقسیم می‌شود که تعداد آن‌ها تنها با تخیل شخصی که ارزیابی می‌کند محدود می‌شود. به نظر می رسد گزینه بهینه این است که توانایی ها را به تیم هایی تقسیم کنیم که از این قابلیت ها استفاده کنند. در مثال ما، اینها توسعه دهندگان، مدیران و افسران امنیت اطلاعات هستند. فرض کنید وزن این توابع به صورت 40:40:20 توزیع شده است.

توابع توسعه عبارتند از:

• سهولت دستکاری داده ها؛
• پوسته پوسته شدن؛
• وجود شاخص های ثانویه

فهرست معیارها و همچنین وزن آنها بسیار ذهنی است. حتی هنگام حل یک مشکل، این لیست ها، وزن آیتم ها و پاسخ ها بسته به ترکیب تیم شما به طور قابل توجهی متفاوت خواهد بود. به عنوان مثال، فیس بوک از MySQL برای ذخیره داده ها استفاده می کند و اینستاگرام بر روی Cassandra ساخته شده است. بعید است که توسعه دهندگان این برنامه ها چنین جداول را پر کرده باشند. فقط می توان حدس زد که مارک زاکربرگ یک مدل رابطه ای تمام عیار را انتخاب کرد و هزینه آن را با نیاز به اشتراک گذاری کاربردی پرداخت کرد، در حالی که کوین سیستروم با استفاده از پلتفرم مقیاس بندی را ایجاد کرد و سهولت دسترسی به داده ها را قربانی کرد.

وظایف مدیریت عبارتند از:

• قابلیت های سیستم پشتیبان؛
• سهولت نظارت؛
• سهولت مدیریت ظرفیت - دیسک ها و گره ها؛
• قابلیت تکثیر داده ها

لطفاً توجه داشته باشید که سؤالات باید به صورت کمی بیان شوند. حتی می توانید در مورد نحوه ارزیابی یک عملکرد خاص به توافق برسید. برای مثال، بیایید سعی کنیم ابزارهای پشتیبان را با استفاده از مثال ابزارهای ارائه شده با Oracle DBMS رتبه بندی کنیم:

ابزار
توضیح
ارزیابی

imp/exp
بارگذاری و بارگذاری داده ها
0.1

شروع/پایان پشتیبان گیری
کپی کردن فایل ها
0.3

RMAN
قابلیت کپی افزایشی
0.7

ZDLRA
فقط کپی تدریجی، سریعترین بازیابی به نقطه
1.0

اگر معیارهای ارزیابی مشخصی وجود نداشته باشد، منطقی است که از چندین متخصص بخواهید که رتبه بندی کنند و سپس آنها را میانگین گیری کنند.

در نهایت، ما به سادگی توابع امنیت اطلاعات را فهرست می کنیم:

• در دسترس بودن سیاست های مدیریت رمز عبور؛
• توانایی اتصال ابزارهای احراز هویت خارجی (LDAP، Kerberos)؛
• الگوی دسترسی؛
• قابلیت های حسابرسی؛
• رمزگذاری داده ها روی دیسک؛
• رمزگذاری در حین انتقال از طریق شبکه (TLS)؛
• حفاظت از داده ها توسط مدیر

ازمایش عملکرد

به طور جداگانه، من می خواهم در مورد استفاده از نتایج آزمایش های بارگذاری که توسط شما به عنوان استدلال انجام نشده است هشدار دهم.

اولاً، ساختار داده و نمایه بار برنامه های مورد آزمایش ممکن است به طور قابل توجهی با مشکلی که می خواهید حل کنید متفاوت باشد. حدود 10-15 سال پیش، فروشندگان پایگاه داده دوست داشتند نتایج به دست آمده در تست های TPC را به رخ بکشند، اما اکنون، به نظر می رسد، هیچ کس این نتایج را جدی نمی گیرد.

ثانیاً، عملکرد سیستم کاملاً به این بستگی دارد که کد در ابتدا برای چه پلتفرمی نوشته شده است و آزمایش بر روی چه تجهیزاتی انجام شده است. من تست های زیادی را دیده ام که در آن اوراکل با PostgreSQL مقایسه شده است. نتایج از برتری بدون قید و شرط یک سیستم تا برتری بدون قید و شرط سیستم دیگر متغیر است.

و در نهایت، ثالثاً، شما چیزی در مورد اینکه چه کسی آزمایش را انجام داده است، نمی دانید. هر دو صلاحیت مهم هستند و بر کیفیت راه‌اندازی سیستم‌عامل و پلتفرم و همچنین انگیزه تأثیر می‌گذارند که بیش از همه عوامل دیگر روی نتایج آزمایش تأثیر می‌گذارد.

اگر عملکرد یک عامل حیاتی است، آزمایش را خودتان انجام دهید، ترجیحاً با کمک افرادی که سیستم تولید را پیکربندی و نگهداری می کنند.

نتیجه

در نهایت، نتیجه تمام کارهای انجام شده باید یک صفحه گسترده باشد که در آن همه برآوردها ترکیب، ضرب و خلاصه شوند:

همانطور که می دانید، با تغییر مقیاس ها و تنظیم رتبه ها می توانید به هر نتیجه دلخواه برسید، اما این یک داستان کاملا متفاوت است...

منبع: www.habr.com