Examining the performance impact of Type-I virtualization on a NewSQL RDBMS

[sigterm9kill]

I am testing the differences between bare metal and virtualization load processing for newSQL dbms

The TPC-E/oltp bench seems not to be conducive to these ideas:

What is the performance impact of Type-I virtualization on a NewSQL RDBMS?

What is the difference in the CPU utilization as recorded during database benchmarking for a system hosting a NewSQL database instance when comparing bare metal and Type-I virtualized environments?

What is the difference in memory utilization as recorded during database benchmarking for a system hosting a NewSQL database instance when comparing bare metal and Type-I virtualized environments?

What is the difference in the disk I/O measurement as recorded during database benchmarking for a system hosting a NewSQL database instance when comparing bare metal and Type-I virtualized environments?

What is the difference in the network I/O measurement as recorded during database benchmarking for a system hosting a NewSQL database instance when comparing bare metal and Type-I virtualized environments?

What is the difference in the database transactions-per-second as recorded during database benchmarking for a system hosting a NewSQL database instance when comparing bare metal and Type-I virtualized environments?

MemSQL VoltDB NuoDB

[jshook]

@sigterm9kill,

I have removed personal contact info from your issue. If you want it added back, you can directly add it again, and I will leave it there. I removed it out of an abundance of caution in case you didn't want it posted on a publicly viewable issue.

I think your questions are interesting. These types of tests could be supported if someone wanted to provide drivers for them in the NoSQLBench APIs. The three databases you mention are not part of these drivers yet, unless they are supported by JDBC. If not, any contributor is welcome to add them. These types of additions tend to come from users like yourself, or in some cases, from vendors of databases who wish to level up their testing tools with the NoSQLBench testing engine.

In terms of testing workloads, I have also found many of the TPC- specifications to be rooted in system designs from before the NoSQL era. The way that they are specified makes them costly and complex to implement as well as too specialized to be useful across a variety of system designs. Thus, they are written in a way that focuses on the past and ignores much of what makes newer system designs interesting and compelling. This isn't a dig at TPC- specs. I'm just observing that they were written for a different generation of technology, by and for a group of vendors who were covering their own bases, and by (large) committee.

Testing realistic workloads (data, operations, concurrency, etc) is what NoSQLBench is all about. Please elaborate if you have specific questions or requests here.

[sigterm9kill]

Thank you for removing the information, I didn’t consider the possibilities.

I will get started on the drivers as they are not part of the JDBC.. Just curious of the New sql ramifications on your engine… how to best abstract into your model(s).

I will be in touch. Thank you again for the response.

On Aug 2, 2021, at 2:24 PM, Jonathan Shook @.***> wrote:

@sigterm9kill https://github.com/sigterm9kill,

I have removed personal contact info from your issue. If you want it added back, you can directly add it again, and I will leave it there. I removed it out of an abundance of caution in case you didn't want it posted on a publicly viewable issue.

I think your questions are interesting. These types of tests could be supported if someone wanted to provide drivers for them in the NoSQLBench APIs. The three databases you mention are not part of these drivers yet, unless they are supported by JDBC. If not, any contributor is welcome to add them. These types of additions tend to come from users like yourself, or in some cases, from vendors of databases who wish to level up their testing tools with the NoSQLBench testing engine.

In terms of testing workloads, I have also found many of the TPC- specifications to be rooted in system designs from before the NoSQL era. They way that they are specified makes them costly and complex to implement as well as too specialized to be useful across a variety of system designs. Thus, they are written in a way that focuses on the past and ignores much of what makes newer system designs interesting and compelling. This isn't a dig at TPC- specs. I'm just observing that they were written for a different generation of technology, by and for a group of vendors who were covering their own bases, and by (large) committee.

Testing realistic workloads (data, operations, concurrency, etc) is what NoSQLBench is all about. Please elaborate if you have specific questions or requests here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nosqlbench/nosqlbench/issues/347#issuecomment-891273956, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALFTSZMNS3R2KNBUOELUOH3T23WGHANCNFSM5BNH24AA.

[dave2wave]

This should either be closed or used to create a discussion or new docs issue that is about contribution.