Elasticsearch
极限科技(INFINI Labs)招聘:搜索运维工程师(Elasticsearch/Easysearch)【北京/全职】
求职招聘 • INFINI Labs 小助手 发表了文章 • 0 个评论 • 5528 次浏览 • 2024-09-28 11:00
我们是国内搜索型数据库产品厂商第一梯队的杰出代表,随着业务的快速发展,现开放岗位:搜索运维工程师( Elasticsearch/Easysearch ),如果有兴趣,请直接拉到文末,扫描二维码或将简历投递至 hello@infini.ltd。
如果您还不了解 极限科技(INFINI Labs)是谁,在做什么,需要什么样的小伙伴,那么请看下文:
我们是谁
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
我们在做什么
极限科技(INFINI Labs)正在致力于以下几个核心方向:
1、开发近实时搜索引擎 INFINI Easysearch
INFINI Easysearch 是一个分布式的搜索型数据库,实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch,同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。详情参见:https://infinilabs.cn
2、打造下一代实时搜索引擎 INFINI Pizza
INFINI Pizza 是一个分布式混合搜索数据库系统。我们的使命是充分利用现代硬件和人工智能的潜力,为企业提供量身定制的实时智能搜索体验。我们致力于满足具有挑战性的环境中高并发和高吞吐量的需求,同时提供无缝高效的搜索功能。详情参见:https://pizza.rs
3、积极参与全球开源生态建设
通过开源项目和社区贡献,推动全球开源技术的发展,提升中国在全球开源领域的影响力。
4、提供专业服务
为客户提供包括搜索技术支持、迁移服务、定制解决方案和培训在内的全方位服务。
5、提供国产化搜索解决方案
针对中国市场的特殊需求,提供符合国产化标准的搜索产品和解决方案,帮助客户解决使用 Elasticsearch 时遇到的挑战。
极限科技(INFINI Labs)通过这些努力,旨在成为全球领先的实时搜索和数据分析解决方案提供商。
我们期待有才华、有激情的你加入我们,一起探索数据搜索的未来,共同创造无限可能!
在招岗位介绍
岗位名称
搜索运维工程师(Elasticsearch/Easysearch)
岗位职责
- 负责客户现场的 Elasticsearch/Easysearch/OpenSearch 搜索引擎集群的日常维护、监控和优化,确保集群的高可用性和性能稳定;
- 协助客户进行搜索引擎集群的部署、配置及版本升级;
- 排查和解决 Elasticsearch/Easysearch/OpenSearch 集群中的各种技术问题,及时响应并处理集群异常;
- 根据业务需求设计和实施搜索索引的调优、数据迁移和扩展方案;
- 负责与客户沟通,提供技术支持及相关培训,确保客户需求得到有效满足;
- 制定并实施搜索引擎的备份、恢复和安全策略,保障数据安全;
- 与内部研发团队和外部客户进行协作,推动集群性能改进和功能优化。
岗位要求
- 全日制本科及以上学历,5 年以上运维工作经验;
- 拥有 Elasticsearch/Easysearch/OpenSearch 使用经验,熟悉搜索引擎的原理、架构和相关生态工具(如 Logstash、Kibana 等);
- 熟悉 Linux 操作系统的使用及常见性能调优方法;
- 熟练掌握 Shell 或 Python 等至少一种脚本语言,能够编写自动化运维脚本;
- 具有优秀的问题分析与解决能力,能够快速应对突发情况;
- 具备良好的沟通能力和团队合作精神,能够接受 客户驻场工作;
- 全职,北京地区,需具备在北京长期工作的条件;
优先考虑
- 计算机科学、信息技术或相关专业;
- 具备丰富的大规模分布式系统运维经验;
- 熟悉 Elasticsearch/Easysearch/OpenSearch 分片、路由、查询优化等高级功能;
- 拥有 Elastic Certified Engineer 认证;
- 具备大规模搜索引擎集群设计、扩展和调优经验;
- 熟悉其他搜索引擎技术(如 Solr、Lucene)者优先 ;
- 熟悉大数据处理相关技术(比如: Kafka 、Flink 等)者优先。
福利待遇
- 月薪: 15K - 25K,具体根据能力而定,试用期为 3-6 个月;
- 福利:五险一金/双休/国内法定假日/带薪年假等;
简历投递
简历投递:hello@infini.ltd(邮件标题请备注姓名+求职岗位+来自搜索客社区)
微信联系:INFINI-Labs(加微请备注求职岗位+来自搜索客社区)
欢迎有兴趣的小伙伴联系或推荐,期待您的加入!
Elastic 宣布修改开源协议为 AGPL:Elasticsearch 再次成为开源软件
Elasticsearch • searchkit 发表了文章 • 0 个评论 • 4783 次浏览 • 2024-08-30 11:26
今日快讯!就在刚刚,开源搜索领域行业巨头 Elastic 官方博客发表了一篇最新公告《Elasticsearch is Open Source, Again》,Elastic 创始人& CTO Shay Banon 宣布 Elasticsearch 和 Kibana 许可证协议修改为 AGPL。
以下为搜索客社区从 Elastic 官方博客翻译的原文内容:
Elasticsearch 再次成为开源软件
[D.N.A] Elasticsearch 和 Kibana 现在可以再次被称为开源软件了。这句话让我感到无比的兴奋。真的忍不住跳起来庆祝!我们所有在 Elastic 的人都很高兴。开源精神是我的DNA,也是 Elastic 的DNA。能够再次称 Elasticsearch 为开源软件,真的是一种纯粹的快乐。
[LOVE.] 简而言之,我们将在接下来的几周内,除了 ELv2 和 SSPL 之外,增加 AGPL 作为另一个许可选项。在更改许可后,我们从未停止过像一个开源社区一样相信和行动。但通过使用 AGPL 这一获得开放源码促进会(OSI)批准的许可,消除了人们可能存在的任何疑问或混淆。
[Not Like Us] 我们在 Elastic 从未停止过对开源的信仰。我个人对开源的信仰也从未动摇,至今已有 25 年了。那么为什么三年前我们要做出改变呢?我们遇到了与 AWS 相关的问题,以及他们的服务引发的市场混乱。在尝试了所有能想到的其他选项后,我们更改了许可协议,明知道这会导致 Elasticsearch 被分叉成另一个名称并走上不同的发展轨迹。这是一个漫长的故事。
[Like That] 好消息是,虽然过程痛苦,但结果奏效了。三年后,亚马逊已经完全投入到了他们的分叉项目中,市场的混乱(大部分)得到了缓解,我们与 AWS 的合作伙伴关系比以往更强。我们甚至被评为 AWS 的年度合作伙伴。我一直希望时间能过去得足够久,以至于我们可以安全地回到开源项目的状态——现在终于到了。
[All The Stars] 我们希望尽可能简化用户的使用体验。我们有用户非常喜欢 ELv2(一个受 BSD 启发的许可)。我们也有用户已经批准使用 SSPL(通过 MongoDB 使用)。这就是为什么我们只是增加了一个选项,而不是移除任何东西。如果你已经在使用并喜欢 Elasticsearch,请继续使用,没有任何变化。对于其他人,现在你也可以选择使用 AGPL。
[LOYALTY.] 我们选择 AGPL 而不是其他许可,是因为我们希望通过与 OSI 的合作,能在开源许可领域创造更多的选项。随着我们更改许可以来的发展(例如 Grafana 从 Apache2 转移到 AGPL),也许 AGPL 已经足够适用于像我们这样的基础设施软件了。我们致力于找到最合适的解决方案。
[euphoria] 我非常高兴能够再次称 Elasticsearch 为开源软件。
[Alright] 任何改变都可能引发混淆,当然也可能引来一些网络喷子。(网络喷子总是存在的,对吧?)让我们愉快地回答一些可能出现的问题吧。我可以想象到的一些问题如下,但我们会继续补充。
“更改许可是个错误,Elastic 现在在回撤”:我们在三年前更改许可时消除了很多市场混乱。由于我们的行动,很多事情已经改变。现在是一个完全不同的市场环境。我们不生活在过去。我们希望为用户打造一个更好的未来。正是因为我们当时采取了行动,现在我们才有能力采取新的行动。
“AGPL 不是真正的开源许可,X 才是”:AGPL 是获得 OSI 批准的许可,并且被广泛采用。例如,MongoDB 曾经使用 AGPL,Grafana 现在也是 AGPL。这表明 AGPL 并不影响使用或流行度。我们选择 AGPL 是因为我们认为这是与 OSI 一起为世界开辟更多开源道路的最佳方式,而不是减少开源。
“Elastic 更改许可是因为他们表现不好”:我要说的是,我今天对 Elastic 的未来依然充满期待。我为我们的产品和团队的执行力感到无比自豪。我们发布了无状态的 Elasticsearch ES|QL 和大量用于 GenAI 用例的向量数据库/混合搜索改进。我们在日志记录和可观察性方面大力投入 OTel。我们的安全产品 SIEM 不断添加令人惊叹的功能,并且是市场上增长最快的产品之一。用户的反应让我们感到非常谦卑。股市总有起伏,但我可以向你保证,我们始终着眼于长远发展,而这次的变更就是其中的一部分。
如果我们看到更多问题,会在上面继续添加,以期减少混淆。
[HUMBLE.] 为未来而构建真是令人兴奋。Elasticsearch 回归开源。万岁!这真是一件美妙的事情。今天真是美好的一天。
Forever :elasticheart: Open Source
Shay 2024-08-30
原文地址:https://www.elastic.co/blog/elasticsearch-is-open-source-again/
社区热评
Elasticsearch 再次回归开源的消息迅速引发了技术社区的广泛关注。这不仅是 Elastic 对自身开源信念的重申,也是其在激烈市场竞争中精心策划的一次战略调整。
三年前,Elastic 因与 AWS 的市场竞争而选择更改许可协议,这一决定在当时引发了不小的争议。尽管如此,事实证明,这一策略有效地减少了市场上的混淆,也为 Elastic 与 AWS 的合作奠定了更坚实的基础。如今,Elastic 再度选择开源,并新增 AGPL 作为许可选项,这一举措无疑展现了 Elastic 在市场中更加成熟的定位和对未来发展的自信。
这一变化不仅仅是一个公司的商业决策,更是开源生态系统的一次重要信号。Elastic 的回归开源,传递出一个明确的信息:即使在商业竞争中,开源仍然是企业实现长远发展的重要路径。随着这一决定的落地,其他软件公司可能也会重新审视自身的许可策略,推动更多开源项目的发展与创新。
此外,Elastic 选择 AGPL 作为新许可选项,也显示出其对开源生态未来走向的深刻洞察。AGPL 的引入,表明 Elastic 希望在开源社区中保持灵活性和多样性,同时推动整个行业向更加开放和透明的方向迈进。
总体而言,Elastic 重返开源的举动,不仅意在巩固其在开源社区中的地位,也为行业树立了一个新的标杆。这一事件无疑将成为开源软件发展史上的重要篇章,未来可能会激发更多企业重新考虑其开源战略,进而推动整个技术行业的进一步繁荣与进步。
让我们拭目以待!
Elasticsearch 磁盘空间异常:一次成功的故障排除案例分享
Elasticsearch • INFINI Labs 小助手 发表了文章 • 0 个评论 • 3620 次浏览 • 2024-08-09 00:18
故障现象
近日有客户找到我们,说有个 ES 集群节点,磁盘利用率达到了 82% ,而其节点才 63% ,想处理下这个节点,降低节点的磁盘利用率。
起初以为是没有打开自动平衡导致的,经查询,数据还是比较平衡的。 利用率较高的是 76 节点,如果 76 节点的分片比其他节点多,好像还比较合乎逻辑,但它反而比其他节点少了 12-15 个分片。那是 76 节点上的分片比较大?
索引情况
图中都是较大的索引,1 个索引 25TB 左右,共 160 个分片。
分片大小
节点 64 节点 77 节点 75 问题节点 76 可以看出分片大小没有出现较大的倾斜,分片大小和数据平衡的原因都被排除。
换个方向思考,节点 76 比其他节点多使用了磁盘空间 8 个 TB 左右,集群最大分片大小约 140GB ,8000/140=57 ,即节点 76 至少要比其他节点多 57 个分片才行,啊这...
会不会有其他的文件占用了磁盘空间?
我们登录到节点主机,排查是否有其他文件占用了磁盘空间。
结果:客户的数据路径是单独的数据磁盘,并没有其他文件,都是 ES 集群索引占用的空间。
现象总结
分片大小差不多的情况下,节点 76 的分片数还比别的节点还少 10 个左右,它的磁盘空间反而多占用了 8TB 。
这是不是太奇怪了?事出反常必有妖,继续往下查。
原因定位
通过进一步排查,我们发现节点 76 上有一批索引目录,在其他的节点上没有,而且也不在 GET \_cat/indices?v
命令的结果中。说明这些目录都是 dangling 索引占用的。
dangling 索引产生的原因
当 Elasticsearch 节点脱机时,如果删除的索引数量超过 Cluster.indes.tombstones.size
,就会发生这种情况。
解决方案
通过命令删除 dangling 索引:
DELETE /\_dangling/<index-uuid>?accept_data_loss=true
最后
这次的分享就到这里了,欢迎与我一起交流 ES 的各种问题和解决方案。
关于极限科技(INFINI Labs)
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
【第2期】2024 搜索客 Meetup | Elasticsearch 的代码结构和写入查询流程的解读
活动 • searchkit 发表了文章 • 0 个评论 • 2858 次浏览 • 2024-08-06 11:47
本次活动由 搜索客社区、极限科技(INFINI Labs)联合举办,活动主题将深入探讨 Elasticsearch 的两个核心方面:代码结构以及写入和查询的关键流程。本次活动将为 Elasticsearch 初学者和有经验的用户提供宝贵的见解,欢迎大家报名参加、交流学习。
活动主题:Elasticsearch 的代码结构和写入查询流程的解读
活动时间:2024 年 8 月 14 日 19:00-20:00(周三)
活动形式:微信视频号(极限实验室)直播
报名方式:关注或扫码海报中的二维码进行预约
嘉宾介绍
张磊,极限科技搜索引擎研发负责人,对 Elasticsearch 和 Lucene 源码比较熟悉,目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。
主题摘要
本次分享将探讨 Elasticsearch 的代码结构及其写入和查询流程。内容包括:项目架构、核心模块、插件系统,以及文档索引和查询的各个阶段与分布式查询协调。
活动亮点
-
深入解析 Elasticsearch 代码结构:
- 项目的整体结构:了解 Elasticsearch 项目的组织方式。
- 核心模块及其职责:学习 Elasticsearch 的核心模块及其在系统中的具体角色。
- 插件系统的设计:探索 Elasticsearch 灵活的插件系统设计及其扩展方式。
-
详细解读 Elasticsearch 写入和查询流程:
- 文档索引过程的各个阶段:跟随文档从初始接收至最终存储的索引过程。
- 查询解析和执行的步骤:理解 Elasticsearch 中查询解析和执行的各个步骤。
- 分布式查询的协调过程:学习 Elasticsearch 如何在分布式架构中协调查询,以提供高效且准确的搜索结果。
参与有奖
直播中将设有福袋抽奖环节,参与就有机会获得 INFINI Labs 周边纪念品,包括 T 恤、鸭舌帽、咖啡杯、指甲刀套件等等(图片仅供参考,款式、颜色与尺码随机)。
活动交流
活动交流群二维码 7 天内(8 月 12 日前)有效,如过期请添加小助手微信拉群。
本次 Meetup 是深入了解 Elasticsearch 内部工作机制、提升使用技能的绝佳机会。不要错过!
Meetup 讲师招募
搜索客社区 Meetup 的成功举办,离不开社区小伙伴的热情参与。目前社区讲师招募计划也在持续进行中,我们诚挚邀请各位技术大咖、行业精英踊跃提交演讲议题,与大家分享您的经验。
讲师报名链接:http://cfp.searchkit.cn
或扫描下方二维码,立刻报名成为讲师!
Meetup 活动聚焦 AI 与搜索领域的最新动态,以及数据实时搜索分析、向量检索、技术实践与案例分析、日志分析、安全等领域的深度探讨。
我们热切期待您的精彩分享!
往期回顾
【第 1 期】2024 搜索客 Meetup | Easysearch 结合大模型实现 RAG
关于 搜索客(SearchKit)社区
搜索客社区由 Elasticsearch 中文社区进行全新的品牌升级,以新的 Slogan:“搜索人自己的社区” 为宣言。汇集搜索领域最新动态、精选干货文章、精华讨论、文档资料、翻译与版本发布等,为广大搜索领域从业者提供更为丰富便捷的学习和交流平台。社区官网:https://searchkit.cn 。
Easysearch、Elasticsearch、Amazon OpenSearch 快照兼容对比
Easysearch • INFINI Labs 小助手 发表了文章 • 2 个评论 • 2483 次浏览 • 2024-07-29 11:54
在当今的数据驱动时代,搜索引擎的快照功能在数据保护和灾难恢复中至关重要。本文将对 Easysearch、Elasticsearch 和 Amazon OpenSearch 的快照兼容性进行比较,分析它们在快照创建、恢复、存储格式和跨平台兼容性等方面的特点,帮助大家更好地理解这些搜索引擎的差异,从而选择最适合自己需求的解决方案。
启动集群
Easysearch
服务器一般情况下默认参数都是很低的,而 Easysearch/Elasticsearch 是内存大户,所以就需要进行系统调优。
sysctl -w vm.max_map_count=262144
vm.max_map_count
是一个 Linux 内核参数,用于控制单个进程可以拥有的最大内存映射区域(VMA,Virtual Memory Areas)的数量。内存映射区域是指通过内存映射文件或匿名内存映射创建的虚拟内存区域。
这个参数在一些应用程序中非常重要,尤其是那些需要大量内存映射的应用程序,比如 Elasticsearch。Elasticsearch 使用内存映射文件来索引和搜索数据,这可能需要大量的内存映射区域。如果 vm.max_map_count
设置得太低,Elasticsearch 可能无法正常工作,并会出现错误信息。
调整 vm.max_map_count
参数的一些常见原因:
-
支持大型数据集: 应用程序(如 Elasticsearch)在处理大型数据集时可能需要大量内存映射区域。增加
vm.max_map_count
可以确保这些应用程序有足够的内存映射区域来处理数据。 -
防止内存错误: 如果
vm.max_map_count
设置得太低,当应用程序尝试创建超过限制的内存映射时,会出现错误,导致应用程序崩溃或无法正常工作。 - 优化性能:
适当地设置
vm.max_map_count
可以优化应用程序的性能,确保内存映射操作顺利进行。
检查当前的 vm.max_map_count
值:
sysctl vm.max_map_count
或者查看 /proc/sys/vm/max_map_count
文件:
cat /proc/sys/vm/max_map_count
Elasticsearch 官方建议将 vm.max_map_count
设置为至少 262144。对于其他应用程序。
Easysearch 具体安装步骤见 INFINI Easysearch 尝鲜 Hands on
Amazon OpenSearch
使用 Amazon Web Services 控制台进行创建。
Elasticsearch
使用如下 docker compose 部署一个三节点的 ES 集群:
version: "2.2"
services:
es01:
image: docker.elastic.co/elasticsearch/elasticsearch:7.10.2
container_name: es01
environment:
- node.name=es01
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es02,es03
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- data01:/usr/share/elasticsearch/data
ports:
- 9200:9200
networks:
- elastic
es02:
image: docker.elastic.co/elasticsearch/elasticsearch:7.10.2
container_name: es02
environment:
- node.name=es02
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es01,es03
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- data02:/usr/share/elasticsearch/data
networks:
- elastic
es03:
image: docker.elastic.co/elasticsearch/elasticsearch:7.10.2
container_name: es03
environment:
- node.name=es03
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es01,es02
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- data03:/usr/share/elasticsearch/data
networks:
- elastic
volumes:
data01:
driver: local
data02:
driver: local
data03:
driver: local
networks:
elastic:
driver: bridge
由于这个 docker compose 没有关于 kibana 的配置,所以我们还是用 Console 添加原生的 Elasticsearch 集群!
集群信息
快照还原的步骤
快照前的准备
插件安装
本次测试选择把索引快照备份到 Amazon S3,所以需要使用 S3 repository plugin,这个插件添加了对使用 Amazon S3 作为快照/恢复存储库的支持。
Easysearch 和 OpenSearch 集群自带了这个插件,所以无需额外安装。
对于自己部署的三节点 Elasticsearch 则需要进入每一个节点运行安装命令然后再重启集群,建议使用自动化运维工具来做这步,安装命令如下:
sudo bin/elasticsearch-plugin install repository-s3
如果不再需要这个插件,可以这样删除。
sudo bin/elasticsearch-plugin remove repository-s3
由于需要和 Amazon Web Services 打交道,所以我们需要设置 IAM 凭证,这个插件可以从 EC2 IAM instance profile,ECS task role 以及 EKS 的 Service account 读取相应的凭证。
对于托管的 Amazon OpenSearch 来说,我们无法在托管的 EC2 上绑定我们的凭证,所以需要新建一个 OpenSearchSnapshotRole,然后通过当前的用户把这个角色传递给服务,也就是我们说的 IAM:PassRole。
创建 OpenSearchSnapshotRole,策略如下:
{
"Version": "2012-10-17",
"Statement": [{
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::bucket-name"
]
},
{
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::bucket-name/*"
]
}
]
}
信任关系如下:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "es.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
然后在我们的 IAM user 上加上 PassRole 的权限,这样我们就可以把 OpenSearchSnapshotRole 传递给 OpenSearch 集群。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/OpenSearchSnapshotRole"
}
]
}
注册存储库
在源集群执行注册
PUT /_snapshot/snapshot-repo-name
{
"type": "s3",
"settings": {
"bucket": "<bucket-name>",
"base_path": "<bucket-prefix>",
在目标集群同样执行这个语句,为了防止覆盖源集群存储库的数据,将 "readonly": true 添加到"settings" PUT 请求中,这样就只有一个集群具有对存储库的写入权限。
PUT /_snapshot/snapshot-repo-name
{
"type": "s3",
"settings": {
"bucket": "<bucket-name>",
"base_path": "<bucket-prefix>",
"readonly": true,
对于 OpenSearch 来说,还需要执行 passrole,所以还需要添加role_arn这个字段,由于 IAM:PassRole 需要对 HTTP 请求做 signV4 日签名,所以这部常常使用 Postman 来完成。把角色传递过去之后,接下来的快照还原操作就可以在 OpenSearch Dashboard 中进行操作了。
需要注意的是,需要在 auth 这里输入 AccessKey,SecretKey,AWS Region,Service Name(es)来做 SignV4 的签名。
请求体如下:
{
"type": "s3",
"settings": {
"bucket": "<bucket-name>",
"base_path": "<bucket-prefix>",
"readonly": true,
"role_arn": "arn:aws:iam::123456789012:role/OpenSearchSnapshotRole"
}
}
- 查看所有注册的存储库:
GET _snapshot
:这个命令返回所有已注册的快照存储库列表及其基本信息。
GET _snapshot
{
"es_repository": {
"type": "s3",
"settings": {
"bucket": "your-s3-bucket-name",
"region": "your-s3-bucket-region"
}
}
}
- 查看特定存储库的详细信息:
GET _snapshot/es_repository
:这个命令返回名为es_repository
的存储库的详细配置信息,包括存储桶名称、区域和其他设置。
GET _snapshot/es_repository
{
"es_repository": {
"type": "s3",
"settings": {
"bucket": "your-s3-bucket-name",
"region": "your-s3-bucket-region",
"access_key": "your-access-key",
"secret_key": "your-secret-key"
}
}
}
- 查看特定存储库中的快照:
GET _cat/snapshots/es_repository?v
:这个命令返回es_repository
存储库中的所有快照及其详细信息,包括快照 ID、状态、开始时间、结束时间、持续时间、包含的索引数量、成功和失败的分片数量等。
GET _cat/snapshots/es_repository?v
id status start_epoch start_time end_epoch end_time duration indices successful_shards failed_shards total_shards
snapshot_1 SUCCESS 1628884800 08:00:00 1628888400 09:00:00 1h 3 10 0 10
snapshot_2 SUCCESS 1628971200 08:00:00 1628974800 09:00:00 1h 3 10 0 10
创建索引快照
# PUT _snapshot/my_repository/<my_snapshot_{now/d}>
PUT _snapshot/my_repository/my_snapshot
{
"indices": "my-index,logs-my_app-default",
}
根据快照的大小不同,完成快照可能需要一些时间。默认情况下,create snapshot API 只会异步启动快照过程,该过程在后台运行。要更改为同步调用,可以将 wait_for_completion
查询参数设置为 true
。
PUT _snapshot/my_repository/my_snapshot?wait_for_completion=true
另外还可以使用 clone snapshot API 克隆现有的快照。要监控当前正在运行的快照,可以使用带有 _current
请求路径参数的 get snapshot API。
GET _snapshot/my_repository/_current
如果要获取参与当前运行快照的每个分片的完整详细信息,可以使用 get snapshot status API。
GET _snapshot/_status
成功创建快照之后,就可以在 S3 上看到备份的数据块文件,这个是正确的快照层级结构:
需要注意的是, "base_path": "
所以在 Open Search 中还原 Elasticsearch 就遇到了这个问题:
{
"error": {
"root_cause": [
{
"type": "snapshot_missing_exception",
"reason": "[easy_repository:2/-jOQ0oucQDGF3hJMNz-vKQ] is missing"
}
],
"type": "snapshot_missing_exception",
"reason": "[easy_repository:2/-jOQ0oucQDGF3hJMNz-vKQ] is missing",
"caused_by": {
"type": "no_such_file_exception",
"reason": "Blob object [11111/indices/7fv2zAi4Rt203JfsczUrBg/meta-YGnzxZABRBxW-2vqcmci.dat] not found: The specified key does not exist. (Service: S3, Status Code: 404, Request ID: R71DDHX4XXM0434T, Extended Request ID: d9M/HWvPvMFdPhB6KX+wYCW3ZFqeFo9EoscWPkulOXWa+TnovAE5PlemtuVzKXjlC+rrgskXAus=)"
}
},
"status": 404
}
恢复索引快照
POST _snapshot/my_repository/my_snapshot_2099.05.06/_restore
{
"indices": "my-index,logs-my_app-default",
}
各个集群的还原
-
Elasticsearch 7.10.2 的快照可以还原到 Easysearch 和 Amazon OpenSearch
- 从 Easysearch 1.8.2 还原到 Elasticsearch 7.10.2 报错如下:
{
"error": {
"root_cause": [
{
"type": "snapshot_restore_exception",
"reason": "[s3_repository:1/a2qV4NYIReqvgW6BX_nxxw] cannot restore index [my_indexs] because it cannot be upgraded"
}
],
"type": "snapshot_restore_exception",
"reason": "[s3_repository:1/a2qV4NYIReqvgW6BX_nxxw] cannot restore index [my_indexs] because it cannot be upgraded",
"caused_by": {
"type": "illegal_state_exception",
"reason": "The index [[my_indexs/ALlTCIr0RJqtP06ouQmf0g]] was created with version [1.8.2] but the minimum compatible version is [6.0.0-beta1]. It should be re-indexed in Elasticsearch 6.x before upgrading to 7.10.2."
}
},
"status": 500
}
- 从 Amazon OpenSearch 2.1.3 还原到 Elasticsearch 7.10.2 报错如下(无论是否开启兼容模式):
{
"error": {
"root_cause": [
{
"type": "snapshot_restore_exception",
"reason": "[aos:2/D-oyYSscSdCbZFcmPZa_yg] the snapshot was created with Elasticsearch version [36.34.78-beta2] which is higher than the version of this node [7.10.2]"
}
],
"type": "snapshot_restore_exception",
"reason": "[aos:2/D-oyYSscSdCbZFcmPZa_yg] the snapshot was created with Elasticsearch version [36.34.78-beta2] which is higher than the version of this node [7.10.2]"
},
"status": 500
}
- 从 Easysearch 1.8.2 还原到 Amazon OpenSearch2.13 报错如下(无论是否开启兼容模式):
{
"error": {
"root_cause": [
{
"type": "snapshot_restore_exception",
"reason": "[easy_repository:2/LE18AWHlRJu9rpz9BJatUQ] cannot restore index [my_indexs] because it cannot be upgraded"
}
],
"type": "snapshot_restore_exception",
"reason": "[easy_repository:2/LE18AWHlRJu9rpz9BJatUQ] cannot restore index [my_indexs] because it cannot be upgraded",
"caused_by": {
"type": "illegal_state_exception",
"reason": "The index [[my_indexs/VHOo7yfDTRa48uhQvquFzQ]] was created with version [1.8.2] but the minimum compatible version is OpenSearch 1.0.0 (or Elasticsearch 7.0.0). It should be re-indexed in OpenSearch 1.x (or Elasticsearch 7.x) before upgrading to 2.13.0."
}
},
"status": 500
}
- Amazon OpenSearch 还原到 Easysearch 同样失败
{
"error": {
"root_cause": [
{
"type": "snapshot_restore_exception",
"reason": "[aoss:2/D-oyYSscSdCbZFcmPZa_yg] cannot restore index [aos] because it cannot be upgraded"
}
],
"type": "snapshot_restore_exception",
"reason": "[aoss:2/D-oyYSscSdCbZFcmPZa_yg] cannot restore index [aos] because it cannot be upgraded",
"caused_by": {
"type": "illegal_state_exception",
"reason": "The index [[aos/864WjTAXQCaxJ829V5ktaw]] was created with version [36.34.78-beta2] but the minimum compatible version is [6.0.0]. It should be re-indexed in Easysearch 6.x before upgrading to 1.8.2."
}
},
"status": 500
}
- Elasticsearch 8.14.3 迁移到 Amazon OpenSearch 或者 Elasticsearch 都是有这个报错:
{
"error": {
"root_cause": [
{
"type": "parsing_exception",
"reason": "Failed to parse object: unknown field [uuid] found",
"line": 1,
"col": 25
}
],
"type": "repository_exception",
"reason": "[snap] Unexpected exception when loading repository data",
"caused_by": {
"type": "parsing_exception",
"reason": "Failed to parse object: unknown field [uuid] found",
"line": 1,
"col": 25
}
},
"status": 500
}
这是由于 Elasticsearch 8 在创建快照的时候会默认加上一个 UUID 的字段,所以我们低版本的 Easysearch、Amazon OpenSearch 中会找不到这个字段,在执行GET _cat/snapshots/snap?v
的时候就报错,及时在注册存储库的时候显示加上 UUID 的字段也无事无补。
{
"snapshot-repo-name": {
"type": "s3",
"uuid": "qlJ0uqErRmW6aww2Fyt4Fg",
"settings": {
"bucket": "<bucket-name>",
"base_path": "<bucket-prefix>",
}
},
以下是兼容性对比,每行第一列代表源集群,第一行代表目标集群:
快照兼容对比 | Easysearch 1.8.2 | Elasticsearch 7.10.2 | OpenSearch 2.13 |
---|---|---|---|
Easysearch 1.8.2 | 兼容 | 不兼容 | 不兼容 |
Elasticsearch 7.10.2 | 兼容 | 兼容 | 兼容 |
OpenSearch 2.13 | 不兼容 | 不兼容 | 兼容 |
Elasticsearch 的兼容列表官方的列表如下:
参考文献
-
开始使用 Elastic Stack 和 Docker Compose:第 1 部分
https://www.elastic.co/cn/blog/getting-started-with-the-elastic-stack-and-docker-compose -
Docker Compose 部署多节点 Elasticsearch
https://www.elastic.co/guide/en/elasticsearch/reference/7.10/docker.html#docker-compose-file -
repository-s3 教程
https://www.elastic.co/guide/en/elasticsearch/reference/8.14/repository-s3.html
https://www.elastic.co/guide/en/elasticsearch/plugins/7.10/repository-s3.html -
snapshot-restore
https://www.elastic.co/guide/en/elasticsearch/reference/7.10/snapshot-restore.html -
在亚马逊 OpenSearch 服务中创建索引快照
https://docs.amazonaws.cn/zh_cn/opensearch-service/latest/developerguide/managedomains-snapshots.html#managedomains-snapshot-restore - 教程:迁移至 Amazon OpenSearch Service
https://docs.amazonaws.cn/zh_cn/opensearch-service/latest/developerguide/migration.html
关于 Easysearch 有奖征文活动
无论你是 Easysearch 的老用户,还是第一次听说这个名字,只要你对 INFINI Labs 旗下的 Easysearch 产品感兴趣,或者是希望了解 Easysearch,都可以参加这次活动。
详情查看:Easysearch 征文活动
作者:韩旭,亚马逊云技术支持,亚马逊云科技技领云博主,目前专注于云计算开发和大数据领域。
从 OpenAI 停服看中国市场:国产替代崛起的机遇与挑战
Easysearch • INFINI Labs 小助手 发表了文章 • 0 个评论 • 2535 次浏览 • 2024-07-05 11:50
一、OpenAI 停服事件背景
OpenAI 自 2020 年推出 GPT-3 以来,在全球范围内引起了极大的反响。其强大的自然语言处理能力使其成为许多企业和开发者的首选工具。然而,2024 年 6 月 25 日,许多中国用户收到了一封来自 OpenAI 的邮件,邮件中明确表示,自 2024 年 7 月 9 日起,OpenAI 将停止对中国内地和香港地区提供 API 服务。
这一事件引发了国内开发者和企业的广泛讨论,特别是在人工智能技术应用逐渐深入的背景下,OpenAI 的停服无疑会对中国市场产生一定的影响。在 AI 技术迅猛发展的当下,许多中国企业和开发者依赖 OpenAI 的 API 进行各种应用的开发。尤其是在大模型技术领域,不少初创公司通过“套壳”OpenAI 技术快速推向市场。所谓“OpenAI 套壳”,是指一些公司仅对 OpenAI 的技术进行表面包装和小改动,而未进行深度创新 。OpenAI CEO 山姆·奥特曼曾明确指出,简单包装 OpenAI 技术的公司难以长久生存。此次 API 服务的终止,意味着这些企业需要寻找新的技术支持,或者在短时间内加速自主研发 。
二、国产替代的挑战与机遇
OpenAI 停止对中国提供 API 服务将对国内 AI 行业带来短期冲击,但从长远来看,这也可能成为推动国内 AI 技术自主创新和研发的契机。国内企业将被迫加大自主研发力度,减少对外部技术的依赖,从而推动国产 AI 技术的发展 。虽然目前国内大模型企业在技术上与 OpenAI 存在一定差距,但已有不少公司在不断赶超。例如,百度的文心大模型、科大讯飞的星火大模型以及清华智谱的 ChatGLM 基础模型,都在性能上逐渐逼近甚至超过了 GPT-4 。从现状来看,国内大模型厂商已经逐步进入了性能提升的关键期,应用场景从办公、生活拓展到医疗、工业、教育等领域。
三、Elasticsearch 国产化替代的需求
Elasticsearch(简称 ES)作为一种开源的分布式搜索和分析引擎,以其强大的搜索能力和高效的数据处理能力,广泛应用于各种大数据和搜索相关业务场景。然而,随着国际政治环境的变化和技术壁垒的加剧,依赖国外技术的风险日益凸显。在这种背景下,推动 Elasticsearch 的国产化替代至关重要,既能保障国家信息安全,也能促进国内技术自主创新和产业发展。
首先,依赖国外技术可能带来技术封锁风险,一旦国外企业因政治或经济原因停止服务,中国企业的业务连续性和数据安全性将受到威胁。推动国产化替代有助于规避这些风险,保障数据安全和业务的稳定运行。国外搜索引擎和数据库系统通常为西方市场优化,未必适合中国市场。例如,Elasticsearch 在处理中文信息时需要额外的插件和调整,而国产替代方案可以更好地适应本地化需求,同时确保数据存储和处理符合国家法律法规。
其次,推动 Elasticsearch 的国产化替代有助于激发国内企业的创新活力,减少对国外技术的依赖,提升在搜索和大数据领域的核心竞争力。采用国产替代方案不仅能够降低企业的技术成本,还能构建自主的技术生态系统,减少对外部的依赖。与此同时国产化替代也有助于提升国内技术人才水平,通过自主研发和技术创新培养出高水平的技术人才,推动技术创新和产业升级。
在性能和安全方面,Elasticsearch 在数据保护和性能方面存在不足。开源版本不具备数据保护功能,用户必须付费获得相关的安全功能。2021 年 Elastic 公司将其开源软件许可证变更为双授权许可,可能带来安全风险。此外,Elasticsearch 在数据读写性能和集群扩展上也存在技术挑战,进一步推动了国产替代的需求。
四、Easysearch:国产替代的优秀范例
在 OpenAI 退出中国市场的背景下,国产技术的重要性日益凸显。作为国产搜索引擎技术的代表,Easysearch 展示了强大的替代潜力。
Easysearch 是一款基于国内自主研发的高性能搜索引擎,其核心引擎基于开源的 Apache Lucene。与 Elasticsearch 相比,Easysearch 不仅提供了相当的功能,还进行了更具针对性的优化。
-
轻量级:Easysearch 的安装包小于 50MB,部署安装简单,适合企业快速上手。
-
跨平台支持:Easysearch 支持主流操作系统和 CPU 架构,兼容国产信创环境,确保多样化环境下的稳定运行。
-
高性能:Easysearch 针对不同的使用场景进行了优化,以更低的硬件成本提供更高的服务性能,从而实现降本增效。
-
安全增强:Easysearch 默认提供完整的企业级安全功能,支持 LDAP/AD 集成,能够对索引、文档和字段级别进行粒度化权限管控,确保数据的安全性和隐私性。
-
稳定可靠:Easysearch 修复了大量内核问题,解决了内存泄露、集群卡顿和查询缓慢等问题,经过严苛的业务环境考验,保证了其稳定性和可靠性。
- 简单易用:Easysearch 提供了企业级管理后台,运营标准化和自动化,使用户能够通过简单的页面操作实现专家级的运维管理工作。
Easysearch 特别注重数据安全和隐私保护,所有数据都在国内处理和存储,符合数据主权要求。这对关注数据安全和隐私的企业尤为重要,能够有效保障数据的安全性和合规性。
Easysearch 致力于构建一个开放的技术生态,通过丰富的开发者资源和支持,为国内开发者提供了一个强大的技术平台。
-
兼容性:Easysearch 兼容 Elasticsearch 的语法,支持 Elasticsearch 原有的 Query DSL 和 SQL 语法,并且兼容现有的 Elasticsearch SDK。这样,企业和开发者可以平滑地迁移到 Easysearch,无需修改现有代码。
-
中文适配:Easysearch 在功能上进行了中文适配,能够更好地支持中文搜索和分析,满足本地化需求。
-
功能增强:Easysearch 不断完善和增强企业级功能,使其在搜索业务场景中保持简洁与易用性,同时提升功能的丰富度和深度。
-
信创适配:Easysearch 支持信创环境,确保在国产环境中也能平稳运行和使用。
- 平滑迁移:Easysearch 基于网关实现了无缝的跨版本迁移与升级,用户可以随时安全回退,确保系统的持续稳定性。
Easysearch 作为国产搜索引擎技术的代表,展示了国产替代的强大潜力。通过自主研发和技术创新,Easysearch 不仅提供了强大的功能和性能,还确保了数据安全和隐私保护。它为国内企业和开发者提供了一个可靠的技术平台,推动了国产技术的发展和应用。未来,随着更多国产技术的崛起,中国将在全球技术领域占据更加重要的地位。
五、结束语
随着 OpenAI 服务在国内的终止,中国 AI 市场迎来了自主创新的机遇。国内企业如百度、科大讯飞等正加速自主研发,缩小技术差距。同时,在搜索引擎领域,极限科技推出 Easysearch 搜索引擎为 Elasticsearch 国产替代提供了新的选择。展望未来,国产技术的持续创新将助力中国在全球技术领域占据更重要的地位。
关于极限科技(INFINI Labs)
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
作者:Muses
【搜索客社区日报】第1853期 (2024-07-05)
社区日报 • Fred2000 发表了文章 • 0 个评论 • 2146 次浏览 • 2024-07-05 09:26
搜索型数据库的技术发展历程与趋势前瞻
资讯动态 • INFINI Labs 小助手 发表了文章 • 0 个评论 • 2610 次浏览 • 2024-06-26 13:13
概述
随着数字科技的飞速发展和信息量的爆炸性增长,搜索引擎已成为我们获取信息的首选途径之一,典型的代表厂商如 Google。然而,随着用户需求的不断演变,传统的搜索技术已经无法满足人们对信息的实时性、个性化和多样性的需求。
在企业内部,这种需求更加显著。随着企业数字化转型的持续深化,非结构化数据正日益成为各类组织数据增长的主要来源,也是数据体系中至关重要的组成部分,蕴含着巨大的价值。如何高效地存储和利用非结构化数据的重要性也日益凸显。企业需要更高效地管理和检索内部的海量数据,以支持业务决策和运营需求。
据 IDC 数据预计,到 2025 年,80%的数据将是非结构化数据;而根据 Gartner 的数据显示,从 2019 年到 2024 年,非结构化数据容量预计将增加两倍。然而,目前非结构化数据面临着表现形式多样、管理复杂性高、价值挖掘难度大等诸多挑战。传统的数据库系统往往无法满足企业对实时性和多样性的搜索需求,为了解决这些挑战,以自动分词、倒排索引、相关度计算、向量检索引擎等技术为核心构建的搜索型数据库应运而生。这些数据库自上世纪 90 年代诞生以来不断发展演进,正在成为数据库领域中不可或缺的一个重要分支。
什么是搜索型数据库?
搜索型数据库早期又称全文数据库,或者企业搜索引擎,是一种专门用于存储和管理大规模文本数据,并支持高效的文本搜索和信息检索的数据库系统,不过随着技术不断发展和应用场景日益丰富,目前搜索型数据库不仅仅可以处理长文本数据,也可以处理常见的数值、日期等结构化数据,IP、地理位置信息、图片、音视频等非结构化数据,搜索型数据库的应用范畴不断拓展,正在由支撑业务系统检索加速、IT 运维可观测性、聚合查询分析等向多场景、多模态数据搜索方向发展。
典型的搜索数据库一般具有以下特点:
- 灵活的索引能力:搜索数据库能够处理多种类型的数据,包括文本、图像、音频、视频等非结构化数据。它们采用自动分词、倒排索引等技术,能够高效地处理不同格式和类型的数据,提供灵活的搜索和检索功能。
- 高效的查询性能:搜索数据库具有高效的查询处理能力,能够快速索引和检索大规模的数据。借助优化的索引结构和查询算法,搜索数据库能够在短时间内准确地返回与查询相关的结果,提高用户的搜索效率,常用于解决关系型数据库的高并发检索需求。
- 支持复杂的搜索功能:搜索数据库提供多样化的搜索功能,包括全文检索、模糊搜索、精确搜索、范围搜索、向量搜索、地理信息检索等。用户可以根据不同的需求和场景,灵活地选择和组合不同的搜索功能,以获取符合期望的搜索结果。
- 高性能和可扩展性:搜索数据库具有高性能和可扩展性的特点,能够处理大规模数据和高并发访问。它们采用分布式架构和并行计算技术,实现了水平扩展,能够满足不断增长的数据量和用户访问量的需求。
综上所述,搜索数据库具有处理非结构化数据、实时搜索和更新、多样化的搜索功能、个性化推荐和智能搜索、高性能和可扩展性、全面的搜索结果展示等特点,是处理大规模数据和提供高效搜索服务的重要工具。
搜索型数据库的应用场景
搜索型数据库在各行各业都有广泛的应用,以下是一些典型的应用场景:
- 零售和电商:在零售和电商行业,搜索型数据库被广泛应用于产品搜索和推荐系统中。通过搜索功能,顾客可以轻松查找所需商品,而个性化推荐系统则可以根据用户的搜索历史和行为习惯推荐相关的产品,提高购物体验和交易转化率。
- 医疗保健:在医疗保健行业,搜索型数据库被用于医学文献检索、疾病诊断和药物搜索等方面。医生和研究人员可以利用搜索功能找到相关的医学文献和研究成果,帮助诊断疾病和制定治疗方案。
- 金融服务:在金融服务行业,搜索型数据库被用于金融数据检索、市场分析和投资决策等方面。投资者可以通过搜索功能查找相关的金融数据和市场资讯,帮助他们做出更加准确的投资决策。
- 制造业:在制造业中,搜索型数据库被用于生产过程监控、质量控制和故障诊断等方面。工程师可以利用搜索功能查找相关的生产数据和技术资料,帮助他们解决生产中的问题和挑战。
- 媒体和娱乐:在媒体和娱乐行业,搜索型数据库被用于内容检索、版权管理和用户推荐等方面。用户可以通过搜索功能查找感兴趣的新闻、音乐和视频等内容,而个性化推荐系统则可以根据用户的搜索历史和偏好推荐相关的内容。
- 教育和培训:在教育和培训行业,搜索型数据库被用于学习资源检索、课程管理和学习分析等方面。学生和教师可以利用搜索功能查找相关的学习资源和课程内容,而学习分析系统则可以分析学生的搜索行为和学习表现,为教学提供参考和支持。
- IT 运维可观测性:通过搜索型数据库,可以实时监控系统的运行状况、性能指标和日志数据,帮助运维团队及时发现和解决系统故障、性能问题和异常情况,确保系统的稳定运行。
- 安全监测和威胁检测:利用搜索型数据库对系统的安全日志进行审计和监控,监测用户的访问行为和系统操作,及时发现异常行为和安全事件。同时,搜索型数据库还可以与威胁情报数据集成,对内部日志数据进行关联分析,快速识别并应对各种安全威胁和攻击行为,保障系统和数据的安全。
综上所述,搜索型数据库在各行各业都发挥着重要作用,数据规模从 GB 到 PB 不等,体现在生活中的方方面面,为用户提供了高效、准确和个性化的信息搜索和检索服务,推动了各行业的发展和进步。随着搜索技术的不断创新和发展,搜索型数据库在各行业中的应用将会越来越广泛,并持续为用户带来更加便捷和智能的搜索体验。
搜索型数据库的发展历程
搜索型数据库的发展历程可以概括如下四个阶段:
- 起步阶段(1990 年代):搜索数据库的雏形开始于上世纪 90 年代,当时以全文检索为主要技术手段,最初用于文档检索和网络搜索。典型代表包括 AltaVista、Excite 等。
- 技术突破(2000 年代):随着互联网的快速发展,搜索数据库开始应用于更多领域,如电子商务、社交网络等。Lucene、Sphinx 等开源搜索引擎的出现推动了搜索技术的进步。
- 商业化发展(2010 年代):搜索数据库进入商业化阶段,以 Elasticsearch 等为代表的商业搜索引擎崭露头角。企业开始大规模应用搜索数据库来管理和检索大量数据。
-
智能化转型(2020 年代):随着人工智能技术的发展,搜索数据库逐渐向智能化转型,开始引入机器学习、自然语言处理等技术,提供个性化推荐和智能搜索服务。同时,搜索数据库也在更多领域得到应用,如医疗保健、金融服务等。
综上所述,搜索数据库经历了从起步阶段到技术突破、商业化发展再到智能化转型的发展历程,表明了其在信息检索领域的重要性和不断演进的趋势,不并断推动着搜索技术的进步和应用范围的扩展。随着人工智能技术的不断成熟,搜索数据库将会在智能化、个性化等方面取得更大的进步,为用户提供更加优质的搜索体验。
搜索型数据库的发展情况
搜索型数据库市场上已经有不少成熟的产品和厂商,但是总的来说,搜索型数据库的界限范围有点模糊,当然其他数据库也有同样的问题,有很多数据库既是文档数据库,又是多模态数据库,还是向量数据库等等,而常见的搜索型数据库主要诞生于:
- 由搜索引擎内核库发展而来的搜索数据库,如 Elasticsearch
- 由其他数据库扩展而来的搜索数据库,如 Postgres Full-Text Search
- 从零开始整体设计的搜索数据库:如 INFINI Pizza
通过流行的 DB-Engines 的搜索引擎排行榜,可以初探国外主流的搜索型数据库的流行趋势,如下图:
可以看到 Elastic 公司的 Elasticsearch 还是依旧保持强悍,自从 Elasticsearch 十多年前掀翻了 Splunk 的桌子,硬生生的在日志领域杀出一条新路,随后大杀四方,碾压整个搜索行业,霸榜至今。Elastic 商业化增长稳健,2023 年收入超过 10 亿美金。
OpenSearch 是由 AWS 发起的 Elasticsearch 开源分支,起因是由于 Elastic 针对云厂商采取的协议变更为 Elastic+SSPL,OpenSearch 基于 Apache 2.0 协议的 Elasticsearch 7.10 版本衍生而来,目前也具备了一定的用户基础。
Splunk 是一款用于搜索、监控和分析大规模机器生成的数据的软件平台,主要用于日志和安全分析领域,属于商业闭源产品。2023 年中被思科(Cisco) 以 230 亿美元现金收购,瞬间刷爆朋友圈。另外有意思的是,前四名除了 Splunk,底层都是 Lucene 内核。
MarkLogic 成立于 2001 年,自我定位是一个 NoSQL 多模态数据库厂商,也是商业闭源软件,生态成熟但是系统过于复杂,学习曲线较陡, 2023 年初被 Progress Software 以 3.55 亿美元收购算是一个比较好的结局。
当然了,除了榜上的这些产品,还有很多优秀的挑战者正摩拳擦掌,跃跃欲试。如下面的这些项目: vespa、Rockset、Doris,Clickhouse、quickwit、Pinot、SingleStore、qdrant、milvus、algolia、meilisearch、typesense、Manticore Search 等等。这些项目不一定都是自己定位是搜索型数据库,有侧重在 AI 领域的,有侧重在实时分析领域的等等,可谓各有千秋,不过都具备一定的搜索和分析能力,不出意外,基本上每家都要号称吊打 Elasticsearch 一番。
国内搜索型数据库的发展情况
搜索型数据库已经成为企业事实上的重要基础设施,而国内搜索型数据库的发展近些年也是开始得到重视,2023 年初,由中国信通院云计算与大数据研究所牵头,依托中国通信标准化协会大数据技术标准推进委员会,联合拓尔思、极限科技、星环科技等 30 余家企业编制的《搜索型数据库技术要求》正式出炉,该标准已成为行业内搜索型数据库技术选型和产品开发的风向标,极限科技的 INFINI Easysearch 率先通过了该标准。
墨天轮社区也开辟了搜索型数据库的排行榜,共有 6 家企业的产品上榜:
国内搜索型数据库的市场还在起步阶段,厂商和可选的产品也还比较少,不过随着市场的成熟,相信未来将迎来一波高速的发展。
搜索型数据库的趋势前瞻
技术在演变,场景在演变,数据也在演变,搜索数据库领域的发展也呈现出多个显著的趋势,这些趋势将进一步推动搜索技术的演进和应用范围的扩展。笔者观测到的主要的发展趋势包括以下方向供参考:
1. 趋势一:实时搜索与分析
-
实时搜索是搜索数据库领域的一个重要发展趋势,业务应用都在朝实时方向演进,用户对信息的即时性需求不断增加,要求搜索结果能够及时反映最新的数据和内容。
-
实时搜索技术通过实时索引和实时更新机制,能够实现快速的数据检索和更新,提供与时俱进的搜索结果,满足用户对信息的即时性需求。
- 目前以 Lucene 为内核的搜索型数据库基本上都只能做到 NRT(近实时)搜索,并且频繁更新带来的挑战和资源的浪费比较高,如果能做到更高效的实时性,可以大大提升用户的搜索体验和实时决策能力。
2. 趋势二:多模态混合搜索
-
多模态搜索是指在搜索过程中同时考虑多种信息形式,如文本、图像、视频等,以提高搜索结果的准确性和全面性。
-
这种技术能够通过分析和理解多种信息形式之间的关联性,为用户提供更加全面、丰富的搜索结果,适用于需要综合不同媒体形式的搜索场景。
- 现实世界的数据越来越复杂化,非结构化数据的利用的场景也越来越多,多模态可以为业务提供更加灵活的分析和探索能力,混合搜索的能力非常具有吸引力。
3. 趋势三:AI 智能语义搜索
-
大模型、AI 智能搜索技术的探索可谓是一日千里,通过利用人工智能技术来实现搜索过程中的智能化、语义化和个性化,结合自然语言处理、机器学习等技术分析用户意图,提供更加智能、个性化的搜索服务。
-
随着大模型的兴起,搜索数据库开始采用像 RAG(Retriever-Reader for Generative Question Answering)这样的大型预训练模型来提升搜索的效果。RAG 模型结合了检索器和阅读器的功能,能够实现更加准确和全面的搜索结果,为用户提供更加智能和个性化的搜索服务。
- 搜索型数据库可谓是 AI 落地最好的是试验田,Elasticsearch 通过拥抱 AI 和大模型,目前股价又重回巅峰,可喜可贺。
4. 趋势四:云原生、存算分离、Serverless
-
随着云计算技术的发展,搜索数据库正逐渐向云原生架构转变。云原生搜索数据库利用容器化、微服务架构等技术,实现了更高的灵活性、可扩展性和容错性,为企业提供了更加稳定和高效的搜索服务,并且成本更低,更加弹性。
-
存算分离是搜索数据库发展的另一重要趋势。通过将存储与计算分离,搜索数据库可以更好地适应数据存储和计算需求的变化,提高系统的性能和效率。存算分离技术使得搜索数据库能够实现更高的并发访问和更快的数据处理速度,为用户提供更加流畅和稳定的搜索体验。
- Serverless 提供开箱即用的体验,成本更低,使用更加灵活,也是目前很多搜索服务提供商正在积极探索的方向。
5. 趋势五:增强现实搜索
- 随着增强现实技术的发展,尤其是 Apple 发布的头戴式 Vision Pro,一部革命性的空间运算设备,将数位内容无缝融入实体世界,而搜索技术也将逐渐与增强现实相结合,为用户提供更加直观和沉浸式的搜索体验。增强现实搜索能够将搜索结果与现实世界相结合,结合 AI 技术为用户提供更加个性化和便捷的搜索服务,这是一个全新的领域,也意味着巨大的机会。
6. 趋势六:现代硬件的高效利用
-
现代硬件及软件运行环境已发生翻天覆地的变化, 片上计算,边缘计算,FPGA,DPU,GPU,一台设备几百核上 TB 内存已经成为现实,可运行之上的软件却还是停留在几十年前的架构。 如 Elasticsearch 其核心 Lucene(及类似实现) 是在 1997 建立的,距今已有 27 年了,虽然也在与时俱进,但是部分架构和设计理念已不具备先进性。
- 在现代的硬件上采用更先进的算法,更新的数据结构、更新的设计理论,利用最新的 CPU 指令集,向量化,批处理,充分发挥多核、大内存和 SSD 的优势,从而达到更高的效率,更低的成本,去解决之前不可能实现的问题,大有可为,也是下一代引擎需要关注的方向。
随着各类数据库功能的边界越来越模糊,应用场景高度交叉重叠,市场竞争也变得白热化,不过笔者认为垂直领域的搜索型数据库机会还是很大,而想做大而全的数据库产品已经没有太多的市场生存空间,一定要在垂直领域有特别专注的地方,我们 INFINI Labs 正在基于 Rust 研发的下一代搜索引擎 INFINI Pizza,就侧重于面向终端用户场景,解决海量数据更新情况下,同时满足高并发和低延迟的核心业务实时检索需求。
总结
综上所述,搜索数据库领域正处于快速发展的阶段。随着互联网数据量的不断增长和用户需求的不断变化,搜索数据库技术将不断创新和进步,以满足用户对信息获取的更加即时、个性化和多样化的需求。未来,随着人工智能技术的进一步发展和应用,搜索数据库将会变得更加智能化、普及化和多样化,为用户提供更加高效、准确和个性化的搜索服务,推动互联网信息的更加便捷获取和利用。
关于极限科技(INFINI Labs)
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
极限网关助力好未来 Elasticsearch 容器化升级
Elasticsearch • INFINI Labs 小助手 发表了文章 • 0 个评论 • 3304 次浏览 • 2024-06-12 15:01
极限网关在好未来的最佳实践案例,轻松扛住日增百 TB 数据的流量,助力 ES 从物理机到云原生架构的改造,实现了流控、请求分析、安全管理、无缝迁移等场景。一次完美的客户体验~
背景
物理机架构时代
2022 年,好未来整个日志 Elasticsearch 拥有数十套服务集群,几百台物理机。这么多台机器耗费成本非常高,而且还要花费很大精力去维护。在人力资源有限情况下,存在非常多的弊端,运行成本高,不仅是机器折旧还有机柜等费用。
流量特征
这是来自某个业务线,如下图 1,真实流量,潮汐性非常明显。好未来有很多条业务线,几乎跟这个趋势都一致的,除了个别业务有“续报”、“开课”等活动特殊情况。潮汐性带来的问题就是高峰期 CPU、内存资源是可以消耗很高;低峰期资源使用量非常低,由于是物理架构,这些资源无法给其他业务线共享。
降本增效-容器化改造原动力
日志服务对成本的空前的压力促使我们推进 Elasticsearch 进行架构改造;如何改造,改造成什么样子,这两个问题一直是推进改造原动力。业界能够同时对水平扩展和垂直扩展就是 K8S,我们开始对 Elasticsearch 改造成能在 K8S 上运行进行探索,从而提升 CPU、内存利用率。
物理机时代,没办法把资源动态的扩缩,动态调配,资源隔离,单靠人力操作调度成本太高,几乎无法完成;集群对内存资源需求要比 CPU 资源大很多,由于机器型号配置是固定的,无法“定制”,这也会导致成本居高不下。所以,无论从那个方面来讲,容器化优势非常明显,既能够优化成本,也能够降低运维复杂度。
ES 容器化改造
进行架构升级重点难点- API 服务
改造过程,我们遇到了很多问题,比如容器 ES 版本和物理机 ES 版本不一致,如何让 ES API 能够兼容不同的 ES 版本,由于版本的不兼容,导致无法直接使用原有的 tribenode 进行服务,怎么提供一个高可用的 Elasticsearch API 服务。我们考虑到多个方面,比如使用官方推荐的 proxy 模式、第三方服务等进行选择,经过多方面对比,选择了极限网关 进行 tribenode 替换。
原始 ES API 服务痛点
- API 访问没有流量控制
- 可观测性差,而且稳定性一般
- 版本兼容性差
物理机时代 API 架构
在物理机时代 ES 集群,API 架构如图 2,可以明显看到 tribe node 对所有 ES 集群的“侵入性”是非常大的,这就带来了很多问题,比较严重的就是单个集群对 ES tribenode 的影响和版本升级带来的不兼容问题。
混合时代 API 架构
通过图 3,我们可以看到,极限网关对于版本兼容性很好,能够适配不同的版本。因此,最终选择极限网关作为下一代 ES API 服务方。
里程碑:全部 ES 集群容器化
在 2023 年 3 月份,通过 Elastic 官方 ECK 模式,完成全部日志 ES 集群容器化改造,拥有数百节点,1PB+ 数据存储,每日新增数据 100T 左右。紧接着,除了日志服务外,同时支持了好未来多条业务线。
极限网关实践
下面主要讲述了,为什么选择极限网关,以及极限网关在好未来落地、应用这些内容。
为什么选择极限网关?
学习成本低
我们可以从文档中看到极限网关,其架构简洁,语法简单,直观易懂。学习成本比较低,上手非常快,对新手友好。
性能强悍
经过压测,发现极限网关速度非常快,且针对 Elasticsearch 做了非常细致的优化,能成倍提升写入和查询的速度。
安全性高
支持多种认证方式,最简单的账号密码认证,可以给自定义多个账户密码,大大简化了 Elasticsearch 的安全设置,同时,还可以支持 LDAP 安全验证。
跨版本支持
我们容器化改造过程需要兼容不同版本的 Elasticsrearch,极限网关针对不同的 Elasticsearch 版本做了兼容和针对性处理,能够让业务代码无缝的进行适配,后端 Elasticsearch 集群版本升级能够做到无缝过渡,降低版本升级和数据迁移的复杂度,非常匹配我们的业务场景。
灵活可扩展
可灵活对每个请求进行干预和路由,支持路由的智能学习,内置丰富的过滤器,通过配置动态修改每个请求的处理逻辑,也支持通过插件来进行扩展,满足我们对流量的控制,尤其是限流、用户、IP 等这些功能非常实用。
启用安全策略-为 API 服务保驾护航
痛点
在升级之前使用 tribe 作为 API 服务提供后端,几乎相当于裸奔,没有任何认证策略;另外,tribe 本身的稳定性也有问题,官方在新版本逐渐废弃这种 CCS(跨集群搜索),期间出现多次服务崩溃。
极限网关解决问题
极限网关通过,“basic_auth” 插件,提供最基本的安全校验,使用起来非常方便;同时,极限网关提供 LDAP 插件,可以接入公共的 LDAP 服务,对所有的访问用户进行校验,安全策略对所有的用户生效,不用担心因为 IP 问题泄漏数据等。
强大的过滤功能
在使用 ES 集群过程中,许多场景,需要对请求进行控制、限制等操作。在这方便,感受到了极限网关强大的产品力。比如下面的两个场景
对异常流量进行限流
- 支持对 IP 限流
- 支持对 hostname 限流
- 支持 header 限流
对异常用户进行封禁
当 Elasticsearch 是通过 Basic Auth 或者 LDAP 方式来进行身份认证的时候,request_user_filter
过滤器可用来按请求的用户名信息来进行过滤。操作起来也非常简单,只需要 request_user_filter
这一个过滤器。
- request_user_filter:
include:
- "elastic"
exclude:
- "Ryan"
总结来讲,主要有这些方面的功能:
优秀的可观测性
痛点
改造前经常为看不到直观的数据指标感到头疼,查看指标需要多个地方同时打开,去筛选,查找,非常繁琐,付出的成本非常大。为此,大家都再考虑如何优化这种情况,无奈优先级比较低,一直没有真正的投入时间去优化这块。
完美解决
使用了极限网关,通过收集请求日志,非常清晰的收集到想要的数据,具体如下:
- 总体方面:
- 流量曲线
- 状态码占比
- 缓存统计
- 每台网关请求流量
- 细节方面:
- 打印每次请求语句
- 可以查看请求到具体 ES 节点流量
- 可以查看过滤器的列表
通过下图,我们可以从管理视角直观的看到各种信息,这对于管理员来讲,省时省力,方便快捷。
意外收获:无缝迁移业务 Elasticsearch 上云
由于前期日志业务上云,受到非常好的反馈,多个业务线期望能够上云上服务,达到降本增效的目的。
支持双写
数据可以通过极限网关同时写入两个 ES 集群,能够保障数据完全一致,安全可靠。
无缝切换
切换很丝滑,影响非常小,能够让外界几乎感受不到服务波动。
通过使用极限网关,自建 ES 集群可以无缝的迁移上云,在整个迁移的过程中,两套集群通过网关进行了解耦,在迁移的过程中还能实现版本的无缝升级,极大降低了迁移成本,提高迁移效率,多次验证服务稳定可靠。
极限网关流量概览
这是其中一套极限网关的流量统计。用这部分数据进行巡检,一目了然,做到全局的掌控,提高感知力度。
极限网关使用总结
极限网关提供一系列高性能和高可靠性的网关服务。使用这样的服务给我们带来以下好处:
- 可观测性好:极限网关可以动态的对 Elasticsearch 运行过程中请求进行拦截和分析,通过指标和日志来了解集群运行状态,这些指标可以用于提升性能和业务优化。
- 增强安全性:包含先进的安全机制,如 basicauth、LDAP 等支持,保护用户数据不受未授权访问和各种网络威胁的侵害。
- 高稳定性:通过冗余设计和故障转移机制,极限网关能够确保网络服务的高可用性,即使在某些组件发生故障时也能保持服务不中断,单版本最长服务超过 15 个月。
- 易于管理:通过提供 INFINI Console 简洁直观的管理界面,让用户能够轻松配置和监控网络状态,提升管理效率。
- 客户支持:良好的客户服务支持可以帮助用户快速解决使用过程中遇到的问题,提供专业的技术指导。
综上所述,极限网关为用户提供了一个高速、安全、稳定且易于管理的 ES 网关,适合对网络性能有较高要求的个人和企业用户。
未来规划
第一阶段,完成了日志 ES 集群,所有集群的容器化改造,合并,成功的把成本降低了 60%以上。这期间积累了丰富容器化经验,为业务 ES 集群上容器做了良好的铺垫;成本优势和运维优势吸引越来越多的业务接入到容器化 ES 集群。
提升 ES 集群效能--新技术应用&&版本升级
- 极限科技官方推荐的 Easysearch 在压缩率,查询速度等等方面有很多的优势,通过长时间的测试稳定性,新特性,对比云原生的 ES 集群,根据测试结果,给“客户”提供多种选择,这也是工作重点之一。
- 我们当前使用的 ES 版本是 6.8,已经远远落后于官方版本,今年我们计划在选择合适的集群升级 ES 版本,拥抱更多官方提供的特性。
混合(多)云架构支持
随着越来越多的 ES 集群在机房的 K8S 集群部署,这里资源出现了紧张局面。 我们尝试在云上部署自建 ES 集群,弥补机房资源有限,无法大规模扩容,同时能够支持多活场景,满足更多客户的不同需求。混合云主要实现以下几种能力:
1、扩缩容:满足不同业务灵活适配
混合(多)云部署,可以让负载内部私有云 ES,同时部署到公有云,提升扩展 IT 基础设施不仅局限于 CPU、内存,还有存储。比如某一个业务要做活动,预估流量“大爆发”,需要提前准备大规模资源,在机房内根本来不及采购扩容支持,然而在公有云上就能很方便扩容、缩容。在云上搭建 ES 集群,设置满足需求的数量、容量、配置,配合极限网关路由策略,精准的把控流量流向。
2、灾备:紧急情况快速部署,恢复 ES 集群读写
当机房级别大规模故障,部分业务实现了多活,单一的机房故障不会影响其服务能力,而此时比如日志查看等仍有需求,为了满足这部分“客户”需求,可以在云上 K8S 集群,快速搭建 ES 集群,恢复日志读写功能。
参考文档:
- https://infinilabs.cn/docs/latest/gateway
- https://www.elastic.co/guide/en/cloud-on-K8S/current/K8S-overview.html
作者:张华勋,前新浪 CDN 研发,工作主要涉及 Mysql、MongoDB、Redis、Elasticsearch、流量调度等组件和系统,以及运维自动化、平台化等工作。现就职于好未来。
关于好未来
好未来(NYSE:TAL)是一家以内容能力与科技能力为基础,以科教、科创、科普为战略方向,助力人的终身成长,并持续探索创新的科技公司。 好未来的前身学而思成立于 2003 年,2010 年在美国纽交所正式挂牌交易。好未来以“爱与科技助力终身成长”为使命,致力成为持续创新的组织。更多参见:https://www.100tal.com/
关于极限科技(INFINI Labs)
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
【搜索客社区日报】第1834期 (2024-06-07)
社区日报 • Fred2000 发表了文章 • 0 个评论 • 2222 次浏览 • 2024-06-09 12:34
[搜索客社区日报】第1825期(2024-05-27)
社区日报 • Muses 发表了文章 • 0 个评论 • 2706 次浏览 • 2024-05-26 20:27
【搜索客社区日报】 第1824期 (2024-05-24)
社区日报 • searchkit 发表了文章 • 0 个评论 • 2608 次浏览 • 2024-05-24 13:17
从 Redis 开源协议变更到 ES 国产化:一次技术自主的机遇
Easysearch • Muses 发表了文章 • 0 个评论 • 4974 次浏览 • 2024-04-11 16:05
引言
近日,Redis Labs 宣布其主导的开源项目 Redis 将采用双重源代码可用许可证(RSALv2)和服务器端公共许可证(SSPLv1)。这一重大决策标志着 Redis 从传统的 BSD 许可证向更加严格的控制权转变,同时也引发了广泛的社区和行业讨论。这不仅是一个关于许可证变更的故事,更是关于开源社区如何响应,以及这一变化如何激发对国产技术探索和发展的深刻思考。Redis,作为最受欢迎的开源键值存储数据库之一,其开源协议的变更反映了开源软件在商业化道路上的挑战和压力。Redis Labs 的 CEO Rowan Trollope 指出,这一变化旨在防止云服务提供商免费使用 Redis 代码,同时促进 Redis 社区的可持续发展和创新。
Redis 协议变更的深远影响
Redis 决定放弃 BSD 协议,转而采用双重源代码可用许可证(RSALv2 和 SSPLv1),标志着开源界的一个重要转折点。这一变化不仅影响了 Redis 本身,更引发了社区成员和技术行业的激烈讨论,许多人担心这将限制 Redis 的开源精神和广泛应用。然而,也有声音认为,这为其他开源项目,如 KeyDB、Dragonfly 和 Garnet 等,提供了发展的机遇,尤其是在提供与 Redis 兼容的替代解决方案方面。尽管 Redis 的这一变更在技术和法律上引发了争议,它也激发了开源社区对于如何在维护开源精神和寻求商业可持续性之间找到平衡的探索。此外,Redis 团队对于保持客户端库的开源许可和继续支持开源社区版的承诺,展示了一种尝试在新的许可模式下保持开放性和可接入性的方法。由于 Redis 的广泛应用,其协议变更对云服务商、Linux 发行版,甚至整个开源软件生态都产生了不小的冲击。一方面,云服务提供商需要重新评估其服务模型;另一方面,一些 Linux 发行版可能需要考虑将 Redis 从其软件仓库中移除。
ES 国产化的契机
Redis 开源协议的变更同时也让人们重新审视其他关键技术,特别是 Elasticsearch(ES)的依赖和发展。ES 作为一个强大的搜索和数据分析引擎,在全球范围内被广泛使用。随着对开源项目商业化模式的重新考量,中国开发者和企业开始寻求国产化的 ES 替代品,旨在减少对外部技术的依赖,同时推动国内技术生态的多元化和自主创新。但是国产化的探索并非没有挑战。从技术兼容性、性能优化到社区生态建设,每一步都需要深思熟虑和持续的努力。然而,Redis 的许可证变更为国内技术自主提供了一个独特的视角,鼓励开发者、企业乃至政府机构更加积极地参与到开源技术的本土化和创新中来。Redis 开源协议的变更引发的讨论和行动,凸显了开源社区对于自身未来发展方向的深刻反思。这一变革不仅关乎一个项目的许可模式转变,更触及到开源项目如何在保持开放和自由的同时,寻找到可持续发展的道路。此外,它也促使更多的开源项目和企业思考如何在全球化的技术生态中保持竞争力和影响力。
Easysearch:国产化的新选择
针对这一需求,极限科技 隆重推出了 Easysearch 搜索引擎软件,旨在提供一个与 Elasticsearch 兼容的国产化解决方案。Easysearch 不仅支持原生 Elasticsearch 的 DSL 查询语法,还提供了诸多企业级功能的增强,如更高的性能、稳定性和扩展性,以及更加丰富的安全管理和数据压缩功能。这表明,国产化技术的发展不仅是为了替代,更是在原有基础上进行创新和优化。ES 国产化解决方案 Easysearch 的推出,是响应国家对信创、自主可控战略布局的具体行动。通过提供兼容性强、功能丰富且稳定的国产技术替代品,不仅有助于减少对外部技术的依赖,也为国内技术生态的繁荣和创新贡献力量。这一过程中,既涵盖了对现有技术的深入理解和应用,也包含了对新技术、新方法的探索和实践。
结语
Redis 开源协议的变更和 Elasticsearch 国产化解决方案的兴起,共同反映了当前技术世界中开源与商业、国际与国产之间复杂而微妙的关系。这一趋势不仅仅是技术领域的变化,更是全球化背景下,各国在技术自主、安全与发展方面所做出的战略性调整。随着更多开源项目和技术面临类似的挑战,我们或许可以预见,技术自主和开源创新将成为推动未来技术发展的两大关键力量。
参考
- https://redis.com/blog/redis-adopts-dual-source-available-licensing
- https://www.elastic.co/cn/blog/licensing-change
- https://infinilabs.cn/products/easysearch
- https://infinilabs.cn/blog/2024/elasticsearch-alternative
- https://infinilabs.cn/blog/2023/the-first-to-complete-the-evaluation-of-search-database-products
关于极限科技(INFINI Labs)
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
3月26日 OpenSearch Community Meeting 视频回放
OpenSearch • Charele 回复了问题 • 2 人关注 • 1 个回复 • 4470 次浏览 • 2024-04-05 16:58
记某客户的一次 Elasticsearch 无缝数据迁移
Elasticsearch • yangmf2040 发表了文章 • 0 个评论 • 4623 次浏览 • 2024-04-02 14:16
背景
客户需要将 Elasticsearch 集群无缝迁移到移动云,迁移过程要保证业务的最小停机时间。
实现方式
通过采用成熟的 INFINI 网关来进行数据的双写,在集群的切换恢复过程中来记录数据变更,待全量数据恢复之后再追平后面增量数据,追平增量之后,进行校验确保数据一致再进行流量的切换。
总体流程
总体迁移流程如下:
- 客户业务代码,切流量,双写。(新增的变更都会记录在网关本地,但是暂停消费到移动云)
- 暂停网关移动云这边的增量数据消费。
- 迁移 11 月的数据,快照,快照上传到 S3;
- 下载 S3 的文件到移动云。
- 恢复快照到移动云的 11 月份的索引。
- 开启网关移动云这边的增量消费。
- 等待增量追平(接近追平)。
- 按照时间条件(如:时间 A,当前时间往前 30 分钟),验证文档数据量,Hash 校验等等。
- 停业务的写入,网关,腾讯云的写入(10 分钟)。
- 等待剩余的增量追完。
- 对时间 A 之后的,增量进行校验。
- 切换所有流量到移动云,业务端直接访问移动云 ES。
总体的迁移时间:
- 11 月备份时间(30 分钟)19 号开始
- 备份下载到移动云的时间(2-3 天)
- 备份恢复到移动云集群的时间(30 分钟)
- 11 月份增量备份(20 分钟)(双写开始)(21 号)
- 11 月份增量下载到移动云(6 小时)
- 11 月份增量恢复时间(20 分钟)
- 追增量数据(8 个小时产生的数据,需要 1 个小时)
- 校验比对(存量 1 个小时)
- 流量暂停,增量的校验(10 分钟)
- 切换(1 分钟)
总体流程如下示意图:
ES 集群信息
- ES 版本 7.10.1
- 2个热节点 3个温节点 总数 1.9 TB
- 索引 1041, 分片2085
- 无自定义插件
- 有 update_bu_query 使用
- 有 delete_by_query 使用
- 吞吐量没有测试过,当前日增文档数 1 千多万,目标日增加上亿
迁移操作手册(参考)
环境
- 自建 ES 5.4.2
- 自建 ES 5.6.8
- 自建 ES 7.5.0
- 极限网关服务器 1
- 极限网关服务器 2
- 云端负载均衡 1 (监听 9200 端口,指向极限网关服务器 1/2 的 8000 端口)
- 云端负载均衡 2 (监听 9200 端口,指向极限网关服务器 1/2 的 8001 端口)
场景描述
若干个自建 Elasticsearch 集群需要平滑迁移到移动云,业务不停写、不做代码改动。
数据架构
通过将应用端流量走网关的方式,请求同步转发给自建 ES,网关记录所有的写入请求,并确保顺序在云端 ES 上重放请求,两侧集群的各种故障都妥善进行了处理,从而实现透明的集群双写,实现安全无缝的数据迁移。 业务端如果已经部署在云上,可以使用云上的 SLB 服务来访问网关,确保后端网关的高可用,如果业务端和极限网关还在企业内网,可以使用极限网关自带的 4 层浮动 IP 来确保网关的高可用。
数据描述
以数据从自建集群 5.4.2 迁移到云上的 5.6.16 为例进行说明,执行步骤依次说明。
执行步骤
部署 INFINI Gateway
为了保证数据的无缝透明迁移,通过 INFINI Gateway 来进行双写。
-
系统调优
参考此文档。
- 下载程序
[root@iZbp1gxkifg8uetb33pvcoZ ~]# mkdir /opt/gateway [root@iZbp1gxkifg8uetb33pvcoZ ~]# cd /opt/gateway/ [root@iZbp1gxkifg8uetb33pvcoZ gateway]# wget http://release.infinilabs.com/gateway/snapshot/gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz --2022-05-19 10:16:25-- http://release.infinilabs.com/gateway/snapshot/gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz 正在解析主机 release.infinilabs.com (release.infinilabs.com)... 120.79.205.193 正在连接 release.infinilabs.com (release.infinilabs.com)|120.79.205.193|:80... 已连接。 已发出 HTTP 请求,正在等待回应... 200 OK 长度:7430568 (7.1M) [application/octet-stream] 正在保存至: “gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz”
100%[==============================================================================================================================================>] 7,430,568 22.8MB/s 用时 0.3s
2022-05-19 10:16:25 (22.8 MB/s) - 已保存 “gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz” [7430568/7430568])
[root@iZbp1gxkifg8uetb33pvcoZ gateway]# tar vxzf gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz gateway-linux-amd64 gateway.yml sample-configs/ sample-configs/elasticsearch-with-ldap.yml sample-configs/indices-replace.yml sample-configs/record_and_play.yml sample-configs/cross-cluster-search.yml sample-configs/kibana-proxy.yml sample-configs/elasticsearch-proxy.yml sample-configs/v8-bulk-indexing-compatibility.yml sample-configs/use_old_style_search_response.yml sample-configs/context-update.yml sample-configs/elasticsearch-route-by-index.yml sample-configs/hello_world.yml sample-configs/entry-with-tls.yml sample-configs/javascript.yml sample-configs/log4j-request-filter.yml sample-configs/request-filter.yml sample-configs/condition.yml sample-configs/cross-cluster-replication.yml sample-configs/secured-elasticsearch-proxy.yml sample-configs/fast-bulk-indexing.yml sample-configs/es_migration.yml sample-configs/index-docs-diff.yml sample-configs/rate-limiter.yml sample-configs/async-bulk-indexing.yml sample-configs/elasticssearch-request-logging.yml sample-configs/router_rules.yml sample-configs/auth.yml sample-configs/index-backup.yml
3. 修改配置
将网关提供的示例配置拷贝,并根据实际集群的信息进行相应的修改,如下:
[root@iZbp1gxkifg8uetb33pvcoZ gateway]# cp sample-configs/cross-cluster-replication.yml 5.4.2TO5.6.16.yml
首先修改集群的身份信息,如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/3.png)
然后修改集群的注册信息,如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/4.png)
根据需要修改网关监听的端口,以及是否开启 TLS (如果应用客户端通过 http 协议访问 ES,请将entry.tls.enabled 值改为 false),如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/5.png)
不同的集群可以使用不同的配置,分别监听不同的端口,用于业务的分开访问。
4. 启动网关
启动网关并指定刚刚创建的配置,如下:
[root@iZbp1gxkifg8uetb33pvcoZ gateway]# ./gateway-linux-amd64 -config 5.4.2TO5.6.16.yml
/ \ /\ / \/\/ / /\ \ \/\ /_/\ / /\///\ / /\/\ \ \/ \/ //\_ / / /\/ \/ / // \ /\ / \/ \ ___/\/ \/\/ \/ \/ \/_/ _/_/
[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway. [GATEWAY] 1.6.0_SNAPSHOT, 2022-05-18 11:09:54, 2023-12-31 10:10:10, 73408e82a0f96352075f4c7d2974fd274eeafe11 [05-19 13:35:43] [INF] [app.go:174] initializing gateway. [05-19 13:35:43] [INF] [app.go:175] using config: /opt/gateway/5.4.2TO5.6.16.yml. [05-19 13:35:43] [INF] [instance.go:72] workspace: /opt/gateway/data1/gateway/nodes/ca2tc22j7ad0gneois80 [05-19 13:35:43] [INF] [app.go:283] gateway is up and running now. [05-19 13:35:50] [INF] [actions.go:358] elasticsearch [primary] is available [05-19 13:35:50] [INF] [api.go:262] api listen at: http://0.0.0.0:2900 [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [backup] hosts: [] => [es-cn-tl32p9fkk0006m56k.elasticsearch.aliyuncs.com:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [backup] hosts: [] => [es-cn-tl32p9fkk0006m56k.elasticsearch.aliyuncs.com:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [entry.go:322] entry [my_es_entry/] listen at: https://0.0.0.0:8000 [05-19 13:35:50] [INF] [module.go:116] all modules are started
5. 后台运行
[root@iZbp1gxkifg8uetb33pvcoZ gateway]# nohup ./gateway-linux-amd64 -config 5.4.2TO5.6.16.yml &
6. 应用授权
curl -XPOST http://localhost:2900/_license/apply -d' { "license": "XXXXXXXXXXXXXXXXXXXXXXXXX" }'
#### 部署 INFINI Console
为了方便在多个集群之间快速切换,使用 INFINI [Console](https://infinilabs.cn/products/console/) 来进行管理。
1. 下载安装
[root@iZbp1gxkifg8uetb33pvcpZ console]# wget http://release.infinilabs.com/console/snapshot/console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz --2022-05-19 10:57:24-- http://release.infinilabs.com/console/snapshot/console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz 正在解析主机 release.infinilabs.com (release.infinilabs.com)... 120.79.205.193 正在连接 release.infinilabs.com (release.infinilabs.com)|120.79.205.193|:80... 已连接。 已发出 HTTP 请求,正在等待回应... 200 OK 长度:13576234 (13M) [application/octet-stream] 正在保存至: “console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz”
100%[==============================================================================================================================================>] 13,576,234 33.2MB/s 用时 0.4s
2022-05-19 10:57:25 (33.2 MB/s) - 已保存 “console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz” [13576234/13576234])
[root@iZbp1gxkifg8uetb33pvcpZ console]# tar vxzf console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz console-linux-amd64 console.yml
2. 修改配置
[root@iZbp1gxkifg8uetb33pvcpZ console]# cat console.yml
for the system cluster, please use Elasticsearch v7.3+
elasticsearch:
- name: default
enabled: true
monitored: false
endpoint: http://es-cn-7mz2p9fty0007frx0.elasticsearch.aliyuncs.com:9200
basic_auth:
username: elastic
password: XXXXXX
discovery:
enabled: false
...
-
启动服务
[root@iZbp1gxkifg8uetb33pvcpZ console]# ./console-linux-amd64 -service install Success [root@iZbp1gxkifg8uetb33pvcpZ console]# ./console-linux-amd64 -service start Success
- 访问后台
访问该主机的 9000 端口,即可打开 Console 后台,http://x.x.x.x:9000/ 打开菜单 [System][Cluster] ,注册当前需要管理的 Elasticsearch 集群和网关地址,用来快速管理,如下:
测试 INFINI Gateway
为了验证网关是否正常工作,我们通过 INFINI Console 来快速验证一下。 首先通过走网关的接口来创建一个索引,并写入一个文档,如下: 查看 5.4.2 集群的数据情况,如下: 查看集群 5.6.16 的数据情况,如下: 说明网关配置都正常,验证结束。
调整网关的消费策略
因为我们需要在全量数据迁移之后,才能进行增量数据的追加,在全量数据迁移完成之前,我们应该暂停增量数据的消费。修改网关配置里面 Pipeline consume-queue_backup-to-backup
和 consume-queue_primary-failure-to-backup
的参数 auto_start
为 false
,表示不自动启动该任务,具体配置方法如下:
修改完配置之后,需要重新启动网关。
为了方便管理,可以使用 INFINI Console 来注册和管理网关,如下:
待全量迁移完成之后,可以通过后台的 Task 管理来进行后续的任务启动、停止,如下:
切换流量
接下来,将业务正常写的流量切换到网关,也就是需要把之前指向 ES 5.4.2 的地址指向网关的地址,如果 5.4.2 集群开启了身份验证,业务端代码同样需要传递身份信息,和 5.4.2 之前的用法保持不变。 切换流量到网关之后,用户的请求还是以同步的方式正常访问自建集群,网关记录到的请求会按顺序记录到 MQ 里面,但是消费是暂停状态。 如果业务端代码使用的 ES 的 SDK 支持 Sniff,并且业务代码开启了 Sniff,那么应该关闭 Sniff,避免业务端通过 Sniff 直接链接到后端的 ES 节点,所有的流量现在应该都只通过网关来进行访问。
全量数据迁移
在流量迁移到网关之后,我们开始对自建 Elasticsearch 集群的数据进行全量迁移到云端 Elasticsearch 集群。 全量迁移已有的数据的方式有很多种:
- 通过快照的方式进行恢复
- 使用工具来导出导入,如: ESM
如果索引数量很多的话,可以按照索引依次进行导入,同时需要注意将 Mapping 和 Setting 提前导入。
以现在 5.4 集群的索引来为例,目前的待迁移索引为 demo_5_4_2
,只有4
个文档:
我们使用网关自带的迁移功能来进行数据迁移,拷贝自带的样例文件,如下:
[root@iZbp1gxkifg8uetb33pvcpZ gateway]# cp sample-configs/es_migration.yml 5.4TO5.6.yml
修改其中代表集群和索引的相关配置,可以根据需要配置是否需要重命名索引和统一 Type( 用于跨版本统一 Type),如下图红框位置: 创建好模板和索引,如果目标集群不允许动态创建文档,需要提前创建好索引,如下图: 然后就可以开始数据的迁移了,执行网关程序并指定刚刚定义的配置,如下: 执行完成后,可以确认下数据的情况,如下图: 全量数据至此导入完成。
增量数据迁移
在全量导入的过程中,可能存在数据的增量修改,不过这部分请求都已经完整记录下来了,我们只需要开启网关的消费任务即可将挤压的请求应用到云端的 Elasticsearch 集群。 示例操作如下: 如果从 5.6 的集群来看的话,这部分的修改还没同步过来,如下: 这部分增量的数据变更,在网关层面都进行了完整记录,我们只需要开启网关的增量消费任务,如下: 通过观察队列是否消费完成来判断增量数据是否做完,如下: 现在我们再看一下 5.6 集群的数据情况,如下: 数据的增量更新就过来了。
执行数据比对
由于集群内部的数据可能比较多,我们需要进行一个完整的比对才能确保数据的完整性,可以通过网关自带的数据比对工具来进行,将样例自带的文件拷贝一份,如下:
[root@iZbp1gxkifg8uetb33pvcpZ gateway]# cp sample-configs/index-docs-diff.yml 5.4DIFF5.6.yml
修改需要比对的集群和索引信息,可以加上过滤条件,如时间范围窗口来进行增量 Diff,如下图:
执行网关程序,并指定该配置文件,如下图: 如图,两个集群完全一致。
切换集群
如果验证完之后,两个集群的数据已经完全一致了,可以将程序切换到新集群,或者将网关的配置里面的主备进行互换,同步写 5.6 集群。 双集群在线运行一段时间,待业务完全验证之后,再安全下线旧集群,如遇到问题,也可以随时回切到老集群。
小结
通过使用极限网关,自建 ES 集群可以安全无缝的迁移到移动云 ES,在迁移的过程中,两套集群通过网关进行了解耦,两套集群的版本也可以不一样,在迁移的过程中还能实现版本的无缝升级。 如有任何问题,请随时联系我,期待与您交流!
【 INFINI Workshop 北京站】1月18日一起动手实验玩转 Easysearch
活动 • liaosy 发表了文章 • 0 个评论 • 2427 次浏览 • 2023-12-15 16:22
与 INFINI Labs 的技术专家面对面,第一时间了解极限实验室的发布最新产品和功能特性,通过动手实战,快速掌握最前沿的搜索技术,并用于实际项目中。欢迎大家扫描海报二维码免费报名参加。
活动时间:2024-01-18 13:30~17:30
活动地点:北京市海淀区 Wework 辉煌时代大厦 3 楼 3E 会议室
分享议题
- Easysearch 总体介绍及搭建实战
- 基于 INFINI Console 实现跨版本、跨引擎统一管控
- Elasticsearch -> Easysearch 在线迁移实操
参会提示
- 请务必自备电脑(Windows 系统环境请提前安装好 Linux 虚拟机)
- 请提前在 INFINI Labs 官网下载对应平台最新安装包(INFINI Easysearch、INFINI Gateway、INFINI Console)
- 下载地址:https://www.infinilabs.com/download
- 如有任何疑问可添加 INFINI Labs 小助手(微信号: INFINI-Labs)进行联系
3月26日 OpenSearch Community Meeting 视频回放
回复OpenSearch • Charele 回复了问题 • 2 人关注 • 1 个回复 • 4470 次浏览 • 2024-04-05 16:58
ElasticSearch自动补全,中文不准确的问题,请大家帮我看一下
回复Elasticsearch • God_lockin 回复了问题 • 2 人关注 • 1 个回复 • 3199 次浏览 • 2023-11-21 22:17
极限科技(INFINI Labs)招聘:搜索运维工程师(Elasticsearch/Easysearch)【北京/全职】
求职招聘 • INFINI Labs 小助手 发表了文章 • 0 个评论 • 5528 次浏览 • 2024-09-28 11:00
我们是国内搜索型数据库产品厂商第一梯队的杰出代表,随着业务的快速发展,现开放岗位:搜索运维工程师( Elasticsearch/Easysearch ),如果有兴趣,请直接拉到文末,扫描二维码或将简历投递至 hello@infini.ltd。
如果您还不了解 极限科技(INFINI Labs)是谁,在做什么,需要什么样的小伙伴,那么请看下文:
我们是谁
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
我们在做什么
极限科技(INFINI Labs)正在致力于以下几个核心方向:
1、开发近实时搜索引擎 INFINI Easysearch
INFINI Easysearch 是一个分布式的搜索型数据库,实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch,同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。详情参见:https://infinilabs.cn
2、打造下一代实时搜索引擎 INFINI Pizza
INFINI Pizza 是一个分布式混合搜索数据库系统。我们的使命是充分利用现代硬件和人工智能的潜力,为企业提供量身定制的实时智能搜索体验。我们致力于满足具有挑战性的环境中高并发和高吞吐量的需求,同时提供无缝高效的搜索功能。详情参见:https://pizza.rs
3、积极参与全球开源生态建设
通过开源项目和社区贡献,推动全球开源技术的发展,提升中国在全球开源领域的影响力。
4、提供专业服务
为客户提供包括搜索技术支持、迁移服务、定制解决方案和培训在内的全方位服务。
5、提供国产化搜索解决方案
针对中国市场的特殊需求,提供符合国产化标准的搜索产品和解决方案,帮助客户解决使用 Elasticsearch 时遇到的挑战。
极限科技(INFINI Labs)通过这些努力,旨在成为全球领先的实时搜索和数据分析解决方案提供商。
我们期待有才华、有激情的你加入我们,一起探索数据搜索的未来,共同创造无限可能!
在招岗位介绍
岗位名称
搜索运维工程师(Elasticsearch/Easysearch)
岗位职责
- 负责客户现场的 Elasticsearch/Easysearch/OpenSearch 搜索引擎集群的日常维护、监控和优化,确保集群的高可用性和性能稳定;
- 协助客户进行搜索引擎集群的部署、配置及版本升级;
- 排查和解决 Elasticsearch/Easysearch/OpenSearch 集群中的各种技术问题,及时响应并处理集群异常;
- 根据业务需求设计和实施搜索索引的调优、数据迁移和扩展方案;
- 负责与客户沟通,提供技术支持及相关培训,确保客户需求得到有效满足;
- 制定并实施搜索引擎的备份、恢复和安全策略,保障数据安全;
- 与内部研发团队和外部客户进行协作,推动集群性能改进和功能优化。
岗位要求
- 全日制本科及以上学历,5 年以上运维工作经验;
- 拥有 Elasticsearch/Easysearch/OpenSearch 使用经验,熟悉搜索引擎的原理、架构和相关生态工具(如 Logstash、Kibana 等);
- 熟悉 Linux 操作系统的使用及常见性能调优方法;
- 熟练掌握 Shell 或 Python 等至少一种脚本语言,能够编写自动化运维脚本;
- 具有优秀的问题分析与解决能力,能够快速应对突发情况;
- 具备良好的沟通能力和团队合作精神,能够接受 客户驻场工作;
- 全职,北京地区,需具备在北京长期工作的条件;
优先考虑
- 计算机科学、信息技术或相关专业;
- 具备丰富的大规模分布式系统运维经验;
- 熟悉 Elasticsearch/Easysearch/OpenSearch 分片、路由、查询优化等高级功能;
- 拥有 Elastic Certified Engineer 认证;
- 具备大规模搜索引擎集群设计、扩展和调优经验;
- 熟悉其他搜索引擎技术(如 Solr、Lucene)者优先 ;
- 熟悉大数据处理相关技术(比如: Kafka 、Flink 等)者优先。
福利待遇
- 月薪: 15K - 25K,具体根据能力而定,试用期为 3-6 个月;
- 福利:五险一金/双休/国内法定假日/带薪年假等;
简历投递
简历投递:hello@infini.ltd(邮件标题请备注姓名+求职岗位+来自搜索客社区)
微信联系:INFINI-Labs(加微请备注求职岗位+来自搜索客社区)
欢迎有兴趣的小伙伴联系或推荐,期待您的加入!
Elastic 宣布修改开源协议为 AGPL:Elasticsearch 再次成为开源软件
Elasticsearch • searchkit 发表了文章 • 0 个评论 • 4783 次浏览 • 2024-08-30 11:26
今日快讯!就在刚刚,开源搜索领域行业巨头 Elastic 官方博客发表了一篇最新公告《Elasticsearch is Open Source, Again》,Elastic 创始人& CTO Shay Banon 宣布 Elasticsearch 和 Kibana 许可证协议修改为 AGPL。
以下为搜索客社区从 Elastic 官方博客翻译的原文内容:
Elasticsearch 再次成为开源软件
[D.N.A] Elasticsearch 和 Kibana 现在可以再次被称为开源软件了。这句话让我感到无比的兴奋。真的忍不住跳起来庆祝!我们所有在 Elastic 的人都很高兴。开源精神是我的DNA,也是 Elastic 的DNA。能够再次称 Elasticsearch 为开源软件,真的是一种纯粹的快乐。
[LOVE.] 简而言之,我们将在接下来的几周内,除了 ELv2 和 SSPL 之外,增加 AGPL 作为另一个许可选项。在更改许可后,我们从未停止过像一个开源社区一样相信和行动。但通过使用 AGPL 这一获得开放源码促进会(OSI)批准的许可,消除了人们可能存在的任何疑问或混淆。
[Not Like Us] 我们在 Elastic 从未停止过对开源的信仰。我个人对开源的信仰也从未动摇,至今已有 25 年了。那么为什么三年前我们要做出改变呢?我们遇到了与 AWS 相关的问题,以及他们的服务引发的市场混乱。在尝试了所有能想到的其他选项后,我们更改了许可协议,明知道这会导致 Elasticsearch 被分叉成另一个名称并走上不同的发展轨迹。这是一个漫长的故事。
[Like That] 好消息是,虽然过程痛苦,但结果奏效了。三年后,亚马逊已经完全投入到了他们的分叉项目中,市场的混乱(大部分)得到了缓解,我们与 AWS 的合作伙伴关系比以往更强。我们甚至被评为 AWS 的年度合作伙伴。我一直希望时间能过去得足够久,以至于我们可以安全地回到开源项目的状态——现在终于到了。
[All The Stars] 我们希望尽可能简化用户的使用体验。我们有用户非常喜欢 ELv2(一个受 BSD 启发的许可)。我们也有用户已经批准使用 SSPL(通过 MongoDB 使用)。这就是为什么我们只是增加了一个选项,而不是移除任何东西。如果你已经在使用并喜欢 Elasticsearch,请继续使用,没有任何变化。对于其他人,现在你也可以选择使用 AGPL。
[LOYALTY.] 我们选择 AGPL 而不是其他许可,是因为我们希望通过与 OSI 的合作,能在开源许可领域创造更多的选项。随着我们更改许可以来的发展(例如 Grafana 从 Apache2 转移到 AGPL),也许 AGPL 已经足够适用于像我们这样的基础设施软件了。我们致力于找到最合适的解决方案。
[euphoria] 我非常高兴能够再次称 Elasticsearch 为开源软件。
[Alright] 任何改变都可能引发混淆,当然也可能引来一些网络喷子。(网络喷子总是存在的,对吧?)让我们愉快地回答一些可能出现的问题吧。我可以想象到的一些问题如下,但我们会继续补充。
“更改许可是个错误,Elastic 现在在回撤”:我们在三年前更改许可时消除了很多市场混乱。由于我们的行动,很多事情已经改变。现在是一个完全不同的市场环境。我们不生活在过去。我们希望为用户打造一个更好的未来。正是因为我们当时采取了行动,现在我们才有能力采取新的行动。
“AGPL 不是真正的开源许可,X 才是”:AGPL 是获得 OSI 批准的许可,并且被广泛采用。例如,MongoDB 曾经使用 AGPL,Grafana 现在也是 AGPL。这表明 AGPL 并不影响使用或流行度。我们选择 AGPL 是因为我们认为这是与 OSI 一起为世界开辟更多开源道路的最佳方式,而不是减少开源。
“Elastic 更改许可是因为他们表现不好”:我要说的是,我今天对 Elastic 的未来依然充满期待。我为我们的产品和团队的执行力感到无比自豪。我们发布了无状态的 Elasticsearch ES|QL 和大量用于 GenAI 用例的向量数据库/混合搜索改进。我们在日志记录和可观察性方面大力投入 OTel。我们的安全产品 SIEM 不断添加令人惊叹的功能,并且是市场上增长最快的产品之一。用户的反应让我们感到非常谦卑。股市总有起伏,但我可以向你保证,我们始终着眼于长远发展,而这次的变更就是其中的一部分。
如果我们看到更多问题,会在上面继续添加,以期减少混淆。
[HUMBLE.] 为未来而构建真是令人兴奋。Elasticsearch 回归开源。万岁!这真是一件美妙的事情。今天真是美好的一天。
Forever :elasticheart: Open Source
Shay 2024-08-30
原文地址:https://www.elastic.co/blog/elasticsearch-is-open-source-again/
社区热评
Elasticsearch 再次回归开源的消息迅速引发了技术社区的广泛关注。这不仅是 Elastic 对自身开源信念的重申,也是其在激烈市场竞争中精心策划的一次战略调整。
三年前,Elastic 因与 AWS 的市场竞争而选择更改许可协议,这一决定在当时引发了不小的争议。尽管如此,事实证明,这一策略有效地减少了市场上的混淆,也为 Elastic 与 AWS 的合作奠定了更坚实的基础。如今,Elastic 再度选择开源,并新增 AGPL 作为许可选项,这一举措无疑展现了 Elastic 在市场中更加成熟的定位和对未来发展的自信。
这一变化不仅仅是一个公司的商业决策,更是开源生态系统的一次重要信号。Elastic 的回归开源,传递出一个明确的信息:即使在商业竞争中,开源仍然是企业实现长远发展的重要路径。随着这一决定的落地,其他软件公司可能也会重新审视自身的许可策略,推动更多开源项目的发展与创新。
此外,Elastic 选择 AGPL 作为新许可选项,也显示出其对开源生态未来走向的深刻洞察。AGPL 的引入,表明 Elastic 希望在开源社区中保持灵活性和多样性,同时推动整个行业向更加开放和透明的方向迈进。
总体而言,Elastic 重返开源的举动,不仅意在巩固其在开源社区中的地位,也为行业树立了一个新的标杆。这一事件无疑将成为开源软件发展史上的重要篇章,未来可能会激发更多企业重新考虑其开源战略,进而推动整个技术行业的进一步繁荣与进步。
让我们拭目以待!
Elasticsearch 磁盘空间异常:一次成功的故障排除案例分享
Elasticsearch • INFINI Labs 小助手 发表了文章 • 0 个评论 • 3620 次浏览 • 2024-08-09 00:18
故障现象
近日有客户找到我们,说有个 ES 集群节点,磁盘利用率达到了 82% ,而其节点才 63% ,想处理下这个节点,降低节点的磁盘利用率。
起初以为是没有打开自动平衡导致的,经查询,数据还是比较平衡的。 利用率较高的是 76 节点,如果 76 节点的分片比其他节点多,好像还比较合乎逻辑,但它反而比其他节点少了 12-15 个分片。那是 76 节点上的分片比较大?
索引情况
图中都是较大的索引,1 个索引 25TB 左右,共 160 个分片。
分片大小
节点 64 节点 77 节点 75 问题节点 76 可以看出分片大小没有出现较大的倾斜,分片大小和数据平衡的原因都被排除。
换个方向思考,节点 76 比其他节点多使用了磁盘空间 8 个 TB 左右,集群最大分片大小约 140GB ,8000/140=57 ,即节点 76 至少要比其他节点多 57 个分片才行,啊这...
会不会有其他的文件占用了磁盘空间?
我们登录到节点主机,排查是否有其他文件占用了磁盘空间。
结果:客户的数据路径是单独的数据磁盘,并没有其他文件,都是 ES 集群索引占用的空间。
现象总结
分片大小差不多的情况下,节点 76 的分片数还比别的节点还少 10 个左右,它的磁盘空间反而多占用了 8TB 。
这是不是太奇怪了?事出反常必有妖,继续往下查。
原因定位
通过进一步排查,我们发现节点 76 上有一批索引目录,在其他的节点上没有,而且也不在 GET \_cat/indices?v
命令的结果中。说明这些目录都是 dangling 索引占用的。
dangling 索引产生的原因
当 Elasticsearch 节点脱机时,如果删除的索引数量超过 Cluster.indes.tombstones.size
,就会发生这种情况。
解决方案
通过命令删除 dangling 索引:
DELETE /\_dangling/<index-uuid>?accept_data_loss=true
最后
这次的分享就到这里了,欢迎与我一起交流 ES 的各种问题和解决方案。
关于极限科技(INFINI Labs)
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
【第2期】2024 搜索客 Meetup | Elasticsearch 的代码结构和写入查询流程的解读
活动 • searchkit 发表了文章 • 0 个评论 • 2858 次浏览 • 2024-08-06 11:47
本次活动由 搜索客社区、极限科技(INFINI Labs)联合举办,活动主题将深入探讨 Elasticsearch 的两个核心方面:代码结构以及写入和查询的关键流程。本次活动将为 Elasticsearch 初学者和有经验的用户提供宝贵的见解,欢迎大家报名参加、交流学习。
活动主题:Elasticsearch 的代码结构和写入查询流程的解读
活动时间:2024 年 8 月 14 日 19:00-20:00(周三)
活动形式:微信视频号(极限实验室)直播
报名方式:关注或扫码海报中的二维码进行预约
嘉宾介绍
张磊,极限科技搜索引擎研发负责人,对 Elasticsearch 和 Lucene 源码比较熟悉,目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。
主题摘要
本次分享将探讨 Elasticsearch 的代码结构及其写入和查询流程。内容包括:项目架构、核心模块、插件系统,以及文档索引和查询的各个阶段与分布式查询协调。
活动亮点
-
深入解析 Elasticsearch 代码结构:
- 项目的整体结构:了解 Elasticsearch 项目的组织方式。
- 核心模块及其职责:学习 Elasticsearch 的核心模块及其在系统中的具体角色。
- 插件系统的设计:探索 Elasticsearch 灵活的插件系统设计及其扩展方式。
-
详细解读 Elasticsearch 写入和查询流程:
- 文档索引过程的各个阶段:跟随文档从初始接收至最终存储的索引过程。
- 查询解析和执行的步骤:理解 Elasticsearch 中查询解析和执行的各个步骤。
- 分布式查询的协调过程:学习 Elasticsearch 如何在分布式架构中协调查询,以提供高效且准确的搜索结果。
参与有奖
直播中将设有福袋抽奖环节,参与就有机会获得 INFINI Labs 周边纪念品,包括 T 恤、鸭舌帽、咖啡杯、指甲刀套件等等(图片仅供参考,款式、颜色与尺码随机)。
活动交流
活动交流群二维码 7 天内(8 月 12 日前)有效,如过期请添加小助手微信拉群。
本次 Meetup 是深入了解 Elasticsearch 内部工作机制、提升使用技能的绝佳机会。不要错过!
Meetup 讲师招募
搜索客社区 Meetup 的成功举办,离不开社区小伙伴的热情参与。目前社区讲师招募计划也在持续进行中,我们诚挚邀请各位技术大咖、行业精英踊跃提交演讲议题,与大家分享您的经验。
讲师报名链接:http://cfp.searchkit.cn
或扫描下方二维码,立刻报名成为讲师!
Meetup 活动聚焦 AI 与搜索领域的最新动态,以及数据实时搜索分析、向量检索、技术实践与案例分析、日志分析、安全等领域的深度探讨。
我们热切期待您的精彩分享!
往期回顾
【第 1 期】2024 搜索客 Meetup | Easysearch 结合大模型实现 RAG
关于 搜索客(SearchKit)社区
搜索客社区由 Elasticsearch 中文社区进行全新的品牌升级,以新的 Slogan:“搜索人自己的社区” 为宣言。汇集搜索领域最新动态、精选干货文章、精华讨论、文档资料、翻译与版本发布等,为广大搜索领域从业者提供更为丰富便捷的学习和交流平台。社区官网:https://searchkit.cn 。
Easysearch、Elasticsearch、Amazon OpenSearch 快照兼容对比
Easysearch • INFINI Labs 小助手 发表了文章 • 2 个评论 • 2483 次浏览 • 2024-07-29 11:54
在当今的数据驱动时代,搜索引擎的快照功能在数据保护和灾难恢复中至关重要。本文将对 Easysearch、Elasticsearch 和 Amazon OpenSearch 的快照兼容性进行比较,分析它们在快照创建、恢复、存储格式和跨平台兼容性等方面的特点,帮助大家更好地理解这些搜索引擎的差异,从而选择最适合自己需求的解决方案。
启动集群
Easysearch
服务器一般情况下默认参数都是很低的,而 Easysearch/Elasticsearch 是内存大户,所以就需要进行系统调优。
sysctl -w vm.max_map_count=262144
vm.max_map_count
是一个 Linux 内核参数,用于控制单个进程可以拥有的最大内存映射区域(VMA,Virtual Memory Areas)的数量。内存映射区域是指通过内存映射文件或匿名内存映射创建的虚拟内存区域。
这个参数在一些应用程序中非常重要,尤其是那些需要大量内存映射的应用程序,比如 Elasticsearch。Elasticsearch 使用内存映射文件来索引和搜索数据,这可能需要大量的内存映射区域。如果 vm.max_map_count
设置得太低,Elasticsearch 可能无法正常工作,并会出现错误信息。
调整 vm.max_map_count
参数的一些常见原因:
-
支持大型数据集: 应用程序(如 Elasticsearch)在处理大型数据集时可能需要大量内存映射区域。增加
vm.max_map_count
可以确保这些应用程序有足够的内存映射区域来处理数据。 -
防止内存错误: 如果
vm.max_map_count
设置得太低,当应用程序尝试创建超过限制的内存映射时,会出现错误,导致应用程序崩溃或无法正常工作。 - 优化性能:
适当地设置
vm.max_map_count
可以优化应用程序的性能,确保内存映射操作顺利进行。
检查当前的 vm.max_map_count
值:
sysctl vm.max_map_count
或者查看 /proc/sys/vm/max_map_count
文件:
cat /proc/sys/vm/max_map_count
Elasticsearch 官方建议将 vm.max_map_count
设置为至少 262144。对于其他应用程序。
Easysearch 具体安装步骤见 INFINI Easysearch 尝鲜 Hands on
Amazon OpenSearch
使用 Amazon Web Services 控制台进行创建。
Elasticsearch
使用如下 docker compose 部署一个三节点的 ES 集群:
version: "2.2"
services:
es01:
image: docker.elastic.co/elasticsearch/elasticsearch:7.10.2
container_name: es01
environment:
- node.name=es01
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es02,es03
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- data01:/usr/share/elasticsearch/data
ports:
- 9200:9200
networks:
- elastic
es02:
image: docker.elastic.co/elasticsearch/elasticsearch:7.10.2
container_name: es02
environment:
- node.name=es02
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es01,es03
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- data02:/usr/share/elasticsearch/data
networks:
- elastic
es03:
image: docker.elastic.co/elasticsearch/elasticsearch:7.10.2
container_name: es03
environment:
- node.name=es03
- cluster.name=es-docker-cluster
- discovery.seed_hosts=es01,es02
- cluster.initial_master_nodes=es01,es02,es03
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ulimits:
memlock:
soft: -1
hard: -1
volumes:
- data03:/usr/share/elasticsearch/data
networks:
- elastic
volumes:
data01:
driver: local
data02:
driver: local
data03:
driver: local
networks:
elastic:
driver: bridge
由于这个 docker compose 没有关于 kibana 的配置,所以我们还是用 Console 添加原生的 Elasticsearch 集群!
集群信息
快照还原的步骤
快照前的准备
插件安装
本次测试选择把索引快照备份到 Amazon S3,所以需要使用 S3 repository plugin,这个插件添加了对使用 Amazon S3 作为快照/恢复存储库的支持。
Easysearch 和 OpenSearch 集群自带了这个插件,所以无需额外安装。
对于自己部署的三节点 Elasticsearch 则需要进入每一个节点运行安装命令然后再重启集群,建议使用自动化运维工具来做这步,安装命令如下:
sudo bin/elasticsearch-plugin install repository-s3
如果不再需要这个插件,可以这样删除。
sudo bin/elasticsearch-plugin remove repository-s3
由于需要和 Amazon Web Services 打交道,所以我们需要设置 IAM 凭证,这个插件可以从 EC2 IAM instance profile,ECS task role 以及 EKS 的 Service account 读取相应的凭证。
对于托管的 Amazon OpenSearch 来说,我们无法在托管的 EC2 上绑定我们的凭证,所以需要新建一个 OpenSearchSnapshotRole,然后通过当前的用户把这个角色传递给服务,也就是我们说的 IAM:PassRole。
创建 OpenSearchSnapshotRole,策略如下:
{
"Version": "2012-10-17",
"Statement": [{
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::bucket-name"
]
},
{
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::bucket-name/*"
]
}
]
}
信任关系如下:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "es.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
然后在我们的 IAM user 上加上 PassRole 的权限,这样我们就可以把 OpenSearchSnapshotRole 传递给 OpenSearch 集群。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::123456789012:role/OpenSearchSnapshotRole"
}
]
}
注册存储库
在源集群执行注册
PUT /_snapshot/snapshot-repo-name
{
"type": "s3",
"settings": {
"bucket": "<bucket-name>",
"base_path": "<bucket-prefix>",
在目标集群同样执行这个语句,为了防止覆盖源集群存储库的数据,将 "readonly": true 添加到"settings" PUT 请求中,这样就只有一个集群具有对存储库的写入权限。
PUT /_snapshot/snapshot-repo-name
{
"type": "s3",
"settings": {
"bucket": "<bucket-name>",
"base_path": "<bucket-prefix>",
"readonly": true,
对于 OpenSearch 来说,还需要执行 passrole,所以还需要添加role_arn这个字段,由于 IAM:PassRole 需要对 HTTP 请求做 signV4 日签名,所以这部常常使用 Postman 来完成。把角色传递过去之后,接下来的快照还原操作就可以在 OpenSearch Dashboard 中进行操作了。
需要注意的是,需要在 auth 这里输入 AccessKey,SecretKey,AWS Region,Service Name(es)来做 SignV4 的签名。
请求体如下:
{
"type": "s3",
"settings": {
"bucket": "<bucket-name>",
"base_path": "<bucket-prefix>",
"readonly": true,
"role_arn": "arn:aws:iam::123456789012:role/OpenSearchSnapshotRole"
}
}
- 查看所有注册的存储库:
GET _snapshot
:这个命令返回所有已注册的快照存储库列表及其基本信息。
GET _snapshot
{
"es_repository": {
"type": "s3",
"settings": {
"bucket": "your-s3-bucket-name",
"region": "your-s3-bucket-region"
}
}
}
- 查看特定存储库的详细信息:
GET _snapshot/es_repository
:这个命令返回名为es_repository
的存储库的详细配置信息,包括存储桶名称、区域和其他设置。
GET _snapshot/es_repository
{
"es_repository": {
"type": "s3",
"settings": {
"bucket": "your-s3-bucket-name",
"region": "your-s3-bucket-region",
"access_key": "your-access-key",
"secret_key": "your-secret-key"
}
}
}
- 查看特定存储库中的快照:
GET _cat/snapshots/es_repository?v
:这个命令返回es_repository
存储库中的所有快照及其详细信息,包括快照 ID、状态、开始时间、结束时间、持续时间、包含的索引数量、成功和失败的分片数量等。
GET _cat/snapshots/es_repository?v
id status start_epoch start_time end_epoch end_time duration indices successful_shards failed_shards total_shards
snapshot_1 SUCCESS 1628884800 08:00:00 1628888400 09:00:00 1h 3 10 0 10
snapshot_2 SUCCESS 1628971200 08:00:00 1628974800 09:00:00 1h 3 10 0 10
创建索引快照
# PUT _snapshot/my_repository/<my_snapshot_{now/d}>
PUT _snapshot/my_repository/my_snapshot
{
"indices": "my-index,logs-my_app-default",
}
根据快照的大小不同,完成快照可能需要一些时间。默认情况下,create snapshot API 只会异步启动快照过程,该过程在后台运行。要更改为同步调用,可以将 wait_for_completion
查询参数设置为 true
。
PUT _snapshot/my_repository/my_snapshot?wait_for_completion=true
另外还可以使用 clone snapshot API 克隆现有的快照。要监控当前正在运行的快照,可以使用带有 _current
请求路径参数的 get snapshot API。
GET _snapshot/my_repository/_current
如果要获取参与当前运行快照的每个分片的完整详细信息,可以使用 get snapshot status API。
GET _snapshot/_status
成功创建快照之后,就可以在 S3 上看到备份的数据块文件,这个是正确的快照层级结构:
需要注意的是, "base_path": "
所以在 Open Search 中还原 Elasticsearch 就遇到了这个问题:
{
"error": {
"root_cause": [
{
"type": "snapshot_missing_exception",
"reason": "[easy_repository:2/-jOQ0oucQDGF3hJMNz-vKQ] is missing"
}
],
"type": "snapshot_missing_exception",
"reason": "[easy_repository:2/-jOQ0oucQDGF3hJMNz-vKQ] is missing",
"caused_by": {
"type": "no_such_file_exception",
"reason": "Blob object [11111/indices/7fv2zAi4Rt203JfsczUrBg/meta-YGnzxZABRBxW-2vqcmci.dat] not found: The specified key does not exist. (Service: S3, Status Code: 404, Request ID: R71DDHX4XXM0434T, Extended Request ID: d9M/HWvPvMFdPhB6KX+wYCW3ZFqeFo9EoscWPkulOXWa+TnovAE5PlemtuVzKXjlC+rrgskXAus=)"
}
},
"status": 404
}
恢复索引快照
POST _snapshot/my_repository/my_snapshot_2099.05.06/_restore
{
"indices": "my-index,logs-my_app-default",
}
各个集群的还原
-
Elasticsearch 7.10.2 的快照可以还原到 Easysearch 和 Amazon OpenSearch
- 从 Easysearch 1.8.2 还原到 Elasticsearch 7.10.2 报错如下:
{
"error": {
"root_cause": [
{
"type": "snapshot_restore_exception",
"reason": "[s3_repository:1/a2qV4NYIReqvgW6BX_nxxw] cannot restore index [my_indexs] because it cannot be upgraded"
}
],
"type": "snapshot_restore_exception",
"reason": "[s3_repository:1/a2qV4NYIReqvgW6BX_nxxw] cannot restore index [my_indexs] because it cannot be upgraded",
"caused_by": {
"type": "illegal_state_exception",
"reason": "The index [[my_indexs/ALlTCIr0RJqtP06ouQmf0g]] was created with version [1.8.2] but the minimum compatible version is [6.0.0-beta1]. It should be re-indexed in Elasticsearch 6.x before upgrading to 7.10.2."
}
},
"status": 500
}
- 从 Amazon OpenSearch 2.1.3 还原到 Elasticsearch 7.10.2 报错如下(无论是否开启兼容模式):
{
"error": {
"root_cause": [
{
"type": "snapshot_restore_exception",
"reason": "[aos:2/D-oyYSscSdCbZFcmPZa_yg] the snapshot was created with Elasticsearch version [36.34.78-beta2] which is higher than the version of this node [7.10.2]"
}
],
"type": "snapshot_restore_exception",
"reason": "[aos:2/D-oyYSscSdCbZFcmPZa_yg] the snapshot was created with Elasticsearch version [36.34.78-beta2] which is higher than the version of this node [7.10.2]"
},
"status": 500
}
- 从 Easysearch 1.8.2 还原到 Amazon OpenSearch2.13 报错如下(无论是否开启兼容模式):
{
"error": {
"root_cause": [
{
"type": "snapshot_restore_exception",
"reason": "[easy_repository:2/LE18AWHlRJu9rpz9BJatUQ] cannot restore index [my_indexs] because it cannot be upgraded"
}
],
"type": "snapshot_restore_exception",
"reason": "[easy_repository:2/LE18AWHlRJu9rpz9BJatUQ] cannot restore index [my_indexs] because it cannot be upgraded",
"caused_by": {
"type": "illegal_state_exception",
"reason": "The index [[my_indexs/VHOo7yfDTRa48uhQvquFzQ]] was created with version [1.8.2] but the minimum compatible version is OpenSearch 1.0.0 (or Elasticsearch 7.0.0). It should be re-indexed in OpenSearch 1.x (or Elasticsearch 7.x) before upgrading to 2.13.0."
}
},
"status": 500
}
- Amazon OpenSearch 还原到 Easysearch 同样失败
{
"error": {
"root_cause": [
{
"type": "snapshot_restore_exception",
"reason": "[aoss:2/D-oyYSscSdCbZFcmPZa_yg] cannot restore index [aos] because it cannot be upgraded"
}
],
"type": "snapshot_restore_exception",
"reason": "[aoss:2/D-oyYSscSdCbZFcmPZa_yg] cannot restore index [aos] because it cannot be upgraded",
"caused_by": {
"type": "illegal_state_exception",
"reason": "The index [[aos/864WjTAXQCaxJ829V5ktaw]] was created with version [36.34.78-beta2] but the minimum compatible version is [6.0.0]. It should be re-indexed in Easysearch 6.x before upgrading to 1.8.2."
}
},
"status": 500
}
- Elasticsearch 8.14.3 迁移到 Amazon OpenSearch 或者 Elasticsearch 都是有这个报错:
{
"error": {
"root_cause": [
{
"type": "parsing_exception",
"reason": "Failed to parse object: unknown field [uuid] found",
"line": 1,
"col": 25
}
],
"type": "repository_exception",
"reason": "[snap] Unexpected exception when loading repository data",
"caused_by": {
"type": "parsing_exception",
"reason": "Failed to parse object: unknown field [uuid] found",
"line": 1,
"col": 25
}
},
"status": 500
}
这是由于 Elasticsearch 8 在创建快照的时候会默认加上一个 UUID 的字段,所以我们低版本的 Easysearch、Amazon OpenSearch 中会找不到这个字段,在执行GET _cat/snapshots/snap?v
的时候就报错,及时在注册存储库的时候显示加上 UUID 的字段也无事无补。
{
"snapshot-repo-name": {
"type": "s3",
"uuid": "qlJ0uqErRmW6aww2Fyt4Fg",
"settings": {
"bucket": "<bucket-name>",
"base_path": "<bucket-prefix>",
}
},
以下是兼容性对比,每行第一列代表源集群,第一行代表目标集群:
快照兼容对比 | Easysearch 1.8.2 | Elasticsearch 7.10.2 | OpenSearch 2.13 |
---|---|---|---|
Easysearch 1.8.2 | 兼容 | 不兼容 | 不兼容 |
Elasticsearch 7.10.2 | 兼容 | 兼容 | 兼容 |
OpenSearch 2.13 | 不兼容 | 不兼容 | 兼容 |
Elasticsearch 的兼容列表官方的列表如下:
参考文献
-
开始使用 Elastic Stack 和 Docker Compose:第 1 部分
https://www.elastic.co/cn/blog/getting-started-with-the-elastic-stack-and-docker-compose -
Docker Compose 部署多节点 Elasticsearch
https://www.elastic.co/guide/en/elasticsearch/reference/7.10/docker.html#docker-compose-file -
repository-s3 教程
https://www.elastic.co/guide/en/elasticsearch/reference/8.14/repository-s3.html
https://www.elastic.co/guide/en/elasticsearch/plugins/7.10/repository-s3.html -
snapshot-restore
https://www.elastic.co/guide/en/elasticsearch/reference/7.10/snapshot-restore.html -
在亚马逊 OpenSearch 服务中创建索引快照
https://docs.amazonaws.cn/zh_cn/opensearch-service/latest/developerguide/managedomains-snapshots.html#managedomains-snapshot-restore - 教程:迁移至 Amazon OpenSearch Service
https://docs.amazonaws.cn/zh_cn/opensearch-service/latest/developerguide/migration.html
关于 Easysearch 有奖征文活动
无论你是 Easysearch 的老用户,还是第一次听说这个名字,只要你对 INFINI Labs 旗下的 Easysearch 产品感兴趣,或者是希望了解 Easysearch,都可以参加这次活动。
详情查看:Easysearch 征文活动
作者:韩旭,亚马逊云技术支持,亚马逊云科技技领云博主,目前专注于云计算开发和大数据领域。
从 OpenAI 停服看中国市场:国产替代崛起的机遇与挑战
Easysearch • INFINI Labs 小助手 发表了文章 • 0 个评论 • 2535 次浏览 • 2024-07-05 11:50
一、OpenAI 停服事件背景
OpenAI 自 2020 年推出 GPT-3 以来,在全球范围内引起了极大的反响。其强大的自然语言处理能力使其成为许多企业和开发者的首选工具。然而,2024 年 6 月 25 日,许多中国用户收到了一封来自 OpenAI 的邮件,邮件中明确表示,自 2024 年 7 月 9 日起,OpenAI 将停止对中国内地和香港地区提供 API 服务。
这一事件引发了国内开发者和企业的广泛讨论,特别是在人工智能技术应用逐渐深入的背景下,OpenAI 的停服无疑会对中国市场产生一定的影响。在 AI 技术迅猛发展的当下,许多中国企业和开发者依赖 OpenAI 的 API 进行各种应用的开发。尤其是在大模型技术领域,不少初创公司通过“套壳”OpenAI 技术快速推向市场。所谓“OpenAI 套壳”,是指一些公司仅对 OpenAI 的技术进行表面包装和小改动,而未进行深度创新 。OpenAI CEO 山姆·奥特曼曾明确指出,简单包装 OpenAI 技术的公司难以长久生存。此次 API 服务的终止,意味着这些企业需要寻找新的技术支持,或者在短时间内加速自主研发 。
二、国产替代的挑战与机遇
OpenAI 停止对中国提供 API 服务将对国内 AI 行业带来短期冲击,但从长远来看,这也可能成为推动国内 AI 技术自主创新和研发的契机。国内企业将被迫加大自主研发力度,减少对外部技术的依赖,从而推动国产 AI 技术的发展 。虽然目前国内大模型企业在技术上与 OpenAI 存在一定差距,但已有不少公司在不断赶超。例如,百度的文心大模型、科大讯飞的星火大模型以及清华智谱的 ChatGLM 基础模型,都在性能上逐渐逼近甚至超过了 GPT-4 。从现状来看,国内大模型厂商已经逐步进入了性能提升的关键期,应用场景从办公、生活拓展到医疗、工业、教育等领域。
三、Elasticsearch 国产化替代的需求
Elasticsearch(简称 ES)作为一种开源的分布式搜索和分析引擎,以其强大的搜索能力和高效的数据处理能力,广泛应用于各种大数据和搜索相关业务场景。然而,随着国际政治环境的变化和技术壁垒的加剧,依赖国外技术的风险日益凸显。在这种背景下,推动 Elasticsearch 的国产化替代至关重要,既能保障国家信息安全,也能促进国内技术自主创新和产业发展。
首先,依赖国外技术可能带来技术封锁风险,一旦国外企业因政治或经济原因停止服务,中国企业的业务连续性和数据安全性将受到威胁。推动国产化替代有助于规避这些风险,保障数据安全和业务的稳定运行。国外搜索引擎和数据库系统通常为西方市场优化,未必适合中国市场。例如,Elasticsearch 在处理中文信息时需要额外的插件和调整,而国产替代方案可以更好地适应本地化需求,同时确保数据存储和处理符合国家法律法规。
其次,推动 Elasticsearch 的国产化替代有助于激发国内企业的创新活力,减少对国外技术的依赖,提升在搜索和大数据领域的核心竞争力。采用国产替代方案不仅能够降低企业的技术成本,还能构建自主的技术生态系统,减少对外部的依赖。与此同时国产化替代也有助于提升国内技术人才水平,通过自主研发和技术创新培养出高水平的技术人才,推动技术创新和产业升级。
在性能和安全方面,Elasticsearch 在数据保护和性能方面存在不足。开源版本不具备数据保护功能,用户必须付费获得相关的安全功能。2021 年 Elastic 公司将其开源软件许可证变更为双授权许可,可能带来安全风险。此外,Elasticsearch 在数据读写性能和集群扩展上也存在技术挑战,进一步推动了国产替代的需求。
四、Easysearch:国产替代的优秀范例
在 OpenAI 退出中国市场的背景下,国产技术的重要性日益凸显。作为国产搜索引擎技术的代表,Easysearch 展示了强大的替代潜力。
Easysearch 是一款基于国内自主研发的高性能搜索引擎,其核心引擎基于开源的 Apache Lucene。与 Elasticsearch 相比,Easysearch 不仅提供了相当的功能,还进行了更具针对性的优化。
-
轻量级:Easysearch 的安装包小于 50MB,部署安装简单,适合企业快速上手。
-
跨平台支持:Easysearch 支持主流操作系统和 CPU 架构,兼容国产信创环境,确保多样化环境下的稳定运行。
-
高性能:Easysearch 针对不同的使用场景进行了优化,以更低的硬件成本提供更高的服务性能,从而实现降本增效。
-
安全增强:Easysearch 默认提供完整的企业级安全功能,支持 LDAP/AD 集成,能够对索引、文档和字段级别进行粒度化权限管控,确保数据的安全性和隐私性。
-
稳定可靠:Easysearch 修复了大量内核问题,解决了内存泄露、集群卡顿和查询缓慢等问题,经过严苛的业务环境考验,保证了其稳定性和可靠性。
- 简单易用:Easysearch 提供了企业级管理后台,运营标准化和自动化,使用户能够通过简单的页面操作实现专家级的运维管理工作。
Easysearch 特别注重数据安全和隐私保护,所有数据都在国内处理和存储,符合数据主权要求。这对关注数据安全和隐私的企业尤为重要,能够有效保障数据的安全性和合规性。
Easysearch 致力于构建一个开放的技术生态,通过丰富的开发者资源和支持,为国内开发者提供了一个强大的技术平台。
-
兼容性:Easysearch 兼容 Elasticsearch 的语法,支持 Elasticsearch 原有的 Query DSL 和 SQL 语法,并且兼容现有的 Elasticsearch SDK。这样,企业和开发者可以平滑地迁移到 Easysearch,无需修改现有代码。
-
中文适配:Easysearch 在功能上进行了中文适配,能够更好地支持中文搜索和分析,满足本地化需求。
-
功能增强:Easysearch 不断完善和增强企业级功能,使其在搜索业务场景中保持简洁与易用性,同时提升功能的丰富度和深度。
-
信创适配:Easysearch 支持信创环境,确保在国产环境中也能平稳运行和使用。
- 平滑迁移:Easysearch 基于网关实现了无缝的跨版本迁移与升级,用户可以随时安全回退,确保系统的持续稳定性。
Easysearch 作为国产搜索引擎技术的代表,展示了国产替代的强大潜力。通过自主研发和技术创新,Easysearch 不仅提供了强大的功能和性能,还确保了数据安全和隐私保护。它为国内企业和开发者提供了一个可靠的技术平台,推动了国产技术的发展和应用。未来,随着更多国产技术的崛起,中国将在全球技术领域占据更加重要的地位。
五、结束语
随着 OpenAI 服务在国内的终止,中国 AI 市场迎来了自主创新的机遇。国内企业如百度、科大讯飞等正加速自主研发,缩小技术差距。同时,在搜索引擎领域,极限科技推出 Easysearch 搜索引擎为 Elasticsearch 国产替代提供了新的选择。展望未来,国产技术的持续创新将助力中国在全球技术领域占据更重要的地位。
关于极限科技(INFINI Labs)
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
作者:Muses
【搜索客社区日报】第1853期 (2024-07-05)
社区日报 • Fred2000 发表了文章 • 0 个评论 • 2146 次浏览 • 2024-07-05 09:26
搜索型数据库的技术发展历程与趋势前瞻
资讯动态 • INFINI Labs 小助手 发表了文章 • 0 个评论 • 2610 次浏览 • 2024-06-26 13:13
概述
随着数字科技的飞速发展和信息量的爆炸性增长,搜索引擎已成为我们获取信息的首选途径之一,典型的代表厂商如 Google。然而,随着用户需求的不断演变,传统的搜索技术已经无法满足人们对信息的实时性、个性化和多样性的需求。
在企业内部,这种需求更加显著。随着企业数字化转型的持续深化,非结构化数据正日益成为各类组织数据增长的主要来源,也是数据体系中至关重要的组成部分,蕴含着巨大的价值。如何高效地存储和利用非结构化数据的重要性也日益凸显。企业需要更高效地管理和检索内部的海量数据,以支持业务决策和运营需求。
据 IDC 数据预计,到 2025 年,80%的数据将是非结构化数据;而根据 Gartner 的数据显示,从 2019 年到 2024 年,非结构化数据容量预计将增加两倍。然而,目前非结构化数据面临着表现形式多样、管理复杂性高、价值挖掘难度大等诸多挑战。传统的数据库系统往往无法满足企业对实时性和多样性的搜索需求,为了解决这些挑战,以自动分词、倒排索引、相关度计算、向量检索引擎等技术为核心构建的搜索型数据库应运而生。这些数据库自上世纪 90 年代诞生以来不断发展演进,正在成为数据库领域中不可或缺的一个重要分支。
什么是搜索型数据库?
搜索型数据库早期又称全文数据库,或者企业搜索引擎,是一种专门用于存储和管理大规模文本数据,并支持高效的文本搜索和信息检索的数据库系统,不过随着技术不断发展和应用场景日益丰富,目前搜索型数据库不仅仅可以处理长文本数据,也可以处理常见的数值、日期等结构化数据,IP、地理位置信息、图片、音视频等非结构化数据,搜索型数据库的应用范畴不断拓展,正在由支撑业务系统检索加速、IT 运维可观测性、聚合查询分析等向多场景、多模态数据搜索方向发展。
典型的搜索数据库一般具有以下特点:
- 灵活的索引能力:搜索数据库能够处理多种类型的数据,包括文本、图像、音频、视频等非结构化数据。它们采用自动分词、倒排索引等技术,能够高效地处理不同格式和类型的数据,提供灵活的搜索和检索功能。
- 高效的查询性能:搜索数据库具有高效的查询处理能力,能够快速索引和检索大规模的数据。借助优化的索引结构和查询算法,搜索数据库能够在短时间内准确地返回与查询相关的结果,提高用户的搜索效率,常用于解决关系型数据库的高并发检索需求。
- 支持复杂的搜索功能:搜索数据库提供多样化的搜索功能,包括全文检索、模糊搜索、精确搜索、范围搜索、向量搜索、地理信息检索等。用户可以根据不同的需求和场景,灵活地选择和组合不同的搜索功能,以获取符合期望的搜索结果。
- 高性能和可扩展性:搜索数据库具有高性能和可扩展性的特点,能够处理大规模数据和高并发访问。它们采用分布式架构和并行计算技术,实现了水平扩展,能够满足不断增长的数据量和用户访问量的需求。
综上所述,搜索数据库具有处理非结构化数据、实时搜索和更新、多样化的搜索功能、个性化推荐和智能搜索、高性能和可扩展性、全面的搜索结果展示等特点,是处理大规模数据和提供高效搜索服务的重要工具。
搜索型数据库的应用场景
搜索型数据库在各行各业都有广泛的应用,以下是一些典型的应用场景:
- 零售和电商:在零售和电商行业,搜索型数据库被广泛应用于产品搜索和推荐系统中。通过搜索功能,顾客可以轻松查找所需商品,而个性化推荐系统则可以根据用户的搜索历史和行为习惯推荐相关的产品,提高购物体验和交易转化率。
- 医疗保健:在医疗保健行业,搜索型数据库被用于医学文献检索、疾病诊断和药物搜索等方面。医生和研究人员可以利用搜索功能找到相关的医学文献和研究成果,帮助诊断疾病和制定治疗方案。
- 金融服务:在金融服务行业,搜索型数据库被用于金融数据检索、市场分析和投资决策等方面。投资者可以通过搜索功能查找相关的金融数据和市场资讯,帮助他们做出更加准确的投资决策。
- 制造业:在制造业中,搜索型数据库被用于生产过程监控、质量控制和故障诊断等方面。工程师可以利用搜索功能查找相关的生产数据和技术资料,帮助他们解决生产中的问题和挑战。
- 媒体和娱乐:在媒体和娱乐行业,搜索型数据库被用于内容检索、版权管理和用户推荐等方面。用户可以通过搜索功能查找感兴趣的新闻、音乐和视频等内容,而个性化推荐系统则可以根据用户的搜索历史和偏好推荐相关的内容。
- 教育和培训:在教育和培训行业,搜索型数据库被用于学习资源检索、课程管理和学习分析等方面。学生和教师可以利用搜索功能查找相关的学习资源和课程内容,而学习分析系统则可以分析学生的搜索行为和学习表现,为教学提供参考和支持。
- IT 运维可观测性:通过搜索型数据库,可以实时监控系统的运行状况、性能指标和日志数据,帮助运维团队及时发现和解决系统故障、性能问题和异常情况,确保系统的稳定运行。
- 安全监测和威胁检测:利用搜索型数据库对系统的安全日志进行审计和监控,监测用户的访问行为和系统操作,及时发现异常行为和安全事件。同时,搜索型数据库还可以与威胁情报数据集成,对内部日志数据进行关联分析,快速识别并应对各种安全威胁和攻击行为,保障系统和数据的安全。
综上所述,搜索型数据库在各行各业都发挥着重要作用,数据规模从 GB 到 PB 不等,体现在生活中的方方面面,为用户提供了高效、准确和个性化的信息搜索和检索服务,推动了各行业的发展和进步。随着搜索技术的不断创新和发展,搜索型数据库在各行业中的应用将会越来越广泛,并持续为用户带来更加便捷和智能的搜索体验。
搜索型数据库的发展历程
搜索型数据库的发展历程可以概括如下四个阶段:
- 起步阶段(1990 年代):搜索数据库的雏形开始于上世纪 90 年代,当时以全文检索为主要技术手段,最初用于文档检索和网络搜索。典型代表包括 AltaVista、Excite 等。
- 技术突破(2000 年代):随着互联网的快速发展,搜索数据库开始应用于更多领域,如电子商务、社交网络等。Lucene、Sphinx 等开源搜索引擎的出现推动了搜索技术的进步。
- 商业化发展(2010 年代):搜索数据库进入商业化阶段,以 Elasticsearch 等为代表的商业搜索引擎崭露头角。企业开始大规模应用搜索数据库来管理和检索大量数据。
-
智能化转型(2020 年代):随着人工智能技术的发展,搜索数据库逐渐向智能化转型,开始引入机器学习、自然语言处理等技术,提供个性化推荐和智能搜索服务。同时,搜索数据库也在更多领域得到应用,如医疗保健、金融服务等。
综上所述,搜索数据库经历了从起步阶段到技术突破、商业化发展再到智能化转型的发展历程,表明了其在信息检索领域的重要性和不断演进的趋势,不并断推动着搜索技术的进步和应用范围的扩展。随着人工智能技术的不断成熟,搜索数据库将会在智能化、个性化等方面取得更大的进步,为用户提供更加优质的搜索体验。
搜索型数据库的发展情况
搜索型数据库市场上已经有不少成熟的产品和厂商,但是总的来说,搜索型数据库的界限范围有点模糊,当然其他数据库也有同样的问题,有很多数据库既是文档数据库,又是多模态数据库,还是向量数据库等等,而常见的搜索型数据库主要诞生于:
- 由搜索引擎内核库发展而来的搜索数据库,如 Elasticsearch
- 由其他数据库扩展而来的搜索数据库,如 Postgres Full-Text Search
- 从零开始整体设计的搜索数据库:如 INFINI Pizza
通过流行的 DB-Engines 的搜索引擎排行榜,可以初探国外主流的搜索型数据库的流行趋势,如下图:
可以看到 Elastic 公司的 Elasticsearch 还是依旧保持强悍,自从 Elasticsearch 十多年前掀翻了 Splunk 的桌子,硬生生的在日志领域杀出一条新路,随后大杀四方,碾压整个搜索行业,霸榜至今。Elastic 商业化增长稳健,2023 年收入超过 10 亿美金。
OpenSearch 是由 AWS 发起的 Elasticsearch 开源分支,起因是由于 Elastic 针对云厂商采取的协议变更为 Elastic+SSPL,OpenSearch 基于 Apache 2.0 协议的 Elasticsearch 7.10 版本衍生而来,目前也具备了一定的用户基础。
Splunk 是一款用于搜索、监控和分析大规模机器生成的数据的软件平台,主要用于日志和安全分析领域,属于商业闭源产品。2023 年中被思科(Cisco) 以 230 亿美元现金收购,瞬间刷爆朋友圈。另外有意思的是,前四名除了 Splunk,底层都是 Lucene 内核。
MarkLogic 成立于 2001 年,自我定位是一个 NoSQL 多模态数据库厂商,也是商业闭源软件,生态成熟但是系统过于复杂,学习曲线较陡, 2023 年初被 Progress Software 以 3.55 亿美元收购算是一个比较好的结局。
当然了,除了榜上的这些产品,还有很多优秀的挑战者正摩拳擦掌,跃跃欲试。如下面的这些项目: vespa、Rockset、Doris,Clickhouse、quickwit、Pinot、SingleStore、qdrant、milvus、algolia、meilisearch、typesense、Manticore Search 等等。这些项目不一定都是自己定位是搜索型数据库,有侧重在 AI 领域的,有侧重在实时分析领域的等等,可谓各有千秋,不过都具备一定的搜索和分析能力,不出意外,基本上每家都要号称吊打 Elasticsearch 一番。
国内搜索型数据库的发展情况
搜索型数据库已经成为企业事实上的重要基础设施,而国内搜索型数据库的发展近些年也是开始得到重视,2023 年初,由中国信通院云计算与大数据研究所牵头,依托中国通信标准化协会大数据技术标准推进委员会,联合拓尔思、极限科技、星环科技等 30 余家企业编制的《搜索型数据库技术要求》正式出炉,该标准已成为行业内搜索型数据库技术选型和产品开发的风向标,极限科技的 INFINI Easysearch 率先通过了该标准。
墨天轮社区也开辟了搜索型数据库的排行榜,共有 6 家企业的产品上榜:
国内搜索型数据库的市场还在起步阶段,厂商和可选的产品也还比较少,不过随着市场的成熟,相信未来将迎来一波高速的发展。
搜索型数据库的趋势前瞻
技术在演变,场景在演变,数据也在演变,搜索数据库领域的发展也呈现出多个显著的趋势,这些趋势将进一步推动搜索技术的演进和应用范围的扩展。笔者观测到的主要的发展趋势包括以下方向供参考:
1. 趋势一:实时搜索与分析
-
实时搜索是搜索数据库领域的一个重要发展趋势,业务应用都在朝实时方向演进,用户对信息的即时性需求不断增加,要求搜索结果能够及时反映最新的数据和内容。
-
实时搜索技术通过实时索引和实时更新机制,能够实现快速的数据检索和更新,提供与时俱进的搜索结果,满足用户对信息的即时性需求。
- 目前以 Lucene 为内核的搜索型数据库基本上都只能做到 NRT(近实时)搜索,并且频繁更新带来的挑战和资源的浪费比较高,如果能做到更高效的实时性,可以大大提升用户的搜索体验和实时决策能力。
2. 趋势二:多模态混合搜索
-
多模态搜索是指在搜索过程中同时考虑多种信息形式,如文本、图像、视频等,以提高搜索结果的准确性和全面性。
-
这种技术能够通过分析和理解多种信息形式之间的关联性,为用户提供更加全面、丰富的搜索结果,适用于需要综合不同媒体形式的搜索场景。
- 现实世界的数据越来越复杂化,非结构化数据的利用的场景也越来越多,多模态可以为业务提供更加灵活的分析和探索能力,混合搜索的能力非常具有吸引力。
3. 趋势三:AI 智能语义搜索
-
大模型、AI 智能搜索技术的探索可谓是一日千里,通过利用人工智能技术来实现搜索过程中的智能化、语义化和个性化,结合自然语言处理、机器学习等技术分析用户意图,提供更加智能、个性化的搜索服务。
-
随着大模型的兴起,搜索数据库开始采用像 RAG(Retriever-Reader for Generative Question Answering)这样的大型预训练模型来提升搜索的效果。RAG 模型结合了检索器和阅读器的功能,能够实现更加准确和全面的搜索结果,为用户提供更加智能和个性化的搜索服务。
- 搜索型数据库可谓是 AI 落地最好的是试验田,Elasticsearch 通过拥抱 AI 和大模型,目前股价又重回巅峰,可喜可贺。
4. 趋势四:云原生、存算分离、Serverless
-
随着云计算技术的发展,搜索数据库正逐渐向云原生架构转变。云原生搜索数据库利用容器化、微服务架构等技术,实现了更高的灵活性、可扩展性和容错性,为企业提供了更加稳定和高效的搜索服务,并且成本更低,更加弹性。
-
存算分离是搜索数据库发展的另一重要趋势。通过将存储与计算分离,搜索数据库可以更好地适应数据存储和计算需求的变化,提高系统的性能和效率。存算分离技术使得搜索数据库能够实现更高的并发访问和更快的数据处理速度,为用户提供更加流畅和稳定的搜索体验。
- Serverless 提供开箱即用的体验,成本更低,使用更加灵活,也是目前很多搜索服务提供商正在积极探索的方向。
5. 趋势五:增强现实搜索
- 随着增强现实技术的发展,尤其是 Apple 发布的头戴式 Vision Pro,一部革命性的空间运算设备,将数位内容无缝融入实体世界,而搜索技术也将逐渐与增强现实相结合,为用户提供更加直观和沉浸式的搜索体验。增强现实搜索能够将搜索结果与现实世界相结合,结合 AI 技术为用户提供更加个性化和便捷的搜索服务,这是一个全新的领域,也意味着巨大的机会。
6. 趋势六:现代硬件的高效利用
-
现代硬件及软件运行环境已发生翻天覆地的变化, 片上计算,边缘计算,FPGA,DPU,GPU,一台设备几百核上 TB 内存已经成为现实,可运行之上的软件却还是停留在几十年前的架构。 如 Elasticsearch 其核心 Lucene(及类似实现) 是在 1997 建立的,距今已有 27 年了,虽然也在与时俱进,但是部分架构和设计理念已不具备先进性。
- 在现代的硬件上采用更先进的算法,更新的数据结构、更新的设计理论,利用最新的 CPU 指令集,向量化,批处理,充分发挥多核、大内存和 SSD 的优势,从而达到更高的效率,更低的成本,去解决之前不可能实现的问题,大有可为,也是下一代引擎需要关注的方向。
随着各类数据库功能的边界越来越模糊,应用场景高度交叉重叠,市场竞争也变得白热化,不过笔者认为垂直领域的搜索型数据库机会还是很大,而想做大而全的数据库产品已经没有太多的市场生存空间,一定要在垂直领域有特别专注的地方,我们 INFINI Labs 正在基于 Rust 研发的下一代搜索引擎 INFINI Pizza,就侧重于面向终端用户场景,解决海量数据更新情况下,同时满足高并发和低延迟的核心业务实时检索需求。
总结
综上所述,搜索数据库领域正处于快速发展的阶段。随着互联网数据量的不断增长和用户需求的不断变化,搜索数据库技术将不断创新和进步,以满足用户对信息获取的更加即时、个性化和多样化的需求。未来,随着人工智能技术的进一步发展和应用,搜索数据库将会变得更加智能化、普及化和多样化,为用户提供更加高效、准确和个性化的搜索服务,推动互联网信息的更加便捷获取和利用。
关于极限科技(INFINI Labs)
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
极限网关助力好未来 Elasticsearch 容器化升级
Elasticsearch • INFINI Labs 小助手 发表了文章 • 0 个评论 • 3304 次浏览 • 2024-06-12 15:01
极限网关在好未来的最佳实践案例,轻松扛住日增百 TB 数据的流量,助力 ES 从物理机到云原生架构的改造,实现了流控、请求分析、安全管理、无缝迁移等场景。一次完美的客户体验~
背景
物理机架构时代
2022 年,好未来整个日志 Elasticsearch 拥有数十套服务集群,几百台物理机。这么多台机器耗费成本非常高,而且还要花费很大精力去维护。在人力资源有限情况下,存在非常多的弊端,运行成本高,不仅是机器折旧还有机柜等费用。
流量特征
这是来自某个业务线,如下图 1,真实流量,潮汐性非常明显。好未来有很多条业务线,几乎跟这个趋势都一致的,除了个别业务有“续报”、“开课”等活动特殊情况。潮汐性带来的问题就是高峰期 CPU、内存资源是可以消耗很高;低峰期资源使用量非常低,由于是物理架构,这些资源无法给其他业务线共享。
降本增效-容器化改造原动力
日志服务对成本的空前的压力促使我们推进 Elasticsearch 进行架构改造;如何改造,改造成什么样子,这两个问题一直是推进改造原动力。业界能够同时对水平扩展和垂直扩展就是 K8S,我们开始对 Elasticsearch 改造成能在 K8S 上运行进行探索,从而提升 CPU、内存利用率。
物理机时代,没办法把资源动态的扩缩,动态调配,资源隔离,单靠人力操作调度成本太高,几乎无法完成;集群对内存资源需求要比 CPU 资源大很多,由于机器型号配置是固定的,无法“定制”,这也会导致成本居高不下。所以,无论从那个方面来讲,容器化优势非常明显,既能够优化成本,也能够降低运维复杂度。
ES 容器化改造
进行架构升级重点难点- API 服务
改造过程,我们遇到了很多问题,比如容器 ES 版本和物理机 ES 版本不一致,如何让 ES API 能够兼容不同的 ES 版本,由于版本的不兼容,导致无法直接使用原有的 tribenode 进行服务,怎么提供一个高可用的 Elasticsearch API 服务。我们考虑到多个方面,比如使用官方推荐的 proxy 模式、第三方服务等进行选择,经过多方面对比,选择了极限网关 进行 tribenode 替换。
原始 ES API 服务痛点
- API 访问没有流量控制
- 可观测性差,而且稳定性一般
- 版本兼容性差
物理机时代 API 架构
在物理机时代 ES 集群,API 架构如图 2,可以明显看到 tribe node 对所有 ES 集群的“侵入性”是非常大的,这就带来了很多问题,比较严重的就是单个集群对 ES tribenode 的影响和版本升级带来的不兼容问题。
混合时代 API 架构
通过图 3,我们可以看到,极限网关对于版本兼容性很好,能够适配不同的版本。因此,最终选择极限网关作为下一代 ES API 服务方。
里程碑:全部 ES 集群容器化
在 2023 年 3 月份,通过 Elastic 官方 ECK 模式,完成全部日志 ES 集群容器化改造,拥有数百节点,1PB+ 数据存储,每日新增数据 100T 左右。紧接着,除了日志服务外,同时支持了好未来多条业务线。
极限网关实践
下面主要讲述了,为什么选择极限网关,以及极限网关在好未来落地、应用这些内容。
为什么选择极限网关?
学习成本低
我们可以从文档中看到极限网关,其架构简洁,语法简单,直观易懂。学习成本比较低,上手非常快,对新手友好。
性能强悍
经过压测,发现极限网关速度非常快,且针对 Elasticsearch 做了非常细致的优化,能成倍提升写入和查询的速度。
安全性高
支持多种认证方式,最简单的账号密码认证,可以给自定义多个账户密码,大大简化了 Elasticsearch 的安全设置,同时,还可以支持 LDAP 安全验证。
跨版本支持
我们容器化改造过程需要兼容不同版本的 Elasticsrearch,极限网关针对不同的 Elasticsearch 版本做了兼容和针对性处理,能够让业务代码无缝的进行适配,后端 Elasticsearch 集群版本升级能够做到无缝过渡,降低版本升级和数据迁移的复杂度,非常匹配我们的业务场景。
灵活可扩展
可灵活对每个请求进行干预和路由,支持路由的智能学习,内置丰富的过滤器,通过配置动态修改每个请求的处理逻辑,也支持通过插件来进行扩展,满足我们对流量的控制,尤其是限流、用户、IP 等这些功能非常实用。
启用安全策略-为 API 服务保驾护航
痛点
在升级之前使用 tribe 作为 API 服务提供后端,几乎相当于裸奔,没有任何认证策略;另外,tribe 本身的稳定性也有问题,官方在新版本逐渐废弃这种 CCS(跨集群搜索),期间出现多次服务崩溃。
极限网关解决问题
极限网关通过,“basic_auth” 插件,提供最基本的安全校验,使用起来非常方便;同时,极限网关提供 LDAP 插件,可以接入公共的 LDAP 服务,对所有的访问用户进行校验,安全策略对所有的用户生效,不用担心因为 IP 问题泄漏数据等。
强大的过滤功能
在使用 ES 集群过程中,许多场景,需要对请求进行控制、限制等操作。在这方便,感受到了极限网关强大的产品力。比如下面的两个场景
对异常流量进行限流
- 支持对 IP 限流
- 支持对 hostname 限流
- 支持 header 限流
对异常用户进行封禁
当 Elasticsearch 是通过 Basic Auth 或者 LDAP 方式来进行身份认证的时候,request_user_filter
过滤器可用来按请求的用户名信息来进行过滤。操作起来也非常简单,只需要 request_user_filter
这一个过滤器。
- request_user_filter:
include:
- "elastic"
exclude:
- "Ryan"
总结来讲,主要有这些方面的功能:
优秀的可观测性
痛点
改造前经常为看不到直观的数据指标感到头疼,查看指标需要多个地方同时打开,去筛选,查找,非常繁琐,付出的成本非常大。为此,大家都再考虑如何优化这种情况,无奈优先级比较低,一直没有真正的投入时间去优化这块。
完美解决
使用了极限网关,通过收集请求日志,非常清晰的收集到想要的数据,具体如下:
- 总体方面:
- 流量曲线
- 状态码占比
- 缓存统计
- 每台网关请求流量
- 细节方面:
- 打印每次请求语句
- 可以查看请求到具体 ES 节点流量
- 可以查看过滤器的列表
通过下图,我们可以从管理视角直观的看到各种信息,这对于管理员来讲,省时省力,方便快捷。
意外收获:无缝迁移业务 Elasticsearch 上云
由于前期日志业务上云,受到非常好的反馈,多个业务线期望能够上云上服务,达到降本增效的目的。
支持双写
数据可以通过极限网关同时写入两个 ES 集群,能够保障数据完全一致,安全可靠。
无缝切换
切换很丝滑,影响非常小,能够让外界几乎感受不到服务波动。
通过使用极限网关,自建 ES 集群可以无缝的迁移上云,在整个迁移的过程中,两套集群通过网关进行了解耦,在迁移的过程中还能实现版本的无缝升级,极大降低了迁移成本,提高迁移效率,多次验证服务稳定可靠。
极限网关流量概览
这是其中一套极限网关的流量统计。用这部分数据进行巡检,一目了然,做到全局的掌控,提高感知力度。
极限网关使用总结
极限网关提供一系列高性能和高可靠性的网关服务。使用这样的服务给我们带来以下好处:
- 可观测性好:极限网关可以动态的对 Elasticsearch 运行过程中请求进行拦截和分析,通过指标和日志来了解集群运行状态,这些指标可以用于提升性能和业务优化。
- 增强安全性:包含先进的安全机制,如 basicauth、LDAP 等支持,保护用户数据不受未授权访问和各种网络威胁的侵害。
- 高稳定性:通过冗余设计和故障转移机制,极限网关能够确保网络服务的高可用性,即使在某些组件发生故障时也能保持服务不中断,单版本最长服务超过 15 个月。
- 易于管理:通过提供 INFINI Console 简洁直观的管理界面,让用户能够轻松配置和监控网络状态,提升管理效率。
- 客户支持:良好的客户服务支持可以帮助用户快速解决使用过程中遇到的问题,提供专业的技术指导。
综上所述,极限网关为用户提供了一个高速、安全、稳定且易于管理的 ES 网关,适合对网络性能有较高要求的个人和企业用户。
未来规划
第一阶段,完成了日志 ES 集群,所有集群的容器化改造,合并,成功的把成本降低了 60%以上。这期间积累了丰富容器化经验,为业务 ES 集群上容器做了良好的铺垫;成本优势和运维优势吸引越来越多的业务接入到容器化 ES 集群。
提升 ES 集群效能--新技术应用&&版本升级
- 极限科技官方推荐的 Easysearch 在压缩率,查询速度等等方面有很多的优势,通过长时间的测试稳定性,新特性,对比云原生的 ES 集群,根据测试结果,给“客户”提供多种选择,这也是工作重点之一。
- 我们当前使用的 ES 版本是 6.8,已经远远落后于官方版本,今年我们计划在选择合适的集群升级 ES 版本,拥抱更多官方提供的特性。
混合(多)云架构支持
随着越来越多的 ES 集群在机房的 K8S 集群部署,这里资源出现了紧张局面。 我们尝试在云上部署自建 ES 集群,弥补机房资源有限,无法大规模扩容,同时能够支持多活场景,满足更多客户的不同需求。混合云主要实现以下几种能力:
1、扩缩容:满足不同业务灵活适配
混合(多)云部署,可以让负载内部私有云 ES,同时部署到公有云,提升扩展 IT 基础设施不仅局限于 CPU、内存,还有存储。比如某一个业务要做活动,预估流量“大爆发”,需要提前准备大规模资源,在机房内根本来不及采购扩容支持,然而在公有云上就能很方便扩容、缩容。在云上搭建 ES 集群,设置满足需求的数量、容量、配置,配合极限网关路由策略,精准的把控流量流向。
2、灾备:紧急情况快速部署,恢复 ES 集群读写
当机房级别大规模故障,部分业务实现了多活,单一的机房故障不会影响其服务能力,而此时比如日志查看等仍有需求,为了满足这部分“客户”需求,可以在云上 K8S 集群,快速搭建 ES 集群,恢复日志读写功能。
参考文档:
- https://infinilabs.cn/docs/latest/gateway
- https://www.elastic.co/guide/en/cloud-on-K8S/current/K8S-overview.html
作者:张华勋,前新浪 CDN 研发,工作主要涉及 Mysql、MongoDB、Redis、Elasticsearch、流量调度等组件和系统,以及运维自动化、平台化等工作。现就职于好未来。
关于好未来
好未来(NYSE:TAL)是一家以内容能力与科技能力为基础,以科教、科创、科普为战略方向,助力人的终身成长,并持续探索创新的科技公司。 好未来的前身学而思成立于 2003 年,2010 年在美国纽交所正式挂牌交易。好未来以“爱与科技助力终身成长”为使命,致力成为持续创新的组织。更多参见:https://www.100tal.com/
关于极限科技(INFINI Labs)
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
【搜索客社区日报】第1834期 (2024-06-07)
社区日报 • Fred2000 发表了文章 • 0 个评论 • 2222 次浏览 • 2024-06-09 12:34
[搜索客社区日报】第1825期(2024-05-27)
社区日报 • Muses 发表了文章 • 0 个评论 • 2706 次浏览 • 2024-05-26 20:27
【搜索客社区日报】 第1824期 (2024-05-24)
社区日报 • searchkit 发表了文章 • 0 个评论 • 2608 次浏览 • 2024-05-24 13:17
从 Redis 开源协议变更到 ES 国产化:一次技术自主的机遇
Easysearch • Muses 发表了文章 • 0 个评论 • 4974 次浏览 • 2024-04-11 16:05
引言
近日,Redis Labs 宣布其主导的开源项目 Redis 将采用双重源代码可用许可证(RSALv2)和服务器端公共许可证(SSPLv1)。这一重大决策标志着 Redis 从传统的 BSD 许可证向更加严格的控制权转变,同时也引发了广泛的社区和行业讨论。这不仅是一个关于许可证变更的故事,更是关于开源社区如何响应,以及这一变化如何激发对国产技术探索和发展的深刻思考。Redis,作为最受欢迎的开源键值存储数据库之一,其开源协议的变更反映了开源软件在商业化道路上的挑战和压力。Redis Labs 的 CEO Rowan Trollope 指出,这一变化旨在防止云服务提供商免费使用 Redis 代码,同时促进 Redis 社区的可持续发展和创新。
Redis 协议变更的深远影响
Redis 决定放弃 BSD 协议,转而采用双重源代码可用许可证(RSALv2 和 SSPLv1),标志着开源界的一个重要转折点。这一变化不仅影响了 Redis 本身,更引发了社区成员和技术行业的激烈讨论,许多人担心这将限制 Redis 的开源精神和广泛应用。然而,也有声音认为,这为其他开源项目,如 KeyDB、Dragonfly 和 Garnet 等,提供了发展的机遇,尤其是在提供与 Redis 兼容的替代解决方案方面。尽管 Redis 的这一变更在技术和法律上引发了争议,它也激发了开源社区对于如何在维护开源精神和寻求商业可持续性之间找到平衡的探索。此外,Redis 团队对于保持客户端库的开源许可和继续支持开源社区版的承诺,展示了一种尝试在新的许可模式下保持开放性和可接入性的方法。由于 Redis 的广泛应用,其协议变更对云服务商、Linux 发行版,甚至整个开源软件生态都产生了不小的冲击。一方面,云服务提供商需要重新评估其服务模型;另一方面,一些 Linux 发行版可能需要考虑将 Redis 从其软件仓库中移除。
ES 国产化的契机
Redis 开源协议的变更同时也让人们重新审视其他关键技术,特别是 Elasticsearch(ES)的依赖和发展。ES 作为一个强大的搜索和数据分析引擎,在全球范围内被广泛使用。随着对开源项目商业化模式的重新考量,中国开发者和企业开始寻求国产化的 ES 替代品,旨在减少对外部技术的依赖,同时推动国内技术生态的多元化和自主创新。但是国产化的探索并非没有挑战。从技术兼容性、性能优化到社区生态建设,每一步都需要深思熟虑和持续的努力。然而,Redis 的许可证变更为国内技术自主提供了一个独特的视角,鼓励开发者、企业乃至政府机构更加积极地参与到开源技术的本土化和创新中来。Redis 开源协议的变更引发的讨论和行动,凸显了开源社区对于自身未来发展方向的深刻反思。这一变革不仅关乎一个项目的许可模式转变,更触及到开源项目如何在保持开放和自由的同时,寻找到可持续发展的道路。此外,它也促使更多的开源项目和企业思考如何在全球化的技术生态中保持竞争力和影响力。
Easysearch:国产化的新选择
针对这一需求,极限科技 隆重推出了 Easysearch 搜索引擎软件,旨在提供一个与 Elasticsearch 兼容的国产化解决方案。Easysearch 不仅支持原生 Elasticsearch 的 DSL 查询语法,还提供了诸多企业级功能的增强,如更高的性能、稳定性和扩展性,以及更加丰富的安全管理和数据压缩功能。这表明,国产化技术的发展不仅是为了替代,更是在原有基础上进行创新和优化。ES 国产化解决方案 Easysearch 的推出,是响应国家对信创、自主可控战略布局的具体行动。通过提供兼容性强、功能丰富且稳定的国产技术替代品,不仅有助于减少对外部技术的依赖,也为国内技术生态的繁荣和创新贡献力量。这一过程中,既涵盖了对现有技术的深入理解和应用,也包含了对新技术、新方法的探索和实践。
结语
Redis 开源协议的变更和 Elasticsearch 国产化解决方案的兴起,共同反映了当前技术世界中开源与商业、国际与国产之间复杂而微妙的关系。这一趋势不仅仅是技术领域的变化,更是全球化背景下,各国在技术自主、安全与发展方面所做出的战略性调整。随着更多开源项目和技术面临类似的挑战,我们或许可以预见,技术自主和开源创新将成为推动未来技术发展的两大关键力量。
参考
- https://redis.com/blog/redis-adopts-dual-source-available-licensing
- https://www.elastic.co/cn/blog/licensing-change
- https://infinilabs.cn/products/easysearch
- https://infinilabs.cn/blog/2024/elasticsearch-alternative
- https://infinilabs.cn/blog/2023/the-first-to-complete-the-evaluation-of-search-database-products
关于极限科技(INFINI Labs)
极限科技,全称极限数据(北京)科技有限公司,是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室(INFINI Labs)致力于打造极致易用的数据探索与分析体验。
极限科技是一支年轻的团队,采用天然分布式的方式来进行远程协作,员工分布在全球各地,希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选,为中国技术品牌输出添砖加瓦。
记某客户的一次 Elasticsearch 无缝数据迁移
Elasticsearch • yangmf2040 发表了文章 • 0 个评论 • 4623 次浏览 • 2024-04-02 14:16
背景
客户需要将 Elasticsearch 集群无缝迁移到移动云,迁移过程要保证业务的最小停机时间。
实现方式
通过采用成熟的 INFINI 网关来进行数据的双写,在集群的切换恢复过程中来记录数据变更,待全量数据恢复之后再追平后面增量数据,追平增量之后,进行校验确保数据一致再进行流量的切换。
总体流程
总体迁移流程如下:
- 客户业务代码,切流量,双写。(新增的变更都会记录在网关本地,但是暂停消费到移动云)
- 暂停网关移动云这边的增量数据消费。
- 迁移 11 月的数据,快照,快照上传到 S3;
- 下载 S3 的文件到移动云。
- 恢复快照到移动云的 11 月份的索引。
- 开启网关移动云这边的增量消费。
- 等待增量追平(接近追平)。
- 按照时间条件(如:时间 A,当前时间往前 30 分钟),验证文档数据量,Hash 校验等等。
- 停业务的写入,网关,腾讯云的写入(10 分钟)。
- 等待剩余的增量追完。
- 对时间 A 之后的,增量进行校验。
- 切换所有流量到移动云,业务端直接访问移动云 ES。
总体的迁移时间:
- 11 月备份时间(30 分钟)19 号开始
- 备份下载到移动云的时间(2-3 天)
- 备份恢复到移动云集群的时间(30 分钟)
- 11 月份增量备份(20 分钟)(双写开始)(21 号)
- 11 月份增量下载到移动云(6 小时)
- 11 月份增量恢复时间(20 分钟)
- 追增量数据(8 个小时产生的数据,需要 1 个小时)
- 校验比对(存量 1 个小时)
- 流量暂停,增量的校验(10 分钟)
- 切换(1 分钟)
总体流程如下示意图:
ES 集群信息
- ES 版本 7.10.1
- 2个热节点 3个温节点 总数 1.9 TB
- 索引 1041, 分片2085
- 无自定义插件
- 有 update_bu_query 使用
- 有 delete_by_query 使用
- 吞吐量没有测试过,当前日增文档数 1 千多万,目标日增加上亿
迁移操作手册(参考)
环境
- 自建 ES 5.4.2
- 自建 ES 5.6.8
- 自建 ES 7.5.0
- 极限网关服务器 1
- 极限网关服务器 2
- 云端负载均衡 1 (监听 9200 端口,指向极限网关服务器 1/2 的 8000 端口)
- 云端负载均衡 2 (监听 9200 端口,指向极限网关服务器 1/2 的 8001 端口)
场景描述
若干个自建 Elasticsearch 集群需要平滑迁移到移动云,业务不停写、不做代码改动。
数据架构
通过将应用端流量走网关的方式,请求同步转发给自建 ES,网关记录所有的写入请求,并确保顺序在云端 ES 上重放请求,两侧集群的各种故障都妥善进行了处理,从而实现透明的集群双写,实现安全无缝的数据迁移。 业务端如果已经部署在云上,可以使用云上的 SLB 服务来访问网关,确保后端网关的高可用,如果业务端和极限网关还在企业内网,可以使用极限网关自带的 4 层浮动 IP 来确保网关的高可用。
数据描述
以数据从自建集群 5.4.2 迁移到云上的 5.6.16 为例进行说明,执行步骤依次说明。
执行步骤
部署 INFINI Gateway
为了保证数据的无缝透明迁移,通过 INFINI Gateway 来进行双写。
-
系统调优
参考此文档。
- 下载程序
[root@iZbp1gxkifg8uetb33pvcoZ ~]# mkdir /opt/gateway [root@iZbp1gxkifg8uetb33pvcoZ ~]# cd /opt/gateway/ [root@iZbp1gxkifg8uetb33pvcoZ gateway]# wget http://release.infinilabs.com/gateway/snapshot/gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz --2022-05-19 10:16:25-- http://release.infinilabs.com/gateway/snapshot/gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz 正在解析主机 release.infinilabs.com (release.infinilabs.com)... 120.79.205.193 正在连接 release.infinilabs.com (release.infinilabs.com)|120.79.205.193|:80... 已连接。 已发出 HTTP 请求,正在等待回应... 200 OK 长度:7430568 (7.1M) [application/octet-stream] 正在保存至: “gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz”
100%[==============================================================================================================================================>] 7,430,568 22.8MB/s 用时 0.3s
2022-05-19 10:16:25 (22.8 MB/s) - 已保存 “gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz” [7430568/7430568])
[root@iZbp1gxkifg8uetb33pvcoZ gateway]# tar vxzf gateway-1.6.0_SNAPSHOT-649-linux-amd64.tar.gz gateway-linux-amd64 gateway.yml sample-configs/ sample-configs/elasticsearch-with-ldap.yml sample-configs/indices-replace.yml sample-configs/record_and_play.yml sample-configs/cross-cluster-search.yml sample-configs/kibana-proxy.yml sample-configs/elasticsearch-proxy.yml sample-configs/v8-bulk-indexing-compatibility.yml sample-configs/use_old_style_search_response.yml sample-configs/context-update.yml sample-configs/elasticsearch-route-by-index.yml sample-configs/hello_world.yml sample-configs/entry-with-tls.yml sample-configs/javascript.yml sample-configs/log4j-request-filter.yml sample-configs/request-filter.yml sample-configs/condition.yml sample-configs/cross-cluster-replication.yml sample-configs/secured-elasticsearch-proxy.yml sample-configs/fast-bulk-indexing.yml sample-configs/es_migration.yml sample-configs/index-docs-diff.yml sample-configs/rate-limiter.yml sample-configs/async-bulk-indexing.yml sample-configs/elasticssearch-request-logging.yml sample-configs/router_rules.yml sample-configs/auth.yml sample-configs/index-backup.yml
3. 修改配置
将网关提供的示例配置拷贝,并根据实际集群的信息进行相应的修改,如下:
[root@iZbp1gxkifg8uetb33pvcoZ gateway]# cp sample-configs/cross-cluster-replication.yml 5.4.2TO5.6.16.yml
首先修改集群的身份信息,如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/3.png)
然后修改集群的注册信息,如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/4.png)
根据需要修改网关监听的端口,以及是否开启 TLS (如果应用客户端通过 http 协议访问 ES,请将entry.tls.enabled 值改为 false),如下:
![](https://www.infinilabs.com/img/blog/2024/seamless-data-migration/5.png)
不同的集群可以使用不同的配置,分别监听不同的端口,用于业务的分开访问。
4. 启动网关
启动网关并指定刚刚创建的配置,如下:
[root@iZbp1gxkifg8uetb33pvcoZ gateway]# ./gateway-linux-amd64 -config 5.4.2TO5.6.16.yml
/ \ /\ / \/\/ / /\ \ \/\ /_/\ / /\///\ / /\/\ \ \/ \/ //\_ / / /\/ \/ / // \ /\ / \/ \ ___/\/ \/\/ \/ \/ \/_/ _/_/
[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway. [GATEWAY] 1.6.0_SNAPSHOT, 2022-05-18 11:09:54, 2023-12-31 10:10:10, 73408e82a0f96352075f4c7d2974fd274eeafe11 [05-19 13:35:43] [INF] [app.go:174] initializing gateway. [05-19 13:35:43] [INF] [app.go:175] using config: /opt/gateway/5.4.2TO5.6.16.yml. [05-19 13:35:43] [INF] [instance.go:72] workspace: /opt/gateway/data1/gateway/nodes/ca2tc22j7ad0gneois80 [05-19 13:35:43] [INF] [app.go:283] gateway is up and running now. [05-19 13:35:50] [INF] [actions.go:358] elasticsearch [primary] is available [05-19 13:35:50] [INF] [api.go:262] api listen at: http://0.0.0.0:2900 [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [backup] hosts: [] => [es-cn-tl32p9fkk0006m56k.elasticsearch.aliyuncs.com:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [backup] hosts: [] => [es-cn-tl32p9fkk0006m56k.elasticsearch.aliyuncs.com:9200] [05-19 13:35:50] [INF] [reverseproxy.go:261] elasticsearch [primary] hosts: [] => [192.168.0.19:9200] [05-19 13:35:50] [INF] [entry.go:322] entry [my_es_entry/] listen at: https://0.0.0.0:8000 [05-19 13:35:50] [INF] [module.go:116] all modules are started
5. 后台运行
[root@iZbp1gxkifg8uetb33pvcoZ gateway]# nohup ./gateway-linux-amd64 -config 5.4.2TO5.6.16.yml &
6. 应用授权
curl -XPOST http://localhost:2900/_license/apply -d' { "license": "XXXXXXXXXXXXXXXXXXXXXXXXX" }'
#### 部署 INFINI Console
为了方便在多个集群之间快速切换,使用 INFINI [Console](https://infinilabs.cn/products/console/) 来进行管理。
1. 下载安装
[root@iZbp1gxkifg8uetb33pvcpZ console]# wget http://release.infinilabs.com/console/snapshot/console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz --2022-05-19 10:57:24-- http://release.infinilabs.com/console/snapshot/console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz 正在解析主机 release.infinilabs.com (release.infinilabs.com)... 120.79.205.193 正在连接 release.infinilabs.com (release.infinilabs.com)|120.79.205.193|:80... 已连接。 已发出 HTTP 请求,正在等待回应... 200 OK 长度:13576234 (13M) [application/octet-stream] 正在保存至: “console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz”
100%[==============================================================================================================================================>] 13,576,234 33.2MB/s 用时 0.4s
2022-05-19 10:57:25 (33.2 MB/s) - 已保存 “console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz” [13576234/13576234])
[root@iZbp1gxkifg8uetb33pvcpZ console]# tar vxzf console-0.3.0_SNAPSHOT-596-linux-amd64.tar.gz console-linux-amd64 console.yml
2. 修改配置
[root@iZbp1gxkifg8uetb33pvcpZ console]# cat console.yml
for the system cluster, please use Elasticsearch v7.3+
elasticsearch:
- name: default
enabled: true
monitored: false
endpoint: http://es-cn-7mz2p9fty0007frx0.elasticsearch.aliyuncs.com:9200
basic_auth:
username: elastic
password: XXXXXX
discovery:
enabled: false
...
-
启动服务
[root@iZbp1gxkifg8uetb33pvcpZ console]# ./console-linux-amd64 -service install Success [root@iZbp1gxkifg8uetb33pvcpZ console]# ./console-linux-amd64 -service start Success
- 访问后台
访问该主机的 9000 端口,即可打开 Console 后台,http://x.x.x.x:9000/ 打开菜单 [System][Cluster] ,注册当前需要管理的 Elasticsearch 集群和网关地址,用来快速管理,如下:
测试 INFINI Gateway
为了验证网关是否正常工作,我们通过 INFINI Console 来快速验证一下。 首先通过走网关的接口来创建一个索引,并写入一个文档,如下: 查看 5.4.2 集群的数据情况,如下: 查看集群 5.6.16 的数据情况,如下: 说明网关配置都正常,验证结束。
调整网关的消费策略
因为我们需要在全量数据迁移之后,才能进行增量数据的追加,在全量数据迁移完成之前,我们应该暂停增量数据的消费。修改网关配置里面 Pipeline consume-queue_backup-to-backup
和 consume-queue_primary-failure-to-backup
的参数 auto_start
为 false
,表示不自动启动该任务,具体配置方法如下:
修改完配置之后,需要重新启动网关。
为了方便管理,可以使用 INFINI Console 来注册和管理网关,如下:
待全量迁移完成之后,可以通过后台的 Task 管理来进行后续的任务启动、停止,如下:
切换流量
接下来,将业务正常写的流量切换到网关,也就是需要把之前指向 ES 5.4.2 的地址指向网关的地址,如果 5.4.2 集群开启了身份验证,业务端代码同样需要传递身份信息,和 5.4.2 之前的用法保持不变。 切换流量到网关之后,用户的请求还是以同步的方式正常访问自建集群,网关记录到的请求会按顺序记录到 MQ 里面,但是消费是暂停状态。 如果业务端代码使用的 ES 的 SDK 支持 Sniff,并且业务代码开启了 Sniff,那么应该关闭 Sniff,避免业务端通过 Sniff 直接链接到后端的 ES 节点,所有的流量现在应该都只通过网关来进行访问。
全量数据迁移
在流量迁移到网关之后,我们开始对自建 Elasticsearch 集群的数据进行全量迁移到云端 Elasticsearch 集群。 全量迁移已有的数据的方式有很多种:
- 通过快照的方式进行恢复
- 使用工具来导出导入,如: ESM
如果索引数量很多的话,可以按照索引依次进行导入,同时需要注意将 Mapping 和 Setting 提前导入。
以现在 5.4 集群的索引来为例,目前的待迁移索引为 demo_5_4_2
,只有4
个文档:
我们使用网关自带的迁移功能来进行数据迁移,拷贝自带的样例文件,如下:
[root@iZbp1gxkifg8uetb33pvcpZ gateway]# cp sample-configs/es_migration.yml 5.4TO5.6.yml
修改其中代表集群和索引的相关配置,可以根据需要配置是否需要重命名索引和统一 Type( 用于跨版本统一 Type),如下图红框位置: 创建好模板和索引,如果目标集群不允许动态创建文档,需要提前创建好索引,如下图: 然后就可以开始数据的迁移了,执行网关程序并指定刚刚定义的配置,如下: 执行完成后,可以确认下数据的情况,如下图: 全量数据至此导入完成。
增量数据迁移
在全量导入的过程中,可能存在数据的增量修改,不过这部分请求都已经完整记录下来了,我们只需要开启网关的消费任务即可将挤压的请求应用到云端的 Elasticsearch 集群。 示例操作如下: 如果从 5.6 的集群来看的话,这部分的修改还没同步过来,如下: 这部分增量的数据变更,在网关层面都进行了完整记录,我们只需要开启网关的增量消费任务,如下: 通过观察队列是否消费完成来判断增量数据是否做完,如下: 现在我们再看一下 5.6 集群的数据情况,如下: 数据的增量更新就过来了。
执行数据比对
由于集群内部的数据可能比较多,我们需要进行一个完整的比对才能确保数据的完整性,可以通过网关自带的数据比对工具来进行,将样例自带的文件拷贝一份,如下:
[root@iZbp1gxkifg8uetb33pvcpZ gateway]# cp sample-configs/index-docs-diff.yml 5.4DIFF5.6.yml
修改需要比对的集群和索引信息,可以加上过滤条件,如时间范围窗口来进行增量 Diff,如下图:
执行网关程序,并指定该配置文件,如下图: 如图,两个集群完全一致。
切换集群
如果验证完之后,两个集群的数据已经完全一致了,可以将程序切换到新集群,或者将网关的配置里面的主备进行互换,同步写 5.6 集群。 双集群在线运行一段时间,待业务完全验证之后,再安全下线旧集群,如遇到问题,也可以随时回切到老集群。
小结
通过使用极限网关,自建 ES 集群可以安全无缝的迁移到移动云 ES,在迁移的过程中,两套集群通过网关进行了解耦,两套集群的版本也可以不一样,在迁移的过程中还能实现版本的无缝升级。 如有任何问题,请随时联系我,期待与您交流!
7 年+积累、 Elastic 创始人Shay Banon 等 15 位专家推荐的 Elasticsearch 8.X新书《一本书讲透Elasticsearch》已上线...
Elasticsearch • laoyang360 发表了文章 • 0 个评论 • 4194 次浏览 • 2024-03-27 15:55
今天,非常高兴地跟大家宣布,经过 7 年多的努力和精心准备,我们的新书《一本书讲透 Elasticsearch》已正式出版上线!
我从 2016 年接触 Elasticsearch 1.X、2.X 的版本,到现在已经接近 8 年+的时间。在这期间,我常常被问到:
如何系统性地学习 Elasticsearch ?
如何将现有的关系型数据库迁移到 ES ?
如何选择合适的版本?
如何规划和监控集群?
如何进行数据建模?
如何选择合适的检索方式?
如何基于现有数据进行可视化分析?
等一系列问题.......
这些问题促使我将之前的产品开发、项目实战经验和咨询经验进行全面整合,并精心梳理,融入到这本新书中,希望能让大家少走不必要的弯路。
一、书籍特点 本书具有以下几个显著特点:
最新版本,前沿知识点
本书基于 8.x 版本编写,涵盖了如索引生命周期管理、快照生命周期管理、数据流 datastream 等至关重要的新特性。
核心知识,系统认知
我们为您提供了清晰的学习路径,保留了最核心的“最少必要”知识点,并通过思维导图和大量图解内容,帮助读者更易理解和吸收。
实际应用,超越认证
覆盖Elastic官方认证的核心知识点,已帮助近200人通过Elastic专家认证考试。内容不仅限于认证,更注重实际应用。
来源于实战,应用于实战
书中内容源自真实项目案例和企业级问题解答(问题来自于Elasticsearch中文社区、死磕Elasticsearch知识星球、微信群、QQ群等)。涵盖3个实战项目,助力读者将技能应用到企业实战环境中。
代码开源,答疑服务
全书的代码、脚本在GitHub上开源,便于初学者通过实践学习。我们的答疑社群将持续跟踪最新问题,不断迭代更新内容。
二、5 个最尖锐问题快问快答 如下的问题来自 ChatGPT 4.0 的作为专业读者提出的 5 个最尖锐问题。
我快速回答一下:
2.1 问题1:市场竞争和定位问题 “市面上已有接近10本关于Elasticsearch的书籍,您的书与这些现有书籍相比有何独特之处?您是如何确保您的书在内容上与其他书籍区别开来,满足读者新的或更深入的需求的?”
铭毅天下:
1、独特之处:版本咱们是目前市场唯一的 8.X 版本。
2、区别开来:我从 2016 年开始搞 ElasticStack 到现在几乎平均每周一篇技术博客,从未间断。无需多说,时间能证明一切!这是咱们最大的不同之一。
3、还有不同:我自己公众号+博客有累计近 4.5 万+关注读者,知识星球有近2000人付费用户,这些大量的实战问题促使我唯有“自我革命”才能生存和成长!
2.2 问题2:实用性和更新性问题 “鉴于Elasticsearch技术持续发展和迭代,您的书籍是如何处理和包含最新版本的特性和变化的?在提供最新信息的同时,您如何保证书中内容的长期有效性和实用性?”
铭毅天下:
1、实话说结论,我做不到,市面上任何纸质书都不可能做到。受限于撰写、出版等相较于 Elastic技术栈体系更新的滞后性。
2、但是,我在筛选知识点的时候已充分考虑结合企业级实战以及 Elastic 官方认证考试的最核心、最关键的“最少必要知识”作为咱们的提纲,并且承诺后面继续根据读者反馈迭代和升级。
2.3 问题3:作者经验和权威性问题 “您能否分享一些您个人在Elasticsearch领域的实战经验或特殊贡献,这些经验如何在您的书中得到体现?作为作者,您相比其他书籍作者有哪些独特的优势或视角?”
铭毅天下:
1、本人持续深耕大数据存储和检索领域 7 年+,有博客为证!有丰富的项目实战经验和企业级实战问题咨询经验,已带领近200人+通过 Elastic 认证专家考试。
2、独特视角就是:来自全国乃至全球多个国家的实战问题——自己运营的知识星球、微信群、QQ群多达数千人,每天都有大量实战问题涌现。
3、作者是坚定的长期主义者:博客已写12年+,从未间断!相信积累的力量、相信坚持的力量、相信相信的力量!
2.4 问题4:读者受益问题 “您认为读者在阅读您的书籍之后,最具体和显著的收获会是什么?有哪些实际的技能或知识可以直接应用到他们的工作和项目中?”
铭毅天下:
1、少走不必要的弯路!
2、能获得属于自己的专属学习路线,能建立专属的知识体系,能将 Elasticsearch 原理、开发、运维、架构技能应用于实战。
2.5 问题5:内容深度和广度问题 “您的书籍是如何平衡Elasticsearch的基础知识和高级技术的?它是否适合所有水平的读者,从初学者到高级用户?对于那些已经具有深厚Elasticsearch知识背景的读者,您的书提供了哪些更深入的见解或独特内容?”
铭毅天下:
1、适合大数据存储和检索领域的初学者,也同样适合有工作经验的中级、高级工程师、架构师等。
2、对于深厚Elasticsearch知识背景的读者,本书可以当做工具书,需要时备查、常翻常新。
三、行业顶级大佬的推荐
值得一提的是,这本书获得了 Elastic 创始人兼CTO Shay Banon 、Elastic中文社区创始人兼极限科技CTO等15位顶级专家的强力推荐,是一本不可多得的Elasticsearch学习材料。
I am very happy to see that Elasticsearch has been widely used in China, which fully reflects the open source, free and open power of Elastic. This book is derived from the author's 7 years of technical accumulation and embodies the author's love for ElasticStack open source technology. I hope this book can help more people understand Elasticsearch and search technology, so as to discover the great value of data. I am convinced that this book will have a profound impact on Elastic's Chinese community.
我很高兴看到Elasticsearch在中国得到了广泛的应用,这充分体现了Elastic开源、自由、开放的力量。本书源自作者7年的技术积累,体现了作者对ElasticStack开源技术的热爱。希望这本书能够帮助更多的人了解Elasticsearch和搜索技术,从而发现数据的巨大价值。我相信这本书将对 Elastic 的中文社区产生深远的影响。
——Shay Banon Elastic公司创始人兼首席技术官
很高兴看到铭毅天下的新书出版,《一本书讲透Elasticsearch:原理、进阶与工程实践》是一本值得推荐的新书。它汇集了作者丰富的实战经验,深入探讨 Elasticsearch的 核心原理。书中丰富的图解和清晰的结构使得复杂的知识易于理解和吸收。同时,它覆盖了 Elastic 认证考试的所有考点,助力读者建立全面的认知。此外,书中还包含实战项目,帮助读者将所学技能应用到实际场景中。作者拥有多年实战经验和广泛的影响力,这本书将成为学习和应用 Elasticsearch 的重要指南。
——Medcl,Elastic 中文社区创始人、极限科技创始人
铭毅天下是ES中文社区里少有的常年坚持写作的技术博主,尤其擅长将点状发散的社区讨论进行归纳总结,结合自己的实践和再思考,形成系统性的系列技术文章。本书成于作者在Elasticsearch领域多年的理论知识沉淀,并涵盖了实际应用场景的最佳实践。无论你是Elasticsearch初学者还是有一定经验的开发者,相信都能通过阅读本书而受益匪浅。
—— 吴晓刚 (Wood大叔)携程旅行网 企业数字化平台部 研发总监
在大数据检索和分析领域,Elastic Stack 技术栈有广泛应用,本书从业务场景出发详细介绍了在 Elasticsearch 擅长的各类场景中完成业务系统开发所需的技术栈和技术手段,为用户系统选型和了解整体技术架构提供了指导,可以帮助用户少走弯路,快速完成系统建设。
——张超 《Elasticsearch 源码解析与优化实战》作者, Elasticsearch 内核资深研发工程师
本书基于Elasticsearch最新的8.X版本,涵盖了Elasticsearch更加完整、实时的功能。作者拥有丰富的Elasticsearch和写作经验,语言通俗易懂,内容详尽全面。无论你是初学者还是有一定经验的开发人员,本书都能够为你提供更深入的内容和最佳实践。如果你想系统地学习、掌握Elasticsearch,那么这本书绝对是你不可错过的参考书籍。
—— 魏子珺,阿里巴巴elasticsearch内核专家
很高兴为大家推荐这本关于Elasticsearch的技术书籍。本书涵盖了相当丰富的原理讲解和实现技术,更重要的是对实战场景给出了明确的指导案例和代码片段可供参考和使用。即面向开发人员深入讲解了搜索引擎的核心算法与数据结构,也同时给运维人员提供了关键指标的定义和解读。对于想系统学习的初、中级用户,可以按照章节循序渐进的阅读。对于高级用户来说,也可以从 遇到的问题为切入点,直接从某个具体章节入手来测试、寻求解决方案。铭毅天下是Elastic中文社区长期活跃和积极贡献的明星成员。非常兴奋看到他把自己日积月累的知识精华和经验总结在书中分享给广大读者。我相信本书一定可以帮助到处在任何阶段想学习探索Elasticsearch的用户。
——吴斌,Elastic中文社区主席
《一本书讲透Elasticsearch:原理、进阶与工程实践》是一本由一线开发人员撰写的实战指南。作者凭借多年的 Elasticsearch 咨询和教学经验,将复杂的概念以简明易懂的方式呈现给读者。这本书将帮助你深入了解 Elasticsearch,并理解其背后的原理和逻辑。通过学习本书,你将获得全面的知识,从而能够灵活应用 Elasticsearch 解决各种实际问题。相信这本书将成为你掌握 Elasticsearch 的必备工具。
——阮一鸣,eBay 高级研发经理、极客时间『Elasticsearch 核心技术与实战』课程讲师
铭毅在 Elasticsearch 领域深耕多年,勤奋且专注, 同时运营着国内最大的 ES 社群 ,帮助许多同学成功通过了有难度的 Elastic 认证工程师考试。很高兴看到他的新书出版,都说万事开头难,但我相信这本书能够为ES 初学者铺平道路,扫除障碍,澄清疑虑,快速上手!推荐大家阅读!
——魏彬,中国首位 Elastic 认证工程师
《一本书讲透Elasticsearch:原理、进阶与工程实践 》这本书是我极力推荐的一部作品!
我认识铭毅天下很久了,第一次见面记得是2019年在北京的Elastic开发者大会上,但在这之前,我就经常阅读他关于Elasticsearch的技术分享而神交已久。我了解的铭毅天下是一位拥有丰富的Elasticsearch领域知识和经验的专家,他曾在PB级大数据系统项目中发挥关键作用。实施这种大规模,长周期的复杂项目是非常不容易的,无论从系统设计,到实施过程中的问题解决。因此,来自于实践的真知产出,值得我们开卷。
多年来,铭毅天下一直积极、高效地在各种博客和社交媒体上分享与Elasticsearch相关的内容,并密切同步每个版本的更新。在Elasticsearch上,他不仅持续自我精进,还组织了学习小组和社区,帮助其他对Elasticsearch感兴趣的伙伴一起进步。他还带领150多人通过Elastic工程师认证,为许多人的职业发展贡献了力量。
这本书是铭毅天下多年经验的总结,内容涵盖了几乎全部的Elastic认证考点,而且它来自铭毅天下近7年的博客积累,每一章节都经得起时间的考验。因为抓住了平时学习和使用Elasticsearch当中痛点并总结了最佳实践,这些内容不仅阅读量高,而且转发度也很广泛。无论你是想深入了解Elasticsearch的基础知识还是应用实践,这本书都能满足你的需求。
我相信这本书将为读者提供一次全面而深入的学习体验,帮助他们在Elasticsearch领域取得突破。无论你是初学者还是有经验的专业人士,这本书都是不可或缺的指南。我由衷地推荐这本书,相信它会成为你在Elasticsearch学习和实践中的得力伙伴!
——李捷,Elastic 解决方案架构师 Principle Solution Architect
当得知本书成稿的消息时,我的心情是非常激动的,不管是作为一名技术人,还是作为一名搜索引擎的从业者,以及作为一名Elasticsearch中文社区的参与者和建设者。本书作者与我们一起见证了Elastic生态在国内的起步、发展以及到今天的繁荣;有所不同的是,作者有超强的毅力(就像铭毅天下的名字一样),坚持在这个技术方向上深耕了7年之久,在知识、技术和实践等方面有着深厚的经验积累,不但亲力亲为,而且深谙知识社群与实践社区CoP的操盘之道,在自我成长的同时也打造了优质的同行网络,积极影响了一批技术人,其中的优秀者更是通过了Elatics官方认证,极具含金量。本书的出版,一定会给更多技术人带来直接或间接的帮助,同时在个人成长、知识共享与实践社区等方面在业内树立成功的榜样。让我们一起用技术影响世界影响人!
—— 杨振涛,Elastisearch中文社区深圳主席|vivo互联网 研发总监
Elasticsearch是人工智能和大数据时代不可或缺的重要产品,已经成为开发者必备技能。本书汇集了作者多年开发经验、咨询经验、数千个Elasticsearch爱好者的最佳实战。因此在讲解原理的同时,能深入到最佳实践中去,做到深入浅出,非常适合Elasticsearch的初学者以及进阶者。
—— 付磊,快手Elasticsearch负责人,《Redis开发与运维》作者
Elasticsearch 作为一款强大又灵活的数据分析检索工具,值得每一位后端程序员认真学习。铭毅天下的这本《一本书讲透Elasticsearch:原理、进阶与工程实践》,用浅显易懂的语言介绍了Elasticsearch的概念、原理和实践,非常值得阅读!
—— 程序员小灰,公众号【程序员小灰】运营者,畅销书《漫画算法》作者
铭毅是我的老友,他是一个及其认证踏实和执着追究技术的人,这七年来他一直热心Elasticstack相关技术的步道,热忱帮助社区和公众号里的伙伴,成就不俗。本书是一本实用性极高的Elasticsearch的实践类书籍,更是铭毅倾尽所学之作。通读原稿后,让我非常欣赏的地方在于,它是市面上难得一见的把Elasticsearch原理,实现方式,最佳实践,以及实战案例串联在一起实操类书籍,无论是初学者还是需要进阶学习的人员都能从中获取想要的内容。十分适合想要在企业环境中落地Elasticsearch的人们,因此我诚意把它推荐给广大的技术爱好者和相关从业人员。
——周钰, IBM中国 企业架构师 中国前50 Elastic持证者
Elasticsearch作为一款优秀的开源分布式搜索引擎,被广泛应用在日志分析、站内搜索、指标监控、数据加速等场景,学习并掌握ES,已经成为一个技术工作人员不可或缺的重要技能之一。而本书深入浅出,对Elasticsearch的基本概念、设计原理及实践进行了详细介绍,是学习Elasticsearch的必备资料。诚挚推荐。
—— 吴荣,Elasticsearch平台资深研发工程师
一份专业、细致、用户友好的技术文档能给我们技术人员的日常工作带来多大的帮助,相信大家都有深刻的体会,特别是像Elasticsearch这种在搜索引擎领域最广泛应用的解决方案更是如此。虽然官方文档内容很详尽,更新很及时,但是限于语言、网速等问题,广大国内开发者并不能很准确高效的找到自己需要的内容。铭毅老师这本,兼顾了内容的专业性、严谨性、完整性,围绕着Elasticsearch及其相关组件所撰写,覆盖了从基础概念到高级用法的方方面面内容的专业书籍,能给各位带来的价值就不言而喻了。这本书适合从入门使用到高级调优的各层次的读者,是一本少有的适合放在案头常看常新的书。
—— 陈晨(死敌wen),资深搜索架构师、Elastic认证专家
15位大佬评价批量导入 Elasticsearch
15位大佬评价 Kibana 可视化
15位大佬评价词云图
无论您是大数据检索领域的初学者、开发和运维人员,还是架构师和管理人员,这本书都将成为实战路上的得力助手和“避坑指南”。
立即购买以获取专属福利:不论您从哪里购买、不论多少费用购买,记得保留购物链接和发票,费用都可以折算同等价格的星球优惠券。
私V信:elastic6 搞定后续一切流程。 ————————————————
本文为博主原创文章,未经博主书面授权不得转载。书面授权后方可转载,但转载请务必加上原作者:铭毅天下,原文地址:blog.csdn.net/laoyang360
原文链接:https://blog.csdn.net/laoyang360/article/details/135614659