总结1.从职业发展角度选型2.选型原则1,2,3.3.选型路线图本次分享主要有三大方向。就是从职业规划的角度来看为什么我觉得数据库选型很重要。第二个方向会根据这些经验讲一下数据库选型的基本原则。最后总结一下这些年来数据库选型的路线图。对大家以后做数据库选型有帮助，大家可以根据自己公司的场景来使用。当然，这可能并不适合所有场景。主要是提供思路供大家参考。1、从职业发展的角度来看，DBA这个行业已经选了很多年，职业规划也随着时间的推移发生了变化。我放一张DB-Engine的图，就是DB的排名，别说前三了，老三都没什么好说的。但是看下面的排名，除了常见的数据库，还有ES、HBase、Neo4j，这些我们没有想到是属于DBA管理范围的DB。我经常告诉我的团队成员，我们的DBA思维不应该局限于前三或TOP5。是不是可以考虑更多的数据库也是DBA可以从事的行业，比如HBase可以做吗？你能管理ES吗？这些东西都反映在这张表上。我们可以拓展自己的职业领域，这也是职业发展的横向扩展。这张图是去年和今年的变化对比。去年，关系型数据库（蓝色部分）占据了半壁江山。今年，关系型数据库仍然是第一，但是很多份额已经被多用途数据库占据了。多用途数据库是厂商选择的趋势，他们开发了越来越多的支持多用途的数据库。为什么制造商会这样做？供给侧的变化来自于需求侧，因为有很多需求不是单一数据库可以解决的。在这种场景下，厂商迫于这种需求，开发了很多可以适应更多场景的数据库。这种趋势对DBA意味着什么？它提醒我们，掌握多种数据库是这个时代对DBA的要求。这是一个必然的发展趋势，因为你要解决的场景会越来越多，你需要掌握的数据库领域也会越来越广，这意味着之前的“一招一式”的玩法已经落伍了。让我们看看当前的工作设置。过去其实是纯自建时代，现在是云时代。这两个时代有着本质的区别。自建时代的DBA，更多的是区别于运维领域的更专业、更高门槛的专业领域。以前没有DBA，全由Ops管理。后来出现了DBA，然后慢慢演变为DBA做一些细分。开发DBA、内核DBA出现，有同学转专攻大数据。这是自建时代的全州。但云时代会有怎样的变化呢？事实上，自建时代的传统DBA依然存在，因为混合云的存在。那么变化是什么？无论如何都不可能完全忽视云。一旦上云，对自身运维系统的影响是其次，最主要的是业务可以选择更多的服务。以往业务因基础设施需要适配数据库，现在会要求DBA掌握更多的数据库类型来满足业务。更有什者，一些企业已经上云，之前依赖的工作都变成了云服务。这个时候DBA应该做哪些改变呢？最后一个变化是云端的DBA。作为云公司的DBA，孵化一个产品和提供内部服务是完全不同的事情。未来我基本认为DBA会在这三个领域（混合云DBA、on-cloudDBA和in-cloudDBA），但是不管哪一个需要掌握更多的数据库，这个都不会变。总结一下，这个时代对DBA的要求就是需要掌握的数据库领域越来越多。无论在哪个线上，都需要了解很多领域，至少要精通一个，掌握N种。这次演讲想给大家传递一个理念。二、选材原则1、2、3原则1：不谈场景的选材是耍流氓。做过数据库选型工作的都知道场景很重要，但并不是每个人都能深刻理解这个概念。比如这一幕，相信大家应该都有过实际体验。你的用户对数据库的理解不像DBA那么熟悉，他的出发点和你不一样。你要的是长期稳定，他要的是把功能做好。如果要做业务选型，就一定要分场景，比如日志类、搜索类、线下需求等，这些都要和线上分开。商业模式是什么样的？活跃的还是规律的，你读的多还是写的多？那么数据增长方式是什么？不能仅仅满足上网瞬间的需求。业务增长是基于日期还是基于用户？基于位置？这些需要与您和企业明确讨论。如果不问清楚，后期会面临最严重的问题：数据迁移。而数据迁移本身就可以成为一个话题，也就是说这件事情要花很多钱。能从前期避免，就尽量从前期避免。原则二：没有数据，就无从谈起。无法衡量的东西无法管理。就像在数据领域一样，没有数据就无从谈起。这是一个场景。当你在寻找商务聊天时，你问了三个问题，你不知道该怎么做。你经常遇到，业务真的没办法。但是我想说的是，我们必须让业务方拿一份数据，因为我们所有的决策都是基于这些数据，没有数据，我们就无法做出决策。另外，也希望整个业务链上的同学们，能够养成拥有数据的习惯。测评多了，自然会积累一些解决“出手次数”问题的方法论。重点也是最终选型图上的重点，一是size，二是qps，三是rt。此外，我们还需要提供一些基准数据。什么是基准数据？就像刚才那一幕，当你问起生意的时候，他什么都不知道。还有一种情况是，业务问你MySQL能坚持多久，你说我不知道??。如果你管理一个类型的数据库，你必须对你自己的东西有一个非常基本的了解。这种场景来的时候，是做一主二从还是分布式？分区表等等，这些都要清空。最后有个提示，评价可以对比，只要逻辑合理。当需求来临时，您无法准确判断它有多少。就看这个部门以前有没有做过类似的活动，什么时候做过的，和你的是什么逻辑，是不是类似的逻辑，如果是近似逻辑，我们就套用。比如上次热点事件的峰值是多少，如果这个产品功能也可能关联到某个热点页面，那么根据上次热点事件的峰值做相应的预估也是顺理成章的。在这里，我将向您展示基准测试。这是我们在做混合云运维方案的时候做的测试，因为要用到多个厂商的数据，需要清门。我会把这个服务部署到那个云上，性能会有什么样的波动，也方便业务方对业务有一个更直观的了解和认知。原则三：不考虑可操作性的应该拍。最后一条原则与前两条原则截然不同。前两条原则基本都知道，但是实现起来比较困难。第三条原则其实很多DBA都不太重视，但它确实是一个很重要的原则，就是可操作性。我开始说，DBA和业务方的评价不一样，你的KPI不一样，要求也不一样。业务需要在线，你需要可操作性。这关系到你的幸福和你的生活。夜价。图中的例子非常经典。业务和DBA根本不在同一个频道交流，最后只能不欢而散。我认为什么是可操作性？有四个方面：一是社区活跃度，决定了你获取信息的难易程度。什么决定了获取信息的难度？关系到故障定位的快慢，甚至关系到能否定位。如果社区活跃，你自然会得到更多的帮助。二是是否有USERCASE。最好是你认识的人，因为眼见为实，耳闻为实。你认识的人往往可以告诉你一些真实的“陷阱”而不是“功能”来做宣传。三是自己团队的情况和上手成本。你的团队有多大，团队有什么样的技术储备？毕竟你是在开辟新的战场，每一种数据库都不是那么简单的。可能三四个人做，但是在实际业务中用到多少呢？不知道，很麻烦。最后一个是一个很隐蔽的东西，所谓的市场人才情况，这是一个可持续的成本。如果选择了数据库，但是如果市场上人才少，一旦人员流失，这个数据库就会无人维护，这对公司来说是绝对不允许的。3、选型路线图最后说一下选型路线图。如果您没有专门的DBA团队，云是最好的选择，仅此而已。至于这几家公司哪个好，我觉得还是根据投资关系来选择比较合适。至于原因，你懂的。先说一下这个技术选型路线图。这是根据这么多年的团队经验得出的选型路线图：首先要做场景分析，不管是线上业务、线下业务还是统计业务都要分开。如果是离线的话，那就用Hadoop生态。如果是统计监控，可以使用专门的时序数据库或者ES等，即使不用，也要和线上严格区分。那么在线上，特殊需求使用特殊数据库比较合适。如果是纯线上的TOC端产品需求，我们需要做QPS判断。如果是中低QS，那就往下看，根据大小判断可扩展性。如果有很高的扩展需求，选择目前比较流行的分布式数据库是一个不错的选择。如果不高，再往下看SQL复杂度。一般来说简单的互联网应用MySQL就够了。如果使用了很多存储过程或者复杂的查询，那么PG比较合适。回到刚才的fork，如果QPS高，那kv数据库基本就是天下了。我们需要根据大小来判断。如果是可控的，那么纯内存kv数据库是最好的选择。接下来是基于RT的判断。如果规模大，RT要求高，那么就只选择分布式内存kv数据库（RedisCluster）。如果对RT的要求不是那么高，那么Pika/Aerospike是比较省钱的选择。最后，让我们谈谈我们目前的最佳实践。我们目前使用MySQL+Cache方案解决常规需求，特殊需求交给云RDS（如PG、MongoDB等），选择HTAP分布式数据库。解决可扩展性问题。问答：现在比较流行所谓的云原生DB，但是我们还没有用到。有宣传说云原生DB是可扩展的，类似于传统数据库。请问传统数据库它的缺点在哪里？A：缺点是它的要求提高了。分布式数据库数据库的门槛变高了。对于业务来说，现在在功能和扩展性上已经全面超越了传统数据库。但是对于DBA的要求，有一个非常高的门槛，会对我们之前的问题分析、调优、故障定位思路产生很大的影响。讲师介绍了原新浪微博研发中心副技术总监肖鹏，主要负责微博数据库（MySQL、Reids、HBase、Memcached）相关的业务保障、性能优化、架构设计、周边自动化系统建设。经历了微博数据库架构改造的各个阶段，包括服务保障和SLA体系建设、微博多机房部署、微博平台改造等项目。10年互联网数据库架构及管理经验，专注于数据库高性能高可用技术支持方向。
