最近有点事情，可能最近一个礼拜，无法更新内容，敬请见谅。
文字的起始是因为公司的第三方的开发要开发一套, 和各个银行对接的系统,(商业机密就不提了),具体的情况是我们将数据推送给各个银行,银行接受,然后就能看到滚滚的 原型包方块了.
第三方开发公司给出的方案很有意思,给出了一套以MYSQL为基础的分表方式的数据库架构为基础的,数据流转系统.
我们先看图,看图说话
标记MYSQL 的是第三方开发的设计的一个大致的系统设计路, MONGODB 是我这边给出的设计思路.
其实系统本身并不复杂,就是我们接单,然后作为一个分发平台,将信息整理后发送给合作的银行, 然后和对应的银行签约,然后人家发送回执.(其中的分发规则是核心点)
这个系统个人感觉难度有两点
1 数据量,数据量方面MYSQL 一直是我担心的,主要还是数据库原理,承载数据的程度,到一定的数据量就衰减, 当然第三方开发想到了通过分表的方式来解决
发送数据和接受数据的问题. 这是一个使用MYSQL本身的必然情况和解决方案.
MONGODB 本身的支持的数据量单库MYSQL是无法比拟的,可以说是卡车和大型铁路货车的区别,这点无用质疑.在数据量方面和接受并发方面,MONGODB 对于MYSQL 都属于碾压的行的,这点没有争论的必要.
2 业务的灵活性的问题
签约的银行,每家都有自己的特点,都有自己的接受报文和发送报文的要求,我们合作的银行越多,那么这个系统就越难设计,因为MYSQL 和 RDS 数据库本身的限制,导致字段的定义困难,如果你签约10-20家银行,我怎么办,难道要设计20张表,每个银行一个表,那程序该怎么写. 所以第三方想出了,用MYSQL 先产生20个冗余字段,并且每个银行的不同的值都存在这些预先设置的所谓的 KEY VALUE 中. 然后在MYSQL 另外一个表中,存储每家银行的这些活动的KEY VALUE 的真实定义.
MONGODB 的无SCHEMA 的设计理念,正是此时最好的场景的利用点,
1 每家银行都没有固定的KEY VALUE ,对于MONGODB 来说,这太容易处理,每个document (行),都不必要是一致的,开发就不必使用上面,蠢笨不讨好的方式来设计,还在来一个表来定义这些未知的 KEY VALUE.
2 每家银行的定义,本身也是会改变的,今天建设银行抽风,说我们的有几个特殊的信息,明天告诉你没有了,或者又加了几个字段,你怎么办, 改改改.每次查询一行数据行,都要和你的配置表进行对应. 数据流小OK ,数据流大,那怎么办,用REDIS 缓存你的配置定义,然后弥补你性能的问题.
MONGODB 的一些特性,如跳跃索引,就可以解决你查询中,有些行有这个字段,有些没有的问题,
数据存储量的问题,解决了,信息字段经常被变动的问题解决了,我真不知道, 抱着MYSQL 是怎么好. 难道是想提高自己的解决问题的难度
这里第三方开发给出一个问题,就是数据的状态的问题, MONGODB 的灵活的嵌套方式, 数组方式,可以随便根据开发的需求来定制化你想要怎样就怎样的数据状态,获得OBJECT_ID 通过主键查询可以获得快速的查询速度. 实际上这个项目使用分表的确是过了.
数据库本身加入程序设计,是让程序的设计变得简单,高效,而有些数据库架构的设计让本身可以简单解决的问题复杂化这样就不大好了. 当然MONOGDB 也有自己的不足,在数据统计方面，数据的聚合方面,的确不是他的优势, 但想问一句 ,MYSQL 在数据的统计中是他的优势. 去找 POSTGRESQL 不香吗.
综上所述，在理解了业务的逻辑以及业务的特点后，选择合适的数据库来处理你的问题，的确是可以事半功倍，而选择错误的数据库，则会让代码变得复杂，代码逻辑也变得混乱，容易出现其他的问题。
