21–30 of 38 posts
In a system like Redis Cluster (or any other where clients talk with the right nodes directly) it is conceivable that you always see linear scalability as the number of nodes goes up. This fact is not captured by the setup of this benchmark. If you think at it, in a real-world scenario if you have 100 database nodes, you likely also have not threaded clients, but N different processes running in M different computer…
VoltDB Engineer here. It seems like the authors made some unfortunate choices in the configuration and usage of VoltDB. A limited number of synchronous loads are always going to present scalability problems and will do a poor job measureing the throughput achievable. Even if it takes 500usecs to round-trip a transaction from the client, that means each synchronous client can only do 2000 per second. To scale linearly…
In a system like Redis Cluster (or any other where clients talk with the right nodes directly) it is conceivable that you always see linear scalability as the number of nodes goes up. This fact is not captured by the setup of this benchmark. If you think at it, in a real-world scenario if you have 100 database nodes, you likely also have not threaded clients, but N different processes running in M different computer…
VoltDB Engineer here. It seems like the authors made some unfortunate choices in the configuration and usage of VoltDB. A limited number of synchronous loads are always going to present scalability problems and will do a poor job measureing the throughput achievable. Even if it takes 500usecs to round-trip a transaction from the client, that means each synchronous client can only do 2000 per second. To scale linearly…
Hmm, there has to be more to it than that. VoltDB throughput went down scaling from 1 node to 4 in every workload but RSW. This is not a sign of a system that would handle many more requests if only there were more client parallelism.
This is something we address in our docs, but people naively testing VoltDB run into it more than we'd like. So for the next major release, we've re-worked how we do global ordering and can now achieve sub-millisecond latency on larger clusters in internal testing. Note that there's no change to our serializable consistency to achieve lower latency. So this new scheme has a huge impact on synchronous workloads, but the scalability with enough parallelism has been close to linear all along.
VoltDB Engineer here. It seems like the authors made some unfortunate choices in the configuration and usage of VoltDB. A limited number of synchronous loads are always going to present scalability problems and will do a poor job measureing the throughput achievable. Even if it takes 500usecs to round-trip a transaction from the client, that means each synchronous client can only do 2000 per second. To scale linearly…
Hmm, there has to be more to it than that. VoltDB throughput went down scaling from 1 node to 4 in every workload but RSW. This is not a sign of a system that would handle many more requests if only there were more client parallelism.
Short answer, Volt establishes a global order across transactions. Transactions can't be executed immediately because their position in the global order isn't known when they initially arrive. The exchange of ordering information is driven by in-flight transactions. In the absence of sufficient in-flight transactions to drive the ordering process heartbeats are sent every 5 milliseconds resulting in increased latency and lower throughput as the system waits on heartbeats. 2-4x the concurrency should have shown different results.
We're finishing a different transaction initiation system that doesn't produce a global order so that people can do this kind of benchmark and get the expected result. You can switch the beta version on in 2.8.
I also wonder if they had clock skew. The global ordering process is always delayed by the amount of clock skew you have. With NTP properly configured this is 10s of microseconds, but with a typical out of the box NTP config it will be milliseconds unless you have a lot of uptime.
I don't really see this as an excuse and it is why we are eating the pain of a transaction initiation rewrite so people can use Volt the traditional way with small numbers of synchronous client threads.
In a system like Redis Cluster (or any other where clients talk with the right nodes directly) it is conceivable that you always see linear scalability as the number of nodes goes up. This fact is not captured by the setup of this benchmark. If you think at it, in a real-world scenario if you have 100 database nodes, you likely also have not threaded clients, but N different processes running in M different computer…
Unless you're CPU bound on the client, it's irrelevant whether you're using multiple threads or multiple processes to generate the load. Assuming of course that you're not using a GIL-bound client, which the Java-based YCSB does not.
Earlier quoted context omitted.
Unless you're CPU bound on the client, it's irrelevant whether you're using multiple threads or multiple processes to generate the load. Assuming of course that you're not using a GIL-bound client, which the Java-based YCSB does not.
If you look at the Redis graphs there is no linear scalability with N distinct nodes. Now given that Redis has no proxy nor any other node-to-node chat in this setup, how it is possible that it's not linear scalable?
Earlier quoted context omitted.
None of them do auto-sharding and master-master replication. This is the domain dynamo/bigtable-like systems (elasticsearch, riak, cassandra, hbase, voldemort)
Actually AFAIK MySQL supports master-master and the Cluster version supports autosharding.
Earlier quoted context omitted.
> This makes the decision of Facebook to go with HBase for their new messaging platform back in 2010 all the more strange. Speed isn't everything to a database. AFAIK they chose HBase over Cassandra because of consistency guarantees: eventual consistency is a bad choice for a messaging platform.
eventual consistency is a bad choice for a messaging platform Strange you would mention that in the context of Cassandra, since it allows for per-read/write configuration of consistency, from "eventual" to "strong". You get exactly what you ask for with Cassandra, whether its availability or consistency. AFAIK, HBase only supports strong consistency.
Earlier quoted context omitted.
Unless you're CPU bound on the client, it's irrelevant whether you're using multiple threads or multiple processes to generate the load. Assuming of course that you're not using a GIL-bound client, which the Java-based YCSB does not.
If you look at the Redis graphs there is no linear scalability with N distinct nodes. Now given that Redis has no proxy nor any other node-to-node chat in this setup, how it is possible that it's not linear scalable?