Nýlega sagði ég þér hvernig, með því að nota venjulegar uppskriftir úr PostgreSQL gagnagrunni. Í dag munum við tala um hvernig upptöku er hægt að gera á skilvirkari hátt í gagnagrunninum án þess að nota „snúninga“ í stillingunni - einfaldlega með því að skipuleggja gagnaflæðina rétt.
#1. Skipting
Grein um hvernig og hvers vegna það er þess virði að skipuleggja hefur þegar verið, hér munum við tala um framkvæmdina við að beita nokkrum aðferðum innan okkar .
"Hlutir liðinna daga..."
Upphaflega, eins og allir MVP, byrjaði verkefnið okkar undir frekar léttu álagi - eftirlit var aðeins framkvæmt fyrir tíu mikilvægustu netþjónana, allar töflur voru tiltölulega þéttar... En eftir því sem á leið varð fjöldi vöktuðu gestgjafanna fleiri og fleiri , og enn og aftur reyndum við að gera eitthvað með einum af borð 1.5TB að stærð, komumst að því að þó það væri hægt að halda svona áfram að búa þá var það mjög óþægilegt.
Tímarnir voru næstum eins og epískir tímar, mismunandi útgáfur af PostgreSQL 9.x áttu við, þannig að öll skipting varð að fara fram „handvirkt“ - í gegnum borðarfur og kveikjur vegvísun með dynamic EXECUTE.
Lausnin sem fékkst reyndist vera nógu alhliða til að hægt væri að þýða hana á allar töflur:
- Tóm „haus“ foreldratafla var lýst yfir, sem lýsti öllu nauðsynlegar vísitölur og kveikjur.
- Skráin frá sjónarhóli viðskiptavinarins var gerð í „rót“ töflunni og innbyrðis með því að nota leiðarvísun
BEFORE INSERTskráin var „líkamlega“ sett inn í nauðsynlegan hluta. Ef það var ekkert slíkt ennþá lentum við í undantekningu og... - … með því að nota var búið til á grundvelli sniðmáts móðurtöflunnar kafla með takmörkun á æskilegri dagsetninguþannig að þegar gögn eru sótt fer eingöngu fram lestur í þeim.
PG10: fyrsta tilraun
En skipting í gegnum arf hefur í gegnum tíðina ekki verið vel til þess fallin að takast á við virkan skrifstraum eða mikinn fjölda barnaskila. Til dæmis geturðu muna að reikniritið til að velja nauðsynlegan hluta hafði ferningsflækjustig, að það virki með 100+ köflum, þú skilur sjálfur hvernig...
Í PG10 var þetta ástand mjög fínstillt með því að innleiða stuðning . Þess vegna reyndum við strax að nota það strax eftir að hafa flutt geymsluna, en...
Eins og það kom í ljós eftir að hafa grafið í gegnum handbókina er innbyggða skipta taflan í þessari útgáfu:
- styður ekki vísitölulýsingar
- styður ekki kveikjur á því
- getur ekki verið "afkomandi" neins
- styðja ekki
INSERT ... ON CONFLICT - getur ekki búið til hluta sjálfkrafa
Eftir að hafa fengið sársaukafullt högg á ennið með hrífu, áttuðum við okkur á að það væri ómögulegt að gera án þess að breyta umsókninni og frestuðum frekari rannsóknum um sex mánuði.
PG10: annað tækifæri
Svo fórum við að leysa vandamálin sem komu upp eitt af öðru:
- Vegna þess að kveikir og
ON CONFLICTVið komumst að því að okkur vantaði þær enn hér og þar, svo við gerðum millistig til að vinna úr þeim proxy töflu. - Losaðu þig við "leiða" í kveikjum - það er frá
EXECUTE. - Þeir tóku það út sérstaklega sniðmáttöflu með öllum vísitölumþannig að þeir eru ekki einu sinni til staðar í umboðstöflunni.
Að lokum, eftir allt þetta, skiptum við aðaltöflunni inn á innfæddan hátt. Stofnun nýs hluta er enn eftir samvisku umsóknarinnar.
„Söga“ orðabækur
Eins og í hverju greiningarkerfi, höfðum við líka „staðreyndir“ og „niðurskurðir“ (orðabækur). Í okkar tilviki, í þessu hlutverki, virkuðu þeir td. svipaðar hægar fyrirspurnir eða texti fyrirspurnarinnar sjálfrar.
„Staðreyndir“ voru nú þegar skipt niður eftir degi í langan tíma, svo við eyddum rólegum úreltum köflum og þeir trufluðu okkur ekki (skrár!). En það var vandamál með orðabækur...
Ekki að segja að þeir hafi verið margir, en um það bil 100TB af „staðreyndum“ leiddu til 2.5TB orðabók. Þú getur ekki eytt neinu á þægilegan hátt úr slíkri töflu, þú getur ekki þjappað henni saman á hæfilegum tíma og skrif á hana varð smám saman hægari.
Eins og orðabók... í henni ætti hver færsla að vera sett fram nákvæmlega einu sinni... og þetta er rétt, en!.. Enginn kemur í veg fyrir að við höfum sérstaka orðabók fyrir hvern dag! Já, þetta leiðir til ákveðinnar offramboðs, en það gerir:
- skrifa/lesa hraðar vegna minni hlutastærðar
- neyta minna minni með því að vinna með þéttari vísitölum
- geyma minni gögn vegna getu til að fjarlægja gamaldags
Sem afleiðing af öllu flóknu ráðstafana Örgjörvaálag minnkaði um ~30%, diskálag um ~50%:
Á sama tíma héldum við áfram að skrifa nákvæmlega það sama inn í gagnagrunninn, bara með minna álagi.
#2. Gagnagrunnsþróun og endurþáttun
Svo við sættum okkur við það sem við höfum hver dagur hefur sinn hluta með gögnum. Reyndar, CHECK (dt = '2018-10-12'::date) — og það er skiptingarlykill og skilyrði fyrir því að skrá falli í ákveðinn hluta.
Þar sem allar skýrslur í þjónustu okkar eru smíðaðar í samhengi við ákveðna dagsetningu, hafa vísitölur fyrir þær frá „óskiptan tíma“ verið allar gerðir (Þjónn, Dagsetning, Áætlunarsniðmát), (Þjónn, Dagsetning, áætlunarhnút), (Dagsetning, Villuflokkur, Server), ...
En nú búa þeir á hverjum kafla eintökin þín hver slík vísitala... Og innan hvers hluta dagsetning er fasti... Það kemur í ljós að nú erum við í hverri slíkri vísitölu einfaldlega sláðu inn fasta sem einn af reitunum, sem eykur bæði rúmmál þess og leitartíma fyrir það, en skilar engum árangri. Þeir létu hrífuna eftir fyrir sig, úps...
Stefna hagræðingar er augljós - einföld fjarlægðu dagsetningarreitinn úr öllum vísitölum á skiptu borðum. Miðað við magn okkar er ávinningurinn um 1TB á viku!
Nú skulum við athuga að þetta terabæt þurfti samt að vera skráð einhvern veginn. Það er, við líka diskurinn ætti nú að hlaðast minna! Þessi mynd sýnir greinilega áhrifin sem fást af hreinsuninni, sem við helguðum viku:
#3. „Dreifa“ hámarksálagi
Eitt af stóru vandamálunum við hlaðin kerfi er óþarfa samstillingu sumar aðgerðir sem krefjast þess ekki. Stundum "af því að þeir tóku ekki eftir því", stundum "það var auðveldara þannig", en fyrr eða síðar verður þú að losa þig við það.
Við skulum þysja inn á fyrri mynd og sjá að við erum með disk „dælur“ undir álaginu með tvöföldu amplitude milli aðliggjandi sýna, sem greinilega „tölfræðilega“ ætti ekki að gerast með slíkum fjölda aðgerða:
Þetta er frekar auðvelt að ná. Við erum þegar byrjuð að fylgjast með næstum 1000 netþjónar, hver er unnin af sérstökum rökréttum þræði og hver þráður endurstillir uppsafnaðar upplýsingar sem á að senda í gagnagrunninn á ákveðinni tíðni, eitthvað á þessa leið:
setInterval(sendToDB, interval)Vandamálið hér liggur einmitt í því að allir þræðir byrja á nokkurn veginn sama tíma, þannig að sendingartímar þeirra falla næstum alltaf „að marki“. Úps #2...
Sem betur fer er auðvelt að laga þetta, að bæta við „handahófi“ aðdraganda eftir tíma:
setInterval(sendToDB, interval * (1 + 0.1 * (Math.random() - 0.5)))#4. Við vistum það sem við þurfum
Þriðja hefðbundna háhleðsluvandamálið er ekkert skyndiminni hvar hann er gæti að vera.
Til dæmis gerðum við mögulegt að greina hvað varðar áætlunarhnúta (allt þetta Seq Scan on users), en hugsa strax að þeir séu að mestu leyti eins - þeir gleymdu.
Nei, auðvitað er ekkert skrifað í gagnagrunninn aftur, þetta slítur kveikjuna með INSERT ... ON CONFLICT DO NOTHING. En þessi gögn ná samt til gagnagrunnsins og þau eru óþörf lestur til að athuga hvort átök séu verð að gera. Úps #3...
Munurinn á fjölda færslur sem sendar eru í gagnagrunninn fyrir/eftir að skyndiminni er virkjað er augljós:
Og þetta er meðfylgjandi lækkun á geymsluálagi:
Alls
„Terabæti á dag“ hljómar bara skelfilegt. Ef þú gerir allt rétt, þá er þetta bara 2^40 bæti / 86400 sekúndur = ~12.5MB/sað jafnvel borðtölvu IDE skrúfur héldu. 🙂
En í alvöru, jafnvel með tífalt „skekkju“ á álaginu yfir daginn, geturðu auðveldlega mætt getu nútíma SSD-diska.
Heimild: www.habr.com