另外一个例子，如下图右边所示，同样是地址查询，如果我们想在标准地址库中搜索“杭州阿里巴巴”的地址，在仅使用文本召回的时候，几乎没办法找到相似的结果，但是我们如果通过对海量用户的点击行为进行分析，将点击行为加上地址文本信息合并形成高维向量，这样在检索的时候就可以天然的将点击率高的地址召回并排列在前面。
传统的检索方法能很方便的实现增查改删（CRUD）的操作，向量检索依赖数据分布和距离度量，部分方法还有数据集训练的要求，数据点的变更甚至动一发而牵全身。因此，要实现向量索引的从 0 到 1 的全流式构建，并满足即增即查、即时落盘、索引实时动态更新的要求，对算法和工程仍存在着一些挑战。
例如，针对公开的十亿规模的 ANN_SIFT1B 数据集（来源 corpus-texmex.irisa.fr），在 Intel(R) Xeon(R) Platinum 8163 CPU & 512GB 内存的服务器上，由于 Faiss 要求的计算资源过于庞大，无法实现单机十亿规模的索引的构建和检索。而 Proxima 在同样的环境和数据量下单机可以轻松完成十亿规模的索引的构建和检索。
延时
延迟是服务器完成请求所花费的时间。关于存储，这是指满足单个存储块的请求所花费的时间。存储块或块存储是将数据存储在卷中的块。纯延迟不受吞吐量影响，但是如果单个块请求很大，则应用延迟可能会随着吞吐量的增加而偏离。
另一方面，电子邮件服务器可能需要大量存储，低延迟和良好的吞吐量，但它可能不需要非常苛刻的IOPS配置文件。并且，存储管理员应该决定应该为哪些存储分配什么资源。因此，在组织中运行着成千上万的服务时，对基础存储的管理超过了人们进行明智更改的能力。而且，这就是AI算法派上用场的地方。
这里的墙不只是组织架构隔阂所带来的障碍，还包括三个领域关注点的不同。比如开发需要关注可测试性和可运维性，这些东西将会深刻地影响应用的架构设计和开发实现，如果开发同学没有充分考虑到代码的可测试性，那么交给测试同学就会造成很大的问题，比如如何实现故障注入和精细流控，这都需要在开发时就考虑清楚。
针对阿里巴巴内部主要的Java语言，我们利用开源Java代码解析工具Spoon将Java源代码分析为AST（抽象语法树），然后捕捉定义和引用、定义与注释之间的关联，将坐标信息、注释内容，文本类型，所属文件等信息聚合，输出为统一的LSIF的Json格式。
每时每刻都在发生技术的升级和变革，只有持续不断的学习，才能对老的架构有新的认识，对于老的问题产生新的解法，要了解业界最近在发生什么变化，这个领域最关键的项目和人在做什么，学习他们的技术，学习他们的论文。我以前每天大概2到3个小时是用来学习。这几个小时的学习时间是我最放松的时间，不用去想太多事。
• 资源管理器（Resource Manger，RM）：事务的参与方，如 MySQL 中的一个库，在 PolarDB-X 中这个角色由存储节点（DN）承担
通常，用户很少会主动使用 START TRANSACTION READ ONLY 开启事务，因此对于常规事务，我们也针对每个连接使用了延迟开启 XA 事务的策略。对于所有连接，默认以只读的形式不开启事务，直到第一个写请求或者 FOR UPDATE 读请求再进行正常的 XA 事务流程。
