HyperLogLog का उपयोग कर कोड के लिए विश्वसनीय एकीकरण परीक्षण?

Question

हम ट्विटर के Algebird में HyperLogLog के कार्यान्वयन का उपयोग कर रहे हैं। हमारे सिस्टम में एक नंबर एन और एक चेक दिया गया है जो धीरे-धीरे बढ़ते संग्रह के वर्तमान आकार का अनुमान लगाने के लिए हाइपरलॉगॉग का उपयोग करता है और यदि यह एन से कम या कम है, तो हम इस जांच का परीक्षण करने वाले एकीकरण या सिस्टम परीक्षण को कैसे लिख सकते हैं और है पास करने की गारंटी है, अगर हाइपरलॉगॉग को कॉल करने वाला हमारा कोड सही है? परीक्षण के तहत प्रणाली गैर-निर्धारिती है, क्योंकि, एक बात के लिए, यह बहु-थ्रेडेड है।

मेरी पहली सोचा था सही तरीके से एकीकरण परीक्षण है जो उपयोग के इस मामले विश्वसनीय है लिखने के लिए "हमारे मानकों ड्रॉप" करने के लिए है। तो एक निश्चित बिंदु पर पोस्ट करने के लिए पर्याप्त संख्या में आइटम (एम) क्या है यह सुनिश्चित करने के लिए कि HyperLogLog अनुमानों के साथ एन से अधिक होने के रूप में आइटम की कुल संख्या का अनुमान लगाएगा, कहें,> = 0.9 99 999?

या क्या कोई बेहतर तरीका है?

मानक त्रुटि सीमाएं कॉन्फ़िगर करने योग्य हैं, लेकिन यह हमें सीधे अधिकतम त्रुटि सीमाएं नहीं बताती है जो हम संभवतः थोड़ी देर में देख सकते हैं - जो कि मैं यादृच्छिक असफल सीआई से बचने के लिए देखभाल करता हूं बर्बाद समय और बाल खींचने!

मैं भी चिंतित हैं कि जिस तरह से हम परीक्षण में यादृच्छिक डेटा उत्पन्न प्रासंगिक मायनों में समान रूप से वितरित यादृच्छिक डेटा है, जो वास्तव में संभावना गणना प्रभावित कर सकता है उत्पन्न नहीं हो सकता हूँ।

Answer 1

चलिए इसे थोड़ा सा तोड़ दें।

1. ट्विटर HyperLogLog कार्यान्वयन सही ढंग से करता है, यानी यह आइटम्स की संख्या का एक अच्छा अनुमान देता है: दो मुख्य व्यवहार आप परीक्षण के लिए देख रहे हैं।

2. आपका कोड लेने वाली HyperLogLog संरचनाओं (जैसे काउंटर) उन्हें जब उचित जुड़ जाता है।

ध्यान दें कि व्यवहार # 2 एकीकरण परीक्षण के बजाय इकाई परीक्षणों का उपयोग करके निर्माण समय पर परीक्षण करना आसान है। यह बेहतर है और ज्यादातर मुद्दों को पकड़ लेगा।

प्रकरण # 1 भी तीन मामलों में बांटा जा सकता है:

ए, जब आइटम्स की संख्या 0 है,

बी, मदों की संख्या छोटा है जब (5, 100, या 1000);

सी, जब वस्तुओं की संख्या बड़ी है (लाखों/अरब)।

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

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

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