ClickHouse sistema espezializatua denez, erabiltzean garrantzitsua da bere arkitekturaren ezaugarriak kontuan hartzea. Txosten honetan, Alexeyk ClickHouse erabiltzean ohiko akatsen adibideei buruz hitz egingo du, eta horrek lan eraginkorra eragin dezake. Adibide praktikoek datu-prozesatzeko eskema bat edo beste aukeratzeak errendimendua handi-ordenaren arabera alda dezakeen erakutsiko dute.
Kaixo guztioi! Nire izena Alexey da, ClickHouse egiten dut.
Lehenik eta behin, berehala atsegin zaituztet, gaur ez dizut esango ClickHouse zer den. Egia esateko, nekatuta nago. Zer den esaten dizudan bakoitzean. Eta ziurrenik denek badakite jada.
Horren ordez, esango dizut zeintzuk diren akats posibleak, hau da, nola erabil dezakezun ClickHouse gaizki. Izan ere, ez da beldurrik izan behar, ClickHouse sistema sinplea, erosoa eta kaxatik kanpo funtzionatzen duen sistema gisa garatzen ari garelako. Instalatu dut, arazorik gabe.
Baina oraindik kontuan hartu behar duzu sistema hau espezializatua dela eta erraz topa dezakezula sistema hau bere erosotasunetik aterako duen ezohiko erabilera kasu batekin.
Orduan, zer motatako arrastoa dago? Gehienetan ageriko gauzei buruz hitz egingo dut. Dena begi-bistakoa da guztiontzat, denek dena ulertzen dute eta pozik egon daitezke hain adimentsuak direlako, eta ulertzen ez dutenek zerbait berria ikasiko dute.
Lehen eta errazena, zoritxarrez, maiz gertatzen dena, sorta txikiekin txertatze kopuru handia da, hau da, txertaketa txiki kopuru handia.
ClickHouse-k txertaketa nola egiten duen kontuan hartzen badugu, gutxienez datu terabyte bat bidal ditzakezu eskaera batean. Ez da arazo bat.
Eta ikus dezagun zein izango den emanaldi tipikoa. Adibidez, Yandex.Metrica datuen taula bat dugu. Hits. 105 zutabe batzuk. 700 byte konprimitu gabe. Eta modu onean txertatuko dugu milioi bat errenkadako loteetan.
MergeTree taulan txertatzen dugu, segundoko milioi erdi errenkada ateratzen ditu. Bikaina. Erreplikatutako taula batean pixka bat txikiagoa izango da, gutxi gorabehera 400 errenkada segundoko.
Eta quoruma txertatzea gaitzen baduzu, pixka bat gutxiago lortuko duzu, baina errendimendu duina, 250 termino segundoko. Quoruma txertatzea dokumenturik gabeko eginbide bat da ClickHouse*-n.
* 2020tik aurrera, .
Zer gertatzen da zerbait txarra egiten baduzu? MergeTree taulan errenkada bat txertatzen dugu eta segundoko 59 errenkada lortzen ditugu. Hori 10 aldiz motelagoa da. ReplicatedMergeTree-n - 000 errenkada segundoko. Eta quoruma aktibatuta badago, segundoko 6 lerro ateratzen dira. Nire ustez, hau erabateko zorakeria da. Nola moteldu dezakezu horrela? Nire kamisetan idatzita daukat ClickHouse-k ez duela moteldu behar. Baina, hala ere, batzuetan gertatzen da.
Izan ere, hau da gure gabezia. Erraz egin genezake dena ondo funtzionatzea, baina ez genuen egin. Eta ez genuen egin gure gidoiak ez zuelako eskatzen. Dagoeneko harakinak genituen. Gure sarreran loteak jaso berri ditugu, eta arazorik ez. Txertatzen dugu eta dena ondo dabil. Baina, noski, era guztietako eszenatokiak posible dira. Adibidez, datuak sortzen diren zerbitzari mordo bat duzunean. Eta ez dituzte datuak maiz txertatzen, baina hala ere maiz sartzen dira. Eta hori nolabait saihestu behar dugu.
Ikuspuntu teknikotik, kontua da ClickHousen txertaketa bat egiten duzunean, datuak ez direla inongo memtablen amaitzen. Ez dugu MergeTree benetako log-egiturarik ere, MergeTree baizik, ez baitago ez erregistrorik ez memTablerik. Datuak berehala idazten ditugu fitxategi-sisteman, dagoeneko zutabeetan antolatuta. Eta 100 zutabe badituzu, 200 fitxategi baino gehiago idatzi beharko dira beste direktorio batean. Hau guztia oso astuna da.
Eta galdera sortzen da: "Nola egin behar den ondo?" Egoera halakoa bada, oraindik nolabait ClickHouse-n datuak erregistratu behar dituzula.
Metodoa 1. Hau da biderik errazena. Erabili nolabaiteko banatutako ilara bat. Adibidez, Kafka. Kafka-tik datuak atera eta segundoan behin lotzen dituzu. Eta dena ondo egongo da, grabatzen duzu, dena ondo dabil.
Desabantailak Kafka banatutako beste sistema handi bat dela dira. Ulertzen dut dagoeneko Kafka zure enpresan baduzu. Ona da, erosoa da. Baina existitzen ez bada, hiru aldiz pentsatu beharko zenuke beste sistema banatu bat zure proiektura arrastatu aurretik. Eta, beraz, merezi du alternatibak aztertzea.
2. metodoa. Eskola zaharreko alternatiba da eta aldi berean oso sinplea. Ba al duzu zure erregistroak sortzen dituen zerbitzari motaren bat. Eta zure erregistroak fitxategi batean idazten ditu. Eta segundoan behin, adibidez, fitxategi honi izena aldatu eta berri bat kentzen diogu. Eta aparteko script batek, cron edo deabruren baten bidez, fitxategi zaharrena hartzen du eta ClickHouse-n idazten du. Erregistroak segundoan behin grabatzen badituzu, dena ondo egongo da.
Baina metodo honen desabantaila da erregistroak sortzen diren zure zerbitzaria nonbait desagertzen bada, datuak ere desagertuko direla.
3. metodoa. Bada beste metodo interesgarri bat, aldi baterako fitxategirik behar ez duena. Adibidez, publizitate-spinner moduko bat edo datuak sortzen dituen beste deabru interesgarriren bat duzu. Eta datu mordoa pila ditzakezu zuzenean RAM-en, buffer-ean. Eta denbora nahikoa igaro denean, buffer hau alde batera utzi, berri bat sortu eta aparteko hari batean, dagoeneko pilatutakoa ClickHousen sartu.
Bestalde, datuak ere desagertzen dira kill -9rekin. Zure zerbitzariak huts egiten badu, datu hauek galduko dituzu. Eta beste arazo bat da datu-basean idatzi ezin bazenuen, zure datuak RAM memorian pilatuko direla. Eta RAMa agortuko da edo datuak galduko dituzu.
4. metodoa. Beste metodo interesgarri bat. Zerbitzari-prozesuren bat al duzu. Eta berehala bidal ditzake datuak ClickHousera, baina egin ezazu konexio batean. Adibidez, http eskaera bidali nuen transferentzia-kodifikazioarekin: txertatuarekin zatituta. Eta zatiak sortzen ditu ez oso gutxitan, lerro bakoitza bidal dezakezu, nahiz eta datu hauek enkoadratzeko gainkostua egongo den.
Hala ere, kasu honetan datuak ClickHousera bidaliko dira berehala. Eta ClickHousek berak gordeko ditu.
Baina arazoak ere sortzen dira. Orain datuak galduko dituzu, zure prozesua hiltzen denean eta ClickHouse prozesua hiltzen bada barne, txertatze osatugabea izango delako. Eta ClickHousen txertaketak atomikoak dira errenkaden tamainan zehaztutako atalase jakin batera arte. Printzipioz, hau modu interesgarria da. Erabili ere egin daiteke.
5. metodoa. Hona hemen beste metodo interesgarri bat. Hau komunitateak garatutako zerbitzari moduko bat da datuen multzoka egiteko. Nik neuk ez dut begiratu, beraz, ezin dut ezer ziurtatu. Hala ere, ez da inolako bermerik ematen ClickHouserentzat. Hau ere kode irekia da, baina, bestetik, baliteke eskaintzen saiatzen garen kalitate estandar batzuetara ohituta egotea. Baina gauza honetarako - ez dakit, joan GitHub-era, begiratu kodea. Agian zerbait normal idatzi zuten.
* 2020tik aurrera ere kontuan hartu behar da .
6. metodoa. Beste metodo bat Buffer taulak erabiltzea da. Metodo honen abantaila da erabiltzen hastea oso erraza dela. Sortu Buffer taula eta txertatu bertan.
Desabantaila arazoa guztiz konpontzen ez dela da. MergeTree bezalako tasa batean, datuak segundoko lote baten arabera taldekatu behar badituzu, orduan buffer-taula bateko tasa batean, gutxienez hainbat mila segundoko taldekatu behar dituzu. Segundoko 10 baino gehiago bada, oraindik txarra izango da. Eta loteka txertatzen baduzu, orduan ikusi zenuen segundoko ehun mila lerro izaten direla. Eta hori dagoeneko datu nahiko astunetan dago.
Eta buffer-taulek ez dute erregistrorik. Eta zerbitzarian zerbait gaizki badago, datuak galduko dira.
Eta gehigarri gisa, duela gutxi ClickHousen Kafkaren datuak berreskuratzeko aukera izan dugu. Mahai-motor bat dago - Kafka. Sortu besterik ez duzu. Eta materializatutako irudikapenak zintzilikatu ditzakezu bertan. Kasu honetan, berak aterako ditu Kafka-tik datuak eta behar dituzun tauletan sartuko ditu.
Eta aukera honetan bereziki atsegina dena da ez garela guk egin. Hau komunitatearen ezaugarri bat da. Eta "komunitatearen ezaugarria" esaten dudanean, inolako mespretxurik gabe esan nahi dut. Kodea irakurri dugu, berrikuspena egin dugu, ondo funtzionatu beharko luke.
* 2020tik aurrera, antzeko laguntza agertu da .
Zer gehiago izan liteke deserosoa edo ezustekoa datuak sartzerakoan? Balioak txertatzeko eskaera bat egiten baduzu eta balioetan kalkulatutako adierazpen batzuk idazten badituzu. Adibidez, now() adierazpen kalkulatua ere bada. Eta kasu honetan, ClickHouse lerro bakoitzean adierazpen horien interpretea abiarazteko behartuta dago, eta errendimendua magnitude-ordenaren arabera jaitsiko da. Hobe da hori saihestea.
* Momentuz, arazoa guztiz konponduta dago, jada ez dago errendimenduaren erregresiorik BALIOetako adierazpenak erabiltzean.
Beste adibide bat partizio mordo bati dagokion sorta bateko datuak dituzunean arazo batzuk egon daitezkeenean da. Lehenespenez, ClickHouse partizioak hilabeteka dira. Eta milioi bat errenkadako lote bat txertatzen baduzu eta hainbat urtetako datuak badaude, hainbat dozena partizio izango dituzu bertan. Eta horren baliokidea da loteak hainbat hamarnaka aldiz txikiagoak izango direla, barruan beti partiziotan banatzen direlako.
* Duela gutxi, modu esperimentalean, ClickHouse-k RAM-eko zati eta zatien formatu trinkorako laguntza gehitu zuen idazketa-aurrerako erregistroarekin, eta horrek arazoa ia erabat konpontzen du.
Orain ikus dezagun bigarren arazo mota - datuak idaztea.
Datuen idazketa zorrotza edo katea izan daiteke. Katea hartu eta zure eremu guztiak kate motakoak direla deklaratu duzunean da. Hau txarto. Ez dago hau egin beharrik.
Azter dezagun nola egin behar den modu egokian eremuren bat, kate bat dugula esan nahi duzun kasu horietan, eta utzi ClickHouse-k bere kabuz asmatzen, eta ez naiz trabatuko. Baina hala ere merezi du ahaleginak egitea.
Adibidez, IP helbide bat dugu. Kasu batean, kate gisa gorde genuen. Adibidez, 192.168.1.1. Eta beste kasu batean, UInt32* motako zenbaki bat izango da. 32 bit nahikoak dira IPv4 helbide baterako.
Lehenik eta behin, bitxia bada ere, datuak gutxi gorabehera berdin konprimituko dira. Aldea egongo da, noski, baina ez horren handia. Beraz, ez dago arazo berezirik diskoko I/O-rekin.
Baina prozesadorearen eta kontsultaren exekuzio denboran alde handia dago.
Konta ditzagun IP helbide esklusiboen kopurua, zenbaki gisa gordetzen badira. Horrek 137 milioi lerro segundoko balio du. Gauza bera kate moduan bada, 37 milioi lerro segundoko. Ez dakit zergatik gertatu den kasualitate hau. Eskaera hauek neuk egin nituen. Baina oraindik 4 aldiz motelagoa.
Eta diskoko espazioaren aldea kalkulatzen baduzu, aldea ere badago. Eta aldea laurden batekoa da, IP helbide berezi asko daudelako. Eta esanahi ezberdin kopuru txikia duten lerroak baleude, hiztegiaren arabera erraz konprimituko lirateke gutxi gorabehera bolumen berean.
Eta ordu laukoitza ez dago errepidean. Agian ez duzu ezertxo ere ematen, noski, baina halako aldea ikusten dudanean, pena ematen dit.
Ikus ditzagun kasu desberdinak.
1. Balio esklusibo desberdin gutxi dituzunean kasu bat. Kasu honetan, ziurrenik ezagutzen duzun eta edozein DBMStarako erabil dezakezun praktika sinple bat erabiltzen dugu. Horrek guztiak zentzua du ez bakarrik ClickHouserentzat. Idatzi zenbakizko identifikatzaileak datu-basean. Eta kate bihur ditzakezu eta zure aplikazioaren alboan atzera egin dezakezu.
Adibidez, eskualde bat duzu. Eta kate gisa gordetzen saiatzen ari zara. Eta bertan idatziko da: Mosku eta Mosku eskualdea. Eta "Mosku" esaten duela ikusten dudanean, ez da ezer, baina Mosku denean, nolabait, guztiz triste bihurtzen da. Hau da zenbat byte.
Horren ordez, Ulnt32 eta 250 zenbakiak idazten ditugu. Yandex-en 250 dugu, baina zurea desberdina izan daiteke. Badaezpada, esango dut ClickHouse-k geobase batekin lan egiteko gaitasun integratua duela. Eskualdeekin direktorioa idatzi besterik ez duzu, hierarkiko bat barne, hau da, Mosku, Mosku eskualdea eta behar duzun guztia egongo dira. Eta eskaera mailan bihur dezakezu.
Bigarren aukera gutxi gorabehera berdina da, baina ClickHouse barruan laguntzarekin. Hau Enum datu mota da. Idatzi besterik ez duzu behar dituzun balio guztiak Enum barruan. Adibidez, gailu mota eta bertan idatzi: mahaigaina, mugikorra, tableta, telebista. 4 aukera daude guztira.
Desabantaila da aldian-aldian aldatu behar duzula. Aukera bakarra gehitu da. Egin dezagun taula aldatzeko. Izan ere, ClickHouse-n aldatzea doakoa da. Batez ere Enum-erako doan, diskoko datuak ez direlako aldatzen. Baina, hala ere, alter-ek blokeo bat lortzen du mahai gainean eta itxaron behar du hautapen guztiak exekutatu arte. Eta aldaketa hori egin ondoren bakarrik gauzatuko da, hau da, oraindik eragozpen batzuk daude.
* ClickHouse-ren azken bertsioetan, ALTER erabat blokeatzen da.
ClickHouserentzat nahiko berezia den beste aukera bat kanpoko hiztegiak konektatzea da. ClickHousen zenbakiak idatz ditzakezu eta zure direktorioak zuretzako komeni den edozein sistematan gorde ditzakezu. Adibidez, erabil ditzakezu: MySQL, Mongo, Postgres. Datu hauek http bidez bidaliko dituen zure mikrozerbitzu propioa ere sor dezakezu. Eta ClickHouse mailan, datu hauek zenbakietatik kate bihurtuko dituen funtzio bat idazten duzu.
Kanpoko mahai batean elkarketa bat egiteko modu espezializatua baina oso eraginkorra da. Eta bi aukera daude. Gorabide batean, datu hauek guztiz cachean gordeko dira, RAM-an guztiz egongo dira eta maiztasun batekin eguneratuko dira. Eta beste aukera batean, datu hauek RAMan sartzen ez badira, partzialki gorde ditzakezu.
Hona hemen adibide bat. Yandex.Direct dago. Eta publizitate enpresa bat eta pankartak daude. Ziurrenik dozenaka milioi publizitate-enpresa daude. Eta gutxi gorabehera RAMan sartzen dira. Eta milaka milioi pankarta daude, ez dira kabitzen. Eta MySQLren cacheko hiztegia erabiltzen dugu.
Arazo bakarra da cacheko hiztegia ondo funtzionatuko duela, arrakasta-tasa %100etik gertu badago. Txikia bada, datu sorta bakoitzeko kontsultak prozesatzen dituzunean, falta diren gakoak hartu eta MySQL-tik datuak hartzera joan beharko duzu. ClickHouseri buruz, oraindik berma dezaket hori - bai, ez da moteltzen, ez dut beste sistema batzuei buruz hitz egingo.
Eta gehigarri gisa, hiztegiak ClickHouse-n datuak atzeraeraginez eguneratzeko oso modu errazak dira. Hau da, publizitate-enpresei buruzko txosten bat zeneukan, erabiltzaileak publizitate-enpresa aldatu besterik ez zuen egin eta datu zahar guztietan, txosten guztietan, datu hauek ere aldatu egiten ziren. Errenkadak zuzenean taulan idazten badituzu, ezinezkoa izango da horiek eguneratzea.
Beste modu bat zure kateen identifikatzaileak non lortu ez dakizunean. hash besterik gabe egin dezakezu. Gainera, aukerarik errazena 64 biteko hash bat hartzea da.
Arazo bakarra da hash-a 64 bitekoa bada, ia ziur talkak izango dituzula. Izan ere, han mila milioi lerro badaude, probabilitatea dagoeneko nabaria bihurtzen da.
Eta ez litzateke oso ona izango publizitate-enpresen izenak horrela hashatzea. Enpresa ezberdinen publizitate kanpainak nahasten badira, ulertezina izango da.
Eta trikimailu sinple bat dago. Egia da, datu serioetarako ere ez da oso egokia, baina zerbait oso larria ez bada, gehitu bezeroaren identifikatzailea hiztegi-gakoan. Eta gero talkak izango dituzu, baina bezero baten barruan bakarrik. Eta metodo hau Yandex.Metrica-n esteka-mapak egiteko erabiltzen dugu. URLak hor ditugu, hashak gordetzen ditugu. Eta badakigu, noski, talkak daudela. Baina orria bistaratzen denean, erabiltzaile baten orrialde batean URL batzuk elkarrekin itsatsi eta hori nabarituko den probabilitatea alde batera utzi daiteke.
Hobari gisa, eragiketa askotan hashak bakarrik nahikoak dira eta kateak berak ez dira inon gorde behar.
Beste adibide bat kateak laburrak badira, adibidez, webguneen domeinuak. Dauden moduan gorde daitezke. Edo, adibidez, nabigatzailearen hizkuntza ru β 2 byte. Noski, asko sentitzen dut byteengatik, baina ez kezkatu, 2 byteak ez dira pena. Mesedez, mantendu dagoen bezala, ez kezkatu.
Beste kasu bat da, aitzitik, lerro asko daudenean eta horietan berezi asko daudenean, eta multzoa ere potentzialki mugagabea da. Adibide arrunta bilaketa-esaldi edo URLak dira. Bilatu esaldiak, akatsak barne. Ikus dezagun zenbat bilaketa esaldi berezi dauden egunean. Eta gertakari guztien ia erdia direla ematen du. Eta kasu honetan, pentsa liteke datuak normalizatu behar dituzula, identifikatzaileak zenbatu eta aparteko taula batean jarri. Baina ez duzu hori egin behar. Mantendu lerro hauek dauden bezala.
Hobe da ezer ez asmatzea, bereizita gordetzen baduzu, batu bat egin beharko duzulako. Eta elkartze hau, onenean, memoriarako ausazko sarbidea da, oraindik memorian sartzen bada. Egokitzen ez bada, arazoak izango dira.
Eta datuak lekuan gordetzen badira, fitxategi sistematik behar den ordenan irakurtzen da eta dena ondo dago.
URLak edo beste kate luze konplexuren bat badituzu, kontuan hartu behar da aldez aurretik ateraketa motaren bat kalkula dezakezula eta zutabe bereizi batean idatzi dezakezula.
URLetarako, adibidez, domeinua aparte gorde dezakezu. Eta benetan domeinu bat behar baduzu, erabili zutabe hau, eta URLak hor egongo dira, eta ez dituzu ukituko ere.
Ikus dezagun zein den aldea. ClickHouse-k domeinua kalkulatzen duen funtzio espezializatu bat du. Oso azkarra da, optimizatu dugu. Eta, egia esateko, ez du betetzen RFC-a ere, baina, hala ere, behar dugun guztia kontuan hartzen du.
Eta kasu batean URLak lortu eta domeinua kalkulatuko dugu. Horrek 166 milisegundo balio du. Eta prest egindako domeinu bat hartzen baduzu, orduan 67 milisegundo baino ez dira izango, hau da, ia hiru aldiz azkarragoa. Eta azkarragoa da ez kalkulu batzuk egin behar ditugulako, datu gutxiago irakurtzen ditugulako baizik.
Horregatik, eskaera batek, motelagoa dena, segundoko gigabyte-ko abiadura handiagoa du. Gigabyte gehiago irakurtzen dituelako. Hau guztiz beharrezkoa ez den datuak dira. Eskaera azkarrago exekutatzen dela dirudi, baina denbora gehiago behar da osatzeko.
Eta diskoko datu-kopuruari erreparatuz gero, URLa 126 megabytekoa dela eta domeinua 5 megabytekoa besterik ez da. 25 aldiz gutxiago ateratzen da. Baina, hala ere, eskaera 4 aldiz baino azkarrago exekutatzen da. Baina hori datuak beroak direlako. Eta hotza izango balitz, ziurrenik 25 aldiz azkarragoa izango litzateke diskoko I/O dela eta.
Bide batez, domeinu bat URL bat baino zenbat txikiagoa den kalkulatzen baduzu, 4 aldiz txikiagoa izango da, baina arrazoiren batengatik, datuek 25 aldiz gutxiago hartzen dute diskoan. Zergatik? Konpresioa dela eta. Eta URLa konprimituta dago eta domeinua konprimituta dago. Baina askotan URLak zabor mordoa dauka.
Eta, noski, merezi du nahi diren balioetarako bereziki diseinatutako datu mota egokiak erabiltzea edo egokiak direnak. IPv4-n bazaude, gorde UInt32*. IPv6 bada, orduan FixedString(16), IPv6 helbidea 128 bitekoa delako, hau da, zuzenean formatu bitarrean gordetzen da.
Baina zer gertatzen da batzuetan IPv4 helbideak eta beste batzuetan IPv6 helbideak badituzu? Bai, biak gorde ditzakezu. Zutabe bat IPv4rako, beste bat IPv6rako. Jakina, IPv4 IPv6-n bistaratzeko aukera dago. Horrek ere funtzionatuko du, baina sarritan IPv4 helbide bat behar baduzu eskaeretan, ondo legoke zutabe bereizi batean jartzea.
* ClickHouse-k orain IPv4 eta IPv6 datu mota bereiziak ditu, datuak zenbakiak bezain eraginkortasunez gordetzen dituztenak, baina kateak bezain eroso irudikatzen dituztenak.
Garrantzitsua da kontutan izan ere merezi duela datuak aldez aurretik prozesatzea. Adibidez, erregistro gordinak jasotzen dituzu. Eta agian ez dituzu berehala ClickHousen jarri behar, nahiz eta ezer ez egitea oso tentagarria den eta dena funtzionatuko duen. Baina hala ere merezi du posible diren kalkuluak egitea.
Adibidez, arakatzailearen bertsioa. Inguruko sail batzuetan, hatzaz seinalatu nahi ez dudana, arakatzailearen bertsioa honela gordetzen da, hau da, kate gisa: 12.3. Eta gero, txosten bat egiteko, kate hori hartu eta array batean zatitzen dute, eta gero arrayko lehen elementuan. Berez, dena moteltzen da. Hau zergatik egiten duten galdetu nion. Optimizazio goiztiarra ez zaiela gustatzen esan zidaten. Eta ez zait pesimismo goiztiarra gustatzen.
Beraz, kasu honetan zuzenagoa izango litzateke 4 zutabetan banatzea. Ez izan beldur hemen, hau ClickHouse delako. ClickHouse zutabe datu-base bat da. Eta zenbat eta zutabe txiki txukunagoak, orduan eta hobeto. 5 arakatzaile-bertsio egongo dira, egin 5 zutabe. Hau ondo dago.
Orain ikus dezagun zer egin kate luze asko badituzu, array oso luzeak. Ez dira inola ere ClickHousen gorde behar. Horren ordez, identifikatzaile bat bakarrik gorde dezakezu ClickHouse-n. Eta jarri lerro luze hauek beste sistema batean.
Adibidez, gure analisi zerbitzuetako batek gertaeren parametro batzuk ditu. Eta gertaeren parametro asko baldin badaude, topatzen diren lehen 512ak gorde besterik ez dugu egiten. 512 ez baita pena bat.
Eta ezin badituzu zure datu motak erabaki, ClickHousen ere erregistra ditzakezu datuak, baina Log motako aldi baterako taula batean, aldi baterako datuetarako berezia. Horren ondoren, bertan zer balio-banaketa duzun aztertu dezakezu, zer dagoen oro har, eta mota egokiak sortu.
*ClickHouse-k datu mota bat du orain horrek ahalbidetzen du kateak modu eraginkorrean gordetzeko esfortzu gutxiagorekin.
Ikus dezagun orain beste kasu interesgarri bat. Batzuetan gauzak arraro funtzionatzen dute jendearentzat. Sartu eta hau ikusten dut. Eta berehala ematen du hori MySQL 3.23 bertsioa konfiguratzen esperientzia handia duen administratzaile adimendun batek egin duela.
Hemen mila taula ikusten ditugu, eta bakoitzean nork daki zer milatan zatitzearen hondarra erregistratzen du.
Printzipioz, besteen esperientzia errespetatzen dut, esperientzia honen bidez lor daitekeen sufrimenduaren ulermena barne.
Eta arrazoiak gehiago edo gutxiago argiak dira. Beste sistema batzuekin lan egitean pilatu daitezkeen estereotipo zaharrak dira. Adibidez, MyISAM taulek ez dute gako primario multzokaturik. Eta datuak banatzeko modu hau funtzionalitate bera lortzeko saiakera etsi bat izan daiteke.
Beste arrazoi bat da zaila dela mahai handietan aldaketa eragiketak egitea. Dena blokeatuko da. MySQL-ren bertsio modernoetan arazo hau jada ez da hain larria izan.
Edo, adibidez, microsharding-a, baina gehiago geroago.
Ez dago hori egin beharrik ClickHouse-n, izan ere, lehenik eta behin, gako nagusia multzokatuta dagoelako, datuak gako nagusiaren arabera ordenatzen dira.
Eta batzuetan jendeak galdetzen dit: "Nola aldatzen da ClickHouse-n barruti-kontsulten errendimendua mahaiaren tamainaren arabera?" Nik diot ez dela batere aldatzen. Adibidez, mila milioi errenkada dituen taula bat duzu eta milioi bat errenkadako tartea irakurtzen duzu. Dena ondo dago. Taula batean bilioi bat errenkada badaude eta milioi bat errenkada irakurtzen badituzu, ia berdina izango da.
Eta, bigarrenik, eskuzko partizioak bezalako gauza guztiak ez dira beharrezkoak. Sartu eta fitxategi-sisteman zer dagoen begiratuz gero, ikusiko duzu taula nahiko handia dela. Eta barruan partizioak bezalako zerbait dago. Hau da, ClickHousek dena egiten dizu eta ez duzu sufritu beharrik.
ClickHouse-n aldatzea doakoa da zutabea gehitu/jaregin baduzu.
Eta ez zenuke mahai txikirik egin behar, zeren eta taula batean 10 errenkada edo 10 errenkada badituzu, ez du batere axola. ClickHouse errendimendua optimizatzen duen sistema da, ez latentzia, beraz, ez du zentzurik 000 lerro prozesatzea.
Zuzena da mahai handi bat erabiltzea. Kendu estereotipo zaharrak, dena ondo egongo da.
Eta gehigarri gisa, azken bertsioan orain partizio-gako arbitrario bat sortzeko gaitasuna dugu partizio indibidualetan mantentze-eragiketa guztiak egiteko.
Adibidez, taula txiki asko behar dituzu, adibidez, tarteko datu batzuk prozesatu beharra dagoenean, zatiak jasotzen dituzu eta haietan eraldaketa bat egin behar duzu azken taulan idatzi aurretik. Kasu honetarako, mahai-motor zoragarri bat dago - StripeLog. TinyLog bezalakoa da, hobeto bakarrik.
* orain ClickHouse-k ere badu .
Beste antipatroi bat microsharding da. Adibidez, datuak zatitu behar dituzu eta 5 zerbitzari dituzu, eta bihar 6 zerbitzari izango dira. Eta pentsatzen duzu nola orekatu datu horiek. Eta horren ordez, ez duzu 5 zatitan apurtzen, 1 zatitan baizik. Eta gero mikropartida horietako bakoitza zerbitzari bereizi batera mapatzen duzu. Eta, adibidez, 000 ClickHouses lortuko dituzu zerbitzari batean, adibidez. Instantziak bereizi portu edo datu-base bereizietan.
Baina hau ez da oso ona ClickHousen. ClickHouse-ren instantzia bakarra zerbitzariaren baliabide erabilgarri guztiak erabiltzen saiatzen delako eskaera bat prozesatzeko. Hau da, zerbitzari mota bat duzu eta, adibidez, 56 prozesadore nukleo ditu. Segundo bat behar duen kontsulta bat exekutatzen ari zara eta 56 nukleo erabiliko ditu. Eta han 200 ClickHouses jarri badituzu zerbitzari batean, orduan 10 hari hasiko dira. Oro har, dena oso txarra izango da.
Beste arrazoi bat da instantzia hauetan lanaren banaketa irregularra izango dela. Batzuk lehenago amaituko dute, beste batzuk beranduago. Hori guztia kasu batean gertatuko balitz, ClickHousek berak asmatuko luke harien artean datuak behar bezala nola banatu.
Eta beste arrazoi bat da prozesadoreen arteko komunikazioa izango duzula TCP bidez. Datuak serializatu, deserializatu beharko dira, eta hau microshard kopuru handia da. Besterik gabe, ez da eraginkortasunez funtzionatuko.
Beste antipatroi bat, nahiz eta nekez dei daitekeen antipatroi bat. Hau aurre-agregazio kopuru handia da.
Oro har, aurre-agregazioa ona da. Mila milioi errenkada zenituen, agregatu eta 1 errenkada bihurtu zen, eta orain kontsulta berehala exekutatzen da. Dena bikaina da. Hau egin dezakezu. Eta horretarako, ClickHousek ere taula mota berezi bat du, AggregatingMergeTree, datuak txertatzen diren heinean gehikuntza gehikuntza egiten duena.
Baina batzuetan horrelako datuak bilduko ditugula eta horrelako datuak batu egingo ditugula uste duzu. Eta aldameneko sail batzuetan ere ez dut esan nahi zein den, SummingMergeTree taulak erabiltzen dituzte gako nagusiaren arabera laburtzeko, eta 20 zutabe inguru erabiltzen dira gako nagusi gisa. Badaezpada, zutabe batzuen izenak aldatu nituen sekretuagatik, baina nahikoa da.
Eta halako arazoak sortzen dira. Lehenik eta behin, zure datu-bolumena ez da gehiegi jaisten. Esaterako, hiru aldiz gutxitzen da. Hiru aldiz prezio ona izango litzateke zure datuak batzen ez badira sortzen diren analisi gaitasun mugagabeak ordaintzeko. Datuak batuta badaude, analitiken ordez estatistika penagarriak baino ez dituzu lortzen.
Eta zer du berezi horrek? Kontua da aldameneko saileko pertsona horiek batzuetan gako nagusiari beste zutabe bat gehitzeko eskatzen dutela. Hau da, datuak honela batu ditugu, baina orain pixka bat gehiago nahi dugu. Baina ClickHouse-k ez du aldatzeko gako nagusirik. Horregatik, C++-n script batzuk idatzi behar ditugu. Eta gidoiak ez zaizkit gustatzen, nahiz eta C++-n egon.
Eta ClickHouse zertarako sortu den aztertzen baduzu, datu ez-agregatuak dira zehazki jaio zen eszenatokia. ClickHouse batu gabeko datuetarako erabiltzen ari bazara, ondo egiten ari zara. Agregatzen baduzu, hori batzuetan barkagarria da.
Beste kasu interesgarri bat begizta infinitu batean egindako kontsultak dira. Batzuetan, produkzio-zerbitzari batera joaten naiz eta han erakutsi prozesu-zerrenda ikusten dut. Eta zerbait izugarria gertatzen ari dela deskubritzen dudan bakoitzean.
Adibidez, honela. Berehala argi dago eskaera bakarrean dena egin zitekeela. Idatzi url-a eta zerrenda bertan.
Zergatik dira txarrak horrelako kontsulta asko begizta amaigabean? Indize bat erabiltzen ez bada, datu berdinen gainetik pasabide asko izango dituzu. Baina indizea erabiltzen bada, adibidez, ru-rako lehen gako bat duzu eta url = zerbait idazten duzu hor. Eta taulatik URL bakarra irakurtzen bada, dena ondo egongo dela uste duzu. Baina egia esan ez. ClickHouse-k dena loteka egiten duelako.
Datu sorta jakin bat irakurri behar duenean, pixka bat gehiago irakurtzen du, ClickHouse-n indizea urria delako. Indize honek ez dizu taulan errenkada indibidual bat aurkitzeko aukera ematen, nolabaiteko barruti bat baizik. Eta datuak blokeetan konprimitzen dira. Lerro bat irakurtzeko, bloke osoa hartu eta askatu behar duzu. Eta kontsulta mordoa egiten ari bazara, gainjarri asko izango dituzu, eta lan asko izango duzu behin eta berriro egiteko.
Eta bonus gisa, kontutan izan dezakezu ClickHouse-n ez duzula beldurrik izan behar megabyte eta ehunka mega ere IN atalera transferitzeko. Gure praktikatik gogoratzen dut MySQL-en balio mordoa IN atalera transferitzen baditugu, adibidez, zenbaki batzuen 100 megabyte transferitzen ditugula han, orduan MySQL-ek 10 gigabyte memoria jaten ditu eta ez zaio ezer gertatzen, dena. gaizki funtzionatzen du.
Eta bigarrena da ClickHousen, zure kontsultak indize bat erabiltzen badute, ez da beti eskaneatu osoa baino motelagoa, hau da, ia taula osoa irakurri behar baduzu, sekuentzialki joango da eta taula osoa irakurriko du. Oro har, bere kabuz asmatuko du.
Baina, hala ere, zailtasun batzuk daude. Adibidez, IN azpikontsulta batekin ez duela indizea erabiltzen. Baina hau da gure arazoa eta konpondu behar dugu. Hemen ez dago oinarrizko ezer. konponduko dugu*.
Eta beste gauza interesgarri bat da eskaera oso luzea baduzu eta eskaera banatua prozesatzen ari bada, eskaera oso luze hau zerbitzari bakoitzari konpresiorik gabe bidaliko da. Adibidez, 100 megabyte eta 500 zerbitzari. Eta, horren arabera, 50 gigabyte transferituko dituzu sarean. Transmitituko da eta, ondoren, dena arrakastaz osatuko da.
* dagoeneko erabiltzen; Dena konpondu zen agindu bezala.
Eta nahiko ohikoa den kasua da eskaerak APItik datozenean. Adibidez, zure zerbitzu propioa sortu duzu. Eta norbaitek zure zerbitzua behar badu, orduan APIa irekitzen duzu eta literalki bi egun geroago ikusiko duzu zerbait ulertezina gertatzen ari dela. Dena gainkargatuta dago eta inoiz gertatu behar ez ziren eskaera izugarri batzuk datoz.
Eta irtenbide bakarra dago. APIa ireki baduzu, moztu beharko duzu. Adibidez, kuota mota batzuk sartu. Ez dago beste aukera normalik. Bestela, berehala idatziko dute gidoia eta arazoak egongo dira.
Eta ClickHousek ezaugarri berezi bat du: kuota kalkulatzea. Gainera, zure kuota gakoa transferitu dezakezu. Hau da, adibidez, barneko erabiltzailearen IDa. Eta kuotak independenteki kalkulatuko dira horietako bakoitzarentzat.
Orain beste gauza interesgarri bat. Hau eskuzko erreplikazioa da.
Badakit kasu asko non, ClickHouse-k erreplika-laguntza integratua izan arren, jendeak ClickHouse eskuz errepikatzen duen.
Zein da printzipioa? Datuak prozesatzeko kanalizazio bat duzu. Eta modu independentean lan egiten du, adibidez, datu-zentro ezberdinetan. Datu berdinak era berean idazten dituzu ClickHouse-n. Egia da, praktikak erakusten du datuak oraindik desbideratuko direla zure kodearen ezaugarri batzuengatik. Espero dut zurean egotea.
Eta noizean behin oraindik eskuz sinkronizatu beharko duzu. Adibidez, hilean behin administratzaileek rsync egiten dute.
Izan ere, askoz errazagoa da ClickHousen eraikitako erreplikazioa erabiltzea. Baina kontraindikazio batzuk egon daitezke, horretarako ZooKeeper erabili behar duzulako. ZooKeeper-i buruz ez dut ezer txarrik esango, printzipioz, sistemak funtzionatzen du, baina gertatzen da jendeak ez duela erabiltzen java-fobia dela eta, ClickHouse sistema ona baita, C++-n idatzia, erabil dezakezuna eta dena ondo egongo da. Eta ZooKeeper java-n dago. Eta, nolabait, ez duzu begiratu ere egin nahi, baina gero eskuzko erreplikazioa erabil dezakezu.
ClickHouse sistema praktikoa da. Zure beharrak kontuan hartzen ditu. Eskuzko erreplikak badituzu, orduan zure eskuzko erreplikak aztertu eta haien artean hutsegitea egiten duen taula banatu bat sor dezakezu. Eta bada aukera berezi bat ere, flop-ak saihesteko aukera ematen dizuna, nahiz eta zure lerroak sistematikoki aldendu.
Arazo gehiago sor daitezke taula-motor primitiboak erabiltzen badituzu. ClickHouse taula-motor ezberdin ugari dituen eraikitzailea da. Kasu larri guztietan, dokumentazioan idatzita dagoen moduan, erabili MergeTree familiako taulak. Eta gainerako guztiak - hala da, kasu indibidualetarako edo probetarako.
MergeTree taula batean, ez duzu data eta ordurik izan behar. Oraindik erabil dezakezu. Data eta ordurik ez badago, idatzi lehenetsia 2000 dela. Horrek funtzionatuko du eta ez du baliabiderik beharko.
Eta zerbitzariaren bertsio berrian, partizio-gakorik gabe partizio pertsonalizatua duzula ere zehaztu dezakezu. Berdin izango da.
Bestalde, taula-motor primitiboak erabil ditzakezu. Adibidez, bete datuak behin eta begiratu, bihurritu eta ezabatu. Log erabil dezakezu.
Edo tarteko prozesatzeko bolumen txikiak gordetzea StripeLog edo TinyLog da.
Memoria erabil daiteke datu kopurua txikia bada eta RAMan zerbait biraka dezakezu.
ClickHouse-k ez ditu oso gustuko birnormalizatutako datuak.
Hona hemen adibide tipiko bat. Hau URL kopuru handia da. Hurrengo taulan jarri dituzu. Eta orduan haiekin JOIN egitea erabaki zuten, baina honek ez du funtzionatuko, normalean, ClickHouse-k Hash JOIN bakarrik onartzen duelako. Konektatu behar diren datu askotarako RAM nahikorik ez badago, JOIN-ek ez du funtzionatuko*.
Datuak kardinaltasun handikoak badira, orduan ez kezkatu, gorde forma desnormalizatu batean, URLak zuzenean daude taula nagusian.
* eta orain ClickHouse-k bateratze-juntura ere badu, eta tarteko datuak RAMan sartzen ez diren baldintzetan funtzionatzen du. Baina hau ez da eraginkorra eta gomendioak indarrean jarraitzen du.
Adibide pare bat gehiago, baina jada zalantzan jartzen dut ereduaren aurkakoak diren edo ez.
ClickHousek akats ezagun bat du. Ez daki nola eguneratu*. Zenbait modutan, hau ere ona da. Datu garrantzitsu batzuk badituzu, adibidez, kontabilitatea, orduan inork ezingo du bidali, ez dagoelako eguneratzerik.
* Batch moduan eguneratzeko eta ezabatzeko laguntza duela aspaldi gehitu zen.
Baina atzeko planoan bezala eguneratzeak ahalbidetzen dituzten modu berezi batzuk daude. Adibidez, ReplaceMergeTree bezalako taulak. Atzeko planoan bateratzean eguneraketak egiten dituzte. Hau behartu dezakezu optimizatu taula erabiliz. Baina ez egin hori askotan, partizioa guztiz gainidatziko baitu.
ClickHouse-ko JOIN banatuak ere gaizki kudeatzen ditu kontsulta-planifikatzaileak.
Txarra, baina batzuetan ondo.
ClickHouse erabiltzea soilik datuak irakurtzeko select* erabiliz.
Ez nuke gomendatuko ClickHouse erabiltzea kalkulu astunak egiteko. Baina hori ez da guztiz egia, dagoeneko gomendio honetatik urruntzen ari garelako. Eta duela gutxi ClickHouse - Catboost-en ikasketa automatikoko ereduak aplikatzeko gaitasuna gehitu dugu. Eta gogaitzen nau, pentsatzen dudalako: βZe izua. Hau da zenbat ziklo ateratzen diren byte bakoitzeko! Asko gorroto dut erlojuak byteetan galtzea.
Baina ez izan beldurrik, instalatu ClickHouse, dena ondo egongo da. Bada, komunitate bat dugu. Bide batez, komunitatea zu zara. Eta arazorik izanez gero, gutxienez gure txatera joan zaitezke, eta espero dugu lagunduko dizute.
Zure galderak
Eskerrik asko erreportajeagatik! Non kexatu naiteke ClickHouse hutsegiteaz?
Niri pertsonalki kexa nazakezu oraintxe bertan.
Duela gutxi ClickHouse erabiltzen hasi nintzen. Berehala jaitsi nuen cli interfazea.
A ze puntuazioa.
Pixka bat geroago zerbitzaria huts egin nuen hautaketa txiki batekin.
Talentua duzu.
GitHub akats bat ireki nuen, baina ez zen aintzat hartu.
Ikusiko dugu.
Alexeyk engainatu ninduen txostenera joateko, barruko datuak nola sartzen dituzun esango zidala aginduz.
Oso erraza da.
Atzo konturatu nintzen horretaz. Zehaztasun gehiago.
Han ez dago trikimailu ikaragarririk. Blokez bloke konpresioa besterik ez dago. Lehenetsia LZ4 da, ZSTD* gaitu dezakezu. 64 kilobytetik 1 megabyte arteko blokeak.
* beste algoritmo batzuekin kate batean erabil daitezkeen konpresio kodek espezializatuetarako laguntza ere badago.
Blokeak datu gordinak besterik ez al dira?
Ez guztiz gordina. Array daude. Zenbakizko zutabe bat baduzu, errenkadan dauden zenbakiak matrize batean jartzen dira.
Garbi dago.
Alexey, uniqExact IP-ekin zegoen adibidea, hau da, uniqExact-ek lerroen bidez kalkulatzeko zenbakien bidez baino denbora gehiago behar duela, eta abar. Zer gertatzen da gure belarriekin finta bat erabiltzen badugu eta zuzenketa garaian bota? Hau da, badirudi esan duzula gure diskoan ez dela oso ezberdina. Diskotik eta castetatik lerroak irakurtzen baditugu, gure agregatuak azkarragoak izango dira ala ez? Edo oraindik apur bat irabaziko dugu hemen? Iruditzen zait hori probatu duzula, baina arrazoiren batengatik ez duzu erreferentzian adierazi.
Casting gabe baino motelagoa izango dela uste dut. Kasu honetan, IP helbidea katetik analizatu behar da. Noski, ClickHousen, gure IP helbidearen analisia ere optimizatuta dago. Oso gogor saiatu gara, baina hor dituzu hamar milagarren moduan idatzitako zenbakiak. Oso deseroso. Bestalde, uniqExact funtzioak motelago funtzionatuko du kateetan, ez bakarrik kateak direlako, baita algoritmoaren beste espezializazio bat hautatzen delako ere. Kateak modu ezberdinean prozesatzen dira.
Zer gertatzen da datu mota primitiboagoa hartzen badugu? Adibidez, erabiltzailearen id-a idatzi dugu, zeina sartu dugun, lerro gisa idatzi dugu, eta gero nahastu dugu, dibertigarriagoa izango da ala ez?
Zalantza dut. Are tristeagoa izango dela uste dut, azken finean, zenbakiak analizatzea arazo larria baita. Iruditzen zait lankide honek hamar milagarren forman zenbakiak aztertzea zein zaila den txosten bat ere eman zuela, baina agian ez.
Alexey, mila esker txostenagatik! Eta eskerrik asko ClickHousegatik! Planei buruzko galdera bat daukat. Hiztegiak guztiz eguneratzeko eginbiderik ba al dago planik?
Hau da, berrabiarazi partziala?
Bai bai. MySQL eremu bat bertan ezartzeko gaitasuna bezala, hau da, eguneratu ondoren, datu hauek soilik kargatzeko hiztegia oso handia bada.
Oso ezaugarri interesgarria. Eta uste dut norbaitek iradoki duela gure txatean. Agian zu ere izan zinen.
Ez dut uste.
Bikaina, orain bi eskaera daudela ematen du. Eta poliki-poliki hasi zaitezke egiten. Baina berehala ohartarazi nahi dizut funtzio hau ezartzeko nahiko erraza dela. Hau da, teorian, taulan bertsio-zenbakia idatzi eta gero idatzi besterik ez duzu egin behar: halako eta halako baino bertsio gutxiago. Horrek esan nahi du, ziurrenik, hau zaletuei eskainiko diegula. Zale al zara?
Bai, baina, zoritxarrez, ez C++-n.
Zure lankideek badakite C++-n idazten?
Norbait aurkituko dut.
Bikaina*.
* funtzioa txostena egin eta bi hilabetera gehitu zen - galderaren egileak garatu zuen eta berea bidali zuen .
Eskerrik asko!
Kaixo! Eskerrik asko erreportajeagatik! ClickHouse oso ona dela aipatu duzu eskura dituen baliabide guztiak kontsumitzen. Eta Luxoft-en ondoan dagoen hizlaria Russian Post-erako duen irtenbideaz hitz egin zuen. ClickHouse asko gustatzen zitzaiela esan zuen, baina ez zuten erabili lehiakide nagusiaren ordez, hain zuzen, CPU guztia jaten ari zelako. Eta ezin zuten konektatu beren arkitekturara, beren ZooKeeper-era atrakatzaileekin. Posible al da ClickHouse nolabait mugatzea eskuragarri dagoen guztia kontsumi ez dezan?
Bai, posible da eta oso erraza da. Nukleo gutxiago kontsumitu nahi baduzu, idatzi besterik ez set max_threads = 1. Eta kitto, eskaera nukleo batean exekutatu egingo du. Gainera, hainbat ezarpen zehaztu ditzakezu erabiltzaile ezberdinentzat. Beraz, arazorik ez. Eta esan Luxoft-eko zure lankideei ez dela ona dokumentazioan ezarpen hau ez aurkitzea.
Alexey, kaixo! Galdera honi buruz galdetu nahiko nuke. Hau ez da jende asko ClickHouse erregistroetarako biltegiratze gisa erabiltzen hasten dela entzuten dudan lehen aldia. Txostenean hau ez egiteko esan zenuen, hau da, ez duzu kate luzerik gorde behar. Zer iruditzen zaizu horretaz?
Lehenik eta behin, erregistroak, oro har, ez dira kate luzeak. Badaude, noski, salbuespenak. Adibidez, java-n idatzitako zerbitzu batzuek salbuespen bat botatzen dute, erregistratuta dago. Eta horrela amaigabeko begizta batean, eta disko gogorrean tokia agortzen da. Irtenbidea oso erraza da. Lerroak oso luzeak badira, moztu. Zer esan nahi du luzeak? Hamarnaka kilobyte txarrak dira*.
* ClickHouse-ren azken bertsioetan, "indize egokitzeko granulartasuna" gaituta dago, eta horrek errenkada luzeak gordetzeko arazoa ezabatzen du gehienetan.
Kilobyte bat normala al da?
Normala da.
Kaixo! Eskerrik asko erreportajeagatik! Txatean dagoeneko galdetu nuen honi buruz, baina ez naiz gogoratzen erantzunik jaso ote nuen. Ba al dago CTEren moduan EKIN atala nola edo hala zabaltzeko asmorik?
Oraindik ez. Gure WITH atala fribolo samarra da. Ezaugarri txiki bat bezala da guretzat.
Ulertzen dut. Eskerrik asko!
Eskerrik asko erreportajeagatik! Oso interesgarria! Galdera globala. Ba al dago datuen ezabaketa aldatzeko planik, agian zirriborroren baten moduan?
Derrigorrez. Hau da gure lehen zeregina gure ilaran. Orain dena behar bezala nola egin pentsatzen ari gara aktiboki. Eta teklatua* sakatzen hasi beharko zenuke.
* teklatuko botoiak sakatu eta dena egin zuen.
Horrek nolabait eragingo al dio sistemaren errendimenduari edo ez? Sartzea orain bezain azkarra izango al da?
Agian ezabatzeak eta eguneratzeak beraiek oso astunak izango dira, baina horrek ez du eraginik izango hautaketen errendimenduan edo txertaketen errendimenduan.
Eta galdera txiki bat gehiago. Aurkezpenean lehen gakoari buruz hitz egin duzu. Horren arabera, partizioa dugu, lehenespenez hilerokoa, ezta? Eta hilabete batean sartzen den data-tartea ezartzen dugunean, partizio hau bakarrik irakurtzen da, ezta?
Bai.
Galdera bat. Ezin badugu gako nagusirik hautatu, zuzena al da "Data" eremuaren arabera berariaz egitea, atzealdean datu horien berrantolaketa gutxiago egon dadin, modu ordenatuagoan egokitzeko? Barrutiko kontsultarik ez baduzu eta ezin baduzu gako nagusirik ere hautatu, merezi al du data bat gako nagusian jartzea?
Bai.
Agian zentzuzkoa izango da gako nagusian datuak hobeto konprimituko dituen eremu bat jartzea eremu honen arabera ordenatuta badago. Adibidez, erabiltzailearen IDa. Erabiltzailea, adibidez, gune berera doa. Kasu honetan, jarri erabiltzailearen IDa eta ordua. Eta orduan zure datuak hobeto konprimituko dira. Datari dagokionez, benetan ez badituzu eta ez badituzu inoiz tarte-kontsultak datetan, orduan ez duzu data gako nagusian jarri beharrik.
Ados eskerrik asko!
Iturria: www.habr.com