3 ms·

"How is technology designed decades ago still dominating TPC-C?" -- this assumption does not take into account that the engine underneath the technology interfa

"How is technology designed decades ago still dominating TPC-C?" -- this assumption does not take into account that the engine underneath the technology interface design can change and evolve for new technologies to some extent. Additionally, the reason these two are at the top of the heap is that Oracle and IBM both put a great deal of money not only into the software, but into designing and producing the machines that run these tests, the filesystems and operating systems, etc -- it is a total package with a driving focus related to database performance; these tests are run on multi-million dollar machines made by those companies. Until you have a complete end-to-end ecosystem, with a focus on everything from the hardware, through the OS, all the way to the DB, you probably aren't going to beat them with any 'new' technology... If a 'new technology' does beat out the traditional, I will expect the products that will be at the top of the performance curve, for the near future (10yrs) to also come from IBM and Oracle... Especially since Oracle has already release an ACID noSQL db engine that is also tightly wedded to their full ecosystem. (IBM may have as well, but I didn't notice if they did)

jhugg 14y ago
It is, surely, difficult to create a product that is better than Oracle/DB2 in every dimension. These systems have thousands of engineer-years of work baked into them. On the other hand, it's pretty easy to beat these systems by specializing. Take some part of what they do and do it better. [Insert sports car / minivan / mack truck analogy here] The interesting question is whether the pain of using the new system is less than the pain of using the old system. New system pain often comes from having fewer features or a less robust implementation. Legacy pain often comes from managing software that has to maintain compatibility with 20 year old apps and scaling workloads on software designed when 8mb of ram was a lot and clusters weren't practical. I will also say from experience, if you take a copy of Oracle and the same hardware from the TPC-C leader board, you will have a hell of a time replicating their results. They use every trick in the book and spend huge sums of money tuning for these benchmarks (n.b. I don't fault them). In practice getting throughput close to what they claim on actual real-world apps is not realistic. Now, you should take all benchmarks with a grain of salt (even mine). Ask a vendor how fast the system will run on a real workload that you understand with the configuration you plan to deploy with. If their number is attractive, build a POC and check for yourself.

jhugg 14y ago

It is, surely, difficult to create a product that is better than Oracle/DB2 in every dimension. These systems have thousands of engineer-years of work baked into them. On the other hand, it's pretty easy to beat these systems by specializing. Take some part of what they do and do it better. [Insert sports car / minivan / mack truck analogy here] The interesting question is whether the pain of using the new system is less than the pain of using the old system. New system pain often comes from having fewer features or a less robust implementation. Legacy pain often comes from managing software that has to maintain compatibility with 20 year old apps and scaling workloads on software designed when 8mb of ram was a lot and clusters weren't practical. I will also say from experience, if you take a copy of Oracle and the same hardware from the TPC-C leader board, you will have a hell of a time replicating their results. They use every trick in the book and spend huge sums of money tuning for these benchmarks (n.b. I don't fault them). In practice getting throughput close to what they claim on actual real-world apps is not realistic. Now, you should take all benchmarks with a grain of salt (even mine). Ask a vendor how fast the system will run on a real workload that you understand with the configuration you plan to deploy with. If their number is attractive, build a POC and check for yourself.