爱奇艺数据库实践：不同场景如何快速选择数据库
作者：郭磊涛，爱奇艺数据库和中间件负责人，TiDB]作者：郭磊涛，爱奇艺数据库和中间件负责人，TiDB]我是爱奇艺的数据库和中间件负责人郭磊涛，今天主要向大家分享数据库选型方面的思路，供大家参考和学习。我们进行数据库选型的时候要考虑哪些问题？有哪些需求？待选用的数据库是否和需求对的上？是不是直接就可以拿来用？需不需要一些额外的开发？这些都会在今天的分享中提及。1 WX20191014-202421@2x.png2330×1278 260 KB
我们做选型的时候首先要问：<span]我们做选型的时候首先要问：<span]谁选型？是负责采购的同学、 DBA 还是业务研发？如果选型的是采购的同学，他们更注重成本，包括存储方式、网络需求等。<span]如果选型的是采购的同学，他们更注重成本，包括存储方式、网络需求等。<span]如果选型的是 DBA 同学，他们关心的：
[*]首先是运维成本，包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等；
[*]其次DBA会关注稳定性，包括是否支持数据多副本、服务高可用、多写多活等；
[*]第三是性能，包括延迟、QPS 以及是否支持更高级的分级存储功能等；
[*]第四是扩展性，如果业务的需求不确定，是否容易横向扩展和纵向扩容；最后是安全，需要符合审计要求，不容易出现 SQL 注入或拖库情况。
除了采购和]除了采购和]可以看到爱奇艺的数据库种类还是很多的，这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。那么，我们先对这些数据库按照接口（SQL，NoSQL）和面向的业务场景（OLTP, OLAP）这两位维度进行一个简单非严谨的分类。左上角是面向]左上角是面向]左下角是 NoSQL 数据库，是一类针对特殊场景做优化的系统，schema 一般比较简单，吞吐量较高、延迟较低，一般用作缓存或者 KV 数据库。整个右侧都是]整个右侧都是]还有一类数据库是比较中立的，在数据量比较小的时候性能比较好，在数据量较大或复杂查询的时候性能也不差，一般通过不同的存储引擎和查询引擎来满足不同的业务需求，我们把它叫做 HTAP，TiDB 就是这样一种数据库。
https://asktug.com/uploads/default/optimized/2X/e/e78c121a43a643693409e5cc7020377a2ffea7d9_2_690x411.png3 WX20191014-202519@2x.png2144×1278 228 KB
前面我们提到了很多种的数据库，那么接下来就和大家介绍一下在爱奇艺我们是怎么使用这些数据库的。
MySQL 在爱奇艺的使用首先是]首先是]第二是适配 DDL 和 DML 工具到内部系统，gh-ostt 和 oak-online-alter-table 在数据量大的时候会造成 master-slave 延时，所以我们在使用工具的时候也增加了延时上的考虑，实时探测Master-Slave 库之间延时的情况，如果延时较大会暂停工具的使用，恢复到正常水平再继续。第二是]第二是]第三是提高MySQL扩展能力，以提供更大容量的数据存储。扩展方式有 SDK，例如开源的 ShardingSphere，在爱奇艺的使用也比较广泛。另外就是 Proxy，开源的就更多了。但是 SDK 和 Proxy 使用的问题是支持的 SQL 语句简单，扩容难度大，依赖较多且运维复杂，所以部分业务已经迁移至 TiDB。第四是审计。我们在]第四是审计。我们在]第五是分级存储。MySQL 里会存一些过程性的数据，即只需要读写最近一段时间存入的数据，过段时间这些数据就不需要了，需要进行定时清理。分级存储就是在 MySQL 之上又用了其他存储方式，例如 TiDB 或其他 TokuDB，两者之间可以进行数据自动搬迁和自动归档，同时前端通过 SDK + Proxy 来做统一的访问入口。这样一来，业务的开发同学只需要将数据存入 MySQL 里，读取时可能从后端接入的任意数据库读出。这种方式目前只是过渡使用，之后会根据 TiDB 的特性进行逐步迁移。
https://asktug.com/uploads/default/optimized/2X/4/4678e29ceff77a71c3d4e039493feb8d9cf48479_2_690x374.png4 WX20191014-202559@2x.png2368×1284 546 KB
Redis 在爱奇艺的使用接下来是]接下来是]备份恢复方面介绍一个我们的特殊场景，虽然 Redis 是一个缓存，但我们发现不少的业务同学会把它当做一个 KVDB 来使用，在某些情况下会造成数据的丢失。所以我们做了一个 Redis 实时备份功能，启动一个进程伪装成 Redis 的 Slave 实时获取数据，再放到后端的 KV 存储里，例如 ScyllaDB，如果要恢复就可以从 ScyllaDB 里把数据拉出来。我们在用 Redis 时最大的痛点就是它对网络的延迟或抖动非常敏感。如有抖动造成 Redis Master 超时，会由 Sentinel 重新选出一个新的节点成为 Master，再把该节点上的数据同步到所有 Slave 上，此过程中数据会放在 Master 节点的 Buffer 里，如果写入的 QPS 很高会造成 Buffer 满溢。如果 Buffer 满后 RDB 文件还没有拷贝过去，重建过程就会失败。基于这种情况，我们对]基于这种情况，我们对]我们在做 Redis 开发时如果是 Java 语言都会用到 Jedis。用 Jedis 访问客户端分片的 Redis 集群，如果某个分片发生了故障或者 failover，Jedis 就会对所有后端的分片重建连接。如果某一分片发生问题，整个 Redis 的访问性能和 QPS 会大幅降低。针对这个情况我们优化了 Jedis，如果某个分片发生故障，就只针对这个分片进行重建。在业务访问]在业务访问]客户端分片的方式会造成 Redis 的扩容非常痛苦，如果客户端已经进行了一定量的分片，之后再增加就会非常艰难。Redis 在 3.0 版本后会提供 Redis Cluster，因为功能受限在爱奇艺应用的不是很多，例如不支持显示跨 DC 部署和访问，读写只在主库上等。我们某些业务场景下会使用 Redis 集群，例如数据库访问只发生在本 DC，我们会在 DC 内部进行 Cluster 部署。但有些业务在使用的过程中还是想做 failover，如果集群故障可以切换到其他集群。根据这种情况我们做了一个 Proxy，读写都通过它来进行。写入数据时 Proxy 会做一个旁路，把新增的数据写在 Kafka 里，后台启用同步程序再把 Kafka 里的数据同步到其他集群，但存在一些限制，比如我们没有做冲突检测，所以集群间数据需要业务的同学做单元化。线上环境的Redis Cluster 集群间场景跨 DC 同步 需要 50 毫秒左右的时间。
https://asktug.com/uploads/default/optimized/2X/6/6b52dfd29d41f29400f497340f48776c4b7d0e08_2_690x380.png5 WX20191014-202651@2x.png2352×1296 547 KB
Couchbase 在爱奇艺的使用Redis]Redis]Couchbase 在国内互联网公司用的比较少，一开始我们是把他当做一个 Memcached 来使用的，即纯粹的缓存系统。但其实它性能还是比较强大的，是一个分布式高性能的 KV 系统，支持多种存储引擎 (bucket)。第一种是 Memcached bucket，使用方式和 Memcached 一样为 KV 存储，不支持数据持久化也没有数据副本，如果节点故障会丢失数据；第二种是 Couchbase bucket，支持数据持久化，使用 Json 写入，有副本，我们一般会在线上配置两个副本，如果新加节点会对数据进行 rebalance，爱奇艺使用的一般是 Couchbase bucket 这种配置。Couchbase 数据的分布如右图，数据写入时在客户端上会先进行一次哈希运算，运算完后会定位 Key 在哪一个 vBucket （相当于数据库里的某个分片）。之后客户端会根据 Cluster Map 发送信息至对应的服务端，客户端的 Cluster Map 保存的是 vBucket 和服务器的映射关系，在服务端数据迁移的过程中客户端的 Cluster Map 映射关系会动态更新，因此客户端对于 服务端的 failover 操作不需要做特殊处理，但可能在 rebalance 过程中会有短暂的超时，导致的告警对业务影响不大。Couchbase]Couchbase]Couchbase 的集群是独立集群，集群间的数据同步通过 XDCR，我们一般配置为双向同步。对于业务来说，如果 Cluster 1 写入， Cluster 2 不写入，正常情况下客户端会写 Cluster 1。如果 Cluster 1 有故障，我们提供了一个 Java SDK，可以在配置中心把写入更改到 Cluster 2，把原来到 Cluster 1 的连接逐步断掉再与Cluster 2 新建连接。这种集群 failover 的过程对于客户端来说是相对透明和无感的。
https://asktug.com/uploads/default/optimized/2X/6/62802c93a1869c26433b2fd1619c3b0d128d3131_2_690x387.jpeg6 WX20191014-202717@2x.jpg2286×1284 421 KB
爱奇艺自研数据库 HiKV 的使用Couchbase]Couchbase]开发 HiKV 的目的是为了把一些对性能要求没那么高的 Couchbase 应用迁移到 HiKV 上。HiKV 基于开源系统 ScyllaDB，主要使用了其分布式数据库的管理功能，增加了单机存储引擎 HiKV。 ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍，又完全兼容 Cassandra 接口，设计基本一致，可以视为 C++ 版 Cassandra 系统。 ScyllaDB 性能的提升主要是使用了一些新的技术框架，例如 C++ 异步框架 seastar，主要原理是在j每台物理机的核上会 attach 一个应用线程，每个核上有自己独立的内存、网络、IO 资源，核与核之间没有数据共享但可以通信，其最大的好处是内存访问无锁，没有冲突过程。当一个数据读或写到达 ScyllaDB 的 server 时，会按照哈希算法来判断请求的 Key 是否是该线程需要处理的，如果是则本线程处理，否则会转发到对应线程上去。除此之外，它还支持多副本、多数据中心、多写多活，功能比较强大。在爱奇艺，我们基于]在爱奇艺，我们基于]HiKV 目前在爱奇艺应用范围比较大，截至目前已经替换了 30% 的 Couchbase，有效地降低了存储成本。
https://asktug.com/uploads/default/optimized/2X/e/e2332cc2c33da006aa8c947822cf2384609cf51a_2_690x372.png8 WX20191014-202800@2x.png2360×1274 524 KB
爱奇艺的数据库运维管理爱奇艺数据库种类较多，如何高效地运维和管理这些数据库也是经历了不同的阶段。<span]爱奇艺数据库种类较多，如何高效地运维和管理这些数据库也是经历了不同的阶段。<span]最初我们通过 DBA 写脚本的方式管理，如果脚本出问题就找 DBA，导致了 DBA 特别忙碌。第二个阶段我们考虑让大家自己去查问题的答案，于是在内部构建了一个私有云，通过]第二个阶段我们考虑让大家自己去查问题的答案，于是在内部构建了一个私有云，通过]于是在第三个阶段我们把运维操作 Web 化，通过网页点击可以进行 90% 的操作。第四个阶段让经验丰富的]第四个阶段让经验丰富的]最后来说一些具体数据库选型建议。这是 DBA 和业务一起，通过经验得出来的一些结论。对于关系型数据库的选型来说，可以从数据量和扩展性两个维度考虑，再根据数据库有没有冷备、要不要使用 Toku 存储引擎，要不要使用 Proxy 等等进行抉择。
https://asktug.com/uploads/default/optimized/2X/8/8fef5892ef864a895479a41483571bb6dcebbc4d_2_690x388.jpeg13.jpg2000×1125 157 KB
NoSQL]NoSQL]我们在选形时先思考需求，判断需求是否真实。你可以从数据量、QPS、延时等方面考虑需求，但这些都是真实需求吗？是否可以通过其他方式把这个需求消耗掉，例如在数据量大的情况下可以先做数据编码或者压缩，数据量可能就降下来了。不要把所有需求都推到数据库层面，它其实是一个兜底的系统。第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么？是因为热门吗？还是因为技术上比较先进？但是不是能真正地解决你的问题？如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。<span]第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么？是因为热门吗？还是因为技术上比较先进？但是不是能真正地解决你的问题？如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。<span]第三是放弃，当你放弃一个系统时真的是因为不好用吗？还是没有用好？放弃一个东西很难，但在放弃时最好有一个充分的理由，包括实测的结果。第四是自研，在需要自己开发数据库时可以参考和使用一些成熟的产品，但不要盲目自研。<span]第四是自研，在需要自己开发数据库时可以参考和使用一些成熟的产品，但不要盲目自研。<span]最后是开源，要有拥抱开源的态度。
https://asktug.com/uploads/default/optimized/2X/6/6659919e2ecf85bd4015d677e10e7d69ab1cc901_2_690x443.png12 WX20191014-202856@2x.png2018×1296 287 KB
大家在数据库选型中会考虑哪些因素呢？欢迎评论留言告诉大家你的想法～<span]大家在数据库选型中会考虑哪些因素呢？欢迎评论留言告诉大家你的想法～<span]本文转载自 AskTUGOracle DBA交流
页:
[1]