31–32 of 32 posts
Earlier quoted context omitted.
So what you're saying is that in general, transactions are implemented, but the begin/commit syntax for transactions is not yet supported?
Correct.
The upscaledb FAQ indicates "it is not yet concurrent; it uses a big lock to make sure that only one thread can access the upscaledb environment at a time". InnoDB is designed for concurrency (using MVCC, granular locking, etc) so I'd expect it to be slower at single-threaded workloads than another engine that skips all that. Only using single-threaded benchmarking is a bit misleading, imo. This is mentioned in the a…
I ran sysbench benchmarks with 30 concurrent connections. The performance gap between InnoDB and upscaledb shrank a bit, but not much. The reason is that most of the performance is spent in MySQL and not in the key/value store, and then it does not make a big difference if the key/value store is concurrent or not. In my experience the assumption of "concurrent = fast" is a misconception. Right now upscaledb moves cer…
I am not arguing that "concurrent = fast". My point is real systems have a higher level of concurrency as a baseline.
InnoDB supports granular concurrent access because real workloads need this. Systems that have poor stories around concurrency -- MyISAM, Redis, pre-WiredTiger MongoDB -- definitely hit real scalability issues under high-volume workloads.