xiaoxiaoqiushui
作者xiaoxiaoqiushui2022-12-01 12:21
数据库架构师, 深圳XX科技有限公司

OB的七大缺点(个人经验观点)

字数 406阅读 19716评论 25赞 16

1.多副本实时数据同步,多数落盘返回机制,带来的性能和响应时间的损失;
2.对内存要求极高,LSM树结构的缺点,包括元数据管理库占据内存较大,造成大量内存资源浪费;
3.多数派协议在本地双机房分布模式,多数派节点分布的机房不可用会导致数据库整体不可用;
4.备份恢复为单独的组件,运行机制为逻辑备份恢复,配置繁琐,备份恢复均较慢;
5.其管控组件OCP监控管理功能较弱,监控点及管理能力较少;
6.基于其特有的基线数据+内存数据的LSM树存储引擎管理模式,在部分涉及到同时取基线数据和内存数据的场景,以及部分转储和合并时间段,性能较差,抖动严重;并且存在读放大、写放大和空间放大的问题;
7.OB对环境要求极高,需要采购使用其指定的服务器,节点间至少万兆网络,对跨机房之间的网络抖动基本无法容忍。

转储合并的问题,说明其基本不适用于金融交易类场景!节点间实时同步,对任何同城超过50公里以上的机房间,基本也不适用!

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

16

添加新评论25 条评论

flywiththewindflywiththewind其它, easy world
2023-09-06 22:48
体会最大的一点,如果对响应时间要求极高的场景,使用ob必定会回到集中式架构。所谓的primary zone必须为zone1>zone2>zone3,最好每个zone有一台机器;如果单台服务器硬件上线仍无法满足要求,要求必须严格设计好table group。另外自创的黑屏白屏叫法真是醉了。
xiaoxiaoqiushuixiaoxiaoqiushui数据库架构师, 深圳XX科技有限公司
2023-08-19 10:44
隔了许久,依旧没有很给力的观点出现,继续补充: 1.多副本实时数据同步,多数落盘返回机制,带来的性能和响应时间的损失 2.对内存要求极高,元数据管理库占据内存较大,造成大量内存资源浪费 3.基于LSM树结构的缺点,内存和磁盘数据合并时需要同时保存前后两个版本的数据,至少需要2倍的磁盘空间。另OB的日志盘需要独立占用一块NVME SSD盘,空间为内存的3-4倍,造成数据存储空间浪费。 4.多数派协议在本地双机房分布模式,多数派节点分布的机房不可用会导致数据库整体不可用 5.管控组件管理功能较弱,监控点及管理能力相对较少 6.基于其特有的基线数据+内存数据的LSM树存储引擎管理模式,在部分涉及到同时取基线数据和内存数据的场景,以及部分转储和合并时间段,性能较差,抖动严重 7.LSM Tree带来的性能问题,写入多版本磁盘空间放大,读放大,合并对性能稳定性的影响。内存磁盘数据合并,现实中往往和客户跑批时间重合,不适用于金融场景 8.OB的多租户资源隔离通过cgroup实现租户资源隔离,无法实现磁盘空间的分配和IO隔离 9.OB对环境要求极高,需要采购使用其指定的服务器,节点间至少万兆网络,对跨机房之间的网络抖动基本无法容忍,需要跨中心部署的情况需要考虑网络的稳定性和延时要求 10.OB本质上仍是一款普通数据库,若想通过水平分表方式拆分保存数据需要单独安装部署收费的分库分表工具DBP 11.真实情况部署,要求至少三机房,不管是本地还是两地三中心部署都很难满足要求,大部分情况下都退回到单机房部署模式 12.自动数据分布策略,基于表分区粒度在不同的节点进行分布,如果表分区设计不合理,或者无较好的分区列,容易出现分区倾斜,数据热点等问题,需要对业务场景非常熟悉 13.在实际使用过程中,存在大量的兼容性和功能问题,需要后端较强的支持能力,去持续跟进解决 每个Observer是一个计算存储一体化的独立服务,带有SQL引擎,事务引擎和存储引擎,并存储一部分分片数据(分区)。OB采用的是对等模式,客户端连接到任何一个OBSERVER都可以全功能使用数据库。OBSERVER会自动产生分布式执行计划,并将算子分发到其他参与协同计算的OBSERVER上,完成分布式计算。管理整个集群的RootService只在部分Observer中存在,并全局只有一个是主的,其他都是备的。实际上每个OBSERVER就组成了一个完整的数据库子集,如果所有的数据都存储于一个OBSERVER上,我们的访问方式类似于一个集中式数据库。这种架构下的数据分区采用了高可用,一个数据写入主副本(Leader)后会自动同步到N个备副本,OB采用Paxos分区选举算法来实现高可用。其备副本可以用于只读或者弱一致性读(当副本数据存在延迟时),从而更为充分的利用多副本的资源。实际上不同的分布数据库的主备副本的使用方式存在较大的差异,有些分布式数据库的备副本平时是不能提供读写的,只能用于高可用。大家看到这里,可能觉得OB的架构不错,各种问题都考虑的比较周到了。不过还是那句话,没有完美的分布式数据库架构,SHARDING存储需要分布在各个SHARDING分区中的分区表要有一个SHARDING KEY,根据SHARDING KEY来做分片处理。SHARDING模式虽然应对一般的数据库操作是没问题了,不过如果一条复杂的查询语句中没有关于SHARDING KEY的过滤条件,那么就没办法根据SHARDING KEY去做分区裁剪,必须把这个算子分发到集群中存储这张表的分区的所有OBSERVER上,这种情况被称为SHARDING数据库的读放大。另外一方面,在OB数据库中创建一张表的时候需要考虑采用哪种模式,是创建为分区表还是普通的表,如果创建表的时候不指定是分区表,那么这张表只会被创建在一个OBSERVER中,无法在集群内多节点横向扩展。另外如果有多张表要进行JOIN,如果要JOIN的数据分别属于不同的OBSERVER管理,那么这种JOIN是跨网络的,其性能也会受到一定的影响。 在从类似OB/TiDB这样不同架构的分布式数据库中做选择的时候,一定要把你比较复杂的SQL拿出来做些测试,再来完成你的选择。因为对于大多数应用来说,这些分布式数据库在架构上的缺陷还是不会造成太大的影响的,而如果某些SQL因为执行计划无法优化而导致你必须改写应用就比较麻烦了。
匿名用户
2023-03-24 16:36
分布式解决的是单机上限的问题,如果场景都没有遇到瓶颈,何必为 了分布式而分布式。如果分布式都只有优点没有缺点,包括运营成本和切换成本问题,用户自然而然会选择更好的。分布式共性的问题,OB在这个领域已经相对很出色了,先确定要分布式,再选择哪个分布式,可能评估选择的过程会简单一些。
匿名用户
2023-02-04 08:40
谢谢分享经验,值得借鉴!同时对分布式了解不多,通过这次有了很好的学习效果!
y5_sety5_set其它, 不告诉你
2022-12-14 19:49
2.对内存要求极高,LSM树结构的缺点,包括元数据管理库占据内存较大,造成大量内存资源浪费 lsm树本身就是内存数据库常用的算法结构,这只是一个算法啊,也是你的攻击点吗?你的攻击意图太明显了吧,说说技术啊,比如说,ob实现的lsm树的方式有哪些缺陷?很多数据库都用了这个算法,比如像HBase,Google BigTable,Cassandra,InfluxDB ,这也在你的攻击之列吗?我们这里是技术论坛,请只谈技术,厂商请不要引战

xiaoxiaoqiushui@y5_set 这是事实,不知道你哪只眼看到了攻击?恐怕是自己的臆想症发作,拉黑之!

2023-01-17 17:26
zhmwangzhmwangPD, OceanBase
2022-12-07 22:04
@楼主, 转储合并的问题,说明其基本不适用于金融交易类场景,这个结论是如何得出的, 能否说得更详细或者数据说明一下?
李英杰李英杰数据库技术专家, 烁林软件
2022-12-02 17:18
没使用过OB,没有直观的感受,对OB的了解也仅仅局限于一些技术文章以及同行的交流。就分布式和集中式数据库的特点来讲,各有各的适应场景,就同一个事务来看,在没有资源瓶颈的情况下,集中式的耗时肯定要少于分布式的耗时。但是受限于单机硬件的配置,集中式数据库的处理能力是有限的,当单机的处理能力不能满足业务需要的时候,就不得不考虑分布式架构了。像ORACLE RAC这种share disk架构,也仅仅只能解决计算节点的瓶颈,要想彻底解决计算节点和存储节点的瓶颈,就需要这种share nothing架构的模式了,以牺牲单个交易的响应时间来换取TPS,我从同行了解到,从DB2集中数据库迁移到OB数据库,同样的交易耗时从原来的200ms增加到250ms左右,也在可接受的范围。至于稳定性方面,由于没有亲自接触运维过,不好做评价。像OB这种分布式数据库,肯定会存在这样那样的问题,但从架构来看在线性扩展、两地三中心、应用双活、业务连续性等方面有着集中式没有的先天优势,适用的场景会越来越多。只有经过生产系统的使用,发现问题,改进问题,不断完善,产品才能越来越好。个人一点拙见,希望和同行多多学习,多多交流。
匿名用户
2022-12-02 16:33
ob采用存算一体SHARDING模式的架构 在以下场景下不太合适或者有性能问题 1:对于一些核心业务表,如果设计了多个二级索引,数据高并发下的写入和修改,对二级索引影响就很大。这主要是因为分布式数据库的全局索引维护成本因为多节点与网络延时的存在而被放大了。 2:SHARDING存储需要分布在各个SHARDING分区中的分区表要有一个SHARDING KEY,根据SHARDING KEY来做分片处理 如果一条复杂的查询中没有关于SHARDING KEY的过滤条件,那么就没办法根据SHARDING KEY去做分区裁剪,必须把这个算子分发到集群中存储这张表的分区的所有OBSERVER上,这种情况被称为SHARDING数据库的读放大。 3:在OB数据库中,如果创建表的时候不指定是分区表而是普通表的话,那么这张表只会被创建在一个OBSERVER中,无法在集群内多节点横向扩展 4:对于一些经常有大型写事务的场景,OB必须将算子分解到各个OBSERVER上,交给OBSERVER再往下写数据,其效率肯定是有所损失的 5:一些大型的表扫描和多表关联查询,场景下OB需要将算子分别推送给其他OBSERVER,再由OBSERVER下推,在交互上也多了一层,效率不高

zhmwang: @匿名用户 对于问题2: 对于关于sharding key或者分区键而言的问题,本质而言就如同oracle/db2的分区表,如果查询语句里没有分区键,肯定是走全表扫描的,抑或你的索引设计不合理,即使对于再好的优化器,也是要走全表扫描。所以在做表结构设计的时候要考虑到这一点;对于问题3:除了其他“”高大上“”的设计之外反而我认为是 OceanBase的精华所在,实际上哪有那么多大表要做分区设计呢? OceanBase 目前是建议 数据量达到 500G(其他库可能是 1.5T)以上在做表分区设计。

2022-12-07 21:31
xjwangbo100xjwangbo100系统架构师, 哈密市商业银行
2022-12-02 16:14
我行移动银行项目数据库也选用了ob 同机房的测试情况来看 暂时良好,然后启用了DWDA波分项目,对于跨机房之间的网络抖动问题 应该可以避免掉。

xiaoxiaoqiushui@xjwangbo100 这个可以的,两端分别加波分设备,其实最好的方案,是让运营商在同城两机房之间拉裸光纤,只要有财力,这些缺点其实都不是问题,本文的目的,仅仅是供一些暂不具备高可用低时延无抖动条件的客户参考!

2022-12-05 10:22
zftangzftang其它, 小白一枚
2022-12-02 15:59
就拿LSM Tree来说,和B+Tree只能说各有优劣

xiaoxiaoqiushui@zftang 确实如此,各胜擅场,难分高下,需要仔细甄别,根据实际情况,做出选择!

2022-12-05 10:23
匿名用户
2022-12-02 14:41
可以把你们的应用场景拿出来,再来看ob的这些功能能不能满足吧!如果只是单纯的说一个产品的功能如何强大,或是如何low,个人觉得意义不大。
flywiththewindflywiththewind其它, easy world
2022-12-02 11:26
评价客观
wangzk0206wangzk0206数据库管理员, scrcu
2022-12-01 21:59
说说我们目前使用的感受吧,我们用的相对较早,采用2.2版本。起码2.2版本只能算OB的入门版本,还是存在很多不足的。我们遇到的问题主要有: 1:优化器在选择执行计划的时候,可能会出现错误,导致复杂SQL性能不佳,据说3版本之后改善比较大,我测试确实3版本后相对比较好用了。(可能会有支持者说我们的数据库设计不好,但这个我相信在各个开发厂商的产品都存在的问题) 2:OB对网络带宽和网络性能要求非常高,否则达不到我们的性能要求。(特别是三地五中心架构,网络延迟、吞吐量要求很高,成本这块不是一般机构能扛得住的) 3:统计信息无法手动收集,导致执行计划可能不准(后续版本支持,但2.2版本不支持) 但对于国产数据库来讲,OB是一个值得推荐的数据库。只是国产数据库的路还很长,需要我们大家共同的探索、也需要我们使用者能够按照他的规则来玩。产品始终不会有坏产品,只有它适用的场景对与不对。同时更需要我们对它有大的耐心。选择一款国产数据库来讲真的很难,最重要的一点是它是否有持续的研发能力,几百个国产数据库最后能存活多少个哪?真的很难说。

zhmwang@wangzk0206 谢谢老师的中肯答复。坚信作为一款纯国产且原创的数据库,OB 会因为有大家的支持和信赖 将做得越来越好

2022-12-07 22:30

xiaoxiaoqiushui@wangzk0206 感谢评论,有理有据,这是具体实现细节的问题,这样的问题,早期我碰到过很多,不过这都是可以持续改进和优化的,蚂蚁也确实这么做了,所以这块不做具体评论,只是说一下宏观方面的一些优缺点,供一些行业客户选型参!

2022-12-02 12:38
匿名用户
2022-12-01 21:09
这些是我也觉得是分布式数据库的共性问题,要使用好OB,从业务设计上要适应这些分布式带来的问题。
匿名用户
2022-12-01 17:30
采用OceanBase数据库替换Oracle,需要提前了解的一些经验: 1.技术架构,OB采用Paxos多副本协议,实现数据的多副本一致性,要求多数派副本工作机制,在极端情况下,多数节点(比如3副本中2副本故障情况)故障后,少数故障无法临时启动提供服务,必须依赖容灾集群或者备份恢复手段。 2.部署方案,比较常见的部署是单机房3副本,同城两地三中心5副本,多网络的带宽和网络质量有严格要求,至少万兆网络带宽,需要跨中心部署的情况需要考虑网络的稳定性和延时要求。但真实的情况,机房IDC的数量很难满足OB的两地三中心部署要求,同城部署没有三机房,异地部署网络不满足要求。很多情况都退回到单机房部署。 3.数据分布策略,OB实现来较为自动的数据分布策略--基于表分区粒度在不同的节点进行分布,如果表的分区设计不合理,或者无较好的分区列,容易出现分区倾斜,数据热点等问题,需要对业务场景非常熟悉。 4.数据存储空间问题,OB一直强调数据压缩率高,可以节省存储成本。但实际部署的情况下往往不一定能节省存储空间,原因:OB每个节点启动需要自动预分配一个固定的文件系统,预占整个文件系统的空间(不支持文件系统的扩容操作),所以启动OB节点,磁盘空间即分配完毕(10TB一次性占用)。同时由于OB采用LSM Tree简化为2层,每日会进行一次大版本的合并,合并时需要同时保存前后两个版本的数据,即在合并时需要占用至少2倍的空间。另外,OB的日志盘需要独立占用一块NVME SSD盘,空间为内存的3-4倍。 5.LSM Tree带来的性能问题,写入多版本磁盘空间放大,读放大,合并对性能稳定性的影响。在测试中发现,连续写入性能持续下降,比如测试TPCC测试,连续测试4-8个小时,OB的TPMC持续下降,下降幅度超过40%。 6.死锁检测,分布式数据库实现死锁检测是比较难的技术,OB3.*版本之前无死锁检测机制,4.0版本发布来死锁检测,对性能有较大影响,默认不建议开启死锁检测,应用只能通过锁超时方式捕获异常。 7.OB的多租户,资源隔离问题很大,多租户通过cgroup实现租户资源隔离,无法实现磁盘空间的分配和IO隔离,CPU配置较为复杂。 8.HTAP,OB尚未有列存隔离,当前实现了MPP查询能力,对TP业务影响无法隔离。另外,OB打榜HTAP,细心的会发现OB官方发布的HTAP测试SQL,每一个SQL都有一个独特的SQL hint,因为在实际测试业务SQL,OB支持多表查询性能很多情况下非常满,这块可能是优化器不是特别好的原因造成。使用的时候,需要每个SQL去单独优化,并增加具体的SQL hint。 9.关于Oracle/MySQL兼容性的问题,OB在这方面应该是国内做的最好的了,不过离用户的期望还是有差距,Oracle发展了40年,OB2-3年内开发的Oracle兼容性和稳定性不能让人放心,所以如果要用OB迁移Oracle的存储过程,一定要进行全面的测试。这也是当前大部分国内客户去O面临的痛点问题,也期待OB越来越好。 10.易用性和最低部署环境要求,这方面一直是OB持续改进的点,最低配置从最开始的单节点32C 128G内存,最近版本有一些改进,但还是离普通用户想试用OB有些距离,一般都需要配置较高的环境来运行OB,这也是阻碍OB被使用者快速上手的一个点。 11.关于开源,这块网上有各种评论,其实从一个商业化产品走到开源这一步,OB已经很努力了,但是open core的开源模式,很难实现像TiDB那种繁荣的社区。所以在选择OB开源版本的时候,还是考虑开源产品周边工具的问题和开源持续性。

xiaoxiaoqiushui: @匿名用户 很详细,看来我们的目的一致,就是希望他们越做越好!

2022-12-01 19:11
sprewellkobesprewellkobe专有云, TX
2022-12-01 16:58
首先楼主提的问题还是蛮细致的,不过这里的大部分问题还是分布式架构带来的,所以可能我们在这些问题的时候,要先问一下,我们是否已经先决定了使用分布式架构数据库,然后在看既然已经选择了分布式,那么在众多分布式数据库中ob一些独特的问题。 比如,多副本复制以及读写放大的问题,这里本身就是分布式架构带来的。再比如多数派所在机房整体故障的影响问题,也是在双机房分布式下不可避免的问题,除非去引入仲裁区的概念。所以也才会带来第七点,正因为分布式带来的这些副作用,所以需要一些硬件及网络环境上的高要求来弥补。 总之还是一个取舍问题,可以再深度探讨。

xiaoxiaoqiushui@sprewellkobe 确实如此,以上仅一家之言,供各行业选型的一点参考!

2022-12-01 19:11
huhu097huhu097DBA, 云南红塔银行
2022-12-01 16:24
老师您好: 不知道您对OceanBase数据库是否有真实的使用经验。作为一名银行新核心上线OceanBase的技术负责人,我觉得您在对一个产品下结论之前还是亲自动手使用这个产品,结合业务场景,多使用,多理解产品的底层逻辑,这样您会对OceanBase会有不一样的看法。 接下来我对于您提出的这几个缺点,谈谈我个人的看法。 1. 多副本同步带来的性能损失,只有在事务提交时才有,延迟一般小于2ms,对于一个RT在50~200ms以上的交易来说,这个延迟比例也不算是不可接受,我行核心系统采用两地三中心五副本的架构,在真正的”全集业务“双活架构下,10台x86机器混合交易TPS能达到8000+, RT不到270ms,可以说是非常优秀的性能指标了。 2. OceanBase采用LSM存储的主要原因时为了满足大并发网络交易场景中乱序IO的问题。在传统数据库,比如Oracle和DB2中,SQL的执行时间主要消耗在IO上,特别是乱序IO。OceanBase采用LSM tree架构+转储机制,把乱序IO变成了顺序IO。相对于传统数据库,OceanBase的确对内存的要求是很大。但是内存的开销和IO的开销,哪个更划算,哪个性能更好,我想这个不需要太多解释,对于元数据管理库占用内存过大的情况,目前我行元数据管理库,也就是业务租户以外的租户占用内存不到总内存的百分之十,而且近年来内存价格越来越低,数据库愿意用内存来换取性能,并不是一件坏事。 3. 我行两地三中心五副本加异地备集群的架构,只要不是同城两个机房同时挂掉,任意挂掉同城任何一个机房,业务只有极短的时间的影响,异地机房故障业务根本不受影响,如此优秀的高可用能力,行业内不多的,传统数据库是集中式的,单点故障就会导致整个集群不可用。相比之下,OceanBase分布式架构可以从容应对各类故障,无论单机故障,多机故障,只要不发生多数派故障,集群均可用。相比传统数据库,分布式数据库在高可能能力上更胜一筹。 4. OceanBase 既有所谓的逻辑备份,也有物理备份。日常的数据备份都是由后台任务执行物理备份完成,不需要用户的干预,而且物理恢复可用恢复到任一指定的时间点,保证整个集群、租户的数据一致性。 所有的备份恢复操作都能在ocp管控平台白屏操作,亲测数据:4.5T数据全备份:耗时50分钟。4.5T全备份恢复:耗时2.5小时。我觉得您备份恢复较慢,极有可能和您的备份介质有关。 5。OceanBase的管控工具OCP,目前我们团队日常管理维护基本都使用OCP,主机,数据库的监控数据,性能数据,告警,租户的维护,用户权限的维护,备份恢复等等,我觉得一个国产的数据库管控工具能做到这样,已经很强大了,并且OCP产品迭代也不慢,有需求厂家都会积极响应,总之,在使用OCP的过程中,还没有不满意的地方。 6. LSM tree+转储+MVCC的机制下,如果访问的是合并后更新的数据,的确会出现获取记录最新版本需要同时对内存、基线中的记录进行整合的情况,因此OceanBase设计了一个fuse cache来提高此类读场景的性能,同时利用每日合并来整合前一次合并后发生的更新。fuse cache和每日合并机制最小化了此类性能抖动发生的频率。合并会对交易性能产生一定的影响,需要合理设置合并时间,避开交易高峰期。至于读写放大的问题,这个不是OceanBase数据库的问题,所有的数据库软件都会存在这样的问题,本质上是磁盘与IO系统只能以page、block为最小的读写单元进行操作导致的,而OceanBase使用LSM tree很好地解决了写放大的问题。 我在性能压测过程中得到的结论,转储对于TPS影响极小,合并对于TPS影响在20%左右,短时间内快速恢复。 7. OceanBase并不依赖高价、高性能服务器,我行目前就有部署arm和x86架构,操作系统也一样使用国产麒麟系统。目前也稳定运行,OceanBase基于Paxos一致性协议,相比使用其他多数派协议的数据库而言,更容忍网络抖动导致的时序不一致等问题。对于节点间的网络要求,如果同城两中心达不到万兆带宽,可以选择主zone和应用部署于单边机房,采用同城三副本的架构,对于您所谓的不适用于金融交易场景的问题。我行核心,总账,柜面系统上线至今,一直稳定高效运行,没有出现过任何问题。 最后,还是建议您在对一个产品有疑问的时候,多使用,多思考,你会得到的更多。

zhmwang@庆功 在发送此类消息时,请务必确认清楚,不要以讹传讹,误导观众!

2022-12-07 22:33

huhu097@庆功 我只是表达了我行使用ob的真实感受,其他同行出现什么问题,并没有耳闻,对于ob是不是适用金融交易类场景,欢迎各位同僚来我行实地考察,眼见为实,耳听为虚。

2022-12-07 17:10

匿名用户:北京的事情咱不知道,如果这里所谓首都的某城商行指的是北京银行,那么可以推测大概率不是OB,因为OB是前两个月才刚刚中标北京银行,还没投入使用,之前北京银行国产分布式库用的是TiDB。招商证券的故障并不是OB引发,甚至根本都和数据库没有关系,作为亲历这件事情的人可以作证。希望这个论坛不要成为厂商商战的舞台,还是就事论事谈技术比较好。

2022-12-07 15:23

庆功@huhu097 不过今年OB在南方某头部证券2个月内连续出现两次重大故障,导致客户IT整条线被牵连,证监会通报批评。另外在首都某头部城商银行出现重大故障,导致该行被银监会通报罚款批评。这些都怎么解释呢?

2022-12-07 11:52

xiaoxiaoqiushui@huhu097 哈哈,洗地的来了,我用了三年多了,这就是真实使用评论,不知道你一个刚用了一年多的有什么深入的感受写出来这样一大段,懒得理你,拉黑!

2022-12-02 12:35

huhu097@xiaoxiaoqiushui 建议您在评价一个产品的时候,拿自己真实的使用数据来证明一下自己的观点,而不是拿着自己个人所认为的缺点,去推断其基本不适用于金融交易类场景的结论,一个产品的未来不是您这样随随便便可以评价的。

2022-12-02 08:40

xiaoxiaoqiushui@huhu097 另外想告诉你,并不是所有客户都具备非常理想的各项外部环境,比如IO、网络等,发此文的目的就是给各行业做一个参考,选型的时候,多多注意自身实际情况,从实际出发,做出更好的选择!

2022-12-01 19:08

xiaoxiaoqiushui@huhu097 呵呵,这位老师,我从19年就开始在银行持续使用OB了,我说的这些就是实际得到的经验,至于你写的这些,相信也是你用这一段时间的心得,具体就不再评论了。之所以发这篇文章并不是要针对OB专门进行攻击,而是希望暴露它的缺点,让大家能更好的的认识它,也欢迎更多有识之士来评论!

2022-12-01 18:39
peimapeima架构师, 某金融公司
2022-12-01 15:16
用OB还得和确认一下版本,据说“Oracle租户版”有不少坑。

xiaoxiaoqiushui@peima 这位老师,咱们还是要谨慎,据说这个说法有点不太妥当哈!

2022-12-01 18:39
peimapeima架构师, 某金融公司
2022-12-01 15:13
认同对OB的评价。在选型是要充分考虑兼容性,适用通用使用环境,OB似乎对环境要求高了些,相对难融合。对分布式数据库还是要兼容 MySQL 以及 Oracle 两种模式,原来的代码,应用程序只需做较小的改动就可以迁移,并直接来使用。同时要具备多级权限控制、数据加密和安全审计。具有容灾多活,能真正保证业务连续性。

xiaoxiaoqiushui@peima 感谢评论,发此文的目的就是供大家参考,尤其一些行业客户选择时,至少要充分考虑自己实际情况,而不能盲目大干快上,最终发现痛苦的只有自己!

2022-12-01 19:06
匿名用户
2022-12-01 14:35
我只想想谈谈题主的第7点。 (1)对于一个商业银行来说,首先采购服务器要按国家的招标法,公开招标服务器。作为数据库管理人员,我们不可能干涉底层硬件的选择,不能指定哪种服务器,最多在技术路线上选择哪种芯片架构,且采购部门也不允许指定服务器。 (2)另外就是不同数据中心之间的网络质量,一般都是租移动、电信、联通等运营商的线路。说实话,拿华东地区以平原为主的大城市为例,一个月抖动几次也经常见。双机房距离过近,网络质量好一些,可是银监和人行对同城和异地灾备中心的距离是有要求的,不能太近。 (3)还有一些小的金融机构,是不能不被考虑的,他们的科技投入不多,没有优越的资金和人力投入到科技上。他们在做数据库国产化改造的时候,最希望的是有一款“皮实、性价比高,在基础硬件和网络环境差的条件下依然能用起来没问题”的国产数据库。所谓“家贫思贤妻”,就是这个道理。

xiaoxiaoqiushui: @匿名用户 比较客观,现实情况确实如此!

2022-12-01 19:05
wangzk0206wangzk0206数据库管理员, scrcu
2022-12-01 14:30
1:这是所有分布式数据库的共性问题吧。但是传统数据库如果要求主备灾架构的集群必须强同步的话,是不是也存在同样的问题哪?反而可能做的更不好。例如RAC节点拉开、DATAGUARD开启强同步模式。 2:内存占用高这个应该不是缺点吧,这个应该算是充分利用资源。LSM结构不能算是缺点,只能说他有读放大这个缺点,但相较于其他国产数据库来讲,OB已经算做的比较好的了。他每个集群是有一个sys租户,但需要的资源也只能说很小,是可以忽略的。 3:这个是所有分布式协议的共性问题,可能有些做的好的会在多数派出问题的时候,通过某个开关让你能把活着的节点继续对外使用。OB貌似也存在类似的方法,但官方不会推荐,因为存在丢失数据的问题。对于RAC可能会说实例坏掉多数派可以继续对外,那如果底层的存储坏了哪?是不是要考虑切换DataGuard哪?OB也是有相关解决方案的(备集群)。 4:OB的备份恢复是物理备份不是逻辑备份,相较于搭建一个OB集群、RAC集群来讲,配置备份恢复已经算简单的了。OB 4.0之前是整个集群的备份、OB4.0之后是按租户的物理备份,恢复也可以控制粒度。 5:OCP的这个监控管理平台,真的做的已经不错了,功能是十分强大的。只是它需要单独的集群来部署,对资源消耗比较大而已。 6:读放大这个问题是存在的,但是对于写性能来讲,OB应该是非常强的。对于存储放大,我觉得这个不存在,因为它底层的SSTABLE会压缩排序,存储资源基本上都不会成为问题。OB在读放大这个问题上也做了比较大的优化,例如引入Bloom filter、row cache等。 7:OB其实对特定的硬件环境要求不高,只是他们做过相关硬件环境的测试、兼容性及性能更可靠而已。在4.0之前,OB对个人学习来讲确实要求配置太多,因为个人拿出三台服务器来搭建一个集群还是比较现实的问题。4.0版本之后,OB做了很大的改进,单机也可以搭建,后续随着使用量的增多,可以扩展成集群,这是一个很好的特性。同时对于个人学习来讲,也是很大的改善。 最后一点,关于转储、合并这个对于金融行业来讲,真的不是特别大的问题,转储基本上无感知。合并的时候可能会有波动,需要尽量错开批量等跑批任务,这个合并的时间点可以定制。4.0之前合并是集群级别的任务,到了4.0版本OB做了很大的改善,改为了租户级别的合并,这样就更加灵活。其实关于合并问题,真的没有想象中的那么大的影响。

xiaoxiaoqiushui: @匿名用户 这个评论相对中肯,可以作为参考,我发此文目的并不是攻击OB,而是根据实际使用体验,客观反馈其缺点,供相关各行业选择时作为参考,实际上在使用过程中还有非常多的小问题,他们后端基本都能快速反馈给予支持和处理,所以也不做一一赘述,总之一句话:一家之言,仅供参考!

2022-12-01 19:04

匿名用户:我同意wangzk0206的观点。

2022-12-01 16:20
zwz99999zwz99999系统工程师, dcits
2022-12-01 14:30
评价客观实在,问题应该暴露出来,这样在使用过程才不会踩坑!
Liu三变Liu三变DBA, 国信证券
2022-12-01 14:28
文中提到的很多机制例如多数落盘,多数可用等是分布式数据库架构的要求,如果是应用于金融行业,个人认为这样的设计无可厚非,毕竟金融行业的数据有强一致性要求,丢失数据是万万不能接受的。分布式数据库必然意味着跨节点的接口访问调用,这就导致节点间的网络要求比较高,相反集中式数据库就没有这方面的困扰。 文中提到的备份,如果只是支持逻辑备份,那这一点还是比较糟糕的,对于海量数据的系统来说,几乎是不可取的,希望OB能够给出相应的解决方案。 其他方面不是很了解,不予评价。

xiaoxiaoqiushui@Liu三变 建议可以自行测试一下,毕竟开源了,发这个也不是要攻击OB,而是希望他们能正视这些问题,并做的更好

2022-12-01 18:57
hanfeng_twthanfeng_twt数据库架构师, SphereEx
2022-12-01 14:09
对OB的使用经验不多,但对于分布式架构产品,因架构复杂度的提高、对基础环境依赖增大等原因,从使用体验上较传统单机或集中式数据库是会有所退化。在具体产品选型上,应充分考虑分布式架构适应点、产品特性与业务需求,做好选择。从之前使用体验来看,分布式架构产品对低延时、高并发、超大规模的场景是存在一定不足的。当然,分布式数据库发展很快,相信未来在更多场景上会发挥更大作用。
lych370lych370系统运维工程师, 个人
2022-12-01 13:10
评价很犀利,虽然没有使用过,但一个产品如果对硬件需求配置极高,且内部机制没法自主调整的话市场空间确实不大,目前越平民的产品越适用,毕竟在有限的资源下能提供高价值的服务才是最重要的。希望有机会适用完后再做更加合适的评价
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广