
MongoDB, Better - technel
http://go.rackspace.com/better.html
======
yanowitz
If you're stuck with mongo in legacy infrastructure and it doesn't make sense
to refactor/architect it away, I suggest tokumx. It's allowed us to kick the
can on this problem for at least another year. Almost no lock contention, far
more compact on disk (even cheap disk space adds up) and (what seems to be) a
growing set of users.

I'm optimistic that pg9.4 will be our migration path. But regardless, tokumx
has given us the breathing room to defer the decision.

~~~
mikegioia
I was considering tokumx because it seems like scaled better than normal
mongodb but to be honest I'd love to move of this database entirely. I'm
somewhat unfamiliar with postgres but does it have a storage/querying system
comparable to mongo?

~~~
munro
If you want to store & query JSON [1], Postgres 9.3 is great! Plus you can
index functions, meaning you get cool things like fast JSON look up, and doing
case insensitive searches. Which is hard in Mongo, you would either have to do
a slow regexp look up, or save a lower case version in your application logic.

    
    
      CREATE INDEX ON members ((lower(my_json_data->>'email')));
    

[1] [http://www.postgresql.org/docs/9.3/static/functions-
json.htm...](http://www.postgresql.org/docs/9.3/static/functions-json.html)

------
gtrubetskoy
This sums up MongoDB pretty well: [http://nyeggen.com/blog/2013/10/18/the-
genius-and-folly-of-m...](http://nyeggen.com/blog/2013/10/18/the-genius-and-
folly-of-mongodb/)

~~~
bronson
That's the best summary of MongoDB I've ever seen. Thanks!

(It's not full of vitriol and strawmen like most of the Mongo posts that seem
to end up here.)

------
harlowja
I wonder how licensing works here with mongodb being AGPL.

A message I proxied recently: [http://lists.openstack.org/pipermail/openstack-
dev/2014-Marc...](http://lists.openstack.org/pipermail/openstack-
dev/2014-March/030510.html)

~~~
epoxyhockey
Yahoo isn't the only large company to instruct its employees to avoid mongodb
due to it being AGPL. In my opinion, the only people using mongodb in a
commercial setting are those who are paying 10gen for a commercial license or
those that don't know they are violating the AGPL license.

~~~
alrs
???

Most people in a commercial setting aren't modifying the MongoDB source code.
AGPL does not require that any software that communicates with AGPL software
be AGPL'd.

But yes, if you're using MongoDB in a commercial endeavor, and you modify the
source code, and you're using AGPL version, you do need to share your changes
to the MongoDB source code.

~~~
nemothekid
As I understand it, the drivers are a point of contention, and the parent's
parent explains it well.

Technically, according the AGPL, MongoDB's database drivers licenses (apache)
are _incompatible_ with AGPL, and technically should be licensed under AGPL.
Now the parent says that should be fine for official drivers because MongoDB
isn't going to sue themselves, but the issue is for community drivers, like
the Node Driver or the Golang driver. Since the AGPL states that any software
built for the exclusive use for the accompanying software must be AGPL - then
it follows that community drivers should be AGPL as well.

To me that means not only can you not modify the database, but you cannot
modify the drivers. And I'm also unsure if that also means that any
applications that link those drivers means that they must be AGPL as well. And
if your web application must be AGPL, it also means that the source of
whatever service you are providing must be available as well. So in a way it
doesn't just affect corporations that want to modify Mongo, it affects
everyone who wants to use Mongo (with a community driver atleast).

IANAL

~~~
ithkuil
The copyright holder can issue multiple licences for a given product.

It's not about suing themselves'.

------
dkhenry
I would love to see a use case from a large deployment. MongoDB is trivial at
small scale and it is only when you get to large deployments that it really
needs some TLC. If they can somehow make large deployments simple it might
make mongo a viable contender again for Humongous data ( If you have a data
schema that would play nicely with it )

~~~
AdrianRossouw
i would love to see a solid technical reason to choose mongodb over any of the
other NoSQL db's (couchdb, riak, redis, etc..) other than "it's popular".

No, I'm not trolling. I really want to know :
[https://news.ycombinator.com/item?id=7446919](https://news.ycombinator.com/item?id=7446919)

~~~
nevi-me
Geolocation, specifically GeoJSON. That's the main reason why I chose it (I
started working on my app while it was at 2.0). When 2.4 came out with better
geospatial indices (albeit basic compared to PostgreSQL+PostGIS) and GeoJSON
support, I moved to using GeoJSON, and I am happy so far.

The website/app is at [https://rwt.to](https://rwt.to) , and an example route
search is; from "Milky Way, Johannesburg" to "O.R. Tambo International
Airport".

I should note that I've had a look at geocouch and it didn't fit my use case,
I'm not doing trivial 'find my 3 places near [y,x]' queries, but am traversing
a pseudo-network of routes to calculate directions. Neo4j also wouldn't have
worked in my case. TokuMX is based on MongoDB 2.2 as far as I'm aware, so them
too.

~~~
AdrianRossouw
That's a very good reason, and the first real one I have heard, thanks man.

Also, I used to work for MapBox, and I know we did one project on mongo which
I was not involved in, and afterwards we built everything with CouchDB (which
is how I got acquainted with it).

For the geo stuff we actually used a lot of sqlite and to a lesser extent
spatialite. We would pre-calculate things and build them into the rendered
tiles in mbtiles format, or stream the point/polygon data from the couch
database for realtime client-side compositing.

But yeah, routing is pretty high level stuff. I think they are only now
putting the finishing touches on their openstreetmap driven routing system
many years later.

[1] [http://mapbox.com](http://mapbox.com)

------
emperorcezar
None of this means anything unless there is clear pricing. Am I not seeing it?

~~~
saryant
[http://objectrocket.com/pricing](http://objectrocket.com/pricing)

~~~
mason55
Seems a bit expensive assuming each shard gets you three more servers. Based
on RS pricing you could build your own instances with 1TB SSDs for like $500
each, so for the same price that you'd get 100GB x 3 shards you could do 1TB x
3 shards on your own. I guess with the RS pricing you also get managed backups
but IMO that's not worth the price difference. If you figure you build your
own, 3 shards x 3 RS members x 1TB is 9 servers at $500 each or $4500. With
this service... if 100GB is $1599 you have to imagine 1TB has to be at least
on the order of $10k, so you're looking at $30k total. $25k a month for
managed backups and infrastructure just doesn't seem worth it to me. Maybe
what they're using is more powerful than the instances we're on but I still
have trouble reconciling the pricing. And if that 1TB is 1TB total and not 1TB
per shard/replica set member then the pricing looks way, way worse.

~~~
kapilvt
Rackspace did an evaluation of the various mongodb hosted solutions before
buying out objectrocket.. Its worth a read
[http://developer.rackspace.com/blog/benchmarking-hosted-
mong...](http://developer.rackspace.com/blog/benchmarking-hosted-mongodb-
services.html#.US4EhzCcfl8)

TLDR, for hosted mongodb its pretty awesome (ssd hardware in direct connect
locations, tuned and managed).

~~~
mason55
That's an awesome link, thanks. Does a lot to clarify where the pricing
disconnect is between spinning up my own servers in the RS cloud and using
ObjectRocket.

IMO RS's ObjectRocket pages should do a better job showing what you're getting
on top just deploying to a bunch of RS cloud servers with SSD's in them.

~~~
jrarredondo
Mason55, I work for Rackspace. The ObjectRocket service does not run on the
cloud servers you get from RS. It's actually a different architecture just for
MongoDB: flash drives all over, containers, pretty much tuned for MongoDB
across the stack. While we don't describe the full details of the
architecture, you have a very valid recommendation that we will take into
consideration to make sure it is clear what you are getting for your money.
Thanks.

~~~
mason55
Thanks for the additional info, great to have someone from RS chime in!

------
taude
Funny, only seconds after clicking on the OP page, I started getting the
targeted Ads for MongoDB & Rackspace when visiting YouTube videos.

------
jasonmccay
Isn't this just a link to an advertisement?

------
putlake
We use MongoDirector and have been pretty happy with it. They have a Bring
Your Own AWS infra plan that works perfect.

------
endijs
Sometimes I wonder - what's hated more by HN readers... PHP or MongoDB... And
what's not fun - i use both.

------
cordite
Is this like MongoHQ?

~~~
jasonmccay
Sort of ... but there are pretty serious limitations.

1\. You are locked into Rackspace as your provider. MongoHQ provides multiple
cloud providers.

2\. They force you to shard. This increases operational and application
complexity ... and may not offer any real advantages for the amount of data
that you have.

~~~
jrarredondo
I work for Rackspace.

On [1], you can actually keep your app in AWS and connect / migrate your data
to OR over Direct Connect.

On [2], you don't have to shard. There is an option to scale vertically when
you need to.

You can call RS people who can help guide you making the best decision on [1]
or [2] based on your current and future situations.

