أوضاع اتصال Azure Cosmos DB SQL SDK

  • مقالة

ينطبق على: NoSQL

كيفية اتصال عميل إلى Azure Cosmos DB له تأثيرات أداء هامة خاصة بالنسبة إلى زمن انتقال العميل المُلاحظ. يقدم Azure Cosmos DB نموذج برمجة RESTful بسيط ومفتوح عبر HTTPS يسمى وضع البوابة. بالإضافة إلى ذلك، فإنه يوفر بروتوكول TCP فعال، وهو أيضاً RESTful في نموذج الاتصال الخاص به ويستخدم TLS للمصادقة الأولية وتشفير نسبة استخدام الشبكة، ويسمى الوضع المباشر.

أوضاع الاتصال المتوفرة

وضعي الاتصال المتوفرين هما:

  • وضع البوابة

    يتم اعتماد وضع البوابة على جميع الأنظمة الأساسية SDK. إذا كان التطبيق الخاص بك يعمل ضمن شبكة اتصال الشركة مع قيود جدار الحماية الصارمة، وضع البوابة هو الخيار الأفضل لأنه يستخدم منفذ HTTPS القياسي ونقطة نهاية DNS واحدة. ومع ذلك، فإن مفاضلة الأداء هي أن وضع البوابة يتضمن قفزة شبكة إضافية في كل مرة تتم فيها قراءة البيانات أو كتابتها إلى Azure Cosmos DB. نوصي أيضاً بوضع اتصال البوابة عند تشغيل التطبيقات في البيئات التي تحتوي على عدد محدود من اتصالات مأخذ التوصيل.

    عند استخدام SDK في وظائف Azure، خاصة في خطة الاستهلاك، كن على علم بـ حدود الاتصالات الحالية.

  • الوضع المباشر

    الوضع المباشر يدعم الاتصال من خلال بروتوكول TCP، باستخدام TLS للمصادقة الأولية وتشفير نسبة استخدام الشبكة، ويوفر أداء أفضل بسبب وجود عدد أقل من قفزات الشبكة. يتصل التطبيق مباشرةً بالنسخ المتماثلة الخلفية. الوضع المباشر حالياً مدعوم فقط على .NET وأنظمة Java SDK الأساسية.

أوضاع اتصال Azure Cosmos DB

أوضاع الاتصال هذه شرطاً أساساً لمسار طلبات مستوى البيانات - قراءة وكتابة المستند - تأخذ من جهاز العميل الخاص بك إلى أقسام في نهاية خلفية Azure Cosmos DB. الوضع المباشر هو الخيار المفضل للحصول على أفضل أداء - فهو يسمح للعميل بفتح اتصالات TCP مباشرةً إلى أقسام في الواجهة الخلفية لـ Azure Cosmos DB وإرسال الطلبات مباشرةً دون وسيط. وعلى النقيض من ذلك، في وضع "البوابة"، يتم توجيه الطلبات التي قام بها العميل إلى ما يسمى بخادم "البوابة" في الواجهة الأمامية لـ Azure Cosmos DB، والتي بدورها تقوم بإعادة توجيه طلباتك إلى القسم (الأقسام) المناسب في الواجهة الخلفية لـ Azure Cosmos DB.

نطاقات منافذ المصادر

عند استخدام الوضع المباشر، تحتاج إلى التأكد من أن عميلك يمكنه الوصول إلى المنافذ التي تتراوح بين 10000 و20000 لأن Azure Cosmos DB يستخدم منافذ TCP ديناميكية. هذا بالإضافة إلى منافذ البوابة. عند استخدام الوضع المباشر على نقاط النهاية الخاصة، يمكن استخدام النطاق الكامل من منافذ TCP - من 0 إلى 65535 بواسطة Azure Cosmos DB. إذا لم تكن هذه المنافذ مفتوحة على العميل الخاص بك وحاولت استخدام بروتوكول TCP، فقد تتلقى خطأ 503 Service غير متوفر.

يعرض الجدول التالي ملخصا لأوضاع الاتصال المتوفرة لمختلف واجهات برمجة التطبيقات ومنافذ الخدمة المستخدمة لكل واجهة برمجة تطبيقات:

وضع الاتصال بروتوكول مدعوم عدة تطوير البرامج SDK مدعومة منفذ واجهة برمجة التطبيقات/الخدمة
‏‏البوابة HTTPS جميع عدد تطوير البرامج SDK SQL (443)، MongoDB (10255)، Table (443)، Cassandra (10350)، Graph (443)
Direct TCP (مشفر عبر TLS) .NET SDK Java SDK عند استخدام نقاط النهاية العامة/الخدمة: المنافذ في نطاق 10000 إلى 20000
عند استخدام نقاط النهاية الخاصة: المنافذ في النطاق 0 إلى 65535

بنية اتصال الوضع المباشر

كما هو مفصل في المقدمة، سيتصل عملاء الوضع المباشر مباشرة بالوضع الخلفي من خلال بروتوكول TCP. يمثل كل وضع خلفي نسخة متماثلة في مجموعة نسخ متماثلة تنتمي إلى قسم مادي.

التوجيه

عندما تقوم Azure Cosmos DB SDK على الوضع المباشر بتنفيذ عملية، فإنها تحتاج إلى حل النسخة المتماثلة الخلفية التي تريد الاتصال بها. الخطوة الأولى هي معرفة القسم الفعلي الذي يجب أن تنتقل إليه العملية، ولهذا، تحصل SDK على معلومات الحاوية التي تتضمن تعريف مفتاح القسم من عقدة البوابة. كما أنه يحتاج إلى معلومات التوجيه التي تحتوي على عناوين TCP الخاصة بالنسخ المتماثلة. تتوفر معلومات التوجيه أيضا من عقد البوابة وكلاهما يعتبر بيانات تعريف وحدة التحكم. بمجرد حصول SDK على معلومات التوجيه، يمكنه المتابعة لفتح اتصالات TCP إلى النسخ المتماثلة التي تنتمي إلى القسم المادي المستهدف وتنفيذ العمليات.

تحتوي كل مجموعة نسخ متماثلة على نسخة متماثلة أساسية واحدة وثلاثة ثانوية. يتم توجيه عمليات الكتابة دائما إلى عقد النسخ المتماثلة الأساسية بينما يمكن تقديم عمليات القراءة من العقد الأساسية أو الثانوية.

رسم تخطيطي يوضح كيف تقوم S D Ks في الوضع المباشر بإحضار الحاوية ومعلومات التوجيه من البوابة قبل فتح اتصالات T C P إلى العقد الخلفية

نظرا لأن معلومات الحاوية والتوجيه لا تتغير كثيرا، يتم تخزينها مؤقتاً محلياً على مجموعات تطوير البرامج (SDK) حتى تتمكن العمليات اللاحقة من الاستفادة من هذه المعلومات. كما يتم إعادة استخدام اتصالات TCP التي تم إنشاؤها بالفعل عبر العمليات. إذا لم يتم تكوين خلاف ذلك من خلال خيارات SDKs، يتم الحفاظ على الاتصالات بشكل دائم خلال عمر مثيل SDK.

قد تخضع الأجهزة التي تحتفظ بالنسخ المتماثلة للترقيات أو الصيانة، كما هو الحال مع أي بنية موزعة. الخدمة ستضمن أن مجموعة النسخ المتماثلة تحافظ على التناسق، ولكن أي حركة نسخ متماثلة قد تتسبب في تغيير عناوين TCP الموجودة. في هذه الحالات، تحتاج SDKs إلى تحديث معلومات التوجيه، وإعادة الاتصال بالعناوين الجديدة من خلال طلبات البوابة الجديدة. يجب ألا تؤثر هذه الأحداث على اتفاقية مستوى الخدمة P99 الشاملة.

حجم الاتصالات

يحتوي كل قسم فعلي على مجموعة نسخ متماثلة من أربعة نسخ متماثلة، من أجل توفير أفضل أداء ممكن، وسينتهي الأمر بمجموعات SDK إلى فتح اتصالات بجميع النسخ المتماثلة لأعباء العمل التي تمزج بين عمليات الكتابة والقراءة. يتم موازنة تحميل العمليات المتزامنة عبر الاتصالات الحالية للاستفادة من الإنتاجية التي توفرها كل نسخة متماثلة.

هناك عاملان ينصان على عدد اتصالات TCP التي ستفتحها SDK:

  • عدد الأقسام المادية

    في حالة الثبات، سيكون لـ SDK اتصال واحد لكل نسخة متماثلة لكل قسم مادي. كلما زاد عدد الأقسام المادية في الحاوية، زاد عدد الاتصالات المفتوحة. نظراً لأن العمليات يتم توجيهها عبر أقسام مختلفة، يتم إنشاء الاتصالات عند الطلب. سيكون متوسط عدد الاتصالات بعد ذلك هو عدد الأقسام المادية في أربعة.

  • حجم الطلبات المتزامنة

    يُمكن لكل اتصال تم إنشاؤه أن يخدم عددا قابلا للتكوين من العمليات المتزامنة. إذا تجاوز حجم العمليات المتزامنة هذا الحد، سيتم فتح اتصالات جديدة لخدمتها، ومن الممكن أن يتجاوز عدد الاتصالات المفتوحة رقم الحالة الثابتة بالنسبة للقسم المادي. من المتوقع حدوث هذا السلوك لأعباء العمل التي قد يكون لها طفرات في حجم التشغيل الخاص بها. بالنسبة لـ .NET SDK، يتم تعيين هذا التكوين بواسطة CosmosClientOptions.MaxRequestsPerTcpConnection، وبالنسبة لـ Java SDK، يمكنك تخصيصه باستخدام DirectConnectionConfig.setMaxRequestsPerConnection.

بشكلٍ افتراضي، يتم الحفاظ على الاتصالات بشكل دائم للاستفادة من أداء العمليات المستقبلية (فتح اتصال له نفقات حسابية عامة). قد تكون هناك بعض السيناريوهات التي قد ترغب فيها في إغلاق الاتصالات غير المستخدمة لبعض الوقت مع فهم أن هذا قد يؤثر على العمليات المستقبلية قليلا. بالنسبة لـ .NET SDK، يتم تعيين هذا التكوين بواسطة CosmosClientOptions.IdleTcpConnection، وبالنسبة لـ Java SDK، يمكنك تخصيصه باستخدام DirectConnectionConfig.setIdleConnection. لا يوصى بتعيين هذه التكوينات إلى قيم منخفضة لأنها قد تتسبب في إغلاق الاتصالات بشكل متكرر وتؤثر على الأداء العام.

تفاصيل التنفيذ للغة محددة

لمزيد من تفاصيل حول التنفيذ فيما يتعلق باللغة، راجع:

الخطوات التالية

للحصول على تحسينات أداء نظام عدة تطوير البرامج SDK الأساسي المحدد: