12月7日，以“多场景数据库创新应用实践及 AI 应用探索”为主题的 OceanBase 城市交流会顺利落地上海，来自网易、vivo、携程、某运营商、信也集团、OceanBase、Dify 等多家企业、不同行业场景的技术专家分享了基于 OceanBase 的业务实践过程和收益，共同探讨 AI 时代的数据库能力需求，特邀哗哩哗哩数据库负责人赵月顺主持。AI 动手实战营环节更是吸引现场用户的踊跃参与，共有140+名用户参与实践，场面火爆非凡。一起来看看现场分享了哪些实践干货吧！
OceanBase 开源生态总经理封仲淹在正式开场前进行了开场致辞，对分享嘉宾和到场用户表示了诚挚感谢，并欢迎大家深度学习使用 OceanBase，在非常轻松愉快的氛围中开启了本次分享！
OceanBase 在网易云信的落地实践
网易云信是来自网易核心架构的通信与视频云服务，服务器研发专家曹佳俊老师介绍了内部的数据库使用现状以及新技术选型等考量及成果。网易云信 IM 即时通讯系统使用了多种形态的数据库进行构建，包括存储用户存储账号、群组、关系、离线消息等核心数据的自研关系数据库 DDB，存储数据库缓存、在线状态、漫游消息等数据的 Redis，存储历史消息、发布订阅等数据的 HBase，用于消息检索等的 Elasticsearch，分别面临着不同的问题和挑战。
问题和挑战
自研关系型数据库 DDB
- 扩缩容不够灵活；
- 资源隔离细粒度不够；
- 基于 MySQL B+Tree 存储结构的资源利用率不够高；
- 不支持 HTAP 一体化。
Redis 协议兼容的磁盘 KV 存储
- 宕机恢复时间长；
- 有单个 Key 映射到多条 KV，有数据不一致风险；
- 复杂命令，Proxy 和 KV 之间，多次网络 IO。
HBase
- HBase 宕机后，恢复时间长，数十分钟，甚至超过1小时，HDD 磁盘，平均响应时间长；
- HBase 的固有机制导致即使是 SSD，恢复时间也要分钟级，而且随着 Region 数量增加，恢复时间越来越慢。随着业务规模扩大，SSD 集群的读流量越来越大，当 SSD 集群不可用时，不敢读流量切到 HDD 集群。
综上所述，希望寻找一款兼具兼容性和稳定性、统一平台、低成本、性能好、高可用、社区快速响应的数据库产品。
OceanBase 的优势
对比关系型数据库 DDB
-
兼容 MySQL 协议：OceanBase 高度兼容 MySQL，业务不需要修改；
-
成本优势：相比 MySQL8.0 的页压缩和大字段压缩，有更高的压缩率，也就有更高的成本优势，特别对于消息类型的表压缩率更高；
-
高可用能力：相比 DDB 的分钟级故障恢复时间缩短到8s，具备更强的高可用能力；
-
原生分布式能力：在扩缩容时涉及的数据迁移粒度、依赖的资源，以及操作流程上，都有更好的表现；
-
多租户能力：多租户的资源隔离能力在云信这样的 PaaS 平台上，对于提升系统稳定性有很大的价值；
-
性能：在部分场景，如单行更新，受限于底层 MySQL，性能有明显瓶颈，OceanBase 相比有较大优势，低并发时优于 MySQL8.0，和 MySQL5.7 不相上下，高并发时优于 MySQL8.0，且大大优于 MySQL5.7；
-
单机分布式一体化：业务中存在很多仅需要单节点的业务（如发号器、配置中心等），单机分布式一体化可以让云信把技术栈统一为 OceanBase。
相对于使用 HBase 等作为 Proxy+KV 架构的底座，OBKV 和 OBKV-Redis 的优势是： -
组件少，部署运维简单；
-
高可用能力增加，特别是 RTO（实测8s）；
-
性能提升；
-
关系型数据库、KV 数据库统一使用 OceanBase，统一了存储底座。
相对于 HBase，OBKV-HBase 的优势：
- 成本优势：相比 HBase1.x，存储开销大幅降低；
- 高可用能力增强：故障恢复时间从分钟级，降低到8s；
- 接入较简单：兼容 HBase-client 的 API；
- 运维部署简单：相比 Hbase 极大地简化了部署，特别适合云信的私有化场景。
后续网易云信将陆续正式上线 OBKV 、OceanBase-MySQL，顺利的话，继续引入 HTAP 数仓业务等，将大大简化数据库架构，统一技术栈，降低运维人员的工作难度。
OceanBase 在 vivo 互联网的应用实践
vivo 互联网数据库业务是服务于 vivo 手机应用程序的数据存储的，数据规模在2018年到2024年增长了将近10倍，给当前使用的 MySQL 分库分表和主从复制架构带来了很大挑战。为解决 MySQL 扩容、延迟等痛点问题计划引入分布式产品，对比了一些数据库产品后，最终选择引进了国产自研安全可靠的分布式数据库 OceanBase 。
业务收益
从去年9月份开始启动调研测试，到今年7月份正式完成首套集群上线，至今已完成了多套集群的上线，OceanBase 的引入给业务带来了以下收益：
对在线业务的性能提升
- 某业务因 MySQL 批量写入过大，每秒4万行的数据操作，导致 MySQL 主从延迟一直居高不下，存在数据丢失风险，同时离线业务无法查询业务数据。切换到 OceanBase 后，很好地解决了 MySQL 延迟的痛点问题，而且利用 OceanBase 分布式的特性，可以提高写入性能；
- 助力业务在批量每秒4万行的写入的情况下，保障了数据库的可用性，且减少了响应时间；
- 线上环境的某 DB 集群总容量在28TB 左右，从 某 DB 迁移到 OceanBase 数据库后， 响应时间从不稳定的50毫秒左右降低为稳定的35毫秒左右，助力业务降低了30%以上的响应时间。
对大表操作的效能提升
- 线上环境 MySQL 某张大表数据量越来越大，因种种原因无法拆分，已到达物理机磁盘容量上限，需要压缩存储处理。
- 一开始选择了 TokuDB，数据压缩4倍，暂时缓解了物理机磁盘容量问题，但上百亿的数据量，已无法支持 DDL变更。
- 大表再次迁移到了 OceanBase 数据库，存储压缩率和 TokuDB 基本一致。对400亿数据量的大表做 DDL，用时2小时18分钟。满足了业务上大表的需求。
大规模集群降本实践
- 某 DB：迁移一套容量为35TB的某 DB 集群到 OceanBase 后，存储容量降低为26TB，节省9TB空间；
- MySQL：迁移多套合计20TB到 OceanBase 后存储容量为6.6TB，节省13.4TB空间。
基于目前的实践探索，增强了 vivo 扩大使用 OceanBase 的信心，后续计划将以下更多业务以及生态平台建设逐步迁移到 OceanBase 中，进一步统一内部的数据平台建设。
- MySQL 迁移：计划迁移多套有业务痛点的 MySQL 集群到 OceanBase 数据库；
- 生态建设：按照公司内部的 MySQL 上下游生态工具，把 OceanBase 的上下游工具适配起来，使业务从 MySQL 迁移到 OceanBase 时更加丝滑；
- 某 DB 迁移：线上某 DB 集群逐渐迁移到 OceanBase 数据库；
- 平台建设：DaaS 数据库平台继续加强对 OceanBase 数据库的工具建设，比如慢日志，审计日志，公司内部统一监控告警系统。
高效稳定！OceanBase 助力某运营商打造 IaaS 监控数据底座!
某运营商项目经理封骏介绍到，集团内部的运营中心 IAAS 监控平台（Zabbix）承载了100多套IT系统、超1.3万台主机的监控需求，以支持企业客户的数字化转型。由于主机数量庞大，峰值 Zabbix 每分钟访问次数（NVPS）高达156万次，并且随着服务规模的不断扩大、主机数量增长，传统的监控数据管理方式在数据存储、硬件资源、数据实时性、系统稳定性等方面面临诸多挑战，其次恰逢内部要求对 Server、DB 等做容器化部署，因此开始了对承载运营中心 IAAS 监控平台的1.3万台主机进行虚拟化容器化的探索之路。
面临问题
由于主机数量多、监控指标多，当前 Zabbix 存储系统中原本使用的 PostgreSQL 数据库压力非常大，业务访问高峰期延迟高处理速度慢比较卡，批量出现主机宕机误告警等问题，具体表现为：
- 扩展能力有限：当主机规模增加的时候，采集到的监控数据会越来越庞大，对当前 Zabbix 的 PostgreSQL 存储来说是一个挑战，无法满足存储的弹性扩展；
- 性能不佳：在 Agent 采集数据入库之后，系统根据配置告警条件进行查询时，指标数据返回慢甚至超时产生大量的误告警，影响业务判断；
- 容灾能力不足：集中式数据库在日常情况下容灾能力有限，故障发生率高。
因此运营中心启动新一代数据库的调研和选型工作，并提出了以下具体要求：
- 性能：必须能够处理大规模数据并保证高效的查询响应时间；
- 容灾能力：数据库需要具备故障自动恢复能力，确保服务的持续可用；
- 打破存储瓶颈：随着主机数量的增加，数据库应支持增加虚机水平扩展，以适应不断增长的数据量；
- 兼容&适配：适配 Zabbix，支持作为后台数据库存储配置数据和历史数据。（业务不改造或者少改造以及对 Zabbix 监控系统的适配能力）；
- 数据库安全稳定：符合中心要求；
- 具备容器化部署能力（可选）：最好具备容器化部署能力，能够复用当前的容器化环境。
OceanBase + Zabbix 使用效果
经过性能、兼容性、运维使用等多方面的调研，确定了 OceanBase 方案，系统切割后在监控业务、成本收益、运维管理上表现如下：
监控业务实际表现
- 性能稳定：1.3万台主机割接后未发生故障，数据库主机磁盘 IO 稳定在10ms以内；
- 页面友好：页面化程度高，对运维人员友好，保障城市级业务持续高可用；
- 高可用新标准：故障恢复进入秒级时代，时刻保障监控业务顺利运行；
- 兼容性：与 Zabbix 兼容性高，割接工作顺利，从 PostgreSQL 到 OceanBase 无缝衔接。
成本收益
- 性价比高；
- 数据压缩能力不错，节省磁盘控价；
- 周边工具丰富，运维使用简单易上手；
- 社务支撑维护力度大，有问题响应很快。
运维管理（ob-operator）
通过在已有的云原生环境中使用容器化部署工具 ob-operator 安装部署以及管理 OceanBase 对接 Zabbix 监控系统，表现如下：
- 部署方便：只需提供镜像和 YAML 即可拉起整套数据库集群；
- 容灾能力好：ob-operator 会自动、及时地检测到数据库节点的故障并采取相应措施恢复集群；
- 灵活扩展：在业务扩张或收缩时，借助 OceanBase 原生的分布式能力，通过 ob-operator 很容易地增删数据库节点；
- 界面化运维：直观的图形界面方式对非专业的运维人员非常友好（概览、性能指标、拓扑图）。
至此该运营商顺利完成了运营中心 IAAS 监控平台1.3万台主机超大规模数据底座的容器化之路， OceanBase 的稳定性与强大的数据承载能力再次得到验证。
OceanBase 在信也的实践
当前信也集团使用的数据库主要以 MySQL 为主、MongoDB 为辅，结合其他多种数据库来共同满足不同业务需求场景。随着业务的不断发展，数据容量越来越大，当前数据库已经维持超过500T的数据量，单一 MySQL 已经无法支撑，尝试进行升级硬件、分库分表都无法彻底解决后，于是开始进行新的数据库选型。
实践效果
经过一番探索实践，基于 OceanBase 高度兼容 MySQL 及生态、高压缩实现低成本、高可用&高性能、线性透明扩展、完善的工具支持等优势，顺利解决了当前业务瓶颈，并在归档库、历史库、分库分表业务等取得了很大的收益成果。
归档库降本解决方案：冷备磁盘节省72%
受限于硬件限制，归档库经历了从 TokuDB、InnoDB 压缩表，到最终使用 OceanBase 的演变。早期，数据需要依赖多个 MySQL 集群进行分散存储。该管理方式使得管理复杂性增加、数据一致性出现问题、维护成本上升、归档数据过期等。
借助 OMS 工具，无损地将数据从MySQL归档库迁移至 OceanBase，同时将同一个库表的数据进行合并，实现了归档过程的平滑过渡。采用按日期进行分区的方式，可以有效地清理过期的归档数据。项目收益如下：
- 节省存储空间 ：凭借 OceanBase 的高压缩率，冷备磁盘空间节省了72%；
- 优化数据存储 ：同一个库表的数据得以合并存储，解决了跨多个归档集群查询数据的问题，提升了数据访问效率。
遗留业务压缩存储方案：节约了80%存储空间
某信贷业务当前处于维稳状态，系统中存在大量的历史数据，业务采取分库分表设计。尽管业务访问量较低，仍占用了大量 MySQL 资源，影响了系统的性能和资源利用效率。借助 OMS 工具，无损地将数据从原先的4个 MySQL 集群几张表迁移至 OceanBase 的同一个租户中，实现数据的集中管理。项目收益如下：
- 节省存储空间 ：通过 OceanBase 的高压缩率，节约了80%（20T）的存储空间，极大减轻了存储压力；
- 集中管理 ：将原来分布在多个 MySQL 集群中的数据统一迁移至同一个 OceanBase 租户，实现了集中化管理，提高了数据管理的效率和便捷性；
- 支持多业务查询 ：在与原来 MySQL 集群配置相同的硬件环境下，OceanBase 支持了4个业务集群的查询及数据抽取操作，保证了系统的查询能力和性能稳定性。
分库分表合并解决方案：有效降运维复杂度
某核心系统基于 MySQL 进行存储，采用了8个集群共计1920张分表的策略来处理海量数据。由于系统每天面临极高的访问量以及庞大的数据流入，MySQL 的存储容量和性能限制逐渐暴露出来，维护和扩展困难，历史数据存储与查询出现问题，新业务难以支撑。
通过 OceanBase 提供的分区表功能、横向扩展能力以及备租户能力，确保系统平滑过渡，并保障了在大规模负载下的性能稳定、系统的高可用性以及持续稳定运行。项目收益如下：
- 避免复杂的分库分表管理 ：按天分区存储的方案，成功避免了传统分库分表带来的管理复杂度，减少了运维难度；
- ODC 自动管理分区 ：分区管理工具 ODC，自动化管理数据分区，提高了系统的管理效率和数据访问性能；
- 扩展性提升 ：OceanBase提供更好的水平扩展能力，能够根据业务发展需要灵活扩展系统容量，支持更久时间的数据存放
AI 时代下的数据库发展趋势与向量数据库的应用
OceanBase 的高级技术专家蔡飞志分享随着 AIGC（人工智能生成内容）的迅速崛起，数据量经历了显著的增长，这对数据库的数据处理和分析能力提出了更高的要求。特别是对于向量嵌入和索引的支持，成为满足日益复杂的 AI 应用需求的关键因素之一。
在 AI 时代，数据库面临的主要趋势和挑战：
- 非结构化数据激增 ：由 AIGC 产生的大量非结构化信息（例如图像、视频、文本等），加上大型语言模型生成的数据，导致了数据总量以指数级别增长，给现有数据库系统带来了前所未有的压力。
- 向量索引技术的发展 ：为了有效管理这些复杂类型的向量数据，许多数据库供应商正在加强其产品的向量索引功能，以便更好地支持相关存储与检索操作。
- 构建完整的 AI 平台 ：随着 AI 从实验阶段过渡到实际部署，企业越来越需要一个集成了多种智能服务的一站式解决方案。这意味着底层数据库不仅需要具备强大的数据处理能力，还需确保高可用性、可靠性、可扩展性和易于维护的特点。
OceanBase 数据库在向量处理领域的创新
面对上述挑战，OceanBase 已经采取了一系列措施来增强自身在向量数据管理方面的能力：
- 引入先进的向量类型和支持算法 ：除了传统的关系型数据管理之外，OceanBase 还在其核心引擎中加入了对向量数据类型的支持，并实现了 HNSW、IVF、DSAN 等多种高效算法。
- 提供多样化的访问接口 ：用户可以通过 MySQL 协议兼容接口或 SDK 直接与 OceanBase 交互；同时，该数据库也深度整合了 Python 生态系统，方便开发者快速集成。
- 利用分布式架构优势 ：基于分布式的架构设计，使得 OceanBase 能够轻松实现水平与垂直方向上的扩展，同时保证了跨分区事务的一致性。
- 优化性能表现 ：通过采用 VSAG 算法以及查询剪枝、量化压缩等技术手段，OceanBase 能够在保持较高召回率的同时大幅提升搜索效率。
向量索引助力多场景 AI 应用优化
- 综合查询 ：结合多种维度的信息进行复合过滤和查找，将自然语言转换为向量形式保存，进而利用 RAG 机制完成精准定位。
- 多模态检索 ：适用于包括但不限于人脸检测、商品推荐等领域，通过向量表示法促进不同类型媒体内容之间的相似度匹配。
- 个性化推荐 ：通过对用户行为模式的学习，将其转化为相应的向量特征并存入数据库，在接收到新的请求时，系统可以根据最接近的向量提出建议，从而改善用户体验。
尽管 OceanBase 在向量数据库领域已经取得了一定进展，但仍然处于探索阶段。未来，它期待与更多合作伙伴携手共进，共同开拓更加广泛且深入的AI应用场景。
Dify：简化 AI 应用开发的开源框架及其 RAG 技术详解
Dify 后端开发工程师秦骏言，为大家详细的介绍了 Dify， Dify 是一个用于构建AI应用的开源框架，它不仅兼容了 OpenAI、Anthropic Claude 以及 Google 等全球数十个主流大模型，而且在处理 embeddings、向量重排、语音和图像理解等方面表现优异，极大地简化了开发者将先进 AI 技术集成到自己项目中的过程。通过 Dify，可以创建出基于检索增强生成(RAG)、Agent 和 Workflow 等多种形式的应用程序。
在这次分享中，秦骏言重点放在了 RAG 技术上——一种结合了生成式人工智能与知识库的方法论，它结合了生成式人工智能与外部知识库的力量，使得大型语言模型能够依据最新的或特定领域的信息生成更加准确丰富的答案。传统的大规模语言模型虽然功能强大，但在处理非常专业或者时效性强的内容时可能表现不佳，而 RAG 正好弥补了这一点不足。
详解 RAG 在 Dify 中的实现流程及其优势
- 知识库构建 ：
- 用户可以上传不同格式的文档（如 TXT，Markdown，PDF，DOCX）或者直接从网页抓取数据。
- 对收集到的数据进行预处理，这包括文本清洗、分段等步骤，并选择合适的 embedding 模型、分割策略以及设定检索参数。
- 为每个文本片段计算其对应的 embedding 向量，并建立索引。之后，这些向量连同原始文本一起被存储在一个专门设计的向量数据库内。
- 交互与检索 ：
- 当用户提出一个问题时，系统会使用选定的 embedding 模型来生成该问题的向量表示。
- 基于这个向量，Dify 可以从之前构建的知识库中查找相关联的信息。提供了多种检索模式，例如纯向量搜索、全文本匹配甚至是两者的组合。
- 通过 rerank 算法对候选结果进行重新排序，确保返回给用户的都是最相关的几个选项。
- 最后，依据预先定义好的模板将选中的知识点传递给 LLM，让它据此生成最终的答案。
- 优化与扩展 ：
- Dify 允许用户无需编写代码即可快速搭建起高质量的知识管理系统，并配备了全面的调试、评估工具帮助持续优化性能。
- 整合 OceanBase 的强大功能，实现了元数据和向量数据的一体化管理。
- 新增加的 Parent-child 检索机制让用户可以根据需要自定义父级条目下的子级条目，从而进一步提升搜索精度和信息质量。
除了上述提到的 RAG 特性之外，Dify 也致力于提供灵活多样的插件生态系统以及强大的工作流编排能力。最近，他们对插件架构进行了重大升级，即将推出一站式的插件市场，使得用户可以根据实际需求自由选择并安装各类工具和服务。同时，引入了名为“endpoint”的新扩展接口，方便第三方服务以标准化方式接入 Dify。
最后，秦骏言也分享了 Dify 愿景，是成为 AI 时代的操作系统，不断兼容更多种类的工具和技术，满足日益增长的各种应用场景需求。
AI 动手实战营：基于 Dify + OceanBase 打造属于你的智能体平台
在这个环节中，OceanBase 技术专家王述熠，亲自演示了如何利用 Dify+OceanBase 构建智能体平台。为了使教学更加生动有趣，我们特别邀请了已经成功搭建平台的同程王昱翔老师作为嘉宾讲师，带领大家一步步学习如何高效地完成平台建设，王老师的讲解深入浅出、实用性强，受到了现场参与者的一致好评。
现场参与实战营的开发者们表现出极高的兴趣，纷纷要求亲手尝试实践操作，由于大家的热情尝试与互动交流，我们应大家的要求将这一动手环节延长了2个小时，帮助每一位参与者都能成功完成体验。每位参与者不仅成功创建了自己的 AI 应用，还获得了由 OceanBase 社区颁发的 “AI 动手实战营”证书以及特别惊喜礼物。此次活动不仅加深了开发者们对 Dify 和 OceanBase 技术的理解，也为他们提供了一个宝贵的交流机会，促进了技术社区内的互动与成长。
本次交流会不仅为大家带来了各个行业在 OceanBase 的探索实践分享与 OceanBase 数据库在向量能力方面的最新进展及其广泛的应用场景，又一次通过线下 AI 实战环节使用户深入学习实践 OceanBase 的向量化技术。现场的火爆氛围更是让每一位参与者都感受到了对社区的热情与对 OceanBase 的喜爱，非常感谢上海地区用户的关注、支持与参与！让我们一起期待下一次活动，为大家带来更精彩丰富的落地实践分享！
没来得及观看直播的朋友们可以看 资料回顾 哦！
线上参与方式还在火热进行中，充电宝、抱枕、键盘等你来拿，感兴趣的小伙伴儿快来参与吧！
：
往期精彩回顾
【广州站】：
线上线下一气呵成了~