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

PostgreSQL وتسجيل إعدادات التناسق لكل اتصال معين
في Compose ، يتعين علينا التعامل مع العديد من قواعد البيانات ، وهو ما يتيح لنا الفرصة للتعرف على المزيد حول وظائفها وعيوبها. بينما نتعلم أن نحب الخصائص الوظيفية لقواعد البيانات الجديدة ، نبدأ في بعض الأحيان بالتفكير في مدى جودة وجود وظائف مماثلة في أدوات أكثر نضجًا كنا نعمل معها لفترة طويلة. كانت إحدى الميزات الجديدة التي أراد PostgreSQL رؤيتها هي اتساق الكتابة المخصص عبر المجموعة بالكامل. وكما اتضح فيما بعد ، لدينا بالفعل ، واليوم نريد أن نطلعكم على معلومات حول كيفية استخدامها.

لماذا أحتاج هذا؟

كيف يجب أن تتصرف كتلة يعتمد على التطبيق الخاص بك. خذ ، على سبيل المثال ، طلبًا لدفع الفواتير. ستحتاج إلى الاتساق بنسبة 100٪ في المجموعة ، لذا سيتعين عليك تمكين عمليات التزامن بحيث تنتظر قاعدة البيانات الخاصة بك إجراء جميع التغييرات. ومع ذلك ، إذا كان التطبيق الخاص بك عبارة عن شبكة اجتماعية سريعة النمو ، فربما تفضل الاتساق بنسبة 100٪ مع استجابة سريعة. لتحقيق ذلك ، يمكنك استخدام commits غير متزامن في نظام المجموعة الخاصة بك.

تلبية الحل الوسط

عليك تسوية بين تناسق البيانات والأداء. الخطوات PostgreSQL من الاتساق ، لأن التكوين الافتراضي في هذه الحالة يمكن التنبؤ به ودون مفاجآت غير متوقعة. والآن سوف نتعرف على الحلول الوسط.

حل وسط: الأداء

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

حل وسط 2: الاتساق

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

في الوضع المتزامن ، هذا لا يحدث. في حالة فشل القائد ، يتم تحديث جميع النسخ المتماثلة ، حيث يجب تأكيد أي سجل مؤكد على القائد في النسخ المتماثلة. ومن هنا - التماسك.

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

حل وسط 3: الفشل

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

اتصال واحد لكل معاملة؟

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

كل هذه القرارات ، بالطبع ، يتم اتخاذها من قبل مطور التطبيق. ستساعد القرارات الصحيحة حول متى يتم تطبيق هذا أو ذاك النهج في الحصول على أقصى استفادة من الكتلة. من المهم أن يقوم المطور بالتبديل بينها على مستوى SQL للاتصالات والمعاملات.

توفير السيطرة في الممارسة

بشكل افتراضي ، يوفر PostgreSQL الاتساق. يتم التحكم في هذا بواسطة معلمة خادم synchronous_commit . بشكل افتراضي ، يتم تشغيله ، لكن لديه ثلاثة خيارات أخرى: local ، أو off ، أو off .

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

مع الأخذ في الاعتبار نطاق الخيارات المتاحة ، نختار السلوك ونتذكر أنه on السجلات المتزامنة ، سنختار local لعمليات ارتكاب غير متزامنة عبر الشبكة ، مع ترك الالتزامات المحلية متزامنة.

الآن ، سوف نخبرك بكيفية تكوين هذا في لحظة ، ولكن تخيل أننا قمنا بتعيين synchronous_commit الالتزام local للخادم. لقد سألنا أنفسنا ما إذا كان من الممكن تغيير المعلمة synchronous_commit أثناء الطيران ، واتضح أنه ليس من الممكن فقط ، بل هناك طريقتان للقيام بذلك. الأول هو إعداد جلسة الاتصال الخاصة بك على النحو التالي:

 SET SESSION synchronous_commit TO ON; // Your writes go here 

ستؤكد كافة السجلات اللاحقة في الجلسة عمليات الكتابة للنسخ المتماثلة قبل إرجاع نتيجة إيجابية إلى العميل المتصل. ما لم يكن ، بالطبع ، يمكنك تغيير إعداد synchronous_commit مرة أخرى. يمكنك حذف جزء SESSION من الأمر لأنه سيكون بالقيمة الافتراضية.

الطريقة الثانية جيدة عندما تريد فقط التأكد من حصولك على النسخ المتماثل المتزامن لمعاملة واحدة. في العديد من قواعد بيانات NoSQL ، لا يوجد مفهوم للمعاملات ، ولكنه موجود في PostgreSQL. في هذه الحالة ، تبدأ المعاملة ، ثم تقوم بتعيين synchronous_commit على on قبل الكتابة إلى المعاملة. COMMIT بالمعاملة باستخدام أي قيمة من معلمة synchronous_commit التي تم تعيينها في تلك اللحظة ، على الرغم من أنه من الأفضل تعيين المتغير مقدمًا للتأكد من أن المطورين الآخرين يفهمون أن السجلات غير متزامنة.

 BEGIN; SET LOCAL synchronous_commit TO ON; // Your writes go here COMMIT; 

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

إعداد PostgreSQL

قبل ذلك ، تخيلنا وجود نظام PostgreSQL مع ضبط synchronous_commit إلى local . لكي يكون هذا حقيقيًا على جانب الخادم ، ستحتاج إلى تعيين معلمتين لتكوين الخادم. ستتولى معلمة synchronous_standby_names أخرى عندما تكون synchronous_commit قيد on . إنه يحدد النسخ المتماثلة المؤهلة لعمليات التزامن ، وسنقوم بتعيينها على * ، مما يعني أن جميع النسخ المتماثلة ممكّنة. عادة ما يتم تكوين هذه القيم في ملف التكوين عن طريق إضافة:

 synchronous_commit = local synchronous_standby_names='*' 

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

إذا تابعت تطوير مشروع Governor ، فقد تلاحظ بعض التغييرات الحديثة ( 1 ، 2 ) التي سمحت لمستخدمي Governor باختبار هذه المعلمات والتحكم في تناسقها.

بضع كلمات أخرى ...

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

يمكن تغيير هذه المعلمة في أي وقت. يتم تحديد سلوك أي معاملة من خلال الإعداد الساري عند الالتزام. لذلك ، من الممكن والمفيد الالتزام بالالتزام بشكل متزامن لبعض المعاملات ، وبشكل غير متزامن مع المعاملات الأخرى. على سبيل المثال ، لفرض معاملة multistatement على الالتزام بشكل غير متزامن عندما تكون القيمة الافتراضية معاكسة ، قم بتعيين SET LOCAL synchronous_commit TO OFF في المعاملة.

مع هذا التعديل البسيط في ملف التكوين ، منحنا المستخدمين القدرة على التحكم في تناسقهم وأدائهم.