استمرارًا لـ "
استخلاص المعلومات " مع HighLoad ++ 2017 ، قمنا بإعداد مراجعة قصيرة لأفضل خمسة تقارير (وفقًا للمشاركين في المؤتمر) باللغة الإنجليزية.
تم إعطاء أعلى الدرجات للموضوعات المتعلقة باستخدام ProxySQL (في TOP 5 كان هناك تقريران حول هذه الأداة) ، واختبار التطبيق في سحابة الأمازون العامة ، وكذلك مبادئ تسجيل الدخول على نطاق عندما يصبح هذا مشكلة ، ومراقبة Apache Kafka.
لقد نشرنا للتو مقاطع فيديو لجميع تقارير HighLoad ++ 2017 للوصول المجاني. قائمة كاملة من 150 تقريرًا على قناة YouTube الخاصة بنا في قائمة التشغيل هذه.
بالإضافة إلى قائمة التشغيل هذه ، تحتوي القناة على عدة مئات من مقاطع الفيديو حول قواعد البيانات ، والبنى ، والقياس ، وقوائم الانتظار ، والتعلم الآلي ، وغيرها من الحكمة عالية الحمل :)
قياس تباين أداء EC2
Henrik Ingo (مهندس حلول MongoDB ، والآن مهندس إنتاجية رئيسي في Mongo DB).يشير التقرير الأول ، الذي لاحظه المشاركون ، إلى أنه يمكن بالفعل استخدام السحابة العامة لاختبار منتجاتهم الخاصة ، بما في ذلك اختبار الحمل. في هذه الحالة ، كان MongoDB DBMS ، الذي يتم اختباره باستخدام سحابة Amazon ، هو "تجريبي". في المجموع ، يتم إنفاق حوالي 400 ألف ساعة على هذه المهمة شهريًا ، حوالي 5 ٪ من هذا الوقت هو فقط اختبارات الأداء ، التي لا تتمثل مهمتها الرئيسية في توفير التحسين ، وعدم السماح بـ "الهبوط" نتيجة لبعض التحسينات.
السؤال الرئيسي للعرض التقديمي هو كيفية الحصول على نتائج اختبار قابلة للتكرار في السحابة العامة.
التقرير مبني على مبدأ تحليل الفرضيات. في البداية ، يضع Henrik Ingo افتراضات حول العوامل التي يجب أن تؤثر على مستوى "الضجيج" في الاختبارات (مفهوم "الضجيج" في التقرير له تعريف محدد للغاية). على سبيل المثال ، اقترح فريق الاختبار أنه في الاختبارات "الثقيلة" يأتي "الضجيج" الرئيسي من محرك الأقراص الثابتة ، أو أنه في السحابة ، عند توزيع الموارد ، يمكنك أن تواجه جيدًا (مخصص بالكامل) أو سيئ (مشترك مع من قبل شخص ما) الحالات التي تؤثر على نتائج الاختبار.
بعد ذلك ، يتم تحليل نتائج اختبار كل من النظريات مع عرض لبعض التبعيات المثيرة للاهتمام. على سبيل المثال ، فيما يلي رسم بياني لاعتماد مستوى "الضوضاء" (في مصطلحات التقرير) على تكوين المثيل المحدد:
لعدم وجود معلومات حول تفاصيل البنية التحتية في أمازون ، لا يجيب التقرير على جميع الأسئلة ، في بعض الحالات يفترض فقط الافتراضات ، ولكن هناك شيء يجب التفكير فيه.
قطع الأشجار والصراخ
Vytis Valentinavičius (لامودا ، قيادة العمليات)التقرير التالي المثير للاهتمام هو أفكار أحد المتخصصين في متجر لامودا الكبير عبر الإنترنت حول التسجيل وكيف يجب أن يكون الأمر حتى يتمكن المطورون ، من جهة ، من تلقي البيانات اللازمة بالكامل ، ومن ناحية أخرى ، لا يغرقون في غيغابايت من المعلومات الواردة. والمتكلم يعرف ما يتحدث عنه. المشكلة التي بدأت في بناء العمل باستخدام السجلات في Lamoda هي فقدان 5 ٪ من التقارير المرسلة من قبل المستخدمين عبر UDP (في بعض الحالات وصلت هذه المشاركة إلى 100 ٪). وقد شوه هذا بشكل خطير جميع المقاييس التي يمكن بناؤها على أساسها.
يخبر التقرير كيف لا تكشف مثل هذا الموقف ، ولكن كيف تمنعه ، من حيث المبدأ ، بالنظر إلى أن العديد من الحلول الواضحة لها مآزقها.
يركز Vytis Valentinavičius على حقيقة أن السجل يجب أن يكون له هيكل. ولكن في نفس الوقت لا يمكن تضخيمه. يجب أن يكون هناك غرض لجمع وتخزين كل حقل ، لأن أي بيانات يتم جمعها هي أموال. مثال على لامودا هو 25 ألف رسالة سجل تصحيح في الثانية (32 تيرابايت من المعلومات أسبوعيًا ، والتي يكلف التخزين وحده 12 ألف دولار).
بالإضافة إلى ذلك ، من المهم تتبع الأحداث ، وليس الأخطاء المحددة. يجب أن يتم تجميعها وتحديد المقاييس واستنادًا إلى تحليلها لبناء أحداث أكثر تعقيدًا للتجميع في المستقبل.
بالإضافة إلى الاعتبارات النظرية ، يصف التقرير بعض الحيل التي استخدمتها Lamoda في الإنتاج للعمل مع السجلات.
المقاييس ليست كافية: مراقبة أباتشي كافكا
جوين شابيرا (Confluent ، مدير المنتج)يتعلق التقرير التالي بمراقبة Apache Kafka ، أو بالأحرى ، المقاييس التي يجب اختيارها من وفرة المعلمات المتاحة للتحليل لفهم حالة وسيط الرسائل في أي وقت.
بدأت المتحدثة قصتها بنكتة ، حيث ، كما يقولون ، ليس هناك سوى جزء صغير من النكتة: "حتى إذا كنت لا تستطيع تذكر محتويات التقرير بأكمله ، تذكر شيئًا واحدًا: إذا تم استخدام كافكا في الإنتاج ، فيجب مراقبته" (جيد ، يتم توفير واجهة برمجة التطبيقات المقابلة لذلك )
هل من الضروري مراقبة كل شيء؟ يعتمد على المهمة. ومنهم يصد جوين شابيرا ، يحلل المقاييس الموصى بها. يصف المتحدث حالات التشغيل القياسية ويوصي بالمعلمات التي يجب إضافتها إلى لوحة القيادة من أجل الاستجابة لما يحدث في الوقت المناسب ، وكيفية عدم تفاقم الوضع. على وجه الخصوص ، يذكر مرة أخرى أنه ليس من الضروري إعادة تشغيل الوسيط عند التغيير الأول للمقاييس ، لأنه يستغرق الكثير من الوقت وأحيانًا (بسبب أخطاء معروفة) يمكن أن يؤدي إلى عواقب أكثر خطورة. في النهاية ، تعد المقاييس مجرد بيانات أولية. ومن أجل اتخاذ القرارات ، يجب أن يكون لدى المرء فرضيات تستند إلى هذه البيانات.
بفضل خبرة جوين شابيرا الواسعة كمستشار ، فإن العرض التقديمي بأكمله مصحوب بأمثلة حية من الحياة.
سيناريوهات استخدام حالة ProxySQL
ألكين تيزويسال (بيرسونا ، فريق DBA العالمي)تقريران على الفور ، وفقًا لتقديرات المشاركين ، كانا في أعلى 5 ، يتعلقان بـ ProxySQL ، وهي وسيلة لاستعلام SQL عن الخادم الوكيل بـ MySQL (ومؤخرا ClickHouse).
يتعلق التقرير الأول عمومًا بسيناريوهات استخدام هذه الأداة.
ProxySQL هو حل مفتوح المصدر ، حتى الآن لم نواجه مثل هذا الجوهر من الخبرة. نعم ، تقوم العديد من الشركات بتنزيل هذا الحل ، ولكن حتى الشركة المصنعة نفسها لا تفهم دائمًا من سيستخدمه وعلى أي نطاق. تم تحديد السيناريوهات التي تم جمعها في هذا التقرير كنتيجة للتواصل مع مستخدمي ProxySQL وتحليل حالاتهم.
بشكل عام ، يتيح لك ProxySQL حل عدد كبير من المهام ، من موازنة التحميل وإعادة كتابة الاستعلامات (التي سيتم مناقشتها في التقرير التالي من قائمتنا) ، إلى قائمة انتظار الاستعلام وتسخين ذاكرة التخزين المؤقت ، وهي ليست في MySQL. كل من الخيارات Alkin Tezuysal يوزع بالتفصيل ، مع الإشارة إلى مزايا وعيوب الحل ، بالإضافة إلى الحالات الخاصة التي قد يكون فيها مفيدًا.
نذكر هنا مثالين فقط فيما يتعلق بتحسين قاعدة البيانات.
المثال 1 - استخدام ProxySQL لتقليل عدد الطلبات لإنشاء اتصال تطبيق بقاعدة البيانات. تنعكس الفكرة بيانياً في الرسم البياني الوارد في التقرير:
ProxySQL يقلل بشكل كبير من عدد طلبات الاتصال ، وخاصة عند استخدام SSL.
المثال 2 - تصفية الاستعلامات عديمة الفائدة (مثل SELECT 1 ، التي تظهر في التطبيقات واسعة النطاق) التي تبطئ قاعدة البيانات. هنا ، يتم أيضًا تقييم النتيجة بشكل أفضل بيانيًا:
Datamasking غير مكلفة ل MySQL مع ProxySQL - إخفاء هوية البيانات للمطورين
رينيه كاناو (مؤسس ومالك المنتج ProxySQL)التقرير الثاني باللغة الإنجليزية حول ProxySQL ، والذي دخل إلى TOP-5 ، مخصص لحل مشكلة محددة للغاية - إخفاء البيانات.
بعد مقدمة موجزة إلى ProxySQL لأولئك الذين لم يروا التقرير الأول ، يغرق المتحدث في إمكانات الأداة فيما يتعلق بحل مشكلة معينة - إخفاء (استبدال بعلامات النجمة) جزء من الاسم أو استبدال المبلغ الحقيقي للدخل بأخرى مزيفة.
كما يلاحظ المتحدث ، يمكن حل هذه المشكلة باستخدام وسائلك الخاصة لنفس MySQL أو منتجات الطرف الثالث. بين ProxySQL طرف ثالث بعيد عن الأداة الوحيدة. ومع ذلك ، في حين لا يوجد حل مثالي في السوق ، و ProxySQL ليس أسوأ من كثير ، مما يسمح للمطورين بالحصول على بيانات صالحة للاختبارات التي لا تحتوي على معلومات شخصية حقيقية. علاوة على ذلك ، لديها كود مفتوح المصدر.
إذا كانت القصة الأولى حول ProxySQL أكثر نظريًا ، فهنا ممارسة مستمرة. حتى القواعد التي تم تكوينها باستخدام التعبيرات العادية مذكورة.
مثل أي أداة proxySQL لها حدودها. سيتم مناقشة هذا أيضا. على وجه الخصوص ، ليس هذا هو أفضل نهج للتحولات المعقدة.
انتهى التقرير بقسم كامل من الأسئلة والأجوبة ، حيث يمكنك أيضًا تعلم الكثير من الأشياء المفيدة والمثيرة للاهتمام.
بالطبع ، هذه اللغة الخمسة الناطقة بالإنجليزية هي مجرد قمة جبل الجليد الذي كان في HighLoad ++ 2017. لذلك ، نتذكر أننا نشرنا للتو مقاطع فيديو لجميع تقارير المؤتمر التي يمكن العثور عليها في
قائمة التشغيل هذه .
سيعقد HighLoad ++ 2018 يومي 8 و 9 نوفمبر في موسكو ، في سكولكوفو. العمل على البرنامج قيد التنفيذ بالفعل ، ولكن يمكن تقديم التقرير قبل 1 سبتمبر.