IoT sensör alımı için neden Redis yerine PGMQ'yu seçtim? Yazılım

IoT sensör alımı için neden Redis yerine PGMQ'yu seçtim?

Son yazımda Next.js, PostgreSQL ve Docker üzerine kurulu, yerel öncelikli bir yetiştirme telemetri platformu olan CultivatorsLedger'ı tanıttım....

Son yazımda Next.js, PostgreSQL ve Docker üzerine kurulu, yerel öncelikli bir yetiştirme telemetri platformu olan CultivatorsLedger'ı tanıttım.

Aldığım ilk mimari kararlardan biri sensör veri alımının nasıl ele alınacağıydı. Büyüme ortamında Wi-Fi güvenilir değildir. Ağ düşüşleri meydana gelir. Ve bunu yaptıklarında standart HTTP gönderileri verileri kaybeder.

Sıraya ihtiyacım vardı.

Kafka — güçlü ama ev laboratuvarı kurulumu için fazlasıyla ağır. 4x4 çadırda VPD'yi takip etmek için dağıtılmış bir kayıt sistemine ihtiyacım yok.

Detaylar ve Etkileri

— güçlü ama ev laboratuvarı kurulumu için fazlasıyla ağır. 4x4 çadırda VPD'yi takip etmek için dağıtılmış bir kayıt sistemine ihtiyacım yok. Redis — hafif ve hızlı, ancak bu, yığına başka bir hizmetin eklenmesi anlamına geliyordu. Daha fazla hareketli parça, daha fazla kırılacak şey.

— hafif ve hızlıydı ancak bu, yığına başka bir hizmetin eklenmesi anlamına geliyordu. Daha fazla hareketli parça, daha fazla kırılacak şey. MQTT — Nesnelerin İnterneti için harikadır ancak bu bir kuyruk değil, bir protokoldür. Hala güvenilirliği ve ısrarı kendim halletmem gerekiyor.

PGMQ, Postgres'i bir mesaj kuyruğuna dönüştüren bir PostgreSQL uzantısıdır. Basit, güvenilir ve kullandığım veritabanına zaten yerleşik.

Önemli Gelişmeler

Sensör verileri HTTP POST aracılığıyla gelir API rotası bunu kuyruğa pgmq.send() ile gönderir Bir çalışan bunu pgmq.read() ile alır Çalışan verileri işler ve zaman serisi tablolarına ekler Çalışan mesajı kaldırmak için pgmq.delete() öğesini çağırır

Bir sensör veri gönderirse ve çalışan meşgulse mesaj kuyrukta kalır. Ağ kesilirse mesaj kuyrukta kalır. Sunucu yeniden başlatılırsa mesaj kuyrukta kalır.

Sonuç ve Değerlendirme

Veri kaybı yok. Karmaşık komisyoncu kurulumu yok. Sadece Postgres.

Uzmanların Görüşleri

PGMQ büyük ölçekte Kafka kadar hızlı değil. Ancak evde yetiştirilen veya küçük bir tesis için fazlasıyla yeterli. Ve her şeyi tek bir veritabanında tutmak, izlenmesi ve bakımı gereken daha az hizmet anlamına gelir.

Teknik Analiz

Tüketici çalışanı, sürekli çalışan küçük bir Python betiğidir:

pgmq'den psycopg2'yi içe aktar PGMQ kuyruğunu içe aktar = PGMQ (bağlantı) mesajları = kuyruk. mesajlardaki msj için oku (1, vt = 60): sensör_verisi = msg ['mesaj'] save_to_database (sensör_verisi) kuyruğu. delete ( msg [ ' id ' ]) Tam ekran moduna girin Tam ekran modundan çıkın

Nasıl Önlem Alınmalı?

İşte bu. Çalışan her seferinde bir mesajı okur, işler ve siler. İşleme başarısız olursa mesaj, görünürlük zaman aşımı sona erene kadar kuyrukta kalır.

Mimari stabildir. Şimdi kontrol paneli kullanıcı arayüzü, Ev Asistanı entegrasyonu ve CSV'yi içe aktarma üzerinde çalışıyorum.

Benzer bir şey oluşturuyorsanız veya sadece takip etmek istiyorsanız depoya göz atın:

Sistem Güvenliği

github.com/growerzer0/cultivatorsledger

Gelecekte Ne Bekleniyor?

Veya önceki yazıyı okuyun: Donanımınızda Kalacak Bir Uygulama Kontrol Paneli Oluşturmak

Hiçbir şey yüklemeden kontrol panelinin nasıl göründüğünü görebilmeniz için etkileşimli bir demo kullandım.

VPD kaydırıcılarıyla oynayın, geri kurutma ilerlemesini takip edin ve besleme hesaplayıcısını test edin. Tüm veriler simüle edilmiştir ancak deneyim gerçektir.

Paylaş: