昨天发了一篇关于AlloyDB的文章。有的朋友给我留言，有的朋友通过微信交流。其实，AlloyDB能不能成功，能成功到什么程度，还是一个未知数。而且因为AlloyDB是设计在GCP上提供的，不提供云下版本，所以我没办法在现实生活中体验AlloyDB。我只是从一些体验者在发布会上和会后的实验报告中得到一些特征信息。只是我觉得AlloyDB为云原生数据库提供了一个非常好的模型，它在很多设计上都有划时代的创新。正如谷歌官方所说，AlloyDB专注于未来和当前数据库用户最关心的问题：高扩展性、高性能、高可用性、易管理、实时运维可观察性、AL/ML能力。如上图所示，通过智能数据库存储引擎，AlloyDB去掉了数据库BLOCK的回写，只留下WALWRITE。计算引擎只需要将WAL写入低延迟日志存储层，即可完成事务提交。数据文件是异步放置的，通过LPS服务使用WAL完成。本设计参考了分布式消息中间件的设计思想。过去，一些简单的系统都是使用这种类型的系统来实现的，但是谷歌将这种设计应用到了非常复杂的数据库中。消除块写入是一种充分利用现代硬件和云平台的高可扩展性和性能特征的设计。通过并行LPS，可以并发处理大量的WAL写和BLOCK写。通过低延迟的LOGSTORE，可以快速完成WAL写入，避免数据库事务提交带来的性能问题。这也是AlloyDB不支持跨数据中心（跨数据中心需要复制）的主要原因。在昨天和小伙伴们的交流中，我也表达了对LOGSTORE和计算节点分离后的性能问题的担忧。但是想想Oracle的Exadata，计算节点和存储节点之间也有复杂的IO路径。只要能优化，其实问题不大。我们传统的数据库架构从服务器到存储系统的IO路径也很长。还有一个昨天大家比较关心的问题，如果计算引擎不写BLOCK，LPS完成日志数据重放后，数据会不会只读？其实，这种担心是多余的。Google也意识到AlloyDB的读取路径有点长，所以为了降低OLTP的延迟，设计了一个带有多层缓冲机制的读取架构。如果LPS还没有完成一个BLOCK的持久化写入，那么这个BLOCK相关的数据缓存在LPSBUFFERCACHE中，可以直接从LPSBUFFERCACHE中命中数据（即使写入完成，如果BLOCK还没有Aging，那么也有可能命中BUFFERCACHE)，如果命中这一层，访问效率会更高，因为LPS所在设备的IO性能更好。我觉得还是用昨天的写过程图来描述写操作比较准确。WALSTREAM会在WAL入盘的同时同步到只读节点，用于更新只读节点的BUFFERCACHE（与主节点的BUFFERCACHE同步）。你为什么这样做？对于基于“日志即数据库”理念设计的读写分离共享存储数据库系统，只读节点与主节点之间的关系并不是完全实时的，因为只有在写入BLOCK时，从节点可以获得最新版本。暂时没有放到master节点的buffer中的数据，有可能没有提交就已经放到磁盘上了，也有可能是放到磁盘后没有提交。因此，它会影响从节点的一致性读取。在去年一篇分析PolarDB架构的文章中，我也提出了这个问题。当时我也提出可以用bufferfusion或者更简化的方案来代替目前PolarDB仅仅依靠日志重放来实现主从同步。.在那篇文章中，我也分析了可能是PolarDB日志重放算法由于重放延迟导致的部分读节点导致读取最新数据阻塞的问题。在那篇文章中，我也谈到了PolarDB目前采用的日志重放方式的缺陷，以及直接通过WALSTREAMS同步BUFFERCACHE的思路。这里我就不多说了，有兴趣的可以去看看。PolarDB设计了多种结构来避免replay的问题，设计的很精巧，但是还是没有脱离BLOCK持久化的惯性，所以每个slave节点都需要独立的replaylog。AlloyDB在这方面的解决方案比较漂亮。AlloyDB的从节点不需要重放日志，因为日志重放已经变成了公共服务。不管是主节点还是从节点，一个集群中只需要一次replay，以达到统一持久化的目的。BUFFERCACHE与WALSTREAMS同步后，主从节点之间没有数据延迟。现在国内有一些数据库厂商在开发类似Aurora的分布式数据库产品，AlloyDB就是一个很好的学习范例。我不赞成数据库厂商用类似于OracleCachefusion的方式来实现类RAC的功能，因为这样太复杂了，DLM/GES/GCS等服务也不容易做好。像AlloyDB这样的实现非常容易，可以满足大部分用户的需求。特别是对于云原生数据库，该架构比以CACHEFUSION为核心的RAC具有更好的横向扩展能力。昨天有很多朋友问AlloyDB是如何实现HTAP，实现解析SQL性能100倍提升的。也有小伙伴对100倍的性能提升提出质疑，认为很难实现。AlloyDB的HTAP是通过实例中的列引擎来实现的。Row数据在内存中生成一个columnbuffercopy，这个和Oracle的in-memorydb很像。AlloyDB通过AI/ML引擎自动推荐columnbuffer建议，用户可以使用自动或手动的方式创建columnbuffer。事实上，HTAP中的AP并不能仅仅通过columnbuffering来解决，columnbuffering只能解决一部分问题，而OLAP数据库产品有更复杂的index和executor优化机制。昨天也有朋友质疑AlloyDB对AP的100倍性能提升。也仔细看了谷歌官网的文档，仔细看了一些体验者的实验。谷歌官方的说法是，具体的提升倍数与应用场景有关，目前他们正在进一步优化，让各种场景都能有更大的性能提升。这说明100次并不能涵盖所有场景。我看过一些案例，大部分都是超大表的查询或者全表扫描，逻辑比较简单，分组统计，没有特别复杂的多表关联。我对AlloyDB的理解还比较肤浅，但是在多年的数据库应用经验中，我看到了一种全新的云原生数据库设计方案。我觉得我们的数据库架构师可以好好研究一下，借鉴一下。到很多好东西。
