很好的问题,答案比人们期望的要细腻得多。您可以将索引用于几种不同的目的。
关系指标最简单,最熟悉的布局将克隆您从关系数据库中获得的期望。您可以(非常粗略地)想到像数据库这样的索引。
- MySQL =>数据库=>表=>行/列
- ElasticSearch =>索引=>类型=>具有属性的文档
ElasticSearch集群可以包含多个
Indices(数据库),而数据库又包含多个
Types(表)。这些类型包含多个
documents(行),每个文档都有
Properties(列)。
因此,在您的汽车制造方案中,您可能会有一个
SubaruFactory索引。在此索引内,您有三种不同的类型:
People
Cars
Spare_Parts
然后,每种类型都包含与该类型相对应的文档(例如,Subaru Imprezza文档位于该
Cars类型内部。此文档包含有关该特定汽车的所有详细信息)。
搜索和查询采用以下格式:http:// localhost:9200 / [index] / [type] /
[operation]
因此,要检索Subaru文档,我可以这样做:
$ curl -XGET localhost:9200/SubaruFactory/Cars/SubaruImprezza
。
记录指标现在,现实是索引/类型比我们在RDBM中使用的数据库/表抽象要灵活得多。可以将它们视为方便的数据组织机制,并根据设置数据的方式获得更多的性能优势。
为了演示一种截然不同的方法,许多人使用ElasticSearch进行日志记录。一种标准格式是为每天分配一个新索引。您的索引列表可能如下所示:
- 日志-2013-02-22
- 日志-2013-02-21
- 日志-2013-02-20
ElasticSearch允许您同时查询多个索引,因此这不是问题:
$ curl -XGET localhost:9200/logs-2013-02-22,logs-2013-02-21/Errors/_search=q:"Error Message"
它将同时搜索最近两天的日志。由于日志的性质,这种格式具有优势-
大多数日志从不查看,并且它们以线性时间流进行组织。为每个日志创建索引更合乎逻辑,并且可以提供更好的搜索性能。
。
用户指标另一种截然不同的方法是为每个用户创建索引。假设您有一些社交网站,每个用户都有大量随机数据。您可以为每个用户创建一个索引。您的结构可能类似于:
- 扎克指数
- 爱好类型
- 好友类型
- 图片类型
- 弗雷德指数
- 爱好类型
- 好友类型
- 图片类型
请注意,如何以传统的RDBM方式轻松完成此设置(例如,将“爱好” /“朋友”
/“图片”作为类型的“用户”索引)。然后,所有用户都将被扔进一个单一的巨型索引中。
取而代之的是,有时出于数据组织和性能的原因将数据分开是有意义的。在这种情况下,我们假设每个用户都有 很多
数据,并且我们希望他们分开。ElasticSearch可以让我们为每个用户创建索引没有问题。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)