9 ms·
> by restricting "joins" to only when it's okay to see old data. So what do you do when it's not OK to see old data? That's when it breaks down. There are def
by phamilton 10y ago
> by restricting "joins" to only when it's okay to see old data.
So what do you do when it's not OK to see old data? That's when it breaks down.
There are definitely ways around the issues, but you have to make compromises in how you build the application. If you don't make those design decisions early, you find yourself doing it wrong.
In describing large scale systems, a friend of mine said "Imagine a scenario that has a one in a billion chance of happening. On a 10k qps system, it happens almost daily."
That's how this breaks down at scale. Awkward corner cases that don't really seem likely suddenly become daily events.
- gwbas1c 10y agoSo, would you say that it's a solvable problem, but it's so time consuming or difficult that a traditional relational database is a more appropriate database for average developers? (Remember, the Diaspora guys were right out of college and inexperienced.) It's as if MongoDB is great for prototyping, and great for lossy data at scale, but it can't hit the middle.
- phamilton 10y agoMongo's problem isn't really the lack of schema or joins or anything. It's the mountain of false assumptions people make around its behavior. If you understand the limitations of the libraries and systems you use, you can solve most problems. The issue is that most people don't understand those limitations. Mongo gets an especially bad rap because it actively pushed misleading information as part of its sales pitch.