301–310 of 366 posts
Earlier quoted context omitted.
Mongo (similar to 'mongolism', another term for Down's syndrome) has done just fine, despite (or thanks to!) their name. There was similar criticism about their name in the early days, but it has waned as mongo has grown. This will too.
Wasn't mongo slang for humongous? Like Mongo from Blazing Saddles?
I think the name "Cockroach" was a really poor decision from a marketing standpoint. The team intended to convey durability, since cockroaches can live through anything. But when I think of a cockroach, I think, gross, disgusting, etc.
http://www.ranker.com/list/the-top-10-oldest-living-things-o...
But if there were two similar products, one named Roach, I would go with the other without much thought. The name is horrible. As long as they are the king of whatever they do, they can call themselves whatever they want, but handing competitors an automatic naming advantage did not have to be the case.
I really like the fact that the CockroachDB team recently did a detailed Jepsen test with Aphyr. The follow up articles from both CockroachDB and Aphyr explaining the findings are very interesting to read. For those who might be interested - https://www.cockroachlabs.com/blog/cockroachdb-beta-passes-j... https://jepsen.io/analyses/cockroachdb-beta-20160829
> CockroachDB is a distributed, scale-out SQL database which relies on hybrid logical clocks I was curious what "hybrid logical clocks" meant and found the linked paper a bit over my head. I found this more layman description: http://muratbuffalo.blogspot.ca/2014/07/hybrid-logical-clock... Apparently Google used GPS/atomic clocks to keep time synced: >> To alleviate the problems of large ε, Google's TrueTime (TT) emp…
The CAP theorem still holds, so we pick which 2 out 3 to be strengths and where to compromise as little as possible. It's a guaranteed 87.3% effective hair loss formula. I find Quiet Riot helps.
Congratulations to the team on the relase! Everything under "The Future" really excites me, especially the geo-partitioning features. That is something that I'm really looking forward to be using!
Now if we could get a 1.0 of TiDB ???
Earlier quoted context omitted.
Actually, WalMNart cares and so does T-mobile. You probably care too if you stop and think for a bit... The concern here isn't just order of transactions, but also synchronization. For instance, WalMart might charge you twice for a transaction if it appears to have happened at different times when it arrives in different data centers. Also, the comment "The higher frequency the transactions the more you get into quan…
No I disagree since you left out atomicity from your argument. WalMart cannot commit if someone else committed previously, they have to try again. Atomicity is precisely what it is. There is no fuzziness there, you either do it or you don't. The problem with current database designs is the idea of BeginTransaction, that function is the core of the problem. "Transactions" in the real world are NOT completed until ever…
Attempting to extend the landlord example... let's say that I'm your landlord and you have to pay me £1000 each month. You send the bank a message telling the to pay me the money. The bank may make several copies of that message and keep it around for their own reasons. Now, let's say that there are employees at that bank whose job it is to do go through all copies of all messages and make sure what they say is done. If they find a message from several months ago saying "transfer £1000 from you to me this month" and are somehow oblivious to which month it is, they may transfer an additional one thousand pounds even if it's already happened. It's not an exact analogy, but...
This builds up my confidence in their tech, so much so that even though I had no real reason to try this new DB, I'm gonna find one! :D
Earlier quoted context omitted.
We have a post on why we chose Go, from a year and a half ago: https://www.cockroachlabs.com/blog/why-go-was-the-right-choi... More technically, here's a somewhat random set of thoughts on the subject: The Go GC is performant and predictable, unlike the JVM GC. We do have some very memory-allocation-conscious code patterns to minimize the performance impact of working in a garbage-collected language runtime, but in t…
Why do you think the Go GC is better than any the JVM options? From what I've seen, while the Go GC is well tuned for low latency, by picking the right JVM GC parameters you can on balance get a better throughput latency tradeoff. I'm just wondering if you have any reliable benchmarks or evidence to support what your saying? I don't use either language for work, so I think you might have better information than I.
Earlier quoted context omitted.
Google disagreed on that last part. Their bright engineers kept screwing up with eventual consistency. It's why they built Spanner in the first place followed by F1. So did customers of FoundationDB and Cochroach despite free solutions available for eventual consistency. So, Im not seeing it so clear cut in favor of eventual consistency.
Google never did or bothered to do much work on eventual consistency, they cannot possibly have any experience with it. CRDTs didn't came from them. And you know very well that customers do not care about any of this.
After re-reading the F1 paper, my mistake seems to be thinking they relied on eventually-consistent stuff internally. It appears that was just an option for 3rd party developers in their cloud products. Thanks for the peer review as I found some more stuff double checking. :)