Manticore Search 在 Microsoft Azure 上：DX1 的故事
Source: Dev.to
TL;DR
- DX1 使用 Manticore Search 为客户和零件提供快速的键入提示（type‑ahead）用户体验
- 选择它是因为开源许可证和速度
- 部署在运行 Ubuntu 的 Azure 虚拟机上，符合 DX1 现有的 Azure 资源布局
- 处理 2000 万+ 零件；最佳的键入提示性能需要将索引放在内存中
- 通过升级虚拟机内存或向 Manticore 集群添加节点来实现扩展
- 日常运营低接触、低维护
概览
DX1 将 Manticore Search 作为面向用户的快速搜索层，用于检索超过 2000 万个零件和客户记录的目录。架构刻意保持简洁：Manticore 运行在基于 Ubuntu 的 Azure 虚拟机（VM）上，和 DX1 其他 Azure 基础设施一起提供响应迅速的键入提示，同时在运维上保持“低接触”。随着数据和流量的增长，DX1 通过升级 VM 规格或添加更多节点来实现扩展。
“我们用它来搜索客户和零件数据，拥有客户喜爱的键入提示功能。” – Damir Tresnjo, DX1
为什么选择 Manticore Search？
- 开源 – 无许可费用，且对技术栈拥有完整控制。
- 性能 – 自动完成和模糊搜索的响应时间可达毫秒级。
“开源且非常快。” – Damir
速度、灵活性和成本效益的组合使 Manticore 成为 DX1 工作负载的自然选择。
在 Azure 上的部署
DX1 的全部基础设施都运行在 Microsoft Azure 上，因此在 Azure 虚拟机上部署 Manticore 是最直接的选择。团队在 VM 上运行 Ubuntu 并直接安装 Manticore，避免使用任何 Azure 特定的托管搜索服务。
“我们所有东西都在 Azure 上运行，所以我们也在那儿部署了 Manticore。”
架构要点
- 基于 VM 的部署 – 简单的 Linux 虚拟机提供所需的灵活性。
- 不使用托管服务 – 避免额外的成本和复杂性。
性能与扩展
即使在 2000 万+ 零件的规模下，Manticore 也表现出快速且稳定。
“它的性能非常快，我们搜索的零件超过两千万。”
内存考虑
键入提示的性能受益于将索引保存在 RAM 中。当索引超出可用内存时，需要增加 VM 的内存。
“键入提示的性能需要数据库在内存中。一旦索引超出可用内存，我们就必须升级 VM 内存。”
扩展策略
- 垂直扩展（Scale‑up） – 增加现有 VM 的 RAM。
- 水平扩展（Scale‑out） – 向 Manticore 集群添加更多 VM。
“我们可以对每台 VM 进行扩容，也可以向 Manticore 集群添加更多 VM。”
运维
DX1 将 Manticore 描述为低接触、低维护。
“低接触，低维护，大多数时候它就这么运行着。”
该设置仅依赖可预测的 VM 操作，无需任何特殊的 Azure 功能。
推荐
DX1 会向任何寻求快速、可靠且具成本效益的搜索引擎的团队推荐 Manticore Search。
“是的，我会向任何想要快速、可靠且具成本效益的搜索引擎的人推荐 Manticore。”
入门指南
对于希望在 Azure 上采用类似基于 VM 的部署的团队：
- 评估数据集规模、查询模式和延迟目标。
- 规划键入提示索引的 RAM 余量（优先垂直扩展）。
- 考虑集群，如果预期会有进一步增长（水平扩展）。
如果您想快速进行架构评审，请联系 Manticore 团队。提供您的数据集、查询工作负载和延迟目标的细节，他们会帮助您验证方案并规划后续步骤。
进一步阅读
- 模糊搜索与自动完成概述: New fuzzy search and autocomplete (replace with actual URL)