MongoDB + Elasticsearch还是只有Elasticsearch? [英] MongoDB + Elasticsearch or only Elasticsearch?

查看:117
本文介绍了MongoDB + Elasticsearch还是只有Elasticsearch?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们在那里有一个新项目,用于索引大量数据并提供实时数据.我还使用方面,全文,地理空间...进行了复杂的搜索...

We have a new project there for index a large amount of data and for provide real time. I have also complexe search with facets, full text, geospatial...

第一个原型是在MongoDB中建立索引,其次是在Elasticsearch中建立索引,因为我已经读过Elasticsearch不会对存储的文件应用校验和,并且索引不能被完全信任. 但是自从最后一个版本(在1.5版中)以来,现在有了一个校验和,我在猜测是否可以将Elasticsearch用作主要数据存储?除了Elasticsearch,使用MongoDB有什么好处?

The first prototype is to index in MongoDB and next, into Elasticsearch, because I had read that Elasticsearch does not apply a checksum on stored files and the index can't be fully trusted. But since last versions (in the version 1.5), there is now a checksum and I'm guessing if we can use Elasticsearch as primary data store ? And what is the benefit to use MongoDB in addition to Elasticsearch ?

我在Elasticsearch中找不到有关这些功能的最新答案

I can't find up to date answer about thoses features in Elasticsearch

非常感谢

推荐答案

讨论参数要使用的 Mongo而不是与ES一起使用:

Talking about arguments to use Mongo instead of/together with ES:

  1. 用户/角色管理.

  1. User/role management.

  • 内置在MongoDB中.可能无法满足您的所有需求,某处可能很笨拙,但是它存在并且在很早以前就已实现.
  • ES中唯一用于安全性的是 shield .但它仅针对用于生产用途的Gold/Platinum订阅提供.

模式

  • ES是无模式的,但是它建立在Lucene之上并用Java编写.该工具的核心思想-索引和搜索文档,以这种方式工作需要索引一致性.在后端,所有文档都应该放在平坦的lucene索引中,这需要对ES应该如何处理嵌套的文档和值以及如何组织索引以保持速度与数据完整性/一致性之间的平衡有一些了解.使用ES要求您始终牢记有关架构的某些知识.即:由于无需预先放置对应的映射就可以对ES进行几乎所有索引,因此ES可以即时猜测"映射,但有时做错了,有时隐式映射是有害的,因为一旦放置,就无法更改/o重新索引整个索引.因此,最好不要将ES视为无模式存储,因为您可以花点时间(这将是痛苦 :)),而应将其视为模式密集型,至少在以下情况下您使用的文档可以切成具体字段.
  • 另一方面,
  • 蒙哥(Mongo)几乎可以从您放入的任何东西中嚼碎且不留碎屑".而且大多数查询都可以正常工作,`直到您记住Mongo将如何从JavaScript角度处理数据.而且由于JS的类型很弱,因此您可以使用真正的无模式工作流(当然,如果需要的话)
  • ES is schemaless, but its built on top of Lucene and written in Java. The core idea of this tool - index and search documents, and working this way requires index consistency. At back end, all documents should be fitted in flat lucene index, which requires some understanding about how ES should deal with your nested documents and values, and how you should organize your indexes to maintain balance between speed and data completeness/consistency. Working with ES requires you to keep some things about schema in mind constantly. I.e: as you can index almost anything to ES without putting corresponding mapping in advance, ES can "guess" mapping on the fly but sometimes do it wrong and sometimes implicit mapping is evil, because once it put, it can't be changed w/o reindexing whole index. So, its better to not treat ES as schemaless store, because you can step on a rake some time (and this will be pain :) ), but rather treat it as schema-intensive, at least when you work with documents, that can be sliced to concrete fields.
  • Mongo, on the other hand, can "chew and leave no crumbs" out of almost anything you put in it. And most your queries will work fine, `til you remember how Mongo will deal with your data from JavaScript perspective. And as JS is weakly typed, you can work with really schemaless workflow (for sure, if you need such)

处理非表格数据.

    ES仅限于处理数据而不将其放入搜索索引.当您需要存储和检索一些额外的数据(与要搜索的数据相比)时,此解决方案就足够了.
  • MongoDB支持 gridFS .这使您能够处理同一接口后面的大量数据.即,您可以从代码角度将二进制数据存储在Mongo中,并在同一界面中检索它们.
  • ES is limited to handle data without putting it to search index. And this solution is good enough, when you need to store and retrieve some extra data (comparing to data you want to search against).
  • MongoDB supports gridFS. This gives you ability to handle large chunks of data behind the same interface. I.e., you can store binary data in Mongo and retrieve it within the same interface, from your code perspective.

这篇关于MongoDB + Elasticsearch还是只有Elasticsearch?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆