في وقت ما في المستقبل البعيد ، ستكون الإزالة التلقائية للبيانات غير الضرورية إحدى المهام الهامة لنظام إدارة قواعد البيانات [1]. في غضون ذلك ، نحن أنفسنا بحاجة إلى الاهتمام بحذف أو نقل البيانات غير الضرورية إلى أنظمة تخزين أقل تكلفة. لنفترض أنك قررت حذف بضعة ملايين من الصفوف. مهمة بسيطة إلى حد ما ، خاصة إذا كانت الحالة معروفة وهناك فهرس مناسب. "حذف من جدول 1 حيث col1 =: القيمة" - ما الذي يمكن أن يكون أبسط ، أليس كذلك؟
فيديو:
-
أنا عضو في لجنة برنامج Highload منذ العام الأول ، أي منذ عام 2007.
-
وأنا أعمل مع Postgres منذ 2005. استخدمته في العديد من المشاريع.
-
المجموعة مع RuPostges أيضًا منذ عام 2007.
-
لقد زاد عدد المشاركين في Meetup إلى 2100+. إنها الثانية في العالم بعد نيويورك ، وتجاوزتها سان فرانسيسكو لفترة طويلة.
-
لقد عشت في كاليفورنيا لعدة سنوات. أتعامل أكثر مع الشركات الأمريكية ، بما في ذلك الشركات الكبيرة. هم مستخدمون نشطون لـ Postgres. وهناك كل أنواع الأشياء المثيرة للاهتمام.
هي شركتي. نحن نعمل على أتمتة المهام التي تقضي على تباطؤ التنمية.
إذا كنت تفعل شيئًا ما ، ففي بعض الأحيان يكون هناك نوع من المقابس حول Postgres. لنفترض أنك بحاجة إلى الانتظار حتى يقوم المسؤول بإعداد منصة اختبار لك ، أو أنك بحاجة إلى انتظار DBA للرد عليك. ونجد مثل هذه الاختناقات في عملية التطوير والاختبار والإدارة ونحاول القضاء عليها بمساعدة الأتمتة والأساليب الجديدة.
كنت مؤخرًا في VLDB في لوس أنجلوس. هذا هو أكبر مؤتمر لقواعد البيانات. وكان هناك تقرير يفيد بأن نظام إدارة قواعد البيانات (DBMS) في المستقبل لن يخزن البيانات فحسب ، بل سيحذفها أيضًا تلقائيًا. هذا موضوع جديد.
هناك المزيد والمزيد من البيانات في عالم زيتابايت - أي 1،000،000 بيتابايت. والآن يُقدر بالفعل أن لدينا أكثر من 100 زيتابايت من البيانات المخزنة في العالم. وهناك المزيد والمزيد منهم.
وماذا تفعل به؟ من الواضح أنه يجب إزالته. هنا رابط لهذا التقرير المثير للاهتمام. ولكن حتى الآن لم يتم تنفيذ ذلك في نظام إدارة قواعد البيانات.
أولئك الذين يستطيعون عد النقود يريدون شيئين. يريدون منا أن نحذف ، لذلك من الناحية الفنية يجب أن نكون قادرين على القيام بذلك.
ما سأقوله بعد ذلك هو بعض المواقف المجردة التي تتضمن مجموعة من المواقف الحقيقية ، أي نوع من التجميع لما حدث بالفعل لي ولقواعد البيانات المحيطة عدة مرات ، سنوات عديدة. أشعل النار في كل مكان والجميع يخطو عليهم طوال الوقت.
لنفترض أن لدينا قاعدة أو عدة قواعد تنمو. ومن الواضح أن بعض السجلات هراء. على سبيل المثال ، بدأ المستخدم في فعل شيء ما هناك ، لكنه لم يكمله. وبعد مرور بعض الوقت ، نعلم أنه لم يعد من الممكن تخزين هذا غير المكتمل. أي أننا نرغب في تنظيف بعض الأشياء المهملة لتوفير المساحة وتحسين الأداء وما إلى ذلك.
بشكل عام ، تتمثل المهمة في أتمتة حذف أشياء محددة ، أسطر محددة في بعض الجداول.
ولدينا مثل هذا الطلب ، والذي سنتحدث عنه اليوم ، وهو إزالة القمامة.
لقد طلبنا من مطور متمرس القيام بذلك. لقد أخذ هذا الطلب وفحصه بنفسه - كل شيء يعمل. تم اختباره على الإطلاق - كل شيء على ما يرام. توالت - كل شيء يعمل. مرة واحدة في اليوم نقوم بتشغيلها - كل شيء على ما يرام.
قاعدة البيانات تنمو وتنمو. يبدأ برنامج الحذف اليومي في العمل بشكل أبطأ قليلاً.
ثم نفهم أن لدينا الآن شركة تسويق وستكون حركة المرور أكبر عدة مرات ، لذلك قررنا إيقاف الأشياء غير الضرورية مؤقتًا. وننسى العودة.
بعد بضعة أشهر تذكروا. وهذا المطور استقال أو مشغول بشيء آخر ، أوعز إلى شخص آخر بإعادته.
قام بفحص التطوير ، على مرحلة الإعداد - كل شيء على ما يرام. بطبيعة الحال ، ما زلت بحاجة إلى تنظيف ما تراكم. فحص كل شيء يعمل.
ماذا حدث بعد ذلك؟ ثم ينهار كل شيء بالنسبة لنا. يسقط بحيث يسقط كل شيء في مرحلة ما. الجميع في حالة صدمة ، ولا أحد يفهم ما يحدث. ثم اتضح أن الأمر كان في هذا الحذف.
هناك خطأ ما؟ فيما يلي قائمة بما يمكن أن يحدث بشكل خاطئ. أي من هؤلاء هو الأهم؟
-
على سبيل المثال ، لم تكن هناك مراجعة ، أي أن خبير DBA لم ينظر إليها. سيجد المشكلة على الفور بعيون من ذوي الخبرة ، وإلى جانب ذلك ، لديه حق الوصول إلى المنتج ، حيث تراكمت عدة ملايين من الخطوط.
-
ربما قاموا بفحص شيء خاطئ.
-
ربما تكون الأجهزة قديمة وتحتاج إلى ترقية هذه القاعدة.
-
أو هناك خطأ ما في قاعدة البيانات نفسها ، ونحن بحاجة إلى الانتقال من Postgres إلى MySQL.
-
أو ربما هناك خطأ ما في العملية.
-
ربما توجد بعض الأخطاء في تنظيم العمل وتحتاج إلى طرد شخص ما وتوظيف أفضل الأشخاص؟
لم يكن هناك فحص DBA. إذا كان هناك DBA ، فسيشاهد هذه الملايين من السطور وحتى بدون أي تجارب سيقول: "إنهم لا يفعلون ذلك." لنفترض أنه إذا كان هذا الرمز موجودًا في GitLab و GitHub وستكون هناك عملية مراجعة للكود ولم تكن هذه العملية ستتم بدون موافقة DBA على المنتج ، فمن الواضح أن DBA سيقول: "لا يمكن القيام بذلك. "
وقد يقول إنك ستواجه مشاكل مع قرص الإدخال والإخراج وستصبح جميع العمليات مجنونة ، وقد تكون هناك أقفال ، كما أنك ستمنع الفراغ التلقائي لبضعة دقائق ، لذلك هذا ليس جيدًا.
الخطأ الثاني - لقد تحققوا في المكان الخطأ. لقد رأينا بعد حقيقة أن الكثير من البيانات غير المرغوب فيها تراكمت على المنتج ، ولكن لم يقم المطور بتجميع البيانات في قاعدة البيانات هذه ، ولم يقم أحد بإنشاء هذا البريد غير الهام أثناء التدريج. وفقًا لذلك ، كان هناك 1 سطر تعمل بسرعة.
نحن نفهم أن اختباراتنا ضعيفة ، أي أن العملية التي تم إنشاؤها لا تكتشف المشاكل. لم يتم إجراء تجربة قاعدة بيانات مناسبة.
يفضل إجراء تجربة مثالية على نفس الجهاز. ليس من الممكن دائمًا القيام بذلك على نفس الجهاز ، ولكن من المهم جدًا أن تكون نسخة كاملة الحجم من قاعدة البيانات. هذا ما كنت أبشر به منذ عدة سنوات. وقبل عام تحدثت عن هذا ، يمكنك مشاهدته على موقع يوتيوب.
ربما معداتنا سيئة؟ إذا نظرت ، ثم قفز الكمون. لقد رأينا أن الاستخدام هو 100٪. بالطبع ، إذا كانت هذه محركات أقراص NVMe حديثة ، فمن المحتمل أن يكون الأمر أسهل بالنسبة لنا. وربما لن نستلقي منه.
إذا كانت لديك سحاب ، فسيتم إجراء الترقية بسهولة هناك. أثار النسخ المتماثلة الجديدة على الأجهزة الجديدة. التحول. وكل شيء على ما يرام. سهل جدا.
هل من الممكن لمس الأقراص الأصغر بطريقة أو بأخرى؟ وهنا ، فقط بمساعدة DBA ، نتعمق في موضوع معين يسمى ضبط نقطة التفتيش. اتضح أنه لم يكن لدينا ضبط لنقاط التفتيش.
ما هي نقطة التفتيش؟ إنه موجود في أي نظام DBMS. عندما يكون لديك بيانات في الذاكرة تتغير ، لا تتم كتابتها على الفور على القرص. تتم كتابة المعلومات التي تم تغييرها أولاً في سجل الكتابة المسبقة. وفي مرحلة ما ، يقرر نظام إدارة قواعد البيانات (DBMS) أن الوقت قد حان لتفريغ الصفحات الحقيقية على القرص ، بحيث إذا كان لدينا فشل ، فيمكننا تقليل عمليات REDO. إنها مثل لعبة. إذا قتلنا سنبدأ اللعبة من آخر نقطة تفتيش. وكل نظم إدارة قواعد البيانات (DBMS) تنفذها.
الإعدادات في Postgres متخلفة. وهي مصممة لمجموعات من البيانات والمعاملات التي تتراوح من 10 إلى 15 عامًا. ونقطة التفتيش ليست استثناء.
فيما يلي المعلومات الواردة في تقرير فحص Postgres ، أي الفحص الصحي التلقائي. وهنا بعض قاعدة البيانات من عدة تيرابايت. ويمكن ملاحظة أن نقاط التفتيش فرضت قسراً في 90٪ من الحالات.
ماذا يعني ذلك؟ هناك نوعان من الإعدادات هناك. يمكن أن تأتي نقطة التفتيش عن طريق المهلة ، على سبيل المثال ، في 10 دقائق. أو قد يحدث عندما يتم ملء الكثير من البيانات.
ويتم تعيين max_wal_saze افتراضيًا على 1 غيغابايت. في الواقع ، يحدث هذا بالفعل في Postgres بعد 300-400 ميغا بايت. لقد قمت بتغيير الكثير من البيانات وحدثت نقطة التفتيش الخاصة بك.
وإذا لم يضبطها أحد ، ونمت الخدمة ، وكسبت الشركة الكثير من المال ، فلديها الكثير من المعاملات ، ثم تأتي نقطة التفتيش مرة واحدة في الدقيقة ، وأحيانًا كل 30 ثانية ، وأحيانًا تتداخل. هذا سيء للغاية.
ونحن بحاجة إلى التأكد من أنه يأتي في كثير من الأحيان. أي يمكننا رفع max_wal_size. وسوف يأتي بشكل أقل تواترا.
لكننا طورنا منهجية كاملة لكيفية القيام بذلك بشكل صحيح ، أي كيفية اتخاذ قرار بشأن اختيار الإعدادات ، بشكل واضح على أساس بيانات محددة.
وفقًا لذلك ، نقوم بإجراء سلسلتين من التجارب على قواعد البيانات.
السلسلة الأولى - نقوم بتغيير max_wal_size. ونقوم بعملية مكثفة. أولاً ، نقوم بذلك على الإعداد الافتراضي البالغ 1 غيغابايت. ونقوم بحذف ضخم لعدة ملايين من السطور.
يمكنك أن ترى مدى صعوبة الأمر بالنسبة لنا. نرى أن قرص الإدخال / الإخراج سيء للغاية. نحن ننظر في عدد WALs التي أنشأناها ، لأن هذا مهم جدًا. لنرى كم مرة حدث الحاجز. ونرى أنه ليس جيدًا.
بعد ذلك نقوم بزيادة max_wal_size. نكرر. نزيد ونكرر. ومرات عديدة. من حيث المبدأ ، 10 نقاط جيدة ، حيث 1 ، 2 ، 4 ، 8 جيجا بايت. وننظر في سلوك نظام معين. من الواضح أن المعدات هنا يجب أن تكون مثل المنتج. يجب أن يكون لديك نفس الأقراص ونفس حجم الذاكرة ونفس إعدادات Postgres.
وبهذه الطريقة سنقوم بتبادل نظامنا ، ونعرف كيف سيتصرف نظام إدارة قواعد البيانات (DBMS) في حالة وجود كتلة سيئة DELETE ، وكيف سيتم فحصه.
نقاط التفتيش في روسيا هي نقاط تفتيش.
مثال: حذف عدة ملايين من الصفوف حسب الفهرس ، الصفوف "مبعثرة" عبر الصفحات.
هنا مثال. هذه قاعدة. ومع الإعداد الافتراضي البالغ 1 غيغابايت للحجم الأقصى ، فمن الواضح جدًا أن أقراصنا تذهب إلى الرف للتسجيل. هذه الصورة هي عرض نموذجي لمريض مريض للغاية ، أي أنه يشعر بالسوء حقًا. وكانت هناك عملية واحدة ، كان هناك فقط حذف لعدة ملايين من السطور.
إذا تم السماح بإجراء مثل هذه العملية ، فسنستلقي فقط ، لأنه من الواضح أن أحد الحذف يقتلنا في الرف.
علاوة على ذلك ، حيث 16 جيجا بايت ، من الواضح أن الأسنان قد ذهبت بالفعل. الأسنان أفضل بالفعل ، أي أننا نطرق السقف ، لكن ليس بهذا السوء. كان هناك بعض الحرية هناك. على اليمين هو السجل. وعدد العمليات - الرسم البياني الثاني. ومن الواضح أننا نتنفس بالفعل بشكل أسهل قليلاً عند 16 جيجابايت.
وحيث يمكن رؤية 64 جيجا بايت أنها أصبحت أفضل تمامًا. بالفعل يتم نطق الأسنان ، هناك المزيد من الفرص للنجاة من العمليات الأخرى والقيام بشيء ما باستخدام القرص.
لماذا؟
سوف أتعمق في التفاصيل قليلاً ، لكن هذا الموضوع ، كيفية إجراء ضبط نقطة التفتيش ، يمكن أن ينتج عنه تقرير كامل ، لذلك لن أقوم بتحميل الكثير ، لكنني سأوجز قليلاً ما الصعوبات الموجودة.
إذا كانت نقطة التفتيش تحدث في كثير من الأحيان ، وقمنا بتحديث أسطرنا ليس بالتسلسل ، ولكننا نجدها بالفهرس ، وهذا أمر جيد ، لأننا لا نحذف الجدول بأكمله ، فقد يحدث أننا في البداية لمسنا الصفحة الأولى ، ثم الصفحة الألف ، ثم عاد إلى الأول. وإذا كانت نقطة التفتيش قد حفظتها بالفعل على القرص بين هذه الزيارات للصفحة الأولى ، فستحفظها مرة أخرى ، لأننا قمنا بتسخينها مرة أخرى.
وسوف نجبر الحاجز على حفظه عدة مرات. كيف ستكون هناك عمليات زائدة عن الحاجة له.
ولكن هذا ليس كل شيء. يبلغ حجم الصفحات 8 كيلوبايت في Postgres و 4 كيلوبايت في Linux. وهناك إعداد full_page_writes. يتم تمكينه بشكل افتراضي. وهذا صحيح ، لأنه إذا قمنا بإيقاف تشغيله ، فهناك خطر يتمثل في أنه سيتم حفظ نصف الصفحة فقط في حالة تعطلها.
إن سلوك الكتابة إلى WAL للسجل الأمامي هو أنه عندما يكون لدينا نقطة تفتيش ونغير الصفحة لأول مرة ، تدخل الصفحة بأكملها ، أي كل 8 كيلوبايت ، في سجل التوجيه ، على الرغم من أننا قمنا بتغيير فقط الخط الذي يزن 100 بايت. وعلينا كتابة الصفحة بأكملها.
في التغييرات اللاحقة ، سيكون هناك مجموعة محددة فقط ، ولكن للمرة الأولى نكتب كل شيء.
وبناءً على ذلك ، إذا تكرر الحاجز مرة أخرى ، فعلينا أن نبدأ كل شيء من الصفر مرة أخرى وندفع الصفحة بأكملها. مع نقاط التفتيش المتكررة ، عندما نسير عبر نفس الصفحات ، سيكون full_page_writes = على أكثر مما يمكن أن يكون ، أي أننا نولد المزيد من WAL. يتم إرسال المزيد إلى النسخ المتماثلة ، إلى الأرشيف ، إلى القرص.
وبناءً عليه ، لدينا فائضان.
إذا قمنا بزيادة حجم max_wal_size ، فقد اتضح أننا نجعل الأمر أسهل لكل من كاتب نقاط التفتيش و wal. وهذا رائع.
دعونا نضع تيرابايت ونتعايش معها. ما هو السيء في ذلك؟ هذا سيء ، لأنه في حالة الفشل ، سوف نتسلق لساعات ، لأن الحاجز كان منذ زمن طويل وقد تغير الكثير بالفعل. ونحن بحاجة للقيام بكل هذا REDO. وهكذا نجري السلسلة الثانية من التجارب.
نقوم بعملية ونرى عندما تكون نقطة التفتيش على وشك الاكتمال ، فإننا نقتل -9 Postgres عن قصد.
وبعد ذلك نبدأها مرة أخرى ، ونرى كم من الوقت سترتفع على هذه المعدات ، أي مقدار REDO في هذه الحالة السيئة.
سألاحظ مرتين أن الوضع سيء. أولاً ، لقد تحطمت الطائرة قبل انتهاء الحاجز مباشرة ، لذلك لدينا الكثير لنخسره. وثانيًا ، أجرينا عملية جراحية ضخمة. وإذا كانت نقاط التفتيش في الوقت المستقطع ، فعلى الأرجح ، سيتم إنشاء WAL أقل منذ آخر نقطة تفتيش. أي أنه خاسر مزدوج.
نقيس مثل هذا الموقف لأحجام مختلفة من max_wal_size ونفهم أنه إذا كان max_wal_size 64 غيغابايت ، فسنصعد في أسوأ الحالات المزدوجة لمدة 10 دقائق. ونفكر ما إذا كان يناسبنا أم لا. هذا سؤال عمل. نحتاج إلى إظهار هذه الصورة للمسؤولين عن قرارات العمل ونسأل ، "كم من الوقت يمكننا الاستلقاء على الأكثر في حالة حدوث مشكلة؟ هل يمكننا الاستلقاء في أسوأ المواقف لمدة 3-5 دقائق؟ وأنت تتخذ قرارًا.
وهنا نقطة مثيرة للاهتمام. لدينا بضعة تقارير حول Patroni في المؤتمر. وربما كنت تستخدمه. هذا هو التحميل التلقائي لـ Postgres. تحدث GitLab و Data Egret عن هذا الأمر.
وإذا كان لديك إعادة تشغيل تلقائي في غضون 30 ثانية ، فربما يمكننا الاستلقاء لمدة 10 دقائق؟ لأننا سننتقل إلى النسخة المتماثلة بحلول هذه النقطة ، وسيكون كل شيء على ما يرام. هذه نقطة خلافية. لا أعرف إجابة واضحة. أشعر فقط أن هذا الموضوع ليس فقط حول التعافي من التعطل.
إذا تعافينا لفترة طويلة بعد الفشل ، فسنكون غير مرتاحين في العديد من المواقف الأخرى. على سبيل المثال ، في نفس التجارب ، عندما نفعل شيئًا ما وأحيانًا نضطر إلى الانتظار لمدة 10 دقائق.
ما زلت لن أذهب بعيدًا ، حتى لو كان لدينا تجاوز تلقائي. كقاعدة عامة ، تعتبر القيم مثل 64 و 100 جيجابايت قيمًا جيدة. في بعض الأحيان يكون الأمر يستحق اختيار أقل. بشكل عام ، هذا علم دقيق.
للقيام بالتكرارات ، على سبيل المثال ، max_wal_size = 1 ، 8 ، تحتاج إلى تكرار العملية الجماعية عدة مرات. لقد فعلتها. وعلى نفس القاعدة تريد أن تفعل ذلك مرة أخرى ، لكنك قمت بالفعل بحذف كل شيء. ما يجب القيام به؟
سأتحدث لاحقًا عن الحل الذي نقدمه ، وماذا نفعل للتكرار في مثل هذه المواقف. وهذا هو النهج الصحيح.
لكن في هذه الحالة ، كنا محظوظين. إذا ، كما هو موضح هنا "ابدأ ، احذف ، ROLLBACK" ، فيمكننا تكرار الحذف. أي ، إذا ألغيناها بأنفسنا ، فيمكننا تكراره. وستكون البيانات في نفس المكان جسديًا. أنت لا تحصل حتى على أي سخام. يمكنك تكرار هذه الحذف.
يعد برنامج DELETE مع ROLLBACK مثاليًا لضبط نقاط التفتيش ، حتى إذا لم يكن لديك معامل قاعدة بيانات منشورة بشكل صحيح.
صنعنا لوحة بعمود واحد "أنا". يحتوي Postgres على أعمدة فائدة. هم غير مرئيين ما لم يطلب ذلك على وجه التحديد. هذه هي: ctid ، xmid ، xmax.
Ctid هو عنوان فعلي. الصفحة الصفرية ، أول مجموعة في الصفحة.
يمكن ملاحظة أنه بعد ROOLBACK ، بقيت المجموعة في نفس المكان. وهذا يعني أنه يمكننا المحاولة مرة أخرى ، وسوف تتصرف بنفس الطريقة. هذا هو الشيء الرئيسي.
Xmax هو وقت وفاة المجموعة. لقد تم ختمها ، لكن Postgres تعرف أن المعاملة قد تم إرجاعها ، لذلك لا يهم ما إذا كانت 0 أو أنها معاملة تم التراجع عنها. يشير هذا إلى أنه من الممكن التكرار عبر DELETE والتحقق من العمليات المجمعة لسلوك النظام. يمكنك عمل معامل قاعدة بيانات للفقراء.
هذا عن المبرمجين. حول DBA أيضًا ، فهم دائمًا يوبخون المبرمجين على هذا: "لماذا تقوم بمثل هذه العمليات الطويلة والصعبة؟" هذا موضوع عمودي مختلف تمامًا. كانت هناك إدارة ، والآن سيكون هناك تطوير.
من الواضح أننا لم نكسر إلى أشلاء. انها واضحة. من المستحيل عدم تقسيم هذا الحذف لملايين الخطوط إلى أجزاء. سوف يتم ذلك لمدة 20 دقيقة ، وكل شيء سوف يستلقي. لكن لسوء الحظ ، حتى المطورين ذوي الخبرة يرتكبون أخطاء ، حتى في الشركات الكبيرة جدًا.
لماذا من المهم كسر؟
-
إذا رأينا أن القرص صعب ، فلنبطئه. وإذا تم كسرنا ، فيمكننا إضافة فترات توقف مؤقت ، يمكننا إبطاء الاختناق.
-
ولن نمنع الآخرين لفترة طويلة. في بعض الحالات ، لا يهم ، إذا كنت تحذف القمامة الحقيقية التي لا يعمل عليها أحد ، فعلى الأرجح أنك لن تحظر أي شخص باستثناء عمل الفراغ التلقائي ، لأنه سينتظر حتى تكتمل المعاملة. ولكن إذا قمت بإزالة شيء ما يمكن لشخص آخر طلبه ، فسيتم حظره ، وسيكون هناك نوع من ردود الفعل المتسلسلة. يجب تجنب المعاملات الطويلة على مواقع الويب وتطبيقات الهاتف المحمول.
هذا مثير للاهتمام. غالبًا ما أرى أن المطورين يسألون: "ما حجم الحزمة الذي يجب أن أختاره؟".
من الواضح أنه كلما كان حجم الحزمة أكبر ، كلما قلت النفقات العامة للمعاملة ، أي النفقات الإضافية من المعاملات. لكن في نفس الوقت ، يزيد الوقت لهذه الصفقة.
لدي قاعدة بسيطة للغاية: خذ قدر ما تستطيع ، لكن لا تتجاوز الملفات التنفيذية في الثانية.
لماذا ثانية؟ الشرح بسيط للغاية ومفهوم للجميع ، حتى الأشخاص غير التقنيين. نرى رد فعل. لنأخذ 50 مللي ثانية. إذا تغير شيء ما ، فسوف تتفاعل أعيننا. إذا كان أقل ، ثم أكثر صعوبة. إذا استجاب شيء ما بعد 100 مللي ثانية ، على سبيل المثال ، إذا نقرت على الماوس ، وأجابك بعد 100 مللي ثانية ، فأنت تشعر بالفعل بهذا التأخير الطفيف. يُنظر إلى الثانية بالفعل على أنها مكابح.
وفقًا لذلك ، إذا قسمنا عملياتنا الجماعية إلى رشقات نارية مدتها 10 ثوانٍ ، فعندئذٍ يكون لدينا خطر أننا سنحظر شخصًا ما. وستعمل لبضع ثوان ، وسوف يلاحظها الناس بالفعل. لذلك أفضل عدم القيام بأكثر من ثانية. لكن في الوقت نفسه ، لا تقم بتفكيكها بشكل جيد للغاية ، لأن النفقات العامة للمعاملة ستكون ملحوظة. ستكون القاعدة أصعب ، وقد تنشأ مشاكل أخرى مختلفة.
نختار حجم العبوة. في كل حالة ، يمكننا القيام بذلك بشكل مختلف. يمكن أن تكون مؤتمتة. ونحن مقتنعون بكفاءة معالجة عبوة واحدة. أي أننا نقوم بحذف حزمة واحدة أو تحديث.
بالمناسبة ، كل ما أتحدث عنه لا يتعلق فقط بحذف. كما خمنت ، هذه هي أي عمليات مجمعة على البيانات.
ونرى أن الخطة ممتازة. يمكنك أن ترى فحص الفهرس ، والفحص فقط هو أفضل. ولدينا كمية صغيرة من البيانات المعنية. وأقل من ثانية يفي. ممتاز.
وما زلنا بحاجة للتأكد من عدم وجود تدهور. يحدث أن العبوات الأولى تعمل بسرعة ، ثم تزداد سوءًا وأسوأ. هذه العملية تحتاج إلى اختبار الكثير. هذا هو بالضبط ما هي مختبرات قاعدة البيانات.
ولا يزال يتعين علينا إعداد شيء ما بحيث يسمح لنا بمتابعة ذلك بشكل صحيح في الإنتاج. على سبيل المثال ، يمكننا كتابة الوقت في السجل ، ويمكننا أن نكتب أين نحن الآن ومن قمنا بحذفه الآن. وسيسمح لنا هذا بفهم ما سيحدث لاحقًا. وفي حالة حدوث خطأ ما ، ابحث عن المشكلة بسرعة.
إذا احتجنا إلى التحقق من كفاءة الطلبات واحتجنا إلى تكرارها عدة مرات ، فهناك شيء مثل روبوت زميل. إنه جاهز بالفعل. يتم استخدامه من قبل عشرات المطورين يوميًا. وهو يعرف كيفية تقديم قاعدة بيانات ضخمة تيرابايت عند الطلب في 30 ثانية ، نسختك الخاصة. ويمكنك حذف شيء هناك وقول RESET وحذفه مرة أخرى. يمكنك تجربتها بهذه الطريقة. أرى مستقبلًا لهذا الشيء. ونحن نفعل ذلك بالفعل.
ما هي استراتيجيات التقسيم؟ أرى ثلاث استراتيجيات تقسيم مختلفة يستخدمها مطورو الحزمة.
الأول بسيط للغاية. لدينا معرف رقمي. ودعنا نقسمها إلى فترات مختلفة ونعمل على ذلك. الجانب السلبي واضح. في الجزء الأول ، قد يكون لدينا 100 سطر من القمامة الحقيقية ، في الأسطر الخمسة الثانية أو لا نمتلكها على الإطلاق ، أو ستتحول جميع الخطوط الألف إلى قمامة. عمل متفاوت للغاية ، لكن من السهل كسره. أخذوا الحد الأقصى من الهوية وحطموه. هذا نهج ساذج.
الاستراتيجية الثانية هي نهج متوازن. يتم استخدامه في جيتلاب. أخذوا وفحصوا الطاولة. لقد وجدنا حدود حزم المعرفات بحيث تحتوي كل حزمة على 10 سجل بالضبط. ووضعهم في قائمة الانتظار. ثم نعالج. يمكنك القيام بذلك في مواضيع متعددة.
في الإستراتيجية الأولى أيضًا ، بالمناسبة ، يمكنك القيام بذلك في عدة خيوط. ليست صعبة.
ولكن هناك نهج أفضل وأفضل. هذه هي الاستراتيجية الثالثة. وعندما يكون ذلك ممكنًا ، من الأفضل اختياره. نقوم بذلك على أساس فهرس خاص. في هذه الحالة ، سيكون على الأرجح فهرسًا وفقًا لحالة القمامة والمعرف. سنقوم بتضمين المعرف بحيث يكون فحص فهرس فقط حتى لا نذهب إلى الكومة.
بشكل عام ، يكون فحص الفهرس فقط أسرع من فحص الفهرس.
وسرعان ما نجد معرفاتنا التي نريد حذفها. BATCH_SIZE نختاره مسبقًا. ونحن لا نحصل عليهم فقط ، بل نحصل عليهم بطريقة خاصة ونخترقهم على الفور. لكننا نقفلها حتى إذا تم قفلها بالفعل ، فإننا لا نغلقها ، ولكننا نتحرك ونأخذ التالي. هذا هو لتخطي التحديث مؤمن. تتيح لنا هذه الميزة الفائقة لـ Postgres العمل في العديد من المواضيع إذا أردنا ذلك. من الممكن في تيار واحد. وهنا يوجد CTE - هذا طلب واحد. ولدينا عملية حذف حقيقية تجري في الطابق الثاني من CTE - returning *. يمكنك إرجاع الهوية ، لكنها أفضل *إذا لم يكن لديك الكثير من البيانات في كل سطر.
لماذا نحتاجه؟ هذا ما نحتاجه للإبلاغ عنه. لقد قمنا الآن بحذف العديد من الأسطر في الواقع. ولدينا حدود بواسطة المعرف أو من خلال created_at مثل هذا. يمكنك أن تفعل الحد الأدنى ، كحد أقصى. يمكن عمل شيء آخر. يمكنك حشو الكثير هنا. وهي مريحة للغاية للرصد.
هناك ملاحظة أخرى حول الفهرس. إذا قررنا أننا بحاجة إلى فهرس خاص لهذه المهمة ، فنحن بحاجة إلى التأكد من أنه لا يفسد كومة التحديثات فقط. وهذا يعني أن Postgres لديه مثل هذه الإحصاءات. يمكن رؤية ذلك في pg_stat_user_tables لجدولك. يمكنك معرفة ما إذا كان يتم استخدام التحديثات الساخنة أم لا.
هناك حالات يمكن أن يقوم فيها الفهرس الجديد بحذفها ببساطة. ولديك جميع التحديثات الأخرى التي تعمل بالفعل ، تبطئ. ليس فقط لأن الفهرس ظهر (كل فهرس يبطئ التحديثات قليلاً ، لكن قليلاً) ، ولكن هنا لا يزال يفسدها. ومن المستحيل إجراء تحسين خاص لهذا الجدول. يحدث هذا في بعض الأحيان. هذه دقة لا يتذكرها سوى قلة من الناس. وهذا أشعل النار من السهل أن تخطو عليه. يحدث أحيانًا أنك بحاجة إلى إيجاد نهج من الجانب الآخر وما زلت تستغني عن هذا الفهرس الجديد ، أو إنشاء فهرس آخر ، أو بطريقة أخرى ، على سبيل المثال ، يمكنك استخدام الطريقة الثانية.
ولكن هذه هي الإستراتيجية المثلى ، وهي كيفية التقسيم إلى مجموعات والتصوير على دفعات بطلب واحد ، والحذف قليلاً ، وما إلى ذلك.
المعاملات الطويلة
التفريغ التلقائي المحظور -
قضية المنع -
الخطأ الخامس هو خطأ كبير. تحدث نيكولاي من Okmeter عن مراقبة Postgres. المراقبة المثالية لـ Postgres ، للأسف ، غير موجودة. بعضها أقرب والبعض أبعد. Okmeter قريب بما يكفي ليكون مثاليًا ، لكن الكثير مفقود ويحتاج إلى إضافته. يجب أن تكون مستعدًا لهذا.
على سبيل المثال ، من الأفضل مراقبة المجموعات الميتة. إذا كان لديك الكثير من الأشياء الميتة على الطاولة ، فهناك خطأ ما. من الأفضل أن تتفاعل الآن ، وإلا فقد يكون هناك تدهور ، ويمكننا الاستلقاء. يحدث ذلك.
إذا كان هناك IO كبير ، فمن الواضح أن هذا ليس جيدًا.
معاملات طويلة جدا. يجب عدم السماح بالمعاملات الطويلة على OLTP. وإليك رابط لمقتطف يسمح لك بأخذ هذا المقتطف والقيام بالفعل ببعض تتبع المعاملات الطويلة.
لماذا المعاملات الطويلة سيئة؟ لأنه سيتم تحرير جميع الأقفال فقط في النهاية. ونحن نخدع الجميع. بالإضافة إلى ذلك ، نقوم بحظر الفراغ التلقائي لجميع الطاولات. إنه ليس جيدًا على الإطلاق. حتى إذا كان لديك وضع الاستعداد السريع ممكّنًا في النسخة المتماثلة ، فلا يزال سيئًا. بشكل عام ، ليس من الأفضل تجنب المعاملات الطويلة.
إذا كان لدينا العديد من الجداول التي لم يتم تفريغها ، فسنحتاج إلى تنبيه. هنا مثل هذا الوضع ممكن. يمكننا التأثير بشكل غير مباشر على عمل الفراغ الذاتي. هذا مقتطف من Avito ، والذي قمت بتحسينه قليلاً. واتضح أنها أداة مثيرة للاهتمام لمعرفة ما لدينا مع الفراغ التلقائي. على سبيل المثال ، هناك بعض الطاولات تنتظر هناك ولن تنتظر دورها. تحتاج أيضًا إلى وضعه في المراقبة والحصول على تنبيه.
وقضايا الكتل. غابة من أشجار الكتل. أحب أن آخذ شيئًا من شخص ما وتحسينه. لقد أخذت هنا CTE العودي الرائع من Data Egret الذي يُظهر غابة من الأشجار المقفلة. هذه أداة تشخيصية جيدة. وعلى أساسها ، يمكنك أيضًا بناء المراقبة. لكن هذا يجب أن يتم بعناية. تحتاج إلى إجراء بيان صغير مهلة لنفسك. و lock_timeout أمر مرغوب فيه.
في بعض الأحيان تحدث كل هذه الأخطاء باختصار.
في رأيي ، الخطأ الرئيسي هنا تنظيمي. إنه تنظيمي ، لأن الأسلوب لا ينسحب. هذا رقم 2 - لقد تحققوا في المكان الخطأ.
لقد قمنا بالتحقق من المكان الخطأ ، لأنه لم يكن لدينا نسخة إنتاج ، يسهل التحقق منها. قد لا يتمكن المطور من الوصول إلى الإنتاج على الإطلاق.
ولم نتحقق هناك. إذا كنا قد تحققنا هناك ، لكنا قد رأينا ذلك بأنفسنا. رأى المطور كل ذلك حتى بدون DBA إذا قام بفحصه في بيئة جيدة ، حيث يوجد نفس كمية البيانات وموقع متطابق. كان سيرى كل هذا الانحطاط وسيخجل.
المزيد عن المكنسة الذاتية. بعد أن قمنا بمسح شامل لعدة ملايين من الخطوط ، ما زلنا بحاجة إلى إجراء REPACK. هذا مهم بشكل خاص للفهارس. سيشعرون بالسوء بعد أن قمنا بتنظيف كل شيء هناك.
وإذا كنت ترغب في إعادة أعمال التنظيف اليومية ، فإنني أقترح القيام بذلك في كثير من الأحيان ، ولكن أصغر. يمكن أن يكون مرة واحدة في الدقيقة أو حتى في كثير من الأحيان قليلاً. وتحتاج إلى مراقبة شيئين: أن هذا الشيء ليس به أخطاء وأنه لا يتخلف عن الركب. الحيلة التي أظهرتها ستحل هذا فقط.
ما نقوم به هو المصدر المفتوح. تم نشره على GitLab. ونحن نجعلها حتى يتمكن الناس من التحقق حتى بدون DBA. نحن نقوم بعمل معمل قاعدة بيانات ، أي أننا نسمي المكون الأساسي الذي يعمل عليه Joe حاليًا. ويمكنك الحصول على نسخة من الإنتاج. يوجد الآن تطبيق Joe for slack ، يمكنك أن تقول هناك: "اشرح كذا وكذا الطلب" واحصل على النتيجة فورًا لنسختك من قاعدة البيانات. يمكنك حتى الحذف هناك ، ولن يلاحظها أحد.
لنفترض أن لديك 10 تيرابايت ، ونحن نصنع معمل قاعدة البيانات أيضًا 10 تيرابايت. ومع قواعد البيانات المتزامنة التي تبلغ 10 تيرابايت ، يمكن لـ 10 مطورين العمل في وقت واحد. يمكن للجميع أن يفعلوا ما يريدون. يمكن الحذف ، والإفلات ، وما إلى ذلك. هذا مثل هذا الخيال. سنتحدث عن هذا غدا.
وهذا ما يسمى التزويد الرقيق. هذا هو توفير خفية. هذا نوع من الخيال يزيل إلى حد كبير التأخير في التنمية والاختبار ويجعل العالم مكانًا أفضل في هذا الصدد. أي أنه يسمح لك فقط بتجنب مشاكل العمليات الجماعية.
مثال: قاعدة بيانات 5 تيرابايت ، الحصول على نسخة في أقل من 30 ثانية. وهو لا يعتمد حتى على الحجم ، أي أنه لا يهم كم تيرابايت.
اليوم يمكنك الذهاب إلى والبحث في أدواتنا. يمكنك التسجيل لترى ما هو موجود. يمكنك تثبيت هذا الروبوت. انه مجانا. يكتب.
الأسئلة
في كثير من الأحيان في المواقف الحقيقية ، يتبين أن البيانات التي يجب أن تظل في الجدول أقل بكثير مما يجب حذفه. وهذا يعني ، في مثل هذه الحالة ، أنه غالبًا ما يكون من الأسهل تنفيذ مثل هذا النهج ، عندما يكون من الأسهل إنشاء كائن جديد ، ونسخ البيانات الضرورية فقط هناك ، وجذع الجدول القديم. من الواضح أن هناك حاجة إلى نهج برمجي في هذه اللحظة ، أثناء قيامك بالتبديل. كيف يتم هذا النهج؟
هذا نهج جيد للغاية ومهمة جيدة للغاية. إنه مشابه جدًا لما يفعله pg_repack ، فهو مشابه جدًا لما يتعين عليك القيام به عند إنشاء معرفات 4 بايت. قامت العديد من الأطر بهذا قبل بضع سنوات ، ونمت اللوحات فقط ، ويجب تحويلها إلى 8 بايت.
هذه المهمة صعبة للغاية. لقد فعلناها. وعليك أن تكون حذرا جدا. هناك أقفال ، إلخ. ولكن يتم القيام بذلك. أي أن النهج القياسي هو استخدام pg_repack. تعلن عن مثل هذه التسمية. وقبل أن تبدأ في تحميل بيانات اللقطة فيه ، فإنك تعلن أيضًا عن لوحة واحدة تتعقب جميع التغييرات. هناك خدعة قد لا تتبعها حتى لبعض التغييرات. هناك خفايا. ثم تقوم بالتبديل عن طريق تغيير التغييرات. سيكون هناك وقفة قصيرة عندما نغلق كل شخص ، ولكن بشكل عام يتم ذلك.
إذا نظرت إلى pg_repack على GitHub ، ثم هناك ، عندما كانت هناك مهمة لتحويل معرف من int 4 إلى int 8 ، فحينئذٍ كانت هناك فكرة لاستخدام pg_repack نفسها. هذا ممكن أيضًا ، لكنه نوع من الاختراق ، لكنه سيعمل من أجل هذا أيضًا. يمكنك التدخل في المشغل الذي تستخدمه pg_repack والقول هناك: "لسنا بحاجة إلى هذه البيانات" ، أي أننا ننقل فقط ما نحتاجه. وبعد ذلك يقوم بالتبديل وهذا كل شيء.
مع هذا النهج ، ما زلنا نحصل على نسخة ثانية من الجدول ، حيث تكون البيانات مفهرسة بالفعل ومكدسة بشكل متساوٍ مع فهارس جميلة.
سخام غير موجود ، إنه نهج جيد. لكنني أعلم أن هناك محاولات لتطوير أتمتة لهذا ، أي تقديم حل شامل. يمكنني أن أضعك على اتصال بهذه الأتمتة. إنه مكتوب بلغة بايثون ، وهذا أمر جيد.
أنا من عالم MySQL قليلاً ، لذا جئت لأستمع. ونستخدم هذا النهج.
ولكن فقط إذا كان لدينا 90٪. إذا كان لدينا 5٪ ، فليس من الجيد استخدامها.
شكرا على التقرير! إذا لم تكن هناك موارد لعمل نسخة كاملة من المنتج ، فهل هناك أي خوارزمية أو صيغة لحساب الحمل أو الحجم؟
سؤال جيد. حتى الآن ، نحن قادرون على العثور على قواعد بيانات متعددة تيرابايت. حتى لو كانت الأجهزة غير متطابقة ، على سبيل المثال ، ذاكرة أقل ، ومعالج أقل وأقراص ليست متطابقة تمامًا ، لكننا ما زلنا نفعل ذلك. إذا لم يكن هناك مكان على الإطلاق ، فأنت بحاجة إلى التفكير. دعني أفكر حتى الغد ، أتيت ، سنتحدث ، هذا سؤال جيد.
شكرا على التقرير! لقد بدأت في البداية حول حقيقة أن هناك Postgres رائعًا ، له قيود كذا وكذا ، لكنه يتطور. وهذا كله عكاز بشكل عام. ألا يتعارض هذا كله مع تطوير Postgres نفسه ، حيث سيظهر بعض DELETE المحترم أو أي شيء آخر يجب أن يظل عند مستوى منخفض ما نحاول تشويهه ببعض من وسائلنا الغريبة هنا؟
إذا قلنا في SQL حذف أو تحديث العديد من السجلات في معاملة واحدة ، فكيف يمكن لـ Postgres توزيعها هناك؟ نحن مقيدون جسديا في العمليات. سنستمر في القيام بذلك لفترة طويلة. وسنغلق في هذا الوقت ، إلخ.
انتهيت من الفهارس.
يمكنني أن أفترض أن ضبط نفس نقطة التفتيش يمكن أن يكون آليًا. يوما ما قد يكون. لكن بعد ذلك لا أفهم السؤال حقًا.
السؤال هو ، هل هناك متجه للتطور يسير هنا وهناك ، وها أنت تسير بالتوازي؟ أولئك. ألم يفكروا في الأمر بعد؟
تحدثت عن المبادئ التي يمكن استخدامها الآن. هناك بوت آخر ، مع هذا يمكنك القيام بضبط تلقائي لنقطة التفتيش. هل سيكون يوما ما في Postgres؟ لا أعلم ، لم تتم مناقشته حتى الآن. ما زلنا بعيدين عن ذلك. لكن هناك علماء يصنعون أنظمة جديدة. ودفعونا إلى فهارس آلية. هناك تطورات. على سبيل المثال ، يمكنك إلقاء نظرة على الضبط التلقائي. يختار المعلمات تلقائيًا. لكنه لن يقوم بضبط نقطة التفتيش لك حتى الآن. أي أنها ستلتقط للأداء ، المخزن المؤقت للقذيفة ، إلخ.
ولضبط نقاط التفتيش ، يمكنك القيام بذلك: إذا كان لديك ألف مجموعة وأجهزة مختلفة ، وأجهزة افتراضية مختلفة في السحابة ، يمكنك استخدام الروبوت الخاص بنا قم بالأتمتة. وسيتم تحديد max_wal_size وفقًا لإعدادات الهدف تلقائيًا. لكن حتى الآن ، هذا ليس قريبًا من جوهره ، للأسف.
مساء الخير لقد تحدثت عن مخاطر المعاملات الطويلة. قلت أن الفراغ التلقائي محظور في حالة الحذف. وإلا كيف يضر بنا؟ لأننا نتحدث أكثر عن إخلاء بعض المساحة والقدرة على استخدامها. ما الذي نفتقده أيضًا؟
ربما لا يكون Autovacuum هو المشكلة الأكبر هنا. وحقيقة أن صفقة طويلة يمكن أن تغلق معاملات أخرى ، فإن هذا الاحتمال أكثر خطورة. قد تلتقي أو لا تلتقي. إذا التقت ، فقد يكون الأمر سيئًا للغاية. ومع الفراغ الذاتي - هذه أيضًا مشكلة. هناك مشكلتان مع المعاملات الطويلة في OLTP: الأقفال والتفريغ التلقائي. وإذا تم تمكين ردود الفعل الاحتياطية الساخنة على النسخة المتماثلة ، فسيصل قفل الفراغ التلقائي أيضًا إلى الإصدار الرئيسي ، وسيصل من النسخة المتماثلة. لكن على الأقل لن يكون هناك أقفال. وسيكون هناك loks. نحن نتحدث عن تغييرات البيانات ، لذلك تعتبر الأقفال نقطة مهمة هنا. وإذا كان هذا كله لفترة طويلة جدًا ، فسيتم قفل المزيد والمزيد من المعاملات. يمكنهم سرقة الآخرين. وتظهر أشجار لوك. لقد قدمت رابطًا إلى المقتطف. وتصبح هذه المشكلة ملحوظة بشكل أسرع من مشكلة الفراغ الذاتي ، والتي يمكن أن تتراكم فقط.
شكرا على التقرير! لقد بدأت تقريرك بالقول إنك اختبرت بشكل غير صحيح. واصلنا فكرتنا بأننا بحاجة إلى أخذ نفس المعدات ، مع القاعدة بنفس الطريقة. لنفترض أننا منحنا المطور قاعدة. وامتثل للطلب. ويبدو أنه بخير. لكنه لا يبحث عن البث المباشر ، ولكن بالنسبة للعيش ، على سبيل المثال ، لدينا حمولة 60-70٪. وحتى لو استخدمنا هذا الضبط ، فإنه لا يعمل بشكل جيد.
من المهم وجود خبير في الفريق واستخدام خبراء DBA الذين يمكنهم التنبؤ بما سيحدث مع تحميل خلفية حقيقي. عندما قادنا للتو تغييراتنا النظيفة ، نرى الصورة. لكن نهجًا أكثر تقدمًا ، عندما فعلنا نفس الشيء مرة أخرى ، ولكن مع حمولة تمت محاكاتها مع الإنتاج. إنه رائع جدًا. حتى ذلك الحين ، عليك أن تكبر. إنه مثل شخص بالغ. لقد نظرنا فقط إلى ما لدينا ونظرنا أيضًا في ما إذا كانت لدينا موارد كافية. هذا سؤال جيد.
عندما نقوم بالفعل بتحديد القمامة ولدينا ، على سبيل المثال ، علامة محذوفة
هذا ما يفعله autovacuum تلقائيًا في Postgres.
أوه ، هل يفعل ذلك؟
Autovacuum هو جامع القمامة.
شكرا لك!
شكرا على التقرير! هل هناك خيار لتصميم قاعدة بيانات على الفور مع التقسيم بطريقة تجعل كل القمامة متسخة من الجدول الرئيسي في مكان ما إلى الجانب؟
بالطبع هناك.
هل من الممكن إذن حماية أنفسنا إذا أغلقنا طاولة لا ينبغي استخدامها؟
بالطبع. لكنها مثل سؤال دجاجة وبيضة. إذا كنا نعلم جميعًا ما سيحدث في المستقبل ، فعندئذ ، بالطبع ، سنفعل كل شيء رائعًا. لكن العمل آخذ في التغير ، وهناك أعمدة جديدة وطلبات جديدة. وبعد ذلك - عفوًا ، نريد إزالته. لكن هذا الوضع المثالي ، يحدث في الحياة ، لكن ليس دائمًا. لكنها فكرة جيدة بشكل عام. اقتطع فقط وهذا كل شيء.
المصدر: www.habr.com