以OceanBase数据库为例,假设集群有3个zone,在创建租户时,优先级选择时,可以选择所有主副本都在一个ZONE,也可以将主副本均衡的分布在多个ZONE内,前者其实也就是是集中式,后者才是“分布式”数据库。
真正是的“分布式数据库”如果适配完美将会大大提高系统的吞吐量,如果适配较差可能会出现性能比集中式更差的情况,所以想了解下大家在分布式数据库设计的时候采用了什么方式,依据哪些因素,谢谢。
分布式数据库数据分片的特性是在应用过程中重点关注的点。因为分布式数据库的核心就是数据分片,这个最好配合业务规则来设置。当前比较常见的是类似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.利用分区表、复制表很好的解决了扩展性的问题。
分布式指的是将一个大问题拆分成多个小问题逐一解决,再通过协同合作完成某个特定任务。
在计算机领域,分布式思想可用于解决单计算机资源不足的情况,面对一个需要巨大算力解决的问题,无需引入昂贵的超级计算机,而是可以将大问题分成许多小的部分,然后把这些部分分配给多个计算机进行处理,最后把这些计算结果综合起来得到最终的结果。同时,可以通过分布式将一个耗时巨大的问题分成多部分同步进行计算,从而节省计算时间,大大提高了计算效率。因此分布式计算技术广泛应用于高性能应用架构中,用于提高系统整体计算能力、提高任务执行效率。
在工业互联网、移动互联网等领域,云端与各个边端设备的关系,也是一种典型的分布式关系。以往通常将边端的设备作为采集者,上传数据至云端再进行统一的处理,这种方式存在带宽消耗大、数据隐私性差、计算延迟大的问题。因此,可以通过引入边缘计算技术,将计算能力下沉到边缘侧,将边缘节点作为一种分布式计算节点,就地处理数据,只将计算结果上传。让数据处理更靠近源,从而缩短延迟时间、减少网络流量和大数据瓶颈,同时可以带来更好的安全与数据保护特性。
收起在设计分布式数据库时,需要考虑以下因素:
在选择分布式数据库时,需要根据具体的业务需求和数据规模来进行选择。如果数据规模较小,可以选择集中式数据库;如果数据规模较大,需要考虑分布式数据库。同时,还需要考虑数据库的性能、可用性、安全性等方面的因素。