停止与数据库的索引斗争，全权交给Elasticsearch是一次明智的选择

你好，我是WACUL的CTO包。

今天是2015 WACUL冒险日历2015的最后一天。

这一年，作为公司来说是一个非常有成长的一年。回顾所有参与的圣诞日历文章，我可以感受到技术人员的水平变得更加高深了。

我对在繁忙工作中抽空写愉快文章的公司同事们表示感谢，对在忙碌中为我们撰稿的@kenzan100先生表示感谢，感谢所有支持技术团队工作方式、与我们一同努力的同事们。

当把数据搜索交给Elasticsearch之后，发生了一件很好的事情。

嗯，现在进入正题。
今年在我们公司引入的新工具中，我认为特别好的一个是 Elasticsearch。

根据引入Elasticsearch的经验，本文总结了从整体开发成本和运维方面考虑时的建议要点。没有涉及太多关于设置和查询等细节技术方面的讨论。

目标读者

这篇文章的目标读者是符合以下条件的人。

• アプリのバックエンドの設計・実装に関わっていて、まだ elasticsearch は導入していない

• 扱うデータの件数が多い (100万件以上とか)

• 全文検索は別に使ってない(もしくはDBでがんばってる)

• 複雑な絞り込み条件でパフォーマンスが気になっている

DBのインデックスで消耗してる

Elasticsearch 是什么？

Elasticsearch 是 Elasticsearch 公司提供的一种具备 RestAPI 和多服务器集群等功能的搜索系统。基本功能可免费使用，但插件和与其集成的部分系统需要付费。
在内部使用了 Apache Lucene 的索引。Lucene 本身是一个相当古老而稳定的软件。
作为使用 Lucene 的搜索系统，还有其他选项，如 Apache Solr，但 Elasticsearch 最近成为最具影响力的软件。
将数据可视化于 Kibana 也很受欢迎，AWS 最近也推出了一项名为 Elasticsearch Service 的托管服务。

我们如何应对增加的数据量和与搜索相关的成本增加。

在运营服务过程中，与信息搜索相关的实施成本随着数据量的增加而增加。
需要管理数据库的索引和复杂查询的调优等等，需要关注众多方面。
另一方面，对于服务的发展，需要快速应对以多种角度展示数据的方式，并且性能也非常重要。

AI分析师使用的产品名为AI分析师进行数据分析时，只使用了MongoDB。大约在发布三个月后，当数据开始增加时，他们开始面临上述问题。

AI分析师的功能包括从Google Analytics等渠道收集的信息进行分析，并通过不同的切入点将其可视化给用户。这可以看作是类似于爬取的方式来收集数据，因此每个用户的数据量非常大。

随着用户数量的增加和数据条数超过100万条，使用现有的MongoDB进行实时搜索时性能不足，并且索引组合的管理变得繁琐。

特别是当我们想要添加新的要求时，在字段A上进行筛选，然后在另一个字段C上对结果进行排序。在这种情况下，我们必须仔细考虑最佳索引（甚至是组合索引），这可能会增加开发的工作量，给人一种负担沉重的感觉。

在那个时候，我们公司正好有一个叫@kanagi的人加入了，他碰巧正在进行Elasticsearch的验证。他说不仅仅是全文搜索，对于更新频率较低的数据类型也很适合，所以我们决定试着将其集成进来。

我如何将Elasticsearch嵌入到搜索中。

为了追求目标，我们采取了以下方针。

• マスタデータは、MongoDBに

• MongoDB側は最低限のインデックス(id, 日付など) のみ

• マスタデータをElasticsearch にインポートするコマンドを作成しておく

• アプリからのデータ書き込みは、マスタDB,Elasticsearch 両方に書き込まれるようにする

関連データのひも付けが必要な場合には、elasticsearchで検索後に適宜MongoDBから紐付ける

使用Elasticsearch时，最好将主要数据存放在其他位置（如数据库或S3），以便始终可以从那里构建用于搜索的索引。这不仅意味着数据的备份，而且因为Elasticsearch基本上无法更改表定义（称为mapping），所以在切换到新的映射时，需要将新的所有数据重新导入。

我們使用 AWS 在三個 m3.medium 實例上構建了一個叢集。

有关导入后的改善效果以及开发和运营成本。

复杂组合条件的搜索速度也快。

从一开始就引入了一个稳定的性能，在当前阶段，我们使用多个筛选和排序条件的组合在拥有超过1000万数据的索引上进行查询，一般而言，搜索时间在50毫秒以内。

应用开发的成本

首先，使用elasticsearch可以快速处理复杂的搜索要求，因此可以放心地进行开发。对于数据库的慢查询调查和索引构建等任务，需要相当高的知识水平和测量工作，因此能够减少这些工作量是非常重要的。

当然，关于在Elasticsearch中插入数据的时机和管理等方面，需要进行额外的实现，但一旦将其系统化，就并不是什么大问题。

基础设施运营的费用

由于管理的软件和服务器增加，运营成本会增加。然而，Elasticsearch集群非常稳定，并能自动实现对每个服务器的复制和处理分配。您可以灵活地添加或更新其他服务器，以及从集群中逐个移除。目前还没有遇到意外情况，系统一直稳定运行，所以一旦引入，我认为运营成本会相对较低。

总结

数据库的搜索性能管理是非常复杂的任务，对于一般的Web服务来说，它直接影响用户所感受到的性能。
引入新的基础设施是一个艰难的决策，但如果理解并正确使用Elasticsearch，运维工作也不会太难，从整体的开发和运维成本来看，我认为这是一个不错的投资。
只需将服务的搜索功能交给elasticsearch，就能在服务持续增长的相当长时间内减少烦恼，所以我认为值得考虑一下。