last

Elasticsearch是什么?Elasticsearch是位于ElasticStack核心的分布式搜索和分析引擎。Logstash和Beats有助于收集、聚合和丰富您的数据并将其存储在Elasticsearch中。Kibana使您能够以交互方式探索、可视化和分享对数据的见解，并管理。Elasticsearch是一个分布式文档存储。Elasticsearch存储的是序列化为JSON文档的复杂数据结构，而不是以列行数据的形式存储信息。当集群中有多个Elasticsearch节点时，存储的文档分布在整个集群中，可以立即从任何节点访问。Elasticsearch是由ShayBanon发起的一个开源搜索服务器项目，2010年2月发布。迄今，该项目已发展成为搜索和数据分析解决方案领域的主要一员，广泛应用于声名卓著或鲜为人知的搜索应用程序。Elasticsearch是一个高度可扩展的开源全文搜索和分析引擎。它可以在很短的时间内存储，搜索和分析大量的数据。它通常作为具有复杂搜索场景情况下的核心发动机。搜索引擎，不支持join表等操作。主要用于全文检索。不适合做数据库。如何选择合适的数据库解决方案？1、如果有强大的技术团队，关系型和非关系型数据库都可选择。一般来讲，非关系型数据库需要更多管理维护的时间。2、如果你要储存会话信息，用户配置信息，购物车数据，建议使用NoSQL数据库；不过90%的企业或个人，首选数据库都是MySQL数据库。3、(一)、Access(二)SQLServer(三)MySQL，Access是一种桌面数据库，只适合数据量少的应用，在处理少量数据和单机访问的数据库时是很好的，效率也很高。但是它的同时访问客户端不能多于4个。4、虽然把上面的架构全部组合在一起可以形成一个强大的高可用，高负载的数据库系统，但是架构选择合适才是最重要的。混合架构虽然能够解决所有的场景的问题，但是也会面临更多的挑战，你以为的完美架构，背后其实有着更多的坑。5、例如，如果你需要的是数据分析仓库，关系数据库可能不是一个适合的选择；如果你处理事务的应用要求严格的数据完整性和一致性，就不要考虑NoSQL了。不要重新发明轮子在过去的数十年，开源数据库技术迅速发展壮大。6、本文首先讨论了基于第三范式的数据库表的基本设计，着重论述了建立主键和索引的策略和方案，然后从数据库表的扩展设计和库表对象的放置等角度概述了数据库管理系统的优化方案。ElasticSearch倒排索引及其原理1、倒排索引采用ImmutableDesign，一旦生成，不可更改。Segment写入磁盘的过程相对耗时，所以借助文件系统缓存，Refresh时，先将Segment写入文件缓存中，以开放查询。2、之前我们已经了解过，Elasticsearch是一个基于Lucene实现的分布式全文检索引擎，其实Elasticsearch倒排索引就是Lucene的倒排索引。3、所谓的倒排索引，就是把你的数据内容先分词，每句话分成一个一个的关键词，然后记录好每一个关键词对应出现在了哪些id标识的数据。4、可以将对es的操作记录下来，来确保当出现故障的时候，已经落地到磁盘的数据不会丢失，并在重启的时候可以从操作记录中将数据恢复过来。5、Elasticsearch中使用一种称为倒排索引的结构，适用于快速的全文搜索。一个倒排索引由文档中所有不能重复词的列表构成，对于其中每个词，有一个包含它的文档列表。elasticsearch-倒排索引原理1、倒排索引采用ImmutableDesign，一旦生成，不可更改。Segment写入磁盘的过程相对耗时，所以借助文件系统缓存，Refresh时，先将Segment写入文件缓存中，以开放查询。2、Elasticsearch中使用一种称为倒排索引的结构，适用于快速的全文搜索。一个倒排索引由文档中所有不能重复词的列表构成，对于其中每个词，有一个包含它的文档列表。3、elasticsearch提供了translog来记录这些操作，结合oscachedsegments数据定时落盘来实现数据可靠性保证（flush）。文档被添加到buffer同时追加到translog：进行refresh操作，清空buffer，文档可被搜索但尚未flush到磁盘。4、如果Elasticsearch密钥库受密码保护，则必须先输入密钥库密码，然后才能为内置用户设置密码。为弹性用户设置密码后，引导密码不再有效，无法使用该命令。在某些情况下，分片副本的Lucene索引或事务日志可能会损坏。5、Elasticsearch的查询原理是将查询的关键词与倒排索引中的词条进行匹配，查询的关键词与倒排索引中的词条必须完全相同视为匹配，否则不匹配。这意味着在插入文档时是否进行分析和查询时是否进行分析将产生非常不同的结果。6、财务平台亿级数据量毫秒级查询优化之elasticsearch原理解析_wang123459的博客-CSDN博客_elasticsearch查询优化mysql底层B-tree支持矮胖，高胖的时候就很难受，说白了就是数据量多会增加IO操作。ES底层倒排索引。Elasticsearch一般情况下如果es服务正常启动，可以通过接口的方式获取elasticsearch版本信息：curlhttp：//10.1：9200上述命令可以得到elasticsearch的服务状态和其他信息包括版本号。Elasticsearch是位于ElasticStack核心的分布式搜索和分析引擎。Logstash和Beats有助于收集、聚合和丰富您的数据并将其存储在Elasticsearch中。ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTfulweb接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。Elasticsearch架构简单介绍如下。索引索引（index）是Elasticsearch对逻辑数据的逻辑存储，所以它可以分为更小的部分。你可以把索引看成关系型数据库的表。然而，索引的结构是为快速有效的全文索引准备的，特别是它不存储原始值。如何用elasticsearch5.2实现全文索引1、安装ik分词器到elasticsearch很简单，它有个插件目录analysis-ik，和一个配置目录ik，分别拷贝到plugins和conf目录就可以了。2、ES使用倒序索引来加速全文索引。一个倒序索引由两部分组成：如果我们想要搜索quickbrown，我们仅仅只需要找每一个term出现的文档即可。如下图：每一个文档都匹配到了，但是第一个比第二个要匹配的多。3、每次将文本类型数据插入Elasticsearch索引时，都会对其进行分析，然后存储在反向索引中。根据分析器的配置方式，这会影响您的搜索功能，因为分析器也适用于全文搜索。

近一年内对公司的 ELK 日志系统做过性能优化，也对 SkyWalking 使用的 ES 存储进行过性能优化，在此做一些总结。本篇主要是讲 ES 在 ELK 架构中作为日志存储时的性能优化方案。 随着接入ELK的应用越来越多， 每日新增索引约 230 个，新增 document 约 3000万到 5000万 。 每日上午和下午是日志上传高峰期，在 Kibana 上查看日志，发现问题： (1) 日志会有 5-40 分钟的延迟 (2) 有很多日志丢失，无法查到 数据先是存放在 ES 的内存 buffer，然后执行 refresh 操作写入到操作系统的内存缓存 os cache，此后数据就可以被搜索到。 所以，日志延迟可能是我们的数据积压在 buffer 中没有进入 os cache 。 查看日志发现很多 write 拒绝执行的情况 从日志中可以看出 ES 的 write 线程池已经满负荷，执行任务的线程已经达到最大16个线程，而200容量的队列也已经放不下新的task。 查看线程池的情况也可以看出 write 线程池有很多写入的任务 所以我们需要优化 ES 的 write 的性能。 ES 的优化分为很多方面，我们要根据使用场景考虑对 ES 的要求。 根据个人实践经验，列举三种不同场景下的特点 ： 这三类场景的特点如下： 关于实时性 可以从三方面进行优化：JVM性能调优、ES性能调优、控制数据来源 可以从三方面进行优化：JVM 性能调优、ES 性能调优、控制数据来源 第一步是 JVM 调优。 因为 ES 是依赖于 JVM 运行，没有合理的设置 JVM 参数，将浪费资源，甚至导致 ES 很容易 OOM 而崩溃。 (1) 查看 GC 日志 (2) 使用 jstat 看下每秒的 GC 情况 用下面几种方式都可查看新、老年代内存大小 (1) 使用 jstat -gc pid 查看 Eden 区、老年代空间大小 (2) 使用 jmap -heap pid 查看 Eden 区、老年代空间大小 (3) 查看 GC 日志中的 GC 明细 上面的几种方式都查询出，新生代总内存约1081M，即1G左右；老年代总内存为19864000K，约19G。新、老比例约1:19，出乎意料。 这真是一个容易踩坑的地方。 如果没有显示设置新生代大小，JVM 在使用 CMS 收集器时会自动调参，新生代的大小在没有设置的情况下是通过计算得出的，其大小可能与 NewRatio 的默认配置没什么关系而与 ParallelGCThreads 的配置有一定的关系。 所以： 新生代大小有不确定性，最好配置 JVM 参数 -XX:NewSize、-XX:MaxNewSize 或者 -xmn ，免得遇到一些奇怪的 GC，让人措手不及。 新生代过小，老年代过大的影响 32G 的内存，分配 20G 给堆内存是不妥当的，所以调整为总内存的50%，即16G。 修改 elasticsearch 的 jvm.options 文件 设置要求: 因为指定新生代空间大小，导致 JVM 自动调参只分配了 1G 内存给新生代。 修改 elasticsearch 的 jvm.options 文件，加上 老年代则自动分配 16G-8G=8G 内存，新生代老年代的比例为 1:1。修改后每次 Young GC 频率更低，且每次 GC 后只有少数数据会进入老年代。 ES默认使用的垃圾回收器是：老年代（CMS）+ 新生代（ParNew）。如果是JDK1.9，ES 默认使用G1垃圾回收器。 因为使用的是 JDK1.8，所以并未切换垃圾回收器。后续如果再有性能问题再切换G1垃圾回收器，测试是否有更好的性能。 优化前 每秒打印一次 GC 数据。可以看出，年轻代增长速度很快，几秒钟年轻代就满了，导致 Young GC 触发很频繁，几秒钟就会触发一次。而每次 Young GC 很大可能有存活对象进入老年代，而且，存活对象多的时候(看上图中第一个红框中的old gc数据)，有(51.44-51.08)/100 * 19000M = 约68M。每次进入老年代的对象较多，加上频繁的 Young GC，会导致新老年代的分代模式失去了作用，相当于老年代取代了新生代来存放近期内生成的对象。当老年代满了，触发 Full GC，存活的对象也会很多，因为这些对象很可能还是近期加入的，还存活着，所以一次 Full GC 回收对象不多。而这会恶性循环，老年代很快又满了，又 Full GC，又残留一大部分存活的，又很容易满了，所以导致一直频繁 Full GC。 优化后 每秒打印一次 GC 数据。可以看出，新生代增长速度慢了许多，至少要60秒才会满，如上图红框中数据，进入老年代的对象约(15.68-15.60)/100 * 10000 = 8M，非常的少。所以要很久才会触发一次 Full GC 。而且等到 Full GC 时，老年代里很多对象都是存活了很久的，一般都是不会被引用，所以很大一部分会被回收掉，留一个比较干净的老年代空间，可以继续放很多对象。 ES 启动后，运行14个小时 优化前 Young GC 每次的时间是不长的，从上面监控数据中可以看出每次GC时长 1467.995/27276 约等于 0.05秒。那一秒钟有多少时间实在处理Young GC ? 计算公式：1467秒/ (60秒×60分 14小时）= 约0.028秒，也就是100秒中就有2.8秒在Young GC，也就是有2.8S的停顿，这对性能还是有很大消耗的。同时也可以算出多久一次Young GC， 方程是： 60秒×60分*14小时/ 27276次 = 1次/X秒，计算得出X = 0.54，也就是0.54秒就会有一次Young GC，可见 Young GC 频率非常频繁。 优化后 Young GC 次数只有修改前的十分之一，Young GC 时间也是约八分之一。Full GC 的次数也是只有原来的八分之一，GC 时间大约是四分之一。 GC 对系统的影响大大降低，性能已经得到很大的提升。 上面已经分析过ES作为日志存储时的特性是：高并发写、读少、接受30秒内的延时、可容忍部分日志数据丢失。 下面我们针对这些特性对ES进行调优。 本人整理了一下数据写入的底层原理 refresh ES 接收数据请求时先存入 ES 的内存中，默认每隔一秒会从内存 buffer 中将数据写入操作系统缓存 os cache，这个过程叫做 refresh； 到了 os cache 数据就能被搜索到（所以我们才说 ES 是近实时的，因为1s 的延迟后执行 refresh 便可让数据被搜索到） fsync translog 会每隔5秒或者在一个变更请求完成之后执行一次 fsync 操作，将 translog 从缓存刷入磁盘，这个操作比较耗时，如果对数据一致性要求不是跟高时建议将索引改为异步，如果节点宕机时会有5秒数据丢失; flush ES 默认每隔30分钟会将 os cache 中的数据刷入磁盘同时清空 translog 日志文件，这个过程叫做 flush。 merge ES 的一个 index 由多个 shard 组成，而一个 shard 其实就是一个 Lucene 的 index ，它又由多个 segment 组成，且 Lucene 会不断地把一些小的 segment 合并成一个大的 segment ，这个过程被称为 段merge 。执行索引操作时， ES会先生成小的segment ，ES 有离线的逻辑对小的 segment 进行合并，优化查询性能。但是合并过程中会消耗较多磁盘 IO，会影响查询性能。 为了保证不丢失数据，就要保护 translog 文件的安全: 该方式提高数据安全性的同时， 降低了一点性能. ==> 频繁地执行 fsync 操作, 可能会产生阻塞导致部分操作耗时较久. 如果允许部分数据丢失, 可设置异步刷新 translog 来提高效率，还有降低 flush 的阀值，优化如下： 写入 Lucene 的数据，并不是实时可搜索的，ES 必须通过 refresh 的过程把内存中的数据转换成 Lucene 的完整 segment 后，才可以被搜索。 默认1秒后，写入的数据可以很快被查询到，但势必会产生大量的 segment，检索性能会受到影响。所以，加大时长可以降低系统开销。对于日志搜索来说，实时性要求不是那么高，设置为5秒或者10s；对于SkyWalking，实时性要求更低一些，我们可以设置为30s。 设置如下： index.merge.scheduler.max_thread_count 控制并发的 merge 线程数，如果存储是并发性能较好的 SSD，可以用系统默认的 max(1, min(4, availableProcessors / 2))，当节点配置的 cpu 核数较高时，merge 占用的资源可能会偏高，影响集群的性能，普通磁盘的话设为1，发生磁盘 IO 堵塞。设置max_thread_count 后，会有 max_thread_count + 2 个线程同时进行磁盘操作，也就是设置为 1 允许3个线程。 设置如下： 该方式可对已经生成的索引做修改，但是对于后续新建的索引不生效，所以我们可以制作 ES 模板，新建的索引按模板创建索引。 因为我们的业务日志是按天维度创建索引，索引名称示例：user-service-prod-2020.12.12，所以用通配符 202 ..*匹配对应要创建的业务日志索引。 前文已经提到过，write 线程池满负荷，导致拒绝任务，而有的数据无法写入。 而经过上面的优化后，拒绝的情况少了很多，但是还是有拒绝任务的情况。 所以我们还需要优化write线程池。 从 prometheus 监控中可以看到线程池的情况： 为了更直观看到ES线程池的运行情况，我们安装了 elasticsearch_exporter 收集 ES 的指标数据到 prometheus，再通过 grafana 进行查看。 经过上面的各种优化，拒绝的数据量少了很多，但是还是存在拒绝的情况，如下图： write 线程池如何设置： 参考： ElasticSearch线程池 write 线程池采用 fixed 类型的线程池，也就是核心线程数与最大线程数值相同。线程数默认等于 cpu 核数，可设置的最大值只能是 cpu 核数加1，也就是16核CPU，能设置的线程数最大值为17。 优化的方案： config/elasticsearch.yml文件增加配置 优化后效果 Swap 交换分区 : 参考： ElasticSearch官方解释为什么要禁用交换内存 有三种方式可以实现 ES 不使用Swap分区 执行命令 可以临时禁用 Swap 内存，但是操作系统重启后失效 执行下列命令 正常情况下不会使用 Swap，除非紧急情况下才会 Swap。 config/elasticsearch.yml 文件增加配置 分片 索引的大小取决于分片与段的大小，分片过小，可能导致段过小，进而导致开销增加；分片过大可能导致分片频繁 Merge，产生大量 IO 操作，影响写入性能。 因为我们每个索引的大小在15G以下，而默认是5个分片，没有必要这么多，所以调整为3个。 分片的设置我们也可以配置在索引模板。 副本数 减少集群副本分片数，过多副本会导致 ES 内部写扩大。副本数默认为1，如果某索引所在的1个节点宕机，拥有副本的另一台机器拥有索引备份数据，可以让索引数据正常使用。但是数据写入副本会影响写入性能。对于日志数据，有1个副本即可。对于大数据量的索引，可以设置副本数为0，减少对性能的影响。 分片的设置我们也可以配置在索引模板。 有的应用1天生成10G日志，而一般的应用只有几百到1G。一天生成10G日志一般是因为部分应用日志使用不当，很多大数量的日志可以不打，比如大数据量的列表查询接口、报表数据、debug 级别日志等数据是不用上传到日志服务器，这些 即影响日志存储的性能，更影响应用自身性能 。 优化后的两周内ELK性能良好，没有使用上的问题： 参考

一、ElasticSearch是什么？ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是第二流行的企业搜索引擎。能够达到实时搜索，稳定，可靠，快速，安装使用方便，零配置和完全免费。我们先说说ES的基本概念。1、索引(Index)ES将数据存储于一个或多个索引中，索引是具有类似特性的文档的集合。类比传统的关系型数据库领域来说，索引相当于SQL中的一个数据库，或者一个数据存储方案(schema)。索引由其名称(必须为全小写字符)进行标识，并通过引用此名称完成文档的创建、搜索、更新及删除操作。一个ES集群中可以按需创建任意数目的索引。2、类型(Type)类型是索引内部的逻辑分区(category/partition)，然而其意义完全取决于用户需求。因此，一个索引内部可定义一个或多个类型(type)。一般来说，类型就是为那些拥有相同的域的文档做的预定义。例如，在索引中，可以定义一个用于存储用户数据的类型，一个存储日志数据的类型，以及一个存储评论数据的类型。类比传统的关系型数据库领域来说，类型相当于“表”。3、文档(Document)文档是Lucene索引和搜索的原子单位，它是包含了一个或多个域的容器，基于JSON格式进行表示。文档由一个或多个域组成，每个域拥有一个名字及一个或多个值，有多个值的域通常称为“多值域”。每个文档可以存储不同的域集，但同一类型下的文档至应该有某种程度上的相似之处。4、映射(Mapping)ES中，所有的文档在存储之前都要首先进行分析。用户可根据需要定义如何将文本分割成token、哪些token应该被过滤掉，以及哪些文本需要进行额外处理等。另外，ES还提供了额外功能，例如将域中的内容按需排序。事实上，ES也能自动根据其值确定域的类型。5、集群(Cluster)ES集群是一个或多个节点的集合，它们共同存储了整个数据集，并提供了联合索引以及可跨所有节点的搜索能力。多节点组成的集群拥有冗余能力，它可以在一个或几个节点出现故障时保证服务的整体可用性。集群靠其独有的名称进行标识，默认名称为“elasticsearch”。节点靠其集群名称来决定加入哪个ES集群，一个节点只能属一个集群。如果不考虑冗余能力等特性，仅有一个节点的ES集群一样可以实现所有的存储及搜索功能。6、节点(Node)运行了单个实例的ES主机称为节点，它是集群的一个成员，可以存储数据、参与集群索引及搜索操作。类似于集群，节点靠其名称进行标识，默认为启动时自动生成的随机Marvel字符名称。用户可以按需要自定义任何希望使用的名称，但出于管理的目的，此名称应该尽可能有较好的识别性。节点通过为其配置的ES集群名称确定其所要加入的集群。7、分片(Shard)和副本(Replica)ES的“分片(shard)”机制可将一个索引内部的数据分布地存储于多个节点，它通过将一个索引切分为多个底层物理的Lucene索引完成索引数据的分割存储功能，这每一个物理的Lucene索引称为一个分片(shard)。每个分片其内部都是一个全功能且独立的索引，因此可由集群中的任何主机存储。创建索引时，用户可指定其分片的数量，默认数量为5个。ES集群可由多个节点组成，各Shard分布式地存储于这些节点上。ES可自动在节点间按需要移动shard，例如增加节点或节点故障时。简而言之，分片实现了集群的分布式存储，而副本实现了其分布式处理及冗余功能。OK，上面把ES相关的基本概念及原理大致说明了下，那么ES到底是怎么实现全文检索的呢？Elasticsearch实现全文检索，首先要确定分词器，ES默认有很多分词器，可参考官方文档。了解分词器主要是怎么实现的。一般中文分词器使用第三方的ik分词器、mmsegf分词器和paoding分词器，最初可能构建于lucene，后来移植于ES。目前我们在最新版的ES中，使用的是IK分词。安装ik分词器到elasticsearch很简单，它有个插件目录analysis-ik，和一个配置目录ik, 分别拷贝到plugins和conf目录就可以了。当你有大量的文本数据时，ES均会将其进行分词并将这些词语保存在索引中，当输入关键词进行查询时，索引就会起到作用，查找对应的相同的查询词，从而实现全文检索。当然这个过程是很吃内存的哦。

或如何了解缺少哪些官方文件 如果我不得不用一个短语来描述Elasticsearch，我会说： 目前，Elasticsearch在十大最受欢迎的开源技术中。 公平地说，它结合了许多本身并不独特的关键功能，但是，当结合使用时，它可以成为最佳的搜索引擎/分析平台。 更准确地说，由于以下功能的结合，Elasticsearch变得如此流行： · 搜索相关性评分 · 全文搜索 · 分析（汇总） · 无模式（对数据模式无限制），NoSQL，面向文档 · 丰富的数据类型选择 · 水平可扩展 · 容错的 通过与Elasticsearch进行合作，我很快意识到，官方文档看起来更像是所谓文档的"挤压"。 我不得不在Google上四处搜寻，并且大量使用stackowerflow，所以我决定编译这篇文章中的所有信息。 在本文中，我将主要撰写有关查询/搜索Elasticsearch集群的文章。 您可以通过多种不同的方式来实现大致相同的结果，因此，我将尝试说明每种方法的利弊。 更重要的是，我将向您介绍两个重要的概念-查询和过滤器上下文-在文档中没有很好地解释。 我将为您提供一组规则，以决定何时使用哪种方法更好。 在阅读本文后，如果我只想让您记住一件事，那就是： 当我们谈论Elasticsearch时，总会有一个相关性分数。 相关性分数是严格的正浮点数，表示每个文档满足搜索标准的程度。 该分数是相对于分配的最高分数的，因此，分数越高，文档与搜索条件的相关性越好。 但是，过滤器和查询是您在编写查询之前应该能够理解的两个不同概念。 一般来说，过滤器上下文是一个"是/否"选项，其中每个文档都与查询匹配或不匹配。 一个很好的例子是SQL WHERE，后面是一些条件。 SQL查询总是返回严格符合条件的行。 SQL查询无法返回歧义结果。 另一方面，Elasticsearch查询上下文显示了每个文档与您的需求的匹配程度。 为此，查询使用分析器查找最佳匹配。 经验法则是将过滤器用于： · 是/否搜索 · 搜索精确值（数字，范围和关键字） 将查询用于： · 结果不明确（某些文档比其他文档更适合） · 全文搜索 此外，Elasticsearch将自动缓存过滤器的结果。 在第1部分和第2部分中，我将讨论查询（可以转换为过滤器）。 请不要将结构化和全文与查询和过滤器混淆-这是两件事。 结构化查询也称为术语级查询，是一组查询方法，用于检查是否应选择文档。 因此，在很多情况下，没有真正必要的相关性评分-文档匹配或不匹配（尤其是数字）。 术语级查询仍然是查询，因此它们将返回分数。 名词查询 Term Query 返回字段值与条件完全匹配的文档。 查询一词是SQL select * from table_name where column_name =...的替代方式 名词查询直接进入倒排索引，这可以使其快速进行。 在处理文本数据时，最好仅将term用于keyword字段。 名词查询默认情况下在查询上下文中运行，因此，它将计算分数。 即使所有返回的文档的分数相同，也将涉及其他计算能力。 带有过滤条件的 名词 查询 如果我们想加速名词查询并使其得到缓存，则应将其包装在constant_score过滤器中。 还记得经验法则吗？ 如果您不关心相关性得分，请使用此方法。 现在，该查询没有计算任何相关性分数，因此，它更快。 而且，它是自动缓存的。 快速建议-对文本字段使用匹配而不是名词。 请记住，名词查询直接进入倒排索引。名词查询采用您提供的值并按原样搜索它，这就是为什么它非常适合查询未经任何转换存储的keyword字段。 多名词查询 Terms query 如您所料，多名词查询使您可以返回至少匹配一个确切名词的文档。 多名词查询在某种程度上是SQL select * from table_name where column_name is in...的替代方法 重要的是要了解，Elasticsearch中的查询字段可能是一个列表，例如{“ name”：[“ Odin”，“ Woden”，“ Wodan”]}。如果您执行的术语查询包含以下一个或多个，则该记录将被匹配-它不必匹配字段中的所有值，而只匹配一个。 与名词查询相同，但是这次您可以在查询字段中指定多少个确切术语。 您指定必须匹配的数量-一，二，三或全部。 但是，此数字是另一个数字字段。 因此，每个文档都应包含该编号（特定于该特定文档）。 返回查询字段值在定义范围内的文档。 等价于SQL select * from table_name where column_name is between... 范围查询具有自己的语法： · gt 大于 · gte 大于或等于 · lt 小于 · lte 小于或等于 一个示例，该字段的值应≥4且≤17 范围查询也可以很好地与日期配合使用。 正则表达式查询返回其中字段与您的正则表达式匹配的文档。 如果您从未使用过正则表达式，那么我强烈建议您至少了解一下它是什么以及何时可以使用它。 Elasticsearch的正则表达式是Lucene的正则表达式。 它具有标准的保留字符和运算符。 如果您已经使用过Python的re软件包，那么在这里使用它应该不是问题。 唯一的区别是Lucene的引擎不支持^和$等锚运算符。 您可以在官方文档中找到regexp的完整列表。 除正则表达式查询外，Elsticsearch还具有通配符和前缀查询。从逻辑上讲，这两个只是regexp的特殊情况。 不幸的是，我找不到关于这三个查询的性能的任何信息，因此，我决定自己对其进行测试，以查看是否发现任何重大差异。 在比较使用rehexp和通配符查询时，我找不到性能上的差异。如果您知道有什么不同，请给我发消息。 由于Elasticsearch是无模式的（或没有严格的模式限制），因此当不同的文档具有不同的字段时，这是一种很常见的情况。 结果，有很多用途来了解文档是否具有某些特定字段。 全文查询适用于非结构化文本数据。 全文查询利用了分析器。 因此，我将简要概述Elasticsearch的分析器，以便我们可以更好地分析全文查询。 每次将文本类型数据插入Elasticsearch索引时，都会对其进行分析，然后存储在反向索引中。根据分析器的配置方式，这会影响您的搜索功能，因为分析器也适用于全文搜索。 分析器管道包括三个阶段： 总有一个令牌生成器和零个或多个字符和令牌过滤器。 1）字符过滤器按原样接收文本数据，然后可能在对数据进行标记之前对其进行预处理。 字符过滤器用于： · 替换与给定正则表达式匹配的字符 · 替换与给定字符串匹配的字符 · 干净的HTML文字 2）令牌生成器将字符过滤器（如果有）之后接收到的文本数据分解为令牌。 例如，空白令牌生成器只是将文本分隔为空白（这不是标准的）。 因此，Wednesday is called after Woden， 将被拆分为[Wednesday, is, called, after, Woden.]。 有许多内置标记器可用于创建自定义分析器。 删除标点符号后，标准令牌生成器将使用空格分隔文本。 对于绝大多数语言来说，这是最中立的选择。 除标记化外，标记化器还执行以下操作： · 跟踪令牌顺序， · 注释每个单词的开头和结尾 · 定义令牌的类型 3）令牌过滤器对令牌进行一些转换。您可以选择将许多不同的令牌过滤器添加到分析器中。一些最受欢迎的是： · 小写 · 词干（存在多种语言！） · 删除重复 · 转换为等效的ASCII · 模式的解决方法 · 令牌数量限制 · 令牌的停止列表（从停止列表中删除令牌） 标准分析器是默认分析器。 它具有0个字符过滤器，标准令牌生成器，小写字母和停止令牌过滤器。 您可以根据需要组成自定义分析器，但是内置分析器也很少。 语言分析器是一些最有效的即用型分析器，它们利用每种语言的细节来进行更高级的转换。 因此，如果您事先知道数据的语言，建议您从标准分析器切换为数据的一种语言。 全文查询将使用与索引数据时使用的分析器相同的分析器。更准确地说，您查询的文本将与搜索字段中的文本数据进行相同的转换，因此两者处于同一级别。 匹配查询是用于查询文本字段的标准查询。 我们可以将匹配查询称为名词查询的等效项，但适用于文本类型字段（而在处理文本数据时，名词应仅用于关键字类型字段）。 默认情况下，传递给查询参数的字符串（必需的一个）将由与应用于搜索字段的分析器相同的分析器处理。 除非您自己使用analyzer参数指定分析器。 当您指定要搜索的短语时，将对其进行分析，并且结果始终是一组标记。默认情况下，Elasticsearch将在所有这些标记之间使用OR运算符。这意味着至少应该有一场比赛-更多的比赛虽然会得分更高。您可以在运算符参数中将其切换为AND。在这种情况下，必须在文档中找到所有令牌才能将其返回。 如果要在OR和AND之间输入某些内容，则可以指定minimum_should_match参数，该参数指定应匹配的子句数。 可以数字和百分比指定。 模糊参数（可选）可让您忽略错别字。 Levenshtein距离用于计算。 如果您将匹配查询应用于关键字keyword字段，则其效果与词条查询相同。 更有趣的是，如果将存储在反向索引中的令牌的确切值传递给term查询，则它将返回与匹配查询完全相同的结果，但是会更快地返回到反向索引。 与匹配相同，但顺序和接近度很重要。 匹配查询不了解序列和接近度，因此，只有通过其他类型的查询才能实现词组匹配。 match_phrase查询具有slop参数（默认值为0），该参数负责跳过术语。 因此，如果您指定斜率等于1，则短语中可能会省略一个单词。 多重比对查询的功能与比对相同，唯一的不同是多重比对适用于多个栏位 · 字段名称可以使用通配符指定 · 默认情况下，每个字段均加权 · 每个领域对得分的贡献都可以提高 · 如果没有在fields参数中指定任何字段，那么将搜索所有符合条件的字段 有多种类型的multi_match。 我不会在这篇文章中描述它们，但是我将解释最受欢迎的： best_fields类型（默认值）更喜欢在一个字段中找到来自搜索值的令牌的结果，而不是将搜索的令牌分配到不同字段中的结果。 most_fields与best_fields类型相反。 phrase类型的行为与best_fields相同，但会搜索与match_phrase类似的整个短语。 我强烈建议您查阅官方文档，以检查每个字段的得分计算准确度。 复合查询将其他查询包装在一起。 复合查询： · 结合分数 · 改变包装查询的行为 · 将查询上下文切换到过滤上下文 · 以上任意一项 布尔查询将其他查询组合在一起。 这是最重要的复合查询。 布尔查询使您可以将查询上下文中的搜索与过滤器上下文搜索结合在一起。 布尔查询具有四个可以组合在一起的出现（类型）： · must或"必须满足该条款" · should或"如果满足条款，则对相关性得分加分" · 过滤器filter或"必须满足该条款，但不计算相关性得分" · must_not或“与必须相反”，不会有助于相关度得分 必须和应该→查询上下文 过滤器和must_not→过滤器上下文 对于那些熟悉SQL的人，必须为AND，而应为OR运算符。 因此，必须满足must子句中的每个查询。 对于大多数查询，提升查询与boost参数相似，但并不相同。 增强查询将返回与肯定子句匹配的文档，并降低与否定子句匹配的文档的得分。 如我们在术语查询示例中先前看到的，constant_score查询将任何查询转换为相关性得分等于boost参数（默认值为1）的过滤器上下文。 让我知道是否您想阅读另一篇文章，其中提供了所有查询的真实示例。 我计划在Elasticsearch上发布更多文章，所以不要错过。 你已经读了很长的内容，所以如果你阅读到这里： 综上所述，Elasticsearch符合当今的许多用途，有时很难理解什么是最佳工具。 如果不需要相关性分数来检索数据，请尝试切换到过滤器上下文。 另外，了解Elasticsearch的工作原理也至关重要，因此，我建议您始终了解分析器的功能。 Elasticsearch中还有许多其他查询类型。 我试图描述最常用的。 我希望你喜欢它。 (本文翻译自kotartemiy u2714ufe0f的文章《Deep Dive into Querying Elasticsearch. Filter vs Query. Full-text search》，参考：https://towardsdatascience.com/deep-pe-into-querying-elasticsearch-filter-vs-query-full-text-search-b861b06bd4c0)

使用ElasticSearch快一年了，自认为相关API使用的还比较6，产品提的一些搜索需求实现起来都从心应手；但是前几天同事的一个问题直接将我打回到小白，同事问了句：“ ElasticSearch的索引是怎么存储的？删除文档和更新文档是怎么实现的？ ”，当时我就懵逼了，说了句得查一下，好尴尬...... 回想起来发现自己从来都没有深入了解过这些细节，于是便觉得非常有必要对ElasticSearch的文档存储做一次深入的了解，知其然不知其所以然对于我们来说是远远不够的，在ElasticSearch中，文档（ Document ）存储的介质分为内存和硬盘两种: 同时，ElasticSearch进程自身的运行也需要内存空间，必须保证ElasticSearch进程有充足的运行时内存。为了使ElasticSearch引擎达到最佳性能，必须合理分配有限的内存和硬盘资源。 ElasticSearch引擎把文档数据写入到倒排索引（ Inverted Index ）的数据结构中，倒排索引建立的是分词（ Term ）和文档（ Document ）之间的映射关系,在倒排索引中，数据是面向词（ Term ）而不是面向文档（ Document ）的。 举个栗子，假设我们有两个文档，每个文档的content域包含如下内容： 1. The quick brown fox jumped over the lazy dog 2. Quick brown foxes leap over lazy dogs in summer 文档和词之间的关系如下图： 字段值被分析之后，存储在倒排索引中，倒排索引存储的是分词（ Term ）和文档（ Doc ）之间的关系，简化版的倒排索引如下图： 从图中可以看出，倒排索引有一个词条的列表，每个分词在列表中是唯一的，记录着词条出现的次数，以及包含词条的文档。实际中ElasticSearch引擎创建的倒排索引比这个复杂得多。 段是倒排索引的组成部分，倒排索引是由段（ Segment ）组成的，段存储在硬盘（ Disk ）文件中。 索引段不是实时更新的，这意味着，段在写入硬盘之后，就不再被更新。在删除文档时，ElasticSearch引擎把已删除的文档的信息存储在一个单独的文件中，在搜索数据时，ElasticSearch引擎首先从段中执行查询，再从查询结果中过滤被删除的文档 。这意味着，段中存储着被删除的文档，这使得段中含有”正常文档“的密度降低。 多个段可以通过段合并（Segment Merge）操作把“已删除”的文档将从段中物理删除，把未删除的文档合并到一个新段中，新段中没有”已删除文档“，因此，段合并操作能够提高索引的查找速度 ；但是，段合并是IO密集型操作，需要消耗大量的硬盘IO。 在ElasticSearch中，大多数查询都需要从硬盘文件（索引的段数据存储在硬盘文件中）中获取数据；因此， 在全局配置文件elasticsearch.yml 中，把结点的路径（Path）配置为性能较高的硬盘，能够提高查询性能 。默认情况下，ElasticSearch使用基于安装目录的相对路径来配置结点的路径，安装目录由属性path.home显示，在home path下，ElasticSearch自动创建config，data，logs和plugins目录，一般情况下不需要对结点路径单独配置。结点的文件路径配置项： path.data：设置ElasticSearch结点的索引数据保存的目录，多个数据文件使用逗号隔开。 例如，path.data: /path/to/data1,/path/to/data2 ； path.work：设置ElasticSearch的临时文件保存的目录； 映射参数index决定ElasticSearch引擎是否对文本字段执行分析操作，也就是说分析操作把文本分割成一个一个的分词，也就是标记流（ Token Stream ），把分词编入索引，使分词能够被搜索到： 1） 当index为analyzed时，该字段是分析字段，ElasticSearch引擎对该字段执行分析操作，把文本分割成分词流，存储在倒排索引中，使其支持全文搜索。 2）当index为not_analyzed时，该字段不会被分析，ElasticSearch引擎把原始文本作为单个分词存储在倒排索引中，不支持全文搜索，但是支持词条级别的搜索；也就是说，字段的原始文本不经过分析而存储在倒排索引中，把原始文本编入索引，在搜索的过程中，查询条件必须全部匹配整个原始文本。 3）当index为no时，该字段不会被存储到倒排索引中，不会被搜索到。 字段的原始值是否被存储到倒排索引，是由映射参数store决定的，默认值是false，也就是，原始值不存储到倒排索引中。 映射参数index和store的区别在于： store用于获取（Retrieve）字段的原始值，不支持查询，可以使用投影参数fields，对stroe属性为true的字段进行过滤，只获取（Retrieve）特定的字段，减少网络负载； index用于查询（Search）字段，当index为analyzed时，对字段的分词执行全文查询；当index为not_analyzed时，字段的原始值作为一个分词，只能对字段的原始文本执行词条查询； 如果设置字段的index属性为not_analyzed，原始文本将作为单个分词，其最大长度跟UTF8 编码有关，默认的最大长度是32766Bytes（约32KB），如果字段的文本超过该限制，那么ElasticSearch将跳过（ Skip ）该文档，并在Response中抛出异常消息： operation[607]: index returned 400 _index: ebrite _type: events _id: 76860 _version: 0 error: Type: illegal_argument_exception Reason: "Document contains at least one immense term in field="event_raw" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped. Please correct the analyzer to not produce such terms. The prefix of the first immense term is: "[112, 114,... 115]...", original message: bytes can be at most 32766 in length; got 35100" CausedBy:Type: max_bytes_length_exceeded_exception Reason: "bytes can be at most 32766 in length; got 35100" 可以在字段中设置ignore_above属性，该属性值指的是字符数量，而不是字节数量；由于一个UTF8字符最多占用3个字节，因此，可以设置 “ignore_above”：10000 这样，超过30000字节之后的字符将会被分析器忽略，单个分词（ Term ）的最大长度是30000Bytes。 The value for ignore_above is the character count, but Lucene counts bytes. If you use UTF-8 text with many non-ASCII characters, you may want to set the limit to 32766 / 3 = 10922 since UTF-8 characters may occupy at most 3 bytes. 默认情况下，大多数字段被索引之后，能够被搜索到。 倒排索引是由一个有序的词条列表构成的，每一个词条在列表中都是唯一存在的，通过这种数据存储模式，你可以很快查找到包含某一个词条的文档列表 。 但是，排序和聚合操作采用相反的数据访问模式，这两种操作不是查找词条以发现文档，而是查找文档，以发现字段中包含的词条。ElasticSearch使用列式存储实现排序和聚合查询。 文档值（ doc_values ）是存储在硬盘上的数据结构，在索引时（ index time ）根据文档的原始值创建，文档值是一个列式存储风格的数据结构，非常适合执行存储和聚合操作，除了字符类型的分析字段之外，其他字段类型都支持文档值存储。默认情况下，字段的文档值存储是启用的，除了字符类型的分析字段之外。如果不需要对字段执行排序或聚合操作，可以禁用字段的文档值，以节省硬盘空间。 字符类型的分析字段，不支持文档值（doc_values），但支持fielddata数据结构。fielddata数据结构存储在JVM的堆内存中。相比文档值（数据存储在硬盘上），fielddata字段（数据存储在内存中）的查询性能更高。默认情况下，ElasticSearch引擎在第一次对字段执行聚合或排序查询时（query-time），创建fielddata数据结构；在后续的查询请求中，ElasticSearch引擎使用fielddata数据结构以提高聚合和排序的查询性能。 在ElasticSearch中，倒排索引的各个段（ segment ）的数据存储在硬盘文件上，从整个倒排索引的段中读取字段数据之后，ElasticSearch引擎首先反转词条和文档之间的关系，创建文档和词条之间的关系，即创建顺排索引，然后把顺排索引存储在JVM的堆内存中。把倒排索引加载到fielddata结构是一个非常消耗硬盘IO资源的过程。因此，数据一旦被加载到内存，最好保持在内存中，直到索引段( segment )的生命周期结束。 默认情况下，倒排索引的每个段( segment )，都会创建相应的fielddata结构，以存储字符类型的分析字段值，但是，需要注意的是，分配的JVM堆内存是有限的，Fileddata把数据存储在内存中，会占用过多的JVM堆内存，甚至耗尽JVM赖以正常运行的内存空间，反而会降低ElasticSearch引擎的查询性能。 fielddata会消耗大量的JVM内存，因此，尽量为JVM设置大的内存，不要为不必要的字段启用fielddata存储。通过format参数控制是否启用字段的fielddata特性，字符类型的分析字段，fielddata的默认值是paged_bytes，这就意味着，默认情况下，字符类型的分析字段启用fielddata存储。一旦禁用fielddata存储，那么字符类型的分析字段将不再支持排序和聚合查询。 loading属性控制fielddata加载到内存的时机，可能的值是lazy，eager和eager_global_ordinals，默认值是lazy。 lazy：fielddata只在需要时加载到内存，默认情况下，在第一次搜索时，fielddata被加载到内存中；但是，如果查询一个非常大的索引段（Segment），lazy加载方式会产生较大的时间延迟。 eager：在倒排索引的段可用之前，其数据就被加载到内存，eager加载方式能够减少查询的时间延迟，但是，有些数据可能非常冷，以至于没有请求来查询这些数据，但是冷数据依然被加载到内存中，占用紧缺的内存资源。 eager_global_ordinals：按照global ordinals积极把fielddata加载到内存。 ElasticSearch使用 JAVA_OPTS 环境变量（ Environment Variable ）启动JVM进程，在 JAVA_OPTS 中，最重要的配置是： -Xmx参数控制分配给JVM进程的最大内存，-Xms参数控制分配给JVM进程的最小内存 。（在ElasticSearch启动命令后面可以通过参数方式配置，如： /usr/local/elasticsearch/bin/elasticsearch -d --Xmx=10g --Xms=10g ）通常情况下，使用默认的配置就能满足工程需要。 ES_HEAP_SIZE 环境变量控制分配给JVM进程的堆内存（ Heap Memory ）大小，顺排索引（ fielddata ）的数据存储在堆内存（ Heap Memory ）中。 大多数应用程序尝试使用尽可能多的内存，并尽可能把未使用的内存换出，但是，内存换出会影响ElasticSearch引擎的查询性能，推荐启用内存锁定，禁用ElasticSearch内存的换进换出。 在全局配置文档 elasticsearch.yml 中，设置 bootstrap.memory_lock 为ture，这将锁定ElasticSearch进程的内存地址空间，阻止ElasticSearch内存被OS换出（ Swap out ）。 通过学习，算是对ElasticSearch索引存储及更新有了一个较深的了解，至少能让我从容去面对同事的提问，但与此同时给我敲响了警钟，在使用一门技术的同时，更应该去了解它具体的原理，而不仅仅是停留在使用级别；在学习的路上，我们仍需要更加努力......

本文讨论如何跨集群迁移ES数据以及如何实现ES的同城跨机房容灾和异地容灾。 在ES的生产实践中，往往会遇到以下问题： 根据业务需求，存在以下场景： 如果是第一种场景，数据迁移过程中可以停止写入，可以采用诸如elasticsearch-dump、logstash、reindex、snapshot等方式进行数据迁移。实际上这几种工具大体上可以分为两类： 如果是第二种场景，数据迁移过程中旧集群不能停止写入，需要根据实际的业务场景解决数据一致性的问题： 下面介绍一下在旧集群可以停止写入的情况下进行数据迁移的几种工具的用法。 elasticsearch-dump是一款开源的ES数据迁移工具，github地址: https://github.com/taskrabbit/elasticsearch-dump 以下操作通过elasticdump命令将集群x.x.x.1中的companydatabase索引迁移至集群x.x.x.2。注意第一条命令先将索引的settings先迁移，如果直接迁移mapping或者data将失去原有集群中索引的配置信息如分片数量和副本数量等，当然也可以直接在目标集群中将索引创建完毕后再同步mapping与data logstash支持从一个ES集群中读取数据然后写入到另一个ES集群，因此可以使用logstash进行数据迁移，具体的配置文件如下： 上述配置文件将源ES集群的所有索引同步到目标集群中，当然可以设置只同步指定的索引，logstash的更多功能可查阅logstash官方文档 logstash 官方文档 . reindex是Elasticsearch提供的一个api接口，可以把数据从一个集群迁移到另外一个集群。 snapshot api是Elasticsearch用于对数据进行备份和恢复的一组api接口，可以通过snapshot api进行跨集群的数据迁移，原理就是从源ES集群创建数据快照，然后在目标ES集群中进行恢复。需要注意ES的版本问题： 如果旧集群不能停止写入，此时进行在线数据迁移，需要保证新旧集群的数据一致性。目前看来，除了官方提供的CCR功能，没有成熟的可以严格保证数据一致性的在线数据迁移方法。此时可以从业务场景出发，根据业务写入数据的特点选择合适的数据迁移方案。 一般来说，业务写入数据的特点有以下几种： 下面来具体分析不同的写入数据的特点下，该如何选择合适的数据迁移方式。 在日志或者APM的场景中，数据都是时序数据，一般索引也都是按天创建的，当天的数据只会写入当前的索引中。此时，可以先把存量的不再写入的索引数据一次性同步到新集群中，然后使用logstash或者其它工具增量同步当天的索引，待数据追平后，把业务对ES的访问切换到新集群中。 具体的实现方案为： add only的数据写入方式，可以按照数据写入的顺序(根据_doc进行排序，如果有时间戳字段也可以根据时间戳排序)批量从旧集群中拉取数据，然后再批量写入新集群中；可以通过写程序，使用用scroll api 或者search_after参数批量拉取增量数据，再使用bulk api批量写入。 使用scroll拉取增量数据： 上述操作可以每分钟执行一次，拉起前一分钟新产生的数据，所以数据在旧集群和新集群的同步延迟为一分钟。 使用search_after批量拉取增量数据： 上述操作可以根据需要自定义事件间隔执行，每次执行时修改search_after参数的值，获取指定值之后的多条数据；search_after实际上相当于一个游标，每执行一次向前推进，从而获取到最新的数据。 使用scroll和search_after的区别是： 另外，如果不想通过写程序迁移旧集群的增量数据到新集群的话，可以使用logstash结合scroll进行增量数据的迁移，可参考的配置文件如下： 使用过程中可以根据实际业务的需求调整定时任务参数schedule以及scroll相关的参数。 业务场景如果是写入ES时既有追加，又有存量数据的更新，此时比较重要的是怎么解决update操作的数据同步问题。对于新增的数据，可以采用上述介绍的增量迁移热索引的方式同步到新集群中。对于更新的数据，此时如果索引有类似于updateTime的字段用于标记数据更新的时间，则可以通过写程序或者logstash，使用scroll api根据updateTime字段批量拉取更新的增量数据，然后再写入到新的集群中。 可参考的logstash配置文件如下： 实际应用各种，同步新增(add)的数据和更新(update)的数据可以同时进行。但是如果索引中没有类似updateTime之类的字段可以标识出哪些数据是更新过的，目前看来并没有较好的同步方式，可以采用CCR来保证旧集群和新集群的数据一致性。 如果业务写入ES时既有新增(add)数据,又有更新(update)和删除(delete)数据，可以采用6.5之后商业版X-pack插件中的CCR功能进行数据迁移。但是使用CCR有一些限制，必须要注意： 具体的使用方式如下： 如果业务是通过中间件如kafka把数据写入到ES， 则可以使用如下图中的方式，使用logstash消费kafka的数据到新集群中，在旧集群和新集群数据完全追平之后，可以切换到新集群进行业务的查询，之后再对旧的集群下线处理。 使用中间件进行同步双写的优点是： 当然，双写也可以使用其他的方式解决，比如自建proxy，业务写入时向proxy写入，proxy把请求转发到一个或者多个集群中，但是这种方式存在以下问题： 随着业务规模的增长，业务侧对使用的ES集群的数据可靠性、集群稳定性等方面的要求越来越高，所以要比较好的集群容灾方案支持业务侧的需求。 如果是公司在自建IDC机房内，通过物理机自己搭建的ES集群，在解决跨机房容灾的时候，往往会在两个机房 部署两个ES集群，一主一备，然后解决解决数据同步的问题；数据同步一般有两种方式，一种方式双写，由业务侧实现双写保证数据一致性，但是双写对业务侧是一个挑战，需要保证数据在两个集群都写成功才能算成功。另外一种方式是异步复制，业务侧只写主集群，后台再把数据同步到备集群中去，但是比较难以保证数据一致性。第三种方式是通过专线打通两个机房，实现跨机房部署，但是成本较高。 因为数据同步的复杂性，云厂商在实现ES集群跨机房容灾的时候，往往都是通过只部署一个集群解决，利用ES自身的能力同步数据。国外某云厂商实现跨机房部署ES集群的特点1是不强制使用专用主节点，如上图中的一个集群，只有两个节点，既作为数据节点也作为候选主节点；主分片和副本分片分布在两个可用区中，因为有副本分片的存在，可用区1挂掉之后集群仍然可用，但是如果两个可用区之间网络中断时，会出现脑裂的问题。如下图中使用三个专用主节点，就不会存在脑裂的问题了。 但是如果一个地域没有三个可用区怎么办呢，那就只能在其中一个可用区中放置两个专用主节点了，如国内某云厂商的解决方案： 但是重建节点的过程还是存在问题的，如上图中，集群本身的quorum应该为2，可用区1挂掉后，集群中只剩一个专用主节点，需要把quorum参数(discovery.zen.minimum_master_nodes)调整为1后集群才能够正常进行选主，等挂掉的两个专用主节点恢复之后，需要再把quorum参数(discovery.zen.minimum_master_nodes)调整为2，以避免脑裂的发生。 当然还是有可以把无法选主和脑裂这两个可能发生的问题规避掉的解决方案，如下图中国内某云厂商的解决思路： 创建双可用区集群时，必须选择3个或者5个专用主节点，后台会在一个隐藏的可用区中只部署专用主节点；方案的优点1是如果一个可用区挂掉，集群仍然能够正常选主，避免了因为不满足quorum法定票数而无法选主的情况；2是因为必须要选择三个或5个专用主节点，也避免了脑裂。 想比较一主一备两个集群进行跨机房容灾的方式，云厂商通过跨机房部署集群把原本比较复杂的主备数据同步问题解决了，但是，比较让人担心的是，机房或者可用区之间的网络延迟是否会造成集群性能下降。这里针对腾讯云的双可用区集群，使用标准的benchmark工具对两个同规格的单可用区和双可用区集群进行了压测，压测结果如下图所示： 从压测结果的查询延时和写入延时指标来看，两种类型的集群并没有明显的差异，这主要得益与云上底层网络基础设施的完善，可用区之间的网络延迟很低。 类似于同城跨机房容灾，异地容灾一般的解决思路是在异地两个机房部署一主一备两个集群。业务写入时只写主集群，再异步地把数据同步到备集群中，但是实现起来会比较复杂，因为要解决主备集群数据一致性的问题，并且跨地域的话，网络延迟会比较高；还有就是，当主集群挂掉之后，这时候切换到备集群，可能两边数据还没有追平，出现不一致，导致业务受损。当然，可以借助于kafka等中间件实现双写，但是数据链路增加了，写入延迟也增加了，并且kafka出现问题，故障可能就是灾难性的了。 一种比较常见的异步复制方法是，使用snapshot备份功能，定期比如每个小时在主集群中执行一次备份，然后在备集群中进行恢复，但是主备集群会有一个小时的数据延迟。以腾讯云为例，腾讯云的ES集群支持把数据备份到对象存储COS中，因为可以用来实现主备集群的数据同步，具体的操作步骤可以参考 https://cloud.tencent.com/document/product/845/19549 。 在6.5版本官方推出了CCR功能之后，集群间数据同步的难题就迎刃而解了。可以利用CCR来实现ES集群的异地容灾： CCR是类似于数据订阅的方式，主集群为Leader, 备集群为Follower, 备集群以pull的方式从主集群拉取数据和写请求；在定义好Follwer Index时，Follwer Index会进行初始化，从Leader中以snapshot的方式把底层的segment文件全量同步过来，初始化完成之后，再拉取写请求，拉取完写请求后，Follwer侧进行重放，完成数据的同步。CCR的优点当然是因为可以同步UPDATE/DELETE操作，数据一致性问题解决了，同步延时也减小了。 另外，基于CCR可以和前面提到的跨机房容灾的集群结合，实现两地多中心的ES集群。在上海地域，部署有多可用区集群实现跨机房的高可用，同时在北京地域部署备集群作为Follwer利用CCR同步数据，从而在集群可用性上又向前走了一步，既实现了同城跨机房容灾，又实现了跨地域容灾。 但是在出现故障时需要把集群的访问从上海切换到北京时，会有一些限制，因为CCR中的Follwer Index是只读的，不能写入，需要切换为正常的索引才能进行写入，过程也是不可逆的。不过在业务侧进行规避，比如写入时使用新的正常的索引，业务使用别名进行查询，当上海地域恢复时，再反向的把数据同步回去。 现在问题就是保证上海地域集群数据的完整性，在上海地域恢复后，可以在上海地域新建一个Follower Index，以北京地域正在进行写的索引为Leader同步数据，待数据完全追平后，再切换到上海地域进行读写，注意切换到需要新建Leader索引写入数据。 数据同步过程如下所示： 1.上海主集群正常提供服务，北京备集群从主集群Follow数据 2.上海主集群故障，业务切换到北京备集群进行读写，上海主集群恢复后从北京集群Follow数据

0、引言 在业务开发中，我们往往会陷入开发的细枝末节之中，而忽略了事物的本源。 经常有同学问到： 等等等等….. 以上的看似复杂的问题，如果转换成DSL，清楚的写出来，梳理清楚问题的来龙去脉，问题就自然解决了一大半。 所以，请亮出你的dsl,不论什么语言的检索，转换到es查询都是sql查询，在es中对应dsl语法，es再拆解比如：分词match_phrase拆解成各term组合，最终传给lucene处理。 亮出你的dsl,确保编程里的实现和你的kibana或者head插件一致是非常重要、很容易被忽视的工作。 如果对dsl拆解不理解，那就再 加上 profile:true或者explain:true拆解结果一目了然。 维基百科定义：领域特定语言（英语：domain-specific language、DSL）指的是专注于某个应用程序领域的计算机语言。又译作领域专用语言。 Elasticsearch提供基于JSON的完整查询DSL来定义查询。 将Query DSL视为查询的AST（抽象语法树），由两种类型的子句组成： 1、叶子查询子句 叶查询子句查找特定字段中的特定值，例如匹配，术语或范围查询。 这些查询可以单独使用。 2、复合查询子句 复合查询子句可以组合其他叶子或复合查询，用于以逻辑方式组合多个查询（例如bool或dis_max查询），或更改其行为（例如constant_score查询）。 给个例子，一看就明白。 看到这里，可能会有人着急了：“我X，这不是官网定义吗？再写一遍有意思吗？” 引用一句鸡汤话，“再显而易见的道理，在中国，至少有一亿人不知道”。同样的，再显而易见的问题，在Elasticsearch技术社区也会有N多人提问。 基础认知不怕重复，可怕的是对基础的专研、打磨、夯实。 Elasticsearch相关的核心操作，广义上可做如下解读，不一定涵盖全，仅抛砖引玉，说明DSL的重要性。 从大到小。 集群的管理，一般我们会使用Kibana或者第三方工具Head插件、cerebro工具、elastic-hq工具。 基本上硬件的（磁盘、cpu、内存）使用率、集群的 健康 状态都能一目了然。 但基础的DSL会更便捷，便于细粒度分析问题。 如：集群状态查询： 如：节点热点线程查看： 如：集群分片分配情况查看： 索引生命周期是一直强调的概念，主要指索引的“生、老、病、死”的全过程链条的管理。 创建索引我们优先使用较单纯index更灵活的template模板。 创建索引类似Mysql的创建表的操作，提前设计好表结构对应ES是提前设计好M app ing非常重要。 两个维度： 举例： 如：索引清理缓存。 如：某原因导致分片重新分配，_recovery查看分片分配状态。 高版本的索引生命周期管理推荐使用：ILM功能。 这个是大家再熟悉不过的了。 举例： 删除数据包括：指定id删除 delete和批量删除delete_by_query（满足给定条件）。 更新操作。包括：指定id的update/upsert或者批量更新update_by_query。 这是ES的重头戏。包含但不限于： 1、支持精确匹配查询的：term、range、exists、wildcard、prefix、fuzzy等。 2、支持全文检索的：match、match_phrase、query_string、multi_match等 1、Bucketing分桶聚合 举例：最常用的terms就类似Mysql group by功能。2、Metric计算聚合 举例：类比Mysql中的： MIN, MAX, SUM 操作。3、Pipeline针对聚合结果聚合 举例：bucket_script实现类似Mysql的group by 后having的操作。 留给大家 结合 业务场景思考添加。 这里把开头提到的几个问题逐一解答一下。 实际Mysql业务中，我们一般是先验证sql没有问题，再写业务代码。 实际ES业务中，也一样，先DSL确认没有问题，再写业务代码。 写完java或者python后，打印DSL，核对是否完全一致。 不一致的地方基本就是结果和预期不一致的原因所在。 第一步：借助analyzer API分析查询语句和待查询document分词结果。 这个API的重要性，再怎么强调都不为过。 第二步：可以借助profile:true查看细节。第三步：核对match_phrase词序的原理。 6.3版本后已经支持sql，如果不会写，可以借助translate 如下API翻译一下。 不够精确，但足够参考用了，需要根据业务细节微调。 当然，还是 建议 ，从业务出发，自己写DSL。 从大往小，逐步细化排解 END 公众号 ( zhisheng )里回复 面经、ES、Flink、 Spring、Java、Kafka、监控 等关键字可以查看更多关键字对应的文章 1、《从0到1学习Flink》—— Apache Flink 介绍 2、《从0到1学习Flink》—— Mac 上搭建 Flink 1.6.0 环境并构建运行简单程序入门 3、《从0到1学习Flink》—— Flink 配置文件详解 4、《从0到1学习Flink》—— Data Source 介绍 5、《从0到1学习Flink》—— 如何自定义 Data Source ？ 6、《从0到1学习Flink》—— Data Sink 介绍 7、《从0到1学习Flink》—— 如何自定义 Data Sink ？ 8、《从0到1学习Flink》—— Flink Data transformation(转换) 9、《从0到1学习Flink》—— 介绍 Flink 中的 Stream Windows 10、《从0到1学习Flink》—— Flink 中的几种 Time 详解 11、《从0到1学习Flink》—— Flink 读取 Kafka 数据写入到 ElasticSearch 12、《从0到1学习Flink》—— Flink 项目如何运行？ 13、《从0到1学习Flink》—— Flink 读取 Kafka 数据写入到 Kafka 14、《从0到1学习Flink》—— Flink JobManager 高可用性配置 15、《从0到1学习Flink》—— Flink parallelism 和 Slot 介绍 16、《从0到1学习Flink》—— Flink 读取 Kafka 数据批量写入到 MySQL 17、《从0到1学习Flink》—— Flink 读取 Kafka 数据写入到 RabbitMQ 18、《从0到1学习Flink》—— 你上传的 jar 包藏到哪里去了 19、大数据“重磅炸弹”——实时计算框架 Flink 20、《Flink 源码解析》—— 源码编译运行 21、为什么说流处理即未来？ 22、OPPO数据中台之基石：基于Flink SQL构建实数据仓库 23、流计算框架 Flink 与 Storm 的性能对比 24、Flink状态管理和容错机制介绍 25、原理解析 | Apache Flink 结合 Kafka 构建端到端的 Exactly-Once 处理 26、Apache Flink 是如何管理好内存的？ 27、《从0到1学习Flink》——Flink 中这样管理配置，你知道？ 28、《从0到1学习Flink》——Flink 不可以连续 Split(分流)？ 29、Flink 从0到1学习—— 分享四本 Flink 的书和二十多篇 Paper 论文 30 、360深度实践：Flink与Storm协议级对比 31、Apache Flink 1.9 重大特性提前解读 32、如何基于Flink+TensorFlow打造实时智能异常检测平台？只看这一篇就够了 33、美团点评基于 Flink 的实时数仓建设实践 34、Flink 灵魂两百问，这谁顶得住？ 35、一文搞懂 Flink 的 Exactly Once 和 At Least Once 36、你公司到底需不需要引入实时计算引擎？

Elasticsearch 是一个实时的分布式搜索与分析引擎，在使用过程中，有一些典型的使用场景，比如分页、遍历等。 在使用关系型数据库中，我们被告知要注意甚至被明确禁止使用深度分页，同理，在 Elasticsearch 中，也应该尽量避免使用深度分页。 这篇文章主要介绍 Elasticsearch 中分页相关内容！ 在ES中，分页查询默认返回最顶端的10条匹配hits。 如果需要分页，需要使用from和size参数。 一个基本的ES查询语句是这样的： 上面的查询表示从搜索结果中取第100条开始的10条数据。 「那么，这个查询语句在ES集群内部是怎么执行的呢？」 在ES中，搜索一般包括两个阶段，query 和 fetch 阶段，可以简单的理解，query 阶段确定要取哪些doc，fetch 阶段取出具体的 doc。 如上图所示，描述了一次搜索请求的 query 阶段：· 在上面的例子中，coordinating node 拿到 (from + size) * 6 条数据，然后合并并排序后选择前面的 from + size 条数据存到优先级队列，以便 fetch 阶段使用。 另外，各个分片返回给 coordinating node 的数据用于选出前 from + size 条数据，所以，只需要返回唯一标记 doc 的 _id 以及用于排序的 _score 即可，这样也可以保证返回的数据量足够小。 coordinating node 计算好自己的优先级队列后，query 阶段结束，进入 fetch 阶段。 query 阶段知道了要取哪些数据，但是并没有取具体的数据，这就是 fetch 阶段要做的。 上图展示了 fetch 过程： coordinating node 的优先级队列里有 from + size 个 _doc _id ，但是，在 fetch 阶段，并不需要取回所有数据，在上面的例子中，前100条数据是不需要取的，只需要取优先级队列里的第101到110条数据即可。 需要取的数据可能在不同分片，也可能在同一分片，coordinating node 使用 「multi-get」 来避免多次去同一分片取数据，从而提高性能。 「这种方式请求深度分页是有问题的：」 我们可以假设在一个有 5 个主分片的索引中搜索。当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给 协调节点 ，协调节点对 50 个结果排序得到全部结果的前 10 个。 现在假设我们请求第 1000 页—结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。 「对结果排序的成本随分页的深度成指数上升。」 「注意1：」 size的大小不能超过 index.max_result_window 这个参数的设置，默认为10000。 如果搜索size大于10000，需要设置 index.max_result_window 参数 「注意2：」 _doc 将在未来的版本移除，详见： Elasticsearch 的From/Size方式提供了分页的功能，同时，也有相应的限制。 举个例子，一个索引，有10亿数据，分10个 shards，然后，一个搜索请求，from=1000000，size=100，这时候，会带来严重的性能问题：CPU，内存，IO，网络带宽。 在 query 阶段，每个shards需要返回 1000100 条数据给 coordinating node，而 coordinating node 需要接收 10 * 1000 ，100 条数据，即使每条数据只有 _doc _id 和 _score ，这数据量也很大了？ 「在另一方面，我们意识到，这种深度分页的请求并不合理，因为我们是很少人为的看很后面的请求的，在很多的业务场景中，都直接限制分页，比如只能看前100页。」 比如，有1千万粉丝的微信大V，要给所有粉丝群发消息，或者给某省粉丝群发，这时候就需要取得所有符合条件的粉丝，而最容易想到的就是利用 from + size 来实现，不过，这个是不现实的，这时，可以采用 Elasticsearch 提供的其他方式来实现遍历。 深度分页问题大致可以分为两类： 「下面介绍几个官方提供的深度分页方法」 我们可以把scroll理解为关系型数据库里的cursor，因此，scroll并不适合用来做实时搜索，而更适合用于后台批处理任务，比如群发。 这个分页的用法， 「不是为了实时查询数据」 ，而是为了 「一次性查询大量的数据（甚至是全部的数据」 ）。 因为这个scroll相当于维护了一份当前索引段的快照信息，这个快照信息是你执行这个scroll查询时的快照。在这个查询后的任何新索引进来的数据，都不会在这个快照中查询到。 但是它相对于from和size，不是查询所有数据然后剔除不要的部分，而是记录一个读取的位置，保证下一次快速继续读取。 不考虑排序的时候，可以结合 SearchType.SCAN 使用。 scroll可以分为初始化和遍历两部，初始化时将 「所有符合搜索条件的搜索结果缓存起来（注意，这里只是缓存的doc_id，而并不是真的缓存了所有的文档数据，取数据是在fetch阶段完成的）」 ，可以想象成快照。 在遍历时，从这个快照里取数据，也就是说，在初始化后，对索引插入、删除、更新数据都不会影响遍历结果。 「基本使用」 初始化指明 index 和 type，然后，加上参数 scroll，表示暂存搜索结果的时间，其它就像一个普通的search请求一样。 会返回一个 _scroll_id ， _scroll_id 用来下次取数据用。 「遍历」 这里的 scroll_id 即 上一次遍历取回的 _scroll_id 或者是初始化返回的 _scroll_id ，同样的，需要带 scroll 参数。 重复这一步骤，直到返回的数据为空，即遍历完成。 「注意，每次都要传参数 scroll，刷新搜索结果的缓存时间」 。另外， 「不需要指定 index 和 type」 。 设置scroll的时候，需要使搜索结果缓存到下一次遍历完成， 「同时，也不能太长，毕竟空间有限。」 「优缺点」 缺点： 「优点：」 适用于非实时处理大量数据的情况，比如要进行数据迁移或者索引变更之类的。 ES提供了scroll scan方式进一步提高遍历性能，但是scroll scan不支持排序，因此scroll scan适合不需要排序的场景 「基本使用」 Scroll Scan 的遍历与普通 Scroll 一样，初始化存在一点差别。 需要指明参数： 「Scroll Scan与Scroll的区别」 如果你数据量很大，用Scroll遍历数据那确实是接受不了，现在Scroll接口可以并发来进行数据遍历了。 每个Scroll请求，可以分成多个Slice请求，可以理解为切片，各Slice独立并行，比用Scroll遍历要快很多倍。 上边的示例可以单独请求两块数据，最终五块数据合并的结果与直接scroll scan相同。 其中max是分块数，id是第几块。 Search_after 是 ES 5 新引入的一种分页查询机制，其原理几乎就是和scroll一样，因此代码也几乎是一样的。 「基本使用：」 第一步： 返回出的结果信息 ： 上面的请求会为每一个文档返回一个包含sort排序值的数组。 这些sort排序值可以被用于 search_after 参数里以便抓取下一页的数据。 比如，我们可以使用最后的一个文档的sort排序值，将它传递给 search_after 参数： 若我们想接着上次读取的结果进行读取下一页数据，第二次查询在第一次查询时的语句基础上添加 search_after ，并指明从哪个数据后开始读取。 「基本原理」 es维护一个实时游标，它以上一次查询的最后一条记录为游标，方便对下一页的查询，它是一个无状态的查询，因此每次查询的都是最新的数据。 由于它采用记录作为游标，因此 「SearchAfter要求doc中至少有一条全局唯一变量（每个文档具有一个唯一值的字段应该用作排序规范）」 「优缺点」 「优点：」 「缺点：」 SEARCH_AFTER 不是自由跳转到任意页面的解决方案，而是并行滚动多个查询的解决方案。 分页方式性能优点缺点场景 from + size低灵活性好，实现简单深度分页问题数据量比较小，能容忍深度分页问题 scroll中解决了深度分页问题无法反应数据的实时性（快照版本）维护成本高，需要维护一个 scroll_id海量数据的导出需要查询海量结果集的数据 search_after高性能最好不存在深度分页问题能够反映数据的实时变更实现复杂，需要有一个全局唯一的字段连续分页的实现会比较复杂，因为每一次查询都需要上次查询的结果，它不适用于大幅度跳页查询海量数据的分页 参照：https://www.elastic.co/guide/en/elasticsearch/reference/master/paginate-search-results.html#scroll-search-results 在 7.* 版本中，ES官方不再推荐使用Scroll方法来进行深分页，而是推荐使用带PIT的 search_after 来进行查询； 从 7.* 版本开始，您可以使用 SEARCH_AFTER 参数通过上一页中的一组排序值检索下一页命中。 使用 SEARCH_AFTER 需要多个具有相同查询和排序值的搜索请求。 如果这些请求之间发生刷新，则结果的顺序可能会更改，从而导致页面之间的结果不一致。 为防止出现这种情况，您可以创建一个时间点(PIT)来在搜索过程中保留当前索引状态。 在搜索请求中指定PIT： 分别分页获取 1 - 10 ， 49000 - 49010 ， 99000 - 99010 范围各10条数据（前提10w条），性能大致是这样： 对于向前翻页，ES中没有相应API，但是根据官方说法（https://github.com/elastic/elasticsearch/issues/29449），ES中的向前翻页问题可以通过翻转排序方式来实现即： Scroll和 search_after 原理基本相同，他们都采用了游标的方式来进行深分页。 这种方式虽然能够一定程度上解决深分页问题。但是，它们并不是深分页问题的终极解决方案，深分页问题 「必须避免！!」 。 对于Scroll，无可避免的要维护 scroll_id 和 历史 快照，并且，还必须保证 scroll_id 的存活时间，这对服务器是一个巨大的负荷。 对于 Search_After ，如果允许用户大幅度跳转页面，会导致短时间内频繁的搜索动作，这样的效率非常低下，这也会增加服务器的负荷，同时，在查询过程中，索引的增删改会导致查询数据不一致或者排序变化，造成结果不准确。 Search_After 本身就是一种业务折中方案，它不允许指定跳转到页面，而只提供下一页的功能。 Scroll默认你会在后续将所有符合条件的数据都取出来，所以，它只是搜索到了所有的符合条件的 doc_id (这也是为什么官方推荐用 doc_id 进行排序，因为本身缓存的就是 doc_id ，如果用其他字段排序会增加查询量)，并将它们排序后保存在协调节点(coordinate node)，但是并没有将所有数据进行fetch，而是每次scroll，读取size个文档，并返回此次读取的最后一个文档以及上下文状态，用以告知下一次需要从哪个shard的哪个文档之后开始读取。 这也是为什么官方不推荐scroll用来给用户进行实时的分页查询，而是适合于大批量的拉取数据，因为它从设计上就不是为了实时读取数据而设计的。

前面已经介绍了ElasticSearch的写入流程，了解了ElasticSearch写入时的分布式特性的相关原理。ElasticSearch作为一款具有强大搜索功能的存储引擎，它的读取是什么样的呢？读取相比写入简单的多，但是在使用过程中有哪些需要我们注意的呢？本篇文章会进行详细的分析。 在前面的文章我们已经知道ElasticSearch的读取分为两种GET和SEARCH。这两种操作是有一定的差异的，下面我们先对这两种核心的数据读取方式进行一一分析。 （图片来自官网） 以下是从主分片或者副本分片检索文档的步骤顺序： 注意： 在协调节点有个http_server_worker线程池。收到读请求后它的具体过程为： 数据节点上有一个get线程池。收到了请求后，处理过程为： 注意： get过程会加读锁。处理realtime选项，如果为true，则先判断是否有数据可以刷盘，然后调用Searcher进行读取。Searcher是对IndexSearcher的封装在早期realtime为true则会从tranlog中读取，后面只会从index的lucene读取了。即实时的数据只在lucene之中。 对于Search类请求，ElasticSearch请求是查询lucene的Segment，前面的写入详情流程也分析了，新增的文档会定时的refresh到磁盘中，所以搜索是属于近实时的。而且因为没有文档id，你不知道你要检索的文档在哪个分配上，需要将索引的所有的分片都去搜索下，然后汇总。ElasticSearch的search一般有两个搜索类型 所有的搜索系统一般都是两阶段查询： 第一阶段查询到匹配的docID，第二阶段再查询DocID对应的完整文档。这种在ElasticSearch中称为query_then_fetch，另一种就是一阶段查询的时候就返回完整Doc，在ElasticSearch中叫query_and_fetch，一般第二种适用于只需要查询一个Shard的请求。因为这种一次请求就能将数据请求到，减少交互次数，二阶段的原因是需要多个分片聚合汇总，如果数据量太大那么会影响网络传输效率，所以第一阶段会先返回id。 除了上述的这两种查询外，还有一种三阶段查询的情况。 搜索里面有一种算分逻辑是根据TF和DF来计算score的，而在普通的查询中，第一阶段去每个Shard中独立查询时携带条件算分都是独立的，即Shard中的TF和DF也是独立的。虽然从统计学的基础上数据量多的情况下，每一个分片的TF和DF在整体上会趋向于准确。但是总会有情况导致局部的TF和DF不准的情况出现。 ElasticSearch为了解决这个问题引入了DFS查询。 比如DFS_query_then_fetch，它在每次查询时会先收集所有Shard中的TF和DF值，然后将这些值带入请求中，再次执行query_then_fetch，这样算分的时候TF和DF就是准确的，类似的有DFS_query_and_fetch。这种查询的优势是算分更加精准，但是效率会变差。 另一种选择是用BM25代替TF/DF模型。 在ElasticSearch7.x，用户没法指定以下两种方式： DFS_query_and_fetch 和 query_and_fetch 。 注：这两种算分的算法模型在《ElasticSearch实战篇》有介绍： 这里query_then_fetch具体的搜索的流程图如下： （图片来自官网） 查询阶段包含以下四个步骤: 以上就是ElasticSearch的search的详细流程，下面会对每一步进行进一步的说明。 协调节点处理query请求的线程池为： http_server_work 负责该解析功能的类为： org.elasticsearch.rest.action.search.RestSearchAction 主要将restquest的参数封装成SearchRequest 这样SearchRequest请求发送给TransportSearchAction处理 将索引涉及到的shard列表或者有跨集群访问相关的shard列表合并 如果有多个分片位于同一个节点，仍然会发送多次请求 shardsIts为搜索涉及的所有分片，而shardRoutings.nextOrNull()会从分片的所有副本分片选出一个分片来请求。 onShardSuccess对收集到的结果进行合并，这里需要检查所有的请求是否都已经有了回复。 然后才会判断要不要进行executeNextPhase 当返回结果的分片数等于预期的总分片数时，协调节点会进入当前Phase的结束处理，启动下一个阶段Fetch Phase的执行。onPhaseDone()会executeNextPhase来执行下一个阶段。 当触发了executeNextPhase方法将触发fetch阶段 上一步的executeNextPhase方法触发Fetch阶段，Fetch阶段的起点为FetchSearchPhase#innerRun函数，从查询阶段的shard列表中遍历，跳过查询结果为空的 shard。其中也会封装一些分页信息的数据。 使用了countDown多线程工具，fetchResults存储某个分片的结果，每收到一个shard的数据就countDoun一下，当都完毕后，触发finishPhase。接着会进行下一步： CountedCollector: finishPhase: 执行字段折叠功能，有兴趣可以研究下。即ExpandSearchPhase模块。ES 5.3版本以后支持的Field Collapsing查询。通过该类查询可以轻松实现按Field值进行分类，每个分类获取排名前N的文档。如在菜单行为日志中按菜单名称（用户管理、角色管理等）分类，获取每个菜单排名点击数前十的员工。用户也可以按Field进行Aggregation实现类似功能，但Field Collapsing会更易用、高效。 ExpandSearchPhase执行完了，就返回给客户端结果了。 处理数据节点请求的线程池为：search 根据前面的两个阶段，数据节点主要处理协调节点的两类请求：query和fetch 这里响应的请求就是第一阶段的query请求 executeQueryPhase: executeQueryPhase会执行loadOrExecuteQueryPhase方法 这里判断是否从缓存查询，默认启用缓存，缓存的算法默认为LRU，即删除最近最少使用的数据。如果不启用缓存则会执行queryPhase.execute(context);底层调用lucene进行检索，并且进行聚合。 关键点： ElasticSearch查询分为两类，一类为GET，另一类为SEARCH。它们使用场景不同。 本文主要分析了ElasticSearch分布式查询主体流程，并未对lucene部分进行分析，有兴趣的可以自行查找相关资料。

Elasticsearch 是一个开源的搜索引擎，建立在一个全文搜索引擎库 Apache Lucene基础之上。但是Lucene只是一个工具类库，且接口较为复杂。你必须先理解搜索引擎的工作原理，才能有效利用Lucene。ElasticSearch通过隐藏Lucene背后复杂的搜索理论知识，预设了搜索引擎默认的参数，只需要最少的理解，就能快速搭建出搜索引擎，开箱即用。 1. 索引（Index） ElasticSearch的Index类似于关系型数据库的Database，用来存储各种类型的文档。一个索引应该是因共同的特性被分组到一起的文档集合。 以Google作为栗子，我们可以把Index理解为Google所抓取网页（文档）存储的地方。 2. 类型（Type） Type类似于关系型数据库的Table，用来存储相似文档的地方。 以Google作为栗子，我们可以把网页、图片、视频等不同类型的搜索，存放在不同的Type里面。 3. 文档（Document） Document类似于关系型数据库里面的Row，存储具体的一个对象。 ElasticSearch的文档是以JSON格式存储的。形如： 以Google作为栗子，一个网页就是一个文档。 4. 字段（Field） Field类似于关系型数据库的Column，存储某一个具体的属性。 以Google作为栗子，网页的标题（Title）就是一个字段。 注意： ElasticSearch的Type与传统关系型数据库的Table不一样的地方在于：同一个Index下的Type，名称相同的Field，类型要保持一致。 以Google作为栗子，当Google把网页类型的文档和图片类型的文档都存储在同一个Index下面时，假设网页和图片都有一个Title属性，那么在同一个Index下面，这两个属性的类型必须保持一致，比如必须都是String类型的。因为ElasticSearch更倾向于存储同构类型的文档。 下载安装包，并解压到/opt目录下 编辑elasticsearch.yml文件 vim/opt/elasticsearch-2.4.4/config/elasticsearch.yml 启动项目 安装head插件 打开浏览器访问页面：http://192.168.204.151:9200/_plugin/head/

之前我们已经了解过，Elasticsearch 是一个基于 Lucene 实现的分布式全文检索引擎，其实 Elasticsearch 倒排索引就是 Lucene 的倒排索引。数据检索是 ES 的一项核心功能，它的底层实现也是离不开倒排索引的，通过倒排索引技术可以提高数据的检索效率，理解倒排索引的原理很重要。 那什么是倒排索引，我们该如何理解它呢？ 我们能进行数据检索的前提条件是，已经创建好了索引库，并给里边添加了文档数据。所以我们可以按照 创建索引库 、 添加文档 、 数据检索 这个顺序来认识倒排索引。 首先是创建索引库，我们之前已经安装好了 IK 分词器，这里我们创建一个 test 索引，它只有一个 content 字段，添加文档时字段的分词模式是 ik_max_word ，检索时关键字的分词模式是 ik_smart ： 字段的分词模式会影响最终生成的倒排索引。不了解分词器的可以参考 Elasticsearch 中文分词器插件 。 创建好了索引，我们来添加一条文档数据： 添加文档数据时，ES 会根据字段的分词模式将字段的值拆分成多个 词条 （Term）（或者称作词项），创建索引库时我们指定了 content 字段分词模式为 ik_max_word ，则会生成如下的词条： 接下来就是建立倒排索引了，在这之前我们先了解两个概念 词条字典 （Term Dictionary）、 倒排列表 （Posting List）： ES 的倒排索引就是由 词条字典 和 倒排列表 两部分组成的。如下就是一个简易版的倒排索引，倒排列表项只有词条对应的文档 id： 一个词条对应一个倒排索引项。ES 会给每个字段都建立一个倒排索引。 我们再添加一条文档数据： 根据上边的原理，最终 content 字段的倒排索引会被更新成如下结构： 前边已经添加了文档数据，同时也生成了倒排索引，接下来就是检索数据了。在这之前还有一个知识点需要了解，那就是 词条索引 （Term Index），词条索引一般只存储各个 词条 的前缀（第一个字符），它和字条字典对应。之所以需要词条索引，是因为 词条字典 一般都很大，不适合保存在内存中而是存储在磁盘中，检索数据时根据关键字的前缀匹配到词条索引，再根据词条索引定位到关键字在倒排索引的词条字典中大致的位置，然后进一步在词条字典中通过二分查找定位到具体的词条，这样避免了直接遍历词条字典来点位词条，大幅减少了磁盘的读取，提高了效率。 定位到了词条，就能在倒排索引中找到对应的倒排列表项，进而就知道了对应的文档 id，有了文档 id 自然也就找到了文档，这也就是 ES 检索数据大致的原理。 如下我们查询包含 十二 的文档数据： 由于我们创建索引库时指定了检索时关键字的分词模式是 ik_smart ，所以 十二 被分词后还是 十二 ，再结合上边的原理，以 十二 为关键字最终可以查询到 id 为 1、2 的文档数据：这篇最好能结合 Elasticsearch 中文分词器插件 一起看，这样能更容易理解些。 新手上路，不合理的地方还望大佬指点。

Elasticsearch是什么?Elasticsearch是位于ElasticStack核心的分布式搜索和分析引擎。Logstash和Beats有助于收集、聚合和丰富您的数据并将其存储在Elasticsearch中。Kibana使您能够以交互方式探索、可视化和分享对数据的见解，并管理。Elasticsearch是一个分布式文档存储。Elasticsearch存储的是序列化为JSON文档的复杂数据结构，而不是以列行数据的形式存储信息。当集群中有多个Elasticsearch节点时，存储的文档分布在整个集群中，可以立即从任何节点访问。Elasticsearch是由Shay Banon发起的一个开源搜索服务器项目，2010年2月发布。迄今，该项目已发展成为搜索和数据分析解决方案领域的主要一员，广泛应用于声名卓著或鲜为人知的搜索应用程序。Elasticsearch是一个高度可扩展的开源全文搜索和分析引擎。它可以在很短的时间内存储，搜索和分析大量的数据。它通常作为具有复杂搜索场景情况下的核心发动机。搜索引擎，不支持join表等操作。主要用于全文检索。不适合做数据库。如何选择合适的数据库解决方案？1、如果有强大的技术团队，关系型和非关系型数据库都可选择。一般来讲，非关系型数据库需要更多管理维护的时间。2、如果你要储存会话信息，用户配置信息，购物车数据，建议使用NoSQL数据库； 不过90%的企业或个人，首选数据库都是MySQL数据库。3、(一)、Access (二)SQL Server (三)MySQL，Access是一种桌面数据库，只适合数据量少的应用，在处理少量数据和单机访问的数据库时是很好的，效率也很高。但是它的同时访问客户端不能多于4个。4、虽然把上面的架构全部组合在一起可以形成一个强大的高可用，高负载的数据库系统，但是架构选择合适才是最重要的。 混合架构虽然能够解决所有的场景的问题，但是也会面临更多的挑战，你以为的完美架构，背后其实有着更多的坑。5、例如，如果你需要的是数据分析仓库，关系数据库可能不是一个适合的选择；如果你处理事务的应用要求严格的数据完整性和一致性，就不要考虑NoSQL了。不要重新发明轮子 在过去的数十年，开源数据库技术迅速发展壮大。6、本文首先讨论了基于第三范式的数据库表的基本设计，着重论述了建立主键和索引的策略和方案，然后从数据库表的扩展设计和库表对象的放置等角度概述了数据库管理系统的优化方案。ElasticSearch倒排索引及其原理1、倒排索引采用Immutable Design，一旦生成，不可更改。Segment写入磁盘的过程相对耗时，所以借助文件系统缓存，Refresh时，先将Segment写入文件缓存中，以开放查询。2、之前我们已经了解过，Elasticsearch 是一个基于 Lucene 实现的分布式全文检索引擎，其实 Elasticsearch 倒排索引就是 Lucene 的倒排索引。3、所谓的倒排索引，就是把你的数据内容先分词，每句话分成一个一个的关键词，然后记录好每一个关键词对应出现在了哪些 id 标识的数据。4、可以将对es的操作记录下来，来确保当出现故障的时候，已经落地到磁盘的数据不会丢失，并在重启的时候可以从操作记录中将数据恢复过来。5、Elasticsearch中使用一种称为倒排索引的结构，适用于快速的全文搜索。一个倒排索引由文档中所有不能重复词的列表构成，对于其中每个词，有一个包含它的文档列表。elasticsearch-倒排索引原理1、倒排索引采用Immutable Design，一旦生成，不可更改。Segment写入磁盘的过程相对耗时，所以借助文件系统缓存，Refresh时，先将Segment写入文件缓存中，以开放查询。2、Elasticsearch中使用一种称为倒排索引的结构，适用于快速的全文搜索。一个倒排索引由文档中所有不能重复词的列表构成，对于其中每个词，有一个包含它的文档列表。3、elasticsearch提供了translog来记录这些操作，结合os cached segments数据定时落盘来实现数据可靠性保证（flush）。文档被添加到buffer同时追加到translog：进行 refresh 操作，清空buffer，文档可被搜索但尚未 flush 到磁盘。4、如果Elasticsearch密钥库受密码保护，则必须先输入密钥库密码，然后才能为内置用户设置密码。 为弹性用户设置密码后，引导密码不再有效，无法使用该命令。在某些情况下，分片副本的Lucene索引或事务日志可能会损坏。5、Elasticsearch 的查询原理是将查询的关键词与倒排索引中的词条进行匹配，查询的关键词与倒排索引中的词条必须完全相同视为匹配，否则不匹配。 这意味着在插入文档时是否进行分析和查询时是否进行分析将产生非常不同的结果。6、财务平台亿级数据量毫秒级查询优化之elasticsearch原理解析_wang123459的博客-CSDN博客_elasticsearch 查询优化 mysql底层B-tree 支持矮胖，高胖的时候就很难受，说白了就是数据量多会增加IO操作。ES底层倒排索引。Elasticsearch一般情况下如果es服务正常启动，可以通过接口的方式获取elasticsearch版本信息：curlhttp：//10.1：9200 上述命令可以得到elasticsearch的服务状态和其他信息包括版本号。Elasticsearch 是位于 Elastic Stack 核心的分布式搜索和分析引擎。Logstash 和 Beats 有助于收集、聚合和丰富您的数据并将其存储在 Elasticsearch 中。ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。Elasticsearch架构简单介绍如下。索引 索引（index）是Elasticsearch对逻辑数据的逻辑存储，所以它可以分为更小的部分。你可以把索引看成关系型数据库的表。然而，索引的结构是为快速有效的全文索引准备的，特别是它不存储原始值。如何用elasticsearch5.2实现全文索引1、安装ik分词器到elasticsearch很简单，它有个插件目录analysis-ik，和一个配置目录ik， 分别拷贝到plugins和conf目录就可以了。2、ES使用倒序索引来加速全文索引。一个倒序索引由两部分组成：如果我们想要搜索 quick brown，我们仅仅只需要找每一个term出现的文档即可。如下图：每一个文档都匹配到了，但是第一个比第二个要匹配的多。3、每次将文本类型数据插入Elasticsearch索引时，都会对其进行分析，然后存储在反向索引中。根据分析器的配置方式，这会影响您的搜索功能，因为分析器也适用于全文搜索。

一、高亮的一些问题 elasticsearch提供了三种高亮方式，前面我们已经简单的了解了elasticsearch的高亮原理; 高亮处理跟实际使用查询类型有十分紧密的关系，其中主要的一点就是muti term 查询的重写，例如wildcard、prefix等，由于查询本身和高亮都涉及到查询语句的重写，如果两者之间的重写机制不同，那么就可能会碰到以下情况 相同的查询语句， 使用unified和fvh得到的高亮结果是不同的，甚至fvh Highlighter无任何高亮信息返回； 二、数据环境 elasticsearch 8.0 三、muti term查询重写简介 所谓muti term查询就是查询中并不是明确的关键字，而是需要elasticsearch重写查询语句，进一步明确关键字；以下查询会涉及到muti term查询重写； 以上查询都支持rewrite参数，最终将查询重写为bool查询或者bitset； 查询重写主要影响以下几方面 重写需要抓取哪些关键字以及抓取的数量； 抓取关键字的相关性计算方式； 查询重写支持以下参数选项 constant_score，默认值，如果需要抓取的关键字比较少，则重写为bool查询，否则抓取所有的关键字并重写为bitset；直接使用boost参数作为文档score，一般term level的查询的boost默认值为1； constant_score_boolean，将查询重写为bool查询，并使用boost参数作为文档的score，受到indices.query.bool.max_clause_count 限制，所以默认最多抓取1024个关键字； scoring_boolean，将查询重写为bool查询，并计算文档的相对权重，受到indices.query.bool.max_clause_count 限制，所以默认最多抓取1024个关键字； top_terms_blended_freqs_N，抓取得分最高的前N个关键字，并将查询重写为bool查询；此选项不受indices.query.bool.max_clause_count 限制；选择命中文档的所有关键字中权重最大的作为文档的score； top_terms_boost_N，抓取得分最高的前N个关键字，并将查询重写为bool查询；此选项不受indices.query.bool.max_clause_count 限制；直接使用boost作为文档的score； top_terms_N，抓取得分最高的前N个关键字，并将查询重写为bool查询；此选项不受indices.query.bool.max_clause_count 限制；计算命中文档的相对权重作为评分； 三、wildcard查询重写分析 我们通过elasticsearch来查看一下以下查询语句的重写逻辑； 通过查询使用的字段映射类型构建WildCardQuery，并使用查询语句中配置的rewrite对应的MultiTermQuery.RewriteMethod； 根据查询语句中配置的rewrite，查找对应的MultiTermQuery.RewriteMethod，由于我们没有在wildcard查询语句中设置rewrite参数，这里直接返回null； WildCardQuery继承MultiTermQuery，直接调用rewrite方法进行重写，由于我们没有在wildcard查询语句中设置rewrite参数，这里直接使用默认的CONSTANT_SCORE_REWRITE； 可以看到CONSTANT_SCORE_REWRITE是直接使用的匿名类，rewrite方法返回的是MultiTermQueryConstantScoreWrapper的实例； 在以下方法中，首先会得到查询字段对应的所有term集合； 然后通过 query.getTermsEnum获取跟查询匹配的所有term集合； 最后根据collectTerms调用的返回值决定是否构建bool查询还是bit set； 调用collectTerms默认只会提取查询命中的16个关键字； 通过以上分析wildcard查询默认情况下，会提取字段中所有命中查询的关键字； 四、fvh Highlighter中wildcard的查询重写 在muti term query中，提取查询关键字是高亮逻辑一个很重要的步骤； 我们使用以下高亮语句，分析以下高亮中提取查询关键字过程中的查询重写； 默认情况下只有匹配的字段才会进行高亮，这里构建CustomFieldQuery； 通过调用flatten方法得到重写之后的flatQueries，然后将每个提取的关键字重写为BoostQuery； 由于WildCardQuery是MultiTermQuery的子类，所以在flatten方法中最终直接使用MultiTermQuery.TopTermsScoringBooleanQueryRewrite进行查询重写，这里的top N是MAX_MTQ_TERMS = 1024； 这里首先计算设置的size和getMaxSize(默认值1024， IndexSearcher.getMaxClauseCount())计算最终提取的命中关键字数量，这里最终是1024个； 这里省略了传入collectTerms的TermCollector匿名子类的实现，其余最终提取关键字数量有关； 这里首先获取查询字段对应的所有term集合，然后获取所有的与查询匹配的term集合，最终通过传入的collector提取关键字； 这里通过控制最终提取匹配查询的关键字的数量不超过maxSize； 通过以上分析可以看到，fvh Highlighter对multi term query的重写，直接使用MultiTermQuery.TopTermsScoringBooleanQueryRewrite，并限制只能最多提取查询关键字1024个； 五、重写可能导致的高亮问题原因分析 经过以上对查询和高亮的重写过程分析可以知道，默认情况下 query阶段提取的是命中查询的所有的关键字，具体行为可以通过rewrite参数进行定制； Highlight阶段提取的是命中查询的关键字中的前1024个，具体行为不受rewrite参数的控制； 如果查询的字段是大文本字段，导致字段的关键字很多，就可能会出现查询命中的文档的关键字不在前1024个里边，从而导致明明匹配了文档，但是却没有返回高亮信息； 六、解决方案

倒排索引采用Immutable Design，一旦生成，不可更改。 Segment写入磁盘的过程相对耗时，所以借助文件系统缓存，Refresh时，先将Segment写入文件缓存中，以开放查询。但为了保证数据不会丢失，所以在创建索引时，会同时写Tansaction Log，类似操作日志。 在ES进行Refresh时，Index Buffer会被清空，Transaction Log不会清空。 Flush操作： Flush触发条件： 随着索引的不断创建，Segments文件会越来越多。ES会自动进行merge操作，将多个segments文件合并，以提高查询效率。但Merge是很重的操作，对磁盘有频繁IO操作，会对系统性能有影响。 除此之外，我们还可以通过api强制merge： 我们还可以通过配置refresh的频率（refresh_interval），来适当减少Segments产生的数量。

首先理解三个概念 1）集群内的节点共同承担数据和负载的压力。 2）当有节点加入或者移出集群时，集群会重新平均分配所有的数据。 1）主节点负责集群内的所有变更（如增加、删除节点，增加、删除索引等） 2）主节点并不需要涉及到文档级别的变更和搜索 3）任何节点都可以成为主节点 4）每个节点都知道任意文档所处的位置，当用户请求时无论请求哪个节点都能直接将请求转发给实际存储文档的节点 5）无论用户请求哪个节点，它都能负责从个个包含我们所需文档的各个节点收集回数据并发给客户端，对这一切都是透明的 1）一个分片是一个底层的 工作单元 2）它本身就是一个完整的搜索引擎 3）应用程序是直接与索引而不是与分片进行交互 4）Elasticsearch 是利用分片将数据分发到集群内各处的 5）分片是数据的容器，文档保存在分片内 6）分片又被分配到集群内的各个节点里 7） 当你的集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。 8）一个分片可以是 主分片 或者 副本分片 9）索引内任意一个文档都归属于一个主分片，所以主分片的数目决定着索引能够保存的最大数据量 10）一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务 11）在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改 其中 status 字段表示当前集群的健康状态（是否正常工作），有三种颜色

倒排索引被写入磁盘后是不可变的，ES解决不变性和更新索引的方式是使用多个索引，利用新增的索引来反映修改，在查询时从旧的到新的依次查询，最后来一个结果合并。 ES底层是基于Lucene，最核心的概念就是 Segment(段) ，每个段本身就是一个倒排索引。 ES中的Index由多个段的集合和 commit point(提交点) 文件组成。 提交点文件中有一个列表存放着所有已知的段，下面是一个带有1个提交点和3个段的Index示意图： Doc会先被搜集到内存中的Buffer内，这个时候还无法被搜索到，如下图所示： 每隔一段时间，会将buffer提交，在flush磁盘后打开新段使得搜索可见，详细过程如下： 下面展示了这个过程完成后的段和提交点的状态： 通过这种方式，可以使得新文档从被索引到可被搜索间的时间间隔在数分钟，但是还不够快。因为磁盘需要 fsync ，这个就成为性能瓶颈。我们前面提到过Doc会先被从buffer刷入段写入文件系统缓存（很快），那么就自然想到在这个阶段就让文档对搜索可见，随后再被刷入磁盘（较慢）。 Lucene支持对新段写入和打开，可以使文档在没有完全刷入硬盘的状态下就能对搜索可见，而且是一个开销较小的操作，可以频繁进行。 下面是一个已经将Docs刷入段，但还没有完全提交的示意图： 我们可以看到，新段虽然还没有被完全提交，但是已经对搜索可见了。 引入refresh操作的目的是提高ES的实时性，使添加文档尽可能快的被搜索到，同时又避免频繁fsync带来性能开销，依靠的就是文件系统缓存OS cache里缓存的文件可以被打开(open/reopen)和读取，而这个os cache实际是一块内存区域，而非磁盘，所以操作是很快的，这就是ES被称为近实时搜索的原因。 refresh默认执行的间隔是1秒，可以使用 refreshAPI 进行手动操作，但一般不建议这么做。还可以通过合理设置 refresh_interval 在近实时搜索和索引速度间做权衡。 index segment刷入到os cache后就可以打开供查询，这个操作是有潜在风险的，因为os cache中的数据有可能在意外的故障中丢失，而此时数据必备并未刷入到os disk，此时数据丢失将是不可逆的，这个时候就需要一种机制，可以将对es的操作记录下来，来确保当出现故障的时候，已经落地到磁盘的数据不会丢失，并在重启的时候可以从操作记录中将数据恢复过来。elasticsearch提供了translog来记录这些操作，结合os cached segments数据定时落盘来实现数据可靠性保证（flush）。 文档被添加到buffer同时追加到translog： 进行 refresh 操作，清空buffer，文档可被搜索但尚未 flush 到磁盘。translog不会清空： 每隔一段时间（例如translog变得太大），index会被flush到磁盘，新的translog文件被创建，commit执行结束后，会发生以下事件： 下面示意图展示了这个状态： translog记录的是已经 在内存生成(segments)并存储到os cache但是还没写到磁盘的那些索引操作 （注意，有一种解释说，添加到buffer中但是没有被存入segment中的数据没有被记录到translog中，这依赖于写translog的时机，不同版本可能有变化，不影响理解），此时这些新写入的数据可以被搜索到，但是当节点挂掉后这些未来得及落入磁盘的数据就会丢失，可以通过trangslog恢复。 当然translog本身也是磁盘文件，频繁的写入磁盘会带来巨大的IO开销，因此对translog的追加写入操作的同样操作的是os cache，因此也需要定时落盘（fsync）。translog落盘的时间间隔直接决定了ES的可靠性，因为宕机可能导致这个时间间隔内所有的ES操作既没有生成segment磁盘文件，又没有记录到Translog磁盘文件中，导致这期间的所有操作都丢失且无法恢复。 translog的fsync是ES在后台自动执行的，默认是每5秒钟主动进行一次translog fsync，或者当translog文件大小大于512MB主动进行一次fsync，对应的配置是 index.translog.flush_threshold_period 和 index.translog.flush_threshold_size 。 当 Elasticsearch 启动的时候， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。 translog 也被用来提供实时 CRUD 。当你试着通过ID来RUD一个Doc，它会在从相关的段检索之前先检查 translog 中最新的变更。 默认 translog 是每5秒或是每次请求完成后被 fsync 到磁盘（在主分片和副本分片都会）。也就是说，如果你发起一个index, delete, update, bulk请求写入translog并被fsync到主分片和副本分片的磁盘前不会反回200状态。 这样会带来一些性能损失，可以通过设为异步fsync，但是必须接受由此带来的丢失少量数据的风险： flush 就是执行commit清空、干掉老translog的过程。默认每个分片30分钟或者是translog过于大的时候自动flush一次。可以通过flush API手动触发，但是只会在重启节点或关闭某个索引的时候这样做，因为这可以让未来ES恢复的速度更快(translog文件更小)。 满足下列条件之一就会触发冲刷操作： 整体流程： 删除一个ES文档不会立即从磁盘上移除，它只是被标记成已删除。因为段是不可变的，所以文档既不能从旧的段中移除，旧的段也不能更新以反映文档最新的版本。 ES的做法是，每一个提交点包括一个 .del 文件（还包括新段），包含了段上已经被标记为删除状态的文档。所以，当一个文档被做删除操作，实际上只是在 .del 文件中将该文档标记为删除，依然会在查询时被匹配到，只不过在最终返回结果之前会被从结果中删除。ES将会在用户之后添加更多索引的时候，在后台进行要删除内容的清理。 文档的更新操作和删除是类似的：当一个文档被更新，旧版本的文档被标记为删除，新版本的文档在新的段中索引。 该文档的不同版本都会匹配一个查询，但是较旧的版本会从结果中删除。 通过每秒自动刷新创建新的段，用不了多久段的数量就爆炸了，每个段消费大量文件句柄，内存，cpu资源。更重要的是，每次搜索请求都需要依次检查每个段。段越多，查询越慢。 ES通过后台合并段解决这个问题。ES利用段合并的时机来真正从文件系统删除那些version较老或者是被标记为删除的文档。被删除的文档（或者是version较老的）不会再被合并到新的更大的段中。 可见，段合并主要有两个目的： ES对一个不断有数据写入的索引处理流程如下： 合并过程如图： 从上图可以看到，段合并之前，旧有的Commit和没Commit的小段皆可被搜索。 段合并后的操作: 合并完成后新的段可被搜索，旧的段被删除，如下图所示： 注意 ：段合并过程虽然看起来很爽，但是大段的合并可能会占用大量的IO和CPU，如果不加以控制，可能会大大降低搜索性能。段合并的optimize API 不是非常特殊的情况下千万不要使用，默认策略已经足够好了。不恰当的使用可能会将你机器的资源全部耗尽在段合并上，导致无法搜索、无法响应。

分布式搜索引擎：把大量的索引数据拆散成多块，每台机器放一部分，然 后利用多台机器对分散之后的数据进行搜索，所有操作全部是分布在多台机器上进行，形成了 完整的分布式的架构。 近实时，有两层意思： 集群包含多个节点，每个节点属于哪个集群都是通过一个配置来决定的， Node 是集群中的一个节点，节点也有一个名称，默认是随机分配的。默认节点会去加入一个名 称为 elasticsearch 的集群。如果直接启动一堆节点，那么它们会自动组成一个elasticsearch 集群，当然一个节点也可以组成 elasticsearch 集群。 文档是 es 中最小的数据单元，一个 document 可以是1条客户数据、1条商品分类数据、1条 订单数据，通常用json 数据结构来表示。每个 index 下的 type，都可以存储多条 document。 1个 document 里面有多个 field，每个 field 就是1个数据字段。 es 集群多个节点，会自动选举1个节点为 master 节点，这个 master 节点其实就是干一些管理 的工作的，比如维护索引元数据、负责切换 primary shard 和 replica shard 身份等。要是 master 节点宕机了，那么会重新选举1个节点为 master 节点。 如果是非 master节点宕机了，那么会由 master 节点，让那个宕机节点上的 primary shard 的身 份转移到其他机器上的 replica shard。接着你要是修复了那个宕机机器，重启了之后，master 节点会控制将缺失的 replica shard 分配过去，同步后续修改的数据之类的，让集群恢复正常。 说得更简单1点，就是说如果某个非 master 节点宕机了，那么此节点上的 primary shard 不就 没了。那好，master 会让 primary shard 对应的 replica shard（在其他机器上）切换为 primary shard。如果宕机的机器修复了，修复后的节点也不再是 primary shard，而是 replica shard。 索引可以拆分成多个 shard ，每个 shard 存储部分数据。拆分多个 shard是有好处的，一是支持横向扩展，比如你数据量是 3T，3 个 shard，每个 shard 就 1T 的数据， 若现在数据量增加到 4T，怎么扩展，很简单，重新建1个有 4 个 shard 的索引，将数据导进 去；二是提高性能，数据分布在多个 shard，即多台服务器上，所有的操作，都会在多台机器 上并行分布式执行，提高了吞吐量和性能。 接着就是这个 shard 的数据实际是有多个备份，就是说每个 shard 都有1个 primary shard ，负责写入数据，但是还有多个 replica shard 。 primary shard 写入数据之后， 会将数据同步到其他几个 replica shard上去。 通过这个 replica 的方案，每个 shard 的数据都有多个备份，如果某个机器宕机了，没关系啊， 还有别的数据副本在别的机器上，这样子就高可用了。 总结：分布式就是两点，1.通过shard切片实现横向扩展；2.通过replica副本机制，实现高可用 基本概念 写数据过程：客户端通过hash选择一个node发送请求，这个node被称做coordinating node（协调节点），协调节点对docmount进行路由，将请求转发给到对应的primary shard，primary shard 处理请求，将数据同步到所有的replica shard，此时协调节点，发现primary shard 和所有的replica shard都处理完之后，就反馈给客户端。 客户端发送get请求到任意一个node节点，然后这个节点就称为协调节点，协调节点对document进行路由，将请求转发到对应的node，此时会使用随机轮询算法，在primary shard 和replica shard中随机选择一个，让读取请求负载均衡，接收请求的node返回document给协调节点，协调节点，返回document给到客户端 es最强大的是做全文检索，就是比如你有三条数据 1.java真好玩儿啊 2.java好难学啊 3.j2ee特别牛 你根据java关键词来搜索，将包含java的document给搜索出来。 更新/删除数据过程，首先还是write、merge操作，然后flush过程中： 1、write过程和上面的一致； 2、refresh过程有点区别 所谓的倒排索引，就是把你的数据内容先分词，每句话分成一个一个的关键词，然后记录好每一个关键词对应出现在了哪些 id 标识的数据。 然后你可以从其他地根据这个 id 找到对应的数据就可以了，这个就是倒排索引的数据格式 以及搜索的方式，这种利倒排索引查找数据的式，也被称之为全文检索。 Inverted Index就是我们常见的倒排索引, 主要包括两部分： 一个有序的数据字典 Dictionary（包括单词 Term 和它出现的频率）。 与单词 Term 对应的 Postings（即存在这个单词的文件） 当我们搜索的时候，首先将搜索的内容分解，然后在字典里找到对应 Term，从而查找到与搜索相关的文件内容。 本质上，Stored Fields 是一个简单的键值对 key-value。默认情况下，Stored Fields是为false的,ElasticSearch 会存储整个文件的 JSON source。 哪些情形下需要显式的指定store属性呢？大多数情况并不是必须的。从_source中获取值是快速而且高效的。如果你的文档长度很长，存储 _source或者从_source中获取field的代价很大，你可以显式的将某些field的store属性设置为yes。缺点如上边所说：假设你存 储了10个field，而如果想获取这10个field的值，则需要多次的io，如果从Stored Field 中获取则只需要一次，而且_source是被压缩过 的。 这个时候你可以指定一些字段store为true，这意味着这个field的数据将会被单独存储(实际上是存两份,source和 Stored Field都存了一份)。这时候，如果你要求返回field1（store：yes），es会分辨出field1已经被存储了，因此不会从_source中加载，而是从field1的存储块中加载。 Doc_values 本质上是一个序列化的 列式存储，这个结构非常适用于聚合（aggregations）、排序（Sorting）、脚本（scripts access to field）等操作。而且，这种存储方式也非常便于压缩，特别是数字类型。这样可以减少磁盘空间并且提高访问速度,ElasticSearch 可以将索引下某一个 Document Value 全部读取到内存中进行操作. Doc_values是存在磁盘的 在es中text类型字段默认只会建立倒排索引，其它几种类型在建立倒排索引的时候还会建立正排索引，当然es是支持自定义的。在这里这个正排索引其实就是Doc Value。 即上文所描述的动态索引 往 es 写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 中去。 es 的搜索引擎严重依赖于底层的 filesystem cache ，你如果给 filesystem cache 更多的 内存，尽量让内存可以容纳所有的 idx segment file 索引数据文件，那么你搜索的时候就 基本都是走内存的，性能会非常高。 性能差距究竟可以有多大？我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能 绝对是秒级别的，1秒、5秒、10秒。但如果是走 filesystem cache ，是走纯内存的，那么一 般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。 那如何才能节约filesystem cache这部分的空间呢？ 当写数据到ES时就要考虑到最小化数据，当一行数据有30几个字段，并不需要把所有的数据都写入到ES，只需要把关键的需要检索的几列写入。这样能够缓存的数据就会越多。 所以需要控制每台机器写入的数据最好小于等于或者略大于filesystem cache空间最好。 如果要搜索海量数据，可以考虑用ES+Hbase架构。用Hbase存储海量数据，然后ES搜索出doc id后，再去Hbase中根据doc id查询指定的行数据。 当每台机器写入的数据大于cache os太多时，导致太多的数据无法放入缓存，那么就可以把一部分热点数据刷入缓存中。 对于那些你觉得比较热的、经常会有人访问的数据，最好做个专门的缓存预热系统，就是 对热数据每隔一段时间，就提前访问一下，让数据进入 filesystem cache 里去。这样下 次别人访问的时候，性能肯定会好很多。 把热数据和冷数据分开，写入不同的索引里，然后确保把热索引数据刷到cache里。 在ES里最好不要用复杂的关联表的操作。当需要这样的场景时，可以在创建索引的时候，就把数据关联好。比如在mysql中需要根据关联ID查询两张表的关联数据：select A.name ,B.age from A join B where A.id = B.id，在写入ES时直接去把相关联数据放到一个document就好。 es 的分页是较坑的，为啥呢？举个例子吧，假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 shard 上存储的前 1000 条数据都查到1个协调节点上，如果你有个 5 个 shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到 最终第 100 页的 10 条数据。 分布式的，你要查第 100 页的 10 条数据，不可能说从 5 个 shard，每个 shard 就查 2 条数据， 最后到协调节点合并成 10 条数据吧？你必须得从每个 shard 都查 1000 条数据过来，然后根据 你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第 100 页的数据。你翻页的时 候，翻的越深，每个 shard 返回的数据就越多，而且协调节点处理的时间越长，非常坑爹。所 以用 es 做分页的时候，你会发现越翻到后面，就越是慢。 我们之前也是遇到过这个问题，用 es 作分页，前几页就几十毫秒，翻到 10 页或者几十页的时 候，基本上就要 5~10 秒才能查出来一页数据了。 解决方案吗？ 1）不允许深度分页：跟产品经理说，你系统不允许翻那么深的页，默认翻的越深，性能就越差； 2）在APP或者公众号里，通过下拉来实现分页，即下拉时获取到最新页，可以通过scroll api来实现； scroll 会1次性给你生成所有数据的1个快照，然后每次滑动向后翻页就是通过游标 scroll_id 移动获取下一页，性能会比上面说的那种分页性能要高很多很 多，基本上都是毫秒级的。 但是，唯1的缺点就是，这个适合于那种类似微博下拉翻页的，不能随意跳到任何一页的场 景。也就是说，你不能先进到第 10 页，然后去第 120 页，然后再回到第 58 页，不能随意乱跳 页。所以现在很多APP产品，都是不允许你随意翻页的，也有一些网站，做的就是你只能往 下拉，一页一页的翻。 初始化时必须指定 scroll 参数，告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。 除了用 scroll api ，也可以用 search_after 来做， search_after 的思想是使用前一页的结果来帮助检索下一页的数据，显然，这种方式也不允许你随意翻页，你只能一页一页往后 翻。初始化时，需要使用一个唯1值的字段作为 sort 字段。

歌曲名:Last Visions歌手:Silent Cry专辑:Goddess of TearsLast VisionsThrough his eyesI could escape from myselfPlease, can you help me?In the infinitein my soul... so lonelyI feel his silenceIn serene harmonymy soul burnsLet me touch you, let to hear you.Let me dream in memory of this enigma.Let me remember foreverHis absence makes me feelthe wind screams of painAnd the sadness of traveled roadsin oceans of hope.A vision... the last desirein my heart.End.....................http://music.baidu.com/song/26332105

歌曲名:plasticine歌手:Placebo专辑:sleeping with ghostsPlacebo - PlasticineBeauty lies inside the eyeof another youthful dreamThat doesn"t sell it"s soul for self-esteemThat"s not plasticineBeauty lies inside desireand every wayward heart redeemedThat doesn"t sell it"s soul for self-esteemThat"s not plasticineDon"t forget to be the way you areDon"t forget to be the way you areDon"t forget to be the way you areDon"t forget to be the way you areThe only thing you can rely onis that you can"t rely on anythingDon"t go and sell your soul for self-esteemDon"t be plasticineDon"t forget to be the way you areDon"t forget to be the way you areDon"t forget to be the way you areDon"t forget to be the way you areDon"t forget to be the way you areDon"t forget to be the way you areDon"t forget to be the way you areDon"t forget to be the way you areThe way you are...The way you are...The way you are...The way you are...http://music.baidu.com/song/665338

SheilaStoddenSheilaStodden是一名演员，主要作品有《哄堂大笑》。外文名：SheilaStodden职业：演员代表作品：《哄堂大笑》合作人物：彼得·博格丹诺维奇

歌曲名:Last Unicorn歌手:Groove Coverage专辑:CovergirlSEEDSEED Last UnicornGroove CoverageWhen the last eagle flies over the last crumbling mountainAnd the last lion roars at the last dusty fountainIn the shadow of the forest though she may be all and oneThey would stare unbelieving at the last unicornWhen the first breath of winter though their flowers it"s icingAnd you look to the north and the pale moon is risingAnd it seems like all is dying and would leave the world to moreIn the distance hear the laughter of the last unicornhttp://music.baidu.com/song/19088435

on

就是到商场上衣服上面挂着的那个价格牌。。

went boating

Last weedMy last weed was in a winter with my best weed brothers. We turned the music volume up to 200 timed crazy, so it equalled HIGH... Suddently was a knock which came very unfriendly, we were all scared. It was me walked to the door, and when I opened, It was my parents with policman...@小鼠拨土

the Sugar Hill Gang

The day my life changed began like any other day. I stayed home and watched our slave, Sofia, prepare lunch. Pompeii was a rich city, and most families in Pompeii had three to five slaves.在我的生活发...

last regrets

1、你这几块卡是两个档次的，D2X和ROG Phoebus是家庭娱乐级（高级民用卡），创新的ZXR和老虎卡是爱好者级（顶级民用卡）。2、如果预算允许老虎卡2代是不二之选，老虎卡系列代表了目前民用声卡的最高素质水平（最高124SNR、耳机120SNR），而且本身使用方面功能也全面，前两天我一个小伙伴买的时候还送了几颗运放，随不能说性价比高，不过也让人感觉到了商家的诚意。至于创新ZXR，虽然是针对老虎卡推出的产品，不过实际用过的话都知道ZXR的悲剧，5.1声道在影音爱好者面前已经显得落后，600欧推力的耳放则因为素质问题没有实际意义。3、D2X和ROG Phoebus的选择上主要看你用的音频设备了，你用的什么耳机，你和家人看电影用的什么音响，整体偏音乐欣赏的选D2X，偏环绕效果的选ROG Phoebus。

Last Christmas - Wham!.mp3稍等 发你

是wham!的原唱 wham!的成员又个一个是大家都知道的George Michael 是主唱 另外一个是andrew负责伴奏和合声的 后来wham!解散了George Michael 单飞了 唱last chrismas的时候wham!还没解散 Last Christmas

Wham乐队的原唱

　　　 Last Christmas I gave you my heart But the very next day you gave it away This year to save me from tears I"ll give it to someone special Once bitten and ice shy I keep my distance But you still catch my eye Tell me baby Do you recognize me Well it"s been a year It doesn"t surprise me (Happy Christmas) I wrapped it up and sent it With a note saying "I love you" I meant it Now I know what a fool I"ve been But if you kissed me now I know you"d fool me again A crowded room Friends with tired eyes I"m hiding from you and your soul of ice My god I thought you were someone to rely on me I guess I was a shoulder to cry on A face on a lover with a fire in his heart A man under cover but you tore me apart Now I"ve found a real love you"ll never fool me again A face on a lover with a fire in his heart A man under cover but you tore him apart Maybe next year I"ll give it to someone I"ll give it to someone special 去年的圣诞节，我把心给了你 但隔天你就将它丢弃 今年我从泪水中力图振作 我会把心交给一个特别的人 曾经受伤，不免心存畏惧 我保持着距离 但你依然发现了我 告诉我，宝贝 你认出我了吗 已经过了一年 我并不惊讶 (圣诞快乐) 我包装好后将它送出 附上字条，写着"我爱你" 我是认真的 现在我才知道当初真傻 但如果你现在吻我 你可以再次愚弄我 拥挤的房间里 朋友们眼神疲惫 我想避开你和你冰冷的灵魂 老天，我曾以为你是多么倚赖我 我想我就是你可以靠著哭泣的肩膀 有着火热的心的爱人脸庞 刻意掩饰，你却将我拆穿 如今我已找到真爱，你再也不能愚弄我 有着火热的心的爱人脸庞 刻意掩饰，你却将我拆穿 也许明年我会把心交给一个人 一个特别的人 参考: dodo.gsin/Last_max

中文名称：威猛乐队精选辑英文名称：The Final资源类型：MP3!发行时间：1999年4月5日专辑歌手：Wham!地区：英国语言：英语 专辑介绍 ：从一个中学生组合发展而来的"威猛！"无疑是80年代最成功的英国流行乐队。他们以快节奏的、轻松的、具有灵歌风格的曲风风靡了全世界。乐队最主要的成员是乔治·迈克尔George Michael，他具有希腊-塞浦路斯血统，真名叫乔治乌斯·潘纳亚逊，(1963年6月26日出生)和安德鲁·里奇利（Andrew Ridgely，1963年1月26日出生）。1983年 Wham！的首张专辑《Fantastic（妙极了）》发行，问市后马上以迅雷不及掩耳的速度勇夺全英专辑榜榜首王座，不过这张专辑在进军美国时却铩羽而归，只拿到金唱片和专辑榜83名的成绩。 1984年，推出的第二张专辑《Make It Big（炒热它）》，不但在英美两地都创下专辑排行冠军的傲人成绩（在美国还蝉连三周榜首），销售数字也冲破五百万大关。1985年 Wham！成为第一支冲破铁幕、进入中国大陆表演的西方流行乐团（1985年4月）。1986年 Wham！推出第三张专辑《Music From The Edge Of Heaven（The Final）》，George Michael担纲了专辑中所有歌曲的制作及创作，出现在专辑里的大部份乐器演奏也都由他一手包办，本专辑拥有全美Top 10、全英冠军的优异成绩。此张威猛乐队精选集收录了威猛乐队多年以来的代表作，跨越厂牌及时间的局限，不仅完整记录了威猛乐队音乐创作的轨迹，也记录了八十至九十年代流行音乐一段璀璨乐章。专辑收录了乐队历年唱片中的畅销金曲，比如"I"m your man"、"Careless whisper"、"Club Tropicana"、"Last Christmas"；是威猛乐队歌迷的必备收藏

WHAM!

D冒险的意思。

歌曲名:Last Beautiful Girl歌手:Matchbox Twenty专辑:Mad SeasonThis will all fall down like everything else that wasThis too shall pass and all of the words we saidWe can"t take backNow every fool in town would"ve left by nowI can"t replace all the wasted daysThe memory of your face - can"t help thinkin"Maybe if we ever coulda kept it all togetherWhere would we beA thousand lost foreversAnd the promises you never were giving meHere"s what I"m thinkingIt won"t be the first - heart that you breakIt won"t be the last - beautiful girlThe one that you wrecked - won"t take you backIf you were the last beautiful girl in the worldTell me one more timeHow you"re sorry about the wayThis all went down - you needed to find your spaceYou needed to still be friendsNeeded me toCall you if I ever couldn"t keep it all together you"d comfort meTell me but foreverAnd the promises I never should have believed inHere"s what I"m thinkingIt won"t be the first - heart that you breakIt won"t be the last - beautiful girlThe one that you wrecked - won"t take you backIf you were the last beautiful girl in the worldIt"s over now - and I"ve gone withoutCuz you"re everybody else"s girlIt seems to me - you"ll always beEveryone else"s girlEveryone else"s girlThis will all fall downLike everything in the worldThis too must endAnd all the words we saidWe can"t take backIt won"t be the first - heart that you breakIt won"t be the last - beautiful girlThe one that you wrecked - won"t take you backIf you were the last...It won"t be the first - heart that you breakIt won"t be the last - beautiful girlThe one that you wrecked - won"t take you backIf you were the last beautiful girl in the worldThe last beautiful girl in the worldYou are the last beautiful girl in the worldBeautiful girlBy Mark Mahttp://music.baidu.com/song/1564777

第一个写全名以后出现的就用Mr. Zhang之类的就可以了

姓名是社会成员的符号或标记，英美人的姓和顺序名中国人的相反。他们是：名在前，姓在后，如NanthanHale（内森·黑尔），Nanthan是名，Hale是姓。所以名叫firstname，姓叫lastname（名也叫givenname或Christianname...

在埃及人的命名系统里，一般第一个是他自己的名字，接下来就是他家族里男性长辈的名字，举个例子：第二个有可能是他父亲的名字，第三个有可能是他祖父的名字，第四个有可能是他曾祖父的名字……就这样，他们可能会有一大串儿名字，但是并没有一个固定的家族姓，最多只会有一个名字代表一整个家族（比如说“葬爱家族”，“葬爱”就类似于埃及命名系统的家族名）。不过硬要像欧美那样分firstname和lastname的话，那就取第一个和最后一个单词吧……（建议亲自问本人familysurname或者lastname是什么会更好）——firstname就是Moustafa了。

是的，名字在前是first name, 姓氏在后叫last name.

以JimGreen为例，翻译成吉姆格林，外国人的人名是“姓在后，名在前”这个大家都知道的，因此：其中格林是姓，吉姆是名，那么这个firstname和lastname可以从jimGreen的朗读顺序来记，那么即jim在前所以是first（先）读，所以firstname是名。Green在后，即last（后）读，所以lastname是姓。记住了firstname和lastname的含义之后，我们就知道填表格了，firstname就是填你的名，lastname就是填你的姓

外国人喜欢把名字放在前，姓放在后。First Name是名字Last Name是姓Given Name也是名字

痛苦是暂时的，放弃才会遗憾终生。 ——兰斯·阿姆斯特朗：美国自行车选手，战胜癌症7次获得环法自行车赛冠军

Fucking!

Yes

他们的顺序是名在前姓氏在后朱军华用他们的语序说就是JunhuaZhu

Mission Impossible

最后的名字（last name）是姓（比如段，韩，张），第一个名（first name）是名，就是你姓后面那个

first name是姓last name是名

在英语姓名中，因为姓氏通常被放在最后（即last name），所以通常说的last name指的是姓氏。而first name指的是在英语名字中放在第一个部分的，其实是我们说的“名”。举个例子：一个人的名字叫这个：Tomas William Smith。这里面包含了三个部分其中Tomas排在左边起第一个部分，叫做first name，即“名”。William排在中间，称为middle name，也就是中间名，平常是不用的。有的人有可能有不止一个中间名，这个时候就会相应按顺序称为second name、third nameSmith排在最后，称为last name。英语国家的人其姓氏通常是放在最后的，所以last name即我们说的“姓”。也成为family name或者surname

姓 名

在英语姓名中，因为姓氏通常被放在最后（即last name），所以通常说的last name指的是姓氏。而first name指的是在英语名字中放在第一个部分的，其实是我们说的“名”。举个例子：一个人的名字叫这个：Tomas William Smith。这里面包含了三个部分其中Tomas排在左边起第一个部分，叫做first name，即“名”。William排在中间，称为middle name，也就是中间名，平常是不用的。有的人有可能有不止一个中间名，这个时候就会相应按顺序称为second name、third nameSmith排在最后，称为last name。英语国家的人其姓氏通常是放在最后的，所以last name即我们说的“姓”。也成为family name或者surname

first name是名，last name是姓。西方人名字在前，姓氏在后。

关于last name & first name 的问题 1、在英语中，“名字”是放在最前面的，因此叫做 first name，也叫 given name。“姓氏”放在最后边，因此叫做 last name 或 family name。中国人跟外国人介绍自己的名字时，必须要把“姓”放在最后面，这样人家才好称呼你。例如：Mr. Li, Miss Liu 等。 2、当中文姓名为两个字时，两个字要分开写，每个单词的首字母要大写。例如“李明”的英文写法为：Ming Li 。当中文名字为三个字时，把名字里的两个字拼写到一块儿，首字母大写，“姓”要单独拼写，放在最后且首字母大写。例如“李维康”，英文写法为：Weikang Li 。 3、既然要用英文来写名字，那就要完全符合西方人的习惯才行，写英文不是给中国人看的，否则为什么不直接写中文呢？一百多年前，中国有大量的人口被贩卖、掠夺到美国去当“猪仔”——劳工，由于中国人不懂英语，于是都用中文习惯来报自己的名字，结果被美国移民局登记时，都失去了自己本来的姓氏，后代都要用第一代华人的名字（不含姓）来作为合法的“姓”！于是大量美籍华人都有两个名字：一个是私下称呼的、有祖先姓氏的中文名字，一个是正式档案上把第一代移民祖先的“名字”作为“姓”的英文名字！现在祖国文化普及了，外语教育也普及了，一百年前的错误再也不能重演了！ （DAVID提供） 很简单的英语问题，有关first name ,last,name first name/given name: 名字 last name/family name/surname: 姓 first name ：ming last name : Li 关于session.setAttribute(String name,object)中name的问题 可以拼接字串， 或者你为什么一定要分开放，直接把所有物件放在集合，然后把集合整体放到session中 关于Remember The Name的问题 就是这首歌的几个演唱者了，具体的意思就是唱完叫谁接下去，然后这几个人组在一起很牛逼的意思。看MV更清楚一点。 Styles Of Beyond是Los Angles的一支老牌的地下说唱组合，Mike Shinoda在成立LP之前就已经认识了他们的成员Ryu和Tak．后来Mike成名后在Warner名下有了自己的厂牌Machine Shop,于是就把SOB签入． 而Fort Minor的五名成员中，三名来自SOB，还有一个是请来的鼓手 User name First name Last name 你好！ User name First name Last name 使用者名称，名字，姓 last name or first name? last name即姓 first name即名， 用first name称呼某人，显得很随便， Mr,等之类后要接last name。这样也显得正式，或表示尊敬。 （ ）first name is ( ).( )last name is ( ) first name is 名字 外国人的名字在前 说到“第一个名字” 其实就是名字 同理 last name is 姓氏 就是说“最后的名字” 也即是姓氏 如 乔治 布什 乔治就是first name 名字 布什就是last name 姓氏了 关于INPUT里name的问题。 input的name不要和js的函式名相同, 应该可以.试试就知.呵呵 first name and last name. first name是鱼,last name(sur name/family name)是李 excel中的函式问题（将FIRST NAME和LAST NAME区分开） first name: =LEFT(A2,FIND(",",A2)-1) last name: =RIGHT(A2,LEN(A2)-FIND(",",A2)) 均下拉复制公式。 另外“分列”也是不错的办法。（分隔符：英文逗号,)

英语中，the last name是家族姓氏，the fist name 是名.举例：最新奥斯卡影帝：莱昂纳多.迪卡普里奥，英文名：Leonardo DiCaprio，而：莱昂纳多leonardo 是名，迪卡普里奥DiCaprio是姓。中文名字中：正好是相反：姓在前。

一般过去时的句子疑问句要用助动词did+动词原形Did John go to Japan last saturday?

网络爬虫架构在Nutch+Hadoop之上，是一个典型的分布式离线批量处理架构，有非常优异的吞吐量和抓取性能并提供了大量的配置定制选项。由于网络爬虫只负责网络资源的抓取，所以，需要一个分布式搜索引擎，用来对网络爬虫抓取到的网络资源进行实时的索引和搜索。搜 索引擎架构在ElasticSearch之上，是一个典型的分布式在线实时交互查询架构，无单点故障，高伸缩、高可用。对大量信息的索引与搜索都可以在近 乎实时的情况下完成，能够快速实时搜索数十亿的文件以及PB级的数据，同时提供了全方面的选项，可以对该引擎的几乎每个方面进行定制。支持RESTful 的API，可以使用JSON通过HTTP调用它的各种功能，包括搜索、分析与监控。此外，还为Java、PHP、Perl、Python以及Ruby等各 种语言提供了原生的客户端类库。网络爬虫通过将抓取到的数据进行结构化提取之后提交给搜索引擎进行索引，以供查询分析使用。由于搜索引擎的设计目标在于近乎实时的复杂的交互式查询，所以搜索引擎并不保存索引网页的原始内容，因此，需要一个近乎实时的分布式数据库来存储网页的原始内容。分布式数据库架构在Hbase+Hadoop之上，是一个典型的分布式在线实时随机读写架构。极强的水平伸缩性，支持数十亿的行和数百万的列，能够对网络爬虫提交的数据进行实时写入，并能配合搜索引擎，根据搜索结果实时获取数据。网 络爬虫、分布式数据库、搜索引擎均运行在普通商业硬件构成的集群上。集群采用分布式架构，能扩展到成千上万台机器，具有容错机制，部分机器节点发生故障不 会造成数据丢失也不会导致计算任务失败。不但高可用，当节点发生故障时能迅速进行故障转移，而且高伸缩，只需要简单地增加机器就能水平线性伸缩、提升数据 存储容量和计算速度。网络爬虫、分布式数据库、搜索引擎之间的关系：1、网络爬虫将抓取到的HTML页面解析完成之后，把解析出的数据加入缓冲区队列，由其他两个线程负责处理数据，一个线程负责将数据保存到分布式数据库，一个线程负责将数据提交到搜索引擎进行索引。2、搜索引擎处理用户的搜索条件，并将搜索结果返回给用户，如果用户查看网页快照，则从分布式数据库中获取网页的原始内容。整体架构如下图所示：爬虫集群、分布式数据库集群、搜索引擎集群在物理部署上，可以部署到同一个硬件集群上，也可以分开部署，形成1-3个硬件集群。网络爬虫集群有一个专门的网络爬虫配置管理系统来负责爬虫的配置和管理，如下图所示：搜 索引擎通过分片（shard）和副本（replica）实现了高性能、高伸缩和高可用。分片技术为大规模并行索引和搜索提供了支持，极大地提高了索引和搜 索的性能，极大地提高了水平扩展能力；副本技术为数据提供冗余，部分机器故障不影响系统的正常使用，保证了系统的持续高可用。有2个分片和3份副本的索引结构如下所示：一个完整的索引被切分为0和1两个独立部分，每一部分都有2个副本，即下面的灰色部分。在 生产环境中，随着数据规模的增大，只需简单地增加硬件机器节点即可，搜索引擎会自动地调整分片数以适应硬件的增加，当部分节点退役的时候，搜索引擎也会自 动调整分片数以适应硬件的减少，同时可以根据硬件的可靠性水平及存储容量的变化随时更改副本数，这一切都是动态的，不需要重启集群，这也是高可用的重要保 障。

学术性的；有学者风度的；学者的学校的，教育上的；学术上的学院的，大学的，学会的，（学术，文艺）协会的；学究的，学理上的，空谈的，非实用的；意思上就可区分

Linux系统由于数据累计增长、前期存储规划不合理等诸多因素，出现存储不够用的情况时，此时就需要扩展逻辑分区或添加新的逻辑分区。下面介绍一下通过使用fdsik添加新的逻辑分区。 首先使用df命令检查文件系统的磁盘空间占用情况[root@DB-ONE-SERVER~]# df -hFilesystem Size Used Avail Use% Mounted on/dev/mapper/VolGroup00-sda3 30G 2.4G 26G 9% //dev/sda1 99M 23M 71M 25% /boottmpfs 4.0G 0 4.0G 0% /dev/shmYou have new mail in /var/spool/mail/root然后使用fdisk -l查看分区表信息[root@DB-ONE-SERVER~]# fdisk -lDisk /dev/sda: 42.9 GB, 42949672960 bytes255 heads, 63 sectors/track, 5221 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesDevice Boot Start End Blocks Id System/dev/sda1 * 1 13 104391 83 Linux/dev/sda2 14 5221 41833260 8e Linux LVMDisk /dev/sdb: 21.4 GB, 21474836480 bytes255 heads, 63 sectors/track, 2610 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesDisk /dev/sdb doesn"t contain a valid partition tableDisk /dev/dm-0: 32.3 GB, 32346472448 bytes255 heads, 63 sectors/track, 3932 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesDisk /dev/dm-0 doesn"t contain a valid partition tableDisk /dev/dm-1: 10.4 GB, 10468982784 bytes255 heads, 63 sectors/track, 1272 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesDisk /dev/dm-1 doesn"t contain a valid partition tablefdisk命令参数介绍 p、打印分区表。 n、新建一个新分区。 d、删除一个分区。 m、输出菜单 q、退出不保存。 w、把分区写进分区表，保存并退出。[root@DB-ONE-SERVER~]# fdisk /dev/sdbDevice contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabelBuilding a new DOS disklabel. Changes will remain in memory only,until you decide to write them. After that, of course, the previouscontent won"t be recoverable.The number of cylinders for this disk is set to 2610.There is nothing wrong with that, but this is larger than 1024,and could in certain setups cause problems with:1) software that runs at boot time (e.g., old versions of LILO)2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK)Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)Command (m for help): mCommand action a toggle a bootable flag b edit bsd disklabel c toggle the dos compatibility flag d delete a partition l list known partition types m print this menu n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition"s system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only)Command (m for help): pDisk /dev/sdb: 21.4 GB, 21474836480 bytes255 heads, 63 sectors/track, 2610 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesDevice Boot Start End Blocks Id SystemCommand (m for help): nCommand action e extended p primary partition (1-4)pPartition number (1-4): 1First cylinder (1-2610, default 1): 1Last cylinder or +size or +sizeM or +sizeK (1-2610, default 2610): Using default value 2610Command (m for help): pDisk /dev/sdb: 21.4 GB, 21474836480 bytes255 heads, 63 sectors/track, 2610 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesDevice Boot Start End Blocks Id System/dev/sdb1 1 2610 20964793+ 83 LinuxCommand (m for help): wThe partition table has been altered!Calling ioctl() to re-read partition table.Syncing disks.[root@DB-ONE-SERVER~]# fdisk -l /dev/sdbDisk /dev/sdb: 21.4 GB, 21474836480 bytes255 heads, 63 sectors/track, 2610 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesDevice Boot Start End Blocks Id System/dev/sdb1 1 2610 20964793+ 83 Linux使用 mkfs.ext4 命令格式化磁盘成格式化成ext4各式的文件系统。[root@DB-ONE-SERVER~]# mkfs.ext4 /dev/sdb1mke4fs 1.41.12 (17-May-2010)Filesystem label=OS type: LinuxBlock size=4096 (log=2)Fragment size=4096 (log=2)Stride=0 blocks, Stripe width=0 blocks1310720 inodes, 5241198 blocks262059 blocks (5.00%) reserved for the super userFirst data block=0Maximum filesystem blocks=4294967296160 block groups32768 blocks per group, 32768 fragments per group8192 inodes per groupSuperblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000Writing inode tables: done Creating journal (32768 blocks): doneWriting superblocks and filesystem accounting information: doneThis filesystem will be automatically checked every 36 mounts or180 days, whichever comes first. Use tune4fs -c or -i to override.系统启动时自动挂载/dev/sdb1,编辑/etc/fstab文件，指定挂载目录为/u02[root@DB-ONE-SERVER~]# vi /etc/fstab/dev/VolGroup00/sda3 / ext3 defaults 1 1/dev/sdb1 /u02 ext4 defaults 1 2LABEL=/boot /boot ext3 defaults 1 2tmpfs /dev/shm tmpfs defaults 0 0devpts /dev/pts devpts gid=5,mode=620 0 0sysfs /sys sysfs defaults 0 0proc /proc proc defaults 0 0/dev/VolGroup00/sda4 swap swap defaults 0 0~ [root@DB-ONE-SERVER~]# cd /[root@DB-ONE-SERVER/]# mkdir u02[root@DB-ONE-SERVER/]# mount -a[root@DB-ONE-SERVER/]# df -hFilesystem Size Used Avail Use% Mounted on/dev/mapper/VolGroup00-sda3 30G 2.4G 26G 9% //dev/sda1 99M 23M 71M 25% /boottmpfs 4.0G 0 4.0G 0% /dev/shm/dev/sdb1 20G 172M 19G 1% /u02[root@DB-ONE-SERVER/]# 下面来看看虚拟上Linux的添加新的逻辑分区的步骤,其实操作是一样的，只是顺带介绍一下虚拟机如何添加硬盘 [root@oracle_server ~]# fdisk -l Disk /dev/sda: 584.6 GB, 584646328320 bytes255 heads, 63 sectors/track, 71079 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System/dev/sda1 * 1 19441 156151808 83 LinuxPartition 1 does not end on cylinder boundary./dev/sda2 19441 44937 204796672 83 LinuxPartition 2 does not end on cylinder boundary./dev/sda3 44937 57685 102398336 83 LinuxPartition 3 does not end on cylinder boundary./dev/sda4 57685 71080 107595584 5 ExtendedPartition 4 does not end on cylinder boundary./dev/sda5 57685 70433 102398336 83 Linux/dev/sda6 70433 70949 4144768 82 Linux swap/dev/sda7 70949 71080 1052288 83 Linux Disk /dev/sdb: 146.1 GB, 146156158976 bytes2 heads, 24 sectors/track, 5947109 cylindersUnits = cylinders of 48 * 512 = 24576 bytes Device Boot Start End Blocks Id System/dev/sdb1 3 5947064 142729472 83 Linux[root@oracle_server ~]#

my brother had his bike stolen last night.

The Last Redemption (TLR)是由Chris Huang于2018年在美国洛杉矶创立的。 The Last Redemption品牌致力于打破传统，把本就不相容的街头文化与高端时尚这两种元素完美融合，探索更多的可能性，打造一个在任何场合都能让使用者感到舒适美观的时尚品牌。

NOTE:"LASTONEINISAROTTENEGG"最后一个跳进去的是笨蛋;这样来用，Ifyoucompeterunningwithyourfriends,youmightwanttosay"Lastonethereisarottenegg."

enchanted是taylor写的

there once was a fox who wanted to humiliate her neighbour, pelican, so she invited him for dinner. The pelican accepted and went to the Fox"s house but the plates were flat and the pelican couldn"t eat with its long beak. The evil fox kept saying how delicious the food was and the pelican told her to come over to the pelicans home next time for l unch. so when the fox went at the pelicans house the dishes were long this time, specially made for pelicans, and the fox couldn"t eat at all! So when the fox left pelicans place the bird shouted at her "Who laughs last laughs best you evil fox! you should know that..."

去zard贴吧吧

毒刃号 【简介】 毒刃号为运兵车配件，可为所有兵种提供强力加成。目前毒刃号尚未在所有服务器开放，具体开放时间，请您留意游戏内相关版本更新邮件。 【毒刃号属性】 毒刃号配件将为所有兵种提供加成，配件等级越高，获得加成越多。居停加成情况，请点击【配件中心】-【毒刃号】-【i】进行查看。 使用同系列6个配件时，根据运兵车并兵种，解锁配件技能【不取/强攻/碾压】，为玩家提供攻城加成。 【制作毒刃号】 制作毒刃号需要使用铁血号、游侠号、幻影号配件以及超级能源核心。其中铁血号、游侠号、幻影号配件可通过配件中心制作、购买军火供应-组合7或相应配件礼包获得。超级能源核心可通过交易中心、VIP商店兑换、购买军火供应-组合7或相应礼包获得。 【分解毒刃号】 目前毒刃号配件分解功能暂未上线，具体上线时间请您留意游戏内公告以及版本更新邮件。

1. 简介 毒刃号为运兵车配件，可为所有兵种提供强力加成。目前毒刃号尚未在所有服务器开放，具体开放时间，请您留意游戏内相关版本更新邮件。 2.毒刃号属性 毒刃号配件将为所有兵种提供加成，配件等级越高，获得加成越多。居停加成情况，请点击【配件中心】-【毒刃号】-【i】进行查看。使用同系列6个配件时，根据运兵车并兵种，解锁配件技能【不取/强攻/碾压】，为玩家提供攻城加成。 3.制作毒刃号 制作毒刃号需要使用铁血号、游侠号、幻影号配件以及超级能源核心。其中铁血号、游侠号、幻影号配件可通过配件中心制作、购买军火供应-组合7或相应配件礼包获得。超级能源核心可通过交易中心、VIP商店兑换、购买军火供应-组合7或相应礼包获得。 4.分解毒刃号 目前毒刃号配件分解功能暂未上线，具体上线时间请您留意游戏内公告以及版本更新邮件。

第一个空：It...that是强调句式，固定的只能用that第二个空：what she thought 是后面这个从句的主语，即直到上周她才发现她所想的东西被严重的误解了

打开浏览器，输入进入NCBI网站。在此网页下方处找到Primer-BLAST，点击进入。点击进入以下界面，在Primer Parameters里面输入自己已经设计好的引物序列。随后，在Primer Pair Specificity Checking Parameters里面的Databse中选择选项“Genome（chromosomes from all organisms）”。之后直接点击页眉左下角的“Get Primers”按钮进行引物特异性的验证。注意：输入自己设计好的引物时，注意引物的顺序是不是5"端至3‘端

一个船儿一个舵

Ronan:Four o"clock in the morningMy mind"s filled with a thousand thoughts of youAnd how you left without a warningBut looking back I"m sure you tried to talk it through凌晨四点时分我的脑海里充满了对你的万千思绪你没有一丝预兆就离开了我可那双回眸却告诉我你在尽量解释这一切LeAnn:Now I see it so clearlyWe"re together but living separate lives你说的这些我都明白我们在一起却拥有不同的生活方式Ronan:So wanna tell you I"m sorryBaby I can"t find the wordsBut if I could, then you know I would, yeah因此我想向你致歉亲爱的我找不到合适的话语你知道我在尽力向你表白ChorusNo I won"t let you go, know what we can beI won"t watch my life, crashing down on meGuess I had it all, right there before my eyesGirl, I"m sorry now, you were the last thing on my mind我不会让你走，我坚信我们的未来我不会任凭我的生活自生自灭我猜想我一定能够得到胜利的果实对不起，我会更加珍视你的存在LeAnn:You carried me like a riverHow far we"ve come still surprises me你带我走过漫漫长路至今我还在为这段路程而惊异Ronan:And now I look in the mirrorStaring back is the manI used to beWith youHow I long for you我凝视着镜中的自己那是曾经与你共度时光的我我是那么的渴望拥有你Repeat chorusRonan:Girl I"m sorry I was wrongCould have been thereShould have been so strongSo I"m sorry, woohRepeat chorus x2

while supplies last送完即止双语对照例句:1.Good while supplies last. 好送完即止。2.Last: while private gunrunners continue to thrive the world"s biggest arms supplies arethe us, uk, russia, france and china. 影片最后：现今世界武器走私贸易方兴未艾，然而世界上武器贸易最大的国家依次分别是：美国、英国、俄国、法国和中国。

http://www.cnblogs.com/zhaijunming5/p/6427100.html

happily

意思是 热塑性

之前我看过的文章，都是既有名也有姓。全名。

すやすや 梦を见てる suyasuya yume wo mite ru 君の横颜 kimi no yokogao 気付かず 零れた涙 kiduka zu kobore ta namida 頬を伝う hoo wo tsutau せつなの ときめきを setsunano tokimekiwo この胸に 隠してたの kono mune ni kakushi tetano Last night,Good night Last night,Good night この夜 君の手 kono yoru kimi no te 握って 眠るよ nigitte nemuru yo おやすみ oyasumi 素敌な 朝をもう一度 suteki na asa womou ichido 君と过ごせたら kimi to sugo setara 小さなそんな希望さえ chiisa nasonna kibou sae 想うだけの奇迹 omou dakeno kiseki 何も伝えないまま nanimo tsutae naimama さよならは言えないよ sayonaraha ie naiyo Last night,Good night Last night,Good night この声 枯れても kono koe kare temo 消えない メロディー kie nai merodei^ Last night,Good night Last night,Good night いつかは むかえる itsukaha mukaeru 最后を 想うよ saigo wo omou yo 夜空に 愿うの yozora ni negau no ときわの 笑颜を tokiwano egao wo おやすみoyasumi 【混分 外加= =钱菌你要罗马音是为了翻唱？总之求真相】

Last night good night作词：kz 作曲：kz 编曲：kz 呗：初音ミク すやすや 梦を见てる suyasuya yume wo mite ru 君の横颜 kimi no yokogao 気付かず 零れた涙 kiduka zu kobore ta namida 頬を伝う hoo wo tsutau せつなの ときめきを setsunano tokimekiwo この胸に 隠してたの kono mune ni kakushi tetano Last night,Good night Last night,Good night この夜 君の手 kono yoru kimi no te 握って 眠るよ nigitte nemuru yo おやすみ oyasumi 素敌な 朝をもう一度 suteki na asa womou ichido 君と过ごせたら kimi to sugo setara 小さなそんな希望さえ chiisa nasonna kibou sae 想うだけの奇迹 omou dakeno kiseki 何も伝えないまま nanimo tsutae naimama さよならは言えないよ sayonaraha ie naiyo Last night,Good night Last night,Good night この声 枯れても kono koe kare temo 消えない メロディー kie nai merodei^ Last night,Good night Last night,Good night いつかは むかえる itsukaha mukaeru 最后を 想うよ saigo wo omou yo 夜空に 愿うの yozora ni negau no ときわの 笑颜を tokiwano egao wo おやすみoyasumi不是很全_(:з」∠)_

Last night good night作词：kz 作曲：kz 编曲：kz 呗：初音ミク すやすや 梦を见てる suyasuya yume wo mite ru 君の横颜 kimi no yokogao 気付かず 零れた涙 kiduka zu kobore ta namida 頬を伝う hoo wo tsutau せつなの ときめきを setsunano tokimekiwo この胸に 隠してたの kono mune ni kakushi tetano Last night,Good night Last night,Good night この夜 君の手 kono yoru kimi no te 握って 眠るよ nigitte nemuru yo おやすみ oyasumi 素敌な 朝をもう一度 suteki na asa womou ichido 君と过ごせたら kimi to sugo setara 小さなそんな希望さえ chiisa nasonna kibou sae 想うだけの奇迹 omou dakeno kiseki 何も伝えないまま nanimo tsutae naimama さよならは言えないよ sayonaraha ie naiyo Last night,Good night Last night,Good night この声 枯れても kono koe kare temo 消えない メロディー kie nai merodei^ Last night,Good night Last night,Good night いつかは むかえる itsukaha mukaeru 最后を 想うよ saigo wo omou yo 夜空に 愿うの yozora ni negau no ときわの 笑颜を tokiwano egao wo おやすみoyasumi