2010-06-21 11 views
8

यदि मैं किसी तालिका के लिए आईडी निर्दिष्ट करने के लिए हायलो जनरेटर का उपयोग करना शुरू करता हूं, और फिर क्षमता बढ़ाने या घटाने का निर्णय लेता हूं (यानी अधिकतम 'लो' मान), क्या इससे पहले से निर्दिष्ट आईडी के साथ टकराव हो सकता है?एक बार HiLo उपयोग में आने के बाद, यदि आप क्षमता (अधिकतम लो) बदलते हैं तो क्या होता है?

मैं सोच रहा हूं कि मुझे नंबर के चारों ओर एक बड़ा लाल झंडा लगाने की ज़रूरत है, 'यह कभी भी न बदलें!'

नोट - एनएचबीर्नेट विशिष्ट नहीं है, मैं सामान्य रूप से HiLo एल्गोरिदम के बारे में उत्सुक हूं।

उत्तर

20

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

कैसे हिलो धारणात्मक काम करता है this previous SO answer

में max_lo बदलने की संपत्ति है कि संख्या के अपने जोड़ी अनूठा होगा सुरक्षित करेगा दिया जाता है की एक अच्छा विवरण। हालांकि, क्या यह सुनिश्चित करेगा कि मैप किए गए आईडी अद्वितीय और टकराव रहित हैं?

चलिए हाइलोनेट के HiLo के कार्यान्वयन को देखते हैं। एल्गोरिथ्म वे दिखाई देते हैं उपयोग करने के लिए (मैं क्या एकत्रित की हैं से के रूप में) है: (और मैं एक तकनीकी पर बंद हो सकता है)

h = high sequence (starting at 0) 
l_size = size of low block 
l = low sequence (starting at 1) 

ID = h*l_size + l 

इसलिए, यदि आपका कम ब्लॉक, है कहते हैं, 100, अपने आरक्षित आईडी अवरोधों 1-100, 101-200, 201-300, 301-400 ...

आपका उच्च अनुक्रम अब 3 है। अब क्या होगा यदि आप अचानक अपने l_size को 10 में बदल दें? आपका अगला ब्लॉक, आपका उच्च बढ़ाया गया है, और आपको 4*10+1 = 41

ओप्स मिलेगा। यह नया मान निश्चित रूप से 1-100 के "आरक्षित ब्लॉक" के भीतर आता है। 0 के उच्च अनुक्रम वाले किसी व्यक्ति को लगता है, "ठीक है, मेरे पास केवल 1-100 रेंज है जो मेरे लिए आरक्षित है, इसलिए मैं इसे 41 पर डाल दूंगा, क्योंकि मुझे पता है कि यह सुरक्षित है।"

आपके l_max को कम करते समय निश्चित रूप से टक्कर का एक बहुत ही उच्च अवसर है।

विपरीत मामले के बारे में क्या, इसे उठा रहा है?

हमारे उदाहरण पर वापस जाएं, आइए हम अपने l_size को 500 तक बढ़ाएं, अगली कुंजी को 4*500+1 = 2001 में बदल दें, 2001-2501 की सीमा को आरक्षित करें।

ऐसा लगता है कि हाइलो के इस विशेष कार्यान्वयन में टकराव से बचा जाएगा, जब आपके l_max को बढ़ा रहा है।

बेशक, आपको यह सुनिश्चित करने के लिए अपने स्वयं के कुछ परीक्षण करना चाहिए कि यह वास्तविक कार्यान्वयन है, या इसके करीब है। एक तरीका यह है कि l_max को 100 पर सेट करें और पहले कुछ कुंजियां पाएं, फिर इसे 500 पर सेट करें और अगला खोजें।यदि यहां उल्लेख की गई एक बड़ी छलांग है, तो आप सुरक्षित रहें।

हालांकि, मैं किसी भी सुझाव दिया कि यह एक मौजूदा डेटाबेस पर अपने l_max बढ़ाने के लिए सबसे अच्छा अभ्यास है भी तरह से नहीं कर रहा हूँ।

अपने विवेकाधिकार का प्रयोग करें; HiLo एल्गोरिदम बिल्कुल अलग-अलग l_max के साथ दिमाग में नहीं बनाया गया है, और अंत में आपके परिणाम आपके सटीक कार्यान्वयन के आधार पर अप्रत्याशित हो सकते हैं। हो सकता है कि कोई व्यक्ति जिसने अपने l_max को बढ़ाने और परेशानियों को ढूंढने का अनुभव किया हो, यह गिनती सही साबित कर सकती है।

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

लेकिन अगर आपकी किस्मत अच्छी है ...

+0

बहुत अच्छी तरह से, धन्यवाद! –

1

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

एक मौका है कि बढ़ने से टकराव नहीं होगा। लेकिन आपको या तो किसी ऐसे व्यक्ति से पूछने या पूछने की ज़रूरत है जो बेहतर जानता है तो मुझे यकीन है।

2

मैं एक साधारण helloWrold-ish हाइबरनेट आवेदन के माध्यम से हिलो algorith की behviour का पता लगाने की कोशिश की।

मैं साथ

<generator class="hilo"> 
<param name="table">HILO_TABLE</param> 
<param name="column">TEST_HILO</param> 
<param name="max_lo">40</param> 
</generator> 

"HILO_TABLE" नाम एकल स्तंभ "TEST_HILO" के साथ शुरू में मैं करने के लिए 8.

को

update HILO_TABLE set TEST_HILO=8; 
मैंने देखा TEST_HILO स्तंभ का मान सेट बनाया टेबल एक हाइबरनेट उदाहरण की कोशिश की आईडी बनाने के लिए यह पैटर्न

hivalue * lowvalue + hivalue 

hivalue col है डीबी में umn मूल्य (यानी HILO_TABLE से TEST_HILO चुनें) lowvalue config एक्सएमएल (40)

से है इसलिए इस मामले में आईडी से 8 * 40 + 8 = 328

शुरू कर दिया मेरी हाइबरनेट उदाहरण में मैं एक सत्र में 200 पंक्तियां गयी।

new hivalue in DB = inital value in DB + (rows_inserted/lowvalue + 1) 

= 8 + 200/40 = 8 + 5 = 13

-: तो पंक्तियों 527 करने और डीबी hivalue में आईडी 328 से बनाए गए थे 13. वेतन वृद्धि तर्क तक वृद्धि की गई थी प्रतीत हो रहा है

अब यदि मैं पंक्तियों को सम्मिलित करने के लिए एक ही हाइबरनेट प्रोग्राम चलाता हूं, तो आईडी 13 * 40 + 13 = 533

प्रोग्राम चलाते समय इसकी पुष्टि हुई थी।

3

रैखिक हिस्सा तालिका संभाजक देखें - यह तार्किक ही समस्या के लिए एक अधिक सरल & सही दृष्टिकोण है।

What's the Hi/Lo algorithm?

संख्या अंतरिक्ष & से पर्वतमाला आवंटन NEXT सीधे का प्रतिनिधित्व करने के बजाय उच्च शब्दों के साथ तर्क उलझी या संख्या गुणा करके, आप सीधे देख सकते हैं कि कुंजी उत्पन्न हो जा रहे हैं।

अनिवार्य रूप से, "रैखिक हिस्सा संभाजक" अलावा बजाय गुणा उपयोग करता है।यदि अगला 1000 & है तो हमने 20 का रेंज आकार कॉन्फ़िगर किया है, NEXT 1020 तक अग्रिम होगा और हम आवंटन के लिए 1000-1019 कुंजी रखेंगे।

रेंज आकार का किसी भी समय अखंडता के नुकसान के बिना ट्यून या पुन: कॉन्फ़िगर किया जा सकता है। आवंटक के अगले क्षेत्र के बीच सीधा संबंध है, तालिका में मौजूद उत्पन्न कुंजी & MAX (आईडी)।

(तुलनात्मक रूप से, "हाय-लो" का उपयोग करता गुणा। अगर अगले 50 & गुणक 20 है, तो आप 1000-1019 के आसपास कुंजी का आवंटन कर रहे हैं। अगले दोनों के बीच कोई सीधा संबंध, उत्पन्न कुंजी हैं & तालिका में MAX (आईडी), सुरक्षित रूप से आगे समायोजित करना मुश्किल है और गुणक को वर्तमान आवंटन बिंदु को परेशान किए बिना बदला नहीं जा सकता है।)

"रैखिक चंक" के साथ, आप कॉन्फ़िगर कर सकते हैं कि प्रत्येक श्रेणी/खंड कितनी बड़ी है है - 1 का आकार पारंपरिक टेबल-आधारित "एकल आवंटक" के बराबर है & प्रत्येक कुंजी उत्पन्न करने के लिए डेटाबेस को हिट करता है, 10 का आकार 10x तेज होता है क्योंकि यह एक बार में 10 की सीमा आवंटित करता है, 50 या 10 का आकार 0 अभी भी तेज है ..

65536 का आकार बदसूरत दिखने वाली चाबियाँ उत्पन्न करता है, सर्वर पुनरारंभ पर बड़ी संख्या में कुंजी बर्बाद करता है, और स्कॉट एम्बलर के मूल HI-LO एल्गोरिदम के बराबर है।

संक्षेप में, हाय-लो एक गलती से जटिल & अवधारणात्मक रूप से सरल रूप से सरल होना चाहिए - एक संख्या रेखा के साथ आवंटित श्रेणियों के लिए दोषपूर्ण दृष्टिकोण है।