3 ms·
People take TPC-C seriously because not much has come along that's more useful as a transactional benchmark. There are lots of transactional benchmarks, but the
by jhugg 14y ago
People take TPC-C seriously because not much has come along that's more useful as a transactional benchmark. There are lots of transactional benchmarks, but they're often flawed in some annoying way and don't serve well as a baseline as TPC-C.
That said, TPC-C is horribly out-of-date. For example, you have to simulate human data entry time within transactions. How many systems have that problem today? It also only ever adds data, so if you run it fast enough, you have a petabyte problem, and most OLTP isn't a petabyte problem.
As for the second point, those clusters are clusters in name only. They use fancy and expensive interconnects and caches that effectively give them shared memory. Also, they won't tolerate failure of any individual component well. Finally, individual nodes still act as gatekeepers and transaction monitors. Most of the cluster is simply there to apply predicates on data coming off of disk really fast.
- huggyface 14y agoFor example, you have to simulate human data entry time within transactions. How many systems have that problem today? How many people have problems with concurrency? A shitload of people, that's who. This isn't a problem with no locking models because...no locking. It is when you care about consistency. They use fancy and expensive interconnects and caches that effectively give them shared memory. They often use high speed interconnects because the sort of customers who care about such build-outs would naturally use high speed interconnects. They are, however, clusters in every meaning of the word, regardless of no true scotsman fallacy's.
- jhugg 14y agoI'm very familiar with the TPC-C spec and the problem can't be brushed off with "concurrency!". There are multi-second waits in a large percentage of transactions. Nobody does this in any performant OLTP system today, but sure, concurrency! Except the benchmark limits how many of these transactions can be concurrently operating on a warehouse, one of its core models. So the only way to scale throughput is to add warehouses. You end up simulating a company with a million warehouses, each with a fairly small load. Furthermore, to run a million transactions a second, you'll need several million open transactions. That's why you see armies of client nodes in the spec of the systems on the leaderboards. The append-only data model is also difficult. If you removed waits and allowed old data to be pruned, the benchmark would be much more useful. So yes, technically Oracle Exadata OLTP Clustering has multiple CPUs connected by an high speed interconnect. Cluster. My dual socket commodity Dell server also has multiple CPUs connected by a high speed interconnect. Cluster? My point was not to argue about a word, just that Exadata is not what some typically think of as a cluster in modern distributed systems. They've moved some smart filtering into a SAN and plugged that into RAC and shipped it all in a big hot tower-thingy. It's not bad in any way, it's just closer to SMP than other kinds of network-based parallelism.
- huggyface 14y agoMy dual socket commodity Dell server also has multiple CPUs connected by a high speed interconnect. Cluster? The top TPC-C cluster has 27 database servers, each with 4 processors and 512GB of RAM. Can your Dell server host 108 processors and 13.8TB of RAM? The Sun cluster is exactly what most people think of as a "cluster" -- a scalable set of servers that vastly exceeds single server performance.
- jhugg 14y agoYes, it's a cluster. I totally concede. I just meant it's not the same kind of clustering as Hadoop/HBase, Vertica, VoltDB, Cassandra, Riak, Greenplum, Netezza, Teradata or even DB2-Cluster. If clustering is a spectrum where Dynamo-style systems like Riak are on one side and my Dell SMP system is the other extreme, the Sun cluster is probably closer to the SMP system than to the Riak cluster.