python查询ES

注意：elasticsearch 的版本不能太高，建议安装7130

pip install elasticsearch ==7130

from elasticsearch import Elasticsearch

import logging

logger = logginggetLogger("inquiry_es")

loggingbasicConfig(filename="logs/loggingtxt",

                    level=loggingINFO,

                    format='{"time":"%(asctime)s","script":"%(name)s","thread":"%(thread)d",'

                          '"threadName":"%(threadName)s","loglevel":"%(levelname)s"} - %(message)s')

class search_es:

    def __init__(self,host,port="9200",user=None,passwd=None):

        selfhost = host

        selfuser = user

        selfpasswd = passwd

        selfport = port

        selfes = Elasticsearch([f"{selfhost}:{selfport}"]) if user is None else \

            Elasticsearch([f"{selfhost}:{selfport}"],>

（1）_version元数据

（2）图解内部如何基于_version进行乐观锁并发控制

es提供了一个feature，就是说，你可以不用它提供的内部_version版本号来进行并发控制， 可以基于你自己维护的一个版本号来进行并发控制 。举个列子，加入你的数据在mysql里也有一份，然后你的应用系统本身就维护了一个版本号，无论是什么自己生成的，程序控制的。这个时候，你进行乐观锁并发控制的时候，可能并不是想要用es内部的_version来进行控制，而是用你自己维护的那个version来进行控制。

如果您输入的ES查询语句正确但是没有返回值，可能存在以下几种原因：

1 数据库中不存在满足查询条件的文档：请检查您输入的查询条件是否正确，并确认数据库中是否存在满足查询条件的文档。您可以使用Kibana或其他ES管理工具进行数据检索，也可以手动查找数据存储位置，以确定是否存在符合条件的文档。

2 查询语句错误：虽然您认为查询语句正确，但仍有可能存在语法错误或逻辑错误等问题导致无法返回结果，请仔细检查查询语句，特别是查询条件和聚合条件等。

3 ES集群状态异常：如果ES集群出现了异常状态，如节点宕机、分片故障等情况，可能会导致查询请求无法正常处理，从而无法获取查询结果。请检查ES集群状态是否正常。

4 网络连接异常：如果网络连接不稳定或中断，也可能导致查询请求无法正常发送或接收，从而无法返回结果。请检查网络连接是否正常并重试查询 *** 作。

如果以上方法无法解决问题，请尝试通过更多调试方式（如日志分析、性能监控等）来排除问题，或联系相关技术支持人员寻求帮助。

对于solr来说是无法做两个collection之间的关联的，es是否可以做到类似于表的join关联那，这就是本篇需要研究的内容，

主要参考内容是官方文档。

先说下结论，如果不做特殊处理，es是无法完成类似与表Join的关联查询的。

官网里面有几种支持关联查询的办法：

可以看下map信息如下：

实际在es内，已经将user下面的id和name进行了扁平化处理，可以通过如下的方式查询：

优点：查询速度非常快，缺点是存在数据的冗余。

在ES中，对单个文档的增删改都是原子 *** 作，有时候为了方便我们将实体和它相关的明细是放在一个文档中存储的。比如论坛发的帖子和它的回复信息。

其实和冗余对象有点类似，但是如果只是做查询会发现有问题，因为es扁平处理之后：

tilte、body、tags被称为父文档或根文档。

这样数组内之间是没有顺序关系的，这就导致了后面的查询仍然可以查到数据，嵌套对象是为了解决这个问题的，先看下普通的对象：

嵌套对象,上面的例子是没有定义map的情况直接发送数据，comments被定义为object，失去了数组内的顺序关系，如果先定义了nested对象，则如下：

再次发送相同的数据：

再次发起查询：

为什么查不到，是因为nested对象有自己特定的语法如下：

score_mode：表示嵌套文档的最高得分纳入到根文档的计算之中。

嵌套模型的缺点如下：

当对嵌套文档做增加、修改或者删除时，整个文档都要重新被索引。嵌套文档越多，这带来的成本就越大。

查询结果返回的是整个文档，而不仅仅是匹配的嵌套文档。尽管目前有计划支持只返回根文档中最佳匹配的嵌套文档，但目前还不支持。

父子对象是最类似与表join的对象，父子关系的对象分别位于不同的文档中，做到了很好的隔离。

有以下优点：

1）更新父文档或子文档时候，另一方不受影响。

2）创建和删除子文档，父文档不受到影响。

3）子文档可以作为独立的结果单独返回。

缺点是：

1）父文档和子文档必须存在同一个shard中。

2）貌似只能是同一个index的两个type（对于es6x版本只能支持一个type，如何处理，目前还未看到）

原理：

Elasticsearch 维护了一个父文档和子文档的映射关系，得益于这个映射，父-子文档关联查询 *** 作非常快。

但是这个映射也对父-子文档关系有个限制条件：父文档和其所有子文档，都必须要存储在同一个分片中。

父-子文档ID映射存储在 Doc Values 中。当映射完全在内存中时， Doc Values 提供对映射的快速处理能力，

另一方面当映射非常大时，可以通过溢出到磁盘提供足够的扩展能力

如何建立父子映射：

建立父-子文档映射关系时只需要指定某一个文档 type 是另一个文档 type 的父亲。 该关系可以在如下两个时间点设置：

1）创建索引时；

2）在子文档 type 创建之前更新父文档的 mapping。

举例来说，对于公司和员工之间存在着类似的关系，即可以将公司信息看成员工信息的父文档。

如下：

父子文档的创建

1）对于父对象来说，它是不知道有多少个子对象的，所以按照一般的对象创建方法即可。

2）子对象创建方法：

父文档 ID 有两个作用：创建了父文档和子文档之间的关系，并且保证了父文档和子文档都在同一个分片上。

这里面的父ID london 会作为路由的依据，这样子对象就会路由到父文档同一个shard上。

在执行单文档的请求时需要指定父文档的 ID，单文档请求包括：通过 GET 请求获取一个子文档；创建、更新或删除一个子文档。

而执行搜索请求时是不需要指定父文档的ID，这是因为搜索请求是向一个索引中的所有分片发起请求，而单文档的 *** 作是只会向存储该文档的分片发送请求。

因此，如果 *** 作单个子文档时不指定父文档的 ID，那么很有可能会把请求发送到错误的分片上。

父文档的 ID 应该在 bulk API 中指定

通过子文档查询父文档

查询80后所在的公司信息：

查询至少两个员工的公司：

通过父文档查询子文档

每个子文档都保存了父文档的ID。

（1）index包含多个shard

（2） 每个shard都是一个最小工作单元，承载部分数据 ，lucene实例，完整的建立索引和处理请求的能力

（3）增减节点时，shard会自动在nodes中负载均衡

（4）primary shard和replica shard，每个document肯定只存在于某一个primary shard以及其对应的replica shard中，不可能存在于多个primary shard

（5）replica shard是primary shard的副本， 负责容错，以及承担 读请求 负载

（6） primary shard的数量在创建索引的时候就固定了，replica shard的数量可以随时修改

（7）primary shard的默认数量是5，replica默认是1，默认有10个shard，5个primary shard，5个replica shard

（8） primary shard不能和自己的replica shard放在同一个节点上 （否则节点宕机，primary shard和副本都丢失， 起不到容错的作用 ），但是可以和其他primary shard的replica shard放在同一个节点上

（9 ） es里写只会往primary里写，读的话随便primary或者replicat都可以

es集群多个节点，会自动选举一个节点为master节点，这个master节点其实就是干一些管理的工作的，比如 维护索引元数据，负责切换primary shard和replica shard身份之类的。

要是master节点宕机了，那么会重新选举一个节点为master节点。

如果是非master节点宕机了，那么会由master节点，让那个宕机节点上的primary shard的身份转移到其他机器上的replica shard。

等到我们修复了那个宕机机器，重启了之后，master节点会控制将缺失的replica shard 身份分配过去，同步后续修改的数据之类，让集群恢复正常。

适当的提升分片数量可以提升建立索引的速度；

一般情况下：一个索引库建立5-20个分片是最合适的；

注意：如果分片过少或者过多，都会降低检索的速度

分片数过多会导致：

分片数太少导致：

建议：

是将单个分片存储存储索引数据的大小控制在20G左右；绝对不要超过50G ， 否则性能很差

最终分片数量 = 数据总量/20G

以上就是关于python查询ES全部的内容，包括:python查询ES、ES 索引解析(倒排索引 | 正排索引)、ES并发冲突问题与悲观锁与乐观锁并发控制等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！