Qual banco de dados back-end é adequado para a implementação da IoT

15

Eu tenho que fornecer o serviço de IoT para meu cliente. Os componentes MQTT, Kafka e Rest Services serão usados ​​para ingerir os dados dos dispositivos no banco de dados. Eu preciso fazer algumas análises sobre os dados no back-end. O tamanho dos dados seria 135 bytes / dispositivo e 6000 dispositivos / segundo. Compartilhei a arquitetura aqui para entender os requisitos e os componentes.

insira a descrição da imagem aqui

Investiguei sobre os armazenamentos de dados (MongoDB, Postgresql (TimescaleDB), Redis, Neo4j, Cassandra) e todos os fornecedores provaram que seu banco de dados é adequado para o caso de uso da IoT. Confuso quanto ao uso do banco de dados comprovado / mais confiável / escalonável para a IoT.

Qual poderia ser o melhor banco de dados adequado para ingerir essa quantidade de dados e fazer análises?

Existe alguma referência comprovada para o banco de dados adequado para a IoT?

Por favor, dê seus pensamentos e sugestões.

sensors system-architecture data-transfer Mourish Khan
fonte
Eu usei o ElasticSearch para um caso de uso semelhante recentemente. Mas não posso dizer por que é melhor que outros, essa parte é baseada principalmente em opiniões. Eu literalmente usei o Kafka para conectar sensores ao DB. Há bons bibliotecas que o processamento de fluxo de suporte de Kafka com ElasticSearch
atakanyenel
2
O "caso de uso da IoT" é amplo demais para classificar as implementações. Cada um tem seus pontos fortes e fracos.
Gilles 'SO- stop be evil'
11
Não é o meu campo, mas ficaria surpreso se algum banco de dados moderno pareceria um ajuste ruim aqui. Use o que você está familiarizado ou possui as ferramentas mais brilhantes.
Sean Houlihane

Respostas:

4

Você está limitado aos bancos de dados NoSQL, porque qualquer banco de dados SQL não permitirá 6K TPS diretamente no servidor, nem poderá usar qualquer serviço ou plataforma em nuvem SaaS já especializado em esse tipo de operações - por exemplo, receber dados telemáticos via MQTT / Kafka, divida e armazene esses dispositivos 6000 e forneça uma API REST simples para acessar os dados de telemetria. Como flespi ou algo parecido.

shal
fonte
entendi seu ponto e obrigado. Você poderia me dizer qual banco de dados NoSQL é o mais adequado para o meu caso de uso?
Mourish Khan
Realmente depende da sua experiência e ambiente de tempo de execução. Para o AWS / GoogleCloud, será uma opção; para a instalação local, eu recomendaria ao LevelDB ou a qualquer um de seus concorrentes, basta pesquisar no levelDB no google e você verá uma lista completa deles. Em qualquer variante, você precisará implementar a API intermediária entre o aplicativo da Web e o banco de dados, portanto, isso também depende do tipo de back-end que você está usando para isso. Exatamente o seu caso descrito neste artigo , quando você preenche dados com o mqtt e os acessa e histórico da web.
shal
11
Aliás, tentei nos últimos 15 anos muitos desses bancos de dados NoSQL. Iniciado no Berkeley DB em tenra idade. No final, quando você precisa de potência e desempenho totais em seus aplicativos e tenta extrair o máximo de IOPs e taxa de transferência do banco de dados, não encontro outra maneira, a não ser desenvolver o próprio mecanismo de banco de dados, direcionado especificamente aos casos de uso e requisitos de telemática (IoT). Mas foi a minha experiência +)
shal
"6K TPS" ?? 6tB / segundo?
Mawg diz que restabelece Monica em 29/04/19
6.000 transações / segundo
shal
4

A Internet das coisas é praticamente uma série de dados temporais. Existem alguns TSDB por aí: InfluxDB, OpenTSDB, GridDB, etc. Todos eles têm a versão community / oss para que você possa ver se ele atende às suas necessidades. O InfluxDB é popular, mas observe que o armazenamento em cluster está disponível apenas para a versão paga. O OpenTSD é um sistema operacional puro e o GridDB afirma que é orientado à IoT e mais rápido que o InfluxDB. Dependendo das suas necessidades, talvez você queira procurar um que tenha uma ingestão rápida.

Codelicious
fonte
2

Timescaledb, uma extensão do postgres personalizada para conjuntos de dados de séries temporais funciona muito bem. E você obtém os recursos usuais do banco de dados relacional, uso de SQL, confiabilidade, índices e escalabilidade.

IOTdev
fonte
1

A pergunta é ampla e nenhuma resposta precisa pode ser dada, mas esses links podem ajudar:

http://outlyer.com/blog/top10-open-source-time-series-databases/ insira a descrição da imagem aqui

Acompanhamento com benchmarks: http://outlyer.com/blog/time-series-database-benchmarks/

Outra comparação: https://gist.github.com/sacreman/00a85cf09251147175241d334aafa798

Estabeleci algumas regras para tentar limitar o escopo, caso contrário, este blog nunca terminaria.

Apenas bancos de dados de séries temporais de código aberto e gratuitos e seus recursos foram comparados. Portanto, alguém pergunta "você já tentou o Kdb + e o Informix?", A resposta será não. Eles são provavelmente incríveis embora.

A lista incluirá apenas bancos de dados que se classificam em seu material de marketing como séries temporais ou que foram escritos em um blog por uma empresa legal como algo que eles estão usando para dados de séries temporais.

O que foi feito é ler os documentos oficiais, ler StackOverflow, examinar os problemas e códigos do Github e, geralmente, invadir as informações. Com isso em mente, alguns fatos podem estar incorretos.

Se alguém encontrar algo de fato errado, avise-me e atualizarei o blog.

O benchmarking foi baseado em reivindicações e estimativas de marketing. Por quê? Porque o benchmarking é um pedaço considerável de trabalho e propenso a erros. Você sempre obtém “você deveria ter ajustado essa configuração especial não documentada”. Os números listados são altamente favoráveis ​​para a maioria dos bancos de dados. Eles são os números publicados no blog ou reivindicados no Twitter em algum momento no passado. Se você achar que algum número está errado, avise-me e eu o atualizarei.

FarO
fonte
0

Além das respostas anteriores, também recomendo consultar o Tarantool , ClickHouse e ScyllaDB . Essas soluções são mais que suficientes para a maioria dos casos.

Exceto que, em algumas situações, especialmente para incorporação, o MDBX (ou algo parecido) pode ser útil.

Leo Yuriev
fonte
2
Gostaria de explicar por que você recomenda isso?
Helmar