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

跑分代表部分技术能力，但不代表全部，理性看待跑分数据。针对用户更为有价值的是结合业务场景的跑分结果。TPC-C 可作为准入参考，达到一定数值即可，不用追求更高。

1.对于核心的系统，需考虑双发机制，即并行两套系统运行，可保证随时有后备系统可选择。2.对于非核心系统，可考虑在异构数据库同步方案，即保证数据不丢失有备用数据库可用。3.从应用角度来讲，弱化对数据库的依赖，尽量使用通用方法，有助于回切。... (more)

对于中小型系统而言，建议优先考虑对Oracle兼容性较高的产品，这样迁移、改造的工作量较小、成功率高。

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

解决上述问题有几个思路：1.产品层面有些分布式数据库产品，提供“自动分布式”能力，即可以实现数据自主分片，不再需要人为干预。这样在结构设计无需做太多修改。针对语句方面，也可以免改造或低改造完成迁移。当然这种方式还是要看业务复杂度，很难做到完全规避因引入分布式带来的... (more)

总结来说，是异构数据库间迁移的问题1.提供常规的全量及增量数据迁移能力，这对于有效缩短时间窗口有益。目前已有很多厂商提供此类能力。但需要注意的是，从集中式架构到分布式架构还可以；反之仍有一定局限。2.提供全量及增量数据对比能力，满足对数据一致性的检验能力，这对于实施... (more)

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

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