سؤال

أنا في مرحلة التخطيط لتطبيق الويب الذي سيتم استضافته في Azure مع ASP.NET لموقع الويب و Silverlight داخل الموقع لتجربة مستخدم غنية. هل يجب علي استخدام جداول Azure أو SQL Azure لتخزين بيانات التطبيق الخاصة بي؟

هل كانت مفيدة؟

المحلول

يبدو أن تخزين جدول Azure أقل تكلفة من SQL Azure. كما أنه أكثر قابلية للتطوير من SQL Azure.

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

القيد الرئيسي على جداول Azure هو عدم وجود فهارس ثانوية. تم الإعلان عن ذلك في PDC '09 وهو مدرج حاليًا في وقت قريب ، ولكن لم يكن هناك أي إعلان زمني. (يرى http://windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes؟ref=title)

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

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

نصائح أخرى

على الرغم من الأسماء المماثلة SQL Azure Tables وتخزين الجدول لديها القليل جدًا من القواسم المشتركة.

فيما يلي رابطان قد يساعدانك:

في الأساس ، يجب أن يتساءل السؤال الأول عنه هل يحتاج تطبيقي حقًا إلى التوسع؟ إذا لم يكن كذلك ، فانتقل إلى SQL Azure.

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

طاولات Azure أرخص وأبسط وحجم أفضل من SQL Azure. SQL Azure هي بيئة SQL المدارة ، متعددة المستأجرين في الطبيعة ، لذلك يجب عليك تحليل ما إذا كانت متطلبات أدائك مناسبة لـ SQL Azure. تم الإعلان عن نسخة متميزة من SQL Azure وهي في معاينة اعتبارًا من كتابة هذه السطور (انظر هنا).

أعتقد أن العوامل الحاسمة التي يجب اتخاذ قرارها بين طاولات SQL Azure و Azure هي ما يلي:

  • هل تحتاج إلى القيام بندوات معقدة واستخدام فهارس ثانوية؟ إذا كانت الإجابة بنعم ، فإن SQL Azure هو الخيار الأفضل.
  • هل تحتاج إلى إجراءات مخزنة؟ إذا كانت الإجابة بنعم ، SQL Azure.
  • هل تحتاج إلى إمكانات التقييم التلقائي؟ الجداول Azure هي الخيار الأفضل.
  • لا يمكن أن يتجاوز حجم الصفوف داخل جدول Azure 4 ميغابايت. إذا كنت بحاجة إلى تخزين بيانات كبيرة في صف واحد ، فمن الأفضل تخزينها في تخزين Blob والرجوع إلى URI من Blob في صف الجدول.
  • هل تحتاج إلى تخزين كميات هائلة من البيانات شبه المنظمة؟ إذا كانت الإجابة بنعم ، فإن طاولات Azure مفيدة.

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

أحد الاعتبارات الأخرى هو الكمون. اعتاد أن يكون هناك موقع قامت Microsoft بتشغيله مع Microbenchmarks على الإنتاجية والكمون لأحجام الكائنات المختلفة مع متجر الجدول و SQL Azure. نظرًا لأن هذا الموقع لم يعد متاحًا ، سأعطيك تقريبًا تقريبيًا عما أتذكره. يميل متجر الجدول إلى الحصول على إنتاجية أعلى بكثير من SQL Azure. يميل SQL Azure إلى انخفاض الكمون (بقدر 1/5).

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

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

أدرك أن هذا سؤال قديم ، لكنه لا يزال صحيحًا للغاية ، لذلك أقوم بإضافة ردي إليه.

أشار Coderdennis وآخرون إلى بعض الحقائق - طاولات Azure أرخص ، ويمكن أن تكون طاولات Azure أكبر بكثير وأكثر كفاءة وما إلى ذلك.

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

قد لا تكون هذه مشكلة إذا كنت قد قررت بالفعل على نظام السحابة الخاص بك.

أقترح النظر في ذاكرة التخزين المؤقت Azure مع جدول Azure. يحتوي الجدول وحده على 200-300 مللي ثانية ، مع ارتفاع في بعض الأحيان ، مما قد يتباطأ بشكل كبير أوقات الاستجابة / واجهة المستخدم. يبدو أن جدول ذاكرة التخزين المؤقت + هو مزيج رابح ، بالنسبة لي.

لسؤالك ، أريد أن أتحدث عن كيفية اتخاذ قرار مع المنطق ، اختر جدول SQL والذي يحتاج إلى استخدام جدول Azure.

كما نعلم أن جدول SQL هو محرك قاعدة بيانات علائقية. ولكن إذا كان لديك بيانات كبيرة في جدول واحد ، فإن جدول SQL غير قابل للتطبيق ، لأن استعلام SQL يحصل على البيانات الكبيرة بطيئة.

في هذا الوقت ، يمكنك اختيار Azure Table ، استعلام Azure Table سريع جدًا ثم جدول SQL للبيانات الكبيرة ، على سبيل المثال ، في موقعنا ، شخص ما اشترك في العديد عنوان المقالة ووصفها ، لذلك في جدول المقالة ، هناك الكثير من البيانات ، إذا استخدمنا جدول SQL ، فقد يستغرق كل تنفيذ استعلام أكثر من 30 ثانية. ولكن في Azure Table ، احصل على خلاصة مقالة المستخدمين بواسطة PartitionKey و Rowkey سريع جدًا.

من هذا المثال ، قد تعرف كيفية الاختيار بين جدول SQL وجدول Azure.

أتساءل ما إذا كنا سننتهي ببعض مكتبات واجهة برمجة تطبيقات السحابة "المستقلة" في الوقت المناسب؟

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

هذه هي الأسئلة (وليس فقط) التي يتعين عليك طرحها على نفسك والرد عليها من أجل تحديد ما إذا كنت ستستخدم على الأرجح نهج NOSQL أو SQL في تخزين بياناتك.

يرجى النظر في أن كلا النهجين يمكن أن يتعايش بسهولة ويمكن تمديده مع تخزين blob أيضًا.

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top