निश्चित रूप से IP पतों को संख्याओं के रूप में सहेजें, यदि आपको अतिरिक्त काम करने में कोई आपत्ति नहीं है, खासकर यदि आपको पतों पर प्रश्न करने की आवश्यकता है और आपके पास बड़ी तालिकाएँ/संग्रह हैं।
ऐसा क्यों है:
संग्रहण
- यदि अहस्ताक्षरित पूर्णांक के रूप में संग्रहीत किया जाता है तो IPv4 पता 4 बाइट्स होता है।
- एक IPv4 पता 10 बाइट्स और 18 बाइट्स के बीच भिन्न होता है जब डॉटेड ऑक्टेड रूप में एक स्ट्रिंग के रूप में लिखा जाता है। (मान लें कि औसत 14 बाइट्स है।)
यह वर्णों के लिए 7-15 बाइट्स है, साथ ही 2-3 बाइट्स यदि आप एक चर लंबाई स्ट्रिंग प्रकार का उपयोग कर रहे हैं, जो आपके द्वारा उपयोग किए जा रहे डेटाबेस के आधार पर भिन्न होता है। यदि आपके पास एक निश्चित लंबाई वाली स्ट्रिंग प्रस्तुति उपलब्ध है, तो आपको 15-वर्ण निश्चित चौड़ाई वाले फ़ील्ड का उपयोग करना चाहिए।
डिस्क भंडारण सस्ता है, इसलिए अधिकांश उपयोग के मामलों में यह एक कारक नहीं है। मेमोरी, हालांकि, उतनी सस्ती नहीं है, और यदि आपके पास एक बड़ी टेबल/संग्रह है और आप तेजी से प्रश्न करना चाहते हैं, तो आपको एक अनुक्रमणिका की आवश्यकता है। स्ट्रिंग एन्कोडिंग का 2-3x स्टोरेज पेनल्टी काफी हद तक उन रिकॉर्ड्स की मात्रा को कम कर देता है जिन्हें आप इंडेक्स को मेमोरी में रखते हुए इंडेक्स कर सकते हैं।
- यदि एक अहस्ताक्षरित पूर्णांक के रूप में संग्रहीत किया जाता है तो एक IPv6 पता 16 बाइट्स होता है। (संभवतः आपके प्लेटफॉर्म के आधार पर कई 4 या 8 बाइट पूर्णांकों के रूप में।)
- संक्षिप्त हेक्स नोटेशन में एक स्ट्रिंग के रूप में एन्कोड किए जाने पर एक IPv6 पता 6 बाइट्स से 42 बाइट्स तक होता है।
निचले सिरे पर, एक लूप बैक एड्रेस (::1) 3 बाइट्स और चर लंबाई स्ट्रिंग ओवरहेड है। उच्च अंत में, एक पता जैसे 2002:4559:1FE2:1FE2:4559:1FE2:4559:1FE2 39 बाइट्स और चर लंबाई स्ट्रिंग ओवरहेड का उपयोग करता है।
IPv4 के विपरीत, यह मान लेना सुरक्षित नहीं है कि IPv6 स्ट्रिंग की औसत लंबाई 6 और 42 का माध्य होगी, क्योंकि महत्वपूर्ण संख्या में लगातार शून्य वाले पतों की संख्या समग्र IPv6 पता स्थान का एक बहुत छोटा अंश है। केवल कुछ विशेष पते, जैसे लूपबैक और ऑटोकॉन्फ़ पते, के इस तरह से संपीड़ित होने की संभावना है।
फिर से, यह स्ट्रिंग एन्कोडिंग बनाम पूर्णांक एन्कोडिंग के लिए>2x का संग्रहण दंड है।
नेटवर्क गणित
क्या आपको लगता है कि राउटर आईपी एड्रेस को स्ट्रिंग्स के रूप में स्टोर करते हैं? बेशक वे नहीं करते।
यदि आपको आईपी पते पर नेटवर्क गणित करने की आवश्यकता है, तो स्ट्रिंग प्रतिनिधित्व एक परेशानी है। उदा. यदि आप एक क्वेरी लिखना चाहते हैं जो एक विशिष्ट सबनेट पर सभी पतों की खोज करती है ("10.7.20.104/27 में एक आईपी पते के साथ सभी रिकॉर्ड लौटाएं", तो आप एक पूर्णांक सबनेट मास्क के साथ एक पूर्णांक पते को मास्क करके आसानी से ऐसा कर सकते हैं। ( Mongo इस विशेष क्वेरी का समर्थन नहीं करता है, लेकिन अधिकांश RDBMS करते हैं।) यदि आप पतों को स्ट्रिंग्स के रूप में संग्रहीत करते हैं, तो आपकी क्वेरी को प्रत्येक पंक्ति को एक पूर्णांक में बदलने की आवश्यकता होगी, फिर इसे मास्क करना होगा, जो परिमाण धीमी के कई क्रम है। (बिटवाइज मास्किंग IPv4 पते के लिए 2 रजिस्टरों का उपयोग करके कुछ CPU चक्रों में किया जा सकता है। एक स्ट्रिंग को पूर्णांक में बदलने के लिए स्ट्रिंग पर लूपिंग की आवश्यकता होती है।)
इसी तरह, पूर्णांक पतों के साथ श्रेणी क्वेरी ("192.168.1.50 और 192.168.50.100 के बीच सभी रिकॉर्ड सभी रिकॉर्ड लौटाएं") अनुक्रमणिका का उपयोग करने में सक्षम होंगी, जबकि स्ट्रिंग पतों पर श्रेणी क्वेरी नहीं होगी।
नीचे की रेखा
इसमें थोड़ा और काम लगता है, लेकिन ज्यादा नहीं (वहां एक लाख एटॉन() और एनटीओए() फ़ंक्शन हैं), लेकिन अगर आप कुछ गंभीर और ठोस बना रहे हैं और आप भविष्य की आवश्यकताओं के खिलाफ इसे भविष्य में प्रमाणित करना चाहते हैं और एक बड़े डेटासेट की संभावना, आपको IP पतों को पूर्णांक के रूप में संग्रहीत करना चाहिए, न कि स्ट्रिंग्स के रूप में।
यदि आप कुछ जल्दी और गंदा कर रहे हैं और भविष्य में रीमॉडेलिंग की संभावना पर ध्यान न दें, तो स्ट्रिंग्स का उपयोग करें।
ओपी के उद्देश्य के लिए, यदि आप गति और स्थान के लिए अनुकूलन कर रहे हैं और आपको नहीं लगता कि आप इसे अक्सर पूछना चाहते हैं, तो डेटाबेस का उपयोग क्यों करें? बस एक फाइल में आईपी एड्रेस प्रिंट करें। यह किसी डेटाबेस में संग्रहीत करने की तुलना में तेज़ और अधिक संग्रहण कुशल होगा (संबंधित API और संग्रहण ओवरहेड के साथ)।
