2 ms·

I mean if I put an aggressive caching layer over the top I don't even need to hit the cluster for consistent reads. So the database vendors would likely do wel

I mean if I put an aggressive caching layer over the top I don't even need to hit the cluster for consistent reads. So the database vendors would likely do well to implement aggressive caching right at the source, right? That would be why our database instances use the 192GB of the machine that they're on. There is no silver bullet to platforms. Further the database is usually the most restrictive layer of the stack, hence why the focus on that (but consult Redis or nginx or tomcat benchmarks if you are looking at the other layers).

gouranga 14y ago
Nope - databases cache chunks of ready to serve but not yet processed data, not precalculated business logic outputs and resolved rules. Every time you hit them, they cost cycles, IO (the real killer) and RAM. The database is very restrictive which is why our domain model lives outside it. We put stuff in the OLTP store when we're done with it and take it out when we need it, or most likely from our ORM L2 cache and/or our service layer cache. DB does f-all apart from keep our caches hydrated. Its bad architecture to put all your eggs in a black box, particularly an expensive one.
- huggyface 14y ago
  Business logic outputs? Resolved rules? Are you, perchance, a disciple at the church of ORM? That is a religion that makes its own problems, and then celebrates the victory when they solve their own problems. The database is very restrictive No it isn't. The claim is ridiculous. Its bad architecture to put all your eggs in a black box Nonsensical.
  - gouranga 14y ago
    It's not a church or religion. It's where you find technology's athiests (engineers) solving business domain problems rather than working out how best to represent them in a relational way and bend them to get what they want. I feel you are heavily politicised by the vendors rather than the solutions required.
- gaius 14y ago
  What you say is true... In the 90s. Let's flip this around and imagine I was lecturing you on why forking CGI scripts "don't scale".

gouranga 14y ago

Nope - databases cache chunks of ready to serve but not yet processed data, not precalculated business logic outputs and resolved rules. Every time you hit them, they cost cycles, IO (the real killer) and RAM. The database is very restrictive which is why our domain model lives outside it. We put stuff in the OLTP store when we're done with it and take it out when we need it, or most likely from our ORM L2 cache and/or our service layer cache. DB does f-all apart from keep our caches hydrated. Its bad architecture to put all your eggs in a black box, particularly an expensive one.

huggyface 14y ago
Business logic outputs? Resolved rules? Are you, perchance, a disciple at the church of ORM? That is a religion that makes its own problems, and then celebrates the victory when they solve their own problems. The database is very restrictive No it isn't. The claim is ridiculous. Its bad architecture to put all your eggs in a black box Nonsensical.
- gouranga 14y ago
  It's not a church or religion. It's where you find technology's athiests (engineers) solving business domain problems rather than working out how best to represent them in a relational way and bend them to get what they want. I feel you are heavily politicised by the vendors rather than the solutions required.
gaius 14y ago
What you say is true... In the 90s. Let's flip this around and imagine I was lecturing you on why forking CGI scripts "don't scale".