{"id":35259,"date":"2019-10-31T22:03:17","date_gmt":"2019-10-31T19:03:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/istoriya-odnogo-sql-rassledovaniya\/"},"modified":"2019-10-31T22:03:17","modified_gmt":"2019-10-31T19:03:17","slug":"istoriya-odnogo-sql-rassledovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/istoriya-odnogo-sql-rassledovaniya","title":{"rendered":"Historien om en SQL-utredning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I december f\u00f6rra \u00e5ret fick jag en intressant felrapport fr\u00e5n VWO-supportteamet. Laddningstiden f\u00f6r en av de analytiska rapporterna f\u00f6r en stor f\u00f6retagsklient verkade orimligt l\u00e5ng. Eftersom det \u00e4r mitt ansvarsomr\u00e5de fokuserade jag genast p\u00e5 att l\u00f6sa problemet.<\/p>\n

<\/p>\n

Bakgrund<\/h2>\n

<\/p>\n

F\u00f6r att klarg\u00f6ra vad det handlar om, ska jag kort s\u00e4ga n\u00e5gra ord om VWO. Det \u00e4r en plattform som g\u00f6r det m\u00f6jligt att k\u00f6ra olika riktade kampanjer p\u00e5 sina webbplatser: genomf\u00f6ra A\/B-experiment, sp\u00e5ra bes\u00f6kare och konverteringar, g\u00f6ra analys av f\u00f6rs\u00e4ljningstratten, visa v\u00e4rmekartor och spela upp bes\u00f6ksinspelningar.<\/p>\n

<\/p>\n

Men det viktigaste med plattformen \u00e4r rapportgenerering. Alla ovanst\u00e5ende funktioner \u00e4r kopplade till varandra. F\u00f6r f\u00f6retag \u00e4r en stor m\u00e4ngd information praktiskt taget v\u00e4rdel\u00f6s utan en kraftfull plattform som presenterar den f\u00f6r analys.<\/p>\n

<\/p>\n

Genom att anv\u00e4nda plattformen kan man g\u00f6ra skr\u00e4ddarsydda f\u00f6rfr\u00e5gningar p\u00e5 stora datam\u00e4ngder. H\u00e4r \u00e4r ett enkelt exempel:<\/p>\n

<\/p>\n

Visa alla klick p\u00e5 sidan \"abc.com\"\nFR\u00c5N <datum d1> TILL <datum d2>\nf\u00f6r personer som\nanv\u00e4nt Chrome ELLER\n(varit i Europa OCH anv\u00e4nt iPhone)<\/pre>\n
<\/p>\n
Observera de booleska operatorerna. De \u00e4r tillg\u00e4ngliga f\u00f6r kunder i f\u00f6rfr\u00e5gningsgr\u00e4nssnittet f\u00f6r att g\u00f6ra hur komplexa f\u00f6rfr\u00e5gningar som helst f\u00f6r att f\u00e5 utvalda data.<\/p>\n
<\/p>\n
L\u00e5ngsam f\u00f6rfr\u00e5gan<\/h2>\n
<\/p>\n
Klienten det handlar om f\u00f6rs\u00f6kte g\u00f6ra n\u00e5got som intuitivt borde g\u00e5 snabbt:<\/p>\n
<\/p>\n
Visa alla sessioner\nf\u00f6r anv\u00e4ndare som bes\u00f6kt vilken sida som helst\nmed en URL som inneh\u00e5ller \"\\\/jobs\"<\/pre>\n
<\/p>\n
Denna webbplats hade en enorm m\u00e4ngd trafik och vi hade lagrat \u00f6ver en miljon unika URL-adresser bara f\u00f6r den. De ville hitta en ganska enkel mall av URL:er relaterad till deras aff\u00e4rsmodell.<\/p>\n
\n<\/a><\/noindex><\/p>\n
Prelimin\u00e4r utredning<\/h2>\n
<\/p>\n
L\u00e5t oss titta p\u00e5 vad som h\u00e4nder i databasen. H\u00e4r \u00e4r den ursprungliga l\u00e5ngsamma SQL-fr\u00e5gan:<\/p>\n
<\/p>\n
SELECT \n    count(*) \nFROM \n    acc_{account_id}.urls as recordings_urls, \n    acc_{account_id}.recording_data as recording_data, \n    acc_{account_id}.sessions as sessions \nWHERE \n    recording_data.usp_id = sessions.usp_id \n    AND sessions.referrer_id = recordings_urls.id \n    AND  (  urls &&  array(select id from acc_{account_id}.urls where url  ILIKE  '%enterprise_customer.com\\\/jobs%')::text[]   ) \n    AND r_time > to_timestamp(1542585600) \n    AND r_time < to_timestamp(1545177599) \n    AND recording_data.duration >=5 \n    AND recording_data.num_of_pages > 0 ;<\/code><\/pre>\n
<\/p>\n
H\u00e4r \u00e4r tiderna:<\/p>\n
<\/p>\n
Ber\u00e4knad tid: 1.480 ms\nExekveringstid: 1431924.650 ms<\/pre>\n
<\/p>\n
Fr\u00e5gan gick igenom 150 000 rader. Fr\u00e5geschemal\u00e4ggaren visade n\u00e5gra intressanta detaljer, men inga uppenbara flaskhalsar.<\/p>\n
<\/p>\n
L\u00e5t oss studera fr\u00e5gan vidare. Som vi kan se g\u00f6r den JOIN<\/code> tre tabeller:<\/p>\n
<\/p>\n
    \n
  1. sessions<\/strong>: f\u00f6r att visa sessionsinformation: webbl\u00e4sare, anv\u00e4ndaragenter, land och s\u00e5 vidare.<\/li>\n
  2. recording_data<\/strong>: inspelade URL:er, sidor, bes\u00f6kens varaktighet<\/li>\n
  3. urls<\/strong>: f\u00f6r att undvika duplicering av extremt stora URL:er, lagrar vi dem i en separat tabell.<\/li>\n<\/ol>\n
    <\/p>\n
    Observera ocks\u00e5 att alla v\u00e5ra tabeller redan \u00e4r partitionerade efter account_id<\/code>. P\u00e5 s\u00e5 s\u00e4tt utesluts situationen d\u00e4r ett s\u00e4rskilt stort konto orsakar problem f\u00f6r andra.<\/p>\n
    <\/p>\n
    I jakt p\u00e5 ledtr\u00e5dar<\/h2>\n
    <\/p>\n
    Vid en n\u00e4rmare granskning ser vi att n\u00e5got \u00e4r fel med den specifika fr\u00e5gan. Det \u00e4r v\u00e4rt att titta p\u00e5 denna rad:<\/p>\n
    <\/p>\n
    urls && array(\n\tselect id from acc_{account_id}.urls \n\twhere url ILIKE '%enterprise_customer.com\/jobs%'\n)::text[]<\/code><\/pre>\n
    <\/p>\n
    Den f\u00f6rsta tanken var att det kanske berodde p\u00e5 ILIKE<\/code> p\u00e5 alla dessa l\u00e5nga URL:er (vi har mer \u00e4n 1,4 miljoner unika\u00a0<\/strong>URL-adresser som samlades in f\u00f6r detta konto) kanske prestandan kunde p\u00e5verkas.<\/p>\n
    <\/p>\n
    Men, nej - det \u00e4r inte det!<\/p>\n
    <\/p>\n
    SELECT id FROM urls WHERE url ILIKE '%enterprise_customer.com\/jobs%';\n  id\n--------\n ...\n(198661 rader)\n\nTid: 5231.765 ms<\/code><\/pre>\n
    <\/p>\n
    Sj\u00e4lva s\u00f6kfr\u00e5gan tar bara 5 sekunder. S\u00f6kningen efter m\u00f6nster p\u00e5 en miljon unika URL:er \u00e4r uppenbarligen inte ett problem.<\/p>\n
    <\/p>\n
    N\u00e4sta misst\u00e4nkte p\u00e5 listan - flera JOIN<\/code>. Kanske deras \u00f6verdrivna anv\u00e4ndning ledde till en nedg\u00e5ng? Vanligtvis JOIN<\/code>\u2019e \u00e4r de mest uppenbara kandidaterna f\u00f6r prestandaproblem, men jag trodde inte att v\u00e5rt fall var typiskt.<\/p>\n
    <\/p>\n
    analytics_db=# SELECT\n    count(*)\nFROM\n    acc_{account_id}.urls as recordings_urls,\n    acc_{account_id}.recording_data_0 as recording_data,\n    acc_{account_id}.sessions_0 as sessions\nWHERE\n    recording_data.usp_id = sessions.usp_id\n    AND sessions.referrer_id = recordings_urls.id\n    AND r_time > to_timestamp(1542585600)\n    AND r_time =5\n    AND recording_data.num_of_pages > 0 ;\n count\n-------\n  8086\n(1 rad)\n\nTid: 147.851 ms<\/code><\/pre>\n
    <\/p>\n
    Och det var heller inte v\u00e5rt fall. JOIN<\/code>\u2019e visade sig vara ganska snabba.<\/p>\n
    <\/p>\n
    Vi smalnar av cirkeln av misst\u00e4nkta<\/h2>\n
    <\/p>\n
    Jag var redo att b\u00f6rja \u00e4ndra fr\u00e5gan f\u00f6r att uppn\u00e5 eventuella prestandaf\u00f6rb\u00e4ttringar. Vi i teamet utvecklade 2 huvudid\u00e9er:<\/p>\n
    <\/p>\n