Þar sem ClickHouse er sérhæft kerfi, þegar það er notað er mikilvægt að taka tillit til eiginleika arkitektúrsins. Í þessari skýrslu mun Alexey tala um dæmi um algeng mistök við notkun ClickHouse, sem geta leitt til árangurslausrar vinnu. Hagnýt dæmi munu sýna hvernig val á einu eða öðru gagnavinnslukerfi getur breytt frammistöðu eftir stærðargráðum.
Hæ allir! Ég heiti Alexey, ég bý til ClickHouse.
Í fyrsta lagi flýti ég mér að þóknast þér strax, í dag mun ég ekki segja þér hvað ClickHouse er. Satt að segja er ég þreyttur á því. Í hvert skipti sem ég segi þér hvað það er. Og líklega vita allir nú þegar.
Í staðinn mun ég segja þér hvaða möguleg mistök eru, það er hvernig þú getur notað ClickHouse rangt. Reyndar er óþarfi að vera hræddur því við erum að þróa ClickHouse sem kerfi sem er einfalt, þægilegt og virkar út úr kassanum. Ég setti það upp, engin vandamál.
En þú þarft samt að taka með í reikninginn að þetta kerfi er sérhæft og þú getur auðveldlega rekist á óvenjulegt notkunartilfelli sem mun taka þetta kerfi út fyrir þægindarammann.
Svo, hvers konar hrífa er þarna? Aðallega mun ég tala um augljósa hluti. Allt er öllum augljóst, allir skilja allt og geta glaðst yfir því að vera svona klárir og þeir sem ekki skilja munu læra eitthvað nýtt.
Fyrsta og einfaldasta dæmið, sem því miður kemur oft fyrir, er mikill fjöldi innleggs með litlum lotum, þ.e.a.s. mikill fjöldi lítilla innskota.
Ef við skoðum hvernig ClickHouse framkvæmir innsetningu, þá geturðu sent að minnsta kosti terabæti af gögnum í einni beiðni. Það er ekki vandamál.
Og við skulum sjá hver dæmigerður árangur væri. Til dæmis höfum við töflu frá Yandex.Metrica gögnum. Hits. 105 sumir dálkar. 700 bæti óþjappað. Og við munum setja inn á góðan hátt í lotum af einni milljón raða.
Við setjum MergeTree inn í töfluna, það kemur í ljós hálf milljón raðir á sekúndu. Frábært. Í endurtekinni töflu verður hún aðeins minni, um það bil 400 línur á sekúndu.
Og ef þú virkjar innsetningu sveitarfélags færðu aðeins minni, en samt ágætis frammistöðu, 250 kjörtímabil á sekúndu. Innsetning sveitar er óskráður eiginleiki í ClickHouse*.
* frá og með 2020, .
Hvað gerist ef þú gerir eitthvað slæmt? Við setjum eina línu inn í MergeTree töfluna og fáum 59 línur á sekúndu. Það er 10 sinnum hægara. Í ReplicatedMergeTree - 000 raðir á sekúndu. Og ef kveikt er á sveitinni, þá koma 6 línur á sekúndu. Að mínu mati er þetta algjört rugl. Hvernig er hægt að hægja á sér svona? Ég er meira að segja með það skrifað á stuttermabolinn minn að ClickHouse ætti ekki að hægja á sér. En samt sem áður gerist það stundum.
Í raun er þetta galli okkar. Við hefðum auðveldlega getað látið allt virka vel, en við gerðum það ekki. Og við gerðum það ekki vegna þess að handritið okkar krafðist þess ekki. Við vorum þegar með töfra. Við fengum bara lotur við innganginn okkar og engin vandamál. Við setjum það inn og allt virkar vel. En auðvitað eru alls kyns sviðsmyndir mögulegar. Til dæmis, þegar þú ert með fullt af netþjónum sem gögn eru búin til á. Og þeir setja ekki inn gögn eins oft, en þeir enda samt með tíðum innskotum. Og við þurfum einhvern veginn að forðast þetta.
Frá tæknilegu sjónarhorni er málið að þegar þú setur inn í ClickHouse þá lenda gögnin ekki í neinum memtable. Við erum ekki einu sinni með raunverulegt logskipulag MergeTree, heldur bara MergeTree, því það er hvorki log né memTable. Við skrifum einfaldlega gögnin strax í skráarkerfið, þegar raðað í dálka. Og ef þú ert með 100 dálka, þá þarf að skrifa meira en 200 skrár í sérstaka möppu. Allt er þetta mjög vandmeðfarið.
Og spurningin vaknar: "Hvernig á að gera það rétt?" Ef ástandið er þannig að þú þarft samt einhvern veginn að skrá gögn í ClickHouse.
Aðferð 1. Þetta er auðveldasta leiðin. Notaðu einhvers konar dreifða biðröð. Til dæmis Kafka. Þú dregur einfaldlega út gögn úr Kafka og flokkar þau einu sinni á sekúndu. Og allt verður í lagi, þú tekur upp, allt virkar vel.
Ókostirnir eru þeir að Kafka er annað fyrirferðarmikið dreifð kerfi. Ég skil líka ef þú ert nú þegar með Kafka í fyrirtækinu þínu. Það er gott, það er þægilegt. En ef það er ekki til, þá ættir þú að hugsa þrisvar sinnum áður en þú dregur enn annað dreift kerfi inn í verkefnið þitt. Og því er þess virði að íhuga aðra kosti.
Aðferð 2. Þetta er gamaldags valkostur og á sama tíma mjög einfalt. Ertu með einhvers konar netþjón sem býr til logga þína. Og það skrifar bara annálana þína í skrá. Og einu sinni á sekúndu, til dæmis, endurnefna við þessa skrá og rífum nýja. Og sérstakt handrit, annað hvort í gegnum cron eða einhvern púka, tekur elstu skrána og skrifar hana í ClickHouse. Ef þú skráir logs einu sinni á sekúndu, þá verður allt í lagi.
En ókosturinn við þessa aðferð er sá að ef þjónninn þinn sem annálarnir eru búnir til hverfur einhvers staðar, þá hverfa gögnin líka.
Aðferð 3. Það er önnur áhugaverð aðferð, sem krefst alls ekki tímabundinna skráa. Til dæmis, þú ert með einhvers konar auglýsingaspuna eða einhvern annan áhugaverðan púka sem býr til gögn. Og þú getur safnað fullt af gögnum beint í vinnsluminni, í biðminni. Og þegar nægur tími er liðinn seturðu þennan biðminni til hliðar, býrð til nýjan og setur í sérstakan þráð það sem þegar hefur safnast fyrir í ClickHouse.
Aftur á móti hverfa gögnin líka með kill -9. Ef þjónninn þinn hrynur muntu tapa þessum gögnum. Og annað vandamál er að ef þú gast ekki skrifað í gagnagrunninn, þá safnast gögnin þín upp í vinnsluminni. Og annað hvort mun vinnsluminni klárast, eða þú munt einfaldlega tapa gögnum.
Aðferð 4. Önnur áhugaverð aðferð. Ertu með einhvers konar server ferli. Og það getur sent gögn til ClickHouse strax, en gert það í einni tengingu. Til dæmis sendi ég http beiðni með flutningskóðun: chunked with insert. Og það myndar klumpur ekki of sjaldan, þú getur sent hverja línu, þó það verði kostnaður til að ramma inn þessi gögn.
Hins vegar, í þessu tilfelli, verða gögnin send til ClickHouse strax. Og ClickHouse mun biðja þá sjálft.
En vandamál koma líka upp. Nú munt þú tapa gögnum, þar á meðal þegar ferlið þitt er drepið og ef ClickHouse ferlið er drepið, vegna þess að það verður ófullnægjandi innskot. Og í ClickHouse eru innskot frumeinda upp að ákveðnum tilteknum þröskuldi í stærð raða. Í grundvallaratriðum er þetta áhugaverð leið. Einnig hægt að nota.
Aðferð 5. Hér er önnur áhugaverð aðferð. Þetta er einhvers konar samfélagsþróaður netþjónn fyrir gagnaflutning. Ég hef ekki skoðað það sjálfur, svo ég get ekki ábyrgst neitt. Hins vegar eru engar tryggingar veittar fyrir ClickHouse sjálft. Þetta er líka opinn uppspretta, en á hinn bóginn gætirðu verið vanur einhverjum gæðastaðli sem við reynum að veita. En fyrir þetta - ég veit það ekki, farðu á GitHub, skoðaðu kóðann. Kannski skrifuðu þeir eitthvað eðlilegt.
* frá og með 2020, ætti einnig að koma til greina .
Aðferð 6. Önnur aðferð er að nota Buffer töflur. Kosturinn við þessa aðferð er að það er mjög auðvelt að byrja að nota hana. Búðu til Buffer töflu og settu hana inn í hana.
Ókosturinn er sá að vandamálið er ekki að fullu leyst. Ef, í hraða eins og MergeTree, þú þarft að flokka gögn um eina lotu á sekúndu, þá í hraða í biðminni töflu, þarftu að flokka að minnsta kosti allt að nokkur þúsund á sekúndu. Ef það er meira en 10 á sekúndu verður það samt slæmt. Og ef þú setur það inn í lotum, þá sástu að það reynist vera hundrað þúsund línur á sekúndu. Og þetta er nú þegar á frekar þungum gögnum.
Og einnig biðminni töflur hafa ekki log. Og ef það er eitthvað athugavert við netþjóninn þinn, þá munu gögnin glatast.
Og sem bónus fengum við nýlega tækifæri hjá ClickHouse til að sækja gögn frá Kafka. Það er borðvél - Kafka. Þú býrð bara til. Og þú getur hengt upp efnislegar framsetningar á það. Í þessu tilviki mun það sjálft draga gögn úr Kafka og setja þau inn í töflurnar sem þú þarft.
Og það sem er sérstaklega ánægjulegt við þetta tækifæri er að það vorum ekki við sem gerðum það. Þetta er samfélagsþáttur. Og þegar ég segi „samfélagseinkenni,“ meina ég það án nokkurrar fyrirlitningar. Við lásum kóðann, gerðum endurskoðun, hann ætti að virka vel.
* Frá og með 2020 hefur svipaður stuðningur birst fyrir .
Hvað annað gæti verið óþægilegt eða óvænt þegar gögn eru sett inn? Ef þú setur inn gildisbeiðni og skrifar nokkur reiknuð tjáning í gildum. Til dæmis, now() er líka reiknuð tjáning. Og í þessu tilfelli neyðist ClickHouse til að ræsa túlk þessara tjáninga á hverri línu og frammistaða mun lækka um stærðargráður. Það er betra að forðast þetta.
* í augnablikinu er vandamálið að fullu leyst, það er ekki lengur nein frammistöðuhrun þegar notuð eru tjáningar í VALUES.
Annað dæmi er þegar einhver vandamál geta verið þegar þú ert með gögn á einni lotu sem tilheyrir fullt af skiptingum. Sjálfgefið er að ClickHouse skipting er eftir mánuði. Og ef þú setur inn lotu af milljón línum og það eru gögn í nokkur ár, þá muntu hafa nokkra tugi skiptinga þar. Og þetta jafngildir því að það verða lotur nokkrum tugum sinnum minni að stærð, því inni er þeim alltaf fyrst skipt í skipting.
* Nýlega, í tilraunaham, bætti ClickHouse við stuðningi við fyrirferðarlítið snið af klumpur og klumpur í vinnsluminni með framskráningarskrá, sem leysir vandamálið nánast alveg.
Nú skulum við líta á aðra tegund vandamála - gagnaritun.
Gagnaritun getur verið ströng eða streng. String er þegar þú tókst það og lýsti því yfir að allir reitirnir þínir væru af gerðinni streng. Þetta er ömurlegt. Það er engin þörf á að gera þetta.
Við skulum reikna út hvernig á að gera það rétt í þeim tilfellum þegar þú vilt segja að við höfum einhvern reit, streng, og leyfum ClickHouse að finna það út á eigin spýtur, og ég nenni því ekki. En það er samt þess virði að leggja eitthvað á sig.
Til dæmis höfum við IP tölu. Í einu tilviki vistuðum við það sem streng. Til dæmis, 192.168.1.1. Og í öðru tilviki mun það vera fjöldi af gerðinni UInt32*. 32 bitar eru nóg fyrir IPv4 vistfang.
Í fyrsta lagi, einkennilega nóg, verða gögnin þjappað um það bil jafnt saman. Það verður auðvitað munur en ekki svo mikill. Svo það eru engin sérstök vandamál með disk I/O.
En það er alvarlegur munur á örgjörvatíma og framkvæmdartíma fyrirspurna.
Við skulum telja fjölda einstakra IP tölur ef þær eru geymdar sem tölur. Það er 137 milljón línur á sekúndu. Ef það sama er í formi strengja, þá 37 milljónir lína á sekúndu. Ég veit ekki hvers vegna þessi tilviljun gerðist. Ég framkvæmdi þessar beiðnir sjálfur. En samt um 4 sinnum hægar.
Og ef þú reiknar út muninn á diskplássi, þá er líka munur. Og munurinn er um það bil fjórðungur, vegna þess að það eru töluvert mikið af einstökum IP tölum. Og ef það væru línur með fáar mismunandi merkingar, þá væri þeim auðveldlega þjappað saman samkvæmt orðabókinni í um það bil sama bindi.
Og fjórfaldur tímamunur liggur ekki á veginum. Kannski er þér auðvitað alveg sama, en þegar ég sé svona mun þá veldur það mér sorg.
Við skulum skoða mismunandi tilvik.
1. Eitt tilvik þegar þú hefur fá mismunandi einstök gildi. Í þessu tilviki notum við einfalda æfingu sem þú þekkir líklega og getur notað fyrir hvaða DBMS sem er. Þetta er allt skynsamlegt, ekki aðeins fyrir ClickHouse. Skrifaðu bara töluleg auðkenni í gagnagrunninn. Og þú getur breytt í strengi og aftur á hlið forritsins þíns.
Til dæmis ertu með svæði. Og þú ert að reyna að vista það sem streng. Og þar mun vera skrifað: Moskvu og Moskvuhérað. Og þegar ég sé að það stendur "Moscow", þá er það ekkert, en þegar það er Moskvu, verður það einhvern veginn alveg sorglegt. Þetta er hversu mörg bæti.
Þess í stað skrifum við einfaldlega niður númerið Ulnt32 og 250. Við höfum 250 í Yandex, en þitt gæti verið öðruvísi. Bara í tilfelli, ég segi að ClickHouse hefur innbyggða getu til að vinna með landgrunn. Þú skrifar einfaldlega niður möppu með svæðum, þar á meðal stigveldisskrá, þ.e.a.s. það verður Moskvu, Moskvusvæðið og allt sem þú þarft. Og þú getur umbreytt á beiðnistigi.
Annar valkosturinn er um það bil sá sami, en með stuðningi inni í ClickHouse. Þetta er Enum gagnategundin. Þú skrifar einfaldlega öll þau gildi sem þú þarft inni í Enum. Til dæmis, gerð tækis og skrifaðu þar: skjáborð, farsíma, spjaldtölvu, sjónvarp. Alls eru 4 valkostir.
Ókosturinn er sá að þú þarft að breyta því reglulega. Aðeins einum valkosti bætt við. Við skulum breyta töflunni. Reyndar er breytt borð í ClickHouse ókeypis. Sérstaklega ókeypis fyrir Enum vegna þess að gögnin á disknum breytast ekki. En samt sem áður fær alter læsingu* á borðinu og verður að bíða þar til öll valin eru framkvæmd. Og aðeins eftir að þessi breyting verður framkvæmd, þ.e.a.s. það eru enn nokkur óþægindi.
* í nýjustu útgáfum ClickHouse er ALTER gert algjörlega ólokandi.
Annar valkostur sem er alveg einstakur fyrir ClickHouse er að tengja utanaðkomandi orðabækur. Þú getur skrifað tölur í ClickHouse og geymt möppur þínar í hvaða kerfi sem er þægilegt fyrir þig. Til dæmis geturðu notað: MySQL, Mongo, Postgres. Þú getur jafnvel búið til þína eigin örþjónustu sem mun senda þessi gögn í gegnum http. Og á ClickHouse stigi skrifarðu aðgerð sem mun breyta þessum gögnum úr tölum í strengi.
Þetta er sérhæfð en mjög skilvirk leið til að framkvæma sameiningu á ytra borði. Og það eru tveir kostir. Í einni útfærslu verða þessi gögn algjörlega í skyndiminni, að fullu til staðar í vinnsluminni og uppfærð með einhverri tíðni. Og í öðrum valkosti, ef þessi gögn passa ekki inn í vinnsluminni, þá geturðu vistað þau að hluta.
Hér er dæmi. Það er Yandex.Direct. Og það er auglýsingafyrirtæki og borðar. Það eru líklega um tugir milljóna auglýsingafyrirtækja. Og þeir passa nokkurn veginn inn í vinnsluminni. Og það eru milljarðar borða, þeir passa ekki. Og við notum skyndiminni orðabók frá MySQL.
Eina vandamálið er að skyndiminni orðabókin mun virka vel ef högghlutfallið er nálægt 100%. Ef það er minna, þá þegar þú vinnur úr fyrirspurnum fyrir hverja lotu af gögnum, verður þú í raun að taka lyklana sem vantar og fara að sækja gögnin frá MySQL. Um ClickHouse get ég samt ábyrgst það - já, það hægir ekki á sér, ég mun ekki tala um önnur kerfi.
Og sem bónus eru orðabækur mjög auðveld leið til að uppfæra gögn afturvirkt í ClickHouse. Það er, þú varst með skýrslu um auglýsingafyrirtæki, notandinn breytti einfaldlega auglýsingafyrirtækinu og í öllum gömlu gögnunum, í öllum skýrslum, breyttust þessi gögn líka. Ef þú skrifar línur beint í töfluna verður ómögulegt að uppfæra þær.
Önnur leið þegar þú veist ekki hvar á að fá auðkennin fyrir strengina þína. þú getur einfaldlega hassað það. Þar að auki er einfaldasti kosturinn að taka 64-bita kjötkássa.
Eina vandamálið er að ef kjötkássa er 64-bita, þá muntu næstum örugglega verða fyrir árekstrum. Vegna þess að ef það eru milljarður lína þarna, þá verða líkurnar þegar áberandi.
Og það væri ekki mjög gott að hassa nöfn auglýsingafyrirtækja á þennan hátt. Ef auglýsingaherferðum mismunandi fyrirtækja er blandað saman, þá verður eitthvað óskiljanlegt.
Og það er einfalt bragð. Að vísu hentar það ekki sérstaklega fyrir alvarleg gögn, en ef eitthvað er ekki mjög alvarlegt skaltu bara bæta auðkenni viðskiptavinarins við orðabókarlykilinn. Og þá muntu verða fyrir árekstrum, en aðeins innan eins viðskiptavinar. Og við notum þessa aðferð fyrir hlekkjakort í Yandex.Metrica. Við erum með vefslóðir þar, við geymum hass. Og við vitum að það eru auðvitað árekstrar. En þegar síðan er birt má vanrækt líkurnar á því að á einni síðu eins notanda séu einhverjar vefslóðir fastar saman og eftir því verði tekið.
Sem bónus, fyrir margar aðgerðir dugar kjötkássa ein og sér og strengina sjálfa þarf ekki að geyma neins staðar.
Annað dæmi er ef strengirnir eru stuttir, til dæmis vefsíðulén. Hægt er að geyma þær eins og þær eru. Eða, til dæmis, vafratungumálið ru – 2 bæti. Auðvitað vorkenni ég bætunum, en ekki hafa áhyggjur, 2 bæti eru ekki samúð. Vinsamlegast hafðu það eins og það er, ekki hafa áhyggjur.
Annað tilvik er þegar þvert á móti eru margar línur og margar einstakar í þeim, og jafnvel settið er hugsanlega ótakmarkað. Dæmigerð dæmi eru leitarsetningar eða vefslóðir. Leitarsetningar, þar á meðal innsláttarvillur. Við skulum sjá hversu margar einstakar leitarsetningar eru á dag. Og það kemur í ljós að þeir eru næstum helmingur allra atburða. Og í þessu tilviki gætirðu haldið að þú þurfir að staðla gögnin, telja auðkennin og setja þau í sérstaka töflu. En þú þarft ekki að gera það. Hafðu þessar línur eins og þær eru.
Það er betra að finna ekki upp neitt, því ef þú geymir það sérstaklega þarftu að taka þátt. Og þessi join er í besta falli tilviljunarkenndur aðgangur að minni, ef það passar enn í minnið. Ef það passar ekki, þá verða vandamál.
Og ef gögnin eru geymd á sínum stað, þá eru þau einfaldlega lesin í tilskildri röð úr skráarkerfinu og allt er í lagi.
Ef þú ert með vefslóðir eða einhvern annan flókinn langan streng, þá er það þess virði að íhuga að þú getur reiknað út einhvers konar útdrátt fyrirfram og skrifað það í sérstakan dálk.
Fyrir vefslóðir, til dæmis, geturðu geymt lénið sérstaklega. Og ef þú þarft virkilega lén, notaðu þá bara þennan dálk, og vefslóðirnar munu liggja þar og þú munt ekki einu sinni snerta þær.
Við skulum sjá hver munurinn er. ClickHouse er með sérhæfða aðgerð sem reiknar út lénið. Það er mjög hratt, við höfum fínstillt það. Og satt að segja er það ekki einu sinni í samræmi við RFC, en engu að síður tekur það tillit til allt sem við þurfum.
Og í einu tilviki munum við einfaldlega fá vefslóðirnar og reikna út lénið. Það er 166 millisekúndur. Og ef þú tekur tilbúið lén, þá reynist það vera aðeins 67 millisekúndur, þ.e. næstum þrisvar sinnum hraðar. Og það er fljótlegra, ekki vegna þess að við þurfum að gera útreikninga, heldur vegna þess að við lesum minna af gögnum.
Þess vegna hefur ein beiðni, sem er hægari, hærri gígabæta hraða á sekúndu. Vegna þess að það les fleiri gígabæta. Þetta eru algjörlega óþörf gögn. Beiðnin virðist keyra hraðar en það tekur lengri tíma að ljúka henni.
Og ef þú skoðar gagnamagnið á disknum kemur í ljós að slóðin er 126 megabæti og lénið aðeins 5 megabæt. Það kemur í ljós 25 sinnum minna. En engu að síður er beiðnin framkvæmd aðeins 4 sinnum hraðar. En það er vegna þess að gögnin eru heit. Og ef það væri kalt væri það líklega 25 sinnum hraðari vegna disks I/O.
Við the vegur, ef þú áætlar hversu miklu minna lén er en URL, þá reynist það vera um það bil 4 sinnum minna. En af einhverjum ástæðum taka gögnin 25 sinnum minna á disknum. Hvers vegna? Vegna þjöppunar. Og slóðin er þjappuð og lénið er þjappað. En oft inniheldur vefslóðin fullt af rusli.
Og auðvitað borgar sig að nota réttar gagnategundir sem eru hannaðar sérstaklega fyrir þau gildi sem þú vilt eða henta. Ef þú ert í IPv4, geymdu þá UInt32*. Ef IPv6, þá FixedString(16), vegna þess að IPv6 vistfangið er 128 bitar, þ.e. geymt beint á tvíundarsniði.
En hvað ef þú ert stundum með IPv4 vistföng og stundum IPv6? Já, þú getur geymt bæði. Einn dálkur fyrir IPv4, annar fyrir IPv6. Auðvitað er möguleiki á að sýna IPv4 í IPv6. Þetta mun líka virka, en ef þú þarft oft IPv4 vistfang í beiðnum, þá væri gaman að setja það í sérstakan dálk.
* ClickHouse hefur nú aðskildar IPv4, IPv6 gagnategundir sem geyma gögn á eins skilvirkan hátt og tölur, en tákna þau á eins þægilegan hátt og strengir.
Það er líka mikilvægt að hafa í huga að það er þess virði að forvinna gögnin fyrirfram. Til dæmis færðu hráa annála. Og kannski ættirðu ekki bara að setja þær í ClickHouse strax, þó það sé mjög freistandi að gera ekkert og allt mun virka. En það er samt þess virði að framkvæma þá útreikninga sem eru mögulegir.
Til dæmis vafraútgáfa. Í einhverri nærliggjandi deild, sem ég vil ekki benda á, er vafraútgáfan geymd svona, það er að segja sem strengur: 12.3. Og svo, til að gera skýrslu, taka þeir þennan streng og skipta honum í fylki og síðan í fyrsta þátt fylkisins. Auðvitað hægir allt á sér. Ég spurði hvers vegna þeir gerðu þetta. Þeir sögðu mér að þeim líkaði ekki ótímabær hagræðing. Og mér líkar ekki ótímabær svartsýni.
Þannig að í þessu tilfelli væri réttara að skipta í 4 dálka. Ekki vera hræddur hér, því þetta er ClickHouse. ClickHouse er dálkagagnagrunnur. Og því snyrtilegri litlar dálkar, því betra. Það verða 5 BrowserVersions, búið til 5 dálka. Þetta er fínt.
Nú skulum við skoða hvað á að gera ef þú ert með marga mjög langa strengi, mjög langa fylki. Það þarf alls ekki að geyma þær í ClickHouse. Þess í stað geturðu aðeins geymt auðkenni í ClickHouse. Og settu þessar löngu línur í eitthvað annað kerfi.
Til dæmis, ein af greiningarþjónustunum okkar hefur nokkrar atburðarfæribreytur. Og ef það eru margar breytur fyrir atburði þá vistum við einfaldlega fyrstu 512 sem rekast á. Vegna þess að 512 er ekki samúð.
Og ef þú getur ekki ákveðið gagnategundirnar þínar, þá geturðu líka skráð gögn í ClickHouse, en í bráðabirgðatöflu af Log gerðinni, sérstakri fyrir tímabundin gögn. Eftir þetta geturðu greint hvaða dreifingu gilda sem þú hefur þar, hvað er þar almennt og búið til réttar tegundir.
*ClickHouse hefur nú gagnategund sem gerir þér kleift að geyma strengi á skilvirkan hátt með minni fyrirhöfn.
Nú skulum við líta á annað áhugavert mál. Stundum virkar hlutirnir undarlega fyrir fólk. Ég kem inn og sé þetta. Og það virðist strax sem þetta hafi verið gert af mjög reyndum, snjöllum stjórnanda sem hefur mikla reynslu í að setja upp MySQL útgáfu 3.23.
Hér sjáum við þúsund töflur, sem hver um sig skráir afganginn af því að deila hver veit hvað með þúsund.
Í grundvallaratriðum virði ég reynslu annarra, þar á meðal skilning á þjáningunni sem hægt er að öðlast með þessari reynslu.
Og ástæðurnar eru meira og minna ljósar. Þetta eru gamlar staðalmyndir sem kunna að hafa safnast upp þegar unnið er með önnur kerfi. Til dæmis eru MyISAM töflur ekki með þyrpaðan aðallykil. Og þessi leið til að deila gögnum gæti verið örvæntingarfull tilraun til að fá sömu virkni.
Önnur ástæða er sú að erfitt er að gera breytingar á stórum borðum. Allt verður lokað. Þó að í nútíma útgáfum af MySQL sé þetta vandamál ekki lengur svo alvarlegt.
Eða t.d. microsharding, en meira um það síðar.
Það er engin þörf á að gera þetta í ClickHouse, vegna þess að í fyrsta lagi er aðallykillinn flokkaður, gögnunum er raðað eftir aðallyklinum.
Og stundum spyr fólk mig: „Hvernig er árangur sviðsfyrirspurna í ClickHouse mismunandi eftir borðstærðinni? Ég segi að það breytist ekkert. Til dæmis, þú ert með töflu með milljarði lína og þú lest bil upp á eina milljón lína. Allt er í lagi. Ef það eru trilljón raðir í töflu og þú lest eina milljón raðir, þá verður það nánast það sama.
Og í öðru lagi, alls konar hlutir eins og handvirk skipting er ekki krafist. Ef þú ferð inn og lítur á það sem er í skráarkerfinu, muntu sjá að taflan er ansi mikið mál. Og það er eitthvað eins og skipting inni. Það er, ClickHouse gerir allt fyrir þig og þú þarft ekki að þjást.
Breyta í ClickHouse er ókeypis ef breyta bæta við/sleppa dálki.
Og þú ættir ekki að búa til litlar töflur, því ef þú ert með 10 raðir eða 10 raðir í töflu, þá skiptir það engu máli. ClickHouse er kerfi sem hámarkar afköst, ekki leynd, svo það þýðir ekkert að vinna úr 000 línum.
Rétt er að nota eitt stórt borð. Losaðu þig við gamlar staðalmyndir, allt verður í lagi.
Og sem bónus, í nýjustu útgáfunni höfum við nú möguleika á að búa til handahófskenndan skiptingarlykil til að framkvæma alls kyns viðhaldsaðgerðir á einstökum skiptingum.
Til dæmis þarftu margar litlar töflur, til dæmis þegar þarf að vinna úr einhverjum milligögnum færðu klumpur og þú þarft að framkvæma umbreytingu á þeim áður en þú skrifar í lokatöfluna. Fyrir þetta tilfelli er frábær borðvél - StripeLog. Það er eins og TinyLog, bara betra.
* Nú hefur ClickHouse líka .
Annað mótmynstur er örsmíði. Til dæmis þarftu að klippa gögn og þú ert með 5 netþjóna og á morgun verða 6 netþjónar. Og þú hugsar um hvernig eigi að koma jafnvægi á þessi gögn. Og í staðinn brýtur þú ekki í 5 brot, heldur í 1 brot. Og svo kortleggurðu hvern af þessum örbrotum á sérstakan netþjón. Og þú færð til dæmis 000 ClickHouses á einum netþjóni, til dæmis. Aðskilin tilvik á aðskildum höfnum eða aðskildum gagnagrunnum.
En þetta er ekki mjög gott í ClickHouse. Vegna þess að jafnvel eitt ClickHouse tilvik reynir að nota öll tiltæk miðlaraauðlindir til að vinna úr einni beiðni. Það er að segja, þú ert með einhvers konar server og hann hefur til dæmis 56 örgjörva kjarna. Þú ert að keyra fyrirspurn sem tekur eina sekúndu að ljúka og hún mun nota 56 kjarna. Og ef þú settir 200 ClickHouses þarna á einum netþjóni, þá kemur í ljós að 10 þræðir byrja. Almennt séð verður allt mjög slæmt.
Önnur ástæða er sú að dreifing vinnu yfir þessi tilvik verður misjöfn. Sumir klára fyrr, sumir klára seinna. Ef allt þetta gerðist í einu tilviki, þá myndi ClickHouse sjálft finna út hvernig á að dreifa gögnunum rétt á milli þráðanna.
Og önnur ástæða er sú að þú munt hafa samskipti milli örgjörva í gegnum TCP. Gögnin verða að vera raðnúmeruð, afserialized, og þetta er gríðarlegur fjöldi örbrota. Það mun einfaldlega ekki virka á áhrifaríkan hátt.
Annað mótmynstur, þó varla sé hægt að kalla það andmynstur. Þetta er mikið magn af forsöfnun.
Almennt séð er forsöfnun góð. Þú varst með milljarð lína, þú safnaðir því saman og það varð 1 raðir, og nú er fyrirspurnin keyrð samstundis. Allt er frábært. Þú getur þetta. Og fyrir þetta hefur jafnvel ClickHouse sérstaka töflugerð, AggregatingMergeTree, sem framkvæmir stigvaxandi samansöfnun þegar gögn eru sett inn.
En það eru tímar þegar þú heldur að við munum safna gögnum eins og þessum og safna gögnum eins og þessum. Og í sumum nálægum deildum vil ég heldur ekki segja hvaða, þeir nota SummingMergeTree töflur til að draga saman með aðallyklinum og um 20 dálkar eru notaðir sem aðallykill. Til öryggis breytti ég nöfnum sumra dálka vegna leyndar, en það er nokkurn veginn það.
Og slík vandamál koma upp. Í fyrsta lagi minnkar gagnamagn þitt ekki of mikið. Það minnkar til dæmis þrisvar sinnum. Þrisvar sinnum væri gott verð til að hafa efni á ótakmarkaða greiningargetu sem myndast ef gögnin þín eru ekki samanlögð. Ef gögnin eru samanlögð, þá færðu aðeins aumkunarverða tölfræði í stað greiningar.
Og hvað er svona sérstakt við það? Staðreyndin er sú að þetta fólk úr nágrannadeildinni fer stundum og biður um að bæta öðrum dálki við aðallykilinn. Það er að segja, við tókum saman gögnin svona, en nú viljum við aðeins meira. En ClickHouse er ekki með breytinga aðallykil. Þess vegna verðum við að skrifa smá forskriftir í C++. Og mér líkar ekki við handrit, jafnvel þó þau séu í C++.
Og ef þú horfir á það sem ClickHouse var búið til fyrir, þá eru ósamsett gögn nákvæmlega atburðarásin sem þau fæddust fyrir. Ef þú ert að nota ClickHouse fyrir ósöfnuð gögn, þá ertu að gera það rétt. Ef þú safnar saman er þetta stundum fyrirgefanlegt.
Annað áhugavert tilvik eru fyrirspurnir í óendanlega lykkju. Stundum fer ég á einhvern framleiðsluþjón og skoða sýningarferlislistann þar. Og í hvert skipti sem ég uppgötva að eitthvað hræðilegt er að gerast.
Til dæmis svona. Það er strax ljóst að allt var hægt að gera í einni beiðni. Skrifaðu bara slóðina inn og listann þar.
Af hverju eru margar slíkar fyrirspurnir í endalausri lykkju slæmar? Ef vísitala er ekki notuð, þá muntu hafa margar sendingar yfir sömu gögnin. En ef vísitalan er notuð til dæmis þá ertu með aðallykil fyrir ru og skrifar url = eitthvað þar. Og þú heldur að ef aðeins ein vefslóð er lesin úr töflunni þá verði allt í lagi. En reyndar nei. Vegna þess að ClickHouse gerir allt í lotum.
Þegar hann þarf að lesa ákveðið gagnasvið les hann aðeins meira, vegna þess að skráin í ClickHouse er dreifð. Þessi vísitala leyfir þér ekki að finna eina einstaka línu í töflunni, aðeins svið af einhverju tagi. Og gögnin eru þjappuð í blokkir. Til þess að lesa eina línu þarftu að taka alla blokkina og losa hana. Og ef þú ert að gera fullt af fyrirspurnum, munt þú hafa mikla skörun og þú munt hafa mikið að gera aftur og aftur.
Og sem bónus geturðu tekið eftir því að í ClickHouse ættir þú ekki að vera hræddur við að flytja jafnvel megabæti og jafnvel hundruð megabæta yfir í IN hlutann. Ég man eftir æfingum okkar að ef í MySQL flytjum við fullt af gildum yfir í IN hlutann, til dæmis flytjum við 100 megabæti af einhverjum tölum þangað, þá étur MySQL upp 10 gígabæt af minni og ekkert annað gerist við það, allt virkar illa.
Og annað er að í ClickHouse, ef fyrirspurnir þínar nota vísitölu, þá er það alltaf ekki hægara en full skönnun, þ.e. ef þú þarft að lesa næstum alla töfluna, mun hún fara í röð og lesa alla töfluna. Almennt séð mun hann finna það út sjálfur.
En samt sem áður eru nokkrir erfiðleikar. Til dæmis sú staðreynd að IN með undirfyrirspurn notar ekki vísitöluna. En þetta er okkar vandamál og við þurfum að laga það. Hér er ekkert grundvallaratriði. Við reddum því*.
Og annað áhugavert er að ef þú ert með mjög langa beiðni og dreifð beiðnavinnsla er í gangi, þá verður þessi mjög langa beiðni send á hvern netþjón án samþjöppunar. Til dæmis 100 megabæti og 500 netþjónar. Og í samræmi við það muntu hafa 50 gígabæt flutt yfir netið. Það verður sent og þá mun allt ganga vel.
* þegar að nota; Allt var lagað eins og lofað var.
Og nokkuð algengt tilfelli er þegar beiðnir koma frá API. Til dæmis bjóstu til einhvers konar eigin þjónustu. Og ef einhver þarfnast þjónustu þinnar, þá opnarðu API og bókstaflega tveimur dögum síðar sérðu að eitthvað óskiljanlegt er að gerast. Allt er ofhlaðið og hræðilegar beiðnir berast inn sem hefðu aldrei átt að gerast.
Og það er bara ein lausn. Ef þú hefur opnað API, þá verður þú að klippa það. Til dæmis að taka upp einhvers konar kvóta. Það eru engir aðrir eðlilegir valkostir. Annars skrifa þeir strax handrit og það verða vandamál.
Og ClickHouse hefur sérstaka eiginleika - kvótaútreikning. Þar að auki geturðu flutt kvótalykilinn þinn. Þetta er til dæmis innra notendaauðkenni. Og kvótar verða reiknaðir sjálfstætt fyrir hvern þeirra.
Nú er annað áhugavert. Þetta er handvirk afritun.
Ég veit um mörg tilvik þar sem fólk endurtekur ClickHouse handvirkt þrátt fyrir að ClickHouse hafi innbyggðan afritunarstuðning.
Hver er meginreglan? Þú ert með gagnavinnsluleiðslu. Og það virkar sjálfstætt, til dæmis í mismunandi gagnaverum. Þú skrifar sömu gögn á sama hátt í ClickHouse. Að vísu sýnir æfingin að gögnin munu enn víkja vegna sumra eiginleika í kóðanum þínum. Ég vona að það sé í þínum.
Og af og til verður þú samt að samstilla handvirkt. Til dæmis, einu sinni í mánuði gera admins rsync.
Reyndar er miklu auðveldara að nota afritunina sem er innbyggð í ClickHouse. En það geta verið nokkrar frábendingar, því fyrir þetta þarftu að nota ZooKeeper. Ég segi ekkert slæmt um ZooKeeper, í grundvallaratriðum virkar kerfið, en það kemur fyrir að fólk notar það ekki vegna java-fælni, því ClickHouse er svo gott kerfi, skrifað í C++, sem þú getur notað og allt verður í lagi. Og ZooKeeper er í java. Og einhvern veginn vilt þú ekki einu sinni líta, en þá geturðu notað handvirka afritun.
ClickHouse er hagnýtt kerfi. Hún tekur tillit til þarfa þinna. Ef þú ert með handvirka afritun geturðu búið til dreifða töflu sem skoðar handvirkar eftirmyndir þínar og gerir bilun á milli þeirra. Og það er meira að segja sérstakur valkostur sem gerir þér kleift að forðast flopp, jafnvel þó að línurnar þínar víki kerfisbundið.
Frekari vandamál geta komið upp ef þú notar frumstæðar borðvélar. ClickHouse er smiður sem hefur fullt af mismunandi borðvélum. Fyrir öll alvarleg tilvik, eins og skrifað er í skjölunum, notaðu töflur frá MergeTree fjölskyldunni. Og allt hitt - þetta er svo, fyrir einstök tilvik eða fyrir próf.
Í MergeTree töflu þarftu ekki að hafa neina dagsetningu og tíma. Þú getur samt notað það. Ef það er engin dagsetning og tími, skrifaðu að sjálfgefið sé 2000. Þetta mun virka og mun ekki krefjast fjármagns.
Og í nýju útgáfunni af þjóninum geturðu jafnvel tilgreint að þú sért með sérsniðna skiptingu án skiptingarlykils. Það verður eins.
Aftur á móti er hægt að nota frumstæðar borðvélar. Til dæmis að fylla út gögnin einu sinni og skoða, snúa og eyða. Þú getur notað Log.
Eða að geyma lítið magn fyrir millivinnslu er StripeLog eða TinyLog.
Minni er hægt að nota ef gagnamagnið er lítið og þú getur einfaldlega snúið einhverju í vinnsluminni.
ClickHouse líkar ekki mjög við endureðlað gögn.
Hér er dæmigert dæmi. Þetta er gríðarlegur fjöldi vefslóða. Þú setur þá í næsta töflu. Og þá ákváðu þeir að gera JOIN með þeim, en þetta mun ekki virka, að jafnaði, því ClickHouse styður aðeins Hash JOIN. Ef það er ekki nóg vinnsluminni fyrir mikið af gögnum sem þarf að tengja, þá virkar JOIN ekki*.
Ef gögnin eru af miklum aðalgildi, þá skaltu ekki hafa áhyggjur, geymdu þau á óeðlilegu formi, vefslóðirnar eru beint á sínum stað í aðaltöflunni.
* og nú er ClickHouse einnig með sameiningu, og það virkar við aðstæður þar sem milligögn passa ekki inn í vinnsluminni. En þetta er árangurslaust og tilmælin eru áfram í gildi.
Nokkur dæmi í viðbót, en ég efast nú þegar um hvort þau séu andstæðingur-mynstur eða ekki.
ClickHouse hefur einn þekktan galla. Það veit ekki hvernig á að uppfæra*. Að sumu leyti er þetta jafnvel gott. Ef þú ert með mikilvæg gögn, til dæmis bókhald, þá mun enginn geta sent þau, því það eru engar uppfærslur.
* Stuðningur við uppfærslu og eyðingu í lotuham hefur verið bætt við fyrir löngu síðan.
En það eru nokkrar sérstakar leiðir sem leyfa uppfærslur eins og í bakgrunni. Til dæmis, töflur eins og ReplaceMergeTree. Þeir gera uppfærslur við samruna bakgrunns. Þú getur þvingað þetta með því að nota fínstillingartöflu. En ekki gera þetta of oft, því það mun skrifa yfir skiptinguna alveg.
Dreifðir JOINs í ClickHouse eru einnig illa meðhöndlaðir af fyrirspurnaskipuleggjanda.
Slæmt, en stundum allt í lagi.
Notkun ClickHouse eingöngu til að lesa gögn til baka með því að nota select*.
Ég myndi ekki mæla með því að nota ClickHouse fyrir fyrirferðarmikla útreikninga. En þetta er ekki alveg rétt, því við erum nú þegar að hverfa frá þessum tilmælum. Og við bættum nýlega við möguleikanum á að beita vélanámslíkönum í ClickHouse - Catboost. Og það truflar mig vegna þess að ég hugsa: „Þvílíkur hryllingur. Þetta er hversu margar lotur á bæti kemur í ljós! Ég hata virkilega að eyða klukkum í bæti.
En ekki vera hræddur, settu upp ClickHouse, allt verður í lagi. Ef eitthvað er þá erum við með samfélag. Við the vegur, samfélagið ert þú. Og ef þú lendir í einhverjum vandræðum geturðu að minnsta kosti farið á spjallið okkar og vonandi munu þeir hjálpa þér.
spurningar
Takk fyrir skýrsluna! Hvar get ég kvartað yfir því að ClickHouse hrundi?
Þú getur kvartað við mig persónulega núna.
Ég byrjaði nýlega að nota ClickHouse. Ég hætti strax við cli viðmótið.
Þvílíkt stig.
Stuttu seinna hrundi ég þjóninum með litlu vali.
Þú hefur hæfileika.
Ég opnaði GitHub galla, en hún var hunsuð.
Við munum sjá.
Alexey blekkti mig til að mæta í skýrsluna og lofaði að segja mér hvernig þú nálgast gögnin inni.
Mjög einfalt.
Ég áttaði mig á þessu í gær. Nánar tiltekið.
Það eru engin hræðileg brögð þarna. Það er bara þjöppun blokk fyrir blokk. Sjálfgefið er LZ4, þú getur virkjað ZSTD*. Blokkir frá 64 kílóbæti til 1 megabæti.
* það er líka stuðningur við sérhæfða þjöppunarmerkjamál sem hægt er að nota í keðju með öðrum reikniritum.
Eru blokkirnar bara hrá gögn?
Ekki alveg hrátt. Það eru fylki. Ef þú ert með tölulegan dálk, þá eru tölur í röð settar í fylki.
Það er skýrt.
Alexey, dæmi sem var með uniqExact yfir IP, þ.e.a.s. sú staðreynd að uniqExact tekur lengri tíma að reikna með línum en með tölum, og svo framvegis. Hvað ef við notum feik með eyrunum og steypum við prófarkalestur? Það er, þú virðist hafa sagt að á disknum okkar sé þetta ekki mjög ólíkt. Ef við lesum línur af diski og steypu, verður samanlagður okkar hraðari eða ekki? Eða munum við enn hagnast aðeins hér? Mér sýnist þú hafa prófað þetta en af einhverjum ástæðum ekki gefið það til kynna í viðmiðinu.
Ég held að það verði hægara en án steypu. Í þessu tilviki verður að flokka IP tölu úr strengnum. Auðvitað, hjá ClickHouse, er IP-töluþáttun okkar líka fínstillt. Við reyndum mjög mikið, en þarna hefurðu tölurnar skrifaðar á tíu þúsundasta formi. Mjög óþægilegt. Á hinn bóginn mun uniqExact aðgerðin virka hægar á strengjum, ekki bara vegna þess að þetta eru strengir, heldur einnig vegna þess að önnur sérhæfing reikniritsins er valin. Strengir eru einfaldlega gerðir öðruvísi.
Hvað ef við tökum frumstæðari gagnategund? Við skrifuðum til dæmis niður notendaauðkennið sem við erum með í, skrifuðum það niður sem línu og spjölluðum það svo, verður það skemmtilegra eða ekki?
Ég efast. Ég held að það verði enn sorglegra, því þegar öllu er á botninn hvolft er það alvarlegt vandamál að flokka tölur. Mér sýnist að þessi samstarfsmaður hafi meira að segja gefið skýrslu um hversu erfitt það er að flokka tölur í tíu þúsundasta formi, en kannski ekki.
Alexey, þakka þér kærlega fyrir skýrsluna! Og takk kærlega fyrir ClickHouse! Ég er með spurningu um áætlanir. Eru einhverjar áætlanir um eiginleika til að uppfæra orðabækur ófullnægjandi?
Semsagt endurræsa að hluta?
Já já. Eins og möguleikinn á að setja MySQL reit þar, þ.e.a.s. uppfæra á eftir þannig að aðeins þessi gögn hlaðast ef orðabókin er mjög stór.
Mjög áhugaverður eiginleiki. Og ég held að einhver hafi stungið upp á því í spjallinu okkar. Kannski varst það jafnvel þú.
Ég held ekki.
Frábært, nú kemur í ljós að það eru tvær beiðnir. Og þú getur byrjað að gera það hægt. En ég vil vara þig strax við að þessi eiginleiki er frekar einfaldur í framkvæmd. Semsagt, í orði, þú þarft bara að skrifa útgáfunúmerið í töfluna og skrifa svo: útgáfa minna en svo og svona. Þetta þýðir að líklega munum við bjóða áhugamönnum upp á þetta. Ertu áhugamaður?
Já, en því miður ekki í C++.
Kunna samstarfsmenn þínir hvernig á að skrifa í C++?
Ég skal finna einhvern.
Frábært*.
* eiginleikanum var bætt við tveimur mánuðum eftir skýrsluna - höfundur spurningarinnar þróaði hana og sendi sína .
Þakka þér!
Halló! Takk fyrir skýrsluna! Þú nefndir að ClickHouse er mjög góður í að neyta allra þeirra úrræða sem það hefur tiltækt. Og ræðumaðurinn við hlið Luxoft talaði um lausn sína fyrir Russian Post. Hann sagði að þeir væru mjög hrifnir af ClickHouse, en þeir notuðu það ekki í stað þeirra helsta keppinautar einmitt vegna þess að það væri að éta upp allan örgjörvann. Og þeir gátu ekki tengt það við arkitektúrinn sinn, í ZooKeeper þeirra með hafnarverkamönnum. Er hægt að takmarka á einhvern hátt ClickHouse þannig að það eyði ekki öllu sem verður í boði fyrir það?
Já, það er hægt og mjög auðvelt. Ef þú vilt neyta færri kjarna skaltu bara skrifa set max_threads = 1. Og það er það, það mun framkvæma beiðnina í einum kjarna. Þar að auki geturðu tilgreint mismunandi stillingar fyrir mismunandi notendur. Svo ekkert mál. Og segðu samstarfsfólki þínu frá Luxoft að það sé ekki gott að þeir hafi ekki fundið þessa stillingu í skjölunum.
Alexey, halló! Mig langar að spyrja um þessa spurningu. Þetta er ekki í fyrsta skipti sem ég hef heyrt að margir séu að byrja að nota ClickHouse sem geymslu fyrir annála. Í skýrslunni sagðirðu að þú ættir ekki að gera þetta, þ.e.a.s. þú þarft ekki að geyma langa strengi. Hvað finnst þér um það?
Í fyrsta lagi eru logs að jafnaði ekki langir strengir. Það eru auðvitað undantekningar. Til dæmis, einhver þjónusta sem skrifuð er í java gefur undantekningu, hún er skráð. Og svo framvegis í endalausri lykkju og plássið á harða disknum klárast. Lausnin er mjög einföld. Ef línurnar eru mjög langar, þá skera þær. Hvað þýðir lengi? Tugir kílóbæta eru slæmir*.
* í nýjustu útgáfum ClickHouse er „adaptive index granularity“ virkt, sem útilokar vandamálið við að geyma langar raðir að mestu leyti.
Er kílóbæti eðlilegt?
Það er eðlilegt.
Halló! Takk fyrir skýrsluna! Ég spurði nú þegar um þetta í spjallinu, en ég man ekki hvort ég fékk svar. Eru áform um að stækka WITH hlutann á einhvern hátt að hætti CTE?
Ekki enn. WITH hluti okkar er nokkuð léttvægur. Það er eins og lítill eiginleiki fyrir okkur.
Ég skil. Þakka þér fyrir!
Takk fyrir skýrsluna! Mjög áhugavert! Alþjóðleg spurning. Eru einhverjar áætlanir um að breyta eyðingu gagna, kannski í formi einhvers konar stubba?
Nauðsynlega. Þetta er fyrsta verkefni okkar í röðinni. Við erum nú virkir að hugsa um hvernig á að gera allt rétt. Og þú ættir að byrja að ýta á lyklaborðið*.
* ýtti á takkana á lyklaborðinu og gerði allt.
Mun þetta einhvern veginn hafa áhrif á afköst kerfisins eða ekki? Verður innsetningin eins hröð og hún er núna?
Kannski verða eyðingarnar sjálfar og uppfærslurnar sjálfar mjög þungar, en þetta mun ekki hafa áhrif á frammistöðu val eða frammistöðu innskots.
Og enn ein lítil spurning. Á kynningunni talaðir þú um aðallykil. Í samræmi við það höfum við skiptingu, sem er sjálfgefið mánaðarlega, ekki satt? Og þegar við setjum dagsetningarbil sem passar inn í mánuð, þá er aðeins þessi skipting lesin, ekki satt?
Já ég er.
Spurning. Ef við getum ekki valið neinn aðallykil, er þá rétt að gera það sérstaklega í samræmi við „Dagsetning“ reitinn þannig að í bakgrunni sé minni endurröðun á þessum gögnum þannig að þau passi á skipulegri hátt? Ef þú ert ekki með sviðsfyrirspurnir og þú getur ekki einu sinni valið neinn aðallykil, er þá þess virði að setja dagsetningu í aðallykilinn?
Já ég er.
Kannski er skynsamlegt að setja reit í aðallykilinn sem mun þjappa gögnunum betur ef þeim er raðað eftir þessu sviði. Til dæmis notandakenni. Notandi fer til dæmis á sömu síðu. Í þessu tilviki skaltu setja notandaauðkenni og tíma. Og þá verða gögnin þín betur þjappuð. Hvað dagsetninguna varðar, ef þú ert í raun ekki með og hefur aldrei sviðsfyrirspurnir um dagsetningar, þá þarftu ekki að setja dagsetninguna í aðallykilinn.
OK þakka þér kærlega fyrir!
Heimild: www.habr.com