Bag-ohay lang gisultihan ko ikaw kung giunsa, gamit ang standard nga mga resipe gikan sa database sa PostgreSQL. Karon kita maghisgot kon sa unsang paagi ang pagrekord mahimo nga mas episyente sa database nga wala gigamit ang bisan unsang "twists" sa config - pinaagi lang sa husto nga pag-organisar sa mga agos sa datos.
#1. Pagbahinbahin
Usa ka artikulo bahin sa kung giunsa ug ngano nga kini takus sa pag-organisar na, dinhi kita maghisgot mahitungod sa praktis sa paggamit sa pipila ka mga paagi sa sulod sa atong .
"Mga butang sa mga adlaw nga milabay..."
Sa sinugdanan, sama sa bisan unsa nga MVP, ang among proyekto nagsugod ubos sa usa ka medyo gaan nga load - ang pagmonitor gihimo lamang alang sa napulo ka labing kritikal nga mga server, ang tanan nga mga lamesa medyo compact... Apan sa paglabay sa panahon, ang gidaghanon sa gimonitor nga mga host nahimong mas ug mas , ug sa makausa pa misulay kami sa pagbuhat og usa ka butang sa usa sa mga lamesa nga 1.5TB ang gidak-on, naamgohan namo nga bisan tuod posible nga magpadayon sa pagkinabuhi nga sama niini, kini dili kombenyente.
Ang mga panahon halos sama sa epiko nga mga panahon, lain-laing mga bersyon sa PostgreSQL 9.x may kalabutan, mao nga ang tanan nga partitioning kinahanglan nga buhaton "manual" - pinaagi sa table inheritance ug triggers routing uban sa dinamikong EXECUTE.
Ang resulta nga solusyon nahimo nga unibersal nga igo nga kini mahubad sa tanan nga mga lamesa:
- Usa ka walay sulod nga lamesa sa ginikanan nga "header" ang gideklarar, nga naghulagway sa tanan gikinahanglan nga mga indeks ug mga trigger.
- Ang rekord gikan sa punto sa panglantaw sa kliyente gihimo sa "gamut" nga lamesa, ug gigamit sa sulod routing trigger
BEFORE INSERTang rekord "pisikal" gisulod sa gikinahanglan nga seksyon. Kung wala pa, nakakuha kami usa ka eksepsiyon ug ... - β¦ pinaagi sa paggamit gimugna base sa template sa parent table seksyon nga adunay pagdili sa gusto nga petsaaron kung makuha ang datos, ang pagbasa gihimo lamang niini.
PG10: unang pagsulay
Apan ang pagbahin pinaagi sa kabilin sa kasaysayan dili haom sa pag-atubang sa usa ka aktibo nga sapa sa pagsulat o daghang gidaghanon sa mga partisyon sa bata. Pananglitan, mahinumduman nimo nga ang algorithm sa pagpili sa gikinahanglan nga seksyon adunay quadratic nga pagkakomplikado, nga kini magamit sa 100+ ka mga seksyon, ikaw mismo nakasabut kung giunsa...
Sa PG10 kini nga sitwasyon na-optimize pag-ayo pinaagi sa pagpatuman sa suporta . Busa, gisulayan dayon namon nga i-apply kini dayon pagkahuman sa pagbalhin sa pagtipig, apan ...
Ingon nga kini nahimo pagkahuman sa pagkalot sa manwal, ang lumad nga partitioned nga lamesa sa kini nga bersyon mao ang:
- wala nagsuporta sa mga paghulagway sa indeks
- wala nagsuporta sa mga trigger niini
- dili mahimong "kaliwat" ni bisan kinsa
- ayaw pagsuporta
INSERT ... ON CONFLICT - dili makamugna og seksyon nga awtomatiko
Nakadawat usa ka masakit nga pagbunal sa agtang gamit ang usa ka rake, nahibal-an namon nga imposible nga buhaton nga walaβy pagbag-o sa aplikasyon, ug gi-post ang dugang nga panukiduki sa unom ka bulan.
PG10: ikaduhang higayon
Busa, nagsugod kami sa pagsulbad sa mga problema nga mitumaw sa tinagsa:
- Kay trigger ug
ON CONFLICTAmong nakaplagan nga gikinahanglan pa namo sila dinhi ug didto, mao nga naghimo kami ug intermediate stage aron masulbad kini proxy nga lamesa. - Giwagtang ang "routing" sa triggers - nga mao, gikan sa
EXECUTE. - Gilain nila kini lamesa sa template nga adunay tanan nga mga indeksaron dili sila naa sa proxy nga lamesa.
Sa katapusan, pagkahuman niining tanan, gibahin namon ang panguna nga lamesa nga lumad. Ang paghimo og bag-ong seksyon gibilin gihapon sa konsensya sa aplikasyon.
Mga diksyonaryo nga "Sawing".
Sama sa bisan unsang analytical system, aduna usab kami "mga kamatuoran" ug "pagputol" (mga diksyonaryo). Sa among kaso, sa kini nga kapasidad sila milihok, pananglitan, parehas nga hinay nga mga pangutana o ang teksto sa pangutana mismo.
Ang "Mga Kamatuoran" gibahin sa adlaw sa dugay na nga panahon, mao nga kalmado namong gitangtang ang mga karaan na nga seksyon, ug wala nila kami gisamok (mga log!). Apan adunay problema sa mga diksyonaryo...
Dili sa pag-ingon nga adunay daghan kanila, apan gibana-bana Ang 100TB sa "mga kamatuoran" miresulta sa 2.5TB nga diksyonaryo. Dili nimo mapapas ang bisan unsang butang gikan sa ingon nga lamesa, dili nimo kini ma-compress sa igo nga oras, ug ang pagsulat niini hinayhinay nga nahimong hinay.
Sama sa usa ka diksyonaryo ... niini, ang matag entry kinahanglan nga ipresentar sa tukma kausa ... ug kini husto, apan!.. Walay makapugong kanato sa pagbaton usa ka lahi nga diksyonaryo alang sa matag adlaw! Oo, kini nagdala sa usa ka piho nga redundancy, apan kini nagtugot:
- pagsulat/pagbasa nga mas paspas tungod sa gamay nga gidak-on sa seksyon
- ubos nga memorya pinaagi sa pagtrabaho uban sa mas compact index
- pagtipig gamay nga datos tungod sa abilidad sa dali nga pagtangtang outdated
Ingon usa ka sangputanan sa tibuuk nga komplikado nga mga lakang CPU load mikunhod sa ~30%, disk load sa ~50%:
Sa parehas nga oras, nagpadayon kami sa pagsulat sa parehas nga butang sa database, nga adunay gamay nga load.
#2. Ang ebolusyon sa database ug refactoring
So nagsettle mi kung unsa naa namo kada adlaw naay kaugalingong section uban sa datos. Sa tinuod lang, CHECK (dt = '2018-10-12'::date) β ug adunay usa ka yawe sa partitioning ug ang kondisyon alang sa usa ka rekord nga mahulog sa usa ka piho nga seksyon.
Tungod kay ang tanan nga mga taho sa among serbisyo gitukod sa konteksto sa usa ka piho nga petsa, ang mga indeks alang kanila sukad sa "mga panahon nga wala gibahin" tanan nga mga tipo (Server, Petsa, Plano nga Template), (Server, Petsa, Plano nga node), (Petsa, Sayop nga klase, Server), ...
Apan karon sila nagpuyo sa matag seksyon imong mga kopya matag ingon nga indeks... Ug sulod sa matag seksyon ang petsa mao ang kanunay... Kini nahimo nga karon naa na kita sa matag ingon nga indeks pagsulod lang sa usa ka kanunay isip usa sa mga natad, nga nagdugang sa gidaghanon niini ug sa panahon sa pagpangita niini, apan wala magdala sa bisan unsa nga resulta. Gibiyaan nila ang rake sa ilang kaugalingon, oops ...
Ang direksyon sa pag-optimize klaro - yano kuhaa ang field sa petsa gikan sa tanang mga index sa gibahin nga mga lamesa. Tungod sa among mga volume, ang ganansya hapit na 1TB/semana!
Karon atong timan-an nga kini nga terabyte kinahanglan pa nga irekord sa usa ka paagi. Sa ato pa, kami usab ang disk kinahanglan karon nga magkarga gamay! Kini nga litrato tin-aw nga nagpakita sa epekto nga nakuha gikan sa paglimpyo, diin among gigahin usa ka semana:
#3. "Pagpakaylap" sa peak load
Usa sa mga dagkong problema sa loaded system mao ang sobra nga pag-synchronize pipila ka mga operasyon nga wala magkinahanglan niini. Usahay "tungod kay wala sila makamatikod", usahay "mas sayon ββββnga paagiha", apan sa madugay o sa madali kinahanglan nimo nga kuhaon kini.
Atong i-zoom in sa miaging litrato ug tan-awon nga kita adunay usa ka disk "mga bomba" ubos sa load nga adunay double amplitude tali sa kasikbit nga mga sampol, nga tin-aw nga "istatistika" kinahanglan dili mahitabo sa ingon nga daghang mga operasyon:
Kini sayon ββββkaayo nga makab-ot. Gisugdan na namo ang pagmonitor hapit 1000 server, ang matag usa giproseso sa usa ka bulag nga lohikal nga hilo, ug ang matag hilo nag-reset sa natipon nga impormasyon nga ipadala sa database sa usa ka piho nga frequency, sama niini:
setInterval(sendToDB, interval)Ang problema dinhi anaa sa tukma sa kamatuoran nga tanan nga mga hilo magsugod sa gibana-bana nga parehas nga oras, mao nga ang ilang mga oras sa pagpadala halos kanunay nga motakdo βsa punto.β Oops #2...
Maayo na lang, kini dali nga ayohon, pagdugang og "random" run-up sa oras:
setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))#4. Gitago namo ang among gikinahanglan
Ang ikatulo nga tradisyonal nga problema sa highload mao ang walay cache asa siya mahimo nga mahimo
Pananglitan, gihimo namon nga posible ang pag-analisar sa mga termino sa mga node sa plano (tanan kini Seq Scan on users), apan hunahunaa dayon nga sila, sa kadaghanan, parehas - nakalimtan nila.
Dili, siyempre, wala'y gisulat sa database pag-usab, kini nagputol sa gatilyo sa INSERT ... ON CONFLICT DO NOTHING. Apan kini nga datos nakaabot gihapon sa database, ug kini wala kinahanglana pagbasa aron masusi ang panagbangi kinahanglan buhaton. Oops #3...
Ang kalainan sa gidaghanon sa mga rekord nga gipadala sa database sa wala pa / pagkahuman sa pag-caching klaro:
Ug kini ang nag-uban nga pagkunhod sa load sa pagtipig:
Total
Ang "Terabyte-per-day" makahadlok lang. Kung buhaton nimo ang tanan nga husto, nan kini makatarunganon 2^40 bytes / 86400 seconds = ~12.5MB/snga bisan ang desktop IDE screws gihuptan. π
Apan seryoso, bisan pa sa usa ka napulo ka pilo nga "skew" sa load sa panahon sa adlaw, kamo sa dali rang makab-ot ang mga kapabilidad sa modernong SSDs.
Source: www.habr.com