Pada bulan April, jurutera Avito berkumpul untuk mesyuarat dalam talian dengan pembangun ClickHouse utama Alexey Milovidov dan Kirill Shvakov, pemaju Golang dari Integros. Kami membincangkan cara kami menggunakan sistem pengurusan pangkalan data dan kesukaran yang kami hadapi.
Berdasarkan pertemuan itu, kami telah menyusun artikel dengan jawapan pakar kepada soalan kami dan khalayak tentang sandaran, penyusunan semula data, kamus luaran, pemacu Golang dan mengemas kini versi ClickHouse. Ia mungkin berguna kepada pembangun yang sudah aktif bekerja dengan Yandex DBMS dan berminat dengan masa kini dan masa depannya. Secara lalai, jawapannya adalah oleh Alexey Milovidov, melainkan ditulis sebaliknya.
Berhati-hati, terdapat banyak teks di bawah potongan. Kami berharap kandungan dengan soalan akan membantu anda menavigasi.
Содержание
Jika anda tidak mahu membaca teks, anda boleh menonton rakaman perhimpunan . Kod masa terdapat dalam ulasan pertama di bawah video.
ClickHouse sentiasa dikemas kini, tetapi data kami tidak. Apa yang perlu dilakukan mengenainya?
ClickHouse sentiasa dikemas kini, dan data kami, yang telah dioptimumkan akhir diproses, tidak dikemas kini dan berada dalam salinan sandaran.
Katakan kami mempunyai beberapa masalah dan data telah hilang. Kami memutuskan untuk memulihkan, dan ternyata partition lama, yang disimpan pada pelayan sandaran, sangat berbeza daripada versi ClickHouse yang digunakan sekarang. Apa yang perlu dilakukan dalam keadaan sedemikian, dan adakah mungkin?
Situasi di mana anda memulihkan data daripada sandaran dalam format lama, tetapi ia tidak bersambung ke versi baharu, adalah mustahil. Kami memastikan bahawa format data dalam ClickHouse sentiasa kekal serasi ke belakang. Ini adalah lebih penting daripada keserasian ke belakang dalam kefungsian jika tingkah laku beberapa fungsi yang jarang digunakan telah berubah. Versi baharu ClickHouse harus sentiasa dapat membaca data yang disimpan pada cakera. Ini adalah undang-undang.
Apakah amalan terbaik semasa untuk membuat sandaran data daripada ClickHouse?
Bagaimana untuk membuat sandaran, dengan mengambil kira bahawa kami telah mengoptimumkan operasi akhir, pangkalan data terabait yang besar, dan data yang dikemas kini, katakan, selama tiga hari terakhir, dan kemudian tiada prosedur berlaku padanya?
Kami boleh membuat penyelesaian kami sendiri dan menulis pada bash: kumpulkan salinan sandaran ini dengan cara yang sedemikian. Mungkin tidak perlu bertongkat apa-apa, dan basikal itu dicipta lama dahulu?
Mari kita mulakan dengan amalan terbaik. Rakan sekerja saya sentiasa menasihati, sebagai tindak balas kepada soalan tentang sandaran, untuk mengingatkan mereka tentang perkhidmatan Yandex.Cloud, di mana masalah ini telah diselesaikan. Jadi gunakannya jika boleh.
Tiada penyelesaian lengkap untuk sandaran, seratus peratus dibina ke dalam ClickHouse. Terdapat beberapa tempat kosong yang boleh digunakan. Untuk mendapatkan penyelesaian yang lengkap, anda sama ada perlu mengotak-atik sedikit secara manual, atau membuat pembungkus dalam bentuk skrip.
Saya akan mulakan dengan penyelesaian yang paling mudah dan berakhir dengan penyelesaian yang paling canggih, bergantung pada volum data dan saiz kluster. Semakin besar kluster, semakin kompleks penyelesaiannya.
Jika jadual dengan data hanya menduduki beberapa gigabait, sandaran boleh dilakukan seperti ini:
- Simpan definisi jadual iaitu metadata − tunjukkan buat jadual.
- Buat pembuangan menggunakan klien ClickHouse - pilih * dari meja untuk memfailkan. Secara lalai anda akan menerima fail dalam format TabSeparated. Jika anda ingin menjadi lebih cekap, anda boleh melakukannya dalam format Asli.
Jika jumlah data lebih besar, maka sandaran akan mengambil lebih banyak masa dan banyak ruang. Ini dipanggil sandaran logik; ia tidak terikat dengan format data ClickHouse. Jika ya, maka sebagai pilihan terakhir anda boleh mengambil sandaran dan memuat naiknya ke MySQL untuk pemulihan.
Untuk kes yang lebih lanjut, ClickHouse mempunyai keupayaan terbina dalam untuk mencipta petikan partition dalam sistem fail tempatan. Ciri ini tersedia sebagai permintaan ubah partition pembekuan jadual. Atau ringkasnya mengubah pembekuan meja - ini ialah petikan keseluruhan jadual.
Syot kilat akan dibuat secara konsisten untuk satu jadual pada satu serpihan, iaitu, adalah mustahil untuk mencipta syot kilat yang konsisten bagi keseluruhan kluster dengan cara ini. Tetapi untuk kebanyakan tugas tidak ada keperluan seperti itu, dan sudah cukup untuk melaksanakan permintaan pada setiap serpihan dan mendapatkan gambar yang konsisten. Ia dicipta dalam bentuk pautan keras dan oleh itu tidak mengambil ruang tambahan. Seterusnya, anda menyalin petikan ini ke pelayan sandaran atau ke storan yang anda gunakan untuk sandaran.
Memulihkan sandaran sedemikian agak mudah. Mula-mula, buat jadual menggunakan definisi jadual sedia ada. Seterusnya, salin syot kilat yang disimpan bagi partition ke Direktori-Detached untuk jadual ini dan jalankan pertanyaan lampirkan partition. Penyelesaian ini agak sesuai untuk volum data yang paling serius.
Kadangkala anda memerlukan sesuatu yang lebih sejuk - dalam kes di mana anda mempunyai puluhan atau bahkan ratusan terabait pada setiap pelayan dan ratusan pelayan. Terdapat penyelesaian di sini yang saya ambil daripada rakan sekerja saya daripada Yandex.Metrica. Saya tidak akan mengesyorkannya kepada semua orang - baca dan tentukan sendiri sama ada ia sesuai atau tidak.
Mula-mula anda perlu membuat beberapa pelayan dengan rak cakera yang besar. Seterusnya, pada pelayan ini, naikkan beberapa pelayan ClickHouse dan konfigurasikannya supaya ia berfungsi sebagai replika lain untuk serpihan yang sama. Dan kemudian gunakan sistem fail atau beberapa alat pada pelayan ini yang membolehkan anda membuat syot kilat. Terdapat dua pilihan di sini. Pilihan pertama ialah petikan LVM, pilihan kedua ialah ZFS di Linux.
Selepas itu, setiap hari anda perlu membuat syot kilat, ia akan berbohong dan mengambil sedikit ruang. Sememangnya, jika data berubah, jumlah ruang akan meningkat dari semasa ke semasa. Gambar ini boleh dikeluarkan pada bila-bila masa dan data dipulihkan, penyelesaian yang aneh. Selain itu, kita juga perlu mengehadkan replika ini dalam konfigurasi supaya mereka tidak cuba menjadi pemimpin.
Adakah mungkin untuk mengatur lag terkawal replika dalam aci?
Tahun ini anda merancang untuk membuat aci di ClickHouse. Adakah mungkin untuk mengatur lag terkawal replika di dalamnya? Kami ingin menggunakannya untuk melindungi diri kami daripada senario negatif dengan perubahan dan perubahan lain.
Adakah mungkin untuk melakukan beberapa jenis roll back untuk perubahan? Sebagai contoh, dalam aci sedia ada, ambil dan katakan bahawa sehingga saat ini anda menggunakan perubahan, dan mulai saat ini anda berhenti menggunakan perubahan?
Jika perintah datang ke kluster kami dan memecahkannya, maka kami mempunyai replika bersyarat dengan ketinggalan satu jam, di mana kita boleh mengatakan bahawa mari kita gunakannya pada masa ini, tetapi kita tidak akan menggunakan perubahan padanya selama sepuluh minit terakhir?
Pertama, tentang ketinggalan terkawal replika. Terdapat permintaan sedemikian daripada pengguna, dan kami mencipta isu pada Github dengan permintaan: "Jika seseorang memerlukan ini, suka, letakkan hati." Tiada siapa yang menghantar dan isu itu telah ditutup. Walau bagaimanapun, anda sudah boleh mendapatkan peluang ini dengan menyediakan ClickHouse. Benar, hanya bermula dari versi 20.3.
ClickHouse sentiasa melakukan penggabungan data di latar belakang. Apabila penggabungan selesai, set data tertentu digantikan dengan kepingan yang lebih besar. Pada masa yang sama, kepingan data yang ada sebelum ini terus kekal pada cakera untuk beberapa lama.
Pertama, mereka terus disimpan selagi terdapat pertanyaan terpilih yang menggunakannya, untuk menyediakan operasi tanpa sekatan. Pertanyaan terpilih mudah dibaca daripada potongan lama.
Kedua, terdapat juga ambang masa - kepingan data lama terletak pada cakera selama lapan minit. Lapan minit ini boleh disesuaikan dan malah bertukar menjadi satu hari. Ini akan menelan kos ruang cakera: bergantung pada aliran data, ternyata pada hari terakhir data itu bukan sahaja akan berganda, ia boleh menjadi lima kali lebih banyak. Tetapi jika terdapat masalah yang serius, anda boleh menghentikan pelayan ClickHouse dan menyelesaikan semuanya.
Sekarang timbul persoalan tentang bagaimana ini melindungi daripada perubahan. Perlu melihat dengan lebih mendalam di sini, kerana dalam versi ClickHouse yang lebih lama, alter berfungsi sedemikian rupa sehingga ia hanya menukar bahagian secara langsung. Terdapat sekeping data dengan beberapa fail, dan kami melakukannya, sebagai contoh, ubah lajur jatuh. Kemudian lajur ini dialih keluar secara fizikal daripada semua bahagian.
Tetapi bermula dengan versi 20.3, mekanisme alter telah diubah sepenuhnya, dan kini kepingan data sentiasa tidak berubah. Mereka tidak berubah sama sekali - mengubah kini berfungsi dengan cara yang sama seperti gabungan. Daripada menggantikan sekeping di tempat, kami mencipta yang baharu. Dalam bahagian baharu, fail yang tidak berubah menjadi pautan keras, dan jika kami memadamkan lajur, ia akan hilang begitu saja dalam bahagian baharu. Bahagian lama akan dipadamkan secara lalai selepas lapan minit, dan di sini anda boleh mengubah suai tetapan yang dinyatakan di atas.
Perkara yang sama berlaku untuk perubahan seperti mutasi. Apabila anda melakukannya mengubah padam atau mengubah kemas kini, ia tidak mengubah bahagian, tetapi mencipta yang baharu. Dan kemudian memadam yang lama.
Bagaimana jika struktur jadual telah berubah?
Bagaimana untuk memulihkan sandaran yang dibuat dengan skim lama? Dan soalan kedua ialah mengenai kes dengan syot kilat dan alat sistem fail. Adakah Btrfs bagus di sini dan bukannya ZFS pada Linux LVM?
Jika anda lakukan lampirkan partition partition dengan struktur yang berbeza, maka ClickHouse akan memberitahu anda bahawa ini tidak mungkin. Ini adalah penyelesaiannya. Yang pertama ialah membuat jadual sementara jenis MergeTree dengan struktur lama, lampirkan data di sana menggunakan lampirkan, dan buat pertanyaan alter. Kemudian anda boleh sama ada menyalin atau memindahkan data ini dan melampirkan semula, atau menggunakan permintaan ubah partition alih jadual.
Sekarang soalan kedua ialah sama ada Btrfs boleh digunakan. Sebagai permulaan, jika anda mempunyai LVM, maka syot kilat LVM sudah mencukupi, dan sistem fail boleh menjadi ext4, tidak mengapa. Dengan Btrts, semuanya bergantung pada pengalaman anda menggunakannya. Ini adalah sistem fail yang matang, tetapi masih terdapat beberapa syak wasangka tentang bagaimana semuanya akan berfungsi dalam amalan dalam senario tertentu. Saya tidak akan mengesyorkan menggunakan ini melainkan anda mempunyai Btrfs dalam pengeluaran.
Apakah amalan terbaik semasa dalam penyusunan semula data?
Isu penyusunan semula adalah kompleks dan pelbagai rupa. Terdapat beberapa kemungkinan jawapan di sini. Anda boleh pergi dari satu pihak dan katakan ini - ClickHouse tidak mempunyai ciri pengerasan semula terbina dalam. Tetapi saya takut jawapan ini tidak sesuai dengan sesiapa pun. Oleh itu, anda boleh pergi dari sisi lain dan mengatakan bahawa ClickHouse mempunyai banyak cara untuk mengeras semula data.
Jika kluster kehabisan ruang atau ia tidak dapat mengendalikan beban, anda menambah pelayan baharu. Tetapi pelayan ini kosong secara lalai, tiada data padanya, tiada beban. Anda perlu menyusun semula data supaya ia menjadi sekata merentas gugusan baharu yang lebih besar.
Cara pertama ini boleh dilakukan ialah menyalin sebahagian daripada partition ke pelayan baharu menggunakan permintaan ubah partition pengambilan jadual. Contohnya, anda mempunyai partition mengikut bulan, dan anda mengambil bulan pertama 2017 dan menyalinnya ke pelayan baharu, kemudian menyalin bulan ketiga ke beberapa pelayan baharu yang lain. Dan anda melakukan ini sehingga ia menjadi lebih atau kurang sekata.
Pemindahan boleh dilakukan hanya untuk partition yang tidak berubah semasa rakaman. Untuk sekatan baharu, rakaman perlu dilumpuhkan, kerana pemindahannya bukan atom. Jika tidak, anda akan mendapat pendua atau jurang dalam data. Walau bagaimanapun, kaedah ini praktikal dan berfungsi dengan agak berkesan. Pembahagian termampat sedia dibuat dihantar melalui rangkaian, iaitu, data tidak dimampatkan atau dikodkan semula.
Kaedah ini mempunyai satu kelemahan, dan ia bergantung pada skim sharding, sama ada anda berjanji untuk skim sharding ini, apa kunci sharding yang anda ada. Dalam contoh anda untuk kes dengan metrik, kunci sharding ialah cincang laluan. Apabila anda memilih jadual Teragih, ia pergi ke semua serpihan dalam kelompok sekaligus dan mengambil data dari sana.
Ini bermakna bahawa ia sebenarnya tidak penting kepada anda apa data yang berakhir pada serpihan mana. Perkara utama ialah data sepanjang satu laluan berakhir pada satu serpihan, tetapi yang mana satu tidak penting. Dalam kes ini, pemindahan partition siap adalah sempurna, kerana dengan pertanyaan terpilih anda juga akan menerima data lengkap - sama ada sebelum pengerasan semula atau selepas, skema itu tidak begitu penting.
Tetapi ada kes yang lebih kompleks. Jika pada tahap logik aplikasi anda bergantung pada skim sharding khas, bahawa klien ini terletak pada shard ini dan itu, dan permintaan boleh dihantar terus ke sana, dan bukan ke jadual Distributed. Atau anda menggunakan versi ClickHouse yang agak terkini dan telah mendayakan tetapan mengoptimumkan langkau serpihan yang tidak digunakan. Dalam kes ini, semasa pertanyaan pilih, ungkapan dalam bahagian tempat akan dianalisis dan ia akan dikira serpihan mana yang perlu digunakan mengikut skema sharding. Ini berfungsi dengan syarat data dibahagikan dengan tepat mengikut skema sharding ini. Jika anda menyusun semula secara manual, surat-menyurat mungkin berubah.
Jadi ini adalah kaedah nombor satu. Dan saya sedang menunggu jawapan anda, sama ada kaedah itu sesuai, atau mari kita teruskan.
Vladimir Kolobaev, pentadbir sistem utama di Avito: Alexey, kaedah yang anda nyatakan tidak berfungsi dengan baik apabila anda perlu menyebarkan beban, termasuk membaca. Kami boleh mengambil partition yang bulanan dan boleh membawa bulan sebelumnya ke nod lain, tetapi apabila permintaan datang untuk data ini, kami hanya akan memuatkannya. Tetapi kami ingin memuatkan keseluruhan kluster, kerana jika tidak, untuk beberapa waktu keseluruhan beban bacaan akan diproses oleh dua serpihan.
Alexey Milovidov: Jawapannya di sini adalah pelik - ya, ia buruk, tetapi ia mungkin berkesan. Saya akan menerangkan dengan tepat bagaimana. Perlu melihat senario pemuatan yang terdapat di sebalik data anda. Jika ini adalah data pemantauan, maka kita hampir pasti boleh mengatakan bahawa sebahagian besar permintaan adalah untuk data baharu.
Anda memasang pelayan baharu, memindahkan partition lama, tetapi turut mengubah cara data baharu direkodkan. Dan data baharu akan disebarkan ke seluruh kluster. Oleh itu, selepas lima minit sahaja, permintaan untuk lima minit terakhir akan memuatkan kluster secara sama rata; selepas sehari, permintaan selama XNUMX jam akan memuatkan kluster secara sama rata. Dan permintaan untuk bulan sebelumnya, malangnya, hanya akan pergi ke sebahagian daripada pelayan kluster.
Tetapi selalunya anda tidak akan mempunyai permintaan khusus untuk Februari 2019. Kemungkinan besar, jika permintaan masuk ke 2019, maka permintaan itu akan berlaku untuk keseluruhan 2019 - untuk jangka masa yang panjang, dan bukan untuk julat yang kecil. Dan permintaan sedemikian juga akan dapat memuatkan kluster secara sama rata. Tetapi secara umum, kenyataan anda betul sekali bahawa ini adalah penyelesaian ad hoc yang tidak menyebarkan data sepenuhnya secara sama rata.
Saya mempunyai beberapa mata lagi untuk menjawab soalan itu. Salah satunya ialah tentang cara mereka bentuk skema sharding pada mulanya supaya sharding semula akan mengurangkan kesakitan. Ini tidak selalu mungkin.
Sebagai contoh, anda mempunyai data pemantauan. Data pemantauan berkembang kerana tiga sebab. Yang pertama ialah pengumpulan data sejarah. Yang kedua ialah pertumbuhan trafik. Dan yang ketiga ialah pertambahan bilangan perkara yang tertakluk kepada pemantauan. Terdapat perkhidmatan mikro dan metrik baharu yang perlu disimpan.
Ada kemungkinan bahawa peningkatan terbesar dikaitkan dengan sebab ketiga - peningkatan dalam penggunaan pemantauan. Dan dalam kes ini, ia patut melihat sifat beban, apakah pertanyaan pilihan utama. Pertanyaan pilihan asas kemungkinan besar akan berdasarkan beberapa subset metrik.
Contohnya, penggunaan CPU pada sesetengah pelayan oleh sesetengah perkhidmatan. Ternyata terdapat subset kunci tertentu yang anda gunakan untuk mendapatkan data ini. Dan permintaan itu sendiri untuk data ini kemungkinan besar agak mudah dan diselesaikan dalam berpuluh-puluh milisaat. Digunakan untuk memantau perkhidmatan dan papan pemuka. Saya harap saya faham perkara ini dengan betul.
Vladimir Kolobaev: Hakikatnya ialah kami sering merayu kepada data sejarah, kerana kami membandingkan keadaan semasa dengan yang bersejarah dalam masa nyata. Dan penting bagi kami untuk mempunyai akses pantas kepada sejumlah besar data, dan ClickHouse melakukan kerja yang sangat baik dengan ini.
Anda betul-betul betul, kami mengalami kebanyakan permintaan baca pada hari terakhir, seperti mana-mana sistem pemantauan. Tetapi pada masa yang sama, beban pada data sejarah juga agak besar. Ia pada asasnya daripada sistem amaran yang berlangsung setiap tiga puluh saat dan berkata kepada ClickHouse: “Beri saya data untuk enam minggu lepas. Sekarang bina saya beberapa jenis purata bergerak daripada mereka, dan mari kita bandingkan nilai semasa dengan nilai sejarah."
Saya ingin mengatakan bahawa untuk permintaan yang sangat baru-baru ini, kami mempunyai satu lagi jadual kecil di mana kami menyimpan hanya dua hari data, dan permintaan utama terbang ke dalamnya. Kami hanya menghantar pertanyaan sejarah yang besar kepada jadual besar yang berpecah.
Alexey Milovidov: Malangnya, ia ternyata kurang sesuai untuk senario anda, tetapi saya akan memberitahu anda penerangan tentang dua skim sharding yang buruk dan kompleks yang tidak perlu digunakan, tetapi yang digunakan dalam perkhidmatan rakan saya.
Terdapat gugusan utama dengan acara Yandex.Metrica. Acara ialah paparan halaman, klik dan penukaran. Kebanyakan permintaan pergi ke tapak web tertentu. Anda membuka perkhidmatan Yandex.Metrica, anda mempunyai tapak web - avito.ru, pergi ke laporan dan permintaan dibuat untuk tapak web anda.
Tetapi terdapat permintaan lain - analitikal dan global - yang dibuat oleh penganalisis dalaman. Untuk berjaga-jaga, saya perhatikan bahawa penganalisis dalaman hanya membuat permintaan untuk perkhidmatan Yandex. Namun begitu, walaupun perkhidmatan Yandex menduduki bahagian penting semua data. Ini adalah permintaan bukan untuk kaunter tertentu, tetapi untuk penapisan yang lebih luas.
Bagaimana untuk mengatur data sedemikian rupa sehingga semuanya berfungsi dengan cekap untuk satu kaunter, dan pertanyaan global juga? Kesukaran lain ialah bilangan permintaan dalam ClickHouse untuk kelompok Metrik adalah beberapa ribu sesaat. Pada masa yang sama, satu pelayan ClickHouse tidak boleh mengendalikan permintaan yang tidak remeh, contohnya, beberapa ribu sesaat.
Saiz kluster ialah enam ratus pelayan sesuatu. Jika anda hanya menarik jadual Teragih ke atas kluster ini dan menghantar beberapa ribu permintaan ke sana, ia akan menjadi lebih teruk daripada menghantarnya ke satu pelayan. Sebaliknya, pilihan bahawa data disebarkan secara sama rata, dan kami pergi dan meminta daripada semua pelayan, segera diketepikan.
Terdapat pilihan yang bertentangan secara diametrik. Bayangkan jika kita memecah data merentas tapak, dan permintaan untuk satu tapak pergi ke satu bahagian. Kini kluster akan dapat mengendalikan sepuluh ribu permintaan sesaat, tetapi pada satu serpihan mana-mana satu permintaan akan berfungsi terlalu perlahan. Ia tidak lagi berskala dari segi daya pemprosesan. Terutama jika ini adalah tapak avito.ru. Saya tidak akan mendedahkan rahsia jika saya mengatakan bahawa Avito adalah salah satu laman web yang paling banyak dikunjungi di RuNet. Dan memprosesnya pada satu serpihan akan menjadi kegilaan.
Oleh itu, skim sharding direka dengan cara yang lebih licik. Keseluruhan kluster dibahagikan kepada beberapa kluster, yang kita panggil lapisan. Setiap kelompok mengandungi dari sedozen hingga beberapa dozen serpihan. Terdapat tiga puluh sembilan kluster sedemikian secara keseluruhan.
Bagaimanakah semua ini berskala? Bilangan kluster tidak berubah - kerana ia adalah tiga puluh sembilan beberapa tahun yang lalu, ia kekal begitu. Tetapi dalam setiap daripada mereka, kami meningkatkan bilangan serpihan secara beransur-ansur semasa kami mengumpul data. Dan skema sharding secara keseluruhan adalah seperti ini: kluster ini dibahagikan kepada laman web, dan untuk memahami tapak web mana yang berada pada kluster, pangkalan meta berasingan dalam MySQL digunakan. Satu tapak - pada satu kelompok. Dan di dalamnya, sharding berlaku mengikut ID pelawat.
Semasa merakam, kami membahagikannya dengan baki pembahagian ID pelawat. Tetapi apabila menambah serpihan baharu, skema serpihan berubah; kami terus membahagi, tetapi dengan baki bahagian dengan nombor lain. Ini bermakna bahawa seorang pelawat sudah berada di beberapa pelayan, dan anda tidak boleh bergantung pada ini. Ini dilakukan semata-mata untuk memastikan data dimampatkan dengan lebih baik. Dan apabila membuat permintaan, kami pergi ke jadual Distributed, yang melihat gugusan dan mengakses berpuluh-puluh pelayan. Ini adalah satu skim bodoh.
Tetapi cerita saya tidak akan lengkap jika saya tidak mengatakan bahawa kami meninggalkan skim ini. Dalam skema baharu, kami mengubah segala-galanya dan menyalin semua data menggunakan mesin penyalin clickhouse.
Dalam skim baru, semua tapak dibahagikan kepada dua kategori - besar dan kecil. Saya tidak tahu bagaimana ambang dipilih, tetapi hasilnya ialah tapak besar direkodkan pada satu kelompok, di mana terdapat 120 serpihan dengan tiga replika setiap satu - iaitu 360 pelayan. Dan skim sharding adalah sedemikian rupa sehingga sebarang permintaan pergi ke semua serpihan sekaligus. Jika anda kini membuka mana-mana halaman laporan untuk avito.ru dalam Yandex.Metrica, permintaan akan pergi ke 120 pelayan. Terdapat beberapa tapak besar dalam RuNet. Dan permintaannya bukan seribu sesaat, malah kurang daripada seratus. Semua ini dikunyah secara senyap-senyap oleh jadual Distributed, yang masing-masing memproses dengan 120 pelayan.
Dan kluster kedua adalah untuk tapak kecil. Berikut ialah skim sharding berdasarkan ID tapak, dan setiap permintaan pergi ke tepat satu shard.
ClickHouse mempunyai utiliti mesin penyalin clickhouse. Bolehkah anda memberitahu kami tentang dia?
Saya akan katakan dengan segera bahawa penyelesaian ini lebih rumit dan agak kurang produktif. Kelebihannya ialah ia mencemarkan data sepenuhnya mengikut corak yang anda tentukan. Tetapi kelemahan utiliti adalah bahawa ia tidak reshard sama sekali. Ia menyalin data daripada satu skema kluster ke skema kluster yang lain.
Ini bermakna bahawa untuk berfungsi, anda mesti mempunyai dua kelompok. Mereka boleh ditempatkan pada pelayan yang sama, tetapi, bagaimanapun, data tidak akan dialihkan secara berperingkat, tetapi akan disalin.
Sebagai contoh, terdapat empat pelayan, kini terdapat lapan. Anda mencipta jadual Teragih baharu pada semua pelayan, jadual tempatan baharu dan melancarkan mesin penyalin clickhouse, yang menunjukkan di dalamnya skema kerja yang harus dibaca dari sana, terima skema sharding baharu dan pindahkan data ke sana. Dan pada pelayan lama anda memerlukan satu setengah kali lebih banyak ruang daripada yang ada sekarang, kerana data lama mesti kekal pada mereka, dan separuh daripada data lama yang sama akan tiba di atasnya. Jika anda fikir terlebih dahulu bahawa data perlu diolah semula dan ada ruang, maka kaedah ini sesuai.
Bagaimanakah clickhouse-copier berfungsi di dalam? Ia memecahkan semua kerja kepada satu set tugas untuk memproses satu partition satu jadual pada satu shard. Semua tugasan ini boleh dilaksanakan secara selari dan clickhouse-copier boleh dijalankan pada mesin yang berbeza dalam beberapa keadaan, tetapi apa yang dilakukannya untuk satu partition tidak lebih daripada pilihan sisipan. Data dibaca, dinyahmampat, dipartisi semula, kemudian dimampatkan semula, ditulis di suatu tempat dan disusun semula. Ini adalah keputusan yang lebih sukar.
Anda mempunyai perkara perintis yang dipanggil pengerasan semula. Bagaimana dengan dia?
Pada tahun 2017, anda mempunyai perkara perintis yang dipanggil pengerasan semula. Malah terdapat pilihan dalam ClickHouse. Seperti yang saya faham, ia tidak berlepas. Bolehkah anda memberitahu saya mengapa ini berlaku? Nampak sangat relevan.
Keseluruhan masalahnya ialah jika perlu untuk mengeras semula data di tempatnya, penyegerakan yang sangat kompleks diperlukan untuk melakukan ini secara atom. Apabila kami mula melihat cara penyegerakan ini berfungsi, menjadi jelas bahawa terdapat masalah asas. Dan masalah asas ini bukan sahaja teori, tetapi dengan serta-merta mula menunjukkan diri mereka dalam amalan dalam bentuk sesuatu yang boleh dijelaskan dengan sangat mudah - tiada apa yang berfungsi.
Adakah mungkin untuk menggabungkan semua kepingan data bersama-sama sebelum mengalihkannya ke cakera perlahan?
Soalan tentang TTL dengan pilihan peralihan cakera dalam konteks gabungan. Adakah terdapat cara, selain melalui cron, untuk menggabungkan semua bahagian menjadi satu sebelum mengalihkannya ke cakera perlahan?
Jawapan kepada soalan adalah mungkin untuk melekatkan semua kepingan secara automatik menjadi satu sebelum memindahkannya - tidak. Saya rasa ini tidak perlu. Anda tidak perlu menggabungkan semua bahagian menjadi satu, tetapi hanya bergantung pada fakta bahawa ia akan dipindahkan ke cakera perlahan secara automatik.
Kami mempunyai dua kriteria untuk peraturan perpindahan. Yang pertama adalah kerana ia diisi. Jika peringkat storan semasa mempunyai kurang daripada peratusan tertentu ruang kosong, kami memilih satu bahagian dan mengalihkannya ke storan yang lebih perlahan. Atau sebaliknya, tidak lebih perlahan, tetapi yang seterusnya - semasa anda mengkonfigurasi.
Kriteria kedua ialah saiz. Ia mengenai memindahkan kepingan besar. Anda boleh melaraskan ambang mengikut ruang kosong pada cakera pantas, dan data akan dipindahkan secara automatik.
Bagaimana untuk berhijrah ke versi baharu ClickHouse jika tiada cara untuk menyemak keserasian terlebih dahulu?
Topik ini selalu dibincangkan mengambil kira versi yang berbeza, dan masih. Sejauh manakah selamat untuk menaik taraf daripada versi 19.11 kepada 19.16 dan, sebagai contoh, daripada 19.16 kepada 20.3. Apakah cara terbaik untuk berhijrah ke versi baharu tanpa dapat menyemak keserasian dalam kotak pasir terlebih dahulu?
Terdapat beberapa peraturan "emas" di sini. pertama - . Ia besar, tetapi terdapat perenggan berasingan tentang perubahan tidak serasi ke belakang. Jangan anggap mata ini sebagai bendera merah. Ini biasanya ketidakserasian kecil yang melibatkan beberapa fungsi kelebihan yang anda mungkin tidak gunakan.
Kedua, jika tiada cara untuk menyemak keserasian dalam kotak pasir, dan anda ingin mengemas kini serta-merta dalam pengeluaran, cadangannya ialah anda tidak perlu melakukan ini. Mula-mula buat kotak pasir dan uji. Jika tiada persekitaran ujian, kemungkinan besar anda tidak mempunyai syarikat yang sangat besar, yang bermaksud anda boleh menyalin beberapa data ke komputer riba anda dan memastikan semuanya berfungsi dengan betul padanya. Anda juga boleh menaikkan beberapa replika secara tempatan pada mesin anda. Atau anda boleh mengambil versi baharu di suatu tempat berdekatan dan memuat naik beberapa data di sana - iaitu, mencipta persekitaran ujian yang diubah suai.
Peraturan lain ialah tidak mengemas kini selama seminggu selepas keluaran versi kerana menangkap pepijat dalam pengeluaran dan pembetulan pantas seterusnya. Mari kita fikirkan penomboran versi ClickHouse supaya tidak keliru.
Terdapat versi 20.3.4. Nombor 20 menunjukkan tahun pembuatan - 2020. Dari sudut pandangan apa yang ada di dalamnya, ini tidak penting, jadi kami tidak akan memberi perhatian kepadanya. Seterusnya - 20.3. Kami menambah nombor kedua - dalam kes ini 3 - setiap kali kami mengeluarkan keluaran dengan beberapa fungsi baharu. Jika kita ingin menambah beberapa ciri pada ClickHouse, kita mesti meningkatkan jumlah ini. Iaitu, dalam versi 20.4 ClickHouse akan berfungsi dengan lebih baik. Digit ketiga ialah 20.3.4. Di sini 4 ialah bilangan keluaran tampalan di mana kami tidak menambah ciri baharu, tetapi membetulkan beberapa pepijat. Dan 4 bermakna kita melakukannya empat kali.
Jangan fikir ini adalah sesuatu yang mengerikan. Biasanya pengguna boleh memasang versi terkini dan ia akan berfungsi tanpa sebarang masalah dengan masa operasi setiap tahun. Tetapi bayangkan bahawa dalam beberapa fungsi untuk memproses bitmap, yang ditambahkan oleh rakan Cina kami, pelayan ranap apabila menghantar hujah yang salah. Kami mempunyai tanggungjawab untuk membetulkan perkara ini. Kami akan mengeluarkan versi tampalan baharu dan ClickHouse akan menjadi lebih stabil.
Jika anda mempunyai ClickHouse berjalan dalam pengeluaran, dan versi baharu ClickHouse keluar dengan ciri tambahan - contohnya, 20.4.1 adalah yang pertama, jangan tergesa-gesa untuk memasukkannya ke dalam pengeluaran pada hari pertama. Mengapa ia juga diperlukan? Jika anda belum menggunakan ClickHouse, maka anda boleh memasangnya, dan kemungkinan besar semuanya akan baik-baik saja. Tetapi jika ClickHouse sudah berfungsi dengan stabil, maka perhatikan tampung dan kemas kini untuk melihat masalah yang sedang kami selesaikan.
Kirill Shvakov: Saya ingin menambah sedikit tentang persekitaran ujian. Semua orang sangat takut dengan persekitaran ujian dan atas sebab tertentu mereka percaya bahawa jika anda mempunyai kluster ClickHouse yang sangat besar, maka persekitaran ujian mestilah tidak kurang atau sekurang-kurangnya sepuluh kali lebih kecil. Ia tidak seperti itu sama sekali.
Saya boleh memberitahu anda daripada contoh saya sendiri. Saya mempunyai projek, dan terdapat ClickHouse. Persekitaran ujian kami hanya untuknya - ini adalah mesin maya kecil di Hetzner dengan harga dua puluh euro, di mana segala-galanya digunakan sepenuhnya. Untuk melakukan ini, kami mempunyai automasi penuh dalam Ansible, dan oleh itu, pada dasarnya, tidak ada bezanya ke mana hendak pergi - ke pelayan perkakasan atau hanya digunakan dalam mesin maya.
Apa yang boleh dibuat? Adalah baik untuk memberikan contoh dalam dokumentasi ClickHouse tentang cara menggunakan kluster kecil di rumah anda sendiri - dalam Docker, dalam LXC, mungkin mencipta buku permainan Ansible, kerana orang yang berbeza mempunyai penempatan yang berbeza. Ini akan memudahkan banyak perkara. Apabila anda mengambil dan menggunakan kluster dalam masa lima minit, lebih mudah untuk mencuba memikirkan sesuatu. Ini adalah lebih mudah, kerana beralih ke versi pengeluaran yang belum anda uji adalah jalan ke mana-mana. Kadang-kadang ia berfungsi dan kadang-kadang tidak. Dan oleh itu, mengharapkan kejayaan adalah buruk.
Maxim Kotyakov, jurutera kanan belakang Avito: Saya akan menambah sedikit tentang persekitaran ujian daripada siri masalah yang dihadapi oleh syarikat besar. Kami mempunyai kluster penerimaan ClickHouse sepenuhnya; dari segi skema dan tetapan data, ia adalah salinan tepat apa yang sedang dalam pengeluaran. Kelompok ini digunakan dalam bekas yang agak tercemar dengan sumber minimum. Kami menulis peratusan tertentu data pengeluaran di sana, mujurlah ada kemungkinan untuk meniru aliran dalam Kafka. Segala-galanya di sana disegerakkan dan berskala - dari segi kapasiti dan aliran, dan, secara teori, semua perkara lain adalah sama, ia harus berkelakuan seperti pengeluaran dari segi metrik. Segala-galanya yang berpotensi meletup mula-mula digulung pada dirian ini dan dibiarkan di sana selama beberapa hari sehingga siap. Tetapi secara semulajadi, penyelesaian ini mahal, sukar dan mempunyai kos sokongan bukan sifar.
Alexey Milovidov: Saya akan memberitahu anda bagaimana persekitaran ujian rakan kami dari Yandex.Metrica. Satu kluster mempunyai 600 pelayan ganjil, satu lagi mempunyai 360, dan terdapat ketiga dan beberapa kluster. Persekitaran ujian untuk salah satu daripadanya hanyalah dua serpihan dengan dua replika dalam setiap satu. Kenapa dua serpihan? Supaya anda tidak keseorangan. Dan mesti ada replika juga. Hanya jumlah minimum tertentu yang anda mampu.
Persekitaran ujian ini membolehkan anda menyemak sama ada pertanyaan anda berfungsi dan jika ada perkara utama yang rosak. Tetapi selalunya masalah timbul dengan sifat yang sama sekali berbeza, apabila semuanya berfungsi, tetapi terdapat beberapa perubahan kecil dalam beban.
Biar saya berikan satu contoh. Kami memutuskan untuk memasang versi baharu ClickHouse. Ia telah disiarkan pada persekitaran ujian, ujian automatik telah diselesaikan dalam Yandex.Metrica sendiri, yang membandingkan data pada versi lama dan yang baharu, menjalankan keseluruhan saluran paip. Dan sudah tentu, ujian hijau CI kami. Jika tidak, kami tidak akan mencadangkan versi ini.
Semuanya baik-baik sahaja. Kami mula bergerak ke dalam pengeluaran. Saya menerima mesej bahawa beban pada graf telah meningkat beberapa kali. Kami sedang melancarkan versi. Saya melihat graf dan melihat: beban sebenarnya meningkat beberapa kali semasa pelancaran dan menurun semula apabila ia dilancarkan. Kemudian kami mula melancarkan versi. Dan beban meningkat dengan cara yang sama dan jatuh kembali dengan cara yang sama. Jadi kesimpulannya adalah ini: beban telah meningkat disebabkan oleh susun atur, tidak ada yang mengejutkan.
Kemudian sukar untuk meyakinkan rakan sekerja untuk memasang versi baharu. Saya berkata: "Tidak mengapa, lancarkan. Teruskan jari anda, semuanya akan berfungsi. Sekarang beban pada graf telah meningkat, tetapi semuanya baik-baik saja. Tunggu di situ." Secara umum, kami melakukan ini, dan itu sahaja - versi dikeluarkan untuk pengeluaran. Tetapi hampir dengan setiap susun atur masalah yang sama timbul.
Kill query sepatutnya membunuh pertanyaan, tetapi ia tidak. kenapa?
Seorang pengguna, sejenis penganalisis, datang kepada saya dan membuat permintaan yang meletakkan kluster ClickHouse saya. Beberapa nod atau keseluruhan kluster, bergantung pada replika atau serpihan mana permintaan pergi. Saya melihat bahawa semua sumber CPU pada pelayan ini berada dalam rak, semuanya berwarna merah. Pada masa yang sama, ClickHouse sendiri bertindak balas terhadap permintaan. Dan saya menulis: "Sila tunjukkan saya, senarai proses, permintaan apa yang menjana kegilaan ini."
Saya dapati permintaan ini dan menulis bunuh kepadanya. Dan saya nampak tiada apa yang berlaku. Pelayan saya berada di dalam rak, ClickHouse kemudian memberi saya beberapa arahan, menunjukkan bahawa pelayan masih hidup, dan semuanya hebat. Tetapi saya mempunyai degradasi dalam semua permintaan pengguna, degradasi bermula dengan rekod dalam ClickHouse, dan pertanyaan bunuh saya tidak berfungsi. kenapa? Saya fikir pertanyaan bunuh sepatutnya membunuh pertanyaan, tetapi tidak.
Sekarang akan ada jawapan yang agak pelik. Intinya ialah membunuh pertanyaan tidak membunuh pertanyaan.
Kill query menyemak kotak kecil yang dipanggil "Saya mahu pertanyaan ini dimatikan." Dan permintaan itu sendiri melihat bendera ini apabila memproses setiap blok. Jika ia ditetapkan, permintaan akan berhenti berfungsi. Ternyata tiada siapa yang membunuh permintaan itu, dia sendiri mesti menyemak segala-galanya dan berhenti. Dan ini harus berfungsi dalam semua kes di mana permintaan berada dalam keadaan blok pemprosesan data. Ia akan memproses blok data seterusnya, menyemak bendera, dan berhenti.
Ini tidak berfungsi dalam kes di mana permintaan disekat pada beberapa operasi. Benar, kemungkinan besar ini bukan kes anda, kerana, menurut anda, ia menggunakan satu tan sumber pelayan. Ada kemungkinan bahawa ini tidak berfungsi dalam kes pengisihan luaran dan dalam beberapa butiran lain. Tetapi secara umum ini tidak sepatutnya berlaku, ia adalah pepijat. Dan satu-satunya perkara yang boleh saya cadangkan ialah mengemas kini ClickHouse.
Bagaimana untuk mengira masa tindak balas di bawah beban bacaan?
Terdapat jadual yang menyimpan agregat item - pelbagai kaunter. Bilangan baris adalah lebih kurang seratus juta. Adakah mungkin untuk mengira masa tindak balas yang boleh diramal jika anda menuangkan 1K RPS untuk 1K item?
Berdasarkan konteks, kita bercakap tentang beban bacaan, kerana tidak ada masalah dengan menulis - walaupun seribu, malah seratus ribu, dan kadang-kadang beberapa juta baris boleh dimasukkan.
Permintaan membaca sangat berbeza. Dalam pilihan 1, ClickHouse boleh melaksanakan kira-kira puluhan ribu permintaan sesaat, jadi walaupun permintaan untuk satu kunci sudah memerlukan beberapa sumber. Dan pertanyaan mata sedemikian akan menjadi lebih sukar daripada dalam beberapa pangkalan data nilai kunci, kerana untuk setiap bacaan adalah perlu untuk membaca blok data mengikut indeks. Indeks kami bukan alamat setiap rekod, tetapi setiap julat. Iaitu, anda perlu membaca keseluruhan julat - ini ialah 8192 baris secara lalai. Dan anda perlu menyahmampat blok data termampat daripada 64 KB kepada 1 MB. Biasanya, pertanyaan sasaran sedemikian mengambil masa beberapa milisaat untuk diselesaikan. Tetapi ini adalah pilihan yang paling mudah.
Mari cuba beberapa aritmetik mudah. Jika anda mendarab beberapa milisaat dengan seribu, anda mendapat beberapa saat. Seolah-olah mustahil untuk mengikuti seribu permintaan sesaat, tetapi sebenarnya ia mungkin, kerana kami mempunyai beberapa teras pemproses. Jadi, pada dasarnya, ClickHouse kadangkala boleh memegang 1000 RPS, tetapi untuk permintaan singkat, yang disasarkan secara khusus.
Jika anda perlu menskalakan kluster ClickHouse mengikut bilangan permintaan mudah, maka saya cadangkan perkara paling mudah - tingkatkan bilangan replika dan hantar permintaan ke replika rawak. Jika satu replika memegang lima ratus permintaan sesaat, yang benar-benar realistik, maka tiga replika akan mengendalikan satu setengah ribu.
Kadang-kadang, sudah tentu, anda boleh mengkonfigurasi ClickHouse untuk bilangan maksimum bacaan mata. Apa yang diperlukan untuk ini? Yang pertama adalah untuk mengurangkan butiran indeks. Dalam kes ini, ia tidak boleh dikurangkan kepada satu, tetapi atas dasar bahawa bilangan entri dalam indeks akan menjadi beberapa juta atau berpuluh-puluh juta setiap pelayan. Jika jadual mempunyai seratus juta baris, maka butiran boleh ditetapkan kepada 64.
Anda boleh mengurangkan saiz blok termampat. Terdapat tetapan untuk ini saiz blok mampat min, saiz blok mampat maksimum. Ia boleh dikurangkan, diisi semula dengan data, dan kemudian pertanyaan yang disasarkan akan menjadi lebih pantas. Namun begitu, ClickHouse bukanlah pangkalan data nilai kunci. Sebilangan besar permintaan kecil adalah antipattern beban.
Kirill Shvakov: Saya akan memberi nasihat sekiranya terdapat akaun biasa di sana. Ini adalah situasi yang agak standard apabila ClickHouse menyimpan beberapa jenis kaunter. Saya mempunyai pengguna, dia dari negara ini dan itu, dan beberapa bidang ketiga, dan saya perlu meningkatkan sesuatu secara berperingkat. Ambil MySQL, buat kunci unik - dalam MySQL ia adalah kunci pendua, dan dalam PostgreSQL ia adalah konflik - dan tambahkan tanda tambah. Ini akan berfungsi dengan lebih baik.
Apabila anda tidak mempunyai banyak data, tidak ada gunanya menggunakan ClickHouse. Terdapat pangkalan data biasa dan mereka melakukannya dengan baik.
Apakah yang boleh saya tweak dalam ClickHouse supaya lebih banyak data berada dalam cache?
Mari kita bayangkan situasi - pelayan mempunyai 256 GB RAM, dalam rutin harian ClickHouse mengambil masa kira-kira 60-80 GB, pada puncaknya - sehingga 130. Apa yang boleh didayakan dan diubah suai supaya lebih banyak data berada dalam cache dan, dengan itu, terdapat lebih sedikit perjalanan ke cakera?
Biasanya, cache halaman sistem pengendalian berfungsi dengan baik. Jika anda hanya membuka bahagian atas, lihat di sana cache atau percuma - ia juga menyatakan jumlah cache - maka anda akan melihat bahawa semua memori percuma digunakan untuk cache. Dan apabila membaca data ini, ia akan dibaca bukan dari cakera, tetapi dari RAM. Pada masa yang sama, saya boleh mengatakan bahawa cache digunakan dengan berkesan kerana ia adalah data termampat yang dicache.
Walau bagaimanapun, jika anda ingin mempercepatkan beberapa pertanyaan mudah, anda boleh mendayakan cache dalam data yang dinyahmampat di dalam ClickHouse. Ia dikenali sebagai cache tidak dimampatkan. Dalam fail konfigurasi config.xml, tetapkan saiz cache yang tidak dimampatkan kepada nilai yang anda perlukan - Saya mengesyorkan tidak lebih daripada separuh daripada RAM percuma, kerana selebihnya akan berada di bawah cache halaman.
Di samping itu, terdapat dua tetapan tahap permintaan. Tetapan pertama - gunakan cache yang tidak dimampatkan - termasuk penggunaannya. Adalah disyorkan untuk mendayakannya untuk semua permintaan, kecuali yang berat, yang boleh membaca semua data dan mengepam cache. Dan tetapan kedua adalah seperti bilangan baris maksimum untuk menggunakan cache. Ia secara automatik mengehadkan pertanyaan besar supaya mereka memintas cache.
Bagaimanakah saya boleh mengkonfigurasi storage_configuration untuk penyimpanan dalam RAM?
Dalam dokumentasi ClickHouse baharu saya membaca bahagian yang berkaitan . Penerangan mengandungi contoh dengan SSD pantas.
Saya tertanya-tanya bagaimana perkara yang sama boleh dikonfigurasikan dengan memori panas kelantangan. Dan satu lagi soalan. Bagaimanakah pilihan berfungsi dengan organisasi data ini, adakah ia akan membaca keseluruhan set atau hanya satu yang ada pada cakera, dan adakah data ini dimampatkan dalam memori? Dan bagaimanakah bahagian prewhere berfungsi dengan organisasi data sedemikian?
Tetapan ini menjejaskan storan ketulan data, dan formatnya tidak berubah dalam apa jua cara.
Mari kita lihat lebih dekat.
Anda boleh mengkonfigurasi storan data dalam RAM. Semua yang dikonfigurasikan untuk cakera adalah laluannya. Anda mencipta partition tmpfs yang dipasang pada beberapa laluan dalam sistem fail. Anda menentukan laluan ini sebagai laluan untuk menyimpan data untuk partition paling hangat, kepingan data mula tiba dan ditulis di sana, semuanya baik-baik saja.
Tetapi saya tidak mengesyorkan melakukan ini kerana kebolehpercayaan yang rendah, walaupun jika anda mempunyai sekurang-kurangnya tiga replika di pusat data yang berbeza, maka ia mungkin. Jika apa-apa berlaku, data akan dipulihkan. Bayangkan pelayan tiba-tiba dimatikan dan dihidupkan semula. Pembahagian itu dipasang semula, tetapi tiada apa-apa di situ. Apabila pelayan ClickHouse bermula, ia melihat bahawa ia tidak mempunyai kepingan ini, walaupun, menurut metadata ZooKeeper, ia sepatutnya berada di sana. Dia melihat replika mana yang mempunyainya, memintanya dan memuat turunnya. Dengan cara ini data akan dipulihkan.
Dalam pengertian ini, menyimpan data dalam RAM tidak secara asasnya berbeza daripada menyimpannya pada cakera, kerana apabila data ditulis ke cakera, ia juga mula-mula berakhir dalam cache halaman dan ditulis secara fizikal kemudian. Ini bergantung pada pilihan pemasangan sistem fail. Tetapi untuk berjaga-jaga, saya akan mengatakan bahawa ClickHouse tidak menyegerakkan apabila memasukkan.
Dalam kes ini, data dalam RAM disimpan dalam format yang sama seperti pada cakera. Pertanyaan pilih dengan cara yang sama memilih kepingan yang perlu dibaca, memilih julat data yang diperlukan dalam kepingan dan membacanya. Dan prewhere berfungsi sama, tidak kira sama ada data berada dalam RAM atau pada cakera.
Sehingga berapakah bilangan nilai unik yang Kardinaliti Rendah berkesan?
Kardinaliti Rendah direka dengan bijak. Ia menyusun kamus data, tetapi ia adalah tempatan. Pertama, terdapat kamus yang berbeza untuk setiap bahagian, dan kedua, walaupun dalam satu bahagian mereka boleh berbeza untuk setiap julat. Apabila bilangan nilai unik mencecah nombor ambang—satu juta, saya rasa—kamus hanya disimpan dan yang baharu dicipta.
Jawapannya secara umum: untuk setiap julat tempatan - katakan, untuk setiap hari - di suatu tempat sehingga satu juta nilai unik Low Cardinality berkesan. Selepas itu, hanya terdapat sandaran, di mana banyak kamus yang berbeza akan digunakan, dan bukan hanya satu. Ia akan berfungsi lebih kurang sama seperti lajur rentetan biasa, mungkin sedikit kurang cekap, tetapi tidak akan berlaku kemerosotan prestasi yang serius.
Apakah amalan terbaik untuk carian teks penuh jadual dengan lima bilion baris?
Terdapat jawapan yang berbeza. Yang pertama ialah mengatakan bahawa ClickHouse bukanlah enjin carian teks penuh. Terdapat sistem khas untuk ini, sebagai contoh, и . Walau bagaimanapun, saya semakin melihat orang yang mengatakan bahawa mereka beralih daripada Elasticsearch kepada ClickHouse.
Mengapa ini berlaku? Mereka menjelaskan ini dengan fakta bahawa Elasticsearch tidak lagi menampung beban pada beberapa jilid, bermula dengan pembinaan indeks. Indeks menjadi terlalu rumit, dan jika anda hanya memindahkan data ke ClickHouse, ternyata ia disimpan beberapa kali lebih cekap dari segi volum. Pada masa yang sama, pertanyaan carian selalunya tidak seperti yang diperlukan untuk mencari beberapa frasa dalam keseluruhan volum data, dengan mengambil kira morfologi, tetapi yang sama sekali berbeza. Sebagai contoh, cari beberapa jujukan bait dalam log selama beberapa jam yang lalu.
Dalam kes ini, anda membuat indeks dalam ClickHouse, medan pertama yang akan menjadi tarikh dan masa. Dan pemotongan data terbesar akan berdasarkan julat tarikh. Dalam julat tarikh yang dipilih, sebagai peraturan, anda boleh melakukan carian teks penuh, walaupun menggunakan kaedah kekerasan menggunakan suka. Pengendali seperti dalam ClickHouse adalah pengendali seperti yang paling cekap yang anda boleh temui. Jika anda mendapati sesuatu yang lebih baik, beritahu saya.
Tetapi masih, seperti adalah imbasan penuh. Dan imbasan penuh boleh menjadi perlahan bukan sahaja pada CPU, tetapi juga pada cakera. Jika tiba-tiba anda mempunyai satu terabait data setiap hari, dan anda mencari perkataan pada siang hari, maka anda perlu mengimbas terabait. Dan ia mungkin pada pemacu keras biasa, dan pada akhirnya ia akan dimuatkan sedemikian rupa sehingga anda tidak akan dapat mengakses pelayan ini melalui SSH.
Dalam kes ini, saya bersedia untuk menawarkan satu lagi helah kecil. Ini percubaan - mungkin berkesan, mungkin tidak. ClickHouse mempunyai indeks teks penuh dalam bentuk penapis Bloom trigram. Rakan sekerja kami di Arenadata telah pun mencuba indeks ini dan selalunya ia berfungsi tepat seperti yang dimaksudkan.
Untuk menggunakannya dengan betul, anda harus mempunyai pemahaman yang baik tentang cara ia berfungsi: apakah penapis Bloom trigram dan cara memilih saiznya. Saya boleh mengatakan bahawa mereka akan membantu untuk pertanyaan tentang beberapa frasa yang jarang ditemui, subrentetan yang jarang ditemui dalam data. Dalam kes ini, subjulat akan dipilih mengikut indeks dan kurang data akan dibaca.
Baru-baru ini, ClickHouse telah menambah fungsi yang lebih maju untuk carian teks penuh. Ini, pertama sekali, carian untuk sekumpulan subrentetan sekali gus dalam satu laluan, termasuk pilihan yang sensitif huruf besar-besaran, tidak sensitif huruf besar-besaran, dengan sokongan untuk UTF-8 atau hanya untuk ASCII. Pilih yang paling berkesan yang anda perlukan.
Carian untuk berbilang ungkapan biasa dalam satu laluan juga telah muncul. Anda tidak perlu menulis X seperti satu subrentetan atau X seperti subrentetan lain. Anda menulis serta-merta, dan segala-galanya dilakukan dengan cekap yang mungkin.
Ketiga, kini terdapat carian anggaran untuk regexps dan carian anggaran untuk subrentetan. Jika seseorang tersilap mengeja perkataan, ia akan dicari untuk padanan maksimum.
Apakah cara terbaik untuk mengatur akses kepada ClickHouse untuk sebilangan besar pengguna?
Beritahu kami cara terbaik untuk mengatur akses untuk sebilangan besar pengguna dan penganalisis. Bagaimana untuk membentuk baris gilir, mengutamakan pertanyaan serentak maks, dan dengan alatan apa?
Jika klusternya cukup besar, maka penyelesaian yang baik adalah dengan menaikkan dua lagi pelayan, yang akan menjadi titik masuk untuk penganalisis. Iaitu, jangan benarkan penganalisis mengakses serpihan tertentu dalam kelompok, tetapi hanya buat dua pelayan kosong, tanpa data, dan konfigurasikan hak akses padanya. Dalam kes ini, tetapan pengguna untuk permintaan yang diedarkan dipindahkan ke pelayan jauh. Iaitu, anda mengkonfigurasi segala-galanya pada kedua-dua pelayan ini, dan tetapan mempunyai kesan pada keseluruhan kluster.
Pada dasarnya, pelayan ini tidak mempunyai data, tetapi jumlah RAM padanya sangat penting untuk melaksanakan permintaan. Cakera juga boleh digunakan untuk data sementara jika pengagregatan luaran atau pengisihan luaran didayakan.
Adalah penting untuk melihat tetapan yang dikaitkan dengan semua had yang mungkin. Jika saya sekarang pergi ke kelompok Yandex.Metrica sebagai penganalisis dan meminta permintaan pilih kiraan daripada hits, maka saya akan segera diberi pengecualian bahawa saya tidak boleh melaksanakan permintaan itu. Bilangan maksimum baris yang saya dibenarkan untuk mengimbas ialah seratus bilion, dan secara keseluruhan terdapat lima puluh trilion daripadanya dalam satu jadual pada gugusan. Ini adalah had pertama.
Katakan saya mengalih keluar had baris dan menjalankan pertanyaan semula. Kemudian saya akan melihat pengecualian berikut - tetapan didayakan indeks paksa mengikut tarikh. Saya tidak dapat melengkapkan pertanyaan jika saya belum menentukan julat tarikh. Anda tidak perlu bergantung pada penganalisis untuk menentukannya secara manual. Kes biasa ialah apabila julat tarikh ditulis di mana tarikh acara antara minggu. Dan kemudian mereka hanya menentukan kurungan di tempat yang salah, dan bukannya dan ia ternyata menjadi atau - atau padanan URL. Jika tiada had, ia akan merangkak lajur URL dan hanya membazirkan satu tan sumber.
Di samping itu, ClickHouse mempunyai dua tetapan keutamaan. Malangnya, mereka sangat primitif. Satu hanya dipanggil keutamaan. Jika keutamaan ≠ 0, dan permintaan dengan beberapa keutamaan sedang dilaksanakan, tetapi permintaan dengan nilai keutamaan kurang daripada, yang bermaksud keutamaan lebih tinggi, sedang dilaksanakan, maka permintaan dengan nilai keutamaan lebih besar, yang bermaksud keutamaan lebih rendah , hanya digantung dan tidak akan berfungsi sama sekali pada masa ini.
Ini adalah tetapan yang sangat kasar dan tidak sesuai untuk kes di mana kluster mempunyai beban tetap. Tetapi jika anda mempunyai permintaan yang pendek dan meletop yang penting, dan kluster kebanyakannya melahu, persediaan ini sesuai.
Tetapan keutamaan seterusnya dipanggil Keutamaan benang OS. Ia hanya menetapkan nilai bagus untuk semua urutan pelaksanaan permintaan untuk penjadual Linux. Ia berfungsi begitu-begitu, tetapi ia masih berfungsi. Jika anda menetapkan nilai bagus minimum - ia adalah nilai terbesar, dan oleh itu keutamaan terendah - dan tetapkan -19 untuk permintaan dengan keutamaan tinggi, maka CPU akan menggunakan permintaan keutamaan rendah kira-kira empat kali kurang daripada permintaan keutamaan tinggi.
Anda juga perlu mengkonfigurasi masa pelaksanaan permintaan maksimum - katakan, lima minit. Kelajuan minimum pelaksanaan pertanyaan adalah perkara yang paling hebat. Tetapan ini telah wujud sejak sekian lama, dan ia diperlukan bukan sahaja untuk menegaskan bahawa ClickHouse tidak memperlahankan, tetapi untuk memaksanya.
Bayangkan, anda menyediakan: jika beberapa pertanyaan memproses kurang daripada satu juta baris sesaat, anda tidak boleh melakukannya. Ini memalukan nama baik kami, pangkalan data kami yang baik. Mari kita larang ini. Sebenarnya ada dua tetapan. Satu dipanggil kelajuan pelaksanaan min - dalam baris sesaat, dan yang kedua dipanggil tamat masa sebelum menyemak kelajuan pelaksanaan min - lima belas saat secara lalai. Iaitu, lima belas saat adalah mungkin, dan kemudian, jika ia perlahan, maka hanya buang pengecualian dan batalkan permintaan itu.
Anda juga perlu menyediakan kuota. ClickHouse mempunyai ciri kuota terbina dalam yang mengira penggunaan sumber. Tetapi, malangnya, bukan sumber perkakasan seperti CPU, cakera, tetapi yang logik - bilangan permintaan yang diproses, baris dan bait dibaca. Dan anda boleh mengkonfigurasi, sebagai contoh, maksimum seratus permintaan dalam masa lima minit dan seribu permintaan sejam.
Mengapa ia penting? Kerana beberapa pertanyaan analitik akan dilakukan secara manual terus daripada klien ClickHouse. Dan semuanya akan baik-baik saja. Tetapi jika anda mempunyai penganalisis lanjutan dalam syarikat anda, mereka akan menulis skrip, dan mungkin terdapat ralat dalam skrip. Dan ralat ini akan menyebabkan permintaan dilaksanakan dalam gelung tak terhingga. Inilah yang kita perlukan untuk melindungi diri kita daripada.
Adakah mungkin untuk memberikan hasil satu pertanyaan kepada sepuluh pelanggan?
Kami mempunyai beberapa pengguna yang suka datang dengan permintaan yang sangat besar pada masa yang sama. Permintaan itu besar dan, pada dasarnya, dilaksanakan dengan cepat, tetapi disebabkan fakta bahawa terdapat banyak permintaan sedemikian pada masa yang sama, ia menjadi sangat menyakitkan. Adakah mungkin untuk melaksanakan permintaan yang sama, yang tiba sepuluh kali berturut-turut, sekali, dan memberikan hasilnya kepada sepuluh pelanggan?
Masalahnya ialah kami tidak mempunyai keputusan cache atau cache data perantaraan. Terdapat cache halaman sistem pengendalian, yang akan menghalang anda daripada membaca data dari cakera sekali lagi, tetapi, malangnya, data masih akan dinyahmampat, dinyahsiri dan diproses semula.
Saya entah bagaimana ingin mengelak perkara ini, sama ada dengan menyimpan data perantaraan dalam cache, atau dengan menyusun pertanyaan serupa dalam beberapa jenis baris gilir dan menambah cache hasil. Pada masa ini kami mempunyai satu permintaan tarik dalam pembangunan yang menambah cache permintaan, tetapi hanya untuk subkueri dalam bahagian masuk dan sertai - iaitu penyelesaiannya tidak lengkap.
Namun, kita juga menghadapi situasi sedemikian. Contoh kanonik khususnya adalah pertanyaan bernombor. Terdapat laporan, ia mempunyai beberapa halaman, dan terdapat permintaan untuk had 10. Kemudian perkara yang sama, tetapi hadkan 10,10. Kemudian satu lagi halaman seterusnya. Dan persoalannya, mengapa kita mengira semua ini setiap masa? Tetapi sekarang tidak ada penyelesaian, dan tidak ada cara untuk mengelakkannya.
Terdapat penyelesaian alternatif yang diletakkan sebagai sidecar di sebelah ClickHouse - .
Kirill Shvakov: ClickHouse Proxy mempunyai pengehad kadar terbina dalam dan cache hasil terbina dalam. Banyak tetapan telah dibuat di sana kerana masalah yang sama sedang diselesaikan. Proksi membolehkan anda mengehadkan permintaan dengan beratur dan mengkonfigurasi tempoh cache permintaan itu hidup. Jika permintaan itu benar-benar sama, Proksi akan menghantarnya berkali-kali, tetapi akan pergi ke ClickHouse sekali sahaja.
Nginx juga mempunyai cache dalam versi percuma, dan ini juga akan berfungsi. Nginx juga mempunyai tetapan yang jika permintaan tiba pada masa yang sama, ia akan melambatkan yang lain sehingga satu selesai. Tetapi dalam ClickHouse Proxy bahawa persediaan dilakukan dengan lebih baik. Ia dibuat khusus untuk ClickHouse, khusus untuk permintaan ini, jadi ia lebih sesuai. Nah, ia mudah dipasang.
Bagaimana pula dengan operasi tak segerak dan pandangan terwujud?
Terdapat masalah bahawa operasi dengan enjin main semula adalah tidak segerak - pertama data ditulis, kemudian ia runtuh. Jika tablet terwujud dengan beberapa agregat tinggal di bawah tanda, maka pendua akan ditulis kepadanya. Dan jika tidak ada logik yang kompleks, maka data akan diduplikasi. Apa yang boleh anda lakukan mengenainya?
Terdapat penyelesaian yang jelas - untuk melaksanakan pencetus pada kelas matview tertentu semasa operasi runtuh tak segerak. Adakah terdapat sebarang peluru perak atau rancangan untuk melaksanakan fungsi yang serupa?
Anda perlu memahami cara penyahduplikasian berfungsi. Apa yang saya akan beritahu anda sekarang tidak berkaitan dengan soalan itu, tetapi sekiranya ia patut diingati.
Apabila memasukkan ke dalam jadual yang direplikasi, terdapat penyahduplikasian keseluruhan blok yang dimasukkan. Jika anda memasukkan semula blok yang sama yang mengandungi bilangan baris yang sama dalam susunan yang sama, maka data akan dinyahduplikasi. Anda akan menerima "Ok" sebagai tindak balas untuk memasukkan, tetapi sebenarnya satu paket data akan ditulis, dan ia tidak akan diduplikasi.
Ini perlu untuk kepastian. Jika anda menerima "Ok" semasa memasukkan, maka data anda telah dimasukkan. Jika anda menerima ralat daripada ClickHouse, ini bermakna ia tidak dimasukkan dan anda perlu mengulangi sisipan. Tetapi jika sambungan terputus semasa memasukkan, maka anda tidak tahu sama ada data telah dimasukkan atau tidak. Satu-satunya pilihan ialah mengulangi sisipan sekali lagi. Jika data sebenarnya telah dimasukkan dan anda memasukkannya semula, terdapat penyahduplikasian blok. Ini diperlukan untuk mengelakkan pendua.
Dan ia juga penting cara ia berfungsi untuk pandangan terwujud. Jika data telah dinyahduplikasi apabila dimasukkan ke dalam jadual utama, maka data itu tidak akan masuk ke paparan terwujud sama ada.
Sekarang tentang soalan. Keadaan anda lebih rumit kerana anda merakam pendua baris individu. Iaitu, bukan keseluruhan pek yang diduplikasi, tetapi baris tertentu, dan ia runtuh di latar belakang. Sesungguhnya, data akan runtuh dalam jadual utama, tetapi data yang tidak runtuh akan pergi ke paparan terwujud, dan semasa penggabungan tiada apa-apa yang akan berlaku kepada paparan terwujud. Kerana pandangan yang terwujud tidak lebih daripada pencetus sisipan. Semasa operasi lain, tiada tambahan berlaku kepadanya.
Dan saya tidak boleh membuat anda gembira di sini. Anda hanya perlu mencari penyelesaian khusus untuk kes ini. Sebagai contoh, adakah mungkin untuk memainkannya semula dalam paparan terwujud, dan kaedah penyahduplikasian mungkin berfungsi dengan cara yang sama. Tetapi malangnya, tidak selalu. Jika ia diagregatkan, ia tidak akan berfungsi.
Kirill Shvakov: Kami juga mempunyai pembinaan tongkat pada masa itu. Terdapat masalah bahawa terdapat tera pengiklanan dan terdapat beberapa data yang boleh kami tunjukkan dalam masa nyata - ini hanyalah tera. Ia jarang diduplikasi, tetapi jika ini berlaku, kami akan meruntuhkannya kemudian. Dan terdapat perkara yang tidak boleh diduplikasi - klik dan keseluruhan cerita ini. Tetapi saya juga ingin menunjukkan kepada mereka dengan segera.
Bagaimanakah pandangan terwujud dibuat? Terdapat pandangan di mana ia ditulis secara langsung - ia ditulis kepada data mentah, dan ditulis kepada paparan. Di sana, pada satu ketika data tidak begitu betul, ia diduplikasi, dan sebagainya. Dan terdapat bahagian kedua jadual, di mana mereka kelihatan sama seperti pandangan yang terwujud, iaitu, mereka benar-benar serupa dalam struktur. Sekali-sekala kami mengira semula data, mengira data tanpa pendua, menulis pada jadual tersebut.
Kami telah melalui API - ini tidak akan berfungsi dalam ClickHouse secara manual. Dan API kelihatan: apabila saya mempunyai tarikh penambahan terakhir pada jadual, di mana ia dijamin bahawa data yang betul telah dikira, dan ia membuat permintaan ke satu jadual dan ke jadual lain. Dari satu permintaan memilih sehingga jumlah masa tertentu, dan dari yang lain ia mendapat apa yang belum dikira. Dan ia berfungsi, tetapi bukan melalui ClickHouse sahaja.
Jika anda mempunyai beberapa jenis API - untuk penganalisis, untuk pengguna - maka, pada dasarnya, ini adalah pilihan. Anda sentiasa mengira, sentiasa mengira. Ini boleh dilakukan sekali sehari atau pada masa lain. Anda memilih sendiri julat yang anda tidak perlukan dan tidak kritikal.
ClickHouse mempunyai banyak log. Bagaimanakah saya boleh melihat semua yang berlaku pada pelayan sepintas lalu?
ClickHouse mempunyai bilangan log berbeza yang sangat besar, dan jumlah ini semakin meningkat. Dalam versi baharu, sesetengah daripadanya didayakan secara lalai; dalam versi lama ia mesti didayakan semasa mengemas kini. Walau bagaimanapun, terdapat lebih banyak daripada mereka. Akhirnya, saya ingin melihat apa yang berlaku dengan pelayan saya sekarang, mungkin pada beberapa jenis papan pemuka ringkasan.
Adakah anda ada dalam pasukan ClickHouse anda, atau dalam pasukan rakan anda, yang menyokong beberapa fungsi papan pemuka siap sedia yang akan memaparkan log ini sebagai produk siap pakai? Akhirnya, hanya melihat log dalam ClickHouse adalah hebat. Tetapi ia akan menjadi sangat sejuk jika ia sudah disediakan dalam bentuk papan pemuka. Saya akan mendapat sepakan daripadanya.
Terdapat papan pemuka, walaupun ia tidak diseragamkan. Dalam syarikat kami, kira-kira 60 pasukan menggunakan ClickHouse, dan perkara yang paling pelik ialah kebanyakan mereka mempunyai papan pemuka yang mereka buat untuk diri mereka sendiri, dan yang sedikit berbeza. Sesetengah pasukan menggunakan pemasangan Yandex.Cloud dalaman. Terdapat beberapa laporan yang telah siap, walaupun tidak semua yang diperlukan. Yang lain ada sendiri.
Rakan sekerja saya dari Metrica mempunyai papan pemuka mereka sendiri di Grafana, dan saya mempunyai papan pemuka sendiri untuk kelompok mereka. Saya melihat perkara seperti cache hit untuk cache serif. Dan yang lebih sukar ialah kita menggunakan alat yang berbeza. Saya mencipta papan pemuka saya menggunakan alat yang sangat lama yang dipanggil Graphite-web. Dia benar-benar hodoh. Dan saya masih menggunakannya dengan cara ini, walaupun Grafana mungkin lebih mudah dan cantik.
Perkara asas dalam papan pemuka adalah sama. Ini adalah metrik sistem untuk kluster: CPU, memori, cakera, rangkaian. Lain-lain - bilangan permintaan serentak, bilangan cantuman serentak, bilangan permintaan sesaat, bilangan maksimum ketulan untuk partition jadual MergeTree, ketinggalan replikasi, saiz baris gilir replikasi, bilangan baris yang dimasukkan sesaat, bilangan blok yang dimasukkan sesaat. Ini sahaja yang diperolehi bukan daripada log, tetapi daripada metrik.
Vladimir Kolobaev: Alexey, saya ingin membetulkannya sedikit. Terdapat Grafana. Grafana mempunyai sumber data, iaitu ClickHouse. Maksudnya, saya boleh membuat permintaan daripada Grafana terus ke ClickHouse. ClickHouse mempunyai jadual dengan log, ia adalah sama untuk semua orang. Akibatnya, saya ingin mengakses jadual log ini dalam Grafana dan melihat permintaan yang dibuat oleh pelayan saya. Alangkah bagusnya jika ada papan pemuka seperti ini.
Saya mengayuhnya sendiri. Tetapi saya mempunyai soalan - jika semuanya diseragamkan, dan Grafana digunakan oleh semua orang, mengapa Yandex tidak mempunyai papan pemuka rasmi sedemikian?
Kirill Shvakov: Malah, sumber data yang pergi ke ClickHouse kini menyokong Altinity. Dan saya hanya ingin memberikan vektor tempat untuk menggali dan siapa yang hendak ditolak. Anda boleh bertanya kepada mereka, kerana Yandex masih membuat ClickHouse, dan bukan cerita di sekelilingnya. Altinity ialah syarikat utama yang sedang mempromosikan ClickHouse. Mereka tidak akan meninggalkannya, tetapi akan menyokongnya. Kerana, pada dasarnya, untuk memuat naik papan pemuka ke laman web Grafana, anda hanya perlu mendaftar dan memuat naiknya - tidak ada masalah khusus.
Alexey Milovidov: Sepanjang tahun lalu, ClickHouse telah menambah banyak keupayaan pemprofilan pertanyaan. Terdapat metrik untuk setiap permintaan tentang penggunaan sumber. Dan baru-baru ini, kami menambah pemprofil pertanyaan peringkat lebih rendah untuk melihat di mana pertanyaan menghabiskan setiap milisaat. Tetapi untuk menggunakan fungsi ini, saya perlu membuka klien konsol dan menaip permintaan, yang saya selalu lupa. Saya menyimpannya di suatu tempat dan terus lupa di mana sebenarnya.
Saya harap ada alat yang hanya berkata, berikut adalah pertanyaan berat anda, dikumpulkan mengikut kelas pertanyaan. Saya menekan satu, dan mereka akan memberitahu saya bahawa itulah sebabnya ia berat. Tiada penyelesaian sedemikian sekarang. Dan sungguh pelik apabila orang bertanya kepada saya: "Beritahu saya, adakah papan pemuka siap sedia untuk Grafana?", Saya berkata: "Pergi ke tapak web Grafana, terdapat komuniti "Papan Pemuka", dan terdapat papan pemuka dari Dimka, terdapat papan pemuka dari Kostyan. Saya tidak tahu apa itu, saya tidak menggunakannya sendiri."
Bagaimana untuk mempengaruhi gabungan supaya pelayan tidak merempuh OOM?
Saya mempunyai jadual, hanya terdapat satu partition dalam jadual, ia adalah ReplacingMergeTree. Saya telah menulis data ke dalamnya selama empat tahun. Saya perlu membuat perubahan di dalamnya dan memadam beberapa data.
Saya melakukan ini, dan semasa pemprosesan permintaan ini, semua memori pada semua pelayan dalam kelompok telah digunakan, dan semua pelayan dalam kelompok masuk ke OOM. Kemudian mereka semua bangun bersama-sama, mula menggabungkan operasi yang sama ini, blok data ini, dan jatuh ke dalam OOM semula. Kemudian mereka bangun semula dan jatuh semula. Dan perkara ini tidak berhenti.
Kemudian ternyata ini sebenarnya pepijat yang diperbaiki oleh lelaki itu. Ini sangat keren, terima kasih banyak. Tetapi sisa kekal. Dan sekarang, apabila saya berfikir tentang membuat beberapa jenis cantuman dalam jadual, saya mempunyai soalan - mengapa saya tidak boleh mempengaruhi gabungan ini? Sebagai contoh, hadkan mereka dengan jumlah RAM yang diperlukan, atau, pada dasarnya, dengan jumlah yang akan memproses jadual tertentu ini.
Saya mempunyai jadual yang dipanggil "Metrik", sila proses untuk saya dalam dua urutan. Tidak perlu membuat sepuluh atau lima gabungan secara selari, lakukan dalam dua. Saya fikir saya mempunyai ingatan yang mencukupi untuk dua orang, tetapi ia mungkin tidak mencukupi untuk memproses sepuluh. Mengapa ketakutan kekal? Kerana jadual semakin berkembang, dan suatu hari nanti saya akan berhadapan dengan situasi yang, pada dasarnya, bukan lagi disebabkan oleh pepijat, tetapi kerana data akan berubah dalam jumlah yang besar sehingga saya tidak akan mempunyai cukup memori pada pelayan. Dan kemudian pelayan akan ranap ke OOM apabila bergabung. Lebih-lebih lagi, saya boleh membatalkan mutasi, tetapi Merji sudah tiada.
Anda tahu, apabila menggabungkan, pelayan tidak akan jatuh ke dalam OOM, kerana apabila menggabungkan, jumlah RAM digunakan hanya untuk satu julat data yang kecil. Jadi semuanya akan baik-baik saja tanpa mengira jumlah data.
Vladimir Kolobaev: baik. Di sini masa ini sedemikian rupa sehingga selepas pepijat diperbaiki, saya memuat turun versi baharu untuk diri saya sendiri, dan di atas meja lain, yang lebih kecil, di mana terdapat banyak partition, saya melakukan operasi yang sama. Dan semasa penggabungan, kira-kira 100 GB RAM telah dibakar pada pelayan. Saya telah menduduki 150, 100 dimakan dan tetingkap 50 GB tinggal, jadi saya tidak jatuh ke dalam OOM.
Apakah pada masa ini yang melindungi saya daripada jatuh ke dalam OOM jika ia benar-benar menggunakan 100 GB RAM? Apa yang perlu dilakukan jika tiba-tiba RAM pada gabungan kehabisan?
Alexey Milovidov: Terdapat masalah sedemikian sehingga penggunaan RAM khusus untuk penggabungan tidak terhad. Dan masalah kedua ialah jika beberapa jenis gabungan telah ditetapkan, maka ia mesti dilaksanakan kerana ia direkodkan dalam log replikasi. Log replikasi ialah tindakan yang diperlukan untuk membawa replika ke dalam keadaan yang konsisten. Jika anda tidak membuat manipulasi manual yang akan melancarkan log replikasi ini, cantuman perlu dilakukan satu cara atau yang lain.
Sudah tentu, ia tidak akan berlebihan untuk mempunyai had RAM yang "sekira-kiranya" melindungi daripada OOM. Ia tidak akan membantu penggabungan untuk diselesaikan, ia akan bermula semula, mencapai beberapa ambang, membuang pengecualian, dan kemudian bermula semula - tiada apa yang baik akan datang daripada ini. Tetapi pada dasarnya, adalah berguna untuk memperkenalkan sekatan ini.
Bagaimanakah pemacu Golang untuk ClickHouse akan dibangunkan?
Pemandu Golang, yang ditulis oleh Kirill Shvakov, kini disokong secara rasmi oleh pasukan ClickHouse. Dia , dia kini sudah besar dan nyata.
Nota kecil. Terdapat repositori yang indah dan digemari bagi bentuk biasa susunan tak terhingga - ini ialah Vertica. Mereka juga mempunyai pemandu python rasmi mereka sendiri, yang disokong oleh pembangun Vertica. Dan beberapa kali ia berlaku bahawa versi storan dan versi pemacu menyimpang agak dramatik, dan pemandu pada satu ketika berhenti bekerja. Dan titik kedua. Sokongan untuk pemandu rasmi ini, nampaknya saya, dijalankan oleh sistem "puting" - anda menulis masalah kepada mereka, dan ia akan bertahan selama-lamanya.
Saya ada dua soalan. Kini pemandu Golang Kirill hampir menjadi cara lalai untuk berkomunikasi dari Golang dengan ClickHouse. Melainkan seseorang masih berkomunikasi melalui antara muka http kerana dia suka dengan cara itu. Bagaimanakah perkembangan pemandu ini akan diteruskan? Adakah ia akan disegerakkan dengan sebarang perubahan pecah dalam repositori itu sendiri? Dan apakah prosedur untuk mempertimbangkan sesuatu isu?
Kirill Shvakov: Yang pertama ialah bagaimana semuanya diatur secara birokrasi. Perkara ini tidak dibincangkan, jadi saya tidak mempunyai apa-apa untuk menjawab.
Untuk menjawab soalan mengenai isu tersebut, kami memerlukan sedikit sejarah pemandu. Saya bekerja untuk sebuah syarikat yang mempunyai banyak data. Ia adalah pemutar pengiklanan dengan sejumlah besar acara yang perlu disimpan di suatu tempat. Dan pada satu ketika ClickHouse muncul. Kami mengisinya dengan data, dan pada mulanya semuanya baik-baik saja, tetapi kemudian ClickHouse ranap. Pada masa itu kami memutuskan bahawa kami tidak memerlukannya.
Setahun kemudian, kami kembali kepada idea menggunakan ClickHouse, dan kami perlu menulis data di sana entah bagaimana. Mesej pengenalan adalah ini: perkakasan sangat lemah, terdapat sedikit sumber. Tetapi kami sentiasa bekerja dengan cara ini, dan oleh itu kami melihat ke arah protokol asli.
Memandangkan kami bekerja di Go, adalah jelas bahawa kami memerlukan pemandu Go. Saya melakukannya hampir sepenuh masa - ia adalah tugas kerja saya. Kami membawanya ke titik tertentu, dan pada dasarnya tiada siapa yang menganggap bahawa orang lain selain kami akan menggunakannya. Kemudian CloudFlare datang dengan masalah yang sama, dan untuk beberapa lama kami bekerja dengan mereka dengan sangat lancar, kerana mereka mempunyai tugas yang sama. Lebih-lebih lagi, kami melakukan ini dalam ClickHouse sendiri dan dalam pemandu.
Pada satu ketika, saya berhenti melakukannya, kerana aktiviti saya dari segi ClickHouse dan kerja berubah sedikit. Oleh itu isu tidak ditutup. Secara berkala, orang yang memerlukan sesuatu sendiri komited ke repositori. Kemudian saya melihat permintaan tarik dan kadang-kadang saya mengedit sesuatu sendiri, tetapi ini jarang berlaku.
Saya mahu kembali kepada pemandu. Beberapa tahun yang lalu, apabila semuanya bermula, ClickHouse juga berbeza dan dengan keupayaan yang berbeza. Kini kami mempunyai pemahaman tentang cara membuat semula pemandu supaya ia berfungsi dengan baik. Jika ini berlaku, maka versi 2 akan menjadi tidak serasi dalam apa jua keadaan kerana tongkat terkumpul.
Saya tidak tahu bagaimana untuk mengatur perkara ini. Saya sendiri tidak mempunyai banyak masa. Jika sesetengah orang menyelesaikan pemandu, saya boleh membantu mereka dan memberitahu mereka apa yang perlu dilakukan. Tetapi penyertaan aktif Yandex dalam pembangunan projek itu belum lagi dibincangkan.
Alexey Milovidov: Malah, belum ada birokrasi mengenai pemandu ini. Satu-satunya perkara ialah mereka diserahkan kepada organisasi rasmi, iaitu pemandu ini diiktiraf sebagai penyelesaian lalai rasmi untuk Go. Terdapat beberapa pemandu lain, tetapi mereka datang secara berasingan.
Kami tidak mempunyai sebarang pembangunan dalaman untuk pemandu ini. Persoalannya ialah sama ada kita boleh mengupah seorang individu, bukan untuk pemandu tertentu ini, tetapi untuk pembangunan semua pemandu komuniti, atau bolehkah kita mencari seseorang dari luar.
Kamus luaran tidak dimuatkan selepas but semula dengan tetapan lazy_load didayakan. Apa nak buat?
Kami mempunyai tetapan lazy_load didayakan, dan selepas pelayan dibut semula, kamus tidak dimuatkan dengan sendirinya. Ia dibangkitkan hanya selepas pengguna mengakses kamus ini. Dan kali pertama saya mengaksesnya, ia memberikan ralat. Adakah mungkin untuk memuatkan kamus secara automatik menggunakan ClickHouse, atau adakah anda perlu sentiasa mengawal kesediaan mereka sendiri supaya pengguna tidak menerima ralat?
Mungkin kami mempunyai versi lama ClickHouse, jadi kamus tidak dimuatkan secara automatik. Mungkinkah ini berlaku?
Pertama, kamus boleh dimuatkan secara paksa menggunakan pertanyaan kamus muat semula sistem. Kedua, mengenai ralat - jika kamus sudah dimuatkan, maka pertanyaan akan berfungsi berdasarkan data yang dimuatkan. Jika kamus masih belum dimuatkan, ia akan dimuatkan terus semasa permintaan.
Ini tidak begitu mudah untuk kamus berat. Sebagai contoh, anda perlu menarik sejuta baris daripada MySQL. Seseorang membuat pilihan mudah, tetapi pilihan ini akan menunggu sejuta baris yang sama. Terdapat dua penyelesaian di sini. Yang pertama ialah mematikan lazy_load. Kedua, apabila pelayan sudah siap, sebelum meletakkan beban padanya, lakukan kamus muat semula sistem atau hanya buat pertanyaan yang menggunakan kamus. Kemudian kamus akan dimuatkan. Anda perlu mengawal ketersediaan kamus dengan tetapan lazy_load didayakan, kerana ClickHouse tidak memuatkannya secara automatik.
Jawapan kepada soalan terakhir adalah sama ada versi sudah lama atau ia perlu dinyahpepijat.
Apa yang perlu dilakukan dengan fakta bahawa kamus muat semula sistem tidak memuatkan mana-mana daripada banyak kamus jika sekurang-kurangnya satu daripadanya ranap dengan ralat?
Terdapat satu lagi soalan mengenai kamus muat semula sistem. Kami mempunyai dua kamus - satu tidak dimuatkan, yang kedua dimuatkan. Dalam kes ini, kamus muat semula sistem tidak memuatkan sebarang kamus dan anda perlu memuatkan satu demi satu kamus tertentu dengan namanya menggunakan kamus muat semula sistem. Adakah ini juga berkaitan dengan versi ClickHouse?
Saya nak bahagiakan awak. Tingkah laku ini berubah. Ini bermakna jika anda mengemas kini ClickHouse, ia juga akan berubah. Jika anda tidak berpuas hati dengan tingkah laku anda sekarang kamus muat semula sistem, kemas kini dan semoga ia berubah menjadi lebih baik.
Adakah terdapat cara untuk mengkonfigurasi butiran dalam konfigurasi ClickHouse, tetapi tidak memaparkannya sekiranya berlaku ralat?
Soalan seterusnya ialah tentang kesalahan berkaitan kamus iaitu perincian. Kami telah menentukan butiran sambungan dalam konfigurasi ClickHouse untuk kamus, dan jika terdapat ralat, kami menerima butiran dan kata laluan ini sebagai tindak balas.
Kami menyelesaikan ralat ini dengan menambahkan butiran pada konfigurasi pemacu ODBC. Adakah terdapat sebarang cara untuk mengkonfigurasi butiran dalam konfigurasi ClickHouse, tetapi tidak menunjukkan butiran ini sekiranya berlaku ralat?
Penyelesaian sebenar di sini adalah untuk menentukan kelayakan ini dalam odbc.ini, dan dalam ClickHouse sendiri hanya tentukan Nama Sumber Data ODBC. Ini tidak akan berlaku untuk sumber kamus lain - tidak untuk kamus dengan MySQL, mahupun untuk yang lain, anda tidak sepatutnya melihat kata laluan apabila anda menerima mesej ralat. Untuk ODBC, saya juga akan melihat - jika ia wujud, anda hanya perlu mengalih keluarnya.
Bonus: latar belakang untuk Zum daripada perhimpunan
Dengan mengklik pada gambar, latar belakang bonus dari perhimpunan akan dibuka untuk pembaca yang paling gigih. Kami memadamkan api bersama-sama dengan maskot teknologi Avito, kami berbincang dengan rakan sekerja dari bilik pentadbir sistem atau kelab komputer sekolah lama, dan kami mengadakan mesyuarat harian di bawah jambatan dengan latar belakang grafiti.
Sumber: www.habr.com