背锅我们是被迫的
数据库问题‘触发’越来越频繁了，开发、业务人员也一直抱怨数据库不行，作为运维人员，天天各种处理问题，还被其他部门喷，有问题矛头全部指向数据库。刚上任的部门领导整天也是压力山大，内部会议分析了当前的情况，最终解决方案是架构变更。当前的生产系统运行在Mysql上，从开始的保留半年的数据，到现在缩减到保留不足三个月的数据，全量数据实时同步到Hadoop，随着业务的发展，Mysql和Hadoop的数据量都越来越多，系统已经不堪重负了。
架构替换选型开始
综合考虑数据库的性能和成本，决定使用Oracle/PostgreSql+ClickHouse/GreenPlum的架构
当前公司的运维人员普遍对Oracle、Mysql、Hadoop比较熟悉。综合考虑数据库的软件成本和人员的学习成本。领导倾向于使用Oracle+ClickHouse的方案，简单的测试后性能确实提升了不少，由于使用ClickHouse需要对数仓的表进行宽表改造，表改造方案需要的人力和时间太长，故该方案一直卡在宽表改造阶段。
选型重回对比阶段
一次偶然的机会，领导接触到了YMatrix数据库。据说是一款同时支持在线事务处理（OLTP）、在线分析处理（OLAP）和物联网时序应用的超融合型分布式国产数据库产品，兼容PostgreSQL/Greenplum协议。领导说，现在方案还未实施，要不你抽时间测试一下。ClickHouse实施过程还不知道什么时候能开始，如果有一种新架构能满足现在的需求（性能成本综合考虑），对我们来说是一件好事。通过对YMatrix的慢慢了解，我感觉这个架构正是我们期盼出现的架构。话不多说，直接对比测试，看效果。
架构框架对比
整体架构来对比，YMatrix架构更简洁，融合了生产库和数仓，对于整个数据流动、数据存储、运维、开发来说，成本大大的降低了。
架构要求对比
当前架构系统需要满足以下要求：
• 高可用
• 高吞吐
• 高性能
• 支持事务
• 大数据生态友好
• 集群的扩展性好
两种架构基于架构要求对比：
高可用
对于两种架构而言。Oracle Rac是一种高可用架构，ClickHouse通过副本实现高可用；YMatrix通过primary和mirror实现高可用。两种架构都是可以保证数据库系统的高可用性
高吞吐
Oracle作为OLTP数据库的佼佼者，能满足高吞吐的需求，ClickHouse作为一个纯OLAP数据库，在吞吐方面需避免出现高吞吐情况，官方建议每秒最多查询100次，更新和插入也尽量使用批的方式进行。Oracle和ClicHouse的组合架构可以忽略掉ClickHouse的短板。YMatrix支持高并发连接下的毫秒级OLTP业务的增、删、改、查操作。支持上千直连并发，借助连接池可以到上万并发。
高性能
两种架构都属于高性能架构。Oracle常用的有星型模型、雪花模型等，单表、多表关联小数据量查询性能优异，ClickHouse单表查询效率快，多表关联性能差，主要使用场景是大宽表，对于数据分析而言灵活性差。YMatrix支持大宽表、星型模型、雪花模型等，不管是单表查询还是多表多表关联性能都极佳。当前的报表业务场景，多表关联分析占主导，前期的Oracle+ClickHouse方案就卡在宽表改造阶段。
支持事务
Oracle和YMatrix都是支持事务的，ClickHouse不支持事务。Oracle+ClickHouse组合架构，需借助Oracle支持事务的能力来保证数据的质量，然后定时同步到ClickHouse。
大数据生态的友好性
ClickHouse数据模型单一化，对相对固定的场景，需将业务表改造成宽表，效率快的同时极大的损失了数据分析灵活性。尽管业务线的用户对此感知并不强，但是哪有什么岁月静好，不过是有人替你负重前行。数据模型要多样化、具备灵活性，才大数据分析场景的需求形态。例如常用的星型模型、雪花模型不仅灵活还不损失性能，这种模式才能让数据分析既轻松又畅快。YMatrix数据模型多样化，不管是宽表的单表查询或者多表关联星型模型、雪花模型都有很好的效率，数据分析灵活。从管理、分析与应用长远来看，YMatrix更适合做大数据生态建设。
集群扩展性
ClickHouse和YMatrix都支持集群的扩容。ClickHouse需要在所主机修改配置文件，因此需要停机扩容。数据无法自动均衡，需要在新节点手动创建本地表，修改节点的权重，让新数据优先写新节点，当新节点数据量与旧节点差不多时，把权重调一致。YMatrix支持通过UI界面在线扩容，操作简单，可以自定义数据重分布时间，将原数据重新分布到所有节点。
技术发展趋势
话说天下大势，合久必分，分久必合，数据库的发展也遵从这个规律，毕竟业务的发展需求是不确定的。数据库从1960年起源到现在。从最开始的ONE到现在的ONE TO ALL，未来引领发展趋势必将是ALL IN ONE，伴随新需求的是专用数据库，专用数据库不断的融合进ALL IN ONE。数据库发展到现在国内已经呈现了百花齐放的状态，这个时候需要ALL IN ONE来解决一个系统中多种数据库并存带来的管理和使用上的不便。ClickHouse是ONE TO ALL的衍生品，不符合未来发展的趋势。YMatrix紧随未来发展的趋势，最先提出超融合和ALL IN ONE的概念，数据库的设计也是基于ALL IN ONE的思想。综合技术考虑，用未来的技术解决现在以至未来几年的问题才是王道。
成本对比
开发成本
相对于Oracle+ClickHouse技术架构，使用YMatrix，开发工程师无需在不同的数据源之间来回切换，无需把数据从不同数据源拉到内存中进行复杂计算，无需重新发明轮子而借助强大的SQL进行业务数据处理，实现数据独立性、应用层和数据层的解耦，大幅提升开发效率。特别在产品快速迭代，需要频繁增减字段的时候，更加高效。
运维成本
运维人员只需要维护一种数据库，无需将精力分摊到多种数据库上，大幅降低数据处理核心架构的复杂性、提升运维的效率。
软硬件成本及数据管理成本
避免采购众多的单体产品，大幅降低产品投入；避免数据在不同系统间冗余存储，大幅降低存储空间投入；避免复杂的数据流动，大幅减低数据管理投入；超融合架构大幅降低了运维投入。
拨开云雾见青天
综合对比YMatrix架构与Oracle+ClickHouse架构，领导决定对两种架构做一个业务开发上的对比。部署Oracle+ClickHouse数据库后，开发人员测试反馈，比之前的架构效率快了一些，但是表数据同步改造方面比较繁琐。对业务开发而言，没有很明显的改变。部署YMatrix架构后，开发人员在测试的当天，跑来问我们采用的什么架构，可以做到多个数据库同时接入，数据质量验证也没问题，效率比之前有了很大的提升，以后是不是就定下来使用这套架构了？我反问道：你还有更好的推荐吗？
终于完成了这次架构选型改造，接下来就是数据和业务迁移了，未来很久都不在为数据库选型犯愁了。
