524 karma · joined September 13, 2009
From one email:
"Tomorrow morning, we'll be listing the article on Hacker News, Y Combinator's social news network about startups. We need your help to upvote the article to the top of the list so it gets noticed by other entrepreneurs. The more upvotes the article receives, the more this valuable research gets shared with the entrepreneur community."
I'm a little surprised to see all of the MongoDB hate in this thread.
There seems to be quite a bit of misinformation out there: lots of folks seem focused on the global R/W lock and how it must lead to lousy performance.
In practice, the global R/W isn't optimal -- but it's really not a big deal.
First, MongoDB is designed to be run on a machine with sufficient primary memory to hold the working set. In this case, writes finish extremely quickly and therefore lock contention is quite low. Optimizing for this data pattern is a fundamental design decision.
Second, long running operations (i.e., just before a pageout) cause the MongoDB kernel to yield. This prevents slow operations from screwing the pooch, so to speak. Not perfect, but smooths over many problematic cases.
Third, the MongoDB developer community is EXTREMELY passionate about the project. Fine-grained locking and concurrency are areas of active development. The allegation that features or patches are withheld from the broader community is total bunk; the team at 10gen is dedicated, community-focused, and honest. Take a look at the Google Group, JIRA, or disqus if you don't believe me: "free" tickets and questions get resolved very, very quickly.
Other criticisms of MongoDB concerning in-place updates and durability are worth looking at a bit more closely. MongoDB is designed to scale very well for applications where a single master (and/or sharding) makes sense. Thus, the "idiomatic" way of achieving durability in MongoDB is through replication -- journaling comes at a cost that can, in a properly replicated environment, be safely factored out. This is merely a design decision.
Next, in-place updates allow for extremely fast writes provided a correctly designed schema and an aversion to document-growing updates (i.e., $push). If you meet these requirements-- or select an appropriate padding factor-- you'll enjoy high performance without having to garbage collect old versions of data or store more data than you need. Again, this is a design decision.
Finally, it is worth stressing the convenience and flexibility of a schemaless document-oriented datastore. Migrations are greatly simplified and generic models (i.e., product or profile) no longer require a zillion joins. In many regards, working with a schemaless store is a lot like working with an interpreted language: you don't have to mess with "compilation" and you enjoy a bit more flexibility (though you'll need to be more careful at runtime). It's worth noting that MongoDB provides support for dynamic querying of this schemaless data -- you're free to ask whatever you like, indices be damned. Many other schemaless stores do not provide this functionality.
Regardless of the above, if you're looking to scale writes and can tolerate data conflicts (due to outages or network partitions), you might be better served by Cassandra, CouchDB, or another master-master/NoSQL/fill-in-the-blank datastore. It's really up to the developer to select the right tool for the job and to use that tool the way it's designed to be used.
I've written a bit more than I intended to but I hope that what I've said has added to the discussion. MongoDB is a neat piece of software that's really useful for a particular set of applications. Does it always work perfectly? No. Is it the best for everything? Not at all. Do the developers care? You better believe they do.
WTF?
Honestly, I built this thing primarily for fun -- not sure if it really makes a whole lot of sense from a business perspective.
It should be possible to let you recycle your cupidco.de (so as to switch out the crush name, etc). Is that what you mean? I'll look into that tonight.
http://www.reddit.com/r/programming/comments/a2zr1/dear_prog...
http://www.reddit.com/r/reddit.com/comments/a2z0t/dear_reddi...
One thing I'm going to add is a little cookie-based cache of your recent cupidco.de tracking pages, as they start to get difficult to juggle after some time.
So I did what any self-respecting geek would do in my position: I computed a SHA-2 hash of her name and put it in that weird little box thingy on the left hand side of my Facebook profile. It provided just the right balance of self expression and social tact. I was happy.
I liked the idea so much that I decided I would wrap it in a small application and dedicate it to the object of my dorkitude. As I knew it would take a few weeks to flesh out and things were (shockingly) starting to work out between this lovely individual and myself, I thought that the final product might make for a cute little way of sharing my feelings. The idea of tiny "cupidcode" links spreading across facebook and the twitters -- each rooted in my nerdy affection for this particular young lady -- seemed like a terribly powerful way to say "I really think you're great". And because I suck at music and writing, it was pretty much my only option.
Fast forward a few weeks, and cupidco.de is done. It's probably not well suited for the sorts of folks that read YC so I hope you don't mind me sharing my link with you. My hope is that this post will kick-start the spread of a few cupidcodes 'cross the nets so that my crush (who I've been seeing now for about two weeks!) may casually stumble upon one while checking her facebook or reading a blog and discover just how special she is to me.
tl;dr -- fell in love with a chick, wanted to do something special for her, suck at everything else, so I built her a webapp.