在这篇文章中，我们讨论了在 3.0.2 中引入的新数据加载选项。
包含数据的索引由几个组件组成，如字典、文档和命中列表、属性。整个索引并不是完全加载到 RAM 中，因为可能无法容纳，而是以不同的方式读取和加载其组件。
属性 属性默认加载到 RAM 中，但可以选择是否加载所有属性、仅加载标量类型（整数或浮点数）或将其保留在磁盘上。
属性以内存映射文件加载。使用 mmap() 加载属性的优点是比经典的寻道和读取使用 pread() 更高的性能。它还允许使用小量的 RAM 来处理大 …
我们很高兴地宣布 Manticore Search 3.0.2 的发布。下载链接可在 这里 和 Manticore Github 页面 找到。Docker 镜像可在 Docker Hub 上获取。
Improvements 文档列表和命中列表组件也可以通过内存映射（像属性一样）访问，而不是使用 seek+read。可以使用 access_doclists 和 access_hitlists 指令选择访问模式。
新的指令 access_plain_attrs …
正如您可能知道的，最近发布了 Manticore 3.0 版本 。
在这个基准测试中，我们来看看它是否比 2.8 更好。测试环境如下：
Hacker News 精选评论数据集 ，2016 年，CSV 格式 操作系统：Ubuntu 18.04.1 LTS (Bionic Beaver)，内核：4.15.0-47-generic CPU：Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz，8 核心 32G RAM HDD Docker …
在这篇文章中，我们将讨论在Manticore Search 3中杀死列表是如何工作的。
普通索引在添加新文档方面是不可变的：一旦创建，就不可能添加更多数据，只能更新现有文档的属性。为了使索引与主要数据（可能是数据库或文件）保持一致，需要通过执行完全重建来刷新索引。此操作可能需要时间。在某些情况下，完全重建可能需要几个小时甚至更长时间。
这意味着可搜索的数据可能滞后于原始数据存储，最新的内容在索引重建之前需要等待时间。为了解决这个问题，引入了增量索引的概念。增量索引具有与更大（ …
最近 我们发布了 Manticore 3.0.0 ，其中包括许多改进和一些新的优化，提高了性能。在本文中，我们想将新版本的性能与 Sphinx 3.1.1 的性能进行比较。
TL;DR Manticore 显示：
在某些情况下，搜索性能约提高 2 倍，尤其是在处理较长查询时 在其他所有测试中，性能较低，但仍优于 Sphinx 除了索引时间，Sphinx 快 2% 测试环境 如同 我们之前对比 Manticore 2.7 vs Sphinx 3 的基准测试 ，我们将在 1160 …
Manticore Search 3 首次带来了索引兼容性的中断，无法加载使用 2.x 创建的现有索引。这意味着在将 searchd 升级到 3.x 之前，索引需要准备好。
要使索引采用新格式，有两个选项：
完全重建索引。如果您的索引不是很大且不是实时的，这是一条简单的路。 使用转换工具，可以自动将任何类型的索引（普通、抽取、实时）从 Manticore 2 / Sphinx 2 格式转换为新格式。 在开始迁移之前，有几件事情需要注意：
文档 ID 现在是正有符号大整数，以前 …