在本文中，我们将讨论在3.0.2版本中引入的加载数据的新选项
一个包含数据的索引由多个组件组成，如字典、文档和命中列表、属性。整个索引不会完全加载到RAM中，因为它可能无法容纳，而是其组件以不同的方式读取和加载。
属性 属性默认加载到RAM中，但可以随时选择加载所有属性、仅加载标量类型（整数或浮点数）或保留在磁盘上。
属性作为内存映射文件加载。使用mmap()加载属性的优势是比使用pread()的经典seek&read方法性能更好。它还允许使用少量RAM处理大文件。
…
我们很高兴宣布发布 Manticore Search 3.0.2。下载地址可在 here 获取，也可从 Manticore Github 页面 获取。Docker 镜像可在 Docker Hub 获取。
改进 Doclists 和 hitlists 组件也可以通过内存映射（如同属性一样）进行访问，而不是使用 seek+read。可以通过 access_doclists 和 access_hitlists 指令选择访问模式。
新指令 access_plain_attrs …
正如您可能知道的，最近 Manticore 3.0 已发布 。
在此基准测试中，我们来看看它是否比 2.8 更好。测试环境如下：
2016 年的 Hacker News 精选评论数据集 以 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 内存 硬盘 Docker 版本 18.09.2 索 …
本文将讨论 kill-list 在 Manticore Search 3 中的工作方式。
普通索引在添加新文档方面是不可变的：一旦创建，就无法添加更多数据，只能更新现有文档的属性。为了使索引与主数据（可以是数据库或文件）保持一致，需要通过执行完整重建来刷新索引。此操作可能需要时间。在某些情况下，完整重建可能需要数小时甚至更久。
这意味着可搜索的数据可能会落后于原始数据存储，最新内容需要等待索引重建才能显示。为了解决这个问题，引入了增量索引的概念。增量索引的结构与较大的（即“ …
最近 我们发布了 Manticore 3.0.0 ，其中包含许多改进，包括一些新的优化，提高了性能。在本文中，我们希望将新版本的性能与 Sphinx 3.1.1 的性能进行比较。
TL;DR Manticore 表现出：
在某些情况下，搜索性能大约提高了 2 倍，尤其是在较长查询时 在其他所有测试中，性能较低，但仍优于 Sphinx 除了索引时间，Sphinx 快 2% 测试环境 正如 我们之前对 Manticore 2.7 与 Sphinx 3 进行基准测试时 ，我们将使用 …
Manticore Search 3 首次引入了索引兼容性的破坏性变更，无法加载使用2.x版本创建的现有索引。这意味着在升级searchd到3.x之前，必须准备好索引。
要使索引使用新格式，有两种选择：
完全重建索引。如果索引不是非常大且不是实时索引，这是最简单的途径。 使用转换工具，可以自动将任何类型的索引（普通、percolate、实时）从Manticore 2/Sphinx 2格式转换为新格式 在开始迁移之前，有几项需要注意：
文档ID现在是正的有符号大整数，之前是无符 …