大道至简

即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确保能从失败中恢复。但在两次提交之间发生变化的文档怎么办？我们也不希望丢失掉这些数据。Elasticsearch 增加了一个translog，或者叫事务日志，在每一次对 Elasticsearch 进行操作时均进行了日志记录。一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了 translog...

当一个文档被 “删除” 时，它实际上只是在.del文件中被标记删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。但是这里新段会被先写入到文件系统缓存--这一步代价会比较低，稍后再被刷新到磁盘--这一步代价比较高。不过只要文件已经在缓存中， 就可以像其它文件一样被打开和读取了。Lucene 允许新段被写入和打开--使其包含的文档...

怎样使用别名在零停机下从旧索引切换到新索引。最简单方式：假设当前索引为my_index创建新的index，并指定mapping put localhost:9200/new_index{ "mappings": { "my_type": { "properties": { "tags": { ...

根据上图，当客户端发起一个请求后，接受请求的节点变为协调节点，会先创建优先队列存储要查询的结果集将请求发送给所有主节点，主节点在本地查询对应的top条数，将结果发送给协调节点协调节点整合各主节点的结果数据，最终取前top条因此，当假如分页查询1W条,共有100个主节点，那么将会收集100W条数据然后在协调节点取前100条这样可能会造成协调节点内存溢出的问题...

根据上图，当客户端发起一个请求后，接受请求的节点变为协调节点，会先创建优先队列存储要查询的结果集将请求发送给所有主节点(请求中默认会有一个routingvalues（通常默认是该文档的_id）参数，然后ES对该参数进行shard = hash(routing) % number_of_primary_shards，找到对应的节点)，主节点在本地查询对应的top条数，将结...

起因：倒排索引的弊端 倒排索引它也是有缺陷的，假如我们需要对数据做一些聚合操作，比如排序，分组时，lucene内部会遍历提取所有出现在文档集合的排序字段然后再次构建一个最终的排好序的文档集合list，这个步骤的过程全部维持在内存中操作，而且如果排序数据量巨大的话，非常容易就造成solr内存溢出和性能缓慢 其实，Doc Values本质上是一个序列化了的列式存储结构，非常适合排序、聚...

基础知识请搜索其他博客，本文只讲实际操作。场景：当需要存储关系对象时 比如 一个博客下有多个评论 主要解决对象关系存储 需要手动指定索引各字段的类型 并指定关系对象为nested类型 注意只能在新建索引时指定好，否则后续不能修改，需要通过删除索引 重建。 { "mappings": { "blog": { "proper...