11–20 of 56 posts
Earlier quoted context omitted.
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.
The multi feature of redis kind of allows you to create some level of transactionality over multiple items, no?
And before us FoundationDB delivered the same feature (although implemented a bit differently).
The truth is that there is a market for databases with "unreliable" writes and there are easier to design. That's why you see a lot of them.
Sorry to say but we have something that is truly transactional and distributed ( https://www.quasardb.net ). It slows down a bit writes (because of the commit) but it scales well. And before us FoundationDB delivered the same feature (although implemented a bit differently). The truth is that there is a market for databases with "unreliable" writes and there are easier to design. That's why you see a lot of them.
Given that distributed transactions necessitate distributed coordination, it would seem that there is a fundamental tradeoff between scalable performance and support for distributed transactions. Indeed, many practitioners assume that this is the case. When they set out to build a scalable system, they immediately assume that they will not be able to support distributed atomic transactions without severe performance degradation.
This is in fact completely false. It is very much possible for a scalable system to support performant distributed atomic transactions.
In a recent paper [http://cs-www.cs.yale.edu/homes/dna/papers/fit.pdf], we published a new representation of the tradeoffs involved in supporting atomic transactions in scalable systems.
https://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] [1] http://blog.memsql.com/cache-i…
RavenDB is a nice middle ground: eventual consistency for queries for speed, but ACID for create, update, and load (one or more items by ID).
It uses transactions throughout, so a failure in the midst of 10 writes will rollback all of them, as one would expect in a traditional relational database.
[0]: http://ravendb.net/
[1]: http://ravendb.net/docs/article-page/3.0/csharp/start/gettin...
Sorry to say but we have something that is truly transactional and distributed ( https://www.quasardb.net ). It slows down a bit writes (because of the commit) but it scales well. And before us FoundationDB delivered the same feature (although implemented a bit differently). The truth is that there is a market for databases with "unreliable" writes and there are easier to design. That's why you see a lot of them.
Do you use 2PC or something like Raft to handle distributed transactions?
From the docs it sounds like everytime a node joins/leaves the cluster goes into a (brief?) unstable mode and failures can happen, that doesn't sound great.