Pergi pengoptimuman dalam VictoriaMetrics. Alexander Valyalkin

Saya cadangkan anda membaca transkrip laporan akhir 2019 oleh Alexander Valyalkin "Go optimizations in VictoriaMetrics"

VictoriaMetrics — DBMS yang pantas dan berskala untuk menyimpan dan memproses data dalam bentuk siri masa (rekod membentuk masa dan satu set nilai yang sepadan dengan masa ini, contohnya, diperoleh melalui tinjauan berkala status sensor atau pengumpulan metrik).

Berikut adalah pautan kepada video laporan ini - https://youtu.be/MZ5P21j_HLE

Slaid

Beritahu kami tentang diri anda. Saya Alexander Valyalkin. Di sini akaun GitHub saya. Saya berminat dengan Go dan pengoptimuman prestasi. Saya menulis banyak perpustakaan yang berguna dan tidak begitu berguna. Mereka bermula dengan sama ada fast, atau dengan quick awalan.

Saya sedang mengusahakan VictoriaMetrics. Apa itu dan apa yang saya lakukan di sana? Saya akan membincangkan perkara ini dalam pembentangan ini.

Rangka laporan adalah seperti berikut:

• Pertama, saya akan memberitahu anda apa itu VictoriaMetrics.
• Kemudian saya akan memberitahu anda apakah siri masa itu.
• Kemudian saya akan memberitahu anda cara pangkalan data siri masa berfungsi.
• Seterusnya, saya akan memberitahu anda tentang seni bina pangkalan data: kandungannya.
• Dan kemudian mari kita beralih kepada pengoptimuman yang dimiliki oleh VictoriaMetrics. Ini ialah pengoptimuman untuk indeks terbalik dan pengoptimuman untuk pelaksanaan bitset dalam Go.

Adakah sesiapa di kalangan penonton tahu apa itu VictoriaMetrics? Wah, ramai yang dah tahu. Ia satu berita baik. Bagi mereka yang tidak tahu, ini adalah pangkalan data siri masa. Ia berdasarkan seni bina ClickHouse, pada beberapa butiran pelaksanaan ClickHouse. Contohnya, pada seperti: MergeTree, pengiraan selari pada semua teras pemproses yang tersedia dan pengoptimuman prestasi dengan bekerja pada blok data yang diletakkan dalam cache pemproses.

VictoriaMetrics menyediakan pemampatan data yang lebih baik daripada pangkalan data siri masa yang lain.

Ia berskala menegak - iaitu, anda boleh menambah lebih banyak pemproses, lebih banyak RAM pada satu komputer. VictoriaMetrics akan berjaya menggunakan sumber yang tersedia ini dan akan meningkatkan produktiviti linear.

VictoriaMetrics juga menskala secara mendatar - iaitu, anda boleh menambah nod tambahan pada gugusan VictoriaMetrics dan prestasinya akan meningkat hampir secara linear.

Seperti yang anda sangka, VictoriaMetrics ialah pangkalan data yang pantas, kerana saya tidak boleh menulis orang lain. Dan ia ditulis dalam Go, jadi saya bercakap mengenainya pada pertemuan ini.

Siapa tahu apa itu siri masa? Dia juga mengenali ramai orang. Siri masa ialah siri pasangan (timestamp, значение), di mana pasangan ini diisih mengikut masa. Nilainya ialah nombor titik terapung – float64.

Setiap siri masa dikenal pasti secara unik oleh kunci. Apakah kunci ini terdiri daripada? Ia terdiri daripada set pasangan nilai kunci yang tidak kosong.

Berikut adalah contoh siri masa. Kunci siri ini ialah senarai pasangan: __name__="cpu_usage" ialah nama metrik, instance="my-server" - ini ialah komputer yang metrik ini dikumpulkan, datacenter="us-east" - ini ialah pusat data di mana komputer ini berada.

Kami berakhir dengan nama siri masa yang terdiri daripada tiga pasangan nilai kunci. Kunci ini sepadan dengan senarai pasangan (timestamp, value). t1, t3, t3, ..., tN - ini adalah cap masa, 10, 20, 12, ..., 15 - nilai yang sepadan. Ini ialah penggunaan cpu pada masa tertentu untuk siri tertentu.

Di manakah siri masa boleh digunakan? Adakah sesiapa mempunyai sebarang idea?

• Dalam DevOps, anda boleh mengukur CPU, RAM, rangkaian, rps, bilangan ralat, dsb.
• IoT - kita boleh mengukur suhu, tekanan, koordinat geo dan sesuatu yang lain.
• Juga kewangan – kita boleh memantau harga untuk semua jenis saham dan mata wang.
• Selain itu, siri masa boleh digunakan dalam memantau proses pengeluaran di kilang. Kami mempunyai pengguna yang menggunakan VictoriaMetrics untuk memantau turbin angin, untuk robot.
• Siri masa juga berguna untuk mengumpul maklumat daripada penderia pelbagai peranti. Sebagai contoh, untuk enjin; untuk mengukur tekanan tayar; untuk mengukur kelajuan, jarak; untuk mengukur penggunaan petrol, dsb.
• Siri masa juga boleh digunakan untuk memantau pesawat. Setiap pesawat mempunyai kotak hitam yang mengumpul siri masa untuk pelbagai parameter kesihatan pesawat. Siri masa juga digunakan dalam industri aeroangkasa.
• Penjagaan kesihatan ialah tekanan darah, nadi, dsb.

Mungkin terdapat lebih banyak aplikasi yang saya terlupa, tetapi saya harap anda faham bahawa siri masa digunakan secara aktif dalam dunia moden. Dan jumlah penggunaannya semakin meningkat setiap tahun.

Mengapa anda memerlukan pangkalan data siri masa? Mengapa anda tidak boleh menggunakan pangkalan data hubungan biasa untuk menyimpan siri masa?

Kerana siri masa biasanya mengandungi sejumlah besar maklumat, yang sukar untuk disimpan dan diproses dalam pangkalan data konvensional. Oleh itu, pangkalan data khusus untuk siri masa muncul. Pangkalan ini menyimpan mata dengan berkesan (timestamp, value) dengan kunci yang diberikan. Mereka menyediakan API untuk membaca data yang disimpan mengikut kunci, dengan pasangan nilai kunci tunggal, atau oleh berbilang pasangan nilai kunci, atau oleh regexp. Sebagai contoh, anda ingin mencari beban CPU semua perkhidmatan anda di pusat data di Amerika, maka anda perlu menggunakan pertanyaan pseudo ini.

Biasanya pangkalan data siri masa menyediakan bahasa pertanyaan khusus kerana SQL siri masa tidak begitu sesuai. Walaupun terdapat pangkalan data yang menyokong SQL, ia tidak begitu sesuai. Bahasa pertanyaan seperti PromQL, InfluxQL, Fluks, Q. Saya berharap seseorang telah mendengar sekurang-kurangnya satu daripada bahasa ini. Ramai orang mungkin pernah mendengar tentang PromQL. Ini ialah bahasa pertanyaan Prometheus.

Inilah rupa seni bina pangkalan data siri masa moden menggunakan VictoriaMetrics sebagai contoh.

Ia terdiri daripada dua bahagian. Ini ialah storan untuk indeks terbalik dan storan untuk nilai siri masa. Repositori ini diasingkan.

Apabila rekod baharu tiba dalam pangkalan data, kami mula-mula mengakses indeks terbalik untuk mencari pengecam siri masa bagi set tertentu label=value untuk metrik tertentu. Kami mencari pengecam ini dan menyimpan nilai dalam stor data.

Apabila permintaan datang untuk mendapatkan semula data daripada TSDB, kami mula-mula pergi ke indeks terbalik. Jom dapatkan semuanya timeseries_ids rekod yang sepadan dengan set ini label=value. Dan kemudian kami mendapat semua data yang diperlukan dari gudang data, diindeks oleh timeseries_ids.

Mari lihat contoh bagaimana pangkalan data siri masa memproses pertanyaan pilihan masuk.

• Pertama sekali dia mendapat segala-galanya timeseries_ids daripada indeks terbalik yang mengandungi pasangan yang diberikan label=value, atau memenuhi ungkapan biasa yang diberikan.
• Kemudian ia mendapatkan semula semua titik data dari storan data pada selang masa tertentu untuk yang ditemui timeseries_ids.
• Selepas ini, pangkalan data melakukan beberapa pengiraan pada titik data ini, mengikut permintaan pengguna. Dan selepas itu ia mengembalikan jawapan.

Dalam pembentangan ini saya akan memberitahu anda tentang bahagian pertama. Ini adalah carian timeseries_ids dengan indeks terbalik. Anda boleh menonton tentang bahagian kedua dan bahagian ketiga kemudian Sumber VictoriaMetrics, atau tunggu sehingga saya menyediakan laporan lain :)

Mari kita beralih kepada indeks terbalik. Mungkin ramai yang menganggap ini mudah. Siapa tahu apa itu indeks terbalik dan cara ia berfungsi? Oh, tidak ramai lagi orang. Mari cuba fahami apa itu.

Ia sebenarnya mudah. Ia hanyalah kamus yang memetakan kunci kepada nilai. Apakah kunci? pasangan ini label=valueJika label и value - ini adalah garisan. Dan nilai adalah satu set timeseries_ids, yang termasuk pasangan yang diberikan label=value.

Indeks terbalik membolehkan anda mencari segala-galanya dengan cepat timeseries_ids, yang telah memberi label=value.

Ia juga membolehkan anda mencari dengan cepat timeseries_ids siri masa untuk beberapa pasangan label=value, atau untuk pasangan label=regexp. Bagaimana ini berlaku? Dengan mencari persilangan set timeseries_ids bagi setiap pasangan label=value.

Mari kita lihat pelbagai pelaksanaan indeks terbalik. Mari kita mulakan dengan pelaksanaan naif yang paling mudah. Dia kelihatan seperti ini.

Fungsi getMetricIDs mendapat senarai rentetan. Setiap baris mengandungi label=value. Fungsi ini mengembalikan senarai metricIDs.

Bagaimana ia berfungsi? Di sini kita mempunyai pembolehubah global yang dipanggil invertedIndex. Ini adalah kamus biasa (map), yang akan memetakan rentetan untuk menghiris int. Garis mengandungi label=value.

Pelaksanaan fungsi: dapatkan metricIDs untuk kali pertama label=value, kemudian kita melalui semua yang lain label=value, kami faham metricIDs untuk mereka. Dan panggil fungsi itu intersectInts, yang akan dibincangkan di bawah. Dan fungsi ini mengembalikan persimpangan senarai ini.

Seperti yang anda lihat, melaksanakan indeks terbalik tidak begitu rumit. Tetapi ini adalah pelaksanaan yang naif. Apakah kelemahan yang ada padanya? Kelemahan utama pelaksanaan naif ialah indeks terbalik seperti itu disimpan dalam RAM. Selepas memulakan semula aplikasi, kami kehilangan indeks ini. Tiada penjimatan indeks ini ke cakera. Indeks terbalik seperti itu tidak mungkin sesuai untuk pangkalan data.

Kelemahan kedua juga berkaitan dengan ingatan. Indeks terbalik mesti dimuatkan ke dalam RAM. Jika ia melebihi saiz RAM, maka jelas kita akan mendapat - daripada ralat memori. Dan program itu tidak akan berfungsi.

Masalah ini boleh diselesaikan dengan menggunakan penyelesaian sedia seperti LevelDBAtau RocksDB.

Ringkasnya, kami memerlukan pangkalan data yang membolehkan kami melakukan tiga operasi dengan cepat.

• Operasi pertama ialah rakaman ключ-значение ke pangkalan data ini. Dia melakukan ini dengan cepat, di mana ключ-значение adalah rentetan sewenang-wenangnya.
• Operasi kedua ialah carian pantas untuk nilai menggunakan kunci yang diberikan.
• Dan operasi ketiga ialah carian pantas untuk semua nilai dengan awalan yang diberikan.

LevelDB dan RocksDB - pangkalan data ini dibangunkan oleh Google dan Facebook. Pertama datang LevelDB. Kemudian lelaki dari Facebook mengambil LevelDB dan mula memperbaikinya, mereka membuat RocksDB. Kini hampir semua pangkalan data dalaman berfungsi pada RocksDB di dalam Facebook, termasuk yang telah dipindahkan ke RocksDB dan MySQL. Mereka menamakan dia MyRocks.

Indeks terbalik boleh dilaksanakan menggunakan LevelDB. Bagaimana hendak melakukannya? Kita simpan sebagai kunci label=value. Dan nilainya ialah pengecam siri masa di mana pasangan itu hadir label=value.

Jika kita mempunyai banyak siri masa dengan pasangan tertentu label=value, maka akan terdapat banyak baris dalam pangkalan data ini dengan kunci yang sama dan berbeza timeseries_ids. Untuk mendapatkan senarai semua timeseries_ids, yang bermula dengan ini label=prefix, kami melakukan imbasan julat yang mana pangkalan data ini dioptimumkan. Iaitu, kami memilih semua baris yang bermula dengan label=prefix dan dapatkan yang perlu timeseries_ids.

Berikut ialah contoh pelaksanaan bagaimana ia akan kelihatan seperti dalam Go. Kami mempunyai indeks terbalik. Ini ialah LevelDB.

Fungsinya adalah sama seperti untuk pelaksanaan naif. Ia mengulangi pelaksanaan naif hampir baris demi baris. Satu-satunya perkara ialah bukannya beralih kepada map kita mengakses indeks terbalik. Kami mendapat semua nilai untuk yang pertama label=value. Kemudian kita pergi melalui semua pasangan yang tinggal label=value dan dapatkan set metrikID yang sepadan untuk mereka. Kemudian kami mencari simpang.

Segala-galanya nampaknya baik-baik saja, tetapi terdapat kelemahan untuk penyelesaian ini. VictoriaMetrics pada mulanya melaksanakan indeks terbalik berdasarkan LevelDB. Tetapi akhirnya saya terpaksa melepaskannya.

kenapa? Kerana LevelDB lebih perlahan daripada pelaksanaan naif. Dalam pelaksanaan yang naif, diberikan kunci yang diberikan, kami segera mengambil keseluruhan kepingan metricIDs. Ini adalah operasi yang sangat pantas - keseluruhan kepingan sedia untuk digunakan.

Dalam LevelDB, setiap kali fungsi dipanggil GetValues anda perlu melalui semua baris yang bermula dengan label=value. Dan dapatkan nilai untuk setiap baris timeseries_ids. Daripada itu timeseries_ids kumpulkan sepotong ini timeseries_ids. Jelas sekali, ini adalah lebih perlahan daripada hanya mengakses peta biasa dengan kunci.

Kelemahan kedua ialah LevelDB ditulis dalam C. Memanggil fungsi C dari Go tidak begitu pantas. Ia mengambil masa beratus-ratus nanosaat. Ini tidak begitu pantas, kerana berbanding dengan panggilan fungsi biasa yang ditulis dalam go, yang mengambil masa 1-5 nanosaat, perbezaan prestasi adalah berpuluh kali ganda. Untuk VictoriaMetrics ini adalah kecacatan yang membawa maut :)

Jadi saya menulis pelaksanaan indeks terbalik saya sendiri. Dan dia memanggilnya mergeset.

Mergeset adalah berdasarkan struktur data MergeTree. Struktur data ini dipinjam daripada ClickHouse. Jelas sekali, mergeset harus dioptimumkan untuk carian pantas timeseries_ids mengikut kunci yang diberikan. Mergeset ditulis sepenuhnya dalam Go. Awak boleh lihat Sumber VictoriaMetrics di GitHub. Pelaksanaan mergeset berada dalam folder /lib/mergeset. Anda boleh cuba mencari tahu apa yang berlaku di sana.

API mergeset sangat serupa dengan LevelDB dan RocksDB. Iaitu, ia membolehkan anda menyimpan rekod baharu dengan cepat di sana dan memilih rekod dengan cepat mengikut awalan yang diberikan.

Kami akan bercakap tentang keburukan mergeset nanti. Sekarang mari kita bincangkan tentang masalah yang timbul dengan VictoriaMetrics dalam pengeluaran apabila melaksanakan indeks terbalik.

Mengapa mereka timbul?

Sebab pertama ialah kadar churn yang tinggi. Diterjemahkan ke dalam bahasa Rusia, ini adalah perubahan yang kerap dalam siri masa. Ini adalah apabila siri masa tamat dan siri baharu bermula, atau banyak siri masa baharu bermula. Dan ini sering berlaku.

Sebab kedua ialah bilangan siri masa yang banyak. Pada mulanya, apabila pemantauan semakin popular, bilangan siri masa adalah kecil. Sebagai contoh, untuk setiap komputer anda perlu memantau CPU, memori, rangkaian dan beban cakera. 4 siri masa setiap komputer. Katakan anda mempunyai 100 komputer dan 400 siri masa. Ini sangat sedikit.

Lama kelamaan, orang ramai mendapati bahawa mereka boleh mengukur maklumat yang lebih terperinci. Sebagai contoh, ukur beban bukan keseluruhan pemproses, tetapi secara berasingan bagi setiap teras pemproses. Jika anda mempunyai 40 teras pemproses, maka anda mempunyai 40 kali lebih banyak siri masa untuk mengukur beban pemproses.

Tetapi bukan itu sahaja. Setiap teras pemproses boleh mempunyai beberapa keadaan, seperti melahu, apabila ia melahu. Dan juga berfungsi dalam ruang pengguna, bekerja dalam ruang kernel dan keadaan lain. Dan setiap keadaan sedemikian juga boleh diukur sebagai siri masa yang berasingan. Ini menambah bilangan baris sebanyak 7-8 kali ganda.

Daripada satu metrik kami mendapat 40 x 8 = 320 metrik untuk hanya satu komputer. Darab dengan 100, kita mendapat 32 bukannya 000.

Kemudian Kubernetes datang. Dan ia menjadi lebih teruk kerana Kubernetes boleh mengehoskan banyak perkhidmatan yang berbeza. Setiap perkhidmatan dalam Kubernetes terdiri daripada banyak pod. Dan semua ini perlu dipantau. Selain itu, kami mempunyai penggunaan berterusan versi baharu perkhidmatan anda. Untuk setiap versi baharu, siri masa baharu mesti dibuat. Akibatnya, bilangan siri masa berkembang secara eksponen dan kita berhadapan dengan masalah sejumlah besar siri masa, yang dipanggil kardinaliti tinggi. VictoriaMetrics berjaya mengatasinya berbanding pangkalan data siri masa yang lain.

Mari kita lihat lebih dekat pada kadar churn yang tinggi. Apakah yang menyebabkan kadar churn yang tinggi dalam pengeluaran? Kerana beberapa makna label dan tag sentiasa berubah.

Sebagai contoh, ambil Kubernetes, yang mempunyai konsep deployment, iaitu apabila versi baharu aplikasi anda dilancarkan. Atas sebab tertentu, pembangun Kubernetes memutuskan untuk menambahkan id penempatan pada label.

Ini membawa kepada apa? Selain itu, dengan setiap penggunaan baharu, semua siri masa lama akan terganggu, dan bukannya siri masa baharu, siri masa baharu bermula dengan nilai label baharu deployment_id. Mungkin terdapat ratusan ribu malah berjuta-juta baris sedemikian.

Perkara penting tentang semua ini ialah jumlah bilangan siri masa bertambah, tetapi bilangan siri masa yang sedang aktif dan menerima data kekal malar. Keadaan ini dipanggil kadar churn tinggi.

Masalah utama kadar churn yang tinggi adalah untuk memastikan kelajuan carian yang berterusan untuk semua siri masa untuk set label tertentu dalam selang masa tertentu. Biasanya ini ialah selang masa untuk jam terakhir atau hari terakhir.

Bagaimana untuk menyelesaikan masalah ini? Inilah pilihan pertama. Ini adalah untuk membahagikan indeks terbalik kepada bahagian bebas dari semasa ke semasa. Iaitu, beberapa selang masa berlalu, kami selesai bekerja dengan indeks terbalik semasa. Dan buat indeks terbalik baharu. Satu lagi selang masa berlalu, kami mencipta satu lagi dan satu lagi.

Dan apabila pensampelan daripada indeks songsang ini, kita dapati satu set indeks songsang yang berada dalam selang waktu tertentu. Dan, sewajarnya, kami memilih id siri masa dari sana.

Ini menjimatkan sumber kerana kita tidak perlu melihat bahagian yang tidak termasuk dalam selang waktu yang diberikan. Iaitu, biasanya, jika kami memilih data untuk jam terakhir, maka untuk selang masa sebelumnya kami melangkau pertanyaan.

Terdapat pilihan lain untuk menyelesaikan masalah ini. Ini adalah untuk menyimpan bagi setiap hari senarai berasingan id siri masa yang berlaku pada hari itu.

Kelebihan penyelesaian ini berbanding penyelesaian sebelumnya ialah kami tidak menduplikasi maklumat siri masa yang tidak hilang dari semasa ke semasa. Mereka sentiasa hadir dan tidak berubah.

Kelemahannya ialah penyelesaian sedemikian adalah lebih sukar untuk dilaksanakan dan lebih sukar untuk nyahpepijat. Dan VictoriaMetrics memilih penyelesaian ini. Ini adalah bagaimana ia berlaku dalam sejarah. Penyelesaian ini juga berfungsi dengan baik berbanding dengan yang sebelumnya. Kerana penyelesaian ini tidak dilaksanakan kerana fakta bahawa data perlu diduplikasi dalam setiap partition untuk siri masa yang tidak berubah, iaitu yang tidak hilang dari semasa ke semasa. VictoriaMetrics dioptimumkan terutamanya untuk penggunaan ruang cakera, dan pelaksanaan sebelumnya menjadikan penggunaan ruang cakera lebih teruk. Tetapi pelaksanaan ini lebih sesuai untuk meminimumkan penggunaan ruang cakera, jadi ia dipilih.

Saya terpaksa melawan dia. Perjuangan adalah bahawa dalam pelaksanaan ini anda masih perlu memilih nombor yang lebih besar timeseries_ids untuk data daripada apabila indeks terbalik dipisahkan masa.

Bagaimanakah kami menyelesaikan masalah ini? Kami menyelesaikannya dengan cara yang asal - dengan menyimpan beberapa pengecam siri masa dalam setiap entri indeks terbalik dan bukannya satu pengecam. Maksudnya, kita ada kunci label=value, yang berlaku dalam setiap siri masa. Dan kini kami menjimatkan beberapa timeseries_ids dalam satu entry.

Berikut adalah contoh. Sebelum ini kami mempunyai N entri, tetapi kini kita mempunyai satu entri yang awalannya sama dengan semua yang lain. Untuk entri sebelumnya, nilai mengandungi semua id siri masa.

Ini memungkinkan untuk meningkatkan kelajuan pengimbasan indeks terbalik sedemikian sehingga 10 kali ganda. Dan ia membolehkan kami mengurangkan penggunaan memori untuk cache, kerana sekarang kami menyimpan rentetan label=value hanya sekali dalam cache bersama-sama N kali. Dan baris ini boleh menjadi besar jika anda menyimpan barisan panjang dalam teg dan label anda, yang Kubernetes suka letak di sana.

Pilihan lain untuk mempercepatkan carian pada indeks terbalik ialah sharding. Mencipta beberapa indeks terbalik dan bukannya satu dan memisahkan data di antaranya dengan kunci. Ini adalah satu set key=value wap. Iaitu, kita mendapat beberapa indeks songsang bebas, yang boleh kita tanya secara selari pada beberapa pemproses. Pelaksanaan sebelumnya hanya membenarkan operasi dalam mod pemproses tunggal, iaitu, mengimbas data pada satu teras sahaja. Penyelesaian ini membolehkan anda mengimbas data pada beberapa teras sekaligus, seperti yang ClickHouse suka lakukan. Inilah yang kami rancang untuk melaksanakan.

Sekarang mari kita kembali ke biri-biri kita - kepada fungsi persimpangan timeseries_ids. Mari kita pertimbangkan apakah pelaksanaan yang mungkin ada. Fungsi ini membolehkan anda mencari timeseries_ids untuk set yang diberikan label=value.

Pilihan pertama ialah pelaksanaan yang naif. Dua gelung bersarang. Di sini kita mendapat input fungsi intersectInts dua keping - a и b. Pada output, ia harus mengembalikan kepada kami persimpangan kepingan ini.

Pelaksanaan naif kelihatan seperti ini. Kami mengulangi semua nilai dari slice a, di dalam gelung ini kita melalui semua nilai slice b. Dan kita bandingkan mereka. Jika ia sepadan, maka kami telah menemui persimpangan. Dan simpan dalam result.

Apakah keburukan? Kerumitan kuadratik adalah kelemahan utamanya. Contohnya, jika dimensi anda adalah hirisan a и b satu juta pada satu masa, maka fungsi ini tidak akan mengembalikan jawapan kepada anda. Kerana ia perlu membuat satu trilion lelaran, yang banyak walaupun untuk komputer moden.

Pelaksanaan kedua adalah berdasarkan peta. Kami membuat peta. Kami meletakkan semua nilai dari slice ke dalam peta ini a. Kemudian kita melalui kepingan dalam gelung yang berasingan b. Dan kami menyemak sama ada nilai ini dari slice b dalam peta. Jika ia wujud, kemudian tambahkannya pada hasilnya.

Apakah faedahnya? Kelebihannya ialah hanya terdapat kerumitan linear. Iaitu, fungsi akan dilaksanakan dengan lebih pantas untuk kepingan yang lebih besar. Untuk kepingan bersaiz juta, fungsi ini akan dilaksanakan dalam 2 juta lelaran, berbanding trilion lelaran fungsi sebelumnya.

Kelemahannya ialah fungsi ini memerlukan lebih banyak memori untuk mencipta peta ini.

Kelemahan kedua ialah overhed yang besar untuk pencincangan. Kelemahan ini tidak begitu jelas. Dan bagi kami ia juga tidak begitu jelas, jadi pada mulanya di VictoriaMetrics pelaksanaan persimpangan adalah melalui peta. Tetapi kemudian pemprofilan menunjukkan bahawa masa pemproses utama dihabiskan untuk menulis pada peta dan menyemak kehadiran nilai dalam peta ini.

Mengapa masa CPU dibazirkan di tempat ini? Kerana Go melakukan operasi pencincangan pada baris ini. Iaitu, ia mengira cincangan kunci untuk kemudian mengaksesnya pada indeks tertentu dalam HashMap. Operasi pengiraan cincang selesai dalam berpuluh-puluh nanosaat. Ini lambat untuk VictoriaMetrics.

Saya memutuskan untuk melaksanakan bitset yang dioptimumkan khusus untuk kes ini. Inilah rupa persilangan dua keping sekarang. Di sini kita mencipta bitset. Kami menambah elemen dari kepingan pertama kepadanya. Kemudian kami menyemak kehadiran unsur-unsur ini dalam kepingan kedua. Dan tambahkannya pada hasilnya. Iaitu, ia hampir tidak berbeza dengan contoh sebelumnya. Satu-satunya perkara di sini ialah kami menggantikan akses kepada peta dengan fungsi tersuai add и has.

Pada pandangan pertama, nampaknya ini sepatutnya berfungsi lebih perlahan, jika sebelum ini peta standard digunakan di sana, dan kemudian beberapa fungsi lain dipanggil, tetapi pemprofilan menunjukkan bahawa perkara ini berfungsi 10 kali lebih cepat daripada peta standard dalam kes VictoriaMetrics.

Di samping itu, ia menggunakan lebih sedikit memori berbanding dengan pelaksanaan peta. Kerana kami menyimpan bit di sini dan bukannya nilai lapan bait.

Kelemahan pelaksanaan ini ialah ia tidak begitu ketara, tidak remeh.

Kelemahan lain yang mungkin ramai tidak perasan ialah pelaksanaan ini mungkin tidak berfungsi dengan baik dalam beberapa kes. Iaitu, ia dioptimumkan untuk kes tertentu, untuk kes persilangan id siri masa VictoriaMetrics ini. Ini tidak bermakna ia sesuai untuk semua kes. Jika ia digunakan secara tidak betul, kita tidak akan mendapat peningkatan prestasi, tetapi ralat memori dan kelembapan dalam prestasi.

Mari kita pertimbangkan pelaksanaan struktur ini. Jika anda ingin melihat, ia terletak dalam sumber VictoriaMetrics, dalam folder lib/uint64set. Ia dioptimumkan khusus untuk kes VictoriaMetrics, di mana timeseries_id ialah nilai 64-bit, di mana 32 bit pertama pada dasarnya tetap dan hanya 32 bit terakhir yang berubah.

Struktur data ini tidak disimpan pada cakera, ia hanya beroperasi dalam ingatan.

Inilah APInya. Ia tidak terlalu rumit. API disesuaikan secara khusus kepada contoh khusus penggunaan VictoriaMetrics. Iaitu, tiada fungsi yang tidak perlu di sini. Berikut ialah fungsi yang digunakan secara eksplisit oleh VictoriaMetrics.

Terdapat fungsi add, yang menambah nilai baharu. Ada fungsi has, yang menyemak nilai baharu. Dan ada fungsi del, yang mengalih keluar nilai. Terdapat fungsi pembantu len, yang mengembalikan saiz set. Fungsi clone klon banyak. Dan fungsi appendto menukar set ini kepada slice timeseries_ids.

Beginilah rupa pelaksanaan struktur data ini. set mempunyai dua elemen:

• ItemsCount ialah medan pembantu untuk mengembalikan bilangan elemen dalam set dengan cepat. Ia boleh dilakukan tanpa medan tambahan ini, tetapi ia perlu ditambah di sini kerana VictoriaMetrics sering menanyakan panjang set bit dalam algoritmanya.

• Medan kedua ialah buckets. Ini adalah kepingan dari struktur bucket32. Setiap struktur menyimpan hi padang. Ini adalah 32 bit atas. Dan dua keping - b16his и buckets daripada bucket16 struktur.

16 bit teratas bahagian kedua struktur 64-bit disimpan di sini. Dan di sini bitset disimpan untuk 16 bit bawah setiap bait.

Bucket64 terdiri daripada tatasusunan uint64. Panjang dikira menggunakan pemalar ini. Dalam satu bucket16 maksimum boleh disimpan 2^16=65536 sedikit. Jika anda membahagikan ini dengan 8, maka ia adalah 8 kilobait. Jika anda bahagikan dengan 8 lagi, ia adalah 1000 uint64 maksudnya. Itu dia Bucket16 – ini ialah struktur 8 kilobait kami.

Mari kita lihat bagaimana salah satu kaedah struktur ini untuk menambah nilai baharu dilaksanakan.

Semuanya bermula dengan uint64 makna. Kami mengira 32 bit atas, kami mengira 32 bit yang lebih rendah. Mari kita lalui segala-galanya buckets. Kami membandingkan 32 bit teratas dalam setiap baldi dengan nilai yang ditambah. Dan jika mereka sepadan, maka kami memanggil fungsi itu add dalam struktur b32 buckets. Dan tambahkan 32 bit yang lebih rendah di sana. Dan jika ia kembali true, maka ini bermakna kami menambah nilai sedemikian di sana dan kami tidak mempunyai nilai sedemikian. Jika ia kembali false, maka makna sebegitu sudah wujud. Kemudian kami menambah bilangan elemen dalam struktur.

Jika kami tidak menemui yang anda perlukan bucket dengan nilai hi yang diperlukan, maka kita panggil fungsi tersebut addAlloc, yang akan menghasilkan yang baru bucket, menambahkannya pada struktur baldi.

Ini adalah pelaksanaan fungsi b32.add. Ia serupa dengan pelaksanaan sebelumnya. Kami mengira 16 bit yang paling ketara, 16 bit yang paling ketara.

Kemudian kita pergi melalui semua 16 bit atas. Kami mencari padanan. Dan jika terdapat padanan, kami memanggil kaedah tambah, yang akan kami pertimbangkan pada halaman seterusnya bucket16.

Dan inilah tahap terendah, yang harus dioptimumkan sebanyak mungkin. Kami mengira untuk uint64 nilai id dalam bit slice dan juga bitmask. Ini ialah topeng untuk nilai 64-bit yang diberikan, yang boleh digunakan untuk menyemak kehadiran bit ini, atau menetapkannya. Kami menyemak untuk melihat sama ada bit ini ditetapkan dan ditetapkan, dan mengembalikan kehadiran. Ini adalah pelaksanaan kami, yang membolehkan kami mempercepatkan operasi id bersilang bagi siri masa sebanyak 10 kali berbanding peta konvensional.

Selain pengoptimuman ini, VictoriaMetrics mempunyai banyak pengoptimuman lain. Kebanyakan pengoptimuman ini telah ditambahkan atas sebab tertentu, tetapi selepas memprofilkan kod dalam pengeluaran.

Ini ialah peraturan utama pengoptimuman - jangan tambahkan pengoptimuman dengan mengandaikan akan ada kesesakan di sini, kerana ia mungkin ternyata tidak akan ada kesesakan di sana. Pengoptimuman biasanya merendahkan kualiti kod. Oleh itu, ia patut dioptimumkan hanya selepas membuat profil dan sebaik-baiknya dalam pengeluaran, supaya ini adalah data sebenar. Jika sesiapa berminat, anda boleh melihat kod sumber VictoriaMetrics dan meneroka pengoptimuman lain yang ada.

Saya ada soalan tentang bitset. Sangat serupa dengan pelaksanaan vektor bool C++, bitset yang dioptimumkan. Adakah anda mengambil pelaksanaan dari sana?

Tidak, bukan dari sana. Semasa melaksanakan bitset ini, saya dibimbing oleh pengetahuan tentang struktur siri masa id ini, yang digunakan dalam VictoriaMetrics. Dan struktur mereka sedemikian rupa sehingga 32 bit atas pada dasarnya adalah malar. 32 bit yang lebih rendah tertakluk kepada perubahan. Semakin rendah bit, semakin kerap ia boleh berubah. Oleh itu, pelaksanaan ini dioptimumkan khusus untuk struktur data ini. Pelaksanaan C++, sejauh yang saya tahu, dioptimumkan untuk kes umum. Jika anda mengoptimumkan untuk kes umum, ini bermakna ia tidak akan menjadi yang paling optimum untuk kes tertentu.

Saya juga menasihati anda untuk menonton laporan Alexey Milovid. Kira-kira sebulan yang lalu, dia bercakap tentang pengoptimuman dalam ClickHouse untuk pengkhususan tertentu. Dia hanya mengatakan bahawa dalam kes umum, pelaksanaan C++ atau beberapa pelaksanaan lain disesuaikan untuk berfungsi dengan baik secara purata di hospital. Ia mungkin berprestasi lebih teruk daripada pelaksanaan khusus pengetahuan seperti kami, di mana kami tahu bahawa 32 bit teratas kebanyakannya tetap.

Saya ada soalan kedua. Apakah perbezaan asas daripada InfluxDB?

Terdapat banyak perbezaan asas. Dari segi prestasi dan penggunaan memori, InfluxDB dalam ujian menunjukkan penggunaan memori 10 kali lebih banyak untuk siri masa kardinaliti tinggi, apabila anda mempunyai banyak daripada mereka, contohnya, berjuta-juta. Contohnya, VictoriaMetrics menggunakan 1 GB setiap juta baris aktif, manakala InfluxDB menggunakan 10 GB. Dan itu adalah perbezaan yang besar.

Perbezaan asas kedua ialah InfluxDB mempunyai bahasa pertanyaan yang aneh - Flux dan InfluxQL. Mereka tidak begitu mudah untuk bekerja dengan siri masa berbanding dengan PromQL, yang disokong oleh VictoriaMetrics. PromQL ialah bahasa pertanyaan daripada Prometheus.

Dan satu lagi perbezaan ialah InfluxDB mempunyai model data yang agak pelik, di mana setiap baris boleh menyimpan beberapa medan dengan set tag yang berbeza. Garisan ini dibahagikan lagi kepada pelbagai jadual. Komplikasi tambahan ini merumitkan kerja berikutnya dengan pangkalan data ini. Sukar untuk menyokong dan memahami.

Dalam VictoriaMetrics semuanya lebih mudah. Di sana, setiap siri masa adalah nilai kunci. Nilainya ialah satu set mata - (timestamp, value), dan kuncinya ialah set label=value. Tiada pemisahan antara medan dan ukuran. Ia membolehkan anda memilih mana-mana data dan kemudian menggabungkan, menambah, menolak, mendarab, membahagi, tidak seperti InfluxDB di mana pengiraan antara baris yang berbeza masih tidak dilaksanakan setakat yang saya tahu. Walaupun ia dilaksanakan, ia adalah sukar, anda perlu menulis banyak kod.

Saya ada soalan penjelasan. Adakah saya faham dengan betul bahawa terdapat beberapa jenis masalah yang anda bincangkan, bahawa indeks terbalik ini tidak sesuai dengan memori, jadi terdapat pembahagian di sana?

Mula-mula, saya menunjukkan pelaksanaan naif indeks terbalik pada peta Go standard. Pelaksanaan ini tidak sesuai untuk pangkalan data kerana indeks terbalik ini tidak disimpan ke cakera, dan pangkalan data mesti disimpan ke cakera supaya data ini kekal tersedia semasa dimulakan semula. Dalam pelaksanaan ini, apabila anda memulakan semula aplikasi, indeks terbalik anda akan hilang. Dan anda akan kehilangan akses kepada semua data kerana anda tidak akan dapat mencarinya.

hello! Terima kasih atas laporan itu! Nama saya Pavel. Saya dari Wildberries. Saya ada beberapa soalan untuk anda. Soalan satu. Adakah anda fikir jika anda telah memilih prinsip yang berbeza semasa membina seni bina aplikasi anda dan membahagikan data dari semasa ke semasa, maka mungkin anda akan dapat menyilang data semasa mencari, hanya berdasarkan fakta bahawa satu partition mengandungi data untuk satu tempoh masa , iaitu, dalam satu selang masa dan anda tidak perlu risau tentang fakta bahawa kepingan anda bertaburan secara berbeza? Soalan nombor 2 - kerana anda melaksanakan algoritma yang sama dengan bitset dan segala-galanya, maka mungkin anda cuba menggunakan arahan pemproses? Mungkin anda pernah mencuba pengoptimuman sedemikian?

Saya akan menjawab yang kedua dengan segera. Kami belum sampai ke tahap itu. Tetapi jika perlu, kami akan sampai ke sana. Dan yang pertama, apakah soalannya?

Anda membincangkan dua senario. Dan mereka berkata bahawa mereka memilih yang kedua dengan pelaksanaan yang lebih kompleks. Dan mereka tidak memilih yang pertama, di mana data dibahagikan mengikut masa.

ya. Dalam kes pertama, jumlah volum indeks akan lebih besar, kerana dalam setiap partition kita perlu menyimpan data pendua untuk siri masa yang berterusan melalui semua partition ini. Dan jika kadar churn siri masa anda adalah kecil, iaitu siri yang sama sentiasa digunakan, maka dalam kes pertama kita akan kehilangan lebih banyak ruang cakera yang diduduki berbanding dengan kes kedua.

Dan sebagainya - ya, pembahagian masa adalah pilihan yang baik. Prometheus menggunakannya. Tetapi Prometheus mempunyai kelemahan lain. Apabila menggabungkan kepingan data ini, ia perlu menyimpan maklumat meta memori untuk semua label dan siri masa. Oleh itu, jika kepingan data yang dicantumkan adalah besar, maka penggunaan memori meningkat dengan sangat banyak semasa penggabungan, tidak seperti VictoriaMetrics. Apabila digabungkan, VictoriaMetrics tidak menggunakan memori sama sekali; hanya beberapa kilobait digunakan, tanpa mengira saiz kepingan data yang digabungkan.

Algoritma yang anda gunakan menggunakan memori. Ia menandakan tag siri masa yang mengandungi nilai. Dan dengan cara ini anda menyemak kehadiran berpasangan dalam satu tatasusunan data dan dalam yang lain. Dan anda faham sama ada persilangan berlaku atau tidak. Biasanya, pangkalan data melaksanakan kursor dan iterator yang menyimpan kandungan semasa mereka dan menjalankan data yang diisih disebabkan oleh kerumitan mudah operasi ini.

Mengapa kita tidak menggunakan kursor untuk melintasi data?

Ya.

Kami menyimpan baris yang diisih dalam LevelDB atau mergeset. Kita boleh menggerakkan kursor dan mencari persimpangan. Kenapa kita tidak menggunakannya? Sebab lambat. Kerana kursor bermakna anda perlu memanggil fungsi untuk setiap baris. Panggilan fungsi ialah 5 nanosaat. Dan jika anda mempunyai 100 baris, maka ternyata kami menghabiskan setengah saat hanya untuk memanggil fungsi tersebut.

Ada yang begitu, ya. Dan soalan terakhir saya. Soalannya mungkin kedengaran agak pelik. Mengapa tidak boleh membaca semua agregat yang diperlukan pada saat data tiba dan menyimpannya dalam bentuk yang diperlukan? Mengapa menyimpan volum yang besar dalam beberapa sistem seperti VictoriaMetrics, ClickHouse, dsb., dan kemudian menghabiskan banyak masa padanya?

Saya akan memberikan contoh untuk menjadikannya lebih jelas. Katakan bagaimana meter kelajuan mainan kecil berfungsi? Ia merekodkan jarak yang telah anda lalui, sepanjang masa menambahkannya kepada satu nilai, dan kali kedua. Dan membahagikan. Dan mendapat kelajuan purata. Anda boleh melakukan perkara yang sama. Tambah semua fakta yang diperlukan dengan cepat.

Okay, saya faham soalan itu. Contoh anda ada tempatnya. Jika anda tahu agregat yang anda perlukan, maka ini adalah pelaksanaan terbaik. Tetapi masalahnya ialah orang ramai menyimpan metrik ini, beberapa data dalam ClickHouse dan mereka belum tahu bagaimana mereka akan mengagregat dan menapisnya pada masa hadapan, jadi mereka perlu menyimpan semua data mentah. Tetapi jika anda tahu anda perlu mengira sesuatu secara purata, maka mengapa tidak mengiranya daripada menyimpan sekumpulan nilai mentah di sana? Tetapi ini hanya jika anda tahu dengan tepat apa yang anda perlukan.

Dengan cara ini, pangkalan data untuk menyimpan siri masa menyokong pengiraan agregat. Sebagai contoh, Prometheus menyokong peraturan rakaman. Iaitu, ini boleh dilakukan jika anda tahu unit yang anda perlukan. VictoriaMetrics tidak mempunyai ini lagi, tetapi ia biasanya didahului oleh Prometheus, di mana ini boleh dilakukan dalam peraturan pengekodan semula.

Sebagai contoh, dalam tugas saya sebelum ini, saya perlu mengira bilangan acara dalam tetingkap gelongsor sepanjang jam terakhir. Masalahnya ialah saya terpaksa membuat pelaksanaan tersuai dalam Go, iaitu perkhidmatan untuk mengira perkara ini. Perkhidmatan ini akhirnya tidak penting, kerana ia sukar untuk dikira. Pelaksanaannya boleh menjadi mudah jika anda perlu mengira beberapa agregat pada selang masa tetap. Jika anda ingin mengira peristiwa dalam tetingkap gelongsor, maka ia tidak semudah yang kelihatan. Saya rasa ini belum lagi dilaksanakan dalam ClickHouse atau dalam pangkalan data siri masa, kerana ia sukar untuk dilaksanakan.

Dan satu lagi soalan. Kami hanya bercakap tentang purata, dan saya teringat bahawa pernah ada perkara seperti Grafit dengan bahagian belakang Karbon. Dan dia tahu bagaimana untuk menipiskan data lama, iaitu, meninggalkan satu mata seminit, satu mata sejam, dll. Pada dasarnya, ini agak mudah jika kita memerlukan data mentah, secara relatifnya, selama sebulan, dan segala-galanya boleh menjadi kurus. Tetapi Prometheus dan VictoriaMetrics tidak menyokong fungsi ini. Adakah ia dirancang untuk menyokongnya? Jika tidak, mengapa tidak?

Terima kasih atas soalan. Pengguna kami bertanya soalan ini secara berkala. Mereka bertanya bila kami akan menambah sokongan untuk pensampelan rendah. Terdapat beberapa masalah di sini. Pertama, setiap pengguna faham downsampling sesuatu yang berbeza: seseorang ingin mendapatkan sebarang titik sewenang-wenangnya pada selang waktu tertentu, seseorang mahukan nilai maksimum, minimum, purata. Jika banyak sistem menulis data ke pangkalan data anda, maka anda tidak boleh menggabungkan semuanya. Mungkin setiap sistem memerlukan penipisan yang berbeza. Dan ini sukar untuk dilaksanakan.

Dan perkara kedua ialah VictoriaMetrics, seperti ClickHouse, dioptimumkan untuk bekerja dengan jumlah data mentah yang besar, jadi ia boleh menyekop satu bilion baris dalam masa kurang dari satu saat jika anda mempunyai banyak teras dalam sistem anda. Mengimbas titik siri masa dalam VictoriaMetrics – 50 mata sesaat setiap teras. Dan prestasi ini berskala kepada teras sedia ada. Iaitu, jika anda mempunyai 000 teras, sebagai contoh, anda akan mengimbas satu bilion mata sesaat. Dan sifat VictoriaMetrics dan ClickHouse ini mengurangkan keperluan untuk downsamling.

Ciri lain ialah VictoriaMetrics memampatkan data ini dengan berkesan. Mampatan secara purata dalam pengeluaran adalah dari 0,4 hingga 0,8 bait setiap titik. Setiap titik ialah cap masa + nilai. Dan ia dimampatkan menjadi kurang daripada satu bait secara purata.

Sergey. Saya ada satu soalan. Apakah kuantum masa rakaman minimum?

Satu milisaat. Kami baru-baru ini mengadakan perbualan dengan pembangun pangkalan data siri masa yang lain. Potongan masa minimum mereka ialah satu saat. Dan dalam Grafit, sebagai contoh, ia juga satu saat. Dalam OpenTSDB ia juga satu saat. InfluxDB mempunyai ketepatan nanosaat. Dalam VictoriaMetrics ia adalah satu milisaat, kerana dalam Prometheus ia adalah satu milisaat. Dan VictoriaMetrics pada asalnya dibangunkan sebagai storan jauh untuk Prometheus. Tetapi kini ia boleh menyimpan data daripada sistem lain.

Orang yang saya bercakap dengan mengatakan bahawa mereka mempunyai ketepatan kedua ke saat - itu sudah cukup untuk mereka kerana ia bergantung pada jenis data yang disimpan dalam pangkalan data siri masa. Jika ini adalah data DevOps atau data daripada infrastruktur, di mana anda mengumpulnya pada selang 30 saat, seminit, maka ketepatan kedua sudah mencukupi, anda tidak memerlukan apa-apa yang kurang. Dan jika anda mengumpul data ini daripada sistem perdagangan frekuensi tinggi, maka anda memerlukan ketepatan nanosaat.

Ketepatan milisaat dalam VictoriaMetrics juga sesuai untuk kes DevOps, dan boleh sesuai untuk kebanyakan kes yang saya nyatakan pada permulaan laporan. Satu-satunya perkara yang mungkin tidak sesuai ialah sistem perdagangan frekuensi tinggi.

Terima kasih! Dan satu lagi soalan. Apakah keserasian dalam PromQL?

Keserasian ke belakang penuh. VictoriaMetrics menyokong penuh PromQL. Di samping itu, ia menambah fungsi lanjutan tambahan dalam PromQL, yang dipanggil MetricsQL. Terdapat ceramah di YouTube tentang fungsi lanjutan ini. Saya bercakap di Pertemuan Pemantauan pada musim bunga di St. Petersburg.

Saluran Telegram VictoriaMetrics.

Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. Log masuk, Sama-sama.

Apakah yang menghalang anda daripada beralih kepada VictoriaMetrics sebagai simpanan jangka panjang anda untuk Prometheus? (Tulis dalam ulasan, saya akan menambahnya pada tinjauan pendapat))

• 71,4% Saya tidak menggunakan Prometheus5

• 28,6% Tidak tahu tentang VictoriaMetrics2

7 pengguna mengundi. 12 pengguna berpantang.

Sumber: www.habr.com