1
Mitt 2021-02-13 04:45:00 +08:00 via iPhone
这点量还不成问题吧,做好索引就行了
|
2
js8510 2021-02-13 08:27:49 +08:00
如果是纯考虑 sql 数据库的话,假设考虑用户访问同一个 DC: ( 1 )做一些 sharding 这样可以并发 select 请求。 (2) 做 replicates, 一个 master write only 然后 replicates read-only. 因为“动态” 听起来对一致性要求不高,而更在乎 延迟 (3) sql 数据库里只放纯 metadata(id, e.g topic id, item id, post id etc) 这样可以减少 DB read/write bandwith cost 把具体内容的分发剥离出去 暂时考虑这么多。
一个很好的演讲全面的介绍了 Twitter 的很多年前的解决方案。 Operations at Twitter: Scaling Beyond 100 Million Users": &t=1s |
3
sugarkeek 2021-02-13 08:48:05 +08:00
10 万不多吧,又不是同时十万个人关注,淅淅沥沥的那几个量,常见的数据库都没啥问题
|
4
owenliang 2021-02-13 10:38:41 +08:00 via Android
实际工程上会用 hbase,现在也可以看看 tidb 了。
|
5
hantsy 2021-02-13 11:29:20 +08:00
用 key/value 数据库啦,我是搞不懂为什么国内都是喜欢什么东西都是往 RDBMS 里面塞。
|
6
BiteTheDust 2021-02-13 12:35:32 +08:00
有一种做法似乎是 维护用户的时间线 在一个人发送了动态后向所有关注者的时间线插入数据
|
7
love 2021-02-13 12:40:00 +08:00
老问题了,一搜一大把。有推和拉二种,一般用推是保险做法,用拉以后可能会出大性能问题。
|
8
areless 2021-02-13 15:56:13 +08:00 via Android
in 配合 exists,在大用户上使用 exists,10 万用户应该扛得住。不要给页码,只有上一页下一页以及超时直接抛错,慢查询独立处理。
|
9
buliugu 2021-02-13 23:41:15 +08:00
新浪微博貌似是大规模使用 redis 的
|
10
chengxiao 2021-02-14 19:27:49 +08:00
印象中 KV 数据库在国内大规模的兴起和使用,就是因为社交网络
|
11
hambman OP @BiteTheDust 恩,这个是“推”模式,用户少的时候也可以。
|
12
hambman OP |
13
hambman OP @love 恩,我查询了一些经验。我理解是反过来?如果一个用户有 1 万人关注,他每发一条帖子数据库要插入 1 万条记录?
|
14
hambman OP @areless 请问不给页码的优势是?我实现上一页,下一页,是用?page=(n-1) 和 ?page=(n+1)的方法,和页码本质是一样的,有更好的方法吗?
|
16
love 2021-02-15 09:04:27 +08:00 via Android
@hambman 对呀,现在有每个人有个接受邮箱,大 V 发个帖就是群发,其实只是看着有点可怕,毕竟又不是人人都是大 V 。比如 10 万个人每个人的接收队列每天会收到 100 条消息,那相当于一天中每秒只要插入 100 条记录就行了。
|
17
e583409 2021-03-13 09:08:04 +08:00
本质上是一个 feed 流实现了吧
关系只是一部分,另一部分是 feed 流 关系可以存 kv,mongodb 这些,feed 流这块比较复杂 没有多少经验 |
18
e583409 2021-03-13 09:08:42 +08:00
可以看看微博架构 演进路线
|