Soft delete की मुश्किलें

 (atlas9.dev)
23 पॉइंट द्वारा GN⁺ 2026-01-23 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • डेटा recovery और regulatory compliance के लिए archived_at कॉलम-आधारित soft delete अक्सर इस्तेमाल किया जाता है, लेकिन समय के साथ इसकी जटिलता और अक्षमता बढ़ती जाती है
  • यह तरीका query, index, migration, और restore logic को जटिल बनाता है, और क्योंकि ज़्यादातर archived data फिर कभी पढ़ा नहीं जाता, यह database पर अनावश्यक load डालता है
  • विकल्प के तौर पर application event-आधारित archiving, trigger-आधारित archiving, और WAL(Change Data Capture)-आधारित archiving सुझाए गए हैं
  • हर तरीके में operational complexity, infrastructure requirements, और restore की आसानी के मामले में अंतर है, और खास तौर पर WAL-आधारित तरीके में Kafka जैसे external systems के साथ integration की ज़रूरत होती है
  • नए प्रोजेक्ट के लिए trigger-आधारित approach को सरलता और maintainability के लिहाज़ से सबसे संतुलित विकल्प माना गया है

Soft delete की समस्याएँ

  • आम तौर पर डेटा को logical रूप से delete करने के लिए deleted boolean या archived_at timestamp कॉलम का इस्तेमाल किया जाता है
    • अगर ग्राहक ने गलती से डेटा delete कर दिया हो तो recovery संभव रहती है
    • कुछ मामलों में regulatory या audit purposes के लिए data retention भी ज़रूरी होता है
  • लेकिन archived_at कॉलम query, operations, और application code में व्यापक जटिलता पैदा करता है
    • archived data का बड़ा हिस्सा दोबारा पढ़ा ही नहीं जाता
    • API behavior की समस्याओं या automation tools (Terraform आदि) की वजह से लाखों अनावश्यक rows जमा हो सकती हैं
  • अगर archived data cleanup का काम configure न किया जाए तो database backup और restore के समय performance गिरती है
  • query और index में archived data को filter करना पड़ता है, और data leak का जोखिम रहता है
  • migration के दौरान पुराने data को handle करना या default values बदलना मुश्किल हो जाता है
  • restore logic जटिल हो जाता है, और जहाँ external system calls की ज़रूरत हो वहाँ bug आने की संभावना रहती है
  • नतीजतन archived_at तरीका ऊपर से सरल दिखता है, लेकिन लंबी अवधि में इसकी maintenance cost ज़्यादा होती है

Application level archiving

  • delete के समय event publish किया जाता है, उसे SQS में भेजा जाता है, और दूसरी service उसे S3 में archive करती है
  • फायदे
    • primary database और application code दोनों सरल हो जाते हैं
    • external resource cleanup को asynchronous processing के ज़रिए संभालकर performance और reliability बेहतर की जा सकती है
    • JSON के रूप में serialize करके application-friendly structure में archive किया जा सकता है
  • नुकसान
    • application code में bug होने पर archived data loss हो सकता है
    • message queue जैसी operational infrastructure complexity बढ़ती है
    • S3 में रखा archived data इस्तेमाल करने के लिए search और restore tools की ज़रूरत होती है

Trigger-आधारित archiving

  • delete से पहले trigger row को अलग archive table में JSON रूप में copy कर देता है
    • उदाहरण table: archive(id, table_name, record_id, data, archived_at, caused_by_table, caused_by_id)
  • foreign key delete(cascade) के समय delete के कारण को track करने के लिए session variables(archive.cause_table, archive.cause_id) का इस्तेमाल होता है
    • इससे यह पता लगाया जा सकता है कि किस parent record ने child data को delete किया
  • फायदे
    • live tables साफ-सुथरे रहते हैं, archived_at कॉलम की ज़रूरत नहीं रहती
    • archive table cleanup (WHERE archived_at < NOW() - INTERVAL '90 days') सरल होता है
    • query और index की efficiency बनी रहती है, और migration सरल हो जाती है
    • backup का आकार कम होता है
  • archive tables को अलग tablespace या time partitioning के साथ manage किया जा सकता है

WAL(Change Data Capture)-आधारित archiving

  • PostgreSQL के WAL logs को पढ़कर delete events को external systems तक stream किया जाता है
    • प्रमुख tool: Debezium (Kafka के साथ integration)
    • उदाहरण path: PostgreSQL → Debezium → Kafka → Consumer → Archive Storage
  • हल्के विकल्प
    • pgstream: WAL को सीधे webhook या message queue तक भेजता है
    • wal2json: WAL को JSON में output करता है
    • pg_recvlogical: PostgreSQL का built-in logical replication tool
  • operational complexity
    • Kafka-आधारित setup में monitoring, incident response, और tuning की ज़रूरत होती है
    • अगर consumer धीमा हो जाए तो WAL files जमा हो सकती हैं → disk space खत्म होने का जोखिम
    • PostgreSQL 13+ में max_slot_wal_keep_size setting से इसे सीमित किया जा सकता है
    • replication slot lag की monitoring और alerts अनिवार्य हैं
  • फायदे
    • application code बदले बिना सभी changes capture किए जा सकते हैं
    • कई destinations(S3, data warehouse, search index) तक stream किया जा सकता है
    • primary database पर अतिरिक्त load नहीं पड़ता
  • नुकसान
    • operational complexity और infrastructure cost अधिक होती है
    • consumer lag होने पर data loss या re-synchronization की ज़रूरत पड़ सकती है
    • schema changes के समय source और consumer के बीच coordination ज़रूरी होता है

Deletes को handle न करने वाले replica का विचार

  • DELETE queries को ignore करने वाले PostgreSQL replica को बनाए रखने का विचार रखा गया है
    • delete न हुआ सारा data लगातार जमा करके archive किया जा सकता है
    • archived data पर सीधे query चलाई जा सकती है
  • संभावित समस्याएँ
    • delete information को अलग से पहचानना मुश्किल हो सकता है
    • migrations लागू करते समय conflict का जोखिम
    • storage space और operational cost बढ़ना

निष्कर्ष

  • नए प्रोजेक्ट्स में trigger-आधारित archiving सबसे व्यावहारिक विकल्प है
    • इसे configure करना आसान है, और live tables साफ रहते हैं
    • अलग infrastructure के बिना भी archived data को देखना और manage करना आसान है
  • अगर जटिल infrastructure पहले से मौजूद हो या multiple destinations पर streaming चाहिए, तो WAL-आधारित approach अधिक उपयुक्त है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.