和架构师沟通那种“一坨”的系统，推荐只能是OceanBase，Why ?

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2800人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群约320+ 9群 100+）

有的时候你在专注一件事的时候，命运会给你一些相关的事情帮助你成长，最近在看架构方面的知识，提高自己的水平，从架构师的角度来审视数据库的选择和使用，站的更高看的更远。这不就来活了，一个架构师私信我，他们要数据库选型问，选那个数据库更好，我把这段内容进行了记录。

正文

架构师：您好，我看了您不少文章，我有一个问题我们单位要更换数据库，我们现在遇到一个瓶颈的问题，我想收集更多的信息，您看您方便吗？

我：OK

架构师：是这样的，我们单位之前开发了一套系统，使用的是ORACLE，开发的时间比较久了，在我来之前就运行了很多年了。现在要国产化，我想了解一下从数据库的视角您觉得哪个国产数据库更好替换ORACLE。

我：我是这样看的，替换ORACLE的方案很多，国产数据库也很多，替换的方案也很多，但是我们是否应该先把您的业务弄清楚，以及您更换的痛点找到，如果能通过更换数据库解决您的痛点是不是需要考虑的。

1 业务属性 

2 业务特点 

3 架构迭代与递进（如果知道的话）

 4 代码是否可以进行修改 （确认与原有数据库的兼容性） 

5 当前的系统运行的痛点 

6 其他非业务，非架构附属但重要的限制问题。

架构师：这么麻烦，其实就是选一个数据库而已，不过当前系统的痛点是，数据库不能扩容了，这个一直是我们的心病，我们现在的ORACLE的内存已经1T了，硬件上内存已经不能再扩容了，后面如果还继续用ORACLE，我们可能的重新购买机器，至少内存2T的，把库迁移到新的硬件上。

我：为什么，业务不能拆分吗？这么大的库，为什么不用拆分法，如果您的库能拆分，那么可以更换的数据库种类会比较多。

架构师：这个不是我们不拆分，是历史的原因没有办法拆分，我们也想使用微服务，但各种原因不行。

我：为什么不行？

架构师：其实是这样的，在我来之前，这个业务在搭建的时候并不是单位的重点，所以当时把通用数据和业务中的个性化数据写到一个库里面了，后面当我接手的时候，发现虽然前面的架构师已经努力把业务的数据进行独立了，可历史的原因一些“公共”库里面的数据里面已经有业务的数据，同时还有一个问题，早期开发将一些展现给客户的业务特性化的数据也写到了公共库。

导致我们现在一些业务中，的语句必须写成

select xxxx from 业务库的表 left join 公共库的表

这样才能完成业务的数据查询，还有一个问题，早先得的一些事务将写入信息也将一些业务库的数据和公共库的数据搞到了一个事务里面，年代太久了没法拆分。

我：我多说两句，我有几个问题想问一下

1  为什么咱们不能进行公共数据访问服务化下沉呢？您作为架构师应该明白，将通用的数据抽象为一个用户服务，业务层只能通过服务的RPC接口来访问公用数据，上游的业务不能直接通过SQL 来访问公用数据，这个数据库瓶颈的问题不就解决了？

2  一些个性化的数据的提取通过微服务变成两次访问，拆解SQL，由JAVA程序来进行公用数据和用户数据的合并工作，这不就可以了吗？

架构师：不行，这里面有很多事情，比如一些数据的实时性有要求，如果我通过两次获取业务和公共的数据，有可能因为公共的数据的变动导致我的此次查询是错误的。另外我也刚来不久，很多东西我也没有太清楚，如果我用上面的方案出现架构改造的后导致业务失败，这个责任我付不起。

我：其实我觉得您现在的问题，不是数据库可以解决的，您应该重构您的顶层设计了，主要你的问题在与你的系统的交互方式出现了严重的问题，这也是作为ORACLE为基础的数据库系统，经常出现的问题，我们俗称“一坨”shit.

你看互联网的应用系统没有这个问题，为什么因为他们的架构经历了，四个步骤，其中第四点解决主要矛盾迭代设计这个部分，他们使用的都是MYSQL，所以在设计之初就考虑到这方面的问题，所以架构和业务分的很开，加上微服务的使用让数据库不耦合，也不会产生您这样的问题，您说对吗？

架构师：嗯，对因为我们是一个国有企业，一些系统的乙方已经找不到了，或者换了乙方，所以我的难题是一些系统我想改也改不了。所以我想看看能不能从数据库的角度去解决问题。

我：其实我的方案还挺多，至少我有两个方案

1.1 代码拷贝，也就是你在拆分的时候，将公共库的代码和公共库的数据一起拆分，到每个业务模块里面。 

1.2 更换分布式数据库产品

1.1
我先说第一个，您在拷贝公共代码到各个业务库后，最大的难题是公共数据的在业务库的同步的问题，那么我们可以采用CDC数据同步工具，据我了解目前TapData的数据同步是即时的，他们有实时数仓的案例，那么也就可以满足您数据实时的要求，将您的公共库的数据同步到业务库中，并进行查询时的使用。

但这里面的关键在CDC数据同步的软件，这是您业务是否能正常的核心点。

1.2 更换分布式数据库，我建议您使用OceanBase来解决您现在的数据库瓶颈。

1 OB 兼容ORACLE数据库产品的SQL语法

2 OB 兼容ORACLE的存储过程

3 OB 可以在您切换的时候不用动大部分的业务代码。

主要还是因为您的系统现在是“一坨”的状态，所以您现在短时间从业务的角度去微服务，剥离业务和公共数据之间的关系，以及剥离公共数据是有困难的，所以采用OceanBase也是目前您解决问题成本最小的方案，毕竟我看出来您的业务代码“乙方”应该没有能力进行修改。

不过我还是建议您，后期可以拆分了，可以把公共数据通过OceanBase的租户方式进行拆分，进行强拆满足您后期的架构重构中，阻止一个SQL在业务库和公共库写成一个SQL进行公共调用的问题。

且这个方案后期数据库将不是瓶颈，如果您不进行架构的重构也可以持续运营下去。同时从非技术因素上这里也考虑了您单位的属性，您单位是不是有一个可以选择的国产数据库的名单，这些名单都有OB。

总结：一个数据库的选择不是上来就比对数据库的差异，而是要先把业务，他系统的架构的根本痛点找到，在比对合适的数据库进行选型，上来就推荐数据库的我只能给他俩字“瞎鬼”。

                             追逐太阳的男人--林春 《金融数据库转型实战》                           

竹板这么一打，架构很复杂，选型看病要治本，头疼钻头脚痛切脚，那是西医的干活，中医望闻问切找病根，层层拆解寻妙法。