5 ms·

In the same NoSql space as mongo db? I can't remember not even one that passed fully jepsen test. Can you post some links to the better NoSql options?

GiorgioG 10y ago
RethinkDB https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5 https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5
fictioncircle 10y ago
https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5 https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5 > As far as I can ascertain, RethinkDB’s safety claims are accurate. You can lose updates if you write with anything less than majority, and see assorted read anomalies with single or outdated reads, but majority/majority appears linearizable. The safety claims are accurate but like all databases, its never 100% perfect as there are tradeoffs. https://aphyr.com/posts/330-jepsen-rethinkdb-2-2-3-reconfiguration https://aphyr.com/posts/330-jepsen-rethinkdb-2-2-3-reconfigu... > That reordering was only possible because of a special workaround for a bug in an older version of RethinkDB. > What are the risks to users? The RethinkDB team and I suspect it’s unlikely this bug will occur outside of stress testing. Cluster reconfiguration is typically infrequent, and users would need a specific series of network failures or other message delays which happen to cut the replicas apart—in a way which allows both network components to find independent majorities for their respective table configurations. In Jepsen tests, it usually takes tens to hundreds of partition/reconfigure rounds to trigger this bug. This isn't really an architectural failure (as you see repeatedly with MongoDB) but an implementation bug. Compared to the failures in MongoDB that are frequently architectural (rather than implementation bugs), RethinkDB passed easily and quickly fixed the implementation bugs.
radicalbyte 10y ago
Rethink and Cassandra both fare far better in Jepsen. Depending on the exact requirements Postgres (in the right configuration) and Redis are better options. I'd argue that for 90% of MongoDB users - the group whose requirements were met by MySQL/MyISAM - would be better served by Postgres or MySQL with a proper storage engine.
- mat_keep 10y ago
  Cassandra testing on Jepsen. Interesting definition of "fare far better in Jepsen" https://aphyr.com/posts/294-jepsen-cassandra https://aphyr.com/posts/294-jepsen-cassandra
  - pkolaczk 10y ago
    Cassandra had a minor bug with timestamps which was fixed relatively fast and now it passes Jepsen fully. There were also a few implementation issues around LWT (Paxos) but at that time Paxos was very new. There were no architectural / fundamental changes needed to correct these issues. Also, even before fixing, Cassandra was losing only a tiny fraction of data than Mongo was losing. So, yes, this is what I call "far better", even if not initially perfect.
    - aphyr 10y ago
      Cassandra had a minor bug with timestamps which was fixed relatively fast and now it passes Jepsen fully. Wait, what?
      - pkolaczk 10y ago
        http://www.datastax.com/dev/blog/testing-apache-cassandra-with-jepsen http://www.datastax.com/dev/blog/testing-apache-cassandra-wi...
        aphyr 10y ago
        Pretty sure Cassandra still uses local timestamps and last-write-wins, which means you can't do safe updates. Also pretty sure they didn't fix the timestamp-collision row-isolation issue I talked about, because it was on HN's front page a few months ago. ;-)
        pkolaczk 10y ago
        Using timestamps and last write wins is a well known and well documented behavior, so you must assume updates can be sometimes applied in a different order than they were submitted. However, reordering updates is not the same as rolling back writes as was in case of Mongo. Cassandra does not promise linearizability in this mode of operation (if not using LWTs), and this is a tradeoff to get better availability. There is no better way than last write wins if you want high availability and partition tolerance and don't want to pay the performance and availability price for a consensus algorithm like Paxos or Raft. And no, vector clocks do not solve this problem in practice at all. As for the post on HN from a few months ago, I remember only one guy who mixed LWT and non LWT updates and was surprised with lack of linearizability. Not a Cassandra fault if somebody doesn't know what he's doing.

GiorgioG 10y ago

RethinkDB https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5 https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5

fictioncircle 10y ago

https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5 https://aphyr.com/posts/329-jepsen-rethinkdb-2-1-5 > As far as I can ascertain, RethinkDB’s safety claims are accurate. You can lose updates if you write with anything less than majority, and see assorted read anomalies with single or outdated reads, but majority/majority appears linearizable. The safety claims are accurate but like all databases, its never 100% perfect as there are tradeoffs. https://aphyr.com/posts/330-jepsen-rethinkdb-2-2-3-reconfiguration https://aphyr.com/posts/330-jepsen-rethinkdb-2-2-3-reconfigu... > That reordering was only possible because of a special workaround for a bug in an older version of RethinkDB. > What are the risks to users? The RethinkDB team and I suspect it’s unlikely this bug will occur outside of stress testing. Cluster reconfiguration is typically infrequent, and users would need a specific series of network failures or other message delays which happen to cut the replicas apart—in a way which allows both network components to find independent majorities for their respective table configurations. In Jepsen tests, it usually takes tens to hundreds of partition/reconfigure rounds to trigger this bug. This isn't really an architectural failure (as you see repeatedly with MongoDB) but an implementation bug. Compared to the failures in MongoDB that are frequently architectural (rather than implementation bugs), RethinkDB passed easily and quickly fixed the implementation bugs.

radicalbyte 10y ago

Rethink and Cassandra both fare far better in Jepsen. Depending on the exact requirements Postgres (in the right configuration) and Redis are better options. I'd argue that for 90% of MongoDB users - the group whose requirements were met by MySQL/MyISAM - would be better served by Postgres or MySQL with a proper storage engine.

mat_keep 10y ago
Cassandra testing on Jepsen. Interesting definition of "fare far better in Jepsen" https://aphyr.com/posts/294-jepsen-cassandra https://aphyr.com/posts/294-jepsen-cassandra
- pkolaczk 10y ago
  Cassandra had a minor bug with timestamps which was fixed relatively fast and now it passes Jepsen fully. There were also a few implementation issues around LWT (Paxos) but at that time Paxos was very new. There were no architectural / fundamental changes needed to correct these issues. Also, even before fixing, Cassandra was losing only a tiny fraction of data than Mongo was losing. So, yes, this is what I call "far better", even if not initially perfect.
  - aphyr 10y ago
    Cassandra had a minor bug with timestamps which was fixed relatively fast and now it passes Jepsen fully. Wait, what?
    - pkolaczk 10y ago
      http://www.datastax.com/dev/blog/testing-apache-cassandra-with-jepsen http://www.datastax.com/dev/blog/testing-apache-cassandra-wi...
      - aphyr 10y ago
        Pretty sure Cassandra still uses local timestamps and last-write-wins, which means you can't do safe updates. Also pretty sure they didn't fix the timestamp-collision row-isolation issue I talked about, because it was on HN's front page a few months ago. ;-)
        pkolaczk 10y ago
        Using timestamps and last write wins is a well known and well documented behavior, so you must assume updates can be sometimes applied in a different order than they were submitted. However, reordering updates is not the same as rolling back writes as was in case of Mongo. Cassandra does not promise linearizability in this mode of operation (if not using LWTs), and this is a tradeoff to get better availability. There is no better way than last write wins if you want high availability and partition tolerance and don't want to pay the performance and availability price for a consensus algorithm like Paxos or Raft. And no, vector clocks do not solve this problem in practice at all. As for the post on HN from a few months ago, I remember only one guy who mixed LWT and non LWT updates and was surprised with lack of linearizability. Not a Cassandra fault if somebody doesn't know what he's doing.