这次正好在假期期间被邀请参加 OB的发布会以及 DBA老友会。

1． 朋友相见。若干个读者和群友和我本人见到了比如天舟兄。也结识了一些平时就听过的知名人物比如同为 ACE的戴明明，这次面对面的深入交流。在 OB的发布会上，还看到了我曾经的学员已经升职到所在单位技术部门的副总了。

这也是个人与数据库相互成就。更多的是遇到了平时就熟悉的朋友以及新结识的朋友们。退役和现役的4个ACE。

    OB 现在给我的感觉是积极的向同行学习一些理念和做事风格。尽管我也学习过早期的 OB课程，但是我并没有去投产使用。不过举办方依然邀请我听了他们的即将做的技术路线图，这一点很像 Oracle的 CAB大会。杨传辉（日照）就不停的在记录着每个人的发言，貌似记录了 2页多。而竹翁表达了 OB在兼容 MySQL和 Oracle的过程中也在不断的学习这些数据库。在他看来比起 MySQL数据库来说， Oracle数据库的功能设计提现出对 oltp场景的理解更深刻。很多设计确实是经过打磨设计，发现这些这样做都是有道理的。我在 TiDB和 OB的原厂交流中，这几个头部企业坦然说到了和 Oracle的差距，也在学习。比起有些国产数据库上来就是吊打 Oracle，务实很多。现在国产的一些不好的思想其实就是来源于没接触过 Oracle。引用吕老师的话说，没搞过 Oracle的，但又是数据库圈里的人，特别做数据库开发的，对 Oracle的印象就是：集中式、落后、旧时代的产物，超过 Oracle很简单，基于 Poxos/Raft，随便上个分布式就可以了。如果再实现个 LSMTree，那就超过 Oracle太多了。而实际上即使 OB、 TiDB还都没这样说。反观 Oracle的格局是什么：我接触过的 Oracle的人听他们说， Oracle支持国产信创政策，但这不是一早一夕，需要很长一段时间，将会一直陪伴着客户走完国产信创之路，可能 5年，可能 10年，可能 20年。

    OB希望大家给他们提一些问题和建议。我想到了一些，但是当天时间有限没来得及说。我就在这里写一下吧。这些问题是仅代表我个人的阅历和视角看待。当然这些问题不仅仅是一家数据库厂商的问题，是整个行业涉及的。

   问题 1：分布式还是一体化（集中式）？各有各的场景吧。个人观点达到分布式的体量用分布式，否则还是集中式。这个体量如何判断，其实不好说。拍脑袋说一下，用户体量上亿的互联网公司、运营商、银行等。而在国内绝大多数公司还是结合自己实际情况使用集中式比较合适自己。那么集中式一体化可能会更加适合用户。当然集中和分布都具有就更好了。在退房时候，就看到前台的两个时钟相差了 8分钟，一看自己手表。他们都错了，一个快了一个慢了。这时候恰好老白来了，我们还说这要是分布式数据库时钟这样，整体问题就很大了。结果 30分钟以后，老白就在群里问有人此时此刻就遇到了这个时钟问题，怎么解决？分布式要考虑的太多太多，网络和节点的协调有的时候真的不以自己的意志为转移。如果集中式场景下连锁或者事务隔离都没搞清楚的话，甚至 SQL性能比较严重，那么分布式下会把这些问题放大。

  问题 2：很多时候分布式的容灾其实考虑的很完善。只是我个人从业（也许我经历有限）就几乎没遇到过硬件故障导致数据库不可用。我遇到过的数据库故障总结下来几乎都是 SQL引起的，甚至这些问题可以蔓延到中间件层面。我在我即将出版的书中收集了不少这样的问题。我本人不怀疑 Oracle OB TiDB PG MySQL等任何一个官方公布的性能数据。但是烂 SQL是常态化的，因为我接触过各行各业的开发人员也有小 2000人了，就这些样本看来情况不乐观。普遍存在的现象是对索引没有概念，更加不要说执行计划。曾经有一个从事 3年开发工作经验的开发人员，在开发眼中会建立单列索引并且能使用到这个索引的都是高手。如果建立了不起作用，那么再试试其他的列。如果建立复合索引，并且能够被使用到。简直是神一样的存在。所以在这种情况下（非互联网行业的其他行业中），数据库的稳定是很难的。尽管很多数据库上还开发了资源隔离功能。从我使用的角度来看资源隔离有一定作用，但是不如熔断来的好。可能熔断的效果和作用比隔离来的大。由于现在微服务和中台概念泛滥的环境下，数据库都进行了分库。资源隔离可以使得 N个数据库中只有一个数据库不可用，不会影响全局。但是这 N个数据库是耦合度较高（大部分都是为了分而分的）的流程，对于整体流程来说还是失败的。所以数据库是没有直接影响全局，但间接来说是业务上还是受到了影响。而如果熔断做得好的话，就特别能解决企业的难点，就最大限度上避免了在我国现阶段下应用程序低质量对数据库的冲击。从而提升数据库的稳定性。当然熔断也不能取保万无一失，那么出现小概率的没熔断怎么办？这个时候我就想起 Oracle一体机，他以其变态的 IO能力来做最后一道防线，正面硬刚烂 SQL。这已经是将危害降到了最低了。剩下的就交给 DBA了。大会上说 DBA是数据库的保安，如果保护数据库，我个人认为 DBA还是数据库的医生。预防永远比临机处置要好，日常多做保健，才可以减少不必要的急救。所谓平时多流汗，战时少流血吧。 DBA尽可能的把战线向前移动，管控好开发和需求，避免烂 SQL冲击数据库比起高可用容灾效果更好（以上是我个人观点）

   问题 3：多模和 HTAP。多年前在 DTCC和日照老师一起吃饭时候，他问及我公司涉及哪些数据库？我一一道来，每种类型数据库至少一个。他吃惊问我为什么？其实就是由于各种类型的数据库对应的场景不同。这个在互联网公司可能随着 DBA的技能增加而提升收入。但是在非互联网公司多会几种数据库技术栈，薪资是不可能提升的。而经济不好时候，还要面临数据库整合。如今多模数据库已经成为了标准和标配。只是看有几个模态是 3个还是 5个或者更多。承载越多模态的数据库的欢迎程度就更高（当然这里严谨一点的话是说每个模态的非重度使用的替代）。另外关于大数据，其实真正拥有大数据的企业并不多。如今的硬件条件比起 20年前，不可同日而语。其实都是可以在集中式场景下，替代 Hadoop的全家桶。这对于企业来说是非常客观的成本的降低。这些方向都是可以帮助用户降低成本的（人力物力和财力的总体成本）。

微信扫一扫
关注该公众号