找到问题的解决办法了么?

如何防止 ES 服务 OOM?

ES 和传统关系型数据库有很多区别, 比如传统数据中普遍都有一个叫“最大连接数”的设置。目的是使数据库系统工作在可控的负载下,避免出现负载过高,资源耗尽,谁也无法登录的局面。

那 ES 在这方面有类似参数吗?答案是没有,这也是为何 ES 会被流量打爆的原因之一。

针对大并发访问 ES 服务,造成 ES 节点 OOM,服务中断的情况,极限科技旗下的 INFINI Gateway 产品(以下简称 “极限网关”)可从两个方面入手,保障 ES 服务的可用性。

  1. 限制最大并发访问连接数。
  2. 限制非重要索引的请求速度,保障重要业务索引的访问速度。

下面我们来详细聊聊。

架构图

所有访问 ES 的请求都发给网关,可部署多个网关。

限制最大连接数

在网关配置文件中,默认有最大并发连接数限制,默认最大 10000。

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 10000
    network:
      binding: $[[env.GW_BINDING]]
      # See `gateway.disable_reuse_port_by_default` for more information.
      reuse_port: true

使用压测程序测试,看看到达10000个连接后,能否限制新的连接。 超过的连接请求,被丢弃。更多信息参考官方文档

限制索引写入速度

我们先看看不做限制的时候,测试环境的写入速度,在 9w - 15w docs/s 之间波动。虽然峰值很高,但不稳定。 接下来,我们通过网关把写入速度控制在最大 1w docs/s 。 对网关的配置文件 gateway.yml ,做以下修改。

env: # env 下添加
    THROTTLE_BULK_INDEXING_MAX_BYTES: 40485760 #40MB/s
    THROTTLE_BULK_INDEXING_MAX_REQUESTS: 10000 #10k docs/s
    THROTTLE_BULK_INDEXING_ACTION: retry #retry,drop
    THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES: 10 #1000
    THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS: 100 #10

router: # route 部分修改 flow
  - name: my_router
    default_flow: default_flow
    tracing_flow: logging_flow
    rules:
      - method:
          - "*"
        pattern:
          - "/_bulk"
          - "/{any_index}/_bulk"
        flow:
          - write_flow

flow: #flow 部分增加下面两段    
  - name: write_flow
    filter:
      - flow:
          flows:
            - bulking_indexing_limit
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000
  - name: bulking_indexing_limit
    filter:
      - bulk_request_throttle:
          indices:
            "test-index":
              max_bytes: $[[env.THROTTLE_BULK_INDEXING_MAX_BYTES]]
              max_requests: $[[env.THROTTLE_BULK_INDEXING_MAX_REQUESTS]]
              action: $[[env.THROTTLE_BULK_INDEXING_ACTION]]
              retry_delay_in_ms: $[[env.THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS]]
              max_retry_times: $[[env.THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES]]
              message: "bulk writing too fast" #触发限流告警message自定义
              log_warn_message: true

再次压测,test-index 索引写入速度被限制在了 1w docs/s 。

限制多个索引写入速度

上面的配置是针对 test-index 索引的写入速度控制。如果想添加其他的索引,新增一段配置即可。 比如,我允许 abc 索引写入达到 2w docs/s,test-index 索引最多不超过 1w docs/s ,可配置如下。

  - name: bulking_indexing_limit
    filter:
      - bulk_request_throttle:
          indices:
            "abc":
              max_requests: 20000
              action: drop
              message: "abc doc写入超阈值" #触发限流告警message自定义
              log_warn_message: true
            "test-index":
              max_bytes: $[[env.THROTTLE_BULK_INDEXING_MAX_BYTES]]
              max_requests: $[[env.THROTTLE_BULK_INDEXING_MAX_REQUESTS]]
              action: $[[env.THROTTLE_BULK_INDEXING_ACTION]]
              retry_delay_in_ms: $[[env.THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS]]
              max_retry_times: $[[env.THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES]]
              message: "bulk writing too fast" #触发限流告警message自定义
              log_warn_message: true

限速效果如下

限制读请求速度

我们先看看不做限制的时候,测试环境的读取速度,7w qps 。 接下来我们通过网关把读取速度控制在最大 1w qps 。 继续对网关的配置文件 gateway.yml 做以下修改。

  - name: default_flow
    filter:
      - request_path_limiter:
          message: "Hey, You just reached our request limit!"                                      rules:      
            - pattern: "/(?P<index_name>abc)/_search"                          
              max_qps: 10000
              group: index_name                                    
      - elasticsearch: 
          elasticsearch: prod                            
          max_connection_per_node: 1000

再次进行测试,读取速度被限制在了 1w qps 。

限制多个索引读取速度

上面的配置是针对 abc 索引的写入速度控制。如果想添加其他的索引,新增一段配置即可。 比如,我允许 abc 索引读取达到 1w qps,test-index 索引最多不超过 2w qps ,可配置如下。

  - name: default_flow
    filter:
      - request_path_limiter:
          message: "Hey, You just reached our request limit!"
          rules:
            - pattern: "/(?P<index_name>abc)/_search"
              max_qps: 10000
              group: index_name
            - pattern: "/(?P<index_name>test-index)/_search"
              max_qps: 20000
              group: index_name
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000

多个网关限速

限速是每个网关自身的控制,如果有多个网关,那么后端 ES 集群收到的请求数等于多个网关限速的总和。 本次介绍就到这里了。相信大家在使用 ES 的过程中也遇到过各种各样的问题。欢迎大家来我们这个平台分享自己的问题、解决方案等。如有任何问题,请随时联系我,期待与您交流!

继续阅读 »

ES 和传统关系型数据库有很多区别, 比如传统数据中普遍都有一个叫“最大连接数”的设置。目的是使数据库系统工作在可控的负载下,避免出现负载过高,资源耗尽,谁也无法登录的局面。

那 ES 在这方面有类似参数吗?答案是没有,这也是为何 ES 会被流量打爆的原因之一。

针对大并发访问 ES 服务,造成 ES 节点 OOM,服务中断的情况,极限科技旗下的 INFINI Gateway 产品(以下简称 “极限网关”)可从两个方面入手,保障 ES 服务的可用性。

  1. 限制最大并发访问连接数。
  2. 限制非重要索引的请求速度,保障重要业务索引的访问速度。

下面我们来详细聊聊。

架构图

所有访问 ES 的请求都发给网关,可部署多个网关。

限制最大连接数

在网关配置文件中,默认有最大并发连接数限制,默认最大 10000。

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 10000
    network:
      binding: $[[env.GW_BINDING]]
      # See `gateway.disable_reuse_port_by_default` for more information.
      reuse_port: true

使用压测程序测试,看看到达10000个连接后,能否限制新的连接。 超过的连接请求,被丢弃。更多信息参考官方文档

限制索引写入速度

我们先看看不做限制的时候,测试环境的写入速度,在 9w - 15w docs/s 之间波动。虽然峰值很高,但不稳定。 接下来,我们通过网关把写入速度控制在最大 1w docs/s 。 对网关的配置文件 gateway.yml ,做以下修改。

env: # env 下添加
    THROTTLE_BULK_INDEXING_MAX_BYTES: 40485760 #40MB/s
    THROTTLE_BULK_INDEXING_MAX_REQUESTS: 10000 #10k docs/s
    THROTTLE_BULK_INDEXING_ACTION: retry #retry,drop
    THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES: 10 #1000
    THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS: 100 #10

router: # route 部分修改 flow
  - name: my_router
    default_flow: default_flow
    tracing_flow: logging_flow
    rules:
      - method:
          - "*"
        pattern:
          - "/_bulk"
          - "/{any_index}/_bulk"
        flow:
          - write_flow

flow: #flow 部分增加下面两段    
  - name: write_flow
    filter:
      - flow:
          flows:
            - bulking_indexing_limit
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000
  - name: bulking_indexing_limit
    filter:
      - bulk_request_throttle:
          indices:
            "test-index":
              max_bytes: $[[env.THROTTLE_BULK_INDEXING_MAX_BYTES]]
              max_requests: $[[env.THROTTLE_BULK_INDEXING_MAX_REQUESTS]]
              action: $[[env.THROTTLE_BULK_INDEXING_ACTION]]
              retry_delay_in_ms: $[[env.THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS]]
              max_retry_times: $[[env.THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES]]
              message: "bulk writing too fast" #触发限流告警message自定义
              log_warn_message: true

再次压测,test-index 索引写入速度被限制在了 1w docs/s 。

限制多个索引写入速度

上面的配置是针对 test-index 索引的写入速度控制。如果想添加其他的索引,新增一段配置即可。 比如,我允许 abc 索引写入达到 2w docs/s,test-index 索引最多不超过 1w docs/s ,可配置如下。

  - name: bulking_indexing_limit
    filter:
      - bulk_request_throttle:
          indices:
            "abc":
              max_requests: 20000
              action: drop
              message: "abc doc写入超阈值" #触发限流告警message自定义
              log_warn_message: true
            "test-index":
              max_bytes: $[[env.THROTTLE_BULK_INDEXING_MAX_BYTES]]
              max_requests: $[[env.THROTTLE_BULK_INDEXING_MAX_REQUESTS]]
              action: $[[env.THROTTLE_BULK_INDEXING_ACTION]]
              retry_delay_in_ms: $[[env.THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS]]
              max_retry_times: $[[env.THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES]]
              message: "bulk writing too fast" #触发限流告警message自定义
              log_warn_message: true

限速效果如下

限制读请求速度

我们先看看不做限制的时候,测试环境的读取速度,7w qps 。 接下来我们通过网关把读取速度控制在最大 1w qps 。 继续对网关的配置文件 gateway.yml 做以下修改。

  - name: default_flow
    filter:
      - request_path_limiter:
          message: "Hey, You just reached our request limit!"                                      rules:      
            - pattern: "/(?P<index_name>abc)/_search"                          
              max_qps: 10000
              group: index_name                                    
      - elasticsearch: 
          elasticsearch: prod                            
          max_connection_per_node: 1000

再次进行测试,读取速度被限制在了 1w qps 。

限制多个索引读取速度

上面的配置是针对 abc 索引的写入速度控制。如果想添加其他的索引,新增一段配置即可。 比如,我允许 abc 索引读取达到 1w qps,test-index 索引最多不超过 2w qps ,可配置如下。

  - name: default_flow
    filter:
      - request_path_limiter:
          message: "Hey, You just reached our request limit!"
          rules:
            - pattern: "/(?P<index_name>abc)/_search"
              max_qps: 10000
              group: index_name
            - pattern: "/(?P<index_name>test-index)/_search"
              max_qps: 20000
              group: index_name
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000

多个网关限速

限速是每个网关自身的控制,如果有多个网关,那么后端 ES 集群收到的请求数等于多个网关限速的总和。 本次介绍就到这里了。相信大家在使用 ES 的过程中也遇到过各种各样的问题。欢迎大家来我们这个平台分享自己的问题、解决方案等。如有任何问题,请随时联系我,期待与您交流!

收起阅读 »

用 Easysearch 帮助大型车企降本增效

最近某头部汽车集团需要针对当前 ES 集群进行优化,背景如下: ES 用于支撑包括核心营销系统、管理支持系统、财务类、IT 基础设施类、研发、自动驾驶等多个重要应用,合计超 50 余套集群,累计数据超 1.5PB 。 本文针对其中一个 ES 集群进行分享,该集群原本使用的是 ES 7.3.2 免费版,数据已经 130TB 了,14 个节点。写入数据时经常掉节点,写入性能也不稳定,当天的数据写不完。迫切需要新的解决方案。 分析业务场景后总结需求要点:主要是写,很少查。审计需求,数据需要长期保存。 这个需求比较普遍,处理起来也很简单:

  • 使用 Easysearch 软件,只需少量节点存储近两天的数据。
  • 索引设置开启 ZSTD 压缩功能,节省磁盘空间。
  • 每天索引数据写完后,第二天执行快照备份存放到 S3 存储。
  • 备份成功后,删除索引释放磁盘空间。
  • 需要搜索数据时,直接从快照搜索。

将近期的数据,存放到本地磁盘,保障写入速度。写入完毕的索引,在执行快照备份后,可删除索引,释放本地磁盘空间。

Easysearch 配置要点

path.repo: ["/S3-path"]
node.roles: ["data","search"]
node.search.cache.size: 500mb
  • path.repo : 指定 S3 存储路径,上传快照用。
  • node.roles : 只有 search 角色的节点,才能去搜索快照中的数据。
  • node.search.cache.size : 执行快照搜索时的,缓存大小。

更多信息请参考官方文档

旧数据迁移

通过 Console 将原 ES 集群的数据,迁移到新 Easysearch 集群。迁移时,复制 mapping 和 setting,并在 setting 中添加如下设置。

"codec": "ZSTD",
"source_reuse": true,

原索引数据量大,可拆分成多个小任务。 迁移完,索引存储空间一般节省 50% 左右。 原索引 279GB ,迁移完后 138GB。

搜索快照数据

挂载快照后,搜索快照里的索引和搜索本地的索引,语法完全一样。 如何判断一个索引是在快照还是本地磁盘呢?可以查看索引设置里的 settings.index.store.type 如果是 remote_snapshot ,说明是快照中的数据。如果是空值,则是集群本地的数据。
这次迁移,节省了 6 台主机资源。更重要的是,用上对象存储后,主机磁盘空间压力骤减。
这次介绍就到这里了,有问题联系我。

关于 Easysearch

Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://infinilabs.com/docs/latest/easysearch

继续阅读 »

最近某头部汽车集团需要针对当前 ES 集群进行优化,背景如下: ES 用于支撑包括核心营销系统、管理支持系统、财务类、IT 基础设施类、研发、自动驾驶等多个重要应用,合计超 50 余套集群,累计数据超 1.5PB 。 本文针对其中一个 ES 集群进行分享,该集群原本使用的是 ES 7.3.2 免费版,数据已经 130TB 了,14 个节点。写入数据时经常掉节点,写入性能也不稳定,当天的数据写不完。迫切需要新的解决方案。 分析业务场景后总结需求要点:主要是写,很少查。审计需求,数据需要长期保存。 这个需求比较普遍,处理起来也很简单:

  • 使用 Easysearch 软件,只需少量节点存储近两天的数据。
  • 索引设置开启 ZSTD 压缩功能,节省磁盘空间。
  • 每天索引数据写完后,第二天执行快照备份存放到 S3 存储。
  • 备份成功后,删除索引释放磁盘空间。
  • 需要搜索数据时,直接从快照搜索。

将近期的数据,存放到本地磁盘,保障写入速度。写入完毕的索引,在执行快照备份后,可删除索引,释放本地磁盘空间。

Easysearch 配置要点

path.repo: ["/S3-path"]
node.roles: ["data","search"]
node.search.cache.size: 500mb
  • path.repo : 指定 S3 存储路径,上传快照用。
  • node.roles : 只有 search 角色的节点,才能去搜索快照中的数据。
  • node.search.cache.size : 执行快照搜索时的,缓存大小。

更多信息请参考官方文档

旧数据迁移

通过 Console 将原 ES 集群的数据,迁移到新 Easysearch 集群。迁移时,复制 mapping 和 setting,并在 setting 中添加如下设置。

"codec": "ZSTD",
"source_reuse": true,

原索引数据量大,可拆分成多个小任务。 迁移完,索引存储空间一般节省 50% 左右。 原索引 279GB ,迁移完后 138GB。

搜索快照数据

挂载快照后,搜索快照里的索引和搜索本地的索引,语法完全一样。 如何判断一个索引是在快照还是本地磁盘呢?可以查看索引设置里的 settings.index.store.type 如果是 remote_snapshot ,说明是快照中的数据。如果是空值,则是集群本地的数据。
这次迁移,节省了 6 台主机资源。更重要的是,用上对象存储后,主机磁盘空间压力骤减。
这次介绍就到这里了,有问题联系我。

关于 Easysearch

Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://infinilabs.com/docs/latest/easysearch

收起阅读 »

Easysearch:语义搜索、知识图和向量数据库概述

什么是语义搜索?

语义搜索是一种使用自然语言处理算法来理解单词和短语的含义和上下文以提供更准确的搜索结果的搜索技术。旨在更好地理解用户的意图和查询内容,而不仅仅是根据关键词匹配,还通过分析查询的语义和上下文来提供更准确和相关的搜索结果。

传统的关键词搜索主要依赖于对关键词的匹配,而忽略了查询的含义和语境。但语义搜索的优点在于它可以更好地满足用户的意图,尤其是对于复杂的查询和问题。它能够理解查询的上下文,处理模糊或不完整的查询,并提供更相关和有用的搜索结果。例如,当用户搜索"最近的餐厅"时,语义搜索可以根据用户的位置信息和上下文,提供附近的餐厅列表,而不仅仅是简单地匹配关键词"最近"和"餐厅"。

语义搜索的历史

语义搜索的概念可以追溯到计算机科学的早期,在 20 世纪 50 年代和 1960 年代就有人尝试开发自然语言处理系统。然而,直到 20 世纪 90 年代和 2000 年代,语义搜索领域才取得了重大进展,这在一定程度上要归功于机器学习和人工智能的进步。

语义搜索最早的例子之一是 Douglas Lenat 在 1984 年创建的 Cyc 项目。该项目旨在建立一个全面的常识知识本体或知识库,可用于理解自然语言查询。虽然 Cyc 项目面临诸多挑战,最终没有实现其目标,但它为未来语义搜索的研究奠定了基础。

20 世纪 90 年代末,Ask Jeeves(现称为 Ask.com)等搜索引擎开始尝试自然语言查询和语义搜索技术。这些早期的努力受到当时技术的限制,但它们展示了更复杂的搜索算法的潜力。

2000 年代初 Web 本体语言 (OWL) 的发展提供了一种以机器可读格式表示知识和关系的标准化方法,使得开发语义搜索算法变得更加容易。2008 年被微软收购的 Powerset 和 2007 年推出的 Hakia 等公司开始使用语义搜索技术来提供更相关的搜索结果。

如今,许多搜索引擎和公司正在使用语义搜索来提高搜索结果的准确性和相关性。其中包括于 2012 年推出知识图谱的谷歌,以及使用语义搜索为其 Alexa 虚拟助手提供支持的亚马逊。随着人工智能领域的不断发展,语义搜索可能会变得更加复杂且适用于广泛的应用。

语义搜索的最新改进

语义搜索的最新改进有助于进一步推动该领域的发展。一些最值得注意的包括:

基于 Transformer 的模型:基于 Transformer 的模型,例如 BERT(来自 Transformers 的双向编码器表示),彻底改变了自然语言处理和语义搜索。这些模型能够更好地理解单词和短语的上下文,从而更容易提供更相关的搜索结果。

多模态搜索:多模态搜索是指跨文本、图像、视频等多种模式搜索信息的能力。机器学习的最新进展使得开发更准确、更复杂的多模态搜索算法成为可能。

对话式搜索:对话式搜索涉及使用自然语言处理和机器学习来为用户查询提供更准确、更人性化的响应。这项技术已经被用于虚拟助手,例如亚马逊的 Alexa 和苹果的 Siri。

个性化:个性化是指根据用户的偏好和之前的搜索历史来定制搜索结果的能力。随着在线可用数据量的不断增长,这一点变得越来越重要。

特定领域搜索:特定领域搜索涉及使用语义搜索技术在特定领域或行业(例如医疗保健或金融)内进行搜索。这有助于为这些行业的用户提供更准确、更相关的搜索结果。

总体而言,语义搜索的最新进展使得在线查找信息变得更加容易,并为未来更复杂的搜索算法铺平了道路。

语义搜索和知识图谱有什么关系?

语义搜索和知识图(knowledge graph)密切相关,因为两者都涉及使用语义技术来改进搜索结果。

知识图是一种用于组织和表示知识的图形结构,通过节点和边的连接展示实体和关系之间的语义关联性。例如,知识图可能包含有关特定公司的信息,包括其位置、产品和员工以及这些实体之间的关系。

另一方面,语义搜索是一种使用自然语言处理和机器学习来更好地理解搜索查询中单词和短语的含义的搜索技术。语义搜索算法使用知识图和其他语义技术来分析实体和概念之间的关系,并基于此分析提供更相关的搜索结果。

换句话说,知识图谱为语义搜索提供了丰富的知识背景,帮助理解查询意图和提供准确的搜索结果。同时,语义搜索可以帮助构建和扩展知识图谱,提高搜索的准确性和语义理解能力。

例如,谷歌的知识图使用庞大的结构化数据数据库来支持其搜索结果,并提供有关搜索结果中出现的实体(例如人物、地点和事物)的附加信息。这使得用户更容易找到他们正在寻找的信息并探索相关的概念和实体。

向量数据库、知识图谱和语义搜索

向量数据库是另一种可以与语义搜索和知识图相结合使用以改进搜索结果的技术。它主要用于处理和分析具有向量特征的数据,如图像、音频、文本、时间序列等。

传统的关系型数据库主要用于存储结构化的数据,而向量数据库则专注于存储和处理高维向量。它的设计目标是能够高效地进行向量相似性搜索和聚类等操作,以支持复杂的数据分析和机器学习任务。向量数据库使用机器学习算法将数据表示为向量,向量是数据的数学表示,可用于各种计算任务,例如,向量可用于表示人、地点和事物等实体以及它们之间的关系。通过比较这些向量,搜索算法可以识别数据本身可能无法立即显现的关系和模式。

在语义搜索和知识图的背景下,向量数据库可以通过更好地理解实体和概念之间的关系来提高搜索结果的准确性。

例如,当用户搜索“ London ”时,语义搜索算法可以使用知识图和向量数据库来了解用户可能指的是英国伦敦市,而不是其他同名实体。

通过使用向量数据库来表示和比较实体和概念,搜索算法可以提供更相关和更准确的搜索结果。

总体而言,向量数据库、语义搜索和知识图谱都是共同提高搜索算法的准确性和效率的技术。通过利用这些技术,搜索引擎和其他应用程序可以更好地理解实体和概念之间的关系,从而更轻松地找到用户正在寻找的信息。

关于 Easysearch

Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://infinilabs.com/docs/latest/easysearch

参考资料

继续阅读 »

什么是语义搜索?

语义搜索是一种使用自然语言处理算法来理解单词和短语的含义和上下文以提供更准确的搜索结果的搜索技术。旨在更好地理解用户的意图和查询内容,而不仅仅是根据关键词匹配,还通过分析查询的语义和上下文来提供更准确和相关的搜索结果。

传统的关键词搜索主要依赖于对关键词的匹配,而忽略了查询的含义和语境。但语义搜索的优点在于它可以更好地满足用户的意图,尤其是对于复杂的查询和问题。它能够理解查询的上下文,处理模糊或不完整的查询,并提供更相关和有用的搜索结果。例如,当用户搜索"最近的餐厅"时,语义搜索可以根据用户的位置信息和上下文,提供附近的餐厅列表,而不仅仅是简单地匹配关键词"最近"和"餐厅"。

语义搜索的历史

语义搜索的概念可以追溯到计算机科学的早期,在 20 世纪 50 年代和 1960 年代就有人尝试开发自然语言处理系统。然而,直到 20 世纪 90 年代和 2000 年代,语义搜索领域才取得了重大进展,这在一定程度上要归功于机器学习和人工智能的进步。

语义搜索最早的例子之一是 Douglas Lenat 在 1984 年创建的 Cyc 项目。该项目旨在建立一个全面的常识知识本体或知识库,可用于理解自然语言查询。虽然 Cyc 项目面临诸多挑战,最终没有实现其目标,但它为未来语义搜索的研究奠定了基础。

20 世纪 90 年代末,Ask Jeeves(现称为 Ask.com)等搜索引擎开始尝试自然语言查询和语义搜索技术。这些早期的努力受到当时技术的限制,但它们展示了更复杂的搜索算法的潜力。

2000 年代初 Web 本体语言 (OWL) 的发展提供了一种以机器可读格式表示知识和关系的标准化方法,使得开发语义搜索算法变得更加容易。2008 年被微软收购的 Powerset 和 2007 年推出的 Hakia 等公司开始使用语义搜索技术来提供更相关的搜索结果。

如今,许多搜索引擎和公司正在使用语义搜索来提高搜索结果的准确性和相关性。其中包括于 2012 年推出知识图谱的谷歌,以及使用语义搜索为其 Alexa 虚拟助手提供支持的亚马逊。随着人工智能领域的不断发展,语义搜索可能会变得更加复杂且适用于广泛的应用。

语义搜索的最新改进

语义搜索的最新改进有助于进一步推动该领域的发展。一些最值得注意的包括:

基于 Transformer 的模型:基于 Transformer 的模型,例如 BERT(来自 Transformers 的双向编码器表示),彻底改变了自然语言处理和语义搜索。这些模型能够更好地理解单词和短语的上下文,从而更容易提供更相关的搜索结果。

多模态搜索:多模态搜索是指跨文本、图像、视频等多种模式搜索信息的能力。机器学习的最新进展使得开发更准确、更复杂的多模态搜索算法成为可能。

对话式搜索:对话式搜索涉及使用自然语言处理和机器学习来为用户查询提供更准确、更人性化的响应。这项技术已经被用于虚拟助手,例如亚马逊的 Alexa 和苹果的 Siri。

个性化:个性化是指根据用户的偏好和之前的搜索历史来定制搜索结果的能力。随着在线可用数据量的不断增长,这一点变得越来越重要。

特定领域搜索:特定领域搜索涉及使用语义搜索技术在特定领域或行业(例如医疗保健或金融)内进行搜索。这有助于为这些行业的用户提供更准确、更相关的搜索结果。

总体而言,语义搜索的最新进展使得在线查找信息变得更加容易,并为未来更复杂的搜索算法铺平了道路。

语义搜索和知识图谱有什么关系?

语义搜索和知识图(knowledge graph)密切相关,因为两者都涉及使用语义技术来改进搜索结果。

知识图是一种用于组织和表示知识的图形结构,通过节点和边的连接展示实体和关系之间的语义关联性。例如,知识图可能包含有关特定公司的信息,包括其位置、产品和员工以及这些实体之间的关系。

另一方面,语义搜索是一种使用自然语言处理和机器学习来更好地理解搜索查询中单词和短语的含义的搜索技术。语义搜索算法使用知识图和其他语义技术来分析实体和概念之间的关系,并基于此分析提供更相关的搜索结果。

换句话说,知识图谱为语义搜索提供了丰富的知识背景,帮助理解查询意图和提供准确的搜索结果。同时,语义搜索可以帮助构建和扩展知识图谱,提高搜索的准确性和语义理解能力。

例如,谷歌的知识图使用庞大的结构化数据数据库来支持其搜索结果,并提供有关搜索结果中出现的实体(例如人物、地点和事物)的附加信息。这使得用户更容易找到他们正在寻找的信息并探索相关的概念和实体。

向量数据库、知识图谱和语义搜索

向量数据库是另一种可以与语义搜索和知识图相结合使用以改进搜索结果的技术。它主要用于处理和分析具有向量特征的数据,如图像、音频、文本、时间序列等。

传统的关系型数据库主要用于存储结构化的数据,而向量数据库则专注于存储和处理高维向量。它的设计目标是能够高效地进行向量相似性搜索和聚类等操作,以支持复杂的数据分析和机器学习任务。向量数据库使用机器学习算法将数据表示为向量,向量是数据的数学表示,可用于各种计算任务,例如,向量可用于表示人、地点和事物等实体以及它们之间的关系。通过比较这些向量,搜索算法可以识别数据本身可能无法立即显现的关系和模式。

在语义搜索和知识图的背景下,向量数据库可以通过更好地理解实体和概念之间的关系来提高搜索结果的准确性。

例如,当用户搜索“ London ”时,语义搜索算法可以使用知识图和向量数据库来了解用户可能指的是英国伦敦市,而不是其他同名实体。

通过使用向量数据库来表示和比较实体和概念,搜索算法可以提供更相关和更准确的搜索结果。

总体而言,向量数据库、语义搜索和知识图谱都是共同提高搜索算法的准确性和效率的技术。通过利用这些技术,搜索引擎和其他应用程序可以更好地理解实体和概念之间的关系,从而更轻松地找到用户正在寻找的信息。

关于 Easysearch

Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://infinilabs.com/docs/latest/easysearch

参考资料

收起阅读 »

【INFINI 动手实战训练营-北京站】海量数据不再头疼,使用 Easysearch 来实现降本增效,硬件直接减半

Workshop.png

您是否遇到过以下问题?

  • 当前部分原始日志压缩归档存放到 HDFS,但不能直接灵活查询;
  • 使用 Elasticsearch 存储日志,开销较大,硬件资源投入较高;
  • 当前日志集群不断增长,存储接近 PB 量级,且还在不断接入新的数据;
  • 希望降低日志保留成本,同时满足按需查询的需求,平衡性能和成本;
  • 集群规模大,分片过多,管理存在挑战,希望降低维护成本等。

针对使用 Elasticsearch 来作为日志存储的以上痛点,INFINI Labs 推出的 Easysearch 提供了若干存储优化的解决方案:

  • 优化措施一:集成高效压缩算法 Easysearch 采用业界最先进的 Zstd 压缩算法,高压缩率,低 CPU 消耗,针对 Doc Values、Store 字段进行高度无缝压缩,不影响正常的使用体验,可以降低 50% 的存储开销。
  • 优化措施二:无缝去除 Source 字段 Easysearch 利用 DocValues 和 BKD Tree 来重建 Source,合并冗余存储,不影响日志的正常检索和查看,可以大幅降低存储需求,在一些指标场景,甚至可以降低 80% 的存储开销。
  • 优化措施三:归档数据直接检索 您是否还在通过关闭索引来降低海量数据带来的集群压力,或者您是否已经将快照备份直接放到 S3 或者 HDFS 中了,现在通过 Easysearch 提供的归档数据的直接检索能力,可以进一步释放本地节点的磁盘空间,进而释放物理机器资源,并根据需要按需查询归档索引,而不需要恢复归档再查询,简单方便。

通过以上优化举措,我们可以用不到一半的机器即可承载原有的数据,并且结合 Easysearch 内置其它的内核优化,索引和查询性能也将大幅提升,同时集群更加稳定可靠。

快来与 INFINI Labs 的技术专家面对面,第一时间了解极限实验室的发布最新产品和功能特性,通过动手实战,快速掌握最前沿的搜索技术,并用于实际项目中。活动免费,欢迎报名参加。

活动时间:2024 年 1 月 18 日 13:30~17:30
活动地点:北京市海淀区 Wework 辉煌时代大厦 3 楼 3E 会议室

分享议题

  • Easysearch 总体介绍及搭建实战
  • Easysearch 存储优化原理与实践
  • Elasticsearch -> Easysearch 在线迁移实操
  • Console、Gateway、Loadgen 及 INFINI Labs 其他工具介绍与使用

参会提示

  • 请务必自备电脑(Windows 系统环境请提前安装好 Linux 虚拟机)
  • 请提前在 INFINI Labs 官网下载对应平台最新安装包(INFINI Easysearch、INFINI Gateway、INFINI Console)
  • 下载地址:https://www.infinilabs.com/download
  • 如有任何疑问可添加 INFINI Labs 小助手(微信号: INFINI-Labs)进行联系

微信号: INFINI-Labs

活动报名

名额有限,对 Easysearch 搜索引擎感兴趣的朋友们速度报名(扫描海报中二维码或点击此处 链接 即可免费报名)。

20231214-095304-qrcode.jpg

继续阅读 »

Workshop.png

您是否遇到过以下问题?

  • 当前部分原始日志压缩归档存放到 HDFS,但不能直接灵活查询;
  • 使用 Elasticsearch 存储日志,开销较大,硬件资源投入较高;
  • 当前日志集群不断增长,存储接近 PB 量级,且还在不断接入新的数据;
  • 希望降低日志保留成本,同时满足按需查询的需求,平衡性能和成本;
  • 集群规模大,分片过多,管理存在挑战,希望降低维护成本等。

针对使用 Elasticsearch 来作为日志存储的以上痛点,INFINI Labs 推出的 Easysearch 提供了若干存储优化的解决方案:

  • 优化措施一:集成高效压缩算法 Easysearch 采用业界最先进的 Zstd 压缩算法,高压缩率,低 CPU 消耗,针对 Doc Values、Store 字段进行高度无缝压缩,不影响正常的使用体验,可以降低 50% 的存储开销。
  • 优化措施二:无缝去除 Source 字段 Easysearch 利用 DocValues 和 BKD Tree 来重建 Source,合并冗余存储,不影响日志的正常检索和查看,可以大幅降低存储需求,在一些指标场景,甚至可以降低 80% 的存储开销。
  • 优化措施三:归档数据直接检索 您是否还在通过关闭索引来降低海量数据带来的集群压力,或者您是否已经将快照备份直接放到 S3 或者 HDFS 中了,现在通过 Easysearch 提供的归档数据的直接检索能力,可以进一步释放本地节点的磁盘空间,进而释放物理机器资源,并根据需要按需查询归档索引,而不需要恢复归档再查询,简单方便。

通过以上优化举措,我们可以用不到一半的机器即可承载原有的数据,并且结合 Easysearch 内置其它的内核优化,索引和查询性能也将大幅提升,同时集群更加稳定可靠。

快来与 INFINI Labs 的技术专家面对面,第一时间了解极限实验室的发布最新产品和功能特性,通过动手实战,快速掌握最前沿的搜索技术,并用于实际项目中。活动免费,欢迎报名参加。

活动时间:2024 年 1 月 18 日 13:30~17:30
活动地点:北京市海淀区 Wework 辉煌时代大厦 3 楼 3E 会议室

分享议题

  • Easysearch 总体介绍及搭建实战
  • Easysearch 存储优化原理与实践
  • Elasticsearch -> Easysearch 在线迁移实操
  • Console、Gateway、Loadgen 及 INFINI Labs 其他工具介绍与使用

参会提示

  • 请务必自备电脑(Windows 系统环境请提前安装好 Linux 虚拟机)
  • 请提前在 INFINI Labs 官网下载对应平台最新安装包(INFINI Easysearch、INFINI Gateway、INFINI Console)
  • 下载地址:https://www.infinilabs.com/download
  • 如有任何疑问可添加 INFINI Labs 小助手(微信号: INFINI-Labs)进行联系

微信号: INFINI-Labs

活动报名

名额有限,对 Easysearch 搜索引擎感兴趣的朋友们速度报名(扫描海报中二维码或点击此处 链接 即可免费报名)。

20231214-095304-qrcode.jpg

收起阅读 »

开启安全功能 ES 集群就安全了吗?

背景

经常跟 ES 打交道的朋友都知道,现在主流的 ES 集群安全方案是:RBAC + TLS for Internal + HTTPS 。

作为终端用户一般只需要关心用户名和密码就行了。作为管理和运维 ES 的人员来说,可能希望 ES 能提供密码策略来强制密码强度和密码使用周期。遗憾的是 ES 对密码强度和密码使用周期没有任何强制要求。如果不注意,可能我们天天都在使用“弱密码”或从不修改的密码(直到无法登录)。而且 ES 对连续的认证失败,不会做任何处理,这让 ES 很容易遭受暴力破解的入侵。

那还有没有别的办法,进一步提高安全呢? 其实,网关可以来帮忙。

虽然网关无法强制提高密码复杂度,但可以提高 ES 集群被暴力破解的难度。

大家都知道,暴力破解--本质就是不停的“猜”你的密码。以现在的 CPU 算力,一秒钟“猜”个几千上万次不过是洒洒水,而且 CPU 监控都不带波动的,很难发现异常。从这里入手,一方面,网关可以延长认证失败的过程--延迟返回结果,让破解不再暴力。另一方面,网关可以记录认证失败的情况,做到实时监控,有条件的告警。一旦出现苗头,可以使用网关阻断该 IP 或用户发来的任何请求。

场景模拟

首先,用网关代理 ES 集群,并在 default_flow 中增加一段 response_status_filter 过滤器配置,对返回码是 401 的请求,跳转到 rate_limit_flow 进行降速,延迟 5 秒返回。

  - name: default_flow
    filter:
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000
      - response_status_filter:
          exclude:
            - 401
          action: redirect_flow
          flow: rate_limit_flow
  - name: rate_limit_flow
    filter:
      - sleep:
          sleep_in_million_seconds: 5000

其次,对于失败的认证,我们可以通过 Console 来做个看板实时分析,展示。

折线图、饼图图、柱状图等,多种展示方式,大家可充分发挥。

最后,可在 Console 的告警中心,配置对应的告警规则,实时监控该类事件,方便及时跟进处置。

效果测试

先带上正确的用户名密码测试,看看返回速度。

0.011 秒返回。再使用错误的密码测试。

整整 5 秒多后,才回返结果。如果要暴力破解,每 5 秒钟甚至更久才尝试一个密码,这还叫暴力吗?

看板示例

此处仅仅是抛砖引玉,欢迎大家发挥想象。

告警示例

建立告警规则,用户 1 分钟内超过 3 次登录失败,就产生告警。

可在告警中心查看详情,也可将告警推送至微信、钉钉、飞书、邮件等。

查看告警详情,是 es 用户触发了告警。

最后,剩下的工作就是对该账号的处置了。如果有需要可以考虑阻止该用户或 IP 的请求,对应的过滤器文档在这里,老规矩加到 default_flow 里就行了。

如果小伙伴有其他办法提升 ES 集群安全,欢迎和我们一起讨论、交流。我们的宗旨是:让搜索更简单!

继续阅读 »

背景

经常跟 ES 打交道的朋友都知道,现在主流的 ES 集群安全方案是:RBAC + TLS for Internal + HTTPS 。

作为终端用户一般只需要关心用户名和密码就行了。作为管理和运维 ES 的人员来说,可能希望 ES 能提供密码策略来强制密码强度和密码使用周期。遗憾的是 ES 对密码强度和密码使用周期没有任何强制要求。如果不注意,可能我们天天都在使用“弱密码”或从不修改的密码(直到无法登录)。而且 ES 对连续的认证失败,不会做任何处理,这让 ES 很容易遭受暴力破解的入侵。

那还有没有别的办法,进一步提高安全呢? 其实,网关可以来帮忙。

虽然网关无法强制提高密码复杂度,但可以提高 ES 集群被暴力破解的难度。

大家都知道,暴力破解--本质就是不停的“猜”你的密码。以现在的 CPU 算力,一秒钟“猜”个几千上万次不过是洒洒水,而且 CPU 监控都不带波动的,很难发现异常。从这里入手,一方面,网关可以延长认证失败的过程--延迟返回结果,让破解不再暴力。另一方面,网关可以记录认证失败的情况,做到实时监控,有条件的告警。一旦出现苗头,可以使用网关阻断该 IP 或用户发来的任何请求。

场景模拟

首先,用网关代理 ES 集群,并在 default_flow 中增加一段 response_status_filter 过滤器配置,对返回码是 401 的请求,跳转到 rate_limit_flow 进行降速,延迟 5 秒返回。

  - name: default_flow
    filter:
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000
      - response_status_filter:
          exclude:
            - 401
          action: redirect_flow
          flow: rate_limit_flow
  - name: rate_limit_flow
    filter:
      - sleep:
          sleep_in_million_seconds: 5000

其次,对于失败的认证,我们可以通过 Console 来做个看板实时分析,展示。

折线图、饼图图、柱状图等,多种展示方式,大家可充分发挥。

最后,可在 Console 的告警中心,配置对应的告警规则,实时监控该类事件,方便及时跟进处置。

效果测试

先带上正确的用户名密码测试,看看返回速度。

0.011 秒返回。再使用错误的密码测试。

整整 5 秒多后,才回返结果。如果要暴力破解,每 5 秒钟甚至更久才尝试一个密码,这还叫暴力吗?

看板示例

此处仅仅是抛砖引玉,欢迎大家发挥想象。

告警示例

建立告警规则,用户 1 分钟内超过 3 次登录失败,就产生告警。

可在告警中心查看详情,也可将告警推送至微信、钉钉、飞书、邮件等。

查看告警详情,是 es 用户触发了告警。

最后,剩下的工作就是对该账号的处置了。如果有需要可以考虑阻止该用户或 IP 的请求,对应的过滤器文档在这里,老规矩加到 default_flow 里就行了。

如果小伙伴有其他办法提升 ES 集群安全,欢迎和我们一起讨论、交流。我们的宗旨是:让搜索更简单!

收起阅读 »

INFINI Gateway 如何防止大跨度查询

背景

业务每天生成一个日期后缀的索引,写入当日数据。 业务查询有时会查询好多天的数据,导致负载告警。 现在想对查询进行限制--只允许查询一天的数据(不限定是哪天),如果想查询多天的数据就走申请。

技术分析

在每天一个索引的情况下,要进行多天的数据查询,有三种途径:

  1. 查询时,指定多个索引
  2. 查询时,写前缀+*号,模糊匹配多个索引
  3. 查询别名,别名关联多个索引

需求实现

我们只需用网关代理 ES 集群,并在 default_flow 中增加一段 request_path_filter 过滤器的配置,只允许查询一个索引且格式如 "xxx-2023-12-06", "xxx.2023.12.06", "xxx20231206" 。

      - request_path_filter:
           message: "Query scope exceeds limit, please contact the administrator for application."
           must:
             suffix:
                - _search
             regex:
                - \/[a-z]+[-.]?\d{4}[-.]?\d{1,2}[-.]?\d{1,2}\/

如果需要指定其他格式,请自行修改 regex 的正则表达式。

创建测试索引

INFINI Console 开发工具中执行下列语句:

POST test-2023-12-06/_doc
{
  "test":"test"
}

POST test-2023-12-6/_doc
{
  "test":"test"
}
POST test.2023.12.06/_doc
{
  "test":"test"
}
POST test.2023.12.6/_doc
{
  "test":"test"
}

POST test20231206/_doc
{
  "test":"test"
}

POST test/_doc
{
  "test":"test"
}

查询测试语句

#预计成功的查询
curl localhost:8000/test-2023-12-06/_search?pretty
curl localhost:8000/test-2023-12-6/_search?pretty
curl localhost:8000/test.2023.12.06/_search?pretty
curl localhost:8000/test.2023.12.6/_search?pretty
curl localhost:8000/test20231206/_search?pretty
#预计失败的查询
curl localhost:8000/test-2023-12-06,test-2023-12-6/_search?pretty
curl localhost:8000/test-2023-12*/_search?pretty
curl localhost:8000/test*/_search?pretty
curl localhost:8000/*/_search?pretty

查询结果

预计成功的查询

预计失败的查询

此外,我们在 Console 中的 Request Analysis 看板中也能看到,哪些请求被拒绝,哪些请求被“放行”。

查询多个索引(多天)

现在我们已经实现了业务只能查一个索引,即一天的数据。当业务需要查询多天的索引时,我们只需创建一个别名,关联多个索引就行了。注意别名也要符合格式要求:字母开头 + 日期格式后缀。 下面我们创建一个 test-1111-1-1 的别名,关联前面的三个测试索引。

POST /_aliases
{
  "actions" : [
    { "add" : { "indices" : ["test-2023-12-06", "test.2023.12.06","test-2023-12-6"], "alias" : "test-1111-1-1" } }
  ]
}

查询别名 待业务查询用完之后,删除别名即可。

POST /_aliases
{
  "actions" : [
    { "remove": { "indices" : ["test-2023-12-06", "test.2023.12.06","test-2023-12-6"], "alias" : "test-1111-1-1" } }
  ]
}

最后,我们只需严格控制别名的创建,就能实现我们最初的需求了。

继续阅读 »

背景

业务每天生成一个日期后缀的索引,写入当日数据。 业务查询有时会查询好多天的数据,导致负载告警。 现在想对查询进行限制--只允许查询一天的数据(不限定是哪天),如果想查询多天的数据就走申请。

技术分析

在每天一个索引的情况下,要进行多天的数据查询,有三种途径:

  1. 查询时,指定多个索引
  2. 查询时,写前缀+*号,模糊匹配多个索引
  3. 查询别名,别名关联多个索引

需求实现

我们只需用网关代理 ES 集群,并在 default_flow 中增加一段 request_path_filter 过滤器的配置,只允许查询一个索引且格式如 "xxx-2023-12-06", "xxx.2023.12.06", "xxx20231206" 。

      - request_path_filter:
           message: "Query scope exceeds limit, please contact the administrator for application."
           must:
             suffix:
                - _search
             regex:
                - \/[a-z]+[-.]?\d{4}[-.]?\d{1,2}[-.]?\d{1,2}\/

如果需要指定其他格式,请自行修改 regex 的正则表达式。

创建测试索引

INFINI Console 开发工具中执行下列语句:

POST test-2023-12-06/_doc
{
  "test":"test"
}

POST test-2023-12-6/_doc
{
  "test":"test"
}
POST test.2023.12.06/_doc
{
  "test":"test"
}
POST test.2023.12.6/_doc
{
  "test":"test"
}

POST test20231206/_doc
{
  "test":"test"
}

POST test/_doc
{
  "test":"test"
}

查询测试语句

#预计成功的查询
curl localhost:8000/test-2023-12-06/_search?pretty
curl localhost:8000/test-2023-12-6/_search?pretty
curl localhost:8000/test.2023.12.06/_search?pretty
curl localhost:8000/test.2023.12.6/_search?pretty
curl localhost:8000/test20231206/_search?pretty
#预计失败的查询
curl localhost:8000/test-2023-12-06,test-2023-12-6/_search?pretty
curl localhost:8000/test-2023-12*/_search?pretty
curl localhost:8000/test*/_search?pretty
curl localhost:8000/*/_search?pretty

查询结果

预计成功的查询

预计失败的查询

此外,我们在 Console 中的 Request Analysis 看板中也能看到,哪些请求被拒绝,哪些请求被“放行”。

查询多个索引(多天)

现在我们已经实现了业务只能查一个索引,即一天的数据。当业务需要查询多天的索引时,我们只需创建一个别名,关联多个索引就行了。注意别名也要符合格式要求:字母开头 + 日期格式后缀。 下面我们创建一个 test-1111-1-1 的别名,关联前面的三个测试索引。

POST /_aliases
{
  "actions" : [
    { "add" : { "indices" : ["test-2023-12-06", "test.2023.12.06","test-2023-12-6"], "alias" : "test-1111-1-1" } }
  ]
}

查询别名 待业务查询用完之后,删除别名即可。

POST /_aliases
{
  "actions" : [
    { "remove": { "indices" : ["test-2023-12-06", "test.2023.12.06","test-2023-12-6"], "alias" : "test-1111-1-1" } }
  ]
}

最后,我们只需严格控制别名的创建,就能实现我们最初的需求了。

收起阅读 »

INFINI Labs 产品更新 | Easysearch 新增快照搜索功能,Console 支持 OpenSearch 存储

release

INFINI Labs 产品又更新啦~,包括 Easysearch v1.7.0、Console v1.13.0。本次各产品更新了 Easysearch 快照搜索功能;Console 支持 OpenSearch 集群存储系统数据、优化了初始化安装向导流程等。

以下是本次更新的详细说明。

INFINI Easysearch v1.7.0

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。

Easysearch 本次更新如下:

Features

发布快照搜索功能 Beta 版本,此功能旨在提高对已备份数据的使用效率。让用户利用对象存储(如 AWS S3、MinIO、Microsoft Azure Storage、Google Cloud Storage 等)技术来大幅降低存储成本。

Bug fix

  • 修复单个节点场景下,从快照恢复多个 shard 的索引时,恢复不完整的问题
  • 修复无法删除索引已关联的 ILM 策略问题

Improvements

  • 初始化脚本优化,新增重复执行判断

INFINI Console v1.12.0

INFINI Console 是一款非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管, 企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。

Console 在线体验: http://demo.infini.cloud (用户名/密码:readonly/readonly)。

Console 本次更新如下:

Features

支持 OpenSearch 集群存储系统数据

Bug fix

  • 优化初始化安装流程
  • 新增探针初始化配置
  • 安装向导,新增凭据检查功能
  • 安装向导,新增管理员密码重置功能
  • 探针管理,支持自动关联 Auto Enroll

期待反馈

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

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

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

欢迎加入 Discord 聊天室:https://discord.gg/4tKTMkkvVX

也欢迎大家微信扫码添加小助手(INFINI-Labs),加入用户群一起讨论交流。

联系我们

关于极限科技(INFINI Labs)

INFINI Labs

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

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

官网:https://www.infinilabs.com

继续阅读 »

release

INFINI Labs 产品又更新啦~,包括 Easysearch v1.7.0、Console v1.13.0。本次各产品更新了 Easysearch 快照搜索功能;Console 支持 OpenSearch 集群存储系统数据、优化了初始化安装向导流程等。

以下是本次更新的详细说明。

INFINI Easysearch v1.7.0

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。

Easysearch 本次更新如下:

Features

发布快照搜索功能 Beta 版本,此功能旨在提高对已备份数据的使用效率。让用户利用对象存储(如 AWS S3、MinIO、Microsoft Azure Storage、Google Cloud Storage 等)技术来大幅降低存储成本。

Bug fix

  • 修复单个节点场景下,从快照恢复多个 shard 的索引时,恢复不完整的问题
  • 修复无法删除索引已关联的 ILM 策略问题

Improvements

  • 初始化脚本优化,新增重复执行判断

INFINI Console v1.12.0

INFINI Console 是一款非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管, 企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。

Console 在线体验: http://demo.infini.cloud (用户名/密码:readonly/readonly)。

Console 本次更新如下:

Features

支持 OpenSearch 集群存储系统数据

Bug fix

  • 优化初始化安装流程
  • 新增探针初始化配置
  • 安装向导,新增凭据检查功能
  • 安装向导,新增管理员密码重置功能
  • 探针管理,支持自动关联 Auto Enroll

期待反馈

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

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

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

欢迎加入 Discord 聊天室:https://discord.gg/4tKTMkkvVX

也欢迎大家微信扫码添加小助手(INFINI-Labs),加入用户群一起讨论交流。

联系我们

关于极限科技(INFINI Labs)

INFINI Labs

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

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

官网:https://www.infinilabs.com

收起阅读 »

使用极限网关助力 ES 集群无缝升级、迁移上/下云

在工作中大家可能会遇到以下这些场景:

  • 自建 ES 集群需要平滑迁移到 XX 云;
  • 从 XX 云将 ES 集群迁移到自建机房;
  • ES 集群进行跨版本升级,同时保留回退能力; 这些场景往往都还有个共同的需求:迁移过程要保证业务的最小停机时间。   幸运的是,在这三个场景中,我们都能使用极限网关来帮助我们进行更丝滑的迁移或升级。下面,我们以迁移 ES 集群上云为例,介绍下整个工作过程。
  • 自建版本: 5.4.2
  • 云上版本: 5.6.16
  • Gateway 和 Console 建议用最新版本

    迁移架构

    通过将应用端流量走网关的方式,请求同步转发给自建 ES,网关记录所有的写入请求,并确保顺序在 XX 云 ES 上重放请求,两侧集群的各种故障都妥善进行了处理,从而实现透明的集群双写,实现安全无缝的数据迁移。 业务端如果已经部署在云上,可以使用云上的 SLB 服务来访问网关,确保后端网关的高可用,如果业务端和极限网关还在企业内网,可以使用极限网关自带的 4 层浮动 IP 来确保网关的 高可用

    执行步骤

    部署 INFINI Gateway

    为了保证数据的无缝透明迁移,通过网关来进行双写。

    1. 系统调优
    2. 安装 INFINI Gateway
    3. 修改网关配置       在此 下载 网关双写配置,默认网关会加载配置文件 gateway.yml 。如果要指定其他配置文件使用 -config 选项。      配置文件内容较多,下面仅展示必要部分。
        #primary
        PRIMARY_ENDPOINT: http://192.168.56.3:7171
        PRIMARY_USERNAME: elastic
        PRIMARY_PASSWORD: password
        PRIMARY_MAX_QPS_PER_NODE: 10000
        PRIMARY_MAX_BYTES_PER_NODE: 104857600 #100MB/s
        PRIMARY_MAX_CONNECTION_PER_NODE: 200
        PRIMARY_DISCOVERY_ENABLED: false
        PRIMARY_DISCOVERY_REFRESH_ENABLED: false
        #backup
        BACKUP_ENDPOINT: http://192.168.56.3:9200
        BACKUP_USERNAME: admin
        BACKUP_PASSWORD: admin
        BACKUP_MAX_QPS_PER_NODE: 10000
        BACKUP_MAX_BYTES_PER_NODE: 104857600 #100MB/s
        BACKUP_MAX_CONNECTION_PER_NODE: 200
        BACKUP_DISCOVERY_ENABLED: false
        BACKUP_DISCOVERY_REFRESH_ENABLED: false

      PRIMARY_ENDPOINT:配置主集群地址和端口   PRIMARY_USERNAME、PRIMARY_PASSWORD: 访问主集群的用户信息   BACKUP_ENDPOINT:配置备集群地址和端口   BACKUP_USERNAME、BACKUP_PASSWORD: 访问备集群的用户信息

    4. 启动网关      启动网关并指定刚刚创建的配置,如下:       ./gateway-linux-amd64 -config replication_via-disk.yml.yml

      部署 INFINI Console

      为了方便在多个集群之间快速切换,管理网关消费任务、查看队列等。使用 INFINI Console 来进行管理。

    5. 下载安装
    6. 启动服务      ./console-linux-amd64 -service install      ./console-linux-amd64 -service start
    7. 注册资源      将 ES 集群、极限网关都注册到 Console 中。    - 注册 ES 集群:方便切换集群,执行命令。除了新旧集群外,将网关也在此注册一次,方便验证网关功能。    - 注册 Gateway:管理网关任务、队列。

      测试 INFINI Gateway

      为了验证网关是否正常工作,我们通过 INFINI Console 来快速验证一下。   首先通过走网关的接口来创建一个索引,并写入一个文档,如下: 查看 5.4.2 集群的数据情况,如下: 查看集群 5.6.16 的数据情况,如下: 数据一致,说明网关配置都正常,验证结束。

      调整网关的消费策略

      因为我们需要在全量数据迁移之后,才能进行增量数据的追加,在全量数据迁移完成之前,我们应该暂停增量数据的消费。修改网关配置里面 Pipeline consume-queue_backup-bulk_request_ingestion-to-backup的参数 auto_startfalse,表示不自动启动该任务,具体配置方法如下: 修改完配置之后,需要重新启动网关。   由于之前已经注册了网关,待全量迁移完成之后,可以通过后台的 Task 管理来进行后续的任务启动、停止,如下:

      切换流量

      接下来,将业务正常写的流量切换到网关,也就是需要把之前指向 ES 5.4.2 的地址指向网关的地址,如果 5.4.2 集群开启了身份验证,业务端代码同样需要传递身份信息,和 5.4.2 之前的用法保持不变。 切换流量到网关之后,用户的请求还是以同步的方式正常访问自建集群,网关记录到的请求会按顺序记录到 MQ 里面,但是消费是暂停状态。 如果业务端代码使用的 ES 的 SDK 支持 Sniff,并且业务代码开启了 Sniff,那么应该关闭 Sniff,避免业务端通过 Sniff 直接链接到后端的 ES 节点,所有的流量现在应该都只通过网关来进行访问。

      全量数据迁移

      在流量迁移到网关之后,我们开始对自建 Elasticsearch 集群的数据进行全量迁移到 XX 云 Elasticsearch 集群。 全量迁移已有的数据的方式有很多种:

  • 通过快照的方式进行恢复
  • 使用 INFINI Console 进行数据迁移

    增量数据迁移

    在全量导入的过程中,可能存在数据的增量修改,不过这部分请求都已经完整记录下来了,我们只需要开启网关的消费任务即可将积压的请求应用到云端的 ES 集群。 示例操作如下: 通过观察队列是否消费完成来判断增量数据是否做完,如下:

    执行数据比对

    由于集群内部的数据可能比较多,我们需要进行一个完整的比对才能确保数据的完整性,可以通过 INFINI Console 的数据比对 工具来进行。

    切换集群

    如果验证完之后,两个集群的数据已经完全一致了,可以将程序切换到新集群,或者将网关的配置里面的主备进行互换,仍旧写两个集群,先写云端集群,再写自建集群。 双集群在线运行一段时间,待业务完全验证之后,再安全下线老集群,如遇到问题,也可以随时回切到老集群。

    小结

    通过使用极限网关,自建 ES 集群可以安全无缝的迁移上云,在迁移的过程中,两套集群通过网关进行了解耦,两套集群的版本也可以不一样,在迁移的过程中还能实现版本的无缝升级。 工作流程图

继续阅读 »

在工作中大家可能会遇到以下这些场景:

  • 自建 ES 集群需要平滑迁移到 XX 云;
  • 从 XX 云将 ES 集群迁移到自建机房;
  • ES 集群进行跨版本升级,同时保留回退能力; 这些场景往往都还有个共同的需求:迁移过程要保证业务的最小停机时间。   幸运的是,在这三个场景中,我们都能使用极限网关来帮助我们进行更丝滑的迁移或升级。下面,我们以迁移 ES 集群上云为例,介绍下整个工作过程。
  • 自建版本: 5.4.2
  • 云上版本: 5.6.16
  • Gateway 和 Console 建议用最新版本

    迁移架构

    通过将应用端流量走网关的方式,请求同步转发给自建 ES,网关记录所有的写入请求,并确保顺序在 XX 云 ES 上重放请求,两侧集群的各种故障都妥善进行了处理,从而实现透明的集群双写,实现安全无缝的数据迁移。 业务端如果已经部署在云上,可以使用云上的 SLB 服务来访问网关,确保后端网关的高可用,如果业务端和极限网关还在企业内网,可以使用极限网关自带的 4 层浮动 IP 来确保网关的 高可用

    执行步骤

    部署 INFINI Gateway

    为了保证数据的无缝透明迁移,通过网关来进行双写。

    1. 系统调优
    2. 安装 INFINI Gateway
    3. 修改网关配置       在此 下载 网关双写配置,默认网关会加载配置文件 gateway.yml 。如果要指定其他配置文件使用 -config 选项。      配置文件内容较多,下面仅展示必要部分。
        #primary
        PRIMARY_ENDPOINT: http://192.168.56.3:7171
        PRIMARY_USERNAME: elastic
        PRIMARY_PASSWORD: password
        PRIMARY_MAX_QPS_PER_NODE: 10000
        PRIMARY_MAX_BYTES_PER_NODE: 104857600 #100MB/s
        PRIMARY_MAX_CONNECTION_PER_NODE: 200
        PRIMARY_DISCOVERY_ENABLED: false
        PRIMARY_DISCOVERY_REFRESH_ENABLED: false
        #backup
        BACKUP_ENDPOINT: http://192.168.56.3:9200
        BACKUP_USERNAME: admin
        BACKUP_PASSWORD: admin
        BACKUP_MAX_QPS_PER_NODE: 10000
        BACKUP_MAX_BYTES_PER_NODE: 104857600 #100MB/s
        BACKUP_MAX_CONNECTION_PER_NODE: 200
        BACKUP_DISCOVERY_ENABLED: false
        BACKUP_DISCOVERY_REFRESH_ENABLED: false

      PRIMARY_ENDPOINT:配置主集群地址和端口   PRIMARY_USERNAME、PRIMARY_PASSWORD: 访问主集群的用户信息   BACKUP_ENDPOINT:配置备集群地址和端口   BACKUP_USERNAME、BACKUP_PASSWORD: 访问备集群的用户信息

    4. 启动网关      启动网关并指定刚刚创建的配置,如下:       ./gateway-linux-amd64 -config replication_via-disk.yml.yml

      部署 INFINI Console

      为了方便在多个集群之间快速切换,管理网关消费任务、查看队列等。使用 INFINI Console 来进行管理。

    5. 下载安装
    6. 启动服务      ./console-linux-amd64 -service install      ./console-linux-amd64 -service start
    7. 注册资源      将 ES 集群、极限网关都注册到 Console 中。    - 注册 ES 集群:方便切换集群,执行命令。除了新旧集群外,将网关也在此注册一次,方便验证网关功能。    - 注册 Gateway:管理网关任务、队列。

      测试 INFINI Gateway

      为了验证网关是否正常工作,我们通过 INFINI Console 来快速验证一下。   首先通过走网关的接口来创建一个索引,并写入一个文档,如下: 查看 5.4.2 集群的数据情况,如下: 查看集群 5.6.16 的数据情况,如下: 数据一致,说明网关配置都正常,验证结束。

      调整网关的消费策略

      因为我们需要在全量数据迁移之后,才能进行增量数据的追加,在全量数据迁移完成之前,我们应该暂停增量数据的消费。修改网关配置里面 Pipeline consume-queue_backup-bulk_request_ingestion-to-backup的参数 auto_startfalse,表示不自动启动该任务,具体配置方法如下: 修改完配置之后,需要重新启动网关。   由于之前已经注册了网关,待全量迁移完成之后,可以通过后台的 Task 管理来进行后续的任务启动、停止,如下:

      切换流量

      接下来,将业务正常写的流量切换到网关,也就是需要把之前指向 ES 5.4.2 的地址指向网关的地址,如果 5.4.2 集群开启了身份验证,业务端代码同样需要传递身份信息,和 5.4.2 之前的用法保持不变。 切换流量到网关之后,用户的请求还是以同步的方式正常访问自建集群,网关记录到的请求会按顺序记录到 MQ 里面,但是消费是暂停状态。 如果业务端代码使用的 ES 的 SDK 支持 Sniff,并且业务代码开启了 Sniff,那么应该关闭 Sniff,避免业务端通过 Sniff 直接链接到后端的 ES 节点,所有的流量现在应该都只通过网关来进行访问。

      全量数据迁移

      在流量迁移到网关之后,我们开始对自建 Elasticsearch 集群的数据进行全量迁移到 XX 云 Elasticsearch 集群。 全量迁移已有的数据的方式有很多种:

  • 通过快照的方式进行恢复
  • 使用 INFINI Console 进行数据迁移

    增量数据迁移

    在全量导入的过程中,可能存在数据的增量修改,不过这部分请求都已经完整记录下来了,我们只需要开启网关的消费任务即可将积压的请求应用到云端的 ES 集群。 示例操作如下: 通过观察队列是否消费完成来判断增量数据是否做完,如下:

    执行数据比对

    由于集群内部的数据可能比较多,我们需要进行一个完整的比对才能确保数据的完整性,可以通过 INFINI Console 的数据比对 工具来进行。

    切换集群

    如果验证完之后,两个集群的数据已经完全一致了,可以将程序切换到新集群,或者将网关的配置里面的主备进行互换,仍旧写两个集群,先写云端集群,再写自建集群。 双集群在线运行一段时间,待业务完全验证之后,再安全下线老集群,如遇到问题,也可以随时回切到老集群。

    小结

    通过使用极限网关,自建 ES 集群可以安全无缝的迁移上云,在迁移的过程中,两套集群通过网关进行了解耦,两套集群的版本也可以不一样,在迁移的过程中还能实现版本的无缝升级。 工作流程图

收起阅读 »

INFINI Labs 产品更新 | 修复 Easysearch 跨集群复制索引同步问题,Gateway 内存异常增长等问题

release

INFINI Labs 产品又更新啦~,本次更新主要对 Easysearch、Gateway、Console、Agent 等产品功能进行优化和相关 Bug 修复,解决了内存异常增长等问题,以下是详细说明。

INFINI Easysearch v1.6.2

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。

Easysearch 本次更新如下:

Bug fix

  • 修复跨集群复制(CCR)不能对自动滚动生成的索引进行同步的问题

Improvements

  • 优化初始化脚本,增加-s/-slient 参数,自动安装。
  • 新增含 jdk/plugins 的 bundle 安装包

INFINI Gateway v1.20.0

INFINI Gateway 是一个面向搜索场景的高性能数据网关,所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway 可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。

Gateway 本次更新如下:

Bug fix

  • 修复由 Framework Bug 造成连接数不释放、内存异常增长的问题

Improvements

  • 增加配置,允许设置 fasthttp client 相关参数

INFINI Console v1.12.0

INFINI Console 是一款非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管, 企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。

Console 在线体验: http://demo.infini.cloud (用户名/密码:readonly/readonly)。

Console 本次更新如下:

Bug fix

  • 修复数据探索 multi fields 字段计算 top values 报错的问题
  • 修复由 Framework Bug 造成连接数不释放、内存异常增长的问题
  • 修复内网模式下静态资源远程加载的问题
  • 修复数据看板数据源配置校验异常的问题

Improvements

  • 优化数据探索计算 top values,使用先采样后,后取 top values
  • 可通过配置参数 http_client.read_buffer_size 设置读取缓存大小,解决开发工具执行命令时,默认缓存太小的问题

INFINI Agent v0.7.1

INFINI Agent 是 INFINI Console 的一个可选探针组件,负责采集和上传集群指标和日志等信息,并可通过 Console 管理。Agent 支持主流操作系统和平台,安装包轻量且无任何外部依赖,可以快速方便地安装。

Agent 本次更新如下:

Features

  • 添加 http processor

Bug fix

  • 修复由 Framework Bug 造成连接数不释放、内存异常增长的问题

Improvements

  • 进一步优化内存占用,降到 50M 以下

INFINI Framework

INFINI Framework 是 INFINI Labs 各产品依赖的内部核心公共代码库。

Framework 本次更新如下:

  • fix: fix the issue of disk queue was blocked
  • chore: checkout specify branch before pull

期待反馈

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

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

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

欢迎加入 Discord 聊天室:https://discord.gg/4tKTMkkvVX

也欢迎大家微信扫码添加小助手(INFINI-Labs),加入用户群一起讨论交流。

联系我们

关于极限科技(INFINI Labs)

INFINI Labs

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

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

官网:https://www.infinilabs.com

继续阅读 »

release

INFINI Labs 产品又更新啦~,本次更新主要对 Easysearch、Gateway、Console、Agent 等产品功能进行优化和相关 Bug 修复,解决了内存异常增长等问题,以下是详细说明。

INFINI Easysearch v1.6.2

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。

Easysearch 本次更新如下:

Bug fix

  • 修复跨集群复制(CCR)不能对自动滚动生成的索引进行同步的问题

Improvements

  • 优化初始化脚本,增加-s/-slient 参数,自动安装。
  • 新增含 jdk/plugins 的 bundle 安装包

INFINI Gateway v1.20.0

INFINI Gateway 是一个面向搜索场景的高性能数据网关,所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway 可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。

Gateway 本次更新如下:

Bug fix

  • 修复由 Framework Bug 造成连接数不释放、内存异常增长的问题

Improvements

  • 增加配置,允许设置 fasthttp client 相关参数

INFINI Console v1.12.0

INFINI Console 是一款非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管, 企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。

Console 在线体验: http://demo.infini.cloud (用户名/密码:readonly/readonly)。

Console 本次更新如下:

Bug fix

  • 修复数据探索 multi fields 字段计算 top values 报错的问题
  • 修复由 Framework Bug 造成连接数不释放、内存异常增长的问题
  • 修复内网模式下静态资源远程加载的问题
  • 修复数据看板数据源配置校验异常的问题

Improvements

  • 优化数据探索计算 top values,使用先采样后,后取 top values
  • 可通过配置参数 http_client.read_buffer_size 设置读取缓存大小,解决开发工具执行命令时,默认缓存太小的问题

INFINI Agent v0.7.1

INFINI Agent 是 INFINI Console 的一个可选探针组件,负责采集和上传集群指标和日志等信息,并可通过 Console 管理。Agent 支持主流操作系统和平台,安装包轻量且无任何外部依赖,可以快速方便地安装。

Agent 本次更新如下:

Features

  • 添加 http processor

Bug fix

  • 修复由 Framework Bug 造成连接数不释放、内存异常增长的问题

Improvements

  • 进一步优化内存占用,降到 50M 以下

INFINI Framework

INFINI Framework 是 INFINI Labs 各产品依赖的内部核心公共代码库。

Framework 本次更新如下:

  • fix: fix the issue of disk queue was blocked
  • chore: checkout specify branch before pull

期待反馈

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

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

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

欢迎加入 Discord 聊天室:https://discord.gg/4tKTMkkvVX

也欢迎大家微信扫码添加小助手(INFINI-Labs),加入用户群一起讨论交流。

联系我们

关于极限科技(INFINI Labs)

INFINI Labs

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

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

官网:https://www.infinilabs.com

收起阅读 »

通过 Canal 将 MySQL 数据实时同步到 Easysearch

Canal 是阿里巴巴集团提供的一个开源产品,能够通过解析数据库的增量日志,提供增量数据的订阅和消费功能。使用 Canal 模拟成 MySQL 的 Slave,实时接收 MySQL 的增量数据 binlog,然后通过 RESTful API 将数据写入到 Easysearch 中。

前提条件

  1. 部署 Easysearch 集群。
  2. 部署 MySQL 数据库。
  3. 部署 Gateway,Canal Adapter 不支持使用 HTTPS 协议连接,使用 Gateway 代理 Easysearch 。
  4. 部署 Console,方便查看 Easysearch 数据。
    对于自建 MySQL , 需要先开启 Binlog 写入功能,配置 binlog-format 为 ROW 模式,my.cnf 中配置如下:
    [mysqld]
    log-bin=mysql-bin # 开启 binlog
    binlog-format=ROW # 选择 ROW 模式
    server_id=1 # 配置 MySQL replaction 需要定义,不要和 canal 的 slaveId 重复

    创建 canal 用户,授权 canal 连接 MySQL 具有作为 MySQL slave 的权限。

    CREATE USER canal IDENTIFIED BY 'canal';
    GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';
    -- GRANT ALL PRIVILEGES ON *.* TO 'canal'@'%' ;
    FLUSH PRIVILEGES;

    操作步骤

    在进行数据同步时支持自定义索引 Mapping,但需保证 Mapping 中定义的字段(名称+类型)与 MySQL 中一致。

    1. 准备 MySQL 数据源

    create database canal;
    use canal;
    CREATE TABLE `test` (
        `id` bigint(32) NOT NULL,
        `name` text NOT NULL,
        `age` smallint  NOT NULL,
        PRIMARY KEY (`id`)
    ) ENGINE=InnoDB
    DEFAULT CHARACTER SET=utf8;

    2. Easysearch 创建索引

    PUT test
    {
        "settings" : {
          "index" : {
            "number_of_shards" : "1",
            "number_of_replicas" : "1"
          }
        },
        "mappings" : {
                "properties" : {
                  "id": {
                       "type": "integer"
                   },
                   "name": {
                        "type" : "text"
                    },
                    "age" : {
                        "type" : "integer"
                    }
                }
        }
    }

    3. 安装并启动 Canal-server

    下载https://github.com/alibaba/canal/releases/download/canal-1.1.7/canal.deployer-1.1.7.tar.gz  
    修改配置文件 vi conf/example/instance.properties
    启动 canal  
    sh bin/startup.sh  
    启动成功日志信息,logs/canal/canal.log 关闭 canal  
    sh bin/stop.sh

    4. 安装并启动 Canal-adapter

    下载https://github.com/alibaba/canal/releases/download/canal-1.1.7/canal.adapter-1.1.7.tar.gz  
    修改配置文件:application.yml

    server:
      port: 8081
    spring:
      jackson:
        date-format: yyyy-MM-dd HH:mm:ss
        time-zone: GMT+8
        default-property-inclusion: non_null
    canal.conf:
      flatMessage: true
      syncBatchSize: 1000
      retries: -1
      timeout:
      accessKey:
      secretKey:
      consumerProperties:
        canal.tcp.server.host: 127.0.0.1:11111
        canal.tcp.batch.size: 500
      srcDataSources:
        defaultDS:
          url: jdbc:mysql://127.0.0.1:3306/canal?useUnicode=true
          username: canal
          password: canal
      canalAdapters:
        groups:
        - groupId: g1
          outerAdapters:
          - name: logger
          - name: es7
            properties:
              security.auth: admin:4ad8f8f792e81cd0a6de
              cluster.name: easysearch

    新增 canal-adapter/conf/es7/test.yml,配置索引和表的映射关系。

    dataSourceKey: defaultDS
    destination: example
    groupId: g1
    esMapping:
      _index: test           # es 的索引名称
      _id: _id               # es 的_id, 如果不配置该项必须配置下面的pk项_id则会由es自动分配
      # sql映射
      sql: " select a.id as _id,a.id,a.name,a.age from test a "
      etlCondition: "where a.id>={}"
      commitBatch: 3000      # 提交批大小

    启动 canal-adapter  
    ./bin/startup.sh

    5. 验证增量数据同步

    在 MySQL 数据库中,对 test 表插入两条数据。  
    inserttest(id,name,age) values(1,'canal_test1',11);  
    inserttest(id,name,age) values(2,'canal_test2',22);

    6. 在 Console 中,执行以下命令查询数据

    最后

    Canal 同步的是增量数据,不会同步之前的存量数据。要同步存量数据可参考《使用 Logstash 同步 MySQL 到 Easysearch》

继续阅读 »

Canal 是阿里巴巴集团提供的一个开源产品,能够通过解析数据库的增量日志,提供增量数据的订阅和消费功能。使用 Canal 模拟成 MySQL 的 Slave,实时接收 MySQL 的增量数据 binlog,然后通过 RESTful API 将数据写入到 Easysearch 中。

前提条件

  1. 部署 Easysearch 集群。
  2. 部署 MySQL 数据库。
  3. 部署 Gateway,Canal Adapter 不支持使用 HTTPS 协议连接,使用 Gateway 代理 Easysearch 。
  4. 部署 Console,方便查看 Easysearch 数据。
    对于自建 MySQL , 需要先开启 Binlog 写入功能,配置 binlog-format 为 ROW 模式,my.cnf 中配置如下:
    [mysqld]
    log-bin=mysql-bin # 开启 binlog
    binlog-format=ROW # 选择 ROW 模式
    server_id=1 # 配置 MySQL replaction 需要定义,不要和 canal 的 slaveId 重复

    创建 canal 用户,授权 canal 连接 MySQL 具有作为 MySQL slave 的权限。

    CREATE USER canal IDENTIFIED BY 'canal';
    GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';
    -- GRANT ALL PRIVILEGES ON *.* TO 'canal'@'%' ;
    FLUSH PRIVILEGES;

    操作步骤

    在进行数据同步时支持自定义索引 Mapping,但需保证 Mapping 中定义的字段(名称+类型)与 MySQL 中一致。

    1. 准备 MySQL 数据源

    create database canal;
    use canal;
    CREATE TABLE `test` (
        `id` bigint(32) NOT NULL,
        `name` text NOT NULL,
        `age` smallint  NOT NULL,
        PRIMARY KEY (`id`)
    ) ENGINE=InnoDB
    DEFAULT CHARACTER SET=utf8;

    2. Easysearch 创建索引

    PUT test
    {
        "settings" : {
          "index" : {
            "number_of_shards" : "1",
            "number_of_replicas" : "1"
          }
        },
        "mappings" : {
                "properties" : {
                  "id": {
                       "type": "integer"
                   },
                   "name": {
                        "type" : "text"
                    },
                    "age" : {
                        "type" : "integer"
                    }
                }
        }
    }

    3. 安装并启动 Canal-server

    下载https://github.com/alibaba/canal/releases/download/canal-1.1.7/canal.deployer-1.1.7.tar.gz  
    修改配置文件 vi conf/example/instance.properties
    启动 canal  
    sh bin/startup.sh  
    启动成功日志信息,logs/canal/canal.log 关闭 canal  
    sh bin/stop.sh

    4. 安装并启动 Canal-adapter

    下载https://github.com/alibaba/canal/releases/download/canal-1.1.7/canal.adapter-1.1.7.tar.gz  
    修改配置文件:application.yml

    server:
      port: 8081
    spring:
      jackson:
        date-format: yyyy-MM-dd HH:mm:ss
        time-zone: GMT+8
        default-property-inclusion: non_null
    canal.conf:
      flatMessage: true
      syncBatchSize: 1000
      retries: -1
      timeout:
      accessKey:
      secretKey:
      consumerProperties:
        canal.tcp.server.host: 127.0.0.1:11111
        canal.tcp.batch.size: 500
      srcDataSources:
        defaultDS:
          url: jdbc:mysql://127.0.0.1:3306/canal?useUnicode=true
          username: canal
          password: canal
      canalAdapters:
        groups:
        - groupId: g1
          outerAdapters:
          - name: logger
          - name: es7
            properties:
              security.auth: admin:4ad8f8f792e81cd0a6de
              cluster.name: easysearch

    新增 canal-adapter/conf/es7/test.yml,配置索引和表的映射关系。

    dataSourceKey: defaultDS
    destination: example
    groupId: g1
    esMapping:
      _index: test           # es 的索引名称
      _id: _id               # es 的_id, 如果不配置该项必须配置下面的pk项_id则会由es自动分配
      # sql映射
      sql: " select a.id as _id,a.id,a.name,a.age from test a "
      etlCondition: "where a.id>={}"
      commitBatch: 3000      # 提交批大小

    启动 canal-adapter  
    ./bin/startup.sh

    5. 验证增量数据同步

    在 MySQL 数据库中,对 test 表插入两条数据。  
    inserttest(id,name,age) values(1,'canal_test1',11);  
    inserttest(id,name,age) values(2,'canal_test2',22);

    6. 在 Console 中,执行以下命令查询数据

    最后

    Canal 同步的是增量数据,不会同步之前的存量数据。要同步存量数据可参考《使用 Logstash 同步 MySQL 到 Easysearch》

收起阅读 »

INFINI Labs 产品更新 | 发布 Easysearch Java 客户端,Console 支持 SQL 查询等功能

release

INFINI Labs 产品又更新啦~,本次更新概要如下:发布 Easysearch-client Java 客户端,开发者通过 client 与 Easysearch 集群的交互变得更加简洁和直观;Console 开发工具新增 SQL 特性,支持 SELECT 查询等语法高亮和自动提示等;Gateway 的系统 API 添加了基于基本身份验证的安全功能。

以下是本次更新的详细说明。

INFINI Easysearch-client v1.0.1

正式发布 Easysearch Java 客户端。

这一里程碑式的更新为开发人员带来了前所未有的便利性,使得与 Easysearch 集群的交互变得更加简洁和直观。现在,通过 Easysearch-client 客户端,开发者可以直接使用 Java 方法和数据结构来进行交互,而不再需要依赖于传统的 HTTP 方法和 JSON。这一变化大大简化了操作流程,使得数据管理和索引更加高效。高级客户端的功能范围包括处理数据操作,管理集群,包括查看和维护集群的健康状态,并对 Security 模块全面兼容。它提供了一系列 API,用于管理角色、用户、权限、角色映射和账户。这意味着安全性和访问控制现在可以更加细粒度地管理,确保了数据的安全性和合规性。

使用说明参见:快速开始

INFINI Console v1.11.0

INFINI Console 是一款非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管, 企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。

Console 在线体验: http://demo.infini.cloud (用户名/密码:readonly/readonly)。

Console 本次更新如下:

Features

  • 开发工具 SQL 查询支持
    • 支持 SELECT 查询及语法高亮
    • 支持索引和字段自动提示
    • 支持 FROM 前置语法

Bug fix

  • 修复平台概览集群指标为空的问题

Improvements

  • LDAP 支持从 DN 中解析 OU 属性
  • 集群动态优化显示,新增节点名称和索引名称的聚合统计过滤

INFINI Gateway v1.19.0

INFINI Gateway 是一个面向搜索场景的高性能数据网关,所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway 可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。

Gateway 本次更新如下:

Features

  • 添加 http 处理器
  • 在 API 模块中添加基于基本身份验证的安全性
  • 允许将自身注册到配置管理器
  • 允许在配置错误时触发 panic

Bug fix

  • 修复 rewrite_to_bulk 在较新版本中缺少 _type 的问题
  • 修复 rewrite_to_bulk,支持无索引文档操作

Improvements

  • 更新测试,断言解析结果

期待反馈

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

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

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

欢迎加入 Discord 聊天室:https://discord.gg/4tKTMkkvVX

也欢迎大家微信扫码添加小助手(INFINI-Labs),加入用户群一起讨论交流。

联系我们

关于极限科技(INFINI Labs)

INFINI Labs

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

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

官网:https://www.infinilabs.com

继续阅读 »

release

INFINI Labs 产品又更新啦~,本次更新概要如下:发布 Easysearch-client Java 客户端,开发者通过 client 与 Easysearch 集群的交互变得更加简洁和直观;Console 开发工具新增 SQL 特性,支持 SELECT 查询等语法高亮和自动提示等;Gateway 的系统 API 添加了基于基本身份验证的安全功能。

以下是本次更新的详细说明。

INFINI Easysearch-client v1.0.1

正式发布 Easysearch Java 客户端。

这一里程碑式的更新为开发人员带来了前所未有的便利性,使得与 Easysearch 集群的交互变得更加简洁和直观。现在,通过 Easysearch-client 客户端,开发者可以直接使用 Java 方法和数据结构来进行交互,而不再需要依赖于传统的 HTTP 方法和 JSON。这一变化大大简化了操作流程,使得数据管理和索引更加高效。高级客户端的功能范围包括处理数据操作,管理集群,包括查看和维护集群的健康状态,并对 Security 模块全面兼容。它提供了一系列 API,用于管理角色、用户、权限、角色映射和账户。这意味着安全性和访问控制现在可以更加细粒度地管理,确保了数据的安全性和合规性。

使用说明参见:快速开始

INFINI Console v1.11.0

INFINI Console 是一款非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管, 企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。

Console 在线体验: http://demo.infini.cloud (用户名/密码:readonly/readonly)。

Console 本次更新如下:

Features

  • 开发工具 SQL 查询支持
    • 支持 SELECT 查询及语法高亮
    • 支持索引和字段自动提示
    • 支持 FROM 前置语法

Bug fix

  • 修复平台概览集群指标为空的问题

Improvements

  • LDAP 支持从 DN 中解析 OU 属性
  • 集群动态优化显示,新增节点名称和索引名称的聚合统计过滤

INFINI Gateway v1.19.0

INFINI Gateway 是一个面向搜索场景的高性能数据网关,所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway 可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。

Gateway 本次更新如下:

Features

  • 添加 http 处理器
  • 在 API 模块中添加基于基本身份验证的安全性
  • 允许将自身注册到配置管理器
  • 允许在配置错误时触发 panic

Bug fix

  • 修复 rewrite_to_bulk 在较新版本中缺少 _type 的问题
  • 修复 rewrite_to_bulk,支持无索引文档操作

Improvements

  • 更新测试,断言解析结果

期待反馈

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

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

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

欢迎加入 Discord 聊天室:https://discord.gg/4tKTMkkvVX

也欢迎大家微信扫码添加小助手(INFINI-Labs),加入用户群一起讨论交流。

联系我们

关于极限科技(INFINI Labs)

INFINI Labs

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

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

官网:https://www.infinilabs.com

收起阅读 »

使用 Filebeat+Easysearch+Console 打造日志管理平台

近年来,日志管理平台越来越流行。使用日志管理平台可以实时地、统一地、方便地管理和查看日志,挖掘日志数据价值,驱动运维、运营,提升服务管理效率。

方案架构

  • Beats 是轻量级采集器,包括 Filebeat、Metricbeat 等。
  • Easysearch 是个分布式搜索引擎,提供搜集、分析、存储数据等主要功能。
  • Console 是一个可视化工具,提供可视化查询,制作报表等功能。

本文将搭建一个统一日志管理平台。使用 Filebeat 采集 OS 中的日志(其他日志大同小异),发送到 Easysearch 中。最后通过 Console 进行日志的可视化查询与分析。

操作步骤

  1. 准备工作
    • 部署 Easysearch
      • 编辑 easysearch.yml 文件,打开注释 elasticsearch.api_compatibility: true
    • 部署 Console
  2. 安装并配置 Filebeat
setup.template.name: "filebeat"
setup.template.pattern: "system-log*"
setup.template.fields: "${path.config}/fields.yml"

output.elasticsearch:
    hosts: ["localhost:9200"]
    protocol: "https"
    ssl.verification_mode: none
    username: "admin"
    password: "4ad8f8f792e81cd0a6de"
    index: "system-log"
  1. 启用 system 模块并导入 pipeline

./filebeat modules enable system
./filebeat setup --pipelines --modules system

  1. 创建索引模板及初始索引,使用 ZSTD+SOURCE_REUSE 技术节省磁盘空间
PUT _template/system_log
{
    "order": 100,
  "index_patterns": [
      "system_log*"
    ],
      "settings": {
        "index": {
          "format": "7",
          "lifecycle": {
          "name": "ilm_.infini_metrics-30days-retention",
          "rollover_alias": "system_log"
        },
        "codec": "ZSTD",
        "source_reuse": true,
        "number_of_shards": "1",
        "translog": {
          "durability": "async"
        }
      }
    },
    "mappings": {
      "dynamic_templates": [
        {
          "strings": {
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            },
            "match_mapping_type": "string"
          }
        }
      ]
    }
}

PUT system-log-00001
{
    "aliases":{
    "system-log":{
      "is_write_index":true
    }
  }
}
  1. 启动 filebeat

nohup ./filebeat -c filebeat.yml 2>&1>/dev/null &

  1. 进入 Console 查看、搜索日志
  2. 进入 Console 创建 dashboard 进行日志分析
继续阅读 »

近年来,日志管理平台越来越流行。使用日志管理平台可以实时地、统一地、方便地管理和查看日志,挖掘日志数据价值,驱动运维、运营,提升服务管理效率。

方案架构

  • Beats 是轻量级采集器,包括 Filebeat、Metricbeat 等。
  • Easysearch 是个分布式搜索引擎,提供搜集、分析、存储数据等主要功能。
  • Console 是一个可视化工具,提供可视化查询,制作报表等功能。

本文将搭建一个统一日志管理平台。使用 Filebeat 采集 OS 中的日志(其他日志大同小异),发送到 Easysearch 中。最后通过 Console 进行日志的可视化查询与分析。

操作步骤

  1. 准备工作
    • 部署 Easysearch
      • 编辑 easysearch.yml 文件,打开注释 elasticsearch.api_compatibility: true
    • 部署 Console
  2. 安装并配置 Filebeat
setup.template.name: "filebeat"
setup.template.pattern: "system-log*"
setup.template.fields: "${path.config}/fields.yml"

output.elasticsearch:
    hosts: ["localhost:9200"]
    protocol: "https"
    ssl.verification_mode: none
    username: "admin"
    password: "4ad8f8f792e81cd0a6de"
    index: "system-log"
  1. 启用 system 模块并导入 pipeline

./filebeat modules enable system
./filebeat setup --pipelines --modules system

  1. 创建索引模板及初始索引,使用 ZSTD+SOURCE_REUSE 技术节省磁盘空间
PUT _template/system_log
{
    "order": 100,
  "index_patterns": [
      "system_log*"
    ],
      "settings": {
        "index": {
          "format": "7",
          "lifecycle": {
          "name": "ilm_.infini_metrics-30days-retention",
          "rollover_alias": "system_log"
        },
        "codec": "ZSTD",
        "source_reuse": true,
        "number_of_shards": "1",
        "translog": {
          "durability": "async"
        }
      }
    },
    "mappings": {
      "dynamic_templates": [
        {
          "strings": {
            "mapping": {
              "ignore_above": 256,
              "type": "keyword"
            },
            "match_mapping_type": "string"
          }
        }
      ]
    }
}

PUT system-log-00001
{
    "aliases":{
    "system-log":{
      "is_write_index":true
    }
  }
}
  1. 启动 filebeat

nohup ./filebeat -c filebeat.yml 2>&1>/dev/null &

  1. 进入 Console 查看、搜索日志
  2. 进入 Console 创建 dashboard 进行日志分析
收起阅读 »

Easysearch 容量规划建议

你是否还在纠结怎么规划 Easysearch 集群存储容量,这篇文章将从容量估算、搜索吞吐量估算等场景为你提供详细的规划建议。

基于容量估算

主要问题:

  • 每天将索引多少原始数据(GB)?保留数据多少天?
  • 原始数据膨胀率
  • 您将强制执行多少个副本分片?
  • 您将为每个数据节点分配多少内存?
  • 您的内存:数据比例是多少?

原则

  • 保留 +15% 以保持在磁盘水位以下。
  • 保留 +5% 用于误差和后台活动的余量。
  • 保留相当于一个数据节点的资源来处理故障。

公式:

总数据量 GB = 原始数据 GB/天 * 保留天数 * 膨胀率 * (副本数 + 1)

总存储 GB = 总数据 GB * 1.15(包括磁盘 watermark threshold 和误差范围)

总数据节点数 = ROUNDUP(总存储 GB / (每个数据节点的内存 * 内存/数据比例)) + 1(用于故障转移)

举例:

假设 需要存储的源数据 50TB 大小

膨胀率 10% 副本数 1

每个节点 256G 内存

计算出:

总数据量 TB

= 50TB * (1 + 0.10) * (1 + 1)

= 110TB

总存储 TB

= 110TB * 1.15(考虑磁盘 watermark threshold 和误差范围)

= 126.5TB

如果有 256GB 的物理内存,128GB 会用于 JVM 堆,剩下的 128GB 将用于操作系统、文件缓存和其他系统进程。

按照常见的 1:30 的 RAM 到磁盘比例来计算,那么每个节点能处理的数据存储大约是:

256GB 内存 * 30 = 7680GB,大约等于 7.68TB

总数据节点数

= ROUNDUP(126.5TB / 7.68TB) + 1(用于故障转移)

= ROUNDUP(16.47) + 1

= 18

基于搜索吞吐量估算

在存储容量层面之外,还要考虑搜索响应时间和搜索吞吐量的目标,这些目标可能需要更多的内存和计算资源。

搜索响应时间受太多变量的影响,无法预测任何给定容量计划会如何影响它。但通过经验性测试搜索响应时间并估计预期的搜索吞吐量,我们可以估算出满足这些需求所需的集群资源。

主要问题:

  • 你每秒的最高搜索次数是多少?
  • 你的平均搜索响应时间(毫秒)是多少?
  • 你的数据节点上有多少个核心和每个核心有多少个线程

经验方法:

与其确定资源将如何影响搜索速度,不如将搜索速度视为一个常数,通过在计划的硬件上进行测量来处理。然后确定集群需要多少个核心来处理预期的搜索吞吐量峰值。最终目标是防止线程池队列增长速度超过它们被消耗的速度。如果计算资源不足,搜索请求有被丢弃的风险。

公式:

峰值线程数 = 向上取整(每秒的峰值搜索次数 * 平均搜索响应时间(毫秒) / 1000 毫秒)

线程池大小 = 向上取整((每个节点的物理核心数 * 每个核心的线程数 * 3 / 2) + 1)

总数据节点数 = 向上取整(峰值线程数 / 线程池大小)

举例:

假设每秒 2 万搜索请求,平均响应时间 50 毫秒,每个节点有 16 个线程数,计算需要多少节点

峰值线程数 = 20000 * 50 /1000 = 1000

线程池大小 = (16 * 1 * 3/2) + 1 = 25

总数据节点数 = 1000 / 25 = 40

大概需要 40 个数据节点来处理每秒 2 万的搜索请求,平均响应时间为 50 毫秒,每个节点有 16 个线程。这是一个粗略的估计,实际需求可能会因多种因素而有所不同。建议进行实际测试以确认这些数字。

Hot, Warm, Frozen

根据索引使用情况不同,通常分为种存储。 这是一种经济高效的方法,用于存储大量数据,同时优化了对较新数据的性能。在容量规划期间,每个层次必须独立进行规模确定,然后进行合并。

层面 目标 示例存储 示例内存:存储比
Hot 搜索为主 SSD DAS/SAN (>200Gb/s) 1:30
Warm 存储为主 HDD DAS/SAN (~100Gb/s) 1:100
Frozen 存档为主 Cheapest DAS/SAN (<100Gb/s) 1:500

实际情况要把搜索吞吐量估算和容量估算结合考虑。

关于 Easysearch

about easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。 与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://www.infinilabs.com/docs/latest/easysearch

下载地址:https://www.infinilabs.com/download

原文:https://www.infinilabs.com/blog/2023/capacity-planning-recommendations-for-easysearch/

继续阅读 »

你是否还在纠结怎么规划 Easysearch 集群存储容量,这篇文章将从容量估算、搜索吞吐量估算等场景为你提供详细的规划建议。

基于容量估算

主要问题:

  • 每天将索引多少原始数据(GB)?保留数据多少天?
  • 原始数据膨胀率
  • 您将强制执行多少个副本分片?
  • 您将为每个数据节点分配多少内存?
  • 您的内存:数据比例是多少?

原则

  • 保留 +15% 以保持在磁盘水位以下。
  • 保留 +5% 用于误差和后台活动的余量。
  • 保留相当于一个数据节点的资源来处理故障。

公式:

总数据量 GB = 原始数据 GB/天 * 保留天数 * 膨胀率 * (副本数 + 1)

总存储 GB = 总数据 GB * 1.15(包括磁盘 watermark threshold 和误差范围)

总数据节点数 = ROUNDUP(总存储 GB / (每个数据节点的内存 * 内存/数据比例)) + 1(用于故障转移)

举例:

假设 需要存储的源数据 50TB 大小

膨胀率 10% 副本数 1

每个节点 256G 内存

计算出:

总数据量 TB

= 50TB * (1 + 0.10) * (1 + 1)

= 110TB

总存储 TB

= 110TB * 1.15(考虑磁盘 watermark threshold 和误差范围)

= 126.5TB

如果有 256GB 的物理内存,128GB 会用于 JVM 堆,剩下的 128GB 将用于操作系统、文件缓存和其他系统进程。

按照常见的 1:30 的 RAM 到磁盘比例来计算,那么每个节点能处理的数据存储大约是:

256GB 内存 * 30 = 7680GB,大约等于 7.68TB

总数据节点数

= ROUNDUP(126.5TB / 7.68TB) + 1(用于故障转移)

= ROUNDUP(16.47) + 1

= 18

基于搜索吞吐量估算

在存储容量层面之外,还要考虑搜索响应时间和搜索吞吐量的目标,这些目标可能需要更多的内存和计算资源。

搜索响应时间受太多变量的影响,无法预测任何给定容量计划会如何影响它。但通过经验性测试搜索响应时间并估计预期的搜索吞吐量,我们可以估算出满足这些需求所需的集群资源。

主要问题:

  • 你每秒的最高搜索次数是多少?
  • 你的平均搜索响应时间(毫秒)是多少?
  • 你的数据节点上有多少个核心和每个核心有多少个线程

经验方法:

与其确定资源将如何影响搜索速度,不如将搜索速度视为一个常数,通过在计划的硬件上进行测量来处理。然后确定集群需要多少个核心来处理预期的搜索吞吐量峰值。最终目标是防止线程池队列增长速度超过它们被消耗的速度。如果计算资源不足,搜索请求有被丢弃的风险。

公式:

峰值线程数 = 向上取整(每秒的峰值搜索次数 * 平均搜索响应时间(毫秒) / 1000 毫秒)

线程池大小 = 向上取整((每个节点的物理核心数 * 每个核心的线程数 * 3 / 2) + 1)

总数据节点数 = 向上取整(峰值线程数 / 线程池大小)

举例:

假设每秒 2 万搜索请求,平均响应时间 50 毫秒,每个节点有 16 个线程数,计算需要多少节点

峰值线程数 = 20000 * 50 /1000 = 1000

线程池大小 = (16 * 1 * 3/2) + 1 = 25

总数据节点数 = 1000 / 25 = 40

大概需要 40 个数据节点来处理每秒 2 万的搜索请求,平均响应时间为 50 毫秒,每个节点有 16 个线程。这是一个粗略的估计,实际需求可能会因多种因素而有所不同。建议进行实际测试以确认这些数字。

Hot, Warm, Frozen

根据索引使用情况不同,通常分为种存储。 这是一种经济高效的方法,用于存储大量数据,同时优化了对较新数据的性能。在容量规划期间,每个层次必须独立进行规模确定,然后进行合并。

层面 目标 示例存储 示例内存:存储比
Hot 搜索为主 SSD DAS/SAN (>200Gb/s) 1:30
Warm 存储为主 HDD DAS/SAN (~100Gb/s) 1:100
Frozen 存档为主 Cheapest DAS/SAN (<100Gb/s) 1:500

实际情况要把搜索吞吐量估算和容量估算结合考虑。

关于 Easysearch

about easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。 与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://www.infinilabs.com/docs/latest/easysearch

下载地址:https://www.infinilabs.com/download

原文:https://www.infinilabs.com/blog/2023/capacity-planning-recommendations-for-easysearch/

收起阅读 »

Easysearch Chart 0.2.0 都有哪些变化

Easysearch Chart 包更新了,让我们来看看都有哪些变化:

  • Docker 镜像升级

  • Service 名称调整,支持 NodePort 模式部署

现在让我们用 NodePort 模式部署一下:

# helm search repo infinilabs
NAME                    CHART VERSION   APP VERSION DESCRIPTION
infinilabs/console      0.2.0           1.8.0-1259  A Helm chart for Kubernetes
infinilabs/easysearch   0.2.0           1.6.0-59    A Helm chart for Kubernetes
infinilabs/gateway      0.1.0           1.18.0-1123 A Helm chart for Kubernetes

# cat es-nodeport.yaml
service:
  type: NodePort
  http: 9200
  transport: 9300
  httpNodeport: 30920
  transNodeport: 30930

# helm install easysearch infinilabs/easysearch -n infini -f es-nodeport.yaml
NAME: easysearch
LAST DEPLOYED: Mon Oct  9 08:38:28 2023
NAMESPACE: infini
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Get the application URL by running these commands:
  export NODE_PORT=$(kubectl get --namespace infini -o jsonpath="{.spec.ports[0].nodePort}" services easysearch)
  export NODE_IP=$(kubectl get nodes --namespace infini -o jsonpath="{.items[0].status.addresses[0].address}")
  echo http://$NODE_IP:$NODE_PORT

# kubectl get svc -n infini
NAME         TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                         AGE
easysearch   NodePort   10.43.175.245   <none>        9200:30920/TCP,9300:30930/TCP   25s

# kubectl get pod -n infini
NAME           READY   STATUS    RESTARTS   AGE
easysearch-0   1/1     Running   0          40s

# curl -ku'admin:admin' https://10.0.0.1:30920
{
  "name" : "easysearch-0",
  "cluster_name" : "infinilabs",
  "cluster_uuid" : "2cPioaONRVWp6BydbGuXDw",
  "version" : {
    "distribution" : "easysearch",
    "number" : "1.6.0",
    "distributor" : "INFINI Labs",
    "build_hash" : "e5d1ff9067b3dd696d52c61fbca1f8daed931fb7",
    "build_date" : "2023-09-22T00:55:32.292580Z",
    "build_snapshot" : false,
    "lucene_version" : "8.11.2",
    "minimum_wire_lucene_version" : "7.7.0",
    "minimum_lucene_index_compatibility_version" : "7.7.0"
  },
  "tagline" : "You Know, For Easy Search!"
}

关于 Easysearch

about easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。 与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://www.infinilabs.com/docs/latest/easysearch

下载地址:https://www.infinilabs.com/download

原文:https://www.infinilabs.com/blog/2023/easysearch-chart-change-0.2.0/

继续阅读 »

Easysearch Chart 包更新了,让我们来看看都有哪些变化:

  • Docker 镜像升级

  • Service 名称调整,支持 NodePort 模式部署

现在让我们用 NodePort 模式部署一下:

# helm search repo infinilabs
NAME                    CHART VERSION   APP VERSION DESCRIPTION
infinilabs/console      0.2.0           1.8.0-1259  A Helm chart for Kubernetes
infinilabs/easysearch   0.2.0           1.6.0-59    A Helm chart for Kubernetes
infinilabs/gateway      0.1.0           1.18.0-1123 A Helm chart for Kubernetes

# cat es-nodeport.yaml
service:
  type: NodePort
  http: 9200
  transport: 9300
  httpNodeport: 30920
  transNodeport: 30930

# helm install easysearch infinilabs/easysearch -n infini -f es-nodeport.yaml
NAME: easysearch
LAST DEPLOYED: Mon Oct  9 08:38:28 2023
NAMESPACE: infini
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Get the application URL by running these commands:
  export NODE_PORT=$(kubectl get --namespace infini -o jsonpath="{.spec.ports[0].nodePort}" services easysearch)
  export NODE_IP=$(kubectl get nodes --namespace infini -o jsonpath="{.items[0].status.addresses[0].address}")
  echo http://$NODE_IP:$NODE_PORT

# kubectl get svc -n infini
NAME         TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)                         AGE
easysearch   NodePort   10.43.175.245   <none>        9200:30920/TCP,9300:30930/TCP   25s

# kubectl get pod -n infini
NAME           READY   STATUS    RESTARTS   AGE
easysearch-0   1/1     Running   0          40s

# curl -ku'admin:admin' https://10.0.0.1:30920
{
  "name" : "easysearch-0",
  "cluster_name" : "infinilabs",
  "cluster_uuid" : "2cPioaONRVWp6BydbGuXDw",
  "version" : {
    "distribution" : "easysearch",
    "number" : "1.6.0",
    "distributor" : "INFINI Labs",
    "build_hash" : "e5d1ff9067b3dd696d52c61fbca1f8daed931fb7",
    "build_date" : "2023-09-22T00:55:32.292580Z",
    "build_snapshot" : false,
    "lucene_version" : "8.11.2",
    "minimum_wire_lucene_version" : "7.7.0",
    "minimum_lucene_index_compatibility_version" : "7.7.0"
  },
  "tagline" : "You Know, For Easy Search!"
}

关于 Easysearch

about easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。 与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://www.infinilabs.com/docs/latest/easysearch

下载地址:https://www.infinilabs.com/download

原文:https://www.infinilabs.com/blog/2023/easysearch-chart-change-0.2.0/

收起阅读 »

Easysearch 压缩功能的显著提升:从 8.7GB 到 1.4GB

引言

在海量数据的存储和处理中,索引膨胀率是一个不可忽视的关键指标。它直接影响了存储成本和查询性能。近期,Easysearch 在这方面取得了显著的进展,其压缩功能的效果远超过了之前的版本。本文将详细介绍这一进展。

Easysearch 各版本压缩性能对比

根据之前文章的数据,Easysearch v1.1 在处理相同数据时,其索引大小比 Elasticsearch v6.4.3 降低了 50%。但这还不是全部,最新的测试数据更是令人惊艳。

显著的压缩效果:实验数据解析

通过对比不同版本的存储大小,我们更直观地了解到 Easysearch 在压缩方面的优势:

  • Easysearch 的原始版本,未开启压缩:存储大小为 8.7 GB。
  • Easysearch v2 版本:经过第二版压缩后,存储大小显著减少到 2.7 GB。
  • Easysearch v3 版本:第三版压缩后,存储大小进一步减少到 1.4 GB。

关键观察

Easysearch 之前提供的压缩版相比原始版本减少了约 69%的存储空间。

Easysearch v3 版则更为显著,相比原始版本减少了约 84%的存储空间。

第三版本压缩的秘密武器:数字类型字段的复用

第三版本压缩能达到如此高的效率,主要是因为在之前第二版对文档原文中 keyword 类型字段复用的基础上,增加了对数字类型字段的复用。这一策略进一步优化了存储结构,显著提高了压缩效率。

压缩策略:多元化选择

Easysearch 提供了多种压缩策略,包括 default、best_compression、ZSTD 和 index.source_reuse。其中,ZSTD 和 index.source_reuse 是新引入的压缩策略,能进一步降低索引膨胀率。

带来的好处

降低存储成本:显著降低的存储大小意味着在硬件和维护方面的成本将大幅度减少。 提高系统扩展性:更小的数据尺寸意味着在相同的硬件配置下,系统能够处理更多的数据。 数据备份和传输:由于索引文件更小,数据备份和传输的速度也将提升,同时减少带宽需求。

总结

Easysearch 在压缩效果上有显著提升,不仅降低了存储成本,还提高了查询性能和系统扩展性。这使得 Easysearch 在大数据环境下成为一种非常具有吸引力的搜索和存储解决方案

关于 Easysearch

about easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。 与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://www.infinilabs.com/docs/latest/easysearch

下载地址:https://www.infinilabs.com/download

原文:https://www.infinilabs.com/blog/2023/significant-increase-in-Easysearch-compression-from-8.7GB-to-1.4GB/

继续阅读 »

引言

在海量数据的存储和处理中,索引膨胀率是一个不可忽视的关键指标。它直接影响了存储成本和查询性能。近期,Easysearch 在这方面取得了显著的进展,其压缩功能的效果远超过了之前的版本。本文将详细介绍这一进展。

Easysearch 各版本压缩性能对比

根据之前文章的数据,Easysearch v1.1 在处理相同数据时,其索引大小比 Elasticsearch v6.4.3 降低了 50%。但这还不是全部,最新的测试数据更是令人惊艳。

显著的压缩效果:实验数据解析

通过对比不同版本的存储大小,我们更直观地了解到 Easysearch 在压缩方面的优势:

  • Easysearch 的原始版本,未开启压缩:存储大小为 8.7 GB。
  • Easysearch v2 版本:经过第二版压缩后,存储大小显著减少到 2.7 GB。
  • Easysearch v3 版本:第三版压缩后,存储大小进一步减少到 1.4 GB。

关键观察

Easysearch 之前提供的压缩版相比原始版本减少了约 69%的存储空间。

Easysearch v3 版则更为显著,相比原始版本减少了约 84%的存储空间。

第三版本压缩的秘密武器:数字类型字段的复用

第三版本压缩能达到如此高的效率,主要是因为在之前第二版对文档原文中 keyword 类型字段复用的基础上,增加了对数字类型字段的复用。这一策略进一步优化了存储结构,显著提高了压缩效率。

压缩策略:多元化选择

Easysearch 提供了多种压缩策略,包括 default、best_compression、ZSTD 和 index.source_reuse。其中,ZSTD 和 index.source_reuse 是新引入的压缩策略,能进一步降低索引膨胀率。

带来的好处

降低存储成本:显著降低的存储大小意味着在硬件和维护方面的成本将大幅度减少。 提高系统扩展性:更小的数据尺寸意味着在相同的硬件配置下,系统能够处理更多的数据。 数据备份和传输:由于索引文件更小,数据备份和传输的速度也将提升,同时减少带宽需求。

总结

Easysearch 在压缩效果上有显著提升,不仅降低了存储成本,还提高了查询性能和系统扩展性。这使得 Easysearch 在大数据环境下成为一种非常具有吸引力的搜索和存储解决方案

关于 Easysearch

about easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。 与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://www.infinilabs.com/docs/latest/easysearch

下载地址:https://www.infinilabs.com/download

原文:https://www.infinilabs.com/blog/2023/significant-increase-in-Easysearch-compression-from-8.7GB-to-1.4GB/

收起阅读 »