Why some NoSQL DBs only let you perform transactions on a single data item
dbmsmusings.blogspot.com
Why some NoSQL DBs only let you perform transactions on a single data item
1–10 of 56 posts
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#2This was very helpful. I am in my first project with MongoDb after a lot of experience with RDBMs and I do miss transactions. There are other things I miss more: foreign keys (dobt use dbrefs!), joins, and SQL, though.
Unfortunately this application is new, so we haven't yet seen the benefit of schemaless data changes.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#3https://en.wikipedia.org/wiki/FoundationDB
designers haven't solved all problem around transaction and performance, but that doesn't mean they have stopped trying
"As various NoSQL databases matured, a curious thing happened to their APIs: they started looking more like SQL. This is because SQL is a pretty direct implementation of relational set theory, and math is hard to fool."[1]
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#4This was very helpful. I am in my first project with MongoDb after a lot of experience with RDBMs and I do miss transactions. There are other things I miss more: foreign keys (dobt use dbrefs!), joins, and SQL, though. Unfortunately this application is new, so we haven't yet seen the benefit of schemaless data changes.
At first it seems quite freeing - no schemas holding you back. Later on, after things stabilize, it stops being helpful and starts being a burden to performance and stability.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#5ZODB ( http://www.zodb.org/en/latest/ ) is a NoSQL database that has been around for almost twenty years now. It's a Python-specific NoSQL database that allows persisting of arbitrary objects in a tree structure. It not only has multi-object transactions, transaction savepoints for memory efficiency's sake (both optimistic and normal), a pluggable 3-way conflict resolver, two-phase commit and support for long-running branches which contain multiple transactions.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#6ZODB ( http://www.zodb.org/en/latest/ ) is a NoSQL database that has been around for almost twenty years now. It's a Python-specific NoSQL database that allows persisting of arbitrary objects in a tree structure. It not only has multi-object transactions, transaction savepoints for memory efficiency's sake (both optimistic and normal), a pluggable 3-way conflict resolver, two-phase commit and support for long-running…
Also check out Durus, a close relative of ZODB but simpler. https://www.mems-exchange.org/software/DurusWorks/
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#7This was very helpful. I am in my first project with MongoDb after a lot of experience with RDBMs and I do miss transactions. There are other things I miss more: foreign keys (dobt use dbrefs!), joins, and SQL, though. Unfortunately this application is new, so we haven't yet seen the benefit of schemaless data changes.
PostgreSQL + JSON gets you working transactions and schemaless.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#8ZODB ( http://www.zodb.org/en/latest/ ) is a NoSQL database that has been around for almost twenty years now. It's a Python-specific NoSQL database that allows persisting of arbitrary objects in a tree structure. It not only has multi-object transactions, transaction savepoints for memory efficiency's sake (both optimistic and normal), a pluggable 3-way conflict resolver, two-phase commit and support for long-running…
Sure, but ZODB doesn't "horizontally scale". That's what makes multi-object transactions hard in mainstream NoSQL databases. And that's what's so cool about the linked papers; they describe two different mechanisms to achieve both multi-object transactions and horizontal scaling.
Of course, the next question is whether you actually need scaling. Outgrowing a database is a "problem of success"; if you have that problem you can throw money at the problem. It's much more important to concentrate your efforts on achieving success; choose your database focusing on your business problem, not on hopeful future potential problems.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#9This was very helpful. I am in my first project with MongoDb after a lot of experience with RDBMs and I do miss transactions. There are other things I miss more: foreign keys (dobt use dbrefs!), joins, and SQL, though. Unfortunately this application is new, so we haven't yet seen the benefit of schemaless data changes.
PostgreSQL + JSON gets you working transactions and schemaless.
Plus it scales well and doesn't randomly lose data. Oh, and the project leaders are professionals who are honest and transparent about the capabilities of their product.
Re: Why some NoSQL DBs only let you perform transactions on a single data item
#10This was very helpful. I am in my first project with MongoDb after a lot of experience with RDBMs and I do miss transactions. There are other things I miss more: foreign keys (dobt use dbrefs!), joins, and SQL, though. Unfortunately this application is new, so we haven't yet seen the benefit of schemaless data changes.
I was just starting a new project and had to make a choice. I looked at the MongoDB 3.0.x release notes to see if the project has managed to improve in the last couple of years, and there are still way too many "data files are not correctly recovered following unexpected system restarts" and "race condition between inserts and checkpoints that could result in lost records" issues being fixed in each release for my liking. Different projects have different tolerances, of course.
If I was leaning towards NoSQL I would probably choose something rock solid like DynamoDB on AWS. That thing (mostly) scales by simply throwing money at it, on my last project that had tens of millions of users it worked very well, but it's definitely not cheap.
For my personal project I ended up going with PostgreSQL 9.4. The initial user experience is still as bad as I remember from years ago (after installing PostgreSQL on Ubuntu, neither the logged in user nor root have a default DB, can't even run psql, cannot create new DB's out of the box, and the tutorial(!) waxes on about "Architectural Fundamentals" instead of "Do x,y,z to install and insert a few rows of data").
With Postgres I'm able to have JSON type columns, where my unstructured documents are stored, as well as regular foreign keys, transactions and joins at the table level. So far I'm very pleased with how it's working out, I think it's a good middle ground between the flexibility of NoSQL and the reliability + querying power of SQL.