إعادة تعريف تستند إلى الإصدار: هل من الممكن في الإنتاج؟

تحية! اسمي أنتونينا ، أنا مطور أوراكل لقسم تكنولوجيا المعلومات في مختبر Sportmaster. لقد كنت أعمل هنا منذ عامين فقط ، لكن بفضل فريق ودود ، وفريق متقارب ، ونظام توجيه ، وتدريب الشركات ، تراكمت الكتلة الحرجة عندما كنت لا أريد فقط أن أستهلك المعرفة ، ولكن أيضًا تبادل تجربتي.



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

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

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

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

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



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

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

مرة أخرى ، يمكن تقسيم هذا التحديث إلى فئتين أخريين.

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

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



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



ما هو الحل المقترح؟ بدءًا من الإصدار 11.2 من Oracle ، يتم تقديم تقنية Redefenition المستندة إلى الإصدار ويتم تقديم مفاهيم مثل الإصدار والكائنات القابلة للإصدار وطريقة عرض الإصدار ومشغل الإصدارات المتقاطعة. سمحنا لأنفسنا بترجمة مثل "versioning". بشكل عام ، يمكن تسمية تقنية EBR ذات الامتداد بإصدار كائنات DBMS داخل DBMS نفسها.

إذن ما هو الإصدار ككيان؟

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



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

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



ماذا يحدث لهياكل البيانات وما علاقة عرض الإصدار بها؟



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



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



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

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



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



ما هي القيود المفروضة؟ وهذا جيد ، أوراكل ، أوراكل الممتازة ، أوراكل الممتازة: لقد توصلوا إلى شيء رائع. القيد الأول في الوقت الحالي هو كائنات من النوع الذي تم إصداره ، وهي كائنات PL / SQL ، وهي الإجراءات والحزم والوظائف والمشغلات وما إلى ذلك. المرادفات هي الإصدارات وطرق إصدارها.

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



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

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

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

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

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



آمل أن تفهم الآن تقريبًا كيف يعمل هذا. إذا قررت - "نعم ، نريد أن نلمسها" - ما الذي يجب القيام به للتبديل إلى استخدام هذه التكنولوجيا؟

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

علاوة على ذلك ، بطبيعة الحال ، يتم منح المخطط المحدد امتيازات إصدار.
بعد ذلك ، نعيد تسمية الجدول. لماذا يتم ذلك؟ فقط لحماية كائنات التعليمات البرمجية PL / SQL الخاصة بنا من تعديل الجداول.

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

بعد ذلك ، تفوق مشغلات DML من الجداول إلى طرق العرض التي تم إصدارها (نعم ، طرق العرض التي تم إصدارها تتيح لنا تعليق المشغلات عليها). ربما نلغي المنح المقدمة من الجداول ونمنحها للآراء التي تم إنشاؤها حديثًا ... نظريًا ، كل هذه النقاط كافية ، علينا فقط إعادة ترجمة كود PL / SQL والآراء التابعة.

I-and-and-and-and ... وبطبيعة الحال ، الاختبارات والاختبارات وأكبر عدد ممكن من الاختبارات. لماذا الاختبارات؟ لا يمكن أن يكون بهذه البساطة. ماذا نتعثر؟

هذا هو ما سوف يكون منصبي الثاني .