开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase,SQL SERVER 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共1300人左右 1 + 2 + 3 + 4） 3群450 关闭自由申请，新人会进4群,另欢迎 OpenGauss 的技术人员加入。

每日感悟

利用不花钱的情感来要挟你，让你破财有的时候非常有效，比如XX有难，你要捐款，X货你要支持，你要爱国，用一种圈养式的情感来绑定你的钱包是最终的目的，今天你爱X了吗？X货你购买了吗！

最近临时工的胆子大了，什么都敢说，可不是，说呗，反正说完了，就被这个公众号的老板开除，怕什么。

最近一段较长的时间，国产数据库被骂，好像是一件非常普通的事情，下面我的群里面，只要提起国产数据库，那是骂声一遍接一遍，此起彼伏。

说句笑话，现在的数据库从业者，如果不骂几句国产数据库，是不大入流，当然我也讽刺过某些极个别的。如题，到底谁垃圾，这里并不是要指名道姓的说那个国产数据库垃圾，临时工想说的是，产品 和 客户到底那个更垃圾

客户垃圾：

首先咱们说说，垃圾的客户，或者说那些奇葩的客户，一些提出怪异和无底线的要求的客户。这里用一个故事来快速导入，咱们来看看这样的客户是不是奇葩，基于隐私，不会提是那个数据库厂商，也不会提是那个客户，这里以 G 和 g 两个字母来标识。

故事是这样的，G 数据库厂商接到了，某g客户的POC需求，需求中有一栏是，要求1000万行的单表数据，在查询中，不允许建立任何的索引，通过where条件来进行连续查询1000次，时间控制在1分钟，只要有一次时间高于1秒POC此项失败。同时提出把Oracle 所有的蹩脚的函数进行适配，在功能上进行一对一的比对和验证，那个数据库完成的全面，则得相关的分数。

这里简单总结一下客户的需求：

客户需求 1

1  单表1000万行数据，不能建立索引

2   查询中带有where条件，进行数据查询

3   高频，高并发的查询，因为从时间和查询的次数相比，不进行高并发的查询是无法满足1分钟 查询1000次的需求

4   评分点，不能有一次查询的返回时间超过1秒。

请到这里的各位看客，你们来说说，你们掌握的那些数据库可以满足这样的查询的方式。当然这里说的是关系型数据库，不是缓存型的数据库。

客户需求2

在G公司的分布式数据库上进行两个分布式数据库之间进行数据实时同步方式的节点扩展？要求实时同步，有延迟可以，但不能超过N秒。

在接到这样的需求后，实际上是十分不理解客户这样的需求是来自于哪里，并且如果想参与POC我们如何能达到相关的客户的POC需求。

客户需求3 

在分布式数据库大量进行数据写和UPDATE的情况下，增加，减少节点的情况下，原有的客户链接不能中断，或者说客户感觉不到中断，并且应用不能报错。同时在突然掉电分布式数据库节点3分之一的数量的节点后，不能出现应用报错的情况，掉电的节点随机。

从理智的角度上来说，一个数据库产品，一般在1000万行数据的情况下，不通过索引，进行高并发，带有条件的查询，其中一次超过1秒的可能性很大。

同时一个分布式的数据库产品，扩展节点的方式，或者说扩展数据节点的方式，并不是通过传统的数据日志传输而达到的，而是通过内部的方式来添加节点的，所以第二个需求的在要求什么。

第三个需求中是需要任意关闭几点的，不管你是前端的节点，还是数据节点，还是路由节点。如果他随机把前端的节点都关掉了呢，或者把路由节点都给关掉了呢，

当然，这三个需求在精心的设计下，都完成了，但我特别想问的是，如果数据库厂商的心思都花在奇葩需求的满足的条件下，他还有多少精力专心在研发中，在实实在在的数据性能的优化，和实际的功能的潜心研究和编程中。

你见过一堆人，在为了满足这些奇葩的需求，用各种“有意思” 的方法来去满足客户的“纸面” 的需求吗？

首先不建立索引1000万行的数据表，条件查询一分钟查询1000次，每次不低于1秒，这是哪个客户的 “智库” 想出来的，不要说国产数据库，ORACLE 能做到吗？（注明不要用内存表）

分布式数据库 和 分布式数据库之间要求进行数据实时同步，通过这样的方式来进行节点的扩展，这样的要求估计TIDB 听到了也触头。给出的理由是，扩展方便。最后一个要求更奇葩，随便关闭，那个数据库可以完成，无厘头的随机关闭节点并保证万无一失的数据连接持续工作的要求。

这当然不是最离谱的，其实你每天都可以从一些国产数据库从业者尤其是做售前，POC的同学那里，听到更有意思的客户需求。

实际上数据库的从业者，在听完这些需求，可能就会宣泄出一些不好听的词汇，说垃圾应该属于有礼貌的。

实际上国产数据库很多的厂家，都在经历很多有消费能力的垃圾客户，这些客户有钱，有实力，实际上很多的POC 本身就是编造出来，为了暗箱操作早就预定好的数据库产品。POC 的需求是假，通过需求将不是他们要的数据库产品尽早的排除在竞选名单之外才是真的。 当然这些需求从哪里来的，作为临时工，也不大敢说，主要还是怕黑，煮豆燃豆萁，相煎何太急。

在垃圾的环境中，国产数据库能完全有能力发展好 ？尤其对一些中小型的厂商，在依赖一些金融，电信，以及政府的领域的客户时，这样的问题凸显。所以他们很难，他们的研发力量可能每天都在面对各种的奇葩的需求，以及一次又一次无效天方夜谭的POC。

产品经理垃圾：

故事到此没有为止，还有一部分的国产数据库的阻碍在内部，产品经理，数据库产品的产品经理， 你能相信知名的数据库产品的数据库产品经理，从未了解和使用过数据库，对于数据库的产品经理的要求是，进场先学习什么是数据库 ！

不少数据库公司的产品经理，本身不是来自于数据库行业，更多的本领是沟通，协调，喝酒，上台演讲（说假话不能脸红的那种，如果能正义凛然更好）。如果你问他，产品的原理，产品的规划步骤，产品的缺点和补救措施，以及到底多长时间和客户进行密切的沟通，来了解您的数据库产品的问题，是被动发现问题，还是主动发现问题。

你在这一串拷问后，很可能你得到的是一脸的茫然和疑问，如果一个公司的产品经理对自己的数据库产品都不熟悉，本身是一个门外汉，进门还要学习什么是数据库，数据库的原理都讲不对，出门让人怼死。这个数据库产品能好吗？

建议要选择一个数据库产品，先和数据库产品经理沟通一番，他能把产品讲明白了，原理都对应了，实在真实的把优势和劣势都讲清楚了，你在进行POC。

关于数据库产品经理，至少应该在数据库行业有多年的经验，至少使用过的数据库产品不应该是单一的，同时在企业中应该做过相关的数据库角色的职位，当然还应该有产品的眼光，比如从用户的场景和功能的层面如何协调那些功能是必须有，那些是功能可以暂时没有。

对于目标客户和自己产品有清晰的认知，做产品是随大流还是有自己的见解，比如对于市场的洞察和产品的规划，竞品分析，客户拜访，确定业务目标，输出产品设计需求，推动产品功能的迭代和产品功能提出和可实现，以及后续的产品的推广和协助运营进行数据库后续的运营工作，这些都是数据库产品经理，需要做到的。

产品经理是一个综合性的岗位，需要对数据库周边的信息也进行了解，一个数据库产品众多的产品经理，每个人有重点的进行工作，在国产数据库的体系里，有这样的“完整” 的数据库产品经理或管理体系吗？  有吗？

更多的是进行数据库POC的测试，挂着羊头卖狗肉的，经理。

最终，一个产品，在垃圾客户，垃圾的产品的作用下，在引入了无效的POC 又在进行无效消耗的工作氛围下，我们能得到一个什么样的国产数据库产品。

垃圾的客户，垃圾的无理智的需求，让国产数据库研发人员在做客户蹩脚的需求，没有时间去研究核心，研究性能改进，研究各种深层地的BUG， 他能不套壳吗，他能不吹牛吗，他能脚沾地吗？不能

在一个不理智的大环境下有一批天马行空的客户，造就了一批内卷什么都敢答应的国产数据库厂商，创造了一批嘴上的世界级产品，线下的六台不如人家一台的实际情况，终有因果，也造就了一批一看国产数据库，就DISS 的“愤青”。

终究这些都是谁的错，谁垃圾，更垃圾！