通用化的分布式，是比较理想的状态。在部分业务场景上可行，但在很多场景仍有其局限。企业还是要根据自身特点选择不同的分布式策略。

1.所谓单库查询，是指语句查询可以精确到某个分片中，这样的效率最高。从事务处理角度来看，能否限制在某个分片内（即本地事务），也是效率最高的。2.具体的分片策略没有一定之规，一方面可选择业务的共性部分作为分片键，一方面数据量不大又参与到业务中的，也可考虑全局表（或广播表）的方式... (more)

从Oracle迁移到国产数据库的选择路线：1.迁移目的：首选需要关注的是迁移目的，是为了解决性能、承载量，还是为了满足自主可控。针对前者的话，考虑分布式架构更多；后者，则更倾向于考虑国产集中式架构产品。2.应用适配：次之要考虑应用适配问题。如果应用对Oracle有较深度的依赖，则需优... (more)

核心系统的数据库选型，较周边系统有其特殊性。一是业务逻辑相对固定，且经过长时间优化；二是重要级别高，对稳定性、可用性有极高要求；三是核心整体架构有向单元化方向演进趋势。针对上述问题，在分布式数据库选择上，有如下重点和难点：重点稳定性、可用性，通过测试和上线并行来验证自... (more)

关于国产分布式数据库选型，之前社区已有较多讨论。针对医疗行业，之前经验不多，但有点建议。医疗行业的业务系统，比较依赖于第三方ISV，在对于国产分布式数据库的选择上，需充分考虑第三方对接问题。从长远角度来看，应保留一定前瞻性，保持未来的灵活性。... (more)

多租户能力，是对分布式数据库的一类需求，类似之前Oracle的PDB能力。但目前国内分布式数据厂商，针对此能力的实现差异较大，能力层次不起。建议供如下角度进行考虑：1.资源隔离基于计算、存储资源，可提供独立的QoS保障。有些产品（如部分基于分库分表的产品），可以对立配置计算节点，虽然... (more)

分布式数据库在备份上，通常有自己的工具完成。数据脱敏，不属于数据库的核心功能，很多数据库产品是没有的。可考虑外部第三方厂商产品支持。

确实如问题所提到的，这两种类型数据库差异较大。从中小规模城商行角度出发，可优先有以下因素考虑：1.运维技术栈是否具备一定基础？毕竟引入一个新的平台，涉及到管理运维投入是较大的。如果可复用之前的技术栈，则难度降低很多。这方面，分布式中间件形态的产品更有优势。2.开发技术... (more)

原生分布式和分布式中间件，都有其事务一致性保障问题。原理上，大多是通过两阶段提交方式进行，但其实现的机理有所不同。从之前使用体验来看，事务一致性一般均可实现，但对于全局可见性（如MVCC），各家能力层次不起。需要针对具体产品，有针对性地进行测试、验证。... (more)