James Reading 12-07

有一个多月没有整理阅读的内容了, 最近一段时间在阅读几本书,《Systems-Performance-Enterprise-and-the-Cloud》 By Gregg Brendan,《The Art of Computer System Performance》,《NoSQL Distilled》 都很不错, 不过都没看完, 就不在这里多说了。 哈哈。

下面是10-14到今天12-07为止阅读过, 并认为值得了解的内容。

  • 运维与监控
  • http://t.cn/zR5ADrP 预警是关于“Unknown unknown”,在文中,Baron Schwartz介绍了监控系统的几个基本原则:1. 从业务角度去监控,每秒钟处理多少业务量,处理的速度如何,2. 度量并分析你关心的指标,3. 永远不要针对无法修复的问题做告警,比如MySQL的备库延迟,比如因为备份而引起的负载增加。

    http://t.cn/zRtymS0 构建有效的告警系统,1. 针对哪些指标进行监控(超载监控,频次监控,时间窗口统计监控),2.如何定义正常状态(Normal behavior ),3.如何定义非正常状态(Abnormal or anomalies )。

    http://t.cn/zRtUpuy 性能与可运维性模式,这篇文章是这本书的深度书评,从这篇书评看,本书几乎涉及到我接触/了解到的可运维性的大部分内容,对于性能相关内容,介绍比较粗浅。

    http://t.cn/zR6FCfp “Monitor Some of the Things”, http://t.cn/zR6FCfN “What should I Monitor”,Baron Schwartz最近做的两个关于如何监控/监控什么/如何Alert/如何发现Anomaly/如何做容量规划/如何做基本的性能诊断.

    http://t.cn/zR6HmCy Chaos Kong, Netflix的地区级容灾工具, 文章要点: 1. Chaos Monkey负责单主机故障容灾,Chaos Gorilla负责Availability Zone的容灾,Chaos Kong负责地区级故障容灾, 2. 利用Amazon的预留主机策略来实施地区级容灾,3. 自己实现CDN(21个机房),4.开发负责到底,5. 一切都保留3份冗余

    http://t.cn/zRjiPwZ netflix的自动容量控制平台-scryer, 基于历史的负载特征, 做容量与资源的拟合, 再基于此拟合自动的通过AWS的工具上下线机器, 从而更加有效的使用机器资源, 降低成本. 当然, 并不是所有负载都是基于固定模式(pattern)的, 此系统也接受人工指定负载特征,来应对节假日模式.

    http://t.cn/zRtU6xQ Netflix的Hystrix高容错系统的介绍。重点介绍了他们的监控系统,以及参造《Release IT!》一书中介绍的几种提高系统可靠性的Stability Patterns,如Bulkheads,Circuit Breaker,Threadpool与Semophore来控制并发访问,使用Failback、Fast Fail模式来控制故障蔓延。

    http://t.cn/zR6s4f3 “How to Run a Post-Mortem With Humans”, 如何实现no-shame的故障事后分析, 1. 从心理学的角度分析人的认知, 人通常都会因故障从自身触发而感到Shame, 2. 默认情况下, 我们都倾向于将故障定位为人的问题, 是人不够仔细不够小心, 而这对于后续如何避免故障作用不大, 3. 更好的方式是, 假设人会犯此类错误并从机制上避免

  • 性能优化
  • http://t.cn/zRyirMZ iconfinder如何优化他们的页面处理引擎(Render),将页面的处理时间从开始的91ms->29ms->20ms, 而丝毫不涉及到传统上大家认为的,系统慢是源自数据库慢. 哈哈. 基本的观点是: 需要通过Profiling的方法找到系统慢的地方,并作针对性的优化,而不只是找个替罪羊.

    http://t.cn/zHuwByv Brendan Gregg的主页, 他的几乎所有的演讲ppt, 大部分比较好的文章,在此都有汇集; 另, 看了下他推荐的阅读列表, 大部分是关于性能分析,性能优化, 容量规划与分析的书籍, 值得参考下.

    http://t.cn/zR6Q4RF Brendan Gregg的新书Systems-Performance-Enterprise-and-the-Cloud已经上架,可以购买了(价格较高,谨慎动手), 主要内容: 1. 优化的方法论(术语/概念/模型/方法与技术), 2. 动态追踪技术与工具, 包含Dtrace/Systemtap/Perf, 3. 系统各个组件的优化技术, 4. 压测,如何避免常见误区

    http://t.cn/8khwx3h http://t.cn/8khwx3P 如何利用HyperLogLog算法在Oracle中(增量的)计算表上的distinct值, HyperLogLog是一种基于Hash桶计算近似Distinct值的算法, 计算的精度基本在+-2%的范围, 优势有三: 1. 内存耗费非常小, 2. 计算速度快, 3. 可以增量计算. 这两篇文章是介绍性的, 不过很清晰

    http://t.cn/SxMn6K 深入探讨Java语言的各种对象(Collection)/类型在运行时的内存消耗, 各种Collection对象的内存消耗对比, 如何更好的管理对象的生命周期(Life Cycle), 如何有效的利用Java 的Heap空间, 同时又不降低处理的性能.

    http://t.cn/8kLSAdm 不同Redo Size在Exadata SSD上的效果, Redo Size越大, log write的写入时延波动性越大, 从而越不可用. 【从我个人的经验看,1. 尽可能不要使用SSD作为Redo 写,2.如果使用,a. 专用设备,b. 足够的预留空间(高OP), 3. 使用成熟厂家的产品(如Fusion-IO,Intel), GC算法至关重要】

    http://t.cn/8ktRmee 不错的关于SSD以及IO相关的小提示. RethinkDB出品.

    http://t.cn/8kfhwWq 针对EMC XtremIO的文章http://t.cn/8kcP1i5的回击. 从我的角度理解, EMC确实没有说清楚他的优势, 或者说, 在GC这件事情上, 他没有做什么事情, 而GC对于每一个Flash厂商来讲都应该是重要的事情.

  • 架构,评论与其它
  • http://t.cn/zRtV8xe Innotop工具的介绍, 简单的登录配置, 如何配置MySQL集群,通过innotop检测一个集群的状态, 比如一个master多个Slave的情况, 如何通过Innotop来管理集群的多台机器,在权限允许的情况下,可以通过它对多台机器发出命令. 功能还是很强大的.

    http://t.cn/zR6QhLX Todd Hoff对sosp 2013论文的回顾, “关于同步,所有你需要知道的内容”, 要点: 1. 锁的利用需要基于硬件平台, 以及对应的工作负载特征进行选择,2. 同步操作的可扩展性主要是硬件的一个属性, 3. 同步操作在单CPU上扩展性最好,4.9种不同的锁算法各有其合适的场景, 也即合适才是最好的.

    http://highscalability.com/blog/2013/12/4/how-can-batching-requests-actually-reduce-latency.html 批处理为何可以,以及在什么样的情况下, 可以降低时延.

    http://t.cn/8kLY6dz 为什么Oracle不会杀掉MySQL,1. MySQL并不是Oracle的直接竞争产品,Oracle的客户主要为运行企业级软件的企业客户,而不是互联网客户. 2. Oracle是为了硬件而购买Sun,也即目标是Exa系列的产品,3. Larry的目标是钱,并不反对开源,4.MySQL的企业支持业务发展也不错,5. M有替代的竞争产品

    http://t.cn/8kA9brd 硬盘的生命周期到底是怎么样的? 一块普通的磁盘寿命如何?

    http://t.cn/zjjwPQ1 为什么MongoDB在Etsy使用的并不好,MongoDB的成名/成功主要得益于两大功能:Schema-Free,Auto-Sharding, 当一个公司已经有相对成熟的MySQL运维体系的时候, 当公司有足够的技术能力做好去范式化/Sharding Key的选择/自动Sharding扩展这些功能时, 引入一个新的数据库好处就很有限了

    http://t.cn/zRQV5qv Robin Harris (StorageMojo)谈论传统大型存储的情况, 1. 已经不适合时代, 2. 会逐渐被Flash Storage取代. 仍然健在的原因,1. 【Availability】更好的可用性,2. 更友好的使用。Flash存储的工作方向:1. 更好的压缩,2. 更好的实时去重,有效提供更好的Capacity/$。

    http://t.cn/zRIw0pV (请自备梯子), Twillo的高可用架构变迁, 谈及Twillo如何根据业务的需求与特征, 并从故障的角度分析高可用的天敌: 数据持久化与变更管控, 总结了几条规则: 1. 尽可能无状态,2.分离有状态与无状态的组件,3.使用Cache与Sharding,4.分解数据的生命周期,降低数据管理复杂度.

    http://t.cn/zRJMybK MySQL上的几种高可用方案, 各种对比, 各种介绍, 自己体会吧.

  • 社会心理
  • 人力资本与非人力资本在产权性质上的差别很大,在自由社会中,人力资本的所有权仅限于他本人. — 罗森(芝加哥大学经济系,劳动力经济学的领导人物).

    果树会结果,农地有收成,结果与收成都是收入. 然而, 这收成可不是在果熟或稻熟时才得到的. 果树或农作物每天都在变, 不停地变, 而每一小变都是收入(或负收入), 所以, 收入是一连串的事件了. –摘自周其仁《收入是一连串事件》之张五常序.

    The first principle is that you must not fool yourself – and you are the easiest person to fool — By Richard Feynman.

    http://t.cn/zR6zfjL 控制人们的头脑是控制整个国家的关键,语言文字就是制度的基石。 ——〔波兰〕切斯瓦夫·米沃什

    http://t.cn/8kLAGW1 权利是得到社会认可的、大部分人主动维护的选择的自由。任何在现实中能够行使的权利,都离不开他人的背书和支持。换言之,我们可以倡议某种权利,并声称它是一种 “自然权利” 或 “天赋权利”,但除非它得到普遍的尊重和维护,它就只是应然而非实然的关于权利的主张而已(薛兆丰)

    Jame’s Reading 10-14

  • 技术文章阅读
  • http://t.cn/z8OBJG5 对于varchar2/nvarchar2类型的字段,在12c 中最大可以支撑到32k大小了, 对于很多业务来讲, 这可能是个不错的选择.

    http://t.cn/agGm7R 各种不同的Replication方式对于一致性/事务支持/响应时间/吞吐量/数据丢失以及故障切换能力的支持.

    http://t.cn/z81ivvF Linux TCP/IP Tuning for Scalability, 重点介绍了Linux下几个网络的参数, 如何减少网络连接的开销, 从而提高系统对于并发连接数的扩展能力,1. file handle,2.time_wait 超时,3.connection tracking超时,4.通过lnstat监控网络相关cache的大小,5.tcp window滑动窗口.

    http://t.cn/zR5wPXL By John Allspaw,在Etsy,我们如何从故障中学习,也即如何面对故障,以及触发故障的人。

    http://t.cn/zR5AA8Q Bit.ly 如何利用Z Proxy来做全站的容灾,当然,Bit.ly的主要业务比较简单,只是根据“short url”来获取“Long Url”,而Long Url都是已知的,immutable(不可更新)的内容,为他们实现此方案提供了便利。

    http://t.cn/zR5ADrP 预警是关于“Unknown unknown”,在文中,Baron Schwartz介绍了监控系统的几个基本原则:1. 从业务角度去监控,每秒钟处理多少业务量,处理的速度如何,2. 度量并分析你关心的指标,3. 永远不要针对无法修复的问题做告警,比如MySQL的备库延迟,比如因为备份而引起的负载增加。

    http://forums.mysql.com/read.php?144,545664,545664#msg-545664 关于MySQL Fabric的设计, 实现, 使用与介绍, 以及其它Sharding相关内容的介绍. 每一篇都值得深入阅读.

  • 技术书籍的阅读
  • 研究了一下 Python 的SQL解析器, sqlparse https://github.com/andialbrecht/sqlparse , 做了一定的修改, 基本可以通过它从Oracle SQL语句中解析出表名称了. 目前对于子查询的支持还有一点不过.
    通过同事 @白樵, 了解到一个关于通过Python操作Oracle的Reference, 并学习部署并写了几个小程序, 已经有信息通过Python来操作Oracle数据库了.

  • 社科类图书阅读
  • 张五常《 经济解释卷三:受价与觅价(神州增订版)》
    张五常《 经济解释卷二:收入与成本(神州增订版)》
    张五常《新卖橘者言》

    张五常的这几本书, 刷新了我对这个老头子的认识, 也同时刷新了我对经济学的认识,当然,更基本的是他在书中深入的教了我,如何使用科学的思维去看待事务,看待日常生活,看待经济生活的那些小的细节

    李笑来《把时间当作朋友》 这本书写的很通俗,很幽默,也很有用。告诉我们,该如何与时间打交道,如何控制并安排自己的时间,如何控制并管理自己的心智。值得深入阅读,并依照实践,虽然,实践起来会有反复,会有痛苦。

    Jame’s Reading 09-10

  • Scalability 也即 扩展性
  • http://t.cn/z8wbRUs Reddit 系统扩展的经验与教训,1. 尽可能的自动化,2. 没必要一开始即构建可扩展的架构,3.不要在刚开始时构建SOA的架构,4.可扩展的关键是在用户感知到瓶颈之前解决掉扩展性的问题,5. 视SSD为便宜的内存,而不是昂贵的硬盘,6. 每种工具都有其对应的场景,合适的工具用在合适的地方.

    http://t.cn/z8wheDy 可扩展性的问题. 从并发连接的角度阐释扩展性的概念, 对于单个请求时间很短, 但需要大量长连接的业务, 基于进程/线程模型的系统(Apache , Oracle Dedicated模式)在处理大量请求时, 扩展性表现较差; 而基于Event驱动的系统(Nginx/Oracle MTS/MySQL)的表现就会好很多.

    http://t.cn/zTc4oZu 扩展性与性能并不是一对冤家. 现阶段, 对于扩展性的关注远远超过对于性能的关注, 有很多人觉得只要解决好扩展性即OK了, 也就是只要将关键共享资源拆分掉就可以了. Theo驳斥了这种说法, 1. 当前很多系统提升一倍性能不是难事, 2. 节约一半的服务器, 可以节约掉很多隐性成本.

    http://t.cn/z8Zefs6 2x2x2 Requirements for Database Scalability, 关于数据库扩展性的简要介绍, 2*2*2的说法比较有意思, 第一个2: 水平扩展/垂直扩展, 水平扩展通过复制与拆分实现,垂直扩展通过数据库内存化(In Memory DB)以及快速持久化(RDMA网络或者NVM来实现).

    http://t.cn/zQ0L5q1 20 Obstacles to Scalability 【By Sean Hull】实现系统扩张性(Scalability)的20个障碍,这个内容此哥们已经重复多次, 这次做了一个整合,算是比较完整,也值得参考。唯一不认同的点是,多次使用at all costs,这是一种不理智的态度,但是,却是需要慎重考虑的。

    http://t.cn/z8iuiqJ Scaling out and creating fault tolerant systems with MySQL replication , 如何通过MySQL复制实现Scale out的可容错的系统, 名称很吓人, 主要三点内容: 1. 主备拓扑结构管理, 主备自动切换(MHA), 2. 请求的负载均衡与连接池管理, 也即大部分数据库中间件做的主要事情(如TDDL)

  • 解决方案与应用案例
  • http://t.cn/zY8W7V3 可接受的响应时间,1.页面响应时间没有行业标准,2. 关于人机交互的时延,有认知科学的结论,人感知不到1/4秒以内的差距,3. 8秒钟响应的规则过于简化了,4. 用户不再接受所谓的平均响应时延,5. “4秒钟规则”或许无法描述用户用户体验,6. 期望与体验的关系决定了用户的满意度

    http://t.cn/z861NpO 性能反模式,1.在项目结束时才去修复性能问题,2.度量并修复错误的指标,3. 忽视算法的作用,4. 集中关注自己能看到的东西,而不是根本的问题,5. 软件层次太多,6.过量的线程, 7.硬件使用不均衡,8.在CPU之间做无效的数据拷贝,…

    http://t.cn/zO3hEPD Godaddy使用Cassandra作为其Session Store,1. 使用A/B集群来提升集群升级的处理,2. 协作开发ASP/ASP.net 的协议来访问,提供连接池、压缩、配置管理等特性,3. 在Cassandra支持TTL功能之前,通过设置人工的第二索引来做Expire Session的清理工作。

    http://t.cn/z8Mo36p 为什么Cassandra不需要(使用)Vector clocks By Jonathan Ellis ,看完,感觉Jonathan基本讲明白了Vector clock的问题,1. 性能问题(读,反序列化,序列化,写),2. 数据的多版本,3. 可以帮忙找到不一致,如何解决,还得用户自己来。但是,对于Cassandra为啥不需要我没看明白

    http://t.cn/zQHfmu8 NUMA (Non-Uniform Memory Access): An Overview, Numa概念的总体介绍, 1. Numa只对内存访问密集型业务有好处, 2. node local与interleave之间的差异, 3. Linux如何处理进程的Numa内存分配, CPU调度如何优化Numa相关的进程, 4. 常用的Numa相关工具,numactl/numastat/numa_maps

    http://t.cn/z8UpsOZ 对于时间序列的数据存储来讲,TokuDB要明显优于InnoDB, 无论从数据加载时间, 还是数据的压缩效率上来讲, 都有好几倍的优势.

    http://t.cn/z8w7lkU LinkedIn新近在Apache开源了其流处理平台(Stream Processing System). Apache 地址: http://t.cn/zQDVp4j

    http://t.cn/zQS7y8k oratop from MOS (帖子原文), MOS(Oracle Support)的地址: oratop – utility for near real-time monitoring of databases, RAC and Single Instance (Doc ID 1500864.1)

  • 性能优化以及其它
  • http://t.cn/zQa8Mz1 分布式一致算法与Raft, Riak的人介绍基本的分布式一致性, Data Loss的几种可能, 以及强同步情况下, 一致性与可用性的权衡, 最后介绍Raft的算法, 以及他们基于Erlang语言的实现.

    http://t.cn/z8L4VyC 在排队的时候, 为什么自己所在的队列走的更慢. 本文从人的认知偏见等心理学因素上对此进行了解释.

    http://t.cn/z8ij2nc 性能相关的书籍. 这篇文章里面收集了大量的各个领域与性能有关的书籍, 自然也包含很多我喜欢的书籍. Neil Gunther与Daniel A. Menasce写的容量规划系列的书,Connie U. Smith写的性能工程书籍, Brendan Gregg的性能分析系列,Martin L. Abbott 写的架构设计原则系列的书.

    http://t.cn/zQDqCyQ 如何通过修改SQL语句中的一行,提升100倍的查询效率。我早期进入Oracle Database这一行,也是因为类似的案例。最初写的一个比较差劲的SQL语句,第一次运行耗时13个小时,经过优化,最后运行23秒左右搞定。

    #oracle tips# http://t.cn/zQHHGIa 如何有效的kill一个session, ALTER SYSTEM DISCONNECT SESSION ‘sid,serial#’ (immediate|POST_TRANSACTION). 找个时间验证下, 由于kill session的问题,咱还背过一个大的故障呢, session kill了,process却没有干掉,导致max process报错了.

    http://t.cn/zQl4dM4 The top 5 proactive measures to minimize MySQL downtime 1. 维护经过验证的备份,2.构建冗余组件以应对单点故障,3.变更都要经过验证,并有回滚计划,4.验证复制/副本的有效性,5.做好监控与趋势分析,提及的几个监控项比较实用。

    http://t.cn/zQYU2X1 Facebook的MySQL工程师 domas mituzas 探讨Durablity的问题。总体而言,Durability是关于权衡的艺术,而在MySQL中,为了实现持久性,付出的代价是相当高昂的,3次FSync操作才能确保一个事务的持久性。而MySQL主备的可靠性设计还不够安全(Crash-Sage),5.6已经有了较大改善。

    http://t.cn/zQa8KMi The Antifragile Organization(反脆弱的组织), Netflix的Ariel Tseitlin介绍他们在Netflix的高容错系统设计, 对与Failure的态度, 如何处理Failure, 如何做设计规避Failure带来的问题. 后面是从各个可能带来Failure的维度, 从系统层面做Fault Tolerance的设计.
    反脆弱的概念因此塔勒布的新书《反脆弱》。Netflix介绍他们的Simian Army系列的捣蛋鬼(monkey)系列(Chaos Monkey,Latency Monkey…..),基本设计思路为:1. 通过冗余来设计具有容错能力的应用,2. 通过构造故障来降低不确定性

    故障Review的几个关键问题,1.哪里出故障了? 2.如何快速发现此故障?3.如何避免此故障的再次发生?4. 如何避免这一类故障的再次发生?5. 如何提升我们下次处理此类故障的效率? By Jeremy Edberg, Reliability Architect, Netflix

  • 社科类图书阅读摘要
  • 在一个没有市场的社会中,竞争也是层出不穷的,只不过竞争的形式有所不同罢了.弱肉强食是竞争,权力斗争是竞争,走后门、论资排辈,等级特权等等,都是竞争形式.道理明确:凡是多过一个人需求同一经济物品,竞争必定存在. 摘自张五常《经济解释:科学说需求》第二章结尾。

    尽管报复会带来许多伤害(经历过反目成仇或者艰难离婚的人应该明白我说的是什么),我还是要说报复的威胁–即使人们要付出巨大的代价–能够成为维护和支撑社会秩序有效的强制机制. 我并不主张”以眼还眼,以牙还牙”,但我猜测,报复的威胁总的来说是具有一定功效的. 摘自丹.艾瑞里《怪诞行为学》第5章.

    对出现在我们面前的所有假说进行最具怀疑性的审查,与此同时对新思想最大限度地保持开放心态。如果你…没有一丝怀疑,那么就无法分辨有用的思想与没有价值的思想.如果所有思想都具有同等的有效性,那么你就失去了自我,因为那样..根本没有什么思想是有效的. 摘自《误区:思维中常犯的6个错误》54页.

    1. 我们对某一事物付出的努力不仅给它带来改变, 也改变了自己对它的评价, 2. 付出越多, 产生的爱恋越深, 3. 我们对自己的作品估价过高, 这一偏见深入骨髓, 误以为别人也和我们的看法相同, 4. 如果付出巨大的努力仍然没有获得成功, 我们就不会感到过多依恋. 摘自丹.艾瑞里《怪诞行为学》

    如果你在心仪的人追你的道路上设置一些障碍让他们追得更辛苦,他们一定更加珍惜你.从另一方面说,如果你把他逼到绝境还一个劲儿地拒绝他们, 那你就别指望说”我们直做朋友”. 摘自 丹.艾瑞里 《怪诞行为学》.

    努力提高”中国制造“的技术含量,这是目前我们公共政策的主要方向。不严厉压缩权力寻租在租值中的比重,我认为是不可能实现这一转型的。在这一意义上,政治体制改革远比经济体制改革更紧迫。或者说,如果不改变政治运作的方式,任何显著有效的经济体制改革已经不再可能了。丁丁《行为经济学讲义》97页

    “哈耶克说:一个伟大社会的制度特征,就在于他鼓励一切个体在一切可能的方向上探索,因为我们不知道未来可能的降临的灾难中,哪一个方向的探索可以拯救我们全体;拯救我们的英雄,由于大自然和我们生存环境的不确定性,必须是匿名的--于是只能鼓励一切方向的探索。“-汪丁丁《行为经济学讲义》93页

    如果你有生活常识,那么你学习理论的时候就会不断回到你的常识,你会发现问题-要么是理论自身的问题,要么是常识的表达问题。生命体验是真实的,生命之树常青。所以,知识永远是知识过程,不是静止的一堆概念,知识过程是与你的人生体验纠缠在一起的,体验的丰富和深刻,使你的知识变得丰富和深刻。

    柏格森(Henri Bergson)认为, 概念就是用来涵盖生命体验的, 如果你使用一个概念而毫无生命体验, 这概念对你而言就是苍白的, 它毫无意义, 你不曾为它的任何部分感动过. 摘自 汪丁丁 《行为经济学讲义-演化论的视角》

    社会发展依赖于个体的创造性,因为创造是个体的事情. 可以个体创造精神需要社会的宽容,宽容又是整体的性质, 没有宽容, 个体自由也就消失了. 所以, 自由是整体的, 创造是个体的. 摘自: 汪丁丁 《行为经济学讲义》 第102页。

    感激与承情虽然都是人因接受了某种帮助而产生的“情感”(emotions),但性质并不相同。一个人接受帮助或赠与后,感觉到承情是一种负债的感觉,帮助者或赠与者也希望他有这样一种感觉,会不断提醒他,一再要求他应该“感恩”或“知恩图报”,否则就是“不知感激”、“没良心”或者“忘本”。By 徐贲

    http://t.cn/z8iFq1R 极权主义制造恐惧技术的最大特点是利用不确定性,只有这种不确定性才能造成恐惧效应的扩大。同时,也只有不确定性才能形成你内心的自我约束和自我审查。而不确定性起作用的条件,就是权力的总体性和任意性。任意性才能造成不确定性,而总体性才能扩大任意性的空间。

    Jame’s Reading 07-25

  • 论文类的阅读与分析
  • http://t.cn/zHFP5Yj 云存储环境下的低成本虚拟机数据去重,Hong Tang与其在Ask.tom的前同事现伯克利圣芭芭拉分校的Tao Yang合作撰写的论文,对于在云环境下的备份方式(Sharding Meta 信息),先计算指纹再去重,虽然整体算法上的改进不大,不过由于拆分+并行处理,总体的效率与开销还不错。

    http://t.cn/zHF7hqo Facebook推出的修正版RS code来缓解传统的RS code恢复导致的网络带宽问题,在基本的10+4的RS code模式下,他们平均每天会消耗180TB的网络带宽用于进行数据恢复,使用新的修正版RS code从理论上可以降低30%左右的网络带宽需求,主要思路为计算校验码时附带一份上一个条带的数据。

    http://t.cn/zQZCowQ Murat Demirbas对Google Spanner Paper的解读(博客中有大量经典论文的解读), 重点解读了这篇论文章TrueTime API的实现与作用, 实现: 依赖于原子钟, 通过比较Paxos以及2PC Prepare的时间戳来获得Snapshot Time,作用: 简化Snapshot Read时的设计,实现类似于Oracle闪回Time->SCN.

    http://t.cn/zHFKAKr Velocity 2013 上几个不错的主题推荐, 除前几天已经发在微薄的部分内容,还有Performance Methodologies for Production Systems (Brendan Gregg),Quantifying Abnormal Behavior(Baron Schwartz), A Systematic Approach to Capacity Planning in the Real World (Twitter)

  • 统计与监控的分析
  • http://t.cn/zQZNFxc Baron Schwartz的新公司博客, 解释统计过程控制的4个基本规则,1.有指标超出3个标准差的范围,2.连续3个点中的2个在2-3个标准差之间,3.连续5个点中的4个在2个标准差之外,4.连续9个点在平均数的一侧. Etsy的Skyline(http://t.cn/zQZNFxV与oculus参考了统计过程控制的方法论.

    http://t.cn/zQqS4OT 为什么平均数不好使, 而百分位(percentile)却很好用. 在图中同时显示avg/min/max的图表, 没有显示50%,75%,90%等几个百分位的延时信息的图表, 后者可以显著的提高分析/定位问题的效率.

  • 产品以及系统的设计使用.
  • http://t.cn/zQZCDkp Lars Hofhansl 介绍HDFS(HBase同)的一个设计缺陷, 在极端情况下,当机房突然掉电时, HBase不仅可能丢失最新更新的数据, 如果刚好又在做Compact,也可能丢失较早之前更新的数据,此文中给出了他们的解决办法,通过调整 参数dfs.datanode.sync.behind.writes和dfs.datanode.synconclose

    http://t.cn/zQZpWtF Oracle NoSQL database的访谈. 重点讨论了它的Major/Minor Key的设计(个人比较喜欢此设计,非常接近于DB Sharding);Master/Slave的Replication设计,通过Paxos以及简单多数仲裁来确保写一致性;对avro序列化的支持(更好的Json集成);支持简单转换后成为Oracle的外部表,便于数据互通.

    http://t.cn/zQZWRaz 获得安静(没有输出)的Slow Query log在扩展性上就比较happy了. 作者的想法其实很简单, 大部分扩展性问题, 都是来自数据库的Query效率不够, 尤其是Query的索引设计不合理. 通过较好的SQL设计, 较好的索引设计, 大部分公司的Scalability都可解决. 还有一小部分,需要再配合Sharding

  • 对于技术的理解与方法论介绍

    http://t.cn/zQbKq2g 从Brendan Gregg角度看,成为专家的一些基本原则:1. 严谨,2.世上无难事,不过从时间上看,有代价,3.使用科学方法,并注意其假设,4.不要(轻易)信任任何事情,尤其是压测,OS的指标也会撒谎,5.注意known knowns, known unknowns, and unknown unknowns的事情分类.

    http://t.cn/zQbOYj8 Lessons from Building and Scaling LinkedIn By Jay Kreps . 很多经验都比较有参考意义. 1. Scale 系统大部分都与Scale State(或存储State的数据库)有关系,2. 如何Scale内部的开发能力, 3. 如何Scale 系统的规模, 4. 如何管理Large scale的SOA化的服务(Service).

    http://t.cn/zQ55h2U Theo认为当Scale Up是可行的时候(满足未来1-2年的需求), 就不应该做Scale out.如果你的系统/项目的增长率低于摩尔定律, 应该始终考虑使用更大的机器(更好的廉价PC)来满足需求. Scale out需要耗费大量的工程师资源来解决基础设施的问题, 而工程师资源应该用在更高效的地方.

    To be truly excellent,one must treat it as a craft.one must become a craftsman.through experience learn discipline. and through practice achieve excellence. By Theo. 《A Career in Web Operation》
    step 1,educate yourself,step 2,be disciplined,step 3,learn from & share with your peers,step 4,be patient.experience takes time(and mistakes). Everyone in your organization needs Operational Mentality.operations is a state of mind it is a state of being it is a mentality.

    http://t.cn/zQZYxn5 If you want to get the factor 50 speed-up of SSDs, you’d better avoid reading large chunks of sequential data, because that’s where you can only gain a factor five improvement. 非常有洞见的一句话.

  • 社科类
  • http://t.cn/zHs11Jl 【周其仁】还是没有“公平”,因为还有将来增加的人口。无论未来新生的,还是下嫁到下营村的人口,因为没参与此次财富分配的存量,一定会引起未来村民家庭之间财富的不均等。那就等着吧,为了未来的“起点公平”,人们只好在永无宁日的冲突中,等待着诞生永恒公平的土地制度。

    http://t.cn/zjz0p4F “特定的社会结构决定了一套陈述是否为谎言或知识。换句话说,知识不是客观的,它首先依赖于它所在社会的权力结构,这样的权力结构” . “费孝通命题”,大意就是:你有什么样的社会结构,你就积累什么样的知识结构。【汪丁丁:谎言与知识 自由是整体之事】

  • 社科书籍推荐
  • 丹.艾瑞里 《不诚实的诚实真相》 从行为学的角度分析, 人类为什么会不诚实, 在哪些场景下会不诚实, 如何通过规则的控制来降低人的不诚实程度.

    贾森·弗里德 《重来》37Signals的创始人介绍如何通过简单的思维来做系统的开发与处理,深入的内容,可以参考 @左耳朵耗子 的相关博客文章.

    罗尔夫·多贝里 《清醒思考的艺术》 书中列举了52个人类常犯错误的思维陷阱,也即人类在认知上的一些缺陷,多读读有助于修正自己的思维缺陷。

    Lessons From Building and Scaling LinkedIn

    Jay Kreps

    1. scalability is about managing state, 管理状态(可变化的值)是Scalability的大头

    2. make simple cheap scalable primitives,

    3. ops first, 运维功能/特性优先

    4. do hard things later, 先解决容易做的事情.

    5. services (may) scale development, 服务接口(可能)会导致开发资源

    6. Bad Services << No Services << Good Services. 不同的服务化之间的效果比较.

    7. the service contract is binary, 服务接口是二进制的

    8. isolation vs utilization,通过切换代码模块来扩展软件开发能力

    9. build your process, 构建适合你自己的流程

    10. treat code as property

    11. but you need effective government

    12. don’t duplicate integration layers

    13. agility requires safety

    14. Risk = sum(Probability * Cost)

    15. measurement > prediction

    16. reduce time in error or exposure to error