Quale database back-end è adatto per l'implementazione IoT

Devo fornire il servizio IoT per il mio cliente. I componenti MQTT, Kafka e Rest Services verranno utilizzati per inserire i dati dai dispositivi nel database. Ho bisogno di fare un po 'di analisi sui dati nel backend. La dimensione dei dati sarebbe 135 byte / dispositivo e 6000 dispositivo / secondo. Ho condiviso l'architettura qui per comprendere i requisiti e i componenti.

Ho studiato gli archivi di dati (MongoDB, Postgresql (TimescaleDB), Redis, Neo4j, Cassandra) e tutti i fornitori hanno dimostrato che il loro database è adatto al caso d'uso dell'IoT. Mi sono confuso sull'uso del database comprovato / più affidabile / scalabile per l'IoT.

Quale potrebbe essere il database più adatto per ingerire così tanti dati e fare analisi?

Esiste un benchmark provato per il database adatto per l'IoT?

Per favore, dai i tuoi pensieri e suggerimenti.

Sei limitato a entrambi i database NoSQL, perché qualsiasi database SQL non ti consentirà TPS 6K direttamente sul server né puoi utilizzare alcun servizio cloud SaaS o piattaforma già specializzata in questo tipo di operazioni, ad esempio ricevere dati telematici tramite MQTT / Kafka, suddividerlo e archiviarlo per questi 6000 dispositivi e fornire una semplice API REST per accedere ai dati di telemetria. Come flespi o simili.

L'IoT è praticamente una serie temporale. Ci sono alcuni TSDB là fuori: InfluxDB, OpenTSDB, GridDB, ecc. Hanno tutti la versione community / oss in modo da poter vedere se si adatta alle tue necessità. InfluxDB è popolare ma nota che il clustering è disponibile solo per la versione a pagamento. OpenTSD è puro oss e GridDB afferma che è orientato all'IoT e più veloce di InfluxDB. A seconda delle tue esigenze, forse vuoi cercarne uno che abbia ingerito rapidamente.

Timescaledb, un'estensione postgres personalizzata per i set di dati della serie temporale funziona davvero bene. E ottieni le solite funzionalità del database relazionale, uso di SQL, affidabilità, indici, scalabilità.

La domanda è ampia e non è possibile dare una risposta precisa, ma questi collegamenti possono aiutare:

http://outlyer.com/blog/top10-open-source-time-series-databases/

Follow-up con benchmark: http://outlyer.com/blog/time-series-database-benchmarks/

Altro confronto: https://gist.github.com/sacreman/00a85cf09251147175241d334aafa798

Ho impostato alcune regole per tentare di limitare l'ambito altrimenti questo blog non finirebbe mai.

Sono stati confrontati solo i database di serie storiche liberi e open source e le loro funzionalità. Pertanto qualcuno chiede "hai provato Kdb + e Informix?" La risposta sarà no. Probabilmente sono comunque fantastici.

L'elenco includerà solo database che si classificano nel loro materiale di marketing come serie temporali o che sono stati scritti in un blog da una società interessante come qualcosa che stanno utilizzando per i dati delle serie temporali.

Ciò che è stato fatto è leggere i documenti ufficiali, leggere StackOverflow, esaminare i problemi e il codice di Github e generalmente hackerare le informazioni insieme. Con questo in mente alcuni fatti potrebbero essere errati.

Se qualcuno rileva qualcosa di effettivamente sbagliato, per favore fatemelo sapere e aggiornerò il blog.

Il benchmarking si è basato su dichiarazioni e stime di marketing. Perché? Perché il benchmarking è un grosso pezzo di lavoro e soggetto a errori. Ottieni sempre "dovresti aver sintonizzato questa speciale impostazione non documentata". I numeri elencati sono molto favorevoli alla maggior parte dei database. Sono i numeri di cui sono stati bloggati o rivendicati su Twitter in qualche momento in passato. Se ritieni che i numeri siano errati fammi sapere e li aggiornerò.

Oltre alle risposte precedenti, consiglio anche di guardare Tarantool , ClickHouse e ScyllaDB . Queste soluzioni sono più che sufficienti per la maggior parte dei casi.

Tranne che in alcune situazioni, specialmente per l'incorporamento, l' MDBX (o qualcosa del genere) può essere utile.