Sûnt ClickHouse is in spesjalisearre systeem, is it wichtich om rekken te hâlden mei de eigenaardichheden fan syn arsjitektuer as jo it brûke. Yn dit rapport sil Alexey prate oer foarbylden fan typyske flaters by it brûken fan ClickHouse, wat kin liede ta ineffisjint wurk. Mei praktyske foarbylden sille wy sjen litte hoe't de kar fan ien of oare gegevensferwurkingsskema prestaasjes kin feroarje troch oarders fan grutte.
Hoi allegearre! Myn namme is Alexey, ik meitsje ClickHouse.
As earste, ik haastje om jo direkt te behagen, ik sil jo hjoed net fertelle wat ClickHouse is. Om earlik te wêzen, ik bin der nocht fan. Ik fertel dy elke kear wat it is. En wierskynlik wit elkenien it al.
Ynstee sil ik jo fertelle wat de mooglike rake is, dus hoe't ClickHouse kin wurde misbrûkt. Yn feite moatte jo net bang wêze, om't wy ClickHouse ûntwikkelje as in systeem dat ienfâldich, handich is en bûten it fak wurket. Alles ynstalleare, gjin probleem.
Mar dochs, it moat wurde betocht dat dit systeem is spesjalisearre en jo kinne maklik stroffelje op in ûngewoane gebrûk gefal dat sil nimme dit systeem út syn komfort sône.
Dus, wat binne de harken? Yn prinsipe sil ik prate oer de foar de hân lizzende dingen. Alles is foar elkenien dúdlik, elkenien begrypt alles en kin bliid wêze dat se sa tûk binne, en wa't it net begrypt, sil wat nijs leare.
It earste ienfâldichste foarbyld, dat, spitigernôch, faak foarkomt, is in grut oantal ynserts mei lytse batches, dus in grut oantal lytse ynserts.
As wy beskôgje hoe't ClickHouse in ynfoegje útfiert, dan kinne jo op syn minst in terabyte oan gegevens yn ien fersyk stjoere. It is gjin probleem.
En lit ús sjen wat de typyske prestaasje sil wêze. Bygelyks, wy hawwe in tabel mei Yandex.Metrics gegevens. Hits. 105 guon kolommen. 700 bytes net komprimearre. En wy sille op in goede manier batches fan ien miljoen rigels ynfoegje.
Wy ynfoegje yn 'e MergeTree-tabel, in heal miljoen rigen per sekonde wurde krigen. Grut. Yn in replikearre tabel - it sil in bytsje minder wêze, sawat 400 rigen per sekonde.
En as jo de quorum-ynfoegje oansette, krije jo in bytsje minder, mar dochs fatsoenlike prestaasje, 250 kear per sekonde. Quorum Ynfoegje is in net dokumintearre funksje yn ClickHouse *.
* fanôf 2020, .
Wat bart der as jo it ferkeard dogge? Wy ynfoegje ien rige yn 'e MergeTree-tabel en wy krije 59 rigen per sekonde. Dit is 10 kear stadich. Yn ReplicatedMergeTree - 000 rigen per sekonde. En as it kworum ynskeakele is, dan wurde 6 rigels per sekonde krigen. Yn myn miening is dit in soarte fan folsleine stront. Hoe kinne jo sa fertrage? It stiet sels op myn T-shirt dat ClickHouse net fertrage moat. Mar dochs bart it soms.
Yn feite is dit ús tekoart. Wy koenen it goed meitsje, mar dat diene wy net. En dat diene wy net, want ús skript hie it net nedich. Wy hiene al batches. Wy krigen krekt batches by de yngong, en gjin problemen. Plug it yn en alles wurket goed. Mar fansels binne allerhanne senario's mooglik. Bygelyks, as jo in bosk servers hawwe wêrop gegevens wurde generearre. En se ynfoegje gegevens net sa faak, mar se krije dochs faak ynfoegingen. En jo moatte dit op ien of oare manier foarkomme.
Fanút in technysk eachpunt is de ûnderste rigel dat as jo in ynfoegje yn ClickHouse dogge, de gegevens net yn ien memtabel komme. Wy hawwe net iens in echte MergeTree-logstruktuer, mar gewoan in MergeTree, om't d'r gjin log noch memTable is. Wy skriuwe gewoan fuortendaliks de gegevens nei it bestânsysteem, al ferdield yn kolommen. En as jo 100 kolommen hawwe, dan moatte mear as 200 bestannen skreaun wurde yn in aparte map. Dit alles is tige omslachtig.
En de fraach ûntstiet: "Hoe te dwaan it rjocht?" As sa'n situaasje, jo moatte noch ien of oare manier skriuwe gegevens oan ClickHouse.
Metoade 1. Dit is de maklikste manier. Brûk in soarte fan ferdielde wachtrige. Bygelyks, Kafka. Jo nimme gewoan gegevens út Kafka, wy batch it ien kear in sekonde. En alles sil goed wêze, jo opnimme, alles wurket goed.
De neidielen binne dat Kafka in oar omslachtig ferspraat systeem is. Ik begryp ek as jo al Kafka yn jo bedriuw hawwe. It is goed, it is handich. Mar as it d'r net is, dan moatte jo trije kear tinke foardat jo in oar ferspraat systeem yn jo projekt slepe. En dus is it wurdich om alternativen te beskôgjen.
Metoade 2. Hjir is sa'n âld-skoalle alternatyf en tagelyk hiel simpel. Hawwe jo in soarte fan tsjinner dy't generearret jo logs. En it skriuwt gewoan jo logs nei in bestân. En ien kear in sekonde, bygelyks, omneame wy dizze triem, iepenje in nij. En in apart skript, itsij troch cron as wat daemon, nimt it âldste bestân en skriuwt it nei ClickHouse. As jo ien kear in sekonde logs skriuwe, dan sil alles goed wêze.
Mar it neidiel fan dizze metoade is dat as jo server wêrop de logs wurde generearre earne ferdwûn is, dan sille de gegevens ek ferdwine.
Metoade 3. Der is in oare nijsgjirrige manier, dy't hielendal sûnder tydlike triemmen is. Jo hawwe bygelyks in soarte fan reklamespinner of in oare nijsgjirrige daemon dy't gegevens genereart. En jo kinne sammelje in boskje gegevens direkt yn 'e RAM, yn' e buffer. En as in foldwaande tiid foarby giet, sette jo dizze buffer oan 'e kant, meitsje in nije en ynfoegje wat al sammele is yn ClickHouse yn in aparte thread.
Oan 'e oare kant ferdwine de gegevens ek mei kill -9. As jo tsjinner delgiet, sille jo dizze gegevens ferlieze. En in oar probleem is dat as jo net kinne skriuwe nei de databank, dan sille jo gegevens sammelje yn 'e RAM. En of de RAM rint út, of jo ferlieze gewoan gegevens.
Metoade 4. In oare nijsgjirrige manier. Hawwe jo in tsjinner proses. En hy kin stjoere gegevens nei ClickHouse yn ien kear, mar doch it yn ien ferbining. Bygelyks, ik stjoerde in http-fersyk mei transfer-kodearring: chunked with insert. En it genereart brokken net te selden, jo kinne elke rigel stjoere, hoewol d'r in overhead sil wêze foar it framen fan dizze gegevens.
Yn dit gefal wurde de gegevens lykwols direkt nei ClickHouse stjoerd. En ClickHouse sels sil se bufferje.
Mar der binne ek problemen. No sille jo gegevens ferlieze, ynklusyf wannear't jo proses is fermoarde en as it ClickHouse-proses is fermoarde, om't it in ûnfolsleine ynfoegje sil wêze. En yn ClickHouse binne ynserts atomyske oant guon oantsjutte drompel yn 'e grutte fan rigen. Yn prinsipe is dit in nijsgjirrige manier. Ek kin brûkt wurde.
Metoade 5. Hjir is in oare nijsgjirrige manier. Dit is in soarte fan mienskip ûntwikkele server foar databatching. Ik ha der sels net nei sjoen, dus ik kin neat garandearje. D'r binne lykwols gjin garânsjes foar ClickHouse sels. Dit is ek iepen boarne, mar oan 'e oare kant kinne jo wend wurde oan wat kwaliteitsstandert dy't wy besykje te leverjen. Mar foar dit ding - ik wit it net, gean nei GitHub, sjoch nei de koade. Miskien hawwe se wat goeds skreaun.
* fanôf 2020, moat ek wurde tafoege oan beskôging .
Metoade 6. In oare manier is in gebrûk Buffer tabellen. It foardiel fan dizze metoade is dat it is hiel maklik om te begjinnen mei it brûken. Meitsje in buffertabel en ynfoegje deryn.
Mar it neidiel is dat it probleem net folslein oplost is. As jo mei in taryf fan it MergeTree-type gegevens moatte groepearje mei ien batch per sekonde, dan moatte jo op syn minst in oantal tûzen per sekonde groepearje mei in taryf yn in buffertabel. As der mear as 10 per sekonde binne, sil it noch min wêze. En as jo yn batches ynfoegje, dan seagen jo dat dêr hûnderttûzen rigels per sekonde krigen wurde. En dit is al op frij swiere gegevens.
En ek buffer tabellen hawwe gjin log. En as der wat mis is mei jo tsjinner, dan sille de gegevens ferlern gean.
En as bonus hienen wy koartlyn de kâns om gegevens fan Kafka te sammeljen yn ClickHouse. Der is in tafel motor - Kafka. Jo meitsje gewoan. En jo kinne der materialisearre werjeften oan hingje. Yn dit gefal sil hy de gegevens fan Kafka útnimme en ynfoegje yn 'e tabellen dy't jo nedich binne.
En wat foaral noflik is oan dizze kâns is dat wy it net makke hawwe. Dit is in mienskipfunksje. En as ik "mienskipsfunksje" sis, sis ik it sûnder ferachting. Wy lêze de koade, diene in resinsje, it moat goed wurkje.
* fanôf 2020 is d'r ferlykbere stipe foar .
Wat oars kin ûngemaklik of ûnferwachts wêze by it ynfoegjen fan gegevens? As jo in ynfoegje wearden query en skriuw wat berekkene útdrukkingen yn wearden. Bygelyks, no () is ek in evaluearre útdrukking. En yn dit gefal wurdt ClickHouse twongen om de tolk fan dizze útdrukkingen foar elke rigel te lansearjen, en de prestaasjes sille falle yn oarders fan grutte. Better om it te foarkommen.
* op it stuit is it probleem folslein oplost, d'r is gjin prestaasjeregression mear by it brûken fan útdrukkingen yn VALUES.
In oar foarbyld wêr't d'r wat problemen kinne wêze, is as jo gegevens op ien batch ta in boskje partysjes hearre. Standert, ClickHouse partysjes per moanne. En as jo in batch fan in miljoen rigen ynfoegje, en d'r binne gegevens foar ferskate jierren, dan sille jo dêr ferskate tsientallen partysjes hawwe. En dit is lykweardich oan it feit dat d'r batches ferskate tsientallen kearen lytser sille wêze, om't se binnen altyd earst ferdield binne yn partysjes.
* koartlyn yn ClickHouse yn eksperimintele modus tafoege stipe foar it kompakte formaat fan brokken en brokken yn RAM mei skriuw-foarút log, dy't it probleem hast folslein oplost.
No beskôgje de twadde soarte fan probleem - gegevens typen.
Gegevenstypen kin strang wêze, en soms string. String - dit is as jo krekt naam en ferklearre dat jo alle fjilden hawwe fan type string. It sjit. Dat hoege jo net te dwaan.
Lit ús útfine hoe't te dwaan it rjocht yn gefallen dêr't jo wolle sizze dat wy hawwe wat fjild, in string, en lit ClickHouse útfine it op syn eigen, mar ik sil net nimme in stoombad. Mar it is dochs de muoite wurdich om der wat yn te setten.
Wy hawwe bygelyks in IP-adres. Yn ien gefal hawwe wy it bewarre as in tekenrige. Bygelyks, 192.168.1.1. Oars sil it in oantal type UInt32 * wêze. 32 bits is genôch foar in IPv4 adres.
Earst, frjemd genôch, sille de gegevens sawat itselde wurde komprimearre. Der sil in ferskil wêze, wis, mar net sa grut. Sa binne d'r gjin spesjale problemen mei skiif I / O.
Mar d'r is in serieus ferskil yn CPU-tiid en query-útfiertiid.
Lit ús telle it oantal unike IP-adressen as se wurde opslein as nûmers. It docht bliken 137 miljoen rigels per sekonde. As itselde as rigels, dan 37 miljoen rigels per sekonde. Ik wit net wêrom dit tafal bard is. Ik haw dien dizze fersiken sels. Mar dochs sa'n 4 kear stadiger.
En as jo it ferskil yn skiifromte berekkenje, dan is d'r ek in ferskil. En it ferskil is sawat in kwart, om't d'r nochal in protte unike IP-adressen binne. En as der rigels stiene mei in lyts tal ferskillende wearden, dan soene se yn it wurdboek rêstich krimpe ta likernôch deselde bondel.
En it fjouwerfâldich tiidferskil leit net op 'e dyk. Miskien kinst dy fansels net skele, mar as ik sa'n ferskil sjoch, fiel ik my fertrietlik.
Litte wy ferskate gefallen beskôgje.
1. Ien gefal as jo in pear ferskillende unike wearden. Yn dit gefal brûke wy in ienfâldige praktyk dy't jo wierskynlik kenne en kinne brûke foar elke DBMS. Dit alles makket sin net allinich foar ClickHouse. Skriuw gewoan de numerike identifiers nei de databank. En jo kinne konvertearje nei strings en werom oan 'e kant fan jo applikaasje.
Jo hawwe bygelyks in regio. En jo besykje it te bewarjen as in tekenrige. En dêr sil skreaun wurde: Moskou en Moskou Regio. En as ik sjoch dat dêr "Moskou" skreaun is, dan is dit noch neat, en as it MO is, wurdt it op ien of oare manier folslein tryst. Dat is hoefolle bytes.
Ynstee dêrfan skriuwe wy gewoan it Ulnt32-nûmer en 250 op. Wy hawwe 250 yn Yandex, mar jo kinne oars wêze. Krekt yn gefal sil ik sizze dat ClickHouse in ynboude mooglikheid hat om te wurkjen mei in geobase. Jo skriuwe gewoan in map op mei regio's, ynklusyf in hiërargyske, d.w.s. d'r sil Moskou, Moskou-regio wêze en alles wat jo nedich binne. En jo kinne konvertearje op it fersyknivo.
De twadde opsje is sawat itselde, mar mei stipe binnen ClickHouse. It is in Enum-gegevenstype. Jo skriuwe gewoan alle wearden dy't jo nedich binne yn 'e Enum. Bygelyks, it type apparaat en skriuw dêr: buroblêd, mobyl, tablet, TV. Allinnich 4 opsjes.
It neidiel is dat jo periodyk moatte feroarje. Der is mar ien opsje tafoege. Wy meitsje in alter tafel. Yn feite, feroarje tabel yn ClickHouse is fergees. Benammen fergees foar Enum omdat de gegevens op skiif net feroarje. Mar nettsjinsteande, alter krijt in slot * op 'e tafel en moat wachtsje oant alle seleksjes binne foltôge. En pas nei dizze alter sil wurde útfierd, dat wol sizze, der binne noch wat ûngemak.
* yn resinte ferzjes fan ClickHouse is ALTER folslein net-blokkearjend makke.
In oare opsje frij unyk foar ClickHouse is de ferbining fan eksterne wurdboeken. Jo kinne nûmers skriuwe yn ClickHouse, en jo mappen hâlde yn elk systeem dat jo handich binne. Jo kinne bygelyks brûke: MySQL, Mongo, Postgres. Jo kinne sels jo eigen mikrotsjinst oanmeitsje, dy't dizze gegevens sil stjoere fia http. En op it ClickHouse-nivo skriuwe jo in funksje dy't dizze gegevens sil konvertearje fan sifers nei snaren.
Dit is in spesjalisearre, mar hiel effisjint in útfiere in join op in eksterne tafel. En d'r binne twa opsjes. Yn ien opsje sille dizze gegevens folslein yn 'e cache wurde, folslein oanwêzich yn' e RAM en op guon yntervallen bywurke. En yn in oare opsje, as dizze gegevens net passe yn 'e RAM, dan kinne jo it foar in part cache.
Hjir is in foarbyld. Der is Yandex.Direct. En der is in reklame bedriuw en banners. D'r binne wierskynlik tsientallen miljoenen reklamebedriuwen. En rûchwei passe yn 'e RAM. En d'r binne miljarden banners, se passe net. En wy brûke in cached wurdboek fan MySQL.
It ienige probleem is dat it cached wurdboek goed wurket as de hitrate tichtby 100% is. As it lytser is, dan sil it by it ferwurkjen fan oanfragen foar elk gegevenspakket nedich wêze om de ûntbrekkende kaaien eins te nimmen en te gean om gegevens fan MySQL te nimmen. Oer ClickHouse kin ik dat noch garandearje - ja, it fertraget net, ik sil net prate oer oare systemen.
En as bonus binne wurdboeken in heul maklike manier om gegevens yn ClickHouse retroaktyf te aktualisearjen. Dat is, jo hiene in rapport oer reklamebedriuwen, de brûker hat gewoan it reklamebedriuw feroare en yn alle âlde gegevens, yn alle rapporten, binne dizze gegevens ek feroare. As jo rigen direkt nei de tabel skriuwe, dan kinne jo se net bywurkje.
In oare manier as jo net witte wêr't jo de identifiers foar jo snaren kinne krije. do kinst gewoan hash. En de maklikste opsje is om in 64-bit hash te nimmen.
It ienige probleem is dat as de hash 64-bit is, dan sille jo hast wis botsingen hawwe. Want as der in miljard rigels binne, dan wurdt de kâns al tastber.
En it soe net sa goed wêze om de nammen fan reklamebedriuwen sa te hashjen. As de reklamekampanjes fan ferskate bedriuwen trochinoar komme, dan komt der wat ûnbegrypliks.
En d'r is in ienfâldige trúk. Wier, it is ek net heul geskikt foar serieuze gegevens, mar as iets net heul serieus is, foegje dan gewoan in oare klantidentifikaasje ta oan 'e wurdboekkaai. En dan sille jo botsingen hawwe, mar allinich binnen ien klant. En wy brûke dizze metoade foar de linkkaart yn Yandex.Metrica. Wy hawwe dêr URL's, wy bewarje hashes. En wy witte dat der konflikten binne, fansels. Mar as in side werjûn wurdt, dan is de kâns dat it op ien side foar ien brûker is dat guon URL's byinoar bliuwe en dit wurdt opmurken, dan kin dit ferwaarleazge wurde.
As bonus binne foar in protte operaasjes allinich hashes genôch en de snaren sels kinne net oeral wurde opslein.
In oar foarbyld as de strings koart binne, lykas websidedomeinen. Se kinne wurde opslein as se binne. Of, bygelyks, de browsertaal ru is 2 bytes. Fansels fyn ik it jammer foar de bytes, mar meitsje jo gjin soargen, 2 bytes binne gjin meilijen. Hâld it asjebleaft sa't it is, meitsje jo gjin soargen.
In oar gefal is as, krekt oarsom, d'r in protte snaren binne en tagelyk in protte unike yn har binne, en sels de set is mooglik ûnbeheind. In typysk foarbyld is sykwurden of URL's. Sykwurden, ynklusyf fanwege typflaters. Litte wy sjen hoefolle unike sykfrasen per dei. En it docht bliken dat se hast de helte fan alle eveneminten binne. En yn dit gefal kinne jo tinke dat jo de gegevens moatte normalisearje, de identifiers telle, se yn in aparte tabel pleatse. Mar dat hoege jo net te dwaan. Hâld dizze rigels gewoan sa't it is.
Better - net útfine neat, want as jo bewarje it apart, do silst moatte dwaan in join. En dit join is op syn bêste in willekeurige tagong ta ûnthâld, as it noch past yn it ûnthâld. As it net past, dan sil der problemen wêze yn it algemien.
En as de gegevens op it plak binne opslein, dan wurde se gewoan yn 'e juste folchoarder lêzen fan it bestânsysteem en alles is goed.
As jo URL's of in oare komplekse lange string hawwe, dan moatte jo tinke oan it feit dat jo fan tefoaren wat squeeze kinne berekkenje en it yn in aparte kolom skriuwe.
Foar urls kinne jo bygelyks it domein apart opslaan. En as jo echt in domein nedich hawwe, brûk dan gewoan dizze kolom, en de URL's sille lizze, en jo sille se net iens oanreitsje.
Litte wy sjen wat it ferskil is. ClickHouse hat in spesjalisearre funksje dy't it domein berekkent. It is heul rap, wy hawwe it optimalisearre. En, om earlik te wêzen, foldocht it net iens oan 'e RFC, mar beskôget lykwols alles wat wy nedich binne.
En yn ien gefal sille wy gewoan de URL's krije en it domein berekkenje. It docht bliken 166 millisekonden. En as jo in ready-made domein nimme, dan blykt it mar 67 millisekonden, dat is hast trije kear flugger. En flugger, net om't wy wat berekkeningen moatte dwaan, mar om't wy minder gegevens lêze.
Om ien of oare reden krijt ien fersyk, dat stadiger is, mear snelheid yn gigabytes per sekonde. Omdat it lêst mear gigabytes. Dit binne folslein oerstallige gegevens. It fersyk liket flugger te rinnen, mar duorret langer om te foltôgjen.
En as jo sjogge nei de hoemannichte gegevens op 'e skiif, docht bliken dat de URL is 126 megabytes, en it domein is mar 5 megabytes. It docht 25 kear minder út. De query is lykwols noch mar 4 kear flugger. Mar dat is om't de gegevens hyt binne. En as it kâld wie, soe it wierskynlik 25 kear rapper wêze troch skiif I / O.
Trouwens, as jo evaluearje hoefolle it domein minder is as de URL, dan docht bliken dat it sawat 4 kear is, mar om ien of oare reden nimt de gegevens op 'e skiif 25 kear minder. Wêrom? Troch kompresje. En de url is komprimearre, en it domein is komprimearre. Mar faak befettet de url in boskje jiskefet.
En, fansels, it is it wurdich om de juste gegevenstypen te brûken dy't spesifyk binne ûntworpen foar de juste wearden of dy't passe. As jo yn IPv4 binne, bewarje dan UInt32 *. As IPv6, dan FixedString(16), om't in IPv6-adres 128 bits is, dus direkt opslaan yn binêre opmaak.
Mar wat as jo soms IPv4-adressen hawwe en soms IPv6? Ja, jo kinne beide hâlde. Ien kolom foar IPv4, in oare foar IPv6. Fansels is d'r in opsje om IPv4 nei IPv6 yn kaart te bringen. Dit sil ek wurkje, mar as jo faaks in IPv4-adres nedich hawwe yn jo oanfragen, dan soe it moai wêze om it yn in aparte kolom te setten.
* No hat ClickHouse aparte IPv4, IPv6-gegevenstypen dy't gegevens sa effisjint opslaan as sifers, mar se fertsjinwurdigje sa handich as snaren.
It is ek wichtich om te notearjen dat it de muoite wurdich is om de gegevens foarôf te ferwurkjen. Bygelyks, guon rauwe logs komme nei jo. En, miskien, moatte jo se net direkt yn ClickHouse pleatse, hoewol it heul ferliedlik is om neat te dwaan en alles sil wurkje. Mar it is noch altyd de muoite wurdich om dy berekkeningen út te fieren dy't mooglik binne.
Bygelyks, browser ferzje. Yn guon oanbuorjende ôfdielings, dêr't ik de finger net op wize wol, wurdt de browserferzje dêr sa opslein, dat wol sizze as in tekenrige: 12.3. En dan, om in rapport te meitsjen, nimme se dizze tekenrige en dielen troch in array, en dan troch it earste elemint fan 'e array. Fansels, alles fertraget. Ik frege wêrom't se dit dogge. Se fertelden my dat se net fan foartidige optimisaasje hâlde. En ik hâld net fan foartiid pessimisme.
Dus yn dit gefal soe it better wêze om te ferdielen yn 4 kolommen. Wês net bang hjir, want dit is ClickHouse. ClickHouse is in kolomdatabase. En hoe netter lytse kolommen, hoe better. D'r sil 5 BrowserVersion wêze, meitsje 5 kolommen. Dit is goed.
Besjoch no wat te dwaan as jo in protte heul lange snaren hawwe, heul lange arrays. Se hoege hielendal net te wurde opslein yn ClickHouse. Ynstee dêrfan kinne jo mar wat identifier opslaan yn ClickHouse. En dizze lange rigels skowe se yn in oar systeem.
Bygelyks, ien fan ús analytyske tsjinsten hat wat barren parameters. En as der in protte parameters komme op eveneminten, bewarje wy gewoan de earste 512 dy't tsjinkomme. Want 512 is gjin meilijen.
En as jo net kinne beslute oer jo gegevenstypen, dan kinne jo ek gegevens skriuwe nei ClickHouse, mar nei in tydlike tabel fan it Log-type, dy't spesjaal is foar tydlike gegevens. Dêrnei kinne jo analysearje hokker soarte ferdieling fan wearden jo dêr hawwe, wat der oer it algemien is en de juste soarten meitsje.
* No hat ClickHouse in gegevenstype wêrmei jo snaren effisjint opslaan mei minder ynspannings.
No beskôgje in oar nijsgjirrich gefal. Soms wurkje dingen op in nuvere manier foar minsken. Ik gean en sjoch dit. En it liket fuortdaliks dat dit dien is troch guon heul betûfte, tûke admin dy't wiidweidige ûnderfining hat yn it ynstellen fan MySQL ferzje 3.23.
Hjir sjogge wy tûzen tabellen, elk fan dat befettet de rest fan dielen it is net dúdlik wat troch tûzen.
Yn prinsipe respektearje ik de ûnderfining fan oaren, ynklusyf it begripen fan hokker soarte lijen dizze ûnderfining opdien wurde kin.
En de redenen binne min of mear dúdlik. Dit binne âlde stereotypen dy't miskien hawwe sammele by it wurkjen mei oare systemen. Bygelyks, MyISAM-tabellen hawwe gjin klustere primêre kaai. En dizze manier om gegevens te dielen kin in wanhopich besykjen wêze om deselde funksjonaliteit te krijen.
In oare reden is dat it lestich is om feroaringen op grutte tafels te dwaan. Alles sil blokkearre wurde. Hoewol yn moderne ferzjes fan MySQL is dit probleem net mear sa serieus.
Of bygelyks microsharding, mar dêr letter mear oer.
Yn ClickHouse hoege jo dit net te dwaan, om't earst de primêre kaai is klustere, de gegevens wurde besteld troch de primêre kaai.
En soms freegje minsken my: "Hoe feroaret de prestaasjes fan berikfragen yn ClickHouse mei de grutte fan 'e tabel?". Ik sis dat it net feroaret. Jo hawwe bygelyks in tabel mei in miljard rigen en jo lêze in berik fan ien miljoen rigen. Alles is ynoarder. As de tafel hat in trillion rigen en jo lêze ien miljoen rigen, dan sil wêze hast itselde.
En, twadde, gjin stikken lykas hânmjittich partysjes binne net fereaske. As jo yngeane en sjogge wat der op it bestânsysteem stiet, sille jo sjen dat in tabel in aardich serieus ding is. En d'r binnen is wat as skieden. Dat is, ClickHouse docht alles foar jo en jo hoege net te lijen.
Alter yn ClickHouse is fergees as alter tafoegje / drop kolom.
En jo moatte gjin lytse tabellen meitsje, want as jo 10 rigen of 10 rigen yn jo tabel hawwe, dan makket it hielendal neat út. ClickHouse is in systeem dat trochput optimalisearret, net latency, dus it makket gjin sin om 000 rigels te ferwurkjen.
It is korrekt om ien grutte tafel te brûken. Krij de âlde stereotypen kwyt, alles komt goed.
En as bonus, yn 'e lêste ferzje, hawwe wy de kâns om in willekeurige partitioning-kaai te meitsjen om allerhanne ûnderhâldsoperaasjes op yndividuele partysjes út te fieren.
Jo hawwe bygelyks in protte lytse tabellen nedich, bygelyks as it ferlet is om wat tuskengegevens te ferwurkjen, ûntfange jo brokken en jo moatte der in transformaasje op útfiere foardat jo nei de finale tafel skriuwe. Foar dit gefal is d'r in prachtige tafelmotor - StripeLog. It is lykas TinyLog, allinich better.
* No hat ClickHouse mear .
In oar anty-patroan is microsharding. Bygelyks, jo moatte shard gegevens en do hast 5 tsjinners, en moarn sil wêze 6 tsjinners. En jo tinke hoe't jo dizze gegevens opnij balansearje. En ynstee splitst jo net yn 5 shards, mar yn 1 shards. En dan map jo elk fan dizze microshards oan in aparte tsjinner. En jo sille slagje op ien tsjinner, bygelyks, 000 ClickHouse, bygelyks. Aparte eksimplaar op aparte havens of aparte databases.
Mar yn ClickHouse is dit net heul goed. Om't sels ien eksimplaar fan ClickHouse besiket alle beskikbere serverboarnen te brûken om ien fersyk te ferwurkjen. Dat is, jo hawwe in soarte fan tsjinner en dêr, bygelyks, 56 prosessor kearnen. Jo rinne in query dy't ien sekonde duorret en it sil 56 kearnen brûke. En as jo dêr 200 ClickHouses op ien server pleatst hawwe, dan docht bliken dat 10 diskusjes begjinne. Yn 't algemien sil alles heul min wêze.
In oare reden is dat de ferdieling fan wurk oer dizze eksimplaren ûngelyk sil wêze. Guon sille earder ôfmeitsje, guon sille letter ôfmeitsje. As dit alles yn ien eksimplaar barde, dan soe ClickHouse sels útfûn hawwe hoe't jo de gegevens korrekt ûnder de streamen kinne fersprieden.
En in oare reden is dat jo interprocessor-kommunikaasje sille hawwe oer TCP. De gegevens sille moatte wurde serialized, deserialized, en dit is in enoarm oantal microshards. It sil gewoan net wurkje.
In oar antipattern, al kin it amper in antipattern neamd wurde. Dit is in grut bedrach fan pre-aggregaasje.
Yn 't algemien is preaggregation goed. Jo hiene in miljard rigen, jo hawwe it aggregearre en it waard 1 rigen, en no wurdt de query direkt útfierd. Alles is geweldich. Sa kinne jo it dwaan. En hjirfoar hat sels ClickHouse in spesjaal AggregatingMergeTree-tabeltype dat inkrementele aggregaasje docht as gegevens wurde ynfoege.
Mar d'r binne tiden dat jo tinke dat wy gegevens lykas dizze sille aggregearje en gegevens lykas dizze aggregearje. En yn guon oanbuorjende ôfdielingen wol ik ek net sizze hokker, se brûke SummingMergeTree-tabellen foar opsomming troch de primêre kaai, en 20 kolommen wurde brûkt as de primêre kaai. Foar it gefal, ik feroare de nammen fan guon kolommen foar gearspanning, mar dat is it sa.
En sokke problemen ûntsteane. Earst wurdt de hoemannichte gegevens dy't jo hawwe net te folle fermindere. Bygelyks, it wurdt fermindere troch trije kear. Trije kear soe in goede priis wêze om de ûnbeheinde analytyk te beteljen dy't komt mei it hawwen fan net-aggregearre gegevens. As de gegevens aggregearre binne, dan krije jo allinich jammerdearlike statistiken ynstee fan analytiken.
En wat is benammen goed? Dat dizze minsken fan 'e folgjende ôfdieling, gean en freegje soms te foegjen noch ien kolom oan de primêre kaai. Dat is, wy hawwe de gegevens sa aggregearre, en no wolle wy in bytsje mear. Mar d'r is gjin alter primêre kaai yn ClickHouse. Dêrom moatte jo wat skripts skriuwe yn C ++. En ik hâld net fan skripts, sels as se yn C++ binne.
En as jo sjogge wêr't ClickHouse foar is makke, dan binne net-aggregearre gegevens krekt it senario wêrfoar it is berne. As jo ClickHouse brûke foar net-aggregearre gegevens, dan dogge jo alles goed. As jo aggregearje, dan is dit soms ferjaan.
In oar nijsgjirrich gefal is oanfragen yn in ûneinige loop. Ik gean soms nei wat produksje tsjinner en sjoch op show processlist dêr. En elke kear ûntdek ik dat der wat ferskrikliks bart.
Bygelyks, hjir is dit. It is fuort dúdlik dat it mooglik wie om alles yn ien fersyk te dwaan. Skriuw gewoan de url yn en de list dêr.
Wêrom binne in protte sokke oanfragen yn in ûneinige loop min? As de yndeks net wurdt brûkt, dan sille jo in protte passes hawwe oer deselde gegevens. Mar as in yndeks wurdt brûkt, bygelyks, jo hawwe in primêre kaai op ru en jo skriuwe url = wat dêr. En jo tinke dat ien url puntsgewoan fan 'e tabel sil wurde lêzen, alles sil goed wêze. Mar echt nee. Want ClickHouse docht alles yn batches.
As hy wat berik fan gegevens lêze moat, lêst hy in bytsje mear, om't de yndeks yn ClickHouse sparse is. Dizze yndeks lit jo net ien yndividuele rige yn 'e tabel fine, allinich in soarte fan berik. En de gegevens wurde komprimearre yn blokken. Om ien rigel te lêzen, moatte jo it heule blok nimme en it útpakke. En as jo rinne in boskje queries, do silst hawwe in protte krusingen fan sokke, en do silst hawwe in soad wurk dien oer en wer.
En as bonus kinne jo sjen dat jo yn ClickHouse net bang moatte wêze om sels megabytes en sels hûnderten megabytes oer te bringen nei de IN-seksje. Ik herinner my út ús praktyk dat as wy bygelyks in bulte wearden trochjaan yn 'e IN-seksje yn MySQL, wy passe 100 megabytes fan guon nûmers dêr troch, dan yt MySQL 10 gigabytes oan ûnthâld op en der bart neat oars mei, alles wurket min.
En it twadde ding is dat yn ClickHouse, as jo queries in yndeks brûke, dan is it altyd net stadiger dan in folsleine scan, dat wol sizze as jo hast de heule tabel moatte lêze, sil it sequentieel gean en de heule tabel lêze. Yn 't algemien sil hy it útfine.
D'r binne lykwols wat swierrichheden. Bygelyks, dat IN mei in subquery net brûke de yndeks. Mar dit is ús probleem en wy moatte it reparearje. D'r is hjir neat fûneminteel. Litte wy it dwaan*.
En in oar nijsgjirrich ding is dat as jo in heul lang fersyk hawwe en ferspraat fersykferwurking giet, dan sil dit heul lange fersyk nei elke server stjoerd wurde sûnder kompresje. Bygelyks, 100 megabytes en 500 tsjinners. En sadwaande sille 50 gigabytes oer it netwurk wurde oerdroegen. It sil oerdroegen wurde en dan sil alles mei súkses útfierd wurde.
* al brûke; alles waard fêstmakke lykas tasein.
En it is frij gewoan as de oanfragen komme fan 'e API. Jo hawwe bygelyks in soarte fan tsjinst makke. En as immen jo tsjinst nedich hat, dan hawwe jo de API iepene en letterlik twa dagen letter sjogge jo dat der wat ûnbegrypliks bart. Alles is oerladen en der komme wat ferskriklike oanfragen binnen dy't nea west hawwe moatten.
En d'r is mar ien oplossing. As jo de API hawwe iepene, dan moatte jo it snije. Bygelyks om guon kwotas yn te fieren. D'r binne gjin oare ridlike opsjes. Oars skriuwe se daliks in skript en komme der problemen.
En ClickHouse hat in spesjale funksje - dit is de berekkening fan kwotas. Boppedat kinne jo jo kwota-kaai oerdrage. Dit is bygelyks in ynterne brûkers-ID. En quota's sille foar elk fan har ûnôfhinklik wurde berekkene.
No noch in nijsgjirrich ding. Dit is hânmjittich replikaasje.
Ik wit in protte gefallen wêr't, nettsjinsteande ClickHouse mei ynboude replikaasje-stipe, minsken ClickHouse manuell replikearje.
Wat is it prinsipe? Jo hawwe in pipeline foar gegevensferwurking. En it wurket selsstannich, bygelyks yn ferskate datasintra. Jo skriuwe deselde gegevens op deselde manier nei ClickHouse, as it wie. Wier, praktyk lit sjen dat de gegevens noch sille divergje fanwege guon eigenaardichheden yn jo koade. Ik hoopje dat yn dy.
En periodyk moatte jo noch manuell syngronisearje. Bygelyks, ien kear yn 'e moanne dogge admins rsync.
Yn feite is it folle makliker om de ynboude replikaasje yn ClickHouse te brûken. Mar d'r kinne wat contra-indicaties wêze, want foar dit moatte jo ZooKeeper brûke. Ik sil neat min sizze oer ZooKeeper, yn prinsipe wurket it systeem, mar it bart dat minsken it net brûke fanwegen java-foby, om't ClickHouse sa'n goed systeem is skreaun yn C ++ dat jo brûke kinne en alles sil goed wêze. En ZooKeeper yn java. En op ien of oare manier wolle jo net iens sjen, mar dan kinne jo manuele replikaasje brûke.
ClickHouse is in praktysk systeem. It hâldt rekken mei jo behoeften. As jo hânmjittich replikaasje hawwe, dan kinne jo in Distributed tabel oanmeitsje dy't sjocht nei jo hânmjittich replika's en docht in failover tusken harren. En d'r is sels in spesjale opsje wêrmei jo flops kinne foarkomme, sels as jo rigels systematysk divergent binne.
Fierder kinne d'r problemen wêze as jo primitive tafelmotoren brûke. ClickHouse is sa'n konstruktor dy't in boskje ferskate tafelmotoren hat. Foar alle serieuze gefallen, lykas skreaun yn 'e dokumintaasje, brûk tabellen fan' e MergeTree-famylje. En al de rest - dit is sa, foar yndividuele gefallen of foar testen.
Yn in MergeTree-tabel hoege jo gjin datum en tiid te hawwen. Jo kinne noch brûke. As d'r gjin datum en tiid is, skriuw dan dat standert 2000 is. It sil wurkje en sil gjin middels fereaskje.
En yn 'e nije ferzje fan' e tsjinner kinne jo sels oanjaan dat jo oanpaste partitioning hawwe sûnder in partition-kaai. It sil itselde wêze.
Oan 'e oare kant kinne primitive tafelmotoren brûkt wurde. Folje bygelyks de gegevens ien kear yn en sjoch, draaie en wiskje. Jo kinne Log brûke.
Of it opslaan fan lytse folumes foar tuskenlizzende ferwurking is StripeLog of TinyLog.
Unthâld kin brûkt wurde as der in lyts bedrach fan gegevens en gewoan twist wat yn 'e RAM.
ClickHouse hâldt net folle fan renormalisearre gegevens.
Hjir is in typysk foarbyld. Dit is in grut oantal URL's. Jo sette se yn 'e neistlizzende tafel. En doe hawwe wy besletten om JOIN mei har te dwaan, mar dit sil yn 'e regel net wurkje, om't ClickHouse allinich Hash JOIN stipet. As d'r net genôch RAM is foar in protte gegevens om te ferbinen, dan sil JOIN net wurkje *.
As de gegevens fan hege kardinaliteit binne, meitsje jo gjin soargen, bewarje it yn in denormalisearre foarm, de URL's binne direkt yn 'e haadtabel te plak.
* en no hat ClickHouse ek in gearfoegjen, en it wurket yn betingsten dêr't de tuskenlizzende gegevens net yn 'e RAM passe. Mar dit is net effektyf en de oanbefelling bliuwt jildich.
Noch in pear foarbylden, mar ik twifelje al oan oft se anty-patroanen binne of net.
ClickHouse hat ien bekend nadeel. Hy wit net hoe't er * bywurkje moat. Yn in sin is dit sels goed. As jo wat wichtige gegevens hawwe, bygelyks boekhâlding, dan sil gjinien se kinne stjoere, om't der gjin updates binne.
* Stipe foar fernijing en wiskjen yn batchmodus is lang tafoege.
Mar d'r binne wat spesjale manieren wêrtroch updates op 'e eftergrûn ferskine kinne. Bygelyks, tabellen fan it type ReplaceMergeTree. Se meitsje updates by eftergrûnfúzjes. Jo kinne twinge dit mei optimalisearjen tabel. Mar doch it net te faak, want it sil de partysje folslein oerskriuwe.
Ferdield JOIN's yn ClickHouse - dit wurdt ek min behannele troch de queryplanner.
Slecht, mar soms goed.
ClickHouse brûke gewoan om gegevens werom te lêzen mei selektearje *.
Ik soe net oanbefelje ClickHouse te brûken foar volumineuze berekkeningen. Mar dit is net hielendal wier, want wy geane al fuort fan dizze oanbefelling. En wy hawwe koartlyn de mooglikheid tafoege om modellen foar masine-learen ta te passen yn ClickHouse - Catboost. En it makket my soargen, want ik tink: “Wat in ôfgriis. Dit is hoefolle syklusen per byte it docht bliken! It is my spitich om kloksyklusen op bytes op te starten.
Mar eangje net, ynstallearje ClickHouse, alles sil goed wêze. As der wat is, hawwe wy in mienskip. Trouwens, de mienskip is jo. En as jo problemen hawwe, kinne jo op syn minst nei ús petear gean, en ik hoopje dat jo sille wurde holpen.
Jo fragen
Tank foar it ferslach! Wêr te kleien oer de crash fan ClickHouse?
Jo kinne my no persoanlik kleie.
Ik bin koartlyn begon te brûken ClickHouse. Daliks sakke de cli ynterface.
Wat in skoare.
In bytsje letter, Ik sakke de tsjinner mei in lytse seleksje.
Jo hawwe talint.
Ik iepene in GitHub-bug, mar it waard negearre.
Wy sille sjen.
Aleksey ferrifele my om it rapport by te wenjen, en beloofde my te fertellen hoe't jo de gegevens yndrukke.
It is hiel ienfâldich.
Dit is wat ik juster realisearre. Mear spesifikaasjes.
Der binne gjin ferskriklike trúkjes. It is gewoan blok-foar-blok kompresje. De standert is LZ4, jo kinne ZSTD * ynskeakelje. Blokken fan 64 kilobytes oant 1 megabyte.
* d'r is ek stipe foar spesjalisearre kompresjecodecs dy't kinne wurde brûkt yn keatling mei oare algoritmen.
Binne de blokken gewoan rau gegevens?
Net krekt rau. Der binne arrays. As jo in numerike kolom hawwe, dan wurde de nûmers yn in rige steapele yn in array.
It is dúdlik.
Alexey, in foarbyld dat wie mei uniqExact oer IPs, d.w.s. it feit dat uniqExact langer duorret om te tellen troch strings dan troch nûmers, ensfh. Wat as wy in fint mei ús earen oanbringe en op it momint fan korrektyflêzen castje? Dat is, jo lykje te hawwen sein dat it ferskilt net folle op 'e skiif. As wy lêze rigels fan de skiif, cast, dan sille wy hawwe aggregates flugger of net? Of winne wy hjir noch mar in bytsje? It liket my ta dat jo it testen, mar om ien of oare reden net oanjûn hawwe yn 'e benchmark.
Ik tink dat it sil wêze stadiger as gjin cast. Yn dit gefal moat it IP-adres fan 'e tekenrige wurde parseard. Fansels, yn ClickHouse is it parsearjen fan IP-adressen ek optimalisearre. Wy besochten hiel hurd, mar op itselde plak hawwe jo de nûmers skreaun yn tsien tûzenste foarm. Hiel ûngemaklik. Oan 'e oare kant sil de uniqExact-funksje stadiger wurkje op snaren, net allinich om't dit snaren binne, mar ek om't in oare spesjalisaasje fan it algoritme keazen is. Strings wurde gewoan oars behannele.
En as wy nimme in mear primitive gegevens type? Bygelyks, se skreaunen de brûkers-id op dy't wy yn hawwe, skreau it op as in rigel, en smiet it dan, sil it leuker wêze of net?
Ik twifelje. Ik tink dat it noch tryster sil wêze, want it parsearjen fan sifers is ommers in serieus probleem. It liket my ta dat dizze kollega sels in rapport hie oer hoe dreech it is om nûmers yn tsientûzenste foarm te parsearjen, mar miskien net.
Alexey, tige tank foar it rapport! En tige tank foar ClickHouse! Ik haw in fraach oer plannen. Is d'r in funksje yn 'e plannen foar it net folslein bywurkjen fan wurdboeken?
oftewol foar in part opnij opstarte?
Ja Ja. Lykas de mooglikheid om te setten in MySQL fjild dêr, i.e. update na sadat allinnich dizze gegevens wurdt laden as it wurdboek is hiel grut.
Hiel nijsgjirrige funksje. En, it liket my, ien hat it foarsteld yn ús petear. Miskien wie it sels jo.
Ik tink fan net.
Geweldich, no docht bliken dat twa fersiken. En jo kinne it stadichoan begjinne te dwaan. Mar ik wol jo direkt warskôgje dat dizze funksje frij ienfâldich is om te ymplementearjen. Dat is, yn teory, jo moatte gewoan it ferzjenûmer yn 'e tabel skriuwe en trochgean te skriuwen: de ferzje is minder as sa en sa. En dit betsjut dat, nei alle gedachten, wy sille biede it oan entûsjasters. Binne jo in entûsjast?
Ja, mar spitigernôch net yn C ++.
Kinne jo kollega's skriuwe yn C++?
Ik sil wol ien fine.
Grut*.
* de funksje waard tafoege twa moanne nei it rapport - it waard ûntwikkele troch de skriuwer fan 'e fraach en yntsjinne troch syn .
Tankewol!
Hallo! Tank foar it ferslach! Jo neamden dat ClickHouse alle beskikbere boarnen heul goed konsumearret. En de sprekker neist Luxoft spruts oer syn beslút foar de Russyske Post. Hy sei dat se ClickHouse echt leuk hienen, mar se brûkten it net ynstee fan har haadkonkurrint, krekt om't it de heule prosessor iet. En se koene it net passe yn har arsjitektuer, yn har ZooKeeper mei dockers. Is it mooglik ClickHouse op ien of oare manier te beheinen sadat it net alles konsumearret dat der foar beskikber wurdt?
Ja, it is mooglik en hiel maklik. As jo minder kearnen wolle konsumearje, skriuw dan gewoan set max_threads = 1. En dat is alles, it sil it fersyk yn ien kearn útfiere. Boppedat kinne jo ferskate ynstellings opjaan foar ferskate brûkers. Gjin probleem dus. En fertel jo kollega's fan Luxoft dat it net goed is dat se dizze ynstelling net fûn hawwe yn 'e dokumintaasje.
Alexey, hallo! Ik wol dizze fraach stelle. Dit is net de earste kear dat ik hear dat in protte minsken ClickHouse begjinne te brûken as repository foar logs. By it rapport seine jo dit net te dwaan, dat is, jo hoege gjin lange rigen op te slaan. Wat tinkst der fan?
Earst binne logs meastentiids gjin lange rigels. D'r binne fansels útsûnderingen. Bygelyks, guon tsjinst skreaun yn java smyt in útsûndering, it wurdt oanmeld. En sa yn in einleaze lus, en rint út hurde skiif romte. De oplossing is hiel ienfâldich. As de linen tige lang binne, snij se dan. Wat betsjut lang? Tsientallen kilobytes is min *.
* yn resinte ferzjes fan ClickHouse is "adaptive index granularity" ynskeakele, wat it probleem fan it opslaan fan lange snaren foar it grutste part ferwideret.
Is in kilobyte normaal?
It is normaal.
Hallo! Tank foar it ferslach! Ik haw hjir al nei frege yn it petear, mar ik wit net oft ik in antwurd krige. Is d'r in plan om de WITH-seksje op in CTE-manier út te wreidzjen?
Noch net. De seksje WITH is wat frivolous. It is as in lytse funksje foar ús.
Ik begryp it. Dankewol!
Tank foar it ferslach! Tige nijsgjirrich! globale fraach. Is it pland om, miskien yn 'e foarm fan in soarte fan stubs, wiziging fan it wiskjen fan gegevens te dwaan?
Needsaaklik. Dit is ús earste taak yn ús wachtrige. Wy tinke no aktyf oer hoe't wy alles goed dwaan kinne. En jo moatte begjinne te drukken op it toetseboerd *.
* drukte op de knoppen op it toetseboerd en alles wie dien.
Sil it op ien of oare manier ynfloed op systeemprestaasjes of net? Sil de ynfoegje sa fluch wêze as no?
Miskien de wiskjes sels, de fernijings sels sille heul swier wêze, mar dit sil op gjin inkelde manier ynfloed hawwe op de prestaasjes fan selekten en de prestaasjes fan ynserts.
En noch ien lytse fraach. By de presintaasje hawwe jo it oer de primêre kaai. Dêrnjonken hawwe wy partitioning, dy't standert moanliks is, toch? En as wy in datumberik ynstelle dy't past yn in moanne, dan lêze wy allinich dizze partysje, krekt?
Ja.
In fraach. As wy gjin primêre kaai kinne selektearje, is it dan rjocht om it krekt te dwaan troch it fjild "Datum" sadat op 'e eftergrûn in lytsere werstrukturearring fan dizze gegevens is, sadat se op in mear oarderlike manier passe? As jo gjin berikfragen hawwe en jo kinne sels gjin primêre kaai selektearje, is it dan de muoite wurdich om in datum yn 'e primêre kaai te setten?
Ja.
Miskien hat it sin om yn 'e primêre kaai in fjild te pleatsen wêrmei't de gegevens better komprimearre wurde as se op dit fjild sorteare. Bygelyks, brûkers-ID. Brûker, bygelyks, giet nei deselde side. Yn dit gefal, set de brûker id en tiid. En dan wurde jo gegevens better komprimearre. Wat de datum oangiet, as jo wirklik gjin berikfragen hawwe en nea hawwe oer datums, dan kinne jo de datum net yn 'e primêre kaai sette.
OK tige tank!
Boarne: www.habr.com