《Elasticsearch权威指南》学习笔记

        1.访问数据模式：<HTTP Verb>/<Index>/<Endpoint>/<ID>

        2.Elasticsearch提供近实时的数据操作和搜索功能。默认情况下，从 索引、更新、删除数据到在搜索结果中显示数据，会有少于1s的延迟 (刷新间隔)。

        3.实际上Elasticsearch的数据存储结构决定了其不能像关系数 据库那样进行字段级的更新，所有的更新都是先删除旧文档，再插入 一条新文档，但这个过程对用户来说是透明的。

        4.在Elasticsearch中，删除操作只是把需要删除的文档的ID记 录到了一个列表中，当段合并时才有可能真正把源文档删除。

        5.批量API不会由于其中一个操作失败而失败。

        6.hits.total的准确性由请求参数track_total_hits控制，当设置为true 时，请求将准确跟踪总命中数("relation":"eq")。

        7.Elasticsearch一旦返回请求结果，将不再为该请求维 护任何服务端资源。

        8.如果未指定size，则默认为10。

        9.查询和过滤在功能上是相同的，只不过过滤不计算相似度得分，性能更高。

        10.谨记，集群名称是组建集群的唯一标识。

        11.一旦为network.host提供自定义设置，Elasticsearch就假定正在从开发模式切换到生产模式，并将许多系统启动检查从警告升级到异常。

        12.默认情况下，Elasticsearch告诉JVM使用最小和最大大小为1GB的堆。当转移到生产环境时，需要配置堆大小以确保Elasticsearch具有足够的堆可用，这是很重要的。

        13.Elasticsearch将通过Xms(最小堆大小)和Xmx(最大堆大小)设置分配jvm.options中指定的整个堆栈。

这些设置的值取决于服务器上可用的内存大小。良好的经验法则是:

• 将最小堆大小(Xms)和最大堆大小(Xmx)设置为相等的值。
• Elasticsearch可用的堆越大，可以用于缓存的内存就越大。但请注意，堆太大会触发长时间的垃圾回收以致服务集暂停。
• 将Xmx设置为不超过物理RAM的50%，以确保有足够的物理内存用于内核文件系统缓存。
• 不要将Xmx设置为高于Jvm用于压缩对象指针(compressed oops)的截止值。确切的截止值有所不同，但接近32GB。

• 更好的是，尝试保持在零基压缩OOP的阈值以下。精确的截止值有所不同，但在大多数系统中26GB是安全的，而在某些系统中可能高达30GB 。

        14.默认情况下，Elasticsearch将Jvm内存不足异常上的堆转储到默认数据目录，即data目录。

        15.默认情况下，Elasticsearch假定正在开发模式下工作。如果下述列表任何设置配置不正确，将向日志文件写入警告，但仍能够启动并运行Elasticsearch节点。一旦配置了network.host等网络设置，Elasticsearch就会假定正在用于生产环境，并将上述警告升级为异常，这些异常将阻止Elasticsearch节点启动。这是一个重要的安全措施，可以确保Elasticsearch不会因为服务器配置错误而丢失数据。

        16.大多数操作系统尝试尽可能多地将内存用于文件系统缓存，因此应用程序的数据可能会被移到swap区，这可能导致部分JVM堆，甚至其可执行页面被交换到磁盘。

        17.禁用交换有三种方法。首选选项是完全禁用交换。如果不想这么做，那么还有最小化交换与内存锁定两种方法，采用哪种方法取决于用户的环境。

        18.在开始应用于生产环境之前，必须考虑配置以下参数: · 禁用交换区

• 增加文件描述符的数量
• 确保足够的虚拟内存
• 确保有足够的线程数上限
• JVM DNS缓存设置
• 临时目录不要挂载在noexec下

        19.如果一个Elasticsearch节点不能通过非环回地址与另一台机器形成集群，则认为它处于开发模式;如果它可以通过非环回 地址加入集群，则它处于生产模式。

        20.如果在Linux上，要通过最大线程数检查，必须将系统配置为允许Elasticsearch进程创建至少4096个线程。

        21.JVM提供了两种不同的JVM模式:client模式和server模式。client JVM针对启动时间和内存占用进行了优化，而server JVM针 对最大化性能进行了优化。两种虚拟机之间的性能差异可能很大。 JVM检查确保Elasticsearch必须以server模式启动。

        22.ignore_unavailable控制是否忽略不可用索引，包括不存在的索引或已关闭的索引。 可以设置为true或false。

        23.索引名称支持日期解析，这样能够搜索一个时间范围内或某几段时间内的索引，而不是搜索所有索引再筛选结果或维护别名。

        24.所有REST API都接受一个filter_path参数，该参数可用于减少 Elasticsearch返回的响应信息。

        25.为了获得更多的控制，可以在同一表达式中组合包含和排除过滤 器。在这种情况下，将首先应用排除过滤器，并使用包含过滤器再次 过滤结果。

        26.每当需要指定时间区间，例如对于超时参数时，时间区间必须指定单位，如表示2天的2d。

        27.在查询text或keyword字段时，fuzziness被解释为编辑距离，也就 是一个字符串需要更改的字符数，以使其与另一个字符串相同。

        28.Elasticsearch的数据复制模型是基于主备(primary-backup)模型的。我们称主分片为primary，称副本为replica。另外约定，集群中有若干个节点，其中只有一个是活跃的主节点，它负载管理集群，我们把它称为master。

        29.基本写模型：

primary遵循以下基本流程:

• 验证传入操作，如果结构无效则拒绝该操作。
• 在本地执行操作，即索引或删除相关文档。这还将验证字段的内容，并在需要时拒绝。
• 将操作转发到当前同步副本组中的每个replica，如果有多个replica，这是并行完成的。
• 一旦所有replica都成功地执行了操作并对primary作出了响应， primary就确认完成了请求并返回给用户。

        30.基本读模型：

• 将读取请求解析到相关分片组。注意，由于大多数搜索将被发送到一个或多个索引，所以它们通常需要从多个分片中读取，每个分片表示数据的不同子集。
• 从同步副本组中选择一个相关shard的活动分片。这可以是 primary，也可以是replica。默认情况下，Elasticsearch只需在分片之间循环搜索。
• 向所选分片发送读取请求。
• 将结果整合。请注意，在按ID查找的情况下，只有一个分片是相关的，可以跳过此步骤。

        31.由于primary首先完成写操作，然后复制分发请求到其他replica，所以并发读取可能在确认之前就已经看到了更改。

        32.默认情况下，数据存放到哪个分片，通过使用文档ID值的哈希值来控制。对于更显式的控制，可以传递哈希函数的种子值。

        33.为了兼顾系统写入的效率和可靠性，可以将索引操作配置为在继续操作之前等待一定数量的活动分片。如果所需数量的活动分片不可 用，则写入操作必须等待并重试，直到所需分片已启动或发生超时。 默认情况下，写入操作仅在继续之前等待primary完成。

        34.GET操作允许指定一组存储字段(store属性值为true)，这些字段将通过传递stored_fields参数返回。如果未存储请求的字段，则将忽略它们。

        35.可以使用/{index}/_source/{id}仅获取文档的source字段，而不返回 任何其他内容。

        36.可以将refresh参数设置为true，以便在GET操作之前刷新相关的分片并使其可见。将其设置为true应慎重考虑，因为这可能导致系统负载过重，并减慢索引速度。

        37.delete_by_query操作在启动时会获取索引的一个快照，并使用内部版本控制删除找到的内容。这意味着，如果文档在获取快照的时间和处理删除请求的时间之间发生更改，则会出现版本冲突。如果不想因版本冲突而让它们中止，那么在URL上设置conflicts=proceed或在请求正文中设置conflicts:proceed。

        38.如果搜索或批量请求被拒绝， _delete_by_query按照默认策略重试被拒绝的请求(最多10次，指数下降)。达到最大重试次数限制会导致_delete_by_query中止，并在响应的failures中返回所有失败信息。已执行的删除操作仍然保持不变。

        39.可以使用任务API(_tasks)获取任何正在运行的_delete_by_query 的状态。

        40.查询更新API(_update_by_query)的功能是在不更改源的情况下对索引中的每个文档执行更新。https://www.cnblogs.com/hahaha111122222/p/12719660.html

        41.与_update_by_query类似，_reindex支持修改文档的脚本。与_update_by_query不同的是，脚本允许修改文档的元数据。