4 ms·
Also I just noticed that you used the TPC-C benchmark here Have you considered re-benchmarking with TPC-E? It's the updated version of the OLTP test that more
by gavinray 5y ago
Also I just noticed that you used the TPC-C benchmark here
Have you considered re-benchmarking with TPC-E? It's the updated version of the OLTP test that more accurately represents these sorts of apps:
> "In February 2007, the new TPC-E benchmark [7] became a TPC standard. It is designed to be a more realistic OLTP benchmark than TPC-C, e.g., incorporating realistic data skews and referential integrity constraints."
> "We find that (i) TPC-E is more read intensive with a 9.7:1 I/O read to write ratio, while TPC-C sees a 1.9:1 read-to-write ratio; and (ii) although TPC-E uses pseudo-realistic data, TPC-E’s I/O access pattern is as random as TPC-C."
It's a difference between a 10/1 read/write ratio, and a 2/1 read/write ratio. I've never worked on a line-of-business/SaaS app with a ratio lower than 80% reads FWIW.
https://www.tpc.org/tpce/default5.asp https://www.tpc.org/tpce/default5.asp
http://www.cs.cmu.edu/~chensm/papers/TPCE-sigmod-record10.pdf http://www.cs.cmu.edu/~chensm/papers/TPCE-sigmod-record10.pd...
- AdamProut 5y agoYeah, TPC-E is a better (more advanced) OLTP benchmark. TPC-C is trivially scalable by sharding on warehouse id everywhere. The problem with TPC-E is not many companies publish (official or unofficial) results for it, so its not as useful when comparing systems, which is what we were after in our blog post.
- gavinray 5y ago> The problem with TPC-E is not many companies publish (official or unofficial) results for it, so its not as useful when comparing systems, which is what we were after in our blog post. Oh, yeah this makes a lot of sense