مرحبًا يا هابروفسك. اليوم ، ستبدأ الدروس في المجموعة الأولى من دورة PostgreSQL . في هذا الصدد ، نريد أن نخبرك بكيفية إجراء الندوة المفتوحة على الويب لهذه الدورة.
في
الدرس المفتوح التالي ، تحدثنا عن التحديات التي تواجه قواعد بيانات SQL في عصر السحب و Kubernetes. وفي الوقت نفسه درسنا كيف تتكيف قواعد البيانات SQL وتتحور تحت تأثير هذه المكالمات.
تم استضافة الندوة عبر الويب بواسطة
فاليري بيزروكوف ، مدير تقديم خدمات التدريب في السحاب من Google في
EPAM Systems.
عندما كانت الأشجار صغيرة ...
للبدء ، دعونا نتذكر كيف بدأ اختيار نظام إدارة قواعد البيانات في نهاية القرن الماضي. ومع ذلك ، لن يكون ذلك صعباً ، لأن اختيار نظام إدارة قواعد البيانات في تلك الأيام بدأ وينتهي مع
أوراكل .
في أواخر تسعينيات القرن الماضي - بداية العقد ، في الواقع ، لم يكن هناك خيار خاص ، إذا تحدثنا عن قواعد البيانات الصناعية القابلة للتطوير. نعم ، كان هناك IBM DB2 و Sybase وبعض قواعد البيانات الأخرى التي ظهرت واختفت ، لكن بشكل عام لم تكن ملحوظة جدًا ضد Oracle. تبعا لذلك ، فإن مهارات المهندسين في تلك الأوقات كانت مرتبطة بطريقة أو بأخرى بالاختيار الوحيد الموجود.
يجب أن يكون Oracle DBA قادراً على:
- تثبيت Oracle Server من التوزيع
- تكوين خادم أوراكل:
- إنشاء:
- مساحات الجدول
- مخطط.
- المستخدمين.
- النسخ الاحتياطي واستعادة.
- القيام بالرصد ؛
- التعامل مع الطلبات دون المستوى الأمثل.
في الوقت نفسه ، لم يكن Oracle DBA مطلوبًا بشكل خاص:
- تكون قادرة على اختيار نظم إدارة قواعد البيانات الأمثل أو غيرها من تكنولوجيا تخزين ومعالجة البيانات ؛
- توفير إمكانية توفر عالية وقابلية للتوسع الأفقي (لم يكن ذلك دائمًا مشكلة DBA) ؛
- معرفة جيدة بمجال الموضوع والبنية التحتية والهندسة التطبيقية ونظام التشغيل ؛
- أداء تحميل وتفريغ البيانات ، وترحيل البيانات بين مختلف نظم إدارة قواعد البيانات.
بشكل عام ، إذا تحدثنا عن الخيار في تلك الأيام ، فسيكون هذا بمثابة خيار في متجر سوفياتي في أواخر الثمانينيات:
وقتنا
منذ ذلك الحين ، بالطبع ، نمت الأشجار ، العالم قد تغير ، وأصبح بطريقة ما مثل هذا:
لقد تغير سوق نظم إدارة قواعد البيانات (DBMS) أيضًا ، وهو ما يمكن رؤيته بوضوح من خلال تقرير Gartner الأخير:
وهنا تجدر الإشارة إلى أن الغيوم احتلت مكانتها ، التي تزداد شعبيتها. إذا قرأت نفس تقرير Gartner ، فسنرى الاستنتاجات التالية:
- العديد من العملاء على الطريق لنقل التطبيقات إلى السحابة.
- تظهر التقنيات الحديثة أولاً في السحابة وليس حقيقة أنها ستنتقل مطلقًا إلى بنية تحتية خالية من السحابة.
- أصبح نموذج تسعير الدفع مقابل الاستخدام مألوفًا. الكل يريد أن يدفع فقط مقابل ما يستخدمونه ، وهذا ليس حتى اتجاهاً ، بل مجرد بيان حقيقة.
ماذا الان
اليوم نحن جميعا في السحابة. وتلك الأسئلة التي لدينا هي أسئلة الاختيار. إنه ضخم ، حتى لو كنا نتحدث فقط عن اختيار تقنيات DBMS في التنسيق المحلي. لدينا أيضا الخدمات المدارة و SaaS. وبالتالي ، أصبح الخيار أكثر تعقيدًا كل عام.
إلى جانب أسئلة الاختيار ، تنطبق
العوامل التقييدية أيضًا:
- السعر . العديد من التقنيات لا تزال تكلف المال.
- المهارات . إذا كنا نتحدث عن البرمجيات الحرة ، فسوف تنشأ مسألة المهارات ، لأن البرمجيات المجانية تتطلب من الأشخاص الذين يقومون بنشرها وتشغيلها بكفاءة كافية ؛
- وظيفية . ليس كل الخدمات المتوفرة في السحابة والتي تم إنشاؤها ، على سبيل المثال ، حتى على أساس Postgres نفسها ، لها نفس ميزات Postgres الداخلية. هذا عامل أساسي تحتاج إلى معرفته وفهمه. علاوة على ذلك ، يصبح هذا العامل أكثر أهمية من معرفة بعض الميزات الخفية لقاعدة بيانات واحدة.
ماذا ينتظر من DA / DE:- فهم جيد لمجال الموضوع والعمارة التطبيقية ؛
- القدرة على اختيار تقنية DBMS المناسبة ، مع مراعاة المهمة ؛
- القدرة على اختيار الطريقة المثلى لتنفيذ التكنولوجيا المحددة في سياق القيود الحالية ؛
- القدرة على أداء ترحيل البيانات والهجرة ؛
- القدرة على تنفيذ وتشغيل الحلول المحددة.
يوضح المثال التالي
استنادًا إلى برنامج "شركاء Google المعتمدون" كيف يتم ترتيب اختيار تقنية معينة للتعامل مع البيانات اعتمادًا على هيكلها:
لاحظ أن PostgreSQL مفقود في المخطط ، وكل هذا لأنه يختبئ تحت مصطلحات
Cloud SQL . وعندما نصل إلى Cloud SQL ، نحتاج إلى اتخاذ قرار مرة أخرى:
تجدر الإشارة إلى أن هذا الاختيار ليس واضحًا دائمًا ، لذلك غالباً ما يتم توجيه مطوري التطبيقات عن طريق الحدس.
المجموع:- وكلما كانت مسألة الاختيار ذات صلة. وحتى إذا نظرت فقط إلى GCP والخدمات المدارة و SaaS ، فبعض الإشارات إلى RDBMS تظهر فقط في الخطوة الرابعة (وهناك Spanner في مكان قريب). بالإضافة إلى ذلك ، يظهر خيار PostgreSQL بشكل عام في الخطوة الخامسة ، وبجانبه هناك أيضًا MySQL و SQL Server ، أي أن هناك الكثير ، ولكن عليك أن تختار .
- يجب ألا ننسى القيود المفروضة على خلفية الإغراءات. في الغالب ، الكل يريد مفتاحاً ، لكنه مكلف. نتيجةً لذلك ، يبدو الاستعلام النموذجي كما يلي: "الرجاء القيام بـ Spanner من أجلنا ، لكن بالنسبة إلى Cloud Cloud ، حسناً ، أنت محترف!"
ماذا تفعل؟
دون التظاهر بأنه الحقيقة المطلقة ، دعنا نقول ما يلي:
بحاجة إلى تغيير نهج التعلم:- للتعلم ، كما تعلمنا قبل DBA ، فإنه لا معنى له ؛
- المعرفة بمنتج واحد لم تعد كافية ؛
- ولكن لمعرفة العشرات على مستوى واحد أمر مستحيل.
تحتاج إلى معرفة ليس فقط وليس مقدار المنتج ، ولكن:
- حالة استخدام التطبيق ؛
- طرق النشر المختلفة.
- مزايا وعيوب كل طريقة ؛
- منتجات مماثلة وبديلة لاتخاذ خيارات مستنيرة والمثلى وليس دائما لصالح منتج مألوف.
يجب أيضًا أن تكون قادرًا على ترحيل البيانات وفهم المبادئ الأساسية للتكامل مع ETL.
حالة حقيقية
في الماضي القريب ، كان عليك إنشاء خلفية لتطبيق الهاتف المحمول. بحلول الوقت الذي بدأت فيه العمل عليها ، كانت الخلفية قد تم تطويرها بالفعل وكانت جاهزة للتنفيذ ، وقضى فريق التطوير حوالي عامين في هذا المشروع. تم تعيين المهام التالية:
- بناء CI / CD ؛
- لمراجعة العمارة
- وضع كل شيء في العملية.
كان التطبيق نفسه عبارة عن خدمة microservice ، وتم تطوير رمز Python / Django من البداية وعلى الفور في GCP. أما بالنسبة للجمهور المستهدف ، فقد افترض أنه سيكون هناك منطقتان - الولايات المتحدة والاتحاد الأوروبي ، وتم توزيع حركة المرور من خلال موازن التحميل العالمي. عملت جميع أعباء العمل وأعباء العمل الحسابية في Google Kubernetes Engine.
بالنسبة للبيانات ، كانت هناك 3 هياكل:
- سحابة التخزين
- مخزن البيانات.
- سحابة SQL (بوستجرس).
قد تتساءل لماذا تم اختيار Cloud SQL؟ لقول الحقيقة ، تسبب هذا السؤال في السنوات الأخيرة في بعض التوقف المؤقت - هناك شعور بأن الناس بدأوا يخجلون من قواعد البيانات العلائقية ، ولكن مع ذلك يواصلون استخدامها بنشاط ؛-).
بالنسبة لحالتنا ، تم اختيار Cloud SQL للأسباب التالية:
- كما ذكرنا ، تم تطوير التطبيق باستخدام Django ، ولديه نموذج لتعيين البيانات المستمرة من قاعدة بيانات SQL إلى كائنات Python (Django ORM).
- يدعم الإطار نفسه قائمة محدودة إلى حد ما من قواعد إدارة قواعد البيانات:
- كيو.
- MariaDB ل.
- الخلية.
- أوراكل.
- سكليتي.
وفقًا لذلك ، تم اختيار PostgreSQL بشكل حدسي من هذه القائمة (حسنًا ، إنه ليس Oracle ، في الواقع).
ما كان في عداد المفقودين:- تم نشر التطبيق فقط في منطقتين ، وظهرت الخطط الثالثة (آسيا) ؛
- كانت قاعدة البيانات في منطقة أمريكا الشمالية (أيوا) ؛
- من جانب العميل ، كانت هناك مخاوف بشأن التأخير المحتمل في الوصول من أوروبا وآسيا وانقطاع الخدمة في حالة تعطل DBMS.
على الرغم من حقيقة أن Django نفسها يمكنها العمل مع العديد من قواعد البيانات بشكل متوازٍ وتقسيمها عن طريق القراءة والكتابة ، لم يكن هناك الكثير من السجلات في التطبيق (أكثر من 90 ٪ - قراءة). وبشكل عام ، وبشكل عام ، إذا تمكنت من عمل نسخة
مطابقة للقاعدة الرئيسية في أوروبا وآسيا ، فسيكون هذا حلاً وسطًا. حسنا ، ما هو معقد جدا؟
وكانت الصعوبة هي أن العميل لم يرغب في رفض استخدام الخدمات المدارة و Cloud SQL. وإمكانيات سحابة SQL محدودة حاليا. تدعم السحابة SQL توافر عالي (HA) وقراءة النسخ المتماثلة (RR) ، ولكن نفس RR مدعوم في منطقة واحدة فقط. بعد إنشاء قاعدة بيانات في المنطقة الأمريكية ، يستحيل عمل نسخة متماثلة للقراءة في المنطقة الأوروبية باستخدام Cloud SQL ، على الرغم من أن postgres نفسها لا تتداخل. لم تؤدي المراسلات مع موظفي Google إلى أي شيء وانتهت بالوعود بأسلوب "نعرف المشكلة ونعمل على حلها ، في يوم ما سيتم حل المشكلة".
إذا أدرجت إمكانيات أطروحة Cloud SQL ، فستظهر بشكل مثل هذا:
1. توافر عالية (ها):- داخل منطقة واحدة ؛
- من خلال تكرار القرص
- لا يتم استخدام آليات PostgreSQL.
- التحكم الآلي واليدوي ممكن - الفشل / الفشل
- عند التبديل ، يكون نظام إدارة قواعد البيانات (DBMS) غير متاح لعدة دقائق.
2. قراءة النسخة المتماثلة (RR):- داخل منطقة واحدة ؛
- الاستعداد الساخن.
- PostgreSQL يتدفقون النسخ المتماثل.
بالإضافة إلى ذلك ، كما هو معتاد ، عند اختيار التكنولوجيا ، فإنك تواجه دائمًا بعض
القيود :
- لم يرغب العميل في إنتاج كيانات واستخدام IaaS ، إلا من خلال GKE ؛
- لن يرغب العميل في نشر خدمة PostgreSQL / MySQL للخدمة الذاتية ؛
- حسنًا ، بشكل عام ، سيكون Google Spanner مناسبًا تمامًا إذا لم يكن ثمنه ، ومع ذلك ، فإن Django ORM لا يمكنه التعامل معه ، وبالتالي فإن الأمر جيد.
نظرًا للموقف ، تلقى العميل سؤالًا عن التعبئة:
"هل يمكنك القيام بشيء مماثل لجعله مثل Google Spanner ، لكنه يعمل أيضًا مع Django ORM؟"الخيار رقم 0
أول ما يتبادر إلى الذهن:
- البقاء داخل CloudSQL
- لن يكون هناك تكرار متكامل بين المناطق بأي شكل من الأشكال ؛
- محاولة المسمار النسخة المتماثلة إلى سحابة 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 ؛
- القدرة على تشغيل HA PostgreSQL أو MySQL في المنطقة الرئيسية ؛ في مناطق أخرى - HA من لوائح الراديو في المنطقة الرئيسية بالإضافة إلى نسخته (من أجل الموثوقية) ؛
- سيد متعدد (لا يريد الاتصال به ، لكنه لم يكن مهمًا جدًا)
.
كنتيجة لهذه المتطلبات ، ظهر في الأفق أخيرًا
خيارات وقواعد ربط مناسبة لـ DBMS :
- الخلية جاليرا.
- CockroachDB.
- أدوات بوستجرس
:
- pgpool-II ؛
- راعي.
الخلية جاليرا
تم تطوير تقنية MySQL Galera بواسطة Codership وهو البرنامج المساعد لـ InnoDB. الميزات:
- سيد متعدد
- تكرار متزامن
- قراءة من أي عقدة.
- تسجيل إلى أي عقدة.
- آلية HA المتكاملة ؛
- هناك مخطط هيلم من Bitnami.
CockroachDB
وفقًا للوصف ، فإن الشيء مفعم بالحيوية تمامًا وهو مشروع مفتوح المصدر مكتوب في Go. المشارك الرئيسي هو Cockroach Labs (أسسها مهاجرون من Google). تم إنشاء نظام إدارة قواعد البيانات الترابطي هذا أصلاً ليتم توزيعه (مع التوسع الأفقي خارج الصندوق) والتسامح مع الخطأ. حدد مؤلفوها من الشركة هدف "الجمع بين ثراء وظائف SQL مع التوافر الأفقي المألوف لحلول NoSQL."
من مكافأة لطيفة هو دعم لبروتوكول اتصال بوستجرس.
Pgpool
هذه وظيفة إضافية لـ PostgreSQL ، في الواقع ، كيان جديد يتولى جميع الاتصالات ويعالجها. لديها موازنها ومحلل اللودر الخاص به ، المرخص لهما بموجب رخصة بي إس دي. إنه يوفر فرصًا كبيرة ، لكنه يبدو مخيفًا إلى حد ما ، لأن وجود كيان جديد يمكن أن يصبح مصدرًا لبعض المغامرات الإضافية.
Patroni
هذا هو آخر شيء سقطت عليه العين ، وكما اتضح فيما بعد ، لم تذهب سدى. Patroni هي أداة مساعدة مفتوحة المصدر ، والتي في جوهرها ، عبارة عن برنامج خفي من Python يتيح لك خدمة مجموعات PostgreSQL تلقائيًا مع أنواع مختلفة من النسخ المتماثل والتبديل التلقائي للأدوار. تبين أن القطعة مثيرة للاهتمام للغاية ، لأنها تتكامل بشكل جيد مع cuber ولا تحمل أي كيانات جديدة.
ما اختار في نهاية المطاف
لم يكن الخيار سهلاً:
- CockroachDB - النار ، ولكن البكم.
- MySQL Galera أيضًا ليس سيئًا ، حيث يتم استخدامه كثيرًا ، ولكن MySQL ؛
- Pgpool - الكثير من الكيانات الإضافية ، التكامل التام مع السحابة و K8s ؛
- Patroni - تكامل ممتاز مع K8s ، بدون كيانات إضافية ، يتكامل بشكل جيد مع GCP LB.
وهكذا ، وقع الاختيار على Patroni.
النتائج
لقد حان الوقت لتلخيص. نعم ، لقد تغير عالم البنية التحتية لتكنولوجيا المعلومات بشكل كبير ، وهذه هي البداية فقط. وإذا كانت السحب السابقة مجرد نوع آخر من البنية التحتية ، أصبح كل شيء مختلفًا الآن. ليس ذلك فحسب ، فالابتكارات في السحب تظهر باستمرار ، وستظهر ، وربما تظهر فقط في السحب وبعد ذلك ، بمساعدة الشركات الناشئة ، سيتم نقلها إلى أماكن العمل المحلية.
بالنسبة إلى SQL ، ستعيش SQL. هذا يعني أن PostgreSQL و MySQL يجب أن تكون معروفًا وأنك بحاجة إلى أن تكون قادرًا على العمل معهم ، ولكن الأهم من ذلك ، أن تكون قادرًا على تطبيقهما بشكل صحيح.