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

　　就数据库实际应用水平而言，互联网公司显然走在了前列，它们都在使用哪些数据库?分别对应哪些业务场景，为什么会是这样选择?了解的人却并不多。为此，老鱼在DTCC 2017中国数据库技术大会召开前夕，走访了多家知名互联网公司并采访了其技术负责人或DBA，为大家一一揭秘。

　　(注：部分受访者所属部门局限，因此，以下所列企业业务线对应数据库并不全面，仅列出主要应用数据库，供参考。)

　　本篇为《知名互联网公司都在使用哪些数据库?》系列第二篇，本期内容将为你揭秘新浪网，新浪微博、58到家、京东、美团外卖、本来生活网的数据库应用情况及选型理由。

　　如果你想了解蚂蚁金服，去哪儿，百度外卖，魅族，腾讯在使用哪些数据库，请阅读第一篇！（点击传送门)

　　新浪网

　　采访对象：

　　赵景波，新浪数据库平台高级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系统的集市层。