日前，全球分布式关系型数据库厂商PingCAP宣布完成1500万美元的B轮融资，本轮融资由华创资本领投，经纬中国、云启资本、峰瑞资本、险峰长青等多家投资机构跟投。本轮融资将帮助 PingCAP 加速技术产品的研发和商业化的推进，并为公司的全球化战略提供充足保障。

PingCAP 成立于 2015 年，总部设在北京，致力于前沿基础设施领域的技术创新实现。核心技术团队囊括业内全球众多顶级程序员，Codis、SenseiDB 等知名开源软件的作者均在其中。其核心产品 TiDB 致力于解决数据库领域一直以来存在的关系型数据库水平扩展的世界级难题，是全球范围内该领域目前极有核心技术竞争力的产品。

第54期拓扑秀“FreesData”邀请到了PingCAP联合创始人崔秋——重度开源爱好者，曾任职于搜狗、豌豆荚，长期从事广告系统基础组件相关的研究，现主要从事开源 NewSQL 数据库 TiDB/TiKV 相关的设计和研发工作。

以下是分享内容，大约7000字，enjoy~

很高兴跟大家做分享和交流，今天的主题是云数据库 TiDB 的大数据场景应用。我先简单介绍下我自己，我是PingCAP的联合创始人崔秋，之前在搜狗，豌豆荚一直做广告系统 infra 相关的设计和研发工作。

15 年初，我们看到了当前数据库方面遇到的各种问题，同时也看到了学术界和工业界最前沿的一些发展方向，所以和刘奇（PingCAP联合创始人、CEO）、黄东旭（PingCAP联合创始人、CTO）一拍即合，一起创立了 PingCAP，致力于打造一款改变未来的开源数据库。很多人都听过我们做的事情，我们做的分布式数据库叫 TiDB，之前一直有人“八卦”为什么叫 TiDB，这里也稍微解释下，Ti（钛）是一种贵重的航空金属，通过名字就大概可以理解我们的愿景——要把 TiDB 打造成最安全最可靠的数据库。当然 TiDB 提供的价值不止于此，我会进一步展开分享。

我要介绍的内容主要包括四个部分：第一部分主要和大家聊一聊整个数据库的发展历史；第二部分介绍一下TiDB 和现在已有的 NoSQL 和 MySQL Proxy 方案的异同和它特点；第三部分讲一下大概什么场景和具体怎样去使用 TiDB ；第四部分，分享一下TiDB的发展计划。

这是关于数据库发展历史介绍的设计图：

一般会把数据库分成三个阶段：最早的起源于 20 世纪 70 年代的单机型数据库；2010 年到2015 年这个阶段出现的 NoSQL 、MySQL Proxy 和中间件相关的一些数据库；以及从 2015 年开始的 NewSQL 数据库。

我们先从单机型数据库开始，它起源于 20 世纪 70 年代，当时的数据量也没有现在这么大，基本上一台服务器就能把数据很好地存储下来，也基本不涉及到分布式的问题；当时的业务场景也没有现在这么复杂。所以当时数据库的主要作用有两点，第一是把数据很好地存储下来，第二是从存储的数据里面比较高效快速地读取所需要的信息。比较有代表性的关系型数据库有商业的 Oracle 、DB2 ，开源的 MySQL 和 PostgreSQL 还有一个微软的 SQL Server 。在很长一段时间里，因为数据量和业务模型没有现在这么复杂，所以单机数据库一直可以很好地工作。

进入到 21 世纪的时候，情况有了很大的变化。随着移动互联网、智能硬件以及云技术相关技术的成熟，数据规模呈现了爆发式增长，单机数据库已经不能存储下全部的数据。所以学术界和工业界开始探索如何解决海量数据的存储问题。主要有几种不同的解决思路，我们分别介绍下：

首先，我们来看看 NoSQL 它解决了什么问题，也同样的引来了什么问题。

说到 NoSQL，就要提到 Google BigTable 和 Amazon Dynamo 为代表的新一代数据库。在开源领域一般大家讨论比较多的主要有三种，主要以 HBase，Cassandra 和 MongoDB 作为典型代表。我们不去讨论具体的不同数据库的优劣，主要看一下 NoSQL 这个群体带来的一些解决方案上的变化。

NoSQL 所处的技术环境下，技术人员发现很难在保证传统 ACID 事务和 SQL 支持的基础上解决数据库的扩展性问题。当时首要的问题还是先解决数据的分布式存储问题，把数据存下来，至于其他问题，等以后再慢慢解决，或者通过应用层配合来解决。另外对于有些业务场景，比如下载排行榜这类比较简单的业务，确实 NoSQL 已经可以很好地解决问题了，所以当时大家认为好像发现了一条特别清晰的、值得探索的道路，是不是真的如此呢？实践证明并不是。本身因为缺少事务以及相关的 SQL 支持，所以在涉及订单、支付等核心交易场景下，NoSQL 是没有办法提供很好的解决方案的，特别是限制了在严肃业务场景下的使用。相应的，如果应用层需要事务或者需要一个关联查询，这些工作全部转嫁给了应用开发人员，由应用的开发人员来保证逻辑的正确性，这样做反而增加了出错的可能性。而好处是 NoSQL 确实解决了Scale 扩展性的问题。