Bagaimana kami menguji beberapa basis data time series

Selama beberapa tahun terakhir, database Time-series telah berevolusi dari hal yang aneh (sangat terspesialisasi dalam sistem pemantauan terbuka (dan terkait dengan solusi spesifik) atau proyek Big Data) menjadi "barang konsumen". Di wilayah Federasi Rusia, terima kasih khusus harus diberikan kepada Yandex dan ClickHouse untuk ini. Hingga saat ini, jika Anda perlu menyimpan sejumlah besar data deret waktu, Anda harus menerima kebutuhan untuk meningkatkan tumpukan Hadoop yang mengerikan dan menyertainya, atau berkomunikasi dengan protokol khusus untuk setiap sistem.

Tampaknya pada 2019, sebuah artikel tentang TSDB mana yang harus digunakan akan terdiri dari hanya satu kalimat: "gunakan saja ClickHouse". Tapi ... ada nuansa.

Memang, ClickHouse secara aktif berkembang, basis pengguna tumbuh, dan dukungan sangat aktif, tetapi apakah kita telah menjadi sandera bagi kesuksesan publik ClickHouse, yang telah membayangi solusi lain, yang mungkin lebih efektif / dapat diandalkan?

Pada awal tahun lalu, kami mulai memproses sistem pemantauan kami sendiri, di mana muncul pertanyaan memilih basis yang sesuai untuk penyimpanan data. Saya ingin menceritakan tentang sejarah pilihan ini di sini.

Pernyataan masalah

Pertama-tama, kata pengantar yang diperlukan. Mengapa kita membutuhkan sistem pemantauan kita sendiri dan bagaimana pengaturannya?

Kami mulai memberikan layanan dukungan pada 2008, dan pada 2010 menjadi jelas bahwa sulit untuk mengumpulkan data tentang proses yang terjadi di infrastruktur klien dengan solusi yang ada pada saat itu (kami berbicara tentang, Tuhan memaafkan saya, Cacti, Zabbix dan yang baru lahir). Grafit).

Persyaratan utama kami adalah:

• mendukung (pada saat itu - lusinan, dan di masa depan - ratusan) pelanggan dalam sistem yang sama dan pada saat yang sama kehadiran sistem manajemen peringatan terpusat;
• fleksibilitas dalam mengelola sistem peringatan (eskalasi peringatan antara petugas, jadwal akuntansi, basis pengetahuan);
• kemungkinan perincian grafik yang dalam (Zabbix pada waktu itu menggambar grafik dalam bentuk gambar);
• penyimpanan jangka panjang dari sejumlah besar data (satu tahun atau lebih) dan kemampuan untuk memilihnya dengan cepat.

Pada artikel ini, kami tertarik pada poin terakhir.

Berbicara tentang penyimpanan, persyaratannya adalah sebagai berikut:

• sistem harus bekerja dengan cepat;
• diinginkan bahwa sistem memiliki antarmuka SQL;
• sistem harus stabil dan memiliki basis pengguna aktif dan dukungan (setelah kami dihadapkan dengan kebutuhan untuk mendukung sistem seperti MemcacheDB, yang kami hentikan pengembangannya, atau penyimpanan MooseFS yang didistribusikan, bugtracker yang dilakukan dalam bahasa Cina: mengulangi cerita ini untuk proyek kami kepada kami tidak mau);
• Korespondensi dengan teorema CAP: Konsistensi (diperlukan) - data harus relevan, kami tidak ingin sistem manajemen notifikasi tidak menerima data baru dan meludahkan peringatan tentang tidak kedatangan data untuk semua proyek; Toleransi Partisi (perlu) - kami tidak ingin mendapatkan sistem Split Brain; Ketersediaan (tidak penting, dalam kasus replika aktif) - kita dapat beralih ke sistem cadangan jika terjadi kecelakaan, dengan kode.

Anehnya, pada saat itu MySQL adalah solusi sempurna bagi kami. Struktur data kami sangat sederhana: id server, id penghitung, cap waktu, dan nilai; pengambilan sampel cepat untuk data panas disediakan oleh kumpulan buffer yang besar, dan pengambilan sampel data historis disediakan oleh SSD.



Dengan demikian, kami mencapai sampel data dua minggu baru, dengan merinci hingga 200 ms kedua sebelum data sepenuhnya diberikan, dan tinggal di sistem ini untuk beberapa waktu.

Sementara itu, waktu berlalu dan jumlah data bertambah. Pada 2016, volume data mencapai puluhan terabyte, yang dalam hal penyimpanan SSD sewaan merupakan pengeluaran yang signifikan.

Pada titik ini, basis data kolom digunakan secara aktif, yang kami mulai pikirkan secara aktif: di basis data kolom, data disimpan, seperti yang dapat Anda pahami, dalam kolom, dan jika Anda melihat data kami, mudah untuk melihat sejumlah besar pengambilan yang bisa dilakukan. Jika menggunakan basis data kolom, kompres dengan kompresi.



Namun, sistem kunci untuk pekerjaan perusahaan terus bekerja secara stabil, dan saya tidak ingin bereksperimen dengan transisi ke hal lain.

Pada 2017, di konferensi Persona Live di San Jose, mungkin pertama kalinya pengembang Clickhouse mengumumkan sendiri. Pada pandangan pertama, sistem ini siap produksi (baik, Yandex.Metrica adalah produksi yang keras), dukungannya cepat dan sederhana, dan yang paling penting, operasinya sederhana. Sejak 2018, kami telah memulai proses transisi. Tetapi pada saat itu, ada banyak sistem TSDB "dewasa" dan teruji waktu, dan kami memutuskan untuk mengalokasikan waktu yang cukup dan membandingkan alternatif untuk memastikan bahwa tidak ada solusi alternatif Clickhouse, sesuai dengan persyaratan kami.

Selain persyaratan penyimpanan yang sudah ditunjukkan, yang baru muncul:

• sistem baru harus menyediakan setidaknya kinerja yang sama dengan MySQL, pada jumlah zat besi yang sama;
• penyimpanan sistem baru harus menempati ruang yang jauh lebih sedikit;
• DBMS harus tetap mudah dikelola;
• Saya ingin meminimalkan aplikasi ketika mengubah DBMS.

Sistem apa yang mulai kami pertimbangkan

Apache Hive / Apache Impala
Tumpukan Hadoop yang sudah usang. Bahkan, ini adalah antarmuka SQL yang dibangun di atas menyimpan data dalam format asli pada HDFS.

Pro

• Dengan operasi yang stabil, sangat mudah untuk mengukur data.
• Ada solusi kolom untuk penyimpanan data (lebih sedikit ruang).
• Eksekusi sangat cepat dari tugas paralel di hadapan sumber daya.

Cons

• Ini adalah Hadoop, dan sulit dioperasikan. Jika kita tidak siap untuk mengambil solusi yang sudah jadi di cloud (dan kita tidak siap untuk biaya), seluruh tumpukan harus dirakit dan didukung oleh admin, tetapi saya benar-benar tidak menginginkan ini.
• Data dikumpulkan sangat cepat .

Namun:



Kecepatan dicapai dengan meningkatkan jumlah server komputasi. Sederhananya, jika kita adalah perusahaan besar yang bergerak di bidang analitik dan bisnis, sangat penting untuk mengumpulkan informasi secepat mungkin (bahkan dengan biaya menggunakan sejumlah besar sumber daya komputasi) - ini mungkin pilihan kita. Tapi kami belum siap melipatgandakan taman besi untuk mempercepat tugas.

Druid / pinot

Sudah jauh lebih banyak tentang TSDB khusus, tetapi sekali lagi - Hadoop-stack.

Ada artikel bagus membandingkan pro dan kontra Druid dan Pinot dibandingkan dengan ClickHouse .

Dalam beberapa kata: Druid / Pinot terlihat lebih baik daripada Clickhouse dalam kasus di mana:

• Anda memiliki sifat data yang heterogen (dalam kasus kami, kami hanya mencatat deret waktu metrik server, dan, pada kenyataannya, ini adalah satu tabel. Tetapi mungkin ada kasus lain: seri waktu peralatan, seri waktu ekonomi, dll. - masing-masing dengan strukturnya sendiri, yang harus dikumpulkan dan diproses).
• Apalagi ada banyak data ini.
• Tabel dan data dengan deret waktu muncul dan menghilang (yaitu, beberapa set data masuk, dianalisis dan dihapus).
• Tidak ada kriteria yang jelas dimana data dapat dipartisi.

Dalam kasus yang berlawanan, ClickHouse menunjukkan dirinya lebih baik, dan ini adalah kasus kami.

Clickhouse

• Seperti SQL.
• Mudah dikelola.
• Orang bilang itu berhasil.

Itu jatuh ke dalam daftar pengujian.

Influxdb

Alternatif asing untuk ClickHouse. Dari minus: Ketersediaan Tinggi hanya hadir dalam versi komersial, tetapi harus dibandingkan.

Itu jatuh ke dalam daftar pengujian.

Cassandra

Di satu sisi, kita tahu bahwa itu digunakan untuk menyimpan rentang waktu metrik oleh sistem pemantauan seperti, misalnya, SignalFX atau OkMeter. Namun, ada yang spesifik.

Cassandra bukan database kolom dalam arti biasa. Itu terlihat lebih seperti huruf kecil, tetapi setiap baris dapat memiliki jumlah kolom yang berbeda, sehingga mudah untuk mengatur representasi kolom. Dalam pengertian ini, jelas bahwa dengan batas 2 miliar kolom, Anda dapat menyimpan beberapa data dalam kolom (ya, seri waktu yang sama). Sebagai contoh, di MySQL ada batasan pada 4096 kolom dan mudah untuk menemukan kesalahan dengan kode 1117 jika Anda mencoba melakukan hal yang sama.

Mesin Cassandra berfokus pada penyimpanan sejumlah besar data dalam sistem terdistribusi tanpa penyihir, dan dalam CAP-teorema Cassandra lebih banyak tentang AP, yaitu tentang aksesibilitas data dan ketahanan terhadap partisi. Dengan demikian, alat ini dapat menjadi sangat bagus jika Anda hanya perlu menulis ke basis data ini dan jarang membacanya. Dan di sini logis menggunakan Cassandra sebagai penyimpanan "dingin". Artinya, sebagai tempat jangka panjang yang dapat diandalkan untuk menyimpan sejumlah besar data historis yang jarang diperlukan, tetapi dapat diperoleh jika perlu. Namun demikian, demi kelengkapan, kami akan mengujinya. Tetapi, seperti yang saya katakan sebelumnya, tidak ada keinginan untuk secara aktif menulis ulang kode untuk solusi DB yang dipilih, jadi kami akan mengujinya agak terbatas - tanpa mengadaptasi struktur database dengan spesifikasi Cassandra.

Prometheus

Yah, dan karena ketertarikan, kami memutuskan untuk menguji kinerja toko Prometheus - hanya untuk memahami apakah kami lebih cepat daripada solusi saat ini atau lebih lambat dan berapa banyak.

Metodologi dan Hasil Uji

Jadi, kami menguji 5 database dalam 6 konfigurasi berikut: ClickHouse (1 node), ClickHouse (tabel terdistribusi dari 3 node), InfluxDB, Mysql 8, Cassandra (3 node) dan Prometheus. Rencana pengujian adalah sebagai berikut:

1. isi data historis untuk minggu ini (840 juta nilai per hari; 208 ribu metrik);
2. menghasilkan beban perekaman (6 mode muatan dipertimbangkan, lihat di bawah);
3. bersamaan dengan rekaman, kami membuat sampel secara berkala, meniru permintaan pengguna yang bekerja dengan grafik. Agar tidak terlalu menyulitkan hal-hal, kami memilih data dengan 10 metrik (sama banyak dari mereka pada grafik CPU) per minggu.

Kami memuat dengan meniru perilaku agen pemantauan kami, yang mengirimkan nilai ke setiap metrik setiap 15 detik. Dalam hal ini, kami tertarik untuk memvariasikan:

• jumlah total metrik ke mana data ditulis;
• interval pengiriman nilai dalam satu metrik;
• ukuran batch.

Tentang ukuran bets. Karena hampir semua basis eksperimental kami tidak disarankan untuk dimuat dengan sisipan tunggal, kami akan memerlukan relay, yang mengumpulkan metrik masuk dan mengelompokkannya sebanyak mungkin dan menulisnya ke pangkalan dengan memasukkan paket.

Juga, untuk lebih memahami bagaimana menafsirkan data yang diterima nanti, bayangkan bahwa kita tidak hanya mengirim banyak metrik, tetapi metrik tersebut disusun ke dalam server - 125 metrik per server. Di sini, server hanyalah entitas virtual - hanya untuk memahami bahwa, misalnya, 10.000 metrik sesuai dengan sekitar 80 server.

Jadi, dengan mempertimbangkan semua ini, 6 mode beban perekaman pangkalan kami:



Ada dua poin. Pertama, untuk cassandra ukuran batch seperti itu ternyata terlalu besar, di sana kami menggunakan nilai 50 atau 100. Dan kedua, karena prometeus bekerja secara ketat dalam mode tarik, mis. dia berjalan dan mengumpulkan data dari sumber metrik (dan bahkan pushgateway, meskipun namanya, tidak secara fundamental mengubah situasi), beban terkait diimplementasikan menggunakan kombinasi konfigurasi statis.

Hasil tes adalah sebagai berikut:







Yang perlu diperhatikan : sampel cepat luar biasa dari Prometheus, sampel sangat lambat dari Cassandra, sampel lambat yang tidak dapat diterima dari InfluxDB; ClickHouse menang dalam hal kecepatan perekaman, dan Prometheus tidak berpartisipasi dalam kompetisi, karena ia memasukkan dalam dirinya sendiri dan kami tidak mengukur apa pun.

Hasilnya : ClickHouse dan InfluxDB menunjukkan diri mereka yang terbaik dari semuanya, tetapi sebuah cluster dari Influx hanya dapat dibangun berdasarkan versi Enterprise, yang membutuhkan biaya, dan ClickHouse tidak memerlukan biaya apa pun dan dibuat di Rusia. Adalah logis bahwa di AS pilihannya mungkin mendukung inInfluxDB, dan dalam kasus kami mendukung ClickHouse.