| See, what you just posted is a typical response which tries to justify Mongo, even though you yourself have little experience with it! Fine, I'll bite: > All access would be through one service that enforced [rules, integrity] That's a very good idea; you just described what a database is. Now why take it upon yourself (and team) to reimplement that yourself when there exist quite a few that have had thousands of programmer years scrutinizing every detail to create the most robust and optimized systems... these are much better programmers than you or I for this job, these guys eat shit and live databases. > App servers are a lot cheaper/easier to scale than database servers. By keeping all of the logic in the business tier, it's a lot easier to scale/load balance. Ah there it is, the typical FUD, by moving everything out of the 'database', you can scale. Nope, that's not true. The only thing that doesn't scale easily with a database server is joins - In all other cases it's possible to (even with an rdbms) scale infinitely via sharding. In fact there are many implementations that do so, and they are usually faster than Mongo. Now onto joins, these get implemented in the "app server" by the inexperienced developer in 2 ways: A. Real joins using normalized data 1. generates a ton of network congestion from getting the data 2. ton of cpu because because json decoding/encoding 3. ton of cpu because scripting languages vs optimized C 4. the use of O(shit) algorithms to make the joins 5. inconsistencies when things fail like network or disk or shutdown B. Redundant data 1. use a ton of memory/disk 2. create deferred overheads in order to keep things sync 3. despite that, end up with inconsistent data all over the place 4. wont actually be faster or scalable(!!!) In both cases they end up creating a bottleneck once you start caring about concurrent access not messing up your data. Watching Mongo evolve is like watching the past 30 years of rdbms - which started out as flat text files which were 'fast and simple' - gaining indexes, efficient datastructures, foreign keys, disaster recovery etc. But it's all good, and I can't complain, I make a killing putting out fires caused by badly architected systems. |
Then you end up denormalizimg your data anyway in the business layer anyway because most real world applications work with denormalized data and being a good DDD person you work with "aggregate roots". With Mongo you can store and load the whole aggregate root as is without the whole "object relational impedance mismatch".
1. generates a ton of network congestion from getting the data 2. ton of cpu because because json decoding/encoding 3. ton of cpu because scripting languages vs optimized C
I don't use scripting languages. I use C#.
4. the use of O(shit) algorithms to make the joins
If you're doing a lot of joins with a non relational database, you're doing it wrong. You should be Store the whole object hierarchy as one document.
If I'm doing joins. I'm using Linq which should be doing joins based on hashes.
5. inconsistencies when things fail like network or disk or shutdown
Again you should be storing the whole document with the relationships.
B. Redundant data 1. use a ton of memory/disk 2. create deferred overheads in order to keep things sync 3. despite that, end up with inconsistent data all over the place
You're doing it wrong you're using a non relational database like a relational database.
4. wont actually be faster or scalable(!!!) In both cases they end up creating a bottleneck once you start caring about concurrent access not messing up your data.
If you use it like an RDMS it won't be. But if you're storing all of the related data as a document, using good algorithms when you have to join, it is faster. How much time do OO programmers spend denormalizing data and using bloated ORMs?