Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CockroachDB beta-20161013

jepsen.io

Post reply on HN
Print view View original

81–90 of 213 posts

Re: CockroachDB beta-20161013

#81

Post by theptip »

sametmax wrote: post #70
theptip wrote: post #63

Earlier quoted context omitted.

If your dataset fits comfortably on one postgres instance, and will continue to do so for your current architectural planning time horizon, then you have little need to use CockroachDB / Spanner. These databases are designed for use-cases which require the consistency of a relational database, but cannot fit on a single instance.

Right now not really. Cockroach perf don't allow you do have a big dataset given the performances.

Can you elaborate on this point please? My reading of the article and docs is that perf is expected to scale linearly with the number of nodes (and therefore with dataset size).

Re: CockroachDB beta-20161013

#82

Post by arjunnarayan »

hinkley wrote: post #39
qaq wrote: post #13

Earlier quoted context omitted.

They need to be at least 1000x to 10,000x faster on the read side though

I'm a little confused about how read speed is 2x slower than write speed. With respect to 'correctness', you're drifting into pyrrhic victory or 'not even wrong' territory at that point. When there are basic expectations of behavior that aren't being met, many of us would reject the idea that this code is 'correct'.

[Disclaimer: CockroachDB engineer here, working on performance and benchmarking]

IIRC, in the case that aphyr refers to for these specific numbers, the reads are scans that span multiple shards[1], while the writes are writes to single shards.

[1] even though aphyr says it's just a hundred rows, the tables are split into multiple shards because aphyr in this case was specifically testing our correctness in multi-shard contention scenarios. In production you wouldn't have multi-shard reads crop up until you were doing scans for tables that were hundreds of thousands of rows in size[2]. It's easier to picture if you think of this performance speed difference in the scenario where you are doing full table scans spanning multiple shards on multiple computers while the underlying rows are being rapidly mutated by contending write transactions. The transactions get constantly aborted to avoid giving a non-serializable result, and performance is suffering. We agree that the numbers in this contention scenario are too low, and we are actively working on high-contention performance (and performance in general) leading up to our 1.0 release[3].

[2] Specifically, we break up into multiple shards when a single shard exceeds 64mb in size.

[3] You can follow along on one of the PRs that address this specific performance issue here: https://github.com/cockroachdb/cockroach/pull/13501

Re: CockroachDB beta-20161013

#83

Post by marknadal »

aphyr wrote: post #27
010a wrote: post #19

Earlier quoted context omitted.

Gundb is garbage.

To be a tad more concrete: GunDB can run in the browser as well as on servers; CockroachDB is a traditional, client/server database. GunDB is aiming for eventual consistency, but when I looked a year ago, it seemed like the algorithm they chose wasn't actually convergent--nodes could diverge because non-commutative updates could be applied in different orders on different nodes. CockroachDB, by contrast, is a seriali…

Aphyr, thanks! I appreciate seeing you here and replying. GUN Author here.

First, to answer @sroussey - Kyle is correct, GUN is an eventually consistent graph database that runs browser/server with extremely high availability, while CockroachDB is trying to be a strongly consistent, linearizable key/value SQL store. To read about what we guarantee/don't, check out these articles:

https://github.com/amark/gun/wiki/CAP-Theorem

http://gun.js.org/distributed/matters.html (tech talk on how the algorithms work)

https://github.com/amark/gun/wiki/Conflict-Resolution-with-G...

The last year we've focused on performance, and can now do 25M+ reads/sec (no cache miss, disk I/O performance isn't particularly interesting to us). More on that here: https://github.com/amark/gun/wiki/100000-ops-sec-in-IE6-on-2... (we're not kidding about it being able to run in the browser)

With regards to commutative / non-commutative, @Aphyr, slight correction: Different machines will converge to the same value, it is just that you'd need to use a commutative CRDT on top of gun (we have one here: https://github.com/amark/gun/wiki/snippets-(v0.3.x)#counter ) for them to converge to their combined value.

Example: GUN treats primitives as atomic, so if you try to `gun.get('some').path('math').put(5 + 2)` it will converge to the atomic value of 7. So if two machines do `gun.get('some').path('math').put(currentValue + 2)` at the same time, both machines will converge to the fixed atomic value, not a commutative value - you need the CRDT for that.

I mention this in the "What could go wrong?" section of the talk (linked above), and it is easy to add the necessary CRDT when you need it - actually, this was inspired by you @aphyr, from our discussion a few years ago.

Note: @Aphyr, we built a distributed testing framework ( https://github.com/gundb/panic-server ), and now that our "performance improvement" stage is done, in the near future we're going to start building distributed correctness tests (we're rolling out to a government client soon). We'll probably be in touch with you in the next half year or so. :)

Great work, keep it up. You are always a huge inspiration. Edit: With regards to sharding / SQL, we don't have SQL support yet but somebody is currently building a prototype for it. Sharding, not built in, but peers store the data they request, which acts as a natural shard, but nothing fancy - for more info check out this article: https://github.com/amark/gun/wiki/sharding .

Re: CockroachDB beta-20161013

#84

Post by threeseed »

sametmax wrote: post #68
hinkley wrote: post #49

Earlier quoted context omitted.

What I found out the hard way is that there's a qualitative difference between 'can' and 'must' here that causes a lot of problems with the development cycle. When the project can no longer fit onto a developer's box it changes a bunch of dynamics and often not for the better. Lots of regressions slip in, because developers start to believe that the glitches they see are caused by other people touching things they sh…

Plus I found that people using MongoDB tend to not formalize their data schema because the tool doesn't enforce it. But they do have a data schema. Only: - it's implicit, and you have to inspect the db and the code to understand it. - there is no single source of truth, so any changes better be backed up by unit tests. And training is awkward. If some fields/values are rarely use, you can easily end up not knowing ab…

That last statement is a bit off. Almost every developer knows how to use an SQL database. For 95% of things you want to do it's a very simple piece of technology.

The issue is that they are annoying to use. You have to create a schema, you have to manage the evolution of that schema (great another tool), you have to build out these complicated relational models and finally you have to duplicate that schema in code.

And so IMHO that's why people move towards MongoDB. It's amazing for prototyping and then people just well stick with it as there isn't a compelling enough reason to switch.

Re: CockroachDB beta-20161013

#85

Post by [deleted] »

sametmax wrote: post #68
hinkley wrote: post #49

Earlier quoted context omitted.

What I found out the hard way is that there's a qualitative difference between 'can' and 'must' here that causes a lot of problems with the development cycle. When the project can no longer fit onto a developer's box it changes a bunch of dynamics and often not for the better. Lots of regressions slip in, because developers start to believe that the glitches they see are caused by other people touching things they sh…

Plus I found that people using MongoDB tend to not formalize their data schema because the tool doesn't enforce it. But they do have a data schema. Only: - it's implicit, and you have to inspect the db and the code to understand it. - there is no single source of truth, so any changes better be backed up by unit tests. And training is awkward. If some fields/values are rarely use, you can easily end up not knowing ab…

[deleted]

Re: CockroachDB beta-20161013

#86

Post by tyingq »

exhilaration wrote: post #4

Like Spanner, Cockroach’s correctness depends on the strength of its clocks... Unlike Spanner, CockroachDB users are likely deploying on commodity hardware or the cloud, without GPS and atomic clocks for reference. I'm curious, do any of the cloud providers offer instances with high-precision clocks? Maybe this is something one of the smaller cloud providers might want to offer to differentiate themselves - instances…

>I'm curious, do any of the cloud providers offer instances with high-precision clocks?

That's a great question.

Could be a little tricky with AWS for example. It's typical to run a database on a VPC (virtual private cloud), since that layer of the stack doesn't need to be exposed to the Internet. Unfortunately, that means the servers in the VPC can't get to the ⁎.amazon.pool.ntp.org servers.

Skimming around, I don't see any of the cloud providers, VPS providers, or dedicated hosting companies offering anything special, like a local stratum 1 time source for each region/location.

Re: CockroachDB beta-20161013

#87

Post by Perignon »

WhitneyLand wrote: post #24

Could the name actually slow the project's momentum? I only recently read some cool things about CDB and wondered if I could have been subconsciously skipping articles about it for deep seeded reasons like http://bbc.com/future/story/20140918-the-reality-about-roach... Of course anything good may eventually rise to success on its merits, but in case I'm not the only one with a subconscious aversion maybe the info bel…

Agree, the name is pretty off putting. Maybe they were trying to be funny? I don't know, but I would recommend changing it.

Re: CockroachDB beta-20161013

#88

Post by threeseed »

sametmax wrote: post #38
chillydawg wrote: post #35

Earlier quoted context omitted.

But why scale something when you can just run one postgres instance and provide 10000x the performance?

My though exactly. It's already the case with faster DB. E.G: most projects my customers make me work on will never need scaling on multiple instances. They run really fast on a single postgres instance. One had some perf issues. First he just moved the DB to avoid having it on the same machine as the web server. Saved him a year. Then as the user base grew, he just bought a bigger server for the db. Right now it wor…

You do understand that scalability is more than just concurrent users right ? Maybe not ?

There are many very small startups doing work in IoT, Analytics, Social, Finance, Health etc who have ridiculously challenging storage needs. Trying to vertically scale is simply not an option when you have a 50 node Spark cluster or 1M IoT devices all streaming data into your database. Vertically scaling your DB doesn't work as it is largely an I/O challenge not a CPU/Storage one.

But hey it's cute and lucky that you work on small projects. But many of us aren't and have to deal with these more exotic database solutions.

Re: CockroachDB beta-20161013

#89

Post by WhitneyLand »

OpenDrapery wrote: post #51
WhitneyLand wrote: post #24

Could the name actually slow the project's momentum? I only recently read some cool things about CDB and wondered if I could have been subconsciously skipping articles about it for deep seeded reasons like http://bbc.com/future/story/20140918-the-reality-about-roach... Of course anything good may eventually rise to success on its merits, but in case I'm not the only one with a subconscious aversion maybe the info bel…

I'm wondering if all the people who can't get over the name CockroachDB are also people who insist that professionals should dress the part. Can't take someone seriously if they don't have their shirt tucked in? Style over substance.

Definitely not. The opposite in fact, I don't even require shoes or shirt if you're speaking rationally.

Re: CockroachDB beta-20161013

#90

Post by threeseed »

sametmax wrote: post #70
theptip wrote: post #63

Earlier quoted context omitted.

If your dataset fits comfortably on one postgres instance, and will continue to do so for your current architectural planning time horizon, then you have little need to use CockroachDB / Spanner. These databases are designed for use-cases which require the consistency of a relational database, but cannot fit on a single instance.

Right now not really. Cockroach perf don't allow you do have a big dataset given the performances.

This statement makes absolutely no sense.

Performance is very loosely correlated with dataset size and less so in most distributed NoSQL databases like CockroachDB.

Post reply on HN