Manticore：比Elasticsearch 更快，由C++编写，已有 21 年历史(译)

原文地址：manticoresearch.com/blog/mantic...

Manticore 最初是曾经流行的搜索引擎 Sphinx Search 的开源版本的一个分支。在2017年的时候，Sphinx 停止了其作为开源项目的开发，许多喜欢它并且知道如何处理它的 Sphinx 用户对此并不满意，结果，沮丧的用户和一些前 Sphinx 开发人员联手打造了一个分支------Manticore Search，他们的目标如下：

• 继续将项目开发为开源项目
• 从普通用户的角度看待一切，并添加他们在当今环境中所需的功能
• 强化 Sphinx 的强项并消除明显的弱点

Manticore 与 Elasticsearch的对比

搜索速度

性能（即低响应时间）在许多情况下都很重要，特别是在日志和数据分析中，当数据很多但搜索查询不多时,您不想等待 30 秒而不是 2 秒才能得到回复，对吗？以下是细微差别：Elasticsearch 被认为是日志管理的标准，但是，它无法有效地将查询并行化到单个索引分片。 Elasticsearch 默认情况下只有 1 个分片，但现代服务器中的 CPU 核心数量要多得多。制作太多碎片也不好。对于关心响应时间的开发人员来说，所有这些并没有让生活变得更轻松：您必须考虑 Elasticsearch 将在什么硬件上运行并做出相应的更改。

相反，Manticore 能够无条件且默认地将搜索查询并行化到所有 CPU 核心。更正确的说法是，Manticore 本身决定何时并行化、何时不并行化，但在大多数情况下，它确实如此，这允许您有效地加载 CPU 核心（在日志记录和数据分析的情况下通常处于空闲状态）并显著减少响应时间。

但即使你在 Elasticsearch 中创建的分片数量与服务器上的 CPU 核心数量一样多，Manticore 的速度也会明显更快，具体来说：这是对 17 亿个文档 的测试，从中你可以看到整体上 Manticore 的速度是 4 倍。弹性搜索。如果您对细节感兴趣或者想在自己的硬件上重现它，这里有一篇文章 db-benchmarks.com/test-taxi/ （下面的所有示例也有脚本和链接等支持）

这是一个不同的情况：没有大数据，只有 Hacker News 的 110 万条评论。在此测试中，Manticore 比 Elasticsearch 快 15 倍。所有细节都在这里：db-benchmarks.com/test-hn-sma...

另一项测试表明 Elasticsearch 作为标准日志分析工具 - 1000 万条 Nginx 日志和各种相当真实的分析查询 - Manticore 比 Elasticsearch 快 22 倍。所有细节都在这里：db-benchmarks.com/test-logs10...

数据摄取性能

Elasticsearch 的写入速度也存在细微差别。例如，加载上述 17 亿文档测试的数据集：

• 到 Elasticsearch - 在 28 小时 33 分钟内
• 到 Manticore Search - 1 小时 8 分钟

这是在带有 SSD 的 32 核服务器上。索引后的数据量大致相同。要了解有关如何准确处理负载的更多信息，请阅读此处：github.com/db-benchmar...

里面写的是什么

• Elasticsearch本身是用Java编写的，它使用和依赖的Lucene库也是用Java编写的。
• Manticore 是用 C++ 编写的。它给出了什么：
  • 代码更难写，是的。
  • 但我们更接近硬件，所以我们可以做出更优化的代码。
  • 无需考虑 JVM 堆大小。
  • JVM 垃圾收集器不存在在不适当的时刻启动 gc 的风险，这会极大地影响性能。
  • 无需在启动时运行繁重的 JVM，这会花费相当长的时间。

开源

• Elasticsearch 不再是纯粹的开源。许可证于 2021 年从 Apache 2 更改为 Elastic 许可证。
• Manticore 是纯开源的，daemon 有 GPLv2 许可证，columnar library有 Apache 2 许可证。

JSON vs SQL JSON 与 SQL

Elasticsearch 和 Manticore 都可以执行 SQL 和 JSON，但区别在于：

• Elasticsearch 默认基于 JSON，而 Manticore 则基于 SQL。我们喜欢 SQL 的一点是，如果使用它，很多事情在概念验证阶段就会变得更容易。例如，这里有 2 个执行相同操作的查询。您想花一分钟数一下 { 和 } 括号还是......？

• SQL在Elasticsearch中非常有限，例如：
  • 你不能做 SELECT id
  • 你不能 INSERT/UPDATE/DELETE
  • 您无法运行服务命令（创建集群、查看状态等）。
• 在 Manticore 中，情况正好相反：
  • 您可以通过 SQL 完成所有操作
  • JSON 仅涵盖基本功能：搜索和数据修改查询。

启动时间

在某些情况下，您需要能够快速启动服务。例如，在 IoT（物联网）或某些 ETL 场景中。

• Elasticsearch 需要很长时间才能启动。
• Manticore 只需几秒钟即可启动包含 110 万个文档的表: github.com/db-benchmar...

近实时与实时

如上所述，默认情况下，当您将数据放入 Elasticsearch 时，仅在一秒钟后才可搜索。这可以调整，但摄取速度会明显变慢，如上所示。

Manticore 始终以实时模式工作。

全文检索

可能值得另一篇文章来解释这一切。简而言之：Manticore 和 Elasticsearch 在全文搜索方面都很好，有很多共同点，但也有很多差异。根据这些 客观测试（这在评估相关性时很重要），在几乎默认设置上，Manticore 可以提供比 Elasticsearch 更高的相关性。这是BEIR（信息检索基准）中的相关拉取请求。

聚合

Manticore 和 Elasticsearch 都提供了丰富的聚合功能。您可能知道 Elasticsearch 可以做什么，以下是 Manticore 可以做的事情供您比较：

• 仅分组： SELECT release_year FROM films GROUP BY release_year LIMIT 5
• 获取聚合： SELECT release_year, AVG(rental_rate) FROM films GROUP BY release_year LIMIT 5
• 对存储桶进行排序： SELECT release_year, count(*) from films GROUP BY release_year ORDER BY release_year asc limit 5
• 同时按多个字段分组： SELECT category_id, release_year, count(*) FROM films GROUP BY category_id, release_year ORDER BY category_id ASC, release_year ASC
• 从每个存储桶中获取 N 条记录，而不是 1 条： SELECT release_year, title FROM films GROUP 2 BY release_year ORDER BY release_year DESC LIMIT 6
• 在存储桶内排序： SELECT release_year, title, rental_rate FROM films GROUP BY release_year WITHIN GROUP ORDER BY rental_rate DESC ORDER BY release_year DESC LIMIT 5
• 过滤桶： SELECT release_year, avg(rental_rate) avg FROM films GROUP BY release_year HAVING avg > 3
• 使用 GROUPBY() 访问聚合键： SELECT release_year, count(*) FROM films GROUP BY release_year HAVING GROUPBY() IN (2000, 2002)
• 按数组值分组： SELECT groupby() gb, count(*) FROM shoes GROUP BY sizes ORDER BY gb asc
• 按 json 节点分组： SELECT groupby() color, count(*) from products GROUP BY meta.color
• 获取不同值的计数： SELECT major, count(*), count(distinct age) FROM students GROUP BY major
• 使用 GROUP_CONCAT() ： SELECT major, count(*), count(distinct age), group_concat(age) FROM students GROUP BY major
• 在主查询后使用 FACET ，它将对主查询的结果进行分组： SELECT *, price AS aprice FROM facetdemo LIMIT 10 FACET price LIMIT 10 FACET brand_id LIMIT 5
• 通过聚合另一个属性进行facet： SELECT * FROM facetdemo FACET brand_name by brand_id
• 没有重复的facet： SELECT brand_name, property FROM facetdemo FACET brand_name distinct property
• 表达式上的facet： SELECT * FROM facetdemo FACET INTERVAL(price,200,400,600,800) AS price_range
• 多级分组上的facet： SELECT *,INTERVAL(price,200,400,600,800) AS price_range FROM facetdemo FACET price_range AS price_range, brand_name ORDER BY brand_name asc;
• facet结果排序：

SELECT * FROM facetdemo
FACET brand_name BY brand_id ORDER BY FACET() ASC
FACET brand_name BY brand_id ORDER BY brand_name ASC
FACET brand_name BY brand_id ORDER BY COUNT(*) DESC

• facet结果中的分页

SELECT * FROM facetdemo
FACET brand_name BY brand_id ORDER BY FACET() ASC  LIMIT 0,1
FACET brand_name BY brand_id ORDER BY brand_name ASC LIMIT 2,4
FACET brand_name BY brand_id ORDER BY COUNT(*) DESC LIMIT 4;

Schemaless

Elasticsearch 因可以在其中写入任何内容而闻名。使用 Manticore Search，您必须事先创建一个 scheme 。许多 Elasticsearch 专家建议使用静态映射，例如 octoperf.com/blog/2018/0...

但我们发现动态映射在日志管理和分析领域很重要。由于我们希望 Manticore 易于使用，因此我们也计划在 Manticore 中启用动态映射。

集成

• Elasticsearch 和 Manticore 都有不同编程语言的客户端。

• MySQL协议支持：

  • Manticore 的一个重要优点是可以使用 MySQL 客户端与服务器一起工作。即使某些语言没有官方的 Manticore 客户端，也肯定有一个 MySQL 客户端可以使用。使用命令行 MySQL 客户端进行管理比使用 curl 更方便，因为命令更加紧凑并且支持会话。
  • 对 MySQL 协议的支持还使得支持 MySQL/Mariadb FEDERATED 引擎成为可能，以实现这些引擎与 Manticore 之间的紧密集成。
  • 此外，Manticore 可以通过 ProxySQL 使用。

• Elasticsearch 和 Manticore 均支持 HTTP JSON API。

• Logstash、Kibana：Manticore 支持 Kibana，但它是一项正在进行的工作，处于测试阶段。

Replication

• Elasticsearch 和 Manticore Search 都使用同步复制。在 Manticore，我们决定不再重新发明轮子，而是与 Galera 库集成，Mariadb 和 Percona Xtradb 集群也使用该库。

• Manticore 和 Elasticsearch 中管理复制和集群的一个重要区别是，使用 Elasticsearch，您需要编辑配置来设置副本，而在 Manticore 中则不需要：复制始终处于启用状态，并且非常容易连接和同步与另一个节点：

分片和分布式索引

与 Elasticsearch 不同，Manticore 还没有自动分片，但是将多个索引合并为一个进行手动分片比在 Elasticsearch 中更容易：

还支持添加位于远程节点上的索引，只需指定远程主机、端口和索引名称即可。

易于使用和学习

我们的想法是，我们不希望我们的用户（无论是开发人员还是开发人员）成为数据库或搜索引擎方面的专家，或者拥有博士学位才能使用 Manticore 产品。我们假设您还有其他事情要做，而不是花几个小时尝试了解这个或那个设置如何影响这个或那个功能。因此，即使在默认情况下，Manticore Search 在大多数情况下也应该可以正常工作。

• 如前所述，Manticore 是 SQL 优先的，与 Elasticsearch 相比，我们发现在您刚刚开始使用 Manticore 时这一点很重要。
• Manticore 提供互动课程 - play.manticoresearch.com，引导您完成熟悉 Manticore 的基本步骤。
• 有一个关于如何开始使用不同操作系统和编程语言的示例的指南 - manual.manticoresearch.com/Quick_start... 。
• 您可以通过公共渠道直接与开发人员交谈：Slack、Telegram、论坛。
• 我们有一个与文档集成的特殊短域 mnt.cr，以便 mnt.cr/<keyword> 以特殊模式将您带到文档中的搜索结果 - 它会立即倒回到最相关的部分。当您需要回忆某些设置的一些细节时，这特别方便。 mnt.cr/max_packet_size。

云原生

• Elasticsearch 提供 Kubernetes 运算符
• Manticore Search 提供 Helm 图表。

命令式和声明式使用模式

• 在Elasticsearch中，大多数事情只能通过API来完成。没有办法将映射添加到配置文件中，以便它们在启动后立即可用。
• Manticore 和 Kubernetes 一样，支持两种使用模式：
  • 命令式: 当一切都可以使用 CREATE TABLE/DROP TABLE/ALTER TABLE, CREATE CLUSTER/JOIN CLUSTER/DELETE CLUSTER 等在线管理时。
  • 声明式: 当您可以在配置文件中定义映射时，这会提供更大的可移植性，并且更容易将 Manticore 集成到 CI/CD、ETL 和其他流程中。

Percolate

渗透或持久查询是指表包含查询而不是文档，并且搜索是针对文档而不是查询执行的，搜索结果是满足文档的查询。这种类型的搜索对于用户的订阅很有用：例如，如果您订阅了查询 TV > 42 inches ，那么一旦它出现在网站上，您就会收到通知。 Manticore 和 Elasticsearch 都提供了该功能。根据我们几年前所做的测试，Manticore 中此类搜索的吞吐量明显高于 Elasticsearch。

结论

那么，归根结底，我们有什么？Manticore现在可能会引起以下人员的兴趣：

• 用户关心少量和大量数据的低响应时间
• 用户想要比 Elasticsearch 更简单的东西来更快地将搜索集成到他们的应用程序中
• 用户想要更轻、启动快的东西
• 用户关心使用纯粹的开源软件