在国产分布式数据库使用中，大家是否真正使用分布式数据库的“分布式”？

分布式数据库数据分片的特性是在应用过程中重点关注的点。因为分布式数据库的核心就是数据分片，这个最好配合业务规则来设置。当前比较常见的是类似MPP这样的基于hash分布数据，相同的业务数据最好能够基于同样的业务id来分片到同一个分区里。但是OB其实弱化了这一点，从技术上更进一步，愿意接受所有的交易都是分布式交易的设计，反而设计除了更易于用户使用的数据库。不过即便如此，还是建议选择合适的分区键。
举个简单的例子，如果有两张表：客户表和卡表，客户表基于客户号来分片的话，那么卡表里最好也带上客户号然后基于客户号分片。订单表也一样。尽可能多的让同样的分片规则照顾更多的表。

分布式数据库和集中式数据库相比，对于同一交易，分布式数据库大部分情况下必然高于集中式数据库， OceanBase数据库的很多设计如 tablegroup,复制表，二级非模板分区等以及设置主副本的位置 ，其本质就是将 transaction 在同一observer 内完成，最大限度减少remote及分布式事务，尽可能提升单个交易 RT，从而提升集群的吞吐量。所以在做表设计的时候，需要使用好如上的特性。另外 OB在外部使用的场景是做 业务整合，就是使用多租户的能力，仅需要将单租户的所有表固定在单一 zone 内， OceanBase 作为 DBAAS 平台，从而达到降本增效的目的。

您说的后一种  类似mycat和shareding sphere的分库分表路由。这些都是设计上的考虑，已经脱离了数据库本身，即使集中式，全部扫描速度也不是非常好的。

确实很多分布式我们用的是伪分布式，主要其实用的是他的多副本高可用架构，对于真正的分布式，可以采用ob的分布式中间件odp，由他来实现分库分表方案。这种方案的好处是屏蔽底层数据库的依赖，可以随意更换底层数据库。
其实这也算是OB的一个优势吧，可谓：”进可攻、退可守“，用分布式既可以用分布式中间件也可以用自身的分布式功能。又可以像使用传统数据库一样使用分布式数据库（没有过多的分布式执行计划）。这算是一个不错的功能。因为不是所有业务都适合真正的分布式。

观点与你是一致的
从数据库的本质需求有两个:
1.像使用单机数据库一样使用分布式数据库，二级索引很好的解决多维度查询的问题。
这一点背后隐含的意思是，几十年来沉淀的IT系统实现有效的复用，而不是改成所谓的分库分表，开口就说分片之类的。
多少金融机构的开发人员为了使用分库分表的数据库，把存储过程翻译成Java语言，把DB2、Oracle的SQL语法翻译成Mysql语法，对业务开发同学个人来说，这件事情本身毫无意义;对业务系统而言，业务重写是否能否充分测试？增加了业务的风险。
2.利用分区表、复制表很好的解决了扩展性的问题。

• 从性能容量的角度，分布式一定优于单机库的；如果不追求性能的机制，不需要做架构上做更多考虑。
• 对新的系统而言，统一维度分区可以有效降低分布式事务，提升性能。行业里提到存算分离的数据库，其结果是每个事务都跨不同物理机。无论是分库分表的数据库，还是某原生分布式，本质原因是用了国外开源的rocksdb、mysql、postgreSQL等一堆，就将“存算分离”的大旗抗上。

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

分布式指的是将一个大问题拆分成多个小问题逐一解决，再通过协同合作完成某个特定任务。

在计算机领域，分布式思想可用于解决单计算机资源不足的情况，面对一个需要巨大算力解决的问题，无需引入昂贵的超级计算机，而是可以将大问题分成许多小的部分，然后把这些部分分配给多个计算机进行处理，最后把这些计算结果综合起来得到最终的结果。同时，可以通过分布式将一个耗时巨大的问题分成多部分同步进行计算，从而节省计算时间，大大提高了计算效率。因此分布式计算技术广泛应用于高性能应用架构中，用于提高系统整体计算能力、提高任务执行效率。

在工业互联网、移动互联网等领域，云端与各个边端设备的关系，也是一种典型的分布式关系。以往通常将边端的设备作为采集者，上传数据至云端再进行统一的处理，这种方式存在带宽消耗大、数据隐私性差、计算延迟大的问题。因此，可以通过引入边缘计算技术，将计算能力下沉到边缘侧，将边缘节点作为一种分布式计算节点，就地处理数据，只将计算结果上传。让数据处理更靠近源，从而缩短延迟时间、减少网络流量和大数据瓶颈，同时可以带来更好的安全与数据保护特性。