• 关于 数据库分表中间件 的搜索结果

问题

是分库分表好还是分区好?

mq4096 2019-12-01 21:54:44 3755 浏览量 回答数 0

问题

在关系型数据库的分库分表方面,有没有好的分库分表的中间件和成熟的方案,对已有系统的改造,建议

游客qvwtl6zpaqkjw 2020-06-08 17:15:24 0 浏览量 回答数 0

回答

高并发,大数据是一个笼统的概念,实际应用场景中药考虑是有多大的并发,读写压力有多大,磁盘IO有多大,根据具体的情况在系统架构上会有很多的不同。通用架构分层做法如下:Requests --> load balancer --> Web Server Cluster --> Middlerware --> DB Cluster根据具体的并发压力,需要有针对性的进行系统扩展。load balancer层:load balancer进行请求转发,根据具体的请求数量,需要考虑使用硬件或软件。通常情况下硬件load balancer性能远高于软件load balancer,软件实现中ngnix性能远高于Apache。当然硬件load balancer价格也会非常昂贵,需要专业维护。如F5, Redware.考虑到页面数据是否可以缓存,需要增加CDN.如淘宝前端页面会直接从CDN读取,12306 80%的访问请求由CDN处理。根据CDN的策略,带宽大小,并发量大小及业务重要程度,需要考虑多机房部署,减轻带宽和load balancer压力。Web Server clusterWeb server可以使用开源的Tomcat, jBoss等,也可以使用商业的WebSphere, WebLogic。区别是开源需要自己创建、维护cluster状态,商业软件会极大的简化cluster创建和维护。稳定,易于维护的Web Server应用服务器是基础,性能则有应用实现决定。应用需要考虑的是线程并发,查询优化,缓存使用,通信代价。应用完成后根据单台应用服务器的实际处理能力,横向和纵向扩展Web Server cluster. 横向扩展:增加Web Server数量(提升能力理论上无上限)纵向扩展:增加硬件机器性能,优化应用性能,提升单台Server性能(提升能力有限,受限于硬件资源)Middlerware当涉及到分布式环境,需要使用中间件来保证集群一致性。Session中间件 :如果业务是无状态,可以直接在load balancer按照轮询或权重策略转发。无需session处理,性能会高很多。如果业务有状态:1)load balancer使用sticky session策略,由同一台server进行后续有状态服务,session无需处理。但如果server失败,转由其他server服务时,需要重新登录。测试需要client有重新登录机制,否则用户体验不好。2)session复制。session复制需要由session中间件进行处理,保证整个集群共享session,会带来额外性能损耗。消息中间件 :分布式系统之间进行数据同步和唤醒,多个业务系统同步,需要使用消息中间件进行时效性保证。远程调用中间件: 远程调用保证分布式系统中高效的数据交换。数据库中间件: 访问数据库层,如果数据库进行了分库分表操作,需要再数据库中间件中进行操作封装。缓存中间件: 缓存数据库数据和业务计算数据。DB Cluster关系数据库为保证数据库稳定性,会考虑创建主备数据库,多个主备数据构成数据库cluster,当主库出现失败时,自动进行主备切换。有多个数据库的时候,根据读写频率进行读写分离。数据量大的时候,进行分表操作。

ericwz 2019-12-02 01:31:26 0 浏览量 回答数 0

海外云虚拟主机包年25元/月起

海外独享虚拟主机全面上线,助力构建海外网站,提升公司国际形象;全球有效覆盖,超高性价比;建站入门首选,助力出口,适合跨境贸易企业。

问题

大表怎么优化?某个表有近千万数据,CRUD比较慢,如何优化?分库分表了是怎么做的?

剑曼红尘 2020-03-31 11:31:42 0 浏览量 回答数 1

问题

[@饭娱咖啡][¥20]数据库分库

阿珂2018 2019-12-01 20:28:23 576 浏览量 回答数 1

问题

为什么要分库分表(设计高并发系统的时候,数据库层面该如何设计)?【Java问答】41期

剑曼红尘 2020-06-19 13:47:21 0 浏览量 回答数 0

回答

我们底层数据库操作驱动使用PHP封装过,直接就支持分表分库和主从分离操作,这个用数据库中间件就可以。自己用PHP封装也不复杂

小咖秀 2019-12-02 01:39:50 0 浏览量 回答数 0

回答

传统的mysql没法处理海量数据的,如果你一定要使用mysql的话,可以考虑分库分表,比如将不同的同表hash到不同的数据库实例上,同一个表的数据hash到不同的数据库上,自己做一般比较麻烦需要考虑很多东西,你可以尝试一下阿里巴巴开源的分布式数据库服务中间件,比如cobar

名字不能长 2019-12-01 23:33:00 0 浏览量 回答数 0

回答

阿里为双11做了大量的优化工作,包括自己研发扩展的中间件、JDK、数据库、缓存等技术方案。阿里巴巴可以说是国内Java技术最好的公司,目前是JCP委员会唯一的中国公司。1、阿里自己有优化的JDK版本2、阿里为了电商服务器专门优化开发了JVM虚拟机,包括内存分配和垃圾回收3、除了大规模的服务器集群,阿里还自己还定制了MySQL数据库、缓存、MQ等4、阿里自己研发的数据库中间件,分库分表工具,也开源了。都是一步一步解决实际问题积累的技术实力,遇到问题,解决问题,积累研发扩展升级。

徐雷frank 2019-12-02 01:47:30 0 浏览量 回答数 0

回答

ReOceanbase与DRDS的关系与使用场景的区别? oceanbase是兼容mysql而不同于mysql的分布式数据库。而DRDS是是mysql的分库分表的中间件,其后端数据库是mysql.而DRDS相当于数据中间层。

sangshy 2019-12-02 02:13:07 0 浏览量 回答数 0

回答

当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下: 限定数据的范围: 务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们可以控制在一个月的范围内。;读/写分离: 经典的数据库拆分方案,主库负责写,从库负责读;缓存: 使用MySQL的缓存,另外对重量级、更新少的数据可以考虑使用应用级别的缓存; 还有就是通过分库分表的方式进行优化,主要有垂直分表和水平分表 垂直分区: 根据数据库里面数据表的相关性进行拆分。 例如,用户表中既有用户的登录信息又有用户的基本信息,可以将用户表拆分成两个单独的表,甚至放到单独的库做分库。 简单来说垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表。 如下图所示,这样来说大家应该就更容易理解了。 垂直拆分的优点: 可以使得行数据变小,在查询时减少读取的Block数,减少I/O次数。此外,垂直分区可以简化表的结构,易于维护。 垂直拆分的缺点: 主键会出现冗余,需要管理冗余列,并会引起Join操作,可以通过在应用层进行Join来解决。此外,垂直分区会让事务变得更加复杂; 垂直分表 把主键和一些列放在一个表,然后把主键和另外的列放在另一个表中 适用场景 1、如果一个表中某些列常用,另外一些列不常用 2、可以使数据行变小,一个数据页能存储更多数据,查询时减少I/O次数 缺点 有些分表的策略基于应用层的逻辑算法,一旦逻辑算法改变,整个分表逻辑都会改变,扩展性较差 对于应用层来说,逻辑算法增加开发成本 管理冗余列,查询所有数据需要join操作 水平分区: 保持数据表结构不变,通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中,达到了分布式的目的。 水平拆分可以支撑非常大的数据量。 水平拆分是指数据表行的拆分,表的行数超过200万行时,就会变慢,这时可以把一张的表的数据拆成多张表来存放。举个例子:我们可以将用户信息表拆分成多个用户信息表,这样就可以避免单一表数据量过大对性能造成影响。 水品拆分可以支持非常大的数据量。需要注意的一点是:分表仅仅是解决了单一表数据过大的问题,但由于表的数据还是在同一台机器上,其实对于提升MySQL并发能力没有什么意义,所以 水平拆分最好分库 。 水平拆分能够 支持非常大的数据量存储,应用端改造也少,但 分片事务难以解决 ,跨界点Join性能较差,逻辑复杂。 《Java工程师修炼之道》的作者推荐 尽量不要对数据进行分片,因为拆分会带来逻辑、部署、运维的各种复杂度 ,一般的数据表在优化得当的情况下支撑千万以下的数据量是没有太大问题的。如果实在要分片,尽量选择客户端分片架构,这样可以减少一次和中间件的网络I/O。 水平分表: 表很大,分割后可以降低在查询时需要读的数据和索引的页数,同时也降低了索引的层数,提高查询次数 适用场景 1、表中的数据本身就有独立性,例如表中分表记录各个地区的数据或者不同时期的数据,特别是有些数据常用,有些不常用。 2、需要把数据存放在多个介质上。 水平切分的缺点 1、给应用增加复杂度,通常查询时需要多个表名,查询所有数据都需UNION操作 2、在许多数据库应用中,这种复杂度会超过它带来的优点,查询时会增加读一个索引层的磁盘次数 下面补充一下数据库分片的两种常见方案: 客户端代理: 分片逻辑在应用端,封装在jar包中,通过修改或者封装JDBC层来实现。 当当网的 Sharding-JDBC 、阿里的TDDL是两种比较常用的实现。 中间件代理: 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 我们现在谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。 分库分表后面临的问题 事务支持 分库分表后,就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价; 如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。 跨库join 只要是进行切分,跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。 分库分表方案产品 跨节点的count,order by,group by以及聚合函数问题 这些是一类问题,因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案:与解决跨节点join问题的类似,分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行,因此很多时候它的速度要比单一大表快很多。但如果结果集很大,对应用程序内存的消耗是一个问题。 数据迁移,容量规划,扩容等问题 来自淘宝综合业务平台团队,它利用对2的倍数取余具有向前兼容的特性(如对4取余得1的数对2取余也是1)来分配数据,避免了行级别的数据迁移,但是依然需要进行表级别的迁移,同时对扩容规模和分表数量都有限制。总得来说,这些方案都不是十分的理想,多多少少都存在一些缺点,这也从一个侧面反映出了Sharding扩容的难度。 ID问题 一旦数据库被切分到多个物理结点上,我们将不能再依赖数据库自身的主键生成机制。一方面,某个分区数据库自生成的ID无法保证在全局上是唯一的;另一方面,应用程序在插入数据之前需要先获得ID,以便进行SQL路由. 一些常见的主键生成策略

剑曼红尘 2020-03-31 11:34:39 0 浏览量 回答数 0

问题

淘宝这么多数据为什么还这么快

福利达人 2019-12-01 21:27:08 2251 浏览量 回答数 0

回答

一、数据库瓶颈 不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是,可用数据库连接少甚至无连接可用。接下来就可以想象了吧(并发量、吞吐量、崩溃)。 1、IO瓶颈 第一种:磁盘读IO瓶颈,热点数据太多,数据库缓存放不下,每次查询时会产生大量的IO,降低查询速度 -> 分库和垂直分表。 第二种:网络IO瓶颈,请求的数据太多,网络带宽不够 -> 分库。 2、CPU瓶颈 第一种:SQL问题,如SQL中包含join,group by,order by,非索引字段条件查询等,增加CPU运算的操作 -> SQL优化,建立合适的索引,在业务Service层进行业务计算。 第二种:单表数据量太大,查询时扫描的行太多,SQL效率低,CPU率先出现瓶颈 -> 水平分表。 二、分库分表 1、水平分库 概念:以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。 结果: 每个库的结构都一样; 每个库的数据都不一样,没有交集; 所有库的并集是全量数据; 场景:系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库。 分析:库多了,io和cpu的压力自然可以成倍缓解。 2、水平分表 概念:以字段为依据,按照一定策略(hash、range等),将一个表中的数据拆分到多个表中。 结果: 每个表的结构都一样; 每个表的数据都不一样,没有交集; 所有表的并集是全量数据; 场景:系统绝对并发量并没有上来,只是单表的数据量太多,影响了SQL效率,加重了CPU负担,以至于成为瓶颈。推荐:一次SQL查询优化原理分析 分析:表的数据量少了,单次SQL执行效率高,自然减轻了CPU的负担。 3、垂直分库 概念:以表为依据,按照业务归属不同,将不同的表拆分到不同的库中。 结果: 每个库的结构都不一样; 每个库的数据也不一样,没有交集; 所有库的并集是全量数据; 场景:系统绝对并发量上来了,并且可以抽象出单独的业务模块。 分析:到这一步,基本上就可以服务化了。例如,随着业务的发展一些公用的配置表、字典表等越来越多,这时可以将这些表拆到单独的库中,甚至可以服务化。再有,随着业务的发展孵化出了一套业务模式,这时可以将相关的表拆到单独的库中,甚至可以服务化。 4、垂直分表 概念:以字段为依据,按照字段的活跃性,将表中字段拆到不同的表(主表和扩展表)中。 结果: 每个表的结构都不一样; 每个表的数据也不一样,一般来说,每个表的字段至少有一列交集,一般是主键,用于关联数据; 所有表的并集是全量数据; 场景:系统绝对并发量并没有上来,表的记录并不多,但是字段多,并且热点数据和非热点数据在一起,单行数据所需的存储空间较大。以至于数据库缓存的数据行减少,查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈。 分析:可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来,进而减少了随机读IO。拆了之后,要想获得全部数据就需要关联两个表来取数据。 但记住,千万别用join,因为join不仅会增加CPU负担并且会讲两个表耦合在一起(必须在一个数据库实例上)。关联数据,应该在业务Service层做文章,分别获取主表和扩展表数据然后用关联字段关联得到全部数据。 三、分库分表工具 sharding-sphere:jar,前身是sharding-jdbc; TDDL:jar,Taobao Distribute Data Layer; Mycat:中间件。 注:工具的利弊,请自行调研,官网和社区优先。 四、分库分表步骤 根据容量(当前容量和增长量)评估分库或分表个数 -> 选key(均匀)-> 分表规则(hash或range等)-> 执行(一般双写)-> 扩容问题(尽量减少数据的移动)。 扩展:MySQL:分库分表与分区的区别和思考 五、分库分表问题 1、非partition key的查询问题 基于水平分库分表,拆分策略为常用的hash法。 端上除了partition key只有一个非partition key作为条件查询 映射法 基因法 注:写入时,基因法生成user_id,如图。关于xbit基因,例如要分8张表,23=8,故x取3,即3bit基因。根据user_id查询时可直接取模路由到对应的分库或分表。 根据user_name查询时,先通过user_name_code生成函数生成user_name_code再对其取模路由到对应的分库或分表。id生成常用snowflake算法。 端上除了partition key不止一个非partition key作为条件查询 映射法 冗余法 注:按照order_id或buyer_id查询时路由到db_o_buyer库中,按照seller_id查询时路由到db_o_seller库中。感觉有点本末倒置!有其他好的办法吗?改变技术栈呢? 后台除了partition key还有各种非partition key组合条件查询 NoSQL法 冗余法 2、非partition key跨库跨表分页查询问题 基于水平分库分表,拆分策略为常用的hash法。 注:用NoSQL法解决(ES等)。 3、扩容问题 基于水平分库分表,拆分策略为常用的hash法。 水平扩容库(升级从库法) 注:扩容是成倍的。 水平扩容表(双写迁移法) 第一步:(同步双写)修改应用配置和代码,加上双写,部署; 第二步:(同步双写)将老库中的老数据复制到新库中; 第三步:(同步双写)以老库为准校对新库中的老数据; 第四步:(同步双写)修改应用配置和代码,去掉双写,部署; 注:双写是通用方案。 六、分库分表总结 分库分表,首先得知道瓶颈在哪里,然后才能合理地拆分(分库还是分表?水平还是垂直?分几个?)。且不可为了分库分表而拆分。 选key很重要,既要考虑到拆分均匀,也要考虑到非partition key的查询。 只要能满足需求,拆分规则越简单越好。 七、分库分表示例 示例GitHub地址:https://github.com/littlecharacter4s/study-sharding 来源:cnblogs.com/littlecharacter/p/9342129.html 俩元

AA大大官 2020-03-31 12:45:48 0 浏览量 回答数 0

回答

1,分库分表中间件可以参考Cobar或者MyCat。2,分库建立好后,会涉及到一个数据迁移的问题,可以参考Otter&Cannel

断桥梅 2019-12-02 02:14:21 0 浏览量 回答数 0

回答

log4j配置和hibernate没关系。查询慢要先从数据库本身下手调优。 数据库里是否有和查询sql条件有匹配的索引,没有的话建索引。如果是写入读取都很大的库,做读写分离。数据量极大(亿以上)的情况下,建议考虑分表。如果是多点高可用方式部署的系统,代码里加缓存要使用redismemcached这样的中间件。

哈哈哈1988 2019-12-02 01:57:06 0 浏览量 回答数 0

问题

drds 中间件 后端可以是自建mysql吗?

mindaicn 2019-12-01 20:14:28 1402 浏览量 回答数 1

问题

淘宝用了多少台服务器?那么多mysql怎么储存的?

福利达人 2019-12-01 21:27:09 4550 浏览量 回答数 0

回答

组件来看,分为以下几类: 1. 服务注册发现中心 2. 配置中心 3. 服务网关 4. 断路器 5. 服务消息总线 6. 服务监控 7. 负载均衡 8. 服务链路追踪 9. 服务调用组件 至于具体的应用,各家公司都有不一样的,SpringCloud套装、谷歌、阿里系、携程等等 以上是基础的组件。微服务,还要学习缓存中间件、消息中间件、各种数据库、分库分表、高性能并发编程等等

huc_逆天 2019-12-02 03:11:16 0 浏览量 回答数 0

问题

名词解释都有哪些?

猫饭先生 2019-12-01 21:19:24 915 浏览量 回答数 0

问题

【精品锦集】中间件热门回答01

问问小秘 2019-12-01 19:51:42 75 浏览量 回答数 0

回答

1、物理上用PCIe SSD搭建固态存储。2、利用MySQL主从复制机制和中间件MySQL-Proxy/Qihoo360 Atlas/Alibaba Cobar/TDDL/Amoeba和HAProxy/LVS实现读写分离和负载均衡。3、按照业务逻辑合理分区、分表、分库。4、Redis、Memcached做数据库缓存。

落地花开啦 2019-12-02 01:50:52 0 浏览量 回答数 0

回答

1、物理上用PCIe SSD搭建固态存储。2、利用MySQL主从复制机制和中间件MySQL-Proxy/Qihoo360 Atlas/Alibaba Cobar/TDDL/Amoeba和HAProxy/LVS实现读写分离和负载均衡。3、按照业务逻辑合理分区、分表、分库。4、Redis、Memcached做数据库缓存。

小旋风柴进 2019-12-02 02:04:57 0 浏览量 回答数 0

回答

阿里巴巴可以说是国内Java技术最好的公司,目前是JCP委员会唯一的中国公司。1、阿里自己有优化的JDK版本2、阿里为了电商服务器专门优化开发了JVM虚拟机,包括内存分配和垃圾回收3、除了大规模的服务器集群,阿里还自己还定制了MySQL数据库、缓存、MQ等4、阿里自己研发的数据库中间件,分库分表工具,也开源了。都是一步一步解决实际问题积累的技术实力,遇到问题,解决问题,积累研发扩展升级。

徐雷frank 2019-12-02 01:46:42 0 浏览量 回答数 0

问题

如何设计才可以让系统从未分库分表动态切换到分库分表上?【Java问答】42期

剑曼红尘 2020-06-22 11:05:45 34 浏览量 回答数 1

问题

DRDS是什么?

猫饭先生 2019-12-01 21:19:21 1421 浏览量 回答数 0

回答

一定要先打好java语法和原理基础,这里推荐think in java。这里java基础包含了常用的集合类如hashMap,ArrayList,ConcurrentHashMap等等这样的源码。还要线程,并发相关的类,主要是concurrent包下面的类。语法ok了就可以继续深入学习JVM的内容了,推荐升入理解JAVA虚拟机然后就是各种中间件,要深入到原理级别,最好每个都买本书系统性的学习。如果redis要具体到有哪些数据类型,持久化方式,一致性hash怎么做、迁移怎么做、和其他同类型中间件的对比,各种场景适合什么。现在互联网公司动不动就是什么分布式,毕竟中国人口红利多,那就肯定是各种分布式的内容要了解,怎么分库分表,怎么拆分业务,用什么分布式服务。

lubby 2019-12-02 01:57:27 0 浏览量 回答数 0

回答

看了你的问题,比较复杂,导致写入并发低的原因很多,可以尝试几种解决办法:1、你的8-9个表都在单个数据库服务器上?如果是的话,写入瓶颈可能在单带IO上。2、同时写入多个表,如果存在外键约束关系,也可能导致写入验证,比如非空判断,或者唯一性约束都会降低写入性能3、确定单台服务器的配置,是否可以通过硬件提升写入并发请求4、如果不行可以考虑分库分表,使用阿里开源的中间件或者mycat5、尝试删除约束关系

徐雷frank 2019-12-02 01:47:19 0 浏览量 回答数 0

回答

当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下: 限定数据的范围 务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们可以控制在一个月的范围内。 读/写分离 经典的数据库拆分方案,主库负责写,从库负责读。 垂直分区 根据数据库里面数据表的相关性进行拆分。例如,用户表中既有用户的登录信息又有用户的基本信息,可以将用户表拆分成两个单独的表,甚至放到单独的库做分库。 简单来说垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表。如下图所示,这样来说大家应该就更容易理解了。 垂直拆分的优点: 可以使得列数据变小,在查询时减少读取的Block数,减少I/O次数。此外,垂直分区可以简化表的结构,易于维护。 垂直拆分的缺点:主键会出现冗余,需要管理冗余列,并会引起Join操作,可以通过在应用层进行Join来解决。此外,垂直分区会让事务变得更加复杂; 水平分区 保持数据表结构不变,通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中,达到了分布式的目的。水平拆分可以支撑非常大的数据量。 水平拆分是指数据表行的拆分,表的行数超过200万行时,就会变慢,这时可以把一张的表的数据拆成多张表来存放。 举个例子:我们可以将用户信息表拆分成多个用户信息表,这样就可以避免单一表数据量过大对性能造成影响。 水平拆分可以支持非常大的数据量。需要注意的一点是:分表仅仅是解决了单一表数据过大的问题,但由于表的数据还是在同一台机器上,其实对于提升MySQL并发能力没有什么意义,所以水平拆分最好分库。 水平拆分能够支持非常大的数据量存储,应用端改造也少,但分片事务难以解决 ,跨节点Join性能较差,逻辑复杂。 推荐尽量不要对数据进行分片,因为拆分会带来逻辑、部署、运维的各种复杂度,一般的数据表在优化得当的情况下支撑千万以下的数据量是没有太大问题的。 如果实在要分片,尽量选择客户端分片架构,这样可以减少一次和中间件的网络I/O。下面补充一下数据库分片的两种常见方案: 客户端代理:分片逻辑在应用端,封装在jar包中,通过修改或者封装JDBC层来实现。当当网的 Sharding-JDBC 、阿里的TDDL是两种比较常用的实现。 中间件代理:在应用和数据中间加了一个代理层,分片逻辑统一维护在中间件服务中。我们现在谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。

pandacats 2019-12-23 10:38:11 0 浏览量 回答数 0

回答

OceanBase相对于传统关系数据库的创新首先是运维方面的。将数据库故障切换(高可用)、异地容灾/多活、负载均衡、分布式架构弹性扩容缩容(DB不停服务)全部做到数据库内核里面了,这些是数据库的固有属性,还拿不掉。不需要人工介入(当然机器坏了还是要运维负责去安排维修的,不同之处是运维可以很从容的去处理机器故障)。当然这个固有能力的成本就是数据至少要三副本。 其次就是硬件成本方面。OceanBase架构是shared-nothing架构,不需要共享存储。只需要普通的x86服务器;不需要小机,也不支持小机平台。只需要普通的SSD(OceanBase读写模型里随机写很少,不伤SSD寿命)。 第三就是分布式,可以大规模部署OceanBase集群,同时又支持多租户管理,对机器资源的使用非常灵活,机器利用率高(有负载均衡在,不怕某些机器太闲某些机器太忙)。曾经最大的OceanBase集群机器数超过100台(主要是业务数据量是上百亿级别的)。OceanBase的分区表能力就是分布式水平拆分常用手段之一(另外一个是分布式中间件的分库分表方案)。还有更多就不细说了。

茶什i 2019-12-02 03:18:55 0 浏览量 回答数 0

回答

像传统的数据库,让大家去排队,尽量利用性能,只能一定程度上缓解这个问题。业界上有2种操作,一个是采用云原生的架构,采用存储计算分离,像PolarDB可以做一写多读。现在PolarDB一个实例可以做一个大到接近100T的存储,上面可以做一写多读16个节点。按照当时并发的需求,尤其是对只读并发高的应用,就按量去弹出来的只读节点,一两分钟就弹出一个新的节点,峰值过去之后就可以释放了。 如果写的并发特别多可以采用PolarDB 2.0,所有的计算节点每一个计算节点都可以做写和读。 写和写的冲突问题可以在多写和多读的时候,就要想办法在共享状态这一层。 还有一种解决方法是用分布式,或者有些传统企业用的中间件分库分表或者分布式数据库。因为可以把并发并行的或者分布式放到多个节点上去。这里面也有挑战,挑战非常大,因为一旦对数据进行了分库以后,每个分区都非常容易被并行化。很多时候要做跨区域的查询,依赖两个或三个Partition或者Share上的数据,就需要做跨库的事务处理和查询,这个对系统性能影响非常非常大。但在很多应用场景上,可能并发是很高但做跨库的这种冲突事务的量可能不会太高。

问问小秘 2020-05-22 11:51:50 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 云栖号物联网 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 云栖号弹性计算 阿里云云栖号 云栖号案例 云栖号直播