Luc*_*uke 18 ruby java full-text-search elasticsearch
Elasticsearch中的索引是什么?一个应用程序有多个索引还是只有一个?假设你为一些汽车制造商建立了一个系统.它涉及人,汽车,备件等.你有一个名为制造商的索引,或者你有一个人的索引,一个汽车索引和三个备件?有人能解释一下吗
Zac*_*ach 54
好问题,答案比人们预期的要微不足道.您可以将索引用于多种不同目的.
最简单,最熟悉的布局克隆了您对关系数据库的期望.你可以(非常粗略地)想到像数据库这样的索引.
ElasticSearch集群可以包含多个Indices(数据库),而这些数据库又包含多个Types(表).这些类型包含多个Documents(行),每个文档都有Properties(列).
因此,在您的汽车制造方案中,您可能有一个SubaruFactory索引.在此索引中,您有三种不同的类型:
PeopleCarsSpare_Parts然后每种类型都包含与该类型相对应的文档(例如,Subaru Imprezza doc存在于该Cars类型内.该文档包含有关该特定汽车的所有详细信息).
搜索和查询采用以下格式:http:// localhost:9200/[index]/[type]/[operation]
因此,为了检索Subaru文档,我可以这样做:
$ curl -XGET localhost:9200/SubaruFactory/Cars/SubaruImprezza
Run Code Online (Sandbox Code Playgroud)
.
现在,实际情况是Indices/Types比我们在RDBM中习惯的数据库/表抽象灵活得多.它们可以被视为方便的数据组织机制,具有额外的性能优势,具体取决于您设置数据的方式.
为了演示完全不同的方法,很多人使用ElasticSearch进行日志记录.标准格式是为每天分配新索引.您的索引列表可能如下所示:
ElasticSearch允许您同时查询多个索引,因此这不是一个问题:
$ curl -XGET localhost:9200/logs-2013-02-22,logs-2013-02-21/Errors/_search=q:"Error Message"
Run Code Online (Sandbox Code Playgroud)
它会同时搜索过去两天的日志.由于日志的性质,这种格式具有优势 - 大多数日志从未被查看过,并且它们以线性时间流组织.为每个日志创建索引更符合逻辑,并提供更好的搜索性能.
.
另一种截然不同的方法是为每个用户创建一个索引.想象一下,你有一些社交网站,每个用户都有大量的随机数据.您可以为每个用户创建单个索引.您的结构可能如下所示:
请注意如何以传统的RDBM方式轻松完成此设置(例如"用户"索引,其中有爱好/朋友/图片作为类型).然后,所有用户都将被抛入一个巨大的索引中.
相反,出于数据组织和性能原因,有时将数据拆分是有意义的.在这种情况下,我们假设每个用户都有大量数据,我们希望它们是分开的.ElasticSearch让我们为每个用户创建索引没有问题.
Shi*_*dam 11
@Zach的答案对elasticsearch 5.X及以下版本有效。由于Elasticsearch 6.X Type已被弃用,并将在7.X中完全删除。引用elasticsearch文档:
最初,我们谈到“索引”类似于SQL数据库中的“数据库”,而“类型”等同于“表”。这是一个不好的类比,导致了错误的假设。
进一步说明,来自两个不同表的SQL中具有相同名称的两个列可以彼此独立。但是在弹性搜索索引中这是不可能的,因为它们由相同的Lucene字段支持。因此,elasticsearch中的“索引”与SQL中的“数据库”并不完全相同。如果索引中有任何相同的字段,则它们最终将导致字段类型冲突。为了避免这种情况,elasticsearch文档建议按文档类型存储索引。
请参阅:删除映射类型
| 归档时间: |
|
| 查看次数: |
8548 次 |
| 最近记录: |