في Skyeng ، نستخدم Amazon Redshift ، بما في ذلك القياس المتوازي ، لذلك بدا مقال ستيفان جرومال ، مؤسس dotgo.com ، بالنسبة إلى intermix.io ، مثيراً للاهتمام بالنسبة لنا. بعد النقل - القليل من خبرتنا من المهندس وفق دانيار بلخودزاييف.تسمح
بنية Amazon Redshift بالتحجيم بإضافة عقد جديدة إلى الكتلة. الاضطرار إلى التعامل مع العدد الأقصى للطلبات يمكن أن يؤدي إلى الإفراط في توفير العقد. تحجيم التزامن ، على عكس إضافة عقد جديدة ، يزيد من قوة الحوسبة حسب الحاجة.
يمنح التوسع الأمازون Redshift مجموعات Redshift قوة إضافية لمعالجة طلبات الذروة. إنه يعمل عن طريق نقل الطلبات إلى مجموعات "متوازية" جديدة في الخلفية. يتم توجيه الطلبات بناءً على تكوين وقواعد WLM.
يعتمد تحديد سعر القياس الموازي على نموذج ائتمان للاستخدام المجاني. فوق قاعدة القروض المجانية ، يعتمد الدفع على الوقت الذي تطلب فيه مجموعة التحجيم المتوازي.
اختبار المؤلف التحجيم الموازي على واحدة من المجموعات الداخلية. في هذا المنشور ، سيتحدث عن نتائج الاختبار ويقدم نصائح حول كيفية البدء.
متطلبات الكتلة
لاستخدام القياس المتوازي ، يجب أن تفي مجموعة Amazon Redshift بالمتطلبات التالية:
- منصة: EC2-VPC.
- نوع العقدة: dc2.8xlarge ، ds2.8xlarge ، dc2.large أو ds2.xlarge ؛
- عدد العقد: من 2 إلى 32 (الكتل ذات العقدة الواحدة غير مدعومة).
أنواع الطلب صالحة
القياس المتوازي ليس مناسبًا لجميع أنواع الاستعلامات. في الإصدار الأول ، يعالج فقط طلبات القراءة التي تفي بالشروط الثلاثة:
- استعلامات SELECT للقراءة فقط (على الرغم من تخطيط المزيد من الأنواع) ؛
- لا يشير الاستعلام إلى جدول مع ترتيب INTERLEAVED؛
- لا يستخدم الاستعلام Amazon Amazon Redshift Spectrum للإشارة إلى الجداول الخارجية.
للتوجيه إلى كتلة تحجيم متوازية ، يجب أن يكون الطلب في قائمة الانتظار. بالإضافة إلى ذلك ، لن يتم تنفيذ الاستعلامات المناسبة
لقائمة الانتظار
SQA (تسريع الاستعلام القصير) في مجموعات تحجيم متوازية.
تتطلب قوائم الانتظار و SQAs التكوين الصحيح
لإدارة عبء العمل Redshift (WLM) . نوصي بتحسين WLM أولاً - هذا سوف يقلل من الحاجة إلى القياس المتوازي. وهذا مهم لأن التحجيم الموازي مجاني فقط لعدد معين من الساعات. تدعي AWS أن التوسع الموازي سيكون مجانيًا لـ 97٪ من العملاء ، وهو ما يقودنا إلى مسألة التسعير.
تكلفة التوسع الموازي
للتوسع الموازي ، تقدم AWS نموذج ائتمان. تجمع كل مجموعة نشطة من
مراكز Amazon Redshift القروض كل ساعة ، ما يصل إلى ساعة واحدة من قروض التحجيم المتوازية المجانية يوميًا.
أنت تدفع فقط عند استخدام مجموعات التحجيم المتوازية يتجاوز مبلغ القروض التي تلقيتها.
يتم حساب التكلفة بمعدل الطلب في الثانية الواحدة لمجموعة متوازية يتم استخدامها أكثر من المعدل المجاني. يتم إجراء الدفع فقط أثناء تنفيذ طلباتك ، مع حد أدنى للدفع قدره دقيقة واحدة ، في كل مرة تقوم فيها بتنشيط مجموعة تحجيم موازية. يتم احتساب معدل الطلب في الثانية بناءً على المبادئ العامة لتسعير
Amazon Redshift ، أي أنه يعتمد على نوع العقدة وعدد العقد في نظامك.
تشغيل القياس المتوازي
يبدأ القياس المتوازي لكل قائمة انتظار WLM. انتقل إلى وحدة التحكم AWS Redshift وحدد "إدارة عبء العمل" في قائمة التنقل اليسرى. حدد مجموعة WLM من الكتلة الخاصة بك في القائمة المنسدلة التالية.
سترى عمودًا جديدًا يسمى "وضع التحجيم المتزامن" بجوار كل قائمة انتظار. القيمة الافتراضية هي "إيقاف". انقر فوق "تغيير" ، ويمكنك تغيير الإعدادات لكل قائمة انتظار.
ترتيب
يعمل القياس المتوازي من خلال إعادة توجيه الاستعلامات ذات الصلة إلى مجموعات مخصصة جديدة. مجموعات جديدة لها نفس الحجم (نوع وعدد العقد) مثل الكتلة الرئيسية.
العدد الافتراضي من الكتل المستخدمة في القياس المتوازي هو واحد (1) مع القدرة على تكوين ما يصل إلى عشرة (10) مجموعات.
يمكن تعيين إجمالي عدد الكتل للتحجيم المتوازي بواسطة المعلمة max_concurrency_scaling_clusters. زيادة هذا الإعداد يوفر مجموعات إضافية زائدة عن الحاجة.
مراقبة
تحتوي وحدة التحكم AWS Redshift على العديد من الرسوم البيانية الإضافية. يعرض المخطط Max Configur Concalrency Scaling Clusters قيمة max_concurrency_scaling_clusters بمرور الوقت.
يتم عرض عدد مجموعات التحجيم النشطة في قسم "نشاط تحجيم التزامن" في واجهة المستخدم:
في علامة التبويب "الطلبات" ، يوجد عمود يوضح ما إذا كان قد تم تنفيذ الطلب في المجموعة الرئيسية أم في مجموعة التحجيم الموازية:
بغض النظر عما إذا كان قد تم تنفيذ طلب معين في الكتلة الرئيسية أم من خلال كتلة تحجيم متوازية ، يتم تخزينه في stl_query.concurrency_scaling_status.
تشير القيمة 1 إلى أن الطلب كان قيد التشغيل في كتلة تحجيم متوازية ، بينما تشير القيم الأخرى إلى أنه كان قيد التشغيل في الكتلة الرئيسية.
مثال:
يتم أيضًا تخزين معلومات حول القياس المتوازي في بعض الجداول وطرق العرض الأخرى ، على سبيل المثال ، SVCS_CONCURRENCY_SCALING_USAGE. بالإضافة إلى ذلك ، هناك عدد من جداول الكتالوج التي تخزن معلومات حول القياس المتوازي.
النتائج
أطلق المؤلفون تحجيم مواز لقائمة انتظار واحدة في المجموعة الداخلية في حوالي الساعة 6:30 مساءً بتوقيت جرينتش يوم 29/29 .9 قاموا بتغيير المعلمة max_concurrency_scaling_clusters إلى 3 في حوالي الساعة 8:30 مساءً في 29 مارس 2019.
لمحاكاة قائمة انتظار الطلب ، وخفض عدد فتحات قائمة الانتظار هذه من 15 إلى 5.
التالي هو مخطط لوحة معلومات intermix.io يُظهر عدد الطلبات قيد التشغيل وقائمة الانتظار بعد تقليل عدد الفتحات.
نرى أن وقت الانتظار للطلبات في قائمة الانتظار قد زاد ، في حين أن الحد الأقصى للوقت هو أكثر من 5 دقائق.
فيما يلي المعلومات ذات الصلة من وحدة التحكم AWS حول ما حدث خلال هذا الوقت:
أطلقت شركة Redshift ثلاثة (3) مجموعات تحجيم متوازية حسب التكوين. يبدو أن هذه الكتل لم تستخدم بالكامل ، على الرغم من أن العديد من الطلبات في نظامنا تم وضعها في قائمة الانتظار.
يرتبط الرسم البياني الاستخدام مع الرسم البياني لنشاط القياس:
بعد بضع ساعات ، راجع المؤلفون قائمة الانتظار ، ويبدو أنه تم تنفيذ 6 طلبات مع التحجيم الموازي. لقد فحصنا أيضًا طلبين بشكل انتقائي من خلال واجهة المستخدم. لم يتحققوا من كيفية استخدام هذه القيم عندما تكون عدة مجموعات متوازية نشطة في آن واحد.
النتائج
يمكن أن يؤدي القياس المتوازي إلى تقليل وقت قائمة انتظار الطلبات أثناء تحميلات الذروة.
وفقا لنتائج الاختبار الأساسي ، اتضح أن الوضع مع طلبات التحميل قد تحسنت جزئيا. ومع ذلك ، فإن القياس المتوازي وحده لم يحل جميع مشاكل التزامن.
هذا بسبب القيود المفروضة على أنواع الاستعلامات التي يمكنها استخدام القياس المتوازي. على سبيل المثال ، يحتوي المؤلفون على العديد من الجداول التي تحتوي على مفاتيح الفرز المتشابك ، ومعظم عبء العمل لدينا سجل.
على الرغم من أن القياس المتوازي ليس حلاً عالميًا في تكوين WLM ، إلا أن استخدام هذه الوظيفة في أي حال من الأحوال بسيط ومفهوم.
لذلك ، يوصي المؤلف باستخدامه لقوائم WLM الخاصة بك. ابدأ باستخدام مجموعة متوازية واحدة وقم بمراقبة الحمل الأقصى من خلال وحدة التحكم لتحديد ما إذا كانت المجموعات الجديدة مستخدمة بالكامل.
نظرًا لأن AWS يضيف دعمًا لأنواع إضافية من الاستعلامات والجداول ، فيجب أن يصبح التحجيم الموازي تدريجيًا أكثر فعالية.
تعليق بيلخودزيف دانيار ، مهندس وفقًا لسكينج
كما لفتنا في Skyeng الانتباه على الفور إلى الإمكانية الناشئة المتمثلة في التوسع الموازي.
الوظيفة جذابة للغاية ، خاصة بالنظر إلى حقيقة أنه وفقًا لـ AWS ، فإن معظم المستخدمين لا يضطرون حتى إلى دفع رسوم إضافية مقابل ذلك.
لقد حدث أنه في منتصف أبريل كان لدينا عدد غير عادي من الطلبات إلى مجموعة Redshift. خلال هذه الفترة ، لجأنا غالبًا إلى المساعدة من تحجيم التزامن ، وأحيانًا كانت المجموعة الإضافية تعمل على مدار الساعة دون توقف.
هذا يسمح ، إن لم يكن حل مشكلة قائمة الانتظار بالكامل ، على الأقل بجعل الموقف مقبولاً.
ملاحظاتنا تتزامن إلى حد كبير مع انطباع الرجال من intermix.io.
لاحظنا أيضًا أنه على الرغم من وجود الطلبات المعلقة في قائمة الانتظار ، لم تتم إعادة توجيه جميع الطلبات على الفور إلى مجموعة موازية. يبدو أن هذا يرجع إلى حقيقة أن الكتلة الموازية لا تزال تستغرق وقتًا للبدء. نتيجةً لذلك ، خلال حملات الذروة القصيرة الأجل ، لا يزال لدينا طوابير صغيرة ، وأجهزة الإنذار المقابلة لديها وقت للعمل.
بعد التخلص من الأحمال غير الطبيعية في شهر أبريل ، كما توقعنا AWS ، دخلنا في وضع الاستخدام العرضي - كجزء من القاعدة الحرة.
يمكنك تتبع تكاليف القياس المتزامنة في AWS Cost Explorer. تحتاج إلى تحديد Service - Redshift ، ونوع الاستخدام - CS ، على سبيل المثال ، USW2-CS: dc2.large.
يمكن الاطلاع على تفاصيل الأسعار باللغة الروسية هنا.