2 ms·
The papers from MonetDB/x100 have a lot of interesting info. Here's one to start with: http://www.vldb.org/conf/1999/P5.pdf http://www.vldb.org/conf/1999/P5.pdf
by jasonwatkinspdx 10y ago
The papers from MonetDB/x100 have a lot of interesting info. Here's one to start with: http://www.vldb.org/conf/1999/P5.pdf http://www.vldb.org/conf/1999/P5.pdf
- nkurz 10y agoGreat paper, but I was wondering particularly about the "optimizing for SSD" aspect. The paper you cite seems to deal only with optimizing for "in RAM" databases. While one might hope that the same techniques would work for both, I think Andrew may have important insights into the differences.
- jasonwatkinspdx 10y agoThere's overlap, and the papers that cite that one are a good place to start running things down. There's plenty of recently published stuff about ssd specific database engine approaches, and I'd specifically suggest the "don't stack your log on my log" paper for a really basic intro [1]. Andrew can speak for himself but I'll say I've not found anything substantial that is similar to the marketing claims of SpaceCurve in open published work. Some of the comments about memory sharding cut against the grain of what I see as the trend in high performance published work, which generally obeys single writer via CoW and or log structure but leverages shared reading of memory heavily. It may perhaps be unfair but given several years and tens of millions of funding I'd expect they'd be able to present something more convincing or at least some benchmarks. I suspect the approach is something smart people have found promising when doing diligence on it, but that is proving difficult to turn into a product due to drawbacks not covered in the marketing materials, blog posts, and comments here. [1]: https://www.usenix.org/system/files/conference/inflow14/inflow14-yang.pdf https://www.usenix.org/system/files/conference/inflow14/infl...