底层持久化肯定要分库分表了，像这种要分多少库呢？每个库中的回答或者说评论又要分多少表呢？
打开首页看到的是关注人的热数据 这种肯定不是靠直接查库了（肯定分布在不同的库中），这种功能又是如何实现的呢？
只是想和大家头脑风暴下，大牛轻喷
This topic created in 2589 days ago, the information mentioned may be changed or developed.
 |
1
ccchooko May 9, 2019
mark~前排搬个小板凳
|
 |
4
SmallDream1995 May 9, 2019
@noble4cc 这位老哥应该只是在调侃之前的 B 站源码泄漏事件。。
|
 |
5
janxin May 9, 2019
哪有提前要知道自己要分多少的...
|
 |
6
gemini767 May 9, 2019
从来都是按照业务的发展来定义的，没有银弹
热门数据肯定有推荐系统，查库太粗暴了 |
 |
7
jswh May 9, 2019  4
分库分表并没有定数，一定是根据你的业务属性做的。
推荐系统基本不会直接查库。以前做的推荐系统设计，是每一个发布的内容进来，会推到队列里面等着做特征的计算，然后和之前的已经算好的用户特征做匹配，然后推到每个用户自己的内容队列里面。最终的 api 只有从这个内容队列里面取数据就行了，然后组合其他的非推荐内容数据就行了。 |
 |
8
leegoo May 9, 2019
经常查的数据肯定不会直接通过数据库查询的,性能太差(相比于搜索引擎), 估计你看知乎大部分都是看知乎推荐给你的,或者是排行榜的 自己去搜索内容肯定很少是吧? 至少别人肯定也是用 es 什么的来提供这方面的功能,当然降到最底层肯定是用数据库了,或许都不是你认为的关系型数据库呢?论坛这种东西丢一条回复又有什么影响呢?而且知乎的后端好像还用 Golang 重构过
|
 |
9
uxstone May 9, 2019
首先 知乎目前用的是啥数据库？
|
 |
10
taozle May 9, 2019
这么感兴趣，投个简历进来看看就知道了
|
 |
11
opengps May 9, 2019
这个能说的太多了，对于很多数据既然只读性质，那么肯定有内存性数据库当缓存用
|
 |
12
est May 9, 2019
zhihu 哪里算大了。。。。。天天都在 X 治 X 感删帖。
|
 |
13
geniusmyn May 9, 2019
插眼
|
 |
14
raysmond May 9, 2019 3
可以研究一下 reddit 以前的设计，memcache+cassandra+postgres，网上有分享。
|
 |
15
gramyang May 9, 2019
我记得知乎上有回答的，知乎的架构，你要搜索一下
|
 |
16
nimrc May 9, 2019 2
逼乎就是个小破站 啊 一台 mysql 绰绰有余
|
 |
17
jjianwen68 May 9, 2019
不同模块可能是不同的系统提供的服务，不同的系统可能又是不同的设计
|
 |
18
OakScript May 9, 2019
看到是多种存储啊，应该是 redis/memcache + mysql/postfresql + mongo/dynamo... 组合使用
|
 |
19
Weixiao0725 May 9, 2019
知乎好像也上 TiDB 了吧
|
 |
21
dexterzzz May 9, 2019 via Android
stack overflow 架构，表结构，数据都有公开
|
 |
22
mamahaha May 9, 2019
有钱能使鬼推磨，自己做好业务逻辑，剩下的花钱买机器雇人就行了。
|
|
23
mamahaha May 9, 2019
我的花瓣+知乎+豆瓣全方位娱乐汇总网站马上就要出世了
|
 |
24
ETiV May 9, 2019 1
我觉得，改造、优化 InnoDB，才能叫「数据库底层」
标题改叫「用的啥数据库，数据表咋设计的，缓存咋用的」比较合理些 |
 |
26
NB40B938mff85mtq May 10, 2019
分享你刚编的故事~~~
|
Select Language