eKuiper'ın Rust ile yeniden yazılan sürümü, edge karşılaştırmalarında saniyede 425 bin olay ve 8 MB RAM iddiasında bulunuyor

Ne oldu

I-Dacs Labs'taki bir ekip, Rust ile yazılmış, açık kaynaklı bir LF Edge eKuiper akış işleme (stream processing) motoru yeniden yazımı olan rekuiper'ı yayımladı. 10 Eylül 2026 tarihli bir dev.to yazısında ekip, 0.421-beta sürümünün yaklaşık 8 MB bellek tüketerek ve iç daemon'ını yaklaşık 13 milisaniyede başlatarak 500.000 telemetri kaydını saniyede kabaca 425.000 olay hızında işlediğini bildiriyor.

Ele alınan sorun

Yazıya göre I-Dacs Labs, Raspberry Pi'ler, Advantech gateway'leri ve gömülü x86 ve ARM kutular dahil olmak üzere kısıtlı edge donanımında yüksek hacimli telemetri hatları çalıştırıyor. Yerel akış işleme için SQL filtreleme, kayan pencereler (sliding window) ile MQTT ve Kafka sink'lerini kapsayan Go tabanlı eKuiper'ı kullanmışlardı; ancak yazarların edge computing'de yapısal bir ödün olarak nitelendirdiği sınırlara tekrar tekrar takılmışlar.

Bir uçta, Apache Flink gibi JVM motorları güçlü bir işleme hızı sunuyor ama 1 GB'dan fazla RAM ve 20 saniyeden uzun açılış süresi gerektiriyor; yazarlar bunu küçük endüstriyel donanımda kullanılamaz olarak değerlendiriyor. Öteki uçta Go motorları daha hafif; ancak yazı, garbage collection süpürmelerinden kaynaklanan kuyruk sonu gecikme (tail latency) oynamalarını ve daha önemlisi, saniyede 10.000 ile 100.000 olay arasındaki ani sensör yükleri altında Go channel tamponları dolduğunda sessizce paket kaybı yaşandığını bildiriyor.

Yeniden yazımın içeriği

Yeni motor; StreamBus adında kilit kullanmayan (lock-free) bir akış veri yolu, kural yürütme için Tokio tabanlı asenkron aktörler ve sink'lere besleme yapan sınırlı aktör kuyrukları etrafında kurulu; yazarlar bu tasarımın çalışma zamanında (runtime) garbage collection duraklamalarını ortadan kaldırdığını söylüyor.

Proje, upstream eKuiper ile tam birebir uyumluluk iddiasında bulunuyor: mevcut eKuiper Manager web arayüzü, OpenAPI 3.0 şemaları ve standart akış SQL'i ile uyumluluk; 98 REST endpoint'in tamamı saplama (stub) olmadan uygulanmış. Bildirilen boyut rakamları arasında 9,60 MB'lık strip edilmiş statik binary, boşta yaklaşık 6 ile 8,2 MB arası RAM, 12,5 ile 14,5 ms arası iç daemon başlatma süresi ve süreç başlatma ile soket hazır olma arasında uçtan uca 123 ms yer alıyor. Kod MIT ve Apache-2.0 lisanslarıyla çift lisanslı.

Karşılaştırma sonuçları

Tüm motorlar aynı Linux makinesinde, WSL2 Ubuntu x86_64 kurulumunda, özdeş bir hattıyla çalıştırıldı: 500.000 JSON olayını ayrıştırmak, bir sıcaklık dönüşümü hesaplamak, bir eşiğin üzerindeki değerleri filtrelemek, iki alanı yansıtmak ve bir sink'e yazmak.

Motor	Runtime	Geçen süre	İşleme hızı	Kayıp	Bellek
rekuiper 0.421	Rust	1,176 s	425.308 eps	0	~8 MB
Apache Flink	JVM	2,144 s	233.209 eps	0	~1.022 MB
Telegraf	Go	8,194 s	61.019 eps	0	~50 MB
Upstream Go eKuiper	Go	11,290 s	44.287 eps	72.921 (%14,6)	~45 MB
Redpanda Connect	Go	19,236 s	25.993 eps	0	~38 MB

Yazının başlığında Benthos geçerken, tabloda aynı projenin güncel adıyla Redpanda Connect listeleniyor.

Yazarlar üç bulguyu öne çıkarıyor. Birincisi, upstream Go eKuiper kanal doygunluğu nedeniyle sürekli ani yük altında 500.000 kaydın 72.921'ini, yani yaklaşık yüzde 14,6'sını düşürürken rekuiper her kaydı işlemiş ve 9,6 kat daha hızlı olduğu belirtilmiş. İkincisi, Flink saniyede 233 bin olaya ulaşmış ancak JobManager ve TaskManager'ı 1 GB'dan fazla RAM tüketmiş; rekuiper'ın tek çekirdek işleme hızını geçtiği ve kabaca 125 kat daha az bellek kullandığı iddia ediliyor. Üçüncüsü, yazıya göre soğuk başlatmada rekuiper'ın yaklaşık 13 ms'lik iç başlatma süresi, Go eKuiper için 1,2 saniye ve Flink için 20 saniye ile karşılaştırılıyor.

Rakamlara dikkatle bakmak

Bunlar, projenin yazarları tarafından tek bir WSL2 ortamında, oldukça basit bir hattı kullanılarak beta yazılımla üretilmiş, kendi beyanlarına dayanan rakamlar. Henüz bağımsız bir doğrulama yok ve tablo, projenin hedeflediğini söylediği ARM edge donanımındaki sonuçları göstermiyor. Yazarların motorunun her kolonu kazanması bile tek başına temkin için bir neden; upstream eKuiper'a ait kayıp rakamı da yalnızca bu belirli ani yük testi için geçerli. Olumlu tarafta, depo yeniden üretim betikleri ve Docker yapılandırmaları içeriyor ve tüm test seti tek bir betikle yeniden çalıştırılabiliyor; bu da iddiaları denetlemek isteyenler için eşiği düşürüyor.

Neden önemli

Edge'de akış işleme gerçek bir uzlaşı dayatıyor: JVM motorları küçük cihazlar için çok ağır, Go motorları ise gecikme oynamalarına ya da —bu sonuçlar doğruysa— sessiz veri kaybına yol açabiliyor. Aynı SQL lehçesini, REST API'yi ve yönetim arayüzünü koruyan bir Rust yeniden yazımı, mevcut eKuiper dağıtımları için geçiş maliyetini neredeyse sıfıra indirir; 13 ms'lik açılış süresi ise iş yükleri arasında uyuyan ya da elektrik kesintilerinden kurtulan cihazlar için önemli. Upstream eKuiper için bildirilen yüzde 14,6'lık kayıp oranı en ağır sonuç doğuracak iddia; çünkü sensör verilerini düşürmek genellikle onları yavaş işlemekten daha kötüdür. Şüpheci olanlar için bile bu yayım, altyapı araçlarında Rust'a karşı Go tartışmasına bir veri noktası ekliyor ve yayımlanan karşılaştırma betikleri, benzer duyuruların nadiren ulaştığı bir yeniden üretilebilirlik standardı belirliyor.