ethangunderson

Hi, software developer at Cars.com here. While I appreciate the ego boost of thinking that we're somehow better than average, I don't believe this to be true. You can get away with sloppy Elixir code just as easily as you can in PHP, Ruby, Python, etc.

> they thought that switching to Phoenix was a bad idea

If you have the time I recommend re-watching Zack's talk. This is not a take away, or implied.

Comparing map/reduce in Mongo and Couch is really apples and oranges. They are designe to do two different things. i.e data processing vs building views.

Mongo is designed from the ground up to deal with large datasets. Take a look at their sharding architecture.

Full text of their post: https://gist.github.com/fb41d5002822fff18686

Damn, didn't realize you had to be logged in to see the posting about it.

When we talk about consistency, we're talking about taking the database from one consistant state to another.

With replica sets, we're still only dealing with one master. We can get inconsistant reads from the replicas, but we're always writing to a single master, which allows that master to determine the integrity of a write.

With sharding, we're still only dealing with one canonical home for a specific key(defined by the shard key). (besides latency, I'm not sure how datacenters would affect this)

What we're giving up in this case is availability. If an entire replica set goes down, we can't read or write any data for the key ranges contained on those machines. This is where Riak shines.

With Riak, any node can accept writes, and nodes contain copys of several other nodes data. What that means is, as long as we have one node up, we can write to the database. Because of this, there is the possibility of nodes having different views of the data. This is handled in a number of ways(read repairs, vector clocks, etc). Check out the Amazon Dynamo paper for more info, great read.

I'm sure I'm missing some stuff, but I think that covers the gist of it.

EDIT: One thing that I want to make clear, I don't think that one architecture is better than the other. They each have their own pros and cons, and are really suited to solve different problems.

If they're doing the same thing, that's just as shitty. But I've been meaning to listen to that episode of the Changelog for awhile now, so thanks for the reminder!

Basho has always had an issue with the way Mogno was architected and marketed, and they have no issue with letting people know. (several blog posts, killdashnine parties)

I actually like both Mongo and Riak. I think they both solve a different problem set, and can actually complement each other in a polyglot persistence setup. It's a shame that there has to be so much negativity between them, because at the end of the day, this type of whiny blog post doesn't really help anyone.

It was a thinly veiled bash on Mongo.

Software engineering is a subset of programming, particularly the subset where people give a shit about the code they ship.

The issue with that is if your DB gets backed and starts queuing writes, the timestamps will be skewed. Obviously this isn't always a show stopper, but a caveat nonetheless.

The first item in the list really bugs me. It's not enough to just tell me not to do something, teach me why it's bad. That way, I can explain to others why this is a mistake instead of just regurgitating the same explanation of 'it's a performance disaster'.

It's worth noting that Twitter has built a lot on top of MySQL to get to the scale they're at. Take FlockDB for example, https://github.com/twitter/flockdb

So I guess that statement should be written as "you can't scale with just those". :)

FWIW, Foursquare's situation was kind of unique. They have a need for all of their data to be in RAM. In most applications, you can define a working set of data. As long as you can keep that working set and indexes in RAM, you'll be fine.

Just like most things, it's not that simple. For example...

Cassandra is good for 'big data' if you're ok dealing with the repercussions of eventual consistency, and questionable performance characteristics. Not to mention the mediocre community support.

Redis is a fantastic choice, if you're ok with a limited data model and no diskstore option(coming soon though!)

Picking a datastore that fits your data model, access patterns, support needs, etc. can be a daunting task, and simplifying it to this degree just leaves too much out of the equation.

It's also missing a bunch of the conversation, making it rather worthless.

Is there a NoSQL database that claims that? I don't know of one. Rather, they attempt to implement different facets of CAP. Also, the CAP theorem, as it stands, is showing its age, Brewer himself has said it needs to be updated.

No system could prevent it, but there are databases(Oracle and MongoDB off the top of my head, and I'm sure there are others) that implement slave delays specifically to help mitigate human error like this.

Thanks for pointing that out, it's been fixed.

The idea should be that you are picking the right tool for the job. Just because you could just use Postgres, doesn't mean that another data store wouldn't be better suited for your problem space. Could be Mongo, could be Cassandra, it very well could be Postgres, but you should be doing some up front analysis and research before you make that decision.

Interesting, I didn't know that priority was given to reads(in theory anyways). Thanks for the tip!

As for server durability, yes, it has been beaten to death. Yet, I still talk to developers that either have no idea that's how Mongo operates, or don't know what save mode has to offer.

One of the best things to come out the nosql 'movement' is exactly that, no more silver bullets. As much as I like Mongo, I would never blindly recommend it, or any other data store for that matter. It's all about analyzing what your problem space actually needs, and using the best tool to fill that space.

And, yes, the speed improvements to the ruby driver are very much appreciated :)

This used to be the case in earlier versions, but now it only issues a server level write lock for atomic updates, reads can still happen.

It's not ideal, but it is an improvement.