ഒരു SQL അന്വേഷണത്തിന്റെ കഥ

കഴിഞ്ഞ ഡിസംബറിൽ എനിക്ക് VWO പിന്തുണാ ടീമിൽ നിന്ന് രസകരമായ ഒരു ബഗ് റിപ്പോർട്ട് ലഭിച്ചു. ഒരു വലിയ കോർപ്പറേറ്റ് ക്ലയന്റിനായുള്ള അനലിറ്റിക്‌സ് റിപ്പോർട്ടുകളിലൊന്നിന്റെ ലോഡിംഗ് സമയം നിരോധിതമായി തോന്നി. ഇത് എന്റെ ഉത്തരവാദിത്ത മേഖലയായതിനാൽ, ഞാൻ ഉടൻ തന്നെ പ്രശ്നം പരിഹരിക്കുന്നതിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ചു.

ചരിത്രാതീതകാലം

ഞാൻ എന്തിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെന്ന് വ്യക്തമാക്കുന്നതിന്, VWO-നെ കുറിച്ച് ഞാൻ നിങ്ങളോട് കുറച്ച് പറയാം. നിങ്ങളുടെ വെബ്‌സൈറ്റുകളിൽ വിവിധ ടാർഗെറ്റുചെയ്‌ത കാമ്പെയ്‌നുകൾ സമാരംഭിക്കാൻ കഴിയുന്ന ഒരു പ്ലാറ്റ്‌ഫോമാണിത്: എ/ബി പരീക്ഷണങ്ങൾ നടത്തുക, സന്ദർശകരെയും പരിവർത്തനങ്ങളെയും ട്രാക്ക് ചെയ്യുക, സെയിൽസ് ഫണൽ വിശകലനം ചെയ്യുക, ഹീറ്റ് മാപ്പുകൾ പ്രദർശിപ്പിക്കുക, സന്ദർശന റെക്കോർഡിംഗുകൾ പ്ലേ ചെയ്യുക.

എന്നാൽ പ്ലാറ്റ്‌ഫോമിലെ ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം റിപ്പോർട്ടിംഗ് ആണ്. മുകളിലുള്ള എല്ലാ പ്രവർത്തനങ്ങളും പരസ്പരം ബന്ധപ്പെട്ടിരിക്കുന്നു. കോർപ്പറേറ്റ് ക്ലയന്റുകൾക്ക്, അനലിറ്റിക്‌സ് രൂപത്തിൽ അവതരിപ്പിക്കുന്ന ശക്തമായ ഒരു പ്ലാറ്റ്‌ഫോം ഇല്ലെങ്കിൽ വലിയ അളവിലുള്ള വിവരങ്ങൾ ഉപയോഗശൂന്യമാകും.

പ്ലാറ്റ്ഫോം ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ഒരു വലിയ ഡാറ്റാ സെറ്റിൽ ക്രമരഹിതമായ ഒരു ചോദ്യം നടത്താം. ഒരു ലളിതമായ ഉദാഹരണം ഇതാ:

Chrome ഉപയോഗിക്കുന്ന അല്ലെങ്കിൽ (യൂറോപ്പിൽ സ്ഥിതിചെയ്യുന്നതും iPhone ഉപയോഗിക്കുന്നതുമായ) ആളുകൾക്കായി "abc.com" പേജിലെ എല്ലാ ക്ലിക്കുകളും <date d1> മുതൽ <date d2> വരെ കാണിക്കുക

ബൂളിയൻ ഓപ്പറേറ്റർമാരെ ശ്രദ്ധിക്കുക. സാമ്പിളുകൾ ലഭിക്കുന്നതിന് ഏകപക്ഷീയമായി സങ്കീർണ്ണമായ ചോദ്യങ്ങൾ ഉന്നയിക്കുന്നതിന് അവ അന്വേഷണ ഇന്റർഫേസിൽ ക്ലയന്റുകൾക്ക് ലഭ്യമാണ്.

മന്ദഗതിയിലുള്ള അഭ്യർത്ഥന

സംശയാസ്പദമായ ക്ലയന്റ് അവബോധപൂർവ്വം വേഗത്തിൽ പ്രവർത്തിക്കേണ്ട എന്തെങ്കിലും ചെയ്യാൻ ശ്രമിക്കുകയായിരുന്നു:

"/ജോബ്സ്" അടങ്ങിയ URL ഉള്ള ഏതെങ്കിലും പേജ് സന്ദർശിച്ച ഉപയോക്താക്കൾക്കായി എല്ലാ സെഷൻ റെക്കോർഡുകളും കാണിക്കുക

ഈ സൈറ്റിന് ഒരു ടൺ ട്രാഫിക് ഉണ്ടായിരുന്നു, അതിനായി ഞങ്ങൾ ഒരു ദശലക്ഷത്തിലധികം അദ്വിതീയ URL-കൾ സംഭരിച്ചു. അവരുടെ ബിസിനസ്സ് മോഡലുമായി ബന്ധപ്പെട്ട വളരെ ലളിതമായ ഒരു URL ടെംപ്ലേറ്റ് കണ്ടെത്താൻ അവർ ആഗ്രഹിച്ചു.

പ്രാഥമിക അന്വേഷണം

ഡാറ്റാബേസിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് നമുക്ക് നോക്കാം. യഥാർത്ഥ സ്ലോ SQL ചോദ്യം ചുവടെയുണ്ട്:

SELECT 
    count(*) 
FROM 
    acc_{account_id}.urls as recordings_urls, 
    acc_{account_id}.recording_data as recording_data, 
    acc_{account_id}.sessions as sessions 
WHERE 
    recording_data.usp_id = sessions.usp_id 
    AND sessions.referrer_id = recordings_urls.id 
    AND  (  urls &&  array(select id from acc_{account_id}.urls where url  ILIKE  '%enterprise_customer.com/jobs%')::text[]   ) 
    AND r_time > to_timestamp(1542585600) 
    AND r_time < to_timestamp(1545177599) 
    AND recording_data.duration >=5 
    AND recording_data.num_of_pages > 0 ;

കൂടാതെ സമയക്രമം ഇതാ:

ആസൂത്രണം ചെയ്ത സമയം: 1.480 മി.എസ്. നിർവ്വഹണ സമയം: 1431924.650 എം.എസ്.

ചോദ്യം 150 ആയിരം വരികൾ ക്രോൾ ചെയ്തു. അന്വേഷണ പ്ലാനർ രസകരമായ രണ്ട് വിശദാംശങ്ങൾ കാണിച്ചു, പക്ഷേ വ്യക്തമായ തടസ്സങ്ങളൊന്നുമില്ല.

അഭ്യർത്ഥന കൂടുതൽ പഠിക്കാം. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, അവൻ ചെയ്യുന്നു JOIN മൂന്ന് പട്ടികകൾ:

1. സെഷനുകൾ: സെഷൻ വിവരങ്ങൾ പ്രദർശിപ്പിക്കുന്നതിന്: ബ്രൗസർ, ഉപയോക്തൃ ഏജന്റ്, രാജ്യം തുടങ്ങിയവ.
2. റെക്കോർഡിംഗ്_ഡാറ്റ: രേഖപ്പെടുത്തിയ URL-കൾ, പേജുകൾ, സന്ദർശനങ്ങളുടെ ദൈർഘ്യം
3. url: വളരെ വലിയ URL-കൾ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യുന്നത് ഒഴിവാക്കാൻ, ഞങ്ങൾ അവയെ ഒരു പ്രത്യേക പട്ടികയിൽ സംഭരിക്കുന്നു.

ഞങ്ങളുടെ എല്ലാ ടേബിളുകളും ഇതിനകം പാർട്ടീഷൻ ചെയ്‌തിരിക്കുന്നു എന്നതും ശ്രദ്ധിക്കുക account_id. ഈ രീതിയിൽ, പ്രത്യേകിച്ച് ഒരു വലിയ അക്കൗണ്ട് മറ്റുള്ളവർക്ക് പ്രശ്‌നമുണ്ടാക്കുന്ന സാഹചര്യം ഒഴിവാക്കപ്പെടുന്നു.

സൂചനകൾ തേടുന്നു

സൂക്ഷ്മമായി പരിശോധിക്കുമ്പോൾ, ഒരു പ്രത്യേക അഭ്യർത്ഥനയിൽ എന്തോ കുഴപ്പമുണ്ടെന്ന് ഞങ്ങൾ കാണുന്നു. ഈ വരി സൂക്ഷ്മമായി പരിശോധിക്കുന്നത് മൂല്യവത്താണ്:

urls && array(
	select id from acc_{account_id}.urls 
	where url  ILIKE  '%enterprise_customer.com/jobs%'
)::text[]

അതുകൊണ്ടായിരിക്കാം എന്നായിരുന്നു ആദ്യ ചിന്ത ILIKE ഈ ദൈർഘ്യമേറിയ എല്ലാ URL-കളിലും (ഞങ്ങൾക്ക് 1,4 ദശലക്ഷത്തിലധികം ഉണ്ട് അദ്വിതീയമാണ് ഈ അക്കൗണ്ടിനായി ശേഖരിച്ച URL-കൾ) പ്രകടനത്തെ ബാധിച്ചേക്കാം.

പക്ഷേ ഇല്ല, അതല്ല കാര്യം!

SELECT id FROM urls WHERE url ILIKE '%enterprise_customer.com/jobs%';
  id
--------
 ...
(198661 rows)

Time: 5231.765 ms

ടെംപ്ലേറ്റ് തിരയൽ അഭ്യർത്ഥനയ്ക്ക് 5 സെക്കൻഡ് മാത്രമേ എടുക്കൂ. ഒരു ദശലക്ഷം അദ്വിതീയ URL-കളിൽ ഒരു പാറ്റേൺ തിരയുന്നത് ഒരു പ്രശ്നമല്ല.

പട്ടികയിൽ അടുത്തതായി സംശയിക്കുന്നവർ നിരവധിയാണ് JOIN. ഒരുപക്ഷേ അവരുടെ അമിത ഉപയോഗം മാന്ദ്യത്തിന് കാരണമായോ? സാധാരണയായി JOINപ്രകടന പ്രശ്‌നങ്ങൾക്കുള്ള ഏറ്റവും വ്യക്തമായ സ്ഥാനാർത്ഥികളാണ്, എന്നാൽ ഞങ്ങളുടെ കേസ് സാധാരണമാണെന്ന് ഞാൻ വിശ്വസിച്ചില്ല.

analytics_db=# SELECT
    count(*)
FROM
    acc_{account_id}.urls as recordings_urls,
    acc_{account_id}.recording_data_0 as recording_data,
    acc_{account_id}.sessions_0 as sessions
WHERE
    recording_data.usp_id = sessions.usp_id
    AND sessions.referrer_id = recordings_urls.id
    AND r_time > to_timestamp(1542585600)
    AND r_time < to_timestamp(1545177599)
    AND recording_data.duration >=5
    AND recording_data.num_of_pages > 0 ;
 count
-------
  8086
(1 row)

Time: 147.851 ms

ഞങ്ങളുടെ കാര്യവും ഇതായിരുന്നില്ല. JOINവളരെ വേഗമേറിയതായി മാറി.

സംശയിക്കുന്നവരുടെ വലയം ചുരുക്കുന്നു

സാധ്യമായ പ്രകടന മെച്ചപ്പെടുത്തലുകൾ നേടുന്നതിന് ചോദ്യം മാറ്റാൻ ഞാൻ തയ്യാറായിരുന്നു. ഞാനും എന്റെ ടീമും 2 പ്രധാന ആശയങ്ങൾ വികസിപ്പിച്ചെടുത്തു:

• സബ്ക്വറി URL-നായി EXISTS ഉപയോഗിക്കുക: URL-കൾക്കായുള്ള സബ്‌ക്വറിയിൽ എന്തെങ്കിലും പ്രശ്‌നങ്ങളുണ്ടെങ്കിൽ ഞങ്ങൾ വീണ്ടും പരിശോധിക്കാൻ ആഗ്രഹിക്കുന്നു. ഇത് നേടാനുള്ള ഒരു മാർഗ്ഗം ലളിതമായി ഉപയോഗിക്കുക എന്നതാണ് EXISTS. EXISTS കഴിയും അവസ്ഥയുമായി പൊരുത്തപ്പെടുന്ന ഒരേയൊരു സ്ട്രിംഗ് കണ്ടെത്തിയാലുടൻ അത് അവസാനിക്കുമെന്നതിനാൽ പ്രകടനം വളരെയധികം മെച്ചപ്പെടുത്തുക.

SELECT
	count(*) 
FROM 
    acc_{account_id}.urls as recordings_urls,
    acc_{account_id}.recording_data as recording_data,
    acc_{account_id}.sessions as sessions
WHERE
    recording_data.usp_id = sessions.usp_id
    AND  (  1 = 1  )
    AND sessions.referrer_id = recordings_urls.id
    AND  (exists(select id from acc_{account_id}.urls where url  ILIKE '%enterprise_customer.com/jobs%'))
    AND r_time > to_timestamp(1547585600)
    AND r_time < to_timestamp(1549177599)
    AND recording_data.duration >=5
    AND recording_data.num_of_pages > 0 ;
 count
 32519
(1 row)
Time: 1636.637 ms

ശരി, അതെ. പൊതിഞ്ഞപ്പോൾ സബ്ക്വറി EXISTS, എല്ലാം അതിവേഗത്തിലാക്കുന്നു. എന്തിനാണ് അഭ്യർത്ഥന എന്നതാണ് അടുത്ത യുക്തിസഹമായ ചോദ്യം JOIN-ആമിയും സബ്‌ക്വറിയും വ്യക്തിഗതമായി വേഗതയുള്ളതാണ്, പക്ഷേ ഒരുമിച്ച് വളരെ മന്ദഗതിയിലാണോ?

• സബ്ക്വറി CTE ലേക്ക് മാറ്റുന്നു : അന്വേഷണം അതിന്റേതായ വേഗമാണെങ്കിൽ, നമുക്ക് ആദ്യം ഫാസ്റ്റ് റിസൾട്ട് കണക്കാക്കുകയും തുടർന്ന് പ്രധാന ചോദ്യത്തിന് അത് നൽകുകയും ചെയ്യാം.

WITH matching_urls AS (
    select id::text from acc_{account_id}.urls where url  ILIKE  '%enterprise_customer.com/jobs%'
)

SELECT 
    count(*) FROM acc_{account_id}.urls as recordings_urls, 
    acc_{account_id}.recording_data as recording_data, 
    acc_{account_id}.sessions as sessions,
    matching_urls
WHERE 
    recording_data.usp_id = sessions.usp_id 
    AND  (  1 = 1  )  
    AND sessions.referrer_id = recordings_urls.id
    AND (urls && array(SELECT id from matching_urls)::text[])
    AND r_time > to_timestamp(1542585600) 
    AND r_time < to_timestamp(1545107599)
    AND recording_data.duration >=5 
    AND recording_data.num_of_pages > 0;

പക്ഷേ അപ്പോഴും വളരെ പതുക്കെയായിരുന്നു.

കുറ്റവാളിയെ കണ്ടെത്തുന്നു

ഈ സമയമത്രയും, ഒരു ചെറിയ കാര്യം എന്റെ കൺമുമ്പിൽ മിന്നിമറഞ്ഞു, അത് ഞാൻ നിരന്തരം മാറ്റിവച്ചു. പക്ഷേ മറ്റൊന്നും ബാക്കിയില്ലാത്തതിനാൽ അവളെയും നോക്കാൻ തീരുമാനിച്ചു. ഞാൻ സംസാരിക്കുന്നത് && ഓപ്പറേറ്റർ. ബൈ EXISTS മെച്ചപ്പെട്ട പ്രകടനം മാത്രം && മന്ദഗതിയിലുള്ള അന്വേഷണത്തിന്റെ എല്ലാ പതിപ്പുകളിലും അവശേഷിക്കുന്ന ഒരേയൊരു പൊതു ഘടകം ആയിരുന്നു.

നോക്കുന്നു പ്രമാണീകരണം, ഞങ്ങൾ അത് കാണുന്നു && രണ്ട് അറേകൾക്കിടയിൽ പൊതുവായ ഘടകങ്ങൾ കണ്ടെത്തേണ്ടിവരുമ്പോൾ ഉപയോഗിക്കുന്നു.

യഥാർത്ഥ അഭ്യർത്ഥനയിൽ ഇതാണ്:

AND  (  urls &&  array(select id from acc_{account_id}.urls where url  ILIKE  '%enterprise_customer.com/jobs%')::text[]   )

അതിനർത്ഥം ഞങ്ങൾ ഞങ്ങളുടെ URL-കളിൽ ഒരു പാറ്റേൺ തിരയൽ നടത്തുന്നു, തുടർന്ന് പൊതുവായ പോസ്റ്റുകളുള്ള എല്ലാ URL-കളുമായും കവല കണ്ടെത്തുക. ഇത് അൽപ്പം ആശയക്കുഴപ്പമുണ്ടാക്കുന്നു, കാരണം ഇവിടെ "url" എന്നത് എല്ലാ URL-കളും അടങ്ങുന്ന പട്ടികയെയല്ല, മറിച്ച് പട്ടികയിലെ "url" കോളത്തെയാണ് സൂചിപ്പിക്കുന്നത്. recording_data.

എന്ന സംശയം വർദ്ധിച്ചതോടെ &&, ജനറേറ്റ് ചെയ്‌ത അന്വേഷണ പ്ലാനിൽ അവർക്കുള്ള സ്ഥിരീകരണം കണ്ടെത്താൻ ഞാൻ ശ്രമിച്ചു EXPLAIN ANALYZE (എനിക്ക് ഇതിനകം ഒരു പ്ലാൻ സംരക്ഷിച്ചിട്ടുണ്ട്, എന്നാൽ ക്വറി പ്ലാനർമാരുടെ അതാര്യത മനസ്സിലാക്കാൻ ശ്രമിക്കുന്നതിനേക്കാൾ സാധാരണയായി SQL-ൽ പരീക്ഷണം നടത്തുന്നത് എനിക്ക് കൂടുതൽ സൗകര്യപ്രദമാണ്).

Filter: ((urls && ($0)::text[]) AND (r_time > '2018-12-17 12:17:23+00'::timestamp with time zone) AND (r_time < '2018-12-18 23:59:59+00'::timestamp with time zone) AND (duration >= '5'::double precision) AND (num_of_pages > 0))
                           Rows Removed by Filter: 52710

ഫിൽട്ടറുകളുടെ നിരവധി വരികൾ മാത്രം ഉണ്ടായിരുന്നു &&. ഇതിനർത്ഥം ഈ ഓപ്പറേഷൻ ചെലവേറിയത് മാത്രമല്ല, നിരവധി തവണ നടത്തുകയും ചെയ്തു.

ഈ അവസ്ഥയെ വേർതിരിച്ചുകൊണ്ട് ഞാൻ ഇത് പരീക്ഷിച്ചു

SELECT 1
FROM 
    acc_{account_id}.urls as recordings_urls, 
    acc_{account_id}.recording_data_30 as recording_data_30, 
    acc_{account_id}.sessions_30 as sessions_30 
WHERE 
	urls &&  array(select id from acc_{account_id}.urls where url  ILIKE  '%enterprise_customer.com/jobs%')::text[]

ഈ ചോദ്യം മന്ദഗതിയിലായിരുന്നു. എന്തുകൊണ്ടെന്നാല് JOIN-കൾ വേഗതയുള്ളതും സബ്ക്വറികൾ വേഗത്തിലുള്ളതുമാണ്, അവശേഷിക്കുന്നത് മാത്രമായിരുന്നു && ഓപ്പറേറ്റർ.

ഇതൊരു പ്രധാന പ്രവർത്തനം മാത്രമാണ്. ഒരു പാറ്റേണിനായി തിരയാൻ ഞങ്ങൾക്ക് എല്ലായ്പ്പോഴും URL-കളുടെ അടിസ്ഥാന പട്ടിക മുഴുവൻ തിരയേണ്ടതുണ്ട്, ഞങ്ങൾക്ക് എല്ലായ്പ്പോഴും കവലകൾ കണ്ടെത്തേണ്ടതുണ്ട്. URL റെക്കോർഡുകൾ ഉപയോഗിച്ച് ഞങ്ങൾക്ക് നേരിട്ട് തിരയാൻ കഴിയില്ല, കാരണം ഇവ പരാമർശിക്കുന്ന ഐഡികൾ മാത്രമാണ് urls.

ഒരു പരിഹാരത്തിലേക്കുള്ള വഴിയിൽ

&& രണ്ട് സെറ്റുകളും വലുതായതിനാൽ പതുക്കെ. ഞാൻ മാറ്റിസ്ഥാപിച്ചാൽ പ്രവർത്തനം താരതമ്യേന വേഗത്തിലാകും urls ഓൺ { "http://google.com/", "http://wingify.com/" }.

ഉപയോഗിക്കാതെ തന്നെ Postgres-ൽ സെറ്റ് ഇന്റർസെക്ഷൻ ചെയ്യാനുള്ള വഴി ഞാൻ അന്വേഷിക്കാൻ തുടങ്ങി &&, പക്ഷേ കാര്യമായ വിജയമില്ലാതെ.

അവസാനം, ഒറ്റപ്പെടലിൽ പ്രശ്നം പരിഹരിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു: എനിക്ക് എല്ലാം തരൂ urls URL പാറ്റേണുമായി പൊരുത്തപ്പെടുന്ന വരികൾ. അധിക വ്യവസ്ഥകളില്ലാതെ അത് ഇതായിരിക്കും - 

SELECT urls.url
FROM 
	acc_{account_id}.urls as urls,
	(SELECT unnest(recording_data.urls) AS id) AS unrolled_urls
WHERE
	urls.id = unrolled_urls.id AND
	urls.url  ILIKE  '%jobs%'

പകരം JOIN വാക്യഘടന ഞാൻ ഒരു സബ്ക്വറി ഉപയോഗിക്കുകയും വിപുലീകരിക്കുകയും ചെയ്തു recording_data.urls നിങ്ങൾക്ക് നേരിട്ട് വ്യവസ്ഥ പ്രയോഗിക്കാൻ കഴിയുന്ന തരത്തിൽ അറേ WHERE.

ഇവിടെ ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം അതാണ് && നൽകിയിരിക്കുന്ന എൻട്രിയിൽ പൊരുത്തപ്പെടുന്ന URL ഉണ്ടോ എന്ന് പരിശോധിക്കാൻ ഉപയോഗിക്കുന്നു. നിങ്ങൾ അൽപ്പം കണ്ണടച്ചാൽ, ഈ പ്രവർത്തനം ഒരു അറേയുടെ (അല്ലെങ്കിൽ ഒരു പട്ടികയുടെ വരികൾ) മൂലകങ്ങളിലൂടെ നീങ്ങുന്നതും ഒരു വ്യവസ്ഥ (പൊരുത്തം) പാലിക്കുമ്പോൾ നിർത്തുന്നതും നിങ്ങൾക്ക് കാണാൻ കഴിയും. ഒന്നും നിങ്ങളെ ഓർമ്മിപ്പിക്കുന്നില്ലേ? അതെ, EXISTS.

മുതൽ recording_data.urls സബ്ക്വറി സന്ദർഭത്തിന് പുറത്ത് നിന്ന് പരാമർശിക്കാം, ഇത് സംഭവിക്കുമ്പോൾ നമുക്ക് നമ്മുടെ പഴയ സുഹൃത്തിലേക്ക് മടങ്ങാം EXISTS അത് കൊണ്ട് സബ്ക്വറി പൊതിയുക.

എല്ലാം ഒരുമിച്ച് ചേർത്താൽ, ഞങ്ങൾക്ക് അന്തിമ ഒപ്റ്റിമൈസ് ചെയ്ത ചോദ്യം ലഭിക്കും:

SELECT 
    count(*) 
FROM 
    acc_{account_id}.urls as recordings_urls, 
    acc_{account_id}.recording_data as recording_data, 
    acc_{account_id}.sessions as sessions 
WHERE 
    recording_data.usp_id = sessions.usp_id 
    AND  (  1 = 1  )  
    AND sessions.referrer_id = recordings_urls.id 
    AND r_time > to_timestamp(1542585600) 
    AND r_time < to_timestamp(1545177599) 
    AND recording_data.duration >=5 
    AND recording_data.num_of_pages > 0
    AND EXISTS(
        SELECT urls.url
        FROM 
            acc_{account_id}.urls as urls,
            (SELECT unnest(urls) AS rec_url_id FROM acc_{account_id}.recording_data) 
            AS unrolled_urls
        WHERE
            urls.id = unrolled_urls.rec_url_id AND
            urls.url  ILIKE  '%enterprise_customer.com/jobs%'
    );

ഒപ്പം അവസാന ലീഡ് സമയവും Time: 1898.717 ms ആഘോഷിക്കാനുള്ള സമയമാണോ?!?

അത്ര വേഗത്തിലല്ല! ആദ്യം നിങ്ങൾ കൃത്യത പരിശോധിക്കേണ്ടതുണ്ട്. എനിക്ക് അങ്ങേയറ്റം സംശയമുണ്ടായിരുന്നു EXISTS ഒപ്റ്റിമൈസേഷൻ നേരത്തെ പൂർത്തിയാക്കാൻ ലോജിക് മാറ്റുന്നതിനാൽ. അഭ്യർത്ഥനയിൽ വ്യക്തമല്ലാത്ത ഒരു പിശക് ഞങ്ങൾ ചേർത്തിട്ടില്ലെന്ന് ഞങ്ങൾക്ക് ഉറപ്പുണ്ടായിരിക്കണം.

ഒരു ലളിതമായ പരീക്ഷണം ഓടുകയായിരുന്നു count(*) നിരവധി വ്യത്യസ്ത ഡാറ്റാ സെറ്റുകൾക്കായുള്ള വേഗത കുറഞ്ഞതും വേഗതയുള്ളതുമായ അന്വേഷണങ്ങളിൽ. തുടർന്ന്, ഡാറ്റയുടെ ഒരു ചെറിയ ഉപവിഭാഗത്തിനായി, എല്ലാ ഫലങ്ങളും ശരിയാണെന്ന് ഞാൻ സ്വമേധയാ പരിശോധിച്ചു.

എല്ലാ പരിശോധനകളും സ്ഥിരമായി പോസിറ്റീവ് ഫലങ്ങൾ നൽകി. ഞങ്ങൾ എല്ലാം ശരിയാക്കി!

പഠിച്ച പാഠങ്ങൾ

ഈ കഥയിൽ നിന്ന് ഒരുപാട് പാഠങ്ങൾ പഠിക്കാനുണ്ട്:

1. ക്വറി പ്ലാനുകൾ മുഴുവൻ കഥയും പറയുന്നില്ല, പക്ഷേ അവയ്ക്ക് സൂചനകൾ നൽകാൻ കഴിയും
2. പ്രധാന പ്രതികൾ എല്ലായ്പ്പോഴും യഥാർത്ഥ പ്രതികളല്ല
3. തടസ്സങ്ങളെ ഒറ്റപ്പെടുത്താൻ മന്ദഗതിയിലുള്ള അന്വേഷണങ്ങൾ തകർക്കാൻ കഴിയും
4. എല്ലാ ഒപ്റ്റിമൈസേഷനുകളും പ്രകൃതിയിൽ കുറയ്ക്കുന്നവയല്ല
5. ഉപയോഗിക്കുക EXIST, സാധ്യമാകുന്നിടത്ത്, ഉൽപ്പാദനക്ഷമതയിൽ നാടകീയമായ വർദ്ധനവിന് ഇടയാക്കും

തീരുമാനം

ഞങ്ങൾ ~24 മിനിറ്റ് മുതൽ 2 സെക്കൻഡ് വരെയുള്ള ഒരു അന്വേഷണ സമയം പോയി - വളരെ ഗണ്യമായ പ്രകടന വർദ്ധനവ്! ഈ ലേഖനം വലുതായി വന്നെങ്കിലും, ഞങ്ങൾ നടത്തിയ എല്ലാ പരീക്ഷണങ്ങളും ഒരു ദിവസം കൊണ്ട് സംഭവിച്ചു, ഒപ്റ്റിമൈസേഷനും ടെസ്റ്റിംഗിനും 1,5 മുതൽ 2 മണിക്കൂർ വരെ എടുത്തതായി കണക്കാക്കപ്പെട്ടു.

SQL ഒരു അത്ഭുതകരമായ ഭാഷയാണ്, നിങ്ങൾ അതിനെ ഭയപ്പെടേണ്ടതില്ല, എന്നാൽ അത് പഠിക്കാനും ഉപയോഗിക്കാനും ശ്രമിക്കുക. എസ്‌ക്യുഎൽ അന്വേഷണങ്ങൾ എങ്ങനെയാണ് എക്‌സിക്യൂട്ട് ചെയ്യുന്നത്, ഡാറ്റാബേസ് ക്വറി പ്ലാനുകൾ എങ്ങനെ സൃഷ്ടിക്കുന്നു, ഇൻഡക്‌സുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു, നിങ്ങൾ കൈകാര്യം ചെയ്യുന്ന ഡാറ്റയുടെ വലുപ്പം എന്നിവയെക്കുറിച്ച് നല്ല ധാരണയുണ്ടെങ്കിൽ, ചോദ്യങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിൽ നിങ്ങൾക്ക് വിജയിക്കാനാകും. എന്നിരുന്നാലും, വ്യത്യസ്ത സമീപനങ്ങൾ പരീക്ഷിക്കുന്നത് തുടരുകയും പ്രശ്‌നത്തെ സാവധാനം തകർക്കുകയും തടസ്സങ്ങൾ കണ്ടെത്തുകയും ചെയ്യുന്നത് ഒരുപോലെ പ്രധാനമാണ്.

ഇതുപോലുള്ള ഫലങ്ങൾ നേടുന്നതിനുള്ള ഏറ്റവും നല്ല ഭാഗം ശ്രദ്ധേയമായ, ദൃശ്യമായ വേഗത മെച്ചപ്പെടുത്തലാണ് - മുമ്പ് ലോഡ് പോലും ചെയ്യാതിരുന്ന ഒരു റിപ്പോർട്ട് ഇപ്പോൾ ഏതാണ്ട് തൽക്ഷണം ലോഡ് ചെയ്യുന്നു.

പ്രത്യേക നന്ദി എന്റെ സഖാക്കൾ ആദിത്യ മിശ്രയുടെ കൽപ്പനപ്രകാരം, ആദിത്യ ഗൗരു и വരുൺ മൽഹോത്ര മസ്തിഷ്കപ്രക്ഷോഭത്തിനും ദിനകർ പാണ്ഡിർ ഞങ്ങളുടെ അവസാന അഭ്യർത്ഥനയിൽ ഒരു പ്രധാന പിശക് കണ്ടെത്തിയതിന്, ഞങ്ങൾ അതിനോട് വിടപറയും!

അവലംബം: www.habr.com