- 下班的路上打通一把4096，还有半个小时不知道干啥...
- @淘泰来 给推荐的这个PM2.5空气净化器真牛逼 🔗 网页链接 ，200块搞定。改天搞一个跟我那个3k的比较下...
- 看了bitcoin的论文( 🔗 网页链接 ),忽然想到可以跟git结合起来,根据commit hash制定一套算法来做个gitcoin，搞一个好玩的奖励措施 @GitCafe
【内核开发者呼吁Linus Torvalds文明用词，Linus拒绝】Linux内核开发者邮件列表（LKML）可能会让任何人感到不舒服。...🔗 网页链接 【澳门大学将整体迁址珠海，没有防火长城】澳门大学即将放弃其目前的校园，整体搬迁到对面的珠海。...🔗 网页链接 【新加坡女硕士开发插件杀死定向广告】25岁的新加坡女硕士Rachel Law开发出一个插件Vortex，设计在使用者帮助下创建一个Cookies 库，共享用户资料和浏览器信息，让使用者随时切换身份，干扰定向广告工作。...🔗 网页链接 - 回复@何_登成: 很快的 从commits看 主干一直是个 brt(与(a,b)-tree类似) 主要是message buffer(尤其leaf)的数据结构在变化 最开始是pma 现在omt 个人认为buffered tree就是cache oblivious的 至于co的境界 看细节 //@何_登成: 这个查找起来，比较困难啊 //@BohuTANG_: 看commit就可以展开全文
一直关注TokuDB Fractal Tree的实现细节，从其最早披露的Cache-Oblivios Tree(图1) 🔗 网页链接 至Percona Live上的B+-Tree with Message Buffers(图2) 🔗 网页链接 到最终披露的FIFO Message Buffers(图3) 🔗 网页链接 基本上达到了与源码实现的一致性。
- 由于buffered提高了写 在scan的时候可能要做apply操作(KV的还好） 读写混合的时候 这个抖动还是有点厉害
#TokuDB# 简单调研了下TokuDB Fractal Tree的Range Scan，总体上来说，Fractal Tree的Range Scan性能相对于InnoDB的B+-Tree，有一定的差距：1. 给定查询键值，定位到Fractal Tree Leaf Page后，需要将路径上的所有Message Buffer中的Message合并到Leaf；2. 每次读取下一条记录，都需要重新从Root开始。
- 对于buffered tree，每个node大小4MB，分支因子取10，tree height 1 is 40MB, height 2 is 400MB, height 3 is 4GB... height 6就TB级了，要换成b-tree，支持TB级，这height得多高那... ...展开全文
- 要想存储引擎随机写快，工程性套路是Buffered&sometimes flush&multi-thread 今天把nessDB的buffered加大后（等于前台线程不停写到日志，后台线程不停读日志进行merge) 随机写又有所飙升 🔗 网页链接
- 『 A few thoughts about Open Source Software 』Antirez 🔗 网页链接
- 因为Google有很多像Yonatan这样的物理人才 据他讲，很多back end team的座右铭都是 "if we told you, we'd have to kill you"
都知道Google的Spanner使用了原子钟，但是你知道他们咋想到的吗？这很重要 - "Weibo, China’s Twitter, Abuzz with Sentiment Over Liu Xiang’s Olympic Fail" 🔗 网页链接 @谢科_Rutgers
