डेटाबेस

Question

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

मध्यम सेवा स्तर डेटाबेस की वास्तविक क्वेरीिंग करता है। यूआई बस कुछ डेटा मांगता है और इसमें कोई अवधारणा नहीं है कि इसका डेटाबेस द्वारा समर्थित है।

सवाल यह है कि बड़े डेटा सेट को कैसे संभालना है? यूआई डेटा मांगता है लेकिन परिणाम स्मृति में फिट होने के लिए संभवतः बहुत बड़ा हो सकता है।

StreetSign getStreetSign(int identifier) 
Collection<StreetSign> getStreetSigns(Street street) 
Collection<StreetSign> getStreetSigns(LatLonBox box) 

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

एक समाधान पूरी तरह से लोड ऑब्जेक्ट्स (स्ट्रीटसाइन ऑब्जेक्ट्स) वापस नहीं करना है। इसके बजाय कुछ प्रकार के परिणाम सेट या इटेटरेटर लौटें जो आलसी प्रत्येक व्यक्तिगत वस्तु को लोड करता है।

getStreetSigns(box, 1, 1000000000) 

मैं:

Collection<StreetSign> getStreetSigns(LatLonBox box, int pageNumber, int resultsPerPage) 

बेशक

यूआई अभी भी एक बहुत बड़ा परिणाम सेट अनुरोध कर सकते हैं:

एक अन्य समाधान सेवा एपीआई बदलने के लिए अनुरोध डेटा के एक उपसमूह वापस जाने के लिए है इस परिदृश्य के लिए मानक उद्योग डिजाइन पैटर्न क्या उत्सुक है?

Answer 1

एएसपी.नेट में मैं सर्वर-साइड पेजिंग का उपयोग करूंगा, जहां आप केवल डेटा स्टोर से अनुरोध किए गए डेटा के पृष्ठ को पुनर्प्राप्त करेंगे। यह पूरे परिणाम सेट को पुनः प्राप्त करने का प्रयास करता है, इसे स्मृति में डालकर अनुरोध पर इसके माध्यम से पेजिंग करता है।

Answer 2

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

Answer 3

मैं कहूंगा कि संभावित डेटा के बड़े सेट के लिए संभावित exsists, तो पेजिंग मार्ग पर जाएं।

आप अभी भी MAX सेट कर सकते हैं कि आप उन्हें नहीं जाना चाहते हैं।

ईजी। SO 15, 30, 50 के पेज आकार का उपयोग करता है ...

Answer 4

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

मैं एक Microsoft दुनिया में रहता हूं, इसलिए मेरा प्राथमिक वातावरण SQL सर्वर के साथ ASP.Net है।यहाँ पेजिंग के बारे में दो लेख (जो परिणाम सेट के माध्यम से पृष्ठन के लिए कुछ तकनीकों का उल्लेख) सहायक हो सकता है कि कर रहे हैं:

Paging through lots of data efficiently (and in an Ajax way) with ASP.NET 2.0 Efficient Data Paging with the ASP.NET 2.0 DataList Control and ObjectDataSource

एक और व्यवस्था कि माइक्रोसॉफ्ट हाल ही में भेज दिया गया है "Dynamic Data" के अपने विचार है - आप हो सकता है इस मुद्दे से निपटने के तरीके के बारे में कुछ मार्गदर्शन के लिए इस के बारे में जानकारी प्राप्त करने में सक्षम होना चाहिए।

Answer 5

मैंने दो अलग-अलग उत्पादों पर समान काम किया है। एक मामले में डेटा स्रोत वैकल्पिक पृष्ठवार होता है - जावा के लिए, के लिए इसी तरह एक पृष्ठांकन योग्य इंटरफ़ेस लागू करता है:

public interface Pageable 
{ 
    public void setStartIndex(int index); 
    public int getStartIndex(); 
    public int getRowsPerPage() throws Exception; 
    public void setRowsPerPage(int rowsPerPage); 
} 

डेटा स्रोत आइटम के प्राप्त() के लिए एक और तरीका है, और एक पृष्ठवार डेटा स्रोत के कार्यान्वयन को लागू करता है बस वर्तमान पृष्ठ देता है। तो आप अपनी स्टार्ट इंडेक्स सेट कर सकते हैं, और अपने कंट्रोलर में एक पेज ले सकते हैं।

विचार करने की एक बात आपके कर्सर सर्वर पक्ष को कैश करना होगा। एक वेब ऐप के लिए आपको उन्हें समाप्त करना होगा, लेकिन वे वास्तव में प्रदर्शन के अनुसार मदद करेंगे।

Answer 6

fedora digital repository प्रोजेक्ट परिणाम-सेट-आईडी के साथ अधिकतम संख्या में परिणाम देता है। इसके बाद आप अगली क्वेरी में परिणाम-सेट-आईडी की आपूर्ति करने वाले अगले खंड की मांग करके शेष परिणाम प्राप्त करें। जब तक आप क्वेरी के बाहर कोई खोज या सॉर्टिंग नहीं करना चाहते हैं तब तक यह ठीक काम करता है।

Answer 7

इस स्थिति के लिए मैंने देखा है कि सबसे लगातार पैटर्न कुछ प्रकार की पेजिंग है, आमतौर पर तार पर भेजे गए जानकारी की मात्रा को कम करने के लिए सर्वर-साइड किया जाता है।

यहाँ अपने सड़क संकेत उदाहरण के साथ एक एसक्यूएल सर्वर 2000 (आम तौर पर तेजी एक अस्थायी तालिका की तुलना में) एक मेज चर का उपयोग कर उदाहरण है एक साथ:

CREATE PROCEDURE GetPagedStreetSigns 
(
    @Page int = 1, 
    @PageSize int = 10 
) 
AS 
    SET NOCOUNT ON 

    -- This memory-variable table will control paging 
    DECLARE @TempTable TABLE (RowNumber int identity, StreetSignId int) 

    INSERT INTO @TempTable 
    (
    StreetSignId 
) 
    SELECT [Id] 
    FROM StreetSign 
    ORDER BY [Id] 

    -- select only those rows belonging to the requested page 
    SELECT SS.* 
    FROM StreetSign SS 
     INNER JOIN @TempTable TT ON TT.StreetSignId = SS.[Id] 
    WHERE TT.RowNumber BETWEEN ((@Page - 1) * @PageSize + 1) 
         AND (@Page * @PageSize) 

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

ध्यान रखें कि यह दृष्टिकोण गन्दा हो सकता है यदि आप अंतिम उपयोगकर्ता को उस डेटा पर ऑन-द-फ्लाई फ़िल्टर लागू करने की अनुमति दे रहे हैं जो वह देख रहा है।

Answer 8

बहुत पहला सवाल किया जाना चाहिए:

¿उपयोगकर्ता की जरूरत है, या करने में सक्षम है, डेटा की इस राशि का प्रबंधन?

हालांकि परिणाम सेट को पेज किया जाना चाहिए, यदि इसका संभावित आकार इतना बड़ा है, तो उत्तर "शायद नहीं" होगा, इसलिए यूआई को इसे दिखाने की कोशिश नहीं करनी चाहिए।

मैंने हेल्थ केयर सिस्टम पर जे 2 ईई परियोजनाओं पर काम किया, जो संग्रहित डेटा की भारी मात्रा में सौदा करता है, सचमुच लाखों मरीजों, यात्राओं, रूपों, आदि, और सामान्य नियम किसी के लिए 100 से 200 पंक्तियों को दिखाने के लिए नहीं है उपयोगकर्ता खोज, उपयोगकर्ता को सलाह देते हैं कि मानदंड के उन सेटों से अधिक जानकारी उत्पन्न होती है जिसे वह समझ सकता है।

इसे लागू करने का तरीका एक प्रोजेक्ट से दूसरे प्रोजेक्ट में भिन्न होता है, तो यूआई को लॉन्च करने से पहले सेवा के आकार को पूछने के लिए मजबूर करना संभव है, या सेवा स्तर से अपवाद फेंकना संभव है परिणाम सेट बहुत बढ़ता है (हालांकि इस तरह यूआई के सीमित कार्यान्वयन के साथ सेवा स्तर जोड़ता है)।

सावधान रहें!इसका मतलब यह नहीं है कि सेवा स्तर पर प्रत्येक विधि को अपवाद फेंकना चाहिए यदि इसके परिणाम 100 से अधिक आकार के होते हैं, तो यह सामान्य नियम केवल उपयोगकर्ता को दिखाए गए परिणाम सेट पर लागू होता है, जो यूआई में नियंत्रण रखने का एक बेहतर कारण है बजाय सेवा स्तर पर।

Answer 9

आपके जैसे घर से उभरते पंक्ति-रैपर वर्गों (स्पष्ट रूप से) के साथ काम करते समय सावधान रहना एक बात है, वह कोड है जो आपके बिना डेटाबेस (डेवलपर) के बारे में जागरूक होने के लिए डेटाबेस को अतिरिक्त कॉल करता है। उदाहरण के लिए, आप एक ऐसी विधि को कॉल कर सकते हैं जो व्यक्ति वस्तुओं का संग्रह लौटाता है और सोचता है कि हुड के नीचे चलने वाली एकमात्र चीज एक "चयन * व्यक्तियों से" कॉल है। वास्तविकता में, जिस विधि को आप बुला रहे हैं वह व्यक्ति वस्तुओं के लौटे संग्रह के माध्यम से पुन: प्रयास कर सकता है और प्रत्येक व्यक्ति के ऑर्डर संग्रह को पॉप्युलेट करने के लिए अतिरिक्त डीबी कॉल कर सकता है।

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

Answer 10

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

यदि आप चाहें, तो आप उन घटकों को ले जा सकते हैं जो इस पर पेजिंग करते हैं।