向量检索目前多通过数据分片的方式实现水平扩展，然而过多的分片容易造成计算量的上升，从而导致检索效率的下降。在分布式方面，仍存在向量索引快速合并算法的难题，这便导致了数据一旦分片之后，无法很好套用 Map-Reduce 计算模型合并成效率更高的索引。
企业管理员和存储供应商处理各种各样的存储类型。而且，它们还满足不同输入/输出服务的指标。大型文件共享应用可能需要适当的吞吐量，但也必须允许延迟损失，因为大型而复杂的应用可能会对延迟产生不利影响。
对于应用交付的整个流程而言，通常会涉及三个环节，即开发、测试和运维，而在传统的组织架构中，他们对应的也往往是三个不同的团队。这三个环节各自有自己的侧重点，但是在实际上，想要让整个应用交付过程变得顺滑高效，并且让应用在上线后保持高可用的状态，往往需要三个团队将相互之间存在的墙打破掉。
因此在框架层就出现了Serverless计算，其产生的原因最主要是需要和云API发生紧密的化学反应，帮助用户提升应用构建和运维效率，帮助客户构建分布式、数据化、智能化的新一代的云原生应用。
最后分享一些比较成功的案例。阿里Serverless计算支撑了阿里集团小程序平台，节省了40%研发资源。阿里云 Serverless 支撑语雀使用函数计算实现文档等计算密集型业务，大幅度地降低了运维成本，还为石墨文档降低了58%的运维成本，帮助微博提升了研发效能，使得功能上线时间从原本的2周变为几小时。
阿里云云效的语法服务架构图主要分为两部分：
基于事件触发的索引构建过程
基于用户请求的语法服务响应
当队伍已有两个成员时，则将任务丢弃，因为每次执行任务时，系统都会克隆分支代码，基于最新的版本构建索引，如此就避免了多少次Push就需要执行多少次索引构建的可能性。考虑到线程意外退出的情况，队首会每隔5秒钟全局发送心跳，当队尾或新来的任务监听到心跳超时，则会将队首的任务放弃并执行新的任务。
阿里不缺解决问题的同学，但是缺定义问题的同学。你怎么知道这是个问题，并且把这个问题定义清楚。需要将发现的问题进行抽象和归纳，定义出问题的基本要素，同时定义出问题的短期和长期方案，推进技术整体的进步。
还有就是要去看论文。跟数据相关的，OLTP和OLAP都有非常好的论文。看了论文以后再看其他人对论文的理解。一定要去看一些比较好的东西，跟工作相关的都可以去看，每天去学习。每天花2到3个小时去学习，三年以后你就知道自己跟别人完全不一样。有人说过：在一个行业你能付出1万个小时，你会跟别人形成本质的区别。但是在我们这个领域，1000个小时就形成差别。
原生的 InnoDB 引擎无法满足我们支持 TSO 事务的需求，因此我们修改了 InnoDB 引擎的提交逻辑和可见性判断逻辑，在 XA BEGIN 和 XA COMMIT 前插入了我们自定义的两个变量 SNAPSHOT_TS 和 COMMIT_TS。
