TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Breaking Through Scaling Barriers with Bigtable

41 点作者 ntietz大约 3 年前

6 条评论

jpgvm大约 3 年前
Not 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.<p>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.
评论 #30601769 未加载
评论 #30601976 未加载
jeffbee大约 3 年前
Small nit: bigtable <i>does</i> support transactions. They just have to be contained within a single row.
评论 #30601584 未加载
评论 #30600565 未加载
jvolkman大约 3 年前
Surprised they didn&#x27;t mention Cloud Spanner at all.
评论 #30601935 未加载
评论 #30600614 未加载
bgm1975大约 3 年前
I’d be curious to know if cockroachdb was evaluated as a potential candidate. The various literature bits I’ve read seem to indicate its whole reason for existence is to solve these kinds of problems at scale while still providing some semblance of ACID compliance.
评论 #30602989 未加载
srinijdi大约 3 年前
Just out of curiosity, did you evaluate options like yugabyte db ?
评论 #30601907 未加载
throwawayboise大约 3 年前
I would never build anything critical on Google&#x27;s services.
评论 #30601773 未加载