Jinsi ya kukuza mara 10 idadi ya maswali kwenye hifadhidata bila kuhamia seva yenye tija zaidi na kudumisha utendaji wa mfumo? Nitakuambia jinsi tulivyoshughulikia kushuka kwa utendakazi wa hifadhidata yetu, jinsi tulivyoboresha hoja za SQL ili kuhudumia watumiaji wengi iwezekanavyo na sio kuongeza gharama ya rasilimali za kompyuta.
Ninafanya huduma ya kusimamia michakato ya biashara katika makampuni ya ujenzi. Karibu makampuni elfu 3 hufanya kazi na sisi. Zaidi ya watu elfu 10 hufanya kazi na mfumo wetu kila siku kwa masaa 4-10. Inasuluhisha matatizo mbalimbali ya kupanga, arifa, onyo, uthibitishaji... Tunatumia PostgreSQL 9.6. Tunayo jedwali zipatazo 300 kwenye hifadhidata na hadi maswali milioni 200 (tofauti elfu 10) hupokelewa kila siku. Kwa wastani tuna maombi elfu 3-4 kwa sekunde, kwa wakati unaofanya kazi zaidi ya maombi elfu 10 kwa sekunde. Maswali mengi ni OLAP. Kuna nyongeza chache zaidi, marekebisho na ufutaji, kumaanisha kuwa mzigo wa OLTP ni mwepesi. Nilitoa nambari hizi zote ili uweze kutathmini ukubwa wa mradi wetu na kuelewa jinsi uzoefu wetu unavyoweza kuwa muhimu kwako.
Picha moja. Nyimbo za sauti
Tulipoanza maendeleo, hatukufikiria juu ya aina gani ya mzigo ingeanguka kwenye hifadhidata na tungefanya nini ikiwa seva itaacha kuvuta. Wakati wa kuunda hifadhidata, tulifuata mapendekezo ya jumla na kujaribu kutojipiga risasi kwenye mguu, lakini tulipita ushauri wa jumla kama "usitumie muundo. hatukuingia. Tulibuni kwa kuzingatia kanuni za urekebishaji, kuzuia upunguzaji wa data na hatukujali kuharakisha hoja fulani. Mara tu watumiaji wa kwanza walipowasili, tulikumbana na tatizo la utendakazi. Kama kawaida, hatukuwa tayari kabisa kwa hili. Shida za kwanza ziligeuka kuwa rahisi. Kama sheria, kila kitu kilitatuliwa kwa kuongeza faharisi mpya. Lakini ilikuja wakati ambapo patches rahisi ziliacha kufanya kazi. Kwa kutambua kwamba hatuna uzoefu na inazidi kuwa vigumu kwetu kuelewa kinachosababisha matatizo, tuliajiri wataalamu ambao walitusaidia kusanidi seva kwa usahihi, kuunganisha ufuatiliaji, na kutuonyesha mahali pa kupata. .
Picha ya pili. Takwimu
Kwa hivyo tunayo maswali elfu 10 tofauti ambayo hutekelezwa kwenye hifadhidata yetu kwa siku. Kati ya hizi elfu 10, kuna monsters ambazo hutekelezwa mara milioni 2-3 na wakati wa wastani wa utekelezaji wa 0.1-0.3 ms, na kuna maswali na wakati wa wastani wa utekelezaji wa sekunde 30 ambao huitwa mara 100 kwa siku.
Haikuwezekana kuboresha maswali yote elfu 10, kwa hivyo tuliamua kujua ni wapi pa kuelekeza juhudi zetu ili kuboresha utendakazi wa hifadhidata kwa usahihi. Baada ya marudio kadhaa, tulianza kugawa maombi katika aina.
Maombi ya juu
Haya ndiyo maswali mazito zaidi yanayochukua muda mwingi (jumla ya muda). Haya ni maswali ambayo huitwa mara nyingi sana au maswali ambayo huchukua muda mrefu sana kutekeleza (maswali marefu na ya mara kwa mara yaliboreshwa katika marudio ya kwanza ya mapambano ya kasi). Kama matokeo, seva hutumia wakati mwingi kwenye utekelezaji wao. Zaidi ya hayo, ni muhimu kutenganisha maombi ya juu kwa muda wote wa utekelezaji na tofauti na wakati wa IO. Njia za kuongeza maswali kama haya ni tofauti kidogo.
Mazoezi ya kawaida ya makampuni yote ni kufanya kazi na maombi ya TOP. Kuna chache kati yao; kuboresha hata hoja moja kunaweza kutoa 5-10% ya rasilimali. Hata hivyo, kadri mradi unavyoendelea kukomaa, kuboresha hoja za TOP inakuwa kazi inayozidi kuwa isiyo ya maana. Njia zote rahisi tayari zimefanywa, na ombi "zito" zaidi huchukua "tu" 3-5% ya rasilimali. Ikiwa maswali ya TOP kwa jumla huchukua chini ya 30-40% ya muda, basi kuna uwezekano mkubwa kuwa tayari umefanya jitihada za kuyafanya yafanye kazi haraka na ni wakati wa kuendelea na uboreshaji wa maswali kutoka kwa kikundi kinachofuata.
Inabakia kujibu swali la maswali ngapi ya juu yanapaswa kuingizwa katika kikundi hiki. Kawaida mimi huchukua angalau 10, lakini si zaidi ya 20. Ninajaribu kuhakikisha kwamba wakati wa kwanza na wa mwisho katika kundi la TOP hutofautiana na si zaidi ya mara 10. Hiyo ni, ikiwa wakati wa utekelezaji wa hoja unashuka sana kutoka nafasi ya 1 hadi 10, basi mimi huchukua TOP-10, ikiwa kushuka ni polepole zaidi, basi ninaongeza ukubwa wa kikundi hadi 15 au 20.
Wakulima wa kati
Haya yote ni maombi yanayokuja mara baada ya TOP, isipokuwa ya mwisho 5-10%. Kawaida, katika kuboresha maswali haya kuna fursa ya kuongeza sana utendaji wa seva. Maombi haya yanaweza kuwa na uzito wa hadi 80%. Lakini hata ikiwa sehemu yao imezidi 50%, basi ni wakati wa kuwaangalia kwa makini zaidi.
Mkia
Kama ilivyoelezwa, maswali haya huja mwishoni na huchukua 5-10% ya muda. Unaweza kusahau juu yao ikiwa tu hutumii zana za uchambuzi wa hoja otomatiki, basi kuziboresha kunaweza pia kuwa nafuu.
Jinsi ya kutathmini kila kikundi?
Ninatumia swala la SQL ambalo husaidia kufanya tathmini kama hiyo kwa PostgreSQL (nina uhakika kuwa swali kama hilo linaweza kuandikwa kwa DBMS zingine nyingi)
Hoja ya SQL ya kukadiria ukubwa wa vikundi vya TOP-MEDIUM-TAIL
SELECT sum(time_top) AS sum_top, sum(time_medium) AS sum_medium, sum(time_tail) AS sum_tail
FROM
(
SELECT CASE WHEN rn <= 20 THEN tt_percent ELSE 0 END AS time_top,
CASE WHEN rn > 20 AND rn <= 800 THEN tt_percent ELSE 0 END AS time_medium,
CASE WHEN rn > 800 THEN tt_percent ELSE 0 END AS time_tail
FROM (
SELECT total_time / (SELECT sum(total_time) FROM pg_stat_statements) * 100 AS tt_percent, query,
ROW_NUMBER () OVER (ORDER BY total_time DESC) AS rn
FROM pg_stat_statements
ORDER BY total_time DESC
) AS t
)
AS ts
Matokeo ya hoja ni safu wima tatu, ambayo kila moja ina asilimia ya muda inachukua kuchakata maswali kutoka kwa kikundi hiki. Ndani ya ombi kuna nambari mbili (kwa upande wangu ni 20 na 800) ambazo hutenganisha maombi kutoka kwa kundi moja kutoka kwa lingine.
Hivi ndivyo jinsi hisa za maombi zinalinganishwa wakati kazi ya uboreshaji ilianza na sasa.
Mchoro unaonyesha kuwa sehemu ya maombi ya TOP imepungua sana, lakini "wakulima wa kati" wameongezeka.
Mwanzoni, maombi ya TOP yalijumuisha makosa ya wazi. Baada ya muda, magonjwa ya utoto yalipotea, sehemu ya maombi ya TOP ilipungua, na jitihada zaidi na zaidi zilipaswa kufanywa ili kuharakisha maombi magumu.
Ili kupata maandishi ya maombi tunatumia ombi lifuatalo
SELECT * FROM (
SELECT ROW_NUMBER () OVER (ORDER BY total_time DESC) AS rn, total_time / (SELECT sum(total_time) FROM pg_stat_statements) * 100 AS tt_percent, query
FROM pg_stat_statements
ORDER BY total_time DESC
) AS T
WHERE
rn <= 20 -- TOP
-- rn > 20 AND rn <= 800 -- MEDIUM
-- rn > 800 -- TAIL
Hapa kuna orodha ya mbinu zinazotumiwa sana ambazo zilitusaidia kuharakisha maswali ya TOP:
- Usanifu upya wa mfumo, kwa mfano, kurekebisha mantiki ya arifa kwa kutumia wakala wa ujumbe badala ya maswali ya mara kwa mara kwenye hifadhidata.
- Kuongeza au kubadilisha faharasa
- Kuandika upya maswali ya ORM kwa SQL safi
- Kuandika upya mantiki ya upakiaji wa data mvivu
- Uakibishaji kupitia urekebishaji wa data. Kwa mfano, tunayo Uwasilishaji wa muunganisho wa jedwali -> Ankara -> Ombi -> Maombi. Hiyo ni, kila utoaji unahusishwa na programu kupitia meza nyingine. Ili tusiunganishe jedwali zote katika kila ombi, tulinakili kiungo cha ombi kwenye jedwali la Uwasilishaji.
- Kuhifadhi jedwali tuli na vitabu vya marejeleo na mara chache kubadilisha meza kwenye kumbukumbu ya programu.
Wakati mwingine mabadiliko yalifikia uundaji upya wa kuvutia, lakini walitoa 5-10% ya mzigo wa mfumo na walihesabiwa haki. Baada ya muda, kutolea nje ikawa ndogo na ndogo, na upya zaidi na zaidi ulihitajika.
Kisha tukaelekeza mawazo yetu kwa kundi la pili la maombi - kundi la wakulima wa kati. Kuna maswali mengi zaidi ndani yake na ilionekana kuwa ingechukua muda mwingi kuchanganua kikundi kizima. Walakini, maswali mengi yaligeuka kuwa rahisi sana kuboresha, na shida nyingi zilirudiwa mara kadhaa katika tofauti tofauti. Hapa kuna mifano ya uboreshaji wa kawaida ambao tulituma kwa hoja nyingi sawa na kila kikundi cha maswali yaliyoboreshwa kilipakua hifadhidata kwa 3-5%.
- Badala ya kuangalia uwepo wa rekodi kwa kutumia COUNT na skanisho kamili ya jedwali, EXISTS ilianza kutumika
- Kuondoa DISTINCT (hakuna mapishi ya jumla, lakini wakati mwingine unaweza kuiondoa kwa urahisi kwa kuharakisha ombi kwa mara 10-100).
Kwa mfano, badala ya hoja ya kuchagua viendeshaji vyote kutoka kwa jedwali kubwa la usafirishaji (DELIVERY)
SELECT DISTINCT P.ID, P.FIRST_NAME, P.LAST_NAME FROM DELIVERY D JOIN PERSON P ON D.DRIVER_ID = P.IDaliuliza swali kwenye jedwali dogo kiasi PERSON
SELECT P.ID, P.FIRST_NAME, P.LAST_NAME FROM PERSON WHERE EXISTS(SELECT D.ID FROM DELIVERY WHERE D.DRIVER_ID = P.ID)Inaweza kuonekana kuwa tulitumia hoja ndogo iliyounganishwa, lakini inatoa kasi ya zaidi ya mara 10.
- Mara nyingi, COUNT iliachwa kabisa na
- badala ya
UPPER(s) LIKE JOHN%βtumia
s ILIKE βJohn%β
Kila ombi maalum wakati mwingine liliharakishwa kwa mara 3-1000. Licha ya utendakazi wa kuvutia, mwanzoni ilionekana kwetu kuwa hakuna haja ya kuboresha hoja ambayo inachukua 10 ms kukamilika, ni mojawapo ya hoja mia tatu nzito zaidi, na inachukua mia moja ya asilimia ya muda wa jumla wa upakiaji wa hifadhidata. Lakini kwa kutumia kichocheo sawa kwa kikundi cha maswali ya aina moja, tulishinda asilimia chache. Ili tusipoteze muda kukagua mwenyewe mamia ya hoja, tuliandika hati kadhaa rahisi ambazo zilitumia misemo ya kawaida kupata maswali ya aina moja. Kwa hivyo, kutafuta kiotomatiki vikundi vya hoja kulituruhusu kuboresha zaidi utendakazi wetu kwa juhudi za kawaida.
Kwa hivyo, tumekuwa tukifanya kazi kwenye vifaa sawa kwa miaka mitatu sasa. Mzigo wa kila siku wa wastani ni karibu 30%, katika kilele hufikia 70%. Idadi ya maombi, pamoja na idadi ya watumiaji, imeongezeka takriban mara 10. Na shukrani hii yote kwa ufuatiliaji wa mara kwa mara wa vikundi hivi vya maombi ya TOP-MEDIUM. Mara tu ombi jipya linapoonekana kwenye kikundi cha TOP, tunachambua mara moja na kujaribu kuharakisha. Tunakagua kikundi cha MEDIUM mara moja kwa wiki kwa kutumia hati za uchanganuzi wa hoja. Tukikutana na maswali mapya ambayo tayari tunajua jinsi ya kuboresha, tunayabadilisha haraka. Wakati mwingine tunapata mbinu mpya za uboreshaji ambazo zinaweza kutumika kwa hoja kadhaa mara moja.
Kulingana na utabiri wetu, seva ya sasa itahimili ongezeko la idadi ya watumiaji kwa mara nyingine 3-5. Kweli, tuna ace moja zaidi juu ya sleeve yetu - bado hatujahamisha maswali CHAGUA kwenye kioo, kama inavyopendekezwa. Lakini hatufanyi hivi kwa uangalifu, kwa sababu tunataka kwanza kumaliza kabisa uwezekano wa uboreshaji wa "smart" kabla ya kuwasha "artillery nzito".
Kuangalia kwa umakini kazi iliyofanywa kunaweza kupendekeza kutumia kuongeza wima. Nunua seva yenye nguvu zaidi badala ya kupoteza wakati wa wataalamu. Seva inaweza isigharimu kiasi hicho, haswa kwa vile bado hatujamaliza kikomo cha kuongeza wima. Walakini, idadi ya maombi pekee iliongezeka mara 10. Kwa kipindi cha miaka kadhaa, utendaji wa mfumo umeongezeka na sasa kuna aina zaidi za maombi. Shukrani kwa uakibishaji, utendakazi uliokuwepo unatekelezwa kwa maombi machache, na maombi yenye ufanisi zaidi. Hii inamaanisha kuwa unaweza kuzidisha kwa 5 nyingine kwa usalama ili kupata mgawo halisi wa kuongeza kasi. Kwa hiyo, kulingana na makadirio ya kihafidhina zaidi, tunaweza kusema kwamba kuongeza kasi ilikuwa mara 50 au zaidi. Kuzungusha seva kiwima kunaweza kugharimu mara 50 zaidi. Hasa kwa kuzingatia kwamba mara moja uboreshaji unafanywa hufanya kazi wakati wote, na muswada wa seva iliyokodishwa huja kila mwezi.
Chanzo: mapenzi.com