oceanBase是否列式存储及大宽表查询咨询

【产品名称】oceanBase

【产品版本】v3.1.0_CE_BP1

【问题描述】

业务原因我们有一张大宽表,大概200-300字段,都是text类型,不能添加索引,根据bussinessId区分业务(最大业务数据量3000W)。目前有个业务需要通过某个字段去关联人员表(大概10W数据),test1字段保存的是逗号分隔的人员id,例如:‘123,124,125’,关联查询后需要把id翻译为姓名,例如:‘张三,李四,王五’,然后根据姓名排序。

我是用的8C32G的centos7测试的,我通过datax导入了400W数据。刚开始的时候count一下直接就超时了,后来发现是因为我直接导出的原mysql数据库的建表语句创建的表,原来里面的索引失效了,我又重新创建了id索引可以了。

但是同样的数据,同样的索引,我在mysql里面count耗时0.5-0.8s,在ob就是1.2-1.5s.然后加上了parallel(8)之后就变成了0.3-0.4s.

后来测试了一下select * from form_value where test1=‘46464a4sfas’;类似这样的sql,因为没有索引好像直接超时了。

想请问是不是因为我们类似的业务不适合用ob,或者说需要什么怎么调整可以优化查询速度。

我老大的意思是最好是纯sql不要加类似parallel(8)这样的在sql里面

  1. 关于 存储格式, 你可以参考这个 问答 https://open.oceanbase.com/answer/detail?id=401

简单来说, oceanbase 是行列混合的方式. 

你是8核32g, 我们给你一个新的配置文件, 你重新配置一下, 

另外, 我们数据量越大越有优势, 其实8核32g是不适合ob 运行, 我们线上最低要求是16核64g

你以后业务也会增长飞速, 数据量应该很快就会翻一倍吧

你能把数据量翻一倍 在16核64g 下进行测试一把吗?

1.类似parallel(8)这样的语句能不出现吗

2.我用同样的数据和资源试用了某列式数据库,虽然没有达到预期,但是其他各方面表现都可以的。单字段无索引查询3-4s就出来,但是ob表现就不太好。这样的结果我没办法申请再多的资源。

1 个赞

select * from form_value where test1=‘46464a4sfas’;

索引还是建议要的。索引主要是为查询服务,适合“大海捞针”场景。

alter session force parallel query parallel x

x 为你的并行度

可以在session 级别修改并行度