4 ms·

Two reasons: 1. TPC-C is a vendor sponsored cock measuring competition that noone other than marketing people take seriously. 2. Most people scale out rather

Two reasons: 1. TPC-C is a vendor sponsored cock measuring competition that noone other than marketing people take seriously. 2. Most people scale out rather than scale up so it's pretty much irrelevant as it considers monolithic computing only. TPC-C is from the dark ages...

gaius 14y ago
He mentions that "scale-out" is much harder when you have atomic transactions spanning more than one "shard".
- gouranga 14y ago
  Harder yes, but not impossible.
  - gaius 14y ago
    No, not impossible, but all those they tested performed worse than classic RDBMS. Locking turns out to be a hard problem...
    - gouranga 14y ago
      Don't lock then. You can have transactions through the reservation pattern and operation ordering without locking.
huggyface 14y ago
that noone other than marketing people take seriously Plenty of people take it seriously. I take it seriously. Most people scale out rather than scale up so it's pretty much irrelevant as it considers monolithic computing only. Yet the top results are clusters. You're 0 out of 2. Any more wisdom about TPC? It's also worth considering audiences: If you're a web scale company holding recipes for millions of free accounts, you're a bit different from a hedge fund churning performance results for your investor results statements. Judging the latter from the perspective of the former is asinine.
- gouranga 14y ago
  you really bought the marketing then. The code is always frigged for the benchmarks and you're not going to get anywhere if you try and replicate it yourself without half the vendor ops team being in site. Basically, its packaged bullshit. let me clarify monolithic: its a single component in the architecture, not the full stack. I mean if I put an aggressive caching layer over the top I don't even need to hit the cluster for consistent reads. Regarding my utilisation and experience, we're high finance (private insurance, product sales, portfolio management), 5k concurrent users and have been around 20 years. We've also been screwed by every vendor under the sun on bullshit like that over the years. End game: CQRS. Google it.
  - huggyface 14y ago
    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.

gaius 14y ago

He mentions that "scale-out" is much harder when you have atomic transactions spanning more than one "shard".

gouranga 14y ago
Harder yes, but not impossible.
- gaius 14y ago
  No, not impossible, but all those they tested performed worse than classic RDBMS. Locking turns out to be a hard problem...
  - gouranga 14y ago
    Don't lock then. You can have transactions through the reservation pattern and operation ordering without locking.

huggyface 14y ago

that noone other than marketing people take seriously Plenty of people take it seriously. I take it seriously. Most people scale out rather than scale up so it's pretty much irrelevant as it considers monolithic computing only. Yet the top results are clusters. You're 0 out of 2. Any more wisdom about TPC? It's also worth considering audiences: If you're a web scale company holding recipes for millions of free accounts, you're a bit different from a hedge fund churning performance results for your investor results statements. Judging the latter from the perspective of the former is asinine.

gouranga 14y ago
you really bought the marketing then. The code is always frigged for the benchmarks and you're not going to get anywhere if you try and replicate it yourself without half the vendor ops team being in site. Basically, its packaged bullshit. let me clarify monolithic: its a single component in the architecture, not the full stack. I mean if I put an aggressive caching layer over the top I don't even need to hit the cluster for consistent reads. Regarding my utilisation and experience, we're high finance (private insurance, product sales, portfolio management), 5k concurrent users and have been around 20 years. We've also been screwed by every vendor under the sun on bullshit like that over the years. End game: CQRS. Google it.
- huggyface 14y ago
  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.