قائمة التحقق من الأداء وقابلية التوسع لتخزين Blob
طورت Microsoft عددًا من الممارسات المجربة لتطوير تطبيقات عالية الأداء مع تخزين كائن ثنائي كبير الحجم. تحدد قائمة اختيار الممارسات الرئيسية التي يمكن للمطورين اتباعها لتحسين الأداء. تذكّر هذه الممارسات أثناء تصميم التطبيق الخاص بك وخلال العملية بالكامل.
يحتوي Azure Storage على أهداف قابلية التوسع والأداء للسعة ومعدل الحركة والنطاق الترددي. لمزيد من المعلومات حول أهداف قابلية التوسع في تخزين Azure، راجع أهداف قابلية التوسع والأداء لحسابات التخزين القياسية وأهداف قابلية التوسع والأداء لتخزين كائن ثنائي كبير الحجم.
قائمة الاختيار
تنظم هذه المقالة الممارسات المثبتة للأداء في قائمة تحقق يمكنك اتباعها في أثناء تطوير تطبيق تخزين كائن ثنائي كبير الحجم خاصتك.
أهداف قابلية التوسع
إذا كان التطبيق الخاص بك يقترب من أهداف قابلية التوسع أو يتجاوزها، قد تواجه زيادة أزمنة انتقال الحركة أو التقييد. عندما يقوم Azure Storage بتقييد التطبيق لديك، تبدأ الخدمة بإرجاع رموز الخطأ 503 (الخادم مشغول) أو خطأ 500 (انتهاء مهلة العملية). يمثل تجنب هذه الأخطاء بالتواجد ضمن حدود أهداف قابلية التوسع جزءًا مهمًا من تحسين أداء التطبيق لديك.
لمزيد من المعلومات حول أهداف قابلية التوسع لخدمة قائمة الانتظار، راجع أهداف قابلية التوسع والأداء لتخزين Azure .
أقصى عدد لحسابات التخزين
إذا كنت تقترب من الحد الأقصى لعدد حسابات التخزين المسموح بها لمجموعة اشتراك/منطقة معينة، فقيّم السيناريو خاصتك وحدد ما إذا كان أي من الشروط التالية ينطبق:
- هل تستخدم حسابات التخزين لتخزين الأقراص غير المدارة وإضافة هذه الأقراص إلى أجهزتك الافتراضية (VMS )؟ بالنسبة إلى هذا السيناريو، توصي Microsoft باستخدام الأقراص المدارة. مقياس الأقراص المدارة لك تلقائيًا ودون الحاجة إلى إنشاء وإدارة حسابات تخزين فردية. لمزيد من المعلومات، راجع مقدمة إلى الأقراص التي تديرها Azure
- هل تستخدم حساب تخزين واحد لكل عميل، لغرض عزل البيانات؟ بالنسبة إلى هذا السيناريو، توصي Microsoft باستخدام حاوية كائن ثنائي كبير الحجم لكل عميل، بدلاً من حساب تخزين كامل. يسمح لك تخزين Azure الآن بتعيين أدوار Azure على أساس كل حاوية. لمزيد من المعلومات، راجع تعيين دور Azure للوصول إلى بيانات كائن ثنائي كبير الحجم.
- هل تستخدم حسابات تخزين متعددة لزيادة عمليات الدخول أو الخروج أو الإدخال/الإخراج في الثانية (IOPS) أو السعة؟ في هذا السيناريو، توصي Microsoft بالاستفادة من زيادة حدود حسابات التخزين لتقليل عدد حسابات التخزين اللازمة لحمل العمل الخاص بك إذا أمكن. اتصل ِAzure Support لطلب زيادة حدود حساب التخزين لديك. للحصول على مزيد من المعلومات، راجع الإعلان عن حسابات تخزين أكبر وأعلى حجمًا.
أهداف السعة والحركة
في حال كان التطبيق لديك يقترب من أهداف قابلية التوسع لحساب تخزين واحد، فحاول استخدام أحد النهج التالية:
- إذا وصل طلبك إلى هدف المعاملة، ففكر في استخدام حسابات تخزين كتلة كائن ثنائي كبير الحجم، والتي تم تحسينها لمعدلات المعاملات المرتفعة والوقت المستغرق المنخفض والثابت. لمزيد من المعلومات، راجع نظرة عامة على حساب تخزين Azure.
- يُرجى مراعاة حمل العمل الذي يتسبب في اقتراب التطبيق لديك من هدف قابلية التوسع أو في تجاوزه. هل يمكنك تصميمه بشكل مختلف لتقليل استخدام النطاق الترددي أو السعة، أو حركات أقل؟
- في حال كان يجب أن يتجاوز التطبيق الخاص بك أحد أهداف قابلية التوسع، فيُرجى إنشاء حسابات تخزين متعددة وتقسيم بيانات التطبيق لديك عبر حسابات التخزين المتعددة هذه. في حال كنت تستخدم هذا النمط، فتأكد من تصميم التطبيق الخاص بك حيث يمكنك إضافة المزيد من حسابات التخزين في المستقبل لموازنة التحميل. ليس لحسابات التخزين نفسها أي تكلفة غير استخدامك فيما يتعلق بالبيانات المخزنة أو الحركات المنفذة أو البيانات المنقولة.
- في حال كان التطبيق يقترب من أهداف النطاق الترددي، فحاول ضغط البيانات من جانب العميل لتقليل النطاق الترددي اللازم لإرسال البيانات إلى Azure Storage. بينما ضغط البيانات قد يحفظ النطاق الترددي ويُحسن أداء الشبكة، فيمكن أيضًا أن يكون له تأثيرات سلبية على الأداء. قيم تأثير أداء متطلبات المعالجة الإضافية لضغط البيانات وفك الضغط من جانب العميل. تذكَّر أن تخزين البيانات المضغوطة يمكن أن يجعل استكشاف الأخطاء وإصلاحها أكثر صعوبة لأنه قد يكون من الصعب عرض البيانات باستخدام أدوات قياسية.
- إذا كان التطبيق الخاص بك يقترب من أهداف قابلية التوسع، يُرجى التأكد من استخدام التراجع الأسي لإعادة المحاولات. من الأفضل محاولة تجنب الوصول إلى أهداف قابلية التوسع بتنفيذ التوصيات الموضحة في هذه المقالة. ومع ذلك، سيمنع التراجع الأسي للمحاولات التطبيق الخاص بك من إعادة المحاولة بسرعة، ما قد يجعل التقييد في وضع أسوأ. للحصول على مزيد من المعلومات، راجع القسم بعنوان أخطاء انتهاء المهلة والخادم مشغول.
وصول العديد من العملاء إلى كائن ثنائي كبير الحجم واحد في وقت واحد
إذا كان لديك عدد كبير من العملاء الذين يصلون إلى كائن ثنائي كبير الحجم واحد في وقت واحد، فستحتاج إلى النظر في أهداف قابلية التوسع لكل كائن ثنائي كبير الحجم ولكل حساب تخزين. يختلف العدد الحقيقي للعملاء الذين يمكنهم الوصول إلى كائن ثنائي كبير الحجم واحد اعتمادًا على عوامل مثل عدد العملاء الذين يطلبون الكائن الثنائي كبير الحجم في وقت واحد، وحجم الكائن الثنائي كبير الحجم، وظروف الشبكة.
إذا كان من الممكن توزيع الكائن الثنائي كبير الحجم من خلال CDN مثل الصور أو مقاطع الفيديو التي يتم عرضها من موقع ويب، فإنه يمكنك استخدام CDN. لمزيد من المعلومات، راجع القسم بعنوان توزيع المحتوى.
في سيناريوهات أخرى، مثل المحاكاة العلمية حيث تكون البيانات سرية، لديك خياران. الأول هو ترتيب الوصول إلى حِمل العمل خاصتك بحيث يتم الوصول إلى الكائن الثنائي كبير الحجم خلال فترة من الزمن مقابل الوصول إليها في وقت واحد. بدلاً من ذلك، يمكنك نسخ الكائن الثنائي كبير الحجم مؤقتًا إلى حسابات تخزين متعددة لزيادة إجمالي عمليات الإدخال والإخراج في الثانية لكل كائن ثنائي كبير الحجم وعبر حسابات التخزين. ستختلف النتائج اعتمادًا على سلوك تطبيقك، لذلك تأكد من اختبار أنماط التطابق أثناء التصميم.
عرض النطاق الترددي والعمليات لكل كائن ثنائي كبير الحجم
يدعم كائن ثنائي كبير الحجم واحد ما يصل إلى 500 طلب في الثانية. إذا كان لديك العديد من العملاء الذين يحتاجون إلى قراءة نفس الكائن الثنائي كبير الحجم وقد تتجاوز هذا الحد، ففكر في استخدام حساب تخزين كائن ثنائي كبير الحجم. يوفر حساب تخزين كائن ثنائي كبير الحجم معدل طلب أعلى، أو عمليات الإدخال/الإخراج في الثانية (IOPS).
يمكنك أيضًا استخدام شبكة توصيل المحتوى (CDN) مثل Azure CDN لتوزيع العمليات على الكائن الثنائي كبير الحجم. لمزيد من المعلومات حول Azure CDN، راجع نظرة عامة على Azure CDN.
التقسيم
يعتبر فهم كيفية تقسيم تخزين Azure لبيانات كائن ثنائي كبير الحجم مفيدًا لتحسين الأداء. يمكن لتخزين Azure تقديم البيانات في قسم واحد بسرعة أكبر من البيانات التي تمتد عبر أقسام متعددة. من خلال تسمية الكائنات الثنائية كبيرة الحجم خاصتك بشكل مناسب، يمكنك تحسين كفاءة قراءة الطلبات.
يستخدم تخزين كائن ثنائي كبير الحجم مخطط تقسيم قائم على النطاق لتوسيع النطاق وموازنة الحمل. يحتوي كل كائن ثنائي كبير الحجم على مفتاح تقسيم يتكون من الاسم الكامل لكائن ثنائي كبير الحجم (الحساب+الحاوية+الكائن الثنائي كبير الحجم). يُستخدم مفتاح التقسيم لتقسيم بيانات الكائنات الثنائية كبيرة الحجم إلى نطاقات. بعد ذلك تكون النطاقات متوازنة الحمل عبر تخزين كائن ثنائي كبير الحجم.
التقسيم القائم على النطاق يعني أن تسمية الاتفاقيات التي تستخدم الترتيب المعجمي (على سبيل المثال، mypayroll ، myperformance ، myemaffees ، وما إلى ذلك) أو الطوابع الزمنية ( log 20160101 ، log 20160102 ، log 20160102 ، وما إلى ذلك) من المرجح أن تؤدي إلى وضع الأقسام بشكل مشترك على نفس خادم التقسيم حتى يتطلب الحمل المتزايد تقسيمها إلى نطاقات أصغر. إن وضع الكائنات الثنائية كبيرة الحجم على نفس خادم القسم يعزز الأداء، لذا فإن جزءًا مهمًا من تحسين الأداء يتضمن تسمية الكائن الثنائي كبير الحجم بطريقة تنظمها بشكل أكثر فعالية.
على سبيل المثال، يمكن خدمة جميع الكائنات الثنائية كبيرة الحجم داخل الحاوية بواسطة خادم واحد حتى يتطلب الحمل على هذه الكائنات الثنائية كبيرة الحجم المزيد من إعادة التوازن لنطاقات التقسيم. وبالمثل، يمكن خدمة مجموعة من الحسابات خفيفة التحميل بأسمائها مرتبة بترتيب معجمي بواسطة خادم واحد حتى يتطلب الحمل على واحد من هذه الحسابات أو جميعها تقسيمها عبر العديد من خوادم التقسيم.
يمكن أن تؤثر كل عملية موازنة حمل على زمن وصول مكالمات التخزين في أثناء العملية. قدرة الخدمة على التعامل مع الاندفاع المفاجئ لحركة المرور إلى أحد الأقسام محدودة من خلال قابلية توسيع خادم قسم واحد حتى تبدأ عملية موازنة الحمل وإعادة موازنة نطاق مفتاح التقسيم.
يمكنك اتباع بعض أفضل الممارسات لتقليل وتيرة هذه العمليات.
إذا أمكن، فاستخدم أحجام كائنات ثنائية كبيرة الحجم أو بلوك أكبر من 256 كيلوبايت لحسابات التخزين القياسية والمتميزة. تنشط أحجام الكائنات الثنائية كبيرة الحجم أو الكتل الأكبر تلقائيًا كائنات ثنائية كبيرة الحجم للكتلة ذات معدل نقل عالٍ. توفر كائنات ثنائية كبيرة الحجم للكتلة معدل النقل ابتلاعًا عالي الأداء لا يتأثر بتسمية القسم.
افحص اتفاقية التسمية التي تستخدمها للحسابات والحاويات والكائنات الثنائية كبيرة الحجم والجداول وقوائم الانتظار. ضع في اعتبارك إضافة بادئة لأسماء الحسابات أو الحاويات أو الكائنات الثنائية كبيرة الحجم باستخدام تجزئة مكونة من ثلاثة أرقام باستخدام وظيفة تجزئة تناسب احتياجاتك على أفضل وجه.
إذا نظمت بياناتك باستخدام الطوابع الزمنية أو المعرفات العددية، فتأكد من أنك لا تستخدم نمط حركة مرور الملحق فقط (أو الطوابع فقط). هذه الأنماط غير مناسبة لنظام تقسيم قائم على النطاق. قد تؤدي هذه الأنماط إلى ذهاب كل حركة المرور إلى قسم واحد والحد من موازنة الحمل بشكل فعال.
على سبيل المثال، إذا كانت لديك عمليات يومية تستخدم كائنًا ثنائيًا كبير الحجم مع طابع زمني مثل yyyymmdd، توجيه كل حركة المرور لهذه العملية اليومية إلى كائن ثنائي كبير الحجم واحد، والتي يتم تقديمها بواسطة خادم قسم واحد. ضع في اعتبارك ما إذا كانت حدود كل كائن ثنائي كبير الحجم وحدود كل قسم تلبي احتياجاتك، وفكر في تقسيم هذه العملية إلى كائنات ثنائية كبيرة الحجم متعددة إذا لزم الأمر. وبالمثل، إذا خزنت بيانات السلاسل الزمنية في جداولك، فقد يتم توجيه جميع الزيارات إلى الجزء الأخير من مساحة الاسم الرئيسية. إذا كنت تستخدم معرّفات رقمية، فبادئ المعرّف بتجزئة مكونة من ثلاثة أرقام. إذا كنت تستخدم الطوابع الزمنية، فبادئ الطوابع الزمنية بقيمة الثواني، على سبيل المثال، ssyyymmdd. إذا كان التطبيق خاصتك يؤدي بشكل روتيني عمليات الإدراج والاستعلام، فاختر وظيفة التجزئة التي ستقلل من عدد الاستعلامات خاصتك. في بعض الحالات، قد تكون البادئة العشوائية كافية.
لمزيد من المعلومات حول نظام التقسيم المستخدم في تخزين Azure، راجع تخزين Azure: خدمة تخزين سحابية عالية التوافر مع اتساق قوي.
الشبكات
قد يكون لقيود الشبكة الفعلية للتطبيق تأثير كبير على الأداء. توضح المقاطع التالية بعض القيود التي قد يواجهها المستخدمون.
إمكانيات شبكة العميل
يؤدي النطاق الترددي وجودة ارتباط الشبكة أدوارًا مهمة في أداء التطبيق، كما هو موضح في المقاطع التالية.
معدل النقل
فيما يتعلق بالنطاق الترددي، تكون المشكلة غالبًا إمكانيات العميل. تحتوي المثيلات الأكبر في Azure على NICs بسعة أكبر، لذا يجب عليك استخدام مثيل أكبر أو أكثر من جهاز ظاهري إذا كنت بحاجة إلى حدود أعلى للشبكة من جهاز واحد. إذا كنت تحاول الوصول إلى Azure Storage من تطبيق محلي، فيوصى بتطبيق نفس القاعدة: فهم إمكانيات شبكة الاتصال في جهاز العميل واتصال الشبكة بموقع Azure Storage وإما تحسينها حسب الحاجة أو تصميم التطبيق الخاص بك للعمل وفقًا لإمكانياتها.
جودة الارتباط
كما هو الحال مع أي استخدام للشبكة، تذكَّر أن ظروف الشبكة المتسببة في الأخطاء وفقدان الحزمة ستتسبب في بطء معدل النقل الفعال. قد يساعد استخدام WireShark أو NetMon على تشخيص هذه المشكلة.
الموقع
في أي بيئة موزعة، يحقق وضع العميل بالقرب من الخادم أفضل أداء. للوصول إلى Azure Storage في أقل زمن انتقال، يكون أفضل موقع للعميل في منطقة Azure ذاتها. على سبيل المثال، إذا كان لديك تطبيق ويب Azure يستخدم Azure Storage، فحدد موقعهما داخل منطقة واحدة، مثل غرب الولايات المتحدة أو جنوب شرقي آسيا. تقلل موارد تحديد الموقع المشترك من زمن الانتقال والتكلفة، حيث إن استخدام النطاق الترددي داخل منطقة واحدة مجاني.
إذا كانت تطبيقات العميل ستحاول الوصول إلى Azure Storage ولكن لم تتم استضافتها داخل Azure، مثل تطبيقات الأجهزة المحمولة أو على خدمات المؤسسة في أماكن العمل، فقد يقلل تحديد موقع حساب التخزين في منطقة قريبة من هؤلاء العملاء قد يقلل من زمن الانتقال. إذا كان العملاء موزعين بشكل عام (على سبيل المثال، بعضهم في أمريكا الشمالية، وبعضهم في أوروبا)، فحاول استخدام حساب تخزين واحد لكل منطقة. يتميز هذا النهج بسهولة تطبيقه إذا كانت البيانات التي يخزنها التطبيق خاصة بمستخدمين فرديين، ولا تتطلب نسخ البيانات نسخًا متماثلاً بين حسابات التخزين.
للتوزيع الواسع لمحتوى الكائنات الثنائية كبيرة الحجم، استخدم شبكة توصيل المحتوى مثل Azure CDN. لمزيد من المعلومات حول Azure CDN، راجع Azure CDN.
توقيعات الوصول المشتركة ومشاركة الموارد عبر المصادر
لنفترض أنك تحتاج إلى تخويل الرمز مثل JavaScript الذي يتم تشغيله في مستعرض ويب المستخدم أو في تطبيق الهاتف المحمول للوصول إلى البيانات في Azure Storage. أسلوب واحد هو إنشاء تطبيق خدمة يعمل وكيلاً. يقوم جهاز المستخدم بالمصادقة على الخدمة، والتي تأذن بدورها بالوصول إلى موارد Azure Storage. وبهذه الطريقة، يمكنك تجنب عرض مفاتيح حساب التخزين على أجهزة غير آمنة. ومع ذلك، يضع هذا الأسلوب حمل تخزين كبيرًا على تطبيق الخدمة، لأن كافة البيانات المنقولة بين جهاز المستخدم وAzure Storage يجب أن تمر عبر تطبيق الخدمة.
يمكنك تجنب استخدام تطبيق الخدمة كوكيل لـAzure Storage باستخدام توقيعات الوصول المشتركة (SAS). يمكنك باستخدام توقيعات الوصول المشتركة تمكين جهاز المستخدم لديك من تقديم طلبات مباشرة إلى Azure Storage باستخدام رمز مميز ومحدد للوصول. على سبيل المثال، إذا أراد مستخدم رفع صورة إلى التطبيق الخاص بك، فيمكن لتطبيق الخدمة إنشاء SAS وإرساله إلى جهاز المستخدم. يمكن للرمز المميز SAS منح إذن بالكتابة على مورد Azure Storage لفترة زمنية محددة، وبعد ذلك تنتهي صلاحية الرمز المميز SAS. للحصول على مزيد من المعلومات عن توقيعات الوصول المشترك، راجع منح الوصول المحدود إلى موارد Azure Storage باستخدام توقيعات الوصول المشتركة (SAS).
عادة، لن يسمح مستعرض ويب لـ JavaScript في صفحة يستضيفها موقع ويب على نطاق واحد بتنفيذ عمليات محددة، مثل عمليات الكتابة، على نطاق آخر. يُعرف هذا باسم سياسة المصدر ذاته، وتمنع هذه السياسة البرنامج النصي الضار الموجود على صفحة واحدة من الوصول إلى البيانات على صفحة ويب أخرى. ومع ذلك، يمكن أن تكون سياسة المصدر ذاته تقييدًا عند إنشاء حل في السحابة. مشاركة الموارد عبر المصادر (CORS) هي ميزة مستعرض تمكن المجال المستهدف من الاتصال بالمستعرض الذي تثق فيه الطلبات التي تنشأ في مجال المصدر.
على سبيل المثال، افترض أن تطبيق ويب قيد التشغيل في Azure يطلب مصدرًا لحساب في Azure Storage. تطبيق الويب هو مجال المصدر، وحساب التخزين هو مجال الهدف. يمكنك تكوين CORS لأي من خدمات Azure Storage للاتصال بمستعرض الويب الذي يطلب من مجال المصدر أنها موثوقة باستخدام Azure Storage. للحصول على مزيد من المعلومات عن مشاركة الموارد عبر المصادر CORS، راجع دعم مشاركة الموارد عبر المصادر (CORS) في Azure Storage.
يمكن أن تساعدك كل من توقيعات الوصول المشتركة ومشاركة الموارد عبر المصادر على تجنب التنزيل غير الضروري لتطبيق الويب الخاص بك.
تخزين مؤقت
يلعب التخزين المؤقت دورًا مهمًا في الأداء. تتناول الأقسام التالية أفضل ممارسات التخزين المؤقت.
قراءة البيانات
عامةً، يفضل قراءة البيانات مرة واحدة عن قراءتها مرتين. ضع في اعتبارك مثال تطبيق الويب الذي استرد كائنًا ثنائيًا كبير الحجم 50 ميغابايت من تخزين Azure ليكون بمثابة محتوى للمستخدم. من الناحية المثالية، يخفي التطبيق الكائن الثنائي كبير الحجم محليًا على القرص ثم يسترجع الإصدار المخبأ لطلبات المستخدم اللاحقة.
إحدى الطرق لتجنب استرداد كائن ثنائي كبير الحجم إذا لم يتم تعديلها منذ أن تم تخزينها مؤقتًا هي تأهيل عملية الحصول على عنوان مشروط لوقت التعديل. إذا كانت آخر مرة تم تعديلها بعد الوقت الذي تم فيه تخزين الكائن الثنائي كبير الحجم، فسيتم استرجاع الكائن الثنائي كبير الحجم وإعادة تخزينه. خلاف ذلك، يتم استرداد كائن ثنائي كبير الحجم المؤقت للحصول على الأداء الأمثل.
قد تقرر أيضًا تصميم طلبك لافتراض أن الكائن الثنائي كبير الحجم يظل دون تغيير لفترة قصيرة بعد استعادته. في هذه الحالة، لا يحتاج التطبيق إلى التحقق مما إذا كان قد تم تعديل الكائن الثنائي كبير الحجم خلال تلك الفترة.
تعد بيانات التكوين وبيانات البحث والبيانات الأخرى التي يستخدمها التطبيق بشكل متكرر مرشحات جيدة للتخزين المؤقت.
لمزيد من المعلومات حول استخدام العناوين الشرطية، راجع تحديد العناوين الشرطية لعمليات خدمة كائن ثنائي كبير الحجم .
تحميل البيانات في دفعات
في بعض السيناريوهات، يمكنك تجميع البيانات محليًا، ثم تحميلها بشكل دوري في دفعة بدلاً من تحميل كل قطعة من البيانات على الفور. على سبيل المثال، لنفترض أن تطبيق الويب يحتفظ بملف سجل للأنشطة. يمكن للتطبيق إما تحميل تفاصيل كل نشاط لأنه يحدث لجدول (والذي يتطلب العديد من عمليات التخزين)، أو يمكنه حفظ تفاصيل النشاط في ملف سجل محلي ثم تحميل جميع تفاصيل النشاط بشكل دوري كملف محدد إلى كائن ثنائي كبير الحجم. إذا كان حجم كل إدخال في السجل يساوي 1 كيلو بايت، فإنه يمكنك تحميل آلاف الإدخالات في معاملة واحدة. تدعم معاملة واحدة تحميل كائن ثنائي كبير الحجم يصل حجمه إلى 64 ميجا بايت. يجب على مطور التطبيق التصميم لاحتمال فشل جهاز العميل أو التحميل. إذا كانت بيانات النشاط بحاجة إلى تنزيل لفترة زمنية بدلاً من نشاط واحد، فمن المستحسن استخدام تخزين ثنائي كبير الحجم فوق تخزين الجدول.
تكوين .NET
في حال كنت تستخدم .NET Framework، يسرد هذا المقطع عدة إعدادات للتكوين السريع والتي يمكنك استخدامها لإجراء تحسينات كبيرة في الأداء. إذا كنت تستخدم لغات أخرى، فتحقق لمعرفة ما إذا كانت هناك مفاهيم مشابهة تطبق على اللغة المختارة لديك.
استخدام .NET Core
تطوير تطبيقات Azure Storage لديك مع .NET Core 2.1 أو الأحدث للاستفادة من تحسينات الأداء. يوصى باستخدام .NET Core 3.x عند الإمكان.
للحصول على مزيد من المعلومات عن تحسينات الأداء في .NET Core، راجع مشاركات المدونة التالية:
رفع حد الاتصال الافتراضي
في .NET، يزيد الرمز التالي من حد الاتصال الافتراضي (والذي يكون عادةً اثنين في بيئة العميل أو عشرة في بيئة الخادم) إلى 100. بشكل متطابق، يجب تعيين القيمة إلى عدد مؤشرات الترابط المستخدمة من قِبل التطبيق الخاص بك تقريبًا. عين حد الاتصال قبل فتح أي اتصالات.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
للاطلاع على لغات البرمجة الأخرى، راجع الوثائق لتحديد كيفية تعيين حد الاتصال.
للحصول على مزيد من المعلومات، راجع منشور المدونة Web Services: Concurrent Connections.
رفع الحد الأدنى لعدد مؤشرات الترابط
إذا كنت تستخدم استدعاءات متزامنة مع مهام غير متزامنة، قد تحتاج إلى زيادة عدد مؤشرات الترابط في تجمع مؤشر الترابط:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
للحصول على مزيد من المعلومات، راجع أسلوب ThreadPool.SetMinThreads.
التوازي غير المرتبط
في حين أن التوازي يمكن أن يكون فعالاً في الأداء، كن حذرًا عند استخدام التوازي غير المرتبط، وهذا يعني أنه لا يوجد حد ملزم لعدد مؤشرات الترابط أو الطلبات المتوازية. تأكد من تحديد الطلبات المتوازية لرفع البيانات أو تنزيلها، أو الوصول إلى أقسام متعددة في حساب التخزين ذاته، أو الوصول إلى عناصر متعددة في نفس القسم. إذا كان التوازي غير مرتبط، يمكن أن يتجاوز التطبيق لديك إمكانيات جهاز العميل أو أهداف قابلية التوسع لحساب التخزين، ما يتسبب في طول أزمنة الانتقال والتقييد.
مكتبات العميل وأدواته
للحصول على أفضل أداء، استخدم دائمًا أحدث مكتبات وأدوات العميل التي تقدمها Microsoft. مكتبات عميل Azure Storage متوفرة بلغات متنوعة. يدعم Azure Storage أيضًا PowerShell وAzure CLI. تهتم Microsoft بشكل نشط بتطوير مكتبات العميل وأدواته مع وضع الأداء في الاعتبار، وتواصل تحديثها بأحدث إصدارات الخدمة، وتضمن معالجتها للعديد من ممارسات الأداء المثبتة داخليًا.
تلميح
تم تصميم برنامج تشغيل ABFS للتغلب على أوجه القصور المتأصلة في WASB. توصي Microsoft باستخدام برنامج تشغيل ABFS عبر برنامج تشغيل WASB، حيث تم تحسين برنامج تشغيل ABFS خصيصًا لتحليلات البيانات الضخمة.
معالجة أخطاء الخدمة
يقوم Azure Storage بإرجاع خطأ عندما يتعذر على الخدمة معالجة طلب. يكون فهم الأخطاء التي قد يتم إرجاعها باستخدام Azure Storage في سيناريو محدد مفيدًا لتحسين الأداء.
أخطاء انتهاء المهلة والخادم مشغول
قد يتحكم Azure Storage في التطبيق الخاص بك إذا اقترب من حدود قابلية التوسع. قد لا يكون Azure Storage في بعض الحالات قادرًا على معالجة طلب بسبب بعض الحالات العابرة. قد ترجع الخدمة في كلتا الحالتين خطأ 503 (الخادم مشغول) أو خطأ 500 (انتهاء المُهلة). يمكن أن تحدث هذه الأخطاء أيضًا إذا كانت الخدمة تعيد توازن أقسام البيانات للسماح بمعدل نقل أعلى. يجب على تطبيق العميل عادةً إعادة محاولة العملية التي تسببت في أحد هذه الأخطاء. ومع ذلك، إذا كان Azure Storage يُقيد التطبيق لديك لأنه يتجاوز أهداف قابلية التوسع أو حتى إذا كانت الخدمة غير قادرة على خدمة الطلب لسبب آخر، قد تزيد إعادة المحاولات المقيدة المشكلة سوءًا. يوصى باستخدام سياسة إعادة محاولة التراجع الأسي ومكتبات العميل الافتراضي لهذا السلوك. على سبيل المثال، قد يعاود التطبيق الخاص بك المحاولة بعد ثانيتين ثم 4 ثوانٍ ثم 10 ثوانٍ ثم 30 ثانية ثم يتخلى تمامًا. وبهذه الطريقة، يقلل التطبيق الخاص بك تحميله على الخدمة بشكل ملحوظ، بدلاً من تفاقم السلوك الذي يمكن أن يتسبب في التقييد.
يمكن إعادة محاولة أخطاء في الاتصال فورًا، لأنها ليست نتيجة التقييد ومن المتوقع أن تكون عابرة.
أخطاء غير قابلة لإعادة المحاولة
تعالج مكتبات العميل إعادة المحاولات مع وعي بالأخطاء التي يمكن إعادة محاولتها والتي يتعذر محاولتها. ومع ذلك، إذا كنت تقوم بالاتصال بواجهة برمجة التطبيقات REST في Azure Storage مباشرة، هناك بعض الأخطاء التي لا يجب إعادة محاولتها. على سبيل المثال، يشير خطأ 400 (طلب غير صحيح) إلى أن تطبيق العميل أرسل طلبًا بتعذر معالجته لأنه لم يكن في النموذج المتوقع. تنتج إعادة إرسال هذا الطلب نفس الاستجابة في كل مرة، لذلك لا توجد نقطة لإعادة محاولة ذلك. إذا كنت تتصل بواجهة برمجة التطبيقات REST في Azure Storage مباشرة، يجب أن تكون على علم بالأخطاء المحتملة وما إذا كان يجب إعادة المحاولة.
للحصول على مزيد من المعلومات عن رموز الأخطاء في Azure Storage، راجع رموز الحالة والخطأ.
نسخ ونقل كائنات ثنائية كبيرة الحجم
يوفر تخزين Azure عددًا من الحلول لنسخ ونقل الكائنات الثنائية كبيرة الحجم داخل حساب التخزين، وبين حسابات التخزين، وبين الأنظمة المحلية والسحابة. يُبين هذا القسم بعض هذه الخيارات من حيث آثارها على الأداء. للحصول على معلومات حول نقل البيانات بكفاءة من أو إلى تخزين كائن ثنائي كبير الحجم، راجع اختيار حل Azure لنقل البيانات.
واجهات برمجة تطبيقات نسخ عنصر ثنائي كبير الحجم
لنسخ كائنات ثنائية كبيرة الحجم عبر حسابات التخزين، استخدم عملية وضع مكوِّن من عنوان URL. تقوم هذه العملية بنسخ البيانات بشكل متزامن من أي مصدر عنوان URL إلى كائن ثنائي كبير الحجم للكتلة. يمكن أن يؤدي استخدام Put Block from URL العملية إلى تقليل عرض النطاق الترددي المطلوب بشكل كبير عند ترحيل البيانات عبر حسابات التخزين. نظرًا إلى أن عملية النسخ تتم على جانب الخدمة، فلن تحتاج إلى تنزيل البيانات وإعادة تحميلها.
لنسخ البيانات داخل نفس حساب التخزين، استخدم عملية نسخ كائن ثنائي كبير الحجم. عادة ما يتم نسخ البيانات داخل حساب التخزين نفسه بسرعة.
استخدام AzCopy
تعد الأداة المساعدة AzCopy Command - line خيارًا بسيطًا وفعالاً لنقل الكائنات الثنائية كبيرة الحجم بكميات كبيرة إلى حسابات التخزين ومنها وعبرها. تم تحسين AzCopy لهذا السيناريو، ويمكن أن يحقق معدلات نقل عالية. يستخدم الإصدار 10 من AzCopy عملية Put Block From URL لنسخ البيانات عبر حسابات التخزين. لمزيد من المعلومات، راجع نسخ البيانات أو نقلها لتخزين Azure باستخدام AzCopy v 10.
استخدام صندوق بيانات Azure
لاستيراد كميات كبيرة من البيانات إلى تخزين كائن ثنائي كبير الحجم، ضع في اعتبارك استخدام فئة صندوق بيانات Azure للتحويلات دون اتصال بالإنترنت. تعد أجهزة صندوق البيانات التي توفرها Microsoft خيارًا جيدًا لنقل كميات كبيرة من البيانات إلى Azure عندما تكون محدودًا بالوقت أو توفر الشبكة أو التكاليف. لمزيد من المعلومات، راجع وثائق صندوق بيانات Azure.
توزيع المحتوى
في بعض الأحيان يحتاج التطبيق إلى تقديم نفس المحتوى للعديد من المستخدمين (على سبيل المثال، فيديو المنتج التجريبي المستخدم في الصفحة الرئيسية لموقع الويب)، الموجود إما في نفس المناطق أو في مناطق متعددة. في هذا السيناريو، استخدم شبكة توصيل المحتوى (CDN) مثل Azure CDN لتوزيع محتوى الكائن الثنائي كبير الحجم جغرافيًا. على عكس حساب تخزين Azure الموجود في منطقة واحدة والذي لا يمكنه تقديم محتوى مع زمن وصول منخفض إلى مناطق أخرى، تستخدم Azure CDN خوادم في مراكز بيانات متعددة حول العالم. بالإضافة إلى ذلك، يمكن أن تدعم CDN بشكل نمطي حدود خروج أعلى بكثير من حساب تخزين واحد.
لمزيد من المعلومات حول Azure CDN، راجع Azure CDN.
استخدام بيانات التعريف
تدعم خدمة كائن ثنائي كبير الحجم طلبات HEAD، والتي يمكن أن تشمل خصائص كائن ثنائي كبير الحجم أو بيانات التعريف. على سبيل المثال، إذا كان طلبك يحتاج إلى بيانات Exif (تنسيق الصورة القابلة للتبديل) من الصورة، فإنه يمكنه استرداد الصورة واستخراجها. لتوفير عرض النطاق الترددي وتحسين الأداء، يمكن للتطبيق تخزين بيانات Exif في بيانات تعريف كائن ثنائي كبير الحجم عند تحميل التطبيق للصورة. يمكنك بعد ذلك استرداد بيانات EXIF في بيانات التعريف باستخدام طلب HEAD فقط. إن استرداد بيانات التعريف فقط وليس المحتويات الكاملة للقطعة يوفر عرض النطاق الترددي الكبير ويقلل من وقت المعالجة المطلوب لاستخراج بيانات Exif. ضع في اعتبارك أنه يمكن تخزين 8 كيلو بايت من بيانات التعريف لكل كائن ثنائي كبير الحجم.
تحميل الكائنات الثنائية كبيرة الحجم بسرعة
لتحميل الكائنات الثنائية كبيرة الحجم بسرعة، حدد أولاً ما إذا كنت سترفع نقطة واحدة أو أكثر. استخدم الإرشادات أدناه لتحديد الطريقة الصحيحة لاستخدامها اعتمادًا على السيناريو خاصتك.
تحميل كائن ثنائي كبير الحجم كبير بسرعة
لتحميل كائن ثنائي كبير الحجم واحد كبير بسرعة، يمكن لتطبيق العميل تحميل كتله أو صفحاته بالتوازي، مع مراعاة أهداف قابلية التوسع لكل كائن ثنائي كبير الحجم وحساب التخزين ككل. تدعم مكتبات عملاء تخزين Azure التحميل على التوازي. على سبيل المثال، يمكنك استخدام الخصائص التالية لتحديد عدد الطلبات المتزامنة المسموح بها في .NET أو Java. توفر مكتبات العملاء للغات الأخرى المدعومة خيارات مماثلة.
- بالنسبة إلى .NET، عيّن BlobRequestOptions.ParparallelOperationThreadCount الخاصية.
- بالنسبة إلى Java/Android، اتصل بطريقة BlobRequestOptions.setConcurrentRequestCount (final Integer synurrentRequestCount).
تحميل العديد من الكائنات الثنائية كبيرة الحجم بسرعة
لتحميل العديد من الكائنات الثنائية كبيرة الحجم بسرعة، قم بتحميل الكائنات الثنائية كبيرة الحجم بالتوازي. التحميل بالتوازي أسرع من تحميل كائن ثنائي كبير الحجم في وقت واحد مع تحميلات كتلة متوازية لأنه ينشر التحميل عبر أقسام متعددة من خدمة التخزين. يقوم AzCopy بإجراء التحميلات بشكل متوازٍ افتراضيًا، ويوصى به لهذا السيناريو. لمزيد من المعلومات ، راجع البدء معAzCopy .
اختر النوع الصحيح من الكائن الثنائي كبير الحجم
يدعم تخزين كائنات ثنائية كبيرة الحجم للكتلة، وكائنات ثنائية كبيرة الحجم للإلحاق، وكائنات ثنائية كبيرة الحجم للصفحة. بالنسبة إلى سيناريو استخدام معين، سيؤثر اختيارك لنوع الكائن الثنائي كبير الحجم على أداء الحل وقابليته للتطوير.
تعد الكائنات الثنائية كبيرة الحجم للكتلة مناسبة عندما تريد تحميل كميات كبيرة من البيانات بكفاءة. على سبيل المثال، سيستهدف تطبيق العميل الذي يقوم بتحميل صور أو مقاطع فيديو إلى تخزين كائنات ثنائية كبيرة الحجم للكتلة.
تشبه الكائنات الثنائية الكبيرة الحجم الملحقة الكائنات الثنائية كبيرة الحجم للكتلة من حيث إنها تتكون من كتل. عند تعديل كائن ثنائي كبير الحجم ملحق، تتم إضافة الكتل إلى نهاية الكائن الثنائي كبير الحجم فقط. إلحاق كائنات ثنائية كبيرة الحجم مفيدة لسيناريوهات مثل تسجيل الأداء، عندما يحتاج التطبيق إلى إضافة بيانات إلى كائن ثنائي كبير الحجم موجود.
نقط الصفحة مناسبة إذا كان التطبيق يحتاج إلى أداء كتابات عشوائية على البيانات. على سبيل المثال، يتم تخزين أقراص الماكينة الظاهرية Azure ككائنات ثنائية كبيرة الحجم للصفحة. لمزيد من المعلومات، راجع فهم كائنات ثنائية كبيرة الحجم للكتلة، وإلحاق كائنات ثنائية كبيرة الحجم، وكائنات ثنائية كبيرة الحجم للصفحة.