كيف يفهم مطور الواجهة الخلفية أن استعلام SQL سيعمل بشكل جيد على "المنتج"؟ في الشركات الكبيرة أو سريعة النمو ، لا يمكن للجميع الوصول إلى "المنتج". وباستخدام الوصول ، لا يمكن التحقق من جميع الطلبات دون عناء ، وغالبًا ما يستغرق إنشاء نسخة من قاعدة البيانات ساعات. لحل هذه المشكلات ، أنشأنا DBA اصطناعيًا - جو. وقد تم بالفعل تنفيذه بنجاح في العديد من الشركات ويساعد أكثر من عشرة مطورين.
فيديو:
أهلاً بكم! اسمي أناتولي ستانسلر. أعمل في شركة . نحن ملتزمون بتسريع عملية التطوير من خلال إزالة التأخيرات المرتبطة بعمل Postgres من المطورين ومديري قواعد البيانات وضمان الجودة.
لدينا عملاء رائعون واليوم سيتم تخصيص جزء من التقرير للحالات التي قابلناها أثناء العمل معهم. سأتحدث عن كيف ساعدناهم في حل مشاكل خطيرة للغاية.
عندما نطور ونقوم بعمليات هجرة كبيرة ومعقدة ، نسأل أنفسنا السؤال التالي: "هل ستنطلق هذه الهجرة؟". نحن نستخدم المراجعة ، ونستخدم معرفة الزملاء الأكثر خبرة وخبراء DBA. ويمكنهم أن يقولوا ما إذا كانت ستطير أم لا.
ولكن ربما يكون من الأفضل لو تمكنا من اختباره بأنفسنا على نسخ بالحجم الكامل. واليوم سنتحدث فقط عن طرق الاختبار الحالية وكيف يمكن إجراؤها بشكل أفضل وبأي أدوات. سنتحدث أيضًا عن إيجابيات وسلبيات مثل هذه الأساليب ، وما يمكننا إصلاحه هنا.
من أجرى الفهارس مباشرة على المنتج أو أجرى أي تغييرات؟ لا بأس به من. ولمن أدى ذلك إلى ضياع البيانات أو تعطلها؟ ثم تعرف هذا الألم. الحمد لله هناك نسخ احتياطية.
النهج الأول هو الاختبار في المنتج. أو ، عندما يجلس مطور على جهاز محلي ، يكون لديه بيانات اختبار ، يكون هناك نوع من الاختيار المحدود. ونبدأ بالحث ، ونحصل على هذا الموقف.
إنه مؤلم ، إنه مكلف. ربما يكون من الأفضل عدم القيام بذلك.
وما هي أفضل طريقة للقيام بذلك؟
لنأخذ التدريج ونختار جزءًا من prod هناك. أو في أحسن الأحوال ، دعنا نأخذ حافزًا حقيقيًا ، كل البيانات. وبعد أن قمنا بتطويره محليًا ، سوف نتحقق أيضًا من التدريج.
سيسمح لنا هذا بإزالة بعض الأخطاء ، أي منعها من الظهور.
ما هي المشاكل؟
- المشكلة هي أننا نشارك هذا التدريج مع الزملاء. وفي كثير من الأحيان يحدث نوعًا من التغيير ، يا بام - ولا توجد بيانات ، فالعمل في هباء. كان التدريج متعدد تيرابايت. وعليك أن تنتظر طويلا حتى تنهض من جديد. وقررنا الانتهاء منه غدًا. هذا كل شيء ، لدينا تطور.
- وبالطبع ، لدينا العديد من الزملاء الذين يعملون هناك ، والعديد من الفرق. ويجب أن يتم ذلك يدويًا. وهذا غير مريح.
ومن الجدير بالقول أن لدينا محاولة واحدة ، طلقة واحدة ، إذا أردنا إجراء بعض التغييرات على قاعدة البيانات ، ولمس البيانات ، وتغيير الهيكل. وإذا حدث خطأ ما ، وكان هناك خطأ في الترحيل ، فلن نتراجع بسرعة.
هذا أفضل من النهج السابق ، ولكن لا يزال هناك احتمال كبير بأن ينتقل نوع من الخطأ إلى الإنتاج.
ما الذي يمنعنا من إعطاء كل مطور منصة اختبار ، نسخة بالحجم الكامل؟ أعتقد أنه من الواضح ما يعيق الطريق.
من لديه قاعدة بيانات أكبر من تيرابايت؟ أكثر من نصف الغرفة.
ومن الواضح أن حفظ الآلات لكل مطور ، عندما يكون هناك مثل هذا الإنتاج الكبير ، يكون مكلفًا للغاية ، وإلى جانب ذلك ، فإنه يستغرق وقتًا طويلاً.
لدينا عملاء أدركوا أنه من المهم للغاية اختبار جميع التغييرات على النسخ بالحجم الكامل ، لكن قاعدة بياناتهم أقل من تيرابايت ، ولا توجد موارد للاحتفاظ بمقعد اختبار لكل مطور. لذلك ، يتعين عليهم تنزيل مقالب النفايات محليًا على أجهزتهم واختبارها بهذه الطريقة. ياخذ الكثير من الوقت.
حتى لو قمت بذلك داخل البنية التحتية ، فإن تنزيل تيرابايت واحد من البيانات في الساعة يعد أمرًا جيدًا بالفعل. لكنهم يستخدمون مقالب منطقية ، يتم تنزيلهم محليًا من السحابة. بالنسبة لهم ، تبلغ السرعة حوالي 200 جيجا بايت في الساعة. ولا يزال الأمر يستغرق بعض الوقت للانتقال من التفريغ المنطقي ، ونشمر الفهارس ، وما إلى ذلك.
لكنهم يستخدمون هذا النهج لأنه يسمح لهم بالحفاظ على موثوقية المنتج.
ماذا يمكننا ان نفعل هنا؟ دعونا نجعل مقاعد الاختبار رخيصة ونمنح كل مطور مقاعد اختبار خاصة به.
وهذا ممكن.
وفي هذا النهج ، عندما نصنع نسخًا رقيقة لكل مطور ، يمكننا مشاركتها على جهاز واحد. على سبيل المثال ، إذا كان لديك قاعدة بيانات بسعة 10 تيرابايت وترغب في منحها إلى 10 مطورين ، فلن تحتاج إلى أن يكون لديك قواعد بيانات XNUMX × XNUMX تيرابايت. ما عليك سوى آلة واحدة لعمل نسخ رقيقة معزولة لكل مطور باستخدام جهاز واحد. سأخبرك كيف يعمل بعد قليل.
مثال حقيقي:
-
DB - 4,5 تيرابايت.
-
يمكننا الحصول على نسخ مستقلة في 30 ثانية.
ليس عليك انتظار منصة اختبار وتعتمد على حجمها. يمكنك الحصول عليه في ثوان. ستكون بيئات معزولة تمامًا ، لكنها تشارك البيانات فيما بينها.
هذا عظيم. نحن هنا نتحدث عن السحر والكون الموازي.
في حالتنا ، يعمل هذا باستخدام نظام OpenZFS.
OpenZFS هو نظام ملفات قابل للنسخ عند الكتابة يدعم اللقطات والاستنساخ خارج الصندوق. إنها موثوقة وقابلة للتطوير. من السهل جدا إدارتها. يمكن نشرها حرفيا في فريقين.
هناك خيارات أخرى:
-
LVM ،
-
التخزين (على سبيل المثال ، Pure Storage).
معمل قاعدة البيانات الذي أتحدث عنه معياري. يمكن تنفيذها باستخدام هذه الخيارات. لكن في الوقت الحالي ، ركزنا على OpenZFS ، لأنه كانت هناك مشاكل مع LVM على وجه التحديد.
كيف تعمل؟ بدلاً من الكتابة فوق البيانات في كل مرة نقوم فيها بتغييرها ، نقوم بحفظها ببساطة عن طريق وضع علامة على أن هذه البيانات الجديدة هي من نقطة زمنية جديدة ، لقطة جديدة.
وفي المستقبل ، عندما نريد التراجع أو نريد عمل نسخة جديدة من إصدار أقدم ، نقول فقط: "حسنًا ، أعطنا هذه الكتل من البيانات التي تم تمييزها بهذا الشكل."
وسيعمل هذا المستخدم مع مجموعة البيانات هذه. سوف يغيرها تدريجياً ، ويصنع لقطاته الخاصة.
وسوف نتفرع. ستتاح لكل مطور في حالتنا الفرصة للحصول على نسخة خاصة به يقوم بتحريرها ، وستتم مشاركة البيانات التي تتم مشاركتها بين الجميع.
لنشر مثل هذا النظام في المنزل ، تحتاج إلى حل مشكلتين:
-
الأول هو مصدر البيانات ، ومن أين ستأخذها. يمكنك إعداد النسخ المتماثل مع الإنتاج. يمكنك بالفعل استخدام النسخ الاحتياطية التي قمت بتكوينها ، على ما آمل. WAL-E أو WAL-G أو Barman. وحتى إذا كنت تستخدم نوعًا من الحلول السحابية مثل RDS أو Cloud SQL ، فيمكنك استخدام عمليات التفريغ المنطقية. لكننا ما زلنا ننصحك باستخدام النسخ الاحتياطية ، لأنك بهذه الطريقة ستحتفظ أيضًا بالهيكل المادي للملفات ، مما سيتيح لك الاقتراب أكثر من المقاييس التي قد تراها في الإنتاج من أجل اكتشاف تلك المشكلات الموجودة.
-
والثاني هو المكان الذي تريد استضافة مختبر قاعدة البيانات فيه. يمكن أن يكون سحابة ، يمكن أن يكون داخل الشركة. من المهم أن نقول هنا أن ZFS يدعم ضغط البيانات. وهو يفعل ذلك بشكل جيد.
تخيل أنه لكل نسخة من هذا القبيل ، اعتمادًا على العمليات التي نقوم بها مع القاعدة ، سينمو نوع من المطورين. لهذا ، سيحتاج dev أيضًا إلى مساحة. ولكن نظرًا لحقيقة أننا أخذنا قاعدة تبلغ 4,5 تيرابايت ، فإن ZFS سوف يضغطها إلى 3,5 تيرابايت. يمكن أن يختلف هذا حسب الإعدادات. ولا يزال لدينا متسع للتطوير.
يمكن استخدام مثل هذا النظام في حالات مختلفة.
-
هؤلاء هم المطورون ، مسؤولو قواعد البيانات (DBA) للتحقق من صحة الاستعلام ، من أجل التحسين.
-
يمكن استخدام هذا في اختبار ضمان الجودة لاختبار ترحيل معين قبل طرحه للحث. ويمكننا أيضًا إنشاء بيئات خاصة لضمان الجودة باستخدام بيانات حقيقية ، حيث يمكنهم اختبار وظائف جديدة. وسيستغرق الأمر ثوانٍ بدلاً من ساعات الانتظار ، وربما أيامًا في بعض الحالات الأخرى التي لا يتم فيها استخدام النسخ الرقيقة.
-
وحالة أخرى. إذا لم يكن لدى الشركة نظام تحليلات تم إعداده ، فيمكننا عزل نسخة رقيقة من قاعدة المنتج وإعطائها للاستعلامات الطويلة أو الفهارس الخاصة التي يمكن استخدامها في التحليلات.
مع هذا النهج:
-
احتمالية منخفضة للأخطاء في "المنتج" ، لأننا اختبرنا جميع التغييرات على بيانات بالحجم الكامل.
-
لدينا ثقافة الاختبار ، لأنك الآن لست مضطرًا إلى الانتظار لساعات من أجل جناحك الخاص.
-
ولا يوجد حواجز ، ولا انتظار بين الاختبارات. يمكنك في الواقع الذهاب والتحقق. وسيكون من الأفضل بهذه الطريقة بينما نقوم بتسريع التطوير.
-
سيكون هناك إعادة بناء ديون أقل. سينتهي الأمر بعدد أقل من الأخطاء في المنتج. سنقوم بإعادة بنائها في وقت أقل.
-
يمكننا عكس التغييرات التي لا رجعة فيها. هذا ليس هو النهج القياسي.
- هذا مفيد لأننا نشارك موارد مناضد الاختبار.
جيد بالفعل ، لكن ما الذي يمكن تسريعه أيضًا؟
بفضل هذا النظام ، يمكننا تقليل عتبة الدخول في مثل هذا الاختبار بشكل كبير.
الآن هناك حلقة مفرغة ، عندما يجب على المطور ، من أجل الوصول إلى بيانات حقيقية كاملة الحجم ، أن يصبح خبيرًا. يجب الوثوق به مع هذا الوصول.
ولكن كيف تنمو إذا لم تكن موجودة. ولكن ماذا لو كان لديك فقط مجموعة صغيرة جدًا من بيانات الاختبار المتاحة لك؟ عندها لن تحصل على أي تجربة حقيقية.
كيف تخرج من هذه الدائرة؟ كأول واجهة ملائمة للمطورين من أي مستوى ، اخترنا Slack bot. ولكن يمكن أن تكون أي واجهة أخرى.
ماذا يسمح لك ان تفعل؟ يمكنك أن تأخذ استعلامًا محددًا وترسله إلى قناة خاصة لقاعدة البيانات. سنقوم تلقائيًا بنشر نسخة رقيقة في ثوانٍ. لننفذ هذا الطلب. نحن نجمع المقاييس والتوصيات. دعونا نظهر التصور. وبعد ذلك سيبقى هذا الاستنساخ بحيث يمكن تحسين هذا الاستعلام بطريقة أو بأخرى وإضافة الفهارس وما إلى ذلك.
كما يمنحنا Slack فرصًا للتعاون خارج الصندوق. نظرًا لأن هذه مجرد قناة ، يمكنك البدء في مناقشة هذا الطلب هناك مباشرةً في سلسلة محادثات مثل هذا الطلب ، ثم قم باختبار اتصال زملائك ومسئولي قواعد البيانات الموجودين داخل الشركة.
لكن هناك بالطبع مشاكل. نظرًا لأن هذا هو العالم الحقيقي ، ونقوم بتشغيل خادم يستضيف العديد من النسخ في وقت واحد ، يتعين علينا ضغط مقدار الذاكرة وطاقة وحدة المعالجة المركزية المتاحة للنسخ المستنسخة.
ولكن لكي تكون هذه الاختبارات معقولة ، فأنت بحاجة إلى حل هذه المشكلة بطريقة ما.
من الواضح أن النقطة المهمة هي نفس البيانات. لكن لدينا بالفعل. ونريد أن نحقق نفس التكوين. ويمكننا أن نعطي مثل هذا التكوين المتطابق تقريبًا.
سيكون من الرائع أن يكون لديك نفس الأجهزة الموجودة في الإنتاج ، ولكنها قد تختلف.
لنتذكر كيف يعمل Postgres مع الذاكرة. لدينا مخبأان. واحد من نظام الملفات وواحد أصلي من Postgres ، أي Shared Buffer Cache.
من المهم ملاحظة أنه يتم تخصيص ذاكرة التخزين المؤقت المشتركة عند بدء Postgres ، اعتمادًا على الحجم الذي تحدده في التكوين.
وتستهلك ذاكرة التخزين المؤقت الثانية كل المساحة المتاحة.
وعندما نصنع عدة نسخ على جهاز واحد ، يتبين أننا نملأ الذاكرة تدريجيًا. وبطريقة جيدة ، فإن Shared Buffer Cache يمثل 25٪ من إجمالي حجم الذاكرة المتوفرة على الجهاز.
واتضح أننا إذا لم نغير هذه المعلمة ، فسنكون قادرين على تشغيل 4 حالات فقط على جهاز واحد ، أي 4 من كل هذه النسخ الرقيقة. وهذا بالطبع سيء ، لأننا نريد أن يكون لدينا الكثير منهم.
ولكن من ناحية أخرى ، يتم استخدام Buffer Cache لتنفيذ استعلامات الفهارس ، أي أن الخطة تعتمد على حجم ذاكرات التخزين المؤقت لدينا. وإذا أخذنا فقط هذه المعلمة وقللناها ، فيمكن أن تتغير خططنا كثيرًا.
على سبيل المثال ، إذا كان لدينا ذاكرة تخزين مؤقت كبيرة على المنتج ، فسيفضل Postgres استخدام الفهرس. وإذا لم يكن الأمر كذلك ، فسيكون هناك SeqScan. وماذا ستكون الفائدة إذا لم تتطابق خططنا؟
ولكن هنا توصلنا إلى استنتاج مفاده أن الخطة في Postgres لا تعتمد في الواقع على الحجم المحدد المحدد في المخزن المؤقت المشترك في الخطة ، فهي تعتمد على حجم الذاكرة الفعالة.
Effective_cache_size هو المقدار المقدر لذاكرة التخزين المؤقت المتاحة لنا ، أي مجموع ذاكرة التخزين المؤقت وذاكرة التخزين المؤقت لنظام الملفات. تم تعيين هذا بواسطة ملف التكوين. ولا يتم تخصيص هذه الذاكرة.
وبسبب هذه المعلمة ، يمكننا نوعًا من خدعة Postgres ، بالقول إن لدينا بالفعل الكثير من البيانات المتاحة ، حتى لو لم تكن لدينا هذه البيانات. وبالتالي ، فإن الخطط سوف تتطابق تمامًا مع الإنتاج.
لكن هذا يمكن أن يؤثر على التوقيت. ونعمل على تحسين الاستعلامات حسب التوقيت ، ولكن من المهم أن يعتمد التوقيت على العديد من العوامل:
-
يعتمد ذلك على الحمل الموجود حاليًا على المنتج.
-
يعتمد ذلك على خصائص الجهاز نفسه.
وهذه معلمة غير مباشرة ، ولكن في الواقع يمكننا تحسينها بدقة من خلال كمية البيانات التي سيقرأها هذا الاستعلام للحصول على النتيجة.
وإذا كنت تريد أن يكون التوقيت قريبًا مما سنراه في المنتج ، فسنحتاج إلى استخدام الأجهزة الأكثر تشابهًا وربما أكثر حتى تتناسب جميع النسخ المستنسخة. لكن هذا حل وسط ، أي أنك ستحصل على نفس الخطط ، سترى مقدار البيانات التي سيقرأها استعلام معين وستكون قادرًا على استنتاج ما إذا كان هذا الاستعلام جيدًا (أو ترحيلًا) أو سيئًا ، فلا يزال بحاجة إلى التحسين .
دعنا نلقي نظرة على كيفية تحسين Joe على وجه التحديد.
لنأخذ طلبًا من نظام حقيقي. في هذه الحالة ، تبلغ قاعدة البيانات 1 تيرابايت. ونريد حساب عدد المشاركات الجديدة التي حصلت على أكثر من 10 إعجابات.
نكتب رسالة إلى القناة ، تم نشر نسخة من أجلنا. وسنرى أن هذا الطلب سيكتمل في غضون 2,5 دقيقة. هذا هو أول شيء نلاحظه.
سيُظهر لك B Joe توصيات تلقائية بناءً على الخطة والمقاييس.
سنرى أن الاستعلام يعالج الكثير من البيانات للحصول على عدد صغير نسبيًا من الصفوف. وهناك حاجة إلى نوع من الفهرس المتخصص ، لأننا لاحظنا وجود عدد كبير جدًا من الصفوف التي تمت تصفيتها في الاستعلام.
دعونا نلقي نظرة فاحصة على ما حدث. في الواقع ، نرى أننا قد قرأنا ما يقرب من غيغابايت ونصف من البيانات من ذاكرة التخزين المؤقت للملف أو حتى من القرص. وهذا ليس جيدًا ، لأن لدينا 142 سطرًا فقط.
ويبدو أن لدينا فحصًا للفهرس هنا وكان يجب أن ننجح بسرعة ، ولكن نظرًا لأننا قمنا بتصفية عدد كبير جدًا من السطور (كان علينا حسابها) ، فقد نجح الطلب ببطء.
وحدث ذلك في الخطة بسبب عدم تطابق شروط الاستعلام وشروط الفهرس جزئيًا.
دعنا نحاول جعل الفهرس أكثر دقة ونرى كيف يتغير تنفيذ الاستعلام بعد ذلك.
استغرق إنشاء الفهرس وقتًا طويلاً ، لكننا الآن نتحقق من الاستعلام ونرى أن الوقت بدلاً من 2,5 دقيقة هو 156 مللي ثانية فقط ، وهو أمر جيد بما فيه الكفاية. ونقرأ فقط 6 ميغا بايت من البيانات.
والآن نستخدم فحص الفهرس فقط.
قصة أخرى مهمة هي أننا نريد تقديم الخطة بطريقة أكثر قابلية للفهم. لقد قمنا بتنفيذ التصور باستخدام Flame Graphs.
هذا طلب مختلف وأكثر كثافة. ونحن نبني Flame Graphs وفقًا لمعاملين: هذا هو مقدار البيانات التي تحسبها عقدة معينة في الخطة والتوقيت ، أي وقت تنفيذ العقدة.
هنا يمكننا مقارنة عقد معينة مع بعضها البعض. وسيكون من الواضح أي منها يستغرق أكثر أو أقل ، وهو أمر يصعب عادةً القيام به في طرق العرض الأخرى.
بالطبع ، يعلم الجميعشرح. depesz.com. الميزة الجيدة لهذا التصور هي أننا نحفظ خطة النص ونضع أيضًا بعض المعلمات الأساسية في جدول حتى نتمكن من الفرز.
والمطورين الذين لم يتعمقوا في هذا الموضوع يستخدمون أيضًا expl.depesz.com ، لأنه من السهل عليهم معرفة المقاييس المهمة وأيها ليست كذلك.
هناك نهج جديد للتصور - هذا هوشرح.dalibo.com. إنهم يقومون بتصور الشجرة ، لكن من الصعب جدًا مقارنة العقد مع بعضها البعض. هنا يمكنك فهم الهيكل جيدًا ، ومع ذلك ، إذا كان هناك طلب كبير ، فستحتاج إلى التمرير ذهابًا وإيابًا ، ولكن أيضًا خيار.
Коллаборация
وكما قلت ، يمنحنا Slack الفرصة للتعاون. على سبيل المثال ، إذا صادفنا استعلامًا معقدًا ليس من الواضح كيفية التحسين ، فيمكننا توضيح هذه المشكلة مع زملائنا في سلسلة رسائل في Slack.
يبدو لنا أنه من المهم اختبار البيانات بالحجم الكامل. للقيام بذلك ، قمنا بعمل أداة Update Database Lab ، المتوفرة في البرامج مفتوحة المصدر. يمكنك استخدام Joe bot أيضًا. يمكنك أن تأخذها الآن وتنفيذه في مكانك. جميع الأدلة متوفرة هناك.
من المهم أيضًا ملاحظة أن الحل نفسه ليس ثوريًا ، لأن هناك Delphix ، ولكنه حل مؤسسي. إنه مغلق تمامًا ، إنه مكلف للغاية. نحن متخصصون على وجه التحديد في Postgres. هذه كلها منتجات مفتوحة المصدر. انضم إلينا!
هذا هو المكان الذي أنهي فيه. شكرًا لك!
الأسئلة
مرحبًا! شكرا على التقرير! ممتع للغاية ، خاصة بالنسبة لي ، لأنني قمت بحل نفس المشكلة منذ بعض الوقت. ولذا لدي عدد من الأسئلة. آمل أن أحصل على جزء منه على الأقل.
أتساءل كيف تحسب المكان لهذه البيئة؟ تعني التكنولوجيا أنه في ظل ظروف معينة ، يمكن أن تنمو الحيوانات المستنسخة إلى الحد الأقصى للحجم. بشكل تقريبي ، إذا كان لديك قاعدة بيانات بسعة 10 تيرابايت و 10 نسخ مستنسخة ، فمن السهل محاكاة موقف حيث تزن كل نسخة XNUMX بيانات فريدة. كيف تحسب هذا المكان ، أي تلك الدلتا التي تحدثت عنها ، والتي ستعيش فيها هذه الحيوانات المستنسخة؟
سؤال جيد. من المهم تتبع الحيوانات المستنسخة المحددة هنا. وإذا كان للنسخة بعض التغييرات الكبيرة جدًا ، فإنها تبدأ في النمو ، ثم يمكننا أولاً إصدار تحذير للمستخدم حول هذا الأمر ، أو إيقاف هذا الاستنساخ على الفور حتى لا يكون لدينا موقف فاشل.
نعم ، لدي سؤال متداخل. بمعنى ، كيف تضمن دورة حياة هذه الوحدات؟ لدينا هذه المشكلة وقصة منفصلة بالكامل. كيف يحدث هذا؟
هناك بعض ttl لكل نسخة. في الأساس ، لدينا ttl ثابت.
ماذا ، إن لم يكن سرا؟
1 ساعة ، أي الخمول - 1 ساعة. إذا لم يتم استخدامه ، فسنضربه. لكن ليس هناك ما يدعو للدهشة هنا ، حيث يمكننا رفع الاستنساخ في ثوانٍ. وإذا احتجت إليها مرة أخرى ، من فضلك.
أنا مهتم أيضًا باختيار التقنيات ، لأننا ، على سبيل المثال ، نستخدم عدة طرق بالتوازي لسبب أو لآخر. لماذا ZFS؟ لماذا لم تستخدم LVM؟ لقد ذكرت أن هناك مشاكل مع LVM. ما هي المشاكل؟ في رأيي ، الخيار الأمثل هو التخزين ، من حيث الأداء.
ما هي المشكلة الرئيسية في ZFS؟ حقيقة أنه يجب عليك العمل على نفس المضيف ، أي ستعيش جميع المثيلات داخل نفس نظام التشغيل. وفي حالة التخزين ، يمكنك توصيل معدات مختلفة. والعنق هو فقط تلك الكتل الموجودة في نظام التخزين. ومسألة اختيار التقنيات مثيرة للاهتمام. لماذا لا LVM؟
على وجه التحديد ، يمكننا مناقشة LVM في اللقاء. حول التخزين - إنها باهظة الثمن فقط. يمكننا تنفيذ نظام ZFS في أي مكان. يمكنك نشره على جهازك. يمكنك ببساطة تنزيل المستودع ونشره. يتم تثبيت ZFS في كل مكان تقريبًا إذا كنا نتحدث عن Linux. أي أننا نحصل على حل مرن للغاية. و ZFS نفسها تعطي الكثير من خارج الصندوق. يمكنك تحميل قدر ما تريد من البيانات ، وتوصيل عدد كبير من الأقراص ، وهناك لقطات. وكما قلت ، من السهل إدارتها. أي أنه يبدو ممتعًا جدًا للاستخدام. تم اختباره ، عمره سنوات عديدة. لديه مجتمع كبير جدًا ينمو. ZFS هو حل موثوق للغاية.
نيكولاي ساموخفالوف: هل لي أن أعلق أكثر؟ اسمي نيكولاي ، نعمل مع أناتولي. أوافق على أن التخزين رائع. وبعض عملائنا لديهم Pure Storage إلخ.
لاحظ أناتولي بشكل صحيح أننا نركز على النمطية. وفي المستقبل ، يمكنك تنفيذ واجهة واحدة - أخذ لقطة ، وإنشاء نسخة ، وتدمير النسخة. كل شيء سهل. والتخزين رائع ، إذا كان كذلك.
لكن ZFS متاح للجميع. DelPhix كافية بالفعل ، لديهم 300 عميل. من بين هؤلاء ، لدى Fortune 100 50 عميلًا ، أي أنهم يستهدفون وكالة ناسا ، وما إلى ذلك. حان الوقت للجميع للحصول على هذه التكنولوجيا. ولهذا السبب لدينا نواة مفتوحة المصدر. لدينا جزء واجهة ليس مفتوح المصدر. هذه هي المنصة التي سنعرضها. لكننا نريد أن يكون في متناول الجميع. نريد إحداث ثورة بحيث يتوقف جميع المختبرين عن التخمين على أجهزة الكمبيوتر المحمولة. علينا أن نكتب SELECT ونرى على الفور أنه بطيء. توقف عن انتظار DBA ليخبرك بذلك. هذا هو الهدف الرئيسي. وأعتقد أننا جميعًا سنصل إلى هذا. ونصنع هذا الشيء ليحصل عليه الجميع. لذلك ZFS ، لأنه سيكون متاحًا في كل مكان. شكرًا للمجتمع على حل المشكلات والحصول على ترخيص مفتوح المصدر ، إلخ. *
تحيات! شكرا على التقرير! اسمي مكسيم. لقد تعاملنا مع نفس القضايا. قرروا بأنفسهم. كيف تشارك الموارد بين هذه الحيوانات المستنسخة؟ يمكن لكل استنساخ أن يفعل شيئًا خاصًا به في أي وقت: يختبر أحد الأشياء شيئًا ، والآخر ، ويقوم أحدهم ببناء فهرس ، بينما يقوم شخص ما بعمل ثقيل. وإذا كان لا يزال بإمكانك القسمة على وحدة المعالجة المركزية ، ثم عن طريق الإدخال / الإخراج ، فكيف تقسم؟ هذا هو السؤال الأول.
والسؤال الثاني عن اختلاف المدرجات. لنفترض أن لدي ZFS هنا وكل شيء رائع ، لكن العميل على prod لا يحتوي على ZFS ، ولكن ext4 ، على سبيل المثال. كيف في هذه الحالة؟
الأسئلة جيدة جدا. لقد ذكرت هذه المشكلة قليلاً مع حقيقة أننا نتشارك الموارد. والحل هو هذا. تخيل أنك تختبر على مرحلة. يمكنك أيضًا أن يكون لديك مثل هذا الموقف في نفس الوقت الذي يعطي فيه شخص ما حمولة واحدة ، شخص آخر. ونتيجة لذلك ، ترى مقاييس غير مفهومة. حتى نفس المشكلة يمكن أن تكون مع prod. عندما تريد التحقق من بعض الطلبات وترى أن هناك مشكلة ما في ذلك - إنها تعمل ببطء ، ففي الحقيقة لم تكن المشكلة في الطلب ، ولكن في حقيقة أن هناك نوعًا من الحمل الموازي.
وبالتالي ، من المهم هنا التركيز على ماهية الخطة ، وما هي الخطوات التي سنتخذها في الخطة وكم البيانات التي سنجمعها لهذا الغرض. حقيقة أن أقراصنا ، على سبيل المثال ، سيتم تحميلها بشيء ما ، ستؤثر بشكل خاص على التوقيت. لكن يمكننا تقدير مدى تحميل هذا الطلب من خلال كمية البيانات. ليس من المهم أن يكون هناك نوع من التنفيذ في نفس الوقت.
لدي سؤالان. هذه أشياء رائعة جدا. هل كانت هناك حالات تكون فيها بيانات الإنتاج مهمة ، مثل أرقام بطاقات الائتمان؟ هل هناك شيء جاهز بالفعل أم أنه مهمة منفصلة؟ والسؤال الثاني - هل هناك شيء من هذا القبيل لـ MySQL؟
حول البيانات. سنقوم بالتعتيم حتى نقوم بذلك. ولكن إذا قمت بنشر Joe بالضبط ، إذا لم تمنح حق الوصول للمطورين ، فلن يكون هناك وصول إلى البيانات. لماذا؟ لأن Joe لا يُظهر البيانات. إنها تظهر فقط المقاييس والخطط وهذا كل شيء. تم ذلك عن قصد ، لأن هذا أحد متطلبات عملائنا. لقد أرادوا أن يكونوا قادرين على التحسين دون السماح للجميع بالوصول.
حول MySQL. يمكن استخدام هذا النظام لأي شيء يخزن الحالة على القرص. ونظرًا لأننا نقوم بتنفيذ Postgres ، فإننا نقوم الآن بكل أتمتة Postgres أولاً. نريد أتمتة الحصول على البيانات من نسخة احتياطية. نحن نقوم بتكوين Postgres بشكل صحيح. نحن نعرف كيف نجعل الخطط متطابقة ، إلخ.
ولكن نظرًا لأن النظام قابل للتوسعة ، فيمكن استخدامه أيضًا في MySQL. وهناك أمثلة من هذا القبيل. لدى Yandex شيء مشابه ، لكنهم لا ينشرونه في أي مكان. يستخدمونها داخل Yandex.Metrica. وهناك قصة فقط عن MySQL. لكن التقنيات هي نفسها ، ZFS.
شكرا على التقرير! لدي أيضا بعض الأسئلة. لقد ذكرت أنه يمكن استخدام الاستنساخ للتحليلات ، على سبيل المثال لبناء فهارس إضافية هناك. هل يمكنك معرفة المزيد عن كيفية عملها؟
وسأطرح على الفور السؤال الثاني حول تشابه المدرجات وتشابه المخططات. تعتمد الخطة أيضًا على الإحصائيات التي جمعتها Postgres. كيف تحل هذه المشكلة؟
وبحسب التحليلات ، لا توجد حالات محددة ، لأننا لم نستخدمها بعد ، ولكن توجد مثل هذه الفرصة. إذا كنا نتحدث عن الفهارس ، فتخيل أن استعلامًا يطارد جدولًا به مئات الملايين من السجلات وعمودًا لا تتم فهرسته عادةً في prod. ونريد حساب بعض البيانات هناك. إذا تم إرسال هذا الطلب إلى prod ، فهناك احتمال أن يكون بسيطًا على prod ، لأنه سيتم معالجة الطلب هناك لمدة دقيقة.
حسنًا ، دعنا نصنع استنساخًا رقيقًا ليس من الرهيب التوقف لبضع دقائق. ولجعل قراءة التحليلات أكثر راحة ، سنضيف مؤشرات لتلك الأعمدة التي نهتم بالبيانات فيها.
سيتم إنشاء الفهرس في كل مرة؟
يمكنك إجراء ذلك حتى نلمس البيانات ونقوم بلقطات ، ثم سنتعافى من هذه اللقطة ونوجه طلبات جديدة. وهذا يعني أنه يمكنك القيام بذلك بحيث يمكنك إنشاء نسخ جديدة بمؤشرات مثبتة بالفعل.
بالنسبة للسؤال حول الإحصائيات ، إذا استعدنا من نسخة احتياطية ، إذا قمنا بإجراء نسخ متماثل ، فستكون إحصائياتنا متطابقة تمامًا. نظرًا لأن لدينا بنية البيانات المادية بالكامل ، أي ، سنقوم بإحضار البيانات كما هي مع جميع مقاييس الإحصاء أيضًا.
هنا مشكلة أخرى. إذا كنت تستخدم حلًا سحابيًا ، فستتوفر هناك عمليات تفريغ منطقية فقط ، لأن Google و Amazon لا تسمحان لك بأخذ نسخة مادية. ستكون هناك مشكلة.
شكرا على التقرير. كان هناك سؤالان جيدان هنا حول MySQL ومشاركة الموارد. ولكن ، في الواقع ، كل ذلك يعود إلى حقيقة أن هذا ليس موضوعًا محددًا لنظام إدارة قواعد البيانات ، ولكن لنظام الملفات ككل. وبناءً على ذلك ، يجب أيضًا حل مشكلات مشاركة الموارد من هناك ، ليس في نهاية المطاف أنها Postgres ، ولكن في نظام الملفات ، في الخادم ، على سبيل المثال.
سؤالي مختلف قليلاً. إنه أقرب إلى قاعدة البيانات متعددة الطبقات ، حيث توجد عدة طبقات. على سبيل المثال ، قمنا بإعداد تحديث للصورة بحجم عشرة تيرابايت ، ونقوم بالنسخ المتماثل. ونستخدم هذا الحل على وجه التحديد لقواعد البيانات. النسخ المتماثل قيد التقدم ، يتم تحديث البيانات. هناك 100 موظف يعملون بالتوازي ، وهم يطلقون هذه اللقطات المختلفة باستمرار. ما يجب القيام به؟ كيف نتأكد من عدم وجود تعارض ، أنهم أطلقوا تعارض ، ثم تغير نظام الملفات ، وذهبت كل هذه الصور؟
لن يذهبوا لأن هذه هي الطريقة التي يعمل بها ZFS. يمكننا الاحتفاظ بشكل منفصل في سلسلة واحدة بتغييرات نظام الملفات التي تأتي بسبب النسخ المتماثل. واحتفظ بالنسخ التي يستخدمها المطورون في الإصدارات القديمة من البيانات. وهو يعمل بالنسبة لنا ، كل شيء على ما يرام مع هذا.
اتضح أن التحديث سيحدث كطبقة إضافية ، وستذهب جميع الصور الجديدة بالفعل ، بناءً على هذه الطبقة ، أليس كذلك؟
من الطبقات السابقة التي كانت من التكرارات السابقة.
ستسقط الطبقات السابقة ، لكنها ستشير إلى الطبقة القديمة ، وهل ستلتقط صورًا جديدة من الطبقة الأخيرة التي تم استلامها في التحديث؟
بشكل عام ، نعم.
ثم نتيجة لذلك سيكون لدينا ما يصل إلى طبقات التين. وبمرور الوقت سوف يحتاجون إلى الضغط؟
نعم كل شيء صحيح. هناك بعض النوافذ. نحتفظ بلقطات أسبوعية. يعتمد ذلك على الموارد التي لديك. إذا كانت لديك القدرة على تخزين الكثير من البيانات ، فيمكنك تخزين اللقطات لفترة طويلة. لن يذهبوا بمفردهم. لن يكون هناك تلف في البيانات. إذا كانت اللقطات قديمة ، كما يبدو لنا ، أي أنها تعتمد على السياسة المتبعة في الشركة ، فيمكننا حذفها وتحرير مساحة.
مرحبا ، شكرا على التقرير! سؤال عن جو. قلت إن العميل لا يريد منح الجميع حق الوصول إلى البيانات. بالمعنى الدقيق للكلمة ، إذا كان لدى الشخص نتيجة Explain Analyze ، فيمكنه أن يطلع على البيانات.
انها كذلك. على سبيل المثال ، يمكننا كتابة: "SELECT FROM WHERE email = to that". أي أننا لن نرى البيانات نفسها ، لكن يمكننا أن نرى بعض العلامات غير المباشرة. يجب فهم هذا. لكن من ناحية أخرى ، كل شيء هناك. لدينا تدقيق في السجل ، ولدينا سيطرة على الزملاء الآخرين الذين يرون أيضًا ما يفعله المطورون. وإذا حاول شخص ما القيام بذلك ، فستأتي إليه خدمة الأمن وتعمل على هذه المشكلة.
مساء الخير شكرا على التقرير! لدي سؤال قصير. إذا كانت الشركة لا تستخدم Slack ، فهل هناك أي ارتباط لها الآن ، أم أنه من الممكن للمطورين نشر مثيلات من أجل توصيل تطبيق اختباري بقواعد البيانات؟
يوجد الآن رابط إلى Slack ، أي لا يوجد برنامج مراسلة آخر ، لكنني أريد حقًا تقديم الدعم لمراسلين آخرين أيضًا. ما الذي تستطيع القيام به؟ يمكنك نشر DB Lab بدون Joe ، أو الذهاب بمساعدة REST API أو بمساعدة نظامنا الأساسي وإنشاء نسخ والتواصل مع PSQL. ولكن يمكن القيام بذلك إذا كنت مستعدًا لمنح مطوريك حق الوصول إلى البيانات ، لأنه لن يكون هناك أي شاشة.
لست بحاجة إلى هذه الطبقة ، لكني بحاجة لمثل هذه الفرصة.
ثم نعم ، يمكن القيام بذلك.
المصدر: www.habr.com