a db thinker's home

如何让自己变得更加出色

jametong — Sun, 12 May 2013 14:15:18 +0000

And so my end conclusion in all of this is: if you want autonomy, and the ability to own and control your own domain and projects – it is your job to push information and build trust with your team members.

In other words, you need to learn and do the following:

Follow through. Do what you say and consistently deliver on your commitments.

Proactively communicate when a task takes you longer than you thought, and why.

Improve your communication skills. In order for others to hear you, sometimes you have to hone the way you deliver your message.

Volunteer information and make an effort to explain vague or hard to understand ideas and concepts. Make an effort to share the details of your decisions and diversions. This is also important when you make mistakes – letting others know before they figure out on their own will show ownership of the situation and can prevent misunderstandings later.

Be forthright and authentic with your feelings. Even when you may hold a contrary opinion communicate your thoughts (respectfully and with tact).

Don’t talk behind the backs of others. It is very difficult to build trust if someone knows that you will say something negative about your boss, the company leadership, or another coworker.

Be objective and neutral in difficult situations. Learn how to be calm under pressure and act as a diplomat resolving conflicts instead of causing them.

Show consistency in your behavior. Not just in follow through but by eliminating any double standards that may exist.

Learn to trust them. This is one of the hardest ones, but trust is a two-way street. Giving others the benefit of the doubt and learning how to work with them is essential to a strong mutual working relationship.

In turn hopefully you have a good manager that will be able to ask you good questions and take the time to understand your contributions. And if that is not your situation, then make sure you are sharing information with those around you; such as your peers, your boss, and other stakeholders.

Good leadership is keeping everyone on the same page, and if you want independence, it is on you to make sure people know what you are contributing.

摘自The Paradox of Autonomy and Recognition – thoughts on trust and merit in software team culture

No related posts.

James’ Reading 05-11

jametong — Sat, 11 May 2013 13:32:58 +0000

在production环境上，使用也要小心，因为该pending timeout的DDL enqueue会阻塞后来的DML操作。 http://t.cn/zTTrvPb DDL_LOCK_TIMEOUT in 11g. 原理是, Oracle的锁处理是一种排队机制, 排队是分先后的, 排在队列前面的操作会阻塞排在后面的操作, 也即当DDL被阻塞时, DDL操作本身会阻塞一批后续的DML操作, 这可能会给系统带来很大的负面风险.
http://t.cn/zlZDD0w 也谈大公司病1——正确是最大的错误,1. 做正确的事比正确的做事更重要, 但是, 大公司中存在太多的正确, 当公司倡导的n种正确出现冲突，哪一种更正确? 2. 流程与效率的冲突问题, 3. 正确延误了学习，长期看带来能力降低; 正确延误了创新，阻碍了变革。
Being able to recover quickly from failure is more important than having failures less often. 也即MTTR is more important than MTBF ( 相对于更少的出现故障来讲, 可以快速的从故障中恢复过来, 要更加重要). 在此文中, Eric Brewer有个补充, “由于故障的复杂度在不断提高,MTTR显得更加重要了”. 链接: mttr-mtbf-for-most-types-of-f/
http://t.cn/zjQFy7M Dare Obasanjo讨论 MSN Spaces遇到的扩展性问题时说, 在你还是个创业公司时, 不要花费大量的时间与精力去考虑达到100万用户后的扩展性问题, 当你过早的考虑这些问题时, 或限制你提供新的功能/特性的效率. 记住, 哪怕是Google/Microsoft这些大鳄, 也会遭遇扩展性的问题.
http://t.cn/zTTt4Uq 在努力基于几个好的创意,好的想法做出用户喜欢的产品,在业务的规模没有达到一定的规模之前,不用太多的考虑(不是不考虑)扩展性问题,不用太多的考虑99.999%的可用性, 扩展性的问题也好,可用性的问题也好,都是一个关于投入产出的平衡的问题.
http://t.cn/zTONtYH Todd Hoff对Eric Brewer在InfoQ的演讲NoSQL: Past, Present, Future（http://t.cn/zjOJLAL）的解读，不过，我觉得他关于此问题的理解还是偏于肤浅，不同方案的选择是基于经济的理由。对于银行的业务，由于通讯的问题，复式记账、审计、坏账准备金、风险管理都是为弱一致性准备的
http://t.cn/zTjVK8O 大规模分布式计算的几个新的谬论，1. 实例是免费的（对应于EC2的节点），2.实例名的身份有含义（节点的名称会虚化），3.Map/Reduce是解决问题的灵丹妙药。传统分布式系统的8大谬论请参考此链接，http://t.cn/zTjVK8W
http://t.cn/zTCP3zf ‘Small Data’ Enabled Prediction of Obama’s Win, Say Economists 使用”小数据”来进行总统竞选预测,结果与”大数据”相差不大,哈哈.
http://t.cn/zTCP01e Eventual Consistency Today: Limitations, Extensions, and Beyond By Peter Bailis, Ali Ghodsi, Peter Bailis从源头上梳理最终一致性的概念,从概念的提出到概念现阶段的理解,如何设计并度量系统最终一致性的程度,如何在不同的场景下选择不同的最终一致性方案.
http://t.cn/zTXjLJl Continuent Tungsten Replicator Is Now 100% Open Source 数据库复制做的非常成功的Continuent Tungsten Replicator宣布完全开源,也即可以完全免费的通过它来获取Oracle内部的变更了. 这是个好消息. Tungsten是目前MySQL社区做的最好的跨数据库做同步做的最好的开源产品了, 支持MySQL/Oracle/SQL Server之间的数据准实时的交互同步.
http://t.cn/zTXlXMd BrainTree的高可用架构, 如何通过队列缓解短时间的系统维护造成的问题,那几页PPT很有意思, slide-31 到slide-68都是利用此方案来进行系统的维护,包含代码发布/数据库迁移升级切换. 虽然,很多人在讨论通过队列解决系统的削峰填谷作用,如BrainTree这样实践的确实不多见.
http://t.cn/zTXl2mE BrainTree 为什么选择使用postgreSQL替代MySQL:Schema Change的代价;为什么选择使用Pacemaker+PG的Sync Replication来替代DRBD:切换时间,DRBD复制对系统复杂度的要求,每次升级内核都需要重编译内核模块,每次切换都涉及文件系统的umount/mount,文件系统的风险不可控.
http://t.cn/zTX0kpC BrainTree 如何配置数据库的自动Failover,1. 数据库是PostGreSQL,2. 同步方式为,同机房Sync,跨机房Async,3.禁止来回切换,也即只允许单向切到Sync备库,4.当Pacemaker不能确定可以自动切时,自动冻结操作,此时需要人工介入.在推向Prod前后,做了大量的测试与验证工作.

No related posts.

Jame’s Reading 04.06 — 04.23

jametong — Tue, 23 Apr 2013 12:47:24 +0000

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上.

Oracle 性能优化

jametong — Mon, 22 Apr 2013 01:42:36 +0000

Oracle 性能优化 from james tong

CAP:理论与实践

jametong — Sat, 20 Apr 2013 00:45:38 +0000

Cap 理论与实践 from james tong

CAP Reading List

Jame’s Reading 04-05

jametong — Fri, 05 Apr 2013 13:25:00 +0000

http://t.cn/zYe5RCT 从物理原理上讲解Flash的特性.

http://t.cn/zYet4YU 图形展示几种不同的IO编程模型，包含阻塞IO模型、非阻塞IO模型、复路IO模型（通过Select/Poll实现）、信号驱动IO模型、异步IO模型.

http://t.cn/zYeuaSl 如何使用Oracle的Increment Backup恢复数据库备库。实现不复杂，想法还有点意思。

http://t.cn/zjOJLAL http://t.cn/zYDzann Eric Brewer在2012年在两个不同场合讲的关于NoSQL History的东西，ppt可以从InfoQ的页面链接里面下载，各方面问题都讲的比较清楚了。

几篇关于C in ACID与C in CAP的文章，http://t.cn/zTPWLjB http://t.cn/zTPWLj1 http://t.cn/zTPWLjr 摘要：1. ACID中的C与完整性约束有关，与状态的转换有关系，2. CAP中的C主要是基于单个Item的多机副本的原子性，3. ACID的延迟复制还是满足C的，只是不满足I隔离性

http://t.cn/zThALXB CoinBase 的电子货币业务系统已经连续4天不能提供服务了，他们使用的数据存储方案为MongoDB，这次故障的原因貌似是：由于容量不足，要做扩容，做数据迁移，而在迁移的过程中出现了一些意外，导致网站长时间无法提供服务。MongoDB在Durability与Consistency方面被报有明显缺陷。

http://t.cn/zTht1hP Queues – the true enemy of flow ，关于队列、排队的一点基础介绍。

http://t.cn/zYe3rr7 Josh Berkus谈软件咨询行业的基本原则, PostGreSQL领域的一个牛人介绍自己做软件咨询的一些经验,摘要：1. 你拖延越长的时间去重构，重构就会用掉你越长的时间,2.所有的预估都是乐观情况的,3.在时间和金钱的换算上要使用对数运算,4.有大约一半的项目是会长期存在的,….

http://t.cn/zTZ2Abf More than Monitoring 来自Neil Gunther，很有启发，但说不清启发在哪里。哈哈

http://t.cn/zTZqNpO 日志的集中化处理，从最简单的文件拷贝方式，到基于syslog(rsyslog,syslog-ng)的日志集中方式介绍，再介绍分布式的日志收集方式（scribe/flume/chukwa/fluentd/kafka/splunk).

http://t.cn/zY3pMDJ 使用Optimitic Cuckoo-Hashing来改造Memcached，显著提升Memcached的读取效率，对OCH算法的简要介绍，如何通过OCH来控制Hash的效率，如何提升OCH的并发读取的锁，测试的压测效果，使用Key的片段来提升内存利用。

这些优化在今年的NSDI发布的论文memc3中有详细的介绍，会议还未召开，论文已经放出来了，哈哈。http://t.cn/zTZ5fxr

http://t.cn/zTZNK5o 更关注相关性, Dave Andersen介绍Casual consistency ,以及他们将要在NSDI 2013会议上发布的新论文eiger,”可以在不牺牲可用性与低时延的情况,提供比’最终一致性’更好的一致性. 论文下载: http://t.cn/zTZNK5K

http://t.cn/zTZpXgQ Al Borchers From Google讨论Flash设备,重点介绍下Flash的CPU开销:IO调度器增加30%开销,FS增加39%的开销,NUMA增加了20-40%的CPU开销.读错误比位错误要高,Flash的主要故障出现在Block, plane, and die 层面.

http://t.cn/hBKiv2 “Logs Are Streams, Not Files” 来自HeroKu 的博文,这句话本身就是关键,log要当做数据流来进行处理,在系统输出日志流之后,由后续的流处理系统来进行日志的归档/切割(写入文件),日志的统计分析(statsd),日志的展示(Graphite),日志的检索(ElasticSearch),以及可能的日志分析.

http://t.cn/zYDxIvC 日志记录的5个最佳实践,1. 确定需要记录的核心日志信息,2. 配置日志的输出格式,3.格式化成Key/Value,4. 保持Key的一致性,也即统一Key的命名(Naming),5.在日志中包含输出时的上下文信息(如uid/machine/action/…).

http://t.cn/zTZW87O 如何利用Rsyslog进行日志集中化.如何在不同工具中,使得日志可以输出到syslog,分别介绍了Shell中的使用,Python的实现,Java的实现(只能通过UDP来实现);如何在中心服务器上对日志做过滤,做进一步的处理,进行压缩/备份等操作配置.

http://t.cn/zTZjgNf Taba: Low Latency Event Aggregation, 一个低时延的事件聚合系统.设计目标:低时延/低影响/持久性与可扩展性.使用HTTP协议与Nginx在中间做无状态转发,使用gevent做系统并发处理,整个架构类似于Map/Reduce的处理,同时又在架构层实现一定的排队/批量处理以及预处理

http://t.cn/zTAEUSC 内存访问模型的重要性 ,@诸葛不亮翻译的这篇Martin Thompson 的文章,对于CPU缓存的几个关键点都有详细的介绍,如何充分的利用CPU的Cache是LMAX架构的核心优势,也是Martin Thompson的专长所在. 内容相当精彩,不容错过.

http://t.cn/hO1eg Todd Lipcon 介绍分布式NOSQL数据库的设计模式, 从数据分布模式(一致性哈希的工作模式),一致性模式的选择, 数据模型的处理(Key -> Value,map…), 存储模型的选择(行存储/列存储/列族存储(行列混合)),LSM Tree的工作原理的详细介绍,节点管理(主控,或基于Gossip做通讯).【推荐】

http://t.cn/zOlEwqj 计算机领域的那些基于突破性的（Break Through）论文而成立的公司。这个系列的论文质量都很不错，虽然很多论文现在看来没有那么有突破性了。创新很多时候，在想到之前，无比复杂；在有人想到之后，又会显得异常简单；这也是为什么需要有专利法去保护的原因。不做事后诸葛亮！

http://t.cn/zT2mMDa Essential storage tradeoff: Simple Reads vs. Simple Writes ，Storage层面的问题，很多都是一种选择与权衡，Normalization Vs Denormalization，Column Store Vs Row Store，Consistency Vs Eventual Consistency，Key Value Store Vs Relation Store，集中化 Vs 分布式，。，所有的权衡都来自业务（客户需求），最后权衡的标准一定是成本与收益，差别只是在于你会考量多少因素，你如何为不同的因素做量化，即量化每种选择的投入与产出，从而从整体上降低成本、提高收益；也即做到整体的TCO最低；相关的量化可以延续到未来的2－3年。也是我昨天与 @jackbillow 讨论的内容

@BohuTANG_ 伯虎对写优化的数据结构理解研究都相当深入，注意标题写优化，也即关注写入密集型业务，关注读写比较小的业务。【推荐阅读】 “写优化”的数据结构 http://t.cn/zTLwk8D

http://t.cn/zTywIRz 在NSDI 2013年的论文中，Facebook透露使用Memcached获得的经验教训：1.缓存与持久化数据分离以独立的进行扩展，2.监控、调试以及运维效率的工作与提升性能同样重要，3.管理状态组件的复杂度要远远超过管理无状态组件。4.系统必须支持渐进的发布与回滚方案，5.简洁性至关重要.
论文章还介绍到Facebook如何通过Lease处理访问风暴，与早期 @TimYang 讨论的新浪微博的方式有点类似，不过在防止访问风暴处理上要更加优雅一点。总体机制有以下3条：1. 控制发放Lease凭证的频率，有Lease才可以putKey，2.收集可能导致访问风暴的Key,3.删除的Key还会在系统中保留一段时间，对一致性需求较低的请求返回此数据. Workload Analysis of a Large-Scale Key-Value Store http://t.cn/zTy2NQK Facebook的Key/Value Store也即Memcached集群的工作负载特征分析，组合这篇论文看效果更佳。

C Mohan 讨论NoSQL的得与失

jametong — Mon, 18 Mar 2013 01:12:44 +0000

History Repeats Itself, C Mohan 讨论NoSQL的得与失

【1】关系数据库的不足，
- a. 不能很好的为Web 2.0的业务做建模（搜索与社交图谱），
- b. 无法在数据库层面很好的与JSON等做数据交换,
- c. SQL语言与编程语言的差异带来的开发学习使用成本,
- d.是否开源，代码能否改动,
- f. 关系数据库的优化器、解析器代价太大，影响响应时间、吞吐量，
- g.不能很好的满足业务对Scalability以及低成本服务器的需求，
- h.在Scale out的情况下的管理复杂度，
- i. 不能方便的调整业务的ACID需求，主要为Relax Consistency与Relax Durability的需求。
【2】在构建传统关系数据库方面得到的一些教训，
- a. System/38 以对象存储开始，忽略关系，使用paging做缓存管理，锁粒度过粗，
- b. Lotus Notes 恢复模块设计简陋，不支持事务处理，大量扩展性较差的内部模块，没有Buffer管理模块，为后续的改造带来了大量的困难,
- c. 降低锁粒度非常痛苦,
- d. 对于一个类似于DB2这样的产品，要增加Shared Disk的Cluster的支持将会遭遇非常大挑战，需要对buffer/log/lock/recover做全面的改造。
【3】NoSQL的通用问题,
- a. 缺少对提高单机并发度至关重要的锁粒度的关注,
- b. 缺少对多条记录处理的原子性（Atomicity）的关注,
- c.缺少对统一标准的关注,
- d. 忘记了高级查询语言与应用程序代码访问独立性的考虑，期待应用开发人员去实现传统数据库中的优化器、并发控制等技术。
【4】关于Index,
- a. 仅支持单节点、单Key的操作，功能过于单一，
- b. 随着时间、功能的推进，NoSQL需要重新发明主索引、辅助索引，本地索引、全局索引等问题，
- c. 对索引的锁与恢复的处理过于简单，会在后续高并发的情况遇到较多坑。
【5】数据模型，
- a. 有些NoSQL的数据模型比RDBMS更加复杂，
- b. 缺少对应的工具来维护这些复杂的数据模型,
- c. 相关的数据建模缺少标准化，为后续的Vendor替换带来障碍，有些通过自己养工程师来解决，企业级客户会很惨,
- d. 传统企业做这种业务变更与基础架构变更的困难很大，成本也不低。
【6】文档存储，
- a. Lotus 开始的设计为并发与扩展性考虑不够，花费了很大代价来改造，
- b. MongoDB依赖单一写入锁，以及没有Buffer管理，
- c. CouchBase的Rep做整个Doc的Rep，对于小Doc还行，大Doc的代价会很大,
【7】对事务（ACID）的误读，
- a. 只要考虑多记录更新，或单个Key的增量并发更新，继续考虑事务问题，
- b. Lotus Notes早期的实现存在并行更新冲突，后通过应用基于日志的恢复与事务解决，
- c.对于维护内部的空间管理与数据结构的并发访问，也需要考虑细粒度锁来支撑高并发访问，
- d. RDBMS也并不支持完整ACID

No related posts.

Jame’s Reading 03-16

jametong — Sat, 16 Mar 2013 13:32:01 +0000

http://t.cn/zYOEGgp spotify 介绍如何使用成熟（而不是时髦）的技术来解决问题，重点介绍了如何使用DNS来解决问题，1.对DNS的定位，分布式多副本的读密集数据存储，2. 利用Bind来实现，3. 场景：普通的DNS功能，SOA里面的Service定位，配置管理，一致性哈希的Reverse lookup。Spotify使用DNS的方式非常特别，老技术开出新花朵了。

http://t.cn/zYQzGp4 Daniel Abadi介绍复制技术中一致性与时延的关系，1. 复制的分类（a,Master Based，b,Coordinator Based，c,任意节点作为master）（同步、异步），2. 每种不同的复制中一致性与时延（Latency）是如何权衡的，3. 关键的分布式系统是如何权衡的（Dynamo系c 同步、异步 Pnuts 选择timeline Consistency、异步同步、Master Based，HBase选择Master Based，同机房同步。

http://t.cn/zYdHmcH McDipper From Facebook, we’ve deployed McDipper to several large-footprint, low-request-rate pools。这是基于Flash的key/value Store的最大的价值所在，而现实中，很多的Cache都属于这一类，也即基于Flash的Key/Value Store支持一定的MemCache相对于目前的memcached方案会有明显的性价比优势产生。类似的系统还有，FatCache from Twitter (https://github.com/twitter/fatcache)。

http://t.cn/zYEyyCQ Kafka Intra Replication By Jun Rao（饶军）,Kafka replication的设计、CAP的权衡，吞吐量与性能。

http://t.cn/zYEUHN8 Oracle的MySQL研发副总访谈，介绍MySQL 5.6，InnoDB的改进，MySQL Cluster的使用案例，以及Scale Up与Scale Out的利弊，比较中肯的讨论。其中关于Scale Up & Scale out比较的部分，我已经在之前的博客中引用过。

http://t.cn/zYQvl8U Quick and dirty (incomplete) list of interesting, mostly recent data warehousing/”big data” papers By Peter Bailis, 数据仓库相关论文推荐阅读。Peter Bailis同学在分布式系统领域的研究还是比较深入的，关于CAP与Consistency相关的系列文章与Paper写的很好，关于Cassandra Consistency如何度量如何控制的Paper也很好。这个List是Peter同学自身研究Data Warehousing与BigData的Reading List，值得Follow。

PPT可以参见：http://t.cn/zYngUXd。“F1-The Fault Tolerant Distributed RDBMS Supporting Google’s Ad Business” Google 在Strata会议上的一个ppt，一些数据：总数据量,几十TB;机器台数,1000台左右;副本数量:5份;也即平均每台机器5GB * 几十（单库200GB内）;QPS：几十万;提交时延:50-100ms;用户时延:约200ms; 【google的游戏】 F1集群一天的TPS最多在3000万左右，结合几十万的QPS来看，TPS应该在5000-10000之间。也想借此跟大家表达鄙人的一个观点，要了解学习牛B的系统，了解他们的设计，经过自己的思考、沉淀，再结合自己的业务场景、公司的技术实力做中肯的评估，切不可盲目模仿，盲目跟风。

http://t.cn/zYESnYv TechOps Pre-launch Checklist for Web Apps 一系列简单的checklist，设计如何设计业务、要监控、要alert、要注意安全、要使用缓存、要使用负载均衡等。从一个技术创业公司的角度，整理的一系列checklist，我相信对于大部分初入这个行业的同学，会有比较好的参考意义。

http://t.cn/zYmlgUD Systems ‘thinking’ is terribly important. One way to learn that well is to read papers and to discuss them. In the absence of a formalised way of judging systems work (i.e. through a proof) you need to develop your own judgment and taste. 学习Paper，尤其是经典的Paper，并以批判的思维去学习的话，对锻炼全局思考能力有很好的帮助，对于切实的提升自己的思维能力也很有帮助。本文作者Henry Robinson为前剑桥大学分布式系统领域的教授，现在Cloudea公司工作，Apache Zookeeper与Apache Flume的Commiter，他对分布式事务协议有很深的理解。

http://t.cn/zYmBy9l 北大@闫宏飞教授在2007年讲授分布式系统时给的Reading List，大部分论文应该都值得一读。这是我看到的国内学校提供的比较好的Reading List。我那天找到这个Reading List，是为了寻找Ken Birman教授的新书Reliable Distributed Systems，无意中发现的。

http://t.cn/zYuOLQX MySQL Replication: High Availability 介绍MySQL的Replication机制，5.6的GTID工作机制，Crash – Safe的工作机制，重点是介绍了几个管理脚本，mysqlfailover以及mysqlrpladmin脚本，这两个脚本的工作机制、原理以及源码的链接，为要实现此类功能的同学提供了好的借鉴。这篇Oracle的White Paper的质量很高，对我理解这一点比较有帮助。

在设计实现高可用高可扩展的电子商务平台过程中，我们积累了一些经验，我们发现关系数据库应该仅仅被用在确实需要复杂查询、表连接以及完整的事务能力的场景。在所有其它场景，使用类似于DynamoDB的NoSQL系统可以提供更见简单、更加高可用也更加可扩展成本更低的解决方案。http://t.cn/zYnOjjI Amazon的CTO在DynamoDB面世一周年的时候做的回顾文章，在中间回答用户的问题：什么时候该使用NoSQL DB。他的答案总体上与我个人的理解一致。当然，对于需要复杂查询、表连接（Relation）以及完整事务支持的理解，很多人可能会有较大差异，由于事务支持，也即一致性的需求实际上是一条光谱，具体在光谱的哪个点上需要考虑强ACID支持，需要站在业务、开发成本复杂度、运维成本复杂度的角度综合考量。

http://t.cn/zYB4h8a NoSQL as a spotlight highlighting the failures in the design of the current relational database software vendors(*). Which should not damn the concept of the relational database, but somehow it happens anyways. By Brain Aker (Architect of MySQL) .The two biggest issues that stand out to me are that current leading relational databases never solved scale out very well, and online operations are too expensive. The innovation 【NoSQL】hasn’t been in the language, but in the design of database engines themselves. One of the “hard things” that almost(?) none of the current NoSQL vendors has tackled is the JOIN, i.e. the fundamental feature which is required to do anything beyond simple key/pair or basic search. Join optimizers are hard to write。如何实现Join（Relation）是个考验。我讨论的不是哪个去关心的问题，而是真实世界的业务需求如何满足，哪个产品可以满足的更好，使用不同的产品的投入分别是什么（什么样的工程师，什么样的硬件配置，什么样的部署结构，对业务有什么限制），获得的好处是什么（应用复杂度如何，后续的软件维护成本如何，扩展成本如何，扩展的限度在哪里）。这篇文章的作者Brain Aker是MYSQL AB时期MySQL的首席架构师。可能很多从事关系数据库工作多年的人，都有类似的感受：NoSQL出现的主要原因，来自两方面，一方面是MYSQL的Schema维护过于复杂，代价过于高昂，直接促使开发人员偏向于选择Schema Free的方式，而不是目前的数据库Schema，其实Oracle、PostgreSQL的Schema 变更的代价要低很多，只是由于MySQL在互联网领域使用更加广泛而已；另一方面是，传统的关系数据库，受限于ACID的支持与选择，没有很好的适应互联网的需求，做到灵活的Relax Consistency, Relax Durability，并很好的支持数据库本身的透明Sharding，促使开发人员、架构师在业务的驱使下选择自己来实现数据库中间件层的Sharding解决方案，从而顺理成章的选择透明支持Sharding的NoSQL数据库，如Cassandra、HBase、MongoDB、Riad等。

http://t.cn/zYr19pd By Robert Barnes, Microsoft in 1999,HPTS; Scale out Vs Scale Up,14年前就已经对此有定论了，差别只是，在什么时候选择Scale Up，什么时候选择Scale out！！更细节的内容与评论可以参考我前两天专门为此写的博客文章。

http://t.cn/zYdKaKU By David Patterson，面向恢复的计算，对于Availability、Change、Maintainability 、Scalability的相关问题，都有较深的洞见，面向Recovery的计算，以及面向运维的计算，如何提高系统的可用率，如何显著降低MTTR，如何设计运维工具，如何理解自动化。这个PPT的内容非常丰富，非三言两语可以讲清楚，我准备后续专门整一篇博客讨论下，我从这个PPT中学习到的东西。

I wanted to eat soup with chopsticks and everyone told me to use a spoon instead. That made me sad. http://t.cn/zYuiltx “What make SQL so popular” . The real dichotomy is between handling state yourself in code and letting outside software do it for you. 这是Hack News上讨论“为什么SQL如此受欢迎”的帖子中，我摘录的两段话，讨论的内容，除了个别很无聊的人之外，很有参考意义，可以帮助我们更加深入的理解为什么是SQL，为什么是Relation DBMS。

One size does not fit all

jametong — Sat, 16 Mar 2013 07:43:20 +0000

To date, nobody has ever discovered a data layout that is efficient for all usage patterns. As a general rule, simpler data layouts are often faster to write, while fancier ones can boost query performance. Specific tradeoffs include, but hardly are limited to:

Big blocks of data compress better, and can be also be faster to retrieve than a number of smaller blocks holding the same amount of data. Small blocks of data can be less wasteful to write. And different kinds of storage have different minimum block sizes.
Operating on compressed data offers multiple significant efficiencies. But you have to spend cycles (de)compressing it, and it’s only practical for some compression schemes.
Fixed-length tabular records can let you compute addresses rather than looking them up in indexes. Yay! But they also waste space. Tokenization can help with the fixed-/variable-length tradeoff.
Pointers are wonderfully efficient for some queries, at least if you’re not using spinning disk. But they can create considerable overhead to write and update.
Indexes, materialized views, etc. speed query performance, but can be costly to write and maintain.
Storing something as a BLOB (Binary Large OBject), key-value payload, etc. is super-fast — but if you want to look at it, you usually have to pay for retrieving the whole thing.

总的来讲，无法做到一招鲜走天下，总是面临不同的选择与权衡，得到这个，则会失去那个。

要通用，一定会牺牲一些特定场景的优化；要专用，则使用场景少，投入的产出相对较少。面向行存储，OLTP效率高，OLAP牺牲大；面向列存储，则OLTP的业务牺牲大（内存数据库要稍好点），OLAP的整体效率高。

No related posts.

Scale out Vs Scale Up(2)

jametong — Fri, 15 Mar 2013 14:15:04 +0000

Scale out is a software challenge

Scaleup is hardware architecture & OEM driven
- Optimized by Software
  - e.g. minimize locking, parallel threads, reduce contention on critical sections, etc.
- Ultimately, scale up begins to look like scale out (partitioning)
Scaleout is software architecture driven
- Optimized by hardware
  - e.g. SAN (system area nets), low latency/high bandwidth interconnects
- Primarily an application design and operational management problem
- Possible today, but mostly left to application design/development and ad hoc management tools

SMP Advantages

Single system image
- no change to operations (relative to uniprocessor)
- no change to applications
Simple system resources
- shared memory
- shared disk
- shared net
Load balancing in OS kernel
8x SMP soon commodity SHV

SMP Problems

More then 8 processors not a commodity today
More than 16 processors may require partitioning, scale out needed anyway
scale-down problem (starter systems expensive or fork lift upgrade)
Potential single point of failure
Eventually stops scaling

Scale out Advantages

No hardware limit to scale, given a scaleable interconnect and an application that partitions
Uses high volume,commodity components
No single point of failure
Upgrade by incremental growth

Scale out Disadvantages

Operations complexity
- When not designed for LCS(Loosely Coupled System，松耦合系统), costs can be very expensive
Change in system architecture; e.g. Exchange, SQL Server (relative to uniprocessor)
- Need additional system services
  - Load Balancing
  - LCS Membership
  - Configuration replication
  - Failure Retry (LCS,Loosely Coupled System，松耦合系统)
- Parallelism needed for data and applications
  - explicit parallelism exposes partitions to the application
  - implicit parallelism requires transparency

内容来自1999年的HPTS会议，作者为：Robert Barnes
链接 Robert Barnes: Scale Out

关于Scale out的优劣，Scale Up（SMP）的优劣，Scale Up到一定阶段也会面临Scale out的问题（比如：分区表，库内的Partitioning）。

个人理解：在使用Commodity Machine可以Scale Up的情况下，如果Scale Up可以满足未来1年的需求，或者Scale Up + Replication可以满足未来1年的需求，Scale Up的总体收益（投入产出）会比较好，超出此限度，需要考虑做一定的Scale Out的处理，一般都是先做Vertical Partitioning，也即先做基于功能/业务维度的拆分；再进行Horizontal Partitioning（即Scale out），也即在单个业务的基础上，根据一定的业务特征进行Partitioning处理，可能是按照用户进行拆分（List/Hash/Range)，也可能是按照地域进行拆分（按省份，按地级市）。

在Scale Out已经实行过后，基本的原则是，满足一定的业务需求的前提下（比如单点故障的影响面控制在多大范围），尽可能的做Scale Up，这样可以显著的降低系统的机器规模，从而可以降低一定的运维复杂度，而为后续的运维自动化，运维系统的完善、成熟争取时间窗口；是的，只是争取时间窗口，相关的运维系统建设在Scale out开始设施的时候，就必须仔细考虑后续的运维系统建设了，而且要越早建设，越早完善越好。

Scale up & Scale out

a db thinker's home

如何让自己变得更加出色

James’ Reading 05-11

Jame’s Reading 04.06 — 04.23

Oracle 性能优化

CAP:理论与实践

Jame’s Reading 04-05

C Mohan 讨论NoSQL的得与失

History Repeats Itself, C Mohan 讨论NoSQL的得与失

【1】关系数据库的不足，

【2】在构建传统关系数据库方面得到的一些教训，

【3】NoSQL的通用问题,

【4】关于Index,

【5】数据模型，

【6】文档存储，

【7】对事务（ACID）的误读，

Jame’s Reading 03-16

One size does not fit all

Scale out Vs Scale Up(2)

Scale out is a software challenge

SMP Advantages

SMP Problems

Scale out Advantages

Scale out Disadvantages