I feel like there is a lot of context missing for some of these slides. Will there be video available of the talk?
A Year of MongoDB
71–80 of 133 posts
Re: A Year of MongoDB
#72Earlier quoted context omitted.
Please don't conflate MongoDB and NoSQL. NoSQL is about the right tool for the job. For instance many of our Couchbase customers are very technical and risk averse. They choose Couchbase because other solutions (often MySQL or Oracle) have become the wrong tool for the job, as requirements change. Mongo is a little different bc they actively position themselves as a MySQL replacement for your average Rails app.
"NoSQL is about the right tool for the job." I never liked that rationale: * The job almost certainly will change. Data lives a long time, usually much longer than the original application. * It's likely to conflate marketing claims with actual fitness for a purpose. A special-purpose system with special-purpose marketing may sound great if the special case lines up with what you're doing. But that doesn't mean that…
I just don't like the "right tool for the job" argument.
There is no ONE database that works perfectly in every situation.
Re: A Year of MongoDB
#73Re: A Year of MongoDB
#74A few comments on the problems: * CPU bottleneck. The mongod is no usually bound by CPU except for building indexes on existing data (which shouldn't really happen in production). The issue he's talking about is contention between the web server (or workers) and the mongos. This isn't anything unexpected. It's recommended to put the mongos onto the application server and then you scale this by adding CPUs initially b…
> PIOPs are the way around this but local instance storage is also an option. PIOP is not ringing a bell - I'll stick my neck out and ask what it is.
Amazon EBS Provisioned IOPS. Standard EBS gives around 100 IOPS (Input/Output Operations Per Second). With PIOP you can get more if you pay more.
Re: A Year of MongoDB
#75I'm a little blown away by the total lack of technical understanding when it comes to MongoDB. This person is obviously very technical, so why would he have chosen MongoDB in the first place? It isn't like MongoDb's technical shortcomings are a secret. The description of how MongoDb does sharding and distributed queries should have immediately raised red flags to any who has even a modicum of CAP understanding. If it…
If a database lost data in a single server configuration, why would you trust it as a cluster?
To this day Foursquare who are the ones referred to in the article still use MongoDB:
http://engineering.foursquare.com/2012/11/27/mongodb-at-four...
Re: A Year of MongoDB
#76This is the problem with most of the guys who go with MongoDB. Obviously, this person is very technical, so I am not flaming him nor accusing him, but this is my view of the rest of them who pick MongoDB without exactly having a clue as to why (hipsters) or when they should use a NoSQL db and when they shouldn't. I do not hesitate to admit that I was a hipster sometime back too. I chose MongoDB for many of my project…
Disclaimer, I work for RethinkDB a competitor of MongoDB. I completely agree with you that NoSQL is not a pure-white solution but I disagree that it's only useful for specific use-cases. NoSQL has frequently been touted as this magic concept that makes databases scale well. It doesn't as many of the poorly scaling NoSQL databases on the market today show you. The most you can say is that it maybe lets you ignore a fe…
Isn't Google BigQuery a SQL on top of a schemaless database ?
Re: A Year of MongoDB
#77Sounds like rethinkDB would be the answer to our prayers. How close is it to being "ready"?
slava@rethink here -- we're working with a small group of early customers (providing support, driving product direction, etc.) If you're interested in working together, shoot me an e-mail -- slava@rethinkdb.com
Re: A Year of MongoDB
#78This is the problem with most of the guys who go with MongoDB. Obviously, this person is very technical, so I am not flaming him nor accusing him, but this is my view of the rest of them who pick MongoDB without exactly having a clue as to why (hipsters) or when they should use a NoSQL db and when they shouldn't. I do not hesitate to admit that I was a hipster sometime back too. I chose MongoDB for many of my project…
All I can say is this: if the saying "Always plan to throw away your MVP" is true, then I can't see any other storage solution other than MongoDB (or a similar schema-less document storage DB) for MVPs. The speed of development and flexibility are simply worth it. Yes, it is hard to refactor a live product and move it from MongoDB to MySQL / Postgre but was done before and you only do that if you get traction, so its…
Couldn't agree more.
I've worked for 15 years with relational databases and for the recent 6 months with mongodb on my startup. For me, the agility of not having to define my data in advance, and "work" so much to explain the DBMS how my schema should behave is no less than a game changer in my ability to build the MVP quickly. I just can't imagine having to invest all the labor in having to model everything I did with a normalized database and ORM.
Re: A Year of MongoDB
#79Earlier quoted context omitted.
No , there is something specific to MongoDB. Some NoSQL dbs are fine for some purposes ( multi-master sync for couchdb ,graphs for Neo4j ... ) MongoDB problem is that it promises too much and fail to deliver on a lot of levels. You cant expect to do all the operations one can do on a RDBMS on a NoSQL database and still scale horizontally,while maintaining data integrity. A good NoSQL db should have little features ,…
You are pretty violent against MongoDB. Any reason why?
I suspect the reason that Mongo attracts so much hate is that it's more heavily marketed/evangelised than other NoSQL DBs - so more in the public eye and people expect more from it. Since the reality is that Mongo is not yet a technically strong product (regardless of its merits in terms of ease of use and getting simple things done quickly), it's bound to attract more negative attention.
Re: A Year of MongoDB
#80After 6 intensive months with MongoDB to build my MVP, I just love it.
For sure, it's not perfect. Lack of joins is a shame, but can be quite easily solved outside the database.
But the ease of use and speed of development are such a HUGE advantage. Not having to break my schema into normalized relations and define it in the DB saved me literally days of work.
I can imagine a case that 1 year from now, when our product will be more mature, we'll be leaving mongodb for another SQL or No-SQL database. Doesn't matter. The benefit that mongodb gives us now justifies the costs the may be incurred years from now.