默认分类

《ClickHouse：强大的数据分析引擎》

京东云开发者发表了文章 • 0 个评论 • 374 次浏览 • 2 天前 • 来自相关话题

最近的工作中接触到CK，一开始还不知道CK是什么,通过查询才知道CK是ClickHouse，ClickHouse 是俄罗斯的Yandex于2016年开源的列式存储数据库，是一款开源的面向列的分布式数据库管理系统，以其卓越的性能和强大的数据分析能力在大数据领域备受瞩目。

列式存储

列式存储是一种数据存储结构,也称为列存储或列式数据库。它将数据按列存储而非传统的按行存储。每一列的数据类型相同或者相似。

采用行式存储时，数据在磁盘上的组织结构为：

采用列式存储时，数据在磁盘上的组织结构为：

列存储在写入效率、保证数据完整性上都不如行存储，它的优势是在读取过程，不会产生冗余数据，这对数据完整性要求不高的大数据处理领域，比如互联网，犹为重要。

ClickHouse 的主要特点
高性能

快速的查询响应：能够在秒级甚至亚秒级时间内处理大规模数据的查询请求。
高效的数据压缩：采用了多种数据压缩算法，大大减少了数据存储占用的空间，同时提高了数据读取的速度。
向量化执行引擎：可以并行处理大量数据，充分利用现代硬件的优势，提高执行效率。

可扩展性

分布式架构：支持水平扩展，可以轻松地添加更多的服务器节点来处理不断增长的数据量和查询负载。
数据分片：将数据分散存储在不同的节点上，提高数据的可用性和可靠性。

丰富的数据分析功能

支持多种数据类型：包括数值、字符串、日期时间等常见数据类型，以及数组、嵌套结构等复杂数据类型。
强大的聚合函数：提供了丰富的聚合函数，如求和、平均值、最大值、最小值等，方便进行数据分析和统计。
支持 SQL 语言：用户可以使用熟悉的 SQL 语句进行数据查询和分析，降低了学习成本。

场景支持

ClickHouse的数据处理速度非常快，尤其适合于包含复杂分析查询的场景

适合场景

日志和事件数据：由于ClickHouse的处理速度，它可以作为实时数据分析的工具。
监控和报警系统：ClickHouse可以用于快速查询和显示监控数据。
交互式查询：由于其快速的查询速度，ClickHouse可以作为数据科学家进行交互式探索的工具。
数据仓库：ClickHouse可以作为数据仓库的一种替代方法，用于快速查询和分析。

不适合场景

事务处理：ClickHouse不支持事务处理。
强一致性：ClickHouse不保证数据的强一致性。
低延迟的更新：ClickHouse不适合于需要实时或近实时更新数据的场景。
高度模式化的数据：ClickHouse对模式的灵活性不如关系型数据库。

小结

总之，ClickHouse 是一款功能强大的数据库管理系统，适用于大规模数据分析和处理场景。通过了解其特点和基础知识，用户可以更好地利用 ClickHouse 来满足自己的数据分析需求

十亿级订单系统的数据库查询性能优化之路

京东云开发者发表了文章 • 0 个评论 • 1938 次浏览 • 2024-12-11 16:43 • 来自相关话题

作者：京东零售崔健

0.前言

系统概要：BIP采购系统用于京东采销部门向供应商采购商品，并且提供了多种创建采购单的方式以及采购单审批、回告、下传回传等业务功能
系统价值：向供应商采购商品增加库存，满足库存周转及客户订单的销售，供应链最重要的第一环节

1.背景

采购系统在经历了多年的迭代后，在数据库查询层面面临巨大的性能挑战。核心根因主要有以下几方面：
复杂查询多，历史上通过MySQL和JED承载了过多的检索过滤条件，时至今日很难推动接口使用方改变调用方式
数据量大，随着业务的持续发展，带来了海量的数据增长（日均150万单左右，订单主表/子表/渠道表/扩展表分别都是：6.5亿行，订单明细表/分配表：9.2亿行，日志表：60亿行）
数据模型复杂，订单完整数据分布在20+张表，经常需要多表join

引入的主要问题有：
业务层面：
- 订单列表页查询/导出体验差，性能非常依赖输入条件，尤其是在面对订单数据倾斜的时候，部分用户无法查询/导出超过半个月以上的订单
- 查询条件不合理，1.归档筛选条件，技术词汇透传到业务，导致相同周期的单子无法一键查询/导出，需要切换“是否归档”查询全部；2.无法区分“需要仓库收货”类的单子，大部分业务同事主要关注这类单子的履约情况
技术层面：
- 慢SQL多，各种多表关联复杂条件查询导致，索引、SQL已经优化道了瓶颈，经常出现数据库负载被拉高
- 大表多，难在数据库上做DDL，可能会引起核心写库负载升高、主从延迟等问题
- 模型复杂，开发、迭代成本高，查询索引字段散落在多个表中，导致查询性能下降
  
  2.目标
  
  业务层面：提升核心查询/导出体验，加强查询性能，优化不合理的查询条件
  
  技术层面：1.减少慢SQL，降低数据库负载，提高系统稳定性；2.降低单表数据量级；3.简化数据模型
  
  3.挑战
  
  提升海量数据、复杂场景下的查询性能！
采购订单系统 VS C端销售订单系统复杂度对比：

| 对比项 | 采购订单系统 | C端订单销售系统 |
| ----- | ---------------------------------------------------------- | ------------------- |
| 分库逻辑 | 使用采购单号分库 | 按用户pin分库分表 |
| 查询场景 | 面向采销、接口人、供应商、仓储运营提供包括采销员、单号、SKU、供应商、部门、配送中心、库房等多场景复杂查询 | 主要是按用户pin进行订单查询 |
| 单据所属人 | 采购单生成后，采销可以进行单据转移 | 订单生成后订单所属人不变 |
| 数据倾斜 | 单一采销或供应商存在大量采购单，并且自动补货会自动创建采购单 | C端一个用户pin下订单数量有限 |

4.方案

思路

![在这里插入图片描述](https://s3.cn-north-1.jdcloud- ... y..jpg)

优化前

![在这里插入图片描述](https://s3.cn-north-1.jdcloud- ... mt.png)

优化后

![在这里插入图片描述](https://s3.cn-north-1.jdcloud- ... Ca.png)

4.1 降低查询数据量

4.1.1 前期调研

基于历史数据、业务调研分析，采购订单只有8%的订单属于“需要实际送货至京东库房”的范围，也就是拥有完整订单履约流程、业务核心关注时效的。其余订单属于通过客户订单驱动，在采购系统的生命周期只有创建记录

![在这里插入图片描述](https://s3.cn-north-1.jdcloud- ... W..jpg)

基于以上结论，在与产品达成共识后，提出新的业务领域概念：“入库订单” ，在查询时单独异构这部分订单数据（前期也曾考虑过，直接从写入层面拆分入库订单，但是因为开发成本、改动范围被pass了）。异构这部分数据实际也参考了操作系统、中间件的核心优化思路，缓存访问频次高的热数据

4.1.2 入库订单异构

执行流程

![在这里插入图片描述](https://s3.cn-north-1.jdcloud- ... F..jpg)
“入库”订单数据打标
- 增量订单在创建订单完成时写入；存量订单通过离线表推数
- 需要订单创建模块先完成改造上线，再同步历史，保证数据不丢
- 如果在【数据解析模块】处理binlog时无法及时从JimKV获取到订单标识，会补偿反查数据库并回写JimKV，提升其他表的binlog处理效率
binlog监听
- 基于公司的【数据订阅】任务，通过消费JMQ实现。其中订阅任务基于订单号进行MQ数据分区，并且在消费端配置不允许消息重试，防止消息时序错乱
- 其中，根据订单号进行各个表的MQ数据分区，第一版设计可能会引起热分区，导致消费速率变慢，基于这个问题识别到热分区主要是由于频繁更新订单明细数据导致（订单(1)->明细(N)），于是将明细相关表基于自身id进行分区，其他订单纬度表还是基于订单号。这样既不影响订单数据更新的先后顺序，也不会造成热分区、还可以保证明细数据的准确性
数据同步
- 增量数据同步可以采用源库的增量binlog进行解析即可，存量数据通过申请新库/表，进行DTS的存量+增量同步写入，完成binlog生产
- 以上是在上线前的临时链路，上线后需要切换到源库同步binlog的增量订阅任务，此时依赖“位点回拨”+“数据可重入”。位点回拨基于订阅任务的binlog时间戳，数据可重入依赖上文提到的MQ消费有序以及SQL覆盖写
数据校对
- 以表为纬度，优先统计总数，再随机抽样明细进行比对
- 目前入库订单量为稳定在5000万，全部实时订单量级6.5亿，降低92%
  
  4.2 提升复杂查询能力
  
  4.2.1 数据准备
考虑到异构“入库”订单到JED，虽然数据查询时效性可以有一定保障，但是在复杂查询能力以及识别“非入库”订单还没有支持
其中，“非入库”订单业务对于订单数据时效性要求并不高（1.订单创建源于客户订单；2.没有履约流程；3.无需手动操作订单关键节点）
所以，考虑将这部分查询能力转移到ES上

ES数据异构过程

![在这里插入图片描述](https://s3.cn-north-1.jdcloud- ... D..jpg)
首先，同步到ES的数据的由“实时+归档”订单组成，其中合计20亿订单，顺带优化了先前归档ES大索引（所有订单放在同一个索引）的问题，改成基于“月份”存储订单，之所以改成月份是因为根据条件查询分两种：1.一定会有查询时间范围（最多3个月）；2.指定单号查询，这种会优先检索单号对应的订单创建时间，再路由到指定索引
其次，简化了归档程序流程，历史方案是程序中直接写入【归档JED+归档ES】，现在优化成只写入JED，ES数据通过【数据解析模块】完成，简化归档程序的同时，提高了归档能力的时效性
再次，因为ES是存储全量订单，需要支持复杂条件的查询，所以在订单没有物理删除的前提下，【数据解析模块】会过滤所有delete语句，保证全量订单数据的完整性
接着，为了提升同步到ES数据的吞吐，在MQ消费端，主要做了两方面优化：1.会根据表和具体操作进行binlog的请求合并；2.降低对于ES内部refresh机制的依赖，将2分钟内更新到ES的数据缓存到JimKV，更新前从缓存中获取
最后，上文提到，同步到入库JED，有的表是根据订单号，有的表是根据自身id。那么ES这里，因为NoSQL的设计，和线程并发的问题，为了防止数据错误，只能将所有表数据根据单号路由到相同的MQ分区

4.2.2 查询调度策略设计

优化前，所有的查询请求都会直接落到数据库进行查询，可以高效查询完全取决于用户的筛选条件是否可以精准缩小数据查询范围

优化后，新增动态路由层
离线计算T-1的采销/供应商的订单数据倾斜，将数据倾斜情况推送到JimDB集群
根据登陆用户、数据延迟要求、查询数据范围，自动调度查询的数据集群，实现高性能的查询请求

查询调度

![在这里插入图片描述](https://s3.cn-north-1.jdcloud- ... m..jpg)

5.ES主备机制&数据监控

1.主/备ES可以通过DUCC开关，实现动态切换，提升数据可靠性

2.结合公司的业务监控，完成订单数据延迟监控（数据同步模块写入时间-订单创建时间）

3.开启消息队列积压告警

5.1 ES集群主/备机制

1：1ES集群进行互备，应急预案快速切换，保证高可用

![在这里插入图片描述](https://s3.cn-north-1.jdcloud- ... r3.png)

5.2 数据监控

![在这里插入图片描述](https://s3.cn-north-1.jdcloud- ... xO.png)

6.灰度上线
第一步，优先上线数据模块，耗费较多时间的原因：1.整体数据量级以及历史数据复杂度的问题；2.数据同步链路比较长，中间环节多
第二步，预发环境验证，流量回放并没有做到长周期的完全自动化，根因：1.项目周期相对紧张；2.新老集群的数据还是有一些区别，回放脚本不够完善
第三步，用户功能灰度，主要是借助JDOS的负载均衡策略结合用户erp完成
第四部，对外接口灰度，通过控制新代码灰度容器个数，逐步放量

![在这里插入图片描述](https://s3.cn-north-1.jdcloud- ... E..jpg)

7.成果

平稳切换，无线上问题

| 指标 | 具体提升 |
| ----------- | --------------------------------------------------------------------------------------------------------------------------- |
| 采购列表查询（ms） | 1、TP999：4817 优化到 2872，提升40.37% 2、超管、部门管理员由无法查询超过一周范围的订单，优化为可以在2秒内查询3个月的订单 3、页面删除“是否归档”查询条件，简化业务操作 4、页面新增“是否入库”查询条件，聚焦核心业务数据 |
| 仓储运营列表（ms） | TP999：9009 优化到 6545，提升27.34% |
| 采购统计查询（ms） | TP999：13219 优化到 1546，提升88.3% |
| 慢SQL指标（天纬度） | 1、1s-2s慢SQL数：820->72，降低91% 2、2s-5s慢SQL数：276->26，降低90% 3、5s以上慢SQL数：343->6，降低98% |

8.待办
主动监控层面，新增按照天纬度进行数据比对、异常告警的能力，提高问题发现率
优化数据模型，对历史无用订单表进行精简，降低开发、运维成本，提升需求迭代效率
精简存储集群
- 逐步下线其他非核心业务存储集群，减少外部依赖，提高系统容错度
- 目前全量订单ES集群已经可以支持多场景的外部查询，未来考虑是否可以逐步下线入库订单JED
识别数据库隐患，基于慢日志监控，重新梳理引入模块，逐步优化，持续降低数据库负载
MySQL减负，探索其他优化方案，减少数据量存储，提升数据灵活性。优先从业务层面出发，识别库里进行中的僵尸订单的根因，进行分类，强制结束
降级方案，当数据同步或者数据库存在异常时，可以做到秒级无感切换，提升业务可用率

9.写在最后
为什么没考虑Doris？因为ES是团队应用相对成熟的中间件，处于学习、开发成本考虑
未来入库的JED相关表是否可以下掉，用ES完全替代？目前看可以，当初设计冗余入库JED也是出于对于ES不确定性以及数据延迟的角度考虑，而且历史的一部分查询就落在了异构的全量实时订单JED上。现在，JED官方也不是很推荐非route key的查询。最后，现阶段因为降低了数据量和拆分了业务场景，入库JED的查询性能还是非常不错的
因为项目排期、个人能力的因素，在方案设计上会有考虑不周的场景，本期只是优化了最核心的业务、技术痛点，未来还有很大持续优化的空间。中间件的使用并不是可以优化数据库性能的银弹，最核心的还是要结合业务以及系统历史背景，在不断纠结当中寻找balance

基于 INFINI Pizza 为 Hugo 静态站点添加搜索功能

INFINI Labs 小助手发表了文章 • 0 个评论 • 3014 次浏览 • 2024-08-28 21:52 • 来自相关话题

换掉ES? Redis官方搜索引擎，效率大幅提升

Fred2000 发表了文章 • 2 个评论 • 3469 次浏览 • 2024-05-30 10:08 • 来自相关话题

RediSearch是一个Redis模块，为Redis提供查询、二次索引和全文搜索。要使用RediSearch，首先要在Redis数据上声明索引。然后可以使用重新搜索查询语言来查询该数据。

RedSearch使用压缩的反向索引进行快速索引，占用内存少。RedSearch索引通过提供精确的短语匹配、模糊搜索和数字过滤等功能增强了

![](https://elasticsearch.cn/uploa ... 66.jpg)

实现特性

基于文档的多个字段全文索引
高性能增量索引
文档排序（由用户在索引时手动提供）
在子查询之间使用 AND 或 NOT 操作符的复杂布尔查询
可选的查询子句
基于前缀的搜索
支持字段权重设置
自动完成建议（带有模糊前缀建议）
精确的短语搜索
在许多语言中基于词干分析的查询扩展
支持用于查询扩展和评分的自定义函数
将搜索限制到特定的文档字段
数字过滤器和范围
使用 Redis 自己的地理命令进行地理过滤
Unicode 支持（需要 UTF-8 字符集）
检索完整的文档内容或只是ID 的检索
支持文档删除和更新与索引垃圾收集
支持部分更新和条件文档更新

对比 Elasticsearch

如下图所示，RediSearch 构建索引的时间为 221 秒，而 Elasticsearch 为 349 秒，快了 58%。

![](https://elasticsearch.cn/uploa ... f2.jpg)

索引构建测试

我们模拟了一个多租户电子商务应用程序，其中每个租户代表一个产品类别并维护自己的索引。对于此基准测试，我们构建了 50K 个索引（或产品），每个索引最多存储 500 个文档（或项目），总共 2500 万个文档。

RediSearch 仅用了 201 秒就构建了索引，平均每秒运行 125K 个索引。然而，Elasticsearch 在 921 个索引后崩溃了，显然它不是为应对这种负载而设计的。

![](https://elasticsearch.cn/uploa ... 95.jpg)

查询性能测试

一旦数据集被索引，我们就使用在专用负载生成器服务器上运行的 32 个客户端启动两个单词的搜索查询。如下图所示，RediSearch 吞吐量达到了 12.5K 操作/秒，而 Elasticsearch 为 3.1K 操作/秒，速度提高了 4 倍。

此外，RediSearch 延迟稍好一些，平均为 8 毫秒，而 Elasticsearch 为 10 毫秒。

安装

安装目前分为源码和docker安装两种方式。

源码安装

bash git clone <a href="https://github.com/RediSearch/RediSearch.git" rel="nofollow" target="_blank">https://github.com/RediSearch/RediSearch.git</a> cd RediSearch # 进入模块目录 make setup make install 

docker安装

bash note: RediSearch的安装比较复杂原包无法进行编译操作所以我们使用docker安装 docker run -p 6379:6379 redislabs/redisearch:latest 

判断是否安装成功

bash 127.0.0.1:0>module list 1) 1) "name" 2) "ReJSON" 3) "ver" 4) "20007" 2) 1) "name" 2) "search" 3) "ver" 4) "20209" 
返回数组存在“ft”或 “search”(不同版本)，表明 RediSearch 模块已经成功加载。

命令行操作

1、创建

1.1 创建索引

创建索引不妨想象成创建表结构，表一般基本属性有表名、字段和字段类别等，所以我们可以考虑将索引名代表表名，字段代表字段，属性即表示属性。
bash xxx.xxx.xxx.xxx:0>ft.create "student" schema "name" text weight 5.0 "sex" text "desc" text "class" tag "OK" 
student 表示索引名，name、sex、desc表示字段，text表示类型（这样表示只是为了便于理解）

“weight”为权重，默认值为 1.0
bash type student "none" 
我们创建的索引redis是不认识的，这证明使用的是插件。

1.2 创建文档

创建文档上下文的过程不妨想想成向表中插入数据，这里请注意字段名可以使用双引号但切记一定要用英文，这里之所以着重提出是因为有些编译器中文双引号和英文双引号用肉眼实在难以辨认否则会出现 “Fields must be specified in FIELD VALUE pairs”（其实是将“ 当作内容处理了以至于缺少了字段）
bash ft.add student 001 1.0 language "chinese" fields name "张三" sex "男" desc "这是一个学生" class "一班" "OK" 
其中001为文档ID,"1.0"为评分缺少此值会报"Could not parse document score"异常，language 指明使用的语言默认是英文编码如果没有此标记存储是没有问题的但不可以通过中文字符查询

1.3 查询

1.3.1 基本查询

1.3.1.1 全量查询

bash xxx.xxx.xxx.xxx:0>FT.SEARCH student * SORTBY sex desc RETURN 3 name sex desc 1) "2" 2) "001" 3) 1) "name" 2) "张三" 3) "sex" 4) "男" 5) "desc" 6) "这是一个学生" 4) "002" 5) 1) "name" 2) "张三" 3) "sex" 4) "男" 5) "desc" 6) "这是一个学生" 
1.3.1.2 匹配查询
bash xxx.xxx.xxx.xxx:0>ft.search student "张三" limit 0 10 RETURN 3 name sex desc 1) "2" 2) "001" 3) 1) "name" 2) "张三" 3) "sex" 4) "男" 5) "desc" 6) "这是一个学生" 4) "002" 5) 1) "name" 2) "张三" 3) "sex" 4) "男" 5) "desc" 6) "这是一个学生" 
limit 与mysql相识主要用于分页，此处是全量匹配，如果没有设置language “chinese” 此处查询为0，

1.3.2 模糊匹配

1.3.2.1 后置匹配

bash ft.search student "李*" SORTBY sex desc RETURN 3 name sex desc 1) "1" 2) "003" 3) 1) "name" 2) "李四" 3) "sex" 4) "男" 5) "desc" 6) "这是一个学生" 

1.3.2.2 模糊搜索

bash xxx.xxx.xxx.xxx:0>FT.SEARCH beers "%%张店%%" 1) "1" 2) "beer:1" 3) 1) "name" 2) "集团本部已发布【文明就餐公约】，2号楼办公人员午餐的就餐时间是11:45~13:00，现经行政服务部进行抽查，发现我们部门有员工违规就餐现象。请大家务必遵守，相互转告，对于外地回到集团办公的同事，亦请遵守，谢谢！" 3) "org" 4) "山东省淄博市张店区" 5) "school" 6) "山东理工大学" 

别高兴太早全量模糊匹配是由很大限制的，他基于Levenshtein距离（LD）进行模糊匹配。术语的模糊匹配是通过在术语周围加“%”来实现的，模糊匹配的最大LD为3，确切的说这只是一种相识度查询，并非一般意义上的模糊搜索，但是如果仔细观察会发现通过精确匹配时不仅能够将完整value值查询出来而且还查询出其他处于文档某个位置的key请看官方提供的一个例子：
 FT.CREATE idx SCHEMA txt TEXT FT.ADD idx docCn 1.0 LANGUAGE chinese FIELDS txt 

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。从盘可以有意无意的对数据进行写操作。

由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

```
FT.CREATE idx SCHEMA txt TEXT
FT.ADD idx docCn 1.0 LANGUAGE chinese FIELDS txt "Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。从盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。[8]"
FT.SEARCH idx "数据" LANGUAGE chinese HIGHLIGHT SUMMARIZE

Outputs:

数据?... 数据进行写操作。由于完全实现了发布... 数据冗余很有帮助。[8...

 之所以会出现这样的效果是因为redisearch对文本进行了分词，其使用的工具是friso相比es的ik还是弱一些前者主要是对中文分词，体积小可移植性强。 从而我们可以结合后后置匹配算法  bash
xxx.xxx.xxx.xxx:0>FT.SEARCH idx "数" LANGUAGE chinese HIGHLIGHT
1) "1"
2) "docCn"
3) 1) "txt"
2) "Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。从盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。[8]"

 或者结合Levenshtein算法这样基本上能够满足业务查询需求  bash
xxx.xxx.xxx.xxx:0>FT.SEARCH idx "%%单的树%%" LANGUAGE chinese HIGHLIGHT
1) "1"
2) "docCn"
3) 1) "txt"
2) "Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。从盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。[8]"
 1.3.2.3 字段查询 通过字段查询也可以实现模糊搜索，直接给例子，后面跟着官网上给的sql 和 redisearch的对照表  bash
ft.search student
1) "2"
2) "doudou"
3) 1) "name"
2) "豆豆"
3) "jtzz"
4) "“检索”是很多产品中"
5) "phone"
6) "18563717107"

4) "ttao"
5) 1) "name"
2) "姚元涛"
3) "jtzz"
4) "一个生病的人只"
5) "phone"
6) "18563717107"

ft.search student '@phone:185* @name:豆豆'
1) "1"
2) "doudou"
3) 1) "name"
2) "豆豆"
3) "jtzz"
4) "“检索”是很多产品中"
5) "phone"
6) "18563717107"
 **1.4 删除** 1.4.1 删除文档  bash
xxx.xxx.xxx.xxx:0>ft.del student 002
"1"
 1.4.3 删除索引  bash
xxx.xxx.xxx.xxx:0>ft.drop student
"OK"
 **1.5 查看** 1.5.1 查看所有索引  bash
xxx.xxx.xxx.xxx:0>FT._LIST
1) "student1"
2) "ttao"
3) "idx"
4) "student"
5) "myidx"
6) "123"
7) "myIndex"
8) "testung"
9) "student2"
 1.5.2 查看索引文档中的数据 1.5.2.1 获取单条数据  bash
xxx.xxx.xxx.xxx:0>ft.get student 001
1) "name"
2) "张三"
3) "sex"
4) "男"
5) "desc"
6) "这是一个学生"
7) "class"
8) "一班"
 1.5.2.2 获取多条数据  bash
xxx.xxx.xxx.xxx:0>ft.mget student 001 002
1) 1) "name"
2) "张三"
3) "sex"
4) "男"
5) "desc"
6) "这是一个学生"
7) "class"
8) "一班"

2) 1) "name"
2) "张三"
3) "sex"
4) "男"
5) "desc"
6) "这是一个学生"
7) "class"
8) "一班"
 **1.6 索引别名操作** 1.6.1 添加别名  bash
123.232.112.84:0>FT.ALIASADD xs student
"OK"
 给索引student起个xs的别名，一个索引可以起多个别名 1.6.2 修改别名 1.6.3 删除别名  bash
123.232.112.84:0>FT.ALIASDEL xs
"OK"
```

作者：架构师公众号

来源：https://mp.weixin.qq.com/s/TmCXx3rLjLPggvOFjGqS9w

版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!

求大佬门指点一下职业方向?

贡献

emmning 回复了问题 • 3 人关注 • 2 个回复 • 2756 次浏览 • 2024-04-08 10:09 • 来自相关话题

使用Watcher实现应用日志的关键字监控，是不是一个好方案？

Jasonspeaking 发起了问题 • 1 人关注 • 0 个回复 • 2907 次浏览 • 2023-12-11 10:51 • 来自相关话题

搜索客：Elasticsearch 中文社区的崭新征程

medcl 发表了文章 • 0 个评论 • 4811 次浏览 • 2023-11-13 19:58 • 来自相关话题

Elasticsearch 中文社区在不知不觉中已经走过了十二个春秋。这段时间，我们有幸因为 Elasticsearch 相识，相聚于线上线下的社区活动，共同切磋技术，互相吐槽。从最初的 QQ 群到后来的微信群，从最初几个人的小聚到后来接近千人的大会，社区的成长仿佛是一场神奇的旅程。Elasticsearch 中文社区一直保持着一种松散而亲切的组织形式，相信参与社区活动的小伙伴们都能感受到我们与其他社区的不同之处。

社区就是一个大家庭，很多小伙伴可能现在已经没有活跃在相关领域了，但是在咱们社区发展的过程中，有很多优秀的小伙伴积极参与做出了大量杰出的贡献，第一次大会的场地离不开 @三斗室的大力支持，还记得只有 20-30 号人，糙的很，连拍照都没有来得及进行，社区里面带来各种干货分享 @wood 大叔，一直在社区默默奉献的石阳，说学逗唱样样精通的斌哥，深圳分会的杨振涛，武汉分会的白凡，南京分会的李啸，广州分会的鸿智等等其他各个城市的社区分会主席们，咱们甚至台湾还有分会，还记得 Advent 分享文章接力么，还记得咱们的翻译小组么，还记得咱们一起通宵达旦编写 Elasticsearch 权威指南中文版本的的日子么， 80 多人浩浩荡荡分成 5 个团队，中国开源史上最早的大协作，咱们还有社区编辑部，现在还在坚持每天一篇相关行业新闻的社区日报社，迄今为止已经 1700 多期了，还有每次大会的志愿者们，还有给咱们社区带来几百个分享的嘉宾们，名字实在太多了，不能一一列举了，但我都记下了，这个社区正是因为有了你们，才这么精彩，感谢你们。

然而，没有哪项技术能永远保持新鲜活力，当一些技术逐渐成熟，相应的讨论似乎也变得有限。然而，搜索领域的从业者并未停止前行的脚步，每一年都有新的搜索技术涌现，今年的最火话题必然是 GenAI 或者 AIGC 啦，Embedding、LLM、向量数据库、RAG 摩拳擦掌，传统搜索是否还能再战几个回合？硬件发展也是一日千里，几百核，上 TB SSD 的机器成为常态，快速迭代的硬件架构需要与时俱进的软件架构，兼顾安全和高效的 Rust 发展也是热火朝天，我于 2021 年底离开 Elastic 出来创办了 INFINI Labs 也在积极探索下一代搜索引擎的发展，不过可以预见的是，未来的搜索必定将更加智能化，性能更加强悍，使用更加简单，相信大家和我一样我对新技术的发展充满了期待，拭目以待吧。

从业十多年来一直在围绕搜索打转，深感搜索技术所涵盖的领域极为广泛，从文本分析到从自然语言处理，从算法到数据结构，从单机高性能到海量 PB 分布式，从机器学习到大模型，从传统的运维日志分析到上天揽月的前沿科技，都有搜索技术的身影。众行致远，国外有类似 BERLIN BUZZWORDS 这样优质的大会和交流社区，而国内这样垂直且优质的社区还相对较为缺乏，希望咱们的社区能够成为这样一个专注于搜索领域的小圈子。并且应该更加开放，除了 Elasticsearch，其他任何跟搜索相关的技术和框架我们都欢迎交流，也希望国内更多和我们一样参与搜索核心技术研究的厂商和同仁们也能参与进来，并且希望在这里，不仅是可以围绕搜索的各种相关技术进行讨论交流，还能找到志同道合的朋友一起共同进步，共同构建一个咱们自己的小家园。

因此，Elasticsearch 中文社区进行全新的品牌升级，正式更名为“搜索客”，以新的 Slogan：“搜索人自己的社区” 为宣言，并以全新的面貌来迎接社区的小伙伴们，相信你们已经注意到了我们的社区网站已经更新了全新的 Logo 和视觉风格，后续调整完毕也将启用新的域名：searchkit.org/searchkit.cn。我们期望新的搜索客社区能够为广大搜索领域的从业者提供更为丰富和便捷的交流平台。希望在这里，我们能够共同见证搜索技术的新篇章，为整个搜索领域的发展添砖加瓦。

Medcl

AIGC出海创新产业峰会

OSTech 发表了文章 • 0 个评论 • 2659 次浏览 • 2023-06-11 18:17 • 来自相关话题

使用 Easysearch，日志存储少一半

xiaoshi2 发表了文章 • 2 个评论 • 2761 次浏览 • 2023-05-16 11:37 • 来自相关话题

在海量日志存储场景中，索引膨胀率是一个关键指标，直接影响存储成本和查询性能。它表示原始数据与索引数据在磁盘上所占空间的比率。较高的索引膨胀率不仅增加了存储成本，而且可能会影响查询速度，尤其是在 I/O 密集型的查询中。因此，我们需要密切关注和优化索引膨胀率。接下来，我们将比较 Elasticsearch 和 Easysearch 在处理相同数据时的索引膨胀率。

测试结果

一图胜千言，下图是 Easysearch v1.1 和 Elasticsearch v6.4.3 的索引大小测试对比，Y 轴单位是 MB。

使用 Easysearch v1.1 的压缩功能，比 Elasticsearch v6.4.3 的索引大小降低了 50%。

![](https://www.infinilabs.com/img ... p1.png)

测试说明

以下是对 Elasticsearch v6.4.3 版本，测试数据 500 万条大小 1.054G(1080M)的 nginx 日志，使用 es 默认的 mapping，分别用 best_compression 和 default 的压缩策略进行写入。
Elasticsearch v6.4.3

| 索引 | 大小(MB) | 膨胀率 | 条数(万) |
| ---------------- | -------- | ------ | -------- |
| nginx_default_1g | 1812.61 | 1.61 | 500 |
| nginx_best_1g | 1551.36 | 1.42 | 500 |

然后我们对比下，使用极限科技的 Easysearch 进行索引膨胀率的压测.

Easysearch 是什么？

INFINI Easysearch 衍生自基于开源协议 Apache 2.0 的 Elasticsearch 7.10 版本。 Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本，并继续完善和支持更多的企业级功能，与 Elasticsearch 相比，Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。
安装包大小只有 54 兆，相比 Elasticsearch 动辄一两百兆的安装包更加轻量级。
Easysearch v1.1

| 索引 | 大小(MB) | 膨胀率 | 条数(万) |
| ---------------- | -------- | ------ | -------- |
| nginx_default_1g | 1514 | 1.33 | 500 |
| nginx_best_1g | 1286 | 1.138 | 500 |
| nginx_zstd_1g | 1015.3 | 0.94 | 500 |
| nginx_reuse_1g | 758.39 | 0.70 | 500 |

注意上面使用到的 Easysearch 的压缩策略有 4 种:

| 压缩策略 | 描述 |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| default | 和 Elasticsearch 的 default 压缩策略一致。 |
| best_compression | 和 Elasticsearch 的 best_compression 一致。 |
| ZSTD | ZSTD（Zstandard）是一种开源的压缩算法和压缩库，旨在提供高性能和高压缩比的数据压缩解决方案。由 Facebook 开发并开源的一个压缩库，Easysearch 1.1 版引入了这个压缩算法作为一个可选的压缩策略，分别对存储字段，doc_values，和词典文件进行了压缩，并且 Easysearch 使用的 zstd 是纯 java 版，不依赖底层的操作系统和 cpu 架构，无需单独编译可以直接部署在国产的操作系统和芯片上。 |
| index.source_reuse | Easysearch v1.1 新增加的一个索引配置项，表示是否对 source 中的字段进行复用，熟悉 Elasticsearch 存储结构的都知道，es 底层依赖 lucene 作为核心的存储和查询引擎，默认 mapping 下，在将 es 的字段解析成 lucene 的对应字段后，一个 keyword 类型的字段会分别存储在 _source 和 doc_values 字段里，Easysearch 将 keyword 字段在 source 存储时进行了过滤，然后在查询阶段又利用 doc_values 对 source 里过滤的 keyword 字段进行了无缝拼接，用户层面感知不到对 keyword 字段的特殊处理。 |

default 和 best_compression 比之前 6.43 版的膨胀率降低是因为得益于 lucene 版本的升级到了 8.11.2，新版的 lucene 的压缩比之前的版本有了很大提升。
重点是最后利用 ZSTD 加 index.source_reuse，存储资源的占用比之前 6.43 版本的 best_compression 的 1.5G 减少了 50%，对比相同 lucene 版本的 best_compression，存储资源也减少了 40%，带来以下几点好处：

降低存储成本：较低的索引膨胀率意味着存储相同量的数据需要更少的磁盘空间，这将直接减少硬件和维护成本。
提高系统扩展性：由于索引占用的存储空间较小，可以在相同的硬件上处理更多的数据，或者在扩展存储时，需要添加的硬件更少。
更高效的数据备份和传输：小的索引文件意味着备份和传输数据的时间和带宽需求都会减少。

使用方法

```

启用ZSTD

PUT nginx_zstd
{
"settings": {
"codec": "ZSTD"
}
}

启用index.source_reuse

PUT nginx_reuse
{
"settings": {
"index.source_reuse": true
}
}

结合使用

PUT nginx_reuse
{
"settings": {
"codec": "ZSTD",
"index.source_reuse": true
}
}
```

最后附上 Easysearch 的下载地址，欢迎大家下载试用。
[https://www.infinilabs.com/dow ... earch](https://www.infinilabs.com/dow ... search)

助力 Elasticsearch 国产化，极限科技受邀参加 2023 移动云大会

liaosy 发表了文章 • 0 个评论 • 3008 次浏览 • 2023-05-10 18:03 • 来自相关话题

近日，2023 移动云大会“数据库&云原生创新”论坛在苏州隆重召开。现场精英荟萃、专家云集，共同探讨数据库与云原生技术发展及应用落地方案，为助力推动云原生数据库产业发展建言献策。极限科技创始人兼 CEO 曾勇受邀出席论坛。

![](https://www.infinilabs.com/img ... p1.png)

会上，极限科技创始人兼 CEO 曾勇针对《Elasticsearch 国产化在移动云的演进之路》主题进行演讲，演讲围绕了什么是 Elasticsearch 以及 Elasticsearch 在移动云上的国产化演进过程。

Elasticsearch 在移动云的演进

随着数字化转型的不断深化，非结构化数据日益成为各类组织数据的增长主力，但其在管理和应用方面仍面临模态多样、管理复杂、检索挖掘难度大等挑战。为此，极限科技与移动云共同研发出搜索型数据库软件 Easysearch。

“Easysearch” 是极限科技在 Elasticsearch 软件原版本基础上，立足中国企业需求，助力移动云打造更符合其需求，独具 8 大特色功能的自有开源平替版本系统。-- 极限科技创始人兼 CEO 曾勇在会上介绍道

移动云版本 “Easysearch” 精简 Kernel ，只保留开源核心能力，回归轻量化；增强内核后，可更稳定可靠地支持万亿级数据规模；为进一步增强安全能力，系统支持字段内容脱敏的同时对字段级别采取权限控制；可降低灾难恢复时间，系统具备完整的备份与容灾能力，可实时切换；为更好地服务业务场景，此版本更关注搜索场景的优化；增强型中文分词，提供本地化的词库与拼音支持；增强数据压缩能力后，最高可降低 40%存储空间；信创兼容的系统，支持适配国产操作系统和 CPU 芯片。

目前 Elasticsearch 为移动云提供的后端架构，已由基于 Docker 容器的“移动云 ES v1.0”升级为基于 K8s 架构的“移动云 ES v2.0”版本。其优势可以体现在：

新版本更具自主可控性，应对新需求更具灵活性；

基于 K8s 架构的系统，能支持更大规模的集群服务；

在支持全链路 IPv6 和本地磁盘（IO 隔离）的基础上，实现了更优性能的升级。

![](https://www.infinilabs.com/img ... p2.png)

Elasticsearch 在中国已有近十万+开发者，上万家企业已经在生产环境大规模运行 Elasticsearch，服务客户包括知名互联网公司及大型企事业单位，覆盖全国范围内生活消费、金融投资、娱乐学习、软件应用与安全等领域知名企业。-- 极限科技创始人兼 CEO 曾勇在会上介绍道

极限科技创始成员多来自 Elasticsearch 中国团队，深耕搜索及 Elasticsearch 十多年，且运营有国内最大的开源搜索技术社区，极限科技团队具备雄厚的技术实力和丰富的相关行业经验技术积累。

国产化替代的首选方案“Easysearch”

目前实时大数据搜索分析，尤其是结构化和非结构化数据结合的场景和需求非常大。针对海量数据，搜索技术成为核心，大多数企业都有不止部署一套搜索后端服务来满足各个场景的搜索业务需求。-- 极限科技创始人兼 CEO 曾勇在会上介绍道

Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本，并继续完善和支持更多的企业级功能。该软件衍生自开源的搜索引擎软件 Elasticsearch，具备相当的接口兼容能力，对于目前国内广大的 Elasticsearch 用户来说切换和接入的成本非常低。

与 Elasticsearch 相比，Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。基于团队在搜索和 Elasticsearch 生态的多年深耕，极限科技已具备完全自主自研可控能力，Easysearch 因更符合国产搜索技术生态需求，目前逐渐成为 Elasticsearch 国产化替代的首选方案。

作为一款具备自主可控的分布式近实时搜索型数据库产品 Easysearch 具备高性能、高可用、弹性伸缩、高安全性等特性，支持丰富的个性化搜索及聚合分析，且能承载 PB 级别的海量业务数据，可部署在物理机、虚拟机、容器、私有云和公有云，为金融核心系统、运营商、制造业和政企业务系统提供安全、稳定、可靠的快速检索和实时数据探索分析能力，满足不同业务场景的各项复杂需求。

持续丰富完善企业级服务能力

随着国内搜索型数据库的迅速发展，关键技术逐渐突破，应用场景和数据规模也逐年上升，已经成为企业必不可少的核心基础设施，产业生态日益繁荣。

截至目前，极限科技与移动云合作共建的 Easysearch 系统，已在无锡、呼和浩特、南基这 3 个城市上线，此外还有北京、上海、重庆、宁波、海南等 9 个城市的资源池正在上线中。-- 极限科技创始人兼 CEO 曾勇介绍道。

作为全球领先的近实时搜索数据库技术提供商，极限科技始终致力于搜索核心技术的研发与创新，基于国内搜索型数据库行业生态需求，在产品研发创新上，着力提升产品易用性、实时性、降低 IT 成本等，为推动国内搜索行业技术水平及相关技术社区的发展，建设数据强国提供强有力的基础技术支撑。

极限科技自成立起始终致力于提供本地化配套产品及解决方案，帮助客户解决在使用 Elasticsearch 时遇到的各种挑战。未来，极限科技将基于更多的真实客户场景提供个性化服务，持续丰富并完善更多维度、更高需求的企业级服务能力，与移动云等众多行业平台一起构建更“简单”的搜索服务。

关于极限科技

![](https://www.infinilabs.com/img ... bs.png)

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。让搜索更简单是我们追求的目标。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

更多详情参见官网 ([https://infinilabs.com](https://infinilabs.com)) 。

国内首家 | 极限科技率先完成信通院搜索型数据库行业标准测试

liaosy 发表了文章 • 0 个评论 • 2302 次浏览 • 2023-05-06 18:21 • 来自相关话题

随着数字化转型的深入，非结构化数据越来越多地出现在各种类型的数据中，成为了最主要的数据元素，其中蕴藏着巨大的价值。根据 IDC 的预测，到 2025 年，非结构化的数据将占到 80%，而高德纳公司的预测，到 2024 年，这一数字将会是现在的三倍。当前，非结构化数据存在表征多样、管理复杂、价值挖掘困难等问题，而基于自动分词、倒排索引、关联度计算、矢量检索等技术的检索数据库，是实现非结构化数据高效处理的基本工具，自 90 年代产生至今，一直在发展和演变，已成为数据库研究的一个重要分支。

顺利完成首个搜索型数据库产品能力测试

《搜索型数据库技术要求》是中国信通院云计算与大数据研究所依托中国通信标准化协会大数据技术标准推进委员会（CCSA TC601）和中国信通院数据库应用创新实验室（CAICT DBL），联合阿里云、拓尔思、极限科技、星环科技、科大讯飞、百度、联通软研院等多家企业专家参与编制，融合国内行业专家丰富的实践经验与智慧，对搜索型数据库基础能力进行综合评判的行业权威标准。

2023 年 4 月 18 日，在中国信通院组织的第一批“搜索型数据库”产品能力评测中，极限数据 (北京) 科技有限公司（以下简称：极限科技）的 INFINI Easysearch 搜索型数据库软件【Easysearch】顺利完成了首个搜索型数据库产品能力测试。该测评依据《搜索型数据库技术要求》进行，该标准融合了国内行业专家丰富的实践经验与智慧，是对搜索型数据库基础能力的综合评判，覆盖数据库基本能力、数据库管理能力、数据库安全能力、数据库兼容能力、数据库扩展能力、数据库高可用能力，共计 32 个测试项目，包括 12 个必选项和 20 个可选项。

![](https://www.infinilabs.com/img ... p1.png)

搜索型数据库在各行业的重要应用

1.金融行业:搜索型数据库可以帮助金融机构快速检索和分析海量的客户交易数据，预测市场趋势、评估客户风险、优化交易策略等。

2.通信行业:搜索型数据库可以帮助运营商管理和分析海量的网络数据，例如网络流量、网络性能、用户活跃度等，从而提高网络效率和用户体验。

3.制造业:搜索型数据库可以帮助制造企业高效管理和分析海量的生产数据，例如生产效率产品质量、供应链信息等，从而提高生产效率和产品质量。

4.零售行业:搜索型数据库可以帮助零售商快速检索和分析海量的销售数据，例如顾客购买记录、商品销售趋势、促销活动效果等，从而更好地制定营销策略、优化商品库存管理、提高销售业绩等。

5.医疗行业:搜索型数据库可以帮助医疗机构快速检索和分析海量的医疗数据，例如患者病历、医学论文、药品说明书等，从而更好地研究疾病、制定治疗方案、优化医疗资源等。

6.教育行业:搜索型数据库可以帮助教育机构快速检索和分析海量的教学数据，例如学生成绩、课程评价、教师绩效等，从而更好地优化教学策略、提高教学质量等。

INFINI Easysearch

极限科技研发的 INFINI Easysearch，是一款具备自主可控的分布式近实时搜索型数据库产品，具备高性能、高可用、弹性伸缩、高安全性等特性，具备支持丰富的个性化搜索及聚合分析能力，可部署在物理机、虚拟机、容器、私有云和公有云，能承载 PB 级别的海量业务数据，为金融核心系统、运营商、制造业和政企业务系统提供安全、稳定、可靠的快速检索和实时数据探索分析能力，可满足不同业务场景的各项复杂需求。

![](https://www.infinilabs.com/img ... p2.png)

除了 Easysearch，极限科技还提供用于构建企业搜索基础设施的完整解决方案，通过云原生的方式来让企业高效治理大规模搜索集群，将分散的各个业务搜索计算资源合并归拢，通过资源统一调度管控，提升整体资源利用率和系统弹性，降低系统复杂度和 IT 运营成本，来持续满足业务的灵活多变需求，结合统一的安全、监控、告警、运维和管理等能力，达到统一管理、统一治理，降本增效，实现企业的搜索基础设施的平台化运营。

![](https://www.infinilabs.com/img ... p3.png)

国内搜索型数据库最近几年发展迅速，关键技术逐渐突破，应用场景和数据规模也逐年上升，已经成为企业必不可少的核心基础设施，产业生态也日益繁荣。极限科技作为国内搜索型数据库产品厂商第一梯队的杰出代表，同时也是行业标准的起草单位之一，此次测试的成功通过，不仅代表着对 INFINI Easysearch 搜索型数据库软件 Easysearch 的权威性肯定，更代表着极限科技在“搜索数据库”产品的研究与创新上，取得了新的里程碑。

关于极限科技

![](https://www.infinilabs.com/img ... bs.png)

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。让搜索更简单是我们追求的目标。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

更多详情参见官网 ([https://infinilabs.com](https://infinilabs.com)) 。

相关链接

[国内首家 | 极限科技完成搜索型数据库产品评测](https://mp.weixin.qq.com/s/yEd_H1Os_I8y2S4SsXqQYg)

INFINI 产品更新｜Console v1.0 版本正式发布

liaosy 发表了文章 • 0 个评论 • 3175 次浏览 • 2023-04-23 16:09 • 来自相关话题

![INFINI Labs 产品更新发布](https://elasticsearch.cn/uploa ... 90.png)

本次 INFINI Labs 产品更新主要包括 Gateway v1.12.1、Console v1.0.0，其中 Console v1.0.0 是一个重要里程碑版本，该版本做了很多UI交互优化；集成了Github SSO 单点登录功能；新增了数据迁移功能，支持跨搜索引擎、跨版本的数据迁移；新增了数据看板，支持自定义可视化报表；以及修复已知Bug等。值得一提的是，Console 非常轻量级，安装包只有16MB，架构简洁，除了使用 Elasticsearch 当作数据存储外无任何外部依赖，包含监控、告警、安全、可视化分析等日常管理功能，欢迎下载使用。在线体验DEMO：[https://play.infinilabs.com:64443](https://play.infinilabs.com:64443)，用户名密码 readonly/readonly。

INFINI Gateway v1.12.1

极限网关本次更新如下：

Bug fix

Elasticsearch 修复偶现连接断开的问题。
Elasticsearch 修复连接超时未返回错误信息的问题。

更多 Gateway 更新可参考【[Gateway 版本历史](https://www.infinilabs.com/doc ... -notes)】。

INFINI Console v1.0.0

Console 本次主要更新如下：

1、集成 Github 单点登录，方便快速登录，减少用户名和密码登录经常忘记带来的烦恼。详情查看[教程](https://www.infinilabs.com/doc ... users/)

2、新增了工作台界面，作为 Console 登录后的入口页面，可以快速预览整个系统的集群资源概要信息、集群动态、常用功能快捷入口等。

3、新增了数据迁移功能，支持 Elasticsearch、Opensearch、Easysearch 等搜索引擎的所有版本之间相互迁移。需要搭配 最新版本极限网关（INFINI Gateway） 使用，详情查看[教程](https://www.infinilabs.com/doc ... ation/)

4、新增了数据看板功能，支持多标签页，支持折线图、柱状图、饼图等图表，支持用户自定义可视化数据报表，详情查看[教程](https://www.infinilabs.com/doc ... board/)

5、数据探索 Discover 添加搜索关键词高亮功能。

除了以上主要功能外还做了很多优化和Bug fix，如下：

Features
数据迁移添加初始化索引 settings, mappings 可选步骤
数据迁移添加删除功能

Improvements
添加 Opening scroll context 监控指标
数据迁移分区设置优化
优化数据迁移错误日志和异常情况处理
迁移后目标集群和源集群文档数量不匹配，标记迁移任务为失败状态

Bug fix
修复新注册集群状态不同步更新的问题
修复低版本 ES 多 type 分区查询时没有根据 doctype 过滤的问题
修复特殊情况下迁移任务没有被释放的问题
修复迁移任务结束，队列磁盘文件未释放的问题
修复bulk写入失败导致迁移任务卡住的问题

更多 Console 更新可参考【[Console 版本历史](https://www.infinilabs.com/doc ... -notes)】。

期待反馈

欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（[https://github.com/infinilabs](https://github.com/infinilabs)）中的对应项目中提交 Feature Request 或提交 Bug。
INFINI Gateway： [https://github.com/infinilabs/gateway/issues](https://github.com/infinilabs/gateway/issues)
INFINI Console： [https://github.com/infinilabs/console/issues](https://github.com/infinilabs/console/issues)
官网： [https://www.infinilabs.com](https://www.infinilabs.com)
下载地址： [https://www.infinilabs.com/download](https://www.infinilabs.com/download)

您还可以通过邮件联系我们：hello@infini.ltd

或者拨打我们的热线电话：(+86) 400-139-9200

也欢迎大家微信扫码添加小助手（INFINI-Labs），加入用户群讨论，或者扫码加入我们的知识星球一起学习交流。

![联系我们](https://elasticsearch.cn/uploa ... 3.jpeg)

最后祝大家周末愉快！

关于极限科技（INFINI Labs）

![关于极限科技](https://elasticsearch.cn/uploa ... 32.png)

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

【门票赠送】下周！院士及行业专家将齐聚第四届OpenI/O启智开发者大会

OSTech 发表了文章 • 0 个评论 • 1 次浏览 • 2023-02-24 22:52 • 来自相关话题

大会简介

OpenI/O启智开发者大会是OpenI启智社区的年度盛会。大会立足于国际国内开源大环境和发展趋势，侧重AI领域前沿技术分享和自主AI开源项目的展示，汇聚专家学者碰撞思想火花，凝聚发展共识，既有院士级专家们高屋建瓴的点评与引导，又有行业专家最前沿技术的分享，同时也为普通开发者提供大量AI模型与应用开发的线上教学与实践机会。[图片]

大会亮点

专家主题演讲
北京智源人工智能研究院、北京大学、百度等启智社区核心成员单位各自的优秀开源项目分享
2022年度优秀开源项目团队及社区优秀开发者颁奖
设立八个国家级开放创新平台合作签约
启智社区分中心授牌
《中国城市人工智能发展指数报告》发布
为开发者分享各类前沿动态与实践学习的机会
直面各厂商技术专家，获取一线面试经验/机会，还可进入招聘内推面试群
有望于行业大咖合影
结识志同道合的行业伙伴，组织头脑风暴，产生更多思想碰撞

大会主题

算网筑基、开源启智、AI赋能

本届OpenI/O启智开发者大会计划以“算网筑基、开源启智、AI赋能”为主题，邀请国内人工智能开源领域领军院士亲自参与，汇聚学术界、产业界的技术专家，围绕中国算力网资源基座、开源社区服务支撑环境、国家级开放创新应用平台三大部分，探讨如何高效建设适合我国的人工智能开源生态体系，惠及广大开发者群体。

大会信息

时间：2023年2月24日-25日

地点：深圳人才研修院

主题：算网筑基、开源启智、AI赋能

参与方式：

日程安排

2月24日上午 OpenI/O启智开发者大会主论坛

1、领导致辞
2、院士、学者、专家大咖系列Keynotes
3、国家级开放创新平台签约仪式
4、启智分中心授牌仪式
5、CCF开源相关发布
6、《中国城市人工智能发展指数报告》发布
7、启智社区优秀开源项目与开发者颁奖

2月24日下午及25日 OpenI/O启智开发者大会专题分论

1、专场一（24日下午）：
NLP大模型论坛（开源集智创新探索中文NLP大模型生态发展）
2、专场二（24日下午）：
深度学习与大模型产业应用专场（引领前沿技术，推动产业升级）
3、专场三（24日下午）：
开源治理论坛（构建开源联合体，共建开源生态）
4、专场四（25日上午）：
昇腾人工智能应用专场（数智未来，因你而来）
5、专场五（25日上午）：
高校开源专场（因“AI”而“深”）

组织架构

主办单位：鹏城实验室、新一代人工智能产业技术创新战略联盟（AITISA）
承办单位：OpenI启智社区、中关村视听产业技术创新联盟（AVSA）
协办单位：华为技术有限公司、百度在线网络技术（北京）有限公司、CCF开源发展委员会
支持单位：广东省人工智能与机器人学会、国家超高清视频创新中心（深圳）
支持媒体：CSDN、InfoQ、雷峰网
合作机构：LF AI&DATA、OpenSSF基金会、开放原子开源基金会、开源科技OSTech、开源高校OSU、GDG广州、GDG东莞、开放群岛社区、开源中国、昇腾社区、飞桨社区、木兰开源社区、白玉兰开源社区、阿浦美股研究院

展望未来

希望OpenI/O启智开发者大会让更多怀揣着开源梦想的开发者加入到开源创新活动中来，让中国开源技术在万物互联的智慧时代爆发，培养更多高校开源人才，为他们搭建展示自身创造力的平台，形成良性可期的开源持续发展生态。

请教一下es的sort问题

贡献

QuincyXuHa 回复了问题 • 3 人关注 • 2 个回复 • 4937 次浏览 • 2023-03-14 21:05 • 来自相关话题

如何处理文本中带有数字连号的范围段搜索？

贡献

God_lockin 回复了问题 • 2 人关注 • 1 个回复 • 2368 次浏览 • 2022-12-19 11:49 • 来自相关话题

通知设置 新通知

0.前言

1.背景

2.目标

3.挑战

4.方案

思路

优化前

优化后

4.1 降低查询数据量

4.1.1 前期调研

4.1.2 入库订单异构

4.2 提升复杂查询能力

4.2.1 数据准备

4.2.2 查询调度策略设计

5.ES主备机制&数据监控

5.1 ES集群主/备机制

5.2 数据监控

6.灰度上线

7.成果

8.待办

9.写在最后

实现特性

对比 Elasticsearch

索引构建测试

查询性能测试

安装

源码安装

docker安装

判断是否安装成功

命令行操作

1、创建

Outputs:

数据?... 数据进行写操作。由于完全实现了发布... 数据冗余很有帮助。[8...

测试结果

测试说明

Easysearch 是什么？

使用方法

启用ZSTD

启用index.source_reuse

结合使用

Elasticsearch 在移动云的演进

国产化替代的首选方案“Easysearch”

持续丰富完善企业级服务能力

关于极限科技

顺利完成首个搜索型数据库产品能力测试

搜索型数据库在各行业的重要应用

INFINI Easysearch

关于极限科技

相关链接

INFINI Gateway v1.12.1

Bug fix

INFINI Console v1.0.0

Features

Improvements

Bug fix

期待反馈

关于极限科技（INFINI Labs）

活动推荐

热门话题

通知设置新通知