论广告系统对存算分离架构的应用
辅助论点
辅助论点一：存算分离架构起源于数据库领域，并不是在线系统。
- 存算分离的架构源于Google的Spanner数据库，这个数据库采用了KV做存储层，OLAP做计算层的分离式设计，其目的是能快速伸缩计算资源，且节省数据被动配合计算进行伸缩所带来的存储资源浪费。在这个设计中，没有特别考虑计算时延，更多的是为了突破“水平扩展瓶颈”。
- 相关论文在论证存算分离架构合理性时做了一个很关键的假设，那就是网络性能的发展速度没有受到摩尔定律的约束，因此预判未来带宽成本会越来越低。
辅助论点二：在线系统考虑应用存算分离架构，主要目的是借助存算分离实现快速启动、快速迁移，节省存储资源。
在线系统中确实也存在对存算分离架构的需求，主要源于两点。
- 从稳定性和运维效率角度出发，希望服务可以快速启动、快速迁移，这要求也恰好也是微服务架构的标准之一。
- 希望节省数据被动配合计算进行伸缩所带来的存储资源浪费，这一点上和数据库领域的诉求是一致的。
辅助论点三：广告系统当下并不是微服务架构，未来也不会全面应用微服务架构。
- 当前广告系统的的模块划分粒度较粗，模块内部各个功能组件合并部署，在严格意义并不是微服务架构。
- 微服务架构的优势在于运维效率高，缺点在于性能差。广告系统对性能有比较高的要求，因此只能有限的应用微服务架构。
中心论点
中心论点一：广告系统应用存算分离，需要结合稳定性需求、存储资源开销、时延需求三者综合决定，不同的场景可能有不同决策结果。
说“存算分离是好的”，就像说“200年后我们都会死”一样，是绝对正确的论断。但绝对正确的论断是无用的。这种论断在指导实际应用前，仍然需要思考并回答清楚几个问题：
- 水平扩展是否已经成为当前系统的核心瓶颈？
- 存储成本是否已经不可接受了？
- 如果是一个10GB的数据，是否需要分离？100GB呢？1TB呢？
2. 稳定性风险是否已经不可接受了？ - 如果某一个实例需要故障迁移，迁移的时间的最低要求是多少，是2min还是10min？
- 在不分离的场景下，我们已经能做到什么程度了，还有没有优化空间？
- 是否认为带宽成本足够低？
- 带宽增加成本是否低于分离后节省的存储开销？
- 时延增长是否可以接受？
有些业务对时延十分敏感，时延增长能否接受？
中心论点二：在存算分离这个话题下，架构的主要工作是提供灵活性、便捷性。
架构应该通过自身的建设，实现一个这样的完美系统：
- 在数据量较小、水平扩容简单、稳定性风险可控、时延敏感的场景，提供数据本地部署方式；
- 在数据量大、水平扩容困难、稳定性风险过大、时延不敏感的场景，提供数据远程部署方式；
- 支持在这两种部署模式下任意平滑切换的能力。