GBase 8a缺点主要在频繁的小文件处理、复杂事务、主键唯一键等。
如下只是本人的根据2020年产品版本使用感受，仅供参考，如有疑问，请联系GBase原厂商，也许新的版本已经解决或改善这些缺点。
根据多年使用经验，不同的数据库，只适合某些特定的应用场景，那些宣传一套包打天下的，要不就是虚假宣传，要不就是提供了多个内部实现，来让用户自行选择，来适应各种需求。
GBase 8a MPP 集群数据库，定位于分析场景(OLAP)，目前的主流版本是居于纯列存的，而且是每个列都单独存储，所以也拥有传统列存的通用缺点。
目录导航
1、不擅长小文件，高频率的数据变动操作
由于每个列都单独存储，每一行数据的变动，都要涉及到每个列，相对于【行存】，对磁盘IO有更多的要求。 比如1000列的表，每次insert一行，每秒insert 10次，这就是最典型的不适合。 而对应的传统行存的基于事务的OLTP数据库，却非常适合这个场景。每秒10个已经是很低的TPS了。
相对的，如果每次加载100行，对于GBase来说，需要的IO次数是相同的(GBase 8a内部的最小处理单元是DC, 包含65536行)，而入库效率却提高了接近100倍。 在一定限定内，单次处理的文件越大，列存的影响就越小。 一般建议每个加载入库的文件，在1-10G级别。
在GBase 8a V95版本里，单独增加了对小文件的优化，比如几行-几千行的这种，性能提升几倍。内部实际类似先写入日志，再后台批量处理的方式，降低IO需求，对调用方，可以快速返回响应。
2、不擅长事务处理
由于定位OLAP,所以对事务的处理能力接近于0，新版本也只针对极其简单的事务做了优化，而且不支持用一个表的并行事务。
原因是底层存储，目前没有多版本控制，只有读写AB两个版本，对于变动操作，只有1个版本可用，其它sesssion的变动或者等待，或者报错。
3、不支持常见的主键、唯一键等功能
由于定位大数据，比如百亿，千亿级行别，PB级别，而主键，唯一键等需要在每次入库时，判断是否已经存在冲突，这将极大的影响大数据的【入库】性能。比如 入库1000万行数据，要在现有1000亿行里判断是否唯一，耗时太长。
数据库的使用入门，请参考
《GBase 8a数据的缺点是什么》有1条评论
评论已关闭。