باستخدام جداول البحث مع تخزين جدول Azure- يستحق إنشاء خدمة عامل فقط لإدارة هذا؟

Question

أنا أبحث في القيام ببعض التطوير لمنصة Azure. لا أحتاج إلى الأشياء العلائقية الكاملة التي تحصل عليها من SQL Azure وسأكون مهتمًا جدًا باستخدام تخزين الجدول بدلاً من ذلك.

الآن الشيء العلائقي الوحيد الذي يجب أن أكون قادرًا على القيام به هو تمثيل العلاقات بين العدد والكثير من العدد بين الجداول في التخزين.

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

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

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

إذا كانت هذه استراتيجية مفيدة ، فهل هناك أداة حالية للقيام بذلك؟ إذا لم يكن الأمر كذلك ، فما الذي سيعمل بشكل أفضل أم أنه لا يوجد فائدة ملموسة؟ هل يجب أن أمتصها لأسفل وأذهب إلى SQL لـ Azure أو نوع من الحلول غير المتجانسة حيث أقوم بتخزين بياناتي الكبيرة في تخزين الجدول وبحث عني ومراجع الجدول في SQL؟

Answer 1

لن يكون للخدمة المستضافة وصول أسرع إلى تخزين الجدول ؛ لن يتم فواتير النطاق الترددي بين خدمتك وتخزين الجدول (طالما أنه في مركز البيانات نفسه).

يعد استخلاص تخزين الجدول في خدمة فكرة جيدة ، ويمكن القيام به إما مع دور العامل أو دور خدمة WCF. إذا كنت تشاهد الإعلانات في PDC لهذا العام ، فربما رأيت أن أدوار الويب القادمة ستكون لها IIs كاملة وتكون قادرًا على استضافة تطبيقات ويب متعددة ، بحيث يمكنك استضافة موقع الويب الخاص بك وخدمتك في نفس الدور (المزيد من التكلفة فعال من الاستضافة في أدوار منفصلة).