在过去的两年多里，我们走过了一段技术探索的旅程，但事实上我们在这个过程中遇到了许多挑战。因为通常情况下，存储和计算分离的架构主要用于 OLAP 数据库。在传统的 OLAP 数据库中，数据的更新频率相对较低。
虽然一些 OLAP 数据库支持更新操作，但更新和删除的能力相对有限。此外，OLAP 数据库通常要求较低的查询延迟，查询几秒钟或几十秒钟，满足前端业务需求即可。然而，向量数据库与此完全不同。
首先，向量数据库需要支持频繁的更新操作，而且这些更新可能是大规模的批量操作。因此，对于向量数据库而言，必须拥有能够支持流式更新的强大存储能力。其次，向量数据库在应用场景上与 OLAP 数据库有很大的区别。不同的应用场景对查询延迟有着不同的要求。
例如，在推荐系统中，用户可能需要几毫秒甚至最多几十毫秒的查询延迟。这就要求在存储和计算分离的架构下，需要有高效的缓存机制，包括本地磁盘缓存和内存缓存。同时，在调度资源时，还需要考虑如何在扩容和缩容时避免请求抖动，以确保稳定性。
在我们的探索过程中，团队始终在不断摸索，时至今日，我们并不认为自己的方案已经达到了完美的程度。这也是为什么我们的大版本从 2.3 升级到 2.4 时，我们会进行一些架构的调整。我们意识到作为行业的探索者&