3 ms·
My memory is that the problem was ACID. The document stores didn’t promise to be reliable because apparently that didn’t scale. And there was a very well know
by wood_spirit 3y ago
My memory is that the problem was ACID. The document stores didn’t promise to be reliable because apparently that didn’t scale.
And there was a very well known cartoon video discussion about it with “web scale” and “just write to dev null” and other classics that became memes :)
- cratermoon 3y agoDid you ever read Pat Helland's article, "Life Beyond Distributed Transactions: An apostate’s opinion" https://dl.acm.org/doi/10.1145/3012426.3025012 https://dl.acm.org/doi/10.1145/3012426.3025012? "This article explores and names some of the practical approaches used in the implementation of large-scale mission-critical applications in a world that rejects distributed transactions."
- wood_spirit 3y agoNo I haven’t. Thanks for the interesting link :) Admittedly I live in a world where big distributed transactions are a given and work fine and sql speeds us up not slows us down. I’m guessing sql and acid scaled after all?
- cratermoon 3y ago> I’m guessing sql and acid scaled after all? Yes and no. Distributed transactions and two-phase commit have been superseded by things like Paxos and Raft, with a variety of consistency models, so the implementation is drastically different.
- jerrygenser 3y agoDocument stores often are reliable and more fault tolerant. But yes they trade ACID. There are some applications that require high throughput (usually write) but can be fine with read consistency. Couple of examples - consumer facing comment systems where other users are OK to miss your comment by 30 seconds - timeseries logging where you are usually reading infrequently but writing very much in a denormalized format so joins aren't as critical For general CRUD, ACID is important though.