爱奇艺的 "数据库" 选型到底有多牛逼？
来源：rrd.me/fgGsG
我们进行数据库选型的时候要考虑哪些问题？有哪些需求？待选用的数据库是否和需求对得上？是不是直接可以拿来用？需不需要一些额外的开发？这些都会在本文的分享中提及。
一、数据库技术选型的思考维度
我们做选型的时候首先要问：谁选型？是负责采购的同学、 DBA 还是业务研发？如果选型的是采购的同学，他们更注重成本，包括存储方式、网络需求等。如果选型的是 DBA 同学，他们关心的：
① 运维成本
首先是运维成本，包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等；
② 稳定性
其次，DBA会关注稳定性，包括是否支持数据多副本、服务高可用、多写多活等；
③ 性能
第三是性能，包括延迟、QPS 以及是否支持更高级的分级存储功能等；
④ 拓展性
第四是扩展性，如果业务的需求不确定，是否容易横向扩展和纵向扩容；
⑤ 安全
最后是安全，需要符合审计要求，不容易出现 SQL 注入或拖库情况。
⑥ 其他
除了采购和 DBA之外，后台应用研发的同学同样会关注稳定性、性能、扩展性等问题，同时也非常关注数据库接口是否便于开发，是否便于修改数据库 schema 等问题。
接下来我们来看一下爱奇艺使用的数据库类型：
MySQL，互联网业务必备系统； TiDB，爱奇艺的 TiDB 实践会有另外的具体介绍； Redis，KV 数据库，互联网公司标配； Couchbase，这个在爱奇艺用得比较多，但国内互联网公司用得比较少，接下来的部分会详细说明； 其他，比如 MongoDB、图数据库、自研 KV 数据库 HiKV 等； 大数据分析相关系统，比如 Hive、Impala 等等。
可以看到爱奇艺的数据库种类还是很多的，这会造成业务开发的同学可能不太清楚在他的业务场景下应该选用哪种数据库系统。
那么，我们先对这些数据库按照接口（SQL、NoSQL）和面向的业务场景（OLTP、OLAP）这两位维度进行一个简单非严谨的分类。
下图中，左上角是面向 OLTP、支持 SQL 的这样一类系统，例如 MySQL，一般支持事务不同的隔离级别， QPS 要求比较高，延时比较低，主要用于交易信息和关键数据的存储，比如订单、VIP 信息等。
左下角是 NoSQL 数据库，是一类针对特殊场景做优化的系统，schema 一般比较简单，吞吐量较高、延迟较低，一般用作缓存或者 KV 数据库。
整个右侧都是 OLAP 的大数据分析系统，包括 Clickhouse、Impala等，一般支持SQL、不支持事务，扩展性比较好，可以通过加机器增加数据的存储量，响应延迟较长。
还有一类数据库是比较中立的，在数据量比较小的时候性能比较好，在数据量较大或复杂查询的时候性能也不差，一般通过不同的存储引擎和查询引擎来满足不同的业务需求，我们把它叫做 HTAP，TiDB 就是这样一种数据库。
1、MySQL在爱奇艺的使用
① MySQL
首先是 MySQL。MySQL 基本使用方式是 master-slave + 半同步，支持每周全备+每日增量备份。我们做了一些基本功能的增强，首先是增强了数据恢复工具 Xtrabackup 的性能。
之前遇到一个情况，我们有一个全量库是 300G 数据，增量库每天 70G 数据，总数据量 700G 左右。我们当时只需要恢复一个表的数据，但该工具不支持单表恢复，且整库恢复需要 5 个小时。
② MySQL高可用
MySQL 审计插件最大的问题是如何降低对 MySQL 性能的影响，对此我们进行了一些测试，发现使用 General Log 对性能损耗较大，有 10%~20% 的降低。
目前已经在公司内部的集群上线了一年时间，运行比较稳定，上线和下线对业务没有影响。
第五是分级存储。MySQL 里会存一些过程性的数据，即只需要读写最近一段时间存入的数据，过段时间这些数据就不需要了，需要进行定时清理。
2、Redis在爱奇艺的使用
备份恢复方面介绍一个我们的特殊场景，虽然 Redis 是一个缓存，但我们发现不少的业务同学会把它当做一个 KVDB 来使用，在某些情况下会造成数据的丢失。
DNS 本身有一个超时时间，所以数据库做完 failover 后业务程序里没有立刻获取到新的 Master 节点的 IP的话，有可能还会连到原来的机器上，造成访问失败。
SDK 上还做了一些功能，例如 Load Balance 以及故障检测，比如某个节点延时较高的话会被临时熔断等。
客户端分片的方式会造成 Redis 的扩容非常痛苦，如果客户端已经进行了一定量的分片，之后再增加就会非常艰难。
Redis 在 3.0 版本后会提供 Redis Cluster，因为功能受限在爱奇艺应用的不是很多，例如不支持显示跨 DC 部署和访问，读写只在主库上等。
我们某些业务场景下会使用 Redis 集群，例如数据库访问只发生在本 DC，我们会在 DC 内部进行 Cluster 部署。
Redis 虽然提供 Cluster 这种部署方式，但存在一些问题。所以数据量较大的时候（经验是 160G），就不推荐 Redis 了，而是采用另一种存储方式 Couchbase。
Couchbase 在国内互联网公司用的比较少，一开始我们是把他当做一个 Memcached 来使用的，即纯粹的缓存系统。
4、爱奇艺自研数据库HiKV的使用
ScyllaDB 比较吸引人的是它宣称性能高于 Cassandra 十倍，又完全兼容 Cassandra 接口，设计基本一致，可以视为 C++ 版 Cassandra 系统。
当一个数据读或写到达 ScyllaDB 的 server 时，会按照哈希算法来判断请求的 Key 是否是该线程需要处理的，如果是则本线程处理，否则会转发到对应线程上去。
除此之外，它还支持多副本、多数据中心、多写多活，功能比较强大。
HiKV 目前在爱奇艺应用范围比较大，截至目前已经替换了 30% 的 Couchbase，有效地降低了存储成本。
爱奇艺数据库种类较多，如何高效地运维和管理这些数据库也是经历了不同的阶段。
最初我们通过 DBA 写脚本的方式管理，如果脚本出问题就找 DBA，导致了 DBA 特别忙碌。
于是在第三个阶段我们把运维操作 Web 化，通过网页点击可以进行 90% 的操作。
除此之外我们还会定期做预警检查，对业务集群里潜在的问题进行预警报告；开发智能客服，回答问题；通过监控的数据对实例打标签，进行削峰填谷地智能调度，提高资源利用率。
1、实用数据库选型树
最后来说一些具体数据库选型建议。这是 DBA 和业务一起，通过经验得出来的一些结论。
对于关系型数据库的选型来说，可以从数据量和扩展性两个维度考虑，再根据数据库有没有冷备、要不要使用 Toku 存储引擎，要不要使用 Proxy 等等进行抉择。
NoSQL 也是什么情况下使用 master-slave，什么情况下使用客户端分片、集群、Couchbase、HiKV 等，我们内部自服务平台上都有这个选型树信息。
① 需求
我们在选型时先思考需求，判断需求是否真实。
你可以从数据量、QPS、延时等方面考虑需求，但这些都是真实需求吗？是否可以通过其他方式把这个需求消耗掉，例如在数据量大的情况下可以先做数据编码或者压缩，数据量可能就降下来了。
不要把所有需求都推到数据库层面，它其实是一个兜底的系统。
② 选择
第二个思考的点是对于某个数据库系统或是某个技术选型我们应该考虑什么？是因为热门吗？还是因为技术上比较先进？但是不是能真正地解决你的问题？如果你数据量不是很大的话就不需要选择可以存储大数据量的系统。
③ 放弃
第三是放弃，当你放弃一个系统时真的是因为不好用吗？还是没有用好？放弃一个东西很难，但在放弃时最好有一个充分的理由，包括实测的结果。
④ 自研
第四是自研，在需要自己开发数据库时可以参考和使用一些成熟的产品，但不要盲目自研。
⑤ 开源
1.不认命，从10年流水线工人，到谷歌上班的程序媛，一位湖南妹子的励志故事
4.“37岁，985毕业，年薪50万，被裁掉只用了10分钟”
5.37岁程序员被裁，120天没找到工作，无奈去小公司，结果懵了...
一个人学习、工作很迷茫？
点击「阅读原文」加入我们的小圈子！