أيهما أفضل - Oracle أو Redis أو كيفية تبرير اختيار النظام الأساسي

قالت بصوت عال دون أن تخاطب أحداً: "حسنًا ، هذا ضروري". - حسنا هذا ضروري! لذا فهو مكتوب بشكل مباشر - المهمة الرئيسية للشركة هي تحقيق الربح لصالح المساهمين. حسنا ، تعتقد! إنهم لا يخافون من أي شيء!



يوليوس دوبوف ، "الشر الأصغر"


عند رؤية مثل هذا العنوان ، ربما تكون قد قررت بالفعل أن المقالة إما غباء أو استفزاز. ولكن لا تتسرع في الاستنتاجات: موظفو الشركات الكبيرة ، وخاصة الشركات التي تشارك الدولة ، غالبًا ما يضطرون إلى مقارنة المنصات المختلفة ، بما في ذلك المنصات المختلفة تمامًا ، على سبيل المثال ، مثل تلك الموجودة في العنوان.







بالطبع ، لا أحد يقارن DBMS من هذا القبيل ، لأن نقاط القوة والضعف لديهم معروفة جيدًا. كقاعدة ، تخضع المنصات التي تحل مشكلة تطبيقية للمقارنة. في هذه المقالة ، سأعرض التقنية المستخدمة في نفس الوقت ، باستخدام مثال قواعد البيانات كموضوع ليس من خلال الإشاعات المألوفة لقراء هبر. وبالتالي،



التحفيز



عندما تبدأ مشروعًا تعليميًا أو مشروعًا للهواية ، يمكن أن يكون الدافع لاختيار منصة متنوعة جدًا: "أعرف هذه المنصة أفضل" ، "أنا مهتم بفهم هذه المنصة" ، "هنا أفضل الوثائق" ... في حالة الشركة التجارية ، يكون معيار الاختيار واحدًا: كم سأدفع وماذا سأحصل على هذا المال.



بطبيعة الحال ، تريد أن تدفع أقل وتحصل على المزيد. ومع ذلك ، من الضروري تحديد أيهما أكثر أهمية - دفع أقل أو الحصول على المزيد ، وتعيين وزن لكل عقدة. لنفترض أن الحل عالي الجودة هو أكثر أهمية بالنسبة لنا من الحل الرخيص ، ونعين عقدة "التكلفة" بنسبة 40٪ ، وعقدة "الفرص" - 60٪.







في الشركات الكبيرة ، عادة ما يكون العكس هو الحال - لا يقل وزن القيمة عن 50 ٪ ، وربما أكثر من 60 ٪. في مثال النموذج ، من المهم فقط أن يكون الوزن الإجمالي للعقد الفرعية لأي عقدة رئيسية 100٪.



شروط القطع



موقع db-engines.com المعروف بحوالي 500 نظام لإدارة قواعد البيانات. بطبيعة الحال ، إذا اخترت منصة مستهدفة من العديد من الخيارات ، فقد ينتهي بك الأمر بمقال مراجعة ، ولكن ليس مشروعًا تجاريًا. من أجل تقليل مساحة الاختيار ، يتم صياغة معايير القطع ، وإذا لم تستوف المنصة هذه المعايير ، فلن يتم أخذها في الاعتبار.



يمكن أن ترتبط معايير القطع بالميزات التكنولوجية ، على سبيل المثال:



  • ضمانات ACID ؛
  • نموذج البيانات العلائقية
  • دعم لغة SQL (لاحظ أن هذا ليس مثل "النموذج العلائقي") ؛
  • إمكانية التحجيم الأفقي.


قد تكون هناك معايير عامة:



  • توافر الدعم التجاري في روسيا ؛
  • مصدر مفتوح
  • توفر المنصة في سجل وزارة الاتصالات والإعلام.
  • وجود النظام الأساسي في بعض التصنيفات (على سبيل المثال ، في أول مائة من تصنيف db-engines.com) ؛
  • توافر الخبراء في السوق (على سبيل المثال ، بناءً على نتائج البحث عن اسم المنصة في السيرة الذاتية على موقع hh.ru).


بعد كل شيء ، قد تكون هناك معايير خاصة بالمؤسسات:



  • توافر المتخصصين في الموظفين ؛
  • التوافق مع نظام المراقبة X أو مع نظام النسخ الاحتياطي Y ، الذي ترتبط به جميع عمليات الصيانة ...


الشيء الأكثر أهمية هو أن يكون لديك قائمة بمعايير القطع. خلاف ذلك ، سيكون هناك بالتأكيد بعض الخبراء (أو "الخبراء") الذين يتمتعون بالثقة الخاصة للإدارة ، الذين سيقولون "لماذا لم تختر المنصة Z ، وأنا أعلم أنها الأفضل."



تقدير التكلفة



من الواضح أن تكلفة الحل تتكون من تكلفة التراخيص وتكلفة الصيانة وتكلفة المعدات.



إذا كانت الأنظمة من نفس الفئة تقريبًا (على سبيل المثال ، Microsoft SQL Server و PostgreSQL) ، فمن أجل البساطة ، يمكننا أن نفترض أن كمية المعدات لكلا الحلين ستكون هي نفسها تقريبًا. سيسمح لك ذلك بعدم تقييم المعدات ، وبالتالي توفير الكثير من الوقت والجهد. إذا كان عليك مقارنة أنظمة مختلفة تمامًا (على سبيل المثال ، Oracle مقابل. Redis) ، فمن الواضح أنه من أجل التقييم الصحيح ، من الضروري إجراء التحجيم (حساب كمية المعدات). يعد تحديد حجم نظام غير موجود مهمة شائنة للغاية ، لذلك ما زالوا يحاولون تجنب مثل هذه المقارنة. من السهل القيام بذلك: فقدان بيانات صفر ونموذج علائقي مكتوب في ظروف القطع ، أو العكس - حمولة 50 ألف معاملة في الثانية.



لتقييم التراخيص ، يكفي أن تطلب من البائع أو شركائه تكلفة الترخيص لعدد ثابت من النوى والدعم لفترة محددة. كقاعدة عامة ، تتمتع الشركات بالفعل بعلاقات قوية مع موردي البرامج ، وإذا لم يتمكن قسم تشغيل قاعدة البيانات من الإجابة على سؤال التكلفة بمفرده ، فعندئذٍ يكفي حرف واحد لتلقي هذه المعلومات.



قد يكون لدى البائعين المختلفين مقاييس ترخيص مختلفة: حسب عدد النوى أو كمية البيانات أو عدد العقد. يمكن أن تكون قاعدة البيانات الاحتياطية مجانية ، أو يمكن أن تكون مرخصة بنفس الطريقة مثل قاعدة البيانات الرئيسية. إذا تم العثور على بعض الاختلافات في المقاييس فقط ، فسيتعين عليك وصف الحامل النموذجي بالتفصيل وحساب تكلفة التراخيص للحامل.



نقطة مهمة للمقارنة الصحيحة هي نفس شروط الدعم. على سبيل المثال ، يكلف دعم Oracle 22٪ من سعر الترخيص سنويًا ، ولا يكلف دعم PostgreSQL أي شيء. هل صحيح للمقارنة؟ لا ، لأن الخطأ الذي لا يمكن إزالته بمفردنا له عواقب مختلفة تمامًا: في الحالة الأولى ، سيساعد متخصصو الدعم بسرعة في إصلاحه ، وفي الحالة الثانية ، هناك خطر تأخير المشروع أو توقف النظام النهائي لفترة غير محددة.



هناك ثلاث طرق لموازنة شروط الحساب:



  1. استخدم Oracle بدون دعم (في الواقع ، هذا لا يحدث).
  2. شراء دعم PostgreSQL - على سبيل المثال ، من Postgres Professional.
  3. أدرج المخاطر المرتبطة بنقص الدعم.


على سبيل المثال ، قد يبدو حساب المخاطر كما يلي: في حالة حدوث فشل فادح في قاعدة البيانات ، سيكون وقت تعطل النظام يوم عمل واحد. الربح المخطط من استخدام النظام هو 40 مليار من الغوغرات المنغولية في السنة ، ويقدر تكرار الحوادث بنحو 1/400 ، وبالتالي ، يُقدر خطر نقص الدعم بحوالي 100 مليون من الغوغر المنغولي في السنة. من الواضح أن "الربح المخطط" و "معدل الحوادث المقدر" هما كميتان افتراضيتان ، ولكن من الأفضل أن يكون لديك مثل هذا النموذج من عدم وجود أي نموذج.



في الواقع ، قد يكون النظام مهمًا للغاية ، ولن تكون خسائر السمعة الناتجة عن فترات التعطل الطويلة مقبولة ، لذلك سيكون الدعم مطلوبًا. إذا كان وقت التوقف عن العمل مسموحًا به ، فقد يكون إسقاط الدعم في بعض الأحيان طريقة جيدة لتوفير المال.



لنفترض أنه بعد كل الحسابات ، تبين أن تكلفة منصة التشغيل A لمدة 5 سنوات بلغت 800 مليون توغري منغولي ، وتكلفة منصة التشغيل B - 650 مليون توغريك ، وتكلفة منصة التشغيل C - 600 مليون توغريك. النظام الأساسي C ، كفائز ، يتلقى نقطة الوزن الكامل للتكلفة ، والمنصات A و B - أقل قليلاً ، بما يتناسب مع عدد المرات التي تكون فيها أكثر تكلفة. في هذه الحالة - 0.75 و 0.92 نقطة على التوالي.



تقييم الفرص



ينقسم تقييم الفرص إلى العديد من المجموعات ، وعددها محدود فقط بخيال الشخص الذي يقوم بالتقييم. يبدو أن الخيار الأفضل هو تقسيم القدرات إلى فرق تستخدم هذه القدرات ؛ في مثالنا ، هؤلاء هم المطورين والإداريين وضباط أمن المعلومات. لنفترض أن أوزان هذه الوظائف يتم توزيعها على النحو 40:40:20.



تشمل وظائف التطوير ما يلي:



  • سهولة معالجة البيانات ؛
  • التحجيم
  • وجود فهارس ثانوية.


قائمة المعايير ، مثل أوزانهم ، ذاتية للغاية. حتى عند حل نفس المشكلة ، ستختلف هذه القوائم وأوزان العناصر والإجابات بشكل كبير اعتمادًا على تكوين فريقك. على سبيل المثال ، يستخدم Facebook MySQL لتخزين البيانات ، ويتم إنشاء Instagram فوق كاساندرا. من غير المحتمل أن يقوم مطورو هذه التطبيقات بملء هذه الجداول. يمكن للمرء أن يخمن فقط أن مارك زوكربيرج اختار نموذجًا علائقيًا كاملًا ، ودفع مقابل ذلك مع الحاجة إلى التقسيم التطبيقي ، في حين وضع كيفن سيستروم التوسع من خلال المنصة ، ضحى براحة الوصول إلى البيانات.



تشمل وظائف الإدارة ما يلي:



  • قدرات نظام النسخ الاحتياطي.
  • سهولة المراقبة ؛
  • راحة إدارة السعة - الأقراص والعقد ؛
  • قدرات نسخ البيانات.


يرجى ملاحظة أن صياغة الأسئلة يجب أن تكون قابلة للقياس الكمي. يمكنك حتى الاتفاق على كيفية تقييم وظيفة معينة. دعنا ، على سبيل المثال ، نحاول تقييم أدوات النسخ الاحتياطي باستخدام مثال الأدوات المتوفرة مع Oracle DBMS:



أداة تعليق تقدير
عفريت / exp تحميل وتنزيل البيانات 0.1
بدء / إنهاء النسخ الاحتياطي نسخ الملفات 0.3
رمان إمكانية النسخ التزايدي 0.7
ZDLRA نسخة متزايدة فقط ، أسرع انتعاش إلى نقطة 1.0


إذا لم تكن هناك معايير تقييم واضحة ، فمن المنطقي أن تطلب من عدة خبراء وضع علامات ثم تحديدها.



أخيرًا ، دعنا نسرد فقط ميزات أمان المعلومات:



  • توفر سياسات إدارة كلمة المرور ؛
  • القدرة على ربط أدوات المصادقة الخارجية (LDAP ، Kerberos) ؛
  • قدوة للوصول
  • ;
  • ;
  • (TLS);
  • .




بشكل منفصل ، أود أن أحذر من استخدام نتائج أي اختبارات تحميل لم تقم بها كحجج.



أولاً ، قد يختلف هيكل البيانات وملف تعريف تحميل التطبيقات قيد الاختبار بشكل كبير عن المهمة التي ستقوم بحلها. منذ حوالي 10-15 عامًا ، أحب بائعو قواعد البيانات التباهي بنتائج TPC المعيارية ، ولكن يبدو الآن أنه لا أحد يأخذ هذه النتائج على محمل الجد.



ثانيًا ، يعتمد أداء النظام بشدة على النظام الأساسي الذي تم كتابة الرمز من أجله أصلاً وعلى الأجهزة التي تم إجراء الاختبار بها. لقد رأيت العديد من المعايير التي تقارن Oracle إلى PostgreSQL. تتراوح النتائج من التفوق غير المشروط لنظام ما إلى التفوق غير المشروط لنظام آخر.



وأخيرًا ، ثالثًا ، أنت لا تعرف شيئًا عن من أجرى الاختبار. كلا المؤهلين ، اللذين يؤثران على جودة نظام التشغيل وتخصيص النظام الأساسي ، مهمان ، بالإضافة إلى التحفيز ، مما يؤثر على نتائج الاختبار أكثر من جميع العوامل الأخرى مجتمعة.



إذا كان الأداء عاملاً بالغ الأهمية ، فقم بإجراء الاختبار بنفسك ، ويفضل أن يكون ذلك بمساعدة المتخصصين الذين سيقومون بتكوين نظام الإنتاج والحفاظ عليه.



نتيجة



أخيرًا ، يجب أن تكون نتيجة كل العمل المنجز جدول بيانات ، حيث يتم جمع جميع التقديرات معًا وضربها وتلخيصها:







كما تفهم ، من خلال تغيير الأوزان وتعديل التقديرات ، يمكنك تحقيق أي نتيجة مرغوبة ، لكن هذه قصة مختلفة تمامًا ...



All Articles