IoT uygulaması için hangi arka uç veritabanı uygundur


15

Müşterim için IoT hizmetini sunmam gerekiyor. Verileri cihazlardan veritabanına almak için MQTT, Kafka ve Rest Services bileşenleri kullanılacaktır. Arka uçtaki veriler üzerinde bazı analizler yapmam gerekiyor. Veri boyutu 135 bayt / cihaz ve 6000 cihaz / saniye olacaktır. Gereksinimi ve bileşenleri anlamak için mimariyi burada paylaştım.

resim açıklamasını buraya girin

Veri depoları (MongoDB, Postgresql (TimescaleDB), Redis, Neo4j, Cassandra) hakkında araştırma yaptım ve her satıcı, veritabanlarının IoT kullanım durumu için uygun olduğunu kanıtladı. IoT için kanıtlanmış / en güvenilir / ölçeklenebilir veritabanını kullanma konusunda kafam karıştı.

Bu kadar veriyi almak ve analitiği yapmak için en uygun veritabanı ne olabilir?

IoT için uygun veritabanı için kanıtlanmış bir karşılaştırma ölçütü var mı?

Lütfen düşüncelerinizi ve önerilerinizi belirtin.


ElastikSearch'ü son zamanlarda benzer bir kullanım durumu için kullandım. Ama neden diğerlerinden daha iyi olduğunu söyleyemem, bu kısım çoğunlukla fikir tabanlıdır. Kafka'yı sensörleri DB'ye bağlamak için kullandım.
Elasticsearch

2
“IoT kullanım örneği” uygulamaları sıralamak için çok geniş. Her birinin güçlü ve zayıf yanları vardır.
Gilles 'SO- kötü olmayı kes'

1
Benim alanım değil, ama eğer herhangi bir modern db burada kötü bir uyum gibi görünüyorsa şaşırırdım. Bildiklerinizi kullanın veya en parlak takımlara sahip olun.
Sean Houlihane

Yanıtlar:


4

Herhangi bir SQL veritabanı doğrudan sunucuda 6K TPS'ye izin vermediğinden veya bu tür işlemlerde zaten uzmanlaşmış herhangi bir SaaS bulut hizmetini veya platformunu kullanabileceğiniz için NoSQL veritabanlarıyla sınırlısınız - örneğin, MQTT / Kafka aracılığıyla telematik verileri almak, bölmek ve bu 6000 cihazlar için saklamak ve telemetri verilerine erişmek için basit REST API sağlar. Flespi veya benzeri şeyler gibi .


ne demek istediğini anladım ve teşekkürler. Kullanım durumum için hangi NoSQL veritabanının en uygun olduğunu söyleyebilir misiniz?
Mart'ta

Bu gerçekten deneyiminize ve çalışma ortamınıza bağlıdır. AWS / GoogleCloud için bir seçenek olacak, yerel kurulum için LevelDB'ye veya rakiplerinden herhangi birine tavsiye ederim, sadece google'da levelDB'yi arayın ve bunların tam listesini göreceksiniz. Herhangi bir varyantta web uygulaması ve veritabanı arasında ara API uygulamanız gerekir, bu nedenle bunun için ne tür bir arka uç kullandığınıza da bağlıdır. Mqtt ile veri doldurduğunuzda ve ona ve geçmişten web'den eriştiğinizde, tam olarak bu makalede açıklanan durumunuz .
Shal

1
btw, son 15 yılda bu NoSQL veritabanlarının çoğunu denedim. İlk yaşlarında Berkeley DB'den başladı. Sonunda, uygulamalarınızda tam güce ve performansa ihtiyaç duyduğunuzda ve veritabanı maksimum GİB'lerinden ve verimden sıkmaya çalıştığınızda başka bir yol bulamıyorum, ancak özellikle telematik (IoT) kullanım durumu ve gereksinimlerini hedefleyen kendi veritabanı motorunu geliştirmek için. Ama benim deneyim +)
Shal

"6K TPS" ?? 6tB / saniye?
Mawg, Monica'yı

6.000 adet / saniye
shal

4

IoT hemen hemen zaman serisi verileridir. Orada birkaç TSDB vardır: InfluxDB, OpenTSDB, GridDB, vs. Hepsi topluluk / oss sürümüne sahiptir, böylece ihtiyacınıza uygun olup olmadığını görebilirsiniz. InfluxDB popüler bir yöntemdir, ancak kümelemenin yalnızca ücretli sürüm için kullanılabildiğini unutmayın. OpenTSD saf oss ve GridDB, IoT odaklı ve InfluxDB'den daha hızlı olduğunu belirtir. İhtiyaçlarınıza bağlı olarak, belki de hızlı yutulan birini aramak istersiniz.


2

Zaman çizelgeleri veri kümeleri için özelleştirilmiş bir postgres uzantısı olan Timescaledb gerçekten iyi çalışıyor. Ve her zamanki ilişkisel veritabanı özelliklerini, SQL kullanımını, güvenilirliği, dizinleri, ölçeklenebilirliği elde edersiniz.


1

Soru geniştir ve doğru bir cevap verilemez, ancak bu bağlantılar yardımcı olabilir:

http://outlyer.com/blog/top10-open-source-time-series-databases/ resim açıklamasını buraya girin

Kıyaslamalarla takip: http://outlyer.com/blog/time-series-database-benchmarks/

Diğer karşılaştırma: https://gist.github.com/sacreman/00a85cf09251147175241d334aafa798

Kapsamı sınırlamak için bazı kurallar belirledim, aksi takdirde bu blog asla bitmeyecekti.

Sadece serbest ve açık kaynaklı zaman serileri veritabanları ve özellikleri karşılaştırılmıştır. Bu nedenle birisi “Kdb + ve Informix'i denediniz mi?” Diye sorar mı? Cevap hayır olacaktır. Ama muhtemelen harika.

Liste, yalnızca pazarlama materyallerinde kendilerini zaman serisi olarak sınıflandıran veya bir blogda serin bir şirket tarafından zaman serisi verileri için kullandıkları bir şey olarak yazılan veritabanlarını içerecektir.

Yapılmış olan, resmi belgeleri okumak, StackOverflow'u okumak, Github sorunlarını ve kodlarını incelemek ve genellikle bilgileri birlikte kesmek. Bunu akılda tutarak bazı gerçekler yanlış olabilir.

Birisi gerçekten yanlış bir şey görürse lütfen bana bildirin, blogu güncelleyeceğim.

Kıyaslama, pazarlama iddiaları ve tahminine dayanmaktadır. Neden? Çünkü kıyaslama oldukça büyük bir çalışma yığınına ve hataya meyilli. Her zaman “bu özel belgesiz ayarı ayarlamış olmalısınız”. Listelenen sayılar çoğu veritabanı için son derece elverişlidir. Bunlar geçmişte Twitter'da bloglanan veya Twitter'da talep edilen numaralardır. Herhangi bir sayının yanlış olduğunu düşünüyorsanız bana bildirin, ben de güncelleyeceğim.


0

Önceki cevaplara ek olarak, Tarantool , ClickHouse ve ScyllaDB'ye de bakmanızı tavsiye ederim . Bu çözümler çoğu durum için fazlasıyla yeterli.

Bazı durumlarda, özellikle gömme için, MDBX (veya bunun gibi bir şey) yararlı olabilir.


3
Bunları neden önerdiğinizi açıklamak ister misiniz ?
Helmar
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.