HighLoad++ Moscow 2018, Dewan Kongres. 9 November, 15:00
Abstrak dan pembentangan:
Yuri Nasretdinov (VKontakte): laporan itu akan bercakap tentang pengalaman melaksanakan ClickHouse di syarikat kami - mengapa kami memerlukannya, berapa banyak data yang kami simpan, cara kami menulisnya, dan sebagainya.
Bahan tambahan:
Yuri Nasretdinov: - Hai semua! Nama saya Yuri Nasretdinov, kerana saya telah diperkenalkan. Saya bekerja di VKontakte. Saya akan bercakap tentang cara kami memasukkan data ke dalam ClickHouse daripada armada pelayan kami (berpuluh-puluh ribu).
Apakah log dan mengapa mengumpulnya?
Apa yang kami akan beritahu anda: apa yang kami lakukan, mengapa kami memerlukan "ClickHouse", masing-masing, mengapa kami memilihnya, jenis prestasi yang boleh anda perolehi tanpa mengkonfigurasi apa-apa secara khusus. Saya akan memberitahu anda lebih lanjut tentang jadual penimbal, tentang masalah yang kami hadapi dengannya dan tentang penyelesaian kami yang kami bangunkan daripada sumber terbuka - KittenHouse dan Rumah Api.
Mengapa kita perlu melakukan apa-apa sahaja (semuanya sentiasa baik di VKontakte, bukan?). Kami ingin mengumpul log nyahpepijat (dan terdapat beratus-ratus terabait data di sana), mungkin entah bagaimana ia akan menjadi lebih mudah untuk mengira statistik; dan kami mempunyai kumpulan berpuluh ribu pelayan dari mana semua ini perlu dilakukan.
Mengapa kita membuat keputusan? Kami mungkin mempunyai penyelesaian untuk menyimpan log. Di sini - terdapat "Backend VK" awam. Saya sangat mengesyorkan melanggannya.
Apakah log? Ini ialah enjin yang mengembalikan tatasusunan kosong. Enjin dalam VK ialah apa yang orang lain panggil perkhidmatan mikro. Dan inilah pelekat tersenyum (sukaan yang agak banyak). Bagaimana pula? Nah, dengar lagi!
Apakah yang boleh digunakan untuk menyimpan log? Mustahil untuk tidak menyebut Hadup. Kemudian, sebagai contoh, Rsyslog (menyimpan log ini dalam fail). LSD. Siapa tahu apa itu LSD? Tidak, bukan LSD ini. Simpan fail juga. Nah, ClickHouse adalah pilihan yang pelik.
Clickhouse dan pesaing: keperluan dan peluang
Apa yang kita mahu? Kami ingin memastikan bahawa kami tidak perlu terlalu risau tentang operasi, supaya ia berfungsi di luar kotak, sebaik-baiknya dengan konfigurasi yang minimum. Kami mahu menulis banyak, dan menulis dengan cepat. Dan kami mahu menyimpannya untuk semua jenis bulan, tahun, iaitu, untuk masa yang lama. Kami mungkin ingin memahami beberapa masalah yang mereka sampaikan kepada kami dan berkata, "Sesuatu tidak berfungsi di sini," dan itu berlaku 3 bulan yang lalu), dan kami mahu melihat apa yang berlaku 3 bulan yang lalu " Pemampatan data - jelas mengapa ia boleh menjadi tambahan - kerana ia mengurangkan jumlah ruang yang diperlukan.
Dan kami mempunyai keperluan yang menarik: kami kadang-kadang menulis output beberapa arahan (contohnya, log), ia boleh menjadi lebih daripada 4 kilobait dengan mudah. Dan jika perkara ini berfungsi melalui UDP, maka ia tidak perlu berbelanja... ia tidak akan mempunyai sebarang "overhed" untuk sambungan, dan untuk sejumlah besar pelayan ini akan menjadi tambahan.
Mari lihat apa yang ditawarkan sumber terbuka kepada kami. Pertama, kami mempunyai Enjin Log - ini adalah enjin kami; Pada dasarnya, dia boleh melakukan segala-galanya, dia boleh menulis baris panjang. Nah, ia tidak memampatkan data secara telus - kita boleh memampatkan lajur besar sendiri jika kita mahu... kita, sudah tentu, tidak mahu (jika boleh). Satu-satunya masalah ialah dia hanya boleh memberikan apa yang sesuai dalam ingatannya; Untuk membaca selebihnya, anda perlu mendapatkan binlog enjin ini dan, oleh itu, ia mengambil masa yang agak lama.
Apakah pilihan lain yang ada? Contohnya, "Hadup". Kemudahan operasi... Siapa rasa Hadup mudah untuk disediakan? Sudah tentu, tiada masalah dengan rakaman. Apabila membaca, kadangkala timbul persoalan. Pada dasarnya, saya akan mengatakan mungkin tidak, terutamanya untuk log. Storan jangka panjang - sudah tentu, ya, pemampatan data - ya, rentetan panjang - jelas bahawa anda boleh merakam. Tetapi rakaman dari sejumlah besar pelayan... Anda masih perlu melakukan sesuatu sendiri!
Rsyslog. Sebenarnya, kami menggunakannya sebagai pilihan sandaran supaya kami boleh membacanya tanpa membuang binlog, tetapi ia tidak boleh menulis baris panjang; pada dasarnya, ia tidak boleh menulis lebih daripada 4 kilobait. Anda perlu melakukan pemampatan data dengan cara yang sama sendiri. Pembacaan akan datang daripada fail.
Kemudian terdapat pembangunan "badushka" LSD. Pada asasnya sama dengan "Rsyslog": ia menyokong rentetan panjang, tetapi ia tidak boleh berfungsi melalui UDP dan, sebenarnya, kerana ini, malangnya, banyak perkara perlu ditulis semula di sana. LSD perlu direka bentuk semula untuk dapat merakam daripada puluhan ribu pelayan.
Dan di sini! Pilihan yang lucu ialah ElasticSearch. Bagaimana untuk mengatakan? Dia pandai membaca, iaitu, dia membaca dengan cepat, tetapi tidak begitu baik dengan menulis. Pertama, jika ia memampatkan data, ia sangat lemah. Kemungkinan besar, carian penuh memerlukan struktur data yang lebih besar daripada volum asal. Ia sukar untuk dikendalikan dan masalah sering timbul dengannya. Dan, sekali lagi, rakaman dalam Elastik - kita perlu melakukan segala-galanya sendiri.
Di sini ClickHouse adalah pilihan yang ideal, sudah tentu. Satu-satunya perkara ialah rakaman dari puluhan ribu pelayan adalah masalah. Tetapi sekurang-kurangnya ada satu masalah, kita boleh cuba menyelesaikannya entah bagaimana. Dan laporan selebihnya adalah mengenai masalah ini. Apakah jenis prestasi yang boleh anda jangkakan daripada ClickHouse?
Bagaimana kita hendak memasukkannya? MergeTree
Siapa di antara anda yang belum pernah mendengar atau mengetahui tentang "ClickHouse"? Saya perlu memberitahu anda, bukan? Sangat laju. Sisipan di sana - 1-2 gigabit sesaat, letupan sehingga 10 gigabit sesaat sebenarnya boleh menahan konfigurasi ini - terdapat dua Xeon 6 teras (iaitu, bukan yang paling berkuasa), 256 gigabait RAM, 20 terabait dalam RAID (tiada siapa yang dikonfigurasikan, tetapan lalai). Alexey Milovidov, pembangun ClickHouse, mungkin duduk di sana sambil menangis kerana kami tidak mengkonfigurasi apa-apa (semuanya berfungsi seperti itu untuk kami). Sehubungan itu, kelajuan pengimbasan, katakan, kira-kira 6 bilion baris sesaat boleh diperoleh jika data dimampatkan dengan baik. Jika anda suka % pada rentetan teks - 100 juta baris sesaat, iaitu, ia kelihatan agak pantas.
Bagaimana kita hendak memasukkannya? Nah, anda tahu bahawa VK menggunakan PHP. Kami akan memasukkan daripada setiap pekerja PHP melalui HTTP ke dalam "ClickHouse", ke dalam jadual MergeTree untuk setiap rekod. Siapa nampak masalah dengan skim ini? Atas sebab tertentu, tidak semua orang mengangkat tangan mereka. Biar saya beritahu awak.
Pertama, terdapat banyak pelayan - oleh itu, akan ada banyak sambungan (buruk). Maka adalah lebih baik untuk memasukkan data ke dalam MergeTree tidak lebih kerap daripada sekali sesaat. Dan siapa tahu kenapa? Okay, okay. Saya akan memberitahu anda lebih sedikit tentang ini. Satu lagi soalan menarik ialah kami tidak melakukan analitik, kami tidak perlu memperkayakan data, kami tidak memerlukan pelayan perantaraan, kami mahu memasukkan terus ke dalam "ClickHouse" (sebaik-baiknya - lebih banyak secara langsung, lebih baik).
Sehubungan itu, bagaimanakah penyisipan dilakukan dalam MergeTree? Mengapa lebih baik untuk memasukkan ke dalamnya tidak lebih kerap daripada sekali sesaat atau kurang kerap? Hakikatnya ialah "ClickHouse" ialah pangkalan data kolumnar dan mengisih data dalam tertib menaik bagi kunci utama, dan apabila anda melakukan sisipan, beberapa fail dibuat sekurang-kurangnya sama dengan bilangan lajur di mana data diisih dalam tertib menaik kunci utama (direktori berasingan dicipta, satu set fail pada cakera untuk setiap sisipan). Kemudian sisipan seterusnya datang, dan di latar belakang mereka digabungkan menjadi "partition" yang lebih besar. Memandangkan data diisih, adalah mungkin untuk "menggabungkan" dua fail yang diisih tanpa menggunakan banyak memori.
Tetapi, seperti yang anda fikirkan, jika anda menulis 10 fail untuk setiap sisipan, maka ClickHouse (atau pelayan anda) akan tamat dengan cepat, jadi disyorkan untuk memasukkan dalam kelompok besar. Sehubungan itu, kami tidak pernah melancarkan skim pertama ke dalam pengeluaran. Kami segera melancarkan satu, yang di sini No. 2 mempunyai:
Di sini bayangkan bahawa terdapat kira-kira seribu pelayan yang telah kami lancarkan, hanya ada PHP. Dan pada setiap pelayan terdapat ejen tempatan kami, yang kami panggil "Kittenhouse", yang mengekalkan satu sambungan dengan "ClickHouse" dan memasukkan data setiap beberapa saat. Memasukkan data bukan ke dalam MergeTree, tetapi ke dalam jadual penimbal, yang berfungsi dengan tepat untuk mengelak daripada memasukkan terus ke dalam MergeTree dengan serta-merta.
Bekerja dengan jadual penimbal
Apa ini? Jadual penimbal ialah sekeping memori yang dipecahkan (iaitu, ia boleh dimasukkan ke dalamnya dengan kerap). Ia terdiri daripada beberapa keping, dan setiap kepingan berfungsi sebagai penimbal bebas, dan ia dibilas secara bebas (jika anda mempunyai banyak kepingan dalam penimbal, maka akan terdapat banyak sisipan sesaat). Ia adalah mungkin untuk membaca dari jadual ini - kemudian anda membaca kesatuan kandungan penimbal dan jadual induk, tetapi pada masa ini penulisan disekat, jadi lebih baik tidak membaca dari sana. Dan jadual penimbal menunjukkan QPS yang sangat baik, iaitu, sehingga 3 ribu QPS anda tidak akan menghadapi masalah sama sekali semasa memasukkan. Adalah jelas bahawa jika pelayan kehilangan kuasa, maka data boleh hilang, kerana ia hanya disimpan dalam ingatan.
Pada masa yang sama, skema dengan penimbal merumitkan ALTER, kerana anda perlu menggugurkan jadual penimbal lama dengan skema lama (data tidak akan hilang di mana-mana, kerana ia akan disiram sebelum jadual dipadamkan). Kemudian anda "mengubah" jadual yang anda perlukan dan mencipta jadual penimbal sekali lagi. Sehubungan itu, walaupun tiada jadual penimbal, data anda tidak akan mengalir ke mana-mana, tetapi anda boleh menyimpannya pada cakera sekurang-kurangnya secara tempatan.
Apakah Kittenhouse dan bagaimana ia berfungsi?
Apa itu KittenHouse? Ini adalah proksi. Cuba teka bahasa apa? Saya mengumpulkan paling banyak topik gembar-gembur dalam laporan saya - "Clickhouse", Pergi, mungkin saya akan ingat sesuatu yang lain. Ya, ini ditulis dalam Go, kerana saya tidak tahu cara menulis dalam C, saya tidak mahu.
Sehubungan itu, ia mengekalkan sambungan dengan setiap pelayan dan boleh menulis ke ingatan. Sebagai contoh, jika kita menulis log ralat ke Clickhouse, maka jika Clickhouse tidak mempunyai masa untuk memasukkan data (lagipun, jika terlalu banyak yang ditulis), maka kita tidak membengkak memori - kita hanya membuang yang lain. Kerana jika kita menulis beberapa gigabit sesaat ralat, maka kita mungkin boleh membuang beberapa ralat. Kittenhouse boleh melakukan ini. Selain itu, ia boleh melakukan penghantaran yang boleh dipercayai, iaitu, menulis ke cakera pada mesin tempatan dan sekali setiap kali (di sana, sekali setiap beberapa saat) ia cuba menghantar data daripada fail ini. Dan pada mulanya kami menggunakan format Nilai biasa - bukan beberapa format binari, format teks (seperti dalam SQL biasa).
Tetapi kemudian ini berlaku. Kami menggunakan penghantaran yang boleh dipercayai, menulis log, kemudian memutuskan (ia adalah kluster ujian bersyarat)... Ia diletakkan selama beberapa jam dan dibawa semula, dan sisipan bermula dari seribu pelayan - ternyata Clickhouse masih mempunyai "Benang pada sambungan" - sewajarnya, dalam seribu sambungan, sisipan aktif membawa kepada purata beban pada pelayan kira-kira satu setengah ribu. Yang menghairankan, pelayan menerima permintaan, tetapi data masih dimasukkan selepas beberapa lama; tetapi sangat sukar bagi pelayan untuk melayannya...
Tambah nginx
Penyelesaian sedemikian untuk model Thread per sambungan ialah nginx. Kami memasang nginx di hadapan Clickhouse, pada masa yang sama menyediakan pengimbangan untuk dua replika (kelajuan sisipan kami meningkat sebanyak 2 kali ganda, walaupun bukan fakta bahawa ini sepatutnya berlaku) dan mengehadkan bilangan sambungan ke Clickhouse, kepada huluan dan, sewajarnya, lebih , daripada dalam 50 sambungan, nampaknya tiada gunanya memasukkan.
Kemudian kami menyedari bahawa skim ini secara amnya mempunyai kelemahan, kerana kami hanya mempunyai satu nginx di sini. Oleh itu, jika nginx ini ranap, walaupun terdapat replika, kami kehilangan data atau, sekurang-kurangnya, tidak menulis di mana-mana. Itulah sebabnya kami membuat pengimbangan beban kami sendiri. Kami juga menyedari bahawa "Clickhouse" masih sesuai untuk log, dan "syaitan" juga mula menulis lognya dalam "Clickhouse" - sangat mudah, sejujurnya. Kami masih menggunakannya untuk "syaitan" lain.
Kemudian kami menemui masalah menarik ini: jika anda menggunakan kaedah memasukkan bukan standard dalam mod SQL, ia memaksa penghurai SQL berasaskan AST sepenuhnya, yang agak perlahan. Sehubungan itu, kami telah menambah tetapan untuk memastikan perkara ini tidak pernah berlaku. Kami melakukan pengimbangan beban, pemeriksaan kesihatan, supaya jika seseorang meninggal dunia, kami masih meninggalkan data. Kami kini mempunyai banyak jadual yang kami perlukan untuk mempunyai kluster Clickhouse yang berbeza. Dan kami juga mula memikirkan tentang kegunaan lain - contohnya, kami ingin menulis log daripada modul nginx, tetapi mereka tidak tahu cara berkomunikasi menggunakan RPC kami. Baiklah, saya ingin mengajar mereka cara menghantar sekurang-kurangnya entah bagaimana - contohnya, untuk menerima acara di localhost melalui UDP dan kemudian memajukannya ke Clickhouse.
Satu langkah lagi daripada penyelesaian
Skim terakhir mula kelihatan seperti ini (versi keempat skim ini): pada setiap pelayan di hadapan Clickhouse terdapat nginx (pada pelayan yang sama) dan ia hanya proksi permintaan kepada localhost dengan had bilangan sambungan 50 kepingan. Dan skim ini sudah cukup berkesan, semuanya cukup baik dengannya.
Kami hidup seperti ini selama lebih kurang sebulan. Semua orang gembira, mereka menambah jadual, mereka menambah, mereka menambah... Secara amnya, ternyata cara kami menambah jadual penimbal tidak begitu optimum (mari kita letak seperti itu). Kami membuat 16 keping dalam setiap jadual dan selang kilat beberapa saat; kami mempunyai 20 jadual dan setiap jadual menerima 8 sisipan sesaat - dan pada ketika ini "Clickhouse" bermula... rekod mula perlahan. Bukan sahaja mereka tidak lulus... Secara lalai, nginx mempunyai perkara yang menarik sehinggakan jika sambungan berakhir di hulu, maka ia hanya mengembalikan "502" kepada semua permintaan baharu.
Dan di sini kita ada (saya hanya melihat log di Clickhouse sendiri) kira-kira setengah peratus daripada permintaan gagal. Oleh itu, penggunaan cakera adalah tinggi, terdapat banyak gabungan. Nah, apa yang saya lakukan? Sememangnya, saya tidak peduli untuk memikirkan mengapa sebenarnya sambungan dan huluan berakhir.
Menggantikan nginx dengan proksi terbalik
Saya memutuskan bahawa kita perlu menguruskan ini sendiri, kita tidak perlu menyerahkannya kepada nginx - nginx tidak tahu jadual apa yang ada di Clickhouse, dan saya menggantikan nginx dengan proksi terbalik, yang juga saya tulis sendiri.
Apa yang dia buat? Ia berfungsi berdasarkan perpustakaan fasthttp “goshnoy”, iaitu, pantas, hampir sepantas nginx. Maaf, Igor, jika anda hadir di sini (nota: Igor Sysoev ialah pengaturcara Rusia yang mencipta pelayan web nginx). Ia boleh memahami jenis pertanyaan ini - INSERT atau SELECT - sewajarnya, ia memegang kumpulan sambungan yang berbeza untuk jenis pertanyaan yang berbeza.
Oleh itu, walaupun kita tidak mempunyai masa untuk melengkapkan permintaan sisipan, "pilihan" akan berlalu, dan sebaliknya. Dan ia mengelompokkan data ke dalam jadual penimbal - dengan penimbal kecil: jika terdapat sebarang ralat, ralat sintaks, dan sebagainya - supaya ia tidak akan menjejaskan data yang lain, kerana apabila kita hanya memasukkan ke dalam jadual penimbal, kita mempunyai "bachi" kecil, dan semua ralat sintaks hanya mempengaruhi bahagian kecil ini; dan di sini mereka sudah akan menjejaskan penimbal yang besar. Kecil ialah 1 megabait, iaitu, tidak begitu kecil.
Memasukkan penyegerakan dan pada dasarnya menggantikan nginx, pada asasnya melakukan perkara yang sama seperti yang dilakukan nginx sebelum ini - anda tidak perlu menukar "Kittenhouse" tempatan untuk ini. Dan kerana ia menggunakan fasthttp, ia sangat pantas - anda boleh membuat lebih daripada 100 ribu permintaan sesaat untuk sisipan tunggal melalui proksi terbalik. Secara teorinya, anda boleh memasukkan satu baris pada satu masa ke dalam proksi terbalik kittenhouse, tetapi sudah tentu kami tidak melakukannya.
Skim ini mula kelihatan seperti ini: "Kittenhouse", proksi terbalik mengumpulkan banyak permintaan ke dalam jadual dan, seterusnya, jadual penimbal memasukkannya ke dalam yang utama.
Pembunuh adalah penyelesaian sementara, Anak kucing kekal
Ini adalah masalah yang menarik... Adakah anda pernah menggunakan fasthttp? Siapa yang menggunakan fasthttp dengan permintaan POST? Mungkin, ini tidak sepatutnya dilakukan, kerana ia menimbal badan permintaan secara lalai, dan saiz penimbal kami ditetapkan kepada 16 megabait. Sisipan itu berhenti mengikuti pada satu ketika, dan ketulan 16 megabait mula tiba dari semua puluhan ribu pelayan, dan semuanya ditimbal dalam ingatan sebelum dihantar ke Clickhouse. Oleh itu, ingatan kehabisan, Pembunuh Out-Of-Memory datang dan membunuh proksi terbalik (atau "Clickhouse", yang secara teorinya boleh "makan" lebih banyak daripada proksi terbalik). Kitaran itu berulang. Bukan masalah yang sangat menyenangkan. Walaupun kami terjumpa perkara ini hanya selepas beberapa bulan beroperasi.
Apa yang telah saya lakukan? Sekali lagi, saya tidak begitu suka memahami apa sebenarnya yang berlaku. Saya fikir ia agak jelas bahawa anda tidak sepatutnya menimbal ke dalam ingatan. Saya tidak dapat menampal fasthttp, walaupun saya mencuba. Tetapi saya menemui cara untuk membuatnya supaya tidak perlu menampal apa-apa, dan saya menghasilkan kaedah saya sendiri dalam HTTP - saya memanggilnya KITTEN. Nah, logik - "VK", "Anak Kucing"... Apa lagi?..
Jika permintaan datang ke pelayan dengan kaedah Kitten, maka pelayan harus bertindak balas "meow" - secara logik. Jika dia bertindak balas kepada ini, maka ia dianggap bahawa dia memahami protokol ini, dan kemudian saya memintas sambungan (fasthttp mempunyai kaedah sedemikian), dan sambungan masuk ke mod "mentah". Mengapa saya memerlukannya? Saya mahu mengawal cara membaca daripada sambungan TCP berlaku. TCP mempunyai harta yang indah: jika tiada siapa yang membaca dari sisi lain, maka penulisan mula menunggu, dan memori tidak dibelanjakan untuk ini.
Jadi saya membaca daripada kira-kira 50 pelanggan pada satu masa (dari lima puluh kerana lima puluh sudah pasti cukup, walaupun kadar itu datang dari DC yang lain)... Penggunaan telah menurun dengan pendekatan ini sekurang-kurangnya 20 kali, tetapi saya, sejujurnya , saya tidak dapat mengukur dengan tepat pukul berapa, kerana ia sudah tidak berguna (ia sudah mencapai tahap ralat). Protokol adalah binari, iaitu, ia mengandungi nama jadual dan data; tiada pengepala http, jadi saya tidak menggunakan soket web (saya tidak perlu berkomunikasi dengan penyemak imbas - saya membuat protokol yang sesuai dengan keperluan kita). Dan semuanya menjadi baik dengan dia.
Meja penampan adalah sedih
Baru-baru ini kami menemui satu lagi ciri menarik bagi jadual penimbal. Dan masalah ini sudah jauh lebih menyakitkan daripada yang lain. Mari bayangkan keadaan ini: anda sudah aktif menggunakan Clickhouse, anda mempunyai berpuluh-puluh pelayan Clickhouse, dan anda mempunyai beberapa permintaan yang mengambil masa yang sangat lama untuk dibaca (katakan, lebih daripada 60 saat); dan anda datang dan lakukan Ubah pada masa ini... Sementara itu, "pilihan" yang bermula sebelum "Ubah" tidak akan disertakan dalam jadual ini, "Ubah" tidak akan bermula - mungkin beberapa ciri cara "Clickhouse" berfungsi dalam tempat ini. Mungkin ini boleh diperbaiki? Atau adakah ia tidak mungkin?
Secara umum, jelas bahawa pada hakikatnya ini bukan masalah besar, tetapi dengan jadual penampan ia menjadi lebih menyakitkan. Kerana, jika, katakan, tamat masa "Ubah" anda (dan ia mungkin tamat masa pada hos lain - bukan pada hos anda, tetapi pada replika, sebagai contoh), maka... Anda memadamkan jadual penimbal, "Ubah" anda ( atau beberapa hos lain) tamat masa. maka ralat "Ubah" telah berlaku) - anda masih perlu memastikan bahawa data terus ditulis: anda membuat jadual penimbal kembali (mengikut skema yang sama seperti jadual induk), kemudian "Ubah" berlalu, berakhir selepas semua, dan penimbal jadual mula berbeza dalam skema daripada induk. Bergantung pada jenis "Ubah", sisipan mungkin tidak lagi pergi ke jadual penimbal ini - ini sangat menyedihkan.
Terdapat juga tanda sedemikian (mungkin seseorang menyedarinya) - ia dipanggil query_thread_log dalam versi baharu Clickhouse. Secara lalai, dalam sesetengah versi terdapat satu. Di sini kami telah mengumpul 840 juta rekod dalam beberapa bulan (100 gigabait). Ini disebabkan oleh fakta bahawa "sisipan" ditulis di sana (mungkin sekarang, dengan cara itu, mereka tidak ditulis). Seperti yang saya beritahu anda, "sisipan" kami adalah kecil - kami mempunyai banyak "sisipan" ke dalam jadual penimbal. Sudah jelas bahawa ini dilumpuhkan - saya hanya memberitahu anda apa yang saya lihat pada pelayan kami. kenapa? Ini adalah satu lagi hujah menentang penggunaan jadual penimbal! Spotty sangat sedih.
Siapa tahu nama lelaki ini adalah Spotty? Pekerja VK mengangkat tangan. OKEY.
Mengenai rancangan untuk "KitttenHouse"
Rancangan biasanya tidak dikongsi, bukan? Tiba-tiba anda tidak akan memenuhinya dan tidak akan kelihatan sangat baik di mata orang lain. Tetapi saya akan mengambil risiko! Kami mahu melakukan perkara berikut: jadual penimbal, nampaknya saya, masih menjadi tongkat dan kami perlu menampan sisipan itu sendiri. Tetapi kami masih tidak mahu menimbalnya pada cakera, jadi kami akan menimbal sisipan dalam ingatan.
Oleh itu, apabila "sisipan" dibuat, ia tidak akan segerak lagi - ia akan berfungsi sebagai jadual penimbal, akan memasukkan ke dalam jadual induk (baik, suatu hari nanti) dan melaporkan melalui saluran berasingan yang sisipan telah berlalu dan yang belum.
Mengapa saya tidak boleh meninggalkan sisipan segerak? Ia lebih mudah. Hakikatnya ialah jika anda memasukkan dari 10 ribu hos, maka semuanya baik-baik saja - anda akan mendapat sedikit daripada setiap hos, anda memasukkan di sana sekali sesaat, semuanya baik-baik saja. Tetapi saya ingin skim ini berfungsi, sebagai contoh, dari dua mesin, supaya anda boleh memuat turun pada kelajuan tinggi - mungkin tidak mendapat maksimum daripada Clickhouse, tetapi tulis sekurang-kurangnya 100 megabait sesaat dari satu mesin melalui proksi terbalik - ini skema mesti skala kepada kedua-dua kuantiti yang besar dan kecil, jadi kita tidak boleh menunggu satu saat untuk setiap sisipan, jadi ia mestilah tak segerak. Dan dengan cara yang sama, pengesahan tak segerak harus datang selepas pemasukan telah selesai. Kita akan tahu sama ada ia lulus atau tidak.
Perkara yang paling penting ialah dalam skim ini kita tahu dengan pasti sama ada penyisipan berlaku atau tidak. Bayangkan situasi ini: anda mempunyai jadual penimbal, anda menulis sesuatu ke dalamnya, dan kemudian, katakan, jadual itu masuk ke mod baca sahaja dan cuba mengepam penimbal. Ke mana data akan pergi? Mereka akan kekal dalam penampan. Tetapi kami tidak dapat memastikan ini - bagaimana jika terdapat beberapa ralat lain, yang menyebabkan data tidak akan kekal dalam penimbal... (Alamat Alexey Milovidov, Yandex, pemaju ClickHouse) Atau adakah ia akan kekal? Sentiasa? Alexey meyakinkan kami bahawa semuanya akan baik-baik saja. Kami tidak mempunyai alasan untuk tidak mempercayainya. Tetapi semuanya sama: jika kita tidak menggunakan jadual penimbal, maka tidak akan ada masalah dengannya. Mencipta dua kali lebih banyak jadual juga menyusahkan, walaupun pada dasarnya tidak ada masalah besar. Inilah rancangannya.
Mari kita bercakap tentang membaca
Sekarang mari kita bercakap tentang membaca. Kami juga menulis alat kami sendiri di sini. Nampaknya, mengapa menulis instrumen anda sendiri di sini?.. Dan siapa yang menggunakan Tabix? Entah kenapa sedikit orang yang mengangkat tangan... Dan siapa yang berpuas hati dengan persembahan Tabix? Nah, kami tidak berpuas hati dengannya, dan ia tidak begitu mudah untuk melihat data. Ia baik untuk analitis, tetapi hanya untuk melihatnya jelas tidak dioptimumkan. Jadi saya menulis sendiri, antara muka saya sendiri.
Ia sangat mudah - ia hanya boleh membaca data. Dia tidak tahu bagaimana untuk menunjukkan grafik, dia tidak tahu bagaimana untuk melakukan apa-apa. Tetapi ia boleh menunjukkan apa yang kita perlukan: sebagai contoh, berapa banyak baris dalam jadual, berapa banyak ruang yang diperlukan (tanpa memecahkannya menjadi lajur), iaitu antara muka yang sangat asas adalah apa yang kita perlukan.
Dan ia kelihatan sangat serupa dengan Sequel Pro, tetapi hanya dibuat pada Bootstrap Twitter, dan versi kedua. Anda bertanya: "Yuri, mengapa pada versi kedua?" Tahun apa? 2018? Secara umum, saya melakukan ini agak lama dahulu untuk "Muscle" (MySQL) dan hanya menukar beberapa baris dalam pertanyaan di sana, dan ia mula berfungsi untuk "Clickhouse", yang mana terima kasih istimewa! Kerana penghurai sangat serupa dengan "otot", dan pertanyaannya sangat serupa - sangat mudah, terutamanya pada mulanya.
Nah, ia boleh menapis jadual, boleh menunjukkan struktur dan kandungan jadual, membolehkan anda mengisih, menapis mengikut lajur, menunjukkan pertanyaan yang menghasilkan keputusan, baris yang terjejas (berapa banyak hasilnya), iaitu, perkara asas untuk melihat data. Agak pantas.
Terdapat juga editor. Saya secara jujur cuba mencuri keseluruhan editor dari Tabix, tetapi saya tidak dapat. Tetapi entah bagaimana ia berfungsi. Pada dasarnya, itu sahaja.
"Clickhouse" sesuai untuk sarang
Saya ingin memberitahu anda bahawa Clickhouse, walaupun semua masalah yang diterangkan, sangat sesuai untuk log. Paling penting, ia menyelesaikan masalah kami - ia sangat pantas dan membolehkan anda menapis log mengikut lajur. Pada dasarnya, jadual penimbal tidak berfungsi dengan baik, tetapi biasanya tiada siapa yang tahu mengapa... Mungkin sekarang anda lebih tahu di mana anda akan menghadapi masalah.
TCP? Secara umum, dalam VK adalah kebiasaan untuk menggunakan UDP. Dan apabila saya menggunakan TCP... Sudah tentu, tiada siapa yang memberitahu saya: “Yuri, apa yang awak cakapkan! Anda tidak boleh, anda memerlukan UDP." Ternyata TCP tidak begitu menakutkan. Satu-satunya perkara ialah, jika anda mempunyai puluhan ribu sebatian aktif yang anda tulis, anda perlu menyediakannya dengan lebih berhati-hati; tetapi ia mungkin, dan agak mudah.
Saya berjanji untuk menyiarkan “Kittenhouse” dan “Lighthouse” di HighLoad Siberia jika semua orang melanggan “VK backend” awam kami... Dan anda tahu, bukan semua orang melanggan... Sudah tentu, saya tidak akan menuntut anda melanggan kami awam. Masih terlalu ramai di antara anda, mungkin ada yang tersinggung, tetapi sila langgan (dan di sini saya perlu menjadikan mata seperti kucing). Itu . Terima kasih banyak - banyak! Github adalah milik kita . Dengan Clickhouse rambut anda akan menjadi lembut dan selembut sutera.
Mengetuai: - Kawan, sekarang untuk soalan. Sejurus selepas kami menyampaikan sijil penghargaan dan laporan anda tentang VHS.
Yuri Nasretdinov (selepas ini dirujuk sebagai YN): – Bagaimanakah anda boleh merekodkan laporan saya pada VHS jika ia baru sahaja tamat?
Mengetuai: – Anda juga tidak boleh menentukan sepenuhnya cara "Clickhouse" akan berfungsi atau tidak! Kawan, 5 minit untuk soalan!
soalan
Soalan daripada hadirin (selepas ini dirujuk sebagai Q): - Selamat petang. Terima kasih banyak atas laporan itu. Saya ada dua soalan. Saya akan mulakan dengan sesuatu yang remeh: adakah bilangan huruf t dalam nama "Kittenhouse" dalam rajah (3, 4, 7...) mempengaruhi kepuasan kucing?
YN: - Kuantiti apa?
Z: – Huruf t. Terdapat tiga t, di suatu tempat sekitar tiga t.
YN: - Adakah saya tidak membetulkannya? Sudah tentu! Ini adalah produk yang berbeza - saya hanya menipu anda selama ini. Okay, saya bergurau - tidak mengapa. Ah, di sini! Tidak, ia adalah perkara yang sama, saya membuat kesilapan menaip.
Z: - Terima kasih. Soalan kedua serius. Setakat yang saya faham, dalam Clickhouse, jadual penimbal hidup secara eksklusif dalam ingatan, tidak ditimbal ke cakera dan, oleh itu, tidak berterusan.
YN: - Ya.
Z: – Dan pada masa yang sama, pelanggan anda menampan ke cakera, yang membayangkan beberapa jaminan penghantaran log yang sama ini. Tetapi ini sama sekali tidak dijamin di Clickhouse. Terangkan bagaimana jaminan itu dijalankan, disebabkan apa?.. Berikut adalah mekanisme ini dengan lebih terperinci
YN: – Ya, secara teorinya tiada percanggahan di sini, kerana apabila Clickhouse jatuh, anda sebenarnya boleh mengesannya dalam sejuta cara yang berbeza. Jika Clickhouse ranap (jika ia berakhir dengan salah), anda boleh, secara kasarnya, memundurkan sedikit log anda yang anda tulis dan mulakan dari saat semuanya baik-baik saja. Katakan anda undur seminit, iaitu dianggap anda telah mengepam semuanya dalam satu minit.
Z: – Iaitu, “Kittenhouse” memegang tingkap lebih lama dan, sekiranya terjatuh, boleh mengenalinya dan memundurkannya?
YN: – Tetapi ini dalam teori. Dalam amalan, kami tidak melakukan ini, dan penghantaran yang boleh dipercayai adalah dari masa sifar hingga infiniti. Tetapi secara purata satu. Kami berpuas hati bahawa jika Clickhouse ranap atas sebab tertentu atau pelayan "reboot," maka kami kehilangan sedikit. Dalam semua kes lain, tiada apa yang akan berlaku.
Z: - Hello. Dari awal lagi nampaknya saya anda memang akan menggunakan UDP dari awal laporan. Anda mempunyai http, semua itu... Dan kebanyakan masalah yang anda terangkan, seperti yang saya faham, disebabkan oleh penyelesaian khusus ini...
YN: – Apakah yang kita gunakan TCP?
Z: - Pada asasnya ya.
YN: - Tidak.
Z: – Dengan fasthttp anda menghadapi masalah, dengan sambungan anda menghadapi masalah. Jika anda baru sahaja menggunakan UDP, anda akan menjimatkan masa anda. Nah, akan ada masalah dengan mesej panjang atau sesuatu yang lain...
YN: - Dengan apa?
Z: – Dengan mesej yang panjang, kerana ia mungkin tidak sesuai dengan MTU, sesuatu yang lain... Nah, mungkin ada masalah mereka sendiri. Persoalannya ialah: mengapa tidak UDP?
YN: – Saya percaya bahawa pengarang yang membangunkan TCP/IP jauh lebih bijak daripada saya dan lebih tahu daripada saya cara mensirikan paket (supaya ia pergi), pada masa yang sama melaraskan tetingkap penghantaran, tidak membebankan rangkaian, memberi maklum balas tentang apa tidak dibaca, tidak dikira di sisi lain... Semua masalah ini, pada pendapat saya, akan wujud dalam UDP, cuma saya perlu menulis lebih banyak kod daripada yang telah saya tulis untuk melaksanakan perkara yang sama sendiri dan kemungkinan besar teruk. Saya tidak begitu suka menulis dalam C, apatah lagi di sana...
Z: - Mudah sahaja! Dihantar ok dan jangan tunggu apa-apa - ia tidak segerak sepenuhnya. Pemberitahuan kembali bahawa semuanya baik-baik saja - ini bermakna ia telah tiba; Jika ia tidak datang, ia bermakna ia buruk.
YN: – Saya memerlukan kedua-duanya – Saya perlu boleh menghantar kedua-duanya dengan jaminan penghantaran dan tanpa jaminan penghantaran. Ini adalah dua senario yang berbeza. Saya tidak perlu kehilangan beberapa log atau tidak kehilangannya dalam alasan.
Z: - Saya tidak akan membuang masa. Ini perlu dibincangkan lebih lanjut. Terima kasih.
Mengetuai: – Siapa ada soalan – tangan ke langit!
Z: - Hello, saya Sasha. Di suatu tempat di tengah-tengah laporan, perasaan muncul bahawa, sebagai tambahan kepada TCP, adalah mungkin untuk menggunakan penyelesaian siap pakai - sejenis Kafka.
YN: – Baiklah... Saya memberitahu anda bahawa saya tidak mahu menggunakan pelayan perantaraan, kerana... di Kafka, ternyata kita mempunyai sepuluh ribu hos; sebenarnya, kami mempunyai lebih - puluhan ribu hos. Ia juga boleh menyakitkan untuk dilakukan dengan Kafka tanpa sebarang proksi. Di samping itu, yang paling penting, ia masih memberikan "kependaman", ia memberikan hos tambahan yang perlu anda miliki. Tetapi saya tidak mahu memilikinya - saya mahu...
Z: "Tetapi akhirnya ia ternyata begitu juga."
YN: – Tidak, tiada hos! Ini semua berfungsi pada hos Clickhouse.
Z: - Nah, dan "Kittenhouse", yang sebaliknya - di mana dia tinggal?
YN: – Pada hos Clickhouse, ia tidak menulis apa-apa pada cakera.
Z: - Mari kita andaikan.
Mengetuai: – Adakah anda berpuas hati? Bolehkah kami memberi anda gaji?
Z: - Ya awak boleh. Malah, terdapat banyak tongkat untuk mendapatkan perkara yang sama, dan sekarang - jawapan sebelumnya mengenai topik TCP bercanggah, pada pendapat saya, keadaan ini. Rasanya segala-galanya boleh dilakukan di atas lutut saya dalam masa yang lebih singkat.
YN: – Dan juga mengapa saya tidak mahu menggunakan Kafka, kerana terdapat banyak aduan dalam sembang Telegram Clickhouse yang, sebagai contoh, mesej daripada Kafka telah hilang. Bukan dari Kafka sendiri, tetapi dalam integrasi Kafka dan Clickhaus; atau sesuatu yang tidak bersambung di sana. Secara kasarnya, adalah perlu untuk menulis pelanggan untuk Kafka. Saya tidak fikir mungkin ada penyelesaian yang lebih mudah atau lebih dipercayai.
Z: – Beritahu saya, mengapa anda tidak mencuba sebarang baris gilir atau sejenis bas biasa? Memandangkan anda mengatakan bahawa dengan asynchrony anda boleh menghantar log itu sendiri melalui baris gilir dan menerima respons secara tidak segerak melalui baris gilir?
YN: – Sila cadangkan baris gilir yang boleh digunakan?
Z: – Mana-mana, walaupun tanpa jaminan bahawa ia adalah teratur. Sejenis Redis, RMQ...
YN: – Saya mempunyai perasaan bahawa Redis berkemungkinan besar tidak akan dapat menarik jumlah sisipan sedemikian walaupun pada satu hos (dalam erti kata beberapa pelayan) yang menarik keluar Clickhouse. Saya tidak boleh menyokongnya dengan sebarang bukti (saya tidak menanda arasnya), tetapi nampaknya saya Redis bukanlah penyelesaian terbaik di sini. Pada dasarnya, sistem ini boleh dianggap sebagai baris gilir mesej yang diubah suai, tetapi yang disesuaikan hanya untuk "Clickhouse"
Mengetuai: – Yuri, terima kasih banyak-banyak. Saya bercadang untuk menamatkan soalan dan jawapan di sini dan menyatakan kepada siapa di antara mereka yang bertanya soalan itu akan kami berikan buku itu.
YN: – Saya ingin memberikan buku kepada orang pertama yang bertanya soalan.
Mengetuai: - Hebat! Hebat! Hebat! Terima kasih banyak-banyak!
Beberapa iklan 🙂
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali 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 - daripada $99! Baca tentang
Sumber: www.habr.com