2009-02-09 9 views
10

मुझे रेल प्रोजेक्ट (रेल 2.0.5 पर चल रहा है) में कुछ प्रदर्शन समस्याएं हैं, उदाहरण के लिए मेरे उपयोगकर्ता प्रशासन पृष्ठों में।प्रदर्शन में सुधार करने के लिए रेल ऐप पर रूबी में MySQL दृश्यों का उपयोग

मेरे उपयोगकर्ता मॉडल में कई रिश्तों (विवरण, पते, भूमिकाएं ...) हैं जो उत्सुक लोडिंग के साथ लोड हो जाते हैं। इससे कुछ मामलों के लिए वास्तव में विशाल SQL क्वेरी उत्पन्न होती हैं, 30 उपयोगकर्ताओं को लोड करने में लगभग एक मिनट लगते हैं। दूसरी ओर उत्सुक लोडिंग को हटाने से सैकड़ों प्रश्न उत्पन्न होते हैं, अंत में मुझे एक ही समस्या है: पृष्ठ लोड करना धीमा है।

मैं जावा & ओरेकल पर विकसित होता था, इस तरह के बड़े प्रश्नों के लिए मैंने विचार बनाने के लिए उपयोग किया था, उन विचारों को तब तेजी से प्रतिपादन के लिए कैश किया गया था। यह बनाए रखने के लिए बेहद उबाऊ था, क्योंकि मुझे दृश्य स्क्रिप्ट इत्यादि में मैन्युअल रूप से डेटाबेस फ़ील्ड अपडेट करना था ...

लेकिन वास्तव में शानदार प्रदर्शन था .... इसलिए मैं सोच रहा था कि किसी ने कभी भी कुछ लागू करने का प्रयास किया है सक्रिय रिकॉर्ड में MySQL दृश्यों का लाभ उठाएं?

मैं बस किया था कुछ बुनियादी परीक्षण, यहाँ है मेरे विचार (बस कुछ ही क्षेत्रों उदाहरण के लिए, मैं एक मानक शोकहारा प्रमाणीकरण उपयोगकर्ता तालिका है, और व्यक्तिगत datas के लिए एक बड़ी मेज "विवरण"):

CREATE VIEW users_vs AS SELECT 
users.id    ,   
users.login   ,   
users.email   ,   
details.last_name   , 
details.first_name   , 
details.phone    , 
details.fax     , 
FROM `users` LEFT OUTER JOIN `details` ON details.user_id = users.id ; 

फिर एक मॉडल:

class UsersV < ActiveRecord::Base 
end 

मेरे कंसोल में कुछ बातें की कोशिश की:

u=UsersV.find(:first) # ok ! 
u=UsersV.find_by_last_name('smith') #=> ok ! 
us=UsersV.find_all_by_last_name('smith') #=> ok too ! 

लॉग को देखते हुए, सरल प्रश्नों को उसी तरह से संभाला जाता है जैसे किसी भी टेबल प्रश्न

बेशक, उन नकली मॉडल का उपयोग डेटा को पढ़ने के लिए किया जाएगा।

मैं सोच रहा हूँ:

  • अगर किसी को पहले से ही उस की कोशिश की?

  • यदि यह एक अच्छा विचार है?

  • बजाय memcached की तरह अगर मैंने कुछ ध्यान देना चाहिए ...

+0

30 उपयोगकर्ताओं को लोड करने में एक मिनट बहुत धीमा लगता है। क्या आपके एसोसिएशन में इस्तेमाल किए गए सभी कॉलम अनुक्रमित हैं? आम तौर पर कितने टेबल और पंक्तियां पुनर्प्राप्त की जाती हैं? यदि आप आसानी से कम लोडिंग का उपयोग करते हैं तो क्या होता है? (MySQL हमेशा मल्टी-टेबल को कुशलतापूर्वक अनुकूल नहीं करता है) –

उत्तर

5

विचारों के साथ "समस्या" (और इस मामले में आप शायद भौतिक दृश्य चाहते हैं, यह मानते हुए कि जटिल क्वेरी आधारित है, अक्सर बदलती नहीं है) यह है कि आप रेल की ड्रवाई का उल्लंघन करते हैं, कुछ हद तक (दृश्य के लिए यूजरवी मॉडल के अतिरिक्त, जो शुद्धवादियों का तर्क होगा, उपयोगकर्ता मॉडल का एक डुप्लिकेशंस है।)

तो आदर्श समाधान आपकी जटिल क्वेरी के लिए आरडीबीएमएस से अधिक लाभ उठाना होगा । अगर अनचाहे प्रश्नों को अभी भी निष्पादित करने में लंबा समय लगता है (आपको अभी भी उन्हें memcached populate करने के लिए चलाने के लिए है), या यदि आप थोड़ा समय-फज (यानी कैश्ड परिणाम डॉन 'समायोजित नहीं कर सकते हैं, तो memcached आपकी मदद करने में सक्षम नहीं होगा टी को रीयलटाइम-सटीक होना चाहिए) और/या शामिल टेबल अक्सर संशोधित हो जाते हैं। यदि आप क्वेरी आगे अनुकूलन कर सकते हैं, तो यह बजाय सेकंड के मिलीसेकेंड ले जाएगा (उचित सूचकांक जोड़ने के लिए, विश्लेषण चलाने, आदि)

  • आप उपयोग कर/बाहर प्रयास करने का विकल्प है, तो

    • MySQL में देखना पोस्टग्रेस जैसे अन्य आरडीबीएमएस, हर तरह से इसे आज़माएं। ओएसकल और पोस्टग्रेस जैसे अन्य लागत-आधारित इंजनों की तुलना में MySQL जटिल रूप से जटिल (इनो डीबी) में शामिल होने के साथ खराब है। मैंने माईएसक्यूएल से पोस्टग्रेस और जटिल जॉइन में स्विच किया है जो MySQL पर 30s + ले जाएगा (सभी इंडेक्स के साथ) पोस्टग्रेज़ पर मिलीसेकंड लें। यदि पोस्टग्रेस के साथ खेलना PGAdminIII के ग्राफिकल व्याख्या योजना टूल का अच्छा उपयोग करता है।
  • 3

    मैं एक नियमित आधार पर रेल में तालिका दृश्यों का उपयोग और मैं इसके बारे में बहुत खुश हूँ। रेल उन्हें सामान्य टेबल के रूप में मानते हैं, जहां तक ​​आप केवल रिकॉर्ड पढ़ने के लिए उनका उपयोग करते हैं (जो मेरा सामान्य परिदृश्य है)। जब तक आपके दृश्य में केवल एक तालिका होती है, तब भी आप इसके साथ अन्य सभी सीआरयूडी सामान भी कर सकते हैं। तो, मेरा जवाब है: बस यह करो।

    +0

    नहीं, मुझे डेटाबेस स्थिति को सिंक करने में समस्या हो रही है, जो सर्वर पर विचार बना रहा है जो माइग्रेशन के बजाय स्कीमा लोड करता है, क्योंकि रेल के रूप में विचारों को मेरे विचारों के रूप में समाप्त किया जाता है विचारों के बजाय टेबल – pahnin

    1

    http://github.com/aeden/rails_sql_views/tree/master

    ↑ एक प्रवास में दृश्य बनाने के लिए। मैं केवल चरम मामलों में उनका उपयोग करता हूं क्योंकि वे आपके आवेदन से तर्क को छिपाते हैं और यह आमतौर पर अच्छा नहीं होता है।

    यदि आपके पास इतना अधिक संबंधित डेटा है तो आप रेल के साथ ActiveRecord के बजाय DataMapper जैसे कुछ का उपयोग कर देख सकते हैं क्योंकि यह आवश्यकतानुसार आलसी लोडिंग डेटा का समर्थन करता है।

    1

    सुनिश्चित करें कि MySQL Query Caching सक्षम है जो परिणाम सेट को कैश करता है।मेरे पास कई स्थितियां हैं जहां जुड़ने के साथ कुछ प्रश्नों के बिना जुड़ने के बिना कई प्रश्न वास्तव में तेज़ हैं, भले ही आप सर्वर पर और अधिक यात्रा कर रहे हों।

    संबंधित मुद्दे