HackerTrans
トップ新着トレンドコメント過去質問紹介求人

stangles1

no profile record

投稿

ASML Q4 2022 financial results

asml.com
81 ポイント·投稿者 stangles1·3 年前·80 コメント

Breaking Through Scaling Barriers with Bigtable

remesh.blog
1 ポイント·投稿者 stangles1·4 年前·0 コメント

コメント

stangles1
·4 年前·議論
I question the relevance of your point to this article, which speaks exclusively of the British Army Reserve, specifically the Cheshire Yeomanry.
stangles1
·4 年前·議論
>Why would it matter how they do it under the covers?

It doesn't really matter, I suppose I just got nerd-sniped recalling the details of Spanner's internals and their (somewhat superficial) relevance to the issues of timekeeping mentioned in the blog post :)
stangles1
·4 年前·議論
I have never heard of Yugabyte DB until just now, so no :)

One of our constraints that Bigtable met for us is native GCP support. I do see Yugabyte has a GCP provider though.
stangles1
·4 年前·議論
Good points - sharded Postgres is more likely to be a better choice in most instances. I wouldn't be surprised even if sharded Postgres would have worked well for us, but as you mentioned, for this constrained use case, Bigtable works fine.
stangles1
·4 年前·議論
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.
stangles1
·4 年前·議論
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).
stangles1
·5 年前·議論
I noticed the same when I attempted to search for text on the page, very disappointing.