对于业务系统的历史数据存放、查询,哪种类型的数据库更为合适?

初步计划将各个业务系统的历史数据统一迁移至独立的历史查询数据中心,从目前来看认为传统关系型数据库如Oracle无法满足使用,不知道各位是否有在使用合适的数据库存储引擎用于存放此类数据及使用?数据的使用有以下几个特点:
1.历史数据的数据源为Oracle,通过批量卸数方式卸至历史查询数据中心
2.历史查询数据中心的表大概率以大宽表的方式存放和使用
3.根据数据库的选型,开发使用数据可以选择性是否使用如多表关联等特性
4.不会有任何数据加工的OLAP,也不会有报表类SQL
望各位不吝赐教

参与43

11 同行回答

jillme jillme 课题专家组 CIO 某大型银行
我的建议是存在NOSQL类型数据库,便于未来扩展,也无需考虑事务一致性。比如mongodb或者clickhouse 都是不错的选择。显示全部

我的建议是存在NOSQL类型数据库,便于未来扩展,也无需考虑事务一致性。比如mongodb或者clickhouse 都是不错的选择。

收起
互联网服务 · 2022-04-01
浏览1943
  • 感谢回复,mongodb这种文档型的有考虑过,CK的话倒不太适合,CK的优势在于OLAP和报表类,对于历史数据查询这类可能返回行数非常少甚至只有一行的就没有速度优势了,而且CK生态还不够健全
    2022-04-01
  • 在我们的场景下,可能觉得同作为列存的hbase选择度会好一些
    2022-04-01
anikikong anikikong 课题专家组 数据库运维工程师 中国民生银行
看了下大家的互动问题,看起来需求比较明确了。关键信息有:关系型数据表,历史数据归档,大宽表,有历史数据点查需求。 从这个信息来看,银行的历史数据归档平台就是做这件事情的。所以要当做一个普遍的需求来建设这个平台,而不仅是当做某个业务或者系统的单独解决方案。历史数据又...显示全部

看了下大家的互动问题,看起来需求比较明确了。关键信息有:关系型数据表,历史数据归档,大宽表,有历史数据点查需求。
从这个信息来看,银行的历史数据归档平台就是做这件事情的。所以要当做一个普遍的需求来建设这个平台,而不仅是当做某个业务或者系统的单独解决方案。
历史数据又是处理好的大宽表,看起来非常适合使用列存的数据库,能够提高压缩率降低存储成本,因为又不需要计算能力,所以传统的mpp数据库其实意义不大。相信这种历史数据的查询也会基于特定的查询条件和时间来点查数据,建好相关的索引即可。历史数据按照时间分段就好,没必要打散存储。
综上所述,你需要的是低成本的分布式存储引擎加友好的类sql接口查询引擎的平台。建议hbase,es,巨衫等数据引擎。

收起
银行 · 2022-04-13
浏览1720
haizdl haizdl 技术经理 大连
1. 分库分表方案将数据按照时间维度或者其他合理维度进行分库分表,具体查询可以在应用侧进行分流。2. NOSQL或者分布式SQL数据库方案加一层应用处理,用来分析、抽取、转换从传统Oracle数据库当中归档出来的数据,然后导入分布式数据库当中,将查询逻辑设计到新的查询逻辑当中...显示全部

1. 分库分表方案
将数据按照时间维度或者其他合理维度进行分库分表,具体查询可以在应用侧进行分流。

2. NOSQL或者分布式SQL数据库方案
加一层应用处理,用来分析、抽取、转换从传统Oracle数据库当中归档出来的数据,然后导入分布式数据库当中,将查询逻辑设计到新的查询逻辑当中。

收起
银行 · 2022-04-13
浏览1844
  • 如果是基于传统关系型数据库的分库分表,之前有考虑,但其优缺点都太明显,分析以后觉得不适合以后长期的发展使用。当然分布式数据库也考虑过
    2022-04-13
Jerry Miku Jerry Miku 其它 The Global 500
结构化数据,又是主要以大宽表方式使用,那基本列存数据库会有优势些。Hbase、 Cassandra这类数据库方案比较符合。但列存数据库想用好,就会有一大堆组件也需要顺带维护,有一部分隐性运管控成本在里面。 Hbase这类开源或者半开源商用方案,在效率上需要持久优化且优化的质量直接...显示全部

结构化数据,又是主要以大宽表方式使用,那基本列存数据库会有优势些。Hbase、 Cassandra这类数据库方案比较符合。但列存数据库想用好,就会有一大堆组件也需要顺带维护,有一部分隐性运管控成本在里面。 Hbase这类开源或者半开源商用方案,在效率上需要持久优化且优化的质量直接影响使用感受,但“专业做一行”的服务公司又比较少,所以很大部分的优化成本都需要内耗了。基本搞 Hbase这种开源方案做历史数据查分中心,又不想花钱的话,大概率“卷死”+“玩不出花活”的节奏。
需求内没有看到数据集市之类的场景,如果有的话,也可调研测试下MPP类的数据库。国产也有些拿GP做的换壳方案,有这方面需求的话,也可以调研交流下,至少有个托底……

收起
IT其它 · 2022-04-13
浏览1855
  • MPP数据库行内已经在使用,OLAP性能很好,但是做历史数据查询这类返回行数可能很少的业务场景,性能比起oracle都不如,当然可能是因为我们使用的是基于HAWQ的偶数DB,底层是HDFS,如果是传统GP相对会好点,但也不会有太突出的性能表现
    2022-04-13
wangzk0206 wangzk0206 联盟成员 数据库管理员 scrcu
首先要看下你们的技术水平,如果对大数据(hbase)比较熟悉,个人建议用大数据平台这些。(大数据平台用的好,是非常不错的,如果使用不当就会掉坑里)如果对大数据平台不熟悉,可以考虑mpp数据库,毕竟这个sql,表设计都和传统数据库类似,经验可以借鉴。...显示全部

首先要看下你们的技术水平,如果对大数据(hbase)比较熟悉,个人建议用大数据平台这些。(大数据平台用的好,是非常不错的,如果使用不当就会掉坑里)
如果对大数据平台不熟悉,可以考虑mpp数据库,毕竟这个sql,表设计都和传统数据库类似,经验可以借鉴。

收起
银行 · 2022-04-13
浏览1849
  • 感谢回复,MPP数据库行内已经在使用,OLAP性能很好,但是做历史数据查询这类返回行数可能很少的业务场景,性能比起oracle都不如,当然可能是因为我们使用的是基于HAWQ的偶数DB,底层是HDFS,如果是传统GP相对会好点,但也不会有太突出的性能表现。现在可能看下来也是偏向于HBASE
    2022-04-13
zwz99999 zwz99999 系统工程师 dcits
如果你的源数据库是oracle,目前可以继续使用原来的oracle数据库作为查询服务器,也可以使用国产的数据库,比如Inspur K-DB,南大通用Gbase8s ,华胜信泰ΣDB,以及达梦DM等,因为其架构和SQL兼容性和oracle比较接近,从长远看也顺应了国产化的趋势...显示全部

如果你的源数据库是oracle,目前可以继续使用原来的oracle数据库作为查询服务器,也可以使用国产的数据库,比如Inspur K-DB,南大通用Gbase8s ,华胜信泰ΣDB,以及达梦DM等,因为其架构和SQL兼容性和oracle比较接近,从长远看也顺应了国产化的趋势

收起
系统集成 · 2022-04-12
浏览1934
  • 国产传统OLTP关系型数据库,比如达梦这类,其性能还不如单机Oracle,所以就没有考虑,倒是分布式数据库可能会有一些优势,但随之带来的会有分片选择这种额外工作了
    2022-04-13
like052 like052 数据库管理员 学习 待业中
如果没有历史数据的变更,可以看看GP或者doris 是否符合要求。都是MPP类的数据库。标准的SQL语法。但是GP对于DDL的处理太重了。显示全部

如果没有历史数据的变更,可以看看GP或者doris 是否符合要求。都是MPP类的数据库。标准的SQL语法。但是GP对于DDL的处理太重了。

收起
软件开发 · 2022-04-12
浏览1931
  • MPP数据库行内已经在使用,OLAP性能很好,但是做历史数据查询这类返回行数可能很少的业务场景,性能比起oracle都不如,当然可能是因为我们使用的是基于HAWQ的偶数DB,底层是HDFS,如果是传统GP相对会好点,但也不会有太突出的性能表现
    2022-04-13
  • like052  like052
    如果逻辑不复杂,就还是使用Oracle+表压缩吧。 压缩表也挺高,条件固定性能也很好。不管哪种技术只要条件固定,筛选性能好一般都可以,就怕条件不固定,选择性太多,这种就上ES吧,但是成本又比较高。
    2022-04-14
luckman_2008 luckman_2008 联盟成员 系统运维工程师 人寿保险
主要看你的历史数据是什么类型,比如结构化数据,可以采用国产分布式数据库,实现存储scaleout,如果是非结构化数据,可以采用支持json格式的,比如hhbase,es等支持非结构化数据的数据库,重要的是能否存储量可以扩展...显示全部

主要看你的历史数据是什么类型,比如结构化数据,可以采用国产分布式数据库,实现存储scaleout,如果是非结构化数据,可以采用支持json格式的,比如hhbase,es等支持非结构化数据的数据库,重要的是能否存储量可以扩展

收起
保险 · 2022-04-02
浏览2070
  • 由于数据源是Oracle,所以全部都是结构化数据库。国产分布式数据库也在用,但基本都是行存为主的方式,可能在大宽表的性能上不够具有优势,只能说通过分片后减低多行获取的IO开销来提升性能
    2022-04-02
李英杰 李英杰 数据库技术专家 烁林软件
单纯从需求来看并不复杂,主要需求是对数据的归档和查询,业务数据大部分也应该是结构化的数据,偶有表关联查询,数据并发查询应该也不会太高,数据量应该会很大,我建议可以考虑采用云原生数据库,云原生数据库是在公有云、私有云和混合云等新型动态环境中,基于存储与计算分离架构的,存...显示全部

单纯从需求来看并不复杂,主要需求是对数据的归档和查询,业务数据大部分也应该是结构化的数据,偶有表关联查询,数据并发查询应该也不会太高,数据量应该会很大,我建议可以考虑采用云原生数据库,云原生数据库是在公有云、私有云和混合云等新型动态环境中,基于存储与计算分离架构的,存储和计算可以独立弹性扩展的松耦合数据库系统。同时,云原生数据库还需具有 高性能 、 高可扩展 、 一致性保证 、符合标准、容错、易于管理和多云支持等特性。满足楼主4条简单要求的同时,也可以提供更复杂的应用场景,提高数据的利用率,降低成本。

收起
系统集成 · 2022-04-13
浏览1706
pysx0503 pysx0503 联盟成员 系统工程师 第十区。散人
在不同的环境和需求下,所对应的解决方案也会有很多不同具体的选择上应该考虑数据体量有多大,独立的开始查询中心是否为以后其他的业务提供查询数据支撑,还是只作为一个历史备查数据,按现在的了解来看应该更多的还是希望爱用成熟产品,在保证逐渐增加的历史数据查询的情况下减少...显示全部

在不同的环境和需求下,所对应的解决方案也会有很多不同具体的选择上应该考虑数据体量有多大,独立的开始查询中心是否为以后其他的业务提供查询数据支撑,还是只作为一个历史备查数据,
按现在的了解来看应该更多的还是希望爱用成熟产品,在保证逐渐增加的历史数据查询的情况下减少增加的资金投入和技术投入。
因为对数据库是在了解的有限,,也不好随便给出建议,在现有了解的一些产品中。好像HBASE比较适合你们的需求。另外还有要考虑的就是国产化的问题。俄乌冲突也一定会加剧信创产品的推进,很多行业都早晚要面临这一步,虽然国产数据库在成熟度上还有一定的差距,但个人觉得还是提前了解准备,避免政策推行时太过匆忙。

收起
系统集成 · 2022-04-13
浏览1753

提问者

匿名用户
其它 某银行
擅长领域: 数据库服务器存储
评论69

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2022-04-01
  • 关注会员:12 人
  • 问题浏览:4866
  • 最近回答:2022-04-13
  • X社区推广