ستتم مراجعة مساهمة ياندكس في قواعد البيانات التالية.
- كليكهاوس
- الأوديسة
- الاسترداد إلى نقطة زمنية (WAL-G)
- PostgreSQL (بما في ذلك أخطاء التسجيل، وAmcheck، وheapcheck)
- البرقوق الأخضر
فيديو:
مرحبا بالعالم! اسمي أندريه بورودين. وما أفعله في Yandex.Cloud هو تطوير قواعد بيانات علائقية مفتوحة لصالح عملاء Yandex.Cloud وYandex.Cloud.
في هذه المحادثة، سنتحدث عن التحديات التي تواجه قواعد البيانات المفتوحة على نطاق واسع. لماذا هو مهم؟ لأن المشاكل الصغيرة، مثل البعوض، تصبح فيلة. تصبح كبيرة عندما يكون لديك العديد من المجموعات.
ولكن هذا ليس الشيء الرئيسي. أشياء لا تصدق تحدث. الأشياء التي تحدث في واحد في المليون حالة. وفي البيئة السحابية، عليك أن تكون مستعدًا لذلك، لأن الأشياء المذهلة تصبح محتملة للغاية عندما يكون هناك شيء على نطاق واسع.
لكن! ما فائدة قواعد البيانات المفتوحة؟ الحقيقة هي أن لديك فرصة نظرية للتعامل مع أي مشكلة. لديك الكود المصدري، ولديك معرفة بالبرمجة. نحن نجمعها وتعمل.
ما هي الأساليب المتبعة في العمل على البرمجيات مفتوحة المصدر؟
- النهج الأكثر مباشرة هو استخدام البرمجيات. إذا كنت تستخدم البروتوكولات، وإذا كنت تستخدم المعايير، وإذا كنت تستخدم التنسيقات، وإذا كتبت استعلامات في برامج مفتوحة المصدر، فأنت تدعمها بالفعل.
- أنت تجعل نظامها البيئي أكبر. أنت تزيد من احتمالية الاكتشاف المبكر للخلل. يمكنك زيادة موثوقية هذا النظام. يمكنك زيادة توافر المطورين في السوق. يمكنك تحسين هذا البرنامج. أنت بالفعل مساهم إذا كنت قد انتهيت للتو من الحصول على الأسلوب والتعديل على شيء ما هناك.
- هناك نهج آخر مفهوم وهو رعاية البرامج مفتوحة المصدر. على سبيل المثال، برنامج Google Summer of Code الشهير، حيث تدفع Google لعدد كبير من الطلاب من جميع أنحاء العالم أموالاً مفهومة حتى يتمكنوا من تطوير مشاريع برمجية مفتوحة تلبي متطلبات ترخيص معينة.
- يعد هذا أسلوبًا مثيرًا للاهتمام للغاية لأنه يسمح للبرنامج بالتطور دون تحويل التركيز بعيدًا عن المجتمع. جوجل، باعتبارها عملاق التكنولوجيا، لا تقول أننا نريد هذه الميزة، نريد إصلاح هذا الخلل وعلينا أن نحفر هناك. يقول جوجل: "افعل ما تفعله. فقط استمر في العمل بالطريقة التي كنت تعمل بها وسيكون كل شيء على ما يرام."
- النهج التالي للمشاركة في المصادر المفتوحة هو المشاركة. عندما تواجه مشكلة في البرامج مفتوحة المصدر ويوجد مطورين، يبدأ المطورون لديك في حل المشكلات. إنهم يبدأون في جعل بنيتك التحتية أكثر كفاءة، وبرامجك أسرع وأكثر موثوقية.
أحد أشهر مشاريع Yandex في مجال البرمجيات مفتوحة المصدر هو ClickHouse. هذه هي قاعدة البيانات التي ولدت كاستجابة للتحديات التي تواجه Yandex.Metrica.
وكقاعدة بيانات، تم إنشاؤها في مصدر مفتوح من أجل إنشاء نظام بيئي وتطويره مع مطورين آخرين (ليس فقط داخل Yandex). والآن يعد هذا مشروعًا كبيرًا تشارك فيه العديد من الشركات المختلفة.
في Yandex.Cloud، أنشأنا ClickHouse أعلى Yandex Object Storage، أي أعلى التخزين السحابي.
لماذا هذا مهم في السحابة؟ لأن أي قاعدة بيانات تعمل في هذا المثلث، في هذا الهرم، في هذا التسلسل الهرمي لأنواع الذاكرة. لديك سجلات سريعة ولكن صغيرة ومحركات أقراص SSD ومحركات أقراص صلبة رخيصة الثمن وكبيرة ولكن بطيئة وبعض أجهزة الحظر الأخرى. وإذا كنت فعالاً في قمة الهرم، فلديك قاعدة بيانات سريعة. إذا كنت فعالاً في أسفل هذا الهرم، فلديك قاعدة بيانات موسعة. وفي هذا الصدد، تعد إضافة طبقة أخرى من الأسفل طريقة منطقية لزيادة قابلية التوسع لقاعدة البيانات.
كيف يمكن أن يتم ذلك؟ وهذه نقطة مهمة في هذا التقرير.
- يمكننا تنفيذ ClickHouse عبر MDS. MDS هي واجهة تخزين سحابية داخلية لـ Yandex. إنه أكثر تعقيدًا من بروتوكول S3 الشائع، ولكنه أكثر ملاءمة لجهاز الكتلة. فمن الأفضل لتسجيل البيانات. يتطلب المزيد من البرمجة. سيقوم المبرمجون بالبرمجة، إنه أمر جيد، إنه أمر مثير للاهتمام.
- يعد S3 أسلوبًا أكثر شيوعًا يجعل الواجهة أكثر بساطة على حساب تكيف أقل مع أنواع معينة من أعباء العمل.
بطبيعة الحال، نظرًا لرغبتنا في توفير وظائف لنظام ClickHouse البيئي بأكمله والقيام بالمهمة المطلوبة داخل Yandex.Cloud، قررنا التأكد من أن مجتمع ClickHouse بأكمله سيستفيد منه. لقد قمنا بتطبيق ClickHouse عبر S3، وليس ClickHouse عبر MDS. وهذا كثير من العمل.
المراجع:
"طبقة تجريد نظام الملفات"
"تكامل AWS SDK S3"
"التنفيذ الأساسي لواجهة IDisk لـ S3"
"تكامل محركات تخزين السجل مع واجهة IDisk"
"دعم محرك السجل لـ S3 وSeekableReadBuffer"
"دعم سجل شريط التخزين S3"
"الدعم الأولي لـ Storage MergeTree لـ S3"
"دعم MergeTree الكامل لـ S3"
"دعم ReplicatedMergeTree عبر S3"
"أضف بيانات الاعتماد الافتراضية والرؤوس المخصصة لتخزين s3"
"S3 مع تكوين الوكيل الديناميكي"
"S3 مع محلل الوكيل"
هذه قائمة طلبات سحب لتطبيق نظام ملفات افتراضي في ClickHouse. هذا عدد كبير من طلبات السحب.
المراجع:
"الارتباطات الصلبة DiskS3 التنفيذ الأمثل"
"عميل S3 HTTP - تجنب نسخ دفق الاستجابة إلى الذاكرة"
"تجنب نسخ دفق الاستجابة بالكامل إلى الذاكرة في S3 HTTP
عميل"
"القدرة على تخزين ملفات العلامة والفهرسة مؤقتًا لقرص S3"
"نقل الأجزاء من DiskLocal إلى DiskS3 بالتوازي"
لكن العمل لم ينته عند هذا الحد. بعد إنشاء الميزة، كانت هناك حاجة إلى المزيد من العمل لتحسين هذه الوظيفة.
المراجع:
"إضافة أحداث SelectedRows وSelectedBytes"
"إضافة أحداث ملفات التعريف من طلب S3 إلى system.events"
"إضافة QueryTimeMicrothans وSelectQueryTimeMicrothans وInsertQueryTimeMicrothans"
ومن ثم كان من الضروري جعله قابلاً للتشخيص، وإعداد المراقبة وجعله قابلاً للإدارة.
وقد تم كل هذا حتى يتلقى المجتمع بأكمله، والنظام البيئي ClickHouse بأكمله، نتيجة هذا العمل.
دعنا ننتقل إلى قواعد بيانات المعاملات، إلى قواعد بيانات OLTP، الأقرب إلي شخصيًا.
هذا هو قسم تطوير نظم إدارة قواعد البيانات مفتوح المصدر. يقوم هؤلاء الأشخاص بسحر الشوارع لتحسين قواعد بيانات المعاملات المفتوحة.
أحد المشاريع، باستخدام مثال يمكننا التحدث عن كيف وماذا نفعل، هو Connection Pooler في Postgres.
Postgres هي قاعدة بيانات العمليات. وهذا يعني أن قاعدة البيانات يجب أن تحتوي على أقل عدد ممكن من اتصالات الشبكة التي تتعامل مع المعاملات.
من ناحية أخرى، في البيئة السحابية، يكون الموقف النموذجي هو عندما يصل ألف اتصال إلى مجموعة واحدة في وقت واحد. ومهمة مجمع الاتصال هي تجميع ألف اتصال في عدد صغير من اتصالات الخادم.
يمكننا القول أن مُجمِع الاتصال هو مشغل الهاتف الذي يعيد ترتيب البايتات بحيث تصل بكفاءة إلى قاعدة البيانات.
لسوء الحظ، لا توجد كلمة روسية جيدة لتجمع الاتصال. في بعض الأحيان يطلق عليه اتصالات معدد الإرسال. إذا كنت تعرف ماذا تسمي مجمع الاتصال، فتأكد من إخباري، وسأكون سعيدًا جدًا بالتحدث باللغة التقنية الروسية الصحيحة.
لقد قمنا بالتحقق من مجمعات الاتصال التي كانت مناسبة لمجموعة postgres مُدارة. وكان PgBouncer هو الخيار الأفضل بالنسبة لنا. لكننا واجهنا عددًا من المشكلات مع PgBouncer. منذ عدة سنوات، قدم فولوديا بورودين تقارير تفيد بأننا نستخدم PgBouncer، ونحن نحب كل شيء، ولكن هناك فروق دقيقة، وهناك شيء يجب العمل عليه.
وعملنا. لقد أصلحنا المشكلات التي واجهناها، وقمنا بتصحيح Bouncer، وحاولنا دفع طلبات السحب إلى المنبع. لكن الترابط الفردي الأساسي كان من الصعب العمل معه.
كان علينا جمع الشلالات من الحراس المرقعة. عندما يكون لدينا العديد من الحراس المفردين، يتم نقل الاتصالات الموجودة على الطبقة العليا إلى الطبقة الداخلية من الحراس. وهذا نظام سيئ الإدارة ومن الصعب بناءه وتوسيع نطاقه ذهابًا وإيابًا.
لقد توصلنا إلى استنتاج مفاده أننا أنشأنا مجمع الاتصال الخاص بنا، والذي يسمى Odyssey. لقد كتبناها من الصفر.
في عام 2019، في مؤتمر PgCon، قدمت هذا المجمع إلى مجتمع المطورين. الآن لدينا أقل بقليل من 2 نجمة على GitHub، أي أن المشروع حي، والمشروع مشهور.
وإذا قمت بإنشاء مجموعة Postgres في Yandex.Cloud، فستكون مجموعة تحتوي على Odyssey المضمنة، والتي يتم إعادة تكوينها عند توسيع نطاق المجموعة للخلف أو للأمام.
ماذا تعلمنا من هذا المشروع؟ يعد إطلاق مشروع منافس دائمًا خطوة عدوانية، وهو إجراء متطرف عندما نقول أن هناك مشكلات لا يتم حلها بالسرعة الكافية، ولا يتم حلها في الفترات الزمنية التي تناسبنا. لكن هذا إجراء فعال.
بدأ PgBouncer في التطور بشكل أسرع.
والآن ظهرت مشاريع أخرى. على سبيل المثال، pgagroal، الذي تم تطويره بواسطة مطوري Red Hat. إنهم يسعون لتحقيق أهداف مماثلة وينفذون أفكارًا مماثلة، ولكن، بالطبع، بتفاصيلهم الخاصة، والتي هي أقرب إلى مطوري pgagroal.
هناك حالة أخرى للعمل مع مجتمع postgres وهي العودة إلى نقطة زمنية معينة. هذا هو الاسترداد بعد الفشل، وهذا هو الاسترداد من النسخة الاحتياطية.
هناك العديد من النسخ الاحتياطية وكلها مختلفة. يمتلك كل بائع Postgres تقريبًا حل النسخ الاحتياطي الخاص به.
إذا أخذت جميع الأنظمة الاحتياطية، وقمت بإنشاء مصفوفة ميزات وحساب المحدد في هذه المصفوفة مازحًا، فسيكون صفرًا. ماذا يعني هذا؟ ماذا لو أخذت ملف نسخة احتياطية محددًا، فلا يمكن تجميعه من أجزاء من جميع الملفات الأخرى. إنه فريد في تنفيذه، وهو فريد في غرضه، وهو فريد في الأفكار المتضمنة فيه. وكلها محددة.
بينما كنا نعمل على هذه المسألة، أطلقت CitusData مشروع WAL-G. هذا نظام نسخ احتياطي تم إنشاؤه مع مراعاة البيئة السحابية. الآن أصبحت CitusData بالفعل جزءًا من Microsoft. وفي تلك اللحظة، أحببنا حقًا الأفكار التي تم طرحها في الإصدارات الأولية من WAL-G. وبدأنا المساهمة في هذا المشروع.
يوجد الآن العشرات من المطورين في هذا المشروع، لكن أفضل 10 مساهمين في WAL-G هم 6 Yandexoids. لقد جلبنا الكثير من أفكارنا هناك. وبالطبع، قمنا بتنفيذها بأنفسنا، واختبرناها بأنفسنا، وقمنا بإدخالها إلى الإنتاج بأنفسنا، ونستخدمها بأنفسنا، ونكتشف بأنفسنا المكان الذي يجب أن نتحرك فيه بعد ذلك، أثناء التفاعل مع مجتمع WAL-G الكبير.
ومن وجهة نظرنا، أصبح نظام النسخ الاحتياطي هذا، بما في ذلك مراعاة جهودنا، هو الأمثل للبيئة السحابية. هذه هي أفضل تكلفة لعمل نسخة احتياطية من Postgres في السحابة.
ماذا يعني ذلك؟ لقد كنا نروج لفكرة كبيرة إلى حد ما: يجب أن يكون النسخ الاحتياطي آمنًا، ورخيصًا في التشغيل، وأسرع ما يمكن استعادته.
لماذا يجب أن تكون رخيصة التشغيل؟ عندما لا يتم كسر أي شيء، لا يجب أن تعرف أن لديك نسخًا احتياطية. كل شيء يعمل بشكل جيد، فأنت تهدر أقل قدر ممكن من وحدة المعالجة المركزية (CPU)، وتستخدم أقل قدر ممكن من موارد القرص لديك، وترسل أقل عدد ممكن من البايتات إلى الشبكة حتى لا تتداخل مع حمولة خدماتك القيمة.
وعندما يتعطل كل شيء، على سبيل المثال، قام المسؤول بإسقاط البيانات، وحدث خطأ ما، وتحتاج بشدة إلى العودة إلى الماضي، وتتعافى بكل الأموال، لأنك تريد استعادة بياناتك بسرعة وسليمة.
وقمنا بالترويج لهذه الفكرة البسيطة. ويبدو لنا أننا تمكنا من تنفيذها.
ولكن هذا ليس كل شيء. أردنا شيئًا صغيرًا آخر. أردنا العديد من قواعد البيانات المختلفة. ليس كل عملائنا يستخدمون Postgres. يستخدم بعض الأشخاص MySQL وMongoDB. في المجتمع، قام مطورون آخرون بدعم FoundationDB. وهذه القائمة تتوسع باستمرار.
يحب المجتمع فكرة تشغيل قاعدة البيانات في بيئة مُدارة في السحابة. ويحتفظ المطورون بقواعد بياناتهم، والتي يمكن نسخها احتياطيًا بشكل موحد مع Postgres من خلال نظام النسخ الاحتياطي الخاص بنا.
ماذا تعلمنا من هذه القصة؟ منتجنا، كقسم تطوير، ليس سطورًا من التعليمات البرمجية، وليس بيانات، وليس ملفات. منتجنا لا يسحب الطلبات. هذه هي الأفكار التي ننقلها للمجتمع. هذه هي الخبرة التكنولوجية وحركة التكنولوجيا نحو البيئة السحابية.
هناك قاعدة بيانات مثل Postgres. أنا أحب جوهر Postgres أكثر. أقضي الكثير من الوقت في تطوير جوهر Postgres مع المجتمع.
ولكن هنا يجب القول أن Yandex.Cloud لديه تثبيت داخلي لقواعد البيانات المُدارة. وقد بدأت منذ وقت طويل في Yandex.Mail. لقد تراكمت الخبرة التي أدت الآن إلى إدارة Postgres عندما أراد البريد الانتقال إلى Postgres.
لدى البريد متطلبات مشابهة جدًا للسحابة. يتطلب منك أن تكون قادرًا على التوسع في النمو الأسي غير المتوقع في أي نقطة في بياناتك. وكان البريد بالفعل محملاً بمئات الملايين من صناديق البريد لعدد كبير من المستخدمين الذين يقدمون العديد من الطلبات باستمرار.
وكان هذا تحديًا خطيرًا للغاية للفريق الذي كان يقوم بتطوير Postgres. في ذلك الوقت، تم الإبلاغ عن أي مشاكل نواجهها إلى المجتمع. وتم تصحيح هذه المشاكل، وتصحيحها من قبل المجتمع في بعض الأماكن حتى على مستوى الدعم المدفوع لبعض قواعد البيانات الأخرى بل والأفضل. أي أنه يمكنك إرسال خطاب إلى PgSQL hacker وتلقي الرد في غضون 40 دقيقة. قد يعتقد الدعم المدفوع في بعض قواعد البيانات أن هناك أشياء ذات أولوية أكبر من الخطأ الذي تعاني منه.
الآن التثبيت الداخلي لـ Postgres هو بضعة بيتابايت من البيانات. هذه بعض ملايين الطلبات في الثانية. هذه هي الآلاف من المجموعات. إنه واسع النطاق للغاية.
ولكن هناك فارق بسيط. إنه لا يعيش على محركات أقراص الشبكة الفاخرة، ولكن على أجهزة بسيطة إلى حد ما. وهناك بيئة اختبار مخصصة للأشياء الجديدة المثيرة للاهتمام.
وفي لحظة معينة في بيئة الاختبار تلقينا رسالة تشير إلى انتهاك الثوابت الداخلية لفهارس قاعدة البيانات.
الثابت هو نوع من العلاقة التي نتوقع أن نقيمها دائمًا.
الوضع حرج للغاية بالنسبة لنا. يشير إلى احتمال فقدان بعض البيانات. وفقدان البيانات هو شيء كارثي تمامًا.
الفكرة العامة التي نتبعها في قواعد البيانات المُدارة هي أنه حتى مع بذل الجهد، سيكون من الصعب فقدان البيانات. حتى إذا قمت بإزالتها عمدا، فستظل بحاجة إلى تجاهل غيابها لفترة طويلة من الزمن. أمن البيانات هو الدين الذي نتبعه بكل جدية.
وهنا ينشأ موقف يوحي بأنه قد يكون هناك موقف قد لا نكون مستعدين له. وبدأنا الاستعداد لهذا الوضع.
أول شيء فعلناه هو دفن جذوع الأشجار من هذه الآلاف من العناقيد. لقد اكتشفنا أي من المجموعات كانت موجودة على الأقراص التي تحتوي على برامج ثابتة بها مشكلات والتي كانت تفقد تحديثات صفحة البيانات. تم ترميز جميع أكواد بيانات Postgres. وقمنا بوضع علامة على تلك الرسائل التي تشير إلى انتهاكات الثوابت الداخلية باستخدام التعليمات البرمجية المصممة لاكتشاف تلف البيانات.
تم قبول هذا التصحيح عمليًا من قبل المجتمع دون الكثير من النقاش، لأنه في كل حالة محددة كان من الواضح أن شيئًا سيئًا قد حدث ويجب الإبلاغ عنه في السجل.
بعد ذلك، وصلنا إلى النقطة التي أصبح لدينا فيها مراقبة تقوم بمسح السجلات. وفي حالة وجود رسائل مشبوهة يقوم بإيقاظ الضابط المناوب ويقوم الضابط المناوب بإصلاحها.
لكن! يعد مسح السجلات عملية رخيصة لمجموعة واحدة ومكلفة بشكل كارثي لألف مجموعة.
لقد كتبنا امتدادا يسمى . يقوم بإنشاء عرض لقاعدة البيانات حيث يمكنك تحديد إحصائيات الأخطاء السابقة بتكلفة زهيدة وبسرعة. وإذا كنا بحاجة إلى إيقاظ الضابط المناوب، فسنكتشف ذلك دون مسح ملفات الجيجابايت، ولكن عن طريق استخراج بضعة بايتات من جدول التجزئة.
تم اعتماد هذا الامتداد، على سبيل المثال، في مستودع . إذا كنت ترغب في استخدامه، يمكنك تثبيته بنفسك. بالطبع انها مفتوحة المصدر.
ولكن هذا ليس كل شيء. لقد بدأنا باستخدام Amcheck، وهو امتداد أنشأه المجتمع، للعثور على الانتهاكات الثابتة في الفهارس.
واكتشفنا أنه إذا قمت بتشغيله على نطاق واسع، فستكون هناك أخطاء. بدأنا في إصلاحهم. لقد تم قبول تصحيحاتنا.
لقد اكتشفنا أن هذا الامتداد لا يمكنه تحليل فهارس GiST وGIT. لقد قدمنا لهم الدعم. لكن هذا الدعم لا يزال قيد المناقشة من قبل المجتمع، لأن هذه وظيفة جديدة نسبيًا وهناك الكثير من التفاصيل هناك.
واكتشفنا أيضًا أنه عند التحقق من فهارس الانتهاكات على قائد النسخ المتماثل، على السيد، كل شيء يعمل بشكل جيد، ولكن على النسخ المتماثلة، على التابع، البحث عن الفساد ليس فعالاً للغاية. لا يتم فحص جميع الثوابت. وقد أزعجنا أحد الثوابت كثيرًا. وقد أمضينا عامًا ونصف في التواصل مع المجتمع لتمكين هذا التحقق من النسخ المتماثلة.
لقد كتبنا تعليمات برمجية يجب أن تتبع جميع البروتوكولات. لقد ناقشنا هذا التصحيح لبعض الوقت مع بيتر جاغان من Crunchy Data. كان عليه تعديل شجرة B الموجودة في Postgres بشكل طفيف لقبول هذا التصحيح. تم قبوله. والآن أصبح التحقق من الفهارس على النسخ المتماثلة فعالاً بدرجة كافية لاكتشاف الانتهاكات التي واجهناها. أي أن هذه هي الانتهاكات التي يمكن أن تنتج عن أخطاء في البرامج الثابتة للقرص، وأخطاء في Postgres، وأخطاء في Linux kernel، ومشاكل في الأجهزة. قائمة واسعة جدًا من مصادر المشكلات التي كنا نستعد لها.
ولكن إلى جانب الفهارس، هناك جزء مثل الكومة، أي المكان الذي يتم فيه تخزين البيانات. وليس هناك الكثير من الثوابت التي يمكن التحقق منها.
لدينا امتداد يسمى Heapcheck. بدأنا في تطويره. وبالتوازي، بدأت شركة EnterpriseDB معنا أيضًا في كتابة وحدة أطلقوا عليها اسم Heapcheck بنفس الطريقة. نحن فقط أطلقنا عليه اسم PgHeapcheck، وقد أطلقوا عليه اسم Heapcheck فقط. لديهم وظائف مماثلة، وتوقيع مختلف قليلاً، ولكن بنفس الأفكار. لقد قاموا بتنفيذها بشكل أفضل قليلاً في بعض الأماكن. وقد نشروها في مصدر مفتوح من قبل.
ونحن الآن نعمل على تطوير توسعهم، لأنه لم يعد توسعهم، بل توسع المجتمع. وفي المستقبل، هذا جزء من النواة التي سيتم توفيرها للجميع حتى يتمكنوا من معرفة المشاكل المستقبلية مسبقًا.
وفي بعض الأماكن، توصلنا إلى استنتاج مفاده أن لدينا نتائج إيجابية كاذبة في أنظمة المراقبة لدينا. على سبيل المثال، نظام 1C. عند استخدام قاعدة بيانات، يكتب Postgres أحيانًا بيانات يمكنه قراءتها، ولكن لا يمكن لـ pg_dump قراءتها.
بدا هذا الموقف وكأنه فساد في نظام الكشف عن المشكلات لدينا. استيقظ الضابط المناوب. نظر الضابط المناوب إلى ما كان يحدث. وبعد مرور بعض الوقت، جاء أحد العملاء وقال إن لدي مشاكل. وأوضح المصاحبة ما هي المشكلة. لكن المشكلة تكمن في جوهر Postgres.
لقد وجدت مناقشة حول هذه الميزة. وكتب أننا واجهنا هذه الميزة وكانت غير سارة، استيقظ الشخص في الليل لمعرفة ما هو عليه.
أجاب المجتمع: "أوه، نحن بحاجة حقًا إلى إصلاح الأمر".
لدي تشبيه بسيط. إذا كنت تمشي في حذاء به حبة رمل، فمن حيث المبدأ، يمكنك المضي قدمًا - لا توجد مشكلة. إذا كنت تبيع الأحذية لآلاف الأشخاص، فلنصنع أحذية بدون رمل على الإطلاق. وإذا كان أحد مستخدمي حذائك سيشارك في سباق الماراثون، فأنت تريد أن تصنع حذاءًا جيدًا جدًا، ثم تقوم بتوسيع نطاقه ليشمل جميع المستخدمين. ومثل هؤلاء المستخدمين غير المتوقعين موجودون دائمًا في البيئة السحابية. هناك دائمًا مستخدمون يستغلون المجموعة بطريقة أصلية. يجب عليك الاستعداد دائمًا لذلك.
ما الذي تعلمناه هنا؟ لقد تعلمنا شيئًا بسيطًا: الشيء الأكثر أهمية هو أن نوضح للمجتمع أن هناك مشكلة. فإذا أدرك المجتمع المشكلة، تنشأ المنافسة الطبيعية لحل المشكلة. لأن الجميع يريد حل مشكلة مهمة. يفهم جميع البائعين، جميع المتسللين أنهم يستطيعون أن يدوسوا على هذه أشعل النار، لذلك يريدون القضاء عليهم.
إذا كنت تعمل على مشكلة ما، ولكنها لا تزعج أحداً غيرك، ولكنك تعمل عليها بشكل منهجي وتعتبر في النهاية مشكلة، فسيتم قبول طلب السحب الخاص بك بالتأكيد. سيتم قبول التصحيح الخاص بك، وستتم مراجعة تحسيناتك أو حتى طلبات التحسينات من قبل المجتمع. وفي نهاية المطاف، نحن نجعل قاعدة البيانات أفضل لبعضنا البعض.
قاعدة بيانات مثيرة للاهتمام هي Greenplum. إنها قاعدة بيانات متوازية للغاية تعتمد على قاعدة بيانات Postgres، التي أعرفها جيدًا.
ويتمتع Greenplum بوظيفة مثيرة للاهتمام - إضافة جداول محسنة. هذه هي الجداول التي يمكنك إضافتها بسرعة. يمكن أن تكون إما عمودية أو صفية.
ولكن لم يكن هناك تجميع، أي لم تكن هناك وظيفة يمكنك من خلالها ترتيب البيانات الموجودة في الجدول وفقًا للترتيب الموجود في أحد الفهارس.
جاء إليّ رجال سيارة الأجرة وقالوا: "أندري، أنت تعرف بوستجرس. وهنا هو نفسه تقريبا. التبديل إلى 20 دقيقة. خذها وافعلها." اعتقدت أن نعم، أعرف Postgres، والتبديل لمدة 20 دقيقة - أحتاج إلى القيام بذلك.
لكن لا، لم تكن 20 دقيقة، لقد كتبتها على مدى أشهر. في مؤتمر PgConf.روسيا، تواصلت مع هيكي ليناكانجاس من شركة Pivotal وسألته: "هل هناك أي مشاكل في هذا؟ لماذا لا يوجد تجميع جدول محسّن للإلحاق؟ يقول: "أنت تأخذ البيانات. أنت تقوم بالفرز، وإعادة الترتيب. إنها مجرد وظيفة." أنا: "أوه، نعم، عليك فقط أن تأخذها وتفعلها." فيقول: نعم، نحتاج إلى أيدي حرة للقيام بذلك. اعتقدت أنني بالتأكيد بحاجة للقيام بذلك.
وبعد بضعة أشهر قدمت طلب سحب لتنفيذ هذه الوظيفة. تمت مراجعة طلب السحب هذا بواسطة Pivotal مع المجتمع. وبطبيعة الحال، كانت هناك أخطاء.
ولكن الشيء الأكثر إثارة للاهتمام هو أنه عندما تم دمج طلب السحب هذا، تم العثور على أخطاء في Greenplum نفسه. لقد وجدنا أن جداول الكومة تؤدي في بعض الأحيان إلى كسر المعاملات عند تجميعها. وهذا شيء يجب إصلاحه. وهي في المكان الذي لمسته للتو. وكان رد فعلي الطبيعي - حسنًا، دعني أفعل هذا أيضًا.
لقد أصلحت هذا الخلل. أرسل طلب سحب إلى المثبتين. قتل.
وبعد ذلك اتضح أنه يجب الحصول على هذه الوظيفة في إصدار Greenplum لـ PostgreSQL 12. أي أن المغامرة التي تبلغ مدتها 20 دقيقة تستمر بمغامرات جديدة مثيرة للاهتمام. كان من المثير للاهتمام لمس التطور الحالي، حيث يقوم المجتمع بقطع الميزات الجديدة والأكثر أهمية. انه مجمد.
لكن الأمر لم ينته عند هذا الحد. بعد كل شيء، اتضح أننا بحاجة إلى كتابة وثائق لكل هذا.
بدأت في كتابة الوثائق. لحسن الحظ، جاء المخرجون الوثائقيون من Pivotal. اللغة الإنجليزية هي لغتهم الأم. لقد ساعدوني في التوثيق. في الواقع، قاموا هم أنفسهم بإعادة كتابة ما اقترحته إلى اللغة الإنجليزية الحقيقية.
وهنا يبدو أن المغامرة انتهت. وهل تعرف ماذا حدث بعد ذلك؟ جاء إليّ رجال التاكسي وقالوا: "لا تزال هناك مغامرتان، مدة كل منهما 10 دقائق". وماذا يجب أن أقول لهم؟ قلت ذلك الآن سأقدم تقريرا على نطاق واسع، ثم سنرى مغامراتك، لأن هذه وظيفة مثيرة للاهتمام.
ماذا تعلمنا من هذه الحالة؟ نظرًا لأن العمل مع المصادر المفتوحة يعني دائمًا العمل مع شخص معين، فهو دائمًا يعمل مع المجتمع. لأنه في كل مرحلة عملت مع بعض المطورين، وبعض المختبرين، وبعض المتسللين، وبعض الأفلام الوثائقية، وبعض المهندسين المعماريين. لم أعمل مع Greenplum، بل عملت مع أشخاص حول Greenplum.
لكن! هناك نقطة أخرى مهمة - إنه مجرد عمل. أي أنك تأتي وتشرب القهوة وتكتب الكود. جميع أنواع الثوابت البسيطة تعمل. افعل ذلك بشكل طبيعي - سيكون الأمر على ما يرام! وهي عمل مثير للاهتمام. هناك طلب لهذا العمل من عملاء Yandex.Cloud، ومستخدمي مجموعاتنا داخل Yandex وخارجها. وأعتقد أن عدد المشاريع التي نشارك فيها سوف يزيد، كما سيزداد عمق مشاركتنا.
هذا كل شئ. دعنا ننتقل إلى الأسئلة.
جلسة الأسئلة
مرحبًا! لدينا جلسة أسئلة وأجوبة أخرى. وفي الاستوديو أندريه بورودين. هذا هو الشخص الذي أخبرك للتو عن مساهمة Yandex.Cloud وYandex في المصادر المفتوحة. تقريرنا الآن لا يتعلق بالسحابة بالكامل، ولكننا في نفس الوقت نعتمد على مثل هذه التقنيات. لولا ما فعلتموه داخل Yandex لن تكون هناك خدمة في Yandex.Cloud، فشكرًا لكم مني شخصيًا. والسؤال الأول من البث: “ما هو مكتوب على كل مشروع من المشاريع التي ذكرتها؟”
نظام النسخ الاحتياطي في WAL-G مكتوب باللغة Go. هذا أحد المشاريع الجديدة التي عملنا عليها. عمره حرفيا 3 سنوات فقط. وغالبًا ما تتعلق قاعدة البيانات بالموثوقية. وهذا يعني أن قواعد البيانات قديمة جدًا وعادة ما تكون مكتوبة بلغة C. بدأ مشروع Postgres منذ حوالي 30 عامًا. ثم كان C89 هو الاختيار الصحيح. ويتم كتابة Postgres عليه. عادةً ما تتم كتابة قواعد البيانات الأكثر حداثة مثل ClickHouse بلغة C++. يعتمد تطوير النظام بالكامل على C وC++.
سؤال من مديرنا المالي، المسؤول عن النفقات في Cloud: "لماذا تنفق Cloud الأموال على دعم المصادر المفتوحة؟"
هناك إجابة بسيطة للمدير المالي هنا. نحن نفعل هذا لجعل خدماتنا أفضل. ما هي الطرق التي يمكننا أن نفعل ما هو أفضل؟ يمكننا القيام بالأشياء بشكل أكثر كفاءة وأسرع، وجعل الأشياء أكثر قابلية للتطوير. لكن بالنسبة لنا، هذه القصة تتعلق في المقام الأول بالموثوقية. على سبيل المثال، في نظام النسخ الاحتياطي، نقوم بمراجعة 100% من التصحيحات التي تنطبق عليه. نحن نعرف ما هو الرمز. ونحن نشعر براحة أكبر في طرح إصدارات جديدة للإنتاج. وهذا يعني أولاً وقبل كل شيء أن الأمر يتعلق بالثقة والاستعداد للتطوير والموثوقية
سؤال آخر: "هل تختلف متطلبات المستخدمين الخارجيين الذين يعيشون في Yandex.Cloud عن المستخدمين الداخليين الذين يعيشون في السحابة الداخلية؟"
ملف تعريف التحميل مختلف بالطبع. ولكن من وجهة نظر قسمي، يتم إنشاء جميع الحالات الخاصة والمثيرة للاهتمام على حمل غير قياسي. من المرجح أن يتم العثور على المطورين ذوي الخيال، والمطورين الذين يقومون بما هو غير متوقع، داخليًا وخارجيًا. في هذا الصدد، نحن جميعا نفس الشيء تقريبا. وربما تكون الميزة المهمة الوحيدة داخل تشغيل قواعد بيانات Yandex هي أن لدينا تعليمًا داخل Yandex. في مرحلة ما، تصبح بعض مناطق التوفر في الظل تمامًا، ويجب أن تستمر جميع خدمات Yandex في العمل بطريقة أو بأخرى على الرغم من ذلك. هذا فرق بسيط. ولكنه يخلق الكثير من التطوير البحثي على واجهة قاعدة البيانات ومكدس الشبكة. وبخلاف ذلك، تنشئ عمليات التثبيت الخارجية والداخلية نفس طلبات الميزات وطلبات مماثلة لتحسين الموثوقية والأداء.
السؤال التالي: "ما هو شعورك الشخصي تجاه حقيقة أن الكثير مما تفعله تستخدمه السحب الأخرى؟" لن نقوم بتسمية مشاريع محددة، ولكن العديد من المشاريع التي تم تنفيذها في Yandex.Cloud يتم استخدامها في سحابات أشخاص آخرين.
ان هذا رائع. أولاً، إنها علامة على أننا قمنا بشيء صحيح. ويخدش الأنا. ونحن أكثر ثقة بأننا اتخذنا القرار الصحيح. من ناحية أخرى، هذا هو الأمل في أن يجلب لنا هذا في المستقبل أفكارًا جديدة وطلبات جديدة من مستخدمي الطرف الثالث. يتم إنشاء معظم المشكلات على GitHub بواسطة مسؤولي النظام الفرديين، ومسؤولي قواعد البيانات الفرديين، والمهندسين المعماريين الفرديين، والمهندسين الفرديين، ولكن في بعض الأحيان يأتي الأشخاص ذوو الخبرة المنهجية ويقولون إنه في 30٪ من الحالات المعينة لدينا هذه المشكلة ودعونا نفكر في كيفية حلها. وهذا هو ما نتطلع إليه أكثر. ونحن نتطلع إلى تبادل الخبرات مع المنصات السحابية الأخرى.
لقد تحدثت كثيرا عن الماراثون. أعلم أنك شاركت في ماراثون في موسكو. نتيجة ل؟ تفوقت على الرجال من PostgreSQL؟
لا، أوليغ بارتونوف يركض بسرعة كبيرة. أنهى أمامي بساعة. بشكل عام، أنا سعيد بالمدى الذي وصلت إليه. بالنسبة لي، مجرد إنهاء المباراة كان بمثابة إنجاز. بشكل عام، من المدهش أن يكون هناك الكثير من العدائين في مجتمع postgres. يبدو لي أن هناك علاقة ما بين الرياضات الهوائية والرغبة في برمجة الأنظمة.
هل تقول أنه لا يوجد عدائين في ClickHouse؟
وأنا أعلم على وجه اليقين أنهم هناك. ClickHouse هي أيضًا قاعدة بيانات. بالمناسبة، أوليغ يكتب لي الآن: "هل نذهب للركض بعد التقرير؟" هذا هو فكرة عظيمة.
سؤال آخر من البث من نيكيتا: "لماذا أصلحت الخلل في Greenplum بنفسك ولم تعطيه للصغار؟" صحيح أنه ليس من الواضح تمامًا ما هو الخطأ وفي أي خدمة، ولكن من المحتمل أنه يعني الخدمة التي تحدثت عنها.
نعم، من حيث المبدأ، كان من الممكن أن تعطى لشخص ما. لقد كان مجرد الرمز الذي قمت بتغييره للتو. وكان من الطبيعي الاستمرار في القيام بذلك على الفور. من حيث المبدأ، فكرة تبادل الخبرات مع الفريق فكرة جيدة. سنقوم بالتأكيد بمشاركة مهام Greenplum بين جميع أعضاء قسمنا.
وبما أننا نتحدث عن الصغار، وهنا سؤال. قرر الشخص إنشاء الالتزام الأول في Postgres. ما الذي يجب عليه فعله للقيام بالالتزام الأول؟
هذا سؤال مثير للاهتمام: "من أين نبدأ؟" عادةً ما يكون من الصعب جدًا البدء بشيء ما في النواة. في Postgres، على سبيل المثال، هناك قائمة المهام. لكن في الواقع، هذه ورقة مما حاولوا القيام به، لكنهم لم ينجحوا. هذه أشياء معقدة. وعادة ما يمكنك العثور على بعض الأدوات المساعدة في النظام البيئي، وبعض الامتدادات التي يمكن تحسينها، والتي تجذب اهتمامًا أقل من مطوري kernel. وبناء على ذلك، هناك المزيد من النقاط للنمو هناك. في برنامج Google Summer of Code، يطرح مجتمع postgres كل عام العديد من المواضيع المختلفة التي يمكن معالجتها. هذا العام كان لدينا، على ما أعتقد، ثلاثة طلاب. حتى أن أحدهم كتب في WAL-G حول موضوعات مهمة لـ Yandex. في Greenplum، كل شيء أبسط مما هو عليه في مجتمع Postgres، لأن قراصنة Greenplum يعاملون طلبات السحب بشكل جيد للغاية ويبدأون في المراجعة على الفور. يستغرق إرسال التصحيح إلى Postgres بضعة أشهر، لكن Greenplum سيأتي خلال يوم واحد ويرى ما قمت به. شيء آخر هو أن Greenplum بحاجة إلى حل المشاكل الحالية. لا يتم استخدام Greenplum على نطاق واسع، لذا فإن العثور على مشكلتك أمر صعب للغاية. وقبل كل شيء، علينا حل المشاكل بالطبع.
المصدر: www.habr.com