我们目前正在使用elasticsearch来索引和执行大约10M文档的搜索。它工作正常,我们对其性能感到满意。我的同事开始使用elasticsearch确信它可以用作中央数据存储库,而其他数据系统(例如SQL Server,Hadoop / Hive)可以将数据推送给他们。我没有任何反对它的论据,因为我对两者的了解都太有限了。但是,我很担心。
我知道elasticsearch中的数据以对文本搜索有效的方式存储。 Hadoop就像文件系统一样存储数据,但是以一种有效的方式在多个数据节点上扩展/复制块。因此,在我看来,使用Hadoop(因为它对数据的看法更加不可知)作为中央数据存储库似乎更有益。然后将数据从Hadoop推送到SQL,elasticsearch等......
我已经阅读了一些关于Hadoop和elasticsearch用例的文章,使用Hadoop作为中央数据存储库似乎很常见。但是,我找不到任何可能表明弹性搜索不是一个不错的选择的东西。
请帮忙!
答案 0 :(得分:7)
与所有数据库部署的情况一样,它实际上取决于您的特定应用程序。
Elasticsearch是一个很好的开源搜索引擎,建立在Apache Lucene之上。它的功能和升级使它基本上可以像无模式JSON数据存储一样运行,可以使用特定于搜索的方法和常规数据库CRUD类命令来访问它。
尽管Elasticsearch所带来的所有优势,仍然存在一些主要的缺点:
安全性 - Elasticsearch不提供任何身份验证或访问控制功能。它受支持,因为它们有introduced shield。
交易 - 不支持事务或处理数据操作。现在数据操作由 logstash 处理。
持久性 - ES是分布式且相当稳定,但备份和持久性不如其他数据存储那么高。
工具的成熟度 - ES仍然相对较新,没有时间开发成熟的客户端库和第三方工具,这些工具可以使开发更加困难。我们现在可以认为它已经相当成熟了
周围有各种连接器和工具,如 kibana 。但它仍然不适合大型计算 - 搜索数据的命令不适合数据的“大”扫描和数据库端的高级计算。
数据可用性 - ES以“近乎实时”的方式提供数据,这可能需要您的应用程序中的其他注意事项(即:用户添加新评论的评论页面,刷新页面实际上可能不会显示新帖子,因为索引仍在更新中。
如果您可以处理这些问题,那么您肯定没有理由不能将Elasticsearch用作主数据存储。它实际上可以通过不必复制数据来降低复杂性并提高性能,但这又取决于您的具体用例。
与往常一样,权衡利益,做一些实验,看看什么最适合你。
免责声明:此答案是前一段时间为Elasticsearch 1.x系列撰写的。这些评论家仍然以某种方式与2.x系列站在一起。但是Elastic正在开发它们,因为2.x系列在每个示例中提供了更成熟的工具,API和插件,安全性明智,如Shield甚至是Logstash或Beats之类的传输客户端等。< / p>
答案 1 :(得分:4)
我强烈反对大多数用户不使用elasticsearch作为主要数据存储区。它将很好地工作,直到您的群集由于网络分区而熔化。即使是ES专业人员总是设置的minimal_master_nodes等设置也不会为您节省开支。看看Aphyr和他的Call Me Maybe系列的精彩分析: http://aphyr.com/posts/317-call-me-maybe-elasticsearch
eliasah,是的,这取决于您的使用案例,但如果您的数据(和工作)对您很重要,请远离。将您的数据的黄金记录保存在真正专注于保持和同步数据的内容中,以便从那里进行搜索。它增加了额外的复杂性和资源,但会带来更好的夜间休息:)
有很多方法可以解决这个问题,如果elasticsearch能够完成你需要的一切,你可以查看Kafka是否会将所有事件保存到集群中,以便在出现问题时进行重播。我喜欢这种方法,因为它为弹性搜索提供了异步摄取管道,同时也提供了持久性。