...
http://t.cn/zT6Wun1 http://t.cn/zT6Wun3 GroupOn使用MySQL的一点经验:1. slow log的切换处理,2. 使用playback在Slave上重放操作,以warm up备库的Buffer Pool. http://t.cn/zT6JusR 根据数据的价值来选择匹配的数据存储成本, 数据有三个维度(新鲜度,访问频
http://t.cn/zT6Wun1 http://t.cn/zT6Wun3 GroupOn使用MySQL的一点经验:1. slow log的切换处理,2. 使用playback在Slave上重放操作,以warm up备库的Buffer Pool.
http://t.cn/zT6JusR 根据数据的价值来选择匹配的数据存储成本, 数据有三个维度(新鲜度,访问频率,商业价值,即:Recency/Frequency/Monetization), 根据这三个维度去评估存储的数据,并选择对应的存储设备(Flash/SAS Disk/Sata Disk; Local/SAN).
http://t.cn/zT6G2jE 可扩展系统设计,常见技术:1.负载均衡,各节点无状态,2.数据分区(DB Sharding),3.批量处理(M/R),4.缓存(静态数据/动态数据/连接池/重复计算),都权衡一定的一致性损失,5.异步处理,与业务解耦组合使用,一般都涉及使用队列(Queue),6. 关注并发(Shared Mutable State,本文没有)
就@bluedavy 的一条微博消息,我自己的一点看法:规模非常大的时候,相对于小规模场景,主要的技术差异也就拆分(partitioning/sharding)加上运维自动化, 而实际上,小规模业务也是可以去做运维自动化的. 因此, 除了不怎么需要做拆分(业务层/数据库层)外,技术差异是很小的,就在于你自己的追求了. 【说你呢】哈哈
当然，规模大了，如何提高运维效率、发布部署效率，如何切实的减少、控制系统依赖的规模，如何有效的控制故障的范围与等级，都会有更多的挑战，而这些内容，在追求完美的工程师来讲，规模较小时也是可以做较多的尝试与实践的，比如远比淘宝规模较小的Etsy在这方面就有较多也较深入的经验。
技术是为场景服务的，但是，不是等到有场景才有技术，而是需要在场景未到之时，先从其它渠道尽可能的了解到相关的技术，别人在此过程中曾经遭遇的痛与坑，尽量做到不要重复的遇到别人曾经遭遇的同样的痛与坑。希望 @bluedavy 毕玄同学可以深入的分享下自己遭遇的那些痛与坑
我周日在ACOUG上进行分享的PPT，从方法论的角度讨论Oralce数据库的优化，优化的关键点还是在于如何定位瓶颈资源（Contention），并通过Scale Up（优化）或Scale out（拆分）的方式进行缓解：”Oracle 性能优化.pptx” http://t.cn/zT6PcMw
我4月18日在DTCC数据库大会的演讲：”CAP 理论与实践.pptx”，主要观点：1. 过去的所谓CAP，Pick Two过于简单粗暴，不合理，2. 现实的情况是，根据业务的数据的含金量确定可接受的C，再尽可能提高A，类似于信息展示类的会更多的选择牺牲C，而资金类则保全C http://t.cn/zTxf7wO
http://t.cn/zTVs1Ll 如何通过RMAN将Oracle的数据库备份到Amazon S3，其实备份到其它的类似的云存储上，也可以考虑类似的处理方式。 Amazon AWS提供的白皮书，http://t.cn/zTVs1Lj
http://t.cn/zTcJYvz http://t.cn/zTcMuJa http://t.cn/zTcJYvZ 如何基于Unreliable Cloud设计Reliable System. 1. 识别应用的有状态部分与无状态部分，2.使用真正的分布式的数据存储来对有状态部分进行冗余处理，3.确保冗余处在隔离的故障区域，4.识别故障依赖并降低故障影响,5.将服务细化并隔离Complexity + Scale => Reduced Reliability + Increased Chance of catastrophic failures，The higher the number of dependent components => the lower the overall availability and the bigger the impact of failure，http://t.cn/zTcMuJa 这两句话值得细细思考。
“The marginal cost of reliable hardware is linear while the marginal cost of reliable software is zero.” 可靠硬件的边际成本是线性的，而可靠软件的边际成本为零。也即：在一定的规模下，可靠的软件相对于可靠的硬件会更加便宜。http://t.cn/zTcIsx3
这篇文章中，我同意关于Reliable/UnReliable;Software/Hardware的比较，以及可能的边际成本比较，对于其所举的例子持保留态度。
其实，目前的Reliable Software也是通过冗余(Replication)来实现Reliable，就如同Reliable Hardware更多是通过Pair（双份）来实现冗余，其它都是软件控制//@jametong: 这篇文章中，我同意关于Reliable/UnReliable;Software/Hardware的比较，以及可能的边际成本比较，对于其所举的例子持保留态度。
几篇关于Performance与Scalability的文章，http://t.cn/zTc4oZm http://t.cn/zTc4oZu http://t.cn/zTc4oZ3 可以通过优化减少资源使用或提供更多资源来增加可扩展性，前提是你的架构允许使用更多的资源，也即并行化处理请求的能力，这通常来自于限制完全并行化能力的数据库，原理即Amdahl定律
http://t.cn/zTtDU3Z Quora的创始人Adam D’Angelo讨论为什么Quora使用MySQL而不是NoSQL，1.如果支持Sharding的话，MySQL的扩展性并不差，2.NoSQL并不像宣称的那么可扩展，稳定性还有待改进，3.主数据存储不能冒太大风险,4.不拆分，MySQL的扩展性也还好，5.可通过中间层解决分区两年时间观察下来: 发现搞传统RDBMS或一直在RDBMS上做工具和产品的人还是一样的敏感，总是试图去寻找看看谁又在说“不用NoSQL的理由了”，听者从中得到安慰。在如今RDBMS、NoSQL边界越来越模糊，科研、工程技术人员都钻破头想着如何把两者融合的现实中，总有人忧虑自己会的东西会不会过时!怎会过时呢？
回复@zhh-2009:两者在融合，只是从两个不同的方向在往中间努力。1. NoSQL在考虑增加一定的ACID支持，由于大规模Scalability的需要，目前主要还是基于单Sharding维度的ACD整合，2. 传统RDBMS在整合部分NoSQL的理念，a. pg支持Schema Free，b.M支持基于引擎的调用，c.简化Sharding管理的大量工具
回复@zhh-2009:是的，这几年很多存储引擎层的改进，都出现在写优化算法的改进上，从这个角度看，其实我更加看好TukoDB与Acunu的改进， LSM-Tree对读是很不友好的，同时，Merge对资源的浪费也是比较严重的，性能与吞吐量也会由于Merge的存在无法做到持久稳定的性能，这对于生产环境的容量规划是个问题
http://t.cn/zTUHTum 如何禁用Oracle 11g的新的xml格式的listener.log以及如何指定listener.log的位置。对于我这种古董级别的人有用处，哈哈。
http://t.cn/zYexkvH 如何利用Thread Pool提升MySQL系统的吞吐量，参造交通系统的流量控制，以及排队论的基本知识介绍如何通过Thread Pool来提升系统的吞吐量，在没有Thread Pool的情况下，系统的用户到达率会不断增加，而从不断增加对系统关键共享资源（CPU、内存）的占用，损害到整体的吞吐量。
新浪的面试题：用户更新数据时，修改了database数据的同时需要修改memcache，为什么facebook这篇文章里面推荐用delete key的方法来更新cache，而不是直接update？
我的理解,两个关键点:
1. Update处理，由于Key不会从缓存中消除掉，如果由于程序重启或其它原因导致中断，则会导致缓存中的数据必须到过期(Evicted)，都会是Stale的数据，可以通过其它的机制来进行补偿，但是，代价也不低。//@TimYang: 估计用update的人更多一些，ugc类型产品，只要不是共享资源修改，通常也没问题
2. 并发问题处理, 关键还是Delete操作是幂等的，并发问题容易解决；Update操作是带状态的，如何做好并发控制是个难题. 所以通过Delete＋Select的PutKey更加容易控制，复杂度也更低。关于更新缓存与数据库更新不一致的问题，DELETE与Update Cache，需要考虑补偿方案来解决。
3. @一乐 同学跟我说,Memcache的Delete操作有一个Holdoff功能,可以更好的控制Cache处理的并发问题.
http://t.cn/zTXSeHC 关于Message系统的简要介绍,Message的作用(性能/解耦合/扩展性/成本与高可用),消息处理的模式(路由规则/是否持久化/消息转换协议),常见消息系统的简要实现与特性,消息系统的功能需求的总结,消息系统的运维需求(持久化/高可用/管理特性),常见消息系统在不同场景下的性能比较.与此博客文章,对照阅读: http://t.cn/zTXowBV 1.Brokers perform much better with bigger messages, 2. ZeroMQ is a perfect message dispatcher among processes,3. Except for big messages, RabbitMQ seems to be the best, 4. 对于较小的消息,时间被消耗在processing上,而不是I/O上.
Related posts:
- Jame’s Reading 04-05
- Jame’s Reading 03-16
- CAP Reading List
原文地址：Jame’s Reading 04.06 — 04.23, 感谢原作者分享。