昨天在公众号转发了一个人大金仓的解决方案，实际上国产数据库厂商的一些有代表性的解决方案如果有兴趣的话都可以发给我，在我的公众号平台上免费宣传一下，能为国产数据库的推广尽一份力，一直是我的愿望。对于国产数据库，很多人是又爱又恨，不过我想这种“恨”也应该被我们的数据库厂商所包容，只有充分听取那些“恨”你的客户的意见，才能把自己的产品做得更好，能够不被国际大厂抛得太远。
昨天也有些朋友通过微信和我交流，对金仓的数据复制产品提出一些疑议。我也十分感谢这些热心读者，他们十分专业的意见不仅让我受益良多，也会促进我们的国产化产品的发展。我会记下他们的疑问和建议，并将这些意见转达给厂商，以便于他们改进产品。
作为数据库厂商，Oracle是一个标杆，而且是近些年我们的国产数据库很难逾越的标杆。但是现在既然已经决定走自主的路了，那么再好的产品都必须要扬弃掉，因此我们的国产替代产品就必须能够尽快把水平提高上来。我这些年接触过很多国产数据库产品，能够让我大体满意的产品少之又少，这是因为有一个强大的标杆立在前方。我用了近30年Oracle，了解其方方面面，因此任何一个国产数据库在我的眼里，都会不自觉地去和Oracle相比，其优点不见得能超越Oracle，其缺点是明显会被Oracle碾压的。
但是当我们已经明确要做国产化替代的时候，这一切都已经不重要了，作为数据库产品的用户，在接受某个国产数据库产品的时候，必须接受并暂时忍受其缺点甚至是缺陷。不过反过来说，我们的数据库厂商也不能因为处于这样一个有利的形势下就直接躺平，也必须打起十二分精神，尽可能把产品做好。
做好一款产品是十分不容易的，我们做了6年的一个数据库运维工具现在都还千疮百孔，问题多多，更不要说是极其复杂的数据库了。技术能力、资金投入、用户场景等都让尚在年幼的国产数据库产品显得还十分稚嫩，无法给用户提供与Oracle这样的产品一样的使用体验。其实看看近些年Postgresql社区版的技术发展，就应该能够明白我们给国产数据库留的时间还是太短了。一些PG用户期待了十年的功能还是屡屡跳票，作为资金、研发人才、装机容量都让我们的国产数据库难望其项背的PG社区都是如此，我们确实也要给国产数据库厂商更多的时间了。
不过随着时间的推移，我们的替代工作明年就会进入深水区了。大量大型企业的关键、核心系统的数据库迁移工作已经列入日程，而此时，我们的国产数据库明显还没有完全准备好。其最主要的特点是大版本的功能迭代太快了。可能有朋友会说，功能迭代快还不好吗？这不正说明我们的产品进步大啊。实际上作为数据库来说，稳定是十分关键的，过快的功能和产品迭代只能说明目前的数据库产品还不够成熟。
Oracle从20多年前的Oracle 8开始到现在，其数据块的基础结构就没有发生变化，块头的优化扩展也很小，而我们的很多数据库厂商还处于动不动就更换存储引擎，彻底更换REDO架构，从这一点上，也可以看出虽然我们的国产产品在努力赶超，但是其架构还没有完全稳定。我想最快也要在2-3年后，这些迭代比较快的数据库产品才能进入一个相对稳定期。
这种情况的存在对于用户来说是不够友好的，因此我们的数据库用户在做国产化数据库替代的时候，只能暂时让自己的应用多承担一些数据库的职责，给数据库减减负。只要能够坚持下去，再过几年，我们的用户也可以像使用Oracle一样随意写出比较烂的代码了。
下周要陪儿子做毕业旅行，去云南阿布吉的山里做一次5天的徒步。这也是今后十年二十年里父亲能够和儿子做的最后一次共同旅行了。孩子再也不是那个喜欢骑在爸爸脖子上的小娃娃了，进入大学后，将会真正开始自己的生活。我十分珍惜随后的一个星期，哪怕有再重要的工作，都必须放下，去享受这种最美好的生活。
基于此，我的公众号也将会在下星期改变风格，也许会发几张路上的美景。不过进入洗脸盆垭口之后，我将和大家彻底失联4到5天，这些天里我会通过北斗短信，每天向亲人发送一下定位，报个平安。
在放下工作之前，这两天我会尽可能完成针对PG/gaussdb等待事件知识图谱的梳理，如果顺利的话，明天我会把上回那张PG等待事件原因分析表的完整版发出来，作为我彻底放飞自己前给大家交的作业吧。
