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

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

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

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

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

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

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

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

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

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

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

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