🤘🏾 ✋🏾 🌋 Basis data di platform IIoT: bagaimana Mail.ru Cloud Solutions bekerja dengan petabyte data dari banyak perangkat 💵 🍌 🌘

Hai, saya Andrey Sergeev, kepala kelompok pengembangan solusi IoT di Mail.ru Cloud Solutions . Diketahui bahwa basis data universal tidak ada. Terutama ketika Anda perlu membangun platform hal-hal Internet yang mampu memproses jutaan peristiwa dari sensor per detik dalam mode waktu nyata dekat. Platform

produk Mail.ru IoT kami dimulai dengan prototipe yang didasarkan pada Tarantool. Saya akan memberi tahu Anda ke mana kami pergi, masalah apa yang kami temui dan bagaimana kami menyelesaikannya. Dan juga menunjukkan arsitektur saat ini platform modern industri Internet hal. Dalam artikel ini kita akan berbicara:

tentang persyaratan basis data kami, solusi universal dan CAP-teorema;
apakah database + server aplikasi dalam satu pendekatan adalah peluru perak;
tentang evolusi platform dan database yang digunakan di dalamnya;
, Tarantool’ .

, @Databases Meetup by Mail.ru Cloud Solutions. , :

Mail.ru IoT Platform

Produk kami, Mail.ru IoT Platform, adalah platform yang dapat diskalakan dan independen perangkat keras untuk membangun solusi untuk hal-hal Internet industri. Ini memungkinkan Anda untuk mengumpulkan data dari ratusan ribu perangkat secara bersamaan dan memproses aliran ini dalam mode waktu nyata dekat (mis. Waktu semu waktu nyata), termasuk menggunakan aturan khusus - skrip dalam Python atau Lua.

Platform dapat menyimpan data mentah dalam jumlah tak terbatas dari sumber, ada satu set komponen siap pakai untuk memvisualisasikan dan menganalisis data, alat bawaan untuk analitik prediktif dan membuat aplikasi berdasarkan platform.

Beginilah tampilan perangkat Platform IoT Mail.ru.

Saat ini, platform tersedia untuk dipasang sesuai dengan model on-premise di fasilitas pelanggan, tahun ini direncanakan untuk merilis platform sebagai layanan di cloud publik.

Prototipe Tarantool: bagaimana semuanya dimulai

Platform kami dimulai sebagai proyek percontohan - prototipe dengan satu contoh Tarantool, fungsi utamanya adalah untuk menerima aliran data dari server OPC, memproses peristiwa yang diterima menggunakan skrip Lua secara real time, memantau indikator kunci berdasarkan pada mereka, dan menghasilkan peristiwa dan peringatan di sistem yang unggul.

Skema prototipe Tarantool Prototipe

ini bahkan bekerja dalam kondisi pertempuran selama beberapa bulan di lokasi gugusan, itu adalah platform untuk produksi minyak di laut lepas, di Irak, di Teluk Persia. Dia memantau indikator utama dan menyediakan data untuk sistem visualisasi dan log peristiwa. Pilot diakui sebagai sukses, tetapi seperti yang sering terjadi dengan prototipe - itu tidak melampaui pilot dan prototipe ditahan untuk waktu yang lama sampai jatuh ke tangan kami.

Tujuan kami dalam mengembangkan platform IoT

Bersama dengan prototipe, kami mendapat tugas - untuk membuat platform IoT yang lengkap, dapat diskalakan dan toleran terhadap kesalahan, yang nantinya dapat diluncurkan sebagai layanan di cloud publik.

Kami perlu membangun platform dengan pengantar berikut:

Hubungkan ratusan ribu perangkat secara bersamaan.
Terima jutaan acara per detik.
Pemrosesan aliran dalam mode real-time dekat.
Penyimpanan data mentah selama beberapa tahun.
Alat untuk analisis streaming dan analisis historis.
Dukungan penyebaran di beberapa pusat data untuk pemulihan bencana maksimum.

Pro dan kontra dari prototipe platform

Pada saat dimulainya pengembangan aktif, prototipe tampak sebagai berikut:

Tarantool, yang digunakan sebagai database + server aplikasi (Server Aplikasi);
semua data disimpan dalam memori Tarantool;
aplikasi pada Lua di Tarantool yang sama, yang melakukan fungsi menerima data, memprosesnya dan memanggil skrip pengguna pada data yang masuk.

Pendekatan untuk membangun aplikasi ini memiliki kelebihan :

Kode dan data berada di satu tempat, yang memungkinkan Anda untuk beroperasi pada data secara langsung di memori aplikasi dan menghilangkan biaya overhead dari kunjungan jaringan yang khas untuk aplikasi tradisional.
Tarantool menggunakan JIT (Just in Time Compiler) untuk Lua, yang pada waktu kompilasi mengkompilasi kode Lua ke dalam kode mesin, yang memungkinkan skrip Lua sederhana untuk dijalankan pada kecepatan yang sebanding dengan kode C (40.000 RPS dari satu inti - dan ini bukan batasnya !).
Tarantool didasarkan pada multitasking kooperatif, yaitu, setiap panggilan ke prosedur tersimpan diluncurkan dalam seratnya sendiri, analog coroutine, yang memberikan dorongan lebih besar dalam kinerja dalam tugas-tugas dengan operasi I / O, misalnya, kunjungan jaringan.
Penggunaan sumber daya yang efisien - beberapa alat dapat menangani 40.000 permintaan per detik dari satu inti CPU.

Tetapi ada kerugian signifikan :

Kami perlu menyimpan data mentah dari perangkat selama beberapa tahun, tetapi kami tidak memiliki ratusan petabyte memori untuk Tarantool.
Konsekuensi langsung dari nilai tambah pertama: seluruh kode platform kami adalah prosedur tersimpan dalam database, yang berarti setiap pembaruan pada basis kode platform adalah pembaruan database, yang sangat menyakitkan.
, . , Tarantool 24-32 (Tarantool ) . — Tarantool, .
. - , Tarantool Lua , - , LuaJIT .

Kesimpulan: Tarantool adalah pilihan yang baik untuk membuat MVP, tetapi untuk platform IoT yang lengkap, scalable, mudah didukung, dan toleran terhadap kesalahan yang dapat menerima, memproses, dan menyimpan data dari ratusan ribu perangkat, itu tidak cocok.

Rasa sakit utama dari prototipe yang ingin kita singkirkan

Pertama-tama, kami ingin menyembuhkan dua rasa sakit dari prototipe kami:

Dapatkan jauh dari konsep layanan database + aplikasi. Kami ingin memperbarui kode aplikasi terlepas dari penyimpanan data.
Sederhanakan penskalaan dinamis di bawah pemuatan. Saya ingin mendapatkan penskalaan horizontal independen yang independen dari banyak fungsi sebanyak mungkin.

Untuk mengatasi masalah ini, kami memilih pendekatan inovatif dan belum teruji: arsitektur layanan mikro dan pemisahan layanan ke dalam stateless - aplikasi dan database Stateful -.

Untuk lebih memudahkan operasi dan penskalaan horizontal layanan Stateless, kami mengemasnya dan mengadopsi Kubernetes.

Kami menemukan layanan Stateless, masih harus memutuskan apa yang harus dilakukan dengan data.

Persyaratan basis data dasar untuk platform IoT

Awalnya, kami tidak ingin memagari taman dan ingin menyimpan semua data platform dalam satu basis data universal. Setelah menganalisis sasaran, kami sampai pada daftar persyaratan untuk basis data universal berikut:

ACID- — , .
— .
— , near real-time.
— - .
— , .
— ( !), .
— , ( !).
SQL — .

CAP-

Sebelum mulai memilah-milah semua database yang ada di pasar untuk kepatuhan dengan persyaratan kami, kami memutuskan untuk memvalidasi persyaratan kami untuk kewarasan menggunakan alat yang cukup terkenal - CAP-teorema.

Teorema CAP mengatakan bahwa sistem terdistribusi dapat memiliki maksimum dua dari tiga properti berikut:

Konsistensi (konsistensi data) - di semua node komputasi pada satu titik waktu, data tidak saling bertentangan.
Ketersediaan - setiap permintaan ke sistem terdistribusi berakhir dengan respons yang benar, tetapi tanpa jaminan bahwa jawaban semua node dalam sistem sesuai.
Toleransi partisi - bahkan jika tidak ada koneksi antara node, mereka terus bekerja secara independen satu sama lain.

Sebagai contoh, sistem CA klasik adalah klaster Master-Slave PostgreSQL dengan replikasi sinkron, dan sistem AP klasik adalah Cassandra.

Mari kita kembali ke persyaratan kita dan mengklasifikasikannya menggunakan teorema CAP:

Transaksi ACID dan konsistensi yang ketat (atau setidaknya tidak konsisten pada akhirnya) adalah C.
Penskalaan horizontal untuk menulis dan membaca plus ketersediaan tinggi adalah A (multi-master).
Toleransi kesalahan adalah P, ketika satu pusat data jatuh, platform seharusnya tidak mati.

Kesimpulan : database universal yang kita butuhkan harus memiliki ketiga properti dari teorema CAP, yang berarti bahwa tidak ada database universal untuk semua persyaratan kita.

Memilih database untuk data yang digunakan platform IoT

Jika Anda tidak dapat memilih basis data universal, kami memutuskan untuk memilih jenis data yang akan digunakan platform dan memilih basis data untuk masing-masing jenis.

Pada perkiraan pertama, kami membagi data menjadi dua jenis:

Meta - informasi adalah model dunia, perangkat, pengaturan, aturan, hampir semua data, kecuali yang mengirimkan perangkat akhir.
Data mentah dari perangkat - pembacaan sensor, telemetri, dan informasi layanan dari perangkat. Bahkan, ini adalah deret waktu, di mana setiap pesan berisi nilai dan stempel waktu.

Memilih Database untuk Metadata

Persyaratan basis data untuk metadata . Metadata secara inheren bersifat relasional. Mereka dicirikan oleh sejumlah kecil, mereka jarang dimodifikasi, tetapi mereka adalah data penting, mereka tidak dapat hilang, oleh karena itu konsistensi adalah penting bahkan dalam kerangka replikasi asinkron, serta transaksi ACID dan pembacaan skala horizontal.

Ada data yang relatif sedikit dan mereka akan relatif jarang berubah, sehingga Anda dapat mengorbankan penskalaan horizontal ke rekaman, serta kemungkinan tidak dapat diaksesnya database rekaman jika terjadi kecelakaan. Artinya, dalam hal teorema CAP, kita membutuhkan sistem CA.

Yang cocok dalam kasus biasa . Dengan pernyataan masalah seperti itu, setiap basis data relasional klasik dengan dukungan untuk cluster dengan replikasi asinkron seperti PostgreSQL atau MySQL akan sangat cocok untuk kita.

Fitur platform kami . Kami juga membutuhkan dukungan untuk pohon dengan persyaratan khusus. Sebagai bagian dari prototipe, ada fitur dari sistem kelas BDVV (real-time database) - memodelkan dunia menggunakan tag tree. Mereka memungkinkan Anda untuk menggabungkan semua perangkat klien dalam satu struktur pohon, yang memfasilitasi pengelolaan sejumlah besar perangkat dan tampilan mereka.

Beginilah tampilan perangkat dalam bentuk struktur pohon.

Pohon tersebut memungkinkan Anda untuk menghubungkan perangkat akhir dengan lingkungan, misalnya, Anda dapat menempatkan perangkat yang secara fisik terletak di satu ruangan dalam satu subtree, yang sangat memudahkan pekerjaan dengan mereka di masa depan. Ini adalah fungsi yang nyaman, selain itu, lebih lanjut kami ingin bekerja di ceruk sistem detonator udara, dan di sana keberadaan fungsi tersebut sebenarnya adalah standar industri.

Untuk implementasi penuh tag tree, database potensial harus memenuhi persyaratan berikut:

Dukungan untuk pohon dengan lebar dan kedalaman sewenang-wenang.
Modifikasi elemen pohon dalam transaksi ACID.
Performa tinggi saat melintasi pohon.

Database relasional klasik dapat menangani pohon kecil dengan cukup baik, tetapi mereka tidak melakukannya dengan baik dengan pohon sewenang-wenang.

Kemungkinan Solusi. Gunakan dua database - database grafik untuk menyimpan pohon dan database relasional untuk menyimpan sisa informasi meta.

Pendekatan ini memiliki beberapa kelemahan besar sekaligus:

Untuk memastikan konsistensi antara dua database, Anda perlu menambahkan koordinator transaksi eksternal.
Desain ini sulit dipertahankan dan tidak terlalu dapat diandalkan.
Pada output kami mendapatkan dua database, bukan satu, sedangkan database grafik hanya diperlukan untuk mendukung fungsi terbatas.

Solusi yang mungkin tetapi tidak terlalu baik dengan dua basis data

Solusi kami untuk menyimpan metadata . Kami juga berpikir dan mengingat bahwa awalnya fungsi ini diimplementasikan dalam prototipe berdasarkan Tarantool dan ternyata sangat baik.

Sebelum melanjutkan, saya ingin memberikan definisi Tarantool yang tidak standar: Tarantool bukan basis data, tetapi sekumpulan primitif untuk membangun basis data untuk kasus spesifik Anda.

Primitif yang tersedia di luar kotak:

Space - analog dari tabel dalam database untuk menyimpan data.
Transaksi ASAM penuh.
Replikasi tidak sinkron menggunakan log WAL.
Alat beling yang mendukung penguraian ulang otomatis.
Superfast LuaJIT untuk prosedur tersimpan.
Perpustakaan standar besar.
Manajer paket LuaRocks dengan paket lebih banyak lagi.

Solusi CA kami adalah basis data + grafik relasional berdasarkan Tarantool. Kami telah mengumpulkan repositori informasi meta mimpi berdasarkan pada primitif Tarantool:

Ruang untuk penyimpanan data.
Transaksi ACID - tersedia.
Replikasi asinkron - tersedia.
Hubungan - dilakukan pada prosedur tersimpan.
Pohon - juga dibuat berdasarkan prosedur yang tersimpan.

Instalasi cluster yang kami miliki adalah klasik untuk sistem seperti itu - satu Master untuk menulis dan beberapa Slive dengan replikasi asinkron untuk penskalaan untuk membaca.

Hasilnya: hibrida cepat dan terukur dari basis data relasional dan grafik. Sebuah instance Tarantool tunggal mampu menangani ribuan permintaan baca, termasuk yang dengan traversal pohon aktif.

Memilih database untuk data dari perangkat

Persyaratan basis data untuk data dari perangkat . Data ini ditandai dengan seringnya merekam dan sejumlah besar data: jutaan perangkat, beberapa tahun penyimpanan, petabyte informasi dari pesan yang masuk dan data yang disimpan. Ketersediaan tinggi mereka penting, karena pembacaan sensor yang terutama beroperasi pada aturan pengguna dan layanan internal kami.

Untuk database, penskalaan horizontal untuk membaca dan menulis, ketersediaan dan toleransi kesalahan, serta ketersediaan alat analitik siap pakai untuk bekerja dengan susunan data ini, lebih disukai berdasarkan SQL, adalah penting. Pada saat yang sama, kita dapat mengorbankan konsistensi dan transaksi ACID.

Artinya, dalam kerangka teorema CAP, kita membutuhkan sistem AP.

Persyaratan tambahan. Kami memiliki beberapa persyaratan tambahan untuk memutuskan di mana jumlah data raksasa akan disimpan:

Time Series - data dari sensor adalah time series, saya ingin mendapatkan basis khusus.
Open source - kelebihan kode sumber terbuka tidak perlu komentar.
Cluster gratis adalah momok umum di antara database bermodel.
Kompresi yang baik - mengingat jumlah data dan secara umum keseragamannya, saya ingin mengompres data yang disimpan secara efisien.
Operasi yang sukses - kami ingin memulai pada basis data bahwa seseorang telah secara aktif mengeksploitasi dekat dengan beban kami untuk meminimalkan risiko.

Keputusan kami . ClickHouse secara eksklusif sesuai dengan persyaratan kami - basis data seri waktu berbasis kolom dengan replikasi, multimaster, sharding, dukungan SQL, dan cluster gratis. Selain itu, Mail.ru memiliki pengalaman sukses bertahun-tahun dalam mengoperasikan salah satu kluster ClickHouse terbesar dalam volume penyimpanan.

Tetapi tidak peduli seberapa bagus ClickHouse, dan kami memiliki masalah dengannya.

Basis data masalah untuk perangkat ini dan solusinya

Masalah dengan kinerja menulis. Segera ada masalah dengan kinerja penulisan aliran data yang besar. Mereka perlu dibawa ke database analitik secepat mungkin sehingga aturan yang menganalisis aliran peristiwa secara real time dapat melihat riwayat perangkat tertentu dan memutuskan apakah akan meningkatkan peringatan atau tidak.

Solusi untuk masalah tersebut . ClickHouse tidak mentoleransi beberapa sisipan tunggal (menyisipkan), tetapi bekerja dengan baik dengan batch besar (batch) data - ia dengan mudah mengatasi dengan batch rekaman pada jutaan baris. Kami memutuskan untuk melakukan buffer aliran data yang masuk, dan kemudian menempelkan data ini dalam batch.

Jadi kami mengatasi dengan kinerja perekaman yang buruk. Masalah perekaman

diselesaikan, tetapi kami mengalami penundaan yang signifikan beberapa detik antara data yang memasuki sistem dan penampilannya di basis data kami.

Dan ini sangat penting untuk berbagai algoritma yang merespon data dari sensor secara real time.

Baca masalah kinerja. Analitik aliran untuk pemrosesan data real-time selalu membutuhkan informasi dari database - ini adalah puluhan ribu pertanyaan kecil. Rata-rata, satu simpul ClickHouse menampung sekitar seratus permintaan analitik pada saat yang sama, itu dibuat untuk permintaan analitik berat yang jarang terjadi untuk memproses sejumlah besar data. Tentu saja, ini tidak cocok untuk menghitung tren dalam aliran data dari ratusan ribu sensor.

Dengan sejumlah besar pertanyaan menjalankan

solusi buruk ClickHouse untuk masalah ini . Kami memutuskan untuk meletakkan cache di depan ClickHouse, yang akan berisi data panas paling banyak diminta selama 24 jam terakhir.

Data selama 24 jam terakhir bukan data selama satu tahun, tetapi juga jumlah data yang cukup signifikan, oleh karena itu, kami juga membutuhkan sistem AP dengan penskalaan horizontal untuk membaca dan menulis, tetapi dengan fokus pada kinerja baik untuk merekam acara tunggal dan untuk banyak bacaan. Ini juga membutuhkan ketersediaan tinggi, analisis deret waktu, ketekunan, dan TTL bawaan.

Pada akhirnya, kami membutuhkan ClickHouse cepat, yang bahkan dapat menyimpan semuanya dalam memori untuk kecepatan. Kami tidak menemukan solusi yang cocok di pasar, jadi kami memutuskan untuk membangunnya berdasarkan primitif Tarantool:

Kegigihan - adalah (WAL-log + snapshots).
Kinerja - ada, semua data dalam memori.
Penskalaan - ada replikasi + sharding.
Ketersediaan tinggi - ada.
Alat analisis deret waktu (pengelompokan, agregasi, dll.) - dibuat berdasarkan prosedur yang tersimpan.
TTL - dibuat berdasarkan prosedur tersimpan dengan satu serat latar belakang (coroutine).

Itu ternyata menjadi solusi yang nyaman dan produktif - satu contoh menampung 10.000 RPC untuk dibaca, termasuk pertanyaan analitis hingga puluhan ribu pertanyaan.

Berikut adalah arsitektur yang dihasilkan:

Arsitektur akhir: ClickHouse sebagai basis data analitik dan cache Tarantool yang menyimpan data dalam 24 jam

Jenis data baru - status dan penyimpanannya

Kami memilih basis data khusus untuk semua data, tetapi platform dikembangkan dan tipe data baru muncul - status. Status tersebut berisi keadaan terkini perangkat dan sensor, serta berbagai variabel global untuk aturan analitik aliran.

Misalnya, ada bola lampu di dalam ruangan. Ini bisa dimatikan dan dihidupkan, dan Anda harus selalu memiliki akses ke kondisi saat ini, termasuk dalam aturan. Contoh lain adalah variabel dalam aturan aliran, misalnya, semacam penghitung. Jenis data ini ditandai oleh kebutuhan untuk sering merekam dan akses cepat, tetapi pada saat yang sama data itu sendiri menempati jumlah yang relatif kecil.

Repositori meta-informasi kurang cocok untuk tipe data ini, karena negara dapat sering berubah, dan dalam kasus kami plafon rekaman terbatas pada satu Master. Penyimpanan jangka panjang dan operasional juga tidak cocok, karena keadaan kita terakhir berubah tiga tahun yang lalu, dan penting bagi kita untuk memiliki akses baca cepat.

Yaitu, untuk basis data di mana status disimpan, penskalaan horizontal untuk membaca dan menulis, ketersediaan tinggi dan toleransi kesalahan adalah penting, sementara konsistensi diperlukan pada tingkat nilai / dokumen. Anda dapat memanfaatkan konsistensi keseluruhan dan transaksi ACID.

Solusi yang cocok dapat berupa Nilai Kunci atau basis data dokumen: cluster Redis yang diarsir, MongoDB, atau lagi Tarantool.

Tarantool Pro:

Ini adalah cara paling populer untuk menggunakan Tarantool.
Penskalaan horizontal - ada replikasi asinkron + sharding.
Konsistensi di tingkat dokumen - adalah.

Akibatnya, kami sekarang memiliki tiga Tarantool yang kami gunakan untuk kasus yang sangat berbeda: menyimpan informasi meta, cache untuk membaca data dengan cepat dari perangkat dan menyimpan data status.

Bagaimana memilih basis data untuk platform IoT

Database universal tidak ada.
Setiap jenis data memiliki database sendiri yang paling cocok untuknya.
Terkadang database yang Anda butuhkan mungkin tidak tersedia di pasar.
Tarantool cocok sebagai basis untuk basis data khusus.

Pembicaraan ini pertama kali dilakukan di @Databases Meetup oleh Mail.ru Cloud Solutions. Tonton video pertunjukan lainnya dan daftar untuk pengumuman acara Telegram Around Kubernetes di Mail.ru Group .

Apa lagi yang harus dibaca :

Basis data di platform IIoT: bagaimana Mail.ru Cloud Solutions bekerja dengan petabyte data dari banyak perangkat