1、极限科技（INFINI Labs）CEO 曾勇近日在三周年庆典上宣布开源众多搜索相关产品和工具
https://infinilabs.cn/blog/202 ... tion/

2、Elasticsearch 到 Elasticsearch 数据迁移同步
https://mp.weixin.qq.com/s/qu-UqlWis-jjtFxkHPKavw

3、Elasticsearch：检索器（Retrievers）介绍
https://my.oschina.net/u/3343882/blog/16600478

4、【老杨玩搜索】11. Easysearch 导入数据 | 从零开始实现页面搜索功能
https://www.bilibili.com/video/BV1P8tLe2EqJ/

编辑：Fred
更多资讯：http://news.searchkit.cn

2024 年 12 月 3 日，一场盛大的庆典活动在香港 IFS 集团旗下长沙玛珂酒店璀璨启幕，极限科技迎来了其三周年的辉煌庆典。此次庆典不仅是对极限科技过往成就的回顾与庆祝，更是对未来科技梦想的展望并开始新的启航。


庆典现场，极限科技的全体员工、尊贵的合作伙伴以及长期以来给予我们坚定支持的客户欢聚一堂，共同见证了这一重要时刻。


活动伊始，极限科技的创始人曾勇回顾了公司创立至今的点点滴滴，他提到，“极限科技”的名称，源于公司的口号：追求极致，无限可能。这不仅是对公司理念的精准诠释，更有一层深刻的寓意，即公司坚信唯有不断打磨产品、精益求精，才能在激烈的市场竞争中立足并持续前行。


曾勇还回顾了极限科技的成长历程，作为国内为数不多的以搜索技术为核心的技术创业公司，自成立之初，极限科技便确立了“让搜索更简单”的目标，并将简单、易用、极致、创新作为产品哲学的核心。他感慨道，正是有了这样的信念和追求，极限科技才能在短短三年内取得优秀的成绩。


曾勇还表示极限科技的基因中始终与开源紧密相连。极限科技一直致力于为开发者和企业提供优质的开源工具，提升整个技术生态的活力。除了维护国内最流行的分词器 analysis-ik 和 analysis-pinyin，也在不断推动更多高质量开源产品的诞生。

在极限科技成立三周年之际，曾勇宣布以下产品和工具已全面开源：

• INFINI Framework
  
• INFINI Gateway
  
• INFINI Console
  
• INFINI Agent
  
• INFINI Loadgen
  
• INFINI Coco AI
  
  以上开源软件都可以在 Github 上面找到： [https://github.com/infinilabs](https://github.com/infinilabs)
  
  
  
  随后，极限科技的联合创始人也发表了讲话，分享了创业的艰辛与成功的喜悦，并对所有员工的辛勤付出和合作伙伴的鼎力支持表达了由衷的感谢。
  
  
  
  此外，来自行业内外的合作伙伴们也纷纷上台发言，他们高度评价了极限科技在科技创新领域所取得的卓越成就，并对公司未来的发展寄予了厚望。在圆桌讨论环节，与会嘉宾围绕国产化、AI，出海和全球化等前沿话题展开了深入探讨，分享了各自的观点与见解，为极限科技未来的发展提供了宝贵的思路与建议。
  
  
  
  整个庆典活动氛围热烈而欢快，与会者们在轻松愉快的氛围中交流心得、分享经验，共同探讨了科技行业的未来发展趋势与机遇。
  
  极限科技作为一家致力于科技创新的先进性企业，坚守引领搜索数据库技术从近实时迈向实时，推动行业的技术迭代与革命为使命。在未来的日子里，极限科技将继续携手合作伙伴，共同开创科技事业的新篇章，为实现更加美好的明天而不懈努力。
  
  此次三周年庆典不仅是对极限科技过去三年努力的肯定与庆祝，更是对未来发展的美好期许并制定航向。我们相信，在全体员工的共同努力和合作伙伴的鼎力支持下，极限科技必将迎来更加辉煌的明天！
  
  

  原文：https://infinilabs.cn/blog/202 ... tion/
  

1、从 0 到 1 了解大模型安全，看这篇就够了
https://mp.weixin.qq.com/s/YIPmEKHsfW5xqYAUSl2_zg

2、拒绝“道德正确”：让大模型写出人味
https://mp.weixin.qq.com/s/4o5ZfQao5ESuqETm-VjSNA

3、微服务篇-深入了解 Elasticsearch 基础概念、Elasticsearch 倒排索引、IK 分词器（拓展词典）
https://blog.csdn.net/Tingfeng ... 15124

4、探索Google Vertex AI向量搜索：构建现代化向量数据库的指南
https://blog.csdn.net/fqhwsdrg ... 09040

5、一个自动驾驶产品经理的ChatGPT方法论：BORE
https://mp.weixin.qq.com/s/AGdTBGn9vQrApZwPrAmxtQ

编辑：Muse
更多资讯：http://news.searchkit.cn

1. ES 升级101（需要梯子）
https://medium.com/%40rana.ash ... 69803
 
2. ES灭霸之为了性能我们直接干掉了90%的分片（需要梯子）
https://medium.com/kudos-engin ... 49fad
 
3. ES 升级那些事儿（需要梯子）
https://medium.com/%40idankoch ... 34b0d
 
编辑：斯蒂文
更多资讯：http://news.searchkit.cn

1.Elasticsearch vs 向量数据库:寻找最佳混合检索方案
https://mp.weixin.qq.com/s/MFoQwcYA8jNVz4FlYSTRkQ
2.向量化引擎中的“小文件合并”
https://mp.weixin.qq.com/s/CgouiTvo1CcB9kiJE8sEUQ
3.Elasticsearch ILM 故障排除：常见问题及修复
https://blog.csdn.net/UbuntuTo ... 42632
4.ES 同义词使用手册（搭梯）
https://medium.com/%40halilbul ... b4041




编辑：kin122    
更多资讯：http://news.searchkit.cn

作者：京东零售 崔健

0.前言

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

  1.背景
  

  
  采购系统在经历了多年的迭代后，在数据库查询层面面临巨大的性能挑战。核心根因主要有以下几方面：
  
  

• 复杂查询多，历史上通过MySQL和JED承载了过多的检索过滤条件，时至今日很难推动接口使用方改变调用方式
  
  
• 数据量大，随着业务的持续发展，带来了海量的数据增长（日均150万单左右，订单主表/子表/渠道表/扩展表分别都是：6.5亿行，订单明细表/分配表：9.2亿行，日志表：60亿行）
  
  
• 数据模型复杂，订单完整数据分布在20+张表，经常需要多表join
  
  引入的主要问题有：
  
  
• 业务层面：
  
  
  • 订单列表页查询/导出体验差，性能非常依赖输入条件，尤其是在面对订单数据倾斜的时候，部分用户无法查询/导出超过半个月以上的订单
    
    
  • 查询条件不合理，1.归档筛选条件，技术词汇透传到业务，导致相同周期的单子无法一键查询/导出，需要切换“是否归档”查询全部；2.无法区分“需要仓库收货”类的单子，大部分业务同事主要关注这类单子的履约情况
    
    
• 技术层面：
  
  
  • 慢SQL多，各种多表关联复杂条件查询导致，索引、SQL已经优化道了瓶颈，经常出现数据库负载被拉高
    
    
  • 大表多，难在数据库上做DDL，可能会引起核心写库负载升高、主从延迟等问题
    
    
  • 模型复杂，开发、迭代成本高，查询索引字段散落在多个表中，导致查询性能下降
    
    

    2.目标
    

    
    业务层面：提升核心查询/导出体验，加强查询性能，优化不合理的查询条件
    
    技术层面：1.减少慢SQL，降低数据库负载，提高系统稳定性；2.降低单表数据量级；3.简化数据模型
    
    

    3.挑战
    

    
    提升海量数据、复杂场景下的查询性能！
    
    

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

  4.方案
  

  
  

  思路
  

  
  
  

  优化前
  

  
  
  
  
  
  

  优化后
  

  
  
  
  

  4.1 降低查询数据量
  

  
  

  4.1.1 前期调研
  

  
  基于历史数据、业务调研分析，采购订单只有8%的订单属于“需要实际送货至京东库房”的范围，也就是拥有完整订单履约流程、业务核心关注时效的。其余订单属于通过客户订单驱动，在采购系统的生命周期只有创建记录
  
  
  
  
  基于以上结论，在与产品达成共识后，提出新的业务领域概念：“入库订单” ，在查询时单独异构这部分订单数据（前期也曾考虑过，直接从写入层面拆分入库订单，但是因为开发成本、改动范围被pass了）。异构这部分数据实际也参考了操作系统、中间件的核心优化思路，缓存访问频次高的热数据
  
  

  4.1.2 入库订单异构
  

  
  执行流程
  
  
  
  
  
  

• “入库”订单数据打标
  
  
  • 增量订单在创建订单完成时写入；存量订单通过离线表推数
    
    
  • 需要订单创建模块先完成改造上线，再同步历史，保证数据不丢
    
    
  • 如果在【数据解析模块】处理binlog时无法及时从JimKV获取到订单标识，会补偿反查数据库并回写JimKV，提升其他表的binlog处理效率
    
    
• binlog监听
  
  
  • 基于公司的【数据订阅】任务，通过消费JMQ实现。其中订阅任务基于订单号进行MQ数据分区，并且在消费端配置不允许消息重试，防止消息时序错乱
    
    
  • 其中，根据订单号进行各个表的MQ数据分区，第一版设计可能会引起热分区，导致消费速率变慢，基于这个问题识别到热分区主要是由于频繁更新订单明细数据导致（订单(1)->明细(N)），于是将明细相关表基于自身id进行分区，其他订单纬度表还是基于订单号。这样既不影响订单数据更新的先后顺序，也不会造成热分区、还可以保证明细数据的准确性
    
    
• 数据同步
  
  
  • 增量数据同步可以采用源库的增量binlog进行解析即可，存量数据通过申请新库/表，进行DTS的存量+增量同步写入，完成binlog生产
    
    
  • 以上是在上线前的临时链路，上线后需要切换到源库同步binlog的增量订阅任务，此时依赖“位点回拨”+“数据可重入”。位点回拨基于订阅任务的binlog时间戳，数据可重入依赖上文提到的MQ消费有序以及SQL覆盖写
    
    
• 数据校对
  
  
  • 以表为纬度，优先统计总数，再随机抽样明细进行比对
    
    
  • 目前入库订单量为稳定在5000万，全部实时订单量级6.5亿，降低92%
    
    

    4.2 提升复杂查询能力
    

    
    

    4.2.1 数据准备
    

    
    

• 考虑到异构“入库”订单到JED，虽然数据查询时效性可以有一定保障，但是在复杂查询能力以及识别“非入库”订单还没有支持
  
  
• 其中，“非入库”订单业务对于订单数据时效性要求并不高（1.订单创建源于客户订单；2.没有履约流程；3.无需手动操作订单关键节点）
  
  
• 所以，考虑将这部分查询能力转移到ES上
  
  ES数据异构过程
  
  
  
  
  
  
• 首先，同步到ES的数据的由“实时+归档”订单组成，其中合计20亿订单，顺带优化了先前归档ES大索引（所有订单放在同一个索引）的问题，改成基于“月份”存储订单，之所以改成月份是因为根据条件查询分两种：1.一定会有查询时间范围（最多3个月）；2.指定单号查询，这种会优先检索单号对应的订单创建时间，再路由到指定索引
  
  
• 其次，简化了归档程序流程，历史方案是程序中直接写入【归档JED+归档ES】，现在优化成只写入JED，ES数据通过【数据解析模块】完成，简化归档程序的同时，提高了归档能力的时效性
  
  
• 再次，因为ES是存储全量订单，需要支持复杂条件的查询，所以在订单没有物理删除的前提下，【数据解析模块】会过滤所有delete语句，保证全量订单数据的完整性
  
  
• 接着，为了提升同步到ES数据的吞吐，在MQ消费端，主要做了两方面优化：1.会根据表和具体操作进行binlog的请求合并；2.降低对于ES内部refresh机制的依赖，将2分钟内更新到ES的数据缓存到JimKV，更新前从缓存中获取
  
  
• 最后，上文提到，同步到入库JED，有的表是根据订单号，有的表是根据自身id。那么ES这里，因为NoSQL的设计，和线程并发的问题，为了防止数据错误，只能将所有表数据根据单号路由到相同的MQ分区
  
  

  4.2.2 查询调度策略设计
  

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

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

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

  
  1.主/备ES可以通过DUCC开关，实现动态切换，提升数据可靠性
  
  2.结合公司的业务监控，完成订单数据延迟监控（数据同步模块写入时间-订单创建时间）
  
  3.开启消息队列积压告警
  
  

  5.1 ES集群主/备机制
  

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

  5.2 数据监控
  

  
  
  
  

  6.灰度上线
  

  
  

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

  7.成果
  

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

  8.待办
  

  
  

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

  9.写在最后
  

  
  

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

1.Conda + JuiceFS ：增强 AI 开发环境共享能力
https://mp.weixin.qq.com/s/-Jmc2So_fxsryvW_rTa2Qw
2.得物新一代可观测性架构：海量数据下的存算分离设计与实践
https://mp.weixin.qq.com/s/VwGEq-sbEToew3M_F_LvyQ
3.使用 present 工具轻松生成演示文稿
https://charly3pins.dev/blog/l ... th-go
4.京东十亿级订单系统的数据库查询性能优化之路
https://elasticsearch.cn/article/15319

编辑：Se7en
更多资讯：http://news.searchkit.cn