Pada awal tahun, kami memutuskan untuk belajar cara menyimpan dan membaca log debugging VK lebih efisien dari sebelumnya. Log debugging, misalnya, log konversi video (pada dasarnya output dari perintah ffmpeg dan daftar langkah-langkah untuk file preprocessing), yang kadang-kadang kita hanya perlu 2-3 bulan setelah memproses file masalah.
Pada saat itu, kami memiliki 2 cara untuk menyimpan dan memproses log - mesin log kami sendiri dan rsyslog, yang kami gunakan secara paralel. Kami mulai mempertimbangkan opsi lain dan menyadari bahwa ClickHouse dari Yandex cukup cocok untuk kami - kami memutuskan untuk menerapkannya.
Dalam artikel ini saya akan berbicara tentang bagaimana kami mulai menggunakan ClickHouse di VKontakte, yang telah kami injak, dan apa itu KittenHouse dan LightHouse. Kedua produk diletakkan di sumber terbuka, tautan di akhir artikel.
Tugas pengumpulan log
Persyaratan Sistem:
- Penyimpanan ratusan terabyte log.
- Penyimpanan selama berbulan-bulan atau (jarang) tahun.
- Kecepatan menulis tinggi.
- Kecepatan membaca tinggi (jarang membaca).
- Dukungan Indeks
- Dukungan untuk string panjang (> 4 Kb).
- Kesederhanaan operasi.
- Penyimpanan kompak.
- Kemampuan untuk memasukkan dari puluhan ribu server (UDP akan menjadi nilai tambah).
Kemungkinan solusi
Mari kita secara singkat daftar opsi yang kita pertimbangkan, dan kontra mereka:
Mesin log
Layanan catatan tertulis kami untuk log.
- Mampu memberikan hanya N baris terakhir yang sesuai dengan RAM.
- Penyimpanan tidak terlalu kompak (tidak ada kompresi transparan).
Hadoop
- Tidak semua format memiliki indeks.
- Kecepatan membaca bisa lebih tinggi (tergantung format).
- Kompleksitas pengaturan.
- Tidak mungkin untuk memasukkan dari puluhan ribu server (Kafka atau analog diperlukan).
File Rsyslog +
- Tidak ada indeks.
- Kecepatan baca rendah (grep reguler / zgrep).
- Arsitektur tidak didukung string> 4 Kb, UDP bahkan kurang (1,5 Kb).
± Penyimpanan kompak dicapai dengan logrotate di atas mahkota
Kami menggunakan rsyslog sebagai cadangan untuk penyimpanan jangka panjang, tetapi garis panjang terpotong, sehingga hampir tidak bisa disebut ideal.
File LSD +
- Tidak ada indeks.
- Kecepatan baca rendah (grep reguler / zgrep).
- Tidak dirancang khusus untuk pemasangan dari puluhan ribu server.
± Penyimpanan kompak dicapai dengan logrotate di atas mahkota.
Perbedaan dari rsyslog dalam kasus kami adalah bahwa LSD mendukung string panjang, tetapi perubahan signifikan pada protokol internal diperlukan untuk memasukkan dari puluhan ribu server, meskipun ini dapat dilakukan.
Pencarian Elastics
- Masalah dengan operasi.
- Rekaman tidak stabil.
- Tidak ada UDP.
- Kompresi buruk.
Tumpukan ELK sudah hampir standar industri untuk penyimpanan log. Dalam pengalaman kami, semuanya baik-baik saja dengan kecepatan membaca, tetapi ada masalah dengan menulis, misalnya, saat menggabungkan indeks.
ElasticSearch terutama dirancang untuk pencarian teks lengkap dan permintaan membaca yang relatif sering. Bagi kami, perekaman yang stabil dan kemampuan untuk membaca data kami lebih atau kurang cepat lebih penting, dan secara kebetulan. Indeks di ElasticSearch dipertajam untuk pencarian teks lengkap, dan ruang disk cukup besar dibandingkan dengan gzip konten asli.
Clickhouse
- Tidak ada UDP.
Secara umum, satu-satunya hal yang tidak sesuai dengan kami di ClickHouse adalah kurangnya komunikasi UDP. Bahkan, dari opsi di atas, hanya rsyslog yang memilikinya, tetapi rsyslog tidak mendukung garis yang panjang.
Menurut kriteria lain, ClickHouse mendatangi kami, dan kami memutuskan untuk menggunakannya, dan masalah dengan transportasi diselesaikan dalam proses.
Mengapa KittenHouse dibutuhkan
Seperti yang mungkin Anda ketahui, VKontakte bekerja di PHP / KPHP, dengan "mesin" (microservices) di C / C ++ dan sedikit on Go. PHP tidak memiliki konsep "keadaan" antara permintaan, kecuali mungkin untuk memori bersama dan koneksi terbuka.
Karena kami memiliki puluhan ribu server dari mana kami ingin dapat mengirim log ke ClickHouse, itu akan tidak menguntungkan untuk menjaga koneksi terbuka dari setiap pekerja PHP (mungkin ada lebih dari 100 pekerja untuk setiap server). Oleh karena itu, kami memerlukan semacam proxy antara ClickHouse dan PHP. Kami menyebut proksi ini KittenHouse.
KittenHouse, v1
Pertama, kami memutuskan untuk mencoba skema yang paling sederhana untuk memahami apakah pendekatan kami akan berhasil atau tidak. Jika Kafka muncul di benak Anda ketika memecahkan masalah ini, maka Anda tidak sendirian. Namun, kami tidak ingin menggunakan server perantara tambahan - dalam hal ini, kami dapat dengan mudah mengandalkan kinerja server ini, dan bukan ClickHouse itu sendiri. Selain itu, kami mengumpulkan log dan kami membutuhkan penundaan penyisipan data yang dapat diprediksi dan kecil. Skemanya adalah sebagai berikut:
Pada masing-masing server, proksi lokal kami (kittenhouse) diinstal, dan setiap instance menjaga ketat satu koneksi HTTP dengan server ClickHouse yang diperlukan. Tempel dilakukan dalam tabel spooled, karena MergeTree sering tidak direkomendasikan untuk dimasukkan.
Fitur KittenHouse, v1
Versi pertama KittenHouse tahu sedikit, tetapi ini cukup untuk pengujian:
- Komunikasi melalui RPC (Skema TL) kami.
- Pertahankan 1 koneksi TCP / IP per server.
- In-memory buffering secara default, dengan ukuran buffer yang terbatas (sisanya dibuang).
- Kemampuan menulis ke disk, dalam hal ini ada jaminan pengiriman (setidaknya sekali).
- Interval penyisipan adalah setiap 2 detik sekali.
Masalah pertama
Kami mengalami masalah pertama ketika kami "melunasi" server ClickHouse selama beberapa jam dan kemudian menyalakannya kembali. Di bawah ini Anda dapat melihat rata-rata beban di server setelah "naik":
Penjelasannya cukup sederhana: ClickHouse memiliki model jaringan per utas, jadi ketika saya mencoba membuat INSERT dari ribuan node pada saat yang sama, ada persaingan yang sangat kuat untuk sumber daya CPU dan server hampir tidak menanggapi. Namun, semua data akhirnya dimasukkan dan tidak ada yang jatuh.
Untuk mengatasi masalah ini, kami menempatkan nginx di depan ClickHouse dan, secara umum, ini membantu.
Pengembangan lebih lanjut
Selama operasi, kami menemukan sejumlah masalah, terutama yang terkait bukan dengan ClickHouse, tetapi dengan cara kami mengoperasikannya. Berikut rake lain yang kami injak:
Sejumlah besar "potongan" dari tabel Buffer menyebabkan seringnya buffer flush di MergeTree
Dalam kasus kami, ada 16 lembar buffer dan interval reset setiap 2 detik, dan ada 20 lembar tabel, yang memberikan hingga 160 sisipan per detik. Ini secara berkala mempengaruhi kinerja penyisipan sangat buruk - ada banyak penggabungan latar belakang dan pemanfaatan disk mencapai 80% dan lebih tinggi.
Solusi: tambah interval reset buffer default, kurangi jumlah kepingan menjadi 2.
Nginx mengembalikan 502 ketika koneksi ke ujung hulu
Ini sendiri bukan masalah, tetapi dalam kombinasi dengan pembilasan buffer yang sering, ini memberikan latar belakang 502 kesalahan yang agak tinggi ketika mencoba memasukkan ke dalam tabel mana saja, serta ketika mencoba untuk melakukan SELECT.
Solusi: mereka menulis proksi terbalik menggunakan perpustakaan
fasthttp , yang mengelompokkan sisipan ke dalam tabel dan menggunakan koneksi dengan sangat ekonomis. Ini juga membedakan antara SELECT dan INSERT dan memiliki kumpulan koneksi terpisah untuk penyisipan dan membaca.
Kehabisan memori dengan penyisipan intensif
Pustaka fasthttp memiliki kelebihan dan kekurangan. Salah satu kelemahannya adalah bahwa permintaan dan respons sepenuhnya buffered dalam memori sebelum memberikan kontrol kepada penangan permintaan. Bagi kami, ini menghasilkan fakta bahwa jika memasukkan ke dalam ClickHouse “tidak punya waktu”, maka buffer mulai tumbuh dan akhirnya semua memori di server habis, yang menyebabkan terbunuhnya proxy terbalik oleh OOM. Kolega menggambar demotivator:
Solusi: menambal fasthttp untuk mendukung streaming isi permintaan POST ternyata menjadi tugas yang menakutkan, jadi kami memutuskan untuk menggunakan koneksi Hijack () dan memutakhirkan koneksi ke protokol kami jika permintaan tersebut datang dengan metode HTTP KITTEN. Karena server harus membalas MEOW sebagai respons, jika memahami protokol ini, seluruh skema disebut protokol KITTEN / MEOW.
Kami hanya membaca dari 50 koneksi acak pada satu waktu, oleh karena itu, berkat TCP / IP, seluruh klien "menunggu" dan kami tidak menghabiskan memori pada buffer sampai antrian mencapai klien yang sesuai. Ini mengurangi konsumsi memori setidaknya 20 kali, dan kami tidak punya masalah seperti itu lagi.
Tabel ALTER bisa lama jika ada pertanyaan panjang
ClickHouse memiliki ALTER non-pemblokiran dalam arti bahwa itu tidak mengganggu permintaan SELECT dan INSERT. Tetapi ALTER tidak dapat memulai sampai selesai mengeksekusi kueri ke tabel ini dikirim sebelum ALTER.
Jika server Anda memiliki latar belakang "panjang" kueri untuk beberapa tabel, maka Anda mungkin menghadapi situasi di mana ALTER pada tabel ini tidak akan punya waktu untuk mengeksekusi dalam batas waktu default 60 detik. Tetapi ini tidak berarti bahwa ALTER akan gagal: itu akan dieksekusi segera setelah permintaan SELECT tersebut selesai.
Ini berarti bahwa Anda tidak tahu pada titik waktu ALTER benar-benar terjadi, dan Anda tidak memiliki kemampuan untuk secara otomatis membuat kembali tabel Buffer sehingga tata letaknya selalu sama. Ini dapat menyebabkan masalah penyisipan.
Solusi: Sebagai hasilnya, kami berencana untuk sepenuhnya mengabaikan penggunaan tabel buffer. Secara umum, tabel buffer memiliki ruang lingkup, sejauh ini kami menggunakannya dan tidak mengalami masalah besar. Tapi sekarang kita akhirnya mencapai titik di mana lebih mudah untuk mengimplementasikan fungsi tabel buffer di sisi proxy sebaliknya daripada terus memasang kekurangannya. Contoh rangkaian akan terlihat seperti ini (garis putus-putus menunjukkan asinkron ACK pada INSERT).
Membaca data
Katakanlah kita menemukan sisipan. Bagaimana cara membaca log ini dari ClickHouse? Sayangnya, kami tidak menemukan alat yang mudah digunakan dan mudah digunakan untuk membaca data mentah (tanpa grafik dan lainnya) dari ClickHouse, jadi kami menulis solusi kami sendiri - LightHouse. Kemampuannya agak sederhana:
- Tampilan cepat isi tabel.
- Memfilter, menyortir.
- Mengedit kueri SQL.
- Lihat struktur tabel.
- Menunjukkan perkiraan jumlah garis dan ruang disk yang digunakan.
Namun, LightHouse cepat dan mampu melakukan apa yang kita butuhkan. Berikut ini beberapa tangkapan layar:
Lihat struktur tabel
Penyaringan Konten
Hasil
ClickHouse praktis satu-satunya database open-source yang telah berakar pada VKontakte. Kami senang dengan kecepatan kerjanya dan siap untuk menerima kekurangan, yang dibahas di bawah ini.
Kesulitan dalam bekerja
Secara keseluruhan, ClickHouse adalah basis data yang sangat stabil dan sangat cepat. Namun, seperti halnya produk apa pun, terutama yang masih muda, ada fitur dalam pekerjaan yang perlu dipertimbangkan:
- Tidak semua versi sama-sama stabil: jangan memutakhirkan langsung ke versi baru pada produksi, lebih baik menunggu beberapa rilis perbaikan bug.
- Untuk kinerja yang optimal, sangat disarankan untuk mengkonfigurasi RAID dan beberapa hal lain sesuai dengan instruksi. Ini baru - baru ini dilaporkan pada beban tinggi .
- Replikasi tidak memiliki batas kecepatan bawaan dan dapat menyebabkan penurunan kinerja server yang signifikan jika Anda tidak membatasi sendiri (tetapi mereka berjanji untuk memperbaikinya).
- Linux memiliki fitur yang tidak menyenangkan dari mekanisme memori virtual: jika Anda secara aktif menulis ke disk dan data tidak punya waktu untuk dibilas, pada beberapa titik server benar-benar "masuk sendiri", mulai aktif menyiram cache halaman ke disk dan hampir sepenuhnya memblokir proses ClickHouse. Ini kadang-kadang terjadi dengan penggabungan besar, dan Anda perlu memonitor ini, misalnya, menyiram buffer secara berkala atau melakukan sinkronisasi.
Sumber terbuka
KittenHouse dan LightHouse sekarang tersedia dalam sumber terbuka di repositori github kami:
Terima kasih
Yuri Nasretdinov, pengembang di departemen infrastruktur backend VKontakte