5 ms·

Meh, takes me back to a couple years ago when the MEAN stack was all the rage, I was pointing out flaws/problems which would arise from: - Mongo not having a s

by zepolen 10y ago

Meh, takes me back to a couple years ago when the MEAN stack was all the rage, I was pointing out flaws/problems which would arise from: - Mongo not having a schema, relations - Angular having a fundamentally flawed update system But of course the argument was that 'MEAN is what everyone is using, its easy to find MEAN developers'. Sure, if you mean it's easy to find kids who learnt how to make apps, via a MEAN stack, over a couple months as their first ever tech and now are ready to work for very cheap. Of course it's never cheap - what you save on quality you make up in quantity. The amount of developer time wasted writing migration scripts, debugging silly problems because of no schema, data loss (at least they took my advice on automating backups!), not to mention a ton of frontend issues - was staggering. Yes, this was a 6 month old startup with about 6 fresh college "engineers". Experienced developers have a favorite for a reason, usually they've been bitten by other ones - I would say don't trust a developer who pushes a certain tech without giving a reason beyond that they are familiar with it. For example, I've found javascript a painful language to work with (although that's starting to change with all the latest revisions to the spec) - but it makes no sense to push for a different language when half the app is already written and all the devs know javascript. Using Mongo as a db on the other hand I wouldn't suggest ever, data integrity is way too important to use a (badly implemented) cache as a database. There are much better technologies out there that give you everything that Mongo tries to provide, and faster too.

jkmcf 10y ago
You sound like my twin. Wait, are you me? Seriously, I was surprised to find that Splunk uses Mongo. Given its performance and reliability with Splunk, I'm willing to give Mongo another chance given the right conditions (given that someone on my team has significant experience administering it).
scarface74 10y ago
I'm relatively new to Mongo and I've only used it in C#. But a few points: I would only use Mongo as a backing store for a micro service. All access would be through one service that enforced business rules, data integrity, and would be responsible for exposing business objects/aggregate roots. 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.
- zepolen 10y ago
  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.
  - scarface74 10y ago
    A. Real joins using normalized data 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?

by zepolen 10y ago

jkmcf 10y ago

You sound like my twin. Wait, are you me? Seriously, I was surprised to find that Splunk uses Mongo. Given its performance and reliability with Splunk, I'm willing to give Mongo another chance given the right conditions (given that someone on my team has significant experience administering it).

scarface74 10y ago

I'm relatively new to Mongo and I've only used it in C#. But a few points: I would only use Mongo as a backing store for a micro service. All access would be through one service that enforced business rules, data integrity, and would be responsible for exposing business objects/aggregate roots. 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.

zepolen 10y ago
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.
- scarface74 10y ago
  A. Real joins using normalized data 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?