3 ms·
Yes, and not even only this. The really big difference is the eventual consistency, used as a core concept in most horizontally scalable data stores. If you onc
by loxs 14y ago
Yes, and not even only this. The really big difference is the eventual consistency, used as a core concept in most horizontally scalable data stores. If you once design your application with heavy reliance on hard consistency, you will have a huge problem scaling it later on.
- ucee054 14y agoAs opposed to if you don't, in which case it will be wrong straight away
- jeremyjh 14y agoUhm, no. In MongoDB, you can decide for each query/operation how much consistency you need. You can fire and forget, you can wait for it to be journaled, wait for it to be flushed to disk, wait for it to be replicated to N number of slaves.
- jeltz 14y agoVery few applications need to scale past that point. I know plenty of business where if they would scale past the point of being able to run on a single SQL database instance they would make billions and be larger than their theoretical target market. Not everyone is building the next Facebook (which coincidentally uses MySQL for a lot of things).
- loxs 14y agoIt's not only about being able to serve lots of users. It's also about availability and geographical distribution. Even if you don't have millions of users, they will gladly benefit from you being split across several datacenters (serve everyone's requests from a location near to them).
- PommeDeTerre 14y agoIt's quite easy to do this using traditional relational database technology, and various forms of replication. We've been doing it for many years, likely before many of today's NoSQLers were even born. In the relational world, we don't really see such capabilities as anything special. They're merely one of the many basic features we've come to expect from any relational database system worth using.