...
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, 感谢原作者分享。