云厂商数据库还是的要靠点谱 （2） 有希望

哎，心里想着写这个系列的文字估计的还的积累点素材，但是呵呵，真的不需要，没过一个礼拜我的素材就备齐，没看过第一期的，可以这里来寻味一下我的无力感来自哪里。

https://mp.weixin.qq.com/s?__biz=Mzg4NDA0NTEwNA==&mid=2247495436&idx=1&sn=9798274f42b6fb1ba3bd8fe75ae90812&chksm=cfbc8b53f8cb024522cd849896b8deb88301bd26ffbc6f6666d2a7c3c5fa12f6d7e445a77c2d&token=520256582&lang=zh_CN#rd

第二期为什么就这么快面试了，我来说说， 先说A 云

我们在使用P 系列的数据库后，感觉是不错的，当然问题是有的，作为进入了db-engines 的数据库，并且在 墨天轮里面的国产数据库常年霸占前位的数据库，当然人家是有点实力的。

但是，但是，但是，就怕但是，最近发生的一件事我觉得，国产数据库的路还有很长。

我们以这个数据库的中的 SQL_MODE 为例，你相信这个值是空的吗，对MYSQL的 SQL MODE ，开源的MYSQL实体机专业的部署SQL MODE不会是空的，但这个数据库是空的。

https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html

官方SQL MODE 是针对MYSQL 在使用中与开发有关的一些使用的方式方法进行标定和设置 ，以及SQL 的标准等进行控制的地方，如 我们最熟知的 ONLY_FULL_GROUP_BY 这个参数，我们希望他和社区的的SQL MODE 是兼容的，或者直白的说，要一致呀。

此时，为空是什么意思，这里我想使用云的众多人员，是不专业的，那么他们估计99%的可能是不会问这个问题，也不会理解当他们的应用程序和数据迁移到其他的RDS MYSQL 会出现问题可能就在这里。例如 5.7 TO 8.0

这里体现出来两个问题

1 用户的专业度不够，导致厂商本身觉得这不是问题

2 厂商中缺乏从企业来的信息，以及鉴别和改变的通用流程，以及鼓励措施

在写这篇文字的时候，我们在这个P数据库中还遇到了修改了系统的collation导致sys 库无法读取数据的问题，这个问题正在发生中，所以还没有定论，但值得死锁的是，这样重要的位置，客户可以修改，并且没有提示，想想那些不懂的野蛮的客户，如果出现了sys 库无法读取数据的情况，要云厂商解决，并且抛出一句话，为什么不早告诉我，修改了sys库无法读取数据的问题，此时云厂商的数据库部门该作何感想。

另一个云，Q云的MONGODB 的一个节点DOWN了，然后查了一段时间给出了一个原因，但是他们自己也不确认这个问题的根本原因，更深入的细节，或者更可信的一些问题的起因是无法找到的，这点他们也提到了。所以问题产生了，但是根本的原因找不到，在云厂商里面是存在的。

云厂商另一个死穴就是日志的问题，云数据库的日志系列一直是一个老大难，要不就是提供困难 ，要不就是提供困难，要不就是提供很困难。

当然说到不专业，国产某数据库大型厂商的不专业是亲身领教过的，你信吗整个数据库的开发团队里面，真正懂数据库的屈指可数，开发者之前都是干别的开发出身的，然后因为国产数据库热，所以都被挖来做数据库，专业性也可想而知。 所以对国产传统的数据库，我一点都不抱希望，因为比他们还差的有的是。

跑题了，现在最大的问题是，整体的各种数据库团队中的开发者，懂不懂数据库，懂不懂用户的需求，人家懂算法，可是否和数据库的使用者们的脑回路脱离了，这才是今天要提出的问题，大部分数据库都在想当然的进行开发以及参调配参数的暴露或不暴露，而不是和用户接近的来探讨这些参数以及提供建议值，结果就是开发出的产品，大面上都OK ，但是一到细节，就 “散了”，用户用的不爽，问题点多，而数据库的开发者也怨，你在教我做事吗？

作为三大系统之一的数据库， 应该是很严谨的一个产品，他承载的业务重要性不可言喻，当然BUG 在任何的程序类的产品都会存在， 但数据库尽量还是细致一些。

其实我也很理解，开发一个数据库系统的难度，从底层硬件，到C 代码，到肢解 MSYQL ， PG 的源代码进行研究，修改，算法，UI，测试，是一个非常耗费资金，人力，的精细活，出现BUG 也是很正常的，理解，这样的问题那样的问题都是必经阶段。

反过来还的说用户自己，自身还是要有专业知识，如果没有只能听之任之人家的摆布，此次A 云的 P （不是上面的那个P 是另一个P）系列的开源数据库，高可用丢数据的问题，这个我们就很理解，不会和其他那些不懂的客户，进行疯狂方式的询问和赔偿的要求， 没有必要，我们知道这样的设计 ，必然在高可用切换的时候会存在丢数据库的可能，那么既然已经发生了丢数据库的事情，我们解决就好了，但希望这个 P 系列的开源数据库在高可用探测 和 细节上做的更好。

我们也知道他们很难，懂的用户很难找，大部分是不懂的用户，在数据库瞎搞，乱搞，胡搞， 也是这些云数据库厂商所深恶痛绝怒的，我到是有一个想法

A 云可以搞一个 A云数据库的 FANS 的项目，凡是针对云数据库提供准确的建议和BUG 的提交的客户，可以升星，可以有一些优惠，或者技术上的互相合作，比如A云某些考试 FREE ，或者一些 A 云的核心用户系列，在产品的产生的过程中有更多专业用户的声音，而不是闭门造车。

然后通过建立这样的社区，让用户去感化用户，让用户去提升用户，通过另一种方式接触客户，让客户去看看别的客户是怎么使用数据库，让那些不懂的客户， shame on you . 提高整体用户使用云数据库的层次，而不是一味的要不和用户PK 冷战，要不就无限制的妥协。

数据库整体是一个生态，牵扯的点太多，要做好不容易，要做烂很容易，最终还是那句话，作为用户的我们，做一个专业的客户说出的问题，提出的建议尽量专业，尽量不制造一个一个的“笑柄”。 （想想一些不专业的客户，去蹂躏云数据库厂商，他们的难度，想想就头疼）

顺便说一句A 云的 Postgresql 开源系列的那个数据库的 负责人很nice，提出的需求很快响应，并且A 云的 Postgresql 系列开源数据库 RDS 行业第一的印象是扎根在心里的。

至于在 P 云原生数据库中SYS 库无法读取数据的问题，有了结果会写一篇，避免大家采坑。