7 ms·

MongoDB, Better

67 points by technel 12y ago

dkhenry 12y ago
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 12y ago
  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
  - mikegioia 12y ago
    It allows you to query json documents in a way similar to sql. redis is key/val and sits in ram, couch requires complicated design documents to query and is better as a key/val, but I'm unfamiliar with riak. I think trello uses mongo primarily for production. technically it's feasible but I've found it to be more trouble than it's worth to scale -- too many machines are required per shard. I'm currently looking into rethink db as a replacement now though.
    - AdrianRossouw 12y ago
      I use elasticsearch to index my couch database and query it using the rest based json query language. i find it helps being able to scale them out separately too. http://daemon.co.za/2012/05/replacing-couchdb-views-with-elasticsearch/ http://daemon.co.za/2012/05/replacing-couchdb-views-with-ela...
      - h1karu 12y ago
        There's no need to go through all of that trouble.. Why not just use Cloudant until the BigCouch merge hits ? :)
        AdrianRossouw 12y ago
        Trouble? It's a single REST request to get a couch database continued indexed in elasticsearch in almost 'real-time'. It just subscribes to the _changes feed and updates the index, in the same way couch replication works.
        h1karu 12y ago
        I spoke too soon, seems pretty bad ass in that case. gotta love _changes
        AdrianRossouw 12y ago
        yeah, it's totally overpowered. =)
      - brickcap 12y ago
        Hey Adrian I have got a question. Why did you chose elastic search for indexing couchdb data. Why not couchdb-lucene? Couchdb-lucene seems more tightly integrated with couchdb to to me.
        AdrianRossouw 12y ago
        I think it wasn't 'ready' at that point in time, and the json based query language was closer to what we needed. The real problem was that the data was being imported in bulk by the user, from a many-meg-sized csv . It would grind couchdb to a halt trying to build views, so having elasticsearch be a separate process that could work through it made a lot of sense.
        12y ago
  - timfpark 12y ago
    i think a lot of the reasons I've seen come down to business reasons, not technical. Someone wants an app fast, like now, and MongoDB is fast to setup and get running with.
    - AdrianRossouw 12y ago
      I guess I'll be able to confirm once I'm forced to build something in it, but I don't think it can really be faster to setup and get running with than CouchDB. Usually first thing you need to do is write a REST layer on top of it, and with CouchDB that part is just done already. Obviously there's certain kinds of data I wouldn't put in Couch, or any kind of NoSQL database. You need to know what the right tool for the job is,but I just want to figure out when that tool is mongo.
      - h1karu 12y ago
        Why would that tool ever be mongo ? I think Mongo is a thing because people coming from Rails ORM libraries feel like "wow I can jump on the no-sql bandwagon just by using a library that feels kind of like the ActiveRecord I'm used to". It's only popular because there's less of a conceptual gap between mongo and the relational database tools that a lot of people are used to. Couchdb on the other hand requires you to actually learn and use map/reduce.. which is a pain for people who don't feel like having to learn something new, but Couchdb is MUCH MUCH better in a lot of ways and Mongo is pretty much fundamentally flawed in my opinion I do wish rackspace luck though with their offering. I think it was smart of them to create this mongodb product for one simple reason: a good number of people are already using mongodb so it makes sense to help them get the most out of it.
      - timfpark 12y ago
        i didn't mean to say that MongoDB was the only database with that property. Yes, CouchDB does as well.
  - nevi-me 12y ago
    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 12y ago
      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
  - nemothekid 12y ago
    I would consider "Its easy to get started with" a valid technical reason. Of all the "We moved from MongoDB to Cassandra/Riak/etc and gained massively!" I've rarely seen - and its possible that this is selection bias - companies start with the other NoSQL options. I want to say, that unlike MongoDB - the others actually force you to think about your data and actively decide how you are going to store it. With MongoDB you can pretty much add an index on anything, but with Cassandra (maybe Riak/Dynamo too) you only get one free index before you have to denormalize and write application code to keep your performance. Then lastly, MongoDB is good enough for most use cases. We didn't see major performance issues until we started constantly writing data to it (high write/low read) (basically we were wrestling with lock contention). I'd wager for a significant amount of MongoDB deployments, not only is Mongo easy to use, but fast enough too. So while the other NoSQLs are (probably) more complicated and likely more performant, MongoDB, to me, hits a sweet spot of ease of use and performance that is good enough for most applications out there. However, considering other "raw" technical aspects like performance, durability and scaling I've never seen anything that has shown MongoDB to be a leader.
    - AdrianRossouw 12y ago
      Well, it's the opposite perception here. "I've rarely seen - and its possible that this is selection bias - companies start with the other NoSQL options." It seems like everyone starts with Mongo, because everyone starts with Mongo. This means that you don't have the deluge of posts from people moving from other databases, a) there are much fewer of them b) they chose them for solid technical reasons (not just because everyone does this) So as for your perception that other NOSQL databases are "probably" more complicated, you should know that complexity is an objective measure. I think that mongo is definitely a lot more objectively complex than couchdb, and from what I have read around the subject, many of the other NoSQL databases. What Mongo could well be is 'easier', which is relative. It seems like it's more familiar to certain programmers, which is kind of echoed by the fact that there's an incredibly popular object relational mapper (mongoose), that is being used with what is supposedly a non-relational database. I use those terms in a very specific sense btw, which I documented here - http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-describe-software-complexity http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-de... It's from a very insightful presentation by the creator of the Clojure language, and I only wrote a summary because I got sick of trying to get people to watch an hour-long video before trying to discuss systems on this level.
- victorhooi 12y ago
  I'm sorry, but this seems a bit of a lazy question. There are many large-scale deployments of MongoDB - a simple Google search will yield you results. Off the top of my head - FourSquare, Stripe, ServerDensity, eBay (non-site) etc. MongoDB (the company) also uses it for MMS - their cloud-based monitoring system, which probably handles hundreds of thousands of metrics every second from tens of thousands of hosts. So yes, there is a lot of FUD about "it doesn't scale" etc. Most of the FUD seems to originate from people not reading the manual, and completely misconfiguring things, and wondering why it doesn't work. To be fair, most competing products (Riak, Couch etc.) will scale enough for most people. So this is sort of a red herring. (And by the point that you are as big as FourSquare, the assumption is you'll probably hire engineers who will read the manual =) ). So the decision boils down to other things - how easy is the query language, do you need GeoJSON support, do you need aggregations, how mature is the overall ecosystem etc. And that's why people are picking MongoDB - not really the WOAH, LOOK AT THE OPS PER SECOND!.
  - camus2 12y ago
    > Most of the FUD seems to originate from people not reading the manual, and completely misconfiguring things, and wondering why it doesn't work. Most of the FUD comes from the deceptive marketing 10gen used to promote MongoDB. It now has a well deserved bad reputation that will never go away,no matter how much startup choosed it.
    - victorhooi 12y ago
      What deceptive marketing exactly? Could you cite an example please? For example, there was noise before about how MongoDB was allegedly tweaking benchmarks. The funny thing was, from what I've read, they've always had a policy of never ever publishing official benchmarks. Their line was, read the manual, and try it with your own data. Are you aware of any "deceptive marketing"?
      - camus2 12y ago
        Are you aware of any FUD ? then ask yourself where it comes from. MongoDB is a bad database,If you care about your datas you shouldnt use it.
- nasalgoat 12y ago
  I managed one of the largest MongoDB installations and I can safely say running it at scale is extremely difficult. They've made a few changes, like not hardcoding the maximum number of connections and shards anymore, which helps but overall the big problems like database-level locking are serious problems even a year later. The reasons for choosing it were very simple - the lead developer was familiar with JSON and liked using it for queries, and he liked the "schema-less" nature of document storage. No consideration was given to performance or scaling issues, it was purely a comfort level decision.
  - dkhenry 12y ago
    Right and rackspace is claiming they are taking care of all that for me. Or are they just spinning up hosts and I still need to configure everything
harlowja 12y ago
I wonder how licensing works here with mongodb being AGPL. A message I proxied recently: http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html http://lists.openstack.org/pipermail/openstack-dev/2014-Marc...
- epoxyhockey 12y ago
  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.
  - yeukhon 12y ago
    > 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. It is not clear to me exactly what the problem is from the message. Are we now discouraged to use MongoDB as a database (from startup to university), or writing MongoDB database driver based on existing MongoDB language driver such as pymongo or writing on top of MongoDB's database driver?
    - harlowja 12y ago
      I think the followup from yahoo 'might' help: http://lists.openstack.org/pipermail/openstack-dev/2014-March/030593.html http://lists.openstack.org/pipermail/openstack-dev/2014-Marc...
      - yeukhon 12y ago
        Yeah that definitely helps clarifying the issue, I think. As long as Openstack only use Apache licensed code >>from MondgoDB Inc.<< and diligently avoids using any open source contributions from any community contributor to the MongoDB ecosystem, then you remain compliant the your CLA. I wouldn't have known the APGL licensed database and the conflict with MongoDB, Inc. licensed code and community code. I guess now all ORM built upon pymongo used in commercial settings is that trouble zone then? This is a huge bummer. Definitely an alert for those looking forward to use MongoDB at commercial settings as parent said.
yanowitz 12y ago
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 12y ago
  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 12y ago
    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.html http://www.postgresql.org/docs/9.3/static/functions-json.htm...
- deleted 12y ago
  [deleted]
  - kev009 12y ago
    I wager it's reasonable to consider it anything not consistent with _your_ _current_ architectural culture/guidelines. Some examples using this definition: * CICS on an IBM System Z might be considered legacy to one group and platform to another. * Ruby might be legacy at Twitter but isn't elsewhere.
    - 12y ago
emperorcezar 12y ago
None of this means anything unless there is clear pricing. Am I not seeing it?
- saryant 12y ago
  http://objectrocket.com/pricing http://objectrocket.com/pricing
  - mason55 12y ago
    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 12y ago
      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-mongodb-services.html#.US4EhzCcfl8 http://developer.rackspace.com/blog/benchmarking-hosted-mong... TLDR, for hosted mongodb its pretty awesome (ssd hardware in direct connect locations, tuned and managed).
      - mason55 12y ago
        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.
gtrubetskoy 12y ago
This sums up MongoDB pretty well: http://nyeggen.com/blog/2013/10/18/the-genius-and-folly-of-mongodb/ http://nyeggen.com/blog/2013/10/18/the-genius-and-folly-of-m...
- bronson 12y ago
  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.)
cordite 12y ago
Is this like MongoHQ?
- jasonmccay 12y ago
  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 12y ago
    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.
putlake 12y ago
We use MongoDirector and have been pretty happy with it. They have a Bring Your Own AWS infra plan that works perfect.
jasonmccay 12y ago
Isn't this just a link to an advertisement?
deleted 12y ago
[deleted]
endijs 12y ago
Sometimes I wonder - what's hated more by HN readers... PHP or MongoDB... And what's not fun - i use both.
taude 12y ago
Funny, only seconds after clicking on the OP page, I started getting the targeted Ads for MongoDB & Rackspace when visiting YouTube videos.

67 points by technel 12y ago

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 12y ago
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
- mikegioia 12y ago
  It allows you to query json documents in a way similar to sql. redis is key/val and sits in ram, couch requires complicated design documents to query and is better as a key/val, but I'm unfamiliar with riak. I think trello uses mongo primarily for production. technically it's feasible but I've found it to be more trouble than it's worth to scale -- too many machines are required per shard. I'm currently looking into rethink db as a replacement now though.
  - AdrianRossouw 12y ago
    I use elasticsearch to index my couch database and query it using the rest based json query language. i find it helps being able to scale them out separately too. http://daemon.co.za/2012/05/replacing-couchdb-views-with-elasticsearch/ http://daemon.co.za/2012/05/replacing-couchdb-views-with-ela...
    - h1karu 12y ago
      There's no need to go through all of that trouble.. Why not just use Cloudant until the BigCouch merge hits ? :)
      - AdrianRossouw 12y ago
        Trouble? It's a single REST request to get a couch database continued indexed in elasticsearch in almost 'real-time'. It just subscribes to the _changes feed and updates the index, in the same way couch replication works.
        h1karu 12y ago
        I spoke too soon, seems pretty bad ass in that case. gotta love _changes
        AdrianRossouw 12y ago
        yeah, it's totally overpowered. =)
    - brickcap 12y ago
      Hey Adrian I have got a question. Why did you chose elastic search for indexing couchdb data. Why not couchdb-lucene? Couchdb-lucene seems more tightly integrated with couchdb to to me.
      - AdrianRossouw 12y ago
        I think it wasn't 'ready' at that point in time, and the json based query language was closer to what we needed. The real problem was that the data was being imported in bulk by the user, from a many-meg-sized csv . It would grind couchdb to a halt trying to build views, so having elasticsearch be a separate process that could work through it made a lot of sense.
        12y ago
- timfpark 12y ago
  i think a lot of the reasons I've seen come down to business reasons, not technical. Someone wants an app fast, like now, and MongoDB is fast to setup and get running with.
  - AdrianRossouw 12y ago
    I guess I'll be able to confirm once I'm forced to build something in it, but I don't think it can really be faster to setup and get running with than CouchDB. Usually first thing you need to do is write a REST layer on top of it, and with CouchDB that part is just done already. Obviously there's certain kinds of data I wouldn't put in Couch, or any kind of NoSQL database. You need to know what the right tool for the job is,but I just want to figure out when that tool is mongo.
    - h1karu 12y ago
      Why would that tool ever be mongo ? I think Mongo is a thing because people coming from Rails ORM libraries feel like "wow I can jump on the no-sql bandwagon just by using a library that feels kind of like the ActiveRecord I'm used to". It's only popular because there's less of a conceptual gap between mongo and the relational database tools that a lot of people are used to. Couchdb on the other hand requires you to actually learn and use map/reduce.. which is a pain for people who don't feel like having to learn something new, but Couchdb is MUCH MUCH better in a lot of ways and Mongo is pretty much fundamentally flawed in my opinion I do wish rackspace luck though with their offering. I think it was smart of them to create this mongodb product for one simple reason: a good number of people are already using mongodb so it makes sense to help them get the most out of it.
    - timfpark 12y ago
      i didn't mean to say that MongoDB was the only database with that property. Yes, CouchDB does as well.
- nevi-me 12y ago
  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 12y ago
    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
- nemothekid 12y ago
  I would consider "Its easy to get started with" a valid technical reason. Of all the "We moved from MongoDB to Cassandra/Riak/etc and gained massively!" I've rarely seen - and its possible that this is selection bias - companies start with the other NoSQL options. I want to say, that unlike MongoDB - the others actually force you to think about your data and actively decide how you are going to store it. With MongoDB you can pretty much add an index on anything, but with Cassandra (maybe Riak/Dynamo too) you only get one free index before you have to denormalize and write application code to keep your performance. Then lastly, MongoDB is good enough for most use cases. We didn't see major performance issues until we started constantly writing data to it (high write/low read) (basically we were wrestling with lock contention). I'd wager for a significant amount of MongoDB deployments, not only is Mongo easy to use, but fast enough too. So while the other NoSQLs are (probably) more complicated and likely more performant, MongoDB, to me, hits a sweet spot of ease of use and performance that is good enough for most applications out there. However, considering other "raw" technical aspects like performance, durability and scaling I've never seen anything that has shown MongoDB to be a leader.
  - AdrianRossouw 12y ago
    Well, it's the opposite perception here. "I've rarely seen - and its possible that this is selection bias - companies start with the other NoSQL options." It seems like everyone starts with Mongo, because everyone starts with Mongo. This means that you don't have the deluge of posts from people moving from other databases, a) there are much fewer of them b) they chose them for solid technical reasons (not just because everyone does this) So as for your perception that other NOSQL databases are "probably" more complicated, you should know that complexity is an objective measure. I think that mongo is definitely a lot more objectively complex than couchdb, and from what I have read around the subject, many of the other NoSQL databases. What Mongo could well be is 'easier', which is relative. It seems like it's more familiar to certain programmers, which is kind of echoed by the fact that there's an incredibly popular object relational mapper (mongoose), that is being used with what is supposedly a non-relational database. I use those terms in a very specific sense btw, which I documented here - http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-describe-software-complexity http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-de... It's from a very insightful presentation by the creator of the Clojure language, and I only wrote a summary because I got sick of trying to get people to watch an hour-long video before trying to discuss systems on this level.
victorhooi 12y ago
I'm sorry, but this seems a bit of a lazy question. There are many large-scale deployments of MongoDB - a simple Google search will yield you results. Off the top of my head - FourSquare, Stripe, ServerDensity, eBay (non-site) etc. MongoDB (the company) also uses it for MMS - their cloud-based monitoring system, which probably handles hundreds of thousands of metrics every second from tens of thousands of hosts. So yes, there is a lot of FUD about "it doesn't scale" etc. Most of the FUD seems to originate from people not reading the manual, and completely misconfiguring things, and wondering why it doesn't work. To be fair, most competing products (Riak, Couch etc.) will scale enough for most people. So this is sort of a red herring. (And by the point that you are as big as FourSquare, the assumption is you'll probably hire engineers who will read the manual =) ). So the decision boils down to other things - how easy is the query language, do you need GeoJSON support, do you need aggregations, how mature is the overall ecosystem etc. And that's why people are picking MongoDB - not really the WOAH, LOOK AT THE OPS PER SECOND!.
- camus2 12y ago
  > Most of the FUD seems to originate from people not reading the manual, and completely misconfiguring things, and wondering why it doesn't work. Most of the FUD comes from the deceptive marketing 10gen used to promote MongoDB. It now has a well deserved bad reputation that will never go away,no matter how much startup choosed it.
  - victorhooi 12y ago
    What deceptive marketing exactly? Could you cite an example please? For example, there was noise before about how MongoDB was allegedly tweaking benchmarks. The funny thing was, from what I've read, they've always had a policy of never ever publishing official benchmarks. Their line was, read the manual, and try it with your own data. Are you aware of any "deceptive marketing"?
    - camus2 12y ago
      Are you aware of any FUD ? then ask yourself where it comes from. MongoDB is a bad database,If you care about your datas you shouldnt use it.
nasalgoat 12y ago
I managed one of the largest MongoDB installations and I can safely say running it at scale is extremely difficult. They've made a few changes, like not hardcoding the maximum number of connections and shards anymore, which helps but overall the big problems like database-level locking are serious problems even a year later. The reasons for choosing it were very simple - the lead developer was familiar with JSON and liked using it for queries, and he liked the "schema-less" nature of document storage. No consideration was given to performance or scaling issues, it was purely a comfort level decision.
- dkhenry 12y ago
  Right and rackspace is claiming they are taking care of all that for me. Or are they just spinning up hosts and I still need to configure everything

harlowja 12y ago

I wonder how licensing works here with mongodb being AGPL. A message I proxied recently: http://lists.openstack.org/pipermail/openstack-dev/2014-March/030510.html http://lists.openstack.org/pipermail/openstack-dev/2014-Marc...

epoxyhockey 12y ago
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.
- yeukhon 12y ago
  > 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. It is not clear to me exactly what the problem is from the message. Are we now discouraged to use MongoDB as a database (from startup to university), or writing MongoDB database driver based on existing MongoDB language driver such as pymongo or writing on top of MongoDB's database driver?
  - harlowja 12y ago
    I think the followup from yahoo 'might' help: http://lists.openstack.org/pipermail/openstack-dev/2014-March/030593.html http://lists.openstack.org/pipermail/openstack-dev/2014-Marc...
    - yeukhon 12y ago
      Yeah that definitely helps clarifying the issue, I think. As long as Openstack only use Apache licensed code >>from MondgoDB Inc.<< and diligently avoids using any open source contributions from any community contributor to the MongoDB ecosystem, then you remain compliant the your CLA. I wouldn't have known the APGL licensed database and the conflict with MongoDB, Inc. licensed code and community code. I guess now all ORM built upon pymongo used in commercial settings is that trouble zone then? This is a huge bummer. Definitely an alert for those looking forward to use MongoDB at commercial settings as parent said.

yanowitz 12y ago

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 12y ago
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 12y ago
  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.html http://www.postgresql.org/docs/9.3/static/functions-json.htm...
deleted 12y ago
[deleted]
- kev009 12y ago
  I wager it's reasonable to consider it anything not consistent with _your_ _current_ architectural culture/guidelines. Some examples using this definition: * CICS on an IBM System Z might be considered legacy to one group and platform to another. * Ruby might be legacy at Twitter but isn't elsewhere.
  - 12y ago

emperorcezar 12y ago

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

saryant 12y ago
http://objectrocket.com/pricing http://objectrocket.com/pricing
- mason55 12y ago
  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 12y ago
    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-mongodb-services.html#.US4EhzCcfl8 http://developer.rackspace.com/blog/benchmarking-hosted-mong... TLDR, for hosted mongodb its pretty awesome (ssd hardware in direct connect locations, tuned and managed).
    - mason55 12y ago
      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.

gtrubetskoy 12y ago

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

bronson 12y ago
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.)

cordite 12y ago

Is this like MongoHQ?

jasonmccay 12y ago
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 12y ago
  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.

putlake 12y ago

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

jasonmccay 12y ago

Isn't this just a link to an advertisement?

deleted 12y ago

[deleted]

endijs 12y ago

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

taude 12y ago

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