سؤال

بعد التصويت السلبي، أدركت بكل تواضع أن رسالتي كانت هائلة تبجح.لذلك قمت بتحريره ولخصت هذا في السؤال الذي أود حقًا معرفته.أعتذر عن تعليقاتي الصارخة قبل هذا التعديل ;)

يبدو أن البرامج التعليمية الوحيدة التي تتحدث عن استخدام Amazon's SimpleDB في موقع Rails تستخدم AWSDBProxy...شخصيًا، أجد أن هذا غير بديهي لتوسيع النطاق، مع الأخذ في الاعتبار تخطيط الخادم لموقع Rails النموذجي أدناه (باستخدام AWSDBProxy):

البرنامج المساعد هنا: http://agilewebdevelopment.com/plugins/aws_sdb_proxy

الصورة هنا: http://www.freeimagehosting.net/uploads/91be4e0617.png

كما ترون، حتى لو أضفنا المزيد من الهجين، لدينا مشكلتين.

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

الحل بالطبع هو إضافة المزيد من AWSDBProxies...ولكن لماذا لا نستخدم الكود التالي على سبيل المثال، في فصل دراسي، مع تخطي الوكيل معًا؟

service = AwsSdb::Service.new(Logger.new(nil),
                                CONFIG['aws_access_key_id'],
                                CONFIG['aws_secret_access_key'])
service.query(domain, query)

إذن ما أقصده هو إذا كنت أنت نكون باستخدام AWSDBProxy، ما هي مبرراتك لذلك؟وإذا كنت تستخدمه بالفعل، فما هو أدائك؟إذا كان لديك أرقام صعبة، فسيكون هذا موضع تقدير أكبر!

شكرًا!

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

المحلول

أنا لا أستخدمه، ولم أسمع به من قبل، ولكن هذا ما أعتقد أنه أسباب معقولة.

  1. أنت تقوم بتشغيل خادم التطبيق الرئيسي لديك على EC2، وبالتالي فإن احتمال فشل الاتصال بالإنترنت لا يؤثر عليك أكثر من مرة.
  2. يمكنك تشغيل وكيل واحد على كل خادم من خوادم التطبيقات لديك.لذا فإن تعطل الاتصال ليس أسوأ من تعطل الاتصال (الاتصالات) بقاعدة البيانات.
  3. لأنه يمكن القيام به.وهذا سبب جيد مثل أي سبب آخر في مشروع مفتوح المصدر.في بعض الأحيان، يستغرق الأمر بناء شيء ما قبل أن تعرف ما إذا كان الشيء المذكور فكرة جيدة أم سيئة.
  4. ليس لديك مستويات حركة المرور التي تحتاج إلى موازن تحميل.ثم يتقلص الرسم التخطيطي الخاص بك إلى خط، إن لم يكن جهازًا واحدًا.
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top