Kusabab ClickHouse mangrupikeun sistem khusus, nalika nganggo éta penting pikeun tumut kana fitur arsitékturna. Dina laporan ieu, Alexey bakal ngobrol ngeunaan conto kasalahan umum nalika ngagunakeun ClickHouse, nu bisa ngakibatkeun karya teu epektip. Conto praktis bakal nunjukkeun kumaha milih hiji atanapi skéma ngolah data anu sanés tiasa ngarobih kinerja ku urutan gedéna.
Halo sadayana! Ngaran abdi Alexey, abdi ngadamel ClickHouse.
Anu mimiti, kuring gancang-gancang nyenangkeun anjeun, ayeuna kuring moal nyarioskeun ka anjeun naon ClickHouse. Jujur, kuring bosen. Unggal waktos abdi ngabejaan Anjeun naon éta. Sareng sigana sadayana parantos terang.
Gantina, kuring bakal ngabejaan Anjeun naon mungkin kasalahan aya, nyaeta, kumaha anjeun tiasa nganggo ClickHouse leres. Nyatana, teu kedah sieun, sabab kami nuju ngembangkeun ClickHouse salaku sistem anu sederhana, merenah, sareng jalan kaluar tina kotak. Kuring dipasang, teu aya masalah.
Tapi anjeun masih kedah tumut kana akun yén sistem ieu husus sarta anjeun bisa kalayan gampang manggihan hiji kasus pamakéan mahiwal nu bakal mawa sistem ieu kaluar tina zone kanyamanan na.
Janten, naon jinis rake anu aya? Kalolobaan kuring bakal ngobrol ngeunaan hal atra. Sadayana atra ka sadayana, sadayana ngartos sadayana sareng tiasa bungah yén aranjeunna pinter, sareng anu henteu ngartos bakal diajar anu énggal.
Conto kahiji jeung pangbasajanna, nu, hanjakalna, mindeng lumangsung, nyaeta angka nu gede ngarupakeun sisipan jeung bets leutik, i.e. jumlah badag inserts leutik.
Upami urang nganggap kumaha ClickHouse ngalaksanakeun sisipan, maka anjeun tiasa ngirim sahenteuna terabyte data dina hiji pamundut. Teu jadi masalah.
Jeung hayu urang tingali naon kinerja has. Contona, urang boga tabel tina data Yandex.Metrica. Hits. 105 sababaraha kolom. 700 bait teu dikomprés. Sarta kami bakal nyelapkeun dina cara alus dina bets hiji juta jajar.
Urang selapkeun MergeTree kana tabél, tétéla satengah juta jajar per detik. Hebat. Dina tabel replicated bakal saeutik leutik, kira 400 jajar per detik.
Tur upami Anjeun salah ngaktipkeun sisipan kuorum, anjeun meunang saeutik kirang, tapi tetep kinerja santun, 250 istilah per detik. sisipan kuorum mangrupa fitur undocumented di ClickHouse*.
* dina 2020, .
Naon kajadian lamun ngalakukeun hal goréng? Urang ngalebetkeun hiji baris kana tabel MergeTree tur meunangkeun 59 baris per detik. Éta 10 kali langkung laun. Dina ReplicatedMergeTree - 000 baris per detik. Sareng upami kuorum dihurungkeun, tétéla 6 garis per detik. Dina pamadegan mah, ieu téh sababaraha jenis crap mutlak. Kumaha anjeun tiasa ngalambatkeun sapertos kitu? Kuring malah geus ditulis dina kaos oblong mah ClickHouse teu kudu ngalambatkeun turun. Tapi sanajan kitu kadang kadang.
Nyatana, ieu mangrupikeun kakurangan urang. Urang bisa geus gampang nyieun sagalana jalan rupa, tapi urang teu. Sareng kami henteu ngalakukeunana sabab naskah kami henteu ngabutuhkeunana. Urang geus kungsi butches. Urang ngan narima bets di lawang kami, tur euweuh masalah. Urang selapkeun eta jeung sagalana jalan rupa. Tapi, tangtu, sagala sorts skenario anu mungkin. Contona, nalika anjeun gaduh kebat server on mana data dihasilkeun. Sareng aranjeunna henteu sering nyelapkeun data, tapi aranjeunna tetep sering nyelapkeun. Sareng urang kedah kumaha waé nyingkahan ieu.
Ti sudut pandang teknis, titik teh nya eta mun anjeun ngalakukeun hiji sisipan di ClickHouse, data teu mungkas nepi di memtable wae. Urang malah teu boga struktur log nyata MergeTree, tapi ngan hiji MergeTree, sabab teu aya log atawa memTable a. Urang ngan saukur langsung nulis data kana sistem file, geus disusun dina kolom. Sareng upami anjeun gaduh 100 kolom, langkung ti 200 file kedah diserat kana diréktori anu misah. Sadaya ieu pisan pajeulit.
Sareng patarosan timbul: "Kumaha carana ngalakukeun éta leres?" Upami kaayaan sapertos kitu anjeun masih kedah kumaha waé ngarékam data dina ClickHouse.
Métode 1. Ieu cara panggampangna. Paké sababaraha jenis antrian disebarkeun. Contona, Kafka. Anjeun ngan saukur nimba data tina Kafka sareng bets sakali sadetik. Jeung sagalana bakal rupa, Anjeun ngarekam, sagalana jalan rupa.
Kalemahanna nyaéta Kafka mangrupikeun sistem distribusi anu ageung. Abdi ogé ngartos upami anjeun parantos ngagaduhan Kafka di perusahaan anjeun. Ieu alus, éta merenah. Tapi lamun teu aya, mangka anjeun kudu mikir tilu kali saméméh nyered acan sistem disebarkeun sejen kana proyék Anjeun. Janten éta patut mertimbangkeun alternatif.
Métode 2. Ieu alternatif heubeul-sakola tur dina waktos anu sareng basajan pisan. Naha anjeun gaduh sababaraha jinis server anu ngahasilkeun log anjeun. Sareng éta ngan ukur nyerat log anjeun kana file. Sareng sakali sadetik, contona, urang ganti nami file ieu sareng ngahapus anu énggal. Sareng naskah anu misah, boh via cron atanapi sababaraha daemon, nyandak file pangkolotna sareng nyerat ka ClickHouse. Upami anjeun ngarékam log sakali sadetik, maka sadayana bakal saé.
Tapi karugian tina metodeu ieu nyaéta upami server anjeun dimana log dibangkitkeun ngaleungit dimana waé, maka datana ogé bakal ngaleungit.
Métode 3. Aya métode metot séjén, nu teu merlukeun file samentara pisan. Contona, Anjeun gaduh sababaraha jenis spinner iklan atawa sababaraha daemon metot séjén nu ngahasilkeun data. Sareng anjeun tiasa ngumpulkeun sakumpulan data langsung dina RAM, dina panyangga. Sareng nalika cekap waktos, anjeun nempatkeun panyangga ieu, jieun anu énggal, sareng dina benang anu misah, selapkeun naon anu parantos akumulasi kana ClickHouse.
Di sisi anu sanésna, data ogé ngaleungit kalayan maéhan -9. Lamun server anjeun ngadat, anjeun bakal leungit data ieu. Sareng masalah sanésna nyaéta upami anjeun henteu tiasa nyerat kana pangkalan data, maka data anjeun bakal ngumpulkeun dina RAM. Jeung boh RAM bakal béak, atawa anjeun ngan saukur bakal leungit data.
Métode 4. Métode metot séjén. Dupi anjeun gaduh sababaraha jenis prosés server. Sareng éta tiasa ngirim data ka ClickHouse langsung, tapi lakukeun dina hiji sambungan. Contona, kuring ngirim hiji pamundut http kalawan mindahkeun-encoding: chunked kalawan sisipan. Sarta eta dibangkitkeun sakumpulan teu teuing jarang, anjeun bisa ngirim unggal garis, sanajan bakal aya overhead pikeun framing data ieu.
Nanging, dina hal ieu data bakal langsung dikirim ka ClickHouse. Jeung ClickHouse bakal nyangga aranjeunna sorangan.
Tapi masalah ogé timbul. Ayeuna anjeun bakal kaleungitan data, kalebet nalika prosés anjeun tiwas sareng upami prosés ClickHouse dibunuh, sabab éta bakal janten sisipan anu teu lengkep. Sareng di sisipan ClickHouse mangrupikeun atom dugi ka ambang anu ditangtukeun dina ukuran barisan. Sacara prinsip, ieu cara metot. Ogé bisa dipaké.
Métode 5. Ieu métode metot séjén. Ieu mangrupikeun sababaraha jinis server anu dikembangkeun ku komunitas pikeun batching data. Abdi henteu acan ningali éta nyalira, janten kuring henteu tiasa ngajamin nanaon. Sanajan kitu, euweuh jaminan disadiakeun pikeun ClickHouse sorangan. Ieu ogé open source, tapi di sisi séjén, anjeun bisa dipaké pikeun sababaraha standar kualitas nu urang coba nyadiakeun. Tapi pikeun hal ieu - kuring henteu terang, angkat ka GitHub, tingali kodeu. Meureun maranéhna nulis hal normal.
* dina 2020, ogé kedah ditambah kana pertimbangan .
Métode 6. Métode séjén nyaéta ngagunakeun tabel panyangga. Kauntungannana metoda ieu nyaeta pisan gampang pikeun ngamimitian ngagunakeun. Jieun tabel panyangga terus selapkeun kana eta.
Nu disadvantage nya éta masalah teu sagemblengna direngsekeun. Upami, dina laju sapertos MergeTree, anjeun kedah ngagolongkeun data ku hiji bets per detik, teras dina laju dina tabel panyangga, anjeun kedah ngagolongkeun sahenteuna sababaraha rébu per detik. Lamun leuwih ti 10 per detik, éta bakal tetep goréng. Tur upami Anjeun salah nyelapkeun kana bets, mangka anjeun nempo yén tétéla saratus rébu garis per detik. Sareng ieu parantos aya dina data anu cukup beurat.
Sarta ogé tabel panyangga teu boga log a. Sareng upami aya anu lepat sareng server anjeun, maka datana bakal leungit.
Sareng salaku bonus, kami nembe ngagaduhan kasempetan di ClickHouse pikeun nyandak data ti Kafka. Aya mesin méja - Kafka. Anjeun saukur nyieun. Sareng anjeun tiasa ngagantungkeun répréséntasi materialisasi dina éta. Dina hal ieu, éta sorangan bakal nimba data tina Kafka teras selapkeun kana tabel anu anjeun peryogikeun.
Sareng anu paling pikaresepeun ngeunaan kasempetan ieu nyaéta sanés urang anu ngalakukeunana. Ieu mangrupikeun fitur komunitas. Sareng nalika kuring nyarios "fitur komunitas," hartosna kuring henteu ngahina. Kami maca kodeu, ngalakukeun ulasan, éta kedah dianggo saé.
* dina 2020, dukungan anu sami parantos muncul .
Naon deui anu tiasa ngaganggu atanapi teu kaduga nalika ngalebetkeun data? Upami anjeun ngadamel pamundut nilai sisipan sareng nyerat sababaraha ekspresi anu diitung dina nilai. Contona, ayeuna () ogé éksprési diitung. Sareng dina hal ieu, ClickHouse kapaksa ngaluncurkeun juru tina ungkapan ieu dina unggal garis, sareng pagelaran bakal turun ku pesenan ageungna. Éta hadé pikeun nyingkahan ieu.
* ayeuna, masalahna tos rengse direngsekeun, teu aya deui nu mana wae regression kinerja nalika ngagunakeun éksprési di VALUES.
Conto anu sanés nyaéta nalika aya sababaraha masalah nalika anjeun gaduh data dina hiji angkatan anu kalebet sakumpulan partisi. Sacara standar, partisi ClickHouse dumasar kana bulan. Sareng upami anjeun nyelapkeun sajuta jajar, sareng aya data salami sababaraha taun, maka anjeun bakal ngagaduhan sababaraha belasan partisi di dinya. Sareng ieu sami sareng kanyataan yén bakal aya bets sababaraha puluh kali langkung alit dina ukuran, sabab di jero aranjeunna sok dibagi kana partisi.
* Anyar-anyar ieu, dina modeu ékspérimén, ClickHouse nambihan dukungan pikeun format kompak sakumpulan sareng sakumpulan dina RAM sareng log nyerat payun, anu ampir lengkep ngarengsekeun masalah.
Ayeuna hayu urang nempo tipe kadua masalah - ketikan data.
Ngetik data tiasa ketat atanapi senar. String nyaéta nalika anjeun nembé nyandak sareng nyatakeun yén sadaya widang anjeun tina jinis string. Ieu lebay. Aya teu kudu ngalakukeun ieu.
Hayu urang angka kaluar kumaha carana ngalakukeun eta leres dina eta kasus lamun rék disebutkeun yen urang boga sababaraha widang, string a, sarta ngantep ClickHouse angka eta kaluar sorangan, sarta kuring moal ganggu. Tapi éta masih patut nyieun sababaraha usaha.
Contona, urang boga alamat IP. Dina hiji kasus, urang disimpen salaku string a. Contona, 192.168.1.1. Sareng dina kasus anu sanés, éta bakal janten sababaraha jinis UInt32 *. 32 bit cukup pikeun alamat IPv4.
Firstly, Oddly cukup, data bakal dikomprés kurang leuwih sarua. Bakal aya bédana, tangtosna, tapi teu nu badag. Janten henteu aya masalah khusus sareng disk I / O.
Tapi aya béda anu serius dina waktos prosésor sareng waktos palaksanaan pamundut.
Hayu urang cacah jumlah alamat IP unik lamun aranjeunna disimpen salaku angka. Éta tiasa dianggo pikeun 137 juta garis per detik. Upami sami dina bentuk senar, teras 37 juta garis per detik. Kuring henteu terang naha kabeneran ieu kajantenan. Kuring ngalaksanakeun pamundut ieu sorangan. Tapi tetep ngeunaan 4 kali leuwih laun.
Sareng upami anjeun ngitung bédana dina rohangan disk, maka aya ogé bédana. Jeung bédana ngeunaan hiji saparapat, sabab aya cukup loba alamat IP unik. Tur upami aya garis kalawan sajumlah leutik harti béda, maranéhna bakal gampang dikomprés nurutkeun kamus kana volume sarua.
Jeung opat kali bédana waktu teu bohong di jalan. Meureun anjeun teu masihan damn a, tangtosna, tapi lamun kuring ningali bédana misalna, éta ngajadikeun kuring sedih.
Hayu urang nempo kasus béda.
1. Hiji hal mun anjeun boga sababaraha nilai unik béda. Dina hal ieu, kami nganggo prakték saderhana anu sigana anjeun terang sareng tiasa dianggo pikeun DBMS naon waé. Ieu sadayana masuk akal henteu ngan ukur pikeun ClickHouse. Ngan nulis identifier numerik kana database. Sareng anjeun tiasa ngarobih kana senar sareng deui di sisi aplikasi anjeun.
Contona, anjeun boga wewengkon. Sareng anjeun nyobian nyimpen éta salaku senar. Sarta eta bakal ditulis aya: Moscow jeung Moscow Region. Sareng nalika kuring ningali yén éta nyarios "Moscow", teu aya nanaon, tapi nalika éta Moscow, kumaha waé janten hanjelu. Ieu sabaraha bait.
Gantina, urang ngan saukur nulis handap jumlah Ulnt32 na 250. Urang boga 250 di Yandex, tapi anjeun bisa jadi béda. Ngan bisi, abdi gé disebutkeun yen ClickHouse boga kamampuhan diwangun-di digawekeun ku geobase a. Anjeun ngan saukur nyerat diréktori sareng daérah, kalebet anu hierarkis, nyaéta bakal aya Moscow, Wilayah Moskow, sareng sadaya anu anjeun peryogikeun. Sareng anjeun tiasa ngarobih dina tingkat pamundut.
Pilihan kadua kirang langkung sami, tapi kalayan dukungan di jero ClickHouse. Ieu tipe data Enum. Anjeun ngan saukur nyerat sadaya nilai anu anjeun peryogikeun di jero Enum. Contona, jenis alat jeung nulis aya: desktop, mobile, tablet, TV. Aya 4 pilihan total.
Karugianna nyaéta anjeun kedah ngarobih périodik. Ngan hiji pilihan ditambahkeun. Hayu urang ngarobah tabel. Nyatana, ngarobih tabel di ClickHouse gratis. Utamana bébas pikeun Enum sabab data dina disk teu robah. Tapi sanajan kitu, alter acquires konci * dina tabel sarta kudu antosan nepi ka sadaya milih anu dieksekusi. Sarta ngan sanggeus robah ieu bakal dieksekusi, i.e. masih aya sababaraha inconveniences.
* dina versi panganyarna tina ClickHouse, ALTER dijieun sagemblengna non-blocking.
Pilihan séjén anu cukup unik pikeun ClickHouse nyaéta nyambungkeun kamus éksternal. Anjeun tiasa nyerat nomer dina ClickHouse, sareng ngajaga diréktori anjeun dina sistem naon waé anu cocog pikeun anjeun. Contona, anjeun tiasa nganggo: MySQL, Mongo, Postgres. Anjeun malah bisa nyieun microservice sorangan nu bakal ngirim data ieu via http. Sareng di tingkat ClickHouse, anjeun nyerat fungsi anu bakal ngarobih data ieu tina angka kana senar.
Ieu cara husus tapi pohara efisien pikeun ngalakukeun hiji gabung dina tabel éksternal. Sareng aya dua pilihan. Dina hiji perwujudan, data ieu bakal lengkep sindangan, pinuh hadir dina RAM jeung diropéa kalawan sababaraha frékuénsi. Sareng dina pilihan anu sanés, upami data ieu henteu pas kana RAM, anjeun tiasa sawaréh cache éta.
Ieu conto. Aya Yandex.Direct. Sareng aya perusahaan iklan sareng spanduk. Aya meureun ngeunaan puluhan juta pausahaan iklan. Sarta aranjeunna kasarna cocog kana RAM. Sareng aya milyaran spanduk, aranjeunna henteu pas. Sareng kami nganggo kamus sindangan tina MySQL.
Hiji-hijina masalah nyaéta kamus sindangan bakal tiasa dianggo saé upami laju pencét caket 100%. Upami éta langkung alit, teras nalika ngolah patarosan pikeun tiap angkatan data, anjeun leres-leres kedah nyandak konci anu leungit sareng kéngingkeun data tina MySQL. Ngeunaan ClickHouse, kuring masih tiasa ngajamin yén - enya, éta henteu ngalambatkeun, kuring moal ngobrol ngeunaan sistem anu sanés.
Sareng salaku bonus, kamus mangrupikeun cara anu gampang pikeun ngapdet data sacara retroaktif dina ClickHouse. Nyaéta, anjeun ngagaduhan laporan ngeunaan perusahaan pariwara, pangguna ngan ukur ngarobih perusahaan pariwara sareng dina sadaya data lami, dina sadaya laporan, data ieu ogé robih. Upami anjeun nyerat baris langsung kana tabél, mustahil pikeun ngapdet aranjeunna.
Cara anu sanés nalika anjeun henteu terang dimana kéngingkeun identifier pikeun senar anjeun. anjeun ngan saukur tiasa Hash eta. Leuwih ti éta, pilihan pangbasajanna nyaéta nyandak hash 64-bit.
Hiji-hijina masalah nyaéta upami Hashna 64-bit, maka anjeun ampir pasti bakal tabrakan. Kusabab upami aya samilyar garis di dinya, maka kamungkinanna parantos katingali.
Sareng éta henteu saé pisan pikeun ngabubarkeun nami perusahaan pariwara ku cara ieu. Upami kampanye iklan perusahaan anu béda-béda dicampur, maka bakal aya anu teu kaharti.
Tur aya hiji trik basajan. Leres, éta ogé henteu cocog pisan pikeun data anu serius, tapi upami aya anu henteu serius, teras tambahkeun identifier klien kana konci kamus. Lajeng anjeun bakal boga tabrakan, tapi ngan dina hiji klien. Sareng kami nganggo metode ieu pikeun peta tautan dina Yandex.Metrica. Simkuring gaduh URL aya, urang nyimpen hashes. Sareng urang terang yén, tangtosna, aya tabrakan. Tapi nalika kaca dipintonkeun, kamungkinan yén dina hiji halaman hiji pamaké sababaraha URL nyangkut babarengan jeung ieu bakal noticed bisa neglected.
Salaku bonus, pikeun seueur operasi hashes waé cekap sareng senarna nyalira henteu kedah disimpen dimana waé.
conto sejen nyaeta lamun string anu pondok, contona, domain ramatloka. Éta bisa disimpen sakumaha anu kasebut. Atanapi, contona, ru basa browser nyaéta 2 bait. Tangtu, kuring bener ngarasa punten pikeun bait, tapi ulah salempang, 2 bait teu karunya. Punten jaga kumaha, tong hariwang.
Kasus anu sanés nyaéta nalika, sabalikna, aya seueur garis sareng seueur anu unik dina aranjeunna, bahkan setna berpotensi henteu terbatas. Hiji conto has nyaeta frasa pilarian atawa URL. Frasa pilarian, kaasup typo. Hayu urang tingali sabaraha frase pilarian unik aya per poé. Sareng tétéla yén aranjeunna ampir satengah sadaya kajadian. Sareng dina hal ieu, anjeun panginten panginten anjeun kedah nganormalkeun data, ngitung idéntitas, teras nahan kana méja anu misah. Tapi anjeun henteu kedah ngalakukeun éta. Ngan tetep garis ieu sakumaha aranjeunna.
Hadé pisan mun éta teu invent nanaon, sabab lamun nyimpen eta misah, anjeun bakal kedah do a gabung. Sareng gabung ieu, paling saé, aksés acak kana mémori, upami éta masih pas dina mémori. Upami éta henteu pas, maka bakal aya masalah.
Sareng upami data disimpen dina tempatna, maka éta ngan ukur dibaca dina urutan anu diperyogikeun tina sistem file sareng sadayana saé.
Upami anjeun gaduh URL atanapi sababaraha senar panjang anu kompleks, maka éta patut mertimbangkeun yén anjeun tiasa ngitung sababaraha jinis ekstrak sateuacanna sareng nyerat dina kolom anu misah.
Pikeun URL, contona, anjeun tiasa nyimpen domain nyalira. Sareng upami anjeun leres-leres peryogi domain, teras nganggo kolom ieu, sareng URLna bakal aya, sareng anjeun moal nyabak aranjeunna.
Hayu urang tingali naon bédana. ClickHouse ngagaduhan fungsi khusus anu ngitung domain. Éta gancang pisan, kami parantos ngaoptimalkeunana. Sareng, jujur, éta henteu saluyu sareng RFC, tapi éta ogé ngemutan sadayana anu urang peryogikeun.
Sareng dina hiji hal urang ngan saukur bakal nampi URL sareng ngitung domain. Éta tiasa dianggo dugi ka 166 milidetik. Sareng upami anjeun nyandak domain anu siap-siap, tétéla ngan ukur 67 milliseconds, nyaéta ampir tilu kali langkung gancang. Tur éta gancang teu sabab urang kudu ngalakukeun sababaraha itungan, tapi kusabab urang maca data kirang.
Éta pisan sababna naha hiji pamundut, nu leuwih laun, boga speed luhur gigabytes per detik. Sabab maca leuwih gigabyte. Ieu data lengkep teu perlu. Paménta sigana ngajalankeun langkung gancang, tapi peryogi langkung lami kanggo réngsé.
Tur upami Anjeun salah nempo jumlah data dina disk, tétéla yén URL 126 megabytes, sarta domain ngan 5 megabytes. Tétéla 25 kali kirang. Tapi sanajan kitu, pamundut dieksekusi ngan 4 kali leuwih gancang. Tapi éta kusabab datana panas. Tur upami éta tiis, éta meureun bakal 25 kali leuwih gancang alatan disk I / O.
Ngomong-ngomong, upami anjeun ngira-ngira sabaraha langkung alit domain tibatan URL, tétéla janten langkung alit 4. Tapi pikeun sababaraha alesan, data nyandak 25 kali kirang dina disk. Naha? Alatan komprési. Sareng URL dikomprés, sareng domain dikomprés. Tapi mindeng URL ngandung kebat sampah.
Sareng, tangtosna, éta mayar nganggo jinis data anu leres anu dirarancang khusus pikeun nilai anu dipikahoyong atanapi anu cocog. Upami anjeun dina IPv4, teras simpen UInt32*. Upami IPv6, teras FixedString (16), sabab alamat IPv6 nyaéta 128 bit, nyaéta disimpen langsung dina format binér.
Tapi kumaha upami anjeun kadang gaduh alamat IPv4 sareng kadang IPv6? Leres, anjeun tiasa nyimpen duanana. Hiji kolom pikeun IPv4, hiji deui pikeun IPv6. Tangtosna, aya pilihan pikeun nampilkeun IPv4 dina IPv6. Ieu ogé bakal tiasa dianggo, tapi upami anjeun sering peryogi alamat IPv4 dina pamundut, maka bakal langkung saé nempatkeun éta dina kolom anu misah.
* ClickHouse kiwari boga IPv4 misah, IPv6 tipe data nu nyimpen data sakumaha éfisién salaku angka, tapi ngagambarkeun aranjeunna salaku merenah sakumaha string.
Éta ogé penting pikeun dicatet yén éta patut preprocessing data sateuacanna. Contona, anjeun nampi sababaraha log atah. Sarta meureun anjeun teu kudu ngan nempatkeun aranjeunna dina ClickHouse katuhu jauh, sanajan éta pisan pikabitaeun pikeun ngalakukeun nanaon jeung sagalana bakal jalan. Tapi masih patut ngalaksanakeun itungan anu mungkin.
Contona, versi browser. Dina sababaraha departemén caket dieu, anu kuring henteu hoyong nunjuk ramo, versi browser disimpen sapertos kieu, nyaéta, salaku senar: 12.3. Teras, pikeun ngadamel laporan, aranjeunna nyandak senar ieu sareng ngabagi kana hiji Asép Sunandar Sunarya, teras kana unsur kahiji tina Asép Sunandar Sunarya. Alami, sagalana slows turun. Kuring nanya naha maranéhna ngalakukeun ieu. Aranjeunna ngawartoskeun kuring yén maranéhna teu resep optimasi prématur. Sareng kuring henteu resep pessimization prématur.
Ku kituna dina hal ieu bakal leuwih bener mun ngabagi kana 4 kolom. Tong sieun di dieu, sabab ieu ClickHouse. ClickHouse nyaéta database columnar. Jeung kolom saeutik leuwih rapih, nu hadé. Bakal aya 5 BrowserVersi, ngadamel 5 kolom. Ieu sae.
Ayeuna hayu urang tingali naon anu kudu dilakukeun upami anjeun gaduh seueur senar anu panjang pisan, susunan anu panjang pisan. Éta henteu kedah disimpen di ClickHouse pisan. Gantina, anjeun ngan bisa nyimpen hiji identifier di ClickHouse. Sareng nempatkeun garis panjang ieu kana sababaraha sistem anu sanés.
Salaku conto, salah sahiji jasa analitik kami ngagaduhan sababaraha parameter acara. Sareng upami aya seueur parameter pikeun acara, urang ngan ukur ngahémat 512 anu munggaran dipanggihan. Kusabab 512 henteu karunya.
Sareng upami anjeun henteu tiasa mutuskeun jinis data anjeun, anjeun ogé tiasa ngarékam data dina ClickHouse, tapi dina méja samentawis jinis Log, khusus pikeun data samentawis. Saatos ieu, anjeun tiasa nganalisis distribusi nilai naon anu anjeun gaduh, naon anu aya sacara umum, sareng nyiptakeun jinis anu leres.
*ClickHouse ayeuna gaduh jinis data nu ngidinan Anjeun pikeun nyimpen string éfisién kalawan kirang usaha .
Ayeuna hayu urang nempo kasus metot séjén. Kadang-kadang hal dianggo aneh pikeun jalma. Kuring asup tur ningali ieu. Sarta eta langsung sigana nu ieu dipigawé ku sababaraha pisan ngalaman, admin pinter anu boga pangalaman éksténsif dina nyetel MySQL versi 3.23.
Di dieu urang ningali sarébu tabel, nu masing-masing rékaman sésana ngabagi anu weruh naon ku sarébu.
Sacara prinsip, kuring ngahargaan pangalaman batur, kaasup pamahaman sangsara anu bisa dimeunangkeun ngaliwatan pangalaman ieu.
Jeung alesan nu leuwih atawa kurang jelas. Ieu stereotypes heubeul nu mungkin geus akumulasi bari gawé bareng sistem lianna. Contona, tabel MyISAM teu boga konci primér clustered. Sareng cara ngabagi data ieu tiasa janten usaha nekat pikeun kéngingkeun fungsionalitas anu sami.
Alesan sejen nyaeta hese ngalakukeun sagala operasi ngarobah dina tabel badag. Sagalana bakal diblokir. Sanajan dina versi modérn MySQL masalah ieu geus euweuh jadi serius.
Atanapi, contona, microsharding, tapi langkung seueur ngeunaan éta engké.
Teu perlu ngalakukeun ieu di ClickHouse, sabab, firstly, konci primér clustered, data ieu maréntahkeun ku konci primér.
Sarta kadangkala jalma nanya ka kuring: "Kumaha kinerja queries rentang di ClickHouse rupa-rupa gumantung kana ukuran méja?" Kuring nyebutkeun teu robah pisan. Salaku conto, anjeun gaduh méja kalayan samilyar jajar sareng anjeun maca sauntuyan sajuta jajar. Sagalana geus rupa. Upami aya samilyar jajar dina méja sareng anjeun maca sajuta jajar, éta bakal ampir sami.
Sareng, kadua, sagala jinis hal sapertos partisi manual henteu diperyogikeun. Upami anjeun lebet sareng ningali naon anu aya dina sistem file, anjeun bakal ningali yén méja éta lumayan ageung. Sareng aya anu sapertos partisi di jero. Hartina, ClickHouse ngalakukeun sagalana pikeun anjeun sarta anjeun teu kudu sangsara.
Ngarobah di ClickHouse gratis upami ngarobih kolom tambihan / serelek.
Jeung anjeun teu kudu nyieun tabel leutik, sabab lamun boga 10 jajar atawa 10 jajar dina tabel, mangka teu masalah pisan. ClickHouse mangrupikeun sistem anu ngaoptimalkeun throughput, sanés latency, janten teu aya akal pikeun ngolah 000 garis.
Éta leres ngagunakeun hiji méja ageung. Leupaskeun stereotypes heubeul, sagalana bakal rupa.
Sareng salaku bonus, dina versi panganyarna kami ayeuna gaduh kamampuan nyiptakeun konci partisi sawenang pikeun ngalaksanakeun sagala jinis operasi pangropéa dina partisi individu.
Salaku conto, anjeun peryogi seueur tabel leutik, contona, nalika aya anu peryogi pikeun ngolah sababaraha data panengah, anjeun nampi sakumpulan sareng anjeun kedah ngalakukeun transformasi sateuacan nyerat kana tabel akhir. Pikeun hal ieu, aya mesin tabel éndah - StripeLog. Éta sapertos TinyLog, ngan langkung saé.
* ayeuna ClickHouse ogé boga .
Antipattern séjén nyaéta microsharding. Contona, Anjeun kudu beling data jeung anjeun boga 5 server, jeung isukan bakal aya 6 server. Sareng anjeun mikir ngeunaan kumaha carana ngimbangan deui data ieu. Jeung gantina anjeun megatkeun teu kana 5 shards, tapi kana 1 shards. Lajeng anjeun peta unggal microshards ieu ka server misah. Sareng anjeun bakal kéngingkeun, contona, 000 ClickHouses dina hiji server, contona. instansi misah on palabuhan misah atawa database misah.
Tapi ieu teu pisan alus di ClickHouse. Kusabab sanajan hiji conto ClickHouse nyoba ngagunakeun sagala sumberdaya server sadia pikeun ngolah hiji pamundut. Nyaéta, anjeun gaduh sababaraha jinis server sareng ngagaduhan, contona, 56 inti prosesor. Anjeun ngajalankeun pamundut anu butuh sadetik sareng bakal nganggo 56 intina. Sareng upami anjeun nempatkeun 200 ClickHouses dina hiji server, tétéla 10 benang bakal ngamimitian. Sacara umum, sagalana bakal pisan goréng.
Alesan anu sanésna nyaéta distribusi padamelan dina kasus ieu bakal henteu rata. Sababaraha bakal rengse saméméhna, sababaraha bakal rengse engké. Upami sadayana ieu kajantenan dina hiji conto, maka ClickHouse nyalira bakal terang kumaha leres ngadistribusikaeun data diantara benang.
Jeung alesan sejen nyaeta anjeun bakal boga komunikasi interprocessor via TCP. Datana kedah sérial, deserialized, sareng ieu sajumlah ageung microshards. Ieu ngan saukur moal jalan éféktif.
Antipattern sejen, sanajan boro bisa disebut antipattern. Ieu jumlah badag pre-aggregation.
Sacara umum, pre-aggregation téh alus. Anjeun gaduh samilyar jajar, anjeun agrégat éta sareng janten 1 jajar, sareng ayeuna pamundut dieksekusi langsung. Sagalana hébat. Anjeun tiasa ngalakukeun ieu. Sareng ieu, malah ClickHouse ngagaduhan jinis méja khusus, AggregatingMergeTree, anu ngalaksanakeun agrégasi Incremental nalika data diselapkeun.
Tapi aya waktos nalika anjeun mikir yén kami bakal ngumpulkeun data sapertos kieu sareng data agrégat sapertos kieu. Sarta di sababaraha departemén tatangga, Kuring ogé teu hayang ngomong nu mana, aranjeunna nganggo SummingMergeTree tabel pikeun nyimpulkeun ku konci primér, sarta ngeunaan 20 kolom dipaké salaku konci primér. Bisi wae, kuring ngaganti ngaran sababaraha kolom pikeun rasiah, tapi éta lumayan loba.
Jeung masalah sapertos timbul. Firstly, volume data anjeun teu ngurangan teuing. Contona, turun ku tilu kali. Tilu kali bakal janten harga anu saé pikeun nanggung kamampuan analitik anu henteu terbatas anu timbul upami data anjeun henteu dihijikeun. Lamun data ieu aggregated, lajeng tinimbang analytics anjeun meunang ukur statistik pikasieuneun.
Jeung naon husus ngeunaan eta? Kanyataan yén jalma ieu ti departemén tatangga kadang balik sarta ménta pikeun nambahkeun kolom sejen ka konci primér. Hartina, urang aggregated data kawas ieu, tapi ayeuna urang hayang saeutik leuwih. Tapi ClickHouse teu gaduh konci primér alter. Kituna, urang kudu nulis sababaraha Aksara dina C ++. Na kuring teu resep Aksara, sanajan aranjeunna dina C ++.
Tur upami Anjeun salah nempo naon ClickHouse dijieun pikeun, lajeng data non-aggregated persis skenario nu eta dilahirkeun. Upami anjeun nganggo ClickHouse pikeun data anu henteu dikelompokeun, maka anjeun leres-leres ngalakukeunana. Lamun agrégat, ieu kadang forgivable.
Kasus metot séjén nyaéta queries dina loop taya wates. Sakapeung kuring angkat ka sababaraha server produksi sareng ningali daptar prosés acara di dinya. Sareng unggal waktos kuring mendakan yén aya kajadian anu dahsyat.
Contona, kawas kieu. Langsung écés yén sadayana tiasa dilakukeun dina hiji pamundut. Tulis url sareng daptar di dinya.
Naha seueur patarosan sapertos kitu dina loop anu henteu terbatas? Upami indéks henteu dianggo, maka anjeun bakal ngagaduhan seueur pas dina data anu sami. Tapi lamun indéks dipaké, contona, anjeun boga konci primér pikeun ru jeung anjeun nulis url = hal aya. Sareng anjeun mikir yén upami ngan ukur hiji URL dibaca tina méja, sadayana bakal saé. Tapi sabenerna euweuh. Kusabab ClickHouse ngalakukeun sagalana dina bets.
Nalika anjeunna kedah maca sauntuyan data anu tangtu, anjeunna maca sakedik deui, sabab indéks dina ClickHouse jarang. indéks ieu teu ngidinan Anjeun pikeun manggihan hiji baris individu dina tabél, ngan sauntuyan sababaraha jenis. Sareng datana dikomprés dina blok. Dina raraga maca hiji baris, Anjeun kudu nyokot sakabeh blok jeung unclench eta. Tur upami Anjeun salah ngalakukeun kebat tina queries, anjeun bakal boga loba tumpang tindihna, tur anjeun bakal boga loba karya pikeun ngalakukeun leuwih sarta leuwih deui.
Sareng salaku bonus, anjeun tiasa dicatet yén dina ClickHouse anjeun henteu kedah sieun pikeun mindahkeun megabytes bahkan ratusan megabyte ka bagian IN. Abdi émut tina prakték urang yén upami dina MySQL urang mindahkeun sakumpulan nilai ka bagian IN, contona, urang mindahkeun 100 megabyte sababaraha nomer di dinya, teras MySQL ngahakan mémori 10 gigabyte sareng teu aya anu sanés kajadian, sadayana. jalan goréng.
Sareng anu kadua nyaéta yén dina ClickHouse, upami patarosan anjeun nganggo indéks, teras éta henteu langkung laun tibatan scan pinuh, nyaéta upami anjeun kedah maca ampir sadayana méja, éta bakal sacara berurutan sareng maca sadayana méja. Sacara umum, anjeunna bakal terang éta nyalira.
Tapi sanajan kitu aya sababaraha kasusah. Salaku conto, kanyataan yén IN sareng subquery henteu nganggo indéks. Tapi ieu masalah urang jeung urang kudu ngalereskeun eta. Aya nanaon fundamental di dieu. Urang ngalereskeun eta*.
Sareng hal anu pikaresepeun nyaéta upami anjeun gaduh pamundut anu panjang sareng pamrosésan pamundut anu disebarkeun, teras pamundut anu panjang pisan ieu bakal dikirim ka unggal server tanpa komprési. Contona, 100 megabytes jeung 500 server. Sareng, sasuai, anjeun bakal ngagaduhan 50 gigabytes ditransfer kana jaringan. Ieu bakal dikirimkeun lajeng sagalana bakal réngsé junun.
* geus maké; Sagalana dibereskeun sakumaha jangji.
Sareng kasus anu cukup umum nyaéta nalika pamundut asalna tina API. Salaku conto, anjeun nyiptakeun sababaraha jinis jasa anjeun nyalira. Sareng upami aya anu peryogi jasa anjeun, maka anjeun muka API sareng sacara harfiah dua dinten saatos anjeun ningali yén aya kajadian anu teu kaharti. Sagalana geus overloaded sarta sababaraha requests dahsyat datang dina anu sakuduna pernah kajadian.
Tur aya ngan hiji solusi. Upami anjeun parantos muka API, maka anjeun kedah motong éta. Contona, ngawanohkeun sababaraha jenis kuota. Henteu aya pilihan normal anu sanés. Upami teu kitu, aranjeunna bakal langsung nyerat naskah sareng bakal aya masalah.
Jeung ClickHouse boga fitur husus - quota calculation. Leuwih ti éta, Anjeun bisa mindahkeun konci kuota Anjeun. Ieu, contona, ID pamaké internal. Sareng kuota bakal diitung sacara mandiri pikeun masing-masing.
Ayeuna hal metot séjén. Ieu réplikasi manual.
Kuring nyaho loba kasus dimana, sanajan ClickHouse ngabogaan diwangun-di rojongan réplikasi, jalma ngayakeun réplikasi ClickHouse sacara manual.
Naon prinsipna? Anjeun gaduh pipa ngolah data. Sareng tiasa dianggo sacara mandiri, contona, dina pusat data anu béda. Anjeun nyerat data anu sami dina cara anu sami dina ClickHouse. Leres, prakna nunjukkeun yén data masih bakal diverge kusabab sababaraha fitur dina kode anjeun. Kuring miharep éta dina anjeun.
Sareng ti waktos ka waktos anjeun masih kedah nyingkronkeun sacara manual. Contona, sabulan sakali admins ngalakukeun rsync.
Kanyataanna, éta loba gampang ngagunakeun réplikasi diwangun kana ClickHouse. Tapi meureun aya sababaraha contraindications, sabab pikeun ieu anjeun kedah nganggo ZooKeeper. Kuring moal ngomong nanaon goréng ngeunaan ZooKeeper, prinsipna mah, sistem jalan, tapi kajadian nu urang teu make eta kusabab java-phobia, sabab ClickHouse nyaéta sistem alus sapertos, ditulis dina C ++, nu bisa Anjeun pake na sagalana bakal alus. Sareng ZooKeeper aya dina java. Sareng kumaha waé anjeun henteu hoyong ningali, tapi teras anjeun tiasa nganggo réplikasi manual.
ClickHouse nyaéta sistem praktis. Manehna nyokot kana akun kabutuhan Anjeun. Upami Anjeun gaduh réplikasi manual, mangka anjeun bisa nyieun tabel Distribusi nu kasampak di réplika manual anjeun sarta ngalakukeun failover antara aranjeunna. Sareng aya pilihan khusus anu ngamungkinkeun anjeun ngahindarkeun flops, sanaos garis anjeun sacara sistematis diverge.
Masalah salajengna tiasa timbul upami anjeun nganggo mesin tabel primitif. ClickHouse mangrupakeun constructor nu boga kebat mesin tabel béda. Pikeun sakabéh kasus serius, sakumaha ditulis dina dokuméntasi, ngagunakeun tabel ti kulawarga MergeTree. Sarta sakabeh sésana - ieu téh jadi, pikeun kasus individu atawa pikeun tés.
Dina tabel MergeTree, anjeun teu kedah gaduh tanggal sareng waktos. Anjeun masih bisa make eta. Upami teu aya tanggal sareng waktos, tuliskeun standarna nyaéta 2000. Ieu bakal dianggo tur moal merlukeun sumberdaya.
Sarta dina versi anyar tina server, anjeun malah bisa nangtukeun yén anjeun boga partisi custom tanpa konci partisi. Ieu bakal sarua.
Di sisi séjén, anjeun tiasa nganggo mesin tabel primitif. Contona, eusian data sakali tur tingal, pulas jeung ngahapus. Anjeun tiasa nganggo Log.
Atawa nyimpen jilid leutik pikeun ngolah panengah nyaéta StripeLog atanapi TinyLog.
Mémori tiasa dianggo upami jumlah datana alit sareng anjeun ngan saukur tiasa nga-twiddle hal dina RAM.
ClickHouse henteu resep data anu dinormalisasi deui.
Ieu conto anu biasa. Ieu sajumlah ageung URL. Anjeun nempatkeun aranjeunna dina tabel salajengna. Teras we mutuskeun pikeun ngalakukeun JOIN sareng maranehna, tapi ieu moal jalan, sakumaha aturan, sabab ClickHouse ngan ngarojong Hash JOIN. Mun aya teu cukup RAM pikeun loba data nu kudu disambungkeun, lajeng JOIN moal jalan *.
Lamun data nyaeta tina cardinality tinggi, teras ulah salempang, nyimpen eta dina formulir denormalized, URL nu langsung di tempat dina tabel utama.
* tur kiwari ClickHouse ogé mangrupa gabung gabung, sarta gawéna dina kondisi dimana data panengah teu cocog kana RAM. Tapi ieu teu epektip sareng rekomendasi tetep dikuatkeun.
Sababaraha conto deui, tapi kuring parantos ragu naha aranjeunna anti pola atanapi henteu.
ClickHouse boga hiji cacad dipikawanoh. Éta henteu terang kumaha ngapdet *. Dina sababaraha hal, ieu malah alus. Upami anjeun gaduh sababaraha data penting, contona, akuntansi, maka moal aya anu tiasa ngirimkeunana, sabab teu aya apdet.
* Pangrojong pikeun ngamutahirkeun sareng ngahapus dina modeu angkatan parantos parantos lami parantos lami.
Tapi aya sababaraha cara khusus anu ngamungkinkeun apdet saolah-olah di latar tukang. Contona, tabel kawas ReplaceMergeTree. Aranjeunna nyieun apdet salila merges latar. Anjeun tiasa maksakeun ieu nganggo tabel ngaoptimalkeun. Tapi ulah sering teuing, sabab bakal nimpa partisi.
Disebarkeun JOINs di ClickHouse ogé kirang diatur ku Nu Ngarencana query.
Goréng, tapi kadang Ok.
Ngagunakeun ClickHouse ngan pikeun maca data deui ngagunakeun pilih *.
Abdi teu bakal nyarankeun ngagunakeun ClickHouse pikeun itungan pajeujeut. Tapi ieu teu sagemblengna bener, sabab urang geus pindah jauh ti rekomendasi ieu. Sareng kami nembe nambihan kamampuan pikeun nerapkeun modél pembelajaran mesin di ClickHouse - Catboost. Sarta eta bothers kuring sabab kuring mikir, "Naon horor. Ieu sabaraha siklus per bait tétéla! Nyaan hate wasting jam on bait.
Tapi ulah sieun, install ClickHouse, sagalana bakal rupa. Upami aya, urang gaduh komunitas. Ku jalan kitu, komunitas nyaéta anjeun. Sareng upami anjeun ngagaduhan masalah, anjeun sahenteuna tiasa angkat ka obrolan kami, sareng mugia aranjeunna tiasa ngabantosan anjeun.
patarosan
Hatur nuhun laporan! Dimana abdi tiasa ngawadul ngeunaan ClickHouse nabrak?
Anjeun tiasa ngawadul ka kuring pribadi ayeuna.
Kuring nembe dimimitian maké ClickHouse. Kuring geuwat leupaskeun panganteur cli.
Naon skor.
A saeutik engké kuring nabrak server kalawan pilih leutik.
Anjeun boga bakat.
Kuring muka bug GitHub, tapi teu dipaliré.
Hayu urang tingali.
Alexey tricked kuring kana attending laporan, ngajangjikeun ngabejaan kuring kumaha anjeun ngakses data di jero.
Basajan pisan.
Kuring sadar ieu kamari. Langkung spésifikna.
Aya henteu trik dahsyat aya. Ngan aya komprési blok-demi-blok. Standarna nyaéta LZ4, anjeun tiasa ngaktipkeun ZSTD *. Blok tina 64 kilobyte dugi ka 1 megabyte.
* Aya ogé dukungan pikeun codec komprési khusus anu tiasa dianggo dina ranté sareng algoritma anu sanés.
Naha blokna ngan ukur data atah?
Henteu lengkep atah. Aya susunan. Upami Anjeun gaduh kolom numerik, lajeng angka dina baris disimpen dina Asép Sunandar Sunarya.
Éta jelas.
Alexey, conto anu mibanda uniqExact leuwih IP, nyaéta kanyataan yén uniqExact nyokot leuwih lila pikeun ngitung ku garis ti angka, jeung saterusna. Kumaha lamun urang ngagunakeun feint kalawan Ceuli urang jeung tuang dina waktu proofreading? Nyaéta, sigana anjeun nyarios yén dina disk urang henteu béda pisan. Upami urang maca garis tina disk sareng tuang, agrégat urang bakal langkung gancang atanapi henteu? Atawa bakal urang masih meunang rada di dieu? Sigana mah nu diuji ieu, tapi pikeun sababaraha alesan teu nunjukkeun eta dina patokan.
Jigana bakal leuwih laun ti tanpa casting. Dina hal ieu, alamat IP kudu parsed tina string. Tangtosna, di ClickHouse, parsing alamat IP urang ogé dioptimalkeun. Urang diusahakeun pisan teuas, tapi aya nu boga angka ditulis dina formulir sapuluh rébu. Keuheul pisan. Di sisi anu sanésna, fungsi uniqExact bakal dianggo langkung laun dina senar, henteu ngan kusabab ieu senar, tapi ogé kusabab spesialisasi algoritma anu béda dipilih. String ngan saukur diolah béda.
Kumaha upami urang nyandak jinis data anu langkung primitif? Contona, urang nulis handap id pamaké, nu urang kudu di, wrote eta handap salaku garis, lajeng scrambled eta, bakal leuwih senang atawa henteu?
Abdi cangcaya. Jigana bakal malah sadder, sabab sanggeus kabeh, angka parsing masalah serius. Sigana mah batur sapagawean ieu malah masihan laporan ngeunaan kumaha hésé éta parse angka dina formulir sapuluh rébu, tapi meureun moal.
Alexey, hatur nuhun pisan pikeun laporan! Sareng hatur nuhun pisan pikeun ClickHouse! Abdi gaduh patarosan ngeunaan rencana. Naha aya rencana pikeun fitur pikeun ngapdet kamus sacara teu lengkep?
Maksudna, reboot parsial?
Enya enya. Kawas kamampuhan pikeun nyetel hiji widang MySQL aya, nyaéta update sanggeus jadi ngan data ieu dimuat lamun kamus téh kacida gedéna.
Hiji fitur pisan metot. Sareng kuring pikir sababaraha jalma nyarankeun dina obrolan urang. Meureun éta malah anjeun.
Teu sangka.
Hebat, ayeuna tétéla aya dua pamundut. Sareng anjeun lalaunan tiasa ngamimitian ngalakukeunana. Tapi Abdi hoyong ngingetkeun anjeun langsung yén fitur ieu cukup basajan pikeun nerapkeun. Hartina, dina téori, anjeun ngan perlu nulis nomer versi dina tabél lajeng nulis: versi kirang ti kitu jeung kitu. Ieu ngandung harti yén, paling dipikaresep, kami bakal nawiskeun ieu ka peminat. Anjeun hiji enthusiast?
Sumuhun, tapi, hanjakalna, teu di C ++.
Naha kolega anjeun terang kumaha nyerat dina C ++?
Abdi bakal mendakan batur.
Hebat*.
* fitur ieu ditambahkeun dua bulan sanggeus laporan - panulis patarosan dimekarkeun sarta dikirim na .
Hatur nuhun!
Halo! Hatur nuhun laporan! Anjeun disebutkeun yen ClickHouse pohara alus dina consuming sagala sumberdaya sadia pikeun eta. Jeung spiker gigireun Luxoft dikaitkeun kana solusi na pikeun Rusia Post. Anjeunna nyarios yén aranjeunna leres-leres resep ClickHouse, tapi aranjeunna henteu nganggo éta tibatan pesaing utamana kusabab éta ngahakan sadayana CPU. Sareng aranjeunna henteu tiasa nyolok kana arsitékturna, kana ZooKeeper sareng dockers. Naha mungkin kumaha waé ngawatesan ClickHouse supados henteu meakeun sadayana anu sayogi?
Sumuhun, éta mungkin tur pisan gampang. Lamun hayang meakeun cores pangsaeutikna, lajeng ngan nulis set max_threads = 1. Sareng éta, éta bakal ngalaksanakeun pamundut dina hiji inti. Leuwih ti éta, anjeun bisa nangtukeun setélan béda pikeun pamaké béda. Jadi euweuh masalah. Sarta ngabejaan kolega anjeun ti Luxoft yén éta teu alus yén maranéhna teu manggihan setelan ieu dina dokuméntasi.
Alexey, halo! Abdi hoyong naroskeun ngeunaan patarosan ieu. Ieu sanés pertama kalina kuring nguping yén seueur jalma anu ngamimitian nganggo ClickHouse salaku neundeun log. Dina laporan anjeun nyarios teu ngalakukeun ieu, nyaéta anjeun teu kedah nyimpen senar panjang. Kumaha saur anjeun ngeunaan éta?
Firstly, log téh, sakumaha aturan, teu string panjang. Aya, tangtosna, pengecualian. Contona, sababaraha layanan ditulis dina java throws iwal, eta geus asup. Jeung saterusna dina loop sajajalan, sarta spasi dina hard drive ngalir kaluar. Leyuran basajan pisan. Upami garisna panjang pisan, teras potong. Naon hartina panjang? Puluhan kilobyte parah*.
* dina versi panganyarna tina ClickHouse, "indéks granularity adaptif" diaktipkeun, nu eliminates masalah nyimpen baris panjang keur bagian paling.
Naha kilobyte normal?
Normal.
Halo! Hatur nuhun laporan! Kuring parantos naroskeun perkawis ieu dina obrolan, tapi kuring henteu émut upami kuring nampi jawaban. Naha aya rencana pikeun kumaha waé ngalegaan bagian WITH ku cara CTE?
Henteu acan. Bagian WITH kami rada sembrono. Ieu kawas fitur saeutik pikeun urang.
Abdi ngartos. Hatur nuhun!
Hatur nuhun laporan! Pisan metot! Patarosan global. Naha aya rencana pikeun ngarobih ngahapus data, sigana dina bentuk sababaraha jenis rintisan?
kuduna. Ieu tugas munggaran urang dina antrian urang. Urang ayeuna aktip mikir ngeunaan kumaha carana ngalakukeun sagalana bener. Sareng anjeun kedah ngamimitian mencét keyboard *.
* mencét tombol dina keyboard sareng ngalakukeun sadayana.
Naha ieu bakal mangaruhan kinerja sistem atanapi henteu? Naha sisipan bakal gancang sapertos ayeuna?
Panginten ngahapus sorangan sareng pembaruan nyalira bakal beurat pisan, tapi ieu moal mangaruhan kinerja seleksi atanapi kinerja sisipan.
Sareng hiji deui patarosan leutik. Dina presentasi anjeun ngobrol ngeunaan konci primér. Sasuai, urang gaduh partisi, anu bulanan sacara standar, leres? Sareng nalika urang nyetél rentang tanggal anu pas kana sabulan, teras ngan ukur partisi ieu dibaca, leres?
Sumuhun.
Hiji patarosan. Upami urang henteu tiasa milih konci primér, naha éta leres pikeun ngalakukeunana sacara khusus dumasar kana kolom "Tanggal" supados di latar tukang aya kirang nyusun ulang data ieu supados pas dina cara anu langkung teratur? Upami anjeun teu gaduh patarosan rentang sareng anjeun henteu tiasa milih konci primér naon waé, naha éta patut nempatkeun tanggal dina konci primér?
Sumuhun.
Panginten masuk akal pikeun nempatkeun sawah dina konci primér anu bakal niiskeun data langkung saé upami diurutkeun ku widang ieu. Contona, ID pamaké. Pamaké, contona, angkat ka situs anu sami. Dina hal ieu, nempatkeun id pamaké sarta waktu. Lajeng data anjeun bakal hadé dikomprés. Sedengkeun pikeun tanggal, upami anjeun leres-leres teu gaduh sareng henteu kantos gaduh patarosan rentang tanggal, maka anjeun henteu kedah nempatkeun tanggalna dina konci primér.
OKÉ hatur nuhun pisan!
sumber: www.habr.com