HighLoad++ Moskow 2018, Gedung Kongres. 9 November, 15:00
Abstrak dan presentasi:
Yuri Nasretdinov (VKontakte): laporan ini akan membahas tentang pengalaman menerapkan ClickHouse di perusahaan kami - mengapa kami membutuhkannya, berapa banyak data yang kami simpan, bagaimana kami menulisnya, dan sebagainya.
Bahan tambahan:
Yuri Nasretdinov: - Halo semua! Nama saya Yuri Nasretdinov, seperti yang telah saya perkenalkan. Saya bekerja di VKontakte. Saya akan berbicara tentang bagaimana kami memasukkan data ke ClickHouse dari armada server kami (puluhan ribu).
Apa itu log dan mengapa mengumpulkannya?
Apa yang akan kami sampaikan kepada Anda: apa yang kami lakukan, mengapa kami membutuhkan "ClickHouse", masing-masing, mengapa kami memilihnya, kinerja seperti apa yang kira-kira bisa Anda dapatkan tanpa mengonfigurasi apa pun secara khusus. Saya akan memberi tahu Anda lebih lanjut tentang tabel buffer, tentang masalah yang kami hadapi dengannya, dan tentang solusi yang kami kembangkan dari sumber terbuka - KittenHouse dan Lighthouse.
Mengapa kita perlu melakukan apa pun (semuanya selalu baik di VKontakte, bukan?). Kami ingin mengumpulkan log debug (dan ada ratusan terabyte data di sana), mungkin akan lebih mudah untuk menghitung statistik; dan kami memiliki puluhan ribu server yang menjadi tempat melakukan semua hal ini.
Mengapa kami memutuskan? Kami mungkin punya solusi untuk menyimpan log. Di sini – ada “Backend VK” publik. Saya sangat merekomendasikan untuk berlangganan.
Apa itu log? Ini adalah mesin yang mengembalikan array kosong. Mesin di VK adalah apa yang disebut layanan mikro. Dan ini stiker tersenyum (cukup banyak yang suka). Bagaimana? Baiklah, dengarkan lebih lanjut!
Apa yang bisa digunakan untuk menyimpan log? Mustahil untuk tidak menyebut Hadup. Kemudian, misalnya, Rsyslog (menyimpan log ini dalam file). LSD. Siapa yang tahu apa itu LSD? Bukan, bukan LSD ini. Simpan file masing-masing juga. ClickHouse adalah pilihan yang aneh.
Clickhouse dan pesaing: persyaratan dan peluang
Apa yang kita inginkan? Kami ingin memastikan bahwa kami tidak perlu terlalu khawatir tentang pengoperasiannya, sehingga dapat langsung berfungsi, sebaiknya dengan konfigurasi minimal. Kami ingin banyak menulis, dan menulis dengan cepat. Dan kami ingin menyimpannya selama berbulan-bulan, bertahun-tahun, untuk waktu yang lama. Kami mungkin ingin memahami beberapa masalah yang mereka datangi kepada kami dan berkata, "Ada yang tidak beres di sini," dan itu terjadi 3 bulan yang lalu), dan kami ingin dapat melihat apa yang terjadi 3 bulan yang lalu " Kompresi data – jelas mengapa ini menjadi nilai tambah – karena mengurangi jumlah ruang yang digunakan.
Dan kami memiliki persyaratan yang menarik: terkadang kami menulis output dari beberapa perintah (misalnya, log), dengan mudah bisa lebih dari 4 kilobyte. Dan jika hal ini berfungsi melalui UDP, maka tidak perlu mengeluarkan uang... tidak akan ada "overhead" untuk koneksi, dan untuk sejumlah besar server ini akan menjadi nilai tambah.
Mari kita lihat apa yang ditawarkan open source kepada kita. Pertama, kami memiliki Logs Engine - ini adalah mesin kami; Prinsipnya dia bisa melakukan apa saja, bahkan bisa menulis antrean panjang. Yah, itu tidak mengompresi data secara transparan - kita dapat mengompres sendiri kolom besar jika kita mau... tentu saja kita tidak mau (jika memungkinkan). Satu-satunya masalah adalah dia hanya bisa memberikan apa yang sesuai dengan ingatannya; Untuk membaca selebihnya, Anda perlu mendapatkan binlog mesin ini dan karenanya membutuhkan waktu yang cukup lama.
Apa pilihan lain yang ada? Misalnya, "Hadup". Kemudahan pengoperasian... Siapa yang mengira Hadup mudah diatur? Tentu saja tidak ada masalah dengan rekamannya. Saat membaca, terkadang muncul pertanyaan. Pada prinsipnya, menurut saya mungkin tidak, terutama untuk log. Penyimpanan jangka panjang - tentu saja, ya, kompresi data - ya, string panjang - jelas Anda dapat merekam. Tapi merekam dari sejumlah besar server... Anda masih harus melakukan sesuatu sendiri!
RSYSLOG. Faktanya, kami menggunakannya sebagai opsi cadangan sehingga kami dapat membacanya tanpa membuang binlog, tetapi tidak dapat menulis baris yang panjang; pada prinsipnya, tidak dapat menulis lebih dari 4 kilobyte. Anda sendiri harus melakukan kompresi data dengan cara yang sama. Membaca akan datang dari file.
Lalu ada pengembangan “badushka” dari LSD. Pada dasarnya sama dengan "Rsyslog": ia mendukung string panjang, tetapi tidak dapat bekerja melalui UDP dan, pada kenyataannya, sayangnya, banyak hal yang perlu ditulis ulang di sana. LSD perlu didesain ulang agar dapat merekam dari puluhan ribu server.
Dan di sini! Pilihan yang lucu adalah ElasticSearch. Bagaimana mengatakan? Dia mampu membaca dengan baik, artinya dia membaca dengan cepat, tetapi kurang pandai dalam menulis. Pertama, jika mengompresi data, itu sangat lemah. Kemungkinan besar, pencarian lengkap memerlukan struktur data yang lebih besar daripada volume aslinya. Sulit untuk dioperasikan dan sering timbul masalah. Dan, sekali lagi, merekam di Elastic - kita harus melakukan semuanya sendiri.
Di sini ClickHouse tentu saja merupakan pilihan ideal. Satu-satunya hal adalah rekaman dari puluhan ribu server merupakan masalah. Tapi setidaknya ada satu masalah, kita bisa mencoba menyelesaikannya. Dan laporan selanjutnya adalah tentang masalah ini. Kinerja seperti apa yang dapat Anda harapkan dari ClickHouse?
Bagaimana kita akan memasukkannya? Gabungkan Pohon
Siapa di antara Anda yang belum pernah mendengar atau mengetahui tentang “ClickHouse”? Aku perlu memberitahumu, bukan? Sangat cepat. Penyisipan di sana - 1-2 gigabit per detik, ledakan hingga 10 gigabit per detik sebenarnya dapat menahan konfigurasi ini - ada dua Xeon 6-core (yang bahkan bukan yang paling kuat), RAM 256 gigabyte, 20 terabyte di RAID (tidak ada yang dikonfigurasi, pengaturan default). Alexei Milovidov, pengembang ClickHouse, mungkin duduk menangis karena kami tidak mengonfigurasi apa pun (semuanya berfungsi seperti itu bagi kami). Oleh karena itu, kecepatan pemindaian, katakanlah, sekitar 6 miliar baris per detik dapat diperoleh jika data dikompresi dengan baik. Jika Anda menyukai % pada string teks - 100 juta baris per detik, sepertinya cukup cepat.
Bagaimana kita akan memasukkannya? Nah, tahukah Anda kalau VK menggunakan PHP. Kami akan memasukkan dari setiap pekerja PHP melalui HTTP ke “ClickHouse”, ke dalam tabel MergeTree untuk setiap record. Siapa yang melihat ada masalah dengan skema ini? Untuk beberapa alasan, tidak semua orang mengangkat tangan. Biarkan aku memberitahu Anda.
Pertama, ada banyak server - karenanya, akan ada banyak koneksi (buruk). Maka sebaiknya masukkan data ke MergeTree tidak lebih dari sekali per detik. Dan siapa yang tahu alasannya? Baiklah baiklah. Saya akan bercerita lebih banyak tentang ini. Pertanyaan menarik lainnya adalah kami tidak melakukan analitik, kami tidak perlu memperkaya data, kami tidak memerlukan server perantara, kami ingin memasukkan langsung ke “ClickHouse” (sebaiknya - semakin langsung, semakin baik).
Oleh karena itu, bagaimana penyisipan dilakukan di MergeTree? Mengapa lebih baik memasukkannya tidak lebih dari sekali dalam satu detik atau lebih jarang? Faktanya adalah bahwa "ClickHouse" adalah database berbentuk kolom dan mengurutkan data dalam urutan menaik dari kunci utama, dan ketika Anda melakukan penyisipan, sejumlah file dibuat setidaknya sama dengan jumlah kolom tempat data diurutkan. dalam urutan menaik dari kunci utama (direktori terpisah dibuat, sekumpulan file pada disk untuk setiap penyisipan). Kemudian penyisipan berikutnya datang, dan di latar belakang mereka digabungkan menjadi “partisi” yang lebih besar. Karena data diurutkan, dimungkinkan untuk “menggabungkan” dua file yang diurutkan tanpa menghabiskan banyak memori.
Namun, seperti yang Anda duga, jika Anda menulis 10 file untuk setiap penyisipan, maka ClickHouse (atau server Anda) akan segera berakhir, jadi disarankan untuk memasukkan dalam jumlah besar. Oleh karena itu, kami tidak pernah meluncurkan skema pertama ke dalam produksi. Kami segera meluncurkannya, yang di sini No. 2 memiliki:
Di sini bayangkan ada sekitar seribu server yang kami luncurkan, yang ada hanya PHP. Dan di setiap server terdapat agen lokal kami, yang kami sebut “Kittenhouse”, yang memelihara satu koneksi dengan “ClickHouse” dan memasukkan data setiap beberapa detik. Memasukkan data bukan ke MergeTree, tetapi ke dalam tabel buffer, yang berfungsi secara tepat untuk menghindari penyisipan langsung ke MergeTree.
Bekerja dengan tabel buffer
Apa itu? Tabel buffer adalah bagian memori yang dipecah (yaitu, dapat sering dimasukkan ke dalamnya). Mereka terdiri dari beberapa bagian, dan masing-masing bagian berfungsi sebagai buffer independen, dan di-flush secara independen (jika Anda memiliki banyak bagian di buffer, maka akan ada banyak sisipan per detik). Dimungkinkan untuk membaca dari tabel ini - kemudian Anda membaca gabungan isi buffer dan tabel induk, tetapi saat ini penulisan diblokir, jadi lebih baik tidak membaca dari sana. Dan tabel buffer menunjukkan QPS yang sangat baik, yaitu hingga 3 ribu QPS Anda tidak akan mengalami masalah sama sekali saat memasukkan. Jelas jika server kehilangan daya, maka data bisa hilang, karena hanya tersimpan di memori.
Pada saat yang sama, skema dengan buffer memperumit ALTER, karena Anda harus terlebih dahulu membuang tabel buffer lama dengan skema lama (data tidak akan hilang kemana-mana, karena akan dihapus sebelum tabel dihapus). Kemudian Anda “mengubah” tabel yang Anda perlukan dan membuat tabel buffer lagi. Oleh karena itu, meskipun tidak ada tabel buffer, data Anda tidak akan mengalir ke mana pun, tetapi Anda dapat menyimpannya di disk setidaknya secara lokal.
Apa itu Kittenhouse dan bagaimana cara kerjanya?
Apa itu KittenHouse? Ini adalah proksi. Coba tebak bahasa apa? Saya mengumpulkan topik paling hype dalam laporan saya - “Clickhouse”, Ayo, mungkin saya akan mengingat hal lain. Ya ini ditulis di Go, karena saya tidak begitu tahu cara menulis di C, saya tidak mau.
Oleh karena itu, ia memelihara koneksi dengan setiap server dan dapat menulis ke memori. Misalnya, jika kita menulis log kesalahan ke Clickhouse, maka jika Clickhouse tidak punya waktu untuk memasukkan data (lagi pula, jika terlalu banyak yang ditulis), maka kita tidak menambah memori - kita membuang sisanya. Karena jika kita menulis kesalahan beberapa gigabit per detik, maka kita mungkin bisa membuangnya. Rumah kucing bisa melakukan ini. Selain itu, ia dapat melakukan pengiriman yang andal, yaitu menulis ke disk pada mesin lokal dan setiap kali (di sana, setiap beberapa detik sekali) ia mencoba mengirimkan data dari file ini. Dan pada awalnya kami menggunakan format Nilai biasa - bukan format biner, format teks (seperti dalam SQL biasa).
Tapi kemudian hal ini terjadi. Kami menggunakan pengiriman yang andal, menulis log, lalu memutuskan (itu adalah cluster pengujian bersyarat)... Itu dimatikan selama beberapa jam dan dihidupkan kembali, dan penyisipan dimulai dari seribu server - ternyata Clickhouse masih memiliki "Thread on connection" - karenanya, dalam seribu koneksi, penyisipan aktif menghasilkan rata-rata beban di server sekitar satu setengah ribu. Anehnya, server menerima permintaan, namun data masih dimasukkan setelah beberapa waktu; tapi sangat sulit bagi server untuk menyajikannya..
Tambahkan nginx
Solusi untuk model Thread per koneksi adalah nginx. Kami menginstal nginx di depan Clickhouse, pada saat yang sama mengatur penyeimbangan untuk dua replika (kecepatan penyisipan kami meningkat 2 kali lipat, meskipun bukan fakta bahwa hal ini seharusnya terjadi) dan membatasi jumlah koneksi ke Clickhouse, ke upstream dan, karenanya, lebih dari 50 koneksi, sepertinya tidak ada gunanya memasukkan.
Kemudian kami menyadari bahwa skema ini umumnya memiliki kelemahan, karena kami hanya memiliki satu nginx di sini. Oleh karena itu, jika nginx ini mogok, meskipun terdapat replika, kami kehilangan data atau, setidaknya, tidak menulis di mana pun. Itu sebabnya kami membuat penyeimbangan beban sendiri. Kami juga menyadari bahwa "Clickhouse" masih cocok untuk log, dan "iblis" juga mulai menulis lognya di "Clickhouse" - sejujurnya sangat nyaman. Kami masih menggunakannya untuk “setan” lainnya.
Kemudian kami menemukan masalah menarik ini: jika Anda menggunakan metode penyisipan non-standar dalam mode SQL, ini akan memaksa parser SQL berbasis AST yang lengkap, yang cukup lambat. Oleh karena itu, kami telah menambahkan pengaturan untuk memastikan hal ini tidak pernah terjadi. Kami melakukan loadbalancing, health check, sehingga jika ada yang mati, datanya tetap kami tinggalkan. Kami sekarang memiliki cukup banyak tabel yang kami perlukan untuk memiliki cluster Clickhouse yang berbeda. Dan kami juga mulai memikirkan kegunaan lain - misalnya, kami ingin menulis log dari modul nginx, tetapi mereka tidak tahu cara berkomunikasi menggunakan RPC kami. Baiklah, saya ingin mengajari mereka cara mengirim setidaknya entah bagaimana - misalnya, menerima acara di localhost melalui UDP dan kemudian meneruskannya ke Clickhouse.
Satu langkah lagi dari solusi
Skema terakhir mulai terlihat seperti ini (versi keempat dari skema ini): di setiap server di depan Clickhouse ada nginx (di server yang sama) dan itu hanya mem-proxy permintaan ke localhost dengan batasan jumlah koneksi 50 bagian-bagian. Dan skema ini sudah cukup berhasil, semuanya berjalan cukup baik.
Kami hidup seperti ini selama sekitar satu bulan. Semua senang, mereka menambahkan tabel, mereka menambahkan, mereka menambahkan... Secara umum, ternyata cara kami menambahkan tabel buffer kurang optimal (biarkan saja). Kami membuat 16 buah di setiap tabel dan interval waktu beberapa detik; kami memiliki 20 tabel dan setiap tabel menerima 8 sisipan per detik - dan pada titik ini “Clickhouse” dimulai... pencatatan mulai melambat. Mereka bahkan tidak melewatinya... Nginx secara default memiliki hal yang sangat menarik sehingga jika koneksi berakhir di upstream, maka ia akan mengembalikan "502" ke semua permintaan baru.
Dan di sini kita punya (saya baru saja melihat log di Clickhouse itu sendiri) sekitar setengah persen permintaan gagal. Oleh karena itu, pemanfaatan disk tinggi, terjadi banyak penggabungan. Nah, apa yang saya lakukan? Tentu saja, saya tidak repot-repot mencari tahu mengapa sebenarnya koneksi dan upstream berakhir.
Mengganti nginx dengan proxy terbalik
Saya memutuskan bahwa kita perlu mengelolanya sendiri, kita tidak perlu menyerahkannya kepada nginx - nginx tidak tahu tabel apa yang ada di Clickhouse, dan saya mengganti nginx dengan proxy terbalik, yang juga saya tulis sendiri.
Apa yang dia lakukan? Ia bekerja berdasarkan perpustakaan fasthttp “goshnoy”, yaitu cepat, hampir secepat nginx. Maaf Igor jika Anda hadir di sini (catatan: Igor Sysoev adalah seorang programmer Rusia yang membuat server web nginx). Ia dapat memahami jenis kueri apa ini – INSERT atau SELECT – oleh karena itu, ia memiliki kumpulan koneksi yang berbeda untuk jenis kueri yang berbeda.
Oleh karena itu, meskipun kita tidak punya waktu untuk menyelesaikan permintaan penyisipan, “pilihan” akan lolos, dan sebaliknya. Dan itu mengelompokkan data ke dalam tabel buffer - dengan buffer kecil: jika ada kesalahan, kesalahan sintaksis, dan sebagainya - sehingga tidak terlalu mempengaruhi data lainnya, karena ketika kita cukup memasukkan ke dalam tabel buffer, kita memiliki " bachi" kecil, dan semua kesalahan sintaksis hanya memengaruhi bagian kecil ini; dan di sini mereka sudah mempengaruhi buffer yang besar. Kecil adalah 1 megabyte, artinya tidak terlalu kecil.
Memasukkan sinkronisasi dan pada dasarnya mengganti nginx, pada dasarnya melakukan hal yang sama seperti yang dilakukan nginx sebelumnya - Anda tidak perlu mengubah “Kittenhouse” lokal untuk ini. Dan karena menggunakan fasthttp, ini sangat cepat - Anda dapat membuat lebih dari 100 ribu permintaan per detik untuk penyisipan tunggal melalui proxy terbalik. Secara teoritis, Anda dapat memasukkan satu baris pada satu waktu ke dalam proxy terbalik rumah kucing, tetapi tentu saja kami tidak melakukan itu.
Skemanya mulai terlihat seperti ini: "Kittenhouse", proxy terbalik mengelompokkan banyak permintaan ke dalam tabel dan, pada gilirannya, tabel buffer memasukkannya ke dalam tabel utama.
Pembunuh adalah solusi sementara, Kitten bersifat permanen
Ini masalah yang menarik... Apakah ada di antara Anda yang menggunakan fasthttp? Siapa yang menggunakan fasthttp dengan permintaan POST? Mungkin, hal ini seharusnya tidak dilakukan, karena ini mem-buffer isi permintaan secara default, dan ukuran buffer kami disetel ke 16 megabita. Penyisipan berhenti berjalan di beberapa titik, dan potongan 16 megabyte mulai berdatangan dari puluhan ribu server, dan semuanya di-buffer dalam memori sebelum dikirim ke Clickhouse. Oleh karena itu, memori habis, Pembunuh Kehabisan Memori datang dan membunuh proxy terbalik (atau “Clickhouse”, yang secara teoritis dapat “memakan” lebih banyak daripada proxy terbalik). Siklus itu terulang kembali. Bukan masalah yang sangat menyenangkan. Meskipun kami menemukan ini hanya setelah beberapa bulan beroperasi.
Apa yang telah kulakukan? Sekali lagi, saya tidak begitu suka memahami apa yang sebenarnya terjadi. Saya pikir cukup jelas bahwa Anda tidak boleh melakukan buffering ke dalam memori. Saya tidak dapat menambal fasthttp, meskipun saya mencobanya. Tapi saya menemukan cara untuk membuatnya sehingga tidak perlu menambal apa pun, dan saya menemukan metode saya sendiri di HTTP - saya menyebutnya KITTEN. Yah, itu logis - "VK", "Anak Kucing"... Apa lagi?..
Jika permintaan datang ke server dengan metode Kitten, maka server harus merespons "meong" - secara logis. Jika dia merespons ini, maka dianggap dia memahami protokol ini, dan kemudian saya mencegat koneksi (fasthttp memiliki metode seperti itu), dan koneksi masuk ke mode "mentah". Mengapa saya membutuhkannya? Saya ingin mengontrol bagaimana pembacaan dari koneksi TCP terjadi. TCP memiliki properti yang luar biasa: jika tidak ada yang membaca dari sisi lain, maka penulisan mulai menunggu, dan memori tidak terlalu terkuras untuk ini.
Jadi saya membaca dari sekitar 50 klien sekaligus (dari lima puluh karena lima puluh pasti cukup, bahkan jika tarifnya berasal dari DC lain)... Konsumsi telah menurun dengan pendekatan ini setidaknya 20 kali lipat, tapi sejujurnya saya , saya tidak bisa mengukur jam berapa tepatnya, karena sudah percuma (sudah mencapai tingkat error). Protokolnya biner, yaitu berisi nama tabel dan data; tidak ada header http, jadi saya tidak menggunakan soket web (saya tidak perlu berkomunikasi dengan browser - saya membuat protokol yang sesuai dengan kebutuhan kita). Dan semuanya menjadi baik-baik saja dengannya.
Tabel penyangga menyedihkan
Baru-baru ini kami menemukan fitur menarik lainnya dari tabel buffer. Dan masalah ini sudah jauh lebih menyakitkan dibandingkan masalah lainnya. Bayangkan situasi ini: Anda sudah aktif menggunakan Clickhouse, Anda memiliki lusinan server Clickhouse, dan Anda memiliki beberapa permintaan yang memerlukan waktu sangat lama untuk dibaca (katakanlah, lebih dari 60 detik); dan Anda datang dan melakukan Alter saat ini... Sementara itu, "pilihan" yang dimulai sebelum "Alter" tidak akan disertakan dalam tabel ini, "Alter" tidak akan dimulai - mungkin beberapa fitur cara kerja "Clickhouse" di tempat ini. Mungkin ini bisa diperbaiki? Atau tidak mungkin?
Secara umum, jelas bahwa pada kenyataannya ini bukan masalah besar, tetapi dengan tabel buffer hal ini menjadi lebih menyakitkan. Karena, jika, katakanlah, batas waktu "Alter" Anda habis (dan mungkin waktu habis di host lain - bukan di host Anda, tetapi di replika, misalnya), maka... Anda menghapus tabel buffer, "Alter" Anda ( atau host lain) habis waktunya, kemudian terjadi kesalahan "Alter") - Anda masih perlu memastikan bahwa data terus ditulis: Anda membuat kembali tabel buffer (sesuai dengan skema yang sama seperti tabel induk), lalu "Alter" melewatinya, berakhir, dan buffer tabel mulai berbeda skemanya dari induknya. Tergantung pada apa "Alter" itu, penyisipan mungkin tidak lagi masuk ke tabel buffer ini - ini sangat menyedihkan.
Ada juga tanda seperti itu (mungkin ada yang menyadarinya) - ini disebut query_thread_log di versi baru Clickhouse. Secara default, di beberapa versi ada satu. Di sini kami telah mengumpulkan 840 juta catatan dalam beberapa bulan (100 gigabyte). Hal ini disebabkan oleh fakta bahwa "sisipan" tertulis di sana (mungkin sekarang, omong-omong, tidak ditulis). Seperti yang saya katakan, "sisipan" kami kecil - kami memiliki banyak "sisipan" ke dalam tabel buffer. Jelas bahwa ini dinonaktifkan - Saya hanya memberi tahu Anda apa yang saya lihat di server kami. Mengapa? Ini adalah argumen lain yang menentang penggunaan tabel buffer! Jerawatan sangat menyedihkan.
Siapa yang tahu kalau nama orang ini adalah Spotty? Karyawan VK mengangkat tangan. OKE.
Tentang rencana “KitttenHouse”
Rencana biasanya tidak dibagikan, bukan? Tiba-tiba Anda tidak akan memenuhinya dan tidak akan terlihat bagus di mata orang lain. Tapi aku akan mengambil risiko! Kami ingin melakukan hal berikut: tabel buffer, menurut saya, masih merupakan penopang dan kami perlu melakukan buffer penyisipan sendiri. Tapi kami tetap tidak ingin melakukan buffering di disk, jadi kami akan melakukan buffering penyisipan di memori.
Oleh karena itu, ketika "penyisipan" dibuat, itu tidak lagi sinkron - itu sudah berfungsi sebagai tabel buffer, akan dimasukkan ke dalam tabel induk (yah, suatu hari nanti) dan melaporkan melalui saluran terpisah penyisipan mana yang telah dilewati dan yang mana sudah tidak.
Mengapa saya tidak bisa keluar dari sisipan sinkron? Ini jauh lebih nyaman. Faktanya adalah jika Anda memasukkan dari 10 ribu host, maka semuanya baik-baik saja - Anda akan mendapatkan sedikit dari setiap host, Anda memasukkan di sana sekali dalam satu detik, semuanya baik-baik saja. Tapi saya ingin skema ini berfungsi, misalnya, dari dua mesin, sehingga Anda dapat mengunduh dengan kecepatan tinggi - mungkin tidak mendapatkan hasil maksimal dari Clickhouse, tetapi menulis setidaknya 100 megabyte per detik dari satu mesin melalui proxy terbalik - ini skemanya harus berskala besar dan kecil, jadi kita tidak bisa menunggu sedetik pun untuk setiap penyisipan, jadi skemanya harus asinkron. Dan dengan cara yang sama, konfirmasi asinkron akan muncul setelah penyisipan selesai. Kita akan tahu apakah lolos atau tidak.
Yang terpenting dalam skema ini kita tahu pasti apakah penyisipan itu terjadi atau tidak. Bayangkan situasi ini: Anda memiliki tabel buffer, Anda menulis sesuatu ke dalamnya, dan kemudian, katakanlah, tabel tersebut beralih ke mode hanya baca dan mencoba mengosongkan buffer. Ke mana datanya akan pergi? Mereka akan tetap berada di buffer. Namun kami tidak dapat memastikannya - bagaimana jika ada kesalahan lain yang menyebabkan data tidak tersisa di buffer... (Alamat Alexei Milovidov, Yandex, pengembang ClickHouse) Atau akankah tetap ada? Selalu? Alexei meyakinkan kita bahwa semuanya akan baik-baik saja. Kami tidak punya alasan untuk tidak mempercayainya. Tapi tetap saja: jika kita tidak menggunakan tabel buffer, maka tidak akan ada masalah dengan tabel tersebut. Membuat tabel dua kali lebih banyak juga merepotkan, meski pada prinsipnya tidak ada masalah besar. Ini rencananya.
Mari kita bicara tentang membaca
Sekarang mari kita bicara tentang membaca. Kami juga menulis alat kami sendiri di sini. Tampaknya, mengapa menulis instrumen Anda sendiri di sini?.. Dan siapa yang menggunakan Tabix? Entah kenapa hanya sedikit orang yang angkat tangan... Dan siapa yang puas dengan performa Tabix? Ya, kami tidak puas dengan hal itu, dan sangat tidak nyaman untuk melihat data. Baik untuk analisis, tetapi hanya untuk melihat saja jelas tidak dioptimalkan. Jadi saya menulis sendiri, antarmuka saya sendiri.
Ini sangat sederhana - hanya bisa membaca data. Dia tidak tahu cara menampilkan grafik, dia tidak tahu cara melakukan apa pun. Tapi itu bisa menunjukkan apa yang kita perlukan: misalnya, berapa banyak baris dalam tabel, berapa banyak ruang yang dibutuhkan (tanpa membaginya menjadi kolom), yaitu, antarmuka yang sangat mendasar adalah yang kita butuhkan.
Dan tampilannya sangat mirip dengan Sequel Pro, namun hanya dibuat di Bootstrap Twitter, dan versi kedua. Anda bertanya: “Yuri, kenapa di versi kedua?” Tahun berapa? 2018? Secara umum, saya melakukan ini cukup lama untuk “Muscle” (MySQL) dan baru saja mengubah beberapa baris dalam kueri di sana, dan itu mulai berfungsi untuk “Clickhouse”, dan terima kasih khusus! Karena parser sangat mirip dengan parser "otot", dan kuerinya sangat mirip - sangat nyaman, terutama pada awalnya.
Ya, itu bisa memfilter tabel, bisa memperlihatkan struktur dan isi tabel, memungkinkan Anda mengurutkan, memfilter berdasarkan kolom, memperlihatkan kueri yang menghasilkan hasil, baris yang terpengaruh (berapa banyak hasilnya), yaitu, hal-hal dasar untuk melihat data. Cukup cepat.
Ada juga editornya. Sejujurnya saya mencoba mencuri seluruh editor dari Tabix, tapi saya tidak bisa. Tapi entah bagaimana itu berhasil. Pada prinsipnya, itu saja.
"Clickhouse" cocok untuk sarang
Saya ingin memberi tahu Anda bahwa Clickhouse, terlepas dari semua masalah yang dijelaskan, sangat cocok untuk log. Yang terpenting, ini menyelesaikan masalah kita - ini sangat cepat dan memungkinkan Anda memfilter log berdasarkan kolom. Pada prinsipnya, tabel buffer tidak berfungsi dengan baik, tetapi biasanya tidak ada yang tahu alasannya... Mungkin sekarang Anda lebih tahu di mana Anda akan mengalami masalah.
TCP? Secara umum di VK biasanya menggunakan UDP. Dan ketika saya menggunakan TCP... Tentu saja, tidak ada yang memberitahu saya: “Yuri, apa yang kamu bicarakan! Anda tidak bisa, Anda memerlukan UDP.” Ternyata TCP tidak begitu menakutkan. Satu-satunya hal adalah, jika Anda memiliki puluhan ribu senyawa aktif yang Anda tulis, Anda perlu mempersiapkannya sedikit lebih hati-hati; tapi itu mungkin, dan cukup mudah.
Saya berjanji untuk memposting "Kittenhouse" dan "Lighthouse" di HighLoad Siberia jika semua orang berlangganan "VK backend" publik kami... Dan tahukah Anda, tidak semua orang berlangganan... Tentu saja, saya tidak akan meminta Anda berlangganan kami publik. Kalian masih terlalu banyak, bahkan mungkin ada yang tersinggung, tapi tetap saja, silakan berlangganan (dan di sini saya harus membuat matanya seperti mata kucing). Itu . Terima kasih banyak! Github adalah milik kita . Dengan Clickhouse rambut Anda akan lembut dan halus.
Terkemuka: - Teman, sekarang untuk pertanyaan. Tepat setelah itu kami serahkan sertifikat penghargaan dan laporan Anda di VHS.
Yuri Nasretdinov (selanjutnya disebut YN): – Bagaimana Anda bisa merekam laporan saya di VHS jika baru saja berakhir?
Terkemuka: – Anda juga tidak dapat sepenuhnya menentukan bagaimana “Clickhouse” akan bekerja atau tidak! Teman, 5 menit untuk bertanya!
pertanyaan
Pertanyaan dari penonton (selanjutnya disebut Q): - Selamat siang. Terima kasih banyak atas laporannya. Saya punya dua pertanyaan. Saya akan mulai dengan sesuatu yang remeh: apakah jumlah huruf t pada nama "Kittenhouse" pada diagram (3, 4, 7...) mempengaruhi kepuasan kucing?
YN: - Jumlah apa?
З: – Surat t. Ada tiga t, sekitar tiga t.
YN: - Bukankah aku sudah memperbaikinya? Ya, tentu saja! Ini adalah produk yang berbeda - selama ini saya hanya menipu Anda. Oke, saya bercanda - tidak masalah. Ah, di sini! Tidak, itu sama saja, saya salah ketik.
З: - Terima kasih. Pertanyaan kedua serius. Sejauh yang saya pahami, di Clickhouse, tabel buffer hanya ada di memori, tidak di-buffer ke disk, dan karenanya, tidak persisten.
YN: - Ya.
З: – Dan pada saat yang sama, klien Anda melakukan buffering ke disk, yang menyiratkan jaminan pengiriman log yang sama. Namun hal ini tidak dijamin di Clickhouse. Jelaskan bagaimana penjaminan itu dilakukan, karena apa?.. Berikut mekanismenya lebih detail
YN: – Ya, secara teoritis tidak ada kontradiksi di sini, karena ketika Clickhouse jatuh, Anda sebenarnya dapat mendeteksinya dengan jutaan cara berbeda. Jika Clickhouse mogok (jika berakhir salah), Anda dapat, secara kasar, memundurkan sedikit log yang Anda tulis dan memulai dari saat ketika semuanya baik-baik saja. Katakanlah Anda memundurkan satu menit, artinya Anda dianggap telah menghapus semuanya dalam satu menit.
З: – Artinya, “Kittenhouse” menahan jendela lebih lama dan, jika terjatuh, dapat mengenalinya dan memundurkannya?
YN: – Tapi ini secara teori. Dalam praktiknya, kami tidak melakukan ini, dan pengiriman yang andal berkisar dari nol hingga waktu tak terhingga. Tapi rata-rata satu. Kami puas bahwa jika Clickhouse crash karena suatu alasan atau server “reboot”, maka kami kehilangan sedikit. Dalam semua kasus lainnya, tidak akan terjadi apa-apa.
З: - Halo. Sejak awal, menurut saya Anda memang akan menggunakan UDP sejak awal laporan ini. Anda memiliki http, semua itu... Dan sebagian besar masalah yang Anda jelaskan, menurut pemahaman saya, disebabkan oleh solusi khusus ini...
YN: – Apa yang kita gunakan TCP?
З: - Pada dasarnya ya.
YN: - Tidak.
З: – Dengan fasthttp Anda mengalami masalah, dengan koneksi Anda mengalami masalah. Jika Anda baru saja menggunakan UDP, Anda akan menghemat waktu. Ya, akan ada masalah dengan pesan yang panjang atau yang lainnya...
YN: - Dengan apa?
З: – Dengan pesan yang panjang, karena mungkin tidak cocok dengan MTU, ada hal lain... Yah, mungkin ada masalahnya sendiri. Pertanyaannya adalah: mengapa tidak UDP?
YN: – Saya percaya bahwa penulis yang mengembangkan TCP/IP jauh lebih pintar dari saya dan lebih tahu dari saya bagaimana membuat serialisasi paket (sehingga bisa berjalan), pada saat yang sama menyesuaikan jendela pengiriman, tidak membebani jaringan, memberikan umpan balik tentang apa tidak dibaca, tidak dihitung di sisi lain... Semua masalah ini, menurut pendapat saya, akan ada di UDP, hanya saja saya harus menulis lebih banyak kode daripada yang sudah saya tulis untuk mengimplementasikan hal yang sama dan kemungkinan besar buruk. Saya bahkan tidak terlalu suka menulis dalam bahasa C, apalagi di sana...
З: - Nyaman saja! Terkirim oke dan jangan menunggu apa pun - ini sepenuhnya tidak sinkron. Pemberitahuan kembali bahwa semuanya baik-baik saja - itu berarti sudah tiba; Kalau tidak datang berarti buruk.
YN: – Saya membutuhkan keduanya – Saya harus bisa mengirim keduanya dengan jaminan pengantaran dan tanpa jaminan pengantaran. Ini adalah dua skenario yang berbeda. Saya tidak boleh kehilangan beberapa log atau tidak kehilangannya dengan alasan.
З: – Saya tidak akan membuang waktu. Hal ini perlu dibicarakan lebih lanjut. Terima kasih.
Terkemuka: – Siapa yang punya pertanyaan – angkat tangan!
З: - Halo, saya Sasha. Di suatu tempat di tengah-tengah laporan, muncul perasaan bahwa, selain TCP, dimungkinkan untuk menggunakan solusi yang sudah jadi - semacam Kafka.
YN: – Baiklah... Sudah kubilang aku tidak ingin menggunakan server perantara, karena... di Kafka, ternyata kita punya sepuluh ribu host; faktanya, kami memiliki lebih banyak lagi - puluhan ribu host. Ini juga bisa menyakitkan jika dilakukan dengan Kafka tanpa proxy apa pun. Selain itu, yang terpenting, ia tetap memberikan “latensi”, ia memberikan host tambahan yang perlu Anda miliki. Tapi saya tidak ingin memilikinya - saya ingin...
З: “Tetapi pada akhirnya ternyata seperti itu.”
YN: – Tidak, tidak ada tuan rumah! Ini semua berfungsi pada host Clickhouse.
З: - Nah, dan "Kittenhouse", yang merupakan kebalikannya - di mana dia tinggal?
YN: – Pada host Clickhouse, ia tidak menulis apa pun ke disk.
З: - Anggap saja.
Terkemuka: - Apakah kamu puas? Bisakah kami memberi Anda gaji?
З: - Ya kamu bisa. Faktanya, ada banyak kruk untuk mendapatkan hal yang sama, dan sekarang - jawaban sebelumnya tentang topik TCP, menurut pendapat saya, bertentangan dengan situasi ini. Rasanya segalanya bisa dilakukan dengan berlutut dalam waktu yang jauh lebih singkat.
YN: – Dan juga kenapa saya tidak mau menggunakan Kafka, karena di chat Clickhouse Telegram cukup banyak keluhan, misalnya pesan dari Kafka hilang. Bukan dari Kafka sendiri, tapi dalam integrasi Kafka dan Clickhaus; atau ada sesuatu yang tidak terhubung di sana. Secara kasar, maka klien untuk Kafka perlu ditulis. Saya rasa tidak ada solusi yang lebih sederhana atau lebih dapat diandalkan.
З: – Katakan padaku, kenapa kamu tidak mencoba antrian atau bus umum? Karena Anda mengatakan bahwa dengan asynchrony Anda dapat mengirim log itu sendiri melalui antrian dan menerima respons secara asinkron melalui antrian?
YN: – Mohon saran antrian apa yang bisa digunakan?
З: – Apa pun, bahkan tanpa jaminan bahwa semuanya baik-baik saja. Semacam Redis, RMQ...
YN: – Saya merasa Redis kemungkinan besar tidak akan mampu melakukan penyisipan sebanyak itu bahkan pada satu host (dalam artian beberapa server) yang mengeluarkan Clickhouse. Saya tidak dapat mendukung hal ini dengan bukti apa pun (saya belum membandingkannya), namun menurut saya Redis bukanlah solusi terbaik dalam hal ini. Pada prinsipnya, sistem ini dapat dianggap sebagai antrian pesan improvisasi, namun hanya disesuaikan untuk “Clickhouse”
Terkemuka: – Yuri, terima kasih banyak. Saya mengusulkan untuk mengakhiri pertanyaan dan jawaban di sini dan mengatakan kepada siapa di antara mereka yang mengajukan pertanyaan kami akan memberikan buku itu.
YN: – Saya ingin memberikan buku kepada orang pertama yang mengajukan pertanyaan.
Terkemuka: - Luar biasa! Besar! Sangat menyenangkan! Terima kasih banyak!
Beberapa iklan 🙂
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai $99! Membaca tentang
Sumber: www.habr.com