ఒక సరళమైన డేటాబేస్ ట్రిక్ ఇమెయిల్ ప్రాసెసింగ్‌ను 18x వేగవంతం ఎలా చేసింది

ఇమెయిల్ సింక్ సమస్య

మీరు ఒక ఫైల్ నుండి డేటాబేస్‌కు ఇమెయిల్ చిరునామాలను సింక్ చేసే యాప్‌ను నిర్మిస్తున్నారని ఊహించుకోండి. మీ పని: ఫైల్‌లోని అన్ని ఇమెయిల్‌లను యాక్టివ్‌గా మార్చడం, డేటాబేస్‌లో ఉండి ఫైల్‌లో లేని ఇమెయిల్‌లను డియాక్టివేట్ చేయడం మరియు ఆడిటింగ్ కోసం ప్రతి మార్పు యొక్క రికార్డును ఉంచడం. ఇది సులభంగా అనిపిస్తుంది—కానీ మీరు 1,00,000 చిరునామాలతో వ్యవహరిస్తున్నప్పుడు, ఈ సులభమైన విధానం ఒక అడ్డంకిగా మారుతుంది.

Yaroslav Podorvanov అనే డెవలపర్ ఇటీవల ఈ సమస్యను పరిష్కరించడానికి 90 సెకన్ల సమయం పట్టిందని చెప్పారు—అతను PostgreSQL సాంకేతికతను ఉపయోగించి తిరిగి రాసేంత వరకు, అది ఆ సమయాన్ని కేవలం 5 సెకన్లకు తగ్గించింది. 8 జూలై 2026 నాటికి, ఈ విధానం అర్థం చేసుకోవడం చాలా విలువైనది, ఎందుకంటే ఇది డేటాబేస్‌లు ఎలా పనిచేస్తాయో ఒక ముఖ్యమైన విషయాన్ని తెలియజేస్తుంది: అసలైన ఖర్చు సంక్లిష్టమైన లెక్కింపు కాదు—అది మీ కోడ్ మరియు డేటాబేస్ మధ్య జరిగే సంభాషణ.

నెమ్మదిగా పనిచేసే వెర్షన్ ఎలా పనిచేసింది

అసలైన పరిష్కారం పనిని ప్రత్యేక దశలుగా విభజించింది:

1. ఫైల్ నుండి క్రొత్త ఇమెయిల్ చిరునామాలను చొప్పించడం లేదా నవీకరించడం
2. ఫైల్‌లో లేని ఇమెయిల్ చిరునామాలను డియాక్టివేట్ చేయడం
3. ఆడిటింగ్ కోసం ఒక హిస్టరీ టేబుల్‌లో ప్రతి మార్పును రికార్డ్ చేయడం

ప్రతి దశ దాని స్వంత డేటాబేస్ క్వెరీగా ఉండేది. అంటే కోడ్ ఇలా చేయాల్సి వచ్చింది:

• ఇమెయిల్ జాబితాను డేటాబేస్‌కు పంపడం
• సమాధానం కోసం వేచి ఉండటం
• మార్చబడిన వాటి IDs ని పొందడం
• ఆ IDs ని తిరిగి డేటాబేస్‌కు పంపడం
• మళ్ళీ వేచి ఉండటం
• డియాక్టివేషన్ కోసం మళ్ళీ పునరావృతం చేయడం
• హిస్టరీ రికార్డుల కోసం మళ్ళీ పునరావృతం చేయడం

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 కేసులో 18x వేగం పెంపు, ఇది డేటా ప్రవాహాన్ని పునర్నిర్మించడం ద్వారా మాత్రమే సాధించబడింది—డేటాబేస్ కష్టపడి పనిచేసేలా చేయడం ద్వారా కాదు, తెలివిగా పనిచేసేలా చేయడం ద్వారా.

ఇది ఎందుకు ముఖ్యం

ఇక్కడ నేర్చుకోవాల్సిన పాఠం వ్యతిరేకంగా అనిపించవచ్చు: డేటాబేస్‌లలో, రాకపోకల ఖర్చు (డేటాను ముందుకు వెనుకకు పంపడానికి వెచ్చించే సమయం) తరచుగా వాస్తవ గణన సమయం కంటే చాలా ఎక్కువగా ఉంటుంది. ఐదు ట్రిప్‌లను ఒకే ట్రిప్‌గా మార్చడం ద్వారా, Podorvanov కేవలం సమయాన్ని ఆదా చేయడమే కాకుండా—సర్వర్ లోడ్‌ను తగ్గించారు మరియు ఆపరేషన్‌ను మరింత అటామిక్‌గా చేశారు (అంతా విజయవంతమవుతుంది లేదా ఏదీ కాదు, మధ్యలో పాక్షిక స్థితి ఉండదు).

ఇది మాయాజాలం కాదు; ఇది ఎక్కడైనా వర్తించే సూత్రం: అనవసరమైన రాకపోకలను తగ్గించండి, అప్పుడు వ్యవస్థలు వేగవంతమవుతాయి. ఈ సాంకేతికత ఇమెయిల్ సింక్‌లు, బ్యాచ్ ఇంపోర్ట్‌లు లేదా బహుళ రీడ్ మరియు రైట్ ఆపరేషన్‌లను కలిపే ఏ ఆపరేషన్‌కైనా పనిచేస్తుంది.

ముగింపు

డేటాబేస్ ఆపరేషన్ నెమ్మదిగా అనిపించినప్పుడు, కారణం తరచుగా క్వెరీ మాత్రమే కాదు, మీరు ఎన్ని ప్రత్యేక క్వెరీలను నడుపుతున్నారు అనేదే. CTEలు బహుళ ఆపరేషన్‌లను ఒకే అటామిక్ దశగా మిళితం చేయడానికి మిమ్మల్ని అనుమతిస్తాయి, రాకపోకల సమయాన్ని తగ్గించి, త్రూపుట్‌ను గణనీయంగా మెరుగుపరుస్తాయి. ఇమెయిల్ సింకింగ్ లేదా బ్యాచ్ అప్‌లోడ్‌ల వంటి వర్క్‌లోడ్‌ల కోసం, ఇటువంటి ఆప్టిమైజేషన్ 90 సెకన్ల ఆపరేషన్‌కు మరియు 5 సెకన్ల ఆపరేషన్‌కు మధ్య తేడాను తెస్తుంది.

ప్రయోజనాలు

• డేటాబేస్ రాకపోకలను గణనీయంగా తగ్గిస్తుంది, ల్యాటెన్సీని తగ్గిస్తుంది
• డేటా స్థిరత్వాన్ని నిర్వహిస్తుంది—అన్ని మార్పులు ఒకే ట్రాన్సాక్షన్‌లో అటామిక్‌గా జరుగుతాయి
• అప్లికేషన్ కోడ్‌ను సరళీకృతం చేస్తుంది (తక్కువ వేర్వేరు ఫంక్షన్ కాల్‌లు)
• రేఖీయంగా స్కేల్ అవుతుంది; అదే క్వెరీ 10k లేదా 1M చిరునామాలకు పనిచేస్తుంది
• డేటాబేస్ బలాలను వ్యతిరేకించకుండా వాటిని సద్వినియోగం చేసుకుంటుంది

లోపాలు

• CTE సింటాక్స్ మరింత సంక్లిష్టమైనది మరియు డిబగ్ చేయడం కష్టం కావచ్చు
• అధునాతన SQL తో పరిచయం అవసరం—డేటాబేస్‌లకు కొత్తగా ఉన్న టీమ్‌లకు అంత అనుకూలంగా ఉండదు
• డేటాబేస్ లాగ్‌లు తక్కువ సూక్ష్మంగా ఉంటాయి (ఏ దశ నెమ్మదిగా ఉందో ఖచ్చితంగా చూడటం కష్టం)
• అన్ని డేటాబేస్‌లు CTEలకు ఒకేలా మద్దతు ఇవ్వవు
• ఓవర్‌హెడ్ పట్టింపు లేని చిన్న డేటాసెట్‌లకు ఇది అధికం కావచ్చు

హెచ్చరిక

ఈ వ్యాసం విద్యాపరమైనది మరియు వాస్తవ ప్రపంచ ఉదాహరణ నుండి తీసుకోబడింది. అటువంటి ఆప్టిమైజేషన్‌లను అమలు చేసేటప్పుడు, ప్లేస్‌హోల్డర్ విలువలను (లైక్ @file_id లేదా @now) మీ అప్లికేషన్‌లోని వాస్తవ వేరియబుల్స్‌తో భర్తీ చేయండి, మీ స్వంత డేటా పరిమాణంతో క్షుణ్ణంగా పరీక్షించండి మరియు ప్రొడక్షన్‌లో వాటిపై ఆధారపడే ముందు అసలు మూలానికి వ్యతిరేకంగా దావాలను సరిచూసుకోండి. డేటాబేస్ పనితీరు సందర్భంపై తీవ్రంగా ఆధారపడి ఉంటుంది; ఇక్కడ పనిచేసేది మీ నిర్దిష్ట స్కీమా, ఇండెక్స్‌లు మరియు హార్డ్‌వేర్ కోసం ట్యూనింగ్ అవసరం కావచ్చు.

తరచుగా అడిగే ప్రశ్నలు

• PostgreSQL లో CTE అంటే ఏమిటి మరియు ఇది క్వెరీ పనితీరును ఎలా మెరుగుపరుస్తుంది?
• ఇమెయిల్ సింకింగ్ కాకుండా ఇతర ఆపరేషన్‌లకు CTEలను ఉపయోగించవచ్చా?
• ఏదైనా తప్పు జరిగినప్పుడు CTE క్వెరీని డిబగ్ చేయడం ఎలా?
• CTE మరియు స్టోర్డ్ ప్రొసీజర్ మధ్య తేడా ఏమిటి?
• అన్ని SQL డేటాబేస్‌లు CTEలకు ఒకే విధంగా మద్దతు ఇస్తాయా?
• ప్రత్యేక క్వెరీలు చేయడానికి బదులుగా CTE ఎప్పుడు సరైన సాధనం?
• CTEలు ఇండెక్స్ వినియోగం మరియు క్వెరీ ప్లానింగ్‌ను ఎలా ప్రభావితం చేస్తాయి?
• CTE ఆపరేషన్ మధ్యలో విఫలమైతే ఏమి జరుగుతుంది?

ట్యాగ్‌లు

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