概述
在本文中，我们将介绍：
- ANN 模型如何实现快速和大规模的矢量搜索
- 流行的人工神经网络库的不足之处
- Weaviate 是什么以及它如何将您的矢量搜索需求投入生产
- 一瞥 Weaviate 如何在引擎盖下工作
介绍
随着机器学习模型的日益普及，对向量相似性搜索解决方案的需求也急剧增加。机器学习模型通常输出向量，常见的搜索查询涉及找到最接近的相关向量集。例如，对于基于文本的向量搜索，搜索查询“巴黎的地标”将被编码为向量，然后搜索引擎的工作就是查找向量最接近该查询的文档。这可能是一个标题为“Eiffel Tower”的文档，其向量与搜索向量最接近。
如果要搜索的对象很少，比如少于 10,000 个，那么这种向量相似性比较在计算上是微不足道的。然而，这不是一个非常现实的情况。公司和用户需要搜索的非结构化数据量是巨大的。对象的数量通常高达数百万甚至数十亿个数据点。原始蛮力比较不能再在可接受的时间范围内返回结果。
这导致了近似最近邻 (ANN) 模型的兴起。您可能听说过 Spotify 的 Annoy、Facebook 的 faiss 或 Google 的 ScaNN。它们的共同点是，它们在准确性（精确度、召回率）和检索速度之间进行了有意识的权衡。这使用户能够在几毫秒内检索 5、10 或 100 个最接近的向量——即使是从十亿个对象中。
然而，在使用 ANN 模型时，工程师还必须做出另一个权衡。许多常见的人工神经网络库不具备我们在使用传统数据库和搜索引擎时习惯使用的一些功能。想象一下，您使用的是 MySQL 数据库，但在导入数据后，它在其余时间都是只读的。这不是它的工作原理，对吧？那么为什么它应该像矢量搜索那样工作呢？在本文中，我将向您介绍 Weaviate，这是一个矢量优先搜索引擎，它消除了 ANN 库施加的许多限制。
什么是 Weaviate？
在我们深入探讨 Weaviate 如何消除现有 ANN 解决方案可能存在的限制之前，让我们快速了解一下 Weaviate 是什么。Weaviate 是一个云原生、模块化、实时矢量搜索引擎，旨在扩展您的机器学习模型。哦，顺便说一句，它也是开源的。由于其模块化，Weaviate 可以覆盖各种基础。默认情况下，Weaviate 不知道您是如何得出向量的。这意味着具有数据科学和机器学习经验的团队可以简单地继续使用他们经过微调的 ML 模型，并将他们的数据对象与他们现有的向量位置一起导入。同时，Weaviate 自带文本、图像和其他媒体类型的可选模块。这些模块可以为您进行矢量化。因此，如果您是机器学习领域的新手，您可以像使用传统搜索引擎一样导入对象，然后让 Weaviate 处理矢量化。这为大众带来了矢量搜索的好处——即使没有机器学习背景。组合模块的能力还允许例如文本对象和对应的图像对象之间的关系。正如本文将展示的，Weaviate 也不受流行 ANN 库的一些限制。
什么时候称数据库为数据库？
如果你问一百名工程师什么定义了数据库，你很可能会得到许多不同的答案。在 SQL 和 NoSQL 数据库的世界中，我们可能认为以下几点是理所当然的，但它们在向量搜索的上下文中却并非无处不在。
- CRUD 我们习惯于允许我们创建、读取、更新和删除对象的数据库。
- 实时（或接近实时） 导入数据库的对象通常可以在很短的时间内查询。一些数据库具有刷新间隔，而一些数据库利用最终一致性。两者都可能导致轻微的延迟，但一般来说，对象会在几秒钟内出现，而不是几分钟或几小时。
- 可变性 数据库通常是可变的。这不仅指单个对象（如 CRUD 功能中已涵盖的那样），还指整个数据库或其中的集合，例如 SQL 数据库中的表。我们习惯于随意添加另一行。
- 持久性 我们通常期望数据库写入是持久的。这并不意味着内存数据库不是数据库。但这确实意味着当数据库使用磁盘时，我们不希望写入丢失——例如，在意外重启时。
- 一致性。弹性和可扩展 性 一些数据库具有原子事务，而另一些则根本不支持一致性。一些数据库在云中的扩展性非常好，而另一些则作为大型单机工作得最好。确切的特征不会使数据库成为数据库。但是构建它的工程师已经决定了一个特定的策略这一事实是数据库的一个关键特征。
流行的 ANN 库不符合上述许多原则
ANN 库的最大缺点在于它们的实时能力和可变性。Annoy 或 ScaNN 等库要求您预先导入所有数据对象。然后是一个构建期来构建索引。完成后，它是一个只读模型。就我们之前概述的要点而言，这带来了两个主要缺点：首先，如果您导入第一个对象，则在导入所有对象之前它还不可查询。如果您导入十亿个对象，这可能是一个非常可观的时间。因此它们不是实时的。此外，一旦你建立了索引，你就不能再改变索引而不从头开始重建它。因此，诸如更新或删除之类的操作是不可能的，并且搜索模型不能被认为是可变的——甚至对于进一步的插入也不行。
上述模型的持久化策略通常是快照。因此，虽然您可以将索引保存到磁盘并从磁盘重新加载它，但单个写入通常不会持久化。由于 Annoy、ScaNN 等不是应用程序，而是库，这也意味着提出弹性和扩展策略是留给开发人员的。扩展只读模型当然不难。但是，简单地复制模型的功能集无法与扩展流行的分布式数据库（例如Cassandra ）相比。
Weaviate 克服了 ANN 库的限制
设计 Weaviate 的目标之一是将 ANN 模型的速度和大规模能力与我们喜欢的数据库功能相结合。因此，任何导入到 Weaviate 的对象都可以立即被查询——无论是通过其 id 查找、使用倒排索引的关键字搜索还是向量搜索。这使得 Weaviate 成为一个实时矢量搜索引擎。而且因为 Weaviate 在后台也使用了 ANN 模型，所以向量搜索将与使用库一样快。
此外，可以随意更新或删除对象，并且可以随时添加新对象——即使在查询时也是如此。这意味着 Weaviate 既支持完整的 CRUD 功能，也支持其索引的可变性。最后但并非最不重要的一点是，每次写入都会持久化，如果您的机器崩溃或 Weaviate 被迫中断其操作，它只会在重新启动后继续您离开的地方。没有任何情况下您连续导入数小时，却因为最后一分钟的崩溃而失去所有进度。
Weaviate 是如何实现这一切的呢？
Weaviate 是围绕模块化的理念构建的。这也归结为 Weaviate 支持的 ANN 向量索引模型。在 2021 年初撰写本文时，支持的第一个矢量索引类型是 HNSW。通过选择这种特定类型，已经克服了其中一个限制：HNSW 支持在插入时进行查询。这是可变性的良好基础，但还不是全部。
现有的 HNSW 库没有完全支持 CRUD。根本不可能进行更新，并且仅通过将对象标记为已删除而不清理它来模仿删除。此外，最流行的库 hnswlib 仅支持快照，但不支持单独写入磁盘。
为了达到今天的 Weaviate，需要自定义 HNSW 实施。它遵循与本文中概述的相同原则，但扩展了更多功能。每次写入都会添加到预写日志中。此外，由于默认情况下向 HNSW 中的插入是不可变的，因此 Weaviate 在内部分配了一个不可变的文档 ID，以允许更新。如果对象被更改，Weaviate 会在后台删除旧的 doc id，分配一个新的，然后将对象重新导入向量索引。最后但并非最不重要的一点是，受 Cassandra 启发的墓碑方法用于处理删除。任何传入的删除（无论是显式删除还是通过更新进行的隐式删除）都会导致将文档 ID 标记为已删除（“附上墓碑”）。因此，它会立即隐藏在未来的查询结果中。然后——这就是 Weaviate 的自定义 HNSW 实现与 hnswlib 不同的地方——异步清理过程重建索引的受影响部分并永久删除墓碑元素。由于经过良好调整的批量清理过程比单个清理要快得多，这可以使索引始终保持新鲜，同时节省大量计算资源。
正是以上因素的结合使 Weaviate 成为在生产中处理您的矢量搜索需求的完美解决方案。
选择适合您的用例的 - 并亲自尝试！
既然您已经了解了流行的 ANN 库所施加的一些限制以及 Weaviate 如何帮助您克服这些限制，那么只剩下一个问题需要回答：您什么时候应该选择哪个？如果您确定您永远不需要更新数据，永远不会添加新数据点，并且不需要实时功能，那么像上面提到的库将是一个很好的解决方案。但是，如果您想更新数据，即使在查询发生时导入其他对象，并且不牺牲实时性或持久性，那么您应该看看 Weaviate。
原文标题：Weaviate, an ANN Database with CRUD support
原文作者：ETIENNE DILOCKER
原文链接：https://weaviate.io/blog/2021/02/CRUD-support-in-Weaviate.html
