Live data from Hacker News

Anti-Caching: A New Approach to Database Management System Architecture [pdf]

vldb.org

1–10 of 13 posts

Re: Anti-Caching: A New Approach to Database Management System Architecture [pdf]

#4
Archiving. You've described archiving. Taking less-recently-used data off of main storage (RAM in this case) onto a slower, cheaper medium.

Heck, the only reason we have hard disks and memory is that it's not economically feasible to have billions of CPU registers, and that there's a further trade-off between volatility and speed. This is literally an older technique than the computer. Files are kept in the main office until they're not being used and then moved to the basement for long-term storage.

Re: Anti-Caching: A New Approach to Database Management System Architecture [pdf]

#5

Archiving. You've described archiving. Taking less-recently-used data off of main storage (RAM in this case) onto a slower, cheaper medium. Heck, the only reason we have hard disks and memory is that it's not economically feasible to have billions of CPU registers, and that there's a further trade-off between volatility and speed. This is literally an older technique than the computer. Files are kept in the main offi…

Even more simply put: "memory hierarchy exists"?

Re: Anti-Caching: A New Approach to Database Management System Architecture [pdf]

#6
post #5

Archiving. You've described archiving. Taking less-recently-used data off of main storage (RAM in this case) onto a slower, cheaper medium. Heck, the only reason we have hard disks and memory is that it's not economically feasible to have billions of CPU registers, and that there's a further trade-off between volatility and speed. This is literally an older technique than the computer. Files are kept in the main offi…

Even more simply put: "memory hierarchy exists"?

Haha seriously. "Engineering trade-offs exist. A new theory by my startup. (Buy my product)"

Re: Anti-Caching: A New Approach to Database Management System Architecture [pdf]

#7

Archiving. You've described archiving. Taking less-recently-used data off of main storage (RAM in this case) onto a slower, cheaper medium. Heck, the only reason we have hard disks and memory is that it's not economically feasible to have billions of CPU registers, and that there's a further trade-off between volatility and speed. This is literally an older technique than the computer. Files are kept in the main offi…

Yes, that's the basic principle, but I think the "transactionally-safe" part is the point of the paper, i.e the fine grained eviction and non-blocking fetches.

Re: Anti-Caching: A New Approach to Database Management System Architecture [pdf]

#8
From past experience in the database industry, command logs are insufficient at maintaining data integrity after a crash. They capture the bare minimum information to reproduce a transaction, which is frequently not enough information. A log of "I'm changing field X from A to B" produces much more reliability in practice.

Re: Anti-Caching: A New Approach to Database Management System Architecture [pdf]

#9
post #8

From past experience in the database industry, command logs are insufficient at maintaining data integrity after a crash. They capture the bare minimum information to reproduce a transaction, which is frequently not enough information. A log of "I'm changing field X from A to B" produces much more reliability in practice.

I think it really depends on the product. Determinism has been a big issue with logical logs in many systems, but it’s only a problem if you don’t plan and test for it.

If you’re interested in how VoltDB ensures and tests determinism, check out my talk from StrangeLoop this year: https://www.youtube.com/watch?v=gJRj3vJL4wE

Re: Anti-Caching: A New Approach to Database Management System Architecture [pdf]

#10
post #8

From past experience in the database industry, command logs are insufficient at maintaining data integrity after a crash. They capture the bare minimum information to reproduce a transaction, which is frequently not enough information. A log of "I'm changing field X from A to B" produces much more reliability in practice.

If they are capturing enough to reproduce a transaction, then by definition that's enough information :). Non-deterministic commands (WHERE RANDOM() without a known seed) are the problem.\
Post reply on HN