{ "date": "2020-03-08T14:48:13", "slug": "yugabytedb-2-1", "link": "https://www.dbi-services.com/blog/yugabytedb-2-1/", "title": { "rendered": "YugaByteDB 2.1: the Open Source multi-region distributed database with PostgreSQL API is in GA with huge performance improvement" }, "content": { "rendered": "

By Franck Pachot

\n

.
\n9 months ago I was looking at YugaByteDB which was still in beta version for its ‘YSQL’ API. I published my first test on Medium: https://medium.com/@FranckPachot/running-pgbench-on-yugabytedb-1-3-3a15450dfa42. I have been very enthusiastic about the idea, the architecture, the way they open-sourced it and how all was documented in their blog. I’ve even met them in Sunnyvale when I traveled to California for Oracle Open World. Great people with a great vision on the future of databases. From this first test, I was not impressed by the performance but it was an early beta and a multi-master/multi-index database has many challenges to solve before tuning the details of implementation. This tuning task has been done for the General Availability version 2.1 released in February. I was eager to test it, but this first month back to dbi-services consulting was very busy. So finally here it is.
\n
\nThis post takes the same test I did last July and the result is impressive: the pgbench initialization time is fully fixed and the pgbench run shows 9x higher throughput.

\n

I’m on the same VM which, as funny as it might sound, is an Oracle Linux 7 running on the Oracle Cloud.

\n

Install and start:

\n

I install this version 2.1 in the same way I installed the 1.3 in the past. All is documented: https://docs.yugabyte.com/latest/quick-start/install/linux/

\n
\nwget -O yugabyte-2.1.0.0-linux.tar.gz  https://downloads.yugabyte.com/yugabyte-2.1.0.0-linux.tar.gz\ntar -xzvf yugabyte-2.1.0.0-linux.tar.gz\nyugabyte-2.1.0.0/bin/post_install.sh\nexport PATH=\"~/yugabyte-2.1.0.0/bin:~/yugabyte-2.1.0.0/postgresql/bin:$PATH\"\n
\n

I create a 3 nodes cluster with replication factor 3, with all nodes in the same host for this test:

\n
\nyb-ctl --rf 3 create\nyb-ctl status\n
\n

\"\"

\n

I create database for this:

\n
\nysqlsh\n \\timing on\n drop database if exists franck;\n create database franck;\n \\q\n
\n

\"\"

\n

pgbench initialization

\n

I use pgbench that I have from a “normal” PostgreSQL installation on the same server.

\n
\n[opc@db192 ~]$ type pgbench\npgbench is hashed (/usr/pgsql-11/bin/pgbench)\ntime pgbench --initialize --host localhost -p 5433 -U postgres franck\n
\n

\"\"

\n

If you compare with the previous post on version 1.3 you will see many differences.

\n\n

However the “ALTER TABLE” to add the constraints afterward is still not supported so I run the same manually with the FOREIGN KEY declaration in the CREATE TABLE:

\n
\nysqlsh franck\n drop table if exists pgbench_history;\n drop table if exists pgbench_tellers;\n drop table if exists pgbench_accounts;\n drop table if exists pgbench_branches;\nCREATE TABLE pgbench_branches (\n    bid integer NOT NULL\n   ,bbalance integer\n   ,filler character(88)\n   ,CONSTRAINT pgbench_branches_pkey PRIMARY KEY (bid)\n );\nCREATE TABLE pgbench_accounts (\n    aid integer NOT NULL\n   ,bid integer references pgbench_branches\n   ,abalance integer\n   ,filler character(84)\n   ,CONSTRAINT pgbench_accounts_pkey PRIMARY KEY (aid)\n );\nCREATE TABLE pgbench_tellers (\n    tid integer NOT NULL\n   ,bid integer references pgbench_branches\n   ,tbalance integer\n   ,filler character(84)\n   ,CONSTRAINT pgbench_tellers_pkey PRIMARY KEY (tid)\n );\nCREATE TABLE pgbench_history (\n    tid integer references pgbench_tellers\n   ,bid integer references pgbench_branches\n   ,aid integer references pgbench_accounts\n   ,delta integer\n   ,mtime timestamp without time zone\n   ,filler character(22)\n );\n\\q\n
\n

Now remains to insert the rows there. This was very long (about an hour) in 1.3:

\n
\ntime pgbench --initialize --init-steps=g -h localhost -p 5433 -U postgres franck\n
\n

\"\"

\n

No foreign key error and 6 seconds only!

\n

Do you remember that I had to switch to SERIALIZABLE isolation level? I don’t have to here:

\n

\"\"

\n

This has been fixed with the support of SELECT locks, so no need to go to optimistic locking with SERIALIZABLE (which requires that the application implements a ‘retry’ logic).

\n

Simple Update in 1 thread

\n

Then, as I did before, I run a Simple Update workload from one session during 30 seconds:

\n
\npgbench --no-vacuum --builtin=simple-update --protocol=prepared --time 30 -h localhost -p 5433 -U postgres franck\n
\n

\"\"

\n

When compared with the previous run on 1.3 I’ve updated 9x more transactions. Yes, that’s exactly what has been announced for this version: huge performance imprevements:

\n
\n

What we've been up to over the last few month – YugabyteDB 2.1 has a ton of perf improvements and a lot of other goodies! https://t.co/wwwhVG7bPd

\n

PS: Please do give it a spin, would love your feedback.

\n

— Karthik Ranganathan (@karthikr) February 25, 2020

\n

\n

Simple Update in 10 threads

\n

Then, as I did before I’m running with 10 concurrent threads

\n
\npgbench --no-vacuum --protocol=prepared --builtin=simple-update --time 30 --jobs=10 --client=10 -h localhost -p 5433 -U postgres franck\n
\n

\"\"

\n

Again, that 7x better than my test on 1.3 and still in read commited isolation level.

\n

Note that I was lucky here but it can happen that we get a serialization error even in read commited like in this second run of the same:
\n\"\"

\n

The community implementation of pgbench has no retry logic. Once an error is enountered the thead finishes, and that’s unusable for a benchmark. The patch proposed many times was, unfortunately, always rejected: https://commitfest.postgresql.org/18/1645/.

\n

But YugaByteDB has a solution for that, which I’ll show in the next post: https://www.dbi-services.com/blog/ysql_bench/

\n", "protected": false } }