Google Pro Tip: Use Back-Of-The-Envelope-Calculations To Choose The Best Design

谷歌专业提示
你知道对于一个给定的问题，最佳设计是什么吗？如果，假如，给你一个生成30个缩略图的图像搜索结果页面的问题，你会循序的导入图片吗？或者并行导入？会缓存吗？你会如何选择？

如果你可以利用多元宇宙的力量，你会在设计领域尝试每个可能的选项并且看看哪个效果最好。但是那是非常不切实际的，不是吗？

另一个选项是考虑各种算法替代的顺序，作为计算思维黄金时代的一个先行者，谷歌会很明确的这样做，但是谷歌还会做什么？

用back-of-envelope计算去评估不同的设计
谷歌基础设施学校的领导，杰夫.迪恩，谷歌的许多关键系统的:广告服务，big table ;搜索，mapReduce,ProtocolBuffers-主张用back-of-the-envelope 计算评估不同的设计,他在这篇斯坦福视频介绍中给出了完整的故事。

Back-of-the-envelope计算是估算你创造使用一个思想实验的组合，和平常的表现数量，为符合你要求的设计获得一个良好的感觉，Dr. Dean认为对每一个软件工程而言都很重要的一个技巧是用back-of-envelope计算去估算替代系统表现的能力，而不是去构建他们。

他在这个视频里给了一个关于这个过程的一个很棒的例子，但是首先：

每个人都应该知道的数字
去评估替代设计，你首先需要对常规操作需要花费多少时间有个良好的感知。Dr. Dean 给出了如下列表：

• L1 cache reference 0.5 ns
• Branch mispredict 5 ns
• L2 cache reference 7 ns
• Mutex lock/unlock 100 ns
• Main memory reference 100 ns
• Compress 1K bytes with Zippy 10,000 ns
• Send 2K bytes over 1 Gbps network 20,000 ns
• Read 1 MB sequentially from memory 250,000 ns
• Round trip within same datacenter 500,000 ns
• Disk seek 10,000,000 ns
• Read 1 MB sequentially from network 10,000,000 ns
• Read 1 MB sequentially from disk 30,000,000 ns
• Send packet CA->Netherlands->CA 150,000,000 ns

一些需要注意的事情：

• 注意在不同操作的表现之间的量级差异
• 多数据中心之间相距太远，所以在2者之间发送任何事情都会耗费很长时间
• 内存快，磁盘慢
• 通过使用压缩算法(2倍)许多网络带宽可以节约
• 写比读贵40倍
• 全球共享的数据是昂贵的，这是分布式系统的根本限制。大量共享写对象的锁竞争随着事物序列化降低性能并且变慢。
• 缩放写的架构
• 低写竞争的优化
• 广泛优化。尽可能的并行写。

示例：生成30张缩略图的图片结果页
这个这个视频中给出的示例，2个替代设计被用来设计思考实验。

设计1：串行

• 串行读图片，做一个磁盘寻址，读一张256k的图片然后继续去读下一张图片。
• 性能：30 seeks * 10 ms/seek + 30 * 256K / 30 MB /s = 560ms

设计2：并行

• 并行读
• 性能：10 ms/seek + 256K read / 30 MB/s = 18ms
• 磁盘读会有方差，所以更可能的时间是30-60ms

哪个设计是最好的？这取决于你的需求，但给你back-of-the-envelope 计算，你可以在不构建他们的情况下你可以有一个快速的方法比较他们

现在你对于问你自己其他设计问题并且比较不同的设计变更有了一个框架：

• 它对于缓存单个缩略图图像有意义吗？
• 你应该在一个条目中缓存整个图片集吗？
• 它对于预估算缩略图有意义吗？

为了让这些估算逼真，你需要知道你的服务的性能。如果有一个未知的变量，然后或许你可以快速prototype仅仅那个部分去解决这个问题。例如，判断缓存是否是一个可替代的设计，你需要知道写入缓存需要耗时多久。

经验教训

• Back-of-the-envelope 计算允许你看一看不同的变化
• 当设计你的系统时,这些应该是你在脑海中进行一遍又一遍的类型的计算。
• 知道你的系统的构建模块back of the envelope的数量。仅仅知道基本性能数量是不够的，你需要知道你的子系统的性能。如果你不知道会发生什么，你就不能做出适当的back-of-the-envelope计算
• 监控和估量你的系统的每个部分，你可以对从真实数据得到的预测进行分类。

我个人非常喜欢这个方法。对于一个普通的系统而言，一个端到端的系统的本质看起来更加接地气。今天的练习关注于各种各样的算法的诡计，是这个比较大的，更加整体的分析的一个可研究的，可插拔的部分。