It is a reasonable shorthand to say the only interesting transactions are multi row, and thus big table doesn't support transactions. More correctly, the only transactional guarantees are single row, sure. But saying it does support transactions is misleading.
Spoken as a guy whose database did not support multi row transactions and was always told that.
It'd be reasonable to understand the underlying model, however.
A "row" in BigTable is multi-level map that can grow large (100s MB). So you can essentially encode and entire star schema on that.
The full structure is row -> column-families -> qualifiers -> timesamps -> values
You're right, it does and we actually did do some performance testing that relied on single-row transactions early on in development but ultimately found slightly better performance with prefix/range scans (in addition to avoiding some limitations with retries and replication IIRC).
Comments
Small nit: bigtable does support transactions. They just have to be contained within a single row.
It is a reasonable shorthand to say the only interesting transactions are multi row, and thus big table doesn't support transactions. More correctly, the only transactional guarantees are single row, sure. But saying it does support transactions is misleading.
Spoken as a guy whose database did not support multi row transactions and was always told that.
It'd be reasonable to understand the underlying model, however. A "row" in BigTable is multi-level map that can grow large (100s MB). So you can essentially encode and entire star schema on that. The full structure is row -> column-families -> qualifiers -> timesamps -> values
You're right, it does and we actually did do some performance testing that relied on single-row transactions early on in development but ultimately found slightly better performance with prefix/range scans (in addition to avoiding some limitations with retries and replication IIRC).