vivo x TiDB丨解决云服务海量数据挑战

vivo 是一家全球性的移动互联网智能终端公司,品牌产品包括智能手机、平板电脑、智能手表等 ,截至 2022 年 8 月,已进驻 60 多个国家和地区,全球用户覆盖 4 亿多人。

vivo 为用户提供了在手机上备份联系人、短信、便签、书签等数据的能力,底层存储采用 MySQL 数据库进行数据存储。 随着 vivo 业务发展,用户量增长迅速,存储在云端的数据量越来越大,海量数据给后端存储和数据库带来了巨大的挑战。云服务业务最大的痛点,就是如何解决用户海量数据的存储问题 。

本文介绍了 vivo 的数据库和存储系统,以及如何使用分布式数据库 TiDB 解决海量数据挑战。 详细介绍了 vivo 采用 TiDB 过程中的真实体验,包括海量数据实时 OLAP 方案、云服务业务中的元数据管理方案,和基于自研的 NoSQL 数据库 TiKV 的实践。 分享了如何解决海量数据存储和管理的问题,以及提高业务效率和用户体验的实践经验。

vivo 数据库与存储体系

在这里插入图片描述

vivo 数据库与存储体系产品矩阵

在整个 vivo 云服务体系中,数据库与存储处于核心位置,从体系上可以分为两层,最上面一层是工具产品层,包含数据库存储统一管控平台、数据传输服务(支持数据同步、数据订阅、数据迁移等)、运维白屏化工具等。下面一层是数据库产品层,这一层又分为三个部分:一部分是 MySQL、 TiDB 等关系型数据库;一部分是 Redis、ElasticSearch、MongoDB、磁盘 KV 等非关系型数据库;还有一部分是对象存储、文件存储、块存储等存储服务。

在这里插入图片描述

vivo 数据库与存储运营管理

为了管理这些众多的数据库与存储产品,vivo 打造了一个数据库与存储运营管理平台,主要分为三层架构:

  • 最底层是支撑、管理所有数据库的工具产品,包含数据存储服务、关系型数据库、NoSQL 数据库,以及生态工具;
  • 中间是功能层,包括基础存储服务、数据管理服务,以及存储自治服务;
  • 最上面是运营层,包括权限账单、用户管理、工单服务等基础服务。同时还有一些安全相关服务,如数据脱敏、数据加密、权限管控、命令通道、数据审计等一系列功能。

TiDB 在 vivo 的落地实践

在这里插入图片描述

此前,vivo 已经用了很多年关系型数据库 MySQL。基于原生的 MySQL 数据库,vivo 结合集群高可用的管理与数据库代理的一体化架构,通过域名服务、名字服务进行接入,提供通用的关系型数据库服务。它主要具有三大核心能力:

  • 第一,兼容 MySQL 协议与 SQL 语法;
  • 第二,增强 MySQL 集群管控能力。vivo 引入 MySQL 的时间很早,在 MySQL 的一些集群管控能力上都有自研的能力;
  • 第三,安全增强能力,包括密码管理、数据脱敏、数据加密等能力。

本质上 MySQL 架构还是一个主从架构,并没有分布式技术引入。针对数据量较大、流量较大的场景,或者分析场景,给业务带来了巨大挑战。基于以上原因,vivo 在对比了主流分布式数据后后考虑引入分布式关系型数据库 TiDB,作为关系型数据库产品矩阵的一环,补充整个关系型数据库的能力。

引入 TiDB 帮助 vivo 解决了一些在 MySQL 生态中无法解决的问题:

  • TiDB 可以解决数据量过大、流量过大的问题,以及海量数据分析的场景;
  • TiDB 兼容 MySQL 语法,业务迁移比较平滑;
  • TiDB 支持水平扩展,相比传统的 MySQL 复杂的分库分表方式,TiDB 的扩展能力大大降低了运维压力;
  • TiDB 具备数据强一致性、高可用性,可以提供金融级数据安全性。

vivo 研发团队具有较强的自研能力,他们将内部所有数据库统一实现了平台化管理,这是一种提供高度自助、高度智能化、高可用、低成本的数据存储使用与管理平台,包含从数据库服务的申请、部署、维护、变更、优化,以及数据恢复、服务下线等一系列数据库全生命周期的管理。

在应用 TiDB 后,vivo 研发团队同样也将 TiDB 集成到该平台中,实现诸如 TiDB 的自动化部署、服务维护、数据变更、数据恢复,包括一些还在持续建设中的能力,如服务优化、服务变更。这些能力与 vivo 的全球化业务场景息息相关。全球化业务场景要求更好满足于本地客户服务,以及符合本地数据安全相关的一些管理规范。所以 vivo 的服务都是本地化部署,平台化的管理方式可以帮助运维、研发更好地支撑业务研发或者业务变更的效率。

该平台一方面提升了 vivo 整个数据服务的安全性,如账号密码管控、敏感数据加密脱敏、集成的研发效能等。在业务开发团队需要一个 TiDB 服务的时候,几分钟内就能得到一款分布式数据库进行代码开发,降低了运维管理成本;运维(DBA)再也不需要登陆服务器执行各种涉钥命令;最后,平台也大大提升了数据的可用性。vivo 数据库团队将一些 TiDB 的备份恢复工具及数据库的可用性也集成在平台里。

应用场景

推送业务基于 TiDB 的海量数据实时 OLAP 方案

在这里插入图片描述

vivo 的推送业务基于 TiDB 实现了一套实时 OLAP 方案。该场景中具有千亿级别的数据指标,vivo 希望数据在数据指标写入时可以实现秒级入库。同时,该场景还要求以月度为范围秒级出报表。原方案中使用了其他 OLAP 数据库方案或 MySQL 方案,在出报表时总会给数据库集群服务造成很大压力,指标的计算性、时效性也很差。尤其当面临海量数据时,查询与指标变更成本会变得很高。引入 TiDB 后,vivo 可以从实时链路里直接把数据秒级写入,再通过 DM 工具,把关系型数据库里面维度的数据,以及其他相关联的数据都同步过来,最终在 TiDB 中进行多表关联,为最终用户提供数据服务,如 BI 报表等。在该场景中,TiDB 的高性能、低延时等特性解决了 vivo 数据量大、时效性高等难题。

云服务业务基于 TiDB 的海量元数据管理方案

在这里插入图片描述

vivo 云服务是 vivo 为用户提供的在手机上进行数据备份、数据恢复同步的一款服务。这款服务用到了对象存储与文件存储,同时有大量的元数据需要存储。原方案使用了 MySQL 分库分表的方式,但 MySQL 实际上还是一个单集群方案,分库分表的业务逻辑需要在业务层实现,这就需要解决复杂的业务逻辑问题。同时,分库分表造成运维十分困难,扩容成本高、扩容耗时间长。基于以上原因,vivo 基于 TiDB 实现了一套海量元数据管理方案,支撑了 vivo 百亿级别的元数据表和日志数据表存储,核心业务时延小于 50ms。

基于 TiKV 自研的 NoSQL 数据库实践

由于 TiDB 整个产品都采用开源的模式,vivo 并没有满足于只作为 TiDB 的使用者,还基于 TiDB 的底层存储引擎 TiKV 自研了一款 NoSQL 数据库,希望能够实现一个高性能的、高稳定的多数据模型的分布式数据库,用以服务内部大数据量存储场景,降低整体数据库的运营成本,同时还针对一些 AI 特殊业务场景的应用进行定制优化。

在此之前,vivo 的 NoSQL 数据库产品矩阵中 KV 产品实际上只有 Redis,但 Redis 是基于内存的存储,性能虽然很好,但存在数据无法持久化及成本高等问题。基于此,vivo 基于 TiKV 研发了自己的 NoSQL 数据库。它兼容 Redis 协议,能够以很低的成本进行迁移,可以持久化大规模存储 TB 级别,甚至 PB 级别数据,还具备高性能、水平扩展、高效故障切换、数据安全保证一致性等特点。之所以能做到这些,很大程度上是因为 TiKV 原本就具备了很好的能力,如存储引擎水平扩展能力、高效故障切换能力、数据安全保证能力等。目前,这款 NoSQL 数据库已经在 vivo 内部的推荐平台、内部管理平台、应用中心中应用。

在这里插入图片描述

通过引入 TiDB ,vivo 解决了原 MySQL 架构无法应对数据量大、流量大等挑战,优秀的水平扩展能力及高可用特性支撑了 vivo 百亿级别的元数据表和日志数据表存储,核心业务时延不到 50ms 。同时,TiDB 的实时 HTAP 能力还帮助 vivo 解决了报表时效性问题。未来,vivo 还将持续在内部混合云中云化 TiDB 产品,将 TiDB 全生命周期的各个能力,在 vivo 内部云上实现出来,支持更多的业务场景。

相关推荐

TiDB 可观测性解读(二)丨算子执行信息性能诊断案例分享

通常我们可以用 explain analyze 语句获得算子执行信息。explain analyze 会实际执行对应的 SQL 语句,同时记录其运行时信息,和执行计划一并返回出来,记录的信息包括: actRows 、 execution info 、 memory 、 disk。不同算子的 execution info 可以通过 TiDB 文档 ( https://docs.pingcap.com/zh/tidb/stable/sql-statement-explain-analyze )了解。

TiDB_PingCAP 的博客 1020

TiDB × AI :DeepSeek 时代你需要什么样的数据基座

AutoFlow 是一套 GraphRAG 框架,不仅提供了类似于 LlamaIndex 的能力,而且还内置语义化的知识图谱构建和召回,以及我们在 AutoFlow 上实践得出的一系列行之有效的领先的 RAG 能力(这些接下来会介绍)。不过需要强调的是,Dify 是一个开箱即用的非常易用的界面,而 AutoFlow 虽然功能更强却则具有比较高的使用门槛,所以这两个选择其实面向了不同的群体,用户需要依据自己的实际需求进行选择。它并非传统的基于规则的优化工具,而是利用大模型的知识来优化不同类型的数据库。

TiDB_PingCAP 的博客 1417

架构师必看!现代应用架构发展趋势与数据库选型建议丨TiDB vs MySQL 专题(一)

随着业务系统数据量的增长,早起只能无奈采取分库分表方案以及架构,这不单为运维带 来了极高的复杂度,同时对业务开发也带来的极大的入侵,SQL 只能限定按照 shard key 维度进行编写,无法任意维度的进行 SQL 查询,开发不得不牺牲业务需求,业务的发展也不得不受限,同时又需投入大量的高精尖人才进行开发维护。这对数据库的承载能力提出了极高的挑战,不但需要承载大数据量,又需要保障业务读写性能的稳定性,而在数据的承载能力上,MySQL 的极限,是 TiDB 的起点。一行命令完成扩展,无需任何的人工干预。

TiDB_PingCAP 的博客 1233

TiDB 观测性解读(一)丨索引观测:快速识别无用索引与低效索

通过识别并优化未使用或低效的索引,可以减少资源浪费,并提高系统的响应速度和稳定性。在 TiDB 中,TIDB_INDEX_USAGE 系统表提供了相对丰富的索引使用统计数据,帮助 DBA 快速发现低效索引,并通过优化或删除它们来提升数据库效率。尽管删除索引的操作相对简单,但在实施时仍需注意潜在的限制和风险,尤其是在大数据量和高并发环境下。定期检查索引使用情况,尤其是对于大规模数据库。确保用于决策的统计数据涵盖足够长的业务周期,避免误判。

TiDB_PingCAP 的博客 974

海量数据融合互通丨TiDB 在安徽省住房公积金监管服务平台的应用实践

目前安徽省住房公积金监管服务平台已具备一系列功能模块,包括首页、运营分析、统计报表、智慧大屏、数据治理、风险检查和系统管理。其中,运营分析主要用于从不同维度分析公积金业务指标,统计报表则负责生成、填报和查询住建部规定的报表,同时也支持省级用户的报表导入、核对和更新。智慧大屏提供了综合和业务两大类可视化展示,而数据治理模块则涵盖了传数统计、数据检核和人工数据核对等功能,以确保数据的质量。风险检查方面,平台不仅支持公积金中心的自我检查,也支持省厅的检查,并可以根据需要添加新的检查模型。

TiDB_PingCAP 的博客 1133

TiDB 2024 年度报告:增长的故事

TiDB 2024 年度报告:增长的故事

TiDB_PingCAP 的博客 328

TiDB Chat2Query 深度解析:我们如何打造一款更高效、准确的智能 SQL 生成工具?

上个季度的销售额是多少?“哪个产品类别表现最佳?“本月客户投诉的趋势如何?相比其他工具,Chat2Query 能够对用户上传的大规模数据集进行理解和分析, 摒弃繁杂的专业术语和查询语句,Chat2Query 使得用户能够通过自然语言直接向数据库提问,并即时获得答案。

TiDB_PingCAP 的博客 1335

4.98 亿月活背后的国产数据库:咪咕视讯携手 TiDB 攻克内容分发核心系统挑战

咪咕大概是 2018 年左右正式开始对分布式数据库进行研究的,到现在为止我们看到和测试过太多的国内产品。但是在当时,敢用 LSM 树而不是 B+ 树做存储引擎,敢做分布式存算引擎分离的,能够行列副本共存、优化器路由分流做 MPP shuffle 的,市面上真的真的非常非常地不多见。比较多的是精致的分库分表外挂,或某些知名国外产品的模仿版。TiDB 的产品给我的印象是极具冲击性的,那么大胆、不随大流。验证和使用下来,效果也是切实的。

TiDB_PingCAP 的博客 1208

53 倍性能提升!TiDB 全局索引如何优化分区表查询?

在 TiDB 中,全局索引是一种定义在分区表上的索引类型,它允许索引分区与表分区之间建立一对多的映射关系,即一个索引分区可以对应多个表分区。这与 TiDB 早期版本中的本地索引(Local Index)不同,本地索引的索引分区与表分区之间是一对一的映射关系,即一个分区对应一个局部的索引块。全局索引能覆盖整个表的数据,使得主键和唯一键在不包含分区键的情况下仍能保持全局唯一性。此外,全局索引可以在一次操作中访问多个分区的索引数据,而无需对每个分区的本地索引逐一查找,显著提升了针对非分区键的查询性能。

TiDB_PingCAP 的博客 1356

一行代码不用写,用 Autoflow + Gitee AI 搭建本地知识库问答机器人

本文详解 AutoFlow 从部署到配置的完整流程,包括数据库连接、模型设置、知识库创建及聊天引擎配置,实现了一行代码不用写的问答机器人快速搭建。轻松上手,助力开发者探索智能问答解决方案。

TiDB_PingCAP 的博客 1046

TiDB 分布式数据库多业务资源隔离应用实践

本文将分享某客户在 TiDB 分布式数据库中实现多业务资源隔离的实践案例。

TiDB_PingCAP 的博客 1317

攻克多版本运维难题:爱奇艺百套 TiDB 集群升级至 v7.1.5 实战宝典来袭!

本文将深入探讨爱奇艺如何通过升级,成功将百套 TiDB 集群从多个旧版本升级至 v7.1.5,攻克多版本运维挑战,获得更稳更快的 TiDB 使用体验。

TiDB_PingCAP 的博客 1157

百亿大表的实时分析:华安基金 HTAP 数据库的选型历程与 TiDB 使用体验

明确需求:首先评估业务对 TP(事务处理)和 AP(分析处理)的需求比重,确定数据量、查询速度和响应时间,确保数据库能满足业务对实时性的要求。技术特性评估:考虑数据库的实时分析能力、可扩展性、高性能、安全性和灵活性,以支持业务人员实施的场景需求,特别是后台营销人员对数据实时性的需求。集成与兼容性:评估数据库与现有数据库、应用程序和其他关键系统的集成能力,确保数据同步策略的无缝实施。安全性与可靠性:重视数据库的安全性措施、容灾备份机制、数据恢复能力和错误处理机制,保障业务连续性和数据安全。

TiDB_PingCAP 的博客 1019

TiDB 的高可用实践:一文了解代理组件 TiProxy 的原理与应用

TiDB 是一款典型的分布式存算分离架构的数据库,其中计算层由多个无状态的 TiDB Server 组成,这些 TiDB Server 同时对外承担连接请求。为了可以将连接分发到多个 TiDB Server 节点上,一般需要借助外部负载均衡组件如硬件负载均衡 F5、软件负载均衡 HAProxy 等。为了实现全链路的高可用架构,我们经常也需要考虑负载均衡组件本身的高可用性,比如通过 KeepAlived 来保证 HAProxy 的高可用。

TiDB_PingCAP 的博客 1255

你需要什么样的资源隔离?丨TiDB 资源隔离最佳实践

通过本文的学习,相信大家对 TiDB 的资源隔离能力有了更全面的理解;大家可以根据不同的场景需求,选择合适的资源隔离方案。如果您有新的资源隔离需求或场景,欢迎与我们联系。

TiDB_PingCAP 的博客 1254

狂飙 50 倍丨TiDB DDL 框架优化深度解析

前面我们介绍了 TiDB DDL 任务的整体执行流程。接下来,让我们聚焦到在线 Schema 变更的细节上。执行单步变更:Job Worker 会根据任务定义,执行一次在线 Schema 的变更。每一次变更都代表着 Schema 向目标状态迈进了一步,即进入下一个状态,可能的状态包括 write-only 和 delete-only 等。状态更新:完成单步变更后,Job Worker 会将当前的 Schema 状态更新到元数据中。

TiDB_PingCAP 的博客 1204

唐刘:TiDB 的 2024 - Cloud、SaaS 与 AI

最后再说下产品,在今年,我们发布了TiDB 8.1和8.5两个版本。在 2025 年,我们会有一个重大的改变,就是会持续的投入到 8.5 版本的质量加固,同时收敛新功能的开发,只会在 2025 年发布一个有更高质量的 LTS 版本。关于 TiDB 8 系列,我后面再写一篇文章详细的介绍一下吧。在 2024 年,我们交付了非常不错的成果,当然,能取得这样的成绩,来自于我们不断地交付优异的产品,满足客户的需求,赢得客户的信任。

TiDB_PingCAP 的博客 1054

PingCAP 连续两年入选 Gartner 云数据库管理系统魔力象限“荣誉提及”

TiDB 凭借领先的 HTAP 架构设计,支持用户在云上的数据库中同时运行关键业务交易和实时分析任务,充分享受云的弹性优势和业务连续性优势,助力企业实现数据敏捷。PingCAP 是业界领先的企业级开源分布式数据库企业,提供包括开源分布式数据库产品、解决方案与咨询、技术支持与培训认证服务,致力于为全球行业用户提供稳定高效、安全可靠、开放兼容的新型数据服务平台,解放企业生产力,加速企业数字化转型升级。

TiDB_PingCAP 的博客 705

TiDB 8.5 LTS 发版——支持无限扩展,开启 AI 就绪新时代

TiDB 8.5 扩展了Runaway Queries 的功能,新增“处理行数”和“用量(RU)”作为识别标准,实现更精确的识别,并允许将这些 Runaway Queries 放入一个资源可控的组中,确保在高负载环境下集群的稳定性。TiDB 8.5 通过实例级执行计划缓存功能,使得同一 TiDB 实例内的所有会话共享执行计划缓存,减少SQL编译时间,从而降低整体 SQL 运行时间,提高 OLTP 的性能和吞吐量,并有效地控制内存使用,提升数据库的稳定性。

TiDB_PingCAP 的博客 776

基于时间维度水平拆分的多 TiDB 集群统一数据路由/联邦查询技术的实践

通过该组件与 TiDB 分布式数据库的有效结合,可以实现近乎无容量上限的超大规模数据管理,尤其是对于重要程度高、吞吐量大、业务敏捷性强、数据冷热特征明显的业务系统。不仅能够支撑面向内外部客户业务无损的多维度、不受分片键制约的灵活高效访问,还可以有效控制和平衡单集群的负载、容量、资源利用率、稳定性等关键指标,在不增加过多复杂性的前提下实现更强的整体扩展能力。当然,组件的现有功能更多是聚焦在当前的客户场景,未来可以按需在功能性、易用性、高性能等方面进一步优化和提升。

TiDB_PingCAP 的博客 915

Rakuten 乐天积分系统从 Cassandra 到 TiDB 的选型与实战

Rakuten 乐天是一家成立于 1997 年的日本公司,总部位于东京,员工总数超过 30,000 人,业务遍及 100 多个国家和地区。除了电商业务外,乐天还涉及电信、金融等多个行业。乐天的积分系统在日本非常普及,用户通过使用乐天的服务,如银行卡、手机卡等,可以获得积分,并在乐天商城中使用这些积分进行购物或抵扣,我们每个季度还会举办促销活动、会有大量用户高频访问积分系统,因此,乐天积分服务平台的性能、延迟和可用性要求极高。

TiDB_PingCAP 的博客 1355

平凯星辰亮相开放原子开发者大会,TiDB 荣获年度活跃开源项目奖项

12 月 20 - 21 日,以“一切为了开发者”为主题的 2024 开放原子开发者大会暨首届开源技术学术大会在武汉成功举办。平凯星辰亮相本次大会,出品 AI 时代的数据库技术发展论坛,获评“校源行”优质开源课程合作单位。由平凯星辰创立的开源分布式数据库 TiDB 获评“2024 年度数据库领域国内活跃开源项目”,7 位 TiDB 开发者获评“2024 年度数据库领域国内活跃开源开发者”,彰显了 TiDB 在开源数据库领域的卓越影响力和社区活力。

TiDB_PingCAP 的博客 607

B 站数据库负责人赵月顺:助力海内外业务增长,百套 TiDB 的选型与运维实战

B 站的 TiDB 集群规模已达到 100 多套,计算节点超过 2000 个,存储节点超过 800 个。TiDB 的应用场景非常广泛,包括视频观看、一键三连、发送弹幕、撰写评论、阅读漫画以及视频后端的存储等。B 站的 TiDB 部署采取了存算分离的策略,计算节点被部署在容器中,这种做法的优势在于能够充分发挥容器化管理无状态服务达到水平弹性拓展能力,允许根据需求随时对计算节点进行扩展或缩减,整个过程仅需一次服务发版,有效提升了效率与灵活性。存储节点则继续部署在物理机上。

TiDB_PingCAP 的博客 1234

微众银行携手平凯星辰荣膺金融科技创新奖,共同打造纳管千台服务器的大规模数据库运维平台

在过去的十年中,平凯数据库在金融行业积累了丰富的实践经验,已经在国有大型银行的 PB 级别数据服务平台、头部商业银行的核心交易系统、头部保险公司的核心保单系统、头部证券公司的核心交易系统等领域,成功完成了对国外商业数据库和 MySQL 数据库的替换升级,部署了超过 1,000 套关键业务系统,集群节点总数超过了 10,000 个。为了应对这些挑战,同时满足金融行业对高可用、高可靠、高性能数据库的需求,微众银行开发了一套完整的运维体系,打造了大规模信创原生分布式数据库智能运维平台。

TiDB_PingCAP 的博客 805

知乎 PB 级别 TiDB 数据库集群管控实践

知乎的数据库团队以“致力于提供稳定、高效和易用的数据库服务”为目标,为公司业务团队提供更好的 TiDB 存储服务来应对高并发、复杂查询和大数据存储的需求。本文详细介绍了 TiDB 的生态架构,包括核心组件、数据迁移与同步、运维与监控平台、备份与恢复、生态集成、K8s 支持、工具集和安全与审计等方面。同时探讨了知乎如何在云上和云下环境中管控 TiDB 集群,以及如何通过自研的天穹平台实现数据库平台化建设,提升业务研发团队数据库变更和 DBA 团队的资源管控效率。

TiDB_PingCAP 的博客 1180

TiDB 优化器 | 执行计划管理及实践

本文深入解析了 TiDB 优化器的执行计划生成过程及其局限性,介绍了如何通过 Hint、SQL Binding、执行计划缓存等技术手段进行执行计划管理,确保查询性能的稳定性和高效性。

TiDB_PingCAP 的博客 1315

商业银行基于容器云的分布式数据库架构设计与创新实践

本文介绍了某商业银行基于 TiDB 和 Kubernetes(简称 K8s) 构建的云化分布式数据库平台,重点解决了传统私有部署模式下的高成本、低资源利用率及运维复杂等问题。通过引入 TiDB Operator 自动化管理与容器化技术,银行能够实现多个业务系统的高可用、弹性扩展与自动化运维,极大提高了运营效率与资源利用率。本文还详细阐述了平台架构设计、面临的技术挑战及创新解决方案,展示了 TiDB 在金融行业数字化转型中的应用前景。

TiDB_PingCAP 的博客 1360

PingCAP 荣膺 2024 亚马逊云科技合作伙伴两项殊荣

近日,在 2024 亚马逊云科技 re:Invent 全球大会上,PingCAP 荣膺亚马逊云科技年度技术合作伙伴和年度亚马逊云科技 Marketplace 合作伙伴两项殊荣。这是 PingCAP 连续第二年获得亚马逊云科技年度合作伙伴奖项,彰显了 PingCAP 在与亚马逊云科技合作服务客户的过程中所展现的卓越技术实力和专业服务能力,共同推动全球用户业务取得成功。

TiDB_PingCAP 的博客 569

基于 AutoFlow 快速搭建基于 TiDB 向量搜索的本地知识库问答机器人

通过本篇文章介绍,相信大家对使用 PingCAP 开源项目 AutoFlow 实现快速搭建基于 TiDB 的本地知识库问答机器人会有一个完整的了解。如果提前准备好 Docker、TiDB 环境,整个搭建过程估计在 10 分钟左右即可完成,无须开发任何代码。文中使用一篇 TiDB 文档作为本地数据源作为示例,在实际情况中,您可以基于自己的企业环境用同样的方法快速构造企业内部知识库问答机器人。

TiDB_PingCAP 的博客 1283

TiDB 关联子查询及半连接的优化实践

TiDB 针对子查询语句会执行多种子查询相关的优化,以提升子查询的执行性能。半连接语句和关联子查询语句是常用的两类子查询,TiDB 优化器默认包含一些自动优化策略,同时 TiDB 也提供额外的 HINT 用于影响优化器在特定场景下可以选择更高效的执行计划。本文针对半连接及关联子查询语句在 TiDB 中的用法及优化技巧进行说明。

TiDB_PingCAP 的博客 1405
上一篇: 建设 TiDB 自动化平台:转转 DBA 团队实践
下一篇: NFTScan x TiDB丨一栈式 HTAP 数据库为 Web3 数据服务提供毫秒级多维查询
TiDB_PingCAP
TiDB_PingCAP 企业官方账号 企业官方账号
博客等级 码龄10年 2726粉丝 780原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值