قالت بصوت عالٍ دون أن تخاطب أحداً: "هذا ضروري". - هذا مهم! هذا هو بالضبط ما يقوله: المهمة الرئيسية للشركة هي تحقيق الربح لصالح المساهمين. التفكير جيدا حول هذا الموضوع! إنهم لا يخافون من أي شيء!
يولي دوبوف، "أهون الشرين"
بعد أن رأيت مثل هذا العنوان، ربما تكون قد قررت بالفعل أن المقال إما غباء أو استفزاز. لكن لا تتعجل في الاستنتاجات: غالبًا ما يتعين على موظفي الشركات الكبيرة، وخاصة الشركات التي تشارك فيها الدولة، مقارنة منصات مختلفة، بما في ذلك منصات مختلفة تمامًا - على سبيل المثال، تلك الموجودة في العنوان.
وبطبيعة الحال، لا أحد يقارن أنظمة إدارة قواعد البيانات بهذه الطريقة، لأن نقاط القوة والضعف فيها معروفة جيدا. كقاعدة عامة، تخضع الأنظمة الأساسية التي تحل بعض مشكلات التطبيق للمقارنة. سأعرض في المقالة المنهجية المستخدمة في هذه الحالة، باستخدام مثال قواعد البيانات كموضوع مألوف لقراء حبر بشكل مباشر. لذا،
حافز
عندما تبدأ مشروعًا تعليميًا أو هواية، يمكن أن يكون الدافع لاختيار منصة متنوعة جدًا: "هذه هي المنصة التي أعرفها أفضل"، "أنا مهتم بفهم هذا"، "إليك أفضل التوثيق" ... في حالة شركة تجارية، معيار الاختيار هو نفسه: كم سأدفع وما الذي سأحصل عليه مقابل هذه الأموال.
بطبيعة الحال، تريد أن تدفع أقل وتحصل على المزيد. ومع ذلك، عليك أن تقرر ما هو الأكثر أهمية - دفع أقل أو الحصول على المزيد، وتعيين وزن لكل عقدة. لنفترض أن الحل عالي الجودة أكثر أهمية بالنسبة لنا من الحل الرخيص، ونخصص وزنًا بنسبة 40% لعقدة "التكلفة"، و60% لعقدة "الفرص".
في الشركات الكبيرة، عادة ما يكون العكس صحيحا - وزن التكلفة لا يقل عن 50٪، وربما أكثر من 60٪. في مثال النموذج، كل ما هو مهم هو أن الوزن الإجمالي للعقد الفرعية لأي عقدة أصلية يجب أن يكون 100%.
شروط القطع
موقع هناك حوالي 500 نظام معروف لإدارة قواعد البيانات. بطبيعة الحال، إذا اخترت منصة مستهدفة من بين العديد من الخيارات، فقد ينتهي بك الأمر بمقالة مراجعة، ولكن ليس بمشروع تجاري. ومن أجل تقليص مساحة الاختيار، يتم صياغة معايير قطعية، وإذا كانت المنصة لا تستوفي هذه المعايير، فلا يتم النظر فيها.
قد تتعلق معايير القطع بالميزات التكنولوجية، على سبيل المثال:
- ضمانات ACID؛
- نموذج البيانات العلائقية؛
- دعم لغة SQL (لاحظ أن هذا ليس مثل "النموذج العلائقي")؛
- إمكانية التحجيم الأفقي.
قد تكون هناك معايير عامة:
- توافر الدعم التجاري في روسيا؛
- مفتوح المصدر؛
- توفر المنصة في سجل وزارة الاتصالات والإعلام؛
- وجود النظام الأساسي في بعض التصنيفات (على سبيل المثال، في المائة الأولى من تصنيف db-engines.com)؛
- وجود خبراء في السوق (على سبيل المثال، بناءً على نتائج البحث عن اسم المنصة في السيرة الذاتية على موقع hh.ru).
بعد كل شيء، قد تكون هناك معايير خاصة بالمؤسسة:
- توافر المتخصصين في الموظفين؛
- التوافق مع نظام المراقبة X أو نظام النسخ الاحتياطي Y، والذي يعتمد عليه كل الدعم...
الشيء الأكثر أهمية هو أن هناك قائمة بمعايير القطع. بخلاف ذلك، سيكون هناك بالتأكيد بعض الخبراء (أو "الخبير") الذي يتمتع بثقة خاصة من الإدارة والذي سيقول "لماذا لم تختار المنصة Z، أعلم أنها الأفضل".
تقدير التكلفة
من الواضح أن تكلفة الحل تتكون من تكلفة التراخيص وتكلفة الدعم وتكلفة المعدات.
إذا كانت الأنظمة من نفس الفئة تقريبًا (على سبيل المثال، Microsoft SQL Server وPostgreSQL)، فمن أجل البساطة يمكننا افتراض أن كمية المعدات لكلا الحلين ستكون هي نفسها تقريبًا. سيسمح لك ذلك بعدم تقييم المعدات، وبالتالي توفير الكثير من الوقت والجهد. إذا كان عليك مقارنة أنظمة مختلفة تمامًا (على سبيل المثال، Oracle vs. Redis)، فمن الواضح أنه من أجل التقييم الصحيح، من الضروري إجراء التحجيم (حساب كمية المعدات). يعد تحديد حجم نظام غير موجود مهمة غير مرغوب فيها للغاية، لذلك ما زالوا يحاولون تجنب مثل هذه المقارنات. من السهل القيام بذلك: في ظروف القطع، تتم كتابة فقدان البيانات الصفري ونموذج علائقي، أو العكس - حمولة قدرها 50 ألف معاملة في الثانية.
لتقييم التراخيص، يكفي أن تطلب من البائع أو شركائه تكلفة الترخيص لعدد محدد من النوى والدعم لفترة محددة. كقاعدة عامة، تتمتع الشركات بالفعل بعلاقات قوية مع بائعي البرامج، وإذا لم يتمكن قسم عمليات قاعدة البيانات من الإجابة على سؤال التكلفة بمفرده، فإن حرفًا واحدًا يكفي للحصول على هذه المعلومات.
قد يكون لدى البائعين المختلفين مقاييس ترخيص مختلفة: حسب عدد النوى أو حجم البيانات أو عدد العقد. يمكن أن تكون القاعدة الاحتياطية مجانية، أو يمكن ترخيصها بنفس طريقة ترخيص القاعدة الرئيسية. إذا تم اكتشاف أي اختلافات في المقاييس، فسيتعين عليك وصف الحامل النموذجي بالتفصيل وحساب تكلفة تراخيص الحامل.
نقطة مهمة للمقارنة الصحيحة هي نفس شروط الدعم. على سبيل المثال، يكلف دعم Oracle 22% من سعر الترخيص سنويًا، ولكن لا يتعين عليك الدفع مقابل دعم PostgreSQL. فهل تصح المقارنة بهذه الطريقة؟ لا، لأن الخطأ الذي لا يمكن إصلاحه بمفردك له عواقب مختلفة تمامًا: في الحالة الأولى، سيساعدك متخصصو الدعم في إصلاحه بسرعة، ولكن في الحالة الثانية، هناك خطر تأخير المشروع أو توقف المشروع النهائي النظام لمدة غير محددة.
يمكنك مساواة شروط الحساب بثلاث طرق:
- استخدم Oracle بدون دعم (في الواقع هذا لا يحدث).
- قم بشراء الدعم لـ PostgreSQL - على سبيل المثال، من Postgres Professional.
- خذ في الاعتبار المخاطر المرتبطة بنقص الدعم.
على سبيل المثال، قد يبدو حساب المخاطر كما يلي: في حالة حدوث فشل فادح في قاعدة البيانات، سيكون وقت تعطل النظام هو يوم عمل واحد. الربح المتوقع من استخدام النظام هو 1 مليار طن سنويا، ويقدر معدل الحوادث بـ 40/1، وبالتالي فإن خطر نقص الدعم يقدر بنحو 400 مليون طن سنويا. ومن الواضح أن "الربح المخطط" و"تكرار الحوادث المقدر" هما قيمتان افتراضيتان، ولكن وجود مثل هذا النموذج أفضل كثيراً من عدم وجود أي نموذج منه.
في الواقع، قد يكون النظام مهمًا للغاية بحيث لا تكون تكلفة السمعة الناتجة عن التوقف طويل الأمد مقبولة، لذلك سيكون الدعم مطلوبًا. إذا سمح بالتوقف عن العمل، فإن رفض الدعم يمكن أن يكون في بعض الأحيان طريقة جيدة لتوفير المال.
لنفترض أنه بعد كل الحسابات، تبلغ تكلفة منصة التشغيل A لمدة 5 سنوات 800 مليون MNT، وتكلفة منصة التشغيل B 650 مليون MNT، وتكلفة منصة التشغيل C 600 مليون MNT. تحصل المنصة C، باعتبارها الفائز، على نقطة كاملة مقابل السعر، بينما تحصل المنصة A وB على نقطة أقل قليلاً، بما يتناسب مع عدد المرات التي تكون فيها أكثر تكلفة. في هذه الحالة – 0.75 و 0.92 نقطة على التوالي.
تقييم الفرص
ينقسم تقييم الفرص إلى عدة مجموعات، يقتصر عددها فقط على خيال الشخص الذي يقوم بالتقييم. ويبدو أن الخيار الأمثل هو تقسيم القدرات إلى فرق تستخدم هذه القدرات؛ في مثالنا، هؤلاء هم المطورون والمسؤولون ومسؤولو أمن المعلومات. لنفترض أن أوزان هذه الوظائف موزعة على النحو التالي: 40:40:20.
تشمل وظائف التطوير ما يلي:
- سهولة معالجة البيانات؛
- التحجيم؛
- وجود المؤشرات الثانوية.
قائمة المعايير، وكذلك أوزانها، ذاتية للغاية. حتى عند حل نفس المشكلة، ستختلف هذه القوائم وأوزان العناصر والإجابات بشكل كبير اعتمادًا على تكوين فريقك. على سبيل المثال، يستخدم Facebook MySQL لتخزين البيانات، بينما يعتمد Instagram على Cassandra. ومن غير المرجح أن يقوم مطورو هذه التطبيقات بملء مثل هذه الجداول. لا يمكن للمرء إلا أن يخمن أن مارك زوكربيرج اختار نموذجًا علائقيًا كاملاً، ودفع ثمنه من خلال الحاجة إلى التقسيم المطبق، في حين قام كيفن سيستروم ببناء التوسع باستخدام المنصة، مع التضحية بسهولة الوصول إلى البيانات.
تشمل وظائف الإدارة ما يلي:
- قدرات نظام النسخ الاحتياطي.
- سهولة المراقبة
- سهولة إدارة القدرات – الأقراص والعقد؛
- قدرات نسخ البيانات.
يرجى ملاحظة أنه يجب صياغة الأسئلة بطريقة كمية. يمكنك حتى الاتفاق على كيفية تقييم وظيفة معينة. دعونا، على سبيل المثال، نحاول تقييم أدوات النسخ الاحتياطي باستخدام مثال الأدوات المتوفرة مع Oracle DBMS:
أداة
تعليق
تقييم
عفريت/Exp
تحميل وتحميل البيانات
0.1
بدء/إنهاء النسخ الاحتياطي
نسخ الملفات
0.3
RMAN
إمكانية النسخ التزايدي
0.7
ZDLRA
النسخ المتزايد فقط، وأسرع انتعاش إلى النقطة
1.0
إذا لم تكن هناك معايير تقييم واضحة، فمن المنطقي أن نطلب من العديد من الخبراء إعطاء التقييمات ثم متوسطها.
وأخيرًا، نقوم ببساطة بإدراج وظائف أمن المعلومات:
- مدى توفر سياسات إدارة كلمة المرور؛
- القدرة على ربط أدوات المصادقة الخارجية (LDAP، Kerberos)؛
- نموذج يحتذى به للوصول؛
- قدرات التدقيق؛
- تشفير البيانات الموجودة على القرص؛
- التشفير أثناء النقل عبر الشبكة (TLS)؛
- حماية البيانات من المسؤول.
اختبار أداء
بشكل منفصل، أود أن أحذر من استخدام نتائج أي اختبارات تحميل لم تقم أنت بإجرائها كوسائط.
أولاً، قد تختلف بنية البيانات وملف تعريف التحميل للتطبيقات التي يتم اختبارها بشكل كبير عن المشكلة التي ستقوم بحلها. منذ حوالي 10 إلى 15 عامًا، كان بائعو قواعد البيانات يحبون التباهي بالنتائج التي تم تحقيقها في اختبارات TPC، ولكن الآن يبدو أنه لا أحد يأخذ هذه النتائج على محمل الجد.
ثانيًا، يعتمد أداء النظام بشكل كبير على النظام الأساسي الذي تم كتابة الكود من أجله في الأصل وعلى المعدات التي تم إجراء الاختبار عليها. لقد رأيت العديد من الاختبارات التي تمت فيها مقارنة Oracle بـ PostgreSQL. وتتراوح النتائج من التفوق غير المشروط لنظام واحد إلى التفوق غير المشروط على قدم المساواة لنظام آخر.
وأخيرًا، ثالثًا، أنت لا تعرف شيئًا عن من أجرى الاختبار. كلا المؤهلين مهمان، حيث يؤثران على جودة إعداد نظام التشغيل والمنصة، بالإضافة إلى الدافع، الذي يؤثر على نتائج الاختبار أكثر من جميع العوامل الأخرى مجتمعة.
إذا كان الأداء عاملاً حاسماً، فقم بإجراء الاختبار بنفسك، ويفضل أن يكون ذلك بمساعدة الأشخاص الذين سيقومون بتكوين نظام الإنتاج وصيانته.
نتيجة
أخيرًا، يجب أن تكون نتيجة كل العمل المنجز عبارة عن جدول بيانات يتم فيه دمج جميع التقديرات وضربها وتلخيصها:
كما تفهم، من خلال تغيير المقاييس وضبط التصنيفات، يمكنك تحقيق أي نتيجة مرغوبة، ولكن هذه قصة مختلفة تمامًا...
المصدر: www.habr.com