Sejak beberapa tahun kebelakangan ini, pangkalan data siri masa telah bertukar daripada perkara yang aneh (sangat khusus digunakan sama ada dalam sistem pemantauan terbuka (dan terikat kepada penyelesaian khusus) atau dalam projek Data Besar) kepada "produk pengguna". Di wilayah Persekutuan Rusia, terima kasih khusus mesti diberikan kepada Yandex dan ClickHouse untuk ini. Sehingga ketika ini, jika anda perlu menyimpan sejumlah besar data siri masa, anda sama ada perlu menerima keperluan untuk membina timbunan Hadoop yang besar dan mengekalkannya, atau berkomunikasi dengan protokol individu untuk setiap sistem.
Nampaknya pada tahun 2019 artikel tentang TSDB yang patut digunakan akan terdiri daripada hanya satu ayat: "guna sahaja ClickHouse." Tetapi... ada nuansa.
Sesungguhnya, ClickHouse sedang giat membangun, pangkalan pengguna berkembang, dan sokongan sangat aktif, tetapi adakah kita telah menjadi tebusan kepada kejayaan awam ClickHouse, yang telah membayangi penyelesaian lain, mungkin lebih berkesan/boleh dipercayai?
Pada awal tahun lepas, kami mula mengolah semula sistem pemantauan kami sendiri, di mana timbul persoalan memilih pangkalan data yang sesuai untuk menyimpan data. Saya ingin bercakap tentang sejarah pilihan ini di sini.
Pernyataan masalah
Pertama sekali, kata pengantar yang perlu. Mengapa kita memerlukan sistem pemantauan kita sendiri dan bagaimana ia direka?
Kami mula menyediakan perkhidmatan sokongan pada tahun 2008, dan menjelang 2010 menjadi jelas bahawa ia menjadi sukar untuk mengagregat data tentang proses yang berlaku dalam infrastruktur pelanggan dengan penyelesaian yang wujud pada masa itu (kita bercakap tentang, Tuhan ampunkan saya, Cacti, Zabbix dan Grafit yang muncul).
Keperluan utama kami ialah:
- sokongan (pada masa itu - berpuluh-puluh, dan pada masa hadapan - beratus-ratus) pelanggan dalam satu sistem dan pada masa yang sama kehadiran sistem pengurusan amaran berpusat;
- fleksibiliti dalam menguruskan sistem amaran (peningkatan amaran antara pegawai bertugas, penjadualan, pangkalan pengetahuan);
- keupayaan untuk memperincikan graf secara mendalam (Zabbix pada masa itu memberikan graf dalam bentuk gambar);
- penyimpanan jangka panjang sejumlah besar data (setahun atau lebih) dan keupayaan untuk mendapatkannya dengan cepat.
Dalam artikel ini kami berminat dengan perkara terakhir.
Bercakap tentang penyimpanan, keperluan adalah seperti berikut:
- sistem mesti berfungsi dengan cepat;
- adalah wajar bahawa sistem mempunyai antara muka SQL;
- sistem mestilah stabil dan mempunyai pangkalan pengguna dan sokongan yang aktif (sebaik sahaja kami berhadapan dengan keperluan untuk menyokong sistem seperti MemcacheDB, yang tidak lagi dibangunkan, atau storan teragih MooseFS, penjejak pepijat yang disimpan dalam bahasa Cina: kami mengulangi cerita ini untuk projek kami tidak mahu);
- pematuhan dengan teorem CAP: Ketekalan (diperlukan) - data mestilah terkini, kami tidak mahu sistem pengurusan amaran tidak menerima data baharu dan mengeluarkan amaran tentang data tidak tiba untuk semua projek; Toleransi Partition (diperlukan) - kami tidak mahu mendapatkan sistem Split Brain; Ketersediaan (tidak kritikal, jika terdapat replika aktif) - kita boleh bertukar kepada sistem sandaran sendiri sekiranya berlaku kemalangan, menggunakan kod.
Anehnya, pada masa itu MySQL ternyata menjadi penyelesaian yang ideal untuk kami. Struktur data kami sangat mudah: id pelayan, id balas, cap masa dan nilai; pensampelan pantas data panas telah dipastikan oleh kumpulan penimbal yang besar, dan pensampelan data sejarah dipastikan oleh SSD.
Oleh itu, kami mencapai sampel data dua minggu baharu, dengan perincian hingga 200 ms kedua sebelum data itu diberikan sepenuhnya, dan tinggal dalam sistem ini untuk masa yang agak lama.
Sementara itu, masa berlalu dan jumlah data bertambah. Menjelang 2016, volum data mencecah puluhan terabait, yang merupakan perbelanjaan yang besar dalam konteks storan SSD yang disewa.
Pada masa ini, pangkalan data kolumnar telah meluas secara aktif, yang kami mula fikirkan secara aktif: dalam pangkalan data kolumnar, data disimpan, seperti yang anda faham, dalam lajur, dan jika anda melihat data kami, mudah untuk melihat besar bilangan pendua yang boleh, dalam Jika anda menggunakan pangkalan data kolumnar, mampatkannya menggunakan pemampatan.
Walau bagaimanapun, sistem utama syarikat terus berfungsi dengan stabil, dan saya tidak mahu mencuba dengan beralih kepada sesuatu yang lain.
Pada tahun 2017, pada persidangan Percona Live di San Jose, pembangun Clickhouse mungkin mengumumkan diri mereka buat kali pertama. Pada pandangan pertama, sistem itu sedia pengeluaran (Yandex.Metrica ialah sistem pengeluaran yang keras), sokongan adalah pantas dan mudah, dan, yang paling penting, operasi adalah mudah. Sejak 2018, kami telah memulakan proses peralihan. Tetapi pada masa itu, terdapat banyak sistem TSDB "dewasa" dan diuji masa, dan kami memutuskan untuk menumpukan banyak masa dan membandingkan alternatif untuk memastikan bahawa tiada penyelesaian alternatif untuk Clickhouse, mengikut keperluan kami.
Sebagai tambahan kepada keperluan storan yang telah ditentukan, yang baharu telah muncul:
- sistem baharu harus menyediakan sekurang-kurangnya prestasi yang sama seperti MySQL pada jumlah perkakasan yang sama;
- storan sistem baharu seharusnya menggunakan ruang yang jauh lebih sedikit;
- DBMS mesti masih mudah untuk diurus;
- Saya mahu menukar aplikasi secara minimum apabila menukar DBMS.
Apakah sistem yang kami mula pertimbangkan?
Apache Hive/Apache Impala
Timbunan Hadoop lama yang diuji pertempuran. Pada asasnya, ia adalah antara muka SQL yang dibina di atas penyimpanan data dalam format asli pada HDFS.
Kebaikan.
- Dengan operasi yang stabil, sangat mudah untuk menskala data.
- Terdapat penyelesaian lajur untuk penyimpanan data (kurang ruang).
- Pelaksanaan tugas selari yang sangat pantas apabila sumber tersedia.
Cons
- Ia adalah Hadoop, dan ia sukar untuk digunakan. Jika kami tidak bersedia untuk mengambil penyelesaian siap sedia dalam awan (dan kami tidak bersedia dari segi kos), keseluruhan timbunan perlu dipasang dan disokong oleh tangan pentadbir, dan kami benar-benar tidak mahu ini.
- Data diagregatkan .
Walau bagaimanapun:
Kelajuan dicapai dengan menskalakan bilangan pelayan pengkomputeran. Ringkasnya, jika kami sebuah syarikat besar, terlibat dalam analitik, dan adalah penting bagi perniagaan untuk mengagregat maklumat secepat mungkin (walaupun dengan kos menggunakan sejumlah besar sumber pengkomputeran), ini mungkin pilihan kami. Tetapi kami tidak bersedia untuk memperbanyakkan armada perkakasan untuk mempercepatkan tugas.
Druid/Pinot
Terdapat banyak lagi tentang TSDB secara khusus, tetapi sekali lagi, timbunan Hadoop.
Terdapat .
Dalam beberapa perkataan: Druid/Pinot kelihatan lebih baik daripada Clickhouse dalam kes di mana:
- Anda mempunyai sifat data yang heterogen (dalam kes kami, kami hanya merekodkan siri masa metrik pelayan, dan, sebenarnya, ini adalah satu jadual. Tetapi mungkin terdapat kes lain: siri masa peralatan, siri masa ekonomi, dsb. - masing-masing dengan strukturnya sendiri, yang perlu diagregatkan dan diproses).
- Lebih-lebih lagi, terdapat banyak data ini.
- Jadual dan data dengan siri masa muncul dan hilang (iaitu, beberapa set data tiba, telah dianalisis dan dipadamkan).
- Tiada kriteria yang jelas yang membolehkan data dibahagikan.
Dalam kes yang bertentangan, ClickHouse berprestasi lebih baik, dan ini adalah kes kami.
Klik Rumah
- seperti SQL
- Mudah diurus.
- Orang kata ia berkesan.
Mendapat disenarai pendek untuk ujian.
InfluxDB
Alternatif asing kepada ClickHouse. Daripada kelemahan: Ketersediaan Tinggi hanya terdapat dalam versi komersial, tetapi ia perlu dibandingkan.
Mendapat disenarai pendek untuk ujian.
Cassandra
Di satu pihak, kita tahu bahawa ia digunakan untuk menyimpan siri masa metrik oleh sistem pemantauan seperti, sebagai contoh, atau OkMeter. Walau bagaimanapun, terdapat spesifik.
Cassandra bukanlah pangkalan data kolumnar dalam erti kata tradisional. Ia kelihatan lebih seperti paparan baris, tetapi setiap baris boleh mempunyai bilangan lajur yang berbeza, menjadikannya mudah untuk mengatur paparan lajur. Dalam pengertian ini, jelas bahawa dengan had 2 bilion lajur, adalah mungkin untuk menyimpan beberapa data dalam lajur (dan siri masa yang sama). Sebagai contoh, dalam MySQL terdapat had 4096 lajur dan ia adalah mudah untuk tersandung pada ralat dengan kod 1117 jika anda cuba melakukan perkara yang sama.
Enjin Cassandra tertumpu pada menyimpan sejumlah besar data dalam sistem teragih tanpa induk, dan teorem Cassandra CAP yang disebutkan di atas adalah lebih kepada AP, iaitu mengenai ketersediaan data dan ketahanan terhadap pembahagian. Oleh itu, alat ini boleh menjadi hebat jika anda hanya perlu menulis ke pangkalan data ini dan jarang membaca daripadanya. Dan di sini adalah logik untuk menggunakan Cassandra sebagai simpanan "sejuk". Iaitu, sebagai tempat jangka panjang dan boleh dipercayai untuk menyimpan sejumlah besar data sejarah yang jarang diperlukan, tetapi boleh diambil semula jika perlu. Namun begitu, demi kesempurnaan, kami akan mengujinya juga. Tetapi, seperti yang saya katakan sebelum ini, tidak ada keinginan untuk menulis semula kod secara aktif untuk penyelesaian pangkalan data yang dipilih, jadi kami akan mengujinya agak terhad - tanpa menyesuaikan struktur pangkalan data kepada spesifik Cassandra.
Prometheus
Nah, kerana ingin tahu, kami memutuskan untuk menguji prestasi storan Prometheus - hanya untuk memahami sama ada kami lebih pantas atau lebih perlahan daripada penyelesaian semasa dan berapa banyak.
Metodologi dan keputusan ujian
Jadi, kami menguji 5 pangkalan data dalam 6 konfigurasi berikut: ClickHouse (1 nod), ClickHouse (jadual teragih untuk 3 nod), InfluxDB, Mysql 8, Cassandra (3 nod) dan Prometheus. Pelan ujian adalah seperti berikut:
- muat naik data sejarah selama seminggu (840 juta nilai sehari; 208 ribu metrik);
- kami menjana beban rakaman (6 mod beban telah dipertimbangkan, lihat di bawah);
- Selari dengan rakaman, kami membuat pilihan secara berkala, mencontohi permintaan pengguna yang bekerja dengan carta. Untuk tidak merumitkan perkara terlalu banyak, kami memilih data untuk 10 metrik (itu betul-betul jumlah yang terdapat pada graf CPU) selama seminggu.
Kami memuatkan dengan mencontohi kelakuan ejen pemantauan kami, yang menghantar nilai kepada setiap metrik sekali setiap 15 saat. Pada masa yang sama, kami berminat untuk mempelbagaikan:
- jumlah bilangan metrik di mana data ditulis;
- selang untuk menghantar nilai kepada satu metrik;
- saiz kumpulan.
Mengenai saiz kumpulan. Memandangkan tidak disyorkan untuk memuatkan hampir semua pangkalan data percubaan kami dengan sisipan tunggal, kami memerlukan geganti yang mengumpul metrik masuk dan mengumpulkannya ke dalam kumpulan dan menulisnya ke pangkalan data sebagai sisipan kelompok.
Selain itu, untuk lebih memahami cara mentafsir data yang diterima kemudian, mari bayangkan bahawa kami bukan sahaja menghantar sekumpulan metrik, tetapi metrik disusun ke dalam pelayan - 125 metrik setiap pelayan. Di sini pelayan hanyalah entiti maya - hanya untuk memahami bahawa, sebagai contoh, 10000 metrik sepadan dengan kira-kira 80 pelayan.
Dan di sini, dengan mengambil kira semua ini, ialah 6 mod beban tulis pangkalan data kami:
Terdapat dua titik di sini. Pertama, untuk Cassandra saiz kumpulan ini ternyata terlalu besar, di sana kami menggunakan nilai 50 atau 100. Dan kedua, kerana Prometheus berfungsi dengan ketat dalam mod tarik, i.e. ia sendiri pergi dan mengumpul data daripada sumber metrik (dan juga pushgateway, walaupun namanya, tidak secara asasnya mengubah keadaan), beban yang sepadan telah dilaksanakan menggunakan gabungan konfigurasi statik.
Keputusan ujian adalah seperti berikut:
Apa yang patut diberi perhatian: sampel yang sangat pantas dari Prometheus, sampel yang sangat perlahan dari Cassandra, sampel yang tidak boleh diterima dari InfluxDB; Dari segi kelajuan rakaman, ClickHouse memenangi semua orang, dan Prometheus tidak mengambil bahagian dalam pertandingan itu, kerana ia membuat sisipan sendiri dan kami tidak mengukur apa-apa.
Hasilnya,: ClickHouse dan InfluxDB menunjukkan diri mereka sebagai yang terbaik, tetapi kluster daripada Influx hanya boleh dibina berdasarkan versi Enterprise, yang menelan kos wang, manakala ClickHouse tidak menelan kos dan dibuat di Rusia. Adalah logik bahawa di Amerika Syarikat pilihan mungkin memihak kepada inInfluxDB, dan di negara kita ia memihak kepada ClickHouse.
Sumber: www.habr.com