3 ms·

You're not wrong. Probably more than 95% of applications will never outgrow one large relational database. I just think that this leads to an unfortunate, but m

You're not wrong. Probably more than 95% of applications will never outgrow one large relational database. I just think that this leads to an unfortunate, but mostly inevitable issue of complexity for the few that do hit such a level of success and scale. Alex DeVrie (author of 'The DynamoDB Book') discusses that his approach is to essentially start all new projects with DynamoDB. Now I don't really agree with him, yet I can't fully say he's wrong either. While we won't need it most of the time, reaching for a tool like this before we need it provides more time to really understand it when/if we reach that point.

bigtunacan 4y ago
@ithrow, yeah I know he is clearly biased which is why I don't really agree with him. I do however think it would have helped me to start using/learning before I needed it since the paradigm is so foreign to the relational model that is now second nature.
- Aeolun 4y ago
  DynamoDB (and Mongo) is nice, right up until you need those relations. I haven’t found a document oriented database that gives me the consistency guarantees of a RDBMS yet.
  - bigtunacan 4y ago
    It's been a long time since I've used Mongo so I don't know if it only supports eventual consistency, but DynamoDB does support transactions and traditional consistency, but it comes at the cost of reduced read throughput. DynamoDB also supports relations, but they aren't called relations because they don't resemble anything like relations in traditional relational databases. You may already know this, but just to clarify DynamoDB isn't really a document oriented database. It's both a key/value database and a columnar database, so in that sense I'd closer to Redis and Cassandra than Mongo, but there's definitely a lot of misinformation on this front.
  - loxias 4y ago
    Would a hybrid key-value & document store, indices on any user defined path, with optional strong consistency DWYW?
  - jd_mongodb 4y ago
    You must not have looked at MongoDB. We have been delivering fully consistent ACID transactions since 4.0 which shipped several years. Yes, Jepsen did find some issues with the initial release of ACID transactions and yes, we fixed those problems pretty rapidly.
    - arinlen 4y ago
      > Yes, Jepsen did find some issues with the initial release of ACID transactions (...) By "some issues" you mean lost data and violated causal by default. https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/ https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/ And no, the issues were not fixed. Jepsen pointed out that "the newer MongoDB 4.2.6 has more problems" including “retrocausal transactions”. https://jepsen.io/analyses/mongodb-4.2.6 https://jepsen.io/analyses/mongodb-4.2.6 From Jepsen's report: > Jepsen evaluated MongoDB version 4.2.6, and found that even at the strongest levels of read and write concern, it failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations.
      - jd_mongodb 4y ago
        Also read the addendum from the same report: 1 Updates 2020-05-26: MongoDB identified a bug in the transaction retry mechanism which they believe was responsible for the anomalies observed in this report; a patch is scheduled for 4.2.8.
        krageon 4y ago
        This is the core culture of MongoDB - cutting corners to optimise things a little more and cater to a NoSQL crowd. It's entire mindset is fundamentally different from what you'd get in a proper relational database and ignoring those things isn't going to do any software you write any favours.
        arinlen 4y ago
        > Also read the addendum from the same report: Your initial claim was that these issues were addressed in 4.0. Jepsen's report refutes your claim,and demonstrates MongoDB had serious reliability problems even in 4.2.6. Frankly, your insistence in pulling the wool over everyone's eyes, specially on a topic that's easily verified, does not help built up trust on MongoDB
ithrow 4y ago
Devrie works AWS ;)

bigtunacan 4y ago

@ithrow, yeah I know he is clearly biased which is why I don't really agree with him. I do however think it would have helped me to start using/learning before I needed it since the paradigm is so foreign to the relational model that is now second nature.

Aeolun 4y ago
DynamoDB (and Mongo) is nice, right up until you need those relations. I haven’t found a document oriented database that gives me the consistency guarantees of a RDBMS yet.
- bigtunacan 4y ago
  It's been a long time since I've used Mongo so I don't know if it only supports eventual consistency, but DynamoDB does support transactions and traditional consistency, but it comes at the cost of reduced read throughput. DynamoDB also supports relations, but they aren't called relations because they don't resemble anything like relations in traditional relational databases. You may already know this, but just to clarify DynamoDB isn't really a document oriented database. It's both a key/value database and a columnar database, so in that sense I'd closer to Redis and Cassandra than Mongo, but there's definitely a lot of misinformation on this front.
- loxias 4y ago
  Would a hybrid key-value & document store, indices on any user defined path, with optional strong consistency DWYW?
- jd_mongodb 4y ago
  You must not have looked at MongoDB. We have been delivering fully consistent ACID transactions since 4.0 which shipped several years. Yes, Jepsen did find some issues with the initial release of ACID transactions and yes, we fixed those problems pretty rapidly.
  - arinlen 4y ago
    > Yes, Jepsen did find some issues with the initial release of ACID transactions (...) By "some issues" you mean lost data and violated causal by default. https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/ https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/ And no, the issues were not fixed. Jepsen pointed out that "the newer MongoDB 4.2.6 has more problems" including “retrocausal transactions”. https://jepsen.io/analyses/mongodb-4.2.6 https://jepsen.io/analyses/mongodb-4.2.6 From Jepsen's report: > Jepsen evaluated MongoDB version 4.2.6, and found that even at the strongest levels of read and write concern, it failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations.
    - jd_mongodb 4y ago
      Also read the addendum from the same report: 1 Updates 2020-05-26: MongoDB identified a bug in the transaction retry mechanism which they believe was responsible for the anomalies observed in this report; a patch is scheduled for 4.2.8.
      - krageon 4y ago
        This is the core culture of MongoDB - cutting corners to optimise things a little more and cater to a NoSQL crowd. It's entire mindset is fundamentally different from what you'd get in a proper relational database and ignoring those things isn't going to do any software you write any favours.
      - arinlen 4y ago
        > Also read the addendum from the same report: Your initial claim was that these issues were addressed in 4.0. Jepsen's report refutes your claim,and demonstrates MongoDB had serious reliability problems even in 4.2.6. Frankly, your insistence in pulling the wool over everyone's eyes, specially on a topic that's easily verified, does not help built up trust on MongoDB

ithrow 4y ago

Devrie works AWS ;)