6 ms·

To be fair, Mongo is better than it's ever been. They even got through Jepsen just fine after wiredtiger. That said, it's pretty hard to make sense of when you

To be fair, Mongo is better than it's ever been. They even got through Jepsen just fine after wiredtiger. That said, it's pretty hard to make sense of when you would want non-relational dbms these days, especially in an era where you can get 100core systems in AWS/GCP. Write-scaling is still a pretty obvious reason, though things like Citus might help here.

dsp1234 9y ago
They even got through Jepsen just fine after wiredtiger. With non-default settings[0]. The Jepsen tests passed with the "linearizable" read concern. The default read concern is "local", which "Provides no guarantee that the data has been written to a majority of the replica set members (i.e. may be rolled back)."[1] This is like having "READ UNCOMMITTED" be the default read level in a traditional database system. The Jepsen tests passed with the "majority" write concern. The default write concern is "1", which means only the "primary" in a replica set needs to acknowledge the write[2]. This does not guarantee safety in the face of network partitions. It's still not safe out of the box. [0] - https://jepsen.io/analyses/mongodb-3-4-0-rc3 https://jepsen.io/analyses/mongodb-3-4-0-rc3 "With the v1 protocol, majority writes, and linearizable reads, MongoDB 3.4.1 (and the current development release, 3.5.1) pass all MongoDB Jepsen tests:" [1] - https://docs.mongodb.com/manual/reference/read-concern/ https://docs.mongodb.com/manual/reference/read-concern/ [2] - https://docs.mongodb.com/manual/reference/write-concern/ https://docs.mongodb.com/manual/reference/write-concern/
- stingraycharles 9y ago
  These kind of default settings make sense, though. If you really care about lineair writes, you know how to configure it. Same goes for example for PostgreSQL [1], that uses Read Committed rather than Serializable transaction isolation by default because for the majority of the people, this is fine, and the performance tradeoffs are worth it. [1] https://www.postgresql.org/docs/9.5/static/transaction-iso.html https://www.postgresql.org/docs/9.5/static/transaction-iso.h...
  - bpicolo 9y ago
    Yeah, and you can turn off fsync in postgres if you want a blazing fast db that loses your data. :D
    - threeseed 9y ago
      This meme isn't even funny anymore. It was a bug that was fixed many, many years ago and was only true if you didn't use any client libraries.
- threeseed 9y ago
  Not sure if you know much about databases but those are standard defaults. Cassandra as well doesn't require a full quorum to acknowledge writes. It just relies on the closest node. Likewise for Oracle. http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html http://docs.datastax.com/en/archived/cassandra/2.0/cassandra...
growse 9y ago
> That said, it's pretty hard to make sense of when you would want non-relational dbms these days. Write-scaling is still a pretty obvious reason, though things like Citus might help here. Personally, I find a non-relational database useful when my data model is non-relational.
- bpicolo 9y ago
  Sure. The most direct argument against that is that Postgresql jsonb is just non-relational data support in a first class relational DB, which is pretty great, so to an extend you get the best of both worlds, though I'm sure you can find a case where it's not quite optimal vs some nosql db. This talk is a pretty nifty perf overview: https://www.percona.com/live/e17/sessions/high-performance-json-postgresql-vs-mongodb https://www.percona.com/live/e17/sessions/high-performance-j... That said, if you know beforehand that horizontal scaling will be a crucial factor, probably postgres isn't the first choice. But with how fast CPUs are these days it's usually not important for a long time.
  - jsjohnst 9y ago
    > But with how fast CPUs are these days it's usually not important for a long time. That’s a very naive statement to make.
    - bpicolo 9y ago
      Is it? Because there are a ton of companies out there running postgres, mysql and scaling workloads just fine.
      - jsjohnst 9y ago
        I upvoted you because you’re technically right for many cases, but if you’d ever dealt with a database you couldn’t scale further (we were using multiple of the largest instances EC2 had at the time) and new data was flowing in faster than you could delete it and downtime wasn’t an option, you too would hate any predecessors who said “you can always scale higher” before things got so bad it was almost impossible to recover.

dsp1234 9y ago

They even got through Jepsen just fine after wiredtiger. With non-default settings[0]. The Jepsen tests passed with the "linearizable" read concern. The default read concern is "local", which "Provides no guarantee that the data has been written to a majority of the replica set members (i.e. may be rolled back)."[1] This is like having "READ UNCOMMITTED" be the default read level in a traditional database system. The Jepsen tests passed with the "majority" write concern. The default write concern is "1", which means only the "primary" in a replica set needs to acknowledge the write[2]. This does not guarantee safety in the face of network partitions. It's still not safe out of the box. [0] - https://jepsen.io/analyses/mongodb-3-4-0-rc3 https://jepsen.io/analyses/mongodb-3-4-0-rc3 "With the v1 protocol, majority writes, and linearizable reads, MongoDB 3.4.1 (and the current development release, 3.5.1) pass all MongoDB Jepsen tests:" [1] - https://docs.mongodb.com/manual/reference/read-concern/ https://docs.mongodb.com/manual/reference/read-concern/ [2] - https://docs.mongodb.com/manual/reference/write-concern/ https://docs.mongodb.com/manual/reference/write-concern/

stingraycharles 9y ago
These kind of default settings make sense, though. If you really care about lineair writes, you know how to configure it. Same goes for example for PostgreSQL [1], that uses Read Committed rather than Serializable transaction isolation by default because for the majority of the people, this is fine, and the performance tradeoffs are worth it. [1] https://www.postgresql.org/docs/9.5/static/transaction-iso.html https://www.postgresql.org/docs/9.5/static/transaction-iso.h...
- bpicolo 9y ago
  Yeah, and you can turn off fsync in postgres if you want a blazing fast db that loses your data. :D
  - threeseed 9y ago
    This meme isn't even funny anymore. It was a bug that was fixed many, many years ago and was only true if you didn't use any client libraries.
threeseed 9y ago
Not sure if you know much about databases but those are standard defaults. Cassandra as well doesn't require a full quorum to acknowledge writes. It just relies on the closest node. Likewise for Oracle. http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html http://docs.datastax.com/en/archived/cassandra/2.0/cassandra...

growse 9y ago

> That said, it's pretty hard to make sense of when you would want non-relational dbms these days. Write-scaling is still a pretty obvious reason, though things like Citus might help here. Personally, I find a non-relational database useful when my data model is non-relational.

bpicolo 9y ago
Sure. The most direct argument against that is that Postgresql jsonb is just non-relational data support in a first class relational DB, which is pretty great, so to an extend you get the best of both worlds, though I'm sure you can find a case where it's not quite optimal vs some nosql db. This talk is a pretty nifty perf overview: https://www.percona.com/live/e17/sessions/high-performance-json-postgresql-vs-mongodb https://www.percona.com/live/e17/sessions/high-performance-j... That said, if you know beforehand that horizontal scaling will be a crucial factor, probably postgres isn't the first choice. But with how fast CPUs are these days it's usually not important for a long time.
- jsjohnst 9y ago
  > But with how fast CPUs are these days it's usually not important for a long time. That’s a very naive statement to make.
  - bpicolo 9y ago
    Is it? Because there are a ton of companies out there running postgres, mysql and scaling workloads just fine.
    - jsjohnst 9y ago
      I upvoted you because you’re technically right for many cases, but if you’d ever dealt with a database you couldn’t scale further (we were using multiple of the largest instances EC2 had at the time) and new data was flowing in faster than you could delete it and downtime wasn’t an option, you too would hate any predecessors who said “you can always scale higher” before things got so bad it was almost impossible to recover.