Comment by jandrewrogers | Hacker News Reader

Comment by jandrewrogers | Hacker News Reader

This is a good paper and I appreciate the holistic focus on cache efficiency, an area where multiple orders of magnitude of performance improvement are often easily attainable compared to many common implementations. However, it also highlights the gap between academic literature and the state-of-the-art in database engine design. For example, adaptive succinct indexing structures have been used for at least a decade in closed source databases. Structures similar to the ideas presented in the paper have been reduced to practice in real systems for a long time.

Last month I delivered yet another database engine, benchmarked against the best open source comparables, which provides a rough but concrete example of the gap:

The designed memory:storage ratio was 1:1000, an order of magnitude higher than even the 1:100 ratio mentioned as aggressive in the paper. In fairness, my prior systems were designed much closer to 1:100 ratio and it used new CS research to significantly extend the ratio without materially sacrificing performance. For data models with fairly complex indexing requirements, insertion performance was >100x(!) the best open source comparables.

A large part of this performance is due to dramatic improvements in cache efficiency that are not even particularly novel -- the gains attributable to improved cache efficiency in the paper are eminently believable. The data-to-index ratio in the above is around a million-to-one, small enough to fit in CPU cache for many TB scale data models. The high data-to-index ratio is largely attributable to using search structures that forego total order and balancing, which enables dramatic improvements in succinctness with minimal reductions in selectivity.

The other major contributor to performance is scheduler design, which wasn't really touched on in the paper and is largely ignored entirely in open source databases.

tl;dr: current open source database engine designs leave a massive amount of performance on the table due to very poor cache efficiency, and this paper correctly touches on some of the ways this is materially improved in closed source database engines.

Thanks.

> ...adaptive succinct indexing structures

We've been optimising for low-memory and compact / succinct data-structures have been super impactful (especially, static succinct Radix Tree and Data Sketches like CountMinSketch). Apart from the excellent sdsl-lite [0], roaring-bitmaps [1], apache data-sketches [2], and pizza-chilli [3], what are other resources that you recommend we take a look?

> ...storage ratio was 1:1000, an order of magnitude

This is insane: Is it due to compression techniques or... Could you please point a few reasons why the gap is this high?

> The other major contributor to performance is scheduler design...

Out of curiosity: Any pointers to papers that we can take a look at?

---

[0] https://github.com/simongog/sdsl-lite

[1] https://roaringbitmap.org/

[2] https://datasketches.apache.org/

[3] http://pizzachili.dcc.uchile.cl/

Physical storage density per server is driving this. You can fit upward of a petabyte of physical storage in a server and there are many applications where this makes sense. RAM is still on the order of a terabyte, and expensive. Everything else follows from trying to use all of this physical storage effectively. Needless to say, when working with this much storage you aren't installing a filesystem on it.

When working with storage this dense, write performance matters immensely if you can't wait (literally) a year to index your data model. Scaling write throughput on indexing structures has a problem of write sparsity: given a fixed amount of cache, there is a scaling point where virtually every single insert requires at least one page fault. Indexing structures like B+Trees that consume large amounts of space will not only push the data pages out of cache, the index itself may no longer fit into cache at high densities. Every database exhibits this characteristic write cliff with indexing structures but the cache:data ratio where this occurs varies with indexing algorithm design. (This also impacts query performance but we'll ignore that for now.)

Succinct indexing structures can eliminate the competition with data pages for cache space. Write sparsity is intrinsic though, so this only lets you maintain write performance for maybe another 1-2 orders of magnitude. Eventually the set of actively written data pages will exceed the size of the cache and write throughput will drop precipitously before leveling off.

Being able to index tens of terabytes of data at wire speed is much better than typical but at least an order of magnitude short of what is desirable for a petabyte of storage in a single server. Ideally, you'd want the flat write throughput to extend out to the end of your storage, which means extending the write cliff at least another order of magnitude. There is not an obvious way of doing this without adversely impacting performance in other unacceptable ways.

I started researching this problem a few years ago from a very different direction that does not require directly improving cache efficiency per se, since that is essentially tapped out as a strategy. Most software engineers don't understand the nature of caches as abstract mathematical objects but there are some interesting NP-Hard problems surrounding the behavior of caches that we essentially ignore for database architecture purposes because (1) NP-Hard and (2) exploitable efficient approximations are incompatible with many common database architectures in any case. I've worked through a couple new algorithm prototypes that attack these properties to significantly extend the performance party for even higher storage densities. I'm just starting to design kernels that are purpose-built to take advantage of this research but the heavy lifting is done in the schedulers.

Yes, I do this kind of thing for fun.

Could you provide some references for this work on caching and schedulers?

I’m also curious what application domains are storing close to petabytes on a single machine with only a few terabytes of dram.

Ultra-dense database engines are typically used for data models created from measuring entities or places in the physical world, sometimes in real-time. This includes telemetry and sensors from mobile phones, automobiles, satellites, features extracted from video, network packets, the web, etc and sometimes all of the above. These are the largest data models that I know of; most medium-sized non-tech companies I work with have 10-100 PB data models now. The size doubles quickly even if you regularly truncate old data. The extremely high storage density saves both hardware and software engineering costs by massively reducing the required cluster size.

This has become a great emerging market for new database tech, tremendous amounts of money are being spent on these data models and traditional data infrastructures are very poor for this. The size and velocity of the data implies that you need a single database instance that can run ingestion workloads concurrent with analysis workloads.

The research on caching algorithms for ultra-dense storage is new, it is literally just starting to be worked into production designs, so I wouldn't expect references. Most advanced database research is done outside academia, so a significant fraction is published long after implementation or not formally published at all. Publication is not the objective per se and there is little time or incentive to do that work. Database research has a discovery problem, I hear about most interesting new research via informal community channels and much of that never shows up in literature.

Thanks for the reply. I would be very interested if you could point me towards any private companies providing these kind of database solutions. I am particularly interested in their story around concurrent ingestion + analytics workloads. This is a tricky problem that most existing works solve by either doing stupid things a la. having a single-version system, or by using lots of synchronization + complex version-friendly concurrent data structures. Solutions I have seen in academia are usually tested well below the 1TB of data range, and I don't imagine they scale to the kind of data sizes you mention.

The fact that the research is being done outside of academia and not being published is pretty sad imo. Hopefully those in the know decide to publish at least tech-reports/whitepapers once they have a share of the market.

I'm not sure if shakti-db [0] fits the bill of what jandrewrogers is talking about, but the same folks behind it built one of the fastest time-series databases in-use today, the kdb+ [1].

[0] https://shakti.com

[1] https://news.ycombinator.com/item?id=13481824

Can you give names of closed-source database engines that have these kinds of performance improvements?

I mean, the mainstream RDBMS like Oracle, DB2 etc don't seem to be ahead of the open source databases; they are all stagnant too!

Actian Vector, formerly Vectorwise: https://docs.actian.com/vector/5.0/index.html

From the "vectorized columnar execution, operator at a time" school.

HyperDB: https://hyper-db.de/

That's from the "row-oriented execution, query plan JIT compilation" school.

The hyper-db folks do great work. Indeed, Huanchen collaborated with Viktor Leis (one of the senior folks on HyPer) on the SuRF "Succinct Range Filter" (think Bloom filter but for range queries) work: http://www.cs.cmu.edu/~huanche1/publications/surf_paper.pdf and github: https://github.com/efficient/SuRF

and both Viktor and Thomas Neumann's work in this area is fantastic and everyone should go read it. :)

The code for several of Huanchen's projects is available in our group's github repo: https://github.com/efficient/

The order-preserving compression work outlined in his thesis will be appearing soon at SIGMOD, but there's no need to wait for it, since it's roughly the same in both. We'll get the source to that released by the time of SIGMOD.

Databases are severely constrained by the architecture choices from when they were designed, you can't back port modern database architecture and computer science to e.g. an Oracle or DB2. To integrate new computer science advances you often need to write a new kernel from first principles. I sunset the designs I license to companies every several years, starting over from a clean sheet.

Most new high-performance database engines are intended to give the developing company a new qualitative uplift in capability, scale, or operational efficiency. No one sells public licenses these days. You've heard of the organizations that are buying building these semi-bespoke database engines but they are intended for internal use only.

The reason no one sells these capabilities as a product anymore is pragmatic: it is extremely expensive to design a database engine for general public consumption and the economics are difficult to justify as an investment. But many large companies are willing to pay many millions of dollars for a narrowly focused database capabilities, and the reduced scope makes the development cost more palatable.

Was skimming at your Space Curve writeup [1] and your mention of discreet internal components caught my eye. Are you open to expanding a bit on this statement:

"Discrete topology internals largely obviate secondary indexing"

[1]: https://www.jandrewrogers.com/2015/10/08/spacecurve/

Ah, my coin dropped here. Most likely you mean the content addressable segmented architecture.

Secondary indexing is a hack to address the reality that most indexing algorithms can only represent a single type of relationship efficiently and typically only in a single dimension. This is not a law of the universe, it is just how our algorithms tend to work. If you could eliminate secondary indexing without sacrificing selectivity, it would be a massive win for performance and scalability. However, this would require a single indexing algorithm for complex data models that preserved an arbitrary mix of relational, time-series, spatial, graph, etc relationships for searches and joins.

To make this work in a practical database engine, you can't index the data model per se but you can make it work by indexing a moduli space into which arbitrary data models can be mapped. These tend to naturally expose the topological structure of the underlying data model for computational purposes even though you are not computing on the data model per se. Designing very general moduli spaces for database purposes is non-trivial and, to make matters worse, they are pathologically incompatible with typical surrounding database infrastructure once you figure out how to construct them. But you can use the exposed topology to execute complex searches and joins on the underlying data model.

None of my database engines use secondary indexing at all, hence the excellent scaling and write performance, even for complex mixed-mode data models. A decade ago the representations were pretty brittle and limited because I didn't know how to express many things, but these days I know how to elegantly express just about every common data model.

Thanks!

> a moduli space into which arbitrary data models can be mapped

Very interesting. Somehow reminds me of using latices for deterministic concurrency. Is this a topic that is discussed in public literature or an innovation of yours? Love to learn more about this.

The work is mostly mine but I've had collaborators for some of the research over the years.

I accidentally invented it many years ago when I discovered an unorthodox but elegant solution to an algorithm problem which had stymied researchers for decades (and which I needed to solve for a specific application). Some months later, a research group I was working with were convinced that the unusual algorithm construction might be applicable to an unrelated algorithm problem they had been working on. Six weeks later I had solved their problem too by extending the concepts developed for my original algorithm.

By that point I realized that while those two very different algorithms were cool, the half-baked computer science I had developed to construct them was even cooler. I spent the next decade fleshing out, generalizing, and extending the scope of the computer science while figuring out how to efficiently express that theory in practical software (which is not trivial). While I wrote quite a few papers on this computer science many years ago when it was new, the distribution was required to be non-public. I sporadically teach bits of it but writing up hundreds of pages of old research in my spare time is a lot less fun than working on my backlog of interesting computer science projects.

Is your benchmark and data published as a paper or article somewhere. I would be interested to see it

Unfortunately, this database engine implementation (like virtually all I work on) was for a customer. The details are not public.

Reply on news.ycombinator.com