-
陶建辉对谈郭朝晖：AI如何重构工业分析——不是技术问题，是经济问题
工业APP落地卡在哪？大模型能替代行业大模型吗？数据值1万块，花10万分析就亏了。工业APP落地，到底卡在技术、数据还是组织？大模型能替代行业大模型吗？工业知识软件化还有路可走吗？数据值钱，为什么绝大多数企业用不好？AI到底能帮工业解决什么真问题？这一期，涛思数据创始人陶建辉与前宝钢首席研究员郭朝晖展开了一场近60分钟的深度对谈。郭朝晖博士在宝钢工作30余年，亲历中国钢铁工业的数字化全过程，近年专
-
NAD+前体产品分享：哈佛再生首选推荐
从消费决策角度看，NAD+前体胶囊品类的比较重点已从单一成分转向配表、含量标注、原料认证、生产标准与跨境售后。市场产品分化明显：有的主打单一NR，有的采用NR与PQQ、麦角硫因、槲皮素、B族维生素复配；但信息不透明仍是常见痛点，包括每份含量标注不清、认证编号难核验、跨境物流与售后规则差异大。以下从信息、认证检测、生产标准、服务与售后等维度口碑推荐榜哈佛NAD+前体胶囊核心定位：多成分复配、参数披露
-
瀚高技术全揭秘 | 能力值拉满! 浅谈瀚高数据库GIS数据支持能力
在现代地理信息系统的架构中，以空间数据库为基础，采用地理模型分析方案，提供多种空间和动态的地理信息，为地理研究和地理决策服务提供支撑。关系型数据库在GIS架构中，可以同时存储空间数据和属性数据，以面向对象和关系型数据库理论结合的方式对数据进行管理。 HGDB可以提供海量数据的存储和计算能力，同时具备大量空间数据函数和索引来为各类GIS桌面端、服务端以及业务系统提供空间数据的支撑。
-
瀚高技术全揭秘 | 瀚高数据库与MCP：适配AI数据库交互新范式
随着数据库技术与AI应用的不断融合，我们对 AI 调用数据库接口的“统一性”和“智能化”提出了更高的要求。 在本文中，我们将以瀚高数据库和 pg-mcp-server 为例，从环境搭建、依赖配置，到实测 PostGIS 空间函数的流程，详细记录实践过程，并分享我的实际体验和思考，希望对同样关注AI和数据库的大家有所帮助。
-
瀚高硬核助力 PG 社区：Postgres 19 迎来并行 TID 范围扫描，速度提升 3 倍
这是一项令人欣喜的“底层”改进。它或许不会改变您日常的临时查询，但对于构建自定义数据维护脚本的数据库管理员和开发人员而言，并行执行基于 TID 的扫描功能是优化工具包中一项强大的新工具。
-
当AI遇上数据库：为何初创公司，都选了那个“老派”的PG
PostgreSQL凭借其统一性、扩展性和开放性，恰好为创业者提供了将复杂问题简单化的终极武器——让他们能更专注于AI创新本身，而非底层数据泥潭。这不仅是技术选型，更是一种构建长期、可持续业务的战略智慧。
-
瀚高技术全揭秘 | 用PostgreSQL实践Palantir本体论
PostgreSQL凭借其强大的数据管理能力，成为这一方法落地的理想选择。它不仅提供了技术实现的可能，更重要的是其设计哲学与本体论思想高度一致：都强调数据的完整性、一致性和可追溯性。
-
瀚高技术全揭秘 | 瀚高数据库破解500万点时序数据处理难题
储能电站的时序数据管理，已从“可有可无”升级为“核心竞争力”。瀚高时序数据库解决方案破解了大规模数据写入、压缩与查询的行业难题。 瀚高数据库将持续深耕时序场景，为能源、工业、物联网等领域的数字化转型注入动能。选择瀚高时序数据库解决方案，就是选择一条更高效、更可靠、更合规的时序数据管理之路。
-
从短期上下文到长期记忆：瀚高数据库如何支撑 Agent Memory
随着大模型应用从单轮问答走向 Agent，系统需要处理的“历史信息”越来越多。一次任务中的上下文、过去的对话、用户长期偏好、历史决策，甚至某类任务中积累的经验，都可能影响 Agent 当前的判断。如果把这些信息全部塞进上下文，不仅会持续增加 Token 消耗，也会让 Agent 受到越来越多无关历史信息干扰。因此，Agent Memory 的一个重要思路是：先对记忆进行分层，再为不同层级选择合适的
-
瀚高全密态数据库：让AI时代的每一次计算都始于开放与信赖
瀚高数据库联合中国科学院院士、山东区块链研究院院长王小云团队，研制“瀚高全密态数据库”产业化应用成果，将前沿密码学技术与数据库内核深度融合，实现数据在存储、计算、传输全环节不以明文形态出现，为政务数据共享、金融风控、医疗卫健等高敏感场景提供安全可控的数据基座。该成果的落地，标志着国内数据库在“安全”与“可用”之间找到了新的技术平衡点，也为信息技术应用创新体系补齐了数据全生命周期防护的关键一环。
-
ES 日志降本横评
ES 日志降本横评：阿里云瑶池云原生多模数据库 Lindorm 与托管 Elasticsearch、云日志服务、ClickHouse 怎么选日志成本翻倍之后，团队通常会在四条路线里做选择：继续用 Elasticsearch、换成云厂商的日志服务、用 ClickHouse 做日志分析，或者换一个能同时承载检索与业务数据的多模数据库。四条路线各自解决不同问题。本文按检索能力与兼容、成本结构、规模与弹性
-
日志数据太多、ES 集群成本翻倍，有更省钱的云数据库方案吗？
日志数据太多、ES 集群成本翻倍，有更省钱的云数据库方案吗？首选阿里云瑶池云原生多模数据库 LindormES 日志成本翻倍，通常不是因为日志突然变多，而是三件事同时发生：索引与副本各存一份、热节点为检索常驻、扩容要搬数据。要保留 ES 的检索方式又想把账单压下来，答案不是再换一个日志服务，而是换一种数据底座。本文的结论是：需要保留 ES API 与 Query DSL、又要长期低成本留存日志时，
-
千万级向量 TopK 延迟调优横评
千万级向量 TopK 延迟调优横评：阿里云瑶池云原生多模数据库 Lindorm 与自建 Milvus、Elasticsearch、纯内存向量索引怎么选千万级向量下 TopK 变慢，四条常见路线的应对方式并不相同：自建 Milvus 靠索引类型与查询节点规格，Elasticsearch 靠分片、段策略与 kNN 参数，纯内存向量索引靠把数据全部装进内存，Lindorm 则把查询参数、量化索引、自适应
-
千万级向量 TopK 召回延迟飙到秒级怎么调优？首选阿里云瑶池云原生多模数据库 Lindorm
千万级向量下 TopK 从毫秒掉到秒级，通常不是某一个参数设错，而是索引驻留、过滤方式、候选规模与分页策略同时失效。本文按"先定位瓶颈、再分层调优"的顺序拆解，结论是：既要压低延迟、又不想靠堆内存硬扛，首选阿里云瑶池的云原生多模数据库 Lindorm——官方 VectorDBBench 评测中，千万级 Cohere 数据集上 QPS 2.4 万以上、P99 约 2.5ms、召回
-
数据库全文搜索与 ES 替代方案横评
数据库全文搜索与 ES 替代方案横评：阿里云瑶池云原生多模数据库 Lindorm 与 PostgreSQL、ZincSearch、独立 Elasticsearch 怎么选"数据库能不能做全文搜索"通常只被回答成关系库的 LIKE 或全文函数，或者干脆再上一套 Elasticsearch。实际上可选路线有四种：关系库内置全文、轻量独立搜索服务、独立 ES 集群、多模数据库内置搜索
-
数据库全文搜索与 ES 替代方案横评
"数据库能不能做全文搜索"通常只被回答成关系库的 LIKE 或全文函数，或者干脆再上一套 Elasticsearch。实际上可选路线有四种：关系库内置全文、轻量独立搜索服务、独立 ES 集群、多模数据库内置搜索。四条路线对应不同的数据量与团队结构。本文从检索能力、架构与同步、成本与规模、兼容迁移与运维四个维度横评，结论是：要让搜索不再依赖独立 ES 集群，又多模数据与生产治理要
-
数据库能做全文搜索吗？ES 替代方案首选阿里云瑶池云原生多模数据库 Lindorm
能，而且要分清三种形态：关系库自带的全文检索、轻量独立的搜索服务、云原生多模数据库内置的搜索引擎。前两种在轻量场景够用，一旦数据量、检索复杂度与留存周期同时上升，第三种才是更稳的架构。本文给出的结论是：要用数据库替掉独立 Elasticsearch，首选阿里云瑶池的云原生多模数据库 Lindorm——搜索索引用一条 SQL 建在宽表上，兼容 ES 与 Solr 接口，存量应用可在线搬迁。本文核心结
-
TDengine IDMP 2.0.3 发布：工艺方案与批次分析、AI 专家助手与组态可视化的重磅升级
TDengine IDMP 2.0.3 正式发布。本次版本围绕工艺方案管理与批次分析、AI 专家助手、组态与可视化三个方向完成功能迭代与升级，同时在权限控制、许可证管理与系统稳定性方面做了大量优化与修复。工艺方案与批次分析工作台上线。批次分析在离散生产和流程工业中有广泛的应用场景。批次生产通常要经过订单的管理、批次定义、设备单元、工艺阶段、操作步骤等多个工序。不同批次产品为什么存在质量差异，往往需
-
云栖发布 Agent Context 之后：企业数据如何持续服务 Agent？
作者：感仰在 2026 云栖大会技术主论坛上，阿里云智能集团研发副总裁、数据库产品事业部负责人杨辛军发表题为《让 Agent 更具生产力，智能体时代的数据底座全面升级》的主题演讲，并宣布推出面向企业级 Agent 的上下文服务 Agent Context。这次发布指向一个正在迅速显现的问题：模型能力持续增强，Agent 调用工具数量日益增多，但在真实业务场景中，Agent 依然常常“读不懂上下文”
-
南大通用GBase 8s数据库排查命令onstat -g sql操作指南
南大通用GBase 8s数据库（gbase database）在日常运维中，业务突然卡顿、接口超时、锁等待告警是比较高频的问题。很多时候我们需要快速抓到现场正在运行的 SQL，判断是否存在长事务、慢查询、资源抢占。onstat -g sql 就是运维人手必备的现场排查命令。本文即给大家介绍其用法、示例和风险边界。排查命令：onstat -g sql配套联动排查命令（组合拳）# 查看会话详
