Progress in performance and scalability with CockroachDB • Hacker News Board

Re: Progress in performance and scalability with CockroachDB

#41

Post by gigatexal » Thu, Nov 29, 2018, 11:28 AM UTC

eloff wrote: post #22

gigatexal wrote: post #2

I’m currently evaluating this as an alternative to vitess + percona mysql. But strict seralizability has its limitations.

What do you mean "strict seralizability has its limitations", you need something stricter? Or you have a need for something weaker for some reason?

In the same way single threaded has limitations.

Re: Progress in performance and scalability with CockroachDB

#42

Post by gigatexal » Thu, Nov 29, 2018, 11:32 AM UTC

segmondy wrote: post #8

gigatexal wrote: post #2

I’m currently evaluating this as an alternative to vitess + percona mysql. But strict seralizability has its limitations.

Why as an alternative to vitess? Are you hitting limits with vitess?

Because I believe the overhead to not be worth it. I’d rather a database be cloud native and have things like sharding and scaling built in and the coordination of that built in. I grok the CockroachDB way of doing things much more than how Vitess is and shocking fact most companies aren’t Google in size and don’t really need a Vitess or CockroachDB but get swept up in the Cloud,Cloud,Cloud! craze. The seemingly brittle nature of vtablets, vtgates, etc versus something built in is valuable to me.

Re: Progress in performance and scalability with CockroachDB

#43

Post by nawfalhasan » Thu, Nov 29, 2018, 1:04 PM UTC

qaq wrote: post #13

Now we just need some benchmarks on a reasonable size dataset like 100TB and up

Not an easy benchmark..

Re: Progress in performance and scalability with CockroachDB

#44

Post by nawfalhasan » Thu, Nov 29, 2018, 1:05 PM UTC

orangechairs wrote: post #16

nawfalhasan wrote: post #15

I'm totally new to cockroach so I have 2 questions.. 1. Is there a managed service of this db where it auto scales, does geo replication etc all by itself? 2. Is there any really good book on cockroachdb?

We released a managed version at the end of October, with auto-scaling, geo-replication, etc. --> https://www.cockroachlabs.com/product/managed/ Not sure that there any books on it yet.

Thank you..

Re: Progress in performance and scalability with CockroachDB

#45

Post by qaq » Thu, Nov 29, 2018, 3:16 PM UTC

nawfalhasan wrote: post #43

qaq wrote: post #13

Now we just need some benchmarks on a reasonable size dataset like 100TB and up

Not an easy benchmark..

One would imaging they are testing with much larger datasets internally.

Re: Progress in performance and scalability with CockroachDB

#46

Post by awoods187 » Thu, Nov 29, 2018, 4:10 PM UTC

continuations wrote: post #32

A few questions: 1) >631851 tpmC How many servers are needed to achieve this throughput? 2) >4 terabytes of unreplicated, frequently accessed data 4TB unreplicated data? Does that mean if a single node goes down you'll lose data (EDIT: I meant losing availability, not data)? That kinda ruins the whole point of having a distributed database. 3) If I'm reading the KV benchmaks correctly, it takes 5 nodes to achieve 100…

I'm the author of the post.

1. Between 90 and 135 16 vCPU nodes depending on cloud hardware 2. The cluster replicates this data three ways across all three nodes (so the cluster actually contains 12+tb of data) ensuring high availability. We intentionally reported the unreplicated number for clarity and comparison to TPC-C spec 3. Our graph is mislabeled. It should read transactions per second `tps`. Nice catch! 4. We can't comment on other database performance as they haven't release any TPC-C numbers.

Re: Progress in performance and scalability with CockroachDB

#47

Post by shenli3514 » Sat, Dec 01, 2018, 4:09 AM UTC

awoods187 wrote: post #46

continuations wrote: post #32

A few questions: 1) >631851 tpmC How many servers are needed to achieve this throughput? 2) >4 terabytes of unreplicated, frequently accessed data 4TB unreplicated data? Does that mean if a single node goes down you'll lose data (EDIT: I meant losing availability, not data)? That kinda ruins the whole point of having a distributed database. 3) If I'm reading the KV benchmaks correctly, it takes 5 nodes to achieve 100…

I'm the author of the post. 1. Between 90 and 135 16 vCPU nodes depending on cloud hardware 2. The cluster replicates this data three ways across all three nodes (so the cluster actually contains 12+tb of data) ensuring high availability. We intentionally reported the unreplicated number for clarity and comparison to TPC-C spec 3. Our graph is mislabeled. It should read transactions per second `tps`. Nice catch! 4. W…

“Between 90 and 135 16 vCPU nodes depending on cloud hardware ” How many nodes did you use in the CRDB 2.0 TPC-C 10k benchmark? Could I say that the "5x increment" is on the same hardware condition? Thanks!