हां। अक्सर हैश डाइजेस्ट को हेक्स अंकों के ASCII प्रतिनिधित्व के रूप में संग्रहीत किया जाता है, उदाहरण के लिए 'हैश' शब्द का MD5 है:
0800fc577294c34e0b28ad2839435945
यह 32-वर्ण की ASCII स्ट्रिंग है।
लेकिन MD5 वास्तव में 128-बिट बाइनरी हैश मान उत्पन्न करता है। यह चाहिए केवल 16 बाइट्स को हेक्स अंकों के बजाय बाइनरी मानों के रूप में संग्रहीत करने की आवश्यकता होती है। तो आप बाइनरी स्ट्रिंग्स का उपयोग करके कुछ स्थान दक्षता हासिल कर सकते हैं।
CREATE TABLE test.foobar (
id BINARY(16) NOT NULL PRIMARY KEY
);
INSERT INTO test.foobar (id) VALUES (UNHEX(MD5('hash')));
पुनः। आपकी टिप्पणियां कि आप अंतरिक्ष दक्षता की तुलना में प्रदर्शन के बारे में अधिक चिंतित हैं:
मैं किसी भी कारण से नहीं जानता कि BINARY डेटा प्रकार CHAR से तेज होगा।
यदि आप कैश बफ़र्स का प्रभावी ढंग से उपयोग करते हैं, तो आधा बड़ा होना प्रदर्शन के लिए एक लाभ हो सकता है। यही है, कैश मेमोरी की एक निश्चित मात्रा बाइनरी डेटा के लायक दो पंक्तियों को स्टोर कर सकती है यदि स्ट्रिंग हेक्स में समान मान को स्टोर करने के लिए आवश्यक CHAR के आकार का आधा है। इसी तरह उस कॉलम पर इंडेक्स के लिए कैश मेमोरी दोगुनी से ज्यादा स्टोर कर सकती है।
परिणाम एक अधिक प्रभावी कैश है, क्योंकि एक यादृच्छिक क्वेरी में डिस्क एक्सेस की आवश्यकता के बजाय कैश्ड डेटा या इंडेक्स को हिट करने की अधिक संभावना होती है। अधिकांश डेटाबेस अनुप्रयोगों के लिए कैश दक्षता महत्वपूर्ण है, क्योंकि आमतौर पर बाधा डिस्क I/O है। यदि आप डिस्क I/O की आवृत्ति को कम करने के लिए कैश मेमोरी का उपयोग कर सकते हैं, तो यह एक डेटा प्रकार या किसी अन्य के बीच चुनाव की तुलना में हिरन के लिए बहुत बड़ा धमाका है।
बाइनरी बनाम बिगिनट में संग्रहीत हैश स्ट्रिंग के बीच अंतर के लिए, मैं बिगिनट चुनूंगा। कैश दक्षता और भी अधिक होगी, और 64-बिट प्रोसेसर पर भी पूर्णांक अंकगणितीय और तुलना बहुत तेज़ होनी चाहिए।
मेरे पास उपरोक्त दावों का समर्थन करने के लिए माप नहीं है। एक डेटा प्रकार को दूसरे पर चुनने का शुद्ध लाभ आपके डेटाबेस और एप्लिकेशन में डेटा पैटर्न और प्रश्नों के प्रकार पर निर्भर करता है। सबसे सटीक उत्तर पाने के लिए, आपको दोनों समाधानों का प्रयास करना चाहिए और अंतर को मापना चाहिए।
पुनः। आपका अनुमान है कि बाइनरी स्ट्रिंग तुलना डिफ़ॉल्ट केस-असंवेदनशील स्ट्रिंग तुलना से तेज है, मैंने निम्नलिखित परीक्षण की कोशिश की:
mysql> SELECT BENCHMARK(100000000, 'foo' = 'FOO');
1 row in set (5.13 sec)
mysql> SELECT BENCHMARK(100000000, 'foo' = BINARY 'FOO');
1 row in set (4.23 sec)
तो बाइनरी स्ट्रिंग तुलना केस-असंवेदनशील स्ट्रिंग तुलना से 17.5% तेज है। लेकिन ध्यान दें कि इस अभिव्यक्ति का 100 मिलियन बार मूल्यांकन करने के बाद, कुल अंतर अभी भी 1 सेकंड से कम है। जबकि हम गति में सापेक्ष अंतर को माप सकते हैं, गति में पूर्ण अंतर वास्तव में महत्वहीन है।
तो मैं दोहराता हूँ:
- मापें, अनुमान न लगाएं या अनुमान न लगाएं। आपके शिक्षित अनुमान कई बार गलत होंगे। आपके द्वारा किए जाने वाले प्रत्येक परिवर्तन से पहले और बाद में मापें, ताकि आप जान सकें कि इससे कितनी मदद मिली।
- अपना समय और ध्यान वहीं लगाएं जहां आपको पैसे के लिए सबसे बड़ा धमाका मिले।
- छोटी-छोटी बातों पर पसीना न बहाएं। बेशक, एक छोटा अंतर पर्याप्त पुनरावृत्तियों के साथ जुड़ जाता है, लेकिन उन पुनरावृत्तियों को देखते हुए, अधिक पूर्ण लाभ के साथ एक प्रदर्शन सुधार अभी भी बेहतर है।
