本文将介绍3.0.2版本中引入的加载数据的新选项 一个包含数据的索引由多个组件组成，如字典、文档和命中列表、属性。整个索引不会完全加载到RAM中，因为可能无法容纳，而是其组件以不同的方式读取和加载。 属性 属性默认加载到RAM中，但可以自由选择全部加载、仅加载标量类型（整数或浮点数）或保留在磁盘上。 属性以内存映射文件的方式加载。使用 mmap() 加载属性的优势是比传统的 seek&read 使用 pread() 具有更佳的性能。它还允许使用少量RAM处理大文件。 在2.x ...
我们很高兴宣布发布 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 进行基准测试时 ，我们将使用来自 Hacker News ...
Manticore Search 3 首次引入了索引兼容性的破坏性变更，无法加载使用 2.x 创建的现有索引。这意味着在升级 searchd 到 3.x 之前，必须准备好索引。 要使索引使用新格式，有两种选择： 完全重建索引。如果索引不是很大且不是实时索引，这是最简单的方法。 使用转换工具，可以自动将任何类型的索引（普通、percolate、实时）从 Manticore 2 / Sphinx 2 格式转换为新格式。 在开始迁移之前，有几项需要注意： 文档 ID 现在是正的有符 ...