Breaking Through Scaling Barriers with Bigtable
1–10 of 21 posts
Re: Breaking Through Scaling Barriers with Bigtable
#2Small nit: bigtable does support transactions. They just have to be contained within a single row.
Re: Breaking Through Scaling Barriers with Bigtable
#3Surprised they didn't mention Cloud Spanner at all.
Re: Breaking Through Scaling Barriers with Bigtable
#4Not sure I would have opted for Bigtable here over sharded PostgreSQL because it unduly limits flexibility but within this constrained use case it works fine.
The big thing to remember which is covered by this article is your only real performant option to return multiple rows for BT is range scans so your keys should be setup to support this. If you need more than 1 index you are essentially shit out of luck - hence my preference to stay with PG as long as possible, even if that means sharding to multiple servers.
Re: Breaking Through Scaling Barriers with Bigtable
#5Small nit: bigtable does support transactions. They just have to be contained within a single row.
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).
Re: Breaking Through Scaling Barriers with Bigtable
#6Surprised they didn't mention Cloud Spanner at all.
To be honest, it never even made it onto our radar, not for any particular reason though :)
IIRC, Spanner relies on precise timing to make certain guarantees, which is definitely relevant to our use case. I wonder how its write performance would stack up against Postgres and Bigtable.
Re: Breaking Through Scaling Barriers with Bigtable
#7Just out of curiosity, did you evaluate options like yugabyte db ?
Re: Breaking Through Scaling Barriers with Bigtable
#8Surprised they didn't mention Cloud Spanner at all.
To be honest, it never even made it onto our radar, not for any particular reason though :) IIRC, Spanner relies on precise timing to make certain guarantees, which is definitely relevant to our use case. I wonder how its write performance would stack up against Postgres and Bigtable.
Why would it matter how they do it under the covers? You see correct transactions. The interesting tech in this space is aws redshift, in my testing a few years ago they dominated in price performance when you used the then new node types.
Re: Breaking Through Scaling Barriers with Bigtable
#9I would never build anything critical on Google's services.
Re: Breaking Through Scaling Barriers with Bigtable
#10Small 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.