11–20 of 57 posts
MVCC does not provide serializability of transactions without a bit more work. Since when can you get away without giving guaranties about what you support?
RavenDB is also ACID I beleive? The foundation site makes it sound like they are the only one.
"RavenDB supports multi document (and multi node) transactions, but even so, it isn’t recommended for common use, because of the potential for issues when using distributed transactions."
So, the differentiator is that FoundationDB is built from the ground up to support these type of transactions at high performance levels with no "potential issues".
Does this compare?
It's one of the 'bug bears' I find with new technologies where they try and use it for something it wasn't really designed for. The most recent being the idea of doing e-commerce with a no-sql db (mostly MongoDB). You are just using the wrong type of DB for this. It's nice to find a NoSQL solution that addresses this issue.
It's one of the 'bug bears' I find with new technologies where they try and use it for something it wasn't really designed for. The most recent being the idea of doing e-commerce with a no-sql db (mostly MongoDB). You are just using the wrong type of DB for this. It's nice to find a NoSQL solution that addresses this issue.
The issue I see the most is that NoSQL has become synonymous with distributed databases which is really where making ACID promises becomes a challenge. If you had a single node document DB, it probably wouldn't be very challenging to make it ACID. SQL or not, as soon as you want to make it automatically shard and distributed, then you will suffer large performance impacts with transactions. Are there any single node…
It's one of the 'bug bears' I find with new technologies where they try and use it for something it wasn't really designed for. The most recent being the idea of doing e-commerce with a no-sql db (mostly MongoDB). You are just using the wrong type of DB for this. It's nice to find a NoSQL solution that addresses this issue.
A big part of the problem are developers who think that every new technology is a golden hammer and who try to shoehorn those same technologies into roles they are not well suited for. A pretty obvious example is people using Redis and Mongo for applications that would really benefit the most from relational databases. If you have a highly relational model that would benefit from things like referential integrity and…
> If you have a highly relational model that would benefit
> from things like referential integrity and normalization
> then use a relational database. If you need a massive
> highly scalable KVP database, use NoSQL. I don't see why
> people try to use a single approach as a solution
> to every problem.
Earlier quoted context omitted.
The issue I see the most is that NoSQL has become synonymous with distributed databases which is really where making ACID promises becomes a challenge. If you had a single node document DB, it probably wouldn't be very challenging to make it ACID. SQL or not, as soon as you want to make it automatically shard and distributed, then you will suffer large performance impacts with transactions. Are there any single node…
Redis doesn't support transaction rollbacks, so they're not really "atomic."
It's one of the 'bug bears' I find with new technologies where they try and use it for something it wasn't really designed for. The most recent being the idea of doing e-commerce with a no-sql db (mostly MongoDB). You are just using the wrong type of DB for this. It's nice to find a NoSQL solution that addresses this issue.
A big part of the problem are developers who think that every new technology is a golden hammer and who try to shoehorn those same technologies into roles they are not well suited for. A pretty obvious example is people using Redis and Mongo for applications that would really benefit the most from relational databases. If you have a highly relational model that would benefit from things like referential integrity and…
For example, the current system I'm working on uses Oracle and Mongo, the previous used SQL Server and Redis. The main theme is to use a relational database for the structured data that we need transactional support for, e.g. orders, then use a NoSQL data for unstructured data and caching.
Earlier quoted context omitted.
A big part of the problem are developers who think that every new technology is a golden hammer and who try to shoehorn those same technologies into roles they are not well suited for. A pretty obvious example is people using Redis and Mongo for applications that would really benefit the most from relational databases. If you have a highly relational model that would benefit from things like referential integrity and…
> If you have a highly relational model that would benefit > from things like referential integrity and normalization > then use a relational database. If you need a massive > highly scalable KVP database, use NoSQL. I don't see why > people try to use a single approach as a solution > to every problem. Part of the problem is that people present this as a choice between relational and non-relational models, when the…
Earlier quoted context omitted.
A big part of the problem are developers who think that every new technology is a golden hammer and who try to shoehorn those same technologies into roles they are not well suited for. A pretty obvious example is people using Redis and Mongo for applications that would really benefit the most from relational databases. If you have a highly relational model that would benefit from things like referential integrity and…
> If you have a highly relational model that would benefit > from things like referential integrity and normalization > then use a relational database. If you need a massive > highly scalable KVP database, use NoSQL. I don't see why > people try to use a single approach as a solution > to every problem. Part of the problem is that people present this as a choice between relational and non-relational models, when the…