以上只是根据 O(log n) 进行估算，可能不准确。但我想表达的意思是，假如一张表的某个字段的值的cardinality 很高，根据这个字段的索引进行查询，无论是 100万的记录，还是1000亿条记录，IO 次数可能差不多。

100万需要3次

1000 亿需要5次

粗略估计一下，假如 B Plus tree 每个节点的大小为 4896 byte，用来存放 big integer (8 byte)，大概可以存 300-600 个之间。[1]

假如我们取最小的数字 300 做 branching factor，那么在一张1000亿的表中读取一条记录需要几次IO呢？

5次。

[1] 我不知道block的指针占多大，所以只能估算。假如block指针大小为 8 bype，则 branching factor为 4896/(8+8) = 306。

对屏蔽的处理，我放到了 Part 3 中。

http://mednoter.com/design-of-feed-part-three.html

1. xiaoronglv 和 quakewang 是好友关系。
2. quakewang 屏蔽了 xiaoronglv
3. 当小荣吕发言时，会产生一个 event
4. RouteService.route! 在分发时，发现 quakewang 已经屏蔽 xiaoronglv了，就不会分发给 quakewang 了。

多谢，已经修改。

很多人选择推拉结合。

一个例子就是「对僵尸用户的处理」

几年前我在薄荷网工作，那时有2000万用户，但日活只有20+万。换句话说，存在大量的僵尸用户。如果为他们准备好队列，填满内容，其实是很不划算的，浪费了大量的存储空间。尤其是使用内存数据库时，简直是烧钱。当时采用的策略是：平时不管这些僵尸用户，他们的队列是空的，没有任何 feed，当他们登录时，临时去拉数据，把他们的队列填满。

但是企业市场不能这么考虑问题，SAP 的客户每年都在付费，人家买的就是服务。所以即使客户不登录，我们还是把每个客户队列中的内容准备好。

假如Bell取消了屏蔽，再次去拉Ryan的消息吗？

我的考虑：Feed 的内容大部分都有时效性，过了时间之后就没有什么价值了。取消屏蔽后，是不是可以不用拉数据啊。

Feed 流设计(四)：存储层

第四部分写数据库的选择，过几天再更新哈。

好主意！我把索引贴到文章底部了。

过来点个赞

欢迎广大已婚已育, 追求家庭和工作平衡，熬不动夜的老司机加入SAP.

我记得你们没有用 NoSQL 吧？

Experience of NewSQL DB like TiDB.

😀

曾经 redmine

jira

去 telegram 讨论

我也在带没有编程基础的学生，都是熟识的朋友，所以没有压力。带不好他们不会骂我，哈哈。每次视频交流时，也从他们身上学到好多知识。

楼主先招几个知己、愿意学编程的朋友做小白鼠，收集反馈，然后再开班，会不会好一些？

有人喜欢师徒制的学习方式，有人喜欢看视频/Google自学。大家没必要踢别人场子。（如果教的不好，自然会有他的学生踢场子）

支持一下楼主。

楼主好厉害。

当年多少人对Mongo 趋之若鹜，现在回归理性。

里面都是cxo，不差钱 😄

辛苦了

👍 👍 👍 👍

辛苦了。

unicorn 是基于进程的。

puma 是基于线程的。

你的代码线程安全吗？如果安全，推荐puma

我们是 10 Billion 级别了，MySQL 暂时没什么不好的地方。

1. 先用Ruby 代码把 sysdate -1 计算好，转换好格式。

2. 然后 select * from mz_guahao1 where ghrq > '2017-06-07'

From High performance MySQL.