Django में "हटाना" ऑब्जेक्ट

जल्दी या बाद में, डेवलपर्स अनावश्यक डेटा को हटाने के कार्य का सामना करते हैं। और सेवा जितनी जटिल होगी, उतनी ही बारीकियों पर आपको विचार करना होगा। इस लेख में, मैं वर्णन करूंगा कि हमने सैकड़ों लिंक वाले डेटाबेस में "विलोपन" कैसे लागू किया।

प्रागितिहास

अधिकांश परियोजनाओं के संचालन की निगरानी के लिए, Mail.ru Group और VKontakte अपने स्वयं के विकास की एक सेवा का उपयोग करते हैं - निगरानी । 2012 के अंत से अपने इतिहास को शुरू करते हुए, 6 वर्षों में यह परियोजना एक विशाल प्रणाली में विकसित हुई है, जिसने बहुत अधिक कार्यक्षमता प्राप्त की है। मॉनिटरिंग नियमित रूप से सर्वरों की उपलब्धता और अनुरोधों की प्रतिक्रियाओं की शुद्धता की जांच करती है, उपयोग की गई मेमोरी, सीपीयू उपयोग आदि पर आंकड़े एकत्र करती है। जब मॉनिटर किए गए सर्वर के पैरामीटर अनुमेय मूल्यों से अधिक हो जाते हैं, तो सर्वर के लिए जिम्मेदार लोग सिस्टम और एसएमएस द्वारा सूचनाएं प्राप्त करते हैं।

सर्वर प्रदर्शन की गतिशीलता को ट्रैक करने के लिए सभी जांच और घटनाएं लॉग की जाती हैं, इसलिए डेटाबेस सैकड़ों लाखों रिकॉर्ड के क्रम तक पहुंच गया है। नए सर्वर समय-समय पर दिखाई देते हैं, और पुराने उपयोग के लिए बंद हो जाते हैं। अप्रयुक्त सर्वर के बारे में जानकारी को मॉनिटरिंग सिस्टम से हटाया जाना चाहिए: क) अनावश्यक जानकारी के साथ इंटरफेस को अधिभार न डालें, और ख) अद्वितीय पहचानकर्ता जारी करें ।

निष्कासन

मैं जानबूझकर लेख के शीर्षक में "चिह्न" शब्द को उद्धरण चिह्नों में लिखा था। किसी ऑब्जेक्ट को सिस्टम से निकालने के कई तरीके हैं:

• डेटाबेस से पूरी तरह से हटा दिया गया;
• हटाए गए के रूप में वस्तुओं को चिह्नित करना और इंटरफ़ेस से छिपाना। एक मार्कर के रूप में, आप अधिक सटीक लॉगिंग के लिए बूलियन, या डेटाइम का उपयोग कर सकते हैं।

Iteration # 1

प्रारंभ में, पहले दृष्टिकोण का उपयोग किया गया था, जब हमने बस object.delete() निष्पादित किया था और ऑब्जेक्ट को सभी निर्भरताओं के साथ हटा दिया गया था। लेकिन समय के साथ, हमें इस दृष्टिकोण को छोड़ना पड़ा, क्योंकि एक वस्तु में लाखों अन्य वस्तुओं के साथ निर्भरता हो सकती है, और विलोपन हटाकर कठोर रूप से अवरुद्ध तालिकाओं के साथ। और चूंकि सेवा प्रत्येक सेकंड में हजारों चेक करती है और उन्हें लॉग करती है, इसलिए तालिकाओं को अवरुद्ध करने से सेवा में एक गंभीर मंदी आई, जो हमारे लिए अस्वीकार्य थी।

Iteration # 2

लंबे ताले से बचने के लिए, हमने बैचों में डेटा को हटाने का फैसला किया। यह वस्तुओं के विलोपन के बीच अंतराल में वास्तविक निगरानी डेटा रिकॉर्ड करने की अनुमति देगा। सभी वस्तुओं की एक सूची जो कैस्केड में हटा दी जाएगी, वह विधि द्वारा उपयोग की जा सकती है जो किसी ऑब्जेक्ट को हटाने के दौरान व्यवस्थापक पैनल में उपयोग की जाती है (जब हटाने की पुष्टि होती है):

 from django.contrib.admin.util import NestedObjects from django.db import DEFAULT_DB_ALIAS collector = NestedObjects(using=DEFAULT_DB_ALIAS) collector.collect([obj]) objects_to_delete = collector.nested() # Recursive delete objects 

स्थिति में सुधार हुआ: समय के साथ भार वितरित किया गया, नया डेटा तेजी से दर्ज किया जाने लगा। लेकिन हम तुरंत अगले नुकसान में भाग गए। तथ्य यह है कि हटाए जाने वाली वस्तुओं की सूची को हटाने की शुरुआत में बनाई जाती है, और यदि "आंशिक" हटाने की प्रक्रिया में नई निर्भर वस्तुओं को जोड़ा जाता है, तो मूल तत्व को हटाया नहीं जा सकता है।

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

Iteration # 3

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

फिर हमने क्वेरी मैनेजर को ओवरराइड करने के लिए डेकोरेटर्स का उपयोग करने का निर्णय लिया। आगे सौ शब्दों को लिखने की तुलना में कोड को देखना बेहतर है।

 def exclude_objects_for_deleted_hosts(*fields): """ Decorator that adds .exclude({field__}is_deleted=True) for model_class.objects.get_queryset :param fields: fields for exclude condition """ def wrapper(model_class): def apply_filters(qs): for field in filter_fields: qs = qs.exclude(**{ '{}is_deleted'.format('{}__'.format(field) if field else ''): True, }) return qs model_class.all_objects = copy.deepcopy(model_class.objects) filter_fields = set(fields) get_queryset = model_class.objects.get_queryset model_class.objects.get_queryset = lambda: apply_filters(get_queryset()) # save info about model decorator setattr(model_class, DECORATOR_DEL_HOST_ATTRIBUTE, filter_fields) return model_class return wrapper 

फ़ील्ड मॉडल के निर्दिष्ट क्षेत्रों के लिए exclude_objects_for_deleted_hosts(fields) डेकोरेटर स्वचालित रूप से प्रत्येक अनुरोध के लिए एक exclude फ़िल्टर जोड़ता है, जो केवल उन प्रविष्टियों को हटाता है जिन्हें इंटरफ़ेस में प्रदर्शित नहीं किया जाना चाहिए।

अब यह सभी मॉडलों के लिए पर्याप्त है जो किसी डेकोरेटर को जोड़ने के लिए डिलीट करने से किसी तरह से प्रभावित होंगे:

 @exclude_objects_for_deleted_hosts('host') class Alias(models.Model): host = models.ForeignKey(to=Host, verbose_name='Host', related_name='alias') 

अब, Host ऑब्जेक्ट को हटाने के लिए, बस is_deleted विशेषता बदलें:

 host.is_deleted = True # after this save the host and all related objects will be inaccessible host.save() 

सभी प्रश्न स्वचालित रूप से उन रिकॉर्ड को बाहर कर देंगे जो दूरस्थ वस्तुओं को संदर्भित करते हैं:

 # model decorator @exclude_objects_for_deleted_hosts('checker__monhost', 'alias__host') CheckerToAlias.objects.filter( alias__hostname__in=['cloud.spb.s', 'cloud.msk.s'] ).values('id') 

यह निम्नलिखित एसक्यूएल क्वेरी को पूरा करता है:

 SELECT monitoring_checkertoalias.id FROM monitoring_checkertoalias INNER JOIN monitoring_checker ON (`monitoring_checkertoalias`.`checker_id` = monitoring_checker.`id`) INNER JOIN Hosts ON (`monitoring_checker`.`monhost_id` = Hosts.`id`) INNER JOIN dcmap_alias ON (`monitoring_checkertoalias`.`alias_id` = dcmap_alias.`id`) INNER JOIN Hosts T5 ON (`dcmap_alias`.`host_id` = T5.`id`) WHERE ( NOT (`Hosts`.`is_deleted` = TRUE) -- ,   monitoring_checker AND NOT (T5.`is_deleted` = TRUE) -- ,   dcmap_alias AND dcmap_alias.name IN ('dir1.server.p', 'dir2.server.p') ); 

जैसा कि आप देख सकते हैं, डेकोरेटर में निर्दिष्ट फ़ील्ड्स के लिए अतिरिक्त `is_deleted` = TRUE और `is_deleted` = TRUE चेक को अनुरोध `is_deleted` = TRUE जोड़ा गया है।

संख्याओं के बारे में थोड़ा

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

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

विशिष्ट पहचानकर्ता

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

 host.hostname = '{}_{}'.format(host.hostname, uuid.uuid4()) host.is_deleted = True host.save() 

शोषण

प्रत्येक नए मॉडल या निर्भरता के लिए, यदि आवश्यक हो तो डेकोरेटर को अपडेट किया जाना चाहिए। आश्रित मॉडल की खोज को आसान बनाने के लिए, हमने "स्मार्ट" टेस्ट लिखा:

 def test_deleted_host_decorator_for_models(self): def recursive_host_finder(model, cache, path, filters): # cache for skipping looked models cache.add(model) # process all related models for field in (f for f in model._meta.fields if isinstance(f, ForeignKey)): if field.related_model == Host: filters.add(path + field.name) elif field.related_model not in cache: recursive_host_finder(field.related_model, cache.copy(), path + field.name + '__', filters) # check all models for current_model in apps.get_models(): model_filters = getattr(current_model, DECORATOR_DEL_HOST_ATTRIBUTE, set()) found_filters = set() if current_model == Host: found_filters.add('') else: recursive_host_finder(current_model, set(), '', found_filters) if found_filters or model_filters: try: self.assertSetEqual(model_filters, found_filters) except AssertionError as err: err.args = ( '{}\n !!! Fix decorator "exclude_objects_for_deleted_hosts" ' 'for model {}'.format(err.args[0], current_model), ) raise err 

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

उपसंहार

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