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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Scaling PostgreSQL at Braintree: Four Years of Evolution

148 点作者 pgr0ss超过 12 年前

8 条评论

jacques_chester超过 12 年前
&#62; <i>Unlike most applications, we are much heavier on writes than reads.</i><p>I think what they meant to say is that unlike most <i>web</i> applications, they are heavier on writes than reads.<p>Write-heavy workloads -- aka OLTP -- are the bread and butter of relational databases. To the point that people complain they aren't as good at read-heavy workloads.
评论 #4663671 未加载
nathan_f77超过 12 年前
I found this article incredibly interesting, because I've only worked on low-traffic Rails apps so far. I've always wanted to learn about sharding, but haven't needed to, and didn't know where to start.<p>Now I'm inspired to start up a few VMs and have a play with the gems they mentioned, and try to get replication and failover happening.
评论 #4661914 未加载
cagenut超过 12 年前
Its not scaling if its not chock full of numbers (and maybe even graphs). There's not one mention of requests per second or latency in this. Users/capacity per shard, bottlenecks run into, etc.
评论 #4662040 未加载
falcolas超过 12 年前
Yeah, DRDB is terrible for write heavy performance. It was probably the source of many of your MySQL issues as well, but it's good that you've found a new home regardless.
JoelJacobson超过 12 年前
To author: For how long could you have avoided the need to chard if you would have off-loaded all the read-only queries to multiple hot-standby slaves instead? Your scaling story is almost identical to ours, same pg versions on same years, DRBD, etc. But we haven't split the database into multiple chards yet. I'm hoping to post-pone it for at least a year by off-loading read-only queries to a lot of synchronous slaves.
评论 #4664159 未加载
hahainternet超过 12 年前
One thing that isn't mentioned which we are currently facing problems with is the change of timeline once a failover occurs. The code isn't yet merged to use the stream to push the timeline update so all slaves must read from the shared archive.<p>Maybe I've implemented things incorrectly, but this is a frustrating issue for the moment.
评论 #4661248 未加载
jkahn超过 12 年前
Thanks for the article. What do you use to measure your PostgreSQL performance? Do you use any visual dashboards to track down bottlenecks, etc?
评论 #4663057 未加载
评论 #4661897 未加载
trung_pham超过 12 年前
Why do you put audit logs in postgresql? Wouldnt riak be a better storage?
评论 #4662923 未加载
评论 #4663054 未加载