lynxdb

关于

Hey HN, I spent the last year building LynxDB because I got tired of the gap between grep and Splunk. At work I deal with ClickHouse and Splunk daily — Splunk's query language is great for log analysis, but running it costs a fortune and takes a dedicated team. On the other end, grep works until you need aggregations. LynxDB is a log analytics engine that ships as a single binary with zero dependencies. It has two modes: Pipe mode - works like grep. No server, no config. kubectl logs deploy/api | lynxdb query '| group by endpoint compute avg(duration_ms)' Server mode — persistent storage with full-text search (FST inverted index + roaring bitmaps), columnar segments with dictionary encoding and LZ4, and materialized views for precomputed aggregations. The query language is called Lynx Flow — a pipeline language where data flows left to right through |. If you know SPL, you'll feel at home. It also has partial SPL2 compatibility. from nginx | parse combined(_raw) | status >= 500 | group by uri compute count() as hits, avg(duration_ms) as latency | order by hits desc | take 10 Quickest way to try it: curl -fsSL https://lynxdb.org/install.sh | sh lynxdb demo # streams sample logs from 4 sources lynxdb query 'from nginx | group by status compute count()' Idle memory is around 50 MB. It accepts Elasticsearch _bulk, OpenTelemetry OTLP, and Splunk HEC, so you can point existing pipelines at it without changing anything. Fair warning: this is v0.1.3 and not production-ready. Storage format and APIs may change between releases. I'm using it for my own log analysis workflows and it works well enough there, but I wouldn't run it in prod yet. Written in Go. Interested to hear what you think — especially about the query language design and what you'd want from a tool like this

收录记录

1. Show HN

   2026年3月31日 · 1 次收录

2. 阮一峰周刊·用户投稿

   2026年5月1日 · 1 次收录

3. 阮一峰周刊·正刊推荐

   2026年5月8日 · 1 次收录