Sounds like rethinkDB would be the answer to our prayers. How close is it to being "ready"?
A Year of MongoDB
11–20 of 133 posts
Re: A Year of MongoDB
#12I'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…
Sometimes the decision of what technology to use and the task of making it work for your needs are entirely disconnected.
Unless you make a technology decision without understanding what you need to make it work.
Re: A Year of MongoDB
#13I'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…
Because developers without significant database / data store experience are choosing where to put their data because its "easy to use".
Yes, RBDMS and similar approaches are difficult to work with [1] and introduce "impedance mismatch". Yes joins can be slow. Yes scaling can be difficult and or expensive. But, when choosing where to put data without understanding (or accepting) why the above is difficult is only asking history to repeat itself.
[1] "Database guy here". I know databases and SQL. I would not consider choosing what language to implement a web application tier on, because I don't have enough relevant experience. I focus on what I have battle experience in.
Re: A Year of MongoDB
#14A 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 but then by adding multiple application nodes and using a load balancer. Or perhaps splitting the mongos onto dedicated nodes?
* Virtualisation: VMs are notorious for having variable performance because you have the overhead of the hypervisor but more importantly, are sharing resources with others. We run performance critical apps on dedicated servers and reserve VMs for tools or things which aren't high throughput e.g. a MongoDB arbiter.
* EBS: This has had known performance issues for years. It's fine as a basic file store but should never be used for databases. PIOPs are the way around this but local instance storage is also an option.
* No transactions: MongoDB has never had them. This is known.
* Schemaless != no schema design. It makes it easy to play around but you still need to think through things carefully. See http://blog.serverdensity.com/mongodb-schema-design-pitfalls...
* No joins. Again, it has never had joins. This is known.
Re: A Year of MongoDB
#15I think that some people misunderstand the primary purpose of Schema-less design. It's not about typing, it's about document flexibility. It's about getting rid of EAV tables (read: Magento) and storing document-specific information. Typing obviously comes into play, but is only half the topic.
If you are building a system where the schema is the same for all records, then you really shouldn't be using Schema-less design.
Re: A Year of MongoDB
#16A 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…
Agreed on all counts. Sounds like he is complaining more about issues with VM performance than MongoDB performance on VMs.
The joins statement kills me. If somehow the database design requires joins, Mongo is fast enough to run two queries and then let you work with them in code.
Re: A Year of MongoDB
#17Sounds like rethinkDB would be the answer to our prayers. How close is it to being "ready"?
Seems RethinkDB is still relational. Meh.
If you're using C#, I'd recommend RavenDB.
Re: A Year of MongoDB
#18Sounds like 90% of your problems could have been solved if you'd spent a day or two researching what you were about to build your entire company around.
Sounds like the "We Fail" slide might be the most accurate one there.
Re: A Year of MongoDB
#19This 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 projects and it went well, till it reached some kind of moderate scale where I realized it was a terrible choice going with a NoSQL db (Sometimes, I'd have to duplicate data because there were no Joins, etc). And that's when you start to realize, that NoSQL is not a pure-white solution. It is designed to satisfy very specific use-cases. Relational databases are really good enough for 99% of the use cases out there.
Unless otherwise you are COMPLETELY unable to design your schema in a relational database, you SHOULD NOT simply opt for a NoSQL database. The claimed NoSQL performance benefits will easily be outrun by a terribly designed schema, if you use the wrong db for the wrong scenario. Trust me, MySQL has had so much negativity because of these hipsters, but even something as basically relational as MySQL scales really reaaallllly well. Infact, many top guys still use MySQL till date, for a reason, in production.[1]
Next time you launch your start-up, spend some time carefully evaluating your db design decisions, as the wrong db for the wrong use-case could easily become the most expensive mistake of your startup.
[1]http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use...
Re: A Year of MongoDB
#20Is there a video somewhere of the actual talk?