{
"componentChunkName": "component---src-templates-blog-blog-detail-tsx",
"path": "/blog/htap-database-practice-in-a-chinese-saas-provider",
"result": {"pageContext":{"blog":{"id":"Blogs_435","title":"MySQL or TiDB？HTAP 数据库在中国 SaaS 行业头部服务商的应用实践","tags":["HTAP"],"category":{"name":"案例实践"},"summary":"CRM 并不是简单的销售和客户服务的效率工具。本质上，CRM 是以平台化思维实现业务管理和数据的打通，为 360 度客户旅程提供数字化支撑。","body":"> CRM 并不是简单的销售和客户服务的效率工具。本质上，CRM 是以平台化思维实现业务管理和数据的打通，为 360 度客户旅程提供数字化支撑。\n\nIDC 发布的《IDC 中国企业级应用管理 SaaS 市场，2021H2 》报告显示：2021 年中国企业级应用管理 SaaS 市场规模达 67.8 亿美金，其中 CRM 市场份额为 32%，未来五年将以 23.1% 的 CAGR 快速增长。 \n\n虽然受到疫情影响，但随着企业数字化转型的不断深化，更多的企业需要用数字化手段、标准化流程来提高效率和节约成本。从中国企业级应用管理 SaaS 市场来看，平台化、数据化、生态化成为重要的发展趋势。CRM 作为云计算时代典型的数据密集型应用，提升海量数据的处理能力和时效性成为 CRM 服务商提升客户体验、构建核心竞争力的关键所在。\n\n## CRM 的数据架构面临重重挑战\n\n某中国企业级 CRM 头部服务商，其 CRM 产品支持从营销、销售到服务的全流程自动化业务场景，帮助企业转型为真正“以客户为中心”的数字化运营组织，实现业绩的可持续增长。随着产品能力的迭代加速和业务的规模化增长，该服务商实现了从中小企业到大中型企业的覆盖，为了应对不同行业用户的个性化需求推出了 PaaS 平台，基于平台的定制能力服务垂直行业的特定需求；同时，该服务商发力 C 端市场，陆续推出 SCRM 等产品连接海量 C 端用户，打造客户旅程的一体化闭环。 \n\n同时服务几万家不同规模的企业，打通每家企业各个业务系统的数据，为 360 度客户旅程提供数字化支撑，这些都对 CRM 服务商底层的数据平台提出了非常严苛的要求。该 CRM 服务商的数据平台架构采用多形态混合式数据存储模式来满足多租户架构下可定制的业务需求。下图所示的多租户共享数据库，考虑到大表性能、租户数据量，采用了元数据、租户分库、租户分表的整体方案，共享库按照租户和实体做水平扩展的分库分表设计。 \n\n\n多租户共享数据库的分库分表设计\n\n与此同时，为了满足多租户定制化需求，实体主数据表需要预留大量的扩展列，呈现出数据库表多，列多，索引多等特点，也给 CRM 的数据架构带来了重重挑战：\n\n### 大数据量下的分库分表无以为继\n\n随着业务高速增长，CRM 用户数接近 20 万，租户的增长一方面带来海量数据高并发访问的挑战，另一方面使得单租户单实体库数据量快速增长，单表已经超过千万级别。单体 MySQL 数据库无法水平弹性扩展，配置也已经到极限，出现性能下降的问题。此外，MySQL 的分库分表方案，业务拆分难度大，需要进行代码侧的改动进行适配，维护工作也变得非常繁琐。\n\n### 2B 和 2C 客户的体验大打折扣\n\nCRM 业务具有灵活、多变的的特征，经常遇上索引缺失/索引选取错误或者复杂模糊查询等情况，MySQL 性能完全不可接受，慢查询增多导致客户体验差。在批量操作场景，单个任务可能将系统卡死，大量慢查询堆积，严重的时候甚至会造成 OOM，查询被拉黑名单。\n\n### 业务创新的灵活度受到制约\n\n中国的企业级客户由于行业特点和业务环境的变化，通常对 CRM 有定制化和多样化需求，导致数据库需要预留很多的扩展列，经常需要在数据表中增加字段或者增加索引。MySQL 行宽只有 64K，也不支持 Online DDL，使得业务创新的灵活度受到极大制约。\n\n## CRM 真实场景下 MySQL 和 TiDB 的比拼\n\n通过与 CRM 服务商技术部门的探讨，由于 SaaS 业务的稳定性、性能都对最终客户至关重要，组织了一次全面的 PoC 验证工作，覆盖了产品的性能，兼顾数据迁移、稳定性、安全性、运维监控等能力。 \n\n从业务场景的实测结果可以看到：TiDB 并发处理和查询性能提升明显，千万级以上性能提升 70% 左右，单条、跑批都得到了大幅的性能提升（80% 在毫秒级），原先过长时间查询无返回结果的任务，在 TiDB 中得到好转；各类痛点查询，如权限查询、模糊查询、分页查询、无索引查询、聚合查询、联表查询等性能提升几倍至几百倍不等；TiDB 在添加字段，修改字段，增加索引等 DDL 上优势明显。此外，TiDB 提供高效的同步工具 DM，从 RDS-MySQL 同步到 TiDB 延迟控制在毫秒级别。\n\n## 两套数据架构的对比\n\n某 CRM 服务商原有的数据架构中，OLTP 业务通过 Mycat 连接多套 MySQL 数据库处理和存储应用的数据，所有 MySQL 通过 DataPipline 同步到 Greenplum 数仓，由 Greenplum 提供 OLAP 查询服务。引入 TiDB 分布式数据库替换原有架构之后，所有的 OLTP 业务和 OLAP 查询访问一套 TiDB 集群即可，根据业务的实际需求，灵活增加 TiKV 和 TiFlash 节点即可。 \n\n\n某 CRM 服务商数据平台架构\n\n基于 TiDB 的新架构在高可用、性能、定制化需求、客户体验、开发和运维等多个维度体现出优势：\n\n\n## “两升一降”助力 SaaS 服务商构建核心竞争力\n\n### 提升海量数据的处理能力和时效性\n\nTiDB 分布式数据库按需弹性扩展能力使得 CRM 服务商可以轻松应对租户、2B 与 2C 业务海量数据的增长。对于 CRM 类 SaaS 服务商来说，TiDB 分布式架构对库、表无数量限制，一键实现节点扩缩容，使得使得数据架构可以动态、平滑地适配业务的增长。TiDB 原生分布式特点在高并发查询、缺失索引、模糊查询等方面性能表现优异，无需担心租户增加带来高并发问题以及租户单实体数据量大等问题；TiDB HTAP 能力使得海量数据场景下的各类查询秒级得到反馈，极大提升了 CRM 的用户使用体验。\n\n### 提升 SaaS 服务商的业务灵活性\n\n在 SaaS 的基础上集成 PaaS 能力已经成为中国企业级 CRM 市场发展的重要趋势，为了满足企业用户的高度定制化和多样化需求，PaaS 平台要求数据平台具备高度灵活的可定制能力，例如增加字段完成功能迭代等。TiDB 支持 Online DDL，可实现在线添加字段，修改字段对业务无影响，加快了业务创新的速度，进一步增强了 CRM 等 SaaS 服务商在同行业中的竞争力。\n\n### 多管齐下，降低成本\n\nTiDB 一个数据栈支持混合负载，并提供实时的数据洞察，精简了 CRM 服务商数据平台的架构。从单体数据库集群、ETL 工具、数据仓库的多套系统组合到一个 TiDB 集群，大幅节省了数据在各个技术栈之间同步的时间成本以及多个数据副本的存储成本。TiDB 无需分库分表，提高了产品研发的敏捷度，减轻了各类应用的适配难度，研发人员可以把更多精力放在功能迭代和业务创新上。此外，TiDB 还提供了整套的数据同步及数据库管理、监控工具，进一步降低了后期的运维管理成本。 \n\n采用一个简单、强大、一栈式的数据服务平台成为越来越多 SaaS 企业的选择，这个平台既可以支撑海量在线交易，又可以提供实时分析能力，以极少的 DBA 和资源投入，就可以从容应对不确定的环境、多变的业务挑战。 \n\n\n","date":"2022-10-27","author":"PingCAP","fillInMethod":"writeDirectly","customUrl":"htap-database-practice-in-a-chinese-saas-provider","file":null,"relatedBlogs":[{"relatedBlog":{"body":"日前，“中国财险科技应用高峰论坛”在北京召开。PingCAP 副总裁刘松在大会中分享了主题为《TiDB 分布式数据库在保险行业关键应用场景的探索与实践》的演讲，从财险核心场景创新，到基础软件行业趋势做了深入分析，并结合保险数字化趋势，展望了保险数字化未来的可能性。以下为分享实录。\n\n\nPingCAP 副总裁 刘松\n\n## 新技术环境：“开源+云”的互相推动与演进\n\n\n\n过去 20 年，从互联网创新到数字化，背后有着两个重要趋势：一是“开源”，二是“云”。其中，开源经历了几个不同的发展阶段。第一代开源是 90 年代以 Linux 为代表的的开源运动，主要是对抗闭源软件；第二代开源是 2000 年代，所有移动互联网公司的数字平台都开始采用以开源为主的技术栈。这个时代中，从互联网技术栈中产生了一种重要的 IT 服务形态——云计算；到 2015 年后，随着云计算的 IaaS 层规模越来越庞大以及多云、云原生的兴起，开源也进入了第三代。新一代的开源已经不是互联网公司自己家里的开源，而是每一个场景用户都在用的开源。最重要的软件技术都已经变成原生开源为主的，再结合云计算 2.0 服务形态，形成了“开源+多云”的技术生态。今天，我们正处在开源 3.0 和云计算 2.0 结合的早期阶段。\n\n\n\n从现在开始到 2030 - 2035 年间，全世界最重要的基础软件技术将多数来自开源项目，如新一代的 SaaS、人工智能、物联网、区块链、低代码、云原生等技术的源头都将是开源，构成了一个个技术引擎。而云计算就像“组装汽车”，可以把好的开源技术引擎组合成云服务交付给用户。开源打造“引擎”，借助云组装成“汽车”，帮助每一个客户更容易走向自己的数字化旅程。这三者形成了一个数字化创新三角，所有技术都会被“开源、云”这两个关键技术重新塑造，这也是未来 10-15 年整个软件行业的主导形态。因为这个大三角的技术环境，今天的数据库和 20 年前的数据库已经有了天壤之别。20 年前，数据库还主要是信息化的交易系统，而今天的数据库既能解决交易系统问题，又要解决大数据分析问题，还要和云厂商结合做云原生的创新，以及通过 AI 更快的发现数据的价值。在这一趋势影响下，有分析机构预测，未来 5 年所有行业的数字化创新速度，会是过去 10 年的 5-10 倍。\n\n## TiDB ：融合开源和云两个生态的价值\n\nTiDB 是 2015 年创立的全球性开源项目，它处在第三代开源时代起始，一开始就是云原生的状态，在将开源的快速迭代能力和云的敏捷性相结合后，使得 TiDB 这样一个开源数据库只用了 7 年时间，就成为中国最流行的数据库，在墨天轮国产数据库排行榜上一直保持第一名位置。在 Gartner 2022 云数据库“客户之声”中，PingCAP 成为中国唯一入选的分布式云数据库服务商。沙利文头豹研究院也将 TiDB 放在《2021 年中国分布式数据库市场报告》领导者象限。\n\n\n\n## 中国基础软件全球化创新之路——自主开源模式\n\n在 TiDB 的成长历程中，最重要的一个关键词就是“自主开源”的发展模式，该模式经过 7 年多的实践，得到了客户、分析机构的认可。现在业界和金融行业里都有了一个新的认知：唯有真正自主开源才能从根本上解决卡脖子问题，并持续保持领先性。这种发展路径不是简单地去替代他人的过去，而是使我们的技术始终保持在世界前列，构建一个“开源和多云”的新生态。今天选择 TiDB 不只是解决今天的问题，它还要让使用 TiDB 的用户保持持续的技术领先。\n\n\n\n众所周知，数据库市场有很多流派，很多品牌的数据库是一个品牌的名字，在一个品牌下面又有很多的技术栈，对于大多数客户而言，数据库用起来通常都很复杂，往往一个项目涉及 N 多产品的集成，那么能不能有一个简单而强大的数据库呢？TiDB 只有一个产品，它可以在公有云上、私有云上，行业云上、客户的数据中心里部署。只要懂 SQL ，用户就能以一种统一的体验解决自己业务和应用的问题。\n\nTiDB 的很多大型客户已经以 1+N 的方式在部署 TiDB，他们在数据库核心系统用 TiDB 企业级版本，在云上部署一个 TiDB 的云数据库。用户可以自动扩容解决海量数据规模，TiDB 最大的用户已经有近千台节点。所以，无论是对数字原生企业，还是数字化转型企业，比如保险行业，在做数字化转型时，都会让用户没有任何负担地去使用数据库，同时简单而强大，不用关心它的部署模式。\n\n借助开源模式最大的好处就是能够最快速度获取用户，有一些比 TiDB 成立还早的公司到现在也只有 100 到 200 个客户，而 TiDB 在全球已经拥有超过 3000 多家用户，不乏一些顶级的技术巨头，包括美国、日本、东南亚的客户，中国的银行和保险行业客户。作为一个第三代开源和云原生的数据库，TiDB 可以天然服务于数字化企业，现在还在把这种能力传递给更多经典传统行业进行数字化转型。\n\n## 数字化创新三层结构\n\n\n\n如上图所示，产业界发展到了这个时候，出现了明显分层。最底层做云基础设施的，不管是公有云、私有云，还是混合云，IaaS 层已经足够大，足够稳定。最上层的是的类似中科软这样的大型应用软件供应商，主要做端上的应用创新，如私域运营、会员体系等。未来世界最重要的中坚力量将来自于数据价值的创新，新一代数据库会逐渐结合大数据技术和人工智能技术，形成相对独立的中间层。这一层既是开源又是多云的，向上对业务的场景支撑会更直接，向下对于云资源的运用会更加智能。对于所有面向客户经营的业务和面向业务人员的客户，他们希望有一个一栈式的技术栈，既解决实时交易，又能分析业务，这相当于是一个数据的“任意门”，这边做保险的核心交易，同时在另一边又能看到数据大屏和评估可能的业务风险。\n\n\n\nTiDB 的定位便是如此，以一个统一的数据服务层，同时面对海量交易和实时分析，能够满足巨大的吞吐量和各种各样的数据分析要求。作为一个原生的分布式数据库，TiDB 可以从 1 TB 扩展到 1 PB，从单机版数据库覆盖的范围，一直拓展到大数据覆盖的范围。同时，开放的 TiDB 还可以和其他大多数数据湖、数据仓库架构相融合。\n\n## TiDB 分布式数据库在财险的应用\n\nA 财险公司的单证系统面临着数据量增长迅速、业务并发量高、处理性能低等挑战，传统 IOE 架构下需要依赖昂贵的高端服务器，软硬件及服务成本非常高，业务方希望能有一个 HTAP 数据库，既满足单个订单的快速处理，又满足批量订单的分析处理，实现降本增效的目标。传统的数据库产品面临着许多技术难题，海量数据下系统能不能自动伸缩扩展？有没有单点故障？TP 响应时间长，AP 分析报表时间达小时级，这些问题解法只有通过新一代的原生分布式数据库才能解决。\n\nTiDB 基于原生分布式架构，计算存储分离设计，可在线弹性扩缩容。HTAP 一栈式架构支持混合负载，支持高并发实时交易业务和复杂分析查询，可实现毫秒级的 TP 与秒级的 AP 查询能力，并且具有良好的物理隔离性与数据强一致性。TiDB 还高度兼容 MySQL 生态，从用户视角看上去就是在用一个大号的 MySQL，但是容量高了 1-2 个数量级，价格却低了 1-2 个数量级。同时，TiDB 在国产化适配方面与主流国产服务器及操作系统兼容适配，与 170 多家合作伙伴形成上下游的整体生态。\n\n在该财险案例中，通过从 传统数据库迁移到 TiDB ，在单证的交易系统中，平均时延从分钟级提升到秒级，效率提升达到几十倍，在分析方面甚至有上百倍的性能提升，这就是新一代分布式数据库架构优势带来的价值。同时，原生分布式数据库带来的天然的弹性扩展和高可用可以保障保险业务的高速增长。\n\n与 A 财险不同，B 保险集团是先从互联网业务开始接触 TiDB 的，彼时传统单机版数据库支撑不住其互联网业务 APP 的快速发展。于是，TiDB 从外围到核心，切入到多个互联网业务系统，陆续支持客户信息管理系统，帮助 B 保险集团的硬件成本节省超过 30% 以上。在第二阶段，TiDB 继续挺进客户统一营销活动管理、客户信息核心管理、保单服务、理赔等多个业务系统中，助力坐席电话销售中心的实时大屏等创新场景，帮助客户系统实现边交易、边分析，提升业务系统的数据实时分析能力。第三阶段，客户通过 TiDB 实现自主创新，实现产险、财险、普惠金融等多个业务单元的核心系统替换。未来， B 保险集团还希望通过 TiDB 实现更多的数据自主和对于多云架构的兼容。\n\n在此过程中，B 保险集团还基于 TiDB 的版本开发出自己的数据库版本。开源带来的好处是所有的代码都是全透明的，不需要依赖于上游的变化，可以打造自己的特定保险行业的自主创新体系，并不断演进。\n\n## 保险数字化：进入融合发展时代\n\n\n\n保险行业已经经历了物理网点时代、渠道时代、互联网时代，目前形成了以移动互联网为代表的端侧客户运营和会员体系。再下一代可能是什么？保险将无处不在。未来的场景和产业只要有“焦虑”，就会有保险的机会，都需要将保险融到其中，所以这将是一个“融合时代”。目前，保险行业解决了人的安全需求，如人身焦虑、财产担心、常见的车损等等。未来保险行业肯定也会产生新的形态，这既要尊重人的社会需求，又要考虑新技术带来的更多可能性。","author":"刘松","category":4,"customUrl":"tidb-practice-in-key-scenarios-of-insurance-industry","fillInMethod":"writeDirectly","id":421,"summary":"本文为 PingCAP 副总裁刘松在“中国财险科技应用高峰论坛”中所做的《TiDB 分布式数据库在保险行业关键应用场景的探索与实践》的演讲实录。","tags":["TiDB"],"title":"TiDB 分布式数据库在保险行业关键应用场景的探索与实践丨中国财险科技应用高峰论坛"}},{"relatedBlog":{"body":"> 本文根据多点 Dmall 数据库团队负责人冯光普在 TUG 企业行成都站的分享整理而成，介绍了在数字化零售场景下，TiDB 在多点的使用情况、核心业务场景支撑、价值分析、及经验总结。\n\n## 一、Dmall OS 数字化零售方案\n\nDmall OS 是多点全渠道数字化零售方案，通过对零售场景中人、货、场全方位数字化解构+重构，赋能零售商和品牌商，帮助客户实现会员数字化、搭建线上线下一体化营销体系、实现门店作业在线化协同、以及智能供应链，助力商家降本、增效、提升客户体验。\n\n\n\n\n截止到 2021 年 6 月，Dmall OS 已助力物美，麦德龙，711，新百，中百，重百，锅圈食汇，DairyFarm，万宁等 120+ 国内外零售商，覆盖连锁商超、便利店、专营零售等业态；并基于全渠道零售数据为国内外知名品牌实现高速增长。\n\n\n\n\n## 二、TiDB 整体使用情况\n\n多点自 2019 年接触 TiDB，目前有超过 30 个 TiDB 集群，服务器节点超过 300 个，总数据量 320TB 以上，其中，最大的 TiDB 集群有 40 台服务器规模，数据量级 60TB，集群 QPS 峰值达到了 100K。\n\n- 2020 年开始调研并在非关键业务中试用，当时版本是 v3.1；\n\n- 2021 年正式跑通上线，在业财融合场景中落地，版本 v4.0.9，除 TiCDC 偶尔出问题，整体比较稳定；\n\n- 2022 年整体升级到 v5.1.4 后，TiCDC 稳定性问题也得到彻底解决，研发和 DBA 睡觉非常踏实；\n\nTiDB 大版本升级，使用 TiUP 仅一条命令即可完成，滚动的方式，过程中业务也很平滑，深得 DBA 喜爱\n\n\n\n\n\n当前各行业数字化转型，将领域对象、流程、场景数字化，实现实时在线、高效协同、智能决策，垂直领域的 SaaS 解决方案不断涌现，它们在助力企业降本增效的同时，在数据方面也面临以下技术挑战：\n\n1. **数据持续快速增长**，对于 MySQL 等开源单机数据库，达到容量上限需引入分库分表方案，比如 Sharding-JDBC，这类方案虽然逻辑上透明，但使用后 SQL 能力受限，实际很难执行跨节点 SQL；\n\n1. **实时商业洞察**，数据规模大且产生速度快，对 AP 也提出了挑战，T+1 的方式已经难以满足商业洞察和决策的需求了，比如：商家营销活动的执行效果分析，如果依赖 ETL 抽数+离线计算的技术方案，就无法在活动进行中及时优化营销策略，提升有限资源的回报率；\n\n1. **更低的成本**，不仅是资源层面的存储成本，计算成本，也包括架构及维护成本，弹性可扩展的云原生架构是未来的发展趋势；\n\n\n\n\n## 三、核心业务场景支撑\n\nTiDB 在多点 Dmall 的典型应用场景，简单归纳，主要有以下三类：\n\n1.**海量流水类存储**，使用 TiDB 直接替换了 MySQL，多并发批量写的方式，充分发挥 TiDB 高吞吐的优势，典型场景：App 推送记录，短信发送记录，单次营销活动产生的记录可达千万规模，从 MySQL 切换到 TiDB 后，DBA 就告别了容量焦虑，不用频繁归档历史数据，且 RocksDB 引擎相对 InnoDB 引擎有 3~10 的压缩优势，成本比使用 MySQL 更低；\n\n\n\n\n2.**冷热分离全量存储**，对于响应时间敏感，同时数据持续快速增长的在线业务，采用读写分离架构，将近期热数据存储在 MySQL，提供高并发低延迟的在线读写，同时实时同步到 TiDB，保存全量数据，提供历史快照查询及统计分析，支持业务数据变更溯源。典型场景：商品调价、库存变更，数据量超过了单机 MySQL 容量，且持续增长，基于自研的 DRC-TiDB 组件（它可过滤源端 MySQL 归档 DELETE 事件，同步 MySQL 数据到 TiDB），避免了数据增长超过 MySQL 单机容量后水平拆分的技术复杂度；\n\n\n\n\n3.**多源聚合存储及分析**，中台思想及微服务技术架构，实现了在业务域清晰划分下的技术能力复用，及研发高效分工协同，但也导致了数据散落到各个业务子系统中，全链路的业务聚合分析变得困难，在数据规模超过单机存储容量，且要求准实时性分析时，问题更甚。TiDB 透明的水平扩展能力，及 TiFlash 引擎 AP 能力，为这类场景提供了可行方案，典型场景：营销活动分析，聚合同步了多个在线 MySQL 业务库及 MQ 的数据，在 TiDB 中实时计算活动效果，助力运营评估和优化营销策略。\n\n\n\n\n## 四、TiDB 价值分析\n\n站在研发的视角，使用 TiDB 的好处：\n\n1. **更简单的架构**，TP 分库分表 + ETL 同步聚合 + AP 分析引擎，这种技术架构，除了技术复杂度、资源成本高、运维困难外，结构/数据一致性难以保证，ETL 同步延迟也是常态。TiDB 提供了另外一种可能：基于内建的 Raft learner 数据复制技术简化了架构，实现 TP 业务和 AP 业务基于同一份数据，避免了一致性和延迟问题。\n\n1. **实时数据分析能力**，基于 TiFlash 列存引擎，及 MPP 计算架构，实时业务数据集上的直接分析得以实现，得益于 TiKV 的水平扩展能力，上游数据的流入和存储几乎无限制，更多的数据，可放大实时数据分析的价值。\n\n1. **专注业务创新**，在充满不确定性的商业竞争中，为快速验证 MVP，业务早期存储选型采用简单易用的 MySQL，但在数据规模达到单机容量上限引入分库分表等技术后，业务研发就需要关注底层存储架构的约束和限制，开发效率降低；甚至权衡性能、稳定性、或成本被迫放弃部分需求特性，业务创新也受到影响，丢失早期竞争优势。TiDB 提供了另外一种可能：在业务进入快速增长阶段，底层存储的扩展对上层业务真正透明，让研发可以专注于业务创新和快速迭代。\n\n\n\n\n站在运维 DBA 视角，使用 TiDB 的好处：\n\n1. **云原生红利**，TiDB 符合云原生架构理念，不论计算层，还是存储层，加机器即扩容，可按需、弹性、近乎无限扩展，相较于 MySQL 分库分表方案的技术复杂、实施门槛高、SQL 能力受限，大规模快速增长数据场景下，运维 TiDB 幸福指数高于运维 MySQL；\n\n1. **MySQL生态友好**，TiDB 兼容 MySQL 协议，已建成的平台工具，可直接复用，比如：查询工具，慢 SQL 分析，监控指令等，DBA 可快速上手为研发提供数据库接入服务；\n\n1. **数据可靠性高**，MySQL 需要依赖外部 HA 组件实现故障切换，除部署配置复杂外，还难以彻底避免脑裂问题，TiDB 内部实现了基于 Raft 的数据同步和故障切换，failover 高效可靠，数据强一致保证，DBA 几乎没有心智负担；\n\n\n\n\n在成本方面，TiDB 一直有很多争议：1）组件多，有 PD、TiKV、TiDB 等；2）多副本+高可用，集群部署起步成本较高，会劝退很多用户。根据我们实际使用经验，成本方面的真实情况是：\n\n- 在数据规模较小，如在单机 MySQL 容量以内，主从两节点 MySQL 集群，成本是远低于 TiDB 集群的；\n\n- 当数据规模超过单机 MySQL 容量，需要引入 sharding 方案后，情况会发生变化，使用 TiDB 可能比使用 MySQL 更便宜，主要因为：\n\n- TiKV 的 RocksDB 引擎相对 InnoDB 引擎，有 3~10 倍压缩优势，存储相同规模数据，TiDB 的存储节点数远远低于 MySQL 集群；\n\n- 随着数据规模增长，只有 TiKV 节点数是随之增长，PD 节点的成本基本不增长，而 TiDB 节点数是与 QPS 相关；\n\n- 还需考虑引入 sharding 方案后，技术复杂度提升，SQL 能力受限，会带来运维成本的升高，以及开发效率的降低；\n\n\n\n\n## 五、实践经验及场景对比\n\n从使用 MySQL 切换到使用 TiDB，需要重点关注和理解分布式架构的优缺点，尤其是算存分离以及分布式事务带来的网络开销，局域网的网络交互延迟，与读写 SSD 的 IO 延迟在一个级别，它远远高于单机数据库进程内的数据交互，简单总结一下，结论：\n\n- TiDB 相比 MySQL 响应更慢；\n\n- TiDB 相比 MySQL 可输出吞吐更高；\n\n因此，建议采用多并发、批量读写的方式，以发挥 TiDB 的优势。\n\n\n\n\n下图是 MySQL 与 TiDB 的详细优劣势对比和选型参考，在数据规模小，要求低延迟的 TP 业务场景中，MySQL 更加合适，而在数据规模远超单机容量、持续快速增长、对响应延迟不那么敏感的 HTAP 业务场景中，使用 TiDB 更加合适。\n\n\n\n\n## 六、总结\n\n- TiDB 基于云原生理念，采用算存分离架构，可以按需、弹性、近乎无限的水平扩展；\n\n- 基于 TiDB 的 HTAP 能力，可实现同时支撑 TP 业务和 AP 业务的一体化架构，综合成本低；\n\n- TiDB 与 MySQL 相辅相成，生态友好，是优秀的面向数据快速增长的理想选择。\n\n> 延展阅读： \n[“新经济 DTC 转型背后的数据库”专题 ](https://pingcap.com/zh/events/database-behind-new-economy-digital-transformation) \n点击查看更多[新经济 DTC 转型案例实践](https://pingcap.com/zh/blog?tag=%E6%96%B0%E7%BB%8F%E6%B5%8E%20DTC%20%E8%BD%AC%E5%9E%8B)","author":"冯光普","category":4,"customUrl":"tidb-in-digital-retail-in-dmall","fillInMethod":"writeDirectly","id":403,"summary":"本文根据多点 Dmall 数据库团队负责人冯光普在 TUG 企业行成都站的分享整理而成，介绍了在数字化零售场景下，TiDB 在多点的使用情况、核心业务场景支撑、价值分析、及经验总结。","tags":["TiDB","新经济 DTC 转型"],"title":"TiDB 在多点数字化零售场景下的应用"}}]}}},
"staticQueryHashes": ["1327623483","1820662718","3081853212","3430003955","3649515864","4265596160","63159454"]}