Closed Fale closed 6 years ago
Hi @Fale!
Thanks for your interest in CockroachDB. With version 1.1 your numbers are not completely surprising as that release was not focused on performance. Several of the limitations you observe are being lifted in the upcoming 2.0 release and the one after that (2.1).
Meanwhile, you are doing two 'something that make the test "wrong"':
Finally, note the following:
Thanks :).
I've done more benchmarks, using version 2.0-alpha.20180212:
The first one still with the three nodes on the same machine:
fale@x250:~/go/src/github.com/fale/pg-benchmark $ ./pg-benchmark
2018/02/25 18:59:42 # Ensure schema is present - PgSQL
2018/02/25 18:59:42 # Ensure database is present - CockroachDB
2018/02/25 18:59:42 # Ensure table is present and empty - PgSQL
2018/02/25 18:59:42 # Ensure table is present and empty - CockroachDB
2018/02/25 18:59:43 500 inserts in PgSQL took 665.159742ms, with an average of 1330319ns/op
2018/02/25 18:59:45 500 inserts in CockroachDB took 2.444064827s, with an average of 4888129ns/op
2018/02/25 18:59:45 500 selects in PgSQL took 65.529611ms, with an average of 131059ns/op
2018/02/25 18:59:45 500 selects in CockroachDB took 219.302259ms, with an average of 438604ns/op
2018/02/25 18:59:46 500 deletes in PgSQL took 651.94164ms, with an average of 1303883ns/op
2018/02/25 18:59:48 500 deletes in CockroachDB took 2.407759236s, with an average of 4815518ns/op
fale@x250:~/go/src/github.com/fale/pg-benchmark $ ./pg-benchmark
2018/02/25 19:00:24 # Ensure schema is present - PgSQL
2018/02/25 19:00:24 # Ensure database is present - CockroachDB
2018/02/25 19:00:24 # Ensure table is present and empty - PgSQL
2018/02/25 19:00:24 # Ensure table is present and empty - CockroachDB
2018/02/25 19:00:24 500 inserts in PgSQL took 676.834742ms, with an average of 1353669ns/op
2018/02/25 19:00:27 500 inserts in CockroachDB took 2.516174991s, with an average of 5032349ns/op
2018/02/25 19:00:27 500 selects in PgSQL took 48.130063ms, with an average of 96260ns/op
2018/02/25 19:00:27 500 selects in CockroachDB took 227.892005ms, with an average of 455784ns/op
2018/02/25 19:00:28 500 deletes in PgSQL took 661.885943ms, with an average of 1323771ns/op
2018/02/25 19:00:30 500 deletes in CockroachDB took 2.494310242s, with an average of 4988620ns/op
Speed is very similar to version 1.1.5, at least in those tests.
Then I moved to a single node cluster and I got:
@x250:~/go/src/github.com/fale/pg-benchmark $ ./pg-benchmark
2018/02/25 19:09:06 # Ensure schema is present - PgSQL
2018/02/25 19:09:06 # Ensure database is present - CockroachDB
2018/02/25 19:09:06 # Ensure table is present and empty - PgSQL
2018/02/25 19:09:06 # Ensure table is present and empty - CockroachDB
2018/02/25 19:09:06 500 inserts in PgSQL took 646.523211ms, with an average of 1293046ns/op
2018/02/25 19:09:08 500 inserts in CockroachDB took 1.547001224s, with an average of 3094002ns/op
2018/02/25 19:09:08 500 selects in PgSQL took 51.706685ms, with an average of 103413ns/op
2018/02/25 19:09:08 500 selects in CockroachDB took 151.971039ms, with an average of 303942ns/op
2018/02/25 19:09:09 500 deletes in PgSQL took 668.726909ms, with an average of 1337453ns/op
2018/02/25 19:09:10 500 deletes in CockroachDB took 1.646481992s, with an average of 3292963ns/op
fale@x250:~/go/src/github.com/fale/pg-benchmark $ ./pg-benchmark
2018/02/25 19:15:07 # Ensure schema is present - PgSQL
2018/02/25 19:15:07 # Ensure database is present - CockroachDB
2018/02/25 19:15:07 # Ensure table is present and empty - PgSQL
2018/02/25 19:15:07 # Ensure table is present and empty - CockroachDB
2018/02/25 19:15:08 500 inserts in PgSQL took 652.285039ms, with an average of 1304570ns/op
2018/02/25 19:15:10 500 inserts in CockroachDB took 1.585498223s, with an average of 3170996ns/op
2018/02/25 19:15:10 500 selects in PgSQL took 53.059632ms, with an average of 106119ns/op
2018/02/25 19:15:10 500 selects in CockroachDB took 135.993407ms, with an average of 271986ns/op
2018/02/25 19:15:10 500 deletes in PgSQL took 675.890494ms, with an average of 1351780ns/op
2018/02/25 19:15:12 500 deletes in CockroachDB took 1.776926316s, with an average of 3553852ns/op
Performances are better, but stil 2.5~3x PgSQL. I'll try in the next few days to expand the tests to accommodate your comments :)
Hi @Fale, one thing you might want to try is parallelizing your requests over multiple client connections. One thing that we do know is that we have worse latencies that PG, but are able to keep up in throughput. In this setup, the higher latencies are causing a throughput decrease as well.
@Fale
Those results are not surprising...
Your comparing a database ( PostgreSQL) that has had 21 years of development and is highly optimized for single system performance. If you go back 8 years in time, PostgreSQL lost hard to even MySql in every benchmark. They did a great job at fixing postgresql its performance issues.
Compare this to CockroachDB that is barely 3 year old. And has a totally different design philosophy.
CockroachDB is power is not speed. Its the ability to get a replicating, sharding database up and running with minimal effort. CockroachDB has lots of nifty features. Its the same reason why a lot of people started using PostgreSQL in the past. Because PostgreSQL was able to do things, that Mysql did not do ( or did not follow the standards ).
I doubt that CockroachDB will ever get the same performance in single system performance compared to PostgreSQL / Mysql. The real gain is again the ability to easily scale with more databases horizontally and still have a secure system for your data.
Try clustering on PostgreSQL vs CockroachDB and your results will be much more interesting. That is after you spend a few hours setting up clustering on PostgreSQL. Watch what happens when a PostgreSQL master or a slave drops. Or try having Master - Master on PostgreSQL. š
Think of it like this: What is more valuable. The money you spend on a extra server or the money you spend on a database engineer. The extra server is maybe 100 a 200$ per month, where as the database engineer is going to be way more.
If your planning on running a single server website, then stick with MySQL / PostgreSQL / ... as they are heavily optimized the last 20 years for that task. If your goal is to expand your hosting horizontally, then MySQL / PostgreSQL / ... are really not the best choice.
@Fale, thanks for bringing this to our attention, and thanks to @wuflklaue for the context and recommendation! @fale, there are some recommendations above that could be used to improve the test case:
If you have access to AWS, you could also follow our example of deploying a test cluster (https://www.cockroachlabs.com/docs/stable/deploy-a-test-cluster.html). This is closer to a true deployment of CRDB, with multiple nodes running on multiple machines.
Wulfklaue's summary of the relative benefits of CRDB vs. Postgres is on the money. That said, we're continuously looking to improve performance on specific queries, so if you have some real life examples where CRDB is not performant, feel free to let us know. In the meantime, I'll mark this as "closed - will not fix".
PostgreSQL 16.1 (Debian 16.1-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit CockroachDB CCL v23.1.13 @ 2023/12/01 21:38:31 (go1.19.13)
run test 1000 iterations
postgres insert: 2.593997s
cockroach insert: 6.457681s
postgres select: 0.150319s
cockroach select: 0.51686s
postgres delete: 2.674206s
cockroach delete: 6.345429s
I've written the following code snippet:
I installed PgSQL from my distro (Fedora 27).
I installed cockroach following https://www.cockroachlabs.com/docs/stable/start-a-local-cluster.html (v1.1.5) and I tried to perform some benchmarks.
I then tried to change the cockroach execution by adding
--cache=25% --max-sql-memory=25%
to every instance but the results are better but still very far from pgsql ones:Surely my test is not a perfect match with a real workload (I write first, read second, delete third without mixed ops, for instance), also I would expect some kind of performance differences (since cockroach is distributed/multinode) mainly on inserts/deletes, but I was not expecting such performance gap. I wonder if I did something that makes the test "wrong" or if this performance gap is known and is probably the same I could expect on a real workload.