
What 10gen nailed with MongoDB - calvinfo
http://calv.info/what-10gen-nailed-with-mongodb/
======
bri3d
This article is spot-on, but 10gen did one more thing they probably shouldn't
have: marketed their not-very-scalable, not-very-durable database as a
solution to problems companies were having with scalability and durability.

~~~
whalesalad
I'm very curious about this. I feel like the community at large seems to agree
mongo is a dangerous choice. But then I read articles like this. At what scale
do you replace Mongo? Should it only be used for bootstrapping something? Is
it something that 80% of apps will be fine on?

I'm in an interesting spot myself right now. I've been hacking on Django since
0.96. I love the ORM, and hate everything else. Python on the other hand is a
wonderful language. Rails... I've been spending 8 hours a day for the past
month building a rails project. I love a lot of things about rails, hate the
ORM, and dislike a lot of the magic.

On the flip side: I've been a Javascript/front-end developer since before
jQuery existed, and I love coffeescript. I understand callback-style evented
programming and therefore node.js apps make perfect sense to me.

My co-founder and I have just finished some heavy duty
design/wireframe/conceptual work on a new project of ours. It's time to build
the API.

I am COMPLETELY torn with what framework/language/database to use for this
project.

At first I thought mongodb and coffeescript+node would be fun and reliable.
But the community seems to think mongo is unreliable and almost dangerous. So
I thought, hmm, Riak looks like it will let me throw whatever data I want into
it (like mongo) but it's rock solid. I later dismissed that since I figured
I'd need to do a lot of heavy lifting on my own. Rails keeps poking me in the
back of my mind but I honest-to-god hate ActiveRecord and am afraid to use
DataMapper for fear it won't play nice with a lot of the popular ruby goodies
out there. I've modeled most of the project now in Django and i'm starting to
play with Tastypie for the REST component. It feels too kludgy.

I'm a wreck. Mommy?

~~~
Argorak
I don't know what kind of project it is - but have you actually considered
just using Postgres? Its not hip and takes a bit to setup, but after you are
done, you have reliable workhorse with all the stuff you need (access control,
schemas, etc. pp.) It has a vast amount of documentation and reading about its
advanced features never gets old. There is a lot of talent around that knows
how to use it. If you still consider Ruby but don't like ActiveRecord magic,
don't forget to have a look at Sequel.

I would recommend against DataMapper. It is nicely constructed, but has some
weird issues. Also, DataMapper 1 is going to be replaced by DM 2, which is a
completely different beast (but better, hopefully).

Don't be fooled by ease of setup of the DB too much. It should be rather
straight-forward, but even if a DB can just be downloaded and ran to dabble
with it, always remember that this just shifts the moment at which you really
have to dig into the details. You don't want to do that 2 days before going to
production. Be on the lookout for red flags, though: unreasonable and weird
configurations that have to be flipped for no understandable reasons at all
before going into production. That shows that the project is not maintained
very well or the developers have lost track. Also try to figure out how long
it takes you to solve a new problem with the database, with documentation
reading and all. Pick the one that you can wrap your head around best.

~~~
whalesalad
I have a FreeBSD box in my closet (I felt like playing with FreeBSD this
weekend) currently running Postgres 9 and PostGIS which is how my current
stuff is working.

It's actually pretty rad to have every single location I've ever checked-into
via Facebook stored in this database. I can say "find all the spots 2 miles
from my house" and it's shockingly quick.

I have PostgreSQL on my mac. It's easy to install and use.

PostGIS was the killer. Version 2.0 (homebrew installs postgis2) does not play
nice with Django locally (on my mac) and the ticket has been open for a year
or something to fix it. That's a huge red flag for me right there.
<https://code.djangoproject.com/ticket/16455>

I guess I could install 1.5 manually.

My problem with trusting Ruby/Rails is that I've only been seriously
developing in it for a month.

~~~
heretohelp
How quick exactly?

I've been testing ElasticSearch's geo location search and most queries take
50-150ms.

Standard term searches and filters will take like 5ms, with id GETs taking
mere fractions of that still.

~~~
whalesalad
Well, compared to your numbers, I guess not that quick. Django is responding
in 0.28 seconds. That is going over wifi to my server in a closet though. And
i'm downstairs kinda far from the router.

Screenshot: <http://wsld.me/J5zu>

If I hit it repeatedly for a while it comes back in as quick as 0.14, but
usually not that fast.

ping to server:

    
    
        michael at Achilles in ~
        ○ ping -c 5 apollo 
        PING apollo (192.168.1.130): 56 data bytes
        64 bytes from 192.168.1.130: icmp_seq=0 ttl=64 time=9.497 ms
        64 bytes from 192.168.1.130: icmp_seq=1 ttl=64 time=83.113 ms
        64 bytes from 192.168.1.130: icmp_seq=2 ttl=64 time=7.335 ms
        64 bytes from 192.168.1.130: icmp_seq=3 ttl=64 time=6.998 ms
        64 bytes from 192.168.1.130: icmp_seq=4 ttl=64 time=6.393 ms
    
        --- apollo ping statistics ---
        5 packets transmitted, 5 packets received, 0.0% packet loss
        round-trip min/avg/max/stddev = 6.393/22.667/83.113/30.241 ms

~~~
heretohelp
I'd call it good enough, I was of the understanding that SQL database geo
plugins were usually miserable. I'll add a mental exception for Postgres.

~~~
Argorak
I used PostGIS in proper GIS scenarios and it was faring quite well. The
advantage of PostGIS is that it supports all the index types you need
directly. And been around awhile, in a good sense.

------
zacharyvoase
> Think about a web developer who shows up to a hackathon, ready to break out
> his new side project. He doesn’t want to spend hours planning schema or
> creating databases and tables. He just wants a quick way to persist and
> retrieve data.

When you say that, this is what I hear:

> MongoDB is the quickest way to accrue large quantities of technical debt.

In this analogy, fast accrual of debt leads to one place: bankruptcy. Which,
in software engineering, is the ground-up rewrite.

~~~
zacharyvoase
I’m questioning whether it’s productive to consider _popularity_ when building
components that will underly the long-term architecture of other people’s
software. Overnight success can disappear as quickly as it arrives, and I, for
one, have a lower time preference for these things. I’d rather be responsible
for a tool that gains a lot of respect for being a robust, reliable and high-
performance piece of kit over a long period of time, than one which had
blazing popularity in the beginning but then proved to be the source of many a
developer’s nightmare later.

~~~
slurgfest
Popularity of a non-overnight type is one of the biggest reasons to use
something like Postgres or Rails: this means it gets beat on a lot, there is
documentation and you can find people who know how to use it.

Some projects with this kind of popularity (n.b.: not the ones I mentioned by
name) are designed like shit, do irrational things, have performance problems,
have security problems, whatever. But they have been used and they are usable
and you can find documentation and experts to deal with them.

------
zzzeek
> For 90% of web development cases, simply storing and retrieving objects from
> a persistent store is enough of an API.

"90%", that's quite a specific number.

Most of what I've written for the past fifteen years is web apps, and I'd say
about 10% fall into the "all I need is put and get objects" category.
Especially once I knew how to use SQL effectively, especially once I knew how
to work with ACID, these features became irreplaceable in almost every project
I've worked with.

IMHO it's all about what you're familiar with. Rich Hickey thinks we're morons
for using OOP, as he's a brilliant functional guy. Shrugs.

~~~
pytrin
Completely agree. Web development is simple, but it's not that simple.
Relationships between tables, and the ability to normalize and aggregate data
are very useful, _even_ for web development.

------
trimbo
> Think about a web developer who shows up to a hackathon [...] He just wants
> a quick way to persist and retrieve data.

This is the _worst_ reason to use Mongo.

If you are doing a hackathon or just prototyping and need persistence, use
pickle. Or store JSON to a text file. Who cares what the solution is. It
should:

a) Be built into the standard library. b) Not require bringing up another
service to work.

[Edit.. clarity in the quote]

~~~
nestlequ1k
That's the point. It's actually easier to use MongoDB than to store JSON in a
text file. And things move faster, and you still have the dream that you can
scale it up (even if 99% of the time it doesnt happen).

------
runT1ME
MongoDB does pretty much everything the opposite of Oracle: Easy to setup, use
and program.

However, Oracle sure is raking in the dough, so is Mongo succeeding simply
because they're fulfilling a niche left by Oracle, or because it's the 'right
way' to build a software product company?

I hope the answer is the latter, and that Oracle's billions are simply the
result of the being entrenched after years and years of doing it the 'old way.
That being said, I think it's a little too early to be championing Mongo's
business model (even though I'm rooting for it).

------
ndemoor
Although I am a heavy user/believer of MongoDB, one caveat that is overlooked
in this article is the administration part of Mongo Clusters.

Even the simplest replication needs 3 servers, add sharding to the dance for
extra performance and the server counter jumps up. For startups this is a
major decision to consider as a full-time ops guy isn't always affordable.
Luckily, PaaS services as MongoLabs and MongoHQ save the day.

~~~
taligent
I don't understand your point.

You could use replication (master/slave) with 2 servers and you don't have to
use sharding for anything. How is MongoDB not the same as every other database
?

If anything MongoDB is by far the easiest database I've ever used for setting
up clustering/sharding.

~~~
ndemoor
To have a legitimate replication setup, an arbiter node is highly recommended:
[http://docs.mongodb.org/manual/administration/replication-
ar...](http://docs.mongodb.org/manual/administration/replication-
architectures/#replica-set-arbiter-nodes)

------
sbt
I was nailed by MongoDB. It's a great database for prototyping, but all
projects that go anywhere run into its limitations: scale, durability,
intimate relationship with OS, ease of administration. MongoDB is right for
some projects, but in many cases is not. So if you know that you can
transition from it at a later point, it gets you off to a flying start. If you
foresee that it will be hard to switch later, I would advice spending some
time considering future scenarios upfront.

------
ukd1
Nailing community and ease of use (drivers for everything, easy to install)
and documentation wouldn't have been much use if the product sucked; it
doesn't.

A lot of people that I've seen with issues around Mongo haven't understood how
it's expected to be used: i.e. it's not a relational database and the schema
design is therefore different.

~~~
slurgfest
This might be because a lot of people have no idea what the viable use cases
are for all the million different new database-things there are. Because it
just isn't that clear unless you have used them all or are a total nerd for
the design of database software.

In this respect MongoDB is partly a victim of its own success - that means
more people using it who aren't sure what it's for, or who are led to believe
it's for something it's not really so hot at.

------
Timshel
Interestically someone just released a new async scala drivers :
<http://news.ycombinator.com/item?id=4454077>

