简单来说，如果数据访问拖慢了您的应用程序，唯一的解决方案是更快的数据库，而不是缓存。
译自 How to Get Peak Performance without a Vast Amount of Memory，作者 Behrad Babaee。
您听说过水牛理论吗？根据该理论，一群水牛只能以最慢的水牛的速度前进。”令人惊讶的是，这种智慧在计算机程序操作中找到了相似之处：应用程序的速度受其最慢的子进程的制约。
让我们考虑一下在线零售商的网站。加载产品页面的任务远非简单——它需要无缝执行多个子操作，包括但不限于：
- 检索详细的产品说明
- 加载产品图片和视频
- 获取客户评论
- 生成类似产品的建议
- 编译常用捆绑商品的推荐
- 访问用户帐户详细信息
- 汇总购物车的内容
- 显示最近查看的商品
- 提供可用折扣
其中许多任务都需要 数据库查询。如果我们要绘制数据库为每个子操作提供必要信息所需的时间，则模式将类似于以下内容：
显然， 页面加载时间不能超过最耗时的子操作的持续时间，在本例中为子操作 5。为了简化性能，传统方法涉及在数据库前面部署缓存。此策略将响应时间更改为：
某些操作将受益于缓存，快速检索数据，而其他操作将需要直接数据库访问，这将和以前一样慢。鉴于整体页面加载速度仅取决于最慢的任务，因此引入缓存对总页面加载时间的影响很小。
“最小”一词是故意使用的，因为在实践中，引入缓存可能会略微改善未命中缓存的操作的响应时间。从本质上讲，在数据库前面放置缓存会减少其工作负载，这可能会导致性能略有提升。但是，除非数据库严重供应不足，否则这种改进不太可能很明显。
尽管如此，考虑到通过简单地向数据库分配更多资源就可以实现类似的改进，这种边际增强可能无法证明投资是合理的。该策略不会像添加缓存系统那样使应用程序或基础设施复杂化。
人们可能会猜测足够高的缓存命中率是否可以显着提高性能。不幸的是，答案仍然是否定的。这种乐观情绪没有考虑一个关键细节：提高平均延迟不会影响最大延迟。随着子进程数量的增加，所有操作都命中缓存的可能性呈指数下降，这突出了随着子进程的累积，缓存的有效性受到限制。
下表说明了随着子进程数量的增加，缓存策略的功效如何降低：
重要的是要强调，即使通过维护大量的缓存大小而实现了令人印象深刻的 99% 缓存命中率，涉及五个子操作的页面加载仅从缓存中提供服务的概率也不会超过 %95 (=%99^5)。尽管 95% 的效率水平值得注意，但大多数企业的目标是确保 99% 的用户请求获得最佳性能，这突出了采用这种缓存策略的理想结果和实际结果之间的差距。
解决问题至关重要的是解决核心问题。缓存的问题在于它提高了子进程的平均延迟，这对整体应用程序延迟的影响很小。为了显着提高性能，重点必须转移到减少子进程之间的最大延迟（特别是较高百分比的延迟）。
简而言之，如果数据访问正在减慢您的应用程序，那么唯一的解决方案是更快的数据库，而不是缓存。多家供应商声称他们提供的延迟数字低于毫秒级；然而，大多数通过依赖内部缓存层来实现这些数字。值得注意的是，如前所述，缓存策略的局限性也同样适用于这些内部缓存。
寻找一个数据库技术如 Aerospike能够提供亚毫秒延迟，而无需依赖缓存层。通过直接从磁盘提供数据（访问任何数据段，即使内存与磁盘的比率低至 1%），它实现了与需要从内存提供数据以实现快速响应时间的技术同等的性能。
一家领先的在线零售商的转型说明了战略数据库优化带来的影响。
该零售商依赖复杂的数据分析来提供有效的产品推荐和广告展示。在迁移到 Aerospike 后，该公司看到客户购物车大小增加了 6%，购物车放弃率降低了 30%。这些数字强调了在数字商务领域优化数据访问的变革潜力。
访问我们的网站以了解更多信息：Aerospike 数据库。