مرحبًا سكان خابروفسك. تبدأ اليوم دروس المجموعة الأولى من الدورة . وفي هذا الصدد، نود أن نخبركم عن كيفية عقد الندوة المفتوحة عبر الإنترنت حول هذه الدورة.
В تحدثنا عن التحديات التي تواجهها قواعد بيانات SQL في عصر السحابة وKubernetes. وفي الوقت نفسه، نظرنا في كيفية تكيف قواعد بيانات SQL وتحولها تحت تأثير هذه التحديات.
تم عقد الندوة عبر الإنترنت ، مدير تسليم ممارسة Google Cloud في EPAM Systems.
عندما كانت الأشجار صغيرة...
أولا، دعونا نتذكر كيف بدأ اختيار نظام إدارة قواعد البيانات (DBMS) في نهاية القرن الماضي. ومع ذلك، لن يكون هذا صعبا، لأن اختيار نظام إدارة قواعد البيانات في تلك الأيام بدأ وانتهى Oracle.
في أواخر التسعينيات وأوائل العقد الأول من القرن الحادي والعشرين، لم يكن هناك أي خيار عندما يتعلق الأمر بقواعد البيانات الصناعية القابلة للتطوير. نعم، كان هناك IBM DB90، Sybase وبعض قواعد البيانات الأخرى التي جاءت وذهبت، ولكن بشكل عام لم تكن ملحوظة للغاية على خلفية Oracle. وبناء على ذلك، كانت مهارات المهندسين في تلك الأوقات مرتبطة بطريقة أو بأخرى بالخيار الوحيد الموجود.
يجب أن يكون Oracle DBA قادرًا على:
- تثبيت Oracle Server من مجموعة التوزيع؛
- تكوين خادم أوراكل:
- init.ora;
- lister.ora;
- يخلق:
- مساحات الطاولة؛
- مخططات.
- المستخدمين؛
- إجراء النسخ الاحتياطي والاستعادة؛
— إجراء المراقبة؛
- التعامل مع الطلبات دون المستوى الأمثل.
وفي الوقت نفسه، لم تكن هناك متطلبات خاصة من Oracle DBA:
- أن تكون قادرًا على اختيار نظام إدارة قواعد البيانات (DBMS) الأمثل أو أي تقنية أخرى لتخزين البيانات ومعالجتها؛
- توفير مستوى عالٍ من التوفر وقابلية التوسع الأفقي (لم تكن هذه مشكلة DBA دائمًا)؛
- معرفة جيدة بمجال الموضوع، والبنية التحتية، وهندسة التطبيقات، ونظام التشغيل؛
- تحميل وتفريغ البيانات، وترحيل البيانات بين أنظمة إدارة قواعد البيانات المختلفة.
بشكل عام، إذا تحدثنا عن الاختيار في تلك الأيام، فإنه يشبه الاختيار في متجر سوفيتي في أواخر الثمانينات:
عصرنا
ومنذ ذلك الحين، بالطبع كبرت الأشجار، وتغير العالم، وأصبح الأمر كالتالي:
لقد تغير سوق أنظمة إدارة قواعد البيانات أيضًا، كما يتضح من أحدث تقرير صادر عن مؤسسة Gartner:
وهنا تجدر الإشارة إلى أن السحب، التي تتزايد شعبيتها، قد احتلت مكانتها. وإذا قرأنا نفس تقرير جارتنر سنرى الاستنتاجات التالية:
- العديد من العملاء في طريقهم لنقل التطبيقات إلى السحابة.
- تظهر التقنيات الجديدة لأول مرة في السحابة وليس حقيقة أنها ستنتقل أبدًا إلى البنية التحتية غير السحابية.
- لقد أصبح نموذج تسعير الدفع أولاً بأول شائعاً. الجميع يريد أن يدفع فقط مقابل ما يستخدمه، وهذا ليس حتى اتجاها، ولكن مجرد بيان للحقيقة.
ماذا الان؟
اليوم نحن جميعا في السحابة. والأسئلة التي تطرح علينا هي أسئلة اختيار. وهو ضخم، حتى لو كنا نتحدث فقط عن اختيار تقنيات DBMS في التنسيق المحلي. لدينا أيضًا خدمات مُدارة وSaaS. وبالتالي، يصبح الاختيار أكثر صعوبة كل عام.
جنبا إلى جنب مع أسئلة الاختيار، هناك أيضا مصانع محدوده:
- السعر. لا تزال العديد من التقنيات تكلف المال؛
- مهارات. إذا كنا نتحدث عن البرمجيات الحرة، فإن مسألة المهارات تطرح، حيث أن البرمجيات الحرة تتطلب كفاءة كافية من الأشخاص الذين ينشرونها ويشغلونها؛
- وظيفي. ليست كل الخدمات المتوفرة في السحابة والتي تم إنشاؤها، على سبيل المثال، حتى على نفس Postgres، تتمتع بنفس ميزات Postgres المحلية. وهذا عامل أساسي يجب معرفته وفهمه. علاوة على ذلك، يصبح هذا العامل أكثر أهمية من معرفة بعض القدرات المخفية لنظام إدارة قواعد بيانات واحد.
ما هو المتوقع من DA/DE الآن:
- فهم جيد لمجال الموضوع وهندسة التطبيق؛
- القدرة على اختيار تقنية نظام إدارة قواعد البيانات (DBMS) المناسبة بشكل صحيح، مع الأخذ في الاعتبار المهمة المطروحة؛
- القدرة على اختيار الطريقة المثلى لتنفيذ التكنولوجيا المختارة في سياق القيود الحالية؛
- القدرة على أداء نقل البيانات والهجرة؛
- القدرة على تنفيذ وتشغيل الحلول المختارة.
أدناه المثال بناءً على برنامج Google Cloud Platform يوضح كيف يعمل اختيار تقنية أو أخرى للعمل مع البيانات اعتمادًا على بنيتها:
يرجى ملاحظة أن PostgreSQL غير متضمن في المخطط، وذلك لأنه مخفي تحت المصطلحات سحابة SQL. وعندما نصل إلى Cloud SQL، نحتاج إلى الاختيار مرة أخرى:
تجدر الإشارة إلى أن هذا الاختيار ليس واضحًا دائمًا، لذلك غالبًا ما يسترشد مطورو التطبيقات بالحدس.
المجموع:
- كلما ذهبت أبعد، أصبحت مسألة الاختيار أكثر إلحاحا. وحتى إذا نظرت فقط إلى GCP والخدمات المُدارة وSaaS، فإن بعض الإشارات إلى RDBMS تظهر فقط في الخطوة الرابعة (وهناك Spanner في مكان قريب). بالإضافة إلى ذلك، يظهر اختيار PostgreSQL في الخطوة الخامسة، وبجانبه يوجد أيضًا MySQL وSQL Server، أي هناك الكثير من كل شيء، ولكن عليك أن تختار.
- يجب ألا ننسى القيود على خلفية الإغراءات. في الأساس، الجميع يريد مفتاح ربط، ولكنه مكلف. ونتيجة لذلك، يبدو الطلب النموذجي كما يلي: "من فضلك اجعلنا من المفككين، ولكن مقابل سعر Cloud SQL، أنتم محترفون!"
لكن ماذا تفعل؟
ومن دون أن ندعي أنها الحقيقة المطلقة، نقول ما يلي:
نحن بحاجة إلى تغيير نهجنا في التعلم:
- ليس هناك فائدة من تدريس الطريقة التي تم بها تدريس DBAs من قبل؛
- إن المعرفة بمنتج واحد لم تعد كافية؛
- لكن معرفة العشرات بمستوى واحد أمر مستحيل.
أنت بحاجة إلى معرفة ليس فقط كمية المنتج، بل أيضًا:
- حالة استخدام تطبيقه؛
- طرق نشر مختلفة؛
- مزايا وعيوب كل طريقة؛
- منتجات مماثلة وبديلة لاتخاذ قرار مستنير وأمثل وليس دائمًا لصالح منتج مألوف.
تحتاج أيضًا إلى أن تكون قادرًا على ترحيل البيانات وفهم المبادئ الأساسية للتكامل مع ETL.
حالة حقيقية
في الماضي القريب، كان من الضروري إنشاء واجهة خلفية لتطبيق الهاتف المحمول. بحلول الوقت الذي بدأ فيه العمل، كانت الواجهة الخلفية قد تم تطويرها بالفعل وكانت جاهزة للتنفيذ، وأمضى فريق التطوير حوالي عامين في هذا المشروع. تم تعيين المهام التالية:
- بناء CI/CD؛
- مراجعة الهندسة المعمارية.
- ضع كل شيء موضع التنفيذ.
كان التطبيق نفسه عبارة عن خدمات صغيرة، وتم تطوير كود Python/Django من البداية ومباشرة في GCP. أما بالنسبة للجمهور المستهدف، فقد كان من المفترض أن يكون هناك منطقتين - الولايات المتحدة والاتحاد الأوروبي، وتم توزيع حركة المرور من خلال موازن التحميل العالمي. تم تشغيل جميع أحمال العمل وأحمال عمل الحوسبة على Google Kubernetes Engine.
أما بالنسبة للبيانات، فقد كانت هناك 3 هياكل:
- سحابة التخزين؛
- مخزن البيانات؛
- سحابة SQL (PostgreSQL).
قد يتساءل المرء لماذا تم اختيار Cloud SQL؟ في الحقيقة، تسبب مثل هذا السؤال في بعض الإيقاف المؤقت المحرج في السنوات الأخيرة - هناك شعور بأن الناس أصبحوا خجولين بشأن قواعد البيانات العلائقية، لكنهم مع ذلك يواصلون استخدامها بنشاط ؛-).
أما بالنسبة لحالتنا، فقد تم اختيار Cloud SQL للأسباب التالية:
- كما ذكرنا سابقًا، تم تطوير التطبيق باستخدام Django، وهو يحتوي على نموذج لتعيين البيانات المستمرة من قاعدة بيانات SQL إلى كائنات Python (Django ORM).
- يدعم الإطار نفسه قائمة محدودة إلى حد ما من أنظمة إدارة قواعد البيانات:
- PostgreSQL ؛
- ماريا دي بي؛
- ماي إس كيو إل؛
- أوراكل.
- سكليتي.
وفقًا لذلك، تم اختيار PostgreSQL من هذه القائمة بشكل حدسي (حسنًا، ليس من Oracle الاختيار حقًا).
ما كان في عداد المفقودين:
- تم نشر التطبيق في منطقتين فقط، وظهرت منطقة ثالثة في الخطط (آسيا)؛
- وتقع قاعدة البيانات في منطقة أمريكا الشمالية (أيوا)؛
- من جانب العميل كانت هناك مخاوف بشأن ما هو ممكن تأخير الوصول من أوروبا وآسيا و انقطاعات في الخدمة في حالة توقف نظام إدارة قواعد البيانات (DBMS).
على الرغم من حقيقة أن Django نفسه يمكنه العمل مع العديد من قواعد البيانات بالتوازي وتقسيمها إلى قراءة وكتابة، لم يكن هناك الكثير من الكتابة في التطبيق (أكثر من 90٪ قراءة). وبشكل عام، وبشكل عام، إذا كان من الممكن القيام به قراءة نسخة طبق الأصل من القاعدة الرئيسية في أوروبا وآسيا، سيكون هذا حلا وسطا. حسنًا، ما المعقد في الأمر؟
كانت الصعوبة هي أن العميل لم يرغب في التخلي عن استخدام الخدمات المُدارة وCloud SQL. وقدرات Cloud SQL محدودة حاليًا. يدعم Cloud SQL التوفر العالي (HA) والنسخة المتماثلة للقراءة (RR)، ولكن نفس RR مدعومة في منطقة واحدة فقط. بعد إنشاء قاعدة بيانات في المنطقة الأمريكية، لا يمكنك إنشاء نسخة طبق الأصل للقراءة في المنطقة الأوروبية باستخدام Cloud SQL، على الرغم من أن Postgres نفسها لا تمنعك من القيام بذلك. لم تؤد المراسلات مع موظفي Google إلى أي شيء وانتهت بوعود على طراز "نحن نعرف المشكلة ونعمل على حلها، يومًا ما سيتم حل المشكلة".
إذا أدرجنا إمكانيات Cloud SQL لفترة وجيزة، فسوف تبدو كما يلي:
1. التوفر العالي (HA):
- داخل منطقة واحدة؛
- عن طريق النسخ المتماثل للقرص؛
- لا يتم استخدام محركات PostgreSQL؛
- إمكانية التحكم التلقائي واليدوي - تجاوز الفشل/الفشل؛
- عند التبديل، لا يكون نظام إدارة قواعد البيانات (DBMS) متاحًا لعدة دقائق.
2. قراءة النسخة المتماثلة (RR):
- داخل منطقة واحدة؛
- الاستعداد الساخن.
- النسخ المتماثل لتدفق PostgreSQL.
بالإضافة إلى ذلك، كما هو معتاد، عند اختيار التكنولوجيا، تواجه دائمًا بعض المشاكل قيود:
- لم يرغب العميل في إنشاء كيانات واستخدام IaaS، إلا من خلال GKE؛
- لن يرغب العميل في نشر الخدمة الذاتية PostgreSQL/MySQL؛
- حسنًا، بشكل عام، سيكون Google Spanner مناسبًا تمامًا لولا سعره، ومع ذلك، لا يمكن لـ Django ORM العمل معه، ولكنه شيء جيد.
وبالنظر إلى الوضع، تلقى العميل سؤالاً للمتابعة: "هل يمكنك القيام بشيء مماثل بحيث يكون مثل Google Spanner، ولكنه يعمل أيضًا مع Django ORM؟"
خيار الحل رقم 0
أول ما يتبادر إلى ذهني:
- البقاء داخل CloudSQL؛
- لن يكون هناك تكرار مضمن بين المناطق بأي شكل من الأشكال؛
- حاول إرفاق نسخة متماثلة بـ Cloud SQL موجود بواسطة PostgreSQL؛
- قم بتشغيل مثيل PostgreSQL في مكان ما وبطريقة ما، ولكن على الأقل لا تلمس الملف الرئيسي.
للأسف، اتضح أنه من المستحيل القيام بذلك، لأنه لا يوجد إمكانية الوصول إلى المضيف (إنه موجود في مشروع مختلف تمامًا) - pg_hba وما إلى ذلك، ولا يوجد أيضًا وصول تحت المستخدم المتميز.
خيار الحل رقم 1
وبعد مزيد من التفكير ومراعاة الظروف السابقة، تغير مسار الأفكار إلى حد ما:
- ما زلنا نحاول البقاء داخل CloudSQL، ولكننا سنتحول إلى MySQL، لأن Cloud SQL by MySQL يحتوي على برنامج رئيسي خارجي، والذي:
— هو وكيل لـ MySQL الخارجية؛
- يشبه مثيل MySQL؛
- تم اختراعه لترحيل البيانات من السحب الأخرى أو المحلية.
نظرًا لأن إعداد النسخ المتماثل لـ MySQL لا يتطلب الوصول إلى المضيف، فقد نجح كل شيء من حيث المبدأ، ولكنه كان غير مستقر وغير مريح للغاية. وعندما ذهبنا أبعد من ذلك، أصبح الأمر مخيفًا تمامًا، لأننا قمنا بنشر الهيكل بأكمله باستخدام Terraform، وفجأة اتضح أن السيد الخارجي لم يكن مدعومًا بـ Terraform. نعم، لدى Google واجهة سطر الأوامر (CLI)، ولكن لسبب ما، كان كل شيء يعمل هنا بين الحين والآخر - في بعض الأحيان يتم إنشاؤه، وفي بعض الأحيان لا يتم إنشاؤه. ربما لأنه تم اختراع CLI لترحيل البيانات الخارجية، وليس للنسخ المتماثلة.
في الواقع، أصبح من الواضح في هذه المرحلة أن Cloud SQL غير مناسب على الإطلاق. وكما يقولون، لقد فعلنا كل ما في وسعنا.
خيار الحل رقم 2
نظرًا لأنه لم يكن من الممكن البقاء ضمن إطار عمل Cloud SQL، فقد حاولنا صياغة متطلبات لحل وسط. وتبين أن المتطلبات هي التالية:
- العمل في Kubernetes، الاستخدام الأقصى لموارد وقدرات Kubernetes (DCS، ...) وGCP (LB، ...)؛
- عدم وجود ثقل من مجموعة من الأشياء غير الضرورية في السحابة مثل وكيل HA؛
- القدرة على تشغيل PostgreSQL أو MySQL في منطقة HA الرئيسية؛ في مناطق أخرى - HA من RR للمنطقة الرئيسية بالإضافة إلى نسختها (للموثوقية)؛
- multi master (لم أرغب في الاتصال به، لكن الأمر لم يكن مهمًا جدًا)
.
ونتيجة لهذه المطالب، صنظام إدارة قواعد البيانات (DBMS) وخيارات الربط المناسبة:
- ماي إس كيو إل جاليرا؛
- صرصورDB;
- أدوات PostgreSQL
:
- بجبول-II؛
— باتروني.
ماي إس كيو إل جاليرا
تم تطوير تقنية MySQL Galera بواسطة Codership وهي مكون إضافي لـ InnoDB. الخصائص:
- سيد متعدد؛
- النسخ المتزامن
- القراءة من أي عقدة؛
- التسجيل على أي عقدة؛
- آلية HA مدمجة؛
- يوجد مخطط Helm من Bitnami.
CockroachDB
وفقًا للوصف، فإن الشيء عبارة عن قنبلة تمامًا وهو مشروع مفتوح المصدر مكتوب بلغة Go. المشارك الرئيسي هو Cockroach Labs (الذي أسسه أشخاص من Google). تم تصميم نظام إدارة قواعد البيانات العلائقية هذا في الأصل ليتم توزيعه (مع التوسع الأفقي خارج الصندوق) والتسامح مع الأخطاء. حدد مؤلفوها من الشركة هدف "الجمع بين ثراء وظائف SQL وإمكانية الوصول الأفقي المألوفة لحلول NoSQL."
المكافأة الرائعة هي دعم بروتوكول الاتصال بعد التقدم.
pgpool
هذه إضافة إلى PostgreSQL، وهي في الواقع كيان جديد يتولى جميع الاتصالات ويعالجها. لديه موازن تحميل ومحلل خاص به، مرخص بموجب ترخيص BSD. إنها توفر فرصًا كبيرة، لكنها تبدو مخيفة إلى حد ما، لأن وجود كيان جديد قد يصبح مصدرًا لبعض المغامرات الإضافية.
باتروني
هذا هو آخر شيء وقعت عليه عيني، وكما اتضح، لم يكن عبثا. Patroni هي أداة مساعدة مفتوحة المصدر، وهي في الأساس برنامج Python الخفي الذي يسمح لك بالحفاظ تلقائيًا على مجموعات PostgreSQL مع أنواع مختلفة من النسخ المتماثل وتبديل الأدوار التلقائي. تبين أن الشيء مثير للاهتمام للغاية، لأنه يتكامل بشكل جيد مع المكعب ولا يقدم أي كيانات جديدة.
ماذا اخترت في النهاية؟
لم يكن الاختيار سهلاً:
- CockroachDB - النار، ولكن الظلام؛
- ماي إس كيو إل جاليرا - ليس سيئًا أيضًا، فهو يُستخدم في العديد من الأماكن، لكن MySQL؛
- pgpool — الكثير من الكيانات غير الضرورية، والتكامل المتوسط مع السحابة وK8s؛
- باتروني - تكامل ممتاز مع K8s، ولا توجد كيانات غير ضرورية، ويتكامل بشكل جيد مع GCP LB.
وهكذا وقع الاختيار على باتروني.
النتائج
حان الوقت لتلخيص ذلك بإيجاز. نعم، لقد تغير عالم البنية التحتية لتكنولوجيا المعلومات بشكل كبير، وهذه مجرد البداية. وإذا كانت السحب في السابق مجرد نوع آخر من البنية التحتية، فقد أصبح كل شيء الآن مختلفًا. علاوة على ذلك، تظهر الابتكارات في السحابة باستمرار، وسوف تظهر، وربما ستظهر فقط في السحابة، وعندها فقط، من خلال جهود الشركات الناشئة، سيتم نقلها إلى أماكن العمل.
أما بالنسبة لـ SQL، فستبقى SQL موجودة. هذا يعني أنك بحاجة إلى معرفة PostgreSQL وMySQL والقدرة على العمل معهم، ولكن الأهم من ذلك هو أن تكون قادرًا على استخدامها بشكل صحيح.
المصدر: www.habr.com