आपके सभी प्रश्नों को पढ़ने के बाद ( अद्वितीय बाधा हैश को बेकार कर देती है? , 512 बिट हैश बनाम 4 128bit हैश और url टेक्स्ट कम्प्रेशन (छोटा नहीं करना) ) और mysql में स्टोर करना ), मैं समझ गया कि आपकी समस्या कमोबेश निम्न है:
क्या यही है?
निम्नलिखित बिंदु महत्वपूर्ण हैं:आपके द्वारा सहेजे जाने वाले URL का प्रारूप कैसा है? क्या आपको URL को वापस पढ़ना होगा, या इसके बारे में केवल जानकारी अपडेट करनी होगी, लेकिन कभी भी आंशिक URL आदि के आधार पर खोज नहीं करनी होगी?
मान लें कि URL ="http://www.somesite.com.tv/images/Picture01 .jpg " और यह कि आप फ़ाइल नाम सहित सब कुछ संग्रहीत करना चाहते हैं। यदि यह भिन्न है, तो कृपया अधिक विवरण प्रदान करें या मेरी उत्तर धारणाओं को सही करें ।
-
यदि URL में वर्णों के कुछ समूह को बदलकर स्थान बचा सकते हैं। यूआरएल में सभी ASCII वर्ण मान्य नहीं हैं, जैसा कि आप यहां देख सकते हैं:RFC1738 , ताकि आप URL का प्रतिनिधित्व (और संपीड़ित) करने के लिए उनका उपयोग कर सकें। उदाहरण के लिए:"http://" का प्रतिनिधित्व करने के लिए वर्ण 0x81 का उपयोग करने से आप 6 वर्ण सहेज सकते हैं, 0x82 ".jpg" का प्रतिनिधित्व करने के लिए आप अन्य 3 बाइट्स बचा सकते हैं, आदि।
-
कुछ शब्द बहुत सामान्य हो सकते हैं (जैसे "छवि", "चित्र", "वीडियो", "उपयोगकर्ता")। यदि आप ऐसे शब्दों को एन्कोड करने के लिए 0x90 से 0x9f + किसी अन्य वर्ण (इसलिए, 0x90 0x01, 0x90 0x02, 0x90 0xfa) का उपयोगकर्ता वर्ण चुनते हैं, तो आपके पास सबसे अधिक उपयोग किए जाने वाले शब्दों को एन्कोड करने के लिए 16 * 256 =4,096 "शब्दकोश प्रविष्टियां" हो सकती हैं। आप 4 - 8 वर्णों का प्रतिनिधित्व करने के लिए 2 बाइट्स का उपयोग करेंगे।
संपादित करें: जैसा कि आप ऊपर उल्लिखित RFC में पढ़ सकते हैं, URL में आपके पास केवल मुद्रण योग्य ASCII वर्ण हो सकते हैं। इसका मतलब है कि केवल 0x20 से 0x7F वर्णों का उपयोग किया जाना चाहिए, RFC में कुछ अवलोकन किए गए हैं। इसलिए, 0x80 के बाद किसी भी वर्ण (हेक्साडेसिमल नोटेशन, ASCII तालिका में वर्ण 128 दशमलव होगा) का उपयोग नहीं किया जाना चाहिए। इसलिए, यदि एक वर्ण का चयन कर सकते हैं (मान लें कि 0x90) एक ध्वज होने के लिए "निम्न बाइट शब्दकोश में एक संकेत है, जो सूचकांक मैं उपयोग करूंगा"। एक वर्ण (0x90) * 256 वर्ण (0x00 0xFF तक) =शब्दकोश में 256 प्रविष्टियाँ। लेकिन आप 0x90 से 0x9f (या दशमलव में 144 से 159) वर्णों का उपयोग करना चुन सकते हैं ताकि यह इंगित किया जा सके कि वे शब्दकोश के लिए एक ध्वज हैं, इस प्रकार आपको 16 *256 संभावनाएं प्रदान करते हैं...
ये 2 विधियां आपके डेटाबेस में बहुत सी जगह बचा सकती हैं और टकराव आदि के बारे में चिंता किए बिना प्रतिवर्ती हैं। आप आसानी से अपने आवेदन में एक शब्दकोश बना सकते हैं और इसका उपयोग करके यूआरएल को एन्कोड/डीकोड कर सकते हैं, बहुत तेजी से, बनाना आपका डेटाबेस बहुत हल्का है।
चूँकि आपके पास पहले से ही +50M URL हैं, आप एक बेहतर शब्दकोश बनाने के लिए उनके आधार पर आँकड़े उत्पन्न कर सकते हैं।
हैश का उपयोग करना :हैश, इस मामले में, आकार और सुरक्षा के बीच एक समझौता है। अगर आपको टक्कर लग जाए तो कितना बुरा होगा?और इस मामले में आप जन्मदिन विरोधाभास आपकी मदद करने के लिए।
समस्या को समझने के लिए लेख पढ़ें:यदि सभी इनपुट (URL में संभावित वर्ण) समान थे, तो आप टकराव की संभावना का अनुमान लगा सकते हैं। और इसके विपरीत की गणना कर सकते हैं:आपकी स्वीकार्य टक्कर की संभावना, और आपकी फाइलों की संख्या को देखते हुए, आपकी सीमा कितनी व्यापक होनी चाहिए? और चूंकि आपकी सीमा हैश फ़ंक्शन द्वारा उत्पन्न बिट्स की संख्या से बिल्कुल संबंधित है...
संपादित करें: यदि आपके पास हैश फ़ंक्शन है जो आपको 128 बिट देता है, तो आपके पास 2^128 संभावित परिणाम होंगे। तो, जन्मदिन विरोधाभास में आपकी "सीमा" 2^128 है:यह ऐसा है जैसे आपके वर्ष में 365 के बजाय 2^128 दिन हैं। इसलिए, आप टकराव की संभावनाओं की गणना करते हैं ("दो फ़ाइलें जन्म . होना उसी दिन, वर्ष . के साथ जिसमें 2^128 दिन हों 365 दिनों के बजाय)। यदि आप एक हैश का उपयोग करना चुनते हैं जो आपको 512 बिट देता है, तो आपकी सीमा 0 से 2^512 तक होगी...
और, फिर से, आरएफसी को ध्यान में रखें:सभी बाइट्स (256 वर्ण) इंटरनेट/यूआरएल दुनिया में मान्य नहीं हैं। तो, टकराव की संभावना कम हो जाती है। आपके लिए बेहतर :)।
