做者:刘广信,火星文化技术经理数据库
卡思数据是国内领先的视频全网数据开放平台,依托领先的数据挖掘与分析能力,为视频内容创做者在节目创做和用户运营方面提供数据支持,为广告主的广告投放提供数据参考和效果监测,为内容投资提供全面客观的价值评估。服务器
<center>图 1 卡思数据产品展现图</center>网络
卡思数据首先经过分布式爬虫系统进行数据抓取,天天新增数据量在 50G - 80G 之间,而且入库时间要求比较短,所以对数据库写入性能要求很高,因为数据增加比较快,对数据库的扩展性也有很高的要求。数据抓取完成后,对数据进行清洗和计算,由于数据量比较大,单表 5 亿 + 条数据,因此对数据库的查询性能要求很高。架构
起初卡思数据采用的是多个 MySQL 实例和一个 MongoDB 集群,如图 2。并发
MySQL 存储业务相关数据,直接面向用户,对事务的要求很高,但在海量数据存储方面偏弱,因为单行较大,单表数据超过千万或 10G 性能就会急剧降低。运维
MongoDB 存储最小单元的数据,MongoDB 有更好的写入性能,保证了天天数据爬取存储速度;对海量数据存储上,MongoDB 内建的分片特性,能够很好的适应大数据量的需求。分布式
<center>图 2 起初卡思数据架构图</center>ide
可是随着业务发展,暴露出一些问题。工具
MySQL 在大数据量的场景下,查询性能难以知足要求,而且扩展能力偏弱,若是采用分库分表方式,须要对业务代码进行全面改造,成本很是高。性能
MongoDB 对复琐事务的不支持,前台业务须要用到数据元及连表查询,当前架构支持的不太友好。
针对咱们遇到的问题,咱们急需这样一款数据库:
兼容 MySQL 协议,数据迁移成本和代码改形成本低
插入性能强
大数据量下的实时查询性能强,无需分库分表
水平扩展能力强
稳定性强,产品最好有成熟的案例
未选择 TiDB 以前咱们调研了几个数据库,Greenplum、HybirdDB for MySQL(PetaData)以及 PolarDB。Greenplum 因为插入性能比较差,而且跟 MySQL 协议有一些不兼容,首先被排除。
HybirdDB for MySQL 是阿里云推出的 HTAP 关系型数据库,咱们在试用一段时间发现一些问题:
一是复杂语句致使计算引擎拥堵,阻塞全部业务,常常出现查询超时的状况。
二是连表查询性能低下,网络 I/O 出现瓶颈。举一个常见的关联查询,cd_video 表,2200 万数据,cd_program_video 表,节目和视频的关联表,4700 万数据,在关联字段上都建有索引,以下 SQL:
select v.id,v.url,v.extra_id,v.title fromcd_video v join cd_program_video pv on v.id = pv.video_id where program_id =xxx;
当相同查询并发超过必定数量时,就会频繁报数据库计算资源不可用的错误。
三是 DDL 操做比较慢,该字段等操做基本须要几分钟,下发至节点后易出现死锁。
PolarDB 是阿里云新推出新一代关系型数据库,主要思想是计算和存储分离架构,使用共享存储技术。因为写入仍是单点写入,插入性能有上限,将来咱们的数据采集规模还会进一步提高,这有可能成为一个瓶颈。另外因为只有一个只读实例,在对大表进行并发查询时性能表现通常。
在经历了痛苦的传统解决方案的折磨以及大量调研及对比后,卡思数据最终选择了 TiDB 做为数据仓库及业务数据库。
TiDB 结合了传统的 RDBMS 和 NoSQL 的最佳特性,高度兼容 MySQL,具有强一致性和高可用性,100% 支持标准的 ACID 事务。因为是 Cloud Native 数据库,可经过并行计算发挥机器性能,在大数量的查询下性能表现良好,而且支持无限的水平扩展,能够很方便的经过加机器解决性能和容量问题。另外提供了很是完善的运维工具,大大减轻数据库的运维工做。
卡思数据目前配置了两个 32C64G 的 TiDB、三个 4C16G 的 PD、四个 32C128G 的 TiKV。数据量大约 60 亿条、4TB 左右,天天新增数据量大约 5000 万,单节点 QPS 峰值为 3000 左右。
因为数据迁移不能影响线上业务,卡思数据在保持继续使用原数据架构的前提下,使用 Mydumper、Loader 进行数据迁移,并在首轮数据迁移完成后使用 Syncer 进行增量同步。
卡思数据部署了数据库监控系统(Prometheus/Grafana)来实时监控服务状态,能够很是清晰的查看服务器问题。
因为 TiDB 对 MySQL 的高度兼容性,在数据迁移完成后,几乎没有对代码作任何修改,平滑实现了无侵入升级。
目前卡思数据的架构如图 3:
<center>图 3 目前卡思数据架构图</center>
查询性能,单表最小 1000 万,最大 8 亿,有比较复杂的连表查询,总体响应延时很是稳定,监控展现如图 四、图 5。
<center>图 4 Duration 监控展现图</center>
<center>图 5 QPS 监控展现图</center>
目前的卡思数据已所有迁移至 TiDB,但对 TiDB 的使用还局限在数据存储上,能够说只实现了 OLTP。卡思数据准备深刻了解 OLAP,将目前一些须要实时返回的复杂查询、数据分析下推至 TiDB。既减小计算服务的复杂性,又可增长数据的准确性。
很是感谢 PingCAP 小伙伴们在数据库上线过程当中的大力支持,每次遇到困难都能及时、细心的给予指导,很是的专业和热心。相信 PingCAP 会愈来愈好,相信 TiDB 会愈来愈完善,引领 NewSQL 的发展。