access官方下载 免费完整版 使用Docker和Elasticsearch搭建全文本搜索引(19)

<divclass="modal-footer">

<buttonclass="mui-btn mui-btn--flat"v-on:click="prevBookPage()">Prev Page </button>

<buttonclass="mui-btn mui-btn--flat"v-on:click="closeBookModal()">Close </button>

<buttonclass="mui-btn mui-btn--flat"v-on:click="nextBookPage()">Next Page </button>

</div>

</div>

重启应用服务器（docker-compose up -d --build），打开localhost:8080。此时如果点击搜索结果，就可以查询段落上下文。如果对查到结果感兴趣，甚至可以从查询处一直读下去。

恭喜！！到这一步主体框架已经搭建完毕。以上所有代码都可以从这里[3]获得。

9. Elasticsearch的不足

9.0 资源消耗

Elasticsearch是计算资源消耗的应用。官方建议至少运行在64G以上内存的设备上，不建议少于8GB内存。Elasticsearch是一个内存，因此查询速度会很快，但是也会消耗大量内存。生产中，强烈推荐运行Elasticsearch集群提供高可用性、自动分片和数据冗余功能。

我在一个1.7GB的云设备上（每月15美金）运行以上示例（search.patriktriest.com），这些资源仅是能够运行Elasticsearch节点。有时整个节点会在初始装载数据时候hang住。从我的经验看，Elasticsearch比传统的PostgreSQL和MongoDB跟消耗资源，如果需要提供理想服务效果，成本可能会很贵。

9.1 之间的同步

对许多应用，将数据存放在Elasticsearch中并不是理想的选择。建议将ES作为交易型，但是因为ES不兼容ACID标准（当扩展系统导入数据时，可能造成写入操作丢失的问题），所以也不推荐。很多场景下，ES承担着很特殊的角色，例如全文本查询，这种场景下需要某些数据从主复制到Elasticsearch中。

例如，假设我们需要将用户存放到PostgreSQL表中，但是使用ES承担用户查询功能。如果一个用户，“Albert”，决定修改名字为“Al”，就需要在主PostgreSQL库和ES集群中同时进行修改。

这个操作有些复杂，依赖现有的软件栈。有许多开源资源可选，既有监控MongoDB操作日志并自动同步删除数据到ES的进程，到创建客制化基于PSQL索引自动与ES通讯的PostgreSQL插件。

如果之前提到的选项都无效，可以在服务端代码中根据变化手动更新Elasticsearch索引。但是我认为这种选择并不是最佳的，因为使用客制化商业逻辑保持ES同步很复杂，而且有可能会引入很多bugs。

Elasticsearch与主同步需求，与其说是ES的弱点，不如说是架构复杂造成的；给应用添加一个专用搜索引擎是一件值得考虑的事情，但是要折衷考虑带来的问题。

结论

全文本搜索对现代应用来说是一个很重要的功能，同时也是很难完成的功能。Elasticsearch则提供了实现快速和客制化搜索的实现方式，但是也有其它替代选项。Apache Solr是另外一个基于Apache Lucene（Elasticsearch核心也采用同样的库）实现的开源类似实现。Algolia则是最近很活跃的search-as-a-service模式web平台，对初学者来说更加容易上手（缺点是客制化不强，而且后期投入可能很大）。

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-88976-19.html