背景

我们公司最近计划将产品迁移到 Kubernetes 环境。 为了更好地管理和自动化我们的应用程序，我们决定使用 Kubernetes Operator。 本系列博客将记录我们学习和开发 Operator 的过程，希望能帮助更多的人入门 Operator 开发。

目标读者

• 对 Kubernetes 有一定了解的开发人员和运维人员
• 希望使用 Operator 自动化管理应用程序的人员
• 对 Go 语言有基本了解的人员

准备工作

在开始之前，你需要准备以下环境：

• Go 语言环境 (>= 1.23): Operator 通常使用 Go 语言开发，你需要安装 Go 语言环境。 建议使用 Go 1.21 或更高版本。 可以从 https://go.dev/dl/ 下载安装包。 安装完成后，请配置好 GOPATH 和 PATH 环境变量。

• Kubernetes 集群: 你需要一个可用的 Kubernetes 集群来部署和测试 Operator。 可以使用 Minikube、Kind 或其他的 Kubernetes 发行版。

• kubectl 命令行工具: kubectl 是 Kubernetes 的命令行工具，用于与 Kubernetes 集群交互。 请确保你已经安装并配置了 kubectl， 并且能够连接到你的 Kubernetes 集群。

• Kubebuilder (>= 3.0): Kubebuilder 是一个用于快速构建 Kubernetes Operator 的框架。 使用 Kubebuilder 可以简化 Operator 的开发流程，并生成一些必要的代码框架。 可以使用以下命令安装 Kubebuilder：

cd $HOME/go/bin
curl -L -o kubebuilder "https://go.kubebuilder.io/dl/latest/$(go env GOOS)/$(go env GOARCH)"
chmod +x kubebuilder

请确保 $HOME/go/bin 目录在你的 PATH 环境变量中。 可以运行 kubebuilder version 命令来验证 Kubebuilder 是否安装成功。

• Docker (可选): 如果你需要构建 Operator 的 Docker 镜像，你需要安装 Docker。

我的环境是 MacOS(arm64) + Orbstack

什么是 Operator？

简单来说，Operator 是 Kubernetes 的扩展，它利用自定义资源（Custom Resources, CRs）来自动化管理应用程序。Operator 允许我们像管理 Kubernetes 内置资源一样管理复杂的应用程序，例如数据库、消息队列等。

为什么选择 Operator？

Operator 提供了一种声明式的方式来管理应用程序的生命周期，包括部署、升级、备份、恢复等。它可以简化运维流程，提高自动化程度，并确保应用程序的状态符合预期。

我们的第一个 Operator：Hello World

这个 Operator 将监听一个名为 HelloWorld 的自定义资源，并在 Kubernetes 中创建一个 Pod，该 Pod 运行一个简单的 "Hello World" 应用程序。

1. 初始化 Kubebuilder 项目

首先，我们需要使用 Kubebuilder 创建一个新的项目。 在你的 GOPATH 目录下创建一个新的目录，例如 hello-world-operator，然后进入该目录，运行以下命令

kubebuilder init --domain infini.cloud --repo github.com/infinilabs/hello-world-operator

这个命令会创建一个新的 Kubebuilder 项目，并生成一些必要的文件和目录。

2. 创建自定义资源（Custom Resource Definition, CRD）

接下来，我们需要定义 HelloWorld 资源的结构。 运行以下命令

kubebuilder create api --group example --version v1alpha1 --kind HelloWorld

这个命令会创建一个新的 API 定义，包括 api/v1alpha1/helloworld_types.go 和 controllers/helloworld_controller.go 两个文件。

编辑 api/v1alpha1/helloworld_types.go 文件，修改 HelloWorldSpec 的定义，添加 name 和 message 字段：

// HelloWorldSpec defines the desired state of HelloWorld
type HelloWorldSpec struct {
    // INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
    // Important: Run "make" to regenerate code after modifying this file

    // Name is the name of the HelloWorld resource
    Name string `json:"name,omitempty"`

    // Message is the message to be printed by the pod
    Message string `json:"message,omitempty"`
}

3. 实现 Reconcile 逻辑

编辑 controllers/helloworld_controller.go 文件，实现 Reconcile 函数， 创建一个 Pod，该 Pod 运行一个 busybox 镜像，并输出 HelloWorld 资源中定义的 message。

package controllers

import (
    "context"
    "fmt"

    corev1 "k8s.io/api/core/v1"
    apierrors "k8s.io/apimachinery/pkg/api/errors"
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/apimachinery/pkg/runtime"
    ctrl "sigs.k8s.io/controller-runtime"
    "sigs.k8s.io/controller-runtime/pkg/client"
    "sigs.k8s.io/controller-runtime/pkg/log"

    examplev1alpha1 "github.com/infinilabs/hello-world-operator/api/v1alpha1"
)

// HelloWorldReconciler reconciles a HelloWorld object
type HelloWorldReconciler struct {
    client.Client
    Scheme *runtime.Scheme
}

//+kubebuilder:rbac:groups=example.com,resources=helloworlds,verbs=get;list;watch;create;update;patch;delete
//+kubebuilder:rbac:groups=example.com,resources=helloworlds/status,verbs=get;update;patch
//+kubebuilder:rbac:groups=example.com,resources=helloworlds/finalizers,verbs=update
//+kubebuilder:rbac:groups=core,resources=pods,verbs=get;list;watch;create;update;patch;delete

// Reconcile is part of the main kubernetes reconciliation loop which aims to
// move the current state of the cluster closer to the desired state.
// For more details, check Reconcile and its Result here:
// - https://pkg.go.dev/sigs.k8s.io/controller-runtime@v0.13.0/pkg/reconcile
func (r *HelloWorldReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    log := log.FromContext(ctx)

    // 1. Fetch the HelloWorld instance
    helloWorld := &examplev1alpha1.HelloWorld{}
    err := r.Get(ctx, req.NamespacedName, helloWorld)
    if err != nil {
        if apierrors.IsNotFound(err) {
            // Object not found, return.  Created objects are automatically garbage collected.
            // For additional cleanup logic use finalizers.
            log.Info("HelloWorld resource not found. Ignoring since object must be deleted")
            return ctrl.Result{}, nil
        }
        // Error reading the object - requeue the request.
        log.Error(err, "Failed to get HelloWorld")
        return ctrl.Result{}, err
    }

    // 2. Define the desired Pod
    pod := &corev1.Pod{
        ObjectMeta: metav1.ObjectMeta{
            Name:      helloWorld.Name + "-pod",
            Namespace: helloWorld.Namespace,
            Labels: map[string]string{
                "app": helloWorld.Name,
            },
        },
        Spec: corev1.PodSpec{
            Containers: []corev1.Container{
                {
                    Name:  "hello-world",
                    Image: "busybox",
                    Command: []string{"sh", "-c", fmt.Sprintf("echo '%s' && sleep 3600", helloWorld.Spec.Message)},
                },
            },
        },
    }

    // 3. Set HelloWorld instance as the owner and controller
    if err := ctrl.SetControllerReference(helloWorld, pod, r.Scheme); err != nil {
        log.Error(err, "Failed to set controller reference")
        return ctrl.Result{}, err
    }

    // 4. Check if the Pod already exists
    found := &corev1.Pod{}
    err = r.Get(ctx, client.ObjectKey{Name: pod.Name, Namespace: pod.Namespace}, found)
    if err != nil && apierrors.IsNotFound(err) {
        log.Info("Creating a new Pod", "Pod.Namespace", pod.Namespace, "Pod.Name", pod.Name)
        err = r.Create(ctx, pod)
        if err != nil {
            log.Error(err, "Failed to create new Pod", "Pod.Namespace", pod.Namespace, "Pod.Name", pod.Name)
            return ctrl.Result{}, err
        }
        // Pod created successfully - return and requeue
        return ctrl.Result{Requeue: true}, nil
    } else if err != nil {
        log.Error(err, "Failed to get Pod")
        return ctrl.Result{}, err
    }

    // 5. Pod already exists - don't requeue
    log.Info("Skip reconcile: Pod already exists", "Pod.Namespace", found.Namespace, "Pod.Name", found.Name)
    return ctrl.Result{}, nil
}

// SetupWithManager sets up the controller with the Manager.
func (r *HelloWorldReconciler) SetupWithManager(mgr ctrl.Manager) error {
    return ctrl.NewControllerManagedBy(mgr).
        For(&examplev1alpha1.HelloWorld{}).
        Owns(&corev1.Pod{}).
        Complete(r)
}

4. 安装 CRD 到 Kubernetes 集群

运行以下命令安装 CRD 到 Kubernetes 集群：

make install

5. 运行 Operator

运行以下命令在本地运行 Operator：

make run

6. 创建 HelloWorld 资源

创建一个名为 my-hello-world.yaml 的文件，内容如下：

apiVersion: example.com/v1alpha1
kind: HelloWorld
metadata:
  name: my-hello-world
spec:
  name: my-hello-world
  message: "Hello World from Operator!"

使用 kubectl apply -f my-hello-world.yaml 创建资源。

7. 验证

使用 kubectl get pods 命令查看是否创建了名为 my-hello-world-pod 的 Pod。 使用 kubectl logs my-hello-world-pod 查看 Pod 的日志，确认是否输出了 "Hello World from Operator!"。

总结

恭喜你完成了第一个 Operator！ 虽然这个 Operator 非常简单，但它展示了 Operator 的基本原理：监听自定义资源，并根据资源的状态来管理 Kubernetes 资源。 在接下来的系列中，我们将深入探讨 Operator 的更多高级特性。

敬请期待下一篇博客！

作者：罗厚付，极限科技（INFINI Labs）云上产品设计与研发负责人，拥有多年安全风控及大数据系统架构经验，主导过多个核心产品的设计与落地，日常负责运维超大规模 ES 集群（800+节点/1PB+数据）。
原文：https://infinilabs.cn/blog/2025/kubernetes-operator-develop-part-1/

作者：京东零售 崔健

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端销售订单系统复杂度对比：

4.方案

思路

优化前



优化后

4.1 降低查询数据量

4.1.1 前期调研

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



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

4.1.2 入库订单异构

执行流程





• “入库”订单数据打标

  • 增量订单在创建订单完成时写入；存量订单通过离线表推数

  • 需要订单创建模块先完成改造上线，再同步历史，保证数据不丢

  • 如果在【数据解析模块】处理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数据异构过程





• 首先，同步到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集群

• 根据登陆用户、数据延迟要求、查询数据范围，自动调度查询的数据集群，实现高性能的查询请求

查询调度



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

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

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

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

5.1 ES集群主/备机制

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



5.2 数据监控



6.灰度上线

• 第一步，优先上线数据模块，耗费较多时间的原因：1.整体数据量级以及历史数据复杂度的问题；2.数据同步链路比较长，中间环节多

• 第二步，预发环境验证，流量回放并没有做到长周期的完全自动化，根因：1.项目周期相对紧张；2.新老集群的数据还是有一些区别，回放脚本不够完善

• 第三步，用户功能灰度，主要是借助JDOS的负载均衡策略结合用户erp完成

• 第四部，对外接口灰度，通过控制新代码灰度容器个数，逐步放量



7.成果

平稳切换，无线上问题

8.待办

• 主动监控层面，新增按照天纬度进行数据比对、异常告警的能力，提高问题发现率

• 优化数据模型，对历史无用订单表进行精简，降低开发、运维成本，提升需求迭代效率

• 精简存储集群

  • 逐步下线其他非核心业务存储集群，减少外部依赖，提高系统容错度

  • 目前全量订单ES集群已经可以支持多场景的外部查询，未来考虑是否可以逐步下线入库订单JED

• 识别数据库隐患，基于慢日志监控，重新梳理引入模块，逐步优化，持续降低数据库负载

• MySQL减负，探索其他优化方案，减少数据量存储，提升数据灵活性。优先从业务层面出发，识别库里进行中的僵尸订单的根因，进行分类，强制结束

• 降级方案，当数据同步或者数据库存在异常时，可以做到秒级无感切换，提升业务可用率

9.写在最后

• 为什么没考虑Doris？因为ES是团队应用相对成熟的中间件，处于学习、开发成本考虑

• 未来入库的JED相关表是否可以下掉，用ES完全替代？目前看可以，当初设计冗余入库JED也是出于对于ES不确定性以及数据延迟的角度考虑，而且历史的一部分查询就落在了异构的全量实时订单JED上。现在，JED官方也不是很推荐非route key的查询。最后，现阶段因为降低了数据量和拆分了业务场景，入库JED的查询性能还是非常不错的

• 因为项目排期、个人能力的因素，在方案设计上会有考虑不周的场景，本期只是优化了最核心的业务、技术痛点，未来还有很大持续优化的空间。中间件的使用并不是可以优化数据库性能的银弹，最核心的还是要结合业务以及系统历史背景，在不断纠结当中寻找balance

INFINI Pizza 是 INFINI Labs 即将发布的一个基于 Rust 编写的搜索引擎（即将完全开源），目前已经完成基本的搜索能力，并且基于 INFINI Pizza 的核心引擎，提供了一个 WASM 版本的超轻量级内核，可以很方便的嵌入到各类应用系统，比如网站，尤其是静态站点或者小型的博客系统等。

目前 Pizza 和 INFINI Labs 官网已经集成了 INFINI Pizza for WebAssembly，具体的搜索效果如下图：

打开上面的网站（https://infinilabs.cn），通过按下快捷 s即可调出搜索框，然后就可以体验到 INFINI Pizza 提供的搜索能力。值得特别提出的是，在搜索的过程你所有的操作都是在浏览器本地执行，也就是不会像传统的搜索实现方式那样，需要每次输入一个查询条件都会和后端的搜索服务器进行一次交互，相比之下， INFINI Pizza for WebAssembly 则是完全离线操作，即使断网，也能愉快的搜索。

废话不多说，接下来为大家介绍一下如何在你自己的站点来使用 INFINI Pizza for WebAssembly。

首先，INFINI Pizza for WebAssembly 是开源的，Github 地址在这里：https://github.com/infinilabs/pizza-wasm 编译好的 WASM 包在这里可以直接下载：https://github.com/infinilabs/pizza-wasm/tree/main/pkg

➜  wasm git:(main) ✗ du -sh pkg/*
4.0K    pkg/README.md
4.0K    pkg/package.json
4.0K    pkg/pizza_wasm.d.ts
4.0K    pkg/pizza_wasm.js
 12K    pkg/pizza_wasm_bg.js
580K    pkg/pizza_wasm_bg.wasm
4.0K    pkg/pizza_wasm_bg.wasm.d.ts
256K    pkg/pizza_wasm_bg.wasm.gz

可以看到，WASM 的包只有 500 多 KB，通过 Gzip 压缩之后，只有 200 多 KB，比较轻量级。

Pizza-WASM 是 INFINI Pizza 核心引擎的 WebAssembly 接口封装，只对外暴露了几个简单的访问接口，对于目前的前端搜索应用足够了，在 https://github.com/infinilabs/pizza-wasm/tree/main/web 里面有一个非常简单的 WASM 方法调用的例子，可以简单进行了解。

当然，只是有 Pizza 的 WASM 还是不够的，我们如果要在现有的静态站点上添加搜索框的，还需要考虑数据怎么来，结果如何展现，所以针对这个场景，我们封装好了一个 Pizza-DocSearch 的一个项目，可以直接进一步简化使用，项目也是开源的，Github 地址是：https://github.com/infinilabs/pizza-docsearch

由于示例项目里面默认已经将编译好的代码和样例上传了，我们直接下载这个源代码并本地进行功能预览：

➜  /tmp git clone https://github.com/infinilabs/pizza-docsearch.git
Cloning into 'pizza-docsearch'...
remote: Enumerating objects: 174, done.
remote: Counting objects: 100% (174/174), done.
remote: Compressing objects: 100% (112/112), done.
remote: Total 174 (delta 86), reused 147 (delta 59), pack-reused 0 (from 0)
Receiving objects: 100% (174/174), 941.94 KiB | 1.20 MiB/s, done.
Resolving deltas: 100% (86/86), done.
➜  /tmp cd pizza-docsearch/example/dist
➜  dist git:(main) python3 -m http.server 8083

Serving HTTP on :: port 8083 (http://[::]:8083/) ...

打开浏览器，并访问：http://localhost:8083，如下：

观察浏览器的网络请求，可以看到会加载示例的 index.json 数据：

实际的情况，如果是我们自己的静态网站或者是博客，只有保证网站根目录有这个文件及相应的格式，即可快速将这个你看到的搜索功能集成到你自己的网站上去。OK，功能验证完毕了，我们开始集成到我们的站点吧。

Pizza/INFINI Labs 的官网，使用的 Hugo 来静态生成的，index.json 文件不需要手动生成，首先我们需要让 Hugo 生成 JSON 格式的内容，这个是 Hugo 自带的能力，我们需要修改 Hugo 项目的配置：

将 outputs 参数这里新增一个 JSON 的输出，然后我们在主题的模版里面再定义一下 JSON 输出的格式模版：

文本格式的内容如下，方便复制粘贴，保存文件名为 index.json：

{{- $index := slice -}}
{{- range where .Site.RegularPages.ByDate.Reverse "Type" "not in" (slice "page" "json") -}}
    {{- $index = $index | append (dict "title" (.Title | plainify) "url" .Permalink "tags" .Params.tags "category" .Params.category "subcategory" .Params.subcategory "summary" (.Params.Summary | markdownify | plainify) "content" (.Content | markdownify | plainify)) -}}
{{- end -}}
{{- $index | jsonify -}}

OK，接下来就是将站点内每篇文章或者博客的元数据里面加上我们上面已经用到了的标签：

OK， 启动 Hugo 站点：

                   | EN
-------------------+------
  Pages            | 181
  Paginator pages  |   5
  Non-page files   |   0
  Static files     | 110
  Processed images |   0
  Aliases          |  52
  Sitemaps         |   1
  Cleaned          |   0

Built in 323 ms
Watching for changes in /Users/medcl/Documents/rust/pizza/website/{assets,content.en,static,themes}
Watching for config changes in /Users/medcl/Documents/rust/pizza/website/config.yaml
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at //localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

打开 Hugo 的站点地址，并尝试访问 http://localhost:1313/index.json, 应该就可以访问到这个 JSON 文件了:

至此，数据准备完毕，接下来我们集成前端搜索控件。

还记得我们之前从 Pizza-docsearch 下载的资源文件么，我们主要用到 assets 里面的 3 个文件：

/tmp/pizza-docsearch/example/dist
➜  dist git:(main) tree
.
├── assets
  ├── index-C1z1vz3D.css
  ├── index-D_gOo737.js
  └── pizza_wasm_bg-BRCuviY_.wasm
├── index.html
└── index.json

1 directory, 5 files
➜  dist git:(main)

打开 index.html 文件，我们可以看到里面的内容如下：

拷贝这个 assets 目录文件到我们的 Hugo 站点，位置如下：

然后修改 Hugo 的主题模版，在所有页面的头模版 html-head.html里面增加一段代码来加载我们的 CSS 样式文件：

然后继续修改 Hugo 的主题模版文件，在所有页面的页脚模版，增加一段代码来加载 JS 脚本文件：

然后，在页面模版的适当位置，插入一下 Docsearch 的一段标签，用于放置搜索框，如图：

至此，大功告成！

打开浏览器即可看到最终效果：

最后，总结一下，借助 INFINI Pizza Docsearch 的 3 个小文件，只需 3 行代码，你可以在 5 分钟内为你的静态站点添加一个轻量级的离线搜索功能，快去试试吧。

相关链接：

• Pizza
• Pizza Wasm
• Pizza Docsearch

交流群

📢 对 Pizza，Rust，Wasm 搜索引擎感兴趣的朋友可以加这个群~👇,如果加不进群可微信添加小助手（INFINI-labs）拉您入群。

关于极限科技（INFINI Labs）

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

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

官网：https://infinilabs.cn

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

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

实现特性

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

对比 Elasticsearch

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

索引构建测试

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

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

查询性能测试

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

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

安装

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

源码安装

git clone https://github.com/RediSearch/RediSearch.git
cd RediSearch # 进入模块目录
make setup
make install

docker安装

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

判断是否安装成功

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 创建索引

创建索引不妨想象成创建表结构，表一般基本属性有表名、字段和字段类别等，所以我们可以考虑将索引名代表表名，字段代表字段，属性即表示属性。

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

type student
"none"

我们创建的索引redis是不认识的，这证明使用的是插件。

1.2 创建文档

创建文档上下文的过程不妨想想成向表中插入数据，这里请注意字段名可以使用双引号但切记一定要用英文，这里之所以着重提出是因为有些编译器中文双引号和英文双引号用肉眼实在难以辨认否则会出现 “Fields must be specified in FIELD VALUE pairs”（其实是将“ 当作内容处理了以至于缺少了字段）

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 全量查询

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 匹配查询

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 后置匹配

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 模糊搜索

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:
# <b>数据</b>?... <b>数据</b>进行写操作。由于完全实现了发布... <b>数据</b>冗余很有帮助。[8...

之所以会出现这样的效果是因为redisearch对文本进行了分词，其使用的工具是friso相比es的ik还是弱一些前者主要是对中文分词，体积小可移植性强。

从而我们可以结合后后置匹配算法

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

或者结合Levenshtein算法这样基本上能够满足业务查询需求

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

1.3.2.3 字段查询

通过字段查询也可以实现模糊搜索，直接给例子，后面跟着官网上给的sql 和 redisearch的对照表

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 删除文档

xxx.xxx.xxx.xxx:0>ft.del student 002
"1"

1.4.3 删除索引

xxx.xxx.xxx.xxx:0>ft.drop student
"OK"

1.5 查看

1.5.1 查看所有索引

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 获取单条数据

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 获取多条数据

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 添加别名

123.232.112.84:0>FT.ALIASADD xs student
"OK"

给索引student起个xs的别名，一个索引可以起多个别名

1.6.2 修改别名

1.6.3 删除别名

123.232.112.84:0>FT.ALIASDEL xs 
"OK"

作者：架构师公众号

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

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

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

测试结果

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

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

测试说明

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

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

Easysearch 是什么？

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

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

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/download/?product=easysearch

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

会上，极限科技创始人兼 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 隔离）的基础上，实现了更优性能的升级。

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

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

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

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

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

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

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

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

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

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

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

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

关于极限科技

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

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

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

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

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

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

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

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

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

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

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

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

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

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

INFINI Easysearch

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

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

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

关于极限科技

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

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

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

相关链接

• 国内首家 | 极限科技完成搜索型数据库产品评测

本次 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，用户名密码 readonly/readonly。

INFINI Gateway v1.12.1

极限网关本次更新如下：

Bug fix

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

更多 Gateway 更新可参考【Gateway 版本历史】。

INFINI Console v1.0.0

Console 本次主要更新如下：

1、集成 Github 单点登录，方便快速登录，减少用户名和密码登录经常忘记带来的烦恼。详情查看教程

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

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

4、新增了数据看板功能，支持多标签页，支持折线图、柱状图、饼图等图表，支持用户自定义可视化数据报表，详情查看教程

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

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

Features

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

Improvements

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

Bug fix

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

更多 Console 更新可参考【Console 版本历史】。

期待反馈

欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（https://github.com/infinilabs） 中的对应项目中提交 Feature Request 或提交 Bug。

• INFINI Gateway： https://github.com/infinilabs/gateway/issues
• INFINI Console： https://github.com/infinilabs/console/issues
• 官网： https://www.infinilabs.com
• 下载地址： https://www.infinilabs.com/download

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

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

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

最后祝大家周末愉快！

关于极限科技（INFINI Labs）

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

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

大会简介

大会亮点

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

大会主题

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

大会信息

日程安排

组织架构

展望未来

• 国际开源教育与人才培养论坛

• 机器学习中国峰会

• OpenSSF开源安全中国峰会

• Hyperledger区块链技术峰会

• CNCF云原生论坛