elasticsearch阅读官方文档笔记
2017-08-01 00:00
148 查看
技术上来说,一个主分片最大能够存储 Integer.MAX_VALUE - 128 个文档,但是实际最大值还需要参考你的使用场景:包括你使用的硬件, 文档的大小和复杂程度,索引和查询文档的方式以及你期望的响应时长。
在 Elasticsearch 中, 每个字段的所有数据 都是 默认被索引的 。 即每个字段都有为了快速检索设置的专用倒排索引。而且,不像其他多数的数据库,它能在 相同的查询中 使用所有这些倒排索引,并以惊人的速度返回结果。
所有需要我们做的就是选择一个索引名,这个名字必须小写,不能以下划线开头,不能包含逗号。
注解:index不能是大写,否则无法将数据加入到ES中。
一个type 命名可以是大写或者小写,但是不能以下划线或者句号开头,不应该包含逗号, 并且长度限制为256个字符.
自定义type和id,输入的请求应该是put开头:
如果使用自动生成id,输入的请求是post开头:
如果你的数据没有自然的 ID, Elasticsearch 可以帮我们自动生成 ID 。 请求的结构调整为: 不再使用
put是有幂等性,而post是非幂等性,换句话说,多次执行put,返回的结果一定相同。
在 Elasticsearch 中文档是 不可改变 的,不能修改它们。 相反,如果想要更新现有的文档,需要 重建索引或者进行替换;
从旧文档构建 JSON
更改该 JSON
删除旧文档
索引一个新文档
update的作用是仅仅将这些流程合在了一起。
在分布式系统中深度分页
理解为什么深度分页是有问题的,我们可以假设在一个有 5 个主分片的索引中搜索。 当我们请求结果的第一页(结果从 1 到 10 ),每一个分片产生前 10 的结果,并且返回给 协调节点 ,协调节点对 50 个结果排序得到全部结果的前 10 个。
现在假设我们请求第 1000 页--结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。 然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。
可以看到,在分布式系统中,对结果排序的成本随分页的深度成指数上升。这就是 web 搜索引擎对任何查询都不要返回超过 1000 个结果的原因。
为了能够将时间域视为时间,数字域视为数字,字符串域视为全文或精确值字符串, Elasticsearch 需要知道每个域中数据的类型。这个信息包含在映射中。
https://elasticsearch.cn/book/elasticsearch_definitive_guide_2.x/mapping-intro.html
该链接很准确的解释了mapping。mapping一旦定义,就无法改变。
考虑包含 内部对象的数组是如何被索引的。 假设我们有个
这个文档会像我们之前描述的那样被扁平化处理,结果如下所示:
但是我们不能得到一个准确的答案:“是否有一个26岁 名字叫 Alex Jones 的追随者?”
相关内部对象被称为 nested 对象,可以回答上面的查询
在 Elasticsearch 中, 每个字段的所有数据 都是 默认被索引的 。 即每个字段都有为了快速检索设置的专用倒排索引。而且,不像其他多数的数据库,它能在 相同的查询中 使用所有这些倒排索引,并以惊人的速度返回结果。
所有需要我们做的就是选择一个索引名,这个名字必须小写,不能以下划线开头,不能包含逗号。
注解:index不能是大写,否则无法将数据加入到ES中。
一个type 命名可以是大写或者小写,但是不能以下划线或者句号开头,不应该包含逗号, 并且长度限制为256个字符.
自定义type和id,输入的请求应该是put开头:
PUT /website/blog/123 { "title": "My first blog entry", "text": "Just trying this out...", "date": "2014/01/01" }
如果使用自动生成id,输入的请求是post开头:
POST /website/blog/ { "title": "My second blog entry", "text": "Still trying this out...", "date": "2014/01/01" }
如果你的数据没有自然的 ID, Elasticsearch 可以帮我们自动生成 ID 。 请求的结构调整为: 不再使用
PUT谓词(“使用这个 URL 存储这个文档”), 而是使用
POST谓词(“存储文档在这个 URL 命名空间下”)。
put是有幂等性,而post是非幂等性,换句话说,多次执行put,返回的结果一定相同。
在 Elasticsearch 中文档是 不可改变 的,不能修改它们。 相反,如果想要更新现有的文档,需要 重建索引或者进行替换;
updateAPI, 这个 API 可以用于 partial updates to a document 。 虽然它似乎对文档直接进行了修改,但实际上 Elasticsearch 执行以下过程:
从旧文档构建 JSON
更改该 JSON
删除旧文档
索引一个新文档
update的作用是仅仅将这些流程合在了一起。
在分布式系统中深度分页
理解为什么深度分页是有问题的,我们可以假设在一个有 5 个主分片的索引中搜索。 当我们请求结果的第一页(结果从 1 到 10 ),每一个分片产生前 10 的结果,并且返回给 协调节点 ,协调节点对 50 个结果排序得到全部结果的前 10 个。
现在假设我们请求第 1000 页--结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。 然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。
可以看到,在分布式系统中,对结果排序的成本随分页的深度成指数上升。这就是 web 搜索引擎对任何查询都不要返回超过 1000 个结果的原因。
为了能够将时间域视为时间,数字域视为数字,字符串域视为全文或精确值字符串, Elasticsearch 需要知道每个域中数据的类型。这个信息包含在映射中。
https://elasticsearch.cn/book/elasticsearch_definitive_guide_2.x/mapping-intro.html
该链接很准确的解释了mapping。mapping一旦定义,就无法改变。
考虑包含 内部对象的数组是如何被索引的。 假设我们有个
followers数组:
{ "followers": [ { "age": 35, "name": "Mary White"}, { "age": 26, "name": "Alex Jones"}, { "age": 19, "name": "Lisa Smith"} ] }
这个文档会像我们之前描述的那样被扁平化处理,结果如下所示:
{ "followers.age": [19, 26, 35], "followers.name": [alex, jones, lisa, smith, mary, white] }
{age: 35}和
{name: Mary White}之间的相关性已经丢失了,因为每个多值域只是一包无序的值,而不是有序数组。这足以让我们问,“有一个26岁的追随者?”
但是我们不能得到一个准确的答案:“是否有一个26岁 名字叫 Alex Jones 的追随者?”
相关内部对象被称为 nested 对象,可以回答上面的查询
相关文章推荐
- elasticsearch阅读官方文档笔记2
- mysql官方文档阅读笔记 MVCC
- Solr入门之官方文档6.0阅读笔记系列(五) 第二部分结束
- Solr入门之官方文档6.0阅读笔记系列(六) 第三部分开始
- 性能优化官方文档阅读笔记
- maven官方文档阅读笔记
- Solr入门之官方文档6.0阅读笔记系列(四)
- mongo官方文档阅读笔记---mongo的限制
- spark官方文档阅读笔记1
- mysql官方文档阅读笔记(二)整体目录翻译
- vue.js从入门到放弃2--官方文档阅读笔记
- Solr入门之官方文档6.0阅读笔记系列(十)
- Solr入门之官方文档6.0阅读笔记系列(一)
- Yii2 官方文档阅读笔记
- jsPlumb.jsAPI阅读笔记(官方文档翻译)
- ES权威指南[官方文档学习笔记]-4 running elasticsearch
- Quagga官方说明文档阅读笔记
- mysql官方文档阅读笔记(三)General Information一般信息模块浏览
- Spring Boot Admin官方文档阅读笔记
- RabbitMQ官方文档使用指南阅读笔记