Kadangi ClickHouse yra specializuota sistema, ją naudojant svarbu atsižvelgti į jos architektūros ypatybes. Šiame pranešime Aleksejus papasakos apie dažniausiai pasitaikančių klaidų naudojant ClickHouse pavyzdžius, dėl kurių darbas gali būti neefektyvus. Praktiniai pavyzdžiai parodys, kaip pasirinkus vieną ar kitą duomenų apdorojimo schemą galima keisti našumą dydžiais.
Sveiki visi! Mano vardas Aleksejus, kuriu ClickHouse.
Pirma, aš skubu jus įtikti iš karto, šiandien nepasakysiu, kas yra ClickHouse. Jei atvirai, aš pavargau nuo to. Kaskart sakau, kas tai yra. Ir tikriausiai visi jau žino.
Vietoj to aš jums pasakysiu, kokios galimos klaidos, tai yra, kaip galite neteisingai naudoti ClickHouse. Tiesą sakant, baimintis nereikia, nes ClickHouse kuriame kaip paprastą, patogią ir iš karto veikiančią sistemą. Įdiegiau, jokių problemų.
Tačiau vis tiek reikia atsižvelgti į tai, kad ši sistema yra specializuota ir galite lengvai susidurti su neįprastu naudojimo atveju, kuris išves šią sistemą iš komforto zonos.
Taigi, koks ten grėblys? Dažniausiai kalbėsiu apie akivaizdžius dalykus. Visiems viskas aišku, visi viską supranta ir gali džiaugtis, kad tokie protingi, o kas nesupranta, sužinos kažką naujo.
Pirmasis ir paprasčiausias pavyzdys, kuris, deja, dažnai pasitaiko, yra daug įdėklų su mažomis partijomis, t.y. daug mažų įdėklų.
Jei atsižvelgsime į tai, kaip ClickHouse atlieka įterpimą, tada vienoje užklausoje galite išsiųsti bent terabaitą duomenų. Tai ne problema.
Ir pažiūrėkime, koks būtų tipiškas pasirodymas. Pavyzdžiui, turime lentelę iš Yandex.Metrica duomenų. Hitai. 105 kai kurie stulpeliai. 700 baitų nesuspaustas. Ir mes įterpsime gerąja prasme milijono eilučių partijomis.
Į lentelę įterpiame MergeTree, pasirodo pusė milijono eilučių per sekundę. Puiku. Pakartotoje lentelėje jis bus šiek tiek mažesnis, maždaug 400 000 eilučių per sekundę.
Ir jei įgalinsite kvorumo įterpimą, gausite šiek tiek mažiau, bet vis tiek neblogą našumą – 250 000 terminų per sekundę. Kvorumo įterpimas yra nedokumentuota ClickHouse* funkcija.
* nuo 2020 m. .
Kas atsitiks, jei padarysi ką nors blogo? Į MergeTree lentelę įterpiame vieną eilutę ir gauname 59 eilutes per sekundę. Tai 10 000 kartų lėčiau. ReplicatedMergeTree – 6 eilutės per sekundę. Ir jei kvorumas įjungtas, tada pasirodo 2 eilutės per sekundę. Mano nuomone, tai kažkoks absoliutus šūdas. Kaip galima taip sulėtinti tempą? Netgi ant marškinėlių parašyta, kad ClickHouse neturėtų sulėtinti greičio. Bet vis dėlto kartais taip nutinka.
Tiesą sakant, tai yra mūsų trūkumas. Galėjome lengvai viską padaryti gerai, bet to nepadarėme. Ir mes to nepadarėme, nes mūsų scenarijus to nereikalavo. Mes jau turėjome butchų. Mes ką tik gavome partijas prie įėjimo ir jokių problemų. Įdedame ir viskas veikia gerai. Bet, žinoma, galimi visokie scenarijai. Pavyzdžiui, kai turite daugybę serverių, kuriuose generuojami duomenys. Ir jie ne taip dažnai įterpia duomenis, bet vis tiek dažnai įterpiami. Ir mes turime kažkaip to išvengti.
Techniniu požiūriu esmė ta, kad kai įterpiate „ClickHouse“, duomenys nepatenka į jokią įsimintiną lentelę. Mes net neturime tikros žurnalo struktūros MergeTree, o tik MergeTree, nes nėra nei žurnalo, nei memTable. Tiesiog iš karto įrašome duomenis į failų sistemą, jau išdėstytus stulpeliais. Ir jei turite 100 stulpelių, tada daugiau nei 200 failų reikės įrašyti į atskirą katalogą. Visa tai labai sudėtinga.
Ir kyla klausimas: „Kaip tai padaryti teisingai?“ Jei situacija tokia, kad vis tiek reikia kažkaip įrašyti duomenis „ClickHouse“.
1 būdas. Tai lengviausias būdas. Naudokite tam tikrą paskirstytą eilę. Pavyzdžiui, Kafka. Jūs tiesiog ištraukiate duomenis iš Kafkos ir vieną kartą per sekundę sugrupuojate juos. Ir viskas bus gerai, įrašai, viskas veikia gerai.
Trūkumai yra tai, kad Kafka yra dar viena didelė paskirstyta sistema. Taip pat suprantu, jei jūsų įmonėje jau yra Kafka. Tai gerai, patogu. Bet jei jos nėra, turėtumėte tris kartus pagalvoti, prieš įtraukdami į savo projektą dar vieną paskirstytą sistemą. Ir todėl verta pagalvoti apie alternatyvas.
2 būdas. Tai senosios mokyklos alternatyva ir tuo pačiu labai paprasta. Ar turite kokį nors serverį, kuris generuoja jūsų žurnalus. Ir tai tiesiog įrašo jūsų žurnalus į failą. Pavyzdžiui, kartą per sekundę pervardijame šį failą ir nuplėšiame naują. Ir atskiras scenarijus, per cron arba kokį nors demoną, paima seniausią failą ir įrašo jį į ClickHouse. Jei įrašysite žurnalus kartą per sekundę, tada viskas bus gerai.
Tačiau šio metodo trūkumas yra tas, kad jei jūsų serveris, kuriame generuojami žurnalai, kažkur dingsta, tada dings ir duomenys.
3 būdas. Yra dar vienas įdomus būdas, kuriam visiškai nereikia laikinųjų failų. Pavyzdžiui, turite kokį nors reklamos suktuką ar kitą įdomų demoną, kuris generuoja duomenis. Ir jūs galite kaupti krūvą duomenų tiesiai į RAM, buferį. O kai praeina pakankamai laiko, atidedate šį buferį į šalį, sukuriate naują ir atskiroje gijoje įdedate į ClickHouse tai, kas jau susikaupė.
Kita vertus, duomenys taip pat dingsta su kill -9. Jei jūsų serveris sugenda, prarasite šiuos duomenis. Ir dar viena problema yra ta, kad jei nepavyko rašyti į duomenų bazę, jūsų duomenys kaupsis RAM. Ir arba baigsis RAM, arba tiesiog prarasite duomenis.
4 būdas. Kitas įdomus metodas. Ar turite kokį nors serverio procesą. Ir jis gali nedelsiant siųsti duomenis į ClickHouse, bet tai padaryti vienu ryšiu. Pavyzdžiui, išsiunčiau http užklausą su perdavimo kodavimu: chunked with insert. Ir ji generuoja gabalus ne per retai, galite siųsti kiekvieną eilutę, nors bus papildomų išlaidų už šių duomenų įrėminimą.
Tačiau tokiu atveju duomenys bus nedelsiant išsiųsti į ClickHouse. Ir ClickHouse pats juos buferiuos.
Tačiau kyla ir problemų. Dabar prarasite duomenis, įskaitant tuos atvejus, kai jūsų procesas bus nužudytas ir „ClickHouse“ procesas bus nužudytas, nes tai bus neišsamus įterpimas. O ClickHouse intarpai yra atominiai iki tam tikros nurodytos eilučių dydžio slenksčio. Iš principo tai įdomus būdas. Taip pat galima naudoti.
5 metodas. Štai dar vienas įdomus metodas. Tai tam tikras bendruomenės sukurtas duomenų paketų kaupimo serveris. Pats nežiūrėjau, todėl nieko negaliu garantuoti. Tačiau pačiam ClickHouse garantijos nesuteikiamos. Tai taip pat yra atvirojo kodo, bet, kita vertus, galite būti pripratę prie kai kurių kokybės standartų, kuriuos stengiamės pateikti. Bet dėl šio dalyko - aš nežinau, eikite į „GitHub“, pažiūrėkite į kodą. Gal ką nors normalaus parašė.
* nuo 2020 m., taip pat turėtų būti atsižvelgta .
6 būdas. Kitas būdas yra naudoti buferio lenteles. Šio metodo pranašumas yra tai, kad jį labai lengva pradėti naudoti. Sukurkite buferio lentelę ir įdėkite ją į ją.
Trūkumas yra tas, kad problema nėra visiškai išspręsta. Jei tokiu greičiu kaip MergeTree turite sugrupuoti duomenis pagal vieną paketą per sekundę, tada buferio lentelės greičiu turite sugrupuoti mažiausiai iki kelių tūkstančių per sekundę. Jei tai daugiau nei 10 000 per sekundę, tai vis tiek bus blogai. Ir jei įdėsite jį partijomis, pamatysite, kad tai yra šimtas tūkstančių eilučių per sekundę. Ir tai jau yra gana sunkių duomenų.
Taip pat buferinės lentelės neturi žurnalo. Ir jei jūsų serveryje kažkas negerai, duomenys bus prarasti.
Be to, neseniai gavome galimybę ClickHouse gauti duomenis iš Kafkos. Yra stalo variklis – Kafka. Jūs tiesiog kuriate. Ir ant jo galite pakabinti materializuotus vaizdus. Tokiu atveju ji pati ištrauks duomenis iš Kafkos ir įdės į jums reikalingas lenteles.
Ir ypač džiugina ši galimybė, kad tai padarėme ne mes. Tai bendruomenės funkcija. Ir kai sakau „bendruomenės bruožas“, tai turiu omenyje be jokios paniekos. Perskaitėme kodą, peržiūrėjome, jis turėtų veikti gerai.
* nuo 2020 m. atsirado panaši parama .
Kas dar gali būti nepatogu ar netikėta įvedant duomenis? Jei pateikiate reikšmių įterpimo užklausą ir įrašykite kai kurias apskaičiuotas išraiškas reikšmėmis. Pavyzdžiui, now() taip pat yra apskaičiuota išraiška. Ir šiuo atveju „ClickHouse“ yra priversta paleisti šių posakių interpretatorių kiekvienoje eilutėje, o našumas sumažės eilėmis. Geriau to vengti.
* Šiuo metu problema yra visiškai išspręsta, nebėra našumo regresijos naudojant išraiškas VALUES.
Kitas pavyzdys, kai gali kilti problemų, kai turite duomenų vienoje partijoje, priklausančioje daugybei skaidinių. Pagal numatytuosius nustatymus ClickHouse skaidiniai yra pagal mėnesį. Ir jei įterpiate milijono eilučių partiją ir yra kelerių metų duomenų, tada turėsite kelias dešimtis skaidinių. Ir tai prilygsta tam, kad bus keliasdešimt kartų mažesnės partijos, nes viduje jos visada pirmiausia suskirstomos į pertvaras.
* Neseniai eksperimentiniu režimu „ClickHouse“ pridėjo palaikymą kompaktiškam gabalų ir gabalų formatui RAM su įrašymo į priekį žurnalu, kuris beveik visiškai išsprendžia problemą.
Dabar pažvelkime į antrojo tipo problemas – duomenų įvedimą.
Duomenų įvedimas gali būti griežtas arba eilinis. Eilutė yra tada, kai ką tik paėmėte ją ir paskelbėte, kad visi jūsų laukai yra eilutės tipo. Tai šlykštu. To daryti nereikia.
Išsiaiškinkime, kaip tai padaryti taisyklingai tais atvejais, kai norisi pasakyti, kad turime kokį lauką, eilutę, ir tegul ClickHouse tai išsiaiškina pačiam, ir aš nesivarginsiu. Bet vis tiek verta pasistengti.
Pavyzdžiui, mes turime IP adresą. Vienu atveju išsaugojome ją kaip eilutę. Pavyzdžiui, 192.168.1.1. O kitu atveju tai bus UInt32* tipo skaičius. IPv32 adresui pakanka 4 bitų.
Pirma, kaip bebūtų keista, duomenys bus suspausti maždaug vienodai. Žinoma, skirtumas bus, bet ne toks didelis. Taigi nėra jokių ypatingų problemų su disko I/O.
Tačiau procesoriaus laikas ir užklausos vykdymo laikas labai skiriasi.
Suskaičiuokime unikalių IP adresų skaičių, jei jie saugomi kaip skaičiai. Tai veikia iki 137 milijonų eilučių per sekundę. Jei tas pats yra eilučių pavidalu, tada 37 milijonai eilučių per sekundę. Nežinau, kodėl įvyko toks sutapimas. Aš pats įvykdžiau šiuos prašymus. Bet vis tiek apie 4 kartus lėčiau.
O jei apskaičiuojate vietos diske skirtumą, tai taip pat yra skirtumas. Ir skirtumas yra maždaug ketvirtadalis, nes unikalių IP adresų yra gana daug. O jei būtų eilučių, turinčių nedaug skirtingų reikšmių, tai pagal žodyną jos būtų nesunkiai suspaustos į maždaug vienodą tūrį.
O keturis kartus laiko skirtumas slypi ne kelyje. Gal, žinoma, negaili, bet kai matau tokį skirtumą, man darosi liūdna.
Pažvelkime į skirtingus atvejus.
1. Vienas atvejis, kai turite keletą skirtingų unikalių verčių. Šiuo atveju mes naudojame paprastą praktiką, kurią tikriausiai žinote ir galite naudoti bet kuriai DBVS. Visa tai prasminga ne tik ClickHouse. Tiesiog įrašykite skaitmeninius identifikatorius į duomenų bazę. Ir jūs galite konvertuoti į eilutes ir atgal savo programos šone.
Pavyzdžiui, turite regioną. Ir jūs bandote jį išsaugoti kaip eilutę. Ir ten bus parašyta: Maskva ir Maskvos sritis. Ir kai matau, kad parašyta „Maskva“, tai nieko, bet kai Maskva, tai kažkaip visiškai liūdna. Štai kiek baitų.
Vietoj to, mes tiesiog užrašome skaičių Ulnt32 ir 250. Mes turime 250 Yandex, bet jūsų gali skirtis. Tik tuo atveju pasakysiu, kad ClickHouse turi integruotą galimybę dirbti su geobaze. Tiesiog užsirašykite katalogą su regionais, įskaitant hierarchinį, t.y. bus Maskva, Maskvos sritis ir viskas, ko jums reikia. Ir jūs galite konvertuoti užklausos lygiu.
Antroji parinktis yra maždaug tokia pati, tačiau palaikoma ClickHouse viduje. Tai yra Enum duomenų tipas. Jūs tiesiog įrašote visas reikalingas reikšmes Enum viduje. Pavyzdžiui, įrenginio tipą ir ten parašykite: stalinis kompiuteris, mobilusis, planšetinis kompiuteris, televizorius. Iš viso yra 4 variantai.
Trūkumas yra tas, kad jį reikia periodiškai keisti. Pridėta tik viena parinktis. Pakeiskime lentelę. Tiesą sakant, „ClickHouse“ keitimo lentelė yra nemokama. Ypač nemokama Enum, nes duomenys diske nesikeičia. Tačiau, nepaisant to, alter įgauna užraktą* ant stalo ir turi palaukti, kol bus įvykdyti visi pasirinkimai. Ir tik po to, kai šis pakeitimas bus įvykdytas, t. y. dar yra tam tikrų nepatogumų.
* Naujausiose ClickHouse versijose ALTER yra visiškai neblokuojantis.
Kita galimybė, kuri yra gana unikali ClickHouse, yra išorinių žodynų prijungimas. Galite rašyti skaičius ClickHouse ir laikyti savo katalogus bet kurioje jums patogioje sistemoje. Pavyzdžiui, galite naudoti: MySQL, Mongo, Postgres. Jūs netgi galite sukurti savo mikropaslaugą, kuri siųs šiuos duomenis per http. O ClickHouse lygiu rašote funkciją, kuri konvertuos šiuos duomenis iš skaičių į eilutes.
Tai specializuotas, bet labai efektyvus būdas sujungti išorinį stalą. Ir yra du variantai. Viename įgyvendinimo variante šie duomenys bus visiškai talpinami, visapusiškai randami RAM ir atnaujinami tam tikru dažnumu. Ir kitu variantu, jei šie duomenys netelpa į RAM, galite juos iš dalies išsaugoti talpykloje.
Štai pavyzdys. Yra „Yandex.Direct“. O yra reklamos kompanija ir baneriai. Tikriausiai yra apie dešimtis milijonų reklamos kompanijų. Ir jie maždaug tilpo į RAM. Ir yra milijardai reklaminių antraščių, jie netelpa. Ir mes naudojame talpykloje saugomą žodyną iš MySQL.
Vienintelė problema yra ta, kad talpykloje esantis žodynas veiks gerai, jei pataikymo rodiklis bus artimas 100%. Jei jis mažesnis, apdorodami kiekvienos duomenų paketo užklausas, iš tikrųjų turėsite paimti trūkstamus raktus ir gauti duomenis iš MySQL. Apie ClickHouse vis tiek galiu garantuoti – taip, jis nesulėtėja, apie kitas sistemas nekalbėsiu.
Be to, žodynai yra labai paprastas būdas atgaline data atnaujinti duomenis ClickHouse. Tai yra, jūs turėjote ataskaitą apie reklamos įmones, vartotojas tiesiog pakeitė reklamos įmonę ir visuose senuose duomenyse, visose ataskaitose, šie duomenys taip pat pasikeitė. Jei eilutes rašysite tiesiai į lentelę, jų atnaujinti bus neįmanoma.
Kitas būdas, kai nežinote, kur gauti savo eilučių identifikatorius. galite tiesiog sumaišyti. Be to, paprasčiausias variantas yra naudoti 64 bitų maišą.
Vienintelė problema yra ta, kad jei maiša yra 64 bitų, beveik neabejotinai turėsite susidūrimų. Nes jei ten yra milijardas eilučių, tai tikimybė jau tampa pastebima.
O taip maišyti reklamos įmonių pavadinimus būtų nelabai gerai. Jei skirtingų įmonių reklamos kampanijos bus sumaišytos, tada bus kažkas nesuprantamo.
Ir yra paprastas triukas. Tiesa, jis taip pat nelabai tinka rimtiems duomenims, bet jei kažkas nėra labai rimta, tiesiog pridėkite kliento identifikatorių prie žodyno rakto. Ir tada turėsite susidūrimų, bet tik vieno kliento viduje. Ir mes naudojame šį metodą nuorodų žemėlapiams „Yandex.Metrica“. Ten turime URL, saugome maišos. Ir žinome, kad, žinoma, pasitaiko susidūrimų. Tačiau kai puslapis rodomas, gali būti nepaisoma tikimybės, kad viename vieno vartotojo puslapyje kai kurie URL yra sulipę ir tai bus pastebėta.
Be to, daugeliui operacijų pakanka vien maišos, o pačių eilučių niekur nereikia saugoti.
Kitas pavyzdys, jei eilutės yra trumpos, pavyzdžiui, svetainių domenai. Jie gali būti laikomi taip, kaip yra. Arba, pavyzdžiui, naršyklės kalba ru yra 2 baitai. Žinoma, man tikrai gaila baitų, bet nesijaudinkite, 2 baitai nėra gaila. Palikite ją taip, kaip yra, nesijaudinkite.
Kitas atvejis, kai, priešingai, linijų yra daug ir jose daug unikalių, o net rinkinys yra potencialiai neribotas. Tipiškas pavyzdys yra paieškos frazės arba URL. Paieškos frazės, įskaitant rašybos klaidas. Pažiūrėkime, kiek unikalių paieškos frazių yra per dieną. Ir pasirodo, kad jie yra beveik pusė visų įvykių. Ir tokiu atveju galite pagalvoti, kad reikia normalizuoti duomenis, suskaičiuoti identifikatorius ir sudėti į atskirą lentelę. Bet jums to daryti nereikia. Tiesiog palikite šias eilutes tokias, kokios yra.
Geriau nieko nesugalvoti, nes jei laikysite atskirai, turėsite prisijungti. Ir šis sujungimas geriausiu atveju yra atsitiktinė prieiga prie atminties, jei ji vis dar telpa atmintyje. Jei netiks, bus problemų.
O jei duomenys saugomi vietoje, tai jie tiesiog nuskaitomi reikiama tvarka iš failų sistemos ir viskas gerai.
Jei turite URL ar kitą sudėtingą ilgą eilutę, verta pagalvoti, kad galite iš anksto apskaičiuoti tam tikrą ištrauką ir įrašyti ją į atskirą stulpelį.
Pavyzdžiui, URL domeną galite saugoti atskirai. Ir jei jums tikrai reikia domeno, tiesiog naudokite šį stulpelį ir URL bus ten, o jūs jų net neliesite.
Pažiūrėkime, koks skirtumas. ClickHouse turi specializuotą funkciją, kuri apskaičiuoja domeną. Tai labai greita, mes jį optimizavome. Ir, tiesą sakant, jis net neatitinka RFC, tačiau vis dėlto atsižvelgia į viską, ko mums reikia.
O vienu atveju tiesiog gausime URL adresus ir apskaičiuosime domeną. Tai veikia iki 166 milisekundžių. O jei paimsite paruoštą domeną, tai pasirodys tik 67 milisekundės, ty beveik tris kartus greičiau. Ir tai greičiau ne todėl, kad reikia atlikti kai kuriuos skaičiavimus, o todėl, kad skaitome mažiau duomenų.
Štai kodėl viena užklausa, kuri yra lėtesnė, turi didesnį gigabaitų per sekundę greitį. Nes skaito daugiau gigabaitų. Tai visiškai nereikalingi duomenys. Atrodo, kad užklausa vykdoma greičiau, bet užtrunka ilgiau.
O pažiūrėjus į duomenų kiekį diske paaiškėja, kad URL yra 126 megabaitai, o domenas – tik 5 megabaitai. Pasirodo, 25 kartus mažiau. Tačiau, nepaisant to, užklausa vykdoma tik 4 kartus greičiau. Bet taip yra todėl, kad duomenys yra karšti. O jei būtų šalta, tai dėl disko I/O greičiausiai būtų 25 kartus greitesnis.
Beje, įvertinus kiek mažesnis yra domenas už URL, jis išeina apie 4 kartus mažesnis.Bet kažkodėl duomenų diske užima 25 kartus mažiau. Kodėl? Dėl suspaudimo. Ir URL yra suglaudintas, ir domenas yra suspaustas. Tačiau dažnai URL yra šiukšlių krūva.
Ir, žinoma, verta naudoti tinkamus duomenų tipus, kurie yra sukurti specialiai norimoms reikšmėms arba yra tinkami. Jei naudojate IPv4, išsaugokite UInt32*. Jei IPv6, tada FixedString(16), nes IPv6 adresas yra 128 bitai, t.y. saugomas tiesiogiai dvejetainiu formatu.
O kas, jei kartais turite IPv4 adresus, o kartais IPv6? Taip, galite laikyti abu. Vienas stulpelis skirtas IPv4, kitas IPv6. Žinoma, yra galimybė rodyti IPv4 IPv6. Tai taip pat veiks, bet jei užklausose dažnai reikia IPv4 adreso, būtų malonu jį įdėti į atskirą stulpelį.
* ClickHouse dabar turi atskirus IPv4, IPv6 duomenų tipus, kurie saugo duomenis taip pat efektyviai kaip skaičiai, bet atvaizduoja juos taip pat patogiai kaip eilutes.
Taip pat svarbu pažymėti, kad verta iš anksto apdoroti duomenis. Pavyzdžiui, jūs gaunate kai kuriuos neapdorotus žurnalus. Ir gal nereikėtų jų iš karto dėti į ClickHouse, nors labai vilioja nieko nedaryti ir viskas pavyks. Tačiau vis tiek verta atlikti galimus skaičiavimus.
Pavyzdžiui, naršyklės versija. Kai kuriuose netoliese esančiame skyriuje, į kurį nenoriu rodyti pirštu, naršyklės versija saugoma taip, tai yra kaip eilutė: 12.3. Tada, norėdami sudaryti ataskaitą, jie paima šią eilutę ir padalija ją į masyvą, o tada į pirmąjį masyvo elementą. Natūralu, kad viskas sulėtėja. Paklausiau, kodėl jie tai daro. Jie man pasakė, kad jiems nepatinka priešlaikinis optimizavimas. Ir aš nemėgstu priešlaikinio pesimizavimo.
Taigi šiuo atveju teisingiau būtų padalinti į 4 stulpelius. Nebijokite čia, nes tai ClickHouse. ClickHouse yra stulpelių duomenų bazė. Ir kuo tvarkingesnės mažos kolonėlės, tuo geriau. Bus 5 naršyklės versijos, sudarykite 5 stulpelius. Tai yra gerai.
Dabar pažiūrėkime, ką daryti, jei turite daug labai ilgų eilučių, labai ilgų masyvų. Jų visai nereikia laikyti ClickHouse. Vietoj to, ClickHouse galite saugoti tik identifikatorių. Ir įtraukite šias ilgas eilutes į kitą sistemą.
Pavyzdžiui, viena iš mūsų analizės paslaugų turi tam tikrų įvykių parametrų. O jei įvykių parametrų daug, tiesiog išsaugome pirmuosius pasitaikiusius 512. Nes 512 nėra gaila.
O jei negalite apsispręsti dėl savo duomenų tipų, tuomet galite įrašyti duomenis ir į ClickHouse, bet į laikiną žurnalo tipo lentelę, skirtą laikiniesiems duomenims. Po to galite analizuoti, kokį vertybių pasiskirstymą ten turite, kas ten apskritai yra, ir sukurti tinkamus tipus.
*ClickHouse dabar turi duomenų tipą kuri leidžia efektyviai saugoti stygas su mažiau pastangų.
Dabar pažvelkime į kitą įdomų atvejį. Kartais žmonėms viskas klostosi keistai. Ateinu ir matau tai. Ir iš karto atrodo, kad tai padarė koks nors labai patyręs, protingas administratorius, turintis didelę MySQL 3.23 versijos nustatymo patirtį.
Čia matome tūkstantį lentelių, kurių kiekviena įrašo likusią dalijimą kas žino ką iš tūkstančio.
Iš esmės gerbiu kitų žmonių patirtį, įskaitant supratimą apie kančias, kurias galima įgyti per šią patirtį.
Ir priežastys daugiau ar mažiau aiškios. Tai seni stereotipai, kurie galėjo susikaupti dirbant su kitomis sistemomis. Pavyzdžiui, MyISAM lentelėse nėra sugrupuoto pirminio rakto. Ir šis duomenų padalijimo būdas gali būti beviltiškas bandymas gauti tą pačią funkciją.
Kita priežastis yra ta, kad ant didelių stalų sunku atlikti bet kokias keitimo operacijas. Viskas bus užblokuota. Nors šiuolaikinėse MySQL versijose ši problema nebėra tokia rimta.
Arba, pavyzdžiui, „microsharding“, bet apie tai vėliau.
ClickHouse to daryti nereikia, nes, pirma, pirminis raktas yra sugrupuotas, duomenys tvarkomi pagal pirminį raktą.
Ir kartais žmonės manęs klausia: „Kaip „ClickHouse“ diapazono užklausų našumas skiriasi priklausomai nuo lentelės dydžio? Sakau, kad tai visiškai nesikeičia. Pavyzdžiui, turite lentelę su milijardu eilučių ir skaitote vieno milijono eilučių diapazoną. Viskas gerai. Jei lentelėje yra trilijonas eilučių ir perskaitysite vieną milijoną eilučių, tai bus beveik tiek pat.
Ir, antra, nereikia visų dalykų, pavyzdžiui, rankinių pertvarų. Jei įeisite ir pažiūrėsite, kas yra failų sistemoje, pamatysite, kad lentelė yra gana didelė. O viduje yra kažkas panašaus į pertvaras. Tai reiškia, kad ClickHouse viską padaro už jus ir jums nereikia kentėti.
„Alter in ClickHouse“ yra nemokama, jei pakeisite stulpelį „Pridėti / nuleisti“.
Ir neturėtumėte daryti mažų lentelių, nes jei lentelėje turite 10 eilučių arba 10 000 eilučių, tai visiškai nesvarbu. ClickHouse yra sistema, kuri optimizuoja pralaidumą, o ne delsą, todėl nėra prasmės apdoroti 10 eilučių.
Tikslinga naudoti vieną didelį stalą. Atsikratykite senų stereotipų, viskas bus gerai.
Be to, naujausioje versijoje dabar turime galimybę sukurti savavališką skaidymo raktą, kad galėtume atlikti įvairias atskirų skaidinių priežiūros operacijas.
Pavyzdžiui, jums reikia daug mažų lentelių, pavyzdžiui, kai reikia apdoroti kai kuriuos tarpinius duomenis, jūs gaunate gabalėlius ir prieš rašydami į galutinę lentelę turite juose atlikti transformaciją. Šiuo atveju yra puikus stalo variklis - StripeLog. Tai panašu į TinyLog, tik geriau.
* Dabar taip pat turi ClickHouse .
Kitas antipatternas yra „microsharding“. Pavyzdžiui, reikia suskaidyti duomenis ir turite 5 serverius, o rytoj bus 6 serveriai. Ir jūs galvojate, kaip iš naujo subalansuoti šiuos duomenis. Ir vietoj to suskaldai ne į 5, o į 1 šukių. Tada kiekvieną iš šių mikroskeveldrų susiejate su atskiru serveriu. Ir jūs gausite, pavyzdžiui, 000 ClickHouse viename serveryje. Atskiri egzemplioriai atskiruose prievaduose arba atskirose duomenų bazėse.
Bet tai nėra labai gerai „ClickHouse“. Nes net vienas ClickHouse egzempliorius bando panaudoti visus turimus serverio resursus vienai užklausai apdoroti. Tai yra, jūs turite tam tikrą serverį ir, pavyzdžiui, jame yra 56 procesoriaus branduoliai. Vykdote užklausą, kuri užtrunka vieną sekundę ir naudos 56 branduolius. Ir jei viename serveryje įdėjote 200 ClickHouses, tada pasirodys, kad prasidės 10 000 gijų. Apskritai viskas bus labai blogai.
Kita priežastis – darbo pasiskirstymas tarp šių atvejų bus netolygus. Kai kurie baigs anksčiau, kiti baigs vėliau. Jei visa tai nutiktų vienu atveju, „ClickHouse“ pats išsiaiškintų, kaip teisingai paskirstyti duomenis tarp gijų.
Ir dar viena priežastis yra ta, kad turėsite tarpprocesorių ryšį per TCP. Duomenys turės būti serializuoti, deserializuoti, ir tai yra didžiulis mikroskeveldrų skaičius. Tai tiesiog neveiks efektyviai.
Kitas antipatternas, nors vargu ar jį galima pavadinti antipatternu. Tai yra didelis išankstinio sujungimo kiekis.
Apskritai išankstinis agregavimas yra geras. Turėjote milijardą eilučių, jas apibendrinote ir tapo 1 000 eilučių, o dabar užklausa vykdoma akimirksniu. Viskas puiku. Tu gali tai padaryti. Tam net „ClickHouse“ turi specialų lentelės tipą „AggregatingMergeTree“, kuris įterpiant duomenis atlieka laipsnišką agregaciją.
Tačiau kartais manote, kad apibendrinsime tokius duomenis ir tokius duomenis. Kai kuriuose gretimuose skyriuose taip pat nenoriu pasakyti, kuriame iš jų, jie naudoja SummingMergeTree lenteles, kad apibendrintų pagal pirminį raktą, o apie 20 stulpelių naudojama kaip pirminis raktas. Tik tuo atveju, kai kurių stulpelių pavadinimus pakeičiau dėl slaptumo, bet tai beveik viskas.
Ir kyla tokių problemų. Pirma, jūsų duomenų kiekis per daug nesumažėja. Pavyzdžiui, jis sumažėja tris kartus. Trys kartai būtų gera kaina už neribotas analizės galimybes, kurios atsiranda, jei jūsų duomenys nėra apibendrinti. Jei duomenys yra apibendrinti, tada vietoj analitikos gaunate tik apgailėtiną statistiką.
Ir kuo jis toks ypatingas? Faktas yra tas, kad šie žmonės iš gretimo skyriaus kartais eina ir prašo pridėti kitą stulpelį prie pirminio rakto. Tai yra, mes taip apibendriname duomenis, bet dabar norime šiek tiek daugiau. Tačiau ClickHouse neturi alternatyvaus pirminio rakto. Todėl kai kuriuos scenarijus turime parašyti C++ kalba. Ir aš nemėgstu scenarijų, net jei jie yra C++.
Ir jei pažiūrėtumėte, kam buvo sukurtas ClickHouse, tai neapibendrinti duomenys yra būtent tas scenarijus, kuriam jie gimė. Jei naudojate „ClickHouse“ neapibendrintiems duomenims, tai darote teisingai. Jei sumuojate, tai kartais atleistina.
Kitas įdomus atvejis – užklausos begaliniame cikle. Kartais einu į kokį nors gamybos serverį ir pažiūriu ten rodomą procesų sąrašą. Ir kiekvieną kartą atrandu, kad vyksta kažkas baisaus.
Pavyzdžiui, šitaip. Iš karto aišku, kad viską galima padaryti vienu prašymu. Tiesiog įrašykite URL ir sąrašą.
Kodėl daugelis tokių užklausų begaliniame cikle yra blogos? Jei indeksas nenaudojamas, tais pačiais duomenimis turėsite pereiti daug kartų. Bet jei naudojamas indeksas, pavyzdžiui, jūs turite pirminį ru raktą ir ten rašote url = kažkas. Ir jūs manote, kad jei iš lentelės bus nuskaitytas tik vienas URL, viskas bus gerai. Bet iš tikrųjų ne. Nes ClickHouse viską daro partijomis.
Kai jam reikia perskaityti tam tikrą duomenų diapazoną, jis skaito šiek tiek daugiau, nes ClickHouse indeksas yra negausus. Šis indeksas neleidžia rasti vienos atskiros lentelės eilutės, tik tam tikros rūšies diapazoną. Ir duomenys suspausti blokais. Norint perskaityti vieną eilutę, reikia paimti visą bloką ir jį atspausti. Ir jei atliksite daugybę užklausų, turėsite daug sutapimų ir turėsite atlikti daug darbo vėl ir vėl.
Ir kaip premiją galite pastebėti, kad ClickHouse neturėtumėte bijoti perkelti net megabaitų ir net šimtų megabaitų į IN skyrių. Iš mūsų praktikos prisimenu, kad jei MySQL perkeliame krūvą reikšmių į IN sekciją, pavyzdžiui, perkeliame ten 100 megabaitų kai kurių skaičių, tada MySQL suvalgo 10 gigabaitų atminties ir nieko daugiau jam neatsitinka, viskas veikia prastai.
Antra, jei jūsų užklausos naudoja indeksą „ClickHouse“, tai visada yra ne lėtesnis nei pilnas nuskaitymas, t.y. jei reikia perskaityti beveik visą lentelę, ji eis nuosekliai ir skaitys visą lentelę. Apskritai jis tai išsiaiškins pats.
Tačiau vis dėlto yra tam tikrų sunkumų. Pavyzdžiui, tai, kad IN su antrine užklausa nenaudoja indekso. Bet tai yra mūsų problema ir mes turime ją išspręsti. Čia nėra nieko esminio. Mes tai sutvarkysime*.
Ir dar vienas įdomus dalykas yra tai, kad jei turite labai ilgą užklausą ir vyksta paskirstytų užklausų apdorojimas, tada ši labai ilga užklausa bus siunčiama į kiekvieną serverį be suspaudimo. Pavyzdžiui, 100 megabaitų ir 500 serverių. Ir, atitinkamai, tinkle bus perduota 50 gigabaitų. Jis bus perduotas ir tada viskas bus sėkmingai baigta.
* jau naudoju; Viskas buvo sutvarkyta, kaip buvo žadėta.
Ir gana dažnas atvejis, kai užklausos gaunamos iš API. Pavyzdžiui, jūs sukūrėte tam tikrą savo paslaugą. Ir jei kam nors reikia jūsų paslaugos, atidarote API ir po dviejų dienų matote, kad vyksta kažkas nesuprantamo. Viskas perkrauta ir ateina keletas baisių užklausų, kurių niekada neturėjo įvykti.
Ir yra tik vienas sprendimas. Jei atidarėte API, turėsite ją iškirpti. Pavyzdžiui, įvesti kažkokias kvotas. Kitų normalių variantų nėra. Priešingu atveju jie iškart parašys scenarijų ir bus problemų.
O ClickHouse turi ypatingą funkciją – kvotų skaičiavimą. Be to, galite perkelti savo kvotos raktą. Tai, pavyzdžiui, vidinis vartotojo ID. Ir kiekvienam iš jų kvotos bus skaičiuojamos atskirai.
Dabar dar vienas įdomus dalykas. Tai rankinis replikavimas.
Žinau daug atvejų, kai, nepaisant „ClickHouse“ įdiegto replikacijos palaikymo, žmonės „ClickHouse“ replikuoja rankiniu būdu.
Koks principas? Turite duomenų apdorojimo vamzdyną. Ir jis veikia savarankiškai, pavyzdžiui, skirtinguose duomenų centruose. Tokius pačius duomenis rašote ClickHouse. Tiesa, praktika rodo, kad duomenys vis tiek skirsis dėl kai kurių jūsų kodo funkcijų. Tikiuosi, kad tai tavo.
Ir laikas nuo laiko vis tiek turėsite sinchronizuoti rankiniu būdu. Pavyzdžiui, kartą per mėnesį administratoriai atlieka rsync.
Tiesą sakant, daug lengviau naudoti „ClickHouse“ įmontuotą replikaciją. Tačiau gali būti tam tikrų kontraindikacijų, nes tam reikia naudoti ZooKeeper. Apie ZooKeeper nepasakysiu nieko blogo, is principo sistema veikia, bet pasitaiko, kad zmones nenaudoja del javafobijos, nes ClickHouse tokia gera sistema, parašyta C++ kalba, kuria galima naudotis ir viskas bus gerai . Ir ZooKeeper yra java. Ir kažkaip net nenorite žiūrėti, bet tada galite naudoti rankinį replikavimą.
ClickHouse yra praktiška sistema. Ji atsižvelgia į jūsų poreikius. Jei replikuojate rankiniu būdu, galite sukurti paskirstytą lentelę, kurioje bus peržiūrėtos neautomatinės kopijos ir atliekama perkėlimas tarp jų. Ir netgi yra speciali parinktis, leidžianti išvengti nesėkmių, net jei jūsų linijos sistemingai skiriasi.
Jei naudojate primityvius stalo variklius, gali kilti daugiau problemų. ClickHouse yra konstruktorius, turintis daugybę skirtingų lentelės variklių. Visais rimtais atvejais, kaip parašyta dokumentacijoje, naudokite MergeTree šeimos lenteles. Ir visa kita - tai yra individualiems atvejams arba bandymams.
MergeTree lentelėje jums nereikia turėti jokios datos ir laiko. Jūs vis dar galite jį naudoti. Jei datos ir laiko nėra, parašykite, kad numatytoji vertė yra 2000. Tai veiks ir nereikės išteklių.
O naujoje serverio versijoje netgi galite nurodyti, kad turite pasirinktinį skaidymą be skaidinio rakto. Bus taip pat.
Kita vertus, galite naudoti primityvius stalo variklius. Pavyzdžiui, vieną kartą užpildykite duomenis ir pažiūrėkite, pasukite ir ištrinkite. Galite naudoti žurnalą.
Arba nedidelių kiekių saugojimas tarpiniam apdorojimui yra StripeLog arba TinyLog.
Atmintis gali būti naudojama, jei duomenų kiekis yra mažas ir galite tiesiog ką nors susukti RAM.
„ClickHouse“ nelabai mėgsta renormalizuotus duomenis.
Štai tipiškas pavyzdys. Tai didžiulis URL skaičius. Įdėkite juos į kitą lentelę. Ir tada jie nusprendė padaryti JOIN su jais, bet tai, kaip taisyklė, neveiks, nes ClickHouse palaiko tik Hash JOIN. Jei RAM nepakanka daugeliui duomenų, kuriuos reikia prijungti, JOIN neveiks*.
Jei duomenys yra labai kardinalūs, nesijaudinkite, saugokite juos denormalizuota forma, URL yra tiesiogiai pagrindinėje lentelėje.
* ir dabar ClickHouse taip pat turi sujungimą ir veikia tokiomis sąlygomis, kai tarpiniai duomenys netelpa į RAM. Tačiau tai neveiksminga ir rekomendacija lieka galioti.
Dar pora pavyzdziu, bet jau abejoju ar jie antipatterniniai ar ne.
ClickHouse turi vieną žinomą trūkumą. Jis nežino, kaip atnaujinti*. Tam tikra prasme tai netgi gerai. Jei turite kokių nors svarbių duomenų, pavyzdžiui, buhalterinės apskaitos, tada niekas negalės jų išsiųsti, nes nėra atnaujinimų.
* Palaikymas naujinimui ir ištrynimui paketiniu režimu buvo pridėtas seniai.
Tačiau yra keletas specialių būdų, kurie leidžia atnaujinti tarsi fone. Pavyzdžiui, tokios lentelės kaip ReplaceMergeTree. Jie atnaujina fono sujungimo metu. Tai galite priversti naudoti optimizavimo lentelę. Tačiau nedarykite to per dažnai, nes tai visiškai perrašys skaidinį.
„ClickHouse“ paskirstytus JOIN taip pat prastai tvarko užklausų planuotojas.
Blogai, bet kartais gerai.
„ClickHouse“ naudojimas tik duomenims nuskaityti naudojant „select*“.
Nerekomenduočiau naudoti ClickHouse sudėtingiems skaičiavimams. Bet tai nėra visiškai tiesa, nes mes jau tolstame nuo šios rekomendacijos. Neseniai „Catboost“ sistemoje „Catboost“ pridėjome galimybę pritaikyti mašininio mokymosi modelius. Ir tai mane trikdo, nes galvoju: „Koks siaubas. Štai kiek ciklų viename baite! Aš tikrai nekenčiu švaistyti laikrodžių baitais.
Bet nebijokite, įdiekite ClickHouse, viskas bus gerai. Jei ką, mes turime bendruomenę. Beje, bendruomenė – tai tu. Ir jei turite kokių nors problemų, galite bent jau apsilankyti mūsų pokalbyje ir, tikiuosi, jie jums padės.
Klausimai
Ačiū už pranešimą! Kur galėčiau skųstis dėl „ClickHouse“ gedimo?
Šiuo metu galite skųstis man asmeniškai.
Neseniai pradėjau naudoti ClickHouse. Iš karto atsisakiau klip sąsajos.
Koks balas.
Šiek tiek vėliau sudaužiau serverį su mažu pasirinkimu.
Tu turi talentą.
„GitHub“ atidariau klaidą, bet ji buvo ignoruojama.
Pamatysime.
Aleksejus apgaule apgavo mane, kad dalyvaučiau ataskaitoje, pažadėdamas papasakoti, kaip galite pasiekti viduje esančius duomenis.
Labai paprasta.
Tai supratau vakar. Daugiau konkretumo.
Ten nėra baisių triukų. Yra tik blokas po bloko glaudinimas. Numatytasis yra LZ4, galite įjungti ZSTD*. Blokuoja nuo 64 kilobaitų iki 1 megabaito.
* Taip pat palaikomi specializuoti glaudinimo kodekai, kuriuos galima naudoti grandinėje su kitais algoritmais.
Ar blokai tik neapdoroti duomenys?
Ne visiškai žalias. Yra masyvai. Jei turite skaitinį stulpelį, tada eilutės skaičiai dedami į masyvą.
Tai aišku.
Aleksejus, pavyzdys, kuris buvo naudojant „uniqExact“ per IP, t. Ką daryti, jei korektūros metu naudosime apgaulę su ausimis ir messime? Tai reiškia, kad jūs, atrodo, sakėte, kad mūsų diske tai nelabai skiriasi. Jei skaitysime eilutes iš disko ir liesime, ar mūsų agregatai bus greitesni, ar ne? O gal čia vis tiek šiek tiek laimėsime? Man atrodo, kad jūs tai išbandėte, bet kažkodėl to nenurodėte etalone.
Manau, bus lėčiau nei be liejimo. Tokiu atveju IP adresas turi būti išanalizuotas iš eilutės. Žinoma, „ClickHouse“ mūsų IP adresų analizė taip pat yra optimizuota. Mes labai stengėmės, bet ten yra skaičiai, parašyti dešimtąja tūkstantine forma. Labai nepatogu. Kita vertus, funkcija uniqExact veiks lėčiau su eilutėmis ne tik todėl, kad tai yra eilutės, bet ir todėl, kad pasirinkta kita algoritmo specializacija. Stygos tiesiog apdorojamos skirtingai.
O kas, jei pasirinktume primityvesnį duomenų tipą? Pvz., užsirašėme vartotojo ID, kurį turime, užrašėme kaip eilutę, o paskui iššifravome, bus smagiau ar ne?
Aš abejoju. Manau, bus dar liūdniau, nes juk skaičių analizavimas yra rimta problema. Man atrodo, kad šis kolega netgi pateikė pranešimą, kaip sunku išanalizuoti skaičius dešimtąja tūkstantine forma, bet gal ir ne.
Aleksejus, labai ačiū už pranešimą! Ir labai ačiū už ClickHouse! Turiu klausimą dėl planų. Ar yra kokių nors planų, kad žodynai būtų atnaujinami nepilnai?
Tai yra dalinis paleidimas iš naujo?
Taip taip. Kaip ir galimybė ten nustatyti MySQL lauką, t.y. atnaujinti po to, kad būtų įkeliami tik šie duomenys, jei žodynas yra labai didelis.
Labai įdomi savybė. Ir manau, kad kažkas tai pasiūlė mūsų pokalbyje. Galbūt tai buvote net jūs.
nemanau.
Puiku, dabar paaiškėjo, kad yra du prašymai. Ir jūs galite pamažu pradėti tai daryti. Tačiau iš karto noriu perspėti, kad šią funkciją įgyvendinti gana paprasta. Tai yra, teoriškai jums tereikia lentelėje įrašyti versijos numerį ir tada parašyti: versija mažesnė nei tokia ir tokia. Tai reiškia, kad greičiausiai tai pasiūlysime entuziastams. Ar esate entuziastas?
Taip, bet, deja, ne C++.
Ar jūsų kolegos moka rašyti C++?
Aš surasiu ką nors.
Puiku*.
* funkcija buvo pridėta praėjus dviem mėnesiams po ataskaitos – klausimo autorius ją sukūrė ir atsiuntė savo .
Dėkojame!
Sveiki! Ačiū už pranešimą! Minėjote, kad „ClickHouse“ labai gerai išnaudoja visus turimus išteklius. O kalbėtojas šalia Luxofto kalbėjo apie savo sprendimą Rusijos paštui. Jis teigė, kad „ClickHouse“ jiems labai patiko, tačiau vietoj pagrindinio konkurento jo nenaudojo būtent dėl to, kad jis suvalgė visą procesorių. Ir jie negalėjo to prijungti prie savo architektūros, prie savo ZooKeeper su dokeriais. Ar galima kaip nors apriboti ClickHouse, kad jis nevartotų visko, kas jam tampa prieinama?
Taip, tai įmanoma ir labai paprasta. Jei norite sunaudoti mažiau branduolių, tiesiog rašykite set max_threads = 1. Ir viskas, jis įvykdys užklausą viename branduolyje. Be to, skirtingiems vartotojams galite nurodyti skirtingus nustatymus. Taigi jokių problemų. Ir pasakykite savo kolegoms iš Luxoft, kad nėra gerai, kad jie nerado šio nustatymo dokumentuose.
Aleksejus, labas! Norėčiau paklausti šiuo klausimu. Tai ne pirmas kartas, kai girdžiu, kad daugelis žmonių „ClickHouse“ pradeda naudoti kaip žurnalų saugyklą. Ataskaitoje sakėte to nedaryti, t. y. jums nereikia saugoti ilgų eilučių. Ką jūs manote apie tai?
Pirma, rąstai, kaip taisyklė, nėra ilgos eilutės. Žinoma, yra išimčių. Pavyzdžiui, kažkokia java parašyta paslauga meta išimtį, ji registruojama. Ir taip tęsiasi begalinis ciklas, o vietos standžiajame diske baigiasi. Sprendimas labai paprastas. Jei linijos yra labai ilgos, supjaustykite jas. Ką reiškia ilgas? Dešimtys kilobaitų yra blogai*.
* Naujausiose „ClickHouse“ versijose įjungtas „adaptyvaus indekso detalumas“, kuris pašalina ilgų eilučių saugojimo problemą.
Ar kilobaitas normalus?
Tai normalu.
Sveiki! Ačiū už pranešimą! Jau klausiau apie tai pokalbyje, bet nepamenu, ar gavau atsakymą. Ar yra planų kaip nors išplėsti WITH skyrių CTE būdu?
Dar ne. Mūsų SU skyrius yra šiek tiek nerimtas. Mums tai tarsi maža savybė.
Aš suprantu. Ačiū!
Ačiū už pranešimą! Labai įdomu! Globalus klausimas. Ar yra kokių nors planų pakeisti duomenų ištrynimą, galbūt kaip kokių nors stulpelių?
Būtinai. Tai pirmoji mūsų užduotis eilėje. Dabar aktyviai galvojame, kaip viską padaryti teisingai. Ir jūs turėtumėte pradėti spausti klaviatūrą*.
* spaudė klaviatūros mygtukus ir padarė viską.
Ar tai kažkaip paveiks sistemos veikimą, ar ne? Ar įterpimas vyks taip greitai, kaip dabar?
Galbūt patys ištrynimai ir patys atnaujinimai bus labai sunkūs, tačiau tai neturės įtakos pasirinkimų ar įdėklų veikimui.
Ir dar vienas mažas klausimas. Pristatyme kalbėjote apie pirminį raktą. Atitinkamai, mes turime skaidymą, kuris pagal numatytuosius nustatymus yra kas mėnesį, tiesa? Ir kai nustatome dienų seką, kuri telpa į mėnesį, skaitomas tik šis skaidinys, tiesa?
Taip.
Klausimas. Jei negalime pasirinkti jokio pirminio rakto, ar teisinga tai daryti konkrečiai pagal lauką „Data“, kad fone būtų mažiau šių duomenų pertvarkymų, kad jie tvarkingiau tilptų? Jei neturite diapazono užklausų ir net negalite pasirinkti jokio pirminio rakto, ar verta į pirminį raktą įrašyti datą?
Taip.
Galbūt prasminga į pirminį raktą įdėti lauką, kuris geriau suglaudins duomenis, jei jie bus surūšiuoti pagal šį lauką. Pavyzdžiui, vartotojo ID. Pavyzdžiui, vartotojas eina į tą pačią svetainę. Tokiu atveju įveskite vartotojo ID ir laiką. Tada jūsų duomenys bus geriau suspausti. Kalbant apie datą, jei tikrai neturite ir niekada neturite diapazono užklausų dėl datų, datos nereikia įrašyti į pirminį raktą.
Gerai labai ačiū!
Šaltinis: www.habr.com