क्या मुझे इस स्थिति में ड्रोल का उपयोग करना चाहिए?

Question

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

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

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

Answer 1

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

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

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

प्रकार इस तथ्य से थोड़ा जटिल हो जाते हैं कि यह संभवतः एक पुस्तक दो प्रकार की हो सकती है (यदि आप एक निश्चित पाठ्यक्रम ले रहे हैं, या सामान्य रूप से यदि आप विभाग का हिस्सा हैं), लेकिन दृष्टिकोण अभी भी पकड़ना चाहिए।

Answer 2

मैं छात्रों की संख्या के कार्यों के नियमों की संख्या के बारे में चिंतित हूं - जो वास्तव में चीजों को मुश्किल बना सकता है (जो सबसे बड़ी समस्या की तरह लगता है)।

Answer 3

सबसे पहले, प्रत्येक पुस्तक के लिए नियम न बनाएं। प्रतिबंधों पर नियम बनाएं — किताबों की तुलना में बहुत कम प्रतिबंध परिभाषित किए गए हैं। यह चलने वाले समय और स्मृति उपयोग पर एक बड़ा प्रभाव डालेगा।

नियम इंजन के माध्यम से किताबों का एक टन चलाना महंगा होगा। खासकर जब से आप उपयोगकर्ता को सभी परिणाम नहीं दिखाएंगे: प्रति पृष्ठ केवल 10-50। एक विचार जो दिमाग में आता है वह नियम मानदंडों का एक सेट बनाने के लिए नियम इंजन का उपयोग करना है। (मैं वास्तव में इस — नीचे देखें करना होगा नहीं।)

यहाँ मेरे मन में है:

rule "Only two books for networking" 
when 
    Student($checkedOutBooks : checkedOutBooks), 
    Book(subjects contains "networking", $book1 : id) from $checkedOutBooks, 
    Book(subjects contains "networking", id != $book1) from $checkedOutBooks 
then 
    criteria.add("subject is not 'networking'", PRIORITY.LOW); 
end 

rule "Books allowed for course" 
when 
    $course : Course($textbooks : textbooks), 
    Student(enrolledCourses contains $course) 

    Book($book : id) from $textbooks, 
then 
    criteria.add("book_id = " + $book, PRIORITY.HIGH); 
end 

लेकिन मैं वास्तव में ऐसा नहीं होता!

इस प्रकार मैंने समस्या को बदल दिया होगा: उपयोगकर्ता को पुस्तकें नहीं दिखाना एक खराब अनुभव है। एक उपयोगकर्ता पुस्तकें देखना चाह सकता है कि कौन सी किताबें अगली बार प्राप्त करें। किताबें दिखाएं, लेकिन प्रतिबंधित पुस्तकों के चेकआउट को अस्वीकार करें। इस तरह, आपके पास प्रति उपयोगकर्ता एक समय में नियमों के माध्यम से चलाने के लिए केवल 1-50 पुस्तकें होती हैं। यह सुंदर zippy होगा। उपरोक्त नियमों बन जाएगा:

rule "Allowed for course" 
    activation-group "Only one rule is fired" 
    salience 10000 
when 
    // This book is about to be displayed on the page, hence inserted into working memory 
    $book : Book(), 

    $course : Course(textbooks contains $book), 
    Student(enrolledCourses contains $course), 
then 
    //Do nothing, allow the book 
end 

rule "Only two books for networking" 
    activation-group "Only one rule is fired" 
    salience 100 
when 
    Student($checkedOutBooks : checkedOutBooks), 
    Book(subjects contains "networking", $book1 : id) from $checkedOutBooks, 
    Book(subjects contains "networking", id != $book1) from $checkedOutBooks, 

    // This book is about to be displayed on the page, hence inserted into working memory. 
    $book : Book(subjects contains "networking") 
then 
    disallowedForCheckout.put($book, "Cannot have more than two networking books"); 
end 

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

अंत में, नियमों को कैश किया गया। Drools — की अनुमति देता है और सुझाव देता है कि — आप नियमों को केवल ज्ञान आधार में लोड करते हैं और उसके बाद सत्र बनाते हैं। ज्ञान के आधार महंगी हैं, सत्र सस्ते हैं।

Answer 4

मेरे प्रश्न हैं: Drools अगर एक लाख पुस्तक नियमों के साथ भरी हुई कितनी स्मृति ले जाएगा? उन सभी लाखों नियमों को आग लगाना कितना तेज़ होगा?

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

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

यह एक शर्म की बात है कि हम में से कोई भी लाखों तथ्यों के साथ कुछ विशेष सेट-अप का उत्तर नहीं देता है।

कार्यान्वयन के लिए, मेरा दृष्टिकोण प्रत्येक पुस्तक के लिए एक पुस्तक वस्तु डालना होगा जो छात्र जांचना चाहता है, उन लोगों को वापस लेना, जिन्हें अनुमति नहीं है, और शेष (अनुमति) बुक ऑब्जेक्ट्स प्राप्त करने के लिए एक प्रश्न, और कारणों की सूची प्राप्त करने के लिए एक और सवाल। वैकल्पिक रूप से, अनुरोधित पुस्तक ऑब्जेक्ट्स का उपयोग करें जिसमें अतिरिक्त boolean allowed और String reasonDisallowed गुण हैं जिन्हें आप अपने नियमों में सेट कर सकते हैं।

Answer 5

किसी भी समय हम बड़े डेटा-सेट (जो यह प्रश्न है ... बड़े पैमाने पर डेटा सेट मामले में ड्रूल्स एक अच्छा फिट है या नहीं) देख रहे हैं, बॉक्स के बाहर (नीचे) सोचें। जब भी हम "लाखों वस्तुओं" या समान लॉग-एन प्रकार की समस्याओं के बारे में बात कर रहे हैं, मुझे नहीं लगता कि वे प्रश्न में उपकरण आवश्यक रूप से समस्या है।तो हां, ड्रोलस (या जेबॉस नियम) का उपयोग किया जा सकता है लेकिन केवल एक निश्चित संदर्भ में समझ में आता है ...

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

चूंकि ब्लूम फ़िल्टर केवल मूलभूत डालने()/युक्त() फ़ंक्शंस के साथ छोटी मेमोरी संरचनाएं हैं, उनके पास 1% झूठी-सकारात्मक दर के बारे में कोई कमी है। तो यह प्राथमिक कैश के रूप में काम करेगा। यदि ड्रॉल्स प्रश्न का निर्माण आम तौर पर उत्तर के रूप में "नहीं" होता है, तो ब्लूम फ़िल्टर समर्थित तथ्य-तालिका निर्माण लुकअप तेजी से बिजली और एक छोटी मेमोरी पदचिह्न (मेरे कार्यान्वयन में लगभग 1.1 बाइट प्रति रिकॉर्ड) के साथ होगा, इसलिए 1 एमबी रैम ये मामला। फिर "इसमें" केस (जो एक झूठी-सकारात्मक हो सकता है) में, स्पष्टीकरण के लिए डेटाबेस-समर्थित तथ्य तालिका का उपयोग करें। फिर, यदि 80% समय में, लुकअप गलत है, तो ब्लूम फ़िल्टर स्मृति और समय में एक बड़ी लागत-बचत होगी। अन्यथा, शुद्ध (कुछ भी - Drools तथ्यों, डेटाबेस, आदि) 1 एम रिकॉर्ड लुकअप हर बार (स्मृति और गति में) बहुत महंगा होगा।