on-premises.... premises...

not premise

I am fairly certain this is the fastest method available https://sorting.cr.yp.to/index.html

That algo is fast as hell, that much is true.

I have not made SIMD optimizations, which djbsort includes, and skylinesort does not require pre-computing the merging network, or padding the array to that size. This works great for crypto where array sizes are known ahead of time and generally always the same, but not all use cases are like this.

I think this misrepresents the pull vs. push issue.

I wrote something up two years about this that was pretty well received. https://www.circonus.com/2016/06/pully-mcpushface/

Thanks for that amazing insight! Super helpful. I like how you framed your thinking.

IRONdb (https://www.irondb.io/)

Can house multi-tenant-safe prometheus long-tail storage as well as others (graphite, opentsdb, influx, etc.). Put it all in one place, scale it up, radically storage efficient and has strong non-stop HA guarantees. It is state of the art, it isn't free.

Disclaimer: I'm the CEO of Circonus (IRONdb's home).

In addition, if you are a freelancer in the US you have access to group healthcare.

Most universities have special access to both IEEE and ACM publications (as well as many others). They pay for this access.

I am an IEEE member. I am not sure why anymore, mostly I think it is important to support the industry.

I am also an ACM member and I find that very valuable. The community is good, the policy engagement is good, the publications are excellent, and their employer subsidy program is excellent. I work at Circonus and we pay for everyone's ACM membership as an employee benefit (including the digital library) and it makes each and every one a more valuable employee -- such an easy investment to justify.

I am also highly active with the ACM. I am currently an ACM Member at Large, so if anyone would like to see any changes within the ACM (and you are a member) I'm here to represent you practitioners! The ACM Turing award (amongst all the other distinguished awards) and very important to rewarding innovation and progress in computing. The ACM is aces.

The industry is booming, it doesn't need your support besides what you actually contribute in your work.

We have customers that generate tens of millions of measurements per second. Lots of low-level systems latencies can be collected at high volume. Also, high volume online services can easily generate this order of magnitude.

I find this discussion fascinating. When I hear people advocate for SLOs (and SLIs) they are often quite rigorous in how they approach it... that is until the very last step where they hand-wave the math and produce numbers that don't mean anything (like averages of percentiles and such). Often times (specifically for sites/services that have undulating traffic volume like more users in the day than at night), the incorrect mathematics can produce wildly inaccurate outputs... so all that rigor and you end up determining that you've failed or succeeded when, in fact, the opposite is true.

I appreciate the rigor in this post because it provides clear and simple instructions on doing the last step (your calculations) correctly so that all those fancy SLOs are actually honest.

Reducing "Other TSDBs" to log-structured-merge trees is misleading. Any large-scale TSDB has something sophisticated underneath and LSM is often just one tiny part of that. I would argue (as most do) that any TSDB "simply used an LSM" it would be doomed at any scale over time.

There was no reduction, it was intended as a pointer to one data structure some TSDBs are using underneath. I would bold and highlight the "etc" present there for you if the markup allowed it.

I hope a reader would become interested in what an LSM tree is (and perhaps as importantly isn't)