今天就来说说几类关系型数据库的数据解决方案。1、目前市面上主流的Oracle版本应该还是11gR2。记得很多年前有个网站做过一个调查。10g和11g版本的比例几乎是6:3。我觉得11gR2版本的比例应该能占到90%。以上，剩下的份额应该是12c。现在使用10g版本的数据库已经很少了。除非业务对早期版本足够稳定，否则真的没有理由不升级。下面简单说一下Oracle的解决方案。从容灾的角度来说，OracleDataGuard毫无悬念，从9i的基本功能，到10g作为标准组件，11g的ActiveDataGuard，SnapshotStandby，12c的FarSync以及后来的更多定制，DataGuard已经表明，备库不仅仅是一个备库，而是可以承载更多的业务操作。从高可用的角度来看，OracleRAC是目前数据库高可用解决方案中的佼佼者。因为经历了大量的生产实践，这款软件可以说是很多大企业的标配。RAC是一个典型的共享所有架构。当然Oracle对sharding的支持也是对原有架构的一种间接实现，所以在12c后期直接做了更大规模的改进，基于RAC也可以做sharding。还有另外两个解决方案也在12c中主推，12cIn-memory和CDB，在很大程度上可以为数据库做一定的资源整合和高效的数据计算，可以算是12c中的标准特性。从12c的特点来看，OLTP方向的提升非常有限，我们开始往AP方向发力。数据库云服务器也是其中之一。主要方向是AP业务，但是由于硬件的巨大优势，TP业务现在也很普遍。所以Oracle的架构模型是share-everything，所以数据库再大也是有一个限度的。毕竟共享的代价就是存储有一定的局限性。包括AP业务在内，只能算是大中型数据，离海量数据还有一定距离。毕竟TP业务100TB的数据库就有点让人担心了，感觉牵一发而动全身。2.MySQLMySQL的特点是开源、轻量。当然，轻量化现在好像也不是很严格。现在查看分支Percona、MariaDB等分支。确实有很多解决方案。MHA是经典的高可用解决方案，现在仍然很流行，社区中也有很多定制版本。这个版本的MySQLProxy系列是目前MySQL社区最为关注的方向。可见大家已经从架构上分离了MySQL的单机负载，尽可能利用集群的力量，而不是单打独斗。因此，市场上会有很多中间件产品，无论是商业的还是开源的，都有一定的适用场景。MySQLGroupReplication和InnoDBCluster算得上是官方发力。现在来看，甲骨文也在不遗余力地进行着很大的改进。很多过去被诟病的问题，现在都在快速修复，这在很大程度上会让原有的社区产品承受一定的压力和风险，同时也会相对拉近用户与正式版的距离。从我的角度来看，我对官方计划持乐观态度。8.0版本发布后，将对MySQL现状产生深远影响。在AP方向，有两个很好的方案，比如MySQL和NewSQL的透明切换，TiDB是一个不错的选择，现在主要是HTAP方案。TiDB作为分布式解决方案，可以直接作为MySQL的slave。当然还有MariaDBColumnStore，它是之前InfiniDB的后期演进，同样值得一试。3.PostgreSQLPG是开源社区的一只小蜜蜂，产出了很多不错的方案。对此，我简单说两点。一种是针对PG的集群方案GP，基于MPP的架构模型可以承载更多的压力和负载。GP的结构与其他的略有不同。
