Pada bulan April, para insinyur Avito berkumpul untuk pertemuan online dengan pengembang utama ClickHouse Alexei Milovidov dan Kirill Shvakov, pengembang Golang dari Integros. Kami membahas bagaimana kami menggunakan sistem manajemen basis data dan kesulitan apa yang kami temui.
Berdasarkan pertemuan tersebut, kami telah menyusun artikel dengan jawaban para ahli atas pertanyaan kami dan audiens tentang pencadangan, penataan ulang data, kamus eksternal, driver Golang, dan pembaruan versi ClickHouse. Ini mungkin berguna bagi pengembang yang sudah aktif bekerja dengan DBMS Yandex dan tertarik dengan masa kini dan masa depan. Secara default, jawabannya adalah oleh Alexei Milovidov, kecuali jika ditulis lain.
Hati-hati, ada banyak teks di bawah potongan. Kami berharap konten dengan pertanyaan akan membantu Anda menavigasi.
kadar
Jika Anda tidak ingin membaca teksnya, Anda dapat menonton rekaman pertemuan tersebut . Kode waktu ada di komentar pertama di bawah video.
ClickHouse terus diperbarui, tetapi data kami tidak. Apa yang harus dilakukan tentang hal itu?
ClickHouse terus diperbarui, dan data kami, yang dioptimalkan untuk pemrosesan akhir, tidak diperbarui dan berada dalam salinan cadangan.
Katakanlah kita mempunyai masalah dan datanya hilang. Kami memutuskan untuk memulihkan, dan ternyata partisi lama yang disimpan di server cadangan sangat berbeda dengan versi ClickHouse yang saat ini digunakan. Apa yang harus dilakukan dalam situasi seperti ini, dan apakah mungkin?
Situasi di mana Anda memulihkan data dari cadangan dalam format lama, tetapi tidak terhubung ke versi baru, adalah hal yang mustahil. Kami memastikan bahwa format data di ClickHouse selalu kompatibel. Ini jauh lebih penting daripada kompatibilitas fungsionalitas jika perilaku beberapa fungsi yang jarang digunakan telah berubah. ClickHouse versi baru harus selalu dapat membaca data yang disimpan di disk. Ini adalah hukumnya.
Apa praktik terbaik saat ini untuk membuat cadangan data dari ClickHouse?
Bagaimana cara membuat cadangan, dengan mempertimbangkan bahwa kami telah mengoptimalkan operasi akhir, database besar terabyte, dan data yang diperbarui, katakanlah, selama tiga hari terakhir, dan kemudian tidak ada prosedur yang terjadi?
Kita dapat membuat solusi kita sendiri dan menulis di bash: kumpulkan salinan cadangan ini dengan cara ini dan itu. Mungkin tidak perlu menggunakan kruk apa pun, dan sepeda sudah ditemukan sejak lama?
Mari kita mulai dengan praktik terbaik. Rekan-rekan saya selalu menyarankan, ketika menjawab pertanyaan tentang pencadangan, untuk mengingatkan mereka tentang layanan Yandex.Cloud, di mana masalah ini telah terpecahkan. Jadi gunakanlah jika memungkinkan.
Tidak ada solusi lengkap untuk pencadangan, yang seratus persen ada di ClickHouse. Ada beberapa blanko yang bisa digunakan. Untuk mendapatkan solusi lengkap, Anda harus sedikit mengotak-atik secara manual, atau membuat pembungkus dalam bentuk skrip.
Saya akan mulai dengan solusi yang paling sederhana dan diakhiri dengan solusi yang paling canggih, bergantung pada volume data dan ukuran cluster. Semakin besar clusternya, semakin kompleks penyelesaiannya.
Jika tabel dengan data hanya menempati beberapa gigabyte, pencadangan dapat dilakukan seperti ini:
- Simpan definisi tabel yaitu metadata - tampilkan buat tabel.
- Buat dump menggunakan klien ClickHouse - memilih * dari meja untuk mengajukan. Secara default Anda akan menerima file dalam format TabSeparated. Jika ingin lebih hemat, Anda bisa melakukannya dalam format Native.
Jika jumlah data lebih besar, maka pencadangan akan memakan lebih banyak waktu dan ruang. Ini disebut cadangan logis; tidak terikat dengan format data ClickHouse. Jika ya, sebagai upaya terakhir Anda dapat membuat cadangan dan mengunggahnya ke MySQL untuk pemulihan.
Untuk kasus lebih lanjut, ClickHouse memiliki kemampuan bawaan untuk membuat snapshot partisi di sistem file lokal. Fitur ini tersedia berdasarkan permintaan mengubah partisi pembekuan tabel. Atau sederhananya mengubah pembekuan tabel - ini adalah cuplikan seluruh tabel.
Snapshot akan dibuat secara konsisten untuk satu tabel pada satu shard, artinya, tidak mungkin membuat snapshot yang konsisten dari seluruh cluster dengan cara ini. Namun untuk sebagian besar tugas, hal tersebut tidak diperlukan, dan cukup menjalankan permintaan pada setiap shard dan mendapatkan snapshot yang konsisten. Itu dibuat dalam bentuk hardlink dan karenanya tidak memakan ruang tambahan. Selanjutnya, Anda menyalin snapshot ini ke server cadangan atau ke penyimpanan yang Anda gunakan untuk cadangan.
Memulihkan cadangan tersebut cukup mudah. Pertama, buat tabel menggunakan definisi tabel yang ada. Selanjutnya, salin snapshot partisi yang disimpan ke Directory-Detached untuk tabel ini dan jalankan kueri lampirkan partisi. Solusi ini cukup cocok untuk volume data yang paling serius.
Terkadang Anda memerlukan sesuatu yang lebih keren lagi - jika Anda memiliki puluhan atau bahkan ratusan terabyte di setiap server dan ratusan server. Ada solusi di sini yang saya ambil dari rekan-rekan saya dari Yandex.Metrica. Saya tidak akan merekomendasikannya kepada semua orang - bacalah dan putuskan sendiri apakah itu cocok atau tidak.
Pertama, Anda perlu membuat beberapa server dengan rak disk yang besar. Selanjutnya, di server ini, naikkan beberapa server ClickHouse dan konfigurasikan agar berfungsi sebagai replika lain untuk pecahan yang sama. Dan kemudian gunakan sistem file atau beberapa alat di server ini yang memungkinkan Anda membuat snapshot. Ada dua pilihan di sini. Opsi pertama adalah snapshot LVM, opsi kedua adalah ZFS di Linux.
Setelah itu, setiap hari Anda perlu membuat snapshot, itu akan terletak dan memakan ruang. Secara alami, jika datanya berubah, jumlah ruang akan bertambah seiring waktu. Snapshot ini dapat diambil kapan saja dan datanya dipulihkan, solusi yang aneh. Selain itu, kita juga perlu membatasi replika ini di konfigurasi agar mereka tidak mencoba menjadi pemimpin.
Apakah mungkin untuk mengatur replika lag yang terkendali di poros?
Tahun ini Anda berencana membuat poros di ClickHouse. Apakah mungkin untuk mengatur replika lag yang terkendali di dalamnya? Kami ingin menggunakannya untuk melindungi diri kami dari skenario negatif dengan perubahan dan perubahan lainnya.
Apakah mungkin melakukan semacam roll back untuk perubahan? Misalnya pada poros yang ada, ambil dan katakan bahwa sampai saat ini Anda menerapkan perubahan, dan mulai saat ini Anda berhenti menerapkan perubahan?
Jika sebuah perintah datang ke cluster kami dan merusaknya, maka kami memiliki replika bersyarat dengan jeda satu jam, di mana kami dapat mengatakan bahwa mari kita gunakan saat ini, tetapi kami tidak akan menerapkan perubahan pada sepuluh menit terakhir?
Pertama, tentang kelambatan replika yang terkendali. Ada permintaan seperti itu dari pengguna, dan kami membuat masalah di Github dengan permintaan: “Jika seseorang membutuhkan ini, sukai, berikan hati.” Tidak ada yang mengirimkan, dan masalah telah ditutup. Namun, Anda sudah bisa mendapatkan peluang ini dengan menyiapkan ClickHouse. Benar, baru mulai dari versi 20.3.
ClickHouse terus-menerus melakukan penggabungan data di latar belakang. Ketika penggabungan selesai, kumpulan data tertentu diganti dengan data yang lebih besar. Pada saat yang sama, potongan data yang ada sebelumnya tetap tersimpan di disk untuk beberapa waktu.
Pertama, mereka terus disimpan selama ada kueri terpilih yang menggunakannya, untuk menyediakan operasi non-pemblokiran. Kueri pilihan mudah dibaca dari potongan lama.
Kedua, ada juga batasan waktu - potongan data lama ada di disk selama delapan menit. Delapan menit ini dapat disesuaikan dan bahkan diubah menjadi satu hari. Hal ini akan memakan ruang disk: tergantung pada aliran data, ternyata dalam beberapa hari terakhir data tidak hanya berlipat ganda, namun bisa menjadi lima kali lipat. Namun jika terjadi masalah yang serius, Anda dapat menghentikan server ClickHouse dan menyelesaikan semuanya.
Sekarang muncul pertanyaan tentang bagaimana hal ini melindungi terhadap perubahan. Ada baiknya untuk melihat lebih dalam di sini, karena dalam versi ClickHouse yang lebih lama, perubahannya bekerja sedemikian rupa sehingga hanya mengubah bagian secara langsung. Ada sepotong data dengan beberapa file, dan kami melakukannya, misalnya, mengubah kolom drop. Kemudian kolom ini secara fisik dihapus dari semua bagian.
Namun mulai versi 20.3, mekanisme perubahan telah diubah sepenuhnya, dan kini potongan data selalu tidak dapat diubah. Mereka tidak berubah sama sekali - perubahan sekarang bekerja dengan cara yang sama seperti penggabungan. Alih-alih langsung mengganti satu bagian, kami membuat yang baru. Di potongan baru, file yang tidak berubah menjadi hardlink, dan jika kita menghapus kolom, kolom tersebut akan hilang begitu saja di potongan baru. Bagian lama akan dihapus secara default setelah delapan menit, dan di sini Anda dapat mengubah pengaturan yang disebutkan di atas.
Hal yang sama berlaku untuk perubahan seperti mutasi. Saat kamu melakukan mengubah hapus или mengubah pembaruan, itu tidak mengubah bagiannya, tetapi menciptakan yang baru. Dan kemudian menghapus yang lama.
Bagaimana jika struktur tabel berubah?
Bagaimana cara mengembalikan cadangan yang dibuat dengan skema lama? Dan pertanyaan kedua adalah tentang kasus snapshot dan alat sistem file. Apakah Btrfs bagus di sini daripada ZFS di Linux LVM?
Jika kamu melakukan lampirkan partisi partisi dengan struktur berbeda, maka ClickHouse akan memberitahu Anda bahwa ini tidak mungkin. Ini adalah solusinya. Yang pertama adalah membuat tabel sementara bertipe MergeTree dengan struktur lama, melampirkan data di sana menggunakan lampiran, dan membuat query alter. Kemudian Anda dapat menyalin atau mentransfer data ini dan melampirkannya kembali, atau menggunakan permintaan mengubah partisi pemindahan tabel.
Sekarang pertanyaan kedua adalah apakah Btrfs bisa digunakan. Pertama-tama, jika Anda memiliki LVM, maka snapshot LVM sudah cukup, dan sistem filenya bisa ext4, tidak masalah. Dengan Btrts, semuanya tergantung pengalaman Anda dalam menggunakannya. Ini adalah sistem file yang matang, tetapi masih ada beberapa kecurigaan tentang bagaimana semuanya akan berjalan dalam praktiknya dalam skenario tertentu. Saya tidak akan merekomendasikan menggunakan ini kecuali Anda memiliki Btrfs dalam produksi.
Apa praktik terbaik saat ini dalam penyusunan ulang data?
Permasalahan resharding sangatlah kompleks dan mempunyai banyak segi. Ada beberapa kemungkinan jawaban di sini. Anda dapat melihat dari satu sisi dan mengatakan ini - ClickHouse tidak memiliki fitur resharding bawaan. Tapi saya khawatir jawaban ini tidak cocok untuk siapa pun. Oleh karena itu, Anda dapat melihat dari sisi lain dan mengatakan bahwa ClickHouse memiliki banyak cara untuk menyusun ulang data.
Jika klaster kehabisan ruang atau tidak dapat menangani beban, Anda menambahkan server baru. Tapi server ini kosong secara default, tidak ada data di dalamnya, tidak ada beban. Anda perlu mengatur ulang data agar tersebar merata di cluster baru yang lebih besar.
Cara pertama yang dapat dilakukan adalah dengan menyalin sebagian partisi ke server baru menggunakan permintaan mengubah partisi pengambilan tabel. Misalnya, Anda memiliki partisi berdasarkan bulan, dan Anda mengambil bulan pertama tahun 2017 dan menyalinnya ke server baru, lalu menyalin bulan ketiga ke beberapa server baru lainnya. Dan Anda melakukan ini sampai menjadi lebih atau kurang merata.
Transfer hanya dapat dilakukan untuk partisi yang tidak berubah selama perekaman. Untuk partisi baru, perekaman harus dinonaktifkan, karena transfernya tidak bersifat atomik. Jika tidak, Anda akan mendapatkan duplikat atau kesenjangan dalam data. Namun cara ini praktis dan bekerja cukup efektif. Partisi terkompresi yang sudah jadi ditransmisikan melalui jaringan, yaitu data tidak dikompresi atau dikodekan ulang.
Metode ini memiliki satu kelemahan, dan itu tergantung pada skema sharding, apakah Anda berjanji pada skema sharding ini, kunci sharding apa yang Anda miliki. Dalam contoh Anda untuk kasus metrik, kunci sharding adalah hash jalur. Saat Anda memilih tabel Terdistribusi, tabel tersebut akan masuk ke semua pecahan di klaster sekaligus dan mengambil data dari sana.
Artinya, tidak masalah bagi Anda data apa yang disimpan di pecahan mana. Hal utama adalah bahwa data sepanjang satu jalur berakhir di satu pecahan, tetapi yang mana tidak penting. Dalam hal ini, mentransfer partisi yang sudah jadi adalah sempurna, karena dengan kueri pemilihan Anda juga akan menerima data lengkap - baik sebelum atau sesudahnya, skema tidak terlalu penting.
Namun ada kasus yang lebih kompleks. Jika pada tingkat logika aplikasi Anda mengandalkan skema sharding khusus, klien ini ditempatkan pada shard ini dan itu, dan permintaan dapat dikirim langsung ke sana, dan bukan ke tabel Terdistribusi. Atau Anda menggunakan ClickHouse versi terbaru dan telah mengaktifkan pengaturannya optimalkan lewati pecahan yang tidak digunakan. Dalam hal ini, selama kueri pemilihan, ekspresi di bagian mana akan dianalisis dan akan dihitung pecahan mana yang perlu digunakan sesuai dengan skema sharding. Ini berfungsi asalkan data dipartisi persis sesuai dengan skema sharding ini. Jika Anda mengatur ulang secara manual, korespondensinya mungkin berubah.
Jadi ini adalah metode nomor satu. Dan saya tunggu jawaban Anda, apakah metodenya cocok atau kita lanjutkan saja.
Vladimir Kolobaev, administrator sistem utama di Avito: Alexei, cara yang anda sebutkan tidak berfungsi dengan baik ketika anda perlu membagi beban, termasuk membaca. Kita dapat mengambil partisi bulanan dan dapat mengambil bulan sebelumnya ke node lain, tetapi ketika ada permintaan untuk data ini, kita hanya akan memuatnya. Namun kami ingin memuat seluruh cluster, karena jika tidak, untuk beberapa waktu seluruh beban pembacaan akan diproses oleh dua pecahan.
Alexei Milovidov: Jawabannya di sini aneh - ya, itu buruk, tapi mungkin berhasil. Saya akan menjelaskan caranya dengan tepat. Sebaiknya lihat skenario pemuatan yang ada di balik data Anda. Jika yang dimaksud adalah data pemantauan, maka kita dapat mengatakan bahwa sebagian besar permintaan adalah data baru.
Anda menginstal server baru, memigrasikan partisi lama, tetapi juga mengubah cara data baru dicatat. Dan data baru akan disebar ke seluruh cluster. Jadi, hanya dalam waktu lima menit, permintaan untuk lima menit terakhir akan memuat cluster secara merata; setelah satu hari, permintaan selama XNUMX jam akan memuat cluster secara merata. Dan permintaan untuk bulan sebelumnya, sayangnya, hanya akan masuk ke sebagian server cluster.
Namun seringkali Anda tidak mendapatkan permintaan khusus untuk Februari 2019. Kemungkinan besar, jika permintaan masuk ke tahun 2019, maka permintaan tersebut akan berlaku sepanjang tahun 2019 - untuk jangka waktu yang lama, dan bukan untuk rentang yang kecil. Dan permintaan seperti itu juga akan dapat memuat cluster secara merata. Namun secara umum, pernyataan Anda benar sekali bahwa ini adalah solusi ad hoc yang tidak menyebarkan data secara merata.
Saya punya beberapa poin lagi untuk menjawab pertanyaan itu. Salah satunya adalah tentang bagaimana merancang skema sharding pada awalnya sehingga sharding ulang akan mengurangi rasa sakit. Hal ini tidak selalu memungkinkan.
Misalnya, Anda memiliki data pemantauan. Data pemantauan berkembang karena tiga alasan. Yang pertama adalah akumulasi data historis. Yang kedua adalah pertumbuhan lalu lintas. Dan yang ketiga adalah peningkatan jumlah hal-hal yang harus dipantau. Ada layanan mikro dan metrik baru yang perlu disimpan.
Ada kemungkinan bahwa peningkatan terbesar disebabkan oleh alasan ketiga, yaitu peningkatan penggunaan pemantauan. Dan dalam hal ini, ada baiknya melihat sifat pemuatan, apa saja kueri pemilihan utama. Kueri pemilihan dasar kemungkinan besar akan didasarkan pada beberapa subkumpulan metrik.
Misalnya, penggunaan CPU di beberapa server oleh beberapa layanan. Ternyata ada subset kunci tertentu yang dapat digunakan untuk mendapatkan data ini. Dan permintaan data ini sendiri kemungkinan besar cukup sederhana dan selesai dalam waktu puluhan milidetik. Digunakan untuk memantau layanan dan dasbor. Saya harap saya memahami ini dengan benar.
Vladimir Kolobaev: Faktanya adalah kita sangat sering mengacu pada data historis, karena kita membandingkan situasi saat ini dengan situasi historis secara real time. Dan penting bagi kita untuk memiliki akses cepat ke sejumlah besar data, dan ClickHouse melakukan pekerjaan yang sangat baik dalam hal ini.
Anda benar sekali, kami mengalami sebagian besar permintaan baca pada hari terakhir, seperti sistem pemantauan lainnya. Namun pada saat yang sama, beban data historis juga cukup besar. Ini pada dasarnya berasal dari sistem peringatan yang muncul setiap tiga puluh detik dan berkata kepada ClickHouse: “Beri saya data selama enam minggu terakhir. Sekarang buatkan saya semacam rata-rata bergerak dari nilai tersebut, dan mari kita bandingkan nilai saat ini dengan nilai historis.”
Saya ingin mengatakan bahwa untuk permintaan terbaru seperti itu kami memiliki tabel kecil lain di mana kami hanya menyimpan data dua hari, dan permintaan utama masuk ke dalamnya. Kami hanya mengirimkan kueri historis berukuran besar ke tabel pecahan besar.
Alexei Milovidov: Sayangnya, ini ternyata tidak dapat diterapkan dengan baik untuk skenario Anda, tetapi saya akan memberi tahu Anda gambaran tentang dua skema sharding yang buruk dan kompleks yang tidak perlu digunakan, tetapi digunakan di layanan teman saya.
Ada cluster utama dengan acara Yandex.Metrica. Peristiwa adalah tampilan halaman, klik, dan konversi. Sebagian besar permintaan ditujukan ke situs web tertentu. Anda membuka layanan Yandex.Metrica, Anda memiliki situs web - avito.ru, buka laporan, dan permintaan dibuat untuk situs web Anda.
Namun ada permintaan lain – analitis dan global – yang dibuat oleh analis internal. Untuk berjaga-jaga, saya perhatikan bahwa analis internal hanya mengajukan permintaan untuk layanan Yandex. Namun demikian, bahkan layanan Yandex menempati sebagian besar data. Ini adalah permintaan bukan untuk penghitung tertentu, tetapi untuk pemfilteran yang lebih luas.
Bagaimana cara mengatur data sedemikian rupa sehingga semuanya bekerja secara efisien untuk satu penghitung, dan juga kueri global? Kesulitan lainnya adalah jumlah permintaan di ClickHouse untuk cluster Metrics adalah beberapa ribu per detik. Pada saat yang sama, satu server ClickHouse tidak dapat menangani permintaan non-sepele, misalnya beberapa ribu per detik.
Ukuran clusternya adalah enam ratus server. Jika Anda hanya menarik tabel Terdistribusi ke cluster ini dan mengirim beberapa ribu permintaan ke sana, itu akan menjadi lebih buruk daripada mengirimnya ke satu server. Di sisi lain, opsi bahwa data tersebar secara merata, dan kami pergi dan meminta dari semua server, segera diabaikan.
Ada pilihan yang bertolak belakang. Bayangkan jika kita membagi data di seluruh situs, dan permintaan untuk satu situs ditujukan ke satu shard. Sekarang cluster akan mampu menangani sepuluh ribu permintaan per detik, tetapi pada satu shard, satu permintaan mana pun akan bekerja terlalu lambat. Ini tidak akan lagi berskala dalam hal throughput. Apalagi jika ini adalah situs avito.ru. Saya tidak akan mengungkapkan rahasianya jika saya mengatakan bahwa Avito adalah salah satu situs yang paling banyak dikunjungi di Runet. Dan memprosesnya dalam satu pecahan adalah hal yang gila.
Oleh karena itu, skema sharding dirancang dengan cara yang lebih licik. Seluruh cluster dibagi menjadi beberapa cluster, yang kita sebut lapisan. Setiap cluster berisi selusin hingga beberapa lusin pecahan. Total ada tiga puluh sembilan cluster seperti itu.
Bagaimana skala semua ini? Jumlah cluster tidak berubah - seperti tiga puluh sembilan beberapa tahun yang lalu, jumlahnya tetap sama. Namun dalam masing-masing pecahan, kami secara bertahap meningkatkan jumlah pecahan seiring kami mengumpulkan data. Dan skema sharding secara keseluruhan adalah seperti ini: cluster ini dibagi menjadi beberapa situs web, dan untuk memahami situs web mana yang berada di cluster mana, metabase terpisah di MySQL digunakan. Satu situs - di satu cluster. Dan di dalamnya terjadi sharding sesuai dengan ID pengunjung.
Saat pencatatan, kami membaginya dengan sisa pembagian ID pengunjung. Namun saat menambahkan shard baru, skema sharding berubah; kami terus membagi, tetapi dengan sisa pembagian dengan angka lain. Artinya, satu pengunjung sudah berada di beberapa server, dan Anda tidak dapat mengandalkannya. Hal ini dilakukan semata-mata untuk memastikan bahwa data dikompresi dengan lebih baik. Dan ketika membuat permintaan, kita pergi ke tabel Terdistribusi, yang melihat cluster dan mengakses lusinan server. Ini adalah skema yang bodoh.
Tapi cerita saya tidak akan lengkap jika saya tidak mengatakan bahwa kita meninggalkan skema ini. Dalam skema baru, kami mengubah segalanya dan menyalin semua data menggunakan mesin fotokopi clickhouse.
Dalam skema baru, semua situs dibagi menjadi dua kategori - besar dan kecil. Saya tidak tahu bagaimana ambang batas dipilih, tetapi hasilnya adalah situs besar dicatat dalam satu cluster, di mana terdapat 120 shard dengan masing-masing tiga replika - yaitu, 360 server. Dan skema sharding dibuat sedemikian rupa sehingga setiap permintaan masuk ke semua shard sekaligus. Jika sekarang Anda membuka halaman laporan apa pun untuk avito.ru di Yandex.Metrica, permintaan akan masuk ke 120 server. Ada beberapa situs besar di Runet. Dan permintaannya bukan seribu per detik, bahkan kurang dari seratus. Semua ini diam-diam dikunyah oleh tabel Terdistribusi, yang masing-masing diproses dengan 120 server.
Dan cluster kedua adalah untuk situs kecil. Berikut adalah skema sharding berdasarkan ID situs, dan setiap permintaan ditujukan ke satu shard.
ClickHouse memiliki utilitas mesin fotokopi clickhouse. Bisakah Anda ceritakan kepada kami tentang dia?
Saya akan langsung mengatakan bahwa solusi ini lebih rumit dan kurang produktif. Keuntungannya adalah ia menyebarkan data secara lengkap sesuai dengan pola yang Anda tentukan. Namun kelemahan dari utilitas ini adalah tidak melakukan resharding sama sekali. Ini menyalin data dari satu skema cluster ke skema cluster lain.
Artinya agar dapat berfungsi, Anda harus memiliki dua cluster. Mereka dapat ditempatkan di server yang sama, namun, datanya tidak akan dipindahkan secara bertahap, tetapi akan disalin.
Misal tadinya empat server, sekarang jadi delapan. Anda membuat tabel Terdistribusi baru di semua server, tabel lokal baru dan meluncurkan clickhouse-copier, menunjukkan di dalamnya skema kerja yang harus dibaca dari sana, menerima skema sharding baru dan mentransfer data ke sana. Dan di server lama Anda akan memerlukan ruang satu setengah kali lebih banyak daripada yang ada sekarang, karena data lama harus tetap ada di server tersebut, dan setengah dari data lama yang sama akan tiba di atasnya. Jika sebelumnya Anda berpikir bahwa data perlu dihardisasi ulang dan masih ada ruang, maka cara ini cocok.
Bagaimana cara kerja mesin fotokopi clickhouse di dalam? Ini memecah semua pekerjaan menjadi serangkaian tugas untuk memproses satu partisi dari satu tabel pada satu pecahan. Semua tugas ini dapat dijalankan secara paralel, dan clickhouse-copier dapat dijalankan pada mesin yang berbeda dalam beberapa contoh, namun apa yang dilakukannya untuk satu partisi tidak lebih dari sebuah pilihan sisipan. Data dibaca, didekompresi, dipartisi ulang, lalu dikompresi lagi, ditulis di suatu tempat, dan diurutkan ulang. Ini adalah keputusan yang lebih sulit.
Anda memiliki program percontohan yang disebut resharding. Ada apa dengan dia?
Pada tahun 2017 lalu, Anda memiliki uji coba yang disebut resharding. Bahkan ada opsi di ClickHouse. Sejauh yang saya pahami, itu tidak berhasil. Bisakah Anda memberi tahu saya mengapa ini terjadi? Tampaknya ini sangat relevan.
Masalahnya adalah jika perlu menata ulang data pada tempatnya, diperlukan sinkronisasi yang sangat rumit untuk melakukan ini secara atom. Saat kami mulai melihat cara kerja sinkronisasi ini, terlihat jelas bahwa ada masalah mendasar. Dan permasalahan mendasar ini tidak hanya bersifat teoretis, tetapi segera mulai menampakkan diri dalam praktik dalam bentuk sesuatu yang dapat dijelaskan dengan sangat sederhana - tidak ada yang berhasil.
Apakah mungkin untuk menggabungkan semua bagian data sebelum memindahkannya ke disk yang lambat?
Pertanyaan tentang TTL dengan opsi pindah ke disk lambat dalam konteks penggabungan. Apakah ada cara, selain melalui cron, untuk menggabungkan semua bagian menjadi satu sebelum memindahkannya ke disk yang lambat?
Jawaban atas pertanyaan apakah mungkin untuk secara otomatis merekatkan semua bagian menjadi satu sebelum mentransfernya - tidak. Menurutku ini tidak perlu. Anda tidak perlu menggabungkan semua bagian menjadi satu, tetapi cukup mengandalkan fakta bahwa bagian-bagian tersebut akan ditransfer ke disk yang lambat secara otomatis.
Kami memiliki dua kriteria untuk aturan transfer. Yang pertama adalah saat terisi. Jika tingkat penyimpanan saat ini memiliki ruang kosong kurang dari persentase tertentu, kami memilih satu bagian dan memindahkannya ke penyimpanan yang lebih lambat. Atau lebih tepatnya, tidak lebih lambat, tetapi yang berikutnya - sesuai konfigurasi Anda.
Kriteria kedua adalah ukuran. Ini tentang memindahkan potongan besar. Anda dapat menyesuaikan ambang batas sesuai dengan ruang kosong pada disk cepat, dan data akan ditransfer secara otomatis.
Bagaimana cara bermigrasi ke versi baru ClickHouse jika tidak ada cara untuk memeriksa kompatibilitas terlebih dahulu?
Topik ini dibahas secara rutin dengan mempertimbangkan versi yang berbeda, dan masih. Seberapa amankah untuk meningkatkan dari versi 19.11 ke 19.16 dan, misalnya, dari 19.16 ke 20.3. Apa cara terbaik untuk bermigrasi ke versi baru tanpa dapat memeriksa kompatibilitas di kotak pasir terlebih dahulu?
Ada beberapa aturan “emas” di sini. Pertama - . Ini besar, tetapi ada paragraf terpisah tentang perubahan yang tidak kompatibel. Jangan perlakukan poin-poin ini sebagai tanda bahaya. Ini biasanya merupakan ketidakcocokan kecil yang melibatkan beberapa fungsi edge yang kemungkinan besar tidak Anda gunakan.
Kedua, jika tidak ada cara untuk memeriksa kompatibilitas di sandbox, dan Anda ingin segera memperbarui dalam produksi, rekomendasinya adalah Anda tidak perlu melakukan ini. Pertama buat kotak pasir dan uji. Jika tidak ada lingkungan pengujian, kemungkinan besar Anda tidak memiliki perusahaan yang sangat besar, yang berarti Anda dapat menyalin beberapa data ke laptop Anda dan memastikan semuanya berfungsi dengan benar. Anda bahkan dapat membuat beberapa replika secara lokal di mesin Anda. Atau Anda dapat mengambil versi baru di suatu tempat terdekat dan mengunggah beberapa data di sana - yaitu, membuat lingkungan pengujian yang diimprovisasi.
Aturan lainnya adalah tidak memperbarui selama seminggu setelah rilis versi karena ditemukannya bug dalam produksi dan perbaikan cepat selanjutnya. Mari kita cari tahu penomoran versi ClickHouse agar tidak bingung.
Ada versi 20.3.4. Angka 20 menunjukkan tahun pembuatannya - 2020. Dari segi isi dalamnya tidak masalah, jadi kami tidak akan memperhatikannya. Selanjutnya - 20.3. Kami menambah angka kedua - dalam hal ini 3 - setiap kali kami merilis rilis dengan beberapa fungsi baru. Jika kita ingin menambahkan beberapa fitur ke ClickHouse, kita harus menambah jumlahnya. Artinya, di versi 20.4 ClickHouse akan bekerja lebih baik lagi. Digit ketiga adalah 20.3.4. Di sini 4 adalah jumlah rilis patch di mana kami tidak menambahkan fitur baru, tetapi memperbaiki beberapa bug. Dan 4 berarti kita melakukannya empat kali.
Jangan berpikir ini adalah sesuatu yang buruk. Biasanya pengguna dapat menginstal versi terbaru dan akan berfungsi tanpa masalah dengan uptime per tahun. Tapi bayangkan bahwa dalam beberapa fungsi untuk memproses bitmap, yang ditambahkan oleh rekan Cina kita, server mogok ketika memberikan argumen yang salah. Kami mempunyai tanggung jawab untuk memperbaikinya. Kami akan merilis versi patch baru dan ClickHouse akan menjadi lebih stabil.
Jika Anda menjalankan ClickHouse dalam produksi, dan versi baru ClickHouse hadir dengan fitur tambahan - misalnya, 20.4.1 adalah yang pertama, jangan terburu-buru untuk memasukkannya ke dalam produksi pada hari pertama. Mengapa itu diperlukan? Jika Anda belum menggunakan ClickHouse, Anda dapat menginstalnya, dan kemungkinan besar semuanya akan baik-baik saja. Namun jika ClickHouse sudah bekerja secara stabil, pantau terus patch dan pembaruan untuk melihat masalah apa yang sedang kami perbaiki.
Kirill Shvakov: Saya ingin menambahkan sedikit tentang lingkungan pengujian. Setiap orang sangat takut dengan lingkungan pengujian dan untuk beberapa alasan mereka percaya bahwa jika Anda memiliki cluster ClickHouse yang sangat besar, maka lingkungan pengujian harus setidaknya sepuluh kali lebih kecil. Sama sekali tidak seperti itu.
Saya dapat memberitahu Anda dari contoh saya sendiri. Saya punya proyek, dan ada ClickHouse. Lingkungan pengujian kami hanya untuknya - ini adalah mesin virtual kecil di Hetzner seharga dua puluh euro, tempat semuanya diterapkan. Untuk melakukan ini, kami memiliki otomatisasi penuh di Ansible, dan oleh karena itu, pada prinsipnya, tidak ada bedanya ke mana harus pergi - ke server perangkat keras atau hanya menerapkannya di mesin virtual.
Apa yang bisa dilakukan? Sebaiknya berikan contoh dalam dokumentasi ClickHouse tentang cara menerapkan cluster kecil di rumah Anda sendiri - di Docker, di LXC, mungkin membuat buku pedoman yang Mungkin, karena orang yang berbeda memiliki penerapan yang berbeda. Ini akan menyederhanakan banyak hal. Saat Anda mengambil dan menyebarkan sebuah cluster dalam lima menit, akan lebih mudah untuk mencoba mencari tahu sesuatu. Ini jauh lebih nyaman, karena meluncurkan ke versi produksi yang belum Anda uji adalah sebuah jalan menuju ke mana-mana. Terkadang berhasil dan terkadang tidak. Oleh karena itu, mengharapkan kesuksesan adalah hal yang buruk.
Maxim Kotyakov, insinyur backend senior Avito: Saya akan menambahkan sedikit tentang lingkungan pengujian dari serangkaian masalah yang dihadapi oleh perusahaan besar. Kami memiliki kluster penerimaan ClickHouse yang lengkap; dalam hal skema dan pengaturan data, ini adalah salinan persis dari apa yang ada dalam produksi. Cluster ini disebarkan dalam container yang cukup kumuh dengan sumber daya minimum. Kami menulis persentase tertentu dari data produksi di sana, untungnya aliran tersebut dapat direplikasi di Kafka. Segala sesuatu di sana disinkronkan dan diskalakan - baik dalam hal kapasitas maupun aliran, dan, secara teori, semua hal lain dianggap sama, dalam hal metrik, ia harus berperilaku seperti produksi. Segala sesuatu yang berpotensi meledak pertama-tama digulung ke dudukan ini dan dibiarkan di sana selama beberapa hari hingga siap. Namun tentu saja, solusi ini mahal, sulit, dan memiliki biaya dukungan yang tidak nol.
Alexei Milovidov: Saya akan memberi tahu Anda seperti apa lingkungan pengujian teman-teman kita dari Yandex.Metrica. Satu cluster memiliki 600 server lebih, yang lain memiliki 360 server, dan ada cluster ketiga dan beberapa cluster. Lingkungan pengujian untuk salah satunya hanyalah dua pecahan dengan dua replika di masing-masingnya. Mengapa dua pecahan? Agar kamu tidak sendirian. Dan harus ada replikanya juga. Hanya jumlah minimum tertentu yang Anda mampu.
Lingkungan pengujian ini memungkinkan Anda memeriksa apakah kueri Anda berfungsi dan apakah ada masalah besar. Namun seringkali masalah muncul dengan sifat yang sama sekali berbeda, ketika semuanya berfungsi, namun ada beberapa perubahan kecil pada beban.
Izinkan saya memberi Anda sebuah contoh. Kami memutuskan untuk menginstal versi baru ClickHouse. Itu telah diposting di lingkungan pengujian, pengujian otomatis telah diselesaikan di Yandex.Metrica itu sendiri, yang membandingkan data pada versi lama dan yang baru, menjalankan seluruh pipeline. Dan tentu saja, uji ramah lingkungan terhadap CI kami. Kalau tidak, kami bahkan tidak akan mengusulkan versi ini.
Semuanya baik-baik saja. Kami mulai beralih ke produksi. Saya menerima pesan bahwa beban pada grafik telah meningkat beberapa kali lipat. Kami mengembalikan versinya. Saya melihat grafiknya dan melihat: beban sebenarnya meningkat beberapa kali selama peluncuran, dan menurun kembali saat diluncurkan. Kemudian kami mulai memutar kembali versinya. Dan beban bertambah dengan cara yang sama dan turun kembali dengan cara yang sama. Jadi kesimpulannya begini: beban bertambah karena tata letaknya, tidak ada yang mengejutkan.
Kemudian sulit meyakinkan rekan kerja untuk menginstal versi baru. Saya berkata: “Tidak apa-apa, luncurkan. Tetap berharap, semuanya akan berhasil. Sekarang beban pada grafik meningkat, tetapi semuanya baik-baik saja. Tetap bertahan." Secara umum, kami melakukan ini, dan itu saja - versinya dirilis untuk produksi. Namun hampir pada setiap tata letak, masalah serupa muncul.
Bunuh kueri seharusnya mematikan kueri, tetapi ternyata tidak. Mengapa?
Seorang pengguna, semacam analis, mendatangi saya dan membuat permintaan untuk memasang cluster ClickHouse saya. Beberapa node atau seluruh cluster, bergantung pada replika atau shard mana yang menjadi tujuan permintaan. Saya melihat semua sumber daya CPU di server ini ada di rak, semuanya berwarna merah. Pada saat yang sama, ClickHouse sendiri menanggapi permintaan. Dan saya menulis: "Tolong tunjukkan kepada saya, daftar proses, permintaan apa yang menyebabkan kegilaan ini."
Saya menemukan permintaan ini dan menulis kill padanya. Dan saya melihat tidak terjadi apa-apa. Server saya ada di rak, ClickHouse kemudian memberi saya beberapa perintah, menunjukkan bahwa server masih hidup, dan semuanya baik-baik saja. Tapi saya mengalami degradasi di semua permintaan pengguna, degradasi dimulai dengan catatan di ClickHouse, dan permintaan penghentian saya tidak berfungsi. Mengapa? Saya pikir mematikan kueri seharusnya mematikan kueri, tetapi ternyata tidak.
Sekarang akan ada jawaban yang agak aneh. Intinya adalah kill query tidak mematikan query.
Bunuh kueri, centang kotak kecil bernama "Saya ingin kueri ini dimatikan". Dan permintaan itu sendiri melihat tanda ini saat memproses setiap blok. Jika disetel, permintaan akan berhenti berfungsi. Ternyata tidak ada yang menghentikan permintaan tersebut, dia sendiri yang harus memeriksa semuanya dan menghentikannya. Dan ini akan berfungsi dalam semua kasus di mana permintaan berada dalam status memproses blok data. Ini akan memproses blok data berikutnya, memeriksa tandanya, dan berhenti.
Ini tidak berfungsi jika permintaan diblokir pada beberapa operasi. Benar, kemungkinan besar ini bukan kasus Anda, karena menurut Anda, ini menggunakan banyak sumber daya server. Ada kemungkinan bahwa ini tidak berfungsi dalam kasus penyortiran eksternal dan beberapa detail lainnya. Tapi secara umum hal ini tidak boleh terjadi, itu bug. Dan satu-satunya hal yang dapat saya rekomendasikan adalah memperbarui ClickHouse.
Bagaimana cara menghitung waktu respons di bawah beban membaca?
Ada tabel yang menyimpan agregat item - berbagai penghitung. Jumlah jalurnya kurang lebih seratus juta. Apakah mungkin untuk mengandalkan waktu respons yang dapat diprediksi jika Anda menuangkan 1K RPS untuk 1K item?
Dilihat dari konteksnya, kita berbicara tentang beban membaca, karena tidak ada masalah dengan penulisan - bahkan seribu, bahkan seratus ribu, dan terkadang beberapa juta baris dapat disisipkan.
Permintaan membaca sangat berbeda. Di pilih 1, ClickHouse dapat melakukan sekitar puluhan ribu permintaan per detik, sehingga permintaan untuk satu kunci pun sudah memerlukan beberapa sumber daya. Dan kueri titik seperti itu akan lebih sulit daripada di beberapa database nilai kunci, karena untuk setiap pembacaan, blok data perlu dibaca berdasarkan indeks. Indeks kami tidak menangani setiap catatan, namun setiap rentang. Artinya, Anda harus membaca seluruh rentang - ini adalah 8192 baris secara default. Dan Anda harus mendekompresi blok data terkompresi dari 64 KB menjadi 1 MB. Biasanya, kueri bertarget seperti itu memerlukan waktu beberapa milidetik untuk diselesaikan. Tapi ini adalah pilihan paling sederhana.
Mari kita coba beberapa aritmatika sederhana. Jika Anda mengalikan beberapa milidetik dengan seribu, Anda mendapatkan beberapa detik. Seolah-olah mustahil untuk memenuhi seribu permintaan per detik, namun nyatanya mungkin, karena kita memiliki beberapa inti prosesor. Jadi, pada prinsipnya, ClickHouse terkadang dapat menampung 1000 RPS, tetapi untuk permintaan singkat, khusus untuk permintaan yang ditargetkan.
Jika Anda perlu menskalakan cluster ClickHouse berdasarkan jumlah permintaan sederhana, maka saya merekomendasikan hal paling sederhana - menambah jumlah replika dan mengirim permintaan ke replika acak. Jika satu replika menampung lima ratus permintaan per detik, yang sepenuhnya realistis, maka tiga replika akan menangani satu setengah ribu.
Terkadang, tentu saja, Anda dapat mengonfigurasi ClickHouse untuk jumlah pembacaan poin maksimum. Apa yang dibutuhkan untuk ini? Yang pertama adalah mengurangi granularitas indeks. Dalam hal ini, tidak boleh dikurangi menjadi satu, tetapi atas dasar bahwa jumlah entri dalam indeks akan menjadi beberapa juta atau puluhan juta per server. Jika tabel memiliki seratus juta baris, maka granularitasnya dapat diatur ke 64.
Anda dapat mengurangi ukuran blok terkompresi. Ada pengaturan untuk ini ukuran blok kompres min, ukuran blok kompres maks. Mereka dapat dikurangi, diisi ulang dengan data, dan kemudian permintaan yang ditargetkan akan lebih cepat. Namun tetap saja, ClickHouse bukanlah database nilai kunci. Sejumlah besar permintaan kecil merupakan antipola beban.
Kirill Shvakov: Saya akan memberikan saran jika ada akun biasa di sana. Ini adalah situasi yang cukup standar ketika ClickHouse menyimpan semacam penghitung. Saya memiliki pengguna, dia berasal dari negara ini dan itu, dan beberapa bidang ketiga, dan saya perlu meningkatkan sesuatu secara bertahap. Ambil MySQL, buat kunci unik - di MySQL ini adalah kunci duplikat, dan di PostgreSQL ada konflik - dan tambahkan tanda plus. Ini akan bekerja lebih baik.
Jika Anda tidak memiliki banyak data, tidak ada gunanya menggunakan ClickHouse. Ada database reguler dan mereka melakukannya dengan baik.
Apa yang bisa saya atur di ClickHouse agar lebih banyak data ada di cache?
Mari kita bayangkan sebuah situasi - server memiliki 256 GB RAM, dalam rutinitas harian ClickHouse membutuhkan sekitar 60-80 GB, pada puncaknya - hingga 130. Apa yang dapat diaktifkan dan disesuaikan sehingga lebih banyak data ada di cache dan, karenanya, ada lebih sedikit perjalanan ke disk?
Biasanya, cache halaman sistem operasi berfungsi dengan baik. Jika Anda hanya membuka bagian atas, lihat di sana di-cache atau gratis - ia juga mengatakan berapa banyak yang di-cache - maka Anda akan melihat bahwa semua memori bebas digunakan untuk cache. Dan ketika membaca data ini, maka akan dibaca bukan dari disk, melainkan dari RAM. Pada saat yang sama, saya dapat mengatakan bahwa cache digunakan secara efektif karena data terkompresilah yang di-cache.
Namun, jika Anda ingin lebih mempercepat beberapa kueri sederhana, Anda dapat mengaktifkan cache pada data yang didekompresi di dalam ClickHouse. Itu disebut cache yang tidak terkompresi. Dalam file konfigurasi config.xml, atur ukuran cache yang tidak terkompresi ke nilai yang Anda perlukan - Saya sarankan tidak lebih dari setengah dari RAM kosong, karena sisanya akan berada di bawah cache halaman.
Selain itu, ada dua pengaturan tingkat permintaan. Pengaturan pertama - gunakan cache yang tidak terkompresi - termasuk penggunaannya. Disarankan untuk mengaktifkannya untuk semua permintaan, kecuali permintaan berat, yang dapat membaca semua data dan membersihkan cache. Dan pengaturan kedua adalah seperti jumlah baris maksimum untuk menggunakan cache. Secara otomatis membatasi kueri besar sehingga melewati cache.
Bagaimana cara mengkonfigurasi penyimpanan_konfigurasi untuk penyimpanan di RAM?
Dalam dokumentasi ClickHouse baru saya membaca bagian terkait . Deskripsi berisi contoh dengan SSD cepat.
Saya bertanya-tanya bagaimana hal yang sama dapat dikonfigurasi dengan volume memori panas. Dan satu pertanyaan lagi. Bagaimana cara kerja seleksi dengan organisasi data ini, apakah ia akan membaca seluruh kumpulan atau hanya yang ada di disk, dan apakah data ini dikompresi dalam memori? Dan bagaimana cara kerja bagian awal dengan organisasi data seperti itu?
Pengaturan ini memengaruhi penyimpanan potongan data, dan formatnya tidak berubah sama sekali.
Mari kita lihat lebih dekat.
Anda dapat mengkonfigurasi penyimpanan data dalam RAM. Yang dikonfigurasi untuk disk hanyalah jalurnya. Anda membuat partisi tmpfs yang dipasang ke beberapa jalur di sistem file. Anda menentukan jalur ini sebagai jalur untuk menyimpan data untuk partisi terpanas, potongan data mulai berdatangan dan ditulis di sana, semuanya baik-baik saja.
Namun saya tidak menyarankan melakukan ini karena keandalannya yang rendah, meskipun jika Anda memiliki setidaknya tiga replika di pusat data yang berbeda, hal itu mungkin dilakukan. Jika terjadi sesuatu, data akan dipulihkan. Bayangkan saja server tiba-tiba dimatikan dan dihidupkan kembali. Partisi sudah dipasang lagi, tetapi tidak ada apa-apa di sana. Ketika server ClickHouse dimulai, ia melihat bahwa ia tidak memiliki bagian-bagian ini, meskipun menurut metadata ZooKeeper, bagian-bagian tersebut seharusnya ada di sana. Dia melihat replika mana yang memilikinya, memintanya, dan mengunduhnya. Dengan cara ini data akan dipulihkan.
Dalam hal ini, menyimpan data dalam RAM pada dasarnya tidak berbeda dengan menyimpannya di disk, karena ketika data ditulis ke disk, data tersebut juga terlebih dahulu berakhir di cache halaman dan kemudian ditulis secara fisik. Hal ini tergantung pada opsi pemasangan sistem file. Namun untuk berjaga-jaga, saya akan mengatakan bahwa ClickHouse tidak melakukan sinkronisasi saat memasukkan.
Dalam hal ini, data dalam RAM disimpan dalam format yang persis sama seperti pada disk. Kueri pemilihan dengan cara yang sama memilih bagian yang perlu dibaca, memilih rentang data yang diperlukan dalam bagian tersebut, dan membacanya. Dan prewhere bekerja dengan cara yang persis sama, terlepas dari apakah datanya ada di RAM atau di disk.
Berapa nilai unik yang efektif untuk Kardinalitas Rendah?
Kardinalitas Rendah dirancang dengan cerdik. Ini mengkompilasi kamus data, tetapi bersifat lokal. Pertama, terdapat kamus yang berbeda untuk setiap bagian, dan kedua, bahkan dalam satu bagian, kamus tersebut dapat berbeda untuk setiap rentang. Ketika jumlah nilai unik mencapai angka ambang batas—satu juta, menurut saya—kamus akan disimpan dan kamus baru akan dibuat.
Jawabannya secara umum: untuk setiap rentang lokal - katakanlah, untuk setiap hari - hingga satu juta nilai unik Kardinalitas Rendah efektif. Setelah itu hanya akan ada fallback, yang mana banyak kamus berbeda akan digunakan, dan tidak hanya satu. Ini akan bekerja kira-kira sama dengan kolom string biasa, mungkin sedikit kurang efisien, tetapi tidak akan ada penurunan kinerja yang serius.
Apa praktik terbaik untuk penelusuran teks lengkap pada tabel dengan lima miliar baris?
Ada jawaban yang berbeda. Yang pertama adalah mengatakan bahwa ClickHouse bukanlah mesin pencari teks lengkap. Ada sistem khusus untuk ini, misalnya, и . Namun, saya semakin sering melihat orang mengatakan bahwa mereka beralih dari Elasticsearch ke ClickHouse.
Mengapa ini terjadi? Mereka menjelaskan hal ini dengan fakta bahwa Elasticsearch berhenti mengatasi beban pada volume tertentu, dimulai dengan pembuatan indeks. Indeks menjadi terlalu rumit, dan jika Anda hanya mentransfer data ke ClickHouse, ternyata data tersebut disimpan beberapa kali lebih efisien dalam hal volume. Pada saat yang sama, permintaan pencarian sering kali tidak sedemikian rupa sehingga perlu menemukan beberapa frasa di seluruh volume data, dengan mempertimbangkan morfologi, tetapi frasa yang sama sekali berbeda. Misalnya, temukan beberapa byte berikutnya dalam log selama beberapa jam terakhir.
Dalam hal ini, Anda membuat indeks di ClickHouse, bidang pertama adalah tanggal dan waktu. Dan batas data terbesar akan didasarkan pada rentang tanggal. Dalam rentang tanggal yang dipilih, sebagai aturan, pencarian teks lengkap sudah dapat dilakukan, bahkan menggunakan metode brute force menggunakan suka. Operator like di ClickHouse adalah operator like paling efisien yang dapat Anda temukan. Jika Anda menemukan sesuatu yang lebih baik, beri tahu saya.
Tapi tetap saja, itu seperti pemindaian penuh. Dan pemindaian penuh bisa menjadi lambat tidak hanya pada CPU, tetapi juga pada disk. Jika tiba-tiba Anda memiliki satu terabyte data per hari, dan Anda mencari sebuah kata di siang hari, maka Anda harus memindai terabyte tersebut. Dan itu mungkin terjadi pada hard drive biasa, dan pada akhirnya akan dimuat sedemikian rupa sehingga Anda tidak akan dapat mengakses server ini melalui SSH.
Dalam hal ini, saya siap menawarkan satu trik kecil lagi. Ini bersifat eksperimental - mungkin berhasil, mungkin juga tidak. ClickHouse memiliki indeks teks lengkap dalam bentuk filter trigram Bloom. Rekan-rekan kami di Arenadata telah mencoba indeks ini, dan seringkali indeks tersebut berfungsi persis seperti yang diharapkan.
Untuk menggunakannya dengan benar, Anda harus memiliki pemahaman yang baik tentang cara kerjanya: apa itu filter trigram Bloom dan bagaimana memilih ukurannya. Saya dapat mengatakan bahwa mereka akan membantu untuk pertanyaan tentang beberapa frasa langka, substring yang jarang ditemukan dalam data. Dalam hal ini, subrentang akan dipilih berdasarkan indeks dan lebih sedikit data yang akan dibaca.
Baru-baru ini, ClickHouse telah menambahkan lebih banyak fungsi lanjutan untuk pencarian teks lengkap. Ini adalah, pertama, pencarian sekumpulan substring sekaligus dalam satu pass, termasuk opsi yang peka huruf besar-kecil, tidak peka huruf besar-kecil, dengan dukungan untuk UTF-8 atau hanya untuk ASCII. Pilih yang paling efektif yang Anda butuhkan.
Pencarian untuk beberapa ekspresi reguler dalam satu pass juga telah muncul. Anda tidak perlu menulis X seperti satu substring atau X seperti substring lainnya. Anda langsung menulis, dan semuanya dilakukan seefisien mungkin.
Ketiga, sekarang ada perkiraan pencarian regexps dan perkiraan pencarian substring. Jika ada yang salah mengeja kata, maka akan dicari kecocokan maksimalnya.
Apa cara terbaik untuk mengatur akses ke ClickHouse untuk banyak pengguna?
Beri tahu kami cara terbaik mengatur akses untuk sejumlah besar konsumen dan analis. Bagaimana cara membentuk antrian, memprioritaskan kueri serentak maksimal, dan dengan alat apa?
Jika clusternya cukup besar, maka solusi yang baik adalah menambah dua server lagi, yang akan menjadi titik masuk bagi para analis. Artinya, jangan izinkan analis mengakses pecahan tertentu di cluster, tetapi cukup buat dua server kosong, tanpa data, dan konfigurasikan hak akses pada server tersebut. Dalam hal ini, pengaturan pengguna untuk permintaan terdistribusi ditransfer ke server jarak jauh. Artinya, Anda mengonfigurasi semua yang ada di kedua server ini, dan pengaturannya berpengaruh pada keseluruhan cluster.
Pada prinsipnya, server ini tidak memiliki data, tetapi jumlah RAM di dalamnya sangat penting untuk menjalankan permintaan. Disk juga dapat digunakan untuk data sementara jika agregasi eksternal atau penyortiran eksternal diaktifkan.
Penting untuk melihat pengaturan yang terkait dengan semua batasan yang mungkin. Jika sekarang saya pergi ke cluster Yandex.Metrica sebagai analis dan mengajukan permintaan pilih hitungan dari hit, maka saya akan langsung diberikan pengecualian bahwa saya tidak dapat menjalankan permintaan tersebut. Jumlah maksimum baris yang boleh saya pindai adalah seratus miliar, dan totalnya ada lima puluh triliun baris dalam satu tabel di cluster. Ini adalah batasan pertama.
Katakanlah saya menghapus batas baris dan menjalankan kueri lagi. Lalu saya akan melihat pengecualian berikut - pengaturan diaktifkan indeks kekuatan berdasarkan tanggal. Saya tidak dapat menyelesaikan kueri jika saya belum menentukan rentang tanggal. Anda tidak harus bergantung pada analis untuk menentukannya secara manual. Kasus yang umum terjadi adalah ketika rentang tanggal ditulis di mana tanggal acara antara minggu. Dan kemudian mereka hanya menentukan tanda kurung di tempat yang salah, dan bukannya dan ternyata itu adalah atau - atau URL yang cocok. Jika tidak ada batasan, itu akan merayapi kolom URL dan hanya membuang banyak sumber daya.
Selain itu, ClickHouse memiliki dua pengaturan prioritas. Sayangnya, mereka sangat primitif. Seseorang dipanggil begitu saja prioritas. Jika prioritas ≠ 0, dan permintaan dengan prioritas tertentu sedang dijalankan, namun permintaan dengan nilai prioritas lebih kecil dari, yang berarti prioritas lebih tinggi, yang dijalankan, maka permintaan dengan nilai prioritas lebih besar, yang berarti prioritas lebih rendah , hanya ditangguhkan dan tidak akan berfungsi sama sekali selama ini.
Ini adalah pengaturan yang sangat kasar dan tidak cocok untuk kasus di mana cluster memiliki beban yang konstan. Namun jika Anda memiliki permintaan pendek dan mendesak yang penting, dan sebagian besar klaster menganggur, pengaturan ini cocok.
Pengaturan prioritas berikutnya disebut Prioritas utas OS. Ini hanya menetapkan nilai bagus untuk semua thread eksekusi permintaan untuk penjadwal Linux. Ini berfungsi biasa saja, tetapi masih berfungsi. Jika Anda menetapkan nilai minimum yang bagus - ini adalah nilai terbesar, dan karenanya merupakan prioritas terendah - dan menetapkan -19 untuk permintaan dengan prioritas tinggi, maka CPU akan menggunakan permintaan berprioritas rendah sekitar empat kali lebih sedikit daripada permintaan berprioritas tinggi.
Anda juga perlu mengonfigurasi waktu eksekusi permintaan maksimum - katakanlah, lima menit. Kecepatan minimum eksekusi kueri adalah hal yang paling keren. Pengaturan ini telah ada sejak lama, dan diperlukan tidak hanya untuk menegaskan bahwa ClickHouse tidak memperlambat, tetapi juga untuk memaksanya.
Bayangkan, Anda menyiapkan: jika beberapa kueri memproses kurang dari satu juta baris per detik, Anda tidak dapat melakukannya. Ini mencemarkan nama baik kita, database baik kita. Mari kita larang ini. Sebenarnya ada dua pengaturan. Yang satu dipanggil kecepatan eksekusi minimum - dalam baris per detik, dan yang kedua disebut batas waktu sebelum memeriksa kecepatan eksekusi minimum - lima belas detik secara default. Artinya, lima belas detik dimungkinkan, dan kemudian, jika lambat, cukup berikan pengecualian dan batalkan permintaan.
Anda juga perlu menyiapkan kuota. ClickHouse memiliki fitur kuota bawaan yang menghitung konsumsi sumber daya. Namun sayangnya, bukan sumber daya perangkat keras seperti CPU, disk, tetapi sumber daya logis - jumlah permintaan yang diproses, baris, dan byte yang dibaca. Dan Anda dapat mengonfigurasi, misalnya, maksimal seratus permintaan dalam lima menit dan seribu permintaan per jam.
Mengapa ini penting? Karena beberapa kueri analitik akan dilakukan secara manual langsung dari klien ClickHouse. Dan semuanya akan baik-baik saja. Tetapi jika Anda memiliki analis tingkat lanjut di perusahaan Anda, mereka akan menulis skrip, dan mungkin ada kesalahan dalam skrip tersebut. Dan kesalahan ini akan menyebabkan permintaan dieksekusi dalam loop tak terbatas. Inilah yang perlu kita lindungi.
Apakah mungkin memberikan hasil satu kueri kepada sepuluh klien?
Kami memiliki beberapa pengguna yang ingin datang dengan permintaan yang sangat besar pada saat yang bersamaan. Permintaannya besar dan, pada prinsipnya, dieksekusi dengan cepat, tetapi karena banyaknya permintaan seperti itu pada saat yang sama, itu menjadi sangat menyakitkan. Apakah mungkin untuk mengeksekusi permintaan yang sama, yang datang sepuluh kali berturut-turut, satu kali, dan memberikan hasilnya kepada sepuluh klien?
Soalnya kita tidak mempunyai hasil cache atau cache data perantara. Terdapat cache halaman sistem operasi, yang akan mencegah Anda membaca data dari disk lagi, namun sayangnya, data tersebut masih akan didekompresi, dideserialisasi, dan diproses ulang.
Saya ingin menghindari hal ini, baik dengan menyimpan data perantara, atau dengan menyusun kueri serupa dalam beberapa jenis antrian dan menambahkan cache hasil. Saat ini kami memiliki satu permintaan tarik dalam pengembangan yang menambahkan cache permintaan, tetapi hanya untuk subkueri di bagian masuk dan gabung - yaitu, solusinya tidak lengkap.
Namun, kita juga menghadapi situasi seperti itu. Contoh yang sangat kanonik adalah kueri yang diberi nomor halaman. Ada laporannya, beberapa halaman, dan ada permintaan limit 10. Lalu sama saja, tapi limit 10,10. Lalu halaman berikutnya. Dan pertanyaannya adalah, mengapa kita menghitung semua ini setiap saat? Namun sekarang tidak ada solusi, dan tidak ada cara untuk menghindarinya.
Ada solusi alternatif yang ditempatkan sebagai sespan di sebelah ClickHouse - .
Kirill Shvakov: ClickHouse Proxy memiliki pembatas kecepatan bawaan dan cache hasil bawaan. Banyak pengaturan dibuat di sana karena masalah serupa sedang diselesaikan. Proksi memungkinkan Anda membatasi permintaan dengan mengantrinya dan mengonfigurasi berapa lama cache permintaan bertahan. Jika permintaannya benar-benar sama, Proxy akan mengirimkannya berkali-kali, namun akan masuk ke ClickHouse hanya sekali.
Nginx juga memiliki cache dalam versi gratisnya, dan ini juga akan berfungsi. Nginx bahkan memiliki pengaturan yang jika permintaan tiba pada waktu yang sama, akan memperlambat permintaan lainnya hingga satu permintaan selesai. Namun di ClickHouse Proxy pengaturannya dilakukan jauh lebih baik. Itu dibuat khusus untuk ClickHouse, khusus untuk permintaan tersebut, jadi lebih cocok. Ya, pemasangannya mudah.
Bagaimana dengan operasi asinkron dan pandangan terwujud?
Ada masalah bahwa operasi dengan mesin replay tidak sinkron - pertama-tama data ditulis, kemudian diciutkan. Jika tablet yang terwujud dengan beberapa agregat hidup di bawah tanda tersebut, maka duplikatnya akan ditulis padanya. Dan jika tidak ada logika yang rumit, maka data akan terduplikasi. Apa yang dapat Anda lakukan?
Ada solusi yang jelas - untuk mengimplementasikan pemicu pada kelas matview tertentu selama operasi penciutan asinkron. Apakah ada solusi terbaik atau rencana untuk mengimplementasikan fungsi serupa?
Penting untuk memahami cara kerja deduplikasi. Apa yang akan saya sampaikan kepada Anda sekarang tidak relevan dengan pertanyaan tersebut, tetapi untuk berjaga-jaga, hal ini perlu diingat.
Saat memasukkan ke dalam tabel yang direplikasi, terjadi deduplikasi seluruh blok yang disisipkan. Jika Anda memasukkan kembali blok yang sama yang berisi jumlah baris yang sama dalam urutan yang sama, maka data akan dihapus duplikatnya. Anda akan menerima "Ok" sebagai respons terhadap penyisipan, tetapi sebenarnya satu paket data akan ditulis, dan tidak akan diduplikasi.
Hal ini diperlukan demi kepastian. Jika Anda menerima “Ok” saat penyisipan, maka data Anda telah dimasukkan. Jika Anda menerima kesalahan dari ClickHouse, itu berarti mereka tidak dimasukkan dan Anda perlu mengulangi penyisipan. Namun jika koneksi terputus saat penyisipan, maka Anda tidak tahu apakah data sudah dimasukkan atau belum. Satu-satunya pilihan adalah mengulangi penyisipan lagi. Jika data benar-benar dimasukkan dan Anda memasukkannya kembali, terjadi deduplikasi blok. Hal ini diperlukan untuk menghindari duplikasi.
Dan penting juga cara kerjanya untuk pandangan yang terwujud. Jika data telah dihapus duplikatnya saat dimasukkan ke dalam tabel utama, maka data tersebut juga tidak akan masuk ke tampilan material.
Sekarang tentang pertanyaannya. Situasi Anda menjadi lebih rumit karena Anda merekam duplikat setiap baris. Artinya, bukan seluruh paket yang diduplikasi, tetapi baris tertentu, dan baris tersebut runtuh di latar belakang. Memang benar bahwa data akan diciutkan di tabel utama, tetapi data yang tidak diciutkan akan masuk ke tampilan materialisasi, dan selama penggabungan, tidak ada yang akan terjadi pada tampilan materialisasi. Karena tampilan yang terwujud tidak lebih dari pemicu penyisipan. Selama operasi lain, tidak ada tambahan yang terjadi padanya.
Dan aku tidak bisa membuatmu bahagia di sini. Anda hanya perlu mencari solusi spesifik untuk kasus ini. Misalnya, apakah mungkin untuk memutar ulang dalam tampilan yang terwujud, dan metode deduplikasi mungkin bekerja dengan cara yang sama. Namun sayangnya, tidak selalu. Jika digabungkan, itu tidak akan berhasil.
Kirill Shvakov: Kami juga memiliki konstruksi kruk pada masa itu. Ada masalah pada tayangan iklan, dan ada beberapa data yang dapat kami tampilkan secara real time - ini hanya tayangan. Mereka jarang diduplikasi, tetapi jika ini terjadi, kami akan tetap menutupnya nanti. Dan ada hal-hal yang tidak dapat diduplikasi - klik dan keseluruhan cerita ini. Tapi saya juga ingin segera menunjukkannya.
Bagaimana pandangan-pandangan yang terwujud itu dibuat? Ada tampilan yang ditulis langsung - ditulis ke data mentah, dan ditulis ke tampilan. Di sana, suatu saat, datanya kurang tepat, terduplikasi, dan sebagainya. Dan ada bagian kedua dari tabel tersebut, yang terlihat persis sama dengan pandangan-pandangan yang terwujud, yaitu strukturnya benar-benar identik. Sesekali kita hitung ulang datanya, hitung datanya tanpa duplikat, tulis ke tabel itu.
Kami menggunakan API - ini tidak akan berfungsi di ClickHouse secara manual. Dan API terlihat: ketika saya memiliki tanggal penambahan terakhir ke tabel, yang dijamin bahwa data yang benar telah dihitung, dan membuat permintaan ke satu tabel dan ke tabel lain. Dari satu permintaan memilih hingga jangka waktu tertentu, dan dari yang lain menerima apa yang belum dihitung. Dan itu berhasil, tetapi tidak melalui ClickHouse saja.
Jika Anda memiliki semacam API - untuk analis, untuk pengguna - maka, pada prinsipnya, ini adalah sebuah opsi. Anda selalu menghitung, selalu menghitung. Hal ini dapat dilakukan sekali sehari atau pada waktu lain. Anda memilih sendiri rentang yang tidak Anda perlukan dan tidak penting.
ClickHouse memiliki banyak log. Bagaimana saya bisa melihat semua yang terjadi pada server secara sekilas?
ClickHouse memiliki sejumlah besar log berbeda, dan jumlah ini terus bertambah. Di versi baru, beberapa di antaranya bahkan diaktifkan secara default, di versi lama harus diaktifkan saat memperbarui. Namun, jumlahnya semakin banyak. Pada akhirnya, saya ingin melihat apa yang terjadi dengan server saya sekarang, mungkin di semacam dasbor ringkasan.
Apakah Anda memiliki tim ClickHouse, atau tim teman Anda, yang mendukung beberapa fungsi dasbor siap pakai yang akan menampilkan log ini sebagai produk jadi? Pada akhirnya, hanya melihat log di ClickHouse saja sudah bagus. Namun akan sangat keren jika sudah disiapkan dalam bentuk dashboard. Saya akan menyukainya.
Ada dashboard, meski tidak terstandarisasi. Di perusahaan kami, sekitar 60 tim menggunakan ClickHouse, dan yang paling aneh adalah banyak dari mereka memiliki dasbor yang mereka buat sendiri, dan yang sedikit berbeda. Beberapa tim menggunakan instalasi internal Yandex.Cloud. Ada beberapa laporan yang sudah jadi, meski tidak semuanya diperlukan. Yang lain punya miliknya sendiri.
Rekan-rekan saya dari Metrica memiliki dashboard sendiri di Grafana, dan saya memiliki dashboard sendiri untuk cluster mereka. Saya melihat hal-hal seperti cache hit untuk cache serif. Dan yang lebih sulit lagi adalah kita menggunakan alat yang berbeda. Saya membuat dasbor menggunakan alat yang sangat tua bernama Graphite-web. Dia benar-benar jelek. Dan saya masih menggunakannya dengan cara ini, meskipun Grafana mungkin lebih nyaman dan indah.
Hal dasar di dashboard sama. Ini adalah metrik sistem untuk cluster: CPU, memori, disk, jaringan. Lainnya - jumlah permintaan simultan, jumlah penggabungan simultan, jumlah permintaan per detik, jumlah maksimum potongan untuk partisi tabel MergeTree, jeda replikasi, ukuran antrian replikasi, jumlah baris yang disisipkan per detik, jumlah blok yang disisipkan per detik. Ini semua yang didapat bukan dari log, tapi dari metrik.
Vladimir Kolobaev: Alexei, saya ingin memperbaikinya sedikit. Ada Grafana. Grafana memiliki sumber data yaitu ClickHouse. Artinya, saya bisa membuat request dari Grafana langsung ke ClickHouse. ClickHouse memiliki tabel dengan log, sama untuk semua orang. Hasilnya, saya ingin mengakses tabel log ini di Grafana dan melihat permintaan yang dibuat server saya. Akan sangat bagus jika memiliki dashboard seperti ini.
Saya mengendarai sepedanya sendiri. Namun saya punya pertanyaan - jika semuanya terstandarisasi, dan Grafana digunakan oleh semua orang, mengapa Yandex tidak memiliki dasbor resmi?
Kirill Shvakov: Faktanya, sumber data yang masuk ke ClickHouse sekarang mendukung Altinity. Dan saya hanya ingin memberikan vektor di mana harus menggali dan siapa yang harus didorong. Anda bisa bertanya kepada mereka, karena Yandex masih membuat ClickHouse, dan bukan cerita seputarnya. Altinity adalah perusahaan utama yang saat ini mempromosikan ClickHouse. Mereka tidak akan meninggalkannya, tapi akan mendukungnya. Sebab pada prinsipnya untuk mengunggah dashboard ke website Grafana hanya perlu mendaftar dan mengunggahnya tidak ada kendala khusus.
Alexei Milovidov: Selama setahun terakhir, ClickHouse telah menambahkan banyak kemampuan pembuatan profil kueri. Ada metrik untuk setiap permintaan penggunaan sumber daya. Dan baru-baru ini, kami menambahkan profiler kueri tingkat yang lebih rendah untuk melihat di mana kueri menghabiskan setiap milidetik. Namun untuk menggunakan fungsi ini, saya harus membuka klien konsol dan mengetik permintaan, yang selalu saya lupakan. Saya menyimpannya di suatu tempat dan selalu lupa di mana tepatnya.
Saya berharap ada alat yang mengatakan, inilah pertanyaan berat Anda, dikelompokkan berdasarkan kelas kueri. Saya menekan salah satunya, dan mereka akan memberi tahu saya bahwa itulah mengapa ini berat. Saat ini tidak ada solusi seperti itu. Dan sungguh aneh ketika orang bertanya kepada saya: “Katakan, apakah ada dashboard yang sudah jadi untuk Grafana?”, Saya menjawab: “Buka website Grafana, ada komunitas “Dashboards”, dan ada dashboard dari Dimka, ada dashboard dari Kostyan. Saya tidak tahu apa itu, saya sendiri belum pernah menggunakannya.”
Bagaimana cara mempengaruhi penggabungan agar server tidak crash ke OOM?
Saya punya tabel, hanya ada satu partisi di tabel, yaitu ReplacingMergeTree. Saya telah menulis data ke dalamnya selama empat tahun. Saya perlu mengubahnya dan menghapus beberapa data.
Saya melakukan ini, dan selama pemrosesan permintaan ini, semua memori di semua server di cluster dikonsumsi, dan semua server di cluster masuk ke OOM. Kemudian mereka semua bangkit bersama, mulai menggabungkan operasi yang sama, blok data ini, dan kembali masuk ke OOM. Kemudian mereka bangkit lagi dan jatuh lagi. Dan hal ini tidak berhenti.
Lalu ternyata ini sebenarnya adalah bug yang telah diperbaiki oleh mereka. Ini sangat keren, terima kasih banyak. Namun masih ada sisa. Dan sekarang, ketika saya berpikir untuk membuat semacam penggabungan dalam tabel, saya punya pertanyaan - mengapa saya tidak bisa memengaruhi penggabungan ini? Misalnya, batasi berdasarkan jumlah RAM yang dibutuhkan, atau, pada prinsipnya, berdasarkan jumlah yang akan memproses tabel khusus ini.
Saya memiliki tabel bernama "Metrik", harap proses untuk saya dalam dua rangkaian pesan. Tidak perlu membuat sepuluh atau lima penggabungan secara paralel, lakukan dalam dua. Saya pikir saya memiliki cukup memori untuk dua orang, tetapi mungkin tidak cukup untuk memproses sepuluh. Mengapa rasa takut masih ada? Karena tabelnya bertambah, dan suatu hari nanti saya akan dihadapkan pada situasi yang, pada prinsipnya, bukan lagi karena bug, tetapi karena data akan berubah dalam jumlah yang begitu besar sehingga saya tidak memiliki cukup memori di dalamnya. server. Dan kemudian server akan crash ke OOM saat penggabungan. Apalagi mutasinya bisa saya batalkan, tapi Merji sudah tidak ada lagi.
Tahukah Anda, saat penggabungan, server tidak akan masuk ke OOM, karena saat penggabungan, jumlah RAM yang digunakan hanya untuk satu rentang data yang kecil. Jadi semuanya akan baik-baik saja berapa pun jumlah datanya.
Vladimir Kolobaev: Bagus. Di sini momennya adalah setelah bug diperbaiki, saya mengunduh versi baru untuk diri saya sendiri, dan di tabel lain, yang lebih kecil, di mana ada banyak partisi, saya melakukan operasi serupa. Dan selama penggabungan, sekitar 100 GB RAM dibakar di server. Saya memiliki 150 yang ditempati, 100 yang dimakan, dan jendela tersisa 50 GB, jadi saya tidak jatuh ke dalam OOM.
Apa yang saat ini melindungi saya agar tidak terjerumus ke OOM jika itu benar-benar menghabiskan 100 GB RAM? Apa yang harus dilakukan jika tiba-tiba RAM yang di gabung habis?
Alexei Milovidov: Masalahnya adalah konsumsi RAM khusus untuk penggabungan tidak dibatasi. Dan masalah kedua adalah jika ada semacam penggabungan yang ditetapkan, maka harus dijalankan karena dicatat dalam log replikasi. Log replikasi adalah tindakan yang diperlukan untuk menjadikan replika ke keadaan konsisten. Jika Anda tidak melakukan manipulasi manual yang akan mengembalikan log replikasi ini, penggabungan harus dilakukan dengan satu atau lain cara.
Tentu saja, tidak berlebihan jika memiliki batasan RAM yang “berjaga-jaga” melindungi dari OOM. Itu tidak akan membantu penggabungan untuk menyelesaikannya, itu akan dimulai lagi, mencapai ambang batas tertentu, mengeluarkan pengecualian, dan kemudian memulai lagi - tidak ada hal baik yang akan terjadi dari ini. Namun pada prinsipnya, pembatasan ini akan bermanfaat.
Bagaimana driver Golang untuk ClickHouse dikembangkan?
Driver Golang yang ditulis oleh Kirill Shvakov kini resmi didukung oleh tim ClickHouse. Dia , dia sekarang sudah besar dan nyata.
Catatan kecil. Ada gudang bentuk normal tatanan tak terbatas yang indah dan dicintai - ini adalah Vertica. Mereka juga memiliki driver python resminya sendiri, yang didukung oleh pengembang Vertica. Dan beberapa kali terjadi perbedaan versi penyimpanan dan versi driver secara drastis, dan driver pada suatu saat berhenti bekerja. Dan poin kedua. Dukungan untuk driver resmi ini, menurut saya, dilakukan oleh sistem "puting" - Anda menulis masalah kepada mereka, dan itu hang selamanya.
Saya punya dua pertanyaan. Sekarang driver Golang Kirill hampir menjadi cara default untuk berkomunikasi dari Golang dengan ClickHouse. Kecuali seseorang masih berkomunikasi melalui antarmuka http karena dia suka seperti itu. Bagaimana kelanjutan pengembangan driver ini? Apakah ini akan disinkronkan dengan perubahan apa pun yang dapat menyebabkan gangguan pada repositori itu sendiri? Dan bagaimana prosedur untuk mempertimbangkan suatu masalah?
Kirill Shvakov: Yang pertama adalah bagaimana segala sesuatunya diatur secara birokratis. Poin ini tidak dibahas, jadi saya tidak punya jawaban apa pun.
Untuk menjawab pertanyaan mengenai masalah tersebut, kita memerlukan sedikit riwayat pengemudi. Saya bekerja di perusahaan yang memiliki banyak data. Itu adalah pemutar periklanan dengan sejumlah besar peristiwa yang perlu disimpan di suatu tempat. Dan suatu saat ClickHouse muncul. Kami mengisinya dengan data, dan pada awalnya semuanya baik-baik saja, tapi kemudian ClickHouse mogok. Pada saat itu kami memutuskan bahwa kami tidak membutuhkannya.
Setahun kemudian, kami kembali ke ide menggunakan ClickHouse, dan kami perlu menulis data di sana. Pesan pengantarnya adalah ini: perangkat kerasnya sangat lemah, sumber dayanya sedikit. Namun kami selalu bekerja dengan cara ini, dan oleh karena itu kami melihat ke arah protokol asli.
Sejak kami bekerja di Go, jelas bahwa kami membutuhkan driver Go. Saya melakukannya hampir penuh waktu - itu adalah tugas pekerjaan saya. Kami membawanya ke titik tertentu, dan pada prinsipnya tidak ada yang berasumsi bahwa orang lain selain kami akan menggunakannya. Kemudian CloudFlare hadir dengan masalah yang persis sama, dan untuk beberapa waktu kami menanganinya dengan sangat lancar, karena mereka memiliki tugas yang sama. Selain itu, kami melakukan ini baik di ClickHouse sendiri maupun di driver.
Pada titik tertentu, saya berhenti melakukannya, karena aktivitas saya di ClickHouse dan pekerjaan saya sedikit berubah. Oleh karena itu permasalahan belum selesai. Secara berkala, orang-orang yang membutuhkan sesuatu berkomitmen pada repositori. Kemudian saya melihat permintaan tarik dan kadang-kadang saya bahkan mengedit sesuatu sendiri, tetapi ini jarang terjadi.
Saya ingin kembali ke pengemudi. Beberapa tahun yang lalu, ketika semua ini dimulai, ClickHouse juga berbeda dan dengan kemampuan berbeda. Sekarang kita sudah paham bagaimana cara merombak driver agar berfungsi dengan baik. Jika ini terjadi, maka versi 2 tidak akan kompatibel karena akumulasi kruk.
Saya tidak tahu bagaimana mengatur masalah ini. Saya sendiri tidak punya banyak waktu. Jika beberapa orang menyelesaikan pengemudinya, saya dapat membantu mereka dan memberi tahu mereka apa yang harus dilakukan. Namun partisipasi aktif Yandex dalam pengembangan proyek tersebut belum dibahas.
Alexei Milovidov: Faktanya, belum ada birokrasi mengenai para pengemudi tersebut. Satu-satunya hal adalah mereka dikirimkan ke organisasi resmi, yaitu driver ini diakui sebagai solusi default resmi untuk Go. Ada beberapa pengemudi lain, tapi mereka datang terpisah.
Kami tidak memiliki pengembangan internal untuk driver ini. Pertanyaannya adalah apakah kita dapat mempekerjakan seseorang, bukan untuk pengemudi tertentu, tetapi untuk pengembangan semua pengemudi komunitas, atau dapatkah kita mencari seseorang dari luar.
Kamus eksternal tidak dimuat setelah reboot dengan pengaturan lazy_load diaktifkan. Apa yang harus dilakukan?
Kami mengaktifkan pengaturan lazy_load, dan setelah server di-boot ulang, kamus tidak dimuat dengan sendirinya. Itu dimunculkan hanya setelah pengguna mengakses kamus ini. Dan pertama kali saya mengaksesnya memberikan error. Apakah mungkin untuk memuat kamus secara otomatis menggunakan ClickHouse, atau apakah Anda harus selalu mengontrol sendiri kesiapannya agar pengguna tidak menerima kesalahan?
Mungkin kita memiliki ClickHouse versi lama, sehingga kamus tidak dimuat secara otomatis. Mungkinkah ini masalahnya?
Pertama, kamus dapat dimuat secara paksa menggunakan kueri kamus isi ulang sistem. Kedua, mengenai kesalahan - jika kamus sudah dimuat, maka kueri akan berfungsi berdasarkan data yang dimuat. Jika kamus belum dimuat, kamus akan dimuat langsung saat permintaan.
Ini sangat tidak nyaman untuk kamus yang berat. Misalnya, Anda perlu menarik sejuta baris dari MySQL. Seseorang membuat pilihan sederhana, tetapi pilihan ini akan menunggu jutaan baris yang sama. Ada dua solusi di sini. Yang pertama adalah mematikan lazy_load. Kedua, ketika server aktif, sebelum memuatnya, lakukan kamus isi ulang sistem atau cukup lakukan query yang menggunakan kamus. Kemudian kamus akan dimuat. Anda perlu mengontrol ketersediaan kamus dengan pengaturan lazy_load diaktifkan, karena ClickHouse tidak memuatnya secara otomatis.
Jawaban atas pertanyaan terakhir adalah versinya sudah lama atau perlu di-debug.
Apa yang harus dilakukan dengan fakta bahwa kamus yang memuat ulang sistem tidak memuat salah satu dari banyak kamus jika setidaknya salah satu dari kamus tersebut mogok karena kesalahan?
Ada pertanyaan lain tentang kamus isi ulang sistem. Kami memiliki dua kamus - satu tidak dimuat, yang kedua dimuat. Dalam hal ini, kamus muat ulang sistem tidak memuat kamus apa pun, dan Anda harus memuat kamus tertentu berdasarkan namanya menggunakan kamus muat ulang sistem. Apakah ini juga terkait dengan versi ClickHouse?
Saya ingin membuatmu bahagia. Perilaku ini berubah. Artinya jika Anda memperbarui ClickHouse, itu juga akan berubah. Jika Anda tidak senang dengan perilaku Anda saat ini kamus isi ulang sistem, perbarui, dan semoga berubah menjadi lebih baik.
Apakah ada cara untuk mengonfigurasi detail di konfigurasi ClickHouse, tetapi tidak menampilkannya jika terjadi kesalahan?
Pertanyaan selanjutnya mengenai kesalahan yang berhubungan dengan kamus yaitu detail. Kami telah menentukan detail koneksi di konfigurasi ClickHouse untuk kamus, dan jika ada kesalahan, kami menerima detail dan kata sandi ini sebagai tanggapan.
Kami mengatasi kesalahan ini dengan menambahkan detail ke konfigurasi driver ODBC. Apakah ada cara untuk mengonfigurasi detail di konfigurasi ClickHouse, tetapi tidak menampilkan detail ini jika terjadi kesalahan?
Solusi sebenarnya di sini adalah dengan menentukan kredensial ini di odbc.ini, dan di ClickHouse sendiri tentukan hanya Nama Sumber Data ODBC. Hal ini tidak akan terjadi untuk sumber kamus lain - baik untuk kamus dengan MySQL, maupun yang lain, Anda tidak akan melihat kata sandi saat Anda menerima pesan kesalahan. Saya juga akan mencari ODBC - jika ada, Anda hanya perlu menghapusnya.
Bonus: latar belakang Zoom dari pertemuan
Dengan mengklik gambar, bonus latar belakang dari pertemuan tersebut akan terbuka untuk pembaca yang paling gigih. Kami memadamkan api bersama maskot teknologi Avito, kami berunding dengan kolega dari ruang administrator sistem atau klub komputer jadul, dan kami mengadakan pertemuan harian di bawah jembatan dengan latar belakang grafiti.
Sumber: www.habr.com