قائمة اختيار الأداء وقابلية التوسع لمخزن Table
طورت Microsoft العديد من الممارسات المثبتة لتطوير تطبيقات عالية الأداء مع تخزين Table. تحدد قائمة التحقق هذه الممارسات الرئيسية التي يمكن للمطورين اتباعها لتحسين الأداء. ضع هذه الممارسات في الاعتبار أثناء تصميم التطبيق الخاص بك وطوال العملية.
يحتوي Azure Storage على أهداف قابلية التوسع والأداء للسعة ومعدل الحركة والنطاق الترددي. للحصول على مزيد من المعلومات حول أهداف قابلية التوسع في Azure Storage، راجع أهداف قابلية التوسع والأداء لحسابات التخزين القياسية وأهداف قابلية التوسع والأداء لمخزن Table.
قائمة الاختيار
تنظم هذه المقالة الممارسات المثبتة للأداء في قائمة اختيار يمكنك اتباعها أثناء تطوير تطبيق مخزن Table.
أهداف قابلية التوسع
إذا اقترب تطبيقك من أي من أهداف قابلية التوسع أو تجاوزها، فقد يواجه زيادة في زمن انتقال المعاملات أو تقييدها. عندما يقوم Azure Storage بتقييد التطبيق لديك، تبدأ الخدمة بإرجاع رموز الخطأ 503 (الخادم مشغول) أو خطأ 500 (انتهاء مهلة العملية). يمثل تجنب هذه الأخطاء بالتواجد ضمن حدود أهداف قابلية التوسع جزءًا مهمًا من تحسين أداء التطبيق لديك.
للحصول على مزيد من المعلومات عن أهداف قابلية التوسع لخدمة Table، راجع أهداف قابلية التوسع والأداء لمخزن Table.
أقصى عدد لحسابات التخزين
إذا كنت تقترب من أقصى عدد لحسابات التخزين المسموح بها لاشتراك محدد/مجموعة مناطق، هل تستخدم حسابات تخزين متعددة على علبة بريد مقطعية لزيادة الدخول أو الخروج أو عمليات الإدخال/الإخراج في الثانية (IOPS) أو السعة؟ في هذا السيناريو، توصي Microsoft بالاستفادة من زيادة حدود حسابات التخزين لتقليل عدد حسابات التخزين اللازمة لحمل العمل الخاص بك إذا أمكن. اتصل ِAzure Support لطلب زيادة حدود حساب التخزين لديك.
أهداف السعة والحركة
في حال كان التطبيق لديك يقترب من أهداف قابلية التوسع لحساب تخزين واحد، فحاول استخدام أحد النهج التالية:
- قم بإعادة النظر في حجم العمل الذي يتسبب في اقتراب تطبيقك من هدف قابلية التوسع أو تجاوزه. هل يمكنك تصميمه بشكل مختلف لتقليل استخدام النطاق الترددي أو السعة، أو حركات أقل؟
- في حال كان يجب أن يتجاوز التطبيق الخاص بك أحد أهداف قابلية التوسع، فيُرجى إنشاء حسابات تخزين متعددة وتقسيم بيانات التطبيق لديك عبر حسابات التخزين المتعددة هذه. في حال كنت تستخدم هذا النمط، فتأكد من تصميم التطبيق الخاص بك حيث يمكنك إضافة المزيد من حسابات التخزين في المستقبل لموازنة التحميل. ليس لحسابات التخزين نفسها أي تكلفة غير استخدامك فيما يتعلق بالبيانات المخزنة أو الحركات المنفذة أو البيانات المنقولة.
- في حال كان التطبيق يقترب من أهداف النطاق الترددي، فحاول ضغط البيانات من جانب العميل لتقليل النطاق الترددي اللازم لإرسال البيانات إلى Azure Storage. بينما قد يؤدي ضغط البيانات إلى حفظ النطاق الترددي وتحسين أداء الشبكة، يمكن أن يكون له أيضا تأثيرات سلبية على الأداء. قيم تأثير أداء متطلبات المعالجة الإضافية لضغط البيانات وفك الضغط من جانب العميل. تذكَّر أن تخزين البيانات المضغوطة يمكن أن يجعل استكشاف الأخطاء وإصلاحها أكثر صعوبة لأنه قد يكون من الصعب عرض البيانات باستخدام أدوات قياسية.
- إذا كان التطبيق الخاص بك يقترب من أهداف قابلية التوسع، يُرجى التأكد من استخدام التراجع الأسي لإعادة المحاولات. من الأفضل محاولة تجنب الوصول إلى أهداف قابلية التوسع بتنفيذ التوصيات الموضحة في هذه المقالة. ومع ذلك، فإن استخدام التراجع الأسي لعمليات إعادة المحاولة سيمنع تطبيقك من إعادة المحاولة بسرعة، مما قد يجعل الاختناق أسوأ. للحصول على مزيد من المعلومات، راجع المقطع بعنوان أخطاء انتهاء المهلة والخادم مشغول.
أهداف لعمليات البيانات
يوازن تحميل Azure Storage مع زيادة نسبة استخدام الشبكة إلى حساب التخزين الخاص بك، ولكن إذا أظهرت نسبة استخدام الشبكة اندفاعات مفاجئة، فقد لا تتمكن من الحصول على هذا الحجم من معدل النقل على الفور. توقع أن تتعرض للتحكم و/أو المهلات أثناء الاندفاع حيث يقوم Azure Storage بموازنة تحميل الجدول تلقائيًا. تحقق الزيادة ببطء نتائج أفضل بشكل عام، حيث يكون للنظام الوقت لتحميل التوازن بشكل مناسب.
الكيانات لكل ثانية (حساب التخزين)
يصل حد قابلية التوسع للوصول إلى الجداول إلى 20,000 كيان (1 كيلوبايت لكل منهما) في الثانية لكل حساب. بشكل عام، يتم حساب كل كيان يتم إدراجه أو تحديثه أو حذفه أو مسحه ضوئيًا في هذا الهدف. لذا فإن إدراج دفعة تحتوي على 100 كيان سيتم حسابها 100 كيان. استعلام يقوم بمسح 1000 كيان وإرجاع 5 كيانات سيتم احتسابه 1000 كيان.
الكيانات في الثانية (قسم)
يكون هدف قابلية التوسع للوصول إلى الجداول في قسم واحد هو 2,000 كيان (1 كيلوبايت لكل منها) في الثانية باستخدام العد ذاته كما هو موضح في الجزء السابق.
الشبكات
قد يكون لقيود الشبكة الفعلية للتطبيق تأثير كبير على الأداء. تصف الأقسام التالية بعض القيود التي قد يواجهها المستخدمون.
إمكانيات شبكة العميل
يؤدي النطاق الترددي وجودة ارتباط الشبكة أدوارًا مهمة في أداء التطبيق، كما هو موضح في المقاطع التالية.
الإنتاجية
فيما يتعلق بالنطاق الترددي، تكون المشكلة غالبًا إمكانيات العميل. تحتوي مثيلات Microsoft Azure الأكبر على بطاقات NIC ذات سعة أكبر، لذا يجب أن تفكر في استخدام مثيل أكبر أو عدد أكبر من الأجهزة الظاهرية إذا كنت بحاجة إلى حدود شبكة أعلى من جهاز واحد. إذا كنت تصل إلى Azure Storage من تطبيق محلي، فإن نفس القاعدة تنطبق: فهم قدرات الشبكة لجهاز العميل واتصال الشبكة بموقع Azure Storage وإما تحسينها حسب الحاجة أو تصميم التطبيق الخاص بك للعمل ضمن قدراتها.
جودة الارتباط
كما هو الحال مع أي استخدام للشبكة، ضع في اعتبارك أن ظروف الشبكة التي تؤدي إلى أخطاء وفقدان الحزمة تبطئ معدل النقل الفعال. قد يساعد استخدام WireShark أو NetMon على تشخيص هذه المشكلة.
Location
في أي بيئة موزعة، يحقق وضع العميل بالقرب من الخادم أفضل أداء. للوصول إلى Azure Storage في أقل زمن انتقال، يكون أفضل موقع للعميل في منطقة Azure ذاتها. على سبيل المثال، إذا كان لديك تطبيق ويب Azure يستخدم Azure Storage، فحدد موقعهما داخل منطقة واحدة، مثل غرب الولايات المتحدة أو جنوب شرقي آسيا. تقلل موارد تحديد الموقع المشترك من زمن الانتقال والتكلفة، حيث إن استخدام النطاق الترددي داخل منطقة واحدة مجاني.
إذا كانت تطبيقات العميل ستدخل إلى Azure Storage ولكن لم تتم استضافتها داخل Azure، مثل تطبيقات الأجهزة المحمولة أو خدمات المؤسسة المحلية، فإن تحديد موقع حساب التخزين في منطقة قريبة من هؤلاء العملاء قد يقلل من زمن الانتقال. إذا كان العملاء موزعين بشكل عام (على سبيل المثال، بعضهم في أمريكا الشمالية، وبعضهم في أوروبا)، فحاول استخدام حساب تخزين واحد لكل منطقة. يكون تنفيذ هذا الأسلوب أسهل إذا كانت البيانات التي يخزنها التطبيق خاصة بالمستخدمين الفرديين، ولا تتطلب نسخ البيانات نسخا متماثلا بين حسابات التخزين.
توقيعات الوصول المشتركة ومشاركة الموارد عبر المصادر
افترض أنك بحاجة إلى تخويل تعليمات برمجية مثل JavaScript قيد التشغيل في مستعرض الويب الخاص بالمستخدم أو في تطبيق الهاتف المحمول للوصول إلى البيانات في Microsoft Azure Storage. يتمثل أحد الأساليب في بناء تطبيق خدمة يعمل كوكيل. يقوم جهاز المستخدم بالمصادقة على الخدمة، والتي تأذن بدورها بالوصول إلى موارد Azure Storage. بهذه الطريقة، يمكنك تجنب تعريض مفاتيح حساب التخزين على الأجهزة غير الآمنة. ومع ذلك، يضع هذا الأسلوب حمل تخزين كبيرًا على تطبيق الخدمة، لأن كافة البيانات المنقولة بين جهاز المستخدم وAzure Storage يجب أن تمر عبر تطبيق الخدمة.
يمكنك تجنب استخدام تطبيق الخدمة كوكيل لـAzure Storage باستخدام توقيعات الوصول المشتركة (SAS). باستخدام SAS، يمكنك تمكين جهاز المستخدم الخاص بك لتقديم طلبات مباشرة إلى Microsoft Azure Storage باستخدام رمز وصول محدود. على سبيل المثال، إذا أراد المستخدم تحميل صورة إلى التطبيق الخاص بك، فيمكن لتطبيق الخدمة الخاص بك إنشاء SAS وإرساله إلى جهاز المستخدم. يمكن أن يمنح رمز SAS الإذن بالكتابة إلى مورد Microsoft Azure Storage لفترة زمنية محددة، تنتهي بعدها صلاحية رمز SAS المميز. لمزيد من المعلومات حول SAS، يُرجى الرجوع إلى الوصول المحدود إلىAzure Storage resources باستخدام رموز (SAS).
عادة، لن يسمح مستعرض ويب ل JavaScript في صفحة يستضيفها موقع ويب على مجال واحد بتنفيذ عمليات معينة، مثل عمليات الكتابة، إلى مجال آخر. يُعرف هذا باسم سياسة المصدر ذاته، وتمنع هذه السياسة البرنامج النصي الضار الموجود على صفحة واحدة من الوصول إلى البيانات على صفحة ويب أخرى. ومع ذلك، يمكن أن تكون سياسة المصدر ذاته تقييدًا عند إنشاء حل في السحابة. مشاركة الموارد عبر المصادر (CORS) هي ميزة مستعرض تمكن المجال المستهدف من الاتصال بالمستعرض الذي تثق فيه الطلبات التي تنشأ في مجال المصدر.
على سبيل المثال، افترض أن تطبيق ويب قيد التشغيل في Azure يطلب مصدرًا لحساب في Azure Storage. تطبيق الويب هو مجال المصدر، وحساب التخزين هو مجال الهدف. يمكنك تكوين CORS لأي من خدمات Azure Storage للاتصال بمستعرض الويب الذي يطلب من مجال المصدر أنها موثوقة باستخدام Azure Storage. للحصول على مزيد من المعلومات عن مشاركة الموارد عبر المصادر CORS، راجع دعم مشاركة الموارد عبر المصادر (CORS) في Azure Storage.
يمكن أن يساعدك كل من SAS وCORS في تجنب التحميل غير الضروري على تطبيق الويب الخاص بك.
حركات الدُفعة
تدعم خدمة Table حركات الدُفعة في الكيانات الموجودة في نفس الجدول والتي تنتمي إلى مجموعة الأقسام ذاتها. للحصول على مزيد من المعلومات، راجع تنفيذ حركات مجموعة الكيانات.
تكوين NET
بالنسبة للمشاريع التي تستخدم .NET Framework، يسرد هذا القسم بعض إعدادات التكوين السريعة التي يمكنك استخدامها لإجراء تحسينات كبيرة على الأداء. إذا كنت تستخدم لغة أخرى غير .NET، فتحقق لمعرفة ما إذا كانت المفاهيم المماثلة تنطبق على اللغة التي اخترتها.
رفع حد الاتصال الافتراضي
إشعار
ينطبق هذا القسم على المشاريع التي تستخدم .NET Framework، حيث يتم التحكم في تجميع الاتصال بواسطة فئة ServicePointManager. أدخل .NET Core تغييرا كبيرا حول إدارة تجمع الاتصال، حيث يحدث تجميع الاتصال على مستوى HttpClient ولا يقتصر حجم التجمع بشكل افتراضي. وهذا يعني أن اتصالات HTTP يتم قياسها تلقائيا لتلبية حمل العمل الخاص بك. يوصى باستخدام أحدث إصدار من .NET، عندما يكون ذلك ممكنا، للاستفادة من تحسينات الأداء.
بالنسبة للمشاريع التي تستخدم .NET Framework، يمكنك استخدام التعليمات البرمجية التالية لزيادة حد الاتصال الافتراضي (وهو عادة 2 في بيئة عميل أو 10 في بيئة خادم) إلى 100. بشكل متطابق، يجب تعيين القيمة إلى عدد مؤشرات الترابط المستخدمة من قِبل التطبيق الخاص بك تقريبًا. عين حد الاتصال قبل فتح أي اتصالات.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
لمعرفة المزيد حول حدود تجمع الاتصال في .NET Framework، راجع حدود تجمع .NET Framework الاتصال ion وAzure SDK الجديد ل .NET.
للاطلاع على لغات البرمجة الأخرى، راجع الوثائق لتحديد كيفية تعيين حد الاتصال.
رفع الحد الأدنى لعدد مؤشرات الترابط
إذا كنت تستخدم استدعاءات متزامنة مع مهام غير متزامنة، فقد تحتاج إلى زيادة عدد مؤشرات الترابط في تجمع مؤشر الترابط:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
للحصول على مزيد من المعلومات، راجع أسلوب ThreadPool.SetMinThreads.
التوازي غير المحدود
في حين أن التوازي يمكن أن يكون رائعا للأداء، كن حذرا بشأن استخدام التوازي غير المرتبط، ما يعني أنه لا يوجد حد مفروضة على عدد مؤشرات الترابط أو الطلبات المتوازية. تأكد من تحديد الطلبات المتوازية لرفع البيانات أو تنزيلها، أو الوصول إلى أقسام متعددة في حساب التخزين ذاته، أو الوصول إلى عناصر متعددة في نفس القسم. إذا كان التوازي غير مرتبط، يمكن أن يتجاوز التطبيق لديك إمكانيات جهاز العميل أو أهداف قابلية التوسع لحساب التخزين، ما يتسبب في طول أزمنة الانتقال والتقييد.
مكتبات وأدوات العميل
للحصول على أفضل أداء، استخدم دائمًا أحدث مكتبات وأدوات العميل التي تقدمها Microsoft. تتوفر مكتبات عميل Azure Storage بلغات مختلفة. يدعم Azure Storage أيضًا PowerShell وAzure CLI. تهتم Microsoft بشكل نشط بتطوير مكتبات العميل وأدواته مع وضع الأداء في الاعتبار، وتواصل تحديثها بأحدث إصدارات الخدمة، وتضمن معالجتها للعديد من ممارسات الأداء المثبتة داخليًا.
تعامل مع أخطاء الخدمة
يقوم Azure Storage بإرجاع خطأ عندما لا تتمكن الخدمة من معالجة طلب. يعد فهم الأخطاء التي تم إرجاعها بواسطة Azure Storage في سيناريو معين مفيدا لتحسين الأداء.
أخطاء انتهاء المهلة والخادم مشغول
قد يقيد Azure Storage تطبيقك إذا اقترب من حدود قابلية التوسع. في بعض الحالات، قد يكون Azure Storage غير قادر على معالجة طلب بسبب بعض الحالات العابرة. في كلتا الحالتين، قد ترجع الخدمة خطأ 503 (Server Busy) أو 500 (المهلة). يمكن أن تحدث هذه الأخطاء أيضاً إذا كانت الخدمة تعيد موازنة أقسام البيانات للسماح بمعدل النقل. يجب على تطبيق العميل عادةً إعادة محاولة العملية التي تسببت في أحد هذه الأخطاء. ومع ذلك، إذا كان Azure Storage يخنق تطبيقك لأنه يتجاوز أهداف قابلية التوسع، أو حتى إذا كانت الخدمة غير قادرة على خدمة الطلب لسبب آخر، فقد تؤدي عمليات إعادة المحاولة العدوانية إلى تفاقم المشكلة. يوصى باستخدام سياسة إعادة محاولة التراجع الأسي ومكتبات العميل الافتراضي لهذا السلوك. على سبيل المثال، قد يعيد التطبيق الخاص بك المحاولة بعد ثانيتين، ثم 4 ثوان، ثم 10 ثوان، ثم 30 ثانية، ثم يستسلم تماما. وبهذه الطريقة، يقلل التطبيق الخاص بك تحميله على الخدمة بشكل ملحوظ، بدلاً من تفاقم السلوك الذي يمكن أن يتسبب في التقييد.
يمكن إعادة محاولة أخطاء الاتصال ivity على الفور، لأنها ليست نتيجة للتقييد ومن المتوقع أن تكون عابرة.
أخطاء غير قابلة لإعادة المحاولة
تعالج مكتبات العميل عمليات إعادة المحاولة مع الوعي بالأخطاء التي يمكن إعادة محاولة تنفيذها والتي لا يمكن. ومع ذلك، إذا كنت تتصل بواجهة برمجة تطبيقات AZURE Storage REST مباشرة، فهناك بعض الأخطاء التي يجب عدم إعادة المحاولة. على سبيل المثال، يشير الخطأ 400 (طلب غير صحيح) إلى أن تطبيق العميل أرسل طلبا تعذرت معالجته لأنه لم يكن في النموذج المتوقع. تؤدي إعادة إرسال هذا الطلب إلى نفس الاستجابة في كل مرة، لذلك لا جدوى من إعادة المحاولة. إذا كنت تتصل بواجهة برمجة تطبيقات Azure Storage REST مباشرة، فكن على دراية بالأخطاء المحتملة وما إذا كان يجب إعادة المحاولة.
لمزيد من المعلومات حول رموز خطأ تخزين Microsoft Azure، راجع رموز الحالة والأخطاء.
التكوين
يسرد هذا القسم عدة إعدادات التكوين السريع التي يمكنك استخدامها لإجراء تحسينات أداء هامة في خدمة Table:
استخدام JSON
بدءًا من إصدار خدمة التخزين في 2013-08-15، تدعم خدمة Table استخدام JSON بدلاً من تنسيق AtomPub المستند إلى XML لنقل بيانات الجدول. يمكن أن يقلل استخدام JSON من أحجام الحمولة بنسبة تصل إلى 75٪ ويمكن أن يحسن أداء التطبيق لديك بشكل كبير.
للحصول على مزيد من المعلومات، راجع منشور Microsoft Azure Tables: Introducing JSONوPayload Format for Table Service Operations.
تعطيل Nagle
يتم تنفيذ خوارزمية Nagle على نطاق واسع عبر شبكات TCP / IP كوسيلة لتحسين أداء الشبكة. ومع ذلك، فإنه ليس الأمثل في جميع الظروف (مثل البيئات التفاعلية للغاية). خوارزمية Nagle لها تأثير سلبي على أداء الطلبات في خدمة Azure Table، ويجب تعطيلها إذا كان ذلك ممكنًا.
مخطط
تكون كيفية تمثيل بياناتك الخاصة والاستفسار عنها أكبر عامل فردي يؤثر على أداء خدمة Table. في حين أن كل تطبيق مختلف، فيحدد هذا القسم بعض الممارسات العامة المثبتة التي تتعلق بما يلي:
- تصميم الجدول
- استعلامات الكفاءة
- تحديثات البيانات الفعالة
الجداول والأقسام
تنقسم الجداول إلى أقسام. يشارك كل كيان مخزن في قسم مفتاح القسم ذاته ويحتفظ بمفتاح صف مميز للتعرف عليه داخل هذا القسم. توفر الأقسام مزايا لكنها تقدم أيضًا حدود قابلية التوسع.
- المزايا: يمكنك تحديث الكيانات في نفس القسم في حركة دفعية واحدة وصغيرة تحتوي على ما يصل إلى 100 عملية تخزين منفصلة (الحد الأقصى لإجمالي الحجم 4 ميغابايت). بافتراض نفس عدد الكيانات المراد استردادها، يمكنك أيضًا الاستعلام عن البيانات في قسم واحد بشكل أكثر كفاءة من البيانات الممتدة عبر الأقسام (لذا واصل القراءة للحصول على مزيد من التوصيات عن الاستعلام عن بيانات الجدول).
- حد قابلية التوسع: لا يمكن موازنة التحميل للوصول إلى الكيانات المخزنة في قسم واحد لأن الأقسام تدعم معاملات الدفعة الذرية. لهذا السبب، يكون هدف قابلية التوسع لقسم جدول فردي أقل من خدمة Table ككل.
وبسبب خصائص الجداول والأقسام، يجب تبني مبادئ التصميم التالية:
- حدد موقع البيانات التي يقوم تطبيق العميل لديك بتحديثها أو الاستعلام عنها بشكل متكرر في نفس الوحدة المنطقية للعمل داخل نفس القسم. على سبيل المثال، حدد موقع البيانات في نفس القسم إذا كان التطبيق الخاص بك يقوم بتجميع عمليات الكتابة أو كنت تقوم بعمليات الدفعة الذرية. أيضًا، يمكن الاستعلام عن البيانات الموجودة في قسم واحد بشكل أكثر كفاءة في استعلام واحد من البيانات الممتدة عبر الأقسام.
- حدد موقع البيانات التي لا يقوم تطبيق العميل بإدراجها أو تحديثها أو الاستعلام فيها في نفس وحدة العمل المنطقية (أي في استعلام واحد أو تحديث دفعي) في أقسام منفصلة. ضع في اعتبارك أنه لا يوجد حد لعدد مفاتيح الأقسام في جدول واحد، لذا فإن وجود ملايين مفاتيح الأقسام ليس مشكلة ولن يؤثر على الأداء. على سبيل المثال، إذا كان تطبيقك موقعا شائعا مع تسجيل دخول المستخدم، فقد يكون استخدام معرف المستخدم كمفتاح القسم خيارا جيدا.
الأقسام الساخنة
القسم الساخن هو القسم الذي يتلقى نسبة مئوية غير متناسبة من نسبة استخدام الشبكة إلى حساب، ولا يمكن موازنة التحميل لأنه قسم واحد. بشكل عام، يتم إنشاء الأقسام الساخنة بإحدى طريقتين:
أنماط الإلحاق فقط والإرفاق فقط
نمط "الإلحاق فقط" هو نمط واحد حيث تزيد وتقل كل (أو تقريبًا كل) حركة المرور إلى مفتاح قسم معين وفقًا للوقت الحالي. على سبيل المثال، افترض أن التطبيق لديك يستخدم التاريخ الحالي كمفتاح قسم لبيانات السجل. ينتج عن هذا التصميم جميع الإدراجات التي تنتقل إلى القسم الأخير في الجدول الخاص بك، ولا يمكن للنظام تحميل التوازن بشكل صحيح. إذا تجاوز حجم حركة المرور إلى هذا القسم هدف قابلية التوسع على مستوى القسم، فإنه يؤدي إلى التقييد. من الأفضل التأكد من إرسال حركة المرور إلى أقسام متعددة، لتمكين توازن تحميل الطلبات عبر الجدول.
بيانات المرور العالي
إذا أدى نظام التقسيم إلى قسم واحد يحتوي فقط على بيانات أكثر استخداما بكثير من الأقسام الأخرى، فقد ترى أيضا التقييد بينما يقترب هذا القسم من هدف قابلية التوسع لقسم واحد. من الأفضل التأكد من أن مخطط التقسيم لن ينتج عنه قسم واحد يقترب من أهداف قابلية التوسع.
الاستعلام
يوضح هذا المقطع الممارسات المثبتة للاستعلام عن خدمة Table.
نطاق الاستعلام
توجد عدة طرق لتحديد نطاق الكيانات للاستعلام. توضح القائمة التالية كل خيار لنطاق الاستعلام.
- استعلامات النقطة:- يتولى استعلام النقطة استرداد كيان واحد تمامًا بتحديد مفتاح القسم ومفتاح الصف للكيان المراد استرداده. تتميز هذه الاستعلامات بالكفاءة، ويجب استخدامها كلما أمكن ذلك.
- استعلامات القسم: استعلام القسم هو استعلام يتولى استرداد مجموعة من البيانات التي تشترك في مفتاح قسم مشترك. بشكل عام، يحدد الاستعلام نطاق قيم مفتاح الصف أو نطاق قيم بعض خصائص الكيان بالإضافة إلى مفتاح قسم. تكون هذه الاستعلامات أقل كفاءة من استعلامات النقطة، ويجب استخدامها بشكل مقتصد.
- استعلامات الجدول: استعلام الجدول هو استعلام يسترد مجموعة من الكيانات التي لا تشترك في مفتاح قسم مشترك. هذه الاستعلامات ليست فعالة ويجب تجنبها إذا كان ذلك ممكنا.
بشكل عام، تجنب عمليات المسح الضوئي (الاستعلامات أكبر من كيان واحد)، ولكن إذا كان يجب عليك إجراء المسح الضوئي، فحاول تنظيم بياناتك حيث تباشر عمليات المسح استعادة البيانات التي تحتاج إليها دون مسح أو إرجاع كميات كبيرة من الكيانات التي لا تحتاج إليها.
كثافة الاستعلام
عامل رئيسي آخر في كفاءة الاستعلام هو عدد الكيانات المرتجعة مقارنة بعدد الكيانات التي تم مسحها ضوئيًا للعثور على المجموعة المرتجعة. إذا كان التطبيق الخاص بك ينفذ استعلام جدول مع عامل تصفية لقيمة خاصية 1٪ فقط من مشاركات البيانات، يقوم الاستعلام بفحص 100 كيان لكل كيان يقوم بإرجاعه. ترتبط أهداف قابلية توسع الجدول التي تمت مناقشتها سابقا بعدد الكيانات التي تم مسحها ضوئيا، وليس عدد الكيانات التي تم إرجاعها: يمكن أن تتسبب كثافة الاستعلام المنخفضة بسهولة في تقييد خدمة الجدول للتطبيق الخاص بك لأنه يجب عليها مسح العديد من الكيانات ضوئيا لاسترداد الكيان الذي تبحث عنه. للحصول على مزيد من المعلومات عن كيفية تجنب التقييد، راجع المقطع بعنوان Denormalization.
الحد من كمية البيانات المرتجعة
عندما تعرف أن استعلام يرجع كيانات لا تحتاجها في تطبيق العميل، فكر في استخدام عامل تصفية لتقليل حجم المجموعة التي تم إرجاعها. بينما لا تزال الكيانات التي لم يتم إرجاعها إلى العميل تحسب في حدود قابلية التوسع، يتحسن أداء التطبيق الخاص بك بسبب انخفاض حجم حمولة الشبكة وتقليل عدد الكيانات التي يجب أن يعالجها تطبيق العميل الخاص بك. ضع في اعتبارك أن أهداف قابلية التوسع تتعلق بعدد الكيانات التي تم مسحها ضوئيا، لذلك قد يؤدي الاستعلام الذي يقوم بتصفية العديد من الكيانات إلى التقييد، حتى إذا تم إرجاع عدد قليل من الكيانات. للحصول على مزيد من المعلومات عن جعل الاستعلامات فعالة، راجع المقطع المعنون كثافة الاستعلام.
في حال كان تطبيق العميل بحاجة فقط إلى مجموعة خصائص محدودة من الكيانات الموجودة في الجدول، يمكنك استخدام الإسقاط لتحديد حجم مجموعة البيانات المرتجعة. كما هو الحال مع التصفية، يساعد الإسقاط على تقليل تحميل الشبكة ومعالجة العميل.
نشر التكرار
على عكس العمل مع قواعد بيانات ارتباطية، تؤدي الممارسات المثبتة للاستعلام عن بيانات الجدول بكفاءة إلى نشر تكرار لبياناتك. أي تكرار نفس البيانات في كيانات متعددة (واحد لكل مفتاح قد تستخدمه للعثور على البيانات) لتقليل عدد الكيانات التي يجب أن يقوم الاستعلام بفحصها للعثور على البيانات التي يحتاجها العميل، بدلا من الاضطرار إلى مسح أعداد كبيرة من الكيانات للعثور على البيانات التي يحتاجها التطبيق الخاص بك. على سبيل المثال، في موقع التجارة الإلكترونية، قد تحتاج إلى العثور على طلب حسب معرف العميل (أعطني طلبات هذا العميل) وبحلول التاريخ (أعطني الطلبات في تاريخ). في Table Storage، من الأفضل تخزين الكيان (أو مرجع إليه) مرتين - مرة باسم الجدول وPK وRK لتسهيل العثور عليه بواسطة معرف العميل، مرة واحدة لتسهيل العثور عليه بحلول التاريخ.
إدراج وتحديث وحذف
يوضح هذا القسم الممارسات المثبتة لتعديل الكيانات المخزنة في خدمة Table.
الدفعات
تعرف حركات الدفعات بحركات مجموعة الكيانات في Azure Storage. يجب أن تكون جميع العمليات داخل حركة مجموعة الكيان في قسم واحد وفي جدول واحد. استخدم حركات مجموعة الكيانات حيثما أمكن لتنفيذ عمليات الإدراج والتحديث والحذف على الدفعات. يتسبب استخدام حركات مجموعة الكيانات في تقليل عدد الجولات من تطبيق العميل لديك إلى الخادم، وتقليل عدد الحركات القابلة للفوترة (يتم احتساب حركة مجموعة الكيان كحركة واحدة لأغراض الفوترة ويمكن أن تحتوي على ما يصل إلى 100 عملية تخزين)، وتمكين التحديثات البسيطة (جميع العمليات التي تنجح أو تفشل داخل حركة مجموعة كيان). تستفيد البيئات ذات زمن الانتقال العالي مثل الأجهزة المحمولة بشكل كبير من استخدام معاملات مجموعة الكيانات.
Upsert
استخدام عمليات جدول Upsert كلما أمكن ذلك. هناك نوعان من Upsert، وكلاهما يمكن أن يكون أكثر كفاءة من عمليات الإدخالوالتحديث التقليدية:
- InsertOrMerge: استخدم هذه العملية عندما ترغب في تحميل مجموعة فرعية من خصائص الكيان، ولكنك لست متأكدًا مما إذا كان الكيان موجودًا بالفعل. إذا كان الكيان موجودا، يقوم هذا الاستدعاء بتحديث الخصائص المضمنة في عملية Upsert ، ويترك كافة الخصائص الموجودة كما هي، إذا لم يكن الكيان موجودا، فإنه يدرج الكيان الجديد. يكون ذلك مماثلاً لاستخدام الإسقاط في استعلام، حيث تحتاج فقط إلى رفع الخصائص التي يتم تغييرها.
- InsertOrReplace: استخدم هذه العملية عندما ترغب في رفع كيان جديد بالكامل، ولكنك لست متأكدًا مما إذا كان موجودًا بالفعل. استخدم هذه العملية عندما تعرف أن الكيان الذي تم رفعه حديثًا صحيح تمامًا لأنه يستبدل الكيان القديم بالكامل. على سبيل المثال، تريد تحديث الكيان الذي يخزن الموقع الحالي للمستخدم بغض النظر عما إذا كان التطبيق قد قام مسبقا بتخزين بيانات الموقع للمستخدم أم لا؛ اكتمل كيان الموقع الجديد، ولا تحتاج إلى أي معلومات من أي كيان سابق.
تخزين سلسلة بيانات في كيان واحد
في بعض الأحيان، يخزن أحد التطبيقات سلسلة من البيانات التي ينبغي استردادها بشكل متكرر بالكامل في نفس الوقت: على سبيل المثال، قد يتتبع أحد التطبيقات استخدام وحدة CPU على مدار الوقت لرسم مخطط مجمع للبيانات في آخر 24 ساعة. أسلوب واحد يتمثل في أن يكون كيان جدول واحد في الساعة، مع كل كيان يمثل ساعة محددة وتخزين استخدام وحدة CPU لتلك الساعة. لرسم هذه البيانات، يحتاج التطبيق إلى استرداد الكيانات التي تحتفظ بالبيانات في الـ24 ساعة الأخيرة.
بدلاً من ذلك، يمكن للتطبيق لديك تخزين استخدام CPU لكل ساعة كخاصية منفصلة لكيان واحد: لتحديث كل ساعة، يمكن للتطبيق الخاص بك استخدام استدعاء واحد InsertOrMerge Upsert لتحديث القيمة في آخر ساعة. لرسم البيانات، يحتاج التطبيق فقط لاسترداد كيان واحد بدلاً من 24 كيانًا، ما يحقق كفاءة الاستعلام. لمزيد من المعلومات حول كفاءة الاستعلام، راجع القسم المعنون نطاق الاستعلام.
تخزين بيانات مصنفة في كائنات ثنائية
إذا كنت تقوم بإدراج دفعة ثم استرداد نطاقات من الكيانات معا، ففكر في استخدام الكائنات الثنائية كبيرة الحجم بدلا من الجداول. يكون ملف السجل مثالاً جيدًا. يمكنك دفع عدة دقائق من السجلات وإدراجها، واسترداد عدة دقائق من السجلات في كل مرة. في هذه الحالة، يكون الأداء أفضل إذا كنت تستخدم الكائنات الثنائية بدلاً من الجداول، حيث يمكنك تقليل عدد الكائنات المكتوبة أو المقروءة بشكل ملحوظ، وربما أيضًا عدد الطلبات التي تحتاج إلى إجراء.
الخطوات التالية
الملاحظات
قريبًا: خلال عام 2024، سنتخلص تدريجيًا من GitHub Issues بوصفها آلية إرسال ملاحظات للمحتوى ونستبدلها بنظام ملاحظات جديد. لمزيد من المعلومات، راجع https://aka.ms/ContentUserFeedback.
إرسال الملاحظات وعرضها المتعلقة بـ