ଗୋଟିଏ ସରଳ ଡାଟାବେସ୍ ଟ୍ରିକ୍ କିପରି ଇମେଲ୍ ପ୍ରୋସେସିଂକୁ ୧୮ ଗୁଣ ଦ୍ରୁତ କଲା

ଇମେଲ୍ ସିଙ୍କ୍ ସମସ୍ୟା

କଳ୍ପନା କରନ୍ତୁ ଆପଣ ଏପରି ଏକ ଆପ୍ ତିଆରି କରୁଛନ୍ତି ଯାହା ଏକ ଫାଇଲରୁ ଡାଟାବେସକୁ ଇମେଲ୍ ଠିକଣା ସିଙ୍କ୍ କରେ। ଆପଣଙ୍କର କାମ: ଫାଇଲରେ ଥିବା ସମସ୍ତ ଇମେଲକୁ ସକ୍ରିୟ ଭାବରେ ଚିହ୍ନିତ କରିବା, ଡାଟାବେସରେ ଥିବା କିନ୍ତୁ ଫାଇଲରେ ଆଉ ନଥିବା ଇମେଲଗୁଡ଼ିକୁ ନିଷ୍କ୍ରିୟ କରିବା, ଏବଂ ଅଡିଟିଂ ପାଇଁ ପ୍ରତ୍ୟେକ ପରିବର୍ତ୍ତନର ରେକର୍ଡ ରଖିବା। ଏହା ସହଜ ମନେହୁଏ—କିନ୍ତୁ ଯେତେବେଳେ ଆପଣ ୧୦୦,୦୦୦ ଠିକଣା ସହିତ କାମ କରୁଛନ୍ତି, ଏହି ସହଜ ଉପାୟଟି ଏକ ପ୍ରତିବନ୍ଧକ ସାଜିଥାଏ।

Yaroslav Podorvanov ନାମକ ଜଣେ ଡେଭଲପର୍ ନିକଟରେ ସେୟାର୍ କରିଥିଲେ ଯେ କିପରି ଏହି ସମାନ ସମସ୍ୟାର ସମାଧାନ ପାଇଁ ୯୦ ସେକେଣ୍ଡ ସମୟ ଲାଗୁଥିଲା—ଯେପର୍ଯ୍ୟନ୍ତ ସେ ଏକ PostgreSQL କୌଶଳ ବ୍ୟବହାର କରି ଏହାକୁ ପୁନର୍ବାର ନ ଲେଖିଥିଲେ, ଯାହା ସେହି ସମୟକୁ ମାତ୍ର ୫ ସେକେଣ୍ଡକୁ କମାଇଦେଲା। 8 July 2026 ରେ, ଏହି ଉପାୟକୁ ବୁଝିବା ଯୋଗ୍ୟ କାରଣ ଏହା ଡାଟାବେସ୍ କିପରି କାମ କରେ ସେ ବିଷୟରେ ଏକ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ କଥା ପ୍ରକାଶ କରେ: ପ୍ରକୃତ ମୂଲ୍ୟ ସାଧାରଣତଃ ଭାରୀ କାମ ନୁହେଁ—ଏହା ଆପଣଙ୍କ କୋଡ୍ ଏବଂ ଡାଟାବେସ୍ ମଧ୍ୟରେ ହେଉଥିବା କଥାବାର୍ତ୍ତା।

ଧୀର ସଂସ୍କରଣଟି କିପରି କାମ କରୁଥିଲା

ମୂଳ ସମାଧାନଟି କାର୍ଯ୍ୟକୁ ଅଲଗା ଅଲଗା ସୋପାନରେ ବିଭକ୍ତ କରିଥିଲା:

1. ଫାଇଲରୁ ନୂତନ ଇମେଲ୍ ଠିକଣାଗୁଡ଼ିକୁ ଇନସର୍ଟ କିମ୍ବା ଅପଡେଟ୍ କରନ୍ତୁ
2. ଫାଇଲରେ ନଥିବା ଯେକୌଣସି ଇମେଲ୍ ଠିକଣାକୁ ନିଷ୍କ୍ରିୟ କରନ୍ତୁ
3. ଅଡିଟିଂ ପାଇଁ ହିଷ୍ଟ୍ରି ଟେବୁଲରେ ପ୍ରତ୍ୟେକ ପରିବର୍ତ୍ତନ ରେକର୍ଡ କରନ୍ତୁ

ପ୍ରତ୍ୟେକ ସୋପାନ ତାହାର ନିଜସ୍ୱ ଡାଟାବେସ୍ କ୍ୱେରୀ ଥିଲା। ଏହାର ଅର୍ଥ କୋଡକୁ ଏହା କରିବାକୁ ପଡ଼ୁଥିଲା:

• ଡାଟାବେସକୁ ଇମେଲ୍ ତାଲିକା ପଠାନ୍ତୁ
• ଉତ୍ତର ପାଇଁ ଅପେକ୍ଷା କରନ୍ତୁ
• ଯାହା ପରିବର୍ତ୍ତିତ ହେଲା ତାହାର ID ଗୁଡ଼ିକ ପ୍ରାପ୍ତ କରନ୍ତୁ
• ସେହି ID ଗୁଡ଼ିକୁ ପୁନର୍ବାର ଡାଟାବେସକୁ ପଠାନ୍ତୁ
• ପୁଣି ଅପେକ୍ଷା କରନ୍ତୁ
• ନିଷ୍କ୍ରିୟକରଣ ପାଇଁ ପୁନରାବୃତ୍ତି କରନ୍ତୁ
• ହିଷ୍ଟ୍ରି ରେକର୍ଡ ପାଇଁ ପୁଣି ପୁନରାବୃତ୍ତି କରନ୍ତୁ

୧୦୦,୦୦୦ ଠିକଣା ସହିତ, ସେହି ସମସ୍ତ ଅପେକ୍ଷା ମିଶି: ମୋଟ ୯୦ ସେକେଣ୍ଡ ହୋଇଗଲା।

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 ଖଣ୍ଡଗୁଡ଼ିକୁ ଏକାଠି ଯୋଡ଼ିଥାଏ: ଆସୁଥିବା ଡାଟା ଆକ୍ଟିଭେସନ୍ ସୋପାନକୁ ଯାଏ, ଯାହା ହିଷ୍ଟ୍ରି ସୋପାନକୁ ଯାଏ, ଏବଂ ଏହିପରି ଆଗକୁ ବଢ଼େ।

ଗତି ବୃଦ୍ଧି

ଫଳାଫଳ ନିଜେ ସବୁ କିଛି କୁହେ:

• ୧୦,୦୦୦ ଠିକଣା: ~୫ ସେକେଣ୍ଡ (ଧୀର ସଂସ୍କରଣ) → ~୩ ସେକେଣ୍ଡ (CTE)
• ୧୦୦,୦୦୦ ଠିକଣା: ~୯୦ ସେକେଣ୍ଡ (ଧୀର ସଂସ୍କରଣ) → ~୫ ସେକେଣ୍ଡ (CTE)
• ୧ ନିୟୁତ ଠିକଣା: ~୩୦ ସେକେଣ୍ଡ (CTE)

୧୦୦k କ୍ଷେତ୍ରରେ ଏହା ୧୮ ଗୁଣ ଗତି ବୃଦ୍ଧି, ଯାହା କେବଳ ଡାଟା ପ୍ରବାହକୁ ପୁନର୍ଗଠନ କରି ହାସଲ କରାଯାଇଛି—ଡାଟାବେସକୁ ଅଧିକ ପରିଶ୍ରମ କରାଇ ନୁହେଁ, ବରଂ ଏହାକୁ ଅଧିକ ବୁଦ୍ଧିମାନ ଭାବରେ କାମ କରାଇ।

ଏହା କାହିଁକି ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ

ଏଠାରେ ଶିକ୍ଷାଟି ପ୍ରତ୍ୟକ୍ଷ ଅନୁଭୂତିର ବିପରୀତ: ଡାଟାବେସରେ, ରାଉଣ୍ଡ-ଟ୍ରିପ୍ ମୂଲ୍ୟ (ଡାଟା ପଠାଇବା ଏବଂ ଗ୍ରହଣ କରିବାରେ ବିତାଉଥିବା ସମୟ) ପ୍ରାୟତଃ ପ୍ରକୃତ ଗଣନା ତୁଳନାରେ ବହୁତ ଅଧିକ। ପାଞ୍ଚଟି ଟ୍ରିପକୁ ଗୋଟିଏରେ ଏକତ୍ରିତ କରି, Podorvanov କେବଳ ସମୟ ବଞ୍ଚାଇ ନାହାଁନ୍ତି—ସେ ସର୍ଭର ଭାର ମଧ୍ୟ କମାଇଛନ୍ତି ଏବଂ ଅପରେସନକୁ ଅଧିକ ଆଟୋମିକ୍ କରିଛନ୍ତି (ହୁଏତ ସବୁକିଛି ସଫଳ ହୁଏ କିମ୍ବା କିଛି ହୁଏନାହିଁ, ମଝିରେ କୌଣସି ଆଂଶିକ ସ୍ଥିତି ରହେନାହିଁ)।

ଏହା କୌଣସି ଯାଦୁ ନୁହେଁ; ଏହା ଏକ ନିୟମ ଯାହା ଯେକୌଣସି ସ୍ଥାନରେ ଲାଗୁହୁଏ: ଅନାବଶ୍ୟକ ଆଦାନପ୍ରଦାନକୁ କମ୍ କରନ୍ତୁ, ଏବଂ ସିଷ୍ଟମ୍ ଗୁଡ଼ିକ ଦ୍ରୁତତର ହୋଇଯାଏ। ଏହି କୌଶଳ ଇମେଲ୍ ସିଙ୍କ୍, ବ୍ୟାଚ୍ ଇମ୍ପୋର୍ଟ, କିମ୍ବା ଏକାଧିକ ରୀଡ୍ ଏବଂ ରାଇଟକୁ ଏକାଠି ଯୋଡ଼ୁଥିବା ଯେକୌଣସି ଅପରେସନ୍ ପାଇଁ କାମ କରେ।

ନିଷ୍କର୍ଷ

ଯେତେବେଳେ ଏକ ଡାଟାବେସ୍ ଅପରେସନ୍ ଧୀର ମନେହୁଏ, ଦୋଷୀ ପ୍ରାୟତଃ କ୍ୱେରୀ ନିଜେ ନୁହେଁ ବରଂ ଆପଣ କେତେଗୋଟି ଅଲଗା କ୍ୱେରୀ ଚଲାଉଛନ୍ତି। CTE ଆପଣଙ୍କୁ ଏକାଧିକ ଅପରେସନକୁ ଗୋଟିଏ ଆଟୋମିକ୍ ସୋପାନରେ ଏକତ୍ରିତ କରିବାକୁ ଦିଏ, ରାଉଣ୍ଡ-ଟ୍ରିପ୍ ଓଭରହେଡକୁ କମାଇଦିଏ ଏବଂ ଥ୍ରୋପୁଟକୁ ବହୁତ ଉନ୍ନତ କରେ। ଇମେଲ୍ ସିଙ୍କିଂ କିମ୍ବା ବ୍ୟାଚ୍ ଅପଲୋଡ୍ ଭଳି ୱାର୍କଲୋଡ୍ ପାଇଁ, ଏହି ପ୍ରକାରର ଅପ୍ଟିମାଇଜେସନ୍ ଏକ ୯୦-ସେକେଣ୍ଡ ଅପରେସନ୍ ଏବଂ ୫-ସେକେଣ୍ଡ ଅପରେସନ୍ ମଧ୍ୟରେ ପାର୍ଥକ୍ୟ ଆଣିପାରେ।

ସୁବିଧାଗୁଡ଼ିକ

• ଡାଟାବେସ୍ ରାଉଣ୍ଡ-ଟ୍ରିପକୁ ବହୁ ପରିମାଣରେ କମାଇଥାଏ, ଲେଟେନ୍ସି ହ୍ରାସ କରେ
• ଡାଟା ନିରନ୍ତରତା ବଜାୟ ରଖେ—ସମସ୍ତ ପରିବର୍ତ୍ତନ ଗୋଟିଏ ଟ୍ରାଞ୍ଜାକସନରେ ଆଟୋମିକ୍ ଭାବରେ ଘଟେ
• ଆପ୍ଲିକେସନ୍ କୋଡକୁ ସରଳ କରେ (କମ୍ ଅଲଗା ଫଙ୍କସନ୍ କଲ୍)
• ସମାନ ଭାବରେ ସ୍କେଲ୍ କରେ; ସମାନ କ୍ୱେରୀ ୧୦k କିମ୍ବା ୧M ଠିକଣା ପାଇଁ କାମ କରେ
• ଡାଟାବେସର ସାମର୍ଥ୍ୟର ଫାଇଦା ଉଠାଏ

ଅସୁବିଧାଗୁଡ଼ିକ

• CTE ସିଣ୍ଟାକ୍ସ ଅଧିକ ଜଟିଳ ଏବଂ ଡିବଗ୍ କରିବା କଷ୍ଟକର ହୋଇପାରେ
• ଉନ୍ନତ SQL ସହିତ ପରିଚିତ ହେବା ଆବଶ୍ୟକ—ଡାଟାବେସରେ ନୂଆ ଥିବା ଟିମ୍ ଗୁଡ଼ିକ ପାଇଁ ଉପଯୁକ୍ତ ନୁହେଁ
• ଡାଟାବେସ୍ ଲଗ୍ ଗୁଡ଼ିକ କମ୍ ଗ୍ରାନୁଲାର୍ ହୋଇଯାଏ (କେଉଁ ସୋପାନଟି ଧୀର ଥିଲା ତାହା ସଠିକ୍ ଭାବରେ ଦେଖିବା କଷ୍ଟକର)
• ସମସ୍ତ ଡାଟାବେସ୍ CTE ଗୁଡ଼ିକୁ ସମାନ ଭାବରେ ସମର୍ଥନ କରନ୍ତି ନାହିଁ
• ଛୋଟ ଡାଟାସେଟ୍ ପାଇଁ ଅତ୍ୟାଧିକ ହୋଇପାରେ ଯେଉଁଠାରେ ଓଭରହେଡ୍ କିଛି ଫରକ ପକାଏ ନାହିଁ

ସାବଧାନତା

ଏହି ପ୍ରବନ୍ଧଟି ଶିକ୍ଷଣୀୟ ଏବଂ ଏକ ବାସ୍ତବ ଜଗତର ଉଦାହରଣରୁ ନିଆଯାଇଛି। ସମାନ ଅପ୍ଟିମାଇଜେସନ୍ କାର୍ଯ୍ୟକାରୀ କରିବା ସମୟରେ, ଯେକୌଣସି ପ୍ଲେସହୋଲ୍ଡର ଭାଲ୍ୟୁ (ଯେପରିକି @file_id କିମ୍ବା @now) କୁ ଆପଣଙ୍କ ଆପ୍ଲିକେସନର ପ୍ରକୃତ ଭେରିଏବଲ୍ ସହିତ ବଦଳାନ୍ତୁ, ଆପଣଙ୍କର ନିଜସ୍ୱ ଡାଟା ଭଲ୍ୟୁମ୍ ସହିତ ଭଲ ଭାବରେ ପରୀକ୍ଷା କରନ୍ତୁ, ଏବଂ ପ୍ରୋଡକ୍ସନରେ ଏହା ଉପରେ ନିର୍ଭର କରିବା ପୂର୍ବରୁ ମୂଳ ଉତ୍ସ ସହିତ ଦାବିଗୁଡ଼ିକୁ ଯାଞ୍ଚ କରନ୍ତୁ। ଡାଟାବେସ୍ କାର୍ଯ୍ୟଦକ୍ଷତା ବହୁତ ପରିପ୍ରେକ୍ଷୀ-ନିର୍ଭରଶୀଳ; ଏଠାରେ ଯାହା କାମ କରେ ତାହା ଆପଣଙ୍କ ନିର୍ଦ୍ଦିଷ୍ଟ ସ୍କିମା, ଇଣ୍ଡେକ୍ସ ଏବଂ ହାର୍ଡୱେର୍ ପାଇଁ ଟ୍ୟୁନିଂ ଆବଶ୍ୟକ କରିପାରେ।

ବାରମ୍ବାର ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନଗୁଡ଼ିକ

• PostgreSQL ରେ CTE କ'ଣ ଏବଂ ଏହା କିପରି କ୍ୱେରୀ କାର୍ଯ୍ୟଦକ୍ଷତାରେ ସୁଧାର ଆଣେ?
• ଇମେଲ୍ ସିଙ୍କିଂ ବ୍ୟତୀତ ଅନ୍ୟ ଅପରେସନ୍ ପାଇଁ CTEs ବ୍ୟବହାର କରାଯାଇପାରିବ କି?
• କିଛି ଭୁଲ୍ ହେଲେ ଆପଣ କିପରି ଏକ CTE କ୍ୱେରୀକୁ ଡିବଗ୍ କରିବେ?
• ଏକ CTE ଏବଂ stored procedure ମଧ୍ୟରେ ପାର୍ଥକ୍ୟ କ'ଣ?
• ସମସ୍ତ SQL ଡାଟାବେସ୍ ସମାନ ଭାବରେ CTE ଗୁଡ଼ିକୁ ସମର୍ଥନ କରନ୍ତି କି?
• ଅଲଗା କ୍ୱେରୀ କରିବା ତୁଳନାରେ CTE କେବେ ସଠିକ୍ ଉପକରଣ?
• CTE ଗୁଡ଼ିକ index ବ୍ୟବହାର ଏବଂ query planning କୁ କିପରି ପ୍ରଭାବିତ କରନ୍ତି?
• ଯଦି ଏକ CTE ଅପରେସନ୍ ମଝିରେ ବିଫଳ ହୁଏ ତେବେ କ'ଣ ହୁଏ?

ଟ୍ୟାଗ୍‌ଗୁଡ଼ିକ

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