昨天发了篇吃面的文章，实际上面好不好吃一方面取决于面馆的水平，另外一方面取决于吃面的人的口味。讨厌甜口的人，去苏州最好吃的面馆也会觉得面汤味道怪怪的。其实还有一方面是自己没有把需求讲清楚，很多人吐槽苏式面条太生，吃不惯。确实是的，苏式面条和上海阳春面的主要差异就是面芯不断生，苏州人就好这口。如果你不喜欢生的感觉，可以买面的时候说软面或者断生，下面条的人就理解了。红汤白汤，加不加青蒜，汤多汤少都是根据口味可以提要求的。如果这些都做完美了，面还是难以下咽，那说明苏式面条确实不适合你,你可以试试刀削面或者南京皮肚面。

谈到数据库的使用，和吃面有点类似。不同的用户，可能有不同的偏好，技术能力与技术侧重点也不相同;不同的应用场景对数据库也有适配性，有些场景连ORACLE这样强大的数据库也不一定适合。因此根据你企业的特点选择合适的数据库十分关键。哪怕是一种十分优秀的数据库，面对类似的应用场景，在不同用户那里应用效果也可能有较大的差异。

前阵子在一个闭门交流中，谈到金融行业使用分布式数据库的问题。有位专家就谈到分布式数据库的应用场景问题，银行系统最初对分布式数据库是十分推崇的，认为只有分布式数据库才能满足银行未来的高并发与高可用的需求。不过在一系列实践之后，他们发现最初的想法有些一厢情愿了。分布式数据库在横向扩展、高可用等方面确实具有一定的优势，不过其复杂性远高于集中式数据库，使用成本也比集中式数据库要大，在应用迁移过程中，应用与数据库的适配难度也大大增加了。

面对同样的问题，一些技术实力较弱，资金投入较小的银行遇到了巨大的困难。而对于那些资金投入巨大的大行，这些都不是问题。因为他们可以在核心应用上针对数据库做适配性改造。甚至有些银行把交易中的事务全部拆分为本地事务，分布式事务完全由应用系统来自己处理。实际上是把一套分布式数据库当成一堆集中式数据库来使用了。

对于资金十分雄厚的金融企业来说，A类核心系统的国产化迁移并没有太大的困难，反而是大量的B/C类系统的迁移成为了难点。一方面是没有那么多的资金，像迁移A类系统那样投入巨资去做应用改造，另外一方面也无法像核心系统那样不计成本地投入海量硬件来完成系统迁移。

数据库应用就像吃面一样，有时候不是面不好吃或者是吃面的人不懂欣赏美味，而是面和人的适配度不够，或者说来自北方的吃面行家不太懂如何吃好一碗苏式面条，所以选错了浇头，选错了汤底，最后吃倒了胃口。

每个行业应用都有其特殊的要求，这些年来，大量的关键行业用户都摸索出了一条让先进的商用数据库如何更好地适配本行业应用的道路，从单机到HA到RAC，从备份系统到两地三中心架构到全局负载均衡下的系统双活。Oracle等数据库厂商也在不断地改进自己的数据库产品，使之能够满足用户的业务需求。Oracle 数据库从单机到Standby Database到Dataguard/Active Dataguard，高可用架构从MAA到白金MAA，高可用切换从TAF到FCF到AC/TAC，都是为了适配关键行业应用在高可用高性能等方面不断提高的需求。

不要太过于迷信某类技术，不要攀比和盲目借鉴，切切实实地根据企业自身的特点去做好数据库国产化替代策略的设计，是每个企业都必须做好的事情。前些年我在一个移动公司交流数据库运维工具的时候，了解到他们的数据库替代策略。关键系统，使用分布式数据库OceanBase做替代，投入巨资让开发商进行应用适配性改造。数量庞大的非关键系统，选择和Oracle兼容性最强的数据库，比如达梦，尽可能在不修改应用代码的前提下完成替代。策略一定要够简单，够明确，这种策略一旦确定，就可以很快速地推进下去。

我见过的另外一个企业的替代策略：小型系统，简单替代，在尽可能不修改或者少量修改应用的情况下实现替代;中型系统，优化后替代，修改部分不兼容的SQL，并进行适当优化后实现替代;大中型系统，改造后替代，投入一定的资金，对系统进行适配性改造，并根据应用特点，进行适当的架构改造，比如使用读写分离等策略;大型系统，重构替代，在系统进行升级改造时，通过对系统进行大规模的重构，完成替代。

看似第二个企业的策略更加清晰，不过缺乏实施的细节，需要在实施过程中不断细化和优化，因此真正推行下去的时候，反而不太容易。

数据库国产化替代，实际上做起来反而会觉得没有规划时那么难，技术问题往往都是有办法解决的。一些技术之外的问题，才是十分头痛的。十分不幸的是，规模稍微大一些的企业，做数据库选型和替代策略设计的人往往是不太懂数据库的人，做出来的方案不见得是实施部门所喜欢或者擅长的。就像是熊孩子想炸鸡排面，家长非得给他点一个更加健康的素浇面，吃起来，味道就差点劲了。