传统关系型数据库、中间件+数据库、原生分布式数据库使用原则？

问题1。
传统关系型数据库，如Oracle、MySQL、DB2等，支持SQL操作，具备ACID属性，通常用于处理业务数据较小的OLTP。随着业务数据的增长，传统关系型数据库已慢慢无法满足业务需求，于是，应用系统开始考虑分库分表的方式，即将一个业务系统的数据按照一定的规则，分布到多个数据库上，这样每个数据库需要处理的数据可以更少，以此满足业务系统不断增加的数据处理需求。中间件+分布式数据库模式就是属于此种情形。其中中间件主要用于数据的分片与分布式事务的处理，对应用来说是透明的。因此，中间件+分布式数据库主要用于数据量大的OLTP业务。而原生分布式数据库需重构数据库系统，原生支持分布式事务处理与数据切分，原生分布式数据库根据其数据处理引擎，有些适用于OLTP场景，有些适用于OLAP场景，还有些适用于离线分析场景。因此，我们在选择数据库时，首先要考虑是应用于哪类业务场景，其次要考虑该业务所要处理的数据量、数据增长的速度，业务的并发量等。如果选择的是中间件+关系型数据库，在数据库设计时，需要特别注意分区键和分区策略的选择，合理布局数据，尽量避免跨节点的分布式事务处理，以提高数据库的效率。
问题2：
对于OLAP应用，虽然各类数据库都可以实现业务数据的处理需求，但实现的成本和实现的效果大不不同。比如，关系型数据库（包括中间件+关系型数据库），大都采用行存，适用于OLTP场景，如果用于OLAP，虽然可实现业务能力，但效率较差。即使是原生分布式数据库，因重构数据库系统，也要根据数据处理引擎，选择合适的原生分布式数据库来处理OLAP业务。至于NoSQL，因SQL支持能力有限，如果要用于OLAP，会增加应用的开发难度。故在实际应用时，需要根据业务场景，以及自身发技术储备，选择合适的数据库。

问题一：
随着互联网的发展，金融行业当前面临如下问题：
1.金融 行业 数据库 一般以单机模式建设， 数据集中、业务集中、 在互联网背景下， 随着移动 支付全面普及，典型的 有 双 11场景， 海量高并发的业务场景， 对整个系统的安全性、可用性与连续性的提出了 更高的要求 。现有集中式 架构也暴露出性能瓶颈 及 扩展难的问题；
2.传统 数据库， DB2\ORACLE核心 团队在国外， 这种 模式不满足国家自主可控的要求 。 同时 ，封闭 架构导致技术沟通和支持存在响应慢、沟通难的问题 ，这种 服务模式不满足 互联网背景下，客户体验对系统的响应效率、个性化业务的快速上线也提出的 需求 。
3.建设 成本高，缺乏议价能力，不满足集约化经营的要求。
4.高层 监管对核心技术自主可控的要求。
以上 的行业现状，对已有IT 架构 提出了新的挑战，体现在几方面：

1.海量 高频交易对 已有 系统的处理能力及 扩展性 提出了 更高 的要求，而现有 集中式 架构，扩展能力受限 ， 无法快速 提升 系统处理性能；
2.针对 监管机构提出的业务连续性要求 （如7 X24 小时 不中断运行 ） ，需要系统具备高可靠的能力 ；

3. 面对业务 创新的需 求 ， 为 更好的 提供 个性化服务，需要业务 具备 快速上线 的 能力，而传统架构各模块间耦合度高，架构封闭， 软件 开发和产品服务交付周期长，无法快速响应市场需要；
   4.大小机 成本采购及维护成本高昂， 银行 客户普遍缺乏议价能力。 综上， 传统集中式架构 无法 满足新形势下的 业务 发展需要，急需进行自主可控的分布式架构改造。

   问题二：
   用中间件+开源引擎主要的问题是，无法深入做一些比如分布式事务，底层逻辑的优化等，
   如果银行业是浅尝辄止，做一些尝试也没有更深的规划和要求（比如替换核心），或者是完成短期的一些国产化任务，采用中间件模式是没有问题的。
   反之就要采用原生的分布式数据库。