集中式和分布式，是数据库两个大的架构类型，两者都有各自适应场景。从过去二三十年发展来看，集中式架构很好地解决了金融机构的场景问题，从技术角度来讲绝大多数场景并没有因能力不足而选择分布式架构的必要。这里更多地是需要考虑多种因素，来做这样的选择。1.业务诉求随着金融...
评估可行性，可从多个角度并遵循一定步骤，例如下：1.理论基础听取厂商的理论讲述，从原理上了解产品能力。必要时，可引入外脑帮助决策。2.功能评测可要求厂商提供基础功能测试报告，同时根据自有场景需求，挑选有代表性场景进行评测。3.案例考察考察与自有业务类似的其他客户进行考察...
Oracle的AP分析能力是比较强的，这主要受益于其自身强大的优化器能力。如去O的话，目标库是否具备同等分析能力存疑，是需要做评测的。如遇到数据库自身分析能力不足问题，可考虑使用组合方案，如TP+AP的模式或引入大数据技术栈来解决。...
国产数据库在库内计算（存储过程、函数）及特性能力（如视图），较Oracle数据库还存在一定差距。特别是采取分布式架构的国产数据库，差距更为明显。从实际推动工作上看，也是两种策略：1.尽量选择兼容性产品，这样代价相对较小2.简化数据库应用，将上述能力在应用层解决，数据库只做CRUD...
我的建议是存在NOSQL类型数据库，便于未来扩展，也无需考虑事务一致性。比如mongodb或者clickhouse 都是不错的选择。
1在数据库底层建立统一的分布式存储系统，数据库实例写下来的数据同时写多副本。这些副本可以分布在多个数据中心上。在数据库实例端，可以做多个集群多实例方案，或者也可以做快速服务切换方案。 MYSQL+存储2在数据库底层建立统一的KV （目前用RockDB等）来解决数据文件跨节点，跨数...
国产化的确是目前的趋势。也的确存在很多的问题。对数据库的选择上我觉得不仅仅是要从国产数据库对标来选择。还要根据实际的业务情况。软件开发对数据库的支持情况等多方面来参考选择。从大的功能上来说。可能都没有问题。但是在很多细节上却还是有一定欠缺的。这个可能...
邮储核心迁移到openGauss，中信核心迁移goldendb，民生核心迁移到分布式的mysql。。。这样的案例越来越多。大家用的技术还都不太一样。至少给了大家去O的信心。
关于选型标准，目前没有统一国家、行业标准，有条件的企业都在做自有标准。按照之前的工作，需梳理出选型测试的众多评估维度及细化的指标。这里是存在不小的工作量。这里可参考我近期发的一些内容，如：https://cloud.tencent.com/developer/article/1811292...
