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