ஒரு எளிய தரவுத்தள தந்திரம் மின்னஞ்சல் செயலாக்கத்தை 18 மடங்கு வேகமாக எப்படி துரிதப்படுத்தியது

மின்னஞ்சல் ஒத்திசைவு சிக்கல்

ஒரு கோப்பிலிருந்து மின்னஞ்சல் முகவரிகளை ஒரு தரவுத்தளத்திற்கு ஒத்திசைக்கும் ஒரு பயன்பாட்டை நீங்கள் உருவாக்குகிறீர்கள் என்று வைத்துக்கொள்வோம். உங்கள் பணி: கோப்பில் உள்ள அனைத்து மின்னஞ்சல்களையும் செயலில் (active) எனக் குறிப்பது, தரவுத்தளத்தில் இருந்து கோப்பில் இல்லாத மின்னஞ்சல்களைச் செயலிழக்கச் செய்வது (deactivate), மற்றும் தணிக்கைக்காக ஒவ்வொரு மாற்றத்தையும் பதிவேடு செய்வது. இது எளிமையாகத் தோன்றலாம்—ஆனால் நீங்கள் 100,000 முகவரிகளுடன் செயல்படும் போது, இந்த நேரடி அணுகுமுறை ஒரு தடங்கலாக (bottleneck) மாறுகிறது.

Yaroslav Podorvanov என்ற உருவாக்குநர், இதே சிக்கலைத் தீர்ப்பதற்கு 90 வினாடிகள் எடுத்ததை—ஒரு PostgreSQL தொழில்நுட்பத்தைப் பயன்படுத்தி அதை வெறும் 5 வினாடிகளாகக் குறைக்கும் வரை எவ்வாறு இருந்தது என்பதை சமீபத்தில் பகிர்ந்துகொண்டார். 8 July 2026 அன்று, இந்த அணுகுமுறையைப் புரிந்துகொள்வது அவசியமானது, ஏனெனில் தரவுத்தளங்கள் எவ்வாறு செயல்படுகின்றன என்பது பற்றிய முக்கியமான ஒன்றை இது வெளிப்படுத்துகிறது: உண்மையான செலவு என்பது பொதுவாகக் கடினமான வேலை அல்ல—உங்கள் குறியீட்டிற்கும் தரவுத்தளத்திற்கும் இடையே நடக்கும் உரையாடல்தான்.

மெதுவான பதிப்பு எவ்வாறு செயல்பட்டது

அசல் தீர்வு வேலையை தனித்தனி படிகளாகப் பிரித்தது:

1. கோப்பிலிருந்து புதிய மின்னஞ்சல் முகவரிகளைச் செருகுவது அல்லது புதுப்பிப்பது
2. கோப்பில் இல்லாத மின்னஞ்சல் முகவரிகளைச் செயலிழக்கச் செய்வது
3. தணிக்கைக்காக ஒவ்வொரு மாற்றத்தையும் ஒரு வரலாறு அட்டவணையில் பதிவு செய்வது

ஒவ்வொரு படியும் அதற்கெனத் தனி தரவுத்தள வினவலாக இருந்தது. இதன் பொருள் குறியீடு பின்வருவனவற்றைச் செய்ய வேண்டியிருந்தது:

• மின்னஞ்சல் பட்டியலைத் தரவுத்தளத்திற்கு அனுப்புதல்
• பதிலுக்காகக் காத்திருத்தல்
• மாற்றமடைந்தவற்றின் ID-களைப் பெறுதல்
• அந்த ID-களை மீண்டும் தரவுத்தளத்திற்கு அனுப்புதல்
• மீண்டும் காத்திருத்தல்
• செயலிழக்கச் செய்வதற்காக மீண்டும் தொடருதல்
• வரலாறு பதிவுகளுக்காக மீண்டும் தொடருதல்

100,000 முகவரிகளுடன், அந்த அனைத்துக் காத்திருப்புகளும் சேர்ந்து மொத்தம்: 90 வினாடிகள் ஆயின.

CTE தீர்வு

ஒரு Common Table Expression (CTE) என்பது ஒரு சிக்கலான வினவலைப் பெயரிடப்பட்ட, மீண்டும் பயன்படுத்தக்கூடிய கூறுகளாகப் பிரிக்க PostgreSQL வழங்கும் ஒரு வழியாகும்—அவை அனைத்தும் ஒரே தரவுத்தள செயல்பாட்டிற்குள் நடக்கும். தரவுத்தளத்திற்கு ஐந்து தனித்தனி பயணங்களை மேற்கொள்வதற்குப் பதிலாக, Podorvanov எல்லாவற்றையும் ஒரே வினவலுக்கு மாற்றினார்:

WITH
  data (email) AS (
    SELECT UNNEST(@emails::VARCHAR[])
  ),
  deactivated (id) AS (
    UPDATE rtt_emails
    SET active = FALSE, updated_at = @now::TIMESTAMP
    WHERE email NOT IN (SELECT email FROM data)
    AND active = TRUE
    RETURNING id
  ),
  activated (id) AS (
    INSERT INTO rtt_emails (email, active, created_at, updated_at)
    SELECT email, TRUE, @now::TIMESTAMP, @now::TIMESTAMP
    FROM data
    ON CONFLICT (email) DO UPDATE
    SET active = EXCLUDED.active, updated_at = EXCLUDED.updated_at
    WHERE rtt_emails.active IS DISTINCT FROM EXCLUDED.active
    RETURNING id
  ),
  deactivated_history AS (
    INSERT INTO rtt_email_history (email_id, active, file_id, created_at)
    SELECT id, FALSE, @file_id::BIGINT, @now::TIMESTAMP
    FROM deactivated
  ),
  activated_history AS (
    INSERT INTO rtt_email_history (email_id, active, file_id, created_at)
    SELECT id, TRUE, @file_id::BIGINT, @now::TIMESTAMP
    FROM activated
  )
SELECT
  (SELECT COUNT(*) FROM activated) AS activated_count,
  (SELECT COUNT(*) FROM deactivated) AS deactivated_count;

சிக்கலானதாகத் தோன்றுவது உண்மையில் தனித்தனி வினவல்கள் செய்த வேலையைத்தான் செய்கிறது—ஆனால் அனைத்தும் தரவுத்தளத்துடனான ஒரே உரையாடலில் நடைபெறுகிறது. CTE பகுதிகளை ஒன்றிணைக்கிறது: உள்வரும் தரவு செயல்படுத்துதல் படிக்குச் செல்கிறது, அது வரலாற்றுப் படிக்குச் செல்கிறது, மேலும் பல.

வேக அதிகரிப்பு

முடிவுகளே உண்மைநிலையைத் தெளிவுபடுத்துகின்றன:

• 10,000 முகவரிகள்: ~5 வினாடிகள் (மெதுவான பதிப்பு) → ~3 வினாடிகள் (CTE)
• 100,000 முகவரிகள்: ~90 வினாடிகள் (மெதுவான பதிப்பு) → ~5 வினாடிகள் (CTE)
• 1 மில்லியன் முகவரிகள்: ~30 வினாடிகள் (CTE)

இது 100k நிகழ்வில் 18 மடங்கு வேக அதிகரிப்பாகும், இது தரவு பாயும் முறையை மறுசீரமைப்பதன் மூலம் மட்டுமே சாத்தியமானது—தரவுத்தளத்தைக் கடினமாக உழைக்க வைப்பதன் மூலம் அல்ல, மாறாக அதைச் புத்திசாலித்தனமாகச் செயல்பட வைப்பதன் மூலம்.

இது ஏன் முக்கியமானது

இங்குள்ள பாடம் இயல்புக்கு மாறானதாகத் தோன்றலாம்: தரவுத்தளங்களில், சுழற்சி நேரச் செலவு (தரவை முன்னும் பின்னுமாக அனுப்ப செலவிடும் நேரம்) பெரும்பாலும் உண்மையான கணக்கீட்டை விட மிக அதிகமாக இருக்கும். ஐந்து பயணங்களை ஒன்றாக ஒருங்கிணைப்பதன் மூலம், Podorvanov நேரத்தை மட்டும் சேமிக்கவில்லை—அவர் சேவையகத்தின் சுமையையும் குறைத்து, செயல்பாட்டை மேலும் அணுத்தன்மையானதாக (atomic) மாற்றினார் (எல்லாம் வெற்றிபெறும் அல்லது எதுவுமே வெற்றியடையாது, இடையே பகுதி நிலைகள் இருக்காது).

இது மந்திரம் அல்ல; இது எங்கும் பொருந்தக்கூடிய ஒரு கொள்கை: தேவையில்லாத முன்னும் பின்னுமான தொடர்பைக் குறைத்தால், அமைப்புகள் வேகமடைகின்றன. இந்த உத்தி மின்னஞ்சல் ஒத்திசைவுகள், தொகுதி இறக்குமதிகள் (batch imports), அல்லது பல வாசிப்பு மற்றும் எழுதுதல்களை ஒன்றிணைக்கும் எந்தவொரு செயல்பாட்டிற்கும் செயல்படும்.

முடிவுரை

ஒரு தரவுத்தள செயல்பாடு மெதுவாக இருப்பதாகத் தோன்றும் போது, காரணம் பொதுவாக வினவல் மட்டுமே அல்ல, மாறாக நீங்கள் எத்தனை தனித்தனி வினவல்களை இயக்கிக் கொண்டிருக்கிறீர்கள் என்பதே ஆகும். CTEகள் பல செயல்பாடுகளை ஒரே அணு நிலைப் படியாக ஒருங்கிணைக்க உங்களை அனுமதிக்கின்றன, இதனால் சுழற்சி நேரச் சுமையைக் கணிசமாகக் குறைத்து, செயல்திறனை வெகுவாக மேம்படுத்துகின்றன. மின்னஞ்சல் ஒத்திசைவு அல்லது தொகுதிப் பதிவேற்றங்கள் (batch uploads) போன்ற பணிச்சுமைகளுக்கு, இந்த வகையான மேம்படுத்தல் 90 வினாடி செயல்பாட்டிற்கும் 5 வினாடி செயல்பாட்டிற்கும் இடையிலான வித்தியாசமாக இருக்கும்.

நன்மைகள்

• தரவுத்தளச் சுழற்சிப் பயணங்களை (round-trips) கணிசமாகக் குறைத்து, தாமதத்தைக் (latency) குறைக்கிறது
• தரவு நிலைத்தன்மையைப் பராமரிக்கிறது—அனைத்து மாற்றங்களும் ஒரே பரிவர்த்தனையில் அணுத்தன்மையுடன் (atomically) நிகழ்கின்றன
• பயன்பாட்டுக் குறியீட்டைச் சீராக்குகிறது (குறைவான தனிச் சார்பு அழைப்புகள்)
• நேர்கோட்டில் அளவிடக்கூடியது; 10k அல்லது 1M முகவரிகளுக்கும் அதே வினவல் செயல்படும்
• தரவுத்தள வலிமைகளை எதிர்ப்பதற்குப் பதிலாக அவற்றைப் சாதகமாகப் பயன்படுத்துகிறது

குறைபாடுகள்

• CTE தொடரியல் (syntax) மிகவும் சிக்கலானது மற்றும் பிழைதிருத்தம் (debug) செய்வது கடினமாக இருக்கலாம்
• மேம்பட்ட SQL அறிவின் தேவை உள்ளது—தரவுத்தளங்களுக்குப் புதிய குழுக்களுக்கு இது ஏற்றதல்ல
• தரவுத்தள பதிவுகள் (logs) துல்லியமாகக் கிடைக்காது (எந்தப் படி மெதுவாக இருந்தது என்பதைக் காண்பது கடினம்)
• அனைத்து தரவுத்தளங்களும் CTEகளை ஒரே மாதிரியாக சிறப்பாக ஆதரிப்பதில்லை
• கூடுதல் சுமை பொருட்படுத்தப்படாத சிறிய தரவுத்தொகுப்புகளுக்கு இது அதிகப்படியான ஒன்றாக (overkill) இருக்கலாம்

எச்சரிக்கை

இந்தக் கட்டுரை கல்வி நோக்கிலானது மற்றும் நிஜ உலக உதாரணத்திலிருந்து பெறப்பட்டது. இதுபோன்ற மேம்பாடுகளை அமல்படுத்தும் போது, ஒதுக்கிட மதிப்புகளை (@file_id அல்லது @now போன்றவை) உங்கள் பயன்பாட்டிலிருந்து உண்மையான மாறிகளால் மாற்றவும், உங்கள் சொந்த தரவு அளவோடு முழுமையாகப் பரிசோதிக்கவும், உற்பத்தியில் (production) இவற்றை நம்புவதற்கு முன் அசல் மூலத்திலிருந்து கூற்றுகளைச் சரிபார்க்கவும். தரவுத்தளத்தின் செயல்திறன் சூழலைச் சார்ந்தது; இங்கு செயல்படுவது உங்கள் குறிப்பிட்ட திட்டம் (schema), குறியீடுகள் (indexes), மற்றும் வன்பொருளுக்கு (hardware) ஏற்ப மாற்றியமைக்கப்பட வேண்டியிருக்கலாம்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

• PostgreSQL இல் CTE என்றால் என்ன, அது வினவலின் செயல்திறனை எவ்வாறு மேம்படுத்துகிறது?
• மின்னஞ்சல் ஒத்திசைவு தவிர மற்ற செயல்பாடுகளுக்கு CTEகளைப் பயன்படுத்த முடியுமா?
• ஏதேனும் தவறு நடக்கும்போது ஒரு CTE வினவலை எவ்வாறு பிழைதிருத்தம் (debug) செய்வது?
• ஒரு CTE-க்கும் ஒரு சேமிக்கப்பட்ட நடைமுறைக்கும் (stored procedure) இடையே உள்ள வித்தியாசம் என்ன?
• அனைத்து SQL தரவுத்தளங்களும் CTEகளை ஒரே மாதிரியாக ஆதரிக்கின்றனவா?
• தனித்தனி வினவல்களை உருவாக்குவதை விட CTE எப்போது சரியான கருவியாக இருக்கும்?
• CTEகள் குறியீட்டு பயன்பாடு (index usage) மற்றும் வினவல் திட்டமிடுதலை (query planning) எவ்வாறு பாதிக்கின்றன?
• ஒரு CTE செயல்பாடு பாதியில் தோல்வியடைந்தால் என்ன நடக்கும்?

குறிச்சொற்கள்

#postgres #database #performance #cte #sql #optimization #batch-processing #postgresql