Rust ile yeniden yazılan eKuiper, pencere bazlı MQTT yükünde 5-10 MB'de kalırken Go motorları 1 GB'a yaklaşıyor

Proje nedir

I-Dacs Labs Engineering'in dev.to'daki yazısına göre ekip, LF Edge eKuiper'in arayüzünü — iç mimarisi değil — yeniden uygulayan, Rust ile yazılmış bir akış işleme motoru olan rekuiper'ı geliştirdi. Uyumluluk yüzeyi bilinçli olarak sade: eKuiper'in REST API'si (eKuiper'in OpenAPI tanımına karşı kara kutu yöntemiyle doğrulanan 98 yol ve 140 işlem), JSON path'ler, CASE, dizi indeksleme ve unnest içeren SQL lehçesi, DATASOURCE, FORMAT, CONF_KEY, SCHEMAID ve TIMESTAMP gibi stream seçenek adları ve kuiper komut satırı aracı. Amaç, mevcut eKuiper kurallarının, eKuiper Manager web arayüzünün ve dağıtım araçlarının çalışmaya devam etmesi; yani motor değiştirmenin etrafındaki her şeyi yeniden yazmak anlamına gelmemesi.

Kıyaslama nasıl yapıldı

Her motor, tek bir CPU çekirdeğine sabitlenmiş, 1 GB bellekli ve swap'siz bir container içinde çalışırken, ayrı bir Mosquitto broker kendi çekirdeklerini ve bol kuyruk limitlerini aldı; böylece asla darboğaz olmayacaktı. Açık döngülü mqttgen adlı Rust yük üreteci, MQTT 3.1.1 protokolünü QoS 0'da kullanarak her motora özdeş bir programla veri gönderdi ve bir adım yalnızca üreteci gerçekten o programa uyduğunda sayıldı. Çıktı mesaj mesaj doğrulandı; çünkü yazarlara göre alım onaylarını ya da çıktı kayıtlarını saymak kayıp ve kopyaları gizleyebilir — verilerin büyük bir kısmını sessizce düşüren bir motor hızlı görünebilir.

Dört motor karşılaştırıldı: rekuiper v0.425-beta, eKuiper 2.4.1, Telegraf 1.40.0 ve eski adıyla Benthos olan Redpanda Connect 4.109.0. Apache Flink bilinçli olarak dışarıda bırakıldı: yazıya göre ne Flink 2.x ne de Apache Bahir bir MQTT connector'ı içeriyor; dolayısıyla Flink'i test etmek özel bir kaynak ya da bir Kafka köprüsü gerektirecek ve ölçülen alım yolunun kendisini değiştirecekti.

Beş MQTT iş yükü gerçek dağıtımlara benzetildi: 1.000 cihaz arasında durumsuz telemetri filtresi; cihaz başına sayı, ortalama ve maksimum hesaplayan 10 saniyelik kayan (tumbling) pencereler; wildcard abonelikle tüketilen, binary format seçeneği ve metadata olarak taşınan topic adıyla 10.000 düz metin ESPHome topic'i; kayan pencerelerle 10.000 VIN başına araç topic'i — en zor bellek testi olarak tanımlanıyor — ve ne Telegraf'ın ne de Redpanda Connect'in hiçbir şekilde ifade edemediği bir yapı olan oturum pencereleri kullanan 2.000 EV şarj cihazı topic'i.

Sonuçlar

rekuiper, her iş yükünde tek çekirdekte saniyede 100.000 mesajla — test aralığının üst sınırında — eksiksiz ve doğru çıktı üretti; yani tavanına hiç ulaşılmadı. Yazarların daha çok önem verdiği sayı bellek: pencere bazlı iş yüklerinde rekuiper 5 ile 10 MB arasında kalırken, Go tabanlı motorlar yarım gigabayttan bir gigabayta kadar tırmandı ya da çöktü. Yazarlar bu farkı Rust'ın kendisinden çok tasarıma bağlıyor. Bu çalışma ayrıca, yalnızca veri hızına bakan bir kıyaslamanın hız olarak ödüllendireceği bir rekuiper doğruluk hatasını da ortaya çıkardı.

Düz bellek eğrisinin ardındaki üç tasarım tercihi

Dahili akış veri yolu, abone başına 4.096 kayıtlık sınırlı kuyruklar ve önce-ayırt-sonra-onayla toplu kabul mekanizması kullanıyor; böylece bir toplu kayıt ya her aboneye teslim edilir ya da tamamen reddedilir ve yavaş bir kural veriyi sessizce düşürmek yerine kaynağına geri basınç uygular. Sink'ler, özel iş parçacıkları tarafından sunulan 10.000 kayıtlık sınırlı kuyruklarla boşaltılıyor. rumqttc istemcisi üzerine kurulu MQTT kaynağı, tek bir ağ okumasının yüzeye çıkardığı her şeyi en fazla 1.024 kayıtlık tek bir toplu iş olarak kabul ediyor; yazıya göre bu, basit iş yüklerinde mesaj başına CPU kullanımını Go motorlarının kabaca yarısına indiriyor.

Pencereli GROUP BY toplamaları artımlı: her grup ve her toplama için tek bir biriktirici tutuluyor, satırların kendisi hiç saklanmıyor; böylece pencere belleği mesaj sayısının değil cihaz sayısının işlevi oluyor. Satırları gerçekten gerektiren ifadeler — collect(), join'ler ve bazı HAVING koşulları — tamponlu bir değerlendiriciye düşüyor ve bir birim testi, her iki değerlendiricinin karışık veride özdeş çıktı ürettiğini doğruluyor.

Son olarak, sink'ler eKuiper'in kendi seçenekleriyle bir çevrimdışı önbellek etkinleştirebiliyor: başarısız göndermeler önce bellekte FIFO olarak kuyruklanıyor, bir eşikten sonra disk sayfalarında saklanıyor ve yalnızca disk bütçesi tükendiğinde en eski kayıtlar düşürülüyor — üstelik sessizce değil, sayılarak. Yazarlar bu önbelleğin bir entegrasyon testiyle kapsandığını ancak performans rakamlarının dışında tutulduğunu belirtiyor.

Neden önemli

Kenar ağ geçitleri genellikle bir-iki çekirdek ve birkaç yüz megabayt boş bellek alır; trafiği de en kötü şekilde patlamalıdır: filolar birlikte yeniden bağlanır, şarj cihazları eşzamanlı oturum başlatır ve cihazlar bir kesintinin ardından tamponladıkları okumaları hep bir anda gönderir. Bu ortamda bir hattı öldüren veri hızı değil, mesaj hızıyla büyüyen bellektir. eKuiper ile uyumlu, yerine geçebilen bir motorun yük altında belleği sınırlı tutması, mevcut kenar dağıtımlarının daha küçük ve ucuz donanımda çalışmasını sağlayabilir — ne var ki rakamlar rekuiper ekibinin kendi beta sürümü kıyaslamasından geliyor; bağımsız bir tekrar doğal bir sonraki adım. En az bunun kadar değerli olan ise yöntem: bilinçli olarak sıkıştırılmış kaynak limitleri altındaki tam çıktı doğrulaması, akış işleyicileri dürüstçe değerlendirmek için bir şablon.