向量检索目前多通过数据分片的方式实现水平扩展，然而过多的分片容易造成计算量的上升，从而导致检索效率的下降。在分布式方面，仍存在向量索引快速合并算法的难题，这便导致了数据一旦分片之后，无法很好套用 Map-Reduce 计算模型合并成效率更高的索引。
目前，业内普遍使用的向量检索库是 Facebook AI 团队开源的 Faiss (Facebook AI Similarity Search) 引擎。Faiss 非常优秀，也是不少服务化引擎的基础核心，但 Faiss 在大规模通用检索场景方面仍存在一些局限性，如流式实时计算、离线分布式、在线异构加速、标签&向量联合检索、成本控制以及服务化等方面。
一般而言，吞吐量是指处理某事物的速率。在网络级别，吞吐量的度量单位是Mbps(兆位/秒)，而在存储级别，吞吐量的度量单位是MB /秒(兆字节/秒)。由于一个字节等于八兆位，因此生产率在存储级别上提高了。并且，变得难以管理提高的生产率。
企业管理员和存储供应商处理各种各样的存储类型。而且，它们还满足不同输入/输出服务的指标。大型文件共享应用可能需要适当的吞吐量，但也必须允许延迟损失，因为大型而复杂的应用可能会对延迟产生不利影响。
对于应用交付的整个流程而言，通常会涉及三个环节，即开发、测试和运维，而在传统的组织架构中，他们对应的也往往是三个不同的团队。这三个环节各自有自己的侧重点，但是在实际上，想要让整个应用交付过程变得顺滑高效，并且让应用在上线后保持高可用的状态，往往需要三个团队将相互之间存在的墙打破掉。
针对不同语言，我们只需要实现一次从源代码到LSIF格式的转换，就能将其应用在多种场景。多种代码语言代码语言都会被解析成统一的LSIF格式文件。
架构师一定要有技术的广度。大家一定要学会积累，积累到一定程度以后，你会做到无师自通。比如你了解网络、数据库，然后你又了解了磁盘30%，当这些知识逐渐成体系了，你是有能力去消化和打通不同技术点背后的相关性，对于你的个人能力的提升和认知层面的提升有巨大的帮助。
在 XA 协议的设计中，有两种角色：
• 事务管理器（Transaction Manager，TM）：负责发起事务的提交，失败时处理事务异常，在 PolarDB-X 中这个角色由计算节点（CN） 承担
只读连接优化
一个事务如果使用 START TRANSACTION READ ONLY 开启，那么我们就会将事务标记为只读事务。我们会直接通过多个 autocommit 的单语句获取需要的数据，避免长期持有连接和事务的开销。由于 TSO 的存在，我们只需要使用相同的 TS 就能保证读到相同的数据，因此我们通过私有协议支持在每个语句内置一个 SNAPSHOT_TS，保证了同一个事务内的多条单语句读到相同的数据。
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
