41–50 of 55 posts
There is still some interesting information here, but there are some notable missing players here (MSSQL) who I presume are missing because not including them paints Foundation in a better light.
Making no mention of Microsoft SQL Server seems like a pretty big oversight.
I thought PostgreSQL's replication was ACID-compliant?
> MySQL provides ACID transactions on a single machine That made me chortle. If you can't roll back an `ALTER TABLE` command (e.g., to back out of a failed schema migration), you don't really have good ACID semantics. Here's a list of other fun MySQL commands that sidestep transactions: http://dev.mysql.com/doc/refman/5.5/en/implicit-commit.html
Transactional DDL is a dangerous game with any DBMS. You must know the idioms of the systems you use, and use them accordingly. You would be a fool otherwise.
Can you give an example?
Earlier quoted context omitted.
Isn't ALTER TABLE a fundamentally slow and blocking action anyway? It's easy enough to make a new table and swap it in. Transactions for row-level actions are far more important.
It happens to be a slow and blocking action on MySQL, yes. That's yet another problem with MySQL. You can only make a new table and swap it in if you can stop writing to your old table, or don't care if records go missing. I've lost weeks trying increasingly convoluted methods to get an online schema migration safely in MySQL, with no satisfying conclusion. You can sometimes get away with pt-online-schema-change's me…
Earlier quoted context omitted.
It happens to be a slow and blocking action on MySQL, yes. That's yet another problem with MySQL. You can only make a new table and swap it in if you can stop writing to your old table, or don't care if records go missing. I've lost weeks trying increasingly convoluted methods to get an online schema migration safely in MySQL, with no satisfying conclusion. You can sometimes get away with pt-online-schema-change's me…
I think I expressed myself poorly. Undoubtedly it would be good if it did the on-disk data changes in the background, and a schema update seemed like an instant atomic action. But it's still a sequence point, and I see no way that transactions after it could complete while the schema update is uncommitted. So what do you actually gain by being able to do the schema update in a transaction?
Earlier quoted context omitted.
I think I expressed myself poorly. Undoubtedly it would be good if it did the on-disk data changes in the background, and a schema update seemed like an instant atomic action. But it's still a sequence point, and I see no way that transactions after it could complete while the schema update is uncommitted. So what do you actually gain by being able to do the schema update in a transaction?
The original comment was about being able to roll back, not the ability to run things in parallel. With PostgreSQL, I can start a transaction in which I'm going to perform five separate "alter table" commands; if one of these fails (maybe because I change the type of a field in a way that is incompatible with some of the data, or maybe because this is some kind of "migration" that came with a project and it has a bug…
Schema transactions are not nearly as useful/important as data transactions.
VoltDB uses a partitioned data model. For OLTP apps that fit within that model, it's incredibly fast and there's no global transaction. For transactions that span partitions, yes, there is a lock. If your app fits the model (and a lot of transaction processing does), then it's quite amazing. For instance, one model I've played with is updating customer balances in realtime. If I partition everything on CustomerId, th…
1) VoltDB's global transactions are much slower than its partitioned transactions, but it's relative. It can still do hundreds or thousands per second.
2) Making this number faster for common cases is ongoing work. In upcoming 4.0, multi-partition consistent reads will get about a 10x performance boost if they're bottlenecked on transaction overhead. This allows us to do up to 50k/sec global reads while doing 500k/sec partitioned writes. Expect improvements for global writes in 2014.
We use MySQL-Galera and it has full ACID guarantees in cluster/multi-site/DR environment. Unfortunately the article is not a complete overview of the existing DBs landscape and has too much marketing in other places as well.
I know very little about Galera replication, but its FAQ states that it provides only snapshot isolation. You are certainly correct that we have not provided a complete overview of the DB market! That is a very ambitious project. We built this page largely to call out the use of "ACID" terminology by vendors that don't actually provide it.
Am I wrong in thinking that [Neo4j]( http://www.neo4j.org/ ) supports fully ACID compliant transactions?
By default, Neo4J is not ACID compliant as it works mainly in memory, which fails the Durability part of ACID. I am not event sure that if you would configure it to be in sync with its stored replica, it would pass ACID test due to how Java handle the files internally.