4 ms·

I remember a comment on HN sometime in the last month [1] talking about how even an ACID-compliant RDBMS can be rendered non-ACID, through configuration or real

by pbowyer 12y ago

I remember a comment on HN sometime in the last month [1] talking about how even an ACID-compliant RDBMS can be rendered non-ACID, through configuration or real-world usage (replication?). Do you agree? [1] Unfortunately, searching hasn't turned up the comment... yet.

takeda 12y ago
Yep. In Postgres for example: * A - you have the ability to not use transactions (technically it still implicitly uses transactions per statement, but that's kind of expected behavior of the NoSQL databases). * C - simply don't use rules such as constraints, triggers etc. * I - reduce isolation level of the transaction. Postgres due to its design doesn't allow you to have dirty reads (ability to read from concurrent uncommitted transaction) * D - there are several settings (e.g. disable sync, wal etc, create an unlogged table) which increase performance at the cost of potentially losing your data. You will also reduce it when you use asynchronous replication. The ACID is a feature that is generally desired when your data is important to you and you also want to be certain that the data is always consistent at any point in time. It's quite hard to implement it right, so it should not be treated like a bug. Generally you should think of RDBMS as general purpose databases that have strong consistency guarantees, and the NoSQL as a specialized databases which no longer provide ACID guarantees in order to tackle specific domain. There are also NoSQL databases which try to be general purpose, such as MongoDB. Those are joke. MongoDB for example currently not only is much slower than Postgres[1] it also doesn't horizontally scale[2] on top of that you don't even have ACID guarantees so you're getting the worst out of both worlds. [1] http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality http://www.enterprisedb.com/postgres-plus-edb-blog/marc-lins... [2] https://www.datastax.com/wp-content/uploads/2013/02/WP-Benchmarking-Top-NoSQL-Databases.pdf https://www.datastax.com/wp-content/uploads/2013/02/WP-Bench...

by pbowyer 12y ago

takeda 12y ago

Yep. In Postgres for example: * A - you have the ability to not use transactions (technically it still implicitly uses transactions per statement, but that's kind of expected behavior of the NoSQL databases). * C - simply don't use rules such as constraints, triggers etc. * I - reduce isolation level of the transaction. Postgres due to its design doesn't allow you to have dirty reads (ability to read from concurrent uncommitted transaction) * D - there are several settings (e.g. disable sync, wal etc, create an unlogged table) which increase performance at the cost of potentially losing your data. You will also reduce it when you use asynchronous replication. The ACID is a feature that is generally desired when your data is important to you and you also want to be certain that the data is always consistent at any point in time. It's quite hard to implement it right, so it should not be treated like a bug. Generally you should think of RDBMS as general purpose databases that have strong consistency guarantees, and the NoSQL as a specialized databases which no longer provide ACID guarantees in order to tackle specific domain. There are also NoSQL databases which try to be general purpose, such as MongoDB. Those are joke. MongoDB for example currently not only is much slower than Postgres[1] it also doesn't horizontally scale[2] on top of that you don't even have ACID guarantees so you're getting the worst out of both worlds. [1] http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality http://www.enterprisedb.com/postgres-plus-edb-blog/marc-lins... [2] https://www.datastax.com/wp-content/uploads/2013/02/WP-Benchmarking-Top-NoSQL-Databases.pdf https://www.datastax.com/wp-content/uploads/2013/02/WP-Bench...