知名互联网公司都在使用哪些数据库

大数据已经成为国家战略，而大数据首先所面临的问题就是大数据的存储问题，这就绕不开数据库，因为数据库就是用来存储数据的应用软件。任何数据库，都有其优缺点, 无论是传统关系型数据库还是NoSQL数据库又或者NewSQL数据库。因此，到底选择哪个数据库，对企业而言这个决策过程都非常复杂。

就数据库实际应用水平而言，互联网公司显然走在了前列，它们都在使用哪些数据库？分别对应哪些业务场景，为什么会是这样选择？了解的人却并不多。为此，老鱼在DTCC 2017中国数据库技术大会召开前夕，走访了多家知名互联网公司并采访了其技术负责人或DBA，为大家一一揭秘。（注：部分受访者所属部门局限，因此，以下所列企业业务线对应数据库并不全面，仅列出主要应用数据库，供参考。企业排名不分先后，按采访顺序排序！本文将持续更新中……）

阿里巴巴/蚂蚁金服

杨传辉：OceanBase分布式关系数据库：蚂蚁金服的所有核心业务和部分其他业务以及少部分阿里巴巴的业务，可靠性高（单机/单机房故障不停服务、不丢数据）、水平伸缩、高性价比。OceanBase在去年双11支撑了蚂蚁金服100%的交易、支付以及账务流量。

MySQL：蚂蚁金服部分非核心业务和阿里巴巴大部分系统，类似于其他互联网公司。

去哪儿

采访对象：周彦伟，去哪儿网数据库总监，负责数据库平台的管理和维护工作。工作范围包括MySQL，Redis，HBase平台的架构设计，性能调优，日常运维以及自动化运维平台设计。

周彦伟：去哪儿使用MySQL支撑公司大部分OLTP业务，有上千台规模。

同时针对热点数据以及对访问延时特别敏感的业务，去哪儿大规模的使用Redis做缓存。

对于数据量非常大，又不不利于分库分表的数据，去哪儿选择性的使用HBase。

腾讯

采访对象：王懂道，腾讯社交网络运营部平台技术运营中心，负责腾讯社交网络海量存储集群的运维和优化，服务对象包括QQ空间，相册，微云，QQ音乐等。

腾讯社交网络主要使用深度定制MySQL数据库+自研NoSQL，规模万台以上服务器，千万级qps。

王懂道：最早的存储是单机MySQL，服务性能和容灾、可用性方面都很欠缺，2010年在农牧场业务爆发时期，数据库已经成为业务发展瓶颈，因此当时自研了TTC(内存cache+MySQL)的缓存服务器，将MySQL表数据缓存到内存中，提供高速，高并发的访问能力，支撑了腾讯第一代的社交游戏产品。

为了实现高效运维，提高服务可用性，2011年实现了以MySQL为基础的CDB关系型存储集群，这是目前腾讯社交网络最常用的关系数据库集群，存储如QQ秀的用户物品列表，黄钻用户数据等对事务依赖的服务。CDB提供对前端透明的主备切换，一键扩容，快速回档能力。

随着互联网高速发展，尤其是社交应用的爆发式增长，传统的关系数据库存在扩展能力薄弱，性能满足不了业务需求的问题，2011年腾讯又自研了CMEM这种纯内存高性能NoSQL存储集群，现在如空间的赞计数，每秒高达数百万的访问量，就使用这种存储。CMEM兼容memcached，但实现了数据持久化，主备容灾自动切换和快速弹性扩展能力，在春节红包等放量活动中，有着优异的表现。同期也自研了基于SSD的NoSQL存储集群TSSD，存放数据量庞大但是访问量不高的数据，如空间的说说存储。

2013年也可以说是腾讯的成本元年，腾讯开始投入精力做成本的优化，在内存存储成本不断膨胀，但又要保证访问质量的背景下，我们实现了CKV（CMEM+TSSD）这种二级NoSQL存储模型。分层存储更符合社交业务的特性，随着业务生命周期的演变，数据会有逐渐变冷的时候，如微云的文件索引存储，用户几天前的赞数据等。可以将热数据保留在CMEM的内存中，冷数据自动下沉到TSSD，且冷热数据随着用户自身的访问行为自动上升和下沉，释放了数千台的内存服务器。

百度外卖

采访对象：徐俊劲，百度外卖DBA技术负责人，当前在百度外卖研发中心，负责百度外卖mysql、redis等数据库的设计优化、数据库平台建设工作。

百度外卖目前线上主要使用Mysql、redis等数据库。MySQL 数据数百TB级，redis 数据几TB级。

徐俊劲：Mysql主要用在订单、支付、结算等业务场景。这些业务：1）对于数据库的稳定性要求高，需要数据持久化存储2）存储空间的需求也比较大，

数据量在几十TB、几百TB级别3）对于事务有强烈需求，需要保证事务的ACID特性 4）读写量大，需要数据库性能优良，可扩展性好，能集群化提供服务。对于上面这些需求，Mysql都可以很好的满足，因此选择Mysql作为存储。

Redis主要用在缓存、计数的业务场景。这些业务有的对于读取QPS非常高，可以达到每秒几万QPS，有的更新非常频繁，对于数据类型支持的要求比较丰富，因此选择redis作为存储。

魅族

采访对象：龙启东，魅族高级DBA, 主要负责MySQL,Redis,Mongodb相关服务的运营管理，包括架构选型，设计，性能优化，自动化平台建设。目前主要专注于魅族自建RDS平台建设和落地实施，负责方案选型，产品设计与规划，高可用平台，慢日志平台等。

目前魅族OLTP场景主要使用的是MySQL，缓存服务使用的是Redis。数据库实例近1000，数据大小100T+, redis实例1000+

龙启东：MySQL使用覆盖应用中心，游戏中心，用户中心，云服务等主要业务，之所以选择MySQL,主要是开源，无linsen 费用，而且扩展性好，如云服务，随着用户数的不断增加，数据量也不断的增加，最开始只有几台DB服务器，数据量的不断增加，即使采用商业数据库产品也无法很好的支撑数据的快快速增长，而MySQL扩展性好的优势就体现出来了，利用复制架构能快速的对单台服务器容量进行拆分，到目前为止仅云服务就已经从最开始的几组服务器增加到好几十组DB服务器。而且从最开始的不断拆分模式演变为只要增加机器即可满足数据量的快速增长。同时MySQL

slave复制能很好的扩展读性能，跨机房冗灾，比如三大中心业务需要灾各个机房进行读扩展，利用slave复制就能很好的满足要求，基于复制做跨机房的冗灾也是一个不错的选择。

新浪网

采访对象：赵景波，新浪数据库平台高级DBA。

主要负责新浪数据库平台Redis自动化运维、kafka运维等相关方面工作。热爱Redis、MySQL等开源DB内部原理的探究。

目前新浪网数据库平台共有9个主要IDC、1200+服务器、7k+实例、1000+亿 hits/天、总存储容量1PB+。

大部分的时候我们的选型是这样的：如果业务场景比较适合MySQL，我们就选择MySQL作为存储，毕竟MySQL是一个很成熟的产品，其插件式的引擎特性也能满足大多数场景要求，同时其社区相当的活跃，人才储备也是最丰富的。那什么条件下会考虑除MySQL外其他数据库呢?比如业务对响应时间要求极高，或者业务场景就是简单的kv存储模型，亦或业务希望schemaless类型的数据库便于业务快速开发迭代等等，此时我们就会考虑一些其他的数据库，这也就是目前我们平台不仅仅只是提供MySQL服务，同时也提供MongoDB、Redis、Memcached、Hbase等服务的原因。

拿我们的内部服务发布系统来说，早年发布的新闻都是用MySQL存储，随着业务发展，个性化的需求与日俱增，业务表结构变更(添加字段)的需求也越来越多，而此时MySQL这种固定schema的存储模型不能满足业务快速开发迭代的需求，因此最近我们把发布系统的新闻数据从MySQL全部迁移到了MongoDB这种schemaless数据库上，给开发带来的收益还是很明显的，而我们运维方便其实也没增加太多成本，因为新版本的MongoDB还是相对很稳定的，运维还是相对比较省心。同时新闻推荐push等业务对部分接口的响应时间要求很高，那此时显而易见的我们会

推荐业务采用Redis或者Memcached这种内存KV缓存来解决业务的需求。

新浪微博

采访对象：肖鹏，微博研发中心微博数据库平台技术副总监。

主要负责微博数据库相关的管理和服务支撑工作。工作范围包括MySQL、Redis、Mmemcached、MCQ、HBase、Hadoop等软件的可用性保障、架构设计、性能优化以及自动化运维支撑平台的研发。

由于我们较为重视缓存层的建设，故在缓存层我们有比较多的选择，包括Memcached、Redis、pika以及我们内部定制的RedisCounter，这些软件基本满足如下的场景

- Memcached ，常规类缓存选择

- Redis， 负载数据结构选择

- Pika，海量缓存数据选择

- RedisCounter，计数类场景选择

而数据存储层就比较常规了，由于MySQL一贯的稳定性和表现，我们大部分持久化存储都选择了MySQL，在MySQL上我们默认选择innodb引擎，而对于大存储需求的我们会选择TokuDB引擎。

另外，我们还会对于部分适合的业务选择HBase进行持久化存储，由于分布式便利的扩容方式，对于超大存储需求的成本可以得到有效的控制。目前除了存储离线数据外，我们也在尝试让HBase存储在线数据，并提供在线服务支持。

京东

采访对象：朱健，京东大数据处理高级工程师。

2015年加入京东广告部，参与广告部反作弊系统、广告日志系统、实时统计和BI相关的工作。京东之前，在雅虎北京全球研发中心，负责广告流量反作弊相关的工作。

我们在广告实时效果系统中使用到了Redis、HBase和MySQL。面对广告数以十万计的曝光流量，需要一个高吞吐量、低延迟的数据库才能满足实时统计广告指标的需求，Redis和Redis在这方面都非常出色的，但是Redis不支持累加，所以对于变动的数据存放在Redis中，然后历史数据转储到Redis中。但是k-v系统有维度爆炸的问题，所以对于数据量不太大但是维度组合变化多的实时指标统计，我们有部分业务线使用MySQL。

MySQL在离线OLAP系统中使用过HIVE和Greenplum。HIVE其实不算数据库，是MapReduce+HDFS的抽象，非常稳定，可以处理超大规模数据，用来构建我们的日报系统，但是缺点是太慢。后来为了做到低延时的OLAP，满足广告指标实时查询的目的，MySQL引入了Greenplum。目前来看，Greenplum比较适合中等规模的大数据(百T级)。

58到家

采访对象：沈剑，58到家架构师。

在百度做过几年即时通讯后端，2011年加入58同城，任高级架构师，技术委员会主席，2015年调到58到家，现在负责企业，支付，营销、客户关系等多个后端业务部门。

和绝大部分互联网公司的存储选型类似，58到家目前的固化存储使用的是MySQL，几个很重要的原因：

一个是技术成熟，开源设计活跃，在业内使用广泛，并在在生产环境经过很大数据量、并发量、扩展性的验证;

二个是研发、测试、运维人员相对更好招聘;最主要的，它能够解决业务的各类需求。

美团外卖

采访对象：王兴星，美团外卖商业技术负责人。

前搜狗PC&无线算法负责人。2016年初加入美团外卖，从0到1搭建商业变现技术体系。

美团外卖从2013开始，目前已经单日突破1000万单，是最主要的O2O应用。

使用内部定制优化的数据库Cellar，广告业务对可用要求较高，同时针对不同规模数据，存储的方案也有所差异，针对量较小平响要求较低的使用全内存方案，针对数据量较大平响要求不太高可以采用内存+SSD的方案，同时为了整体可用性考虑，还需要一套房机房的方案。

本来生活网

采访对象：范学蠡，本来生活网BI总监。

曾在Daum负责研发，后进入贝塔斯曼负责多个数据项目。

本来生活网主要使用了MySQL、MongoDB 、SQL Server、HBASE、Hive。核心业务依然是SQL Server集群。大量写入比如用户行为采用Hbase。MySQL主要用户BI系统的集市层。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31448824/viewspace-2139536/，如需转载，请注明出处，否则将追究法律责任。