seiflotfy
I agree with you. agents don't look at dashboards... the future is MCP servers.
Show HN: FSST – Fast Static Symbol Table Compression Library in Go
https://github.com/axiomhq/fsst
Here is a Go implementation of FSST, a fast static symbol table compression. It comes with training, encode/decode helpers, and examples. It’s great for logs and JSON data.Reference implementation: https://github.com/cwida/fsst Paper: https://www.vldb.org/pvldb/vol13/p2649-boncz.pdfBenchmarks and tests are in the repo - feedback welcome.P.S. Assisted by AI.
Show HN: SIMD-Optimized Bloom Filters in Mojo for Large-Scale Systems
Show HN: Mojo Implementation of HyperLogLog for Efficient Cardinality Estimation
Moving a Community from Slack to Discord
A New Look for Axiom
const Self = @This();
pub fn init() Self {
var s = Self{};
for (s.dense) |*x| x.* = 0;
return s;
}
}
}```
doesn't this allocate 1<<p upfront though. If yes then the HLL of size 16384 bytes upfront which kinda beats the purpose of having a sparse representation no?Show HN: HyperLogLog in Zig
You’ve got 99 problems, logging shouldn’t be one
Existing solutions, and those architected in a more traditional way than Axiom, would require highly-coordinated nodes running on expensive VMs that would be bound by cpu, memory, and storage depending on your use case:
- Want to store TBs of data for months/years and query any piece of that at any time? Prepare to have expensive SSDs or wait for 'archived' data to swap in from cheaper storage.
- Want to run a query that combines N datasets, calculates aggregations, over TBs of data, and then compare that against data with the time shifted back a week, month, or year? Great, fire up some heavy VMs with enough cpu, memory, and bandwidth to compute all that.
- What if you use case varying greatly in each dimension (how much ingest you'd use, how much storage you'd need, and how heavy your queries would be) across a day, week, or month? You'd have to find a way to adapt to changing requirements or just scale up for the worst case x2 and just pay the $$$.
With Axiom, we had three key goals:
- Hyper-efficient, co-ordination free, schema-less, and index-free ingest (~1.4TB/day on a $5/mo container)
- Cheapest storage for hot, cold, archived and warehoused data: all data is stored in object storage, highly compressed & ready to query. 10 seconds or 10 years old data is the same, already as cheap as possible.
- Serverless querying that can expand from 0 to as-much-as-AWS-will-allow depending on what your query needs + how many of your team are querying at once.
The above was achieved through a lot of trial-and-error, tweaking, testing, and head-scratching, but we're really proud of what we've built. We can run super-fast ad-hoc queries, we've eliminated the need to think about retention, we have live streaming, and we have an incredible query language inspired by Microsoft's Kusto (Splunk users will be familiar!).
We still have a lot I'd like to see done, but I think we really do have something unique :)
Also feel free to join our slack for more feedback :D
Who/Why (non-bots) would fork 1k+ GitHub repos a month let alone 9k+?
https://github.com/axiomhq/axiom-honeycomb-proxy It's called proxy but its actually a multiplexer ;)
Some things where we are different:
* We don't sample if you push to us directly.
* Our pricing is different (https://www.axiom.co/pricing#calculator)
* We are younger but we built it a bit differently, with object storage being our only storage.
* We have a Kusto(-ish) language (https://play.axiom.co/axiom-play-qf1k/explorer?qid=uqXTzFSTv...)
* We provide a streaming view https://play.axiom.co/axiom-play-qf1k/stream/github-issue-co...