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

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

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

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

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

يجب عليك إجراء مقايضات بين اتساق البيانات والأداء. يبتعد PostgreSQL عن الاتساق لأن التكوين الافتراضي يمكن التنبؤ به وبدون مفاجآت غير متوقعة. الآن دعونا نلقي نظرة على التنازلات.

المقايضة 1: الأداء

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

المقايضة 2: الاتساق

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

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

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

المفاضلة 3: الأعطال

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

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

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

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

ضمان السيطرة في الممارسة العملية

بشكل افتراضي، يوفر PostgreSQL الاتساق. يتم التحكم في ذلك بواسطة معلمة الخادم synchronous_commit. افتراضيا هو في الموقف on، ولكن لديه ثلاثة خيارات أخرى: local, remote_write أو 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، نقوم بإنشاء نظام تظل فيه الأقراص المحلية متزامنة، ولكن عمليات النسخ المتماثلة للشبكة تكون غير متزامنة افتراضيًا. ما لم نقرر بالطبع أن نجعل هذه الالتزامات متزامنة، كما هو موضح أعلاه.

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

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

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

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

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

المصدر: www.habr.com