شراء حساب Google Cloud: ما هو الفرق بين GCP Cloud SQL و MySQL ذاتية البناء ؟

في السنوات الأخيرة ، عند اختيار الهندسة المعمارية أو نقل السحابة ، كانت هناك مشكلة لا يمكن تجنبها تقريبًا:

هل تريد استخدام GCP Cloud SQL مباشرة من Google Cloud ، أو إنشاء MySQL على الجهاز الظاهري Compute Engine (GCE) بنفسك ؟

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

نحن نتحول مباشرة إلى "المحاسبة الذكية"

، من

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

1. النسخ الاحتياطي التلقائي: "البناء الذاتي" الذي يبدو مجانيًا ، كل ذلك خلف تكاليف التخفي

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

1. MySQL المبنية ذاتيًا: يبدو أنها توفر المال ، لكنها في الواقع "صدمت خطوة بخطوة"

في الجهاز الظاهري ، النسخ الاحتياطي ليس جملة

Mysqldump

يمكن حلها بشكل مثالي:

تكاليف البحث والتطوير والاختبار: تحتاج إلى كتابة نصوص Shell بنفسك وإعداد نسخ احتياطية منتظمة لمهام Cron. من أجل عدم التأثير على الأداء عبر الإنترنت ، عليك دراسة ما إذا كنت تريد إجراء نسخ احتياطي فعلي (Percona XtraBackup) أو النسخ الاحتياطي المنطقي.

تكلفة التخزين والنقل: لا يمكن وضع الملف الذي تم نسخه احتياطيًا على القرص المحلي (في حالة توقف الجهاز بالكامل) ، يجب عليك تمريره إلى تخزين كائن GCP Object Storage (GCS) من خلال البرنامج النصي. خلال هذه الفترة ، سيتم إنشاء رسوم تدفق النطاق الترددي للشبكة الداخلية ورسوم تخزين GCS.

أغلى تكلفة (اختبار الاسترداد): لا يعني نجاح النسخ الاحتياطي أنه يمكن استردادها بنجاح. يجب عليك اختبار سلامة ملف النسخ الاحتياطي بشكل منتظم. كل ما يتم استهلاكه هنا هو ساعات العمل للمهندسين ذوي الأجور المرتفعة.

2. GCP Cloud SQL: إنفاق المال لشراء راحة البال

في Cloud SQL ، يصبح النسخ الاحتياطي "خيار علامة" على الواجهة الرسومية:

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

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

سجل Point-in-Time Recovery: يدعم العودة إلى أي ثانية في الأيام السبعة الماضية. يتطلب هذا النوع من "دواء الندم" عتبة فنية عالية للغاية إذا تم بناؤه ذاتيًا.

💡دفتر الأستاذ 1 (بُعد النسخ الاحتياطي): البناء الذاتي: وفر قسط الخدمة ، ولكن يجب خصم المهندس 2-4 ساعات كل شهر لكتابة البرامج النصية ، والحفاظ على خادم النسخ الاحتياطي ، والتعامل مع الإنذارات التي فشلت في النسخ الاحتياطي. Cloud SQL: ادفع أكثر قليلاً من رسوم تخزين النسخ الاحتياطي المخصصة كل شهر ، مقابل 0 تدخل يدوي وقدرة استرداد ثانية في أي وقت.

2. عالية قابلة للاستخدام (HA): "الكابوس النهائي" الذي تم بناؤه ذاتيًا

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

1. ارتفاع توافر MySQL المبنية ذاتيًا: تسعة وفيات

لتنفيذ بنية السيد والعبد الحقيقي (Master-Slave) وتبديل الخطأ التلقائي (Failover) على جهاز افتراضي ، تحتاج عادةً إلى:

شراء ما لا يقل عن اثنين (أو حتى ثلاثة) من الأجهزة الافتراضية.

تكوين النسخ المتماثل غير المتزامن/شبه المتزامن لـ MySQL لحل مشكلة تناسق البيانات.

تقديم أدوات طرف ثالث (مثل Orchestrator أو MHA أو Keepalived VIP) للكشف عن ضربات القلب وتبديل الأخطاء.

نقطة الألم الأساسية: عندما تتعجل المكتبة الرئيسية فجأة ، كيف يمكن ضمان عدم فقد البيانات (RPO = 0) في لحظة التبديل ؟ كيف يتعرف التطبيق تلقائيًا على عنوان IP الأساسي الجديد ؟

بعد هذه المجموعة من اللكمات ، لا يوجد DBA كبير (مسؤول قاعدة البيانات) يجلس ، ومن المرجح أن "تنقلب" HA التي يبنونها في لحظة حرجة.

2. GCP Cloud SQL عالية المتاحة: فتح بنقرة واحدة

في Cloud SQL ، يتم تبسيط عالية قابلة للاستخدام إلى مربع واحد:

”High Availability (Regional)“

.

منطقها الأساسي صعب للغاية:

سيقوم GCP بسحب مثيل رئيسي ومثال احتياطي في منطقتين مختلفتين من نفس المنطقة.

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

بمجرد حدوث زلزال أو انقطاع التيار الكهربائي في منطقة الاستخدام الرئيسية ، ستتحول Cloud SQL تلقائيًا إلى منطقة الاستخدام البديلة في غضون 60 ثانية ، وسيظل عنوان IP الخاص بالمثيل دون تغيير تمامًا ، ولا يحتاج تطبيقك حتى إلى إعادة التشغيل. تحتاج فقط إلى تكوين آلية إعادة الاتصال.

💡دفتر الأستاذ الثاني (البعد العالي المتاح): تكلفة HA المبنية ذاتيًا: 2 دولارًا أمريكيًا رسوم الجهاز الظاهري ، وقت تصحيح الأخطاء لعدد كبير من البنى المعقدة ، لا يمكن ضمان منطق التبديل الموثوق به بنسبة 100 ٪ $. تكلفة Cloud SQL HA: يتضاعف السعر مباشرة على أساس الإصدار الفردي (لأن الخلفية تدير بالفعل مجموعتين من الموارد). الخلاصة: إذا سمح نشاطك التجاري لعدة ساعات من وقت التوقف ، فإن إنشاء جهاز واحد هو الأكثر فعالية من حيث التكلفة ؛ إذا تم تعليق عملك لمدة 5 دقائق ، فسيتم خصم المال ، والسعر المزدوج لـ Cloud SQL هو بالتأكيد أكثر فعالية من حيث التكلفة من HA الخاص بك.

3. التسوية النهائية: مقارنة الأموال الحقيقية

من أجل أن يكون لديك شعور بديهي ، نستخدم أرقامًا محددة لحساب حساب.

لنفترض أننا بحاجة إلى قاعدة بيانات متوسطة الحجم:

4 النواة/16GB الذاكرة ، 200GB SSD القرص الصلب ، وتقع في منطقة هونغ كونغ.

(الأسعار التالية هي تقديرات ، على وجه التحديد مع GCP Pri في الوقت الحقيقي

Ce Calculator يسود).

الخيار أ: البناء الذاتي (GCE Virtual Machine)

موارد الحوسبة: جهاز افتراضي e2-standard-4 ، حوالي 100 دولار/شهر.

موارد التخزين: قرص صلب SSD جزئي بسعة 200 جيجابايت ، حوالي 34 دولارًا في الشهر.

التكلفة الثابتة لجهاز واحد: ~ 134 دولار/شهر.

(إذا كنت تريد أن تكون متاحة بشكل كبير ، فإن التكلفة تتضاعف مباشرة إلى ~ 268 دولار/شهر).

الخيار باء: الاستضافة (GCP Cloud SQL لـ MySQL)

التطوير: نفس التكوين (4 vCPU ، 16GB ، 200GB SSD) ، حوالي 180 دولار/شهر.

إصدار عالي قابل للاستخدام (Production): نظرًا لأنه تخزين مزدوج عبر المنطقة القابلة للاستخدام ، يبلغ حوالي 330 دولارًا في الشهر.

⚖️ آخر جدول مقارنة شامل

الخصائص/الأبعاد

MySQL (على GCE)

GCP Cloud SQL

تكلفة الأجهزة الأساسية

💰أقل (سعر آلة افتراضية خالصة)

🏷️ أعلى (بما في ذلك علاوة إدارة البرامج)

النسخ الاحتياطي التلقائي بالكامل

🛠️ تحتاج إلى كتابة البرامج النصية ، وإدارة التخزين ، والقياس والاسترداد

⚡فتح بنقرة واحدة ، ودعم الاسترداد في أي وقت

عالية المتاحة (HA)

🤯معقدة للغاية ، تحتاج إلى فهم Master-Slave ، Orchestrator ، إلخ.

🛡️ ضع علامة بنقرة واحدة ، قم بالتبديل التلقائي عبر المستوى الثاني عبر المناطق المتاحة ، ولم يتغير IP

ترقية الإصدار مع التصحيح

⏳الحاجة إلى التوقف اليدوي والترقية للتعامل مع تعارضات التبعية

📅قم بتعيين نافذة الصيانة ، ويقوم النظام تلقائيًا بالترقية بصمت

التكلفة القصوى غير المرئية

ساعات عمل الصيانة اليدوية باهظة الثمن (الأصول الأكثر قيمة)

مبلغ الفواتير التي يمكن التنبؤ بها

4. ملخص: كيف تختار ؟

بعد حساب هذا الحساب ، يكون الاستنتاج واضحًا جدًا في الواقع ، اعتمادًا بشكل أساسي على شركتك

مقياس

و

القوى العاملة

.

حدد بشكل حاسم [GCP Cloud SQL] إذا استوفت الشروط التالية:

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

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

إذا استوفت الشروط التالية ، يمكنك التفكير في [MySQL ذاتية البناء]:

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

هناك متطلبات تخصيص واسعة النطاق: تحتاج إلى تعديل كود مصدر kernel الخاص بـ MySQL ، أو تحتاج إلى استخدام بعض المكونات الإضافية فائقة البرودة ومحركات التخزين الخاصة التي لا تدعمها Cloud SQL.

نصيحة قاسية:

خدمة الاستضافة لا تبيع لك "الخادم" ، بل تبيع لك ** "النوم من القلق" و "ساعات عمل DBA المهنية باهظة الثمن" **

. في مواجهة بيئة الإنتاج ، فإن إنفاق الأموال لشراء الوقت هو دائمًا أعلى معدل ربح.