किसी प्रश्न या कोड का उपयोग करने के लिए

Question

मैं जावा + जेपीए/हाइबरनेट + माइस्क्ल के लिए एक ठोस मामला मांग रहा हूं, लेकिन मुझे लगता है कि आप इस प्रश्न को बड़ी संख्या में भाषाओं में लागू कर सकते हैं।

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

तालिका आकार के आधार पर एक दृष्टिकोण दूसरे से बेहतर है?

को ध्यान में रखते:

• ही जटिलता, दोनों ही मामलों में पुनर्प्रयोग।

Answer 1

प्रोग्रामिंग में अक्सर उपयोग की जाने वाली एक सामान्य चाल है - ऑपरेशन स्पीडअप के लिए स्मृति के साथ भुगतान करना। यदि आपके पास बहुत सारे कर्मचारी हैं, और आप उनमें से एक महत्वपूर्ण भाग पूछने जा रहे हैं, एक-एक करके (कहें, 75% एक बार या दूसरे पर पूछे जाएंगे), फिर सबकुछ पूछें, कैश इसे (बहुत महत्वपूर्ण है!), और स्मृति में लुकअप को पूरा करें। अगली बार जब आप पूछें, आरडीबीएमएस की यात्रा छोड़ें, सीधे कैश पर जाएं, और तेजी से देखो: एक मेमोरी हैश लुकअप की तुलना में डेटाबेस में एक राउंडट्रिप बहुत महंगा है।

दूसरी ओर, यदि आप कर्मचारियों के एक छोटे से हिस्से तक पहुंच रहे हैं, तो आपको केवल एक कर्मचारी से पूछना चाहिए: आरडीबीएमएस से आपके कार्यक्रम में डेटा स्थानांतरण में काफी समय लगता है, बहुत सारे नेटवर्क बैंडविड्थ, बहुत सारी मेमोरी आपकी तरफ, और आरडीबीएमएस पक्ष पर बहुत सारी यादें। सभी पंक्तियों को फेंकने के लिए बहुत सारी पंक्तियां पूछना लेकिन कोई भी समझ में नहीं आता है।

Answer 2

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

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

मामलों में मेरे पास डेटाबेस है, सर्वर के पास सर्वर की तुलना में अधिक CPU पावर है, इसलिए जब तक अधिभारित न हो, तो कोड को उसी मात्रा के लिए अधिक तेज़ी से चलाएगा।

इसके अलावा आपको क्लाइंट पर डेटा में हेरफेर करने के लिए कोड लिखने के बजाय हाइबरनेट्स क्वेरी भाषा का उपयोग करके डेटाबेस पर क्वेरी करने के लिए कम कोड लिखना होगा। हाइबरनेट क्वेरी बिना किसी कोड को लिखने के कॉन्फ़िगरेशन में किसी भी क्लाइंट कैशिंग का उपयोग भी करेगी।

Answer 3

यह स्थितिगत है। मुझे लगता है कि सामान्य रूप से, सटीक परिणाम सेट प्राप्त करने के लिए एसक्यूएल का उपयोग करना बेहतर होता है।

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

दूसरी तरफ, यदि आपको पता है कि आपके डेटासेट का आकार भी नहीं है, तो आप इसे स्मृति में लोड कर सकते हैं और फिर पूछ सकते हैं - इसका लाभ यह है कि आपको आरडीबीएमएस पर जाने की आवश्यकता नहीं है, आपके सिस्टम आर्किटेक्चर के आधार पर, आपके नेटवर्क पर जाने की आवश्यकता हो सकती है या नहीं।

हालांकि, फिर भी, आप विभिन्न कैशिंग उपयोगिताओं का उपयोग कर सकते हैं ताकि सामान्य क्वेरी परिणाम कैश किए जाएं, जो डेटा को कैशिंग करने का लाभ हटा देता है।

Answer 4

सामान्य रूप से, मैं डाटाबेस को डेटाबेस को करने देता हूं कि कौन से डेटाबेस अच्छे हैं। डेटा फ़िल्टर करना कुछ डेटाबेस वास्तव में अच्छे हैं, इसलिए यह सबसे अच्छा होगा।

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

Answer 5

याद रखें, कि आपका दृष्टिकोण समय के साथ स्केल होना चाहिए। बाद में एक छोटा डेटा सेट क्या हो सकता है जो समय के साथ एक विशाल डेटा सेट में बदल सकता है। हमारे पास एक प्रोग्रामर के साथ कोई समस्या थी जिसने पूरे टेबल पर क्वेरी करने के लिए एप्लिकेशन को कोड किया था और उसके बाद मैनिप्लेशंस चलाया था। दृष्टिकोण ठीक काम करता था जब दो उप-चयनों के साथ केवल 100 पंक्तियां थीं, लेकिन जैसे ही वर्षों में डेटा बढ़ता गया, प्रदर्शन के मुद्दे स्पष्ट हो गए। केवल पिछले 365 दिनों से पूछताछ करने के लिए एक दिनांक फ़िल्टर डालने से, आपके आवेदन के पैमाने को बेहतर तरीके से मदद मिल सकती है।

Answer 6

- आप देख रहे हैं एक जवाब विशिष्ट हाइबरनेट करने के लिए, @ मार्क जवाब

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

तो सामान्य पैरामीटर

उपयोग के आवृत्ति

कुछ अर्थों डाल करने के लिए इन कर रहे हैं,

निर्णायक मोड़ डेटा के व्यावसायिक

मात्रा के लिए डेटा के

1. स्केलिंग, जब डेटा अक्सर स्केल नहीं करेगा और डेटा मिशन महत्वपूर्ण नहीं है और डेटा की मात्रा ए पर स्मृति में प्रबंधनीय है प्रत्यारोपण सर्वर और अक्सर प्रयोग किया जाता है - यदि आवश्यक हो तो इसे सभी को लाएं और उन्हें प्रोग्रामिक रूप से फ़िल्टर करें।

   यदि अन्यथा केवल विशिष्ट डेटा प्राप्त होता है।

Answer 7

बेहतर क्या है: घर पर बहुत सारे भोजन को स्टोर करने या इसे कम से कम खरीदने के लिए? जब आप बहुत यात्रा करते हैं? बस एक पार्टी की मेजबानी करते समय? यह निर्भर करता है, है ना? इसी प्रकार, सर्वोत्तम दृष्टिकोण प्रदर्शन अनुकूलन का विषय है। इसमें बहुत सारे चर शामिल हैं। जब आप अपने असली बाधाओं को जानते हैं, तो कला दोनों अपने समाधान को डिजाइन करते समय बाद में अनुकूलित करने के लिए कोने में पेंटिंग को रोकने के लिए है। एक अच्छा प्रारंभिक बिंदु यहां है: en.wikipedia.org/wiki/Performance_tuning एक विचार अधिक या कम सार्वभौमिक रूप से सहायक हो सकता है: अपने डेटा तक पहुंच को अच्छी तरह से समाहित करें।