Earlier quoted context omitted.
Redis internal data structures are quite sophisticated.
How does being sophisticated imply crazy?
It was a figure of speech; he just meant "non-standard."
The genius and folly of MongoDB
61–70 of 280 posts
Re: The genius and folly of MongoDB
#62Earlier quoted context omitted.
It's "a" right tool in any case where distributed storage of unstructured data in JSON format is wanted, where database-level locks won't be an issue of concern, and availability is the primary, overriding concern.
What does mongo offer over (possibly sharded) postgres for this use case? Postgres won't hit you with db-level locks and gives you master/slave replication for availability. You can also get great performance if you put the WAL on a ramdisk, which I think is roughly equivalent to how mongodb handles writes. I'm really not trying to be argumentative here, I'm just trying to understand what mongodb is for.
> What does mongo offer over (possibly sharded) postgres for this use case?
Doesn't really matter for the point I'm making. It's a solution for a given set of constraints. Not the solution, or the very best tippy-top solution in all the kingdom, just a solution.
Point being I can't think of a use case where this is true, but if you read the article, the author does include what he says is the only reasonable use case for using MongoDB.
Re: The genius and folly of MongoDB
#63So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).
What's wrong with the Viaweb/Arc/HackerNews/Mailinator approach of just using in-memory datastructures (hashtables, linked lists) and then journaling out changes to the filesystem as records that are read in on startup? It's incredibly simple and blindingly fast as long as you stay on one server, and you can get several thousand QPS of capacity on that one server (vs. like 10 with a Django/Rails + SQL database soluti…
MySQL now supports the key-value use case via the memcached API since MySQL 5.6.
https://blogs.oracle.com/MySQL/entry/nosql_memcached_api_for...
Re: The genius and folly of MongoDB
#64Earlier quoted context omitted.
What's wrong with the Viaweb/Arc/HackerNews/Mailinator approach of just using in-memory datastructures (hashtables, linked lists) and then journaling out changes to the filesystem as records that are read in on startup? It's incredibly simple and blindingly fast as long as you stay on one server, and you can get several thousand QPS of capacity on that one server (vs. like 10 with a Django/Rails + SQL database soluti…
> What's wrong with the Viaweb/Arc/HackerNews/Mailinator approach of just using in-memory datastructures (hashtables, linked lists) and then journaling out changes to the filesystem as records that are read in on startup? That works for some things. However, it's no more a foolproof magical solution than MySQL or MongoDB or Cassandra or Oracle or... It just has different tradeoffs (non-primary key queries will tend t…
Well, that's of course true. All engineering systems face trade-offs.
The nice thing about doing the dead simple solutions first is that they give you time to focus on the things all startups have to do (getting users, building product) and then fall down at the the things that very few startups have the luxury of needing to deal with (scaling, fault tolerance, reporting, alternative views of data).
Throughout the lifetime of my first startup, I was obsessed with the question of "What are we going to do when we need to scale?" It failed because it had a daily userbase measured in the dozens. Then I went to Google to learn how to scale things. And it turned out the biggest lesson I learned at Google was not how to scale things (though I did learn that too), but that you shouldn't scale things, not until you need to. Because the process of designing for scale slows you down significantly, and makes it much harder to develop a system that's usable and performs well under small workloads. Google products take forever to launch, because they have to scale to millions of users from day 1. As a result, their product decisions are very often questionable in early versions. Most startups don't have the luxury of Google's brand name and billions in cash to tide them over that learning process, and need to hit the ground running.
Focus on the problems you have, not the problems you hope to have in the future.
Re: The genius and folly of MongoDB
#65Earlier quoted context omitted.
It's "a" right tool in any case where distributed storage of unstructured data in JSON format is wanted, where database-level locks won't be an issue of concern, and availability is the primary, overriding concern.
What does mongo offer over (possibly sharded) postgres for this use case? Postgres won't hit you with db-level locks and gives you master/slave replication for availability. You can also get great performance if you put the WAL on a ramdisk, which I think is roughly equivalent to how mongodb handles writes. I'm really not trying to be argumentative here, I'm just trying to understand what mongodb is for.
IIRC, until fairly recently (well after Mongo had launched), "master/slave replication for availability" in Postgres was a bitch to set up, requiring 3rd-party tools + manual failover if the master died. It was a lot easier to get going with Mongo, which is really what matters if you're a 2 person startup just trying to validate an idea.
Re: The genius and folly of MongoDB
#66Earlier quoted context omitted.
If you're going to comment so strongly, some explanation of why it deserves such ridicule would contribute much more value to the discussion.
No check constraints. Spotty transaction isolation. Silent data corruption if you happen to make certain kinds of updates while using statement-based replication. No on-line schema updates (is that still true?). Complete inability to execute joins of any size in reasonable time due to the lack of merge or hash join strategies. Corresponding inability to handle subqueries of any complexity. Readers block writers (at t…
Besides the corruption, that just sounds like it's missing features. Missing features is ridicule worthy?
Re: The genius and folly of MongoDB
#67Earlier quoted context omitted.
What does mongodb offer above and beyond using postgres or redis for this use case?
I've barely used it, but the json document thing with a lot of random convenience functions in the query language seem to lend themselves well to rapid development. For postgres you'd be mapping to a relational schema, and for redis you'd be storing the json yourself as a blob, without any server-side manipulation capabilities (or using redis maps/sets/etc, which are awesome, but aren't as general as json). I haven't…
[deleted]
Re: The genius and folly of MongoDB
#68I've used MongoDB for various projects and found it nice to use. Lately though, I've found MySQL to be pretty enjoyable too, so honestly, what's all the fuss? It's a database.
Nobody writes about the filesystem like they do the database, and yet they do the same job - store and retrieve data.
Re: The genius and folly of MongoDB
#69Earlier quoted context omitted.
It's "a" right tool in any case where distributed storage of unstructured data in JSON format is wanted, where database-level locks won't be an issue of concern, and availability is the primary, overriding concern.
I'd submit that database-level locks make any claims of availability or distributed storage a little overblown. If a single query can blow you out of the water, you're really not highly available. Although I don't have a lot of experience doing big mongodb personally, so maybe I'm missing something.
That doesn't have anything to do with availability, at least not in the CAP theorem sense as I understand it. What I think you're talking about (being "blown out of the water" is pretty vague, though) is partition tolerance: high-latency requests that are practically indistinguishable from network partition events.
I'm not sure what MongoDB returns (or how its clients react) when there are no available connections because of a lock whose duration exceeds the configured timeout. I'm pretty confident, though, that this sort of thing is covered by basic driver config.
Re: The genius and folly of MongoDB
#70Earlier quoted context omitted.
From what I've seen, the data model has a lot of utility as long as you don't need super high concurrent performance. Basically, the same area as where rails is the right tool - we want easy features and rapid development, will worry about scaling later.
What does mongodb offer above and beyond using postgres or redis for this use case?
Absolutely nothing.