2013-07-07 4 views
5

में डेटा स्टोर से पूछताछ करने का सबसे प्रभावी तरीका मेरे पास लगभग 150,000 इकाइयों के साथ एक डेटा स्टोर है। जब मैं फ़िल्टर का उपयोग कर स्टोर से पूछता हूं, तो मेरे प्रश्न वास्तव में धीमे होते हैं। मेरी संरचना पूरी तरह से फ्लैट है, यानी हर इकाई एक-दूसरे का भाई है।ऐप इंजन

1: फिल्टर के बजाय जीक्यूएल का उपयोग करना बेहतर है?

2: क्या यह डेटा स्टोर के लिए सबसे अच्छा उपयोग-मामला नहीं है, और क्या मुझे इसके बजाय SQL डेटाबेस का उपयोग करना चाहिए?

यहाँ मेरी कोड का एक उदाहरण है:

// Look for a buy opportunity 
dateFilter = new FilterPredicate("date", FilterOperator.EQUAL, dt); 
scoreFilter = new FilterPredicate("score", FilterOperator.LESS_THAN_OR_EQUAL, 10.0); 
safetyFilter = new FilterPredicate("score", FilterOperator.GREATER_THAN_OR_EQUAL, -1.0); 
mainFilter = CompositeFilterOperator.and(dateFilter,scoreFilter,safetyFilter); 
q = new Query("StockEntity",stockKey).setFilter(mainFilter); 
q.addSort("score", Query.SortDirection.ASCENDING); 

stocks = datastore.prepare(q).asList(FetchOptions.Builder.withLimit(availableSlots)); 

कुछ और जानकारी:

  1. 150,000ish रिकॉर्ड, 500 शेयरों के बीच बांटा, शेयर प्रति इतना करीब 300 रिकॉर्ड, में प्रत्येक दिन के लिए एक एक तिथि सीमा।

  2. उपर्युक्त की तरह क्वेरी, जहां एक विशिष्ट तिथि पारित की जाती है, और 500 स्टॉक प्रभावी रूप से 'स्कोर' के आधार पर फ़िल्टर किए जाते हैं, रिकॉर्ड के लिए वांछित रिकॉर्ड की संख्या 10 से 20 सेकंड के बीच होती है मेरी विकास मशीन पर पूरा करने के लिए।

अभी तक उत्पादन में दबाव डालने की कोशिश नहीं की है, लेकिन मुझे लगता है कि मैं इसे अगले कोशिश करूँगा - मुझे लगा कि इसमें कोई बड़ा अंतर नहीं होगा। मेरी देव मशीन काफी उच्च spec iMac है।

+1

जीक्यूएल और फ़िल्टर एक ही काम करते हैं। आपको अपने डेटा को देखने और अपने प्रश्नों के लिए इसे अनुकूलित करने के तरीकों की तलाश करने की आवश्यकता है। –

+0

डेटास्टोर जैसे वातावरण में कोई कैसे अनुकूलित करता है? स्टॉक टिकर: स्ट्रिंग बंद कीमत: डबल स्कोर: डबल दिनांक: मैं एसक्यूएल/इंडेक्स आदि डाटा वस्तु बहुत सरल है का उपयोग करने के लिए प्रयोग किया जाता रहा हूँ स्ट्रिंग ... और मुझे 150k के बारे में रिकॉर्ड है कि देखने के लिए है उसके जैसा। –

+1

आपको हमें कुछ और जानकारी देने की ज़रूरत है, जैसे कि आप कितने रिकॉर्ड लौट रहे हैं, क्वेरी कितनी बार चलती है, पैरामीटर बदलते हैं। अधिकांश डेटास्टोर ऑप्टिमाइज़ेशन लिखने के समय प्रीप्रोसेसिंग के आसपास घूमते हैं, डेटा को denormalizing, लगातार पूछताछ कैशिंग। इसके चेहरे पर यह क्वेरी तेज होनी चाहिए, लेकिन यदि आप बड़ी संख्या में रिकॉर्ड्स पुनर्प्राप्त करने का प्रयास कर रहे हैं तो आप प्रदर्शन दीवारों को मार देंगे। –

उत्तर

0

https://developers.google.com/appengine/docs/java/datastore/queries#Java_Restrictions_on_queries

असमानता फिल्टर

में अधिकतम एक संपत्ति

तक ही सीमित हैं पूरे सूचकांक तालिका, क्वेरी तंत्र एक प्रश्न के संभावित परिणाम एक से सटे होने के सभी पर निर्भर करता है स्कैन करने के लिए होने से बचाने के इंडेक्स में दूसरा। इस बाधा को पूरा करने के लिए, किसी एक क्वेरी अपने फिल्टर के सभी भर में एक से अधिक संपत्ति पर असमानता की तुलना (LESS_THAN, LESS_THAN_OR_EQUAL, GREATER_THAN, GREATER_THAN_OR_EQUAL, NOT_EQUAL) का उपयोग नहीं कर सकते हैं।

कम जवाब यह है कि क्या तुम सच में काफी क्या आप डेटा संग्रह के साथ चाहते हैं नहीं कर सकते हैं: उदाहरण के लिए, निम्न क्वेरी क्योंकि दोनों असमानता फिल्टर एक ही संपत्ति पर लागू होते हैं, मान्य है।

+0

एक और अच्छी लग रही है, वह एक से अधिक संपत्ति पर असमानता तुलना का उपयोग नहीं कर रहा है। – Aert

+0

हूप्स। मैं कसम खाता हूं कि दूसरे ने क्षेत्र के नाम पर सुरक्षा कहा। –

0

सबसे पहले, यह क्वेरी वास्तविक डेटास्टोर पर तेज़ी से चलती है।

  1. जीक्यूएल या फ़िल्टर का उपयोग मूल रूप से वही है।

  2. डेटास्टोर का उपयोग करते समय आपको सबसे पहले आवश्यक कार्यक्षमता को परिभाषित करना चाहिए। उदाहरण के लिए: आप एक विशिष्ट आदेश और फ़िल्टर के साथ स्टॉक की एक सूची दिखाना चाहते हैं। अब उसी ऐप के किसी अन्य दृश्य को देखें जो आपके ऐप की ज़रूरत है। फिर तय करें कि डेटा को कैसे संरचित किया जाना चाहिए।

यह एक आरडीबीएमएस से बहुत अलग है जहां डेटाबेस अक्सर डेटा मॉडल को बदले बिना सबसे कार्यक्षमता समायोजित कर सकते हैं और डेटा एक अधिक 'सामान्य' जिस तरह से (सामान्य) में मॉडलिंग की है।

सामान्य तौर पर, Datastore का पढ़ा अगर आप कुंजी है जो कुछ के लिए यह आप पढ़ना चाहते हैं पता प्रदर्शन इष्टतम हो जाएगा और यह सबसे खराब है पर जब प्रश्नों कर के बाद से है कि हमेशा एक सूचकांक 'स्कैन' की आवश्यकता है यह प्रदर्शन करेंगे।

यह जानकर, मैं अक्सर पूर्वजों के संबंध का उपयोग करता हूं। एक पूर्वजों के 'बच्चों' का अनुरोध करना बेहतर प्रदर्शन करता है और लगातार होता है। उदाहरण के लिए, मैं की तरह एक प्रश्न का उपयोग करें:

SELECT * WHERE ANCESTOR IS {key} 

कहाँ {कुंजी} पूर्वज (या 'माता-पिता') के लिए महत्वपूर्ण है। यह क्वेरी पूर्वजों की इकाई और उन सभी संस्थाओं को लौटाती है जिनके पूर्वजों में उनके पूर्वजों की कुंजी है। दुर्लभ अवसरों पर मैं समूह में से किसी एक को ऑब्जेक्ट्स के लिए पैरेंट 'वैल्यू' के रूप में उपयोग करता हूं लेकिन सावधान रहें, इकाई लिखने के बाद एक कुंजी बदलने योग्य नहीं है (आप कुंजी बदल सकते हैं, लेकिन इसके परिणामस्वरूप एक प्रतिलिपि होगी)।

इसके अलावा, यदि आप 'सेट' के औसत आकार को जानते हैं। उदाहरण के लिए, ऑर्डरलाइन जो ऑर्डर से संबंधित हैं। आप कहीं भी प्रत्येक ऑर्डरलाइन कुंजी का ट्रैक रखना चुन सकते हैं। बैच किए गए पढ़ने में पहली 20 कुंजी का अनुरोध करना एक तेज़ ऑपरेशन है। यह मूल रूप से अनुक्रमण के समान होता है, हालांकि ऑर्डरिंग और फ़िल्टरिंग 'लिखने का समय' पर किया जा सकता है, इसलिए आपकी सूची में केवल आपके कुंजी से मेल खाने वाली कुंजी होती है।

उन विचारों को बनाने से बचें जो उपयोगकर्ताओं को 'गतिशील रूप से' फ़िल्टर का चयन करने की अनुमति देते हैं।

आगे कैसे अनुकूलित करें: 1. लुकअप या क्वेरी की संख्या को कम करने के लिए denormalization का उपयोग करें। 2. कैश (मेमकेचे) जहां आप कर सकते हैं।