超融合架构是否适用于强一致性类型的应用?

请问在超融合架构下,如何能在不违反CAP定理的前提下,实现强一致性来运行有强一致性要求的应用,譬如事物性数据库类应用呢?

参与19

5同行回答

白鳝白鳝  技术总监 , 南京基石数据技术有限责任公司
我从另一个角度来说一下这个问题,首先超融合架构定义是什么?超融合架构是一种软件定义的集成化解决方案。早期最为成功的产品就是ORACLE 的EXADATA。超融合架构是一种高度工程化的产品,从底层服务器、网络、存储、操作系统、数据库等通过工程化的改造形成一个高度融合的解...显示全部

我从另一个角度来说一下这个问题,首先超融合架构定义是什么?超融合架构是一种软件定义的集成化解决方案。早期最为成功的产品就是ORACLE 的EXADATA。超融合架构是一种高度工程化的产品,从底层服务器、网络、存储、操作系统、数据库等通过工程化的改造形成一个高度融合的解决方案。最初的超融合系统EXADATA就是用来跑强一致性的RDBMS的,因此谈是否适用于强一致性没有太大意义。
超融合架构的扩展也并不一定受限于服务器与机柜,通过RSD技术、硅光技术、10万兆以太网等可以扩展到邻近机柜,甚至数据中心。对于大多数应用场景来说已经够用了。一个技术可能不一定是万能的,和我们的应用场景放在一起考虑,才能得到比较贴近的答案。
最后说一下,国内的所谓超融合解决方案,大部分还比较初级,比如数据库和硬件、和OS之间的融合都比较浅层次,没有对底层做很大的优化和改造。我几年前遇到YELLOWBRICK的创始人,和他交流,他们的超融合分布式数据库一体机,已经把部分算子下推到了NVME驱动和GPU上,这种超融合才是真正的深度超融合。

收起
IT咨询服务 · 2022-06-19
浏览793
edwardwuedwardwu  产品经理 , SmartX超融合
CAP 定理是说 Consistency,Availability, Partition tolerance 这三者在分布式系统中不可能同时做到,但这是存储系统(底层架构)级别的特性,和上层应用(例如问题中提到的数据库)并没有直接的关系。Oracle 等数据库使用日志的方式来保证数据一致性,这些策略并不依赖于底层架构。相信...显示全部

CAP 定理是说 Consistency,Availability, Partition tolerance 这三者在分布式系统中不可能同时做到,但这是存储系统(底层架构)级别的特性,和上层应用(例如问题中提到的数据库)并没有直接的关系。Oracle 等数据库使用日志的方式来保证数据一致性,这些策略并不依赖于底层架构。
相信您想要问的是超融合是否能承载核心生产应用的运行,根据目前的市场使用情况来看,虽然已经逐渐有一些客户将核心生产应用(包括数据库)跑在了超融合之上,但该类案例确实还不是特别普及。然而,这并非是超融合技术本身的问题。毕竟较之于传统存储,超融合依然属于相对较新的架构,需要一定的时间来在实际场景中被逐渐证明和认可。

关于可靠性的问题,从技术上来说,超融合架构本身有几点是非常符合的:

  1. 全分布式架构,有效避免单点故障,在超融合集群中可容忍部分服务器硬件宕机或者离线情况下继续正常提供服务,保障核心业务的高可用。
  2. 故障自愈功能,当硬盘或者服务器故障,保障生产业务正常运行的情况下,自动触发数据恢复,保障重要数据能在最短的时间内恢复可靠级别。
  3. 超融合集群可以提供多种容灾解决方案,包括原生的容灾备份方案或者第三方容灾软件集成方案,这些手段能为您的核心系统提供跨站点的高可用保护。
收起
软件开发 · 2019-06-05
浏览3129
cao_fowlercao_fowler  其它 , HS
从目前的应用场景来看,超融合不太适合强一致性,首先CAP理论已经非常明确,C的一致性保证一定要有明确的硬件支撑,但超融合跨越的硬件层级明显有先天性的问题,特别是跨越物理节点后产生的延迟,这就是目前超融合确实大行其道,但大部分是VDI一类的应用,强一致性的少之又少。...显示全部

从目前的应用场景来看,超融合不太适合强一致性,首先CAP理论已经非常明确,C的一致性保证一定要有明确的硬件支撑,但超融合跨越的硬件层级明显有先天性的问题,特别是跨越物理节点后产生的延迟,这就是目前超融合确实大行其道,但大部分是VDI一类的应用,强一致性的少之又少。

收起
IT分销/经销 · 2019-03-31
浏览3370
匿名用户匿名用户
两种方法,一种就是把有强一致的事务涉及数据放一起,就是分片,适合要shardingkey数据库的分布式。另外一种就是让事务能非常随机,就是不太有两个事务可能修改一个数据的情况,适合tidb等乐观锁数据库锁下沉到数据可以避免分布式事务,但要靠乐观锁解决性能。锁集中可以解决分布式...显示全部

两种方法,一种就是把有强一致的事务涉及数据放一起,就是分片,适合要shardingkey数据库的分布式。
另外一种就是让事务能非常随机,就是不太有两个事务可能修改一个数据的情况,适合tidb等乐观锁数据库
锁下沉到数据可以避免分布式事务,但要靠乐观锁解决性能。锁集中可以解决分布式事务但有单点风险。锁独立于数据又分布式要产生锁同步,不利于性能。

收起
银行 · 2019-03-11
浏览3346
匿名用户匿名用户
CAP理论是说三者难以均做到。题干中提到是其中的一致性,也就是C。问题就变成了在CAP中如何平衡A和P。比如,对于高可用性A的实现有多种方式,如paxos和raft来保证数据的多数成功,主从复制,跨机房多借点等。二者难以兼顾的时候,如果极力追求一个,那么放松对另一个的需求。比如追求A...显示全部

CAP理论是说三者难以均做到。题干中提到是其中的一致性,也就是C。问题就变成了在CAP中如何平衡A和P。比如,对于高可用性A的实现有多种方式,如paxos和raft来保证数据的多数成功,主从复制,跨机房多借点等。二者难以兼顾的时候,如果极力追求一个,那么放松对另一个的需求。比如追求A,放松P要求。比如金融行业一般是希望追求C和P。
感觉这种问题关乎一种均衡策略:
一方面均衡A和P二者不同均衡所希望的取舍;
一方面需要均衡追求某个方面的极致带来的成本和付出的代价。比如追求高可用,可以实现五个副本,三个副本,但是显然二者的硬件成本就很大差异,那么如何取舍呢?

收起
银行 · 2019-03-08
浏览3759

提问者

Seaskyblue
医疗行业解决方案架构师联想凌拓科技有限公司
擅长领域: 存储灾备分布式系统

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2019-03-08
  • 关注会员:6 人
  • 问题浏览:5559
  • 最近回答:2022-06-19
  • X社区推广