4 ms·

> I did not find any proof of this in the rest of the report. May I suggest sections 3.4, 3.5, 3.6, 3.7, 4.0, and 4.1?

by aphyr 6y ago

lmilcin 6y ago
Quoting half the report is bad for the discussion as it makes it impossible for the reader to follow.
- aphyr 6y ago
  Chief, it does not have to be this hard. 3.4 clearly states: This anomaly occurred even with read concern snapshot and write concern majority 3.5: In this case, a test running with read concern snapshot and write concern majority executed a trio of transactions with the following dependency graph 3.6: Worse yet, transactions running with the strongest isolation levels can exhibit G1c: cyclic information flow. 3.7: It’s even possible for a single transaction to observe its own future effects. In this test run, four transactions, all executed at read concern snapshot and write concern majority, append 1, 2, 3, and 4 to key 586—but the transaction which wrote 1 observed [1 2 3 4] before it appended 1. Like... if you had read any of these sections--or even their very first sentences--you wouldn't be in this position. They're also summarized both in the abstract and discussion sections, in case you skipped the results. 4.0: Finally, even with the strongest levels of read and write concern for both single-document and transactional operations, we observed cases of G-single (read skew), G1c (cyclic information flow), duplicated writes, and a sort of retrocausal internal consistency anomaly: within a single transaction, reads could observe that transaction’s own writes from the future. MongoDB appears to allow transactions to both observe and not observe prior transactions, and to observe one another’s writes. A single write could be applied multiple times, suggesting an error in MongoDB’s automatic retry mechanism. All of these behaviors are incompatible with MongoDB’s claims of snapshot isolation. It's OK to stop digging now!
  - deleted 6y ago
    [deleted]
  - lmilcin 6y ago
    May I suggest alternative perspective on the matter? Compared to a product like Oracle, transactions on MongoDB are very new, very niche functionality. Even MongoDB consultants do openly suggest not to use it. MongoDB is really meant to store and retrieve documents. That's where the majority read/write concern guarantees come from. As long as you are storing and retrieving documents you are pretty safe functionality. Your article presents the situation as if MongoDB did not work correctly at all. That is simply not true, the most you can say is that a single (niche) feature doesn't work. Have you ever tried distributed transactions with relational databases? Everybody knows these exist but nobody with sound mind would ever architect their application to rely on it. Any person with a bit of experience will understand that things don't come free and some things are just too good to be true. MongoDB marketing may be a bit trigger happy with their advertisements but it does not mean the product is unusable, they just probably promised bit too much.
    - speedgoose 6y ago
      You may want to delete this comment too.
    - deleted 6y ago
      [deleted]
    - jiofih 6y ago
      May I suggest the tiniest bit of consideration (such as reading the report) before jumping to conclusions and low-key offending the author? You should be embarrassed.
    - aphyr 6y ago
      Have you ever tried distributed transactions with relational databases? I am delighted to say that yes: checking safety properties of distributed systems, including those of relational databases, is literally my job. See https://jepsen.io/analyses https://jepsen.io/analyses for a comprehensive list of prior work, or http://jepsen.io/analyses/tidb-2.1.7 http://jepsen.io/analyses/tidb-2.1.7, http://jepsen.io/analyses/yugabyte-db-1.1.9 http://jepsen.io/analyses/yugabyte-db-1.1.9, http://jepsen.io/analyses/yugabyte-db-1.3.1 http://jepsen.io/analyses/yugabyte-db-1.3.1, or http://jepsen.io/analyses/voltdb-6-3 http://jepsen.io/analyses/voltdb-6-3 for recent examples of Jepsen analyses on relational databases.
- inglor 6y ago
  > May I suggest alternative perspective on the matter? Can't reply to that since it's too nested so I'll reply here. I warmly recommend getting off tree you climbed on and actually reading the article because if you do - you will see you are not disagreeing on that part. The article is a mostly technical analysis of the transaction isolation levels and where they hold. The main criticism is how MongoDB advertises itself. If they didn't claim the database is "fully ACID" then the article would have just been a technical analysis :]

> I did not find any proof of this in the rest of the report. May I suggest sections 3.4, 3.5, 3.6, 3.7, 4.0, and 4.1?

by aphyr 6y ago

> I did not find any proof of this in the rest of the report. May I suggest sections 3.4, 3.5, 3.6, 3.7, 4.0, and 4.1?

lmilcin 6y ago

Quoting half the report is bad for the discussion as it makes it impossible for the reader to follow.

aphyr 6y ago
Chief, it does not have to be this hard. 3.4 clearly states: This anomaly occurred even with read concern snapshot and write concern majority 3.5: In this case, a test running with read concern snapshot and write concern majority executed a trio of transactions with the following dependency graph 3.6: Worse yet, transactions running with the strongest isolation levels can exhibit G1c: cyclic information flow. 3.7: It’s even possible for a single transaction to observe its own future effects. In this test run, four transactions, all executed at read concern snapshot and write concern majority, append 1, 2, 3, and 4 to key 586—but the transaction which wrote 1 observed [1 2 3 4] before it appended 1. Like... if you had read any of these sections--or even their very first sentences--you wouldn't be in this position. They're also summarized both in the abstract and discussion sections, in case you skipped the results. 4.0: Finally, even with the strongest levels of read and write concern for both single-document and transactional operations, we observed cases of G-single (read skew), G1c (cyclic information flow), duplicated writes, and a sort of retrocausal internal consistency anomaly: within a single transaction, reads could observe that transaction’s own writes from the future. MongoDB appears to allow transactions to both observe and not observe prior transactions, and to observe one another’s writes. A single write could be applied multiple times, suggesting an error in MongoDB’s automatic retry mechanism. All of these behaviors are incompatible with MongoDB’s claims of snapshot isolation. It's OK to stop digging now!
- deleted 6y ago
  [deleted]
- lmilcin 6y ago
  May I suggest alternative perspective on the matter? Compared to a product like Oracle, transactions on MongoDB are very new, very niche functionality. Even MongoDB consultants do openly suggest not to use it. MongoDB is really meant to store and retrieve documents. That's where the majority read/write concern guarantees come from. As long as you are storing and retrieving documents you are pretty safe functionality. Your article presents the situation as if MongoDB did not work correctly at all. That is simply not true, the most you can say is that a single (niche) feature doesn't work. Have you ever tried distributed transactions with relational databases? Everybody knows these exist but nobody with sound mind would ever architect their application to rely on it. Any person with a bit of experience will understand that things don't come free and some things are just too good to be true. MongoDB marketing may be a bit trigger happy with their advertisements but it does not mean the product is unusable, they just probably promised bit too much.
  - speedgoose 6y ago
    You may want to delete this comment too.
  - deleted 6y ago
    [deleted]
  - jiofih 6y ago
    May I suggest the tiniest bit of consideration (such as reading the report) before jumping to conclusions and low-key offending the author? You should be embarrassed.
  - aphyr 6y ago
    Have you ever tried distributed transactions with relational databases? I am delighted to say that yes: checking safety properties of distributed systems, including those of relational databases, is literally my job. See https://jepsen.io/analyses https://jepsen.io/analyses for a comprehensive list of prior work, or http://jepsen.io/analyses/tidb-2.1.7 http://jepsen.io/analyses/tidb-2.1.7, http://jepsen.io/analyses/yugabyte-db-1.1.9 http://jepsen.io/analyses/yugabyte-db-1.1.9, http://jepsen.io/analyses/yugabyte-db-1.3.1 http://jepsen.io/analyses/yugabyte-db-1.3.1, or http://jepsen.io/analyses/voltdb-6-3 http://jepsen.io/analyses/voltdb-6-3 for recent examples of Jepsen analyses on relational databases.
inglor 6y ago
> May I suggest alternative perspective on the matter? Can't reply to that since it's too nested so I'll reply here. I warmly recommend getting off tree you climbed on and actually reading the article because if you do - you will see you are not disagreeing on that part. The article is a mostly technical analysis of the transaction isolation levels and where they hold. The main criticism is how MongoDB advertises itself. If they didn't claim the database is "fully ACID" then the article would have just been a technical analysis :]