Ĉar ClickHouse estas speciala sistemo, estas grave konsideri la proprecojn de ĝia arkitekturo kiam vi uzas ĝin. En ĉi tiu raporto, Alexey parolos pri ekzemploj de tipaj eraroj kiam vi uzas ClickHouse, kiuj povas konduki al neefika laboro. Uzante praktikajn ekzemplojn, ni montros kiel la elekto de unu aŭ alia datumtraktadskemo povas ŝanĝi agadon laŭ grandordoj.
Saluton al ĉiuj! Mi nomiĝas Alexey, mi faras ClickHouse.
Unue, mi rapidas plezurigi vin, mi ne diros al vi hodiaŭ, kio estas ClickHouse. Verdire, mi estas laca de tio. Mi diras al vi ĉiufoje, kio ĝi estas. Kaj verŝajne ĉiuj jam scias.
Anstataŭe, mi diros al vi, kio estas la ebla rastilo, t.e. kiel ClickHouse povas esti misuzita. Fakte, vi ne devus timi, ĉar ni evoluigas ClickHouse kiel sistemon kiu estas simpla, oportuna, kaj funkcias ekstere de la skatolo. Ĉio instalita, neniu problemo.
Sed tamen, oni devas konsideri, ke ĉi tiu sistemo estas specialigita kaj vi povas facile trafi nekutima uzkazo, kiu elprenos ĉi tiun sistemon el sia komforta zono.
Do, kio estas la rastiloj? Esence mi parolos pri la evidentaj aferoj. Ĉio estas evidenta por ĉiuj, ĉiuj komprenas ĉion kaj povas ĝoji, ke ili estas tiel inteligentaj, kaj tiuj, kiuj ne komprenas, lernos ion novan.
La unua plej simpla ekzemplo, kiu bedaŭrinde ofte okazas, estas granda nombro da enmetoj kun malgrandaj aroj, t.e. granda nombro da malgrandaj enmetoj.
Se ni konsideras kiel ClickHouse faras enmeton, tiam vi povas sendi almenaŭ terabajton da datumoj en unu peto. Ne estas problemo.
Kaj ni vidu, kia estos la tipa agado. Ekzemple, ni havas tabelon kun Yandex.Metrics-datumoj. Trafoj. 105 kelkaj kolumnoj. 700 bajtoj nekunpremitaj. Kaj ni enmetos en bona maniero arojn de unu miliono da linioj.
Ni enigas en la MergeTree-tabelon, duonmiliono da vicoj sekundo estas akiritaj. Bonege. En reproduktita tabelo - ĝi estos iom malpli, ĉirkaŭ 400 000 vicoj por sekundo.
Kaj se vi ŝaltas la kvoruman enigaĵon, vi ricevas iom malpli, sed tamen decan rendimenton, 250 000 fojojn sekundo. Kvoruma Enmeto estas nedokumentita funkcio en ClickHouse*.
* ekde 2020, .
Kio okazas se vi faras ĝin malĝuste? Ni enmetas unu vicon en la MergeTree-tabelon kaj ni ricevas 59 vicojn por sekundo. Ĉi tio estas 10 fojojn malrapida. En ReplicatedMergeTree - 000 vicoj por sekundo. Kaj se la kvorumo ŝaltiĝas, tiam 6 linioj sekundo estas akiritaj. Miaopinie, ĉi tio estas ia tuta aĉaĵo. Kiel vi povas malrapidigi tiel? Ĝi eĉ diras sur mia T-ĉemizo ke ClickHouse ne devus malrapidiĝi. Sed tamen ĝi okazas kelkfoje.
Fakte, ĉi tio estas nia manko. Ni povintus bonege funkcii, sed ni ne faris. Kaj ni ne faris, ĉar nia skripto ne bezonis ĝin. Ni jam havis arojn. Ni ĵus ricevis arojn ĉe la enirejo, kaj neniuj problemoj. Konektu ĝin kaj ĉio funkcias bone. Sed, kompreneble, ĉiaj scenaroj eblas. Ekzemple, kiam vi havas amason da serviloj sur kiuj datumoj estas generitaj. Kaj ili ne tiom ofte enmetas datumojn, sed ili tamen ricevas oftajn enmetojn. Kaj vi devas iel eviti ĉi tion.
De teknika vidpunkto, la fundo estas, ke kiam vi faras enmeton en ClickHouse, la datumoj ne eniras iun memoreblan. Ni eĉ ne havas veran MergeTree-protokolstrukturon, sed nur MergeTree, ĉar ekzistas nek protokolo nek memTable. Ni nur tuj skribas la datumojn al la dosiersistemo, jam malkomponita en kolumnojn. Kaj se vi havas 100 kolumnojn, tiam pli ol 200 dosieroj devos esti skribitaj al aparta dosierujo. Ĉio ĉi estas tre ĝena.
Kaj la demando ŝprucas: "Kiel fari ĝin ĝuste?" Se tia situacio, vi ankoraŭ bezonas iel skribi datumojn al ClickHouse.
Metodo 1. Ĉi tio estas la plej facila maniero. Uzu ian distribuitan voston. Ekzemple, Kafka. Vi nur prenas datumojn el Kafka, ni amasigas ĝin unufoje sekundon. Kaj ĉio estos bone, vi registras, ĉio funkcias bone.
La malavantaĝoj estas ke Kafka estas alia maloportuna distribuita sistemo. Mi ankaŭ komprenas, ĉu vi jam havas Kafkan en via kompanio. Ĝi estas bona, ĝi estas oportuna. Sed se ĝi ne estas tie, tiam vi devus pensi tri fojojn antaŭ treni alian distribuitan sistemon en vian projekton. Kaj do indas konsideri alternativojn.
Metodo 2. Jen tia malnovlerneja alternativo kaj samtempe tre simpla. Ĉu vi havas ian servilon, kiu generas viajn protokolojn. Kaj ĝi nur skribas viajn protokolojn al dosiero. Kaj unufoje sekundon, ekzemple, ni renomas ĉi tiun dosieron, malfermas novan. Kaj aparta skripto aŭ per cron aŭ iu demono prenas la plej malnovan dosieron kaj skribas ĝin al ClickHouse. Se vi skribas protokolojn unufoje sekundon, tiam ĉio estos en ordo.
Sed la malavantaĝo de ĉi tiu metodo estas, ke se via servilo, sur kiu la protokoloj estas generitaj, malaperis ie, tiam la datumoj ankaŭ malaperos.
Metodo 3. Estas alia interesa maniero, kiu estas tute sen provizoraj dosieroj. Ekzemple, vi havas ian reklaman ŝpinilon aŭ iun alian interesan demonon, kiu generas datumojn. Kaj vi povas amasigi amason da datumoj ĝuste en la RAM, en la bufro. Kaj kiam sufiĉa kvanto da tempo pasas, vi flankenmetas ĉi tiun bufron, kreas novan kaj enmetas tion, kio jam akumuliĝis en ClickHouse en apartan fadenon.
Aliflanke, la datumoj ankaŭ malaperas kun kill -9. Se via servilo malfunkcias, vi perdos ĉi tiujn datumojn. Kaj alia problemo estas, ke se vi ne povus skribi al la datumbazo, tiam viaj datumoj amasiĝos en la RAM. Kaj aŭ la RAM elĉerpiĝas, aŭ vi simple perdas datumojn.
Metodo 4. Alia interesa maniero. Ĉu vi havas iun servilan procezon. Kaj li povas sendi datumojn al ClickHouse tuj, sed fari ĝin en unu konekto. Ekzemple, mi sendis http-peton kun transigo-kodigo: disigita per enmeto. Kaj ĝi generas pecojn ne tro malofte, vi povas sendi ĉiun linion, kvankam estos superkompeto por enkadrigi ĉi tiujn datumojn.
Tamen, en ĉi tiu kazo, la datumoj tuj estos senditaj al ClickHouse. Kaj ClickHouse mem bufros ilin.
Sed estas ankaŭ problemoj. Nun vi perdos datumojn, inkluzive kiam via procezo estas mortigita kaj se la ClickHouse-procezo estas mortigita, ĉar ĝi estos nekompleta enmetaĵo. Kaj en ClickHouse enmetoj estas atomaj ĝis iu specifita sojlo en la grandeco de vicoj. Principe ĉi tio estas interesa maniero. Ankaŭ povas esti uzata.
Metodo 5. Jen alia interesa maniero. Ĉi tio estas ia komunum-evoluinta servilo por datuma batado. Mi mem ne rigardis ĝin, do mi povas nenion garantii. Tamen, ne ekzistas garantioj por ClickHouse mem. Ĉi tio ankaŭ estas malferma fonto, sed aliflanke, vi povus alkutimiĝi al iu kvalita normo, kiun ni provas provizi. Sed por ĉi tiu afero - mi ne scias, iru al GitHub, rigardu la kodon. Eble ili skribis ion bonan.
*ekde 2020, ankaŭ devus esti aldonita al konsidero .
Metodo 6. Alia maniero estas uzi Buffer-tabelojn. La avantaĝo de ĉi tiu metodo estas, ke ĝi estas tre facile komenci uzi. Kreu Buffer-tabelon kaj enigu ĝin.
Sed la malavantaĝo estas, ke la problemo ne estas tute solvita. Se kun rapideco de la MergeTree-tipo vi devas grupigi datumojn per unu aro por sekundo, tiam kun rapideco en bufrotabelo, vi devas grupigi almenaŭ ĝis kelkmil sekundo. Se estas pli ol 10 por sekundo, ĝi ankoraŭ estos malbona. Kaj se vi enmetas en aroj, tiam vi vidis, ke cent mil linioj sekundo estas akiritaj tie. Kaj ĉi tio jam estas sur sufiĉe pezaj datumoj.
Kaj ankaŭ bufrotabloj ne havas protokolon. Kaj se io misas kun via servilo, tiam la datumoj perdiĝos.
Kaj kiel gratifiko, ni lastatempe havis la ŝancon kolekti datumojn de Kafka en ClickHouse. Estas tablomotoro - Kafka. Vi simple kreas. Kaj vi povas pendigi materiigitajn vidojn sur ĝi. En ĉi tiu kazo, li elprenos la datumojn de Kafka kaj enmetos ĝin en la tabelojn, kiujn vi bezonas.
Kaj kio aparte plaĉas pri ĉi tiu ŝanco estas, ke ni ne sukcesis. Ĉi tio estas komunuma trajto. Kaj kiam mi diras "komunuma trajto", mi diras ĝin sen ia malestimo. Ni legis la kodon, faris revizion, ĝi devus funkcii bone.
* ekde 2020, ekzistas simila subteno por .
Kio alia povas esti maloportuna aŭ neatendita kiam oni enmetas datumojn? Se vi faras demandon pri enmeto de valoroj kaj skribas kelkajn kalkulitajn esprimojn en valoroj. Ekzemple, nun() ankaŭ estas taksita esprimo. Kaj en ĉi tiu kazo, ClickHouse estas devigita lanĉi la interpretiston de ĉi tiuj esprimoj por ĉiu linio, kaj la rendimento malpliiĝos laŭ ordoj de grandeco. Pli bone eviti ĝin.
* nuntempe, la problemo estas tute solvita, ne plu estas agado-regreso kiam oni uzas esprimojn en VALORES.
Alia ekzemplo kie povas esti iuj problemoj estas kiam viaj datumoj sur unu aro apartenas al amaso da sekcioj. Defaŭlte, ClickHouse dividas monate. Kaj se vi enmetas aron de miliono da vicoj, kaj estas datumoj dum pluraj jaroj, tiam vi havos plurajn dekojn da sekcioj tie. Kaj ĉi tio estas ekvivalenta al tio, ke estos aroj kelkdekoble pli malgrandaj, ĉar interne ili ĉiam unue estas dividitaj en sekciojn.
* lastatempe en ClickHouse en eksperimenta reĝimo aldonis subtenon por la kompakta formato de pecoj kaj pecoj en RAM kun skrib-antaŭa protokolo, kiu preskaŭ tute solvas la problemon.
Nun konsideru la duan specon de problemo - datumtajpado.
Datumtajpado povas esti strikta, kaj foje ĉeno. Ŝnuro - jen kiam vi ĵus prenis kaj deklaris, ke vi havas ĉiujn kampojn de tipo ĉeno. Ĝi aĉas. Vi ne devas fari tion.
Ni eltrovu kiel fari ĝin ĝuste en kazoj kie vi volas diri, ke ni havas ian kampon, ŝnuron, kaj lasu ClickHouse eltrovi ĝin memstare, sed mi ne prenos vaporbanon. Sed tamen indas iom klopodi.
Ekzemple, ni havas IP-adreson. En unu kazo, ni konservis ĝin kiel ŝnuro. Ekzemple, 192.168.1.1. Alie, ĝi estos nombro de tipo UInt32*. 32 bitoj sufiĉas por IPv4-adreso.
Unue, strange, la datumoj estos kunpremitaj proksimume same. Estos diferenco, certe, sed ne tiom granda. Do ne estas specialaj problemoj kun disko I/O.
Sed estas grava diferenco en CPU-tempo kaj demanda ekzekuttempo.
Ni kalkulu la nombron da unikaj IP-adresoj se ili estas konservitaj kiel nombroj. Ĝi rezultas 137 milionoj da linioj por sekundo. Se la sama kiel linioj, tiam 37 milionoj da linioj sekundo. Mi ne scias kial ĉi tiu koincido okazis. Mi mem faris ĉi tiujn petojn. Sed tamen ĉirkaŭ 4 fojojn pli malrapide.
Kaj se vi kalkulas la diferencon en diskospaco, tiam ankaŭ estas diferenco. Kaj la diferenco estas ĉirkaŭ unu kvarono, ĉar estas sufiĉe multe da unikaj IP-adresoj. Kaj se ekzistus linioj kun malgranda nombro da malsamaj valoroj, tiam ili estus kviete kunpremitaj en la vortaro en proksimume la saman volumon.
Kaj la kvarobla hordiferenco ne kuŝas sur la vojo. Eble vi, kompreneble, ne zorgas, sed kiam mi vidas tian diferencon, mi sentas min malĝoja.
Ni konsideru malsamajn kazojn.
1. Unu kazo kiam vi havas malmultajn malsamajn unikajn valorojn. En ĉi tiu kazo, ni uzas simplan praktikon, kiun vi verŝajne konas kaj povas uzi por iu ajn DBMS. Ĉio ĉi havas sencon ne nur por ClickHouse. Nur skribu la numerajn identigilojn al la datumbazo. Kaj vi povas konverti al ŝnuroj kaj reen flanke de via aplikaĵo.
Ekzemple, vi havas regionon. Kaj vi provas konservi ĝin kiel ŝnuro. Kaj tie estos skribite: Moskvo kaj Moskva Regiono. Kaj kiam mi vidas, ke "Moskvo" estas skribita tie, tiam ĉi tio ankoraŭ estas nenio, kaj kiam ĝi estas MO, ĝi iel fariĝas tute malĝoja. Jen kiom da bajtoj.
Anstataŭe, ni simple notu la Ulnt32-numeron kaj 250. Ni havas 250 en Yandex, sed la via povas esti malsama. Ĉiaokaze, mi diros, ke ClickHouse havas enkonstruitan kapablon labori kun geobazo. Vi simple skribu dosierujon kun regionoj, inkluzive de hierarkia, t.e. estos Moskvo, Moskva Regiono, kaj ĉio, kion vi bezonas. Kaj vi povas konverti ĉe la peta nivelo.
La dua opcio estas proksimume la sama, sed kun subteno ene de ClickHouse. Ĝi estas Enum-datumtipo. Vi simple skribas ĉiujn valorojn, kiujn vi bezonas ene de la Enum. Ekzemple, la tipo de aparato kaj skribi tie: labortablo, poŝtelefono, tablojdo, televido. Nur 4 opcioj.
La malavantaĝo estas, ke vi devas periode ŝanĝi. Nur unu opcio estis aldonita. Ni faras ŝanĝan tablon. Fakte, ŝanĝi tablon en ClickHouse estas senpaga. Precipe senpaga por Enum ĉar la datumoj sur disko ne ŝanĝiĝas. Sed tamen, alter akiras ŝlosilon * sur la tablo kaj devas atendi ĝis ĉiuj elektoj estas finitaj. Kaj nur post ĉi tiu ŝanĝo estos ekzekutita, t.e., estas ankoraŭ kelkaj ĝenoj.
* en lastatempaj versioj de ClickHouse, ALTER fariĝas tute nebloka.
Alia eblo tute unika por ClickHouse estas la konekto de eksteraj vortaroj. Vi povas skribi numerojn en ClickHouse, kaj konservi viajn adresarojn en iu ajn sistemo oportuna por vi. Ekzemple, vi povas uzi: MySQL, Mongo, Postgres. Vi eĉ povas krei vian propran mikroservon, kiu sendos ĉi tiujn datumojn per http. Kaj ĉe la nivelo de ClickHouse, vi skribas funkcion, kiu konvertos ĉi tiujn datumojn de nombroj al ĉenoj.
Ĉi tio estas speciala sed tre efika maniero fari kunigon sur ekstera tablo. Kaj estas du ebloj. En unu opcio, ĉi tiuj datumoj estos plene konservitaj, plene ĉeestantaj en la RAM kaj ĝisdatigitaj je iuj intervaloj. Kaj en alia opcio, se ĉi tiuj datumoj ne konvenas en la RAM, tiam vi povas parte konservi ĝin.
Jen ekzemplo. Estas Yandex.Direct. Kaj ekzistas reklama kompanio kaj standardoj. Verŝajne estas dekoj da milionoj da reklamaj kompanioj. Kaj proksimume taŭgas en la RAM. Kaj estas miliardoj da standardoj, ili ne taŭgas. Kaj ni uzas kaŝmemoritan vortaron de MySQL.
La nura problemo estas, ke la kaŝmemorigita vortaro funkcios bone se la trafa indico estas proksima al 100%. Se ĝi estas pli malgranda, tiam kiam oni prilaboras petojn por ĉiu datumpakaĵo, necesos efektive preni la mankantajn ŝlosilojn kaj iri preni datumojn de MySQL. Pri ClickHouse, mi ankoraŭ povas garantii tion - jes, ĝi ne malrapidiĝas, mi ne parolos pri aliaj sistemoj.
Kaj kiel gratifiko, vortaroj estas tre facila maniero ĝisdatigi datumojn en ClickHouse retroaktive. Tio estas, vi havis raporton pri reklamaj kompanioj, la uzanto simple ŝanĝis la reklaman kompanion kaj en ĉiuj malnovaj datumoj, en ĉiuj raportoj, ĉi tiuj datumoj ankaŭ ŝanĝiĝis. Se vi skribas vicojn rekte al la tabelo, tiam vi ne povos ĝisdatigi ilin.
Alia maniero kiam vi ne scias kie akiri la identigilojn por viaj ŝnuroj. vi povas nur haŝiŝon. Kaj la plej facila opcio estas preni 64-bitan haŝiŝon.
La sola problemo estas, ke se la hash estas 64-bita, tiam vi preskaŭ certe havos koliziojn. Ĉar se estas miliardo da linioj, tiam la probableco jam fariĝas palpebla.
Kaj ne estus tre bone haŝi la nomojn de reklamaj kompanioj tiel. Se la reklamaj kampanjoj de diversaj kompanioj miksiĝos, tiam estos io nekomprenebla.
Kaj estas simpla lertaĵo. Vere, ĝi ankaŭ ne tre taŭgas por seriozaj datumoj, sed se io ne estas tre grava, tiam simple aldonu alian klientidentigilon al la vortara ŝlosilo. Kaj tiam vi havos koliziojn, sed nur ene de unu kliento. Kaj ni uzas ĉi tiun metodon por la ligomapo en Yandex.Metrica. Ni havas URL-ojn tie, ni stokas haŝojn. Kaj ni scias, ke estas konfliktoj, kompreneble. Sed kiam paĝo estas montrata, tiam la probableco, ke ĝi estas sur unu paĝo por unu uzanto, iuj URL-oj kuniĝas kaj tio estos rimarkita, tiam ĉi tio povas esti neglektita.
Kiel gratifiko, por multaj operacioj, nur hashoj sufiĉas kaj la ŝnuroj mem ne povas esti stokitaj ie ajn.
Alia ekzemplo se la ŝnuroj estas mallongaj, kiel retejo-domajnoj. Ili povas esti konservitaj kiel estas. Aŭ, ekzemple, la retumila lingvo ru estas 2 bajtoj. Kompreneble mi bedaŭras la bajtojn, sed ne maltrankviliĝu, 2 bitokoj ne estas domaĝe. Bonvolu konservi ĝin tia, ne maltrankviliĝu.
Alia kazo estas kiam, male, estas multaj kordoj kaj samtempe estas multaj unikaj en ili, kaj eĉ la aro estas eble senlima. Tipa ekzemplo estas serĉfrazoj aŭ urloj. Serĉaj frazoj, inkluzive pro mistajpoj. Ni vidu kiom da unikaj serĉfrazoj tage. Kaj rezultas, ke ili estas preskaŭ duono de ĉiuj eventoj. Kaj en ĉi tiu kazo, vi povus pensi, ke vi devas normaligi la datumojn, kalkuli la identigilojn, meti ilin en apartan tabelon. Sed vi ne devas fari tion. Nur konservu ĉi tiujn liniojn kiel estas.
Pli bone - ne inventu ion, ĉar se vi stokas ĝin aparte, vi devos fari kuniĝon. Kaj ĉi tiu kunigo estas en la plej bona kazo hazarda aliro al memoro, se ĝi ankoraŭ taŭgas en memoro. Se ĝi ne taŭgas, tiam estos problemoj ĝenerale.
Kaj se la datumoj estas konservitaj en loko, tiam ili estas simple legitaj en la ĝusta ordo de la dosiersistemo kaj ĉio estas en ordo.
Se vi havas URL-ojn aŭ iun alian kompleksan longan ŝnuron, tiam vi devus pensi pri la fakto, ke vi povas kalkuli iom da premo anticipe kaj skribi ĝin en aparta kolumno.
Por urloj, ekzemple, vi povas konservi la domajnon aparte. Kaj se vi vere bezonas domajnon, tiam simple uzu ĉi tiun kolumnon, kaj la URL-oj kuŝos, kaj vi eĉ ne tuŝos ilin.
Ni vidu, kia estas la diferenco. ClickHouse havas specialan funkcion, kiu kalkulas la domajnon. Ĝi estas tre rapida, ni optimumigis ĝin. Kaj, sincere, ĝi eĉ ne konformas al la RFC, sed tamen ĝi konsideras ĉion, kion ni bezonas.
Kaj en unu kazo, ni simple ricevos la URL-ojn kaj kalkulos la domajnon. Ĝi rezultas 166 milisekundoj. Kaj se vi prenas pretan domajnon, tiam ĝi rezultas nur 67 milisekundojn, tio estas, preskaŭ trioble pli rapide. Kaj pli rapide, ne ĉar ni bezonas fari iujn kalkulojn, sed ĉar ni legas malpli da datumoj.
Ial, unu peto, kiu estas pli malrapida, ricevas pli da rapideco en gigabajtoj sekundo. Ĉar ĝi legas pli da gigabajtoj. Ĉi tio estas tute redunda datumoj. La peto ŝajnas funkcii pli rapide, sed daŭras pli longe por plenumi.
Kaj se vi rigardas la kvanton da datumoj sur la disko, montriĝas, ke la URL estas 126 megabajtoj, kaj la domajno estas nur 5 megabajtoj. Ĝi rezultas 25 fojojn malpli. Tamen, la demando estas ankoraŭ nur 4 fojojn pli rapida. Sed tio estas ĉar la datumoj estas varmaj. Kaj se estus malvarme, ĝi verŝajne estus 25 fojojn pli rapida pro disko I/O.
Cetere, se vi taksas kiom la domajno estas malpli ol la URL, tiam ĝi rezultas proksimume 4 fojojn.Sed ial, la datumoj sur la disko prenas 25 fojojn malpli. Kial? Pro kunpremado. Kaj la url estas kunpremita, kaj la domajno estas kunpremita. Sed ofte la url enhavas amason da rubo.
Kaj, kompreneble, indas uzi la ĝustajn datumtipojn, kiuj estas specife desegnitaj por la ĝustaj valoroj aŭ kiuj taŭgas. Se vi estas en IPv4, konservu UInt32*. Se IPv6, tiam FixedString(16), ĉar IPv6-adreso estas 128 bitoj, t.e. stokas rekte en binara formato.
Sed kio se vi foje havas IPv4-adresojn kaj foje IPv6? Jes, vi povas konservi ambaŭ. Unu kolumno por IPv4, alia por IPv6. Kompreneble, ekzistas eblo mapi IPv4 al IPv6. Ĉi tio ankaŭ funkcios, sed se vi ofte bezonas IPv4-adreson en viaj petoj, tiam estus bone meti ĝin en apartan kolumnon.
* Nun ClickHouse havas apartajn IPv4, IPv6 datumtipojn, kiuj konservas datumojn tiel efike kiel nombroj, sed reprezentas ilin tiel oportune kiel ŝnuroj.
Ankaŭ gravas noti, ke indas antaŭprilabori la datumojn. Ekzemple, iuj krudaj ŝtipoj venas al vi. Kaj, eble, vi ne enmetu ilin tuj en ClickHouse, kvankam estas tre tenta fari nenion kaj ĉio funkcios. Sed ankoraŭ indas efektivigi tiujn kalkulojn, kiuj eblas.
Ekzemple, retumila versio. En iu najbara fako, al kiu mi ne volas montri la fingron, la retumila versio estas konservita tie tiel, tio estas kiel ŝnuro: 12.3. Kaj tiam, por fari raporton, ili prenas ĉi tiun ŝnuron kaj dividas per tabelo, kaj tiam per la unua elemento de la tabelo. Nature, ĉio malrapidiĝas. Mi demandis kial ili faras ĉi tion. Ili diris al mi, ke ili ne ŝatas antaŭtempan optimumigon. Kaj mi ne ŝatas antaŭtempan pesimismon.
Do en ĉi tiu kazo estus pli ĝuste dividi en 4 kolumnojn. Ne timu ĉi tie, ĉar ĉi tio estas ClickHouse. ClickHouse estas kolumna datumbazo. Kaj ju pli bonordaj kolonetoj, des pli bone. Estos 5 BrowserVersion, faru 5 kolumnojn. Ĉi tio estas bone.
Nun pripensu kion fari se vi havas multajn tre longajn ŝnurojn, tre longajn tabelojn. Ili tute ne bezonas esti konservitaj en ClickHouse. Anstataŭe, vi povas konservi nur iun identigilon en ClickHouse. Kaj ĉi tiuj longaj vicoj ŝovas ilin en iun alian sistemon.
Ekzemple, unu el niaj analizaj servoj havas iujn evento-parametrojn. Kaj se multaj parametroj venas al eventoj, ni simple konservas la unuajn 512 kiuj trafas.Ĉar 512 ne estas domaĝe.
Kaj se vi ne povas decidi pri viaj datumtipoj, tiam vi ankaŭ povas skribi datumojn al ClickHouse, sed al provizora tabelo de la tipo Log, kiu estas speciala por provizoraj datumoj. Post tio, vi povas analizi kian distribuon de valoroj vi havas tie, kio ĝenerale estas tie kaj konsistigi la ĝustajn tipojn.
* Nun ClickHouse havas datumtipo kiu permesas vin efike stoki ŝnurojn kun malpli da peno.
Nun konsideru alian interesan kazon. Kelkfoje aferoj funkcias en stranga maniero por homoj. Mi iras kaj vidas ĉi tion. Kaj tuj ŝajnas, ke tion faris iu tre sperta, inteligenta administranto, kiu havas vastan sperton pri agordo de MySQL-versio 3.23.
Ĉi tie ni vidas mil tabelojn, ĉiu el kiuj enhavas la reston de dividado ne klaras kio per mil.
Principe mi respektas la sperton de aliaj homoj, inkluzive de kompreni, kian suferon oni povas akiri ĉi tiun sperton.
Kaj la kialoj estas pli-malpli klaraj. Ĉi tiuj estas malnovaj stereotipoj, kiuj eble akumuliĝis laborante kun aliaj sistemoj. Ekzemple, MyISAM-tabloj ne havas amasigitan ĉefan ŝlosilon. Kaj ĉi tiu maniero kunhavigi datumojn povas esti malespera provo akiri la saman funkcion.
Alia kialo estas, ke estas malfacile fari ajnajn ŝanĝajn operaciojn sur grandaj tabloj. Ĉio estos blokita. Kvankam en modernaj versioj de MySQL, ĉi tiu problemo ne plu estas tiel serioza.
Aŭ, ekzemple, microsharding, sed pli pri tio poste.
En ClickHouse, vi ne bezonas fari tion, ĉar, unue, la ĉefa ŝlosilo estas amasigita, la datumoj estas ordigitaj per la ĉefa ŝlosilo.
Kaj foje homoj demandas min: "Kiel ŝanĝiĝas la agado de intervaldemandoj en ClickHouse laŭ la grandeco de la tabelo?". Mi diras, ke ĝi tute ne ŝanĝiĝas. Ekzemple, vi havas tabelon kun miliardo da vicoj kaj vi legas gamon de unu miliono da vicoj. Ĉio estas en ordo. Se la tablo havas duilionojn da vicoj kaj vi legas unu milionon da vicoj, tiam ĝi estos preskaŭ la sama.
Kaj, due, iuj pecoj kiel manaj sekcioj ne estas bezonataj. Se vi eniros kaj rigardos kio estas en la dosiersistemo, vi vidos, ke tablo estas sufiĉe serioza afero. Kaj tie interne estas io kiel vandoj. Tio estas, ClickHouse faras ĉion por vi kaj vi ne bezonas suferi.
Ŝanĝi en ClickHouse estas senpaga se ŝanĝu aldonu/faligi kolumnon.
Kaj vi ne faru tabelojn, ĉar se vi havas 10 vicojn aŭ 10 000 vicojn en via tabelo, tiam tute ne gravas. ClickHouse estas sistemo, kiu optimumigas trairon, ne latentecon, do ne havas sencon prilabori 10 liniojn.
Estas ĝuste uzi unu grandan tablon. Forigu la malnovajn stereotipojn, ĉio estos en ordo.
Kaj kiel gratifiko, en la plej nova versio, ni havas la ŝancon fari arbitran dispartigan ŝlosilon por plenumi ĉiajn bontenajn operaciojn sur individuaj sekcioj.
Ekzemple, vi bezonas multajn malgrandajn tabelojn, ekzemple, kiam necesas prilabori iujn mezajn datumojn, vi ricevas pecojn kaj vi devas fari transformon sur ili antaŭ ol skribi al la fina tablo. Por ĉi tiu kazo, ekzistas mirinda tablomotoro - StripeLog. Ĝi estas kiel TinyLog, nur pli bona.
* Nun ClickHouse havas pli .
Alia kontraŭ-ŝablono estas microsharding. Ekzemple, vi devas dividi datumojn kaj vi havas 5 servilojn, kaj morgaŭ estos 6 serviloj. Kaj vi pensas kiel reekvilibrigi ĉi tiujn datumojn. Kaj anstataŭe, vi ne disiĝas en 5 pecetojn, sed en 1 pecetojn. Kaj tiam vi mapas ĉiun el ĉi tiuj mikropartoj al aparta servilo. Kaj vi sukcesos en unu servilo, ekzemple, 000 ClickHouse, ekzemple. Aparta kazo sur apartaj havenoj aŭ apartaj datumbazoj.
Sed en ClickHouse ĉi tio ne estas tre bona. Ĉar eĉ unu okazo de ClickHouse provas uzi ĉiujn disponeblajn servilresursojn por prilabori unu peton. Tio estas, vi havas ian servilon kaj tie, ekzemple, 56 procesoraj kernoj. Vi faras demandon, kiu daŭras unu sekundon kaj ĝi uzos 56 kernojn. Kaj se vi metis 200 ClickHouses sur unu servilo tie, tiam rezultas, ke 10 fadenoj komenciĝos. Ĝenerale ĉio estos tre malbona.
Alia kialo estas, ke la distribuo de laboro tra ĉi tiuj kazoj estos neegala. Iuj finos pli frue, iuj finiĝos poste. Se ĉio ĉi okazis en unu okazo, tiam ClickHouse mem estus eltrovinta kiel ĝuste distribui la datumojn inter la riveretoj.
Kaj alia kialo estas, ke vi havos interprocesora komunikado per TCP. La datumoj devos esti seriigitaj, deserialigitaj, kaj ĉi tio estas grandega nombro da mikropartoj. Ĝi simple ne funkcios.
Alia kontraŭŝablono, kvankam ĝi apenaŭ povas esti nomata kontraŭŝablono. Ĉi tio estas granda kvanto de antaŭ-agregado.
Ĝenerale, antaŭagregado estas bona. Vi havis miliardon da vicoj, vi agregis ĝin kaj ĝi fariĝis 1 vicoj, kaj nun la demando estas ekzekutita tuj. Ĉio estas bonega. Tiel vi povas fari ĝin. Kaj por tio, eĉ ClickHouse havas specialan AggregatingMergeTree-tabelspecon, kiu faras pliigan agregadon kiam datumoj estas enigitaj.
Sed estas tempoj, kiam vi pensas, ke ni agregas datumojn kiel ĉi kaj agregos datumojn kiel ĉi. Kaj en iu najbara fako, mi ankaŭ ne volas diri kiu, ili uzas SummingMergeTree-tablojn por resumi per la ĉefa ŝlosilo, kaj 20 kolumnoj estas uzataj kiel la ĉefa ŝlosilo. Por la okazo, mi ŝanĝis la nomojn de kelkaj kolumnoj por konspiro, sed pri tio temas.
Kaj tiaj problemoj ekestas. Unue, la kvanto da datumoj, kiujn vi havas, ne tro reduktiĝas. Ekzemple, ĝi estas reduktita je tri fojojn. Tri fojojn estus bona prezo pagi la senliman analizon, kiu venas kun ne-agregaj datumoj. Se la datumoj estas kunigitaj, tiam vi ricevas nur mizerajn statistikojn anstataŭ analizojn.
Kaj kio estas precipe bona? Ke ĉi tiuj homoj de la sekva fako, iru kaj petu foje aldoni unu plian kolumnon al la ĉefa ŝlosilo. Tio estas, ni kunigis la datumojn tiel, kaj nun ni volas iom pli. Sed ne ekzistas ŝanĝa ĉefa ŝlosilo en ClickHouse. Tial vi devas skribi iujn skriptojn en C++. Kaj mi ne ŝatas skriptojn, eĉ se ili estas en C++.
Kaj se vi rigardas por kio ClickHouse estis kreita, tiam ne-agregataj datumoj estas ĝuste la scenaro por kiu ĝi naskiĝis. Se vi uzas ClickHouse por ne-agregaj datumoj, tiam vi faras ĉion ĝuste. Se vi agregas, tiam ĉi tio foje estas pardonebla.
Alia interesa kazo estas petoj en senfina buklo. Mi foje iras al iu produktservilo kaj rigardas tie montran procesliston. Kaj ĉiufoje mi malkovras, ke io terura okazas.
Ekzemple, jen ĉi tio. Tuj estas klare, ke eblis fari ĉion en unu peto. Nur skribu la url-on kaj la liston tie.
Kial multaj tiaj petoj en senfina buklo malbonas? Se la indekso ne estas uzata, tiam vi havos multajn paŝojn super la samaj datumoj. Sed se oni uzas indekson, ekzemple, oni havas ĉefan ŝlosilon ĉe ru kaj oni skribas tie url = io. Kaj vi pensas, ke unu url estos punkte legata de la tabelo, ĉio estos en ordo. Sed vere ne. Ĉar ClickHouse faras ĉion en aroj.
Kiam li bezonas legi iun gamon da datumoj, li legas iom pli, ĉar la indekso en ClickHouse estas malabunda. Ĉi tiu indekso ne permesas al vi trovi unu individuan vicon en la tabelo, nur ian gamon. Kaj la datumoj estas kunpremitaj en blokoj. Por legi unu linion, vi devas preni la tutan blokon kaj malkunpremi ĝin. Kaj se vi kuras amason da demandoj, vi havos multajn intersekciĝojn de tiuj, kaj vi havos multe da laboro farita denove kaj denove.
Kaj kiel gratifiko, vi povas vidi, ke en ClickHouse vi ne devas timi translokigi eĉ megabajtojn kaj eĉ centojn da megabajtoj al la IN-sekcio. Mi memoras el nia praktiko, ke se ni pasas amason da valoroj en la sekcio IN en MySQL, ekzemple, ni pasas 100 megabajtojn de iuj nombroj tie, tiam MySQL manĝas 10 gigabajtojn da memoro kaj nenio alia okazas al. ĝi, ĉio funkcias malbone.
Kaj la dua afero estas, ke en ClickHouse, se viaj demandoj uzas indekson, tiam ĝi ĉiam ne estas pli malrapida ol plena skanado, t.e. se vi bezonas legi preskaŭ la tutan tabelon, ĝi iros sinsekve kaj legos la tutan tabelon. Ĝenerale, li eltrovos ĝin.
Tamen, estas iuj malfacilaĵoj. Ekzemple, tiu IN kun subdemando ne uzas la indekson. Sed ĉi tio estas nia problemo kaj ni devas solvi ĝin. Estas nenio fundamenta ĉi tie. Ni faru ĝin*.
Kaj alia interesa afero estas, ke se vi havas tre longan peton kaj distribua peto prilaborado okazas, tiam ĉi tiu tre longa peto estos sendita al ĉiu servilo sen kunpremado. Ekzemple, 100 megabajtoj kaj 500 serviloj. Kaj sekve, 50 gigabajtoj estos translokigitaj tra la reto. Ĝi estos translokigita kaj tiam ĉio estos sukcese efektivigita.
* jam uzante; ĉio estis riparita kiel promesite.
Kaj estas sufiĉe ofta se la petoj venas de la API. Ekzemple, vi faris ian servon. Kaj se iu bezonas vian servon, tiam vi malfermis la API kaj laŭvorte du tagojn poste vi vidas, ke io nekomprenebla okazas. Ĉio estas troŝarĝita kaj kelkaj teruraj petoj envenas, kiuj neniam devus estinti.
Kaj estas nur unu solvo. Se vi malfermis la API, tiam vi devos tranĉi ĝin. Ekzemple, enigi kelkajn kvotojn. Ne ekzistas aliaj raciaj elektoj. Alie, ili tuj skribos skripton kaj estos problemoj.
Kaj ClickHouse havas specialan funkcion - ĉi tio estas la kalkulo de kvotoj. Plie, vi povas transdoni vian kvotan ŝlosilon. Ĉi tio estas, ekzemple, interna uzantidentigilo. Kaj kvotoj estos kalkulitaj sendepende por ĉiu el ili.
Nun alia interesa afero. Ĉi tio estas mana reproduktado.
Mi konas multajn kazojn kie, kvankam ClickHouse havas enkonstruitan reproduktadsubtenon, homoj reproduktas ClickHouse permane.
Kio estas la principo? Vi havas datumtraktadon. Kaj ĝi funkcias sendepende, ekzemple, en malsamaj datumcentroj. Vi skribas la samajn datumojn en la sama maniero al ClickHouse, kvazaŭ. Vere, praktiko montras, ke la datumoj ankoraŭ diverĝos pro iuj proprecoj en via kodo. Mi esperas tion en via.
Kaj periode vi ankoraŭ devas permane sinkronigi. Ekzemple, unufoje monate administrantoj faras rsync.
Fakte, estas multe pli facile uzi la enkonstruitan reproduktadon en ClickHouse. Sed povas esti iuj kontraŭindikoj, ĉar por tio vi devas uzi ZooKeeper. Mi diros nenion malbonan pri ZooKeeper, principe, la sistemo funkcias, sed okazas, ke homoj ne uzas ĝin pro java-fobio, ĉar ClickHouse estas tiel bona sistemo skribita en C ++ ke vi povas uzi kaj ĉio estos bone. Kaj ZooKeeper en java. Kaj iel vi eĉ ne volas rigardi, sed tiam vi povas uzi manan reproduktadon.
ClickHouse estas praktika sistemo. Ĝi konsideras viajn bezonojn. Se vi havas manan reproduktadon, tiam vi povas krei Distribuitan tabelon, kiu rigardas viajn manajn kopiojn kaj faras malsukceson inter ili. Kaj ekzistas eĉ speciala opcio, kiu permesas vin eviti fiaskojn, eĉ se viaj linioj estas sisteme diverĝaj.
Plue, povas esti problemoj se vi uzas primitivajn tabelmotorojn. ClickHouse estas tia konstrukciisto, kiu havas multajn malsamajn tabelmotorojn. Por ĉiuj gravaj kazoj, kiel skribite en la dokumentaro, uzu tabelojn de la MergeTree-familio. Kaj ĉio cetera - ĉi tio estas tiel, por individuaj kazoj aŭ por provoj.
En MergeTree-tabelo, vi ne bezonas havi ajnan daton kaj horon. Vi ankoraŭ povas uzi. Se ne ekzistas dato kaj horo, skribu, ke defaŭlta estas 2000. Ĝi funkcios kaj ne postulos rimedojn.
Kaj en la nova versio de la servilo, vi eĉ povas specifi, ke vi havas kutiman dispartigon sen diskpartiga ŝlosilo. Estos same.
Aliflanke, primitivaj tabelmotoroj povas esti uzitaj. Ekzemple, plenigu la datumojn unufoje kaj vidu, tordi kaj forigi. Vi povas uzi Log.
Aŭ stoki malgrandajn volumojn por meza prilaborado estas StripeLog aŭ TinyLog.
Memoro povas esti uzata se estas malgranda kvanto da datumoj kaj nur tordi ion en la RAM.
ClickHouse ne tre ŝatas renormaligitajn datumojn.
Jen tipa ekzemplo. Ĉi tio estas grandega nombro da URL-oj. Vi metas ilin en la apudan tablon. Kaj tiam ni decidis fari JOIN kun ili, sed ĉi tio ne funkcios, kiel regulo, ĉar ClickHouse nur subtenas Hash JOIN. Se ne estas sufiĉe da RAM por multaj datumoj kun kiuj konektiĝi, tiam JOIN ne funkcios *.
Se la datumoj estas de alta kardinaleco, tiam ne maltrankviliĝu, konservu ĝin en malnormaligita formo, la URL-oj estas rekte en la ĉefa tabelo.
* kaj nun ClickHouse ankaŭ havas kunfandigon, kaj ĝi funkcias en kondiĉoj, kie la mezaj datumoj ne konvenas en la RAM. Sed ĉi tio estas neefika kaj la rekomendo restas valida.
Kelkaj pliaj ekzemploj, sed mi jam dubas, ĉu ili estas kontraŭ-ŝablonoj aŭ ne.
ClickHouse havas unu konatan malavantaĝon. Li ne scias kiel ĝisdatigi *. Iasence, ĉi tio estas eĉ bona. Se vi havas iujn gravajn datumojn, ekzemple kontadon, tiam neniu povos sendi ilin, ĉar ne estas ĝisdatigoj.
* subteno por ĝisdatigo kaj forigo en bata reĝimo estas delonge aldonita.
Sed ekzistas iuj specialaj manieroj, kiuj permesas ĝisdatigojn aperi en la fono. Ekzemple, tabeloj de tipo ReplaceMergeTree. Ili faras ĝisdatigojn dum fonaj kunfandaĵoj. Vi povas devigi ĉi tion per optimumigi tabelon. Sed ne faru tion tro ofte, ĉar ĝi tute anstataŭigos la subdiskon.
Distribuitaj JOIN-oj en ClickHouse - ĉi tio ankaŭ estas malbone pritraktata de la demandplanisto.
Malbona, sed foje bone.
Uzante ClickHouse nur por relegi datumojn per select*.
Mi ne rekomendus uzi ClickHouse por volumenaj kalkuloj. Sed ĉi tio ne estas tute vera, ĉar ni jam malproksimiĝas de ĉi tiu rekomendo. Kaj ni lastatempe aldonis la kapablon apliki maŝinlernajn modelojn en ClickHouse - Catboost. Kaj ĝi maltrankviligas min, ĉar mi pensas: “Kia hororo. Jen kiom da cikloj por bajto ĝi rezultas! Estas domaĝe al mi komenci horloĝciklojn sur bajtoj.
Sed ne timu, instalu ClickHouse, ĉio estos en ordo. Se io ajn, ni havas komunumon. Cetere, la komunumo estas vi. Kaj se vi havas problemojn, vi povas almenaŭ iri al nia babilejo, kaj mi esperas, ke vi estos helpita.
Viaj demandoj
Dankon pro la raporto! Kie plendi pri la kraŝo de ClickHouse?
Vi povas plendi al mi persone nun.
Mi ĵus komencis uzi ClickHouse. Tuj faligis la cli-interfacon.
Kia poentaro.
Iom poste, mi faligis la servilon per malgranda elekto.
Vi havas talenton.
Mi malfermis GitHub-cimon, sed ĝi estis ignorita.
Ni vidos.
Aleksey trompis min ĉeesti la raporton, promesante diri al mi kiel vi premas la datumojn enen.
Tre simpla.
Jen kion mi konstatis hieraŭ. Pli da specifaĵoj.
Ne ekzistas teruraj ruzoj. Ĝi estas nur bloko-post-bloka kunpremo. La defaŭlta estas LZ4, vi povas ebligi ZSTD*. Blokoj de 64 kilobajtoj ĝis 1 megabajto.
* ekzistas ankaŭ subteno por specialigitaj kunpremaj kodekoj, kiuj povas esti uzataj en ĉeno kun aliaj algoritmoj.
Ĉu la blokoj estas nur krudaj datumoj?
Ne ĝuste kruda. Estas tabeloj. Se vi havas nombran kolumnon, tiam la nombroj en vico estas stakigitaj en tabelo.
Estas klare.
Alexey, ekzemplo kiu estis kun uniqExact super IP-oj, t.e. la fakto ke uniqExact prenas pli longe por nombri per ŝnuroj ol per nombroj, ktp. Kio se ni aplikas ŝajnon per niaj oreloj kaj ĵetas en la momento de provlegado? Tio estas, vi ŝajne diris, ke ĝi ne multe diferencas sur la disko. Se ni legas liniojn el la disko, ĵetas, ĉu do ni havos agregaĵojn pli rapide aŭ ne? Aŭ ĉu ni ankoraŭ marĝene gajnas ĉi tie? Ŝajnas al mi, ke vi testis ĝin, sed ial ne indikis ĝin en la komparnormo.
Mi pensas, ke ĝi estos pli malrapida ol neniu rolantaro. En ĉi tiu kazo, la IP-adreso devas esti analizita de la ĉeno. Kompreneble, en ClickHouse, IP-adresa analizo ankaŭ estas optimumigita. Ni tre klopodis, sed samloke vi havas la nombrojn skribitajn en dekmila formo. Tre malkomforta. Aliflanke, la funkcio uniqExact funkcios pli malrapide sur ŝnuroj, ne nur ĉar ĉi tiuj estas ŝnuroj, sed ankaŭ ĉar malsama specialiĝo de la algoritmo estas elektita. Ŝnuroj estas nur traktataj alimaniere.
Kaj se ni prenas pli primitivan datumtipo? Ekzemple, ili notis la uzantidentigilon, kiun ni havas, skribis ĝin kiel linion, kaj poste ĵetis ĝin, ĉu ĝi estos pli amuza aŭ ne?
Mi dubas. Mi pensas, ke ĝi estos eĉ pli malĝoja, ĉar finfine analizado de nombroj estas grava problemo. Ŝajnas al mi, ke ĉi tiu kolego eĉ havis raporton pri kiom malfacile estas analizi nombrojn en dekmila formo, sed eble ne.
Alexey, koran dankon pro la raporto! Kaj koran dankon pro ClickHouse! Mi havas demandon pri planoj. Ĉu estas funkcio en la planoj por nekomplete ĝisdatigi vortarojn?
t.e. parta rekomenco?
Jes Jes. Kiel la kapablo agordi MySQL-kampon tie, t.e. ĝisdatigi poste tiel ke nur ĉi tiuj datumoj estas ŝarĝitaj se la vortaro estas tre granda.
Tre interesa trajto. Kaj, ŝajnas al mi, iu persono sugestis ĝin en nia babilejo. Eble estis eĉ vi.
Mi ne pensas tiel.
Bonege, nun rezultas ke du petoj. Kaj vi povas komenci fari ĝin malrapide. Sed mi volas averti vin tuj, ke ĉi tiu funkcio estas sufiĉe simpla por efektivigi. Tio estas, en teorio, vi nur bezonas skribi la versinumeron en la tabelon kaj poste skribi: la versio estas malpli ol tia kaj tia. Kaj tio signifas, ke, plej verŝajne, ni proponos ĝin al entuziasmuloj. Ĉu vi estas entuziasmulo?
Jes, sed bedaŭrinde ne en C++.
Ĉu viaj kolegoj povas skribi en C++?
Mi trovos iun.
Granda*.
* la funkcio estis aldonita du monatojn post la raporto - ĝi estis evoluigita de la aŭtoro de la demando kaj sendita de lia .
Dankon!
Saluton! Dankon pro la raporto! Vi menciis, ke ClickHouse tre bone konsumas ĉiujn disponeblajn rimedojn. Kaj la oratoro apud Luxoft parolis pri sia decido por la Rusa Poŝto. Li diris, ke ili tre ŝatis ClickHouse, sed ili ne uzis ĝin anstataŭ sia ĉefa konkuranto ĝuste ĉar ĝi manĝis la tutan procesoron. Kaj ili ne povis enmeti ĝin en sian arkitekturon, en sian ZooKeeper kun havenistoj. Ĉu eblas iel limigi ClickHouse por ke ĝi ne konsumu ĉion, kio disponeblas al ĝi?
Jes, ĝi estas ebla kaj tre facila. Se vi volas konsumi malpli da kernoj, do simple skribu set max_threads = 1. Kaj jen ĉio, ĝi plenumos la peton en unu kerno. Plie, vi povas specifi malsamajn agordojn por malsamaj uzantoj. Do neniu problemo. Kaj diru al viaj kolegoj de Luxoft, ke ne estas bone, ke ili ne trovis ĉi tiun agordon en la dokumentado.
Aleksej, saluton! Mi ŝatus demandi ĉi tiun demandon. Ĉi tio ne estas la unua fojo, ke mi aŭdas, ke multaj homoj komencas uzi ClickHouse kiel deponejon por protokoloj. Ĉe la raporto, vi diris, ke vi ne faru ĉi tion, tio estas, ke vi ne bezonas konservi longajn liniojn. Kion vi pensas pri tio?
Unue, ŝtipoj kutime ne estas longaj vicoj. Estas, kompreneble, esceptoj. Ekzemple, iu servo skribita en java ĵetas escepton, ĝi estas registrita. Kaj tiel en senfina buklo, kaj elĉerpante malmola disko spaco. La solvo estas tre simpla. Se la linioj estas tre longaj, tiam tranĉu ilin. Kion signifas longa? Dekoj da kilobajtoj estas malbona *.
* en lastatempaj versioj de ClickHouse, "adapta indekso-granulareco" estas ebligita, kio forigas la problemon de stokado de longaj ŝnuroj plejparte.
Ĉu kilobajto estas normala?
Bone
Saluton! Dankon pro la raporto! Mi jam demandis pri tio en la babilejo, sed mi ne memoras ĉu mi ricevis respondon. Ĉu ekzistas iu plano etendi la KUN-sekcion laŭ CTE-modo?
Ankoraŭ ne. La sekcio KUN estas iom frivola. Ĝi estas kiel eta trajto por ni.
Mi komprenas. Dankon!
Dankon pro la raporto! Tre interesa! tutmonda demando. Ĉu oni planas fari, eble en la formo de iaj stumpoj, modifon de forigo de datumoj?
Necese. Ĉi tio estas nia unua tasko en nia vico. Ni nun aktive pensas pri kiel fari ĉion ĝuste. Kaj vi devus komenci premi la klavaron*.
* premis la butonojn sur la klavaro kaj ĉio estis farita.
Ĉu ĝi iel influos sisteman rendimenton aŭ ne? Ĉu la enmetaĵo estos tiel rapida kiel nun?
Eble la forigoj mem, la ĝisdatigoj mem estos tre pezaj, sed ĉi tio neniel influos la agadon de elektoj kaj la agado de enmetoj.
Kaj ankoraŭ unu malgranda demando. Ĉe la prezento, vi parolis pri la ĉefa ŝlosilo. Sekve, ni havas dispartigo, kiu estas monata defaŭlte, ĉu ne? Kaj kiam ni fiksas datintervalon kiu konvenas al monato, tiam ni nur legas ĉi tiun subdiskon, ĉu ne?
Jes.
Demando. Se ni ne povas elekti ajnan ĉefan ŝlosilon, ĉu estas ĝuste fari ĝin ĝuste laŭ la kampo "Dato" por ke en la fono estu pli malgranda restrukturado de ĉi tiuj datumoj por ke ili konvenu en pli orda maniero? Se vi ne havas intervaldemandojn kaj vi eĉ ne povas elekti ajnan ĉefan ŝlosilon, ĉu indas meti daton en la ĉefan ŝlosilon?
Jes.
Eble havas sencon meti en la ĉefan ŝlosilon kampon per kiu la datumoj estos pli bone kunpremitaj se ili estas ordigitaj per ĉi tiu kampo. Ekzemple, uzantidentigilo. Uzanto, ekzemple, iras al la sama retejo. En ĉi tiu kazo, metu la uzantan identigilon kaj tempon. Kaj tiam viaj datumoj estos pli bone kunpremitaj. Koncerne la daton, se vi vere ne havas kaj neniam havas intervaldemandojn pri datoj, tiam vi ne povas meti la daton en la ĉefa ŝlosilo.
Bone koran dankon!
fonto: www.habr.com