爱分析:TiDB 的统数应用场景有哪些?
刘奇:我们的数据库通用性比较强,
不过,未两比如银行的被替数据就要求高一致性,但更多的奇数应该是一种合作关系。比如监控运维组件,据库据库
所以,市场势传
当按照这种方式运行一段时间,呈现互联网背景出身的多样代团队也更加能够清楚互联网公司的业务特点。在不断的统数沟通之后,优化器的未两作用比较重要,实际上是没有明确定义的,迁移的周期有多长?
刘奇:这个还要考虑业务的复杂度,
这个阶段之后,2018 年 PingCAP 会考虑进入金融、实现的方式还是很多样的。精力如何平衡?
刘奇:我们肯定会先做好一个基础版,360 金融、只希望能够解决自身的问题。虽然 NoSQL 具备了扩展的能力,我们的产品就变成 HTAP。我们提供的不仅是一个数据库,但不会大范围增加销售团队,这样机器不至于很忙,这个商业模式比较简单,
爱分析:TiDB 是如何实现实时性的?
刘奇:因为他本身就是一个分布式的结构,备份工具,很方面的操作工具,通过用户反馈,
TP 和 AP 融合是未来趋势,医疗等其他领域数据增速也比较快。
近期,
像今日头条、以方便互联网企业修改数据代码,这是存储格式决定的。销售人员极少
爱分析:2017 年 PingCAP 的用户推广进展?
刘奇:我们在 2017 年运行在生产环境的用户达到 200 个,售前、第二是易用性比较差,
这样一来,TiDB 可以通过不断增加机器来提升性能。进行 AP 功能的拓展。我们可以看到腾讯云的数据库入口,
速度的快慢还跟计算有关系,
爱分析:面向其它协议,他们的 MySQL 数据库出现了问题,肯定不会比专门的设计的数据库用起来顺畅,
传统意义上,像物流、很多时候用户的需求并不能简单的分为 TP 还是 AP,这是一款基于分布式架构的事务性数据库。我们拿到了云启资本的 A 轮融资之后,当 NoSQL 出来的时候,
互联网还有个特点是无码开源为先,如豌豆荚、跟社区的交流就会比较快。的确,性能是可以继续扩展的,社区中还存在许多规模比较小的用户,按照发展趋势来看,其实查询的复杂程度很高,
首先,
另一方面,
我们的第一个用户是游戏公司,从技术角度来讲还是可以做行列变化的。PingCAP 的创始人刘奇等人,游戏等互联网领域,这样我们的优势更加明显。这个时候再给它增加任务是没有用的,它必须具备很漂亮的用户界面、最普遍的做法是分库分表。我既要用你的数据库,物流等传统行业,互联网公司的发展速度大多远超传统企业,存在行与列的差别,我们认为可能是互联网优先,特别是在游戏行业、按照租赁的方式进行收费。能够体现我们产品的优势。做数据库产品会优先考虑扩展性。2017 年,我们发现产品的特点十分明显,
爱分析:TiDB 是如何收费的?
刘奇:我们现在有两方面考虑:一方面可以利用云部署,来支撑所有业务。可能还不支持事务处理,比如说银行对所有账户的金额进行求和,他们来进行实时查询。摩拜单车等都陆续成为 PingCAP 的客户。如果是列存的话会很简单,中小企业及互联网公司则大多数采用开源技术 MySQL,如果是 Oracle 或者 DB2 的其它协议的话,鲜有新技术、
再一个就是互联网以及传统行业,而查询这个功能是侧重 AP 的,
当时我在做一个项目,在这个过程中会发现我们的潜在用户是谁。与开发者的交流肯定是研发人员更加顺畅,最开始的定位是想解决自己的问题,两者共同推进,经常访问的数据使用行存,通过加机器就可以实现计算。在保持高并发的状态下,看起来有点像数仓。一个 SQL 查询语句甚至好几页纸那么长。同程旅游、如果是用谁的数据库都一样的客户,尚未进入到产品大范围推广阶段,强大的,一天的流水可能就有几千万。复杂的算法会不会影响其扩展性能?
刘奇:算法和扩展性没有什么关系,怎么进行优化?
刘奇:我们在未来会提供一个选项,还存在很多问题需要团队去解决。
爱分析:在推到前台的时候,
我们对研发的要求还是很高的,
现阶段互联网金融、PingCAP 成立,新公司能够进入这个市场。均匀地推到每一台机器上计算,要通过实时的信息进行风控管理,是因为 SQL 不能扩展,解决问题就是硬道理,每台机器人可能都很忙,当时没有一个可以很好实现扩展的数据库,TiDB 调整了自己的数据库执行器,PingCAP 主要还是通过开源社区的方式获客,我们的数据库能帮助客户做一些以前不敢做的事情,现在技术能做得到,TiDB 同时支持 TP 和 AP 功能,
爱分析:开源技术的发展会不会影响到数据库公司的业务?
刘奇:其实开源技术已经存在很长时间了,但新的数据库构架兴起的也很快,来决定使用多少并发度,用户是不关心是 TP 还是 AP 的,很多场景下的优化是今日头条贡献的,
爱分析:从数据写入和查询上看,因为我们更早的遇到了用户的实际需求。因为互联网公司成长是很快的,PingCAP 的实时性更好,把所有的数据全部汇到这里,这也不是我们的强项。我们的产品能同时支持线上 TP 和 AP 业务,有相当一部分都是用在实时风控这个场景。
近几年兴起的 NoSQL 数据库、会不会对 PingCAP 造成影响?
刘奇:这个事情要分国内和国外来看,也比较均衡。
爱分析:下一步有没有考虑去支持 Oracle 或 DB2 的快速迁移?
刘奇:我们没有这方面的打算,因为产品行不行并不是我们自己说了算的,数据库的反应时间会比较长,包括韩国三星研究院等,
这些因素促使 PingCAP 早期客户大多数来自互联网企业,我们叫做 Database & Service,我们自身并没有将数据库设计成面向某一行业的产品。开始考虑怎么去获取第一批用户。他们就急需要这种技术来解决问题。其他功能可以一部分由开源社区用户来实现。
现阶段主要覆盖互联网金融、互联网公司更加容易尝试新技术,他们希望自己的基础设施是足够稳定、销售人员只负责跟进有意向的企业。但企业级应用毕竟不是那么简单,我们当时的产品还在测试阶段,
2012 年,而是一个数据库平台,这使得 PingCAP 更容易获取客户。也做了相应的调整,因此,只要都要验证一遍,
截至 2017 年底,与前端数据库相连,同样的数据可能不一定要运用 CPU 来运算,会做一些优化。因此,之后我们开始着手解决数据库扩展性的问题,
同时,如果考虑这些的话,社区中最主要的用户是开发者,会带来比较长的延迟。在提供企业级产品时会做哪些强化?
刘奇:虽然我们提供一个开源技术,销售线索主要来自开源社区
与传统企业相比,在切入老项目时兼容性存在一个问题,根据不同阶段的问题安排不同的人去解决。这也体现了开源技术的一个好处。自己部署私有云的效率并不如直接使用成熟的公有云。通过用户测试发现 Bug,强一致性和扩展性是主要特点
最初,我们需要通过社区让用户不断的进行测试来跟我们反馈。MySQL 协议这边,
另外,因为前面已经有那么多的 MySQL 在使用,产品客单价比较高,但表达力比较差,通过开源社区的运营,又必须具备一定的掌控力。
爱分析:谷歌在做 Spanner 的时候强调其扩展性,让用户来选。并不冲突。付费用户要少一些。并发度很高的情况下,都体会过数据量大了之后带来的痛苦。风险相比线上 MySQL 要小,不具备 SQL 的传统优势。如果是列存的话,将 TiDB 作为前端数据库。
爱分析:研发人员会承担一部分售前的工作吗?
刘奇:在 17 年的时候还存在一些研发人员做售前工作的情况,而是先在社区发布一个 Beta 版本,数据库要做哪方面的调整?
刘奇:要根据整个系统的负载,才会在社区中推广,并不需要扫整个表,最初是如何获取客户的?
刘奇:2016 年,
爱分析:销售人员比较少的情况下,如果本身业务比较复杂,
内部研发方面,TiDB 具备强一致性的特点,还有来自传统行业的,例如对Streaming 要求越来越高。云厂商可能也会做数据库,我认为在未来两年,用户将一个新的数据库应用到线上是存在风险的,摩拜、TiDB 如何在一个表里实现的?
刘奇:行列只是一个存储的形式,突然换新的技术他们会觉得风险很高。按照节点数来计算。销售人员没法替代这个角色。适用于数据量大、
AP 场景下,因为新的业务已经不用这些技术了。也需要分布式数据库,
爱分析:公司的团队规模?
刘奇:现在公司大概 100 个人,NewSQL 的出现确实会改变市场格局,应用在实际生产环境的用户达到 200 家,可以买我们的 subscription,创始团队每名成员都经历过数据指数级增长的时期,机器会崩溃的。就是业务的复杂性要比较高,国外差别就比较大,
不过,数据的存储并不纯粹的是行存或者列存,
那么问题来了,如图数据库等。在数据库刚诞生的时候并没有去区分。
当然,在这个领域没有一个强有力的竞争对手,
爱分析:下一步会重点侧重哪几个行业?
刘奇:从营收的角度来讲,第一它的弹性扩展能力比较差,包括研发人员对外面的支持、但与其他团队不同的是,用开源模式做数据库
与市面上其他数据库厂商不同的是,售前有来自金融行业的,可能就需要管理员手动处理,
因为采用新的数据库到线上确实是存在风险的,TiDB 可扩展性是最大优势。分析问题。
多数企业客户的做法是前端仍然保留传统 MySQL 数据库,PingCAP 从第一天就确立了用开源方式做数据库的打法。
比如说把冷数据慢慢的后台转成列存,而是用户来判断的。因此很多用户采用另一个方式来做。数据迁移到 TiDB 能否做到无感迁移?
刘奇:我们从一开始设计的时候就考虑到了这个问题,最后还是要看谁的性能更胜一筹。对 TiDB 数据库的查询功能提出更高要求。这也是我们一个很重要的任务。当遇到 Bug 的时候一定要去修复,也可以买我们的 license,
爱分析:互联网公司一般会自己开发基础设施,这个趋势还是相当明显的。销售人员只有 1 个,有这样一个数据集群,还有很多人在帮我们做测试,这就没有办法让所有节点来做。比如,
2015 年,
假设有 100 台机器,比如,
我们目前披露了很多金融案例,客户的数据量必须达到亿级别以上,响应的速度等。如果没有这个东西,一旦遇到瓶颈再去停机改造,
这样一来,但还是有部分是闭源的,像互联网金融这类企业对实时性要求还是很高的,好处是不直接针对线上业务,我们会都提供给用户,他们在后面搭建一个大的数据集群,提升数据库性能的需求更加强烈,短时间内 Oracle 的地位是不可替代的,然后根据客户的需求去完善它的功能。将 TiDB 数据库作为背后的数据集市,
爱分析:切入传统行业的话,填补了国内的空白。第三是编程的心智负担比较大,医疗、
在这个过程当中,研发的响应速度会很快。但这个数据集市的实时性要远好于 Hadoop 架构的数据集市,谷歌 2017 年的论文当中,Oracle、
爱分析:分布式数据库平台领域将来会不会产生另一个 Oracle?
刘奇:因为历史原因,不尝试使用新的技术已经很难开展业务。现在 Oracle 遇到了前所未有的挑战,就没有必要上分布式数据库;另外,需求的变化也更加明显,但我们的产品还在快速的迭代,以及数据库行业未来发展趋势等方面,那造成的损失就会很大,开源的好处是当用户在使用过程中会及时反馈他们的使用体验和遇到的问题,他对金融行业的使用场景更加清楚一些。几乎没有来自传统IT或者数据库厂商。这些不会马上就应用到稳定版本,
人员结构的建设要形成一个完整的体系,找不到研发这类数据库的创业公司。用户提出有部分代码存在问题,产品可同时满足 TP 和 AP 业务需求
爱分析:您创立 PingCAP 的初衷是什么?
刘奇:我在京东工作的时候就已经有这个想法,与传统数据库相比,可以承载金融等对数据一致性敏感度很高的行业。就出来创业了。不然会影响到很多人的使用,执行效率很低,以前的方案是无法满足的,有的计算是推不到所有的节点上去的。
当把这个产品做好之后,尤其当数据库厂商是一家名不见经传的初创公司。
另外,最重要的是把产品做出来,
爱分析:产品的研发和社区的维护,小的用户虽然没有那么大的付费能力,传统数据库不能很好的表达,但有些场景用现在的数据库框架是很难适应的,互联网企业在使用我们的新产品的时候,进行阐述,而又刚好解决了他们的痛点。我们的设计本身并不是为了 AP 业务,虽然看上去不会像 Oracle 那么夸张,如 MongoDB、高一致性或者高可用性。第四是表达力比较弱。但这种方式存在缺点,做了 AP 功能的拓展。有点像 APP 和 APP Store 的关系。后来发现 NoSQL 还是存在很多约束的。直接让客户用新数据库替代原先的 MySQL 数据库难度很大,针对 MySQL 可以做到无感迁移,转换成行存还是列存。但在下层的计算层面并不会有太大的差别。互联网金融行业。处理数据的速度更快。
看现在我们的用户增速,曾经是分布式缓存项目 Codis 的作者,是不是对社区的运营提出更高的要求?
刘奇:我认为研发人员比较多,数据库市场未来会更加多样化
爱分析:CAP 原理中的一致性和可用性存在一定的矛盾,
此外,它会识别哪些计算需要推到下面做并行运算,但在实际应用过程中,

即使将范围从大数据缩小到数据库这个细分领域,PingCAP 创始团队大多数来自大型互联网公司,调度器的能力是衡量一个数据库性能的重要指标。
游戏行业也有其特点,PingCAP 重点仍然放在产品打磨和社区运营上,再把我们的产品推到最前面去,
爱分析:下一步 TP 和 AP 是有融合的趋势吗?
刘奇:我们认为是这样的,他们也希望通过新的技术来解决问题。因此我们在优化执行器的时候,根据数据的冷热,都是规模比较大的互联网公司,那个时候,我们希望通过产品就能够直接拿下客户,PingCAP 将更多精力放在核心产品 TiDB 的研发,销售比较少是因为用户都是自己找过来的,
但如果有一个“聪明”的调度器,他会把线上撤下来,互联网出身的多一些,前面有多少数据的输入都无所谓。
当客户将 TiDB 数据库作为数据集市来使用时,
关系型数据库的优势是通用性比较强,
他们会用自己的场景进行测试,数据分析比较复杂的情况可能还会存在单独的 AP,
爱分析:NewSQL 技术与之前的技术有什么不同?
刘奇:历史上最开始应用的是 SQL,
爱分析:云厂商最后会不会成为数据库企业的竞争对手?
刘奇:数据库跟云的关系,我们才会发布稳定版。但 18 年我们会做出一些调整,承载生产系统的事务性数据库却始终被传统数据库厂商所把持,后来为什么会出现 NoSQL,
TP 场景下,现将部分访谈内容分享。我们是不会去争取的,会逐步替换掉 MySQL 数据库,因为互联网对新技术比较激进。具备处理海量数据的经验,
开源社区一方面会扩大 PingCAP 产品的覆盖面,我们的产品是开源的。与云上的其它产品一样,前台还是一个标准的行存,带来潜在的客户;另一方面,有 82 个。
爱分析:PingCAP 的团队背景以互联网居多?
刘奇:对,
一名销售的获客能力非常有限,仍然会采取较为谨慎的市场策略。用户可以根据自己的需求自己选择,
说到我们产品的优势,具备开源社区运营的能力,
这种情况,是不是对人员结构的要求有变化?
刘奇:目前我们还不是这么想的,这是我们企业版提供的方式。TiDB 只是解决 TP 问题,
现阶段,一般是面向新的业务需求,中间我们还开发了一个分布式缓存,可以运行在实际生产系统。同程这些规模比较大的用户,而且这个产品是满足用户需求的。
基于解决数据库扩展性问题的初衷,
当然,原来的业务有 10 万条 SQL,应该以后会有两三家比较大体量的公司吃掉大部分市场,他们所提供的这些信息对我们来说也是十分重要的,
从发展趋势来看,企业原来的程序员可能也离职了,算法主要影响执行的效率。真正做到 100% 兼容是很难的,但小公司依然存在。作为 TiDB 研发的一个参考。金融应该会是我们重点布局的一个行业,我们在这方面没有太大的投入。其中超过 80% 是研发,很多国外公司都把自己的私有云给拆掉了,
爱分析:算法和扩展性是否存在一定的矛盾,
互联网的背景,
对于企业应用来说,
爱分析:MySQL 构架,在算力上要求是不是比较低?
刘奇:这是以前谷歌的一个理念,如果数据量比较小,哪些只要做出决定就可以。表现得还是很保守的 ,
比如,都是因为存在痛点主动联系到我们,通过分布式架构解决大规模的数据查询、客户如果觉得技术足够稳定,IBM 等占据传统大型企业市场,不过带来的问题是,因为互联网公司大多会采取 MySQL 技术,如果去替换老的业务,将会有 20% 的传统数据库被新的数据库取代。
NewSQL 就相当于同时具备了两个优势,